#launchpad-dev 2009-08-17
 * thumper primal screams
<spm> thumper: fwiw. supermirror on staging is revno 8386. does that help? or you need app as well. ??
<thumper> spm: app
<spm> bleh
<thumper> my great plan to speed something up has been derailed
 * thumper needs to rethink
 * thumper heads to class
<thumper> spm: can you poke stub when he arrives and point him at his build failures?
<spm> thumper: sure
<thumper-afk> ta
<spm> thumper: as I'm sure you've noticed, no stub yet. tho he was sprinting last week, so may be in transit or similar.
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<gmb> Good morning, people of Launchpad.
<jtv> hi henninge!
<jtv> and hi gmb, as well :)
<gmb> :)
<henninge> hi jtv!
<jtv> henninge: how are things coming along with the new model class?
<henninge> jtv: it's still Monday morning here!
<jtv> henninge: I'm not expecting you to have code, just asking if you have any ideas about it yet.  :)
<jtv> henninge: (in other words, whether you have any interest in a pre-imp call or whether you want to look at it some more)
<henninge> jtv: no pre-imp yet ;-)
<jtv> ok :)
<wgrant> Um, why are bugnotificationrecipients being archived, but not the actually useful bugnotifications?
<BjornT> wgrant: the idea was to archive both, so stub probably forgot to archive the BugNotification table, or intend to do that later.
<BjornT> stub: ^^^^
<mrevell> Morning :)
<wgrant> BjornT: Or maybe the intention is to not prune bugnotification, as that isn't too supermassive at the moment.
<BjornT> wgrant: the intention was to prune bugnotication and have a cascading delete that delets the bugnotificationrecipients records as well.
<wgrant> BjornT: Ah.
<gmb> I hate software.
<thumper> gmb: so do I
<thumper> gmb: I hate hardware too
<gmb> thumper: Hmm. I also hate ISPs over whose network a connection to Canonical IRC seems astonishingly laggy.
<gmb> (As does any connection to my IRC proxy. I wonder if that's because both are over SSL).
* mrevell changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/
<gmb> BjornT, FTR, I'm not able to connect to the internal IRC server reliably ATM for the morning call..
<gmb> s/call/meeting
<BjornT> gmb: ok. does skype still work?
<gmb> BjornT: Yes.
 * gmb lunches
<beuno> gooooood morning everyone
<noodles775> hiya beuno :)
<deryck> morning beuno
<beuno> how's it going noodles775?
<noodles775> beuno: yeah ok, glad to be back to doing some actual dev work :) (had a busy OCR day last thursday). And you?
<beuno> noodles775, sprinting with the Ubuntu One guys
<noodles775> beuno: ah, great! Hope it's lots of fun!
<beuno> noodles775, it is  :)
<allenap> Does anyone know when is edge going to update? It's been *ages*!
<intellectronica> allenap: yeah, it's a bit annoying. staging is up-to-date, though, if you need to test stuff
<beuno> allenap, let's stalk flacoste as soon as he comes up
<allenap> intellectronica: Cool.
<allenap> beuno: Yeah :) I want to *see* new stuff already :)
<beuno> me too!
<intellectronica> beuno: not urgent but just a reminder, that we still need to figure out a nice hover image for pages with large clusters of edit icons
<beuno> intellectronica, yes, it's on the top of my list
<beuno> I will try and get something out today or tomorrow
<intellectronica> coolio
<jtv> herb, question: did my CP of 9107 and 9030 really go onto the codehosting server?
<gary_poster> hey leonardr.  My branch to put all of the zope code as distributions as assembled by buildout is waiting for review from flacoste.  I know that was a prerequisite for migrating launchpad to the newer versions of lazr.restful and friends, but I don't remember why--and particularly, if there was something else that needed doing before it could be merged in.  Do you remember?
<leonardr> gary: i don't remember. i think it had something to do with the interplay between launchpad, lazr.restfulclient, and launchpadlib
<leonardr> but at this point i think the best thing to do is just try it
<gary_poster> leonardr: ok.  I might give that a brief whirl sometime today to just get a feel for the problems.
<gary_poster> barry: btw, Jim Fulton now has a predefined set of Zope packages ("Known Good Set") that work together and with Python 2.5 and 2.6.  (the improvement over the previous situation is that each package was supposed to be ready for 2.5/2.6, but there was no automated testing to show that the individual packages all worked together reasonably).  This should hopefully help us in our migration path.
<barry> gary_poster: fantastic!
<barry> leonardr: lazr.restful.simple isn't in the released version of lazr.restful yet, is it?
<leonardr> barry: no, but if you need it i can do a release
<barry> leonardr: if you can do that this morning it might be cool.  i think i can at least do a partial simplification of my code before i give my lazr.restful talk tonight
<leonardr> barry: ok, i'll do that now, should just take a minue
<barry> leonardr: awesome, thanks!
<leonardr> barry, can you review this trivial diff: https://pastebin.canonical.com/21213/
<barry> sure
<barry> r=me
<henninge> jtv: ping
<jtv> henninge: pong
<henninge> jtv: ah, you dropped of the internal IRC
<henninge> jtv: Is there an existing example for something like "TranslatedMessage" ?
<jtv> henninge: the new model class?  Not that I can think of, and that's why we are having these problems.  TranslationMessage sort of fakes it right now by keeping track of the "browser_pofile."
<henninge> jtv: I see.
<adeuring> I'm getting the error "Sender not authorised to commit to branch lp:~launchpad-pqm/lazr.restful/trunk" when I try to pqm-submit a lazr.restful branch. Any ideas what I'm doing wrong?
<jtv> henninge: you could see ProductSeriesLanguage as a recent example of the general construct though.
<henninge> jtv: let me look at that. Yes, I was looking for the general construct.
<jtv> henninge: at its heart it's a "tuple" of two proper model objects."
<BjornT> adeuring: i would try specifying the bzr+ssh url instead of the lp one
<adeuring> BjornT: thanks, I'll try that
<henninge> jtv:  a productseries and ... a pofile ... a language?
<jtv> henninge: in that case, a productseries and a language.  There can be multiple POFiles, otherwise there'd be little point.  :-)
<henninge> jtv: ah, of course ...
<intellectronica> adeuring: yes, using the bzr+ssh protocol should work. however, it didn't work for me last time i tried for independent reasons, so let me know if it works for you or not
<henninge> jtv: there is  a ProductSeriesLanguage and a -Set.
<adeuring> intellectronica: sure... just isuued the pqm-submit again...
<henninge> jtv: so analogous a TranslatedMessageSet would be potmsgsetset (a potemplate) bound to a pofile.
<jtv> henninge: no, that's your TranslatedMessage AFAICS.  If you want a -Set, that's basically the POFile.
<jtv> henninge: sorry, I misread.  What you said is basically a POFile.
<jtv> henninge: or maybe I'm confused about your terminology, since the "Set" in POTMsgSet is in no way related to the -Set in TranslatorSet, POTemplateSet etc.
<leonardr> barry: ok, lazr.restful 0.9.3 is out
<henninge> jtv: yes, I used "SetSet" there ...
 * jtv cries softly into his keyboard
<henninge> jtv: so I a aware of the different meaning of set
 * henninge gets jtv something to wipe his keyboard with .
<barry> leonardr: thanks!
<henninge> jtv: We will need a DummyTranslatedMessage, too.
<henninge> won't we?
<jtv> henninge: yes, I think we need one for dummypofiles.
<jtv> henninge: but it may depend on the details...  a TranslatedMessage referring to a DummyPOFile may be good enough.
<henninge> jtv: ok, details later ;-)
<jtv> I certainly wouldn't introduce a DummyTranslatedMessage unless it's necessary.
<henninge> jtv: ok
<henninge> jtv: hm
<henninge> jtv: I just realized I am not sure what we are trying to accomplish with the new model class.
<henninge> jtv: please don't cry!1
<jtv> henninge: you're trying to build a model class that we can attach the "one translatable message plus translation & suggestions" view to.
<henninge> jtv: A TranslationMessage is already specific to a POFile. Why can't we work with TranslationMessage directly
<henninge> oh!
<henninge> jtv: So it is "All TtranslationMessages for this POTMsgSet for this POFile" ?
<jtv> Pretty much, yes...  I'd say "the translation state for this POTMsgSet as seen in this POFile."
<henninge> jtv: ok, or that ;-)
<jtv> As you can see, the TM is "one step too far down" to do this well.
<henninge> jtv: Yes, I see that now. I was only confused for a short time.
<jtv> Also, right now, there's the weird problem that when you look at an individual message now, you're basically looking at a TranslationMessage that may be shared between POFiles.  So... how do we get the sequence number?
<henninge> jtv: So I need to provid acces to 1. The current message 2. the imported message 3. the shared message 4. all local suggestions 5. the external suggestions.
<henninge> jtv: POFile gives us POTEmplate
<henninge> jtv: doesn't it?
<henninge> oh no, it's the other way round.
<jtv> henninge: there's no reference to either (except if the TM is diverged, but let's not count on our luck :)
<henninge> jtv: so the model class needs a concept of which potemplate it refers to.
<jtv> henninge: exactly, that's the other bit of information you'll be holding onto in your new class.
<henninge> so init would be (POTMsgSet, POFile, POTemplate)
<jtv> henninge: POTemplate == POFile.potemplate
<jtv> henninge: but otherwise, yes, that's it.
<henninge> jtv: oh, it does
 * henninge has to look at jtv's great diagram again ...
<henninge> jtv: that's what I meant when I said
<henninge> jtv: POFile gives us POTEmplate
<jtv> henninge: and you were right there, not wrong :)
<henninge> jtv: so init would just be (POTMsgSet, POFile)
<jtv> henninge: yup
<jtv> that's the basic information you're holding together, and everything else will follow from that.
<henninge> jtv: let me draft the interface to see what I might be missing.
<henninge> jtv: btw, should we stick with "TranslatedMessage"?
<jtv> henninge: it's going to suck typing that, but I guess we'll have to get used to it.  I can't think of anything better.  (Even if the message is untranslated, it's basically just a TranslatedMessage without a current translation)
<danilos> henninge, jtv: TranslatableMessage is what it is
<jtv> \o/
<barry> OMG ugly: notfound-traversals.txt
<henninge> danilos: The probelm is just that "Set" is already used in different places for a "List" ... ;-D
<danilos> henninge: oh well, I believe 'TranslatableMessage' is good, except that I don't like our choice of 'TranslationMessage' then :)
<sinzui> bac loot at the firefox project as sample person in dev to see a converted layout. The sidebar uses all the conventions
 * henninge just noticed the "able" instead of "ed"
<henninge> but that's ok.
<jtv> barry: hey, at least it's not spending all its time in sleep() any more!
<sinzui> bac: mozzila is also a good one to look at
<jtv> danilos, henninge: I initially coined -able, but I think -ed is just fine; less confusion possible with POTMsgSet
 * henninge halts in the middle of renaming
<danilos> jtv: POTMsgSet is English/SourceMessage :)
<henninge> danilos ?
<jtv> danilos: don't go there today... just... don't.  :-)
<danilos> jtv, henninge: there's no solution possible that works well for everything, but I like Translat*able*Message much more than anything else
 * barry wants to spend all his time in sleep()
<henninge> danilos: you're the boss
<danilos> one could say that we never fixed this because we couldn't come up with a proper name :)
<jtv> ...but changing names every few years is almost as good, right?  ;-)
<danilos> barry: you can instead look at the incremental diff for the review you did for me on Friday (thanks!), per your request, I made it another 800 lines :)
<jtv> barry: one of those things in life we shouldn't automate
<barry> ooh!  pretty footers
<danilos> jtv: heh, yeah, definitely, that helps a lot keep the momentum
<barry> jtv: oh trust me, i'm not assigning that task to my clone army, i'm keeping that one for myself.  sure, i'll let a clone eat for me now and then, or shave or stuff like that
<henninge> oh, here comes a review ...
<jtv> barry: I wouldn't want to automate eating either, but frankly, "hungry" is a problem I already fixed.  Why does it keep regressing?
<beuno> sinzui, https://staging.launchpad.net/ubuntuone-client
<beuno> TraversalError: (<canonical.launchpad.webapp.tales.MenuAPI object at 0xb3ebfd0>, 'specications')<br />
<sinzui> beuno: if someone would only review my fix
<sinzui> form friday
<beuno> sinzui, I should of know you had already fixed it  :)
<beuno> flacoste, hi
<barry> jtv: i don't know, but my unit test for that is always dumping core
<beuno> flacoste, where's my edge rollout?  :)
<sinzui> beuno: The Involvement portlet will work with everything as soon as I can land it
<flacoste> hi beuno!
<flacoste> beuno: good question
<jtv> barry: that's invariable a sign of bad input
<barry> jtv: bzr rm dairy.txt
<jtv> barry: please don't take this analogy to "bzr push"...  :)
<barry> :-D
<flacoste> beuno: should be back later this morning
<beuno> flacoste, merce beaucoup
<danilos> rockstar: have you guys seen something like https://code.edge.launchpad.net/~danilo/launchpad/bug-410579/+merge/10179 (OOPS-1325EA163) before?
<flacoste> beuno: hay no problema
<danilos> flacoste: I think you want plural there (i.e. 'problemas') :)
<beuno> actually, just invert the words:  no hay problema
<danilos> oh well, I guess I have no clue :)
<bigjools> but what about the Spanish?
<beuno> danilos, you need more sprints in Argentina
<danilos> beuno: we'll have them, I am all for it :)
<bigjools> beuno: do you know the runes to get those vertical lines I needed in the two-row-headed table on the DSPR mockup I showed you?
<beuno> rockstar, hi
<beuno> bigjools, css rules?
<henninge> jtv: I have a review on the list now. What was that about your time?
<jtv> henninge: I'm past EOD, I need to grab dinner, and I've got a call coming up.
<bigjools> beuno: I would hope so, but I don't know much about how to do that sort of thing
<jtv> henninge: so find another sucker.  :-P
<henninge> jtv: ok, talk to you tomorrow, then. I'll grab the other sucker, then... ;-)
<beuno> bigjools, border-right-style: solid;?
<jtv> henninge: Hals- und Beinbruch.  :)
 * jtv runs
<henninge> lol
<barry> sinzui, beuno ping
<sinzui> Hi barry
<beuno> barry, pong
<barry> beuno, sinzui: hi.  so on /people, there is a small action portlet to view projects, view distributions, view people, view meetings, register a team, merge accounts.  i'm making this page w/o side portlets.  how much of those functions to we want to migrate inline
<barry> beuno, sinzui i have already moved merge accounts inline.  is it useful to keep the 4 view actions and teh register a team action?
<sinzui> barry: That is an excellent question.
<sinzui> barry: For content objects, that menu would be rendered as a related pages section; the last portlet in main content.
<beuno> sinzui, barry, would you guys like to joins us in the UI call today?
<barry> beuno: sure what time
<barry> sinzui: yeah.  i really don't want to add a portlet just for those actions
<beuno> mars, rockstar, EdwinGrubbs, noodles775, intellectronica, jtv-brb, barry, sinzui, UI call in 25'
<noodles775> yup.
<sinzui> barry: beuno: the top-level collections are not common content objects, may be should consider a sidebar for them with an action style menu
<barry> i'm just not sure how useful the 4 'view' links are.  registering a new team, yeah i can see that, and i could easily add that inline
<beuno> sinzui, maybe that's the right thing to do, yes
<barry> beuno: cool
<intellectronica> beuno: sure. cheers for the reminder
<sinzui> barry: the two new menu presentations work with NavigationMenus.
<barry> beuno, sinzui so, add an action style menu for this page and move those links into that?
<barry> beuno, sinzui and put that menu in a sidebar?
<beuno> barry, probably, but a screenshot would give you a definite answer  :)
<sinzui> barry: It is possible to define one menu in browser/__init__, then use it on all the top level collections.
<barry> sinzui: they are slightly different among the three top level pages
<barry> (currently)
<barry> beuno: gotcha ;)
<rockstar> beuno, hi
<sinzui> barry: should they be? We can use enable to enable some links.
<beuno> rockstar, I've been wondering what's up with answers?
<barry> sinzui: if we move some of the actions inline, then they would share the 'View Thing' links.  there are some admin functions in the sidebars currently, but like with /people, i think we can move those inline
<salgado> sinzui, beuno, should https://edge.launchpad.net/codeofconduct/1.0.1/+sign be locationless?
<barry> sinzui: so shared would be view projects, view distributions, view people, and view meetings
<beuno> salgado, I think so, or "Launchpad.net"?
<rockstar> beuno, what do you mean?
<sinzui> barry: these pages could be the first legitimate use of a context and view navigation menu. Consider that (+) Register <yourself|product> is in a action menu, and the other collections are inline in a related searches menu
<beuno> rockstar, I haven't seen any landings?
<rockstar> beuno, it's because I haven't yet landed anything.
<salgado> beuno, "Launchpad.net"?
<barry> sinzui: that makes sense
<beuno> rockstar, any reason for it?  as in, are you going to land everything in one chunk?
<rockstar> beuno, I have a pipeline here where Answers is being ported.  It's getting along.
<barry> sinzui: okay cool.  let me see what i can mock up
<beuno> salgado, I think the location for everything that's not in a context is "Launchpad.net". sinzui?
<sinzui> barry: I think we need to move the browse/search links inline if they exist
<sinzui> beuno: salgado: yes.
<beuno> rockstar, I'm asking because we're tracking progress in https://devpad.canonical.com/~mars/conversions.html
<beuno> rockstar, and answers is at zero, and I get asked about it a lot  :)
<rockstar> beuno, I understand this.  If I wasn't filling in for abentley on CHR today, we'd probably see changes.
<barry> sinzui: /people doesn't have those links
<rockstar> beuno, why anyone is asking you I don't know.
<sinzui> beuno: everyone. do not just look at the number of templates converted. thumper ans I are also deleting pages
<beuno> sinzui, we don't have a way of tracking that, do we?
<rockstar> sinzui, good point.  I've deleted probably 8 templates so far.
<sinzui> barry: true, but a related pages menu should be shared by all the top-level collections, that Is why I mention that we want a common menu in __init__.py and that is related, not action
<sinzui> rockstar: you rock
<salgado> beuno, sinzui, I'm not following you. what's this "Launchpad.net" location? is it just another name for the locationless macro?
<barry> sinzui: yes, i think so
<sinzui> beuno: we needed to save the count of total pages when we started
<rockstar> sinzui, :)  I'm not done yet.
<rockstar> sinzui, generic-edit is frakkin awesome.
<sinzui> yep
<beuno> salgado, yes
<danilos> henninge: I've filed a https://blueprints.edge.launchpad.net/rosetta/+spec/pofile-translate-page and the first bug for you (bug #414856, linked from the blueprint as well)
<mup> Bug #414856: Provide a model class for TranslatableMessage <cleanup> <Launchpad Translations:Triaged by henninge> <https://launchpad.net/bugs/414856>
<henninge> danilos: cheers, now I find purpose in life!
<henninge> ;)
<danilos> henninge: there you go, I am always happy to be so helpful :)
<beuno> barry, UI call!
<beuno> kiko's #
<kiko> yay
<beuno> hola kiko
<barry> beuno: ah dang.  calling in now
<flacoste> beuno: edge updated and will be updated daily from now on
<beuno> flacoste, danke
<sidnei> gary_poster, flacoste: ping
<gary_poster> sidnei: pong
<sidnei> gary_poster: we found an issue that seems like it might affect launchpad too
<gary_poster> sidnei: what's up?
<sidnei> gary_poster: request.supportsRetry() does a sleep() with a random number in the version of zope3 we are using
<gary_poster> heh, uh...weird
<gary_poster> sidnei: is that as insane as it sounds?
<sidnei> gary_poster: yeah :/
<sidnei> gary_poster: seems like this was reported as #401586
<mup> Bug #401586: Zope sleeps during tests <test-system> <Launchpad Foundations:Fix Committed by jml> <https://launchpad.net/bugs/401586>
<sidnei> except it's being papered over during tests, and might still affect production
<gary_poster> sidnei: looks like it's only being papered over for one test, if I read that bug report correctly.  have you seen if this is in trunk for that package?
<sidnei> gary_poster: about to check
<gary_poster> me too ;-)
<gary_poster> sidnei: yes
<gary_poster> sidnei: not an env; apparently supposed to be used as a monkey patch...
<gary_poster> changed I mean
<sidnei> gary_poster: yeah. also, the sleep() should probably be in retry() not in supportsRetry() right?
<gary_poster> sidnei: yeah, I would sure think so.  have you done an annotate yet to see who did this thing?  I went to the web interface.
<gary_poster> sidnei: stevea did it, with Jim following along behind...
<sidnei> gary_poster: indeed
<gary_poster> sidnei: you wanna follow up on list/IRC/steve, or me?
<gary_poster> maybe we should look at doctests really wuickly
<gary_poster> quickly
<BjornT> sidnei, gary_poster: my guess would be that if two requests collides with each other, causing a retry, they shouldn't be retried at the same time, causing them to collide again. not sure how feasible that use case is, though...
<gary_poster> sidnei: I don't see anything explaining it in doctests, interfaces, or tests
<gary_poster> BjornT: yes, but why in supportsRetry rather than retry?
<sidnei> gary_poster: actually, it was jim that added it, and stevea just cleaned up 1/True
<gary_poster> sidnei: ah, ok, I was not paying attention to the revids closely :-/
<BjornT> gary_poster: yeah, that seems a bit crackful... could it be that the transaction gets started before retry() is called?
<BjornT> nope, doesn't look like that would be the case
<gary_poster> BjornT: no don't think so either
<gary_poster> sidnei: you want me to contact Jim about this?  Or are you going to pursue?
<sidnei> gary_poster: let me ask therve, he's the one that found it. we are about to leave for lunch.
<gary_poster> sidnei: ack
<sidnei> gary_poster: so, if you can ping jim that would be great, as you know we are resource constrained. :)
<gary_poster> sidnei: ok will do.
<bigjools> beuno: colgroup FTW -> http://people.canonical.com/~ed/dspr_mockup4.png
<beuno> bigjools, NAIS
<beuno> that page still has issues, but getting there
<bigjools> beuno: I am only aware of the file size one now ...?
<beuno> bigjools, yes, and things are kind of squished?
<beuno> fonts are wonky
<bigjools> it renders differently in Konq  vs FF
<Ursinha> danilos, hi
<danilos> Ursinha: hi, how's it going?
<Ursinha> danilos, good, good
<beuno> flacoste, https://dev.launchpad.net/UserInterfaceReviewNotes
<barry> beuno: https://dev.launchpad.net/ReviewerSchedule
<barry> leonardr: ping
<leonardr> barry, yo
<barry> leonardr: there's a critical bug in lazr.restful 0.9.3.  can you do a quick update to 0.9.4?  simple.py does not import traceback
<leonardr> dammit
<leonardr> sure
<barry> let me make sure my test works with that change...
<barry> leonardr: yep. my test fails but for unrelated reasons.  adding traceback to simple.py will fix the problem
<rockstar> flacoste, I have a user asking me why we're using SSL.  What should I tell him?
<barry> leonardr: rs=me
<gary_poster> leonardr: before you make another release...
<leonardr> ...
<gary_poster> maybe you should remove this 2.5-ism
<gary_poster>   File "/home/gary/canonical/lp-sourcedeps/eggs/tmpm4lpr9/lazr.restful-0.9.3-py2.4.egg/lazr/restful/example/wsgi/root.py", line 44
<gary_poster>     self.schema = ('https' if config.use_https else 'http')
<barry> gary_poster: 2.6'ism?
<gary_poster> barry, heh, I couldn't remember :-) .  I went for being confident in the hope that at least I'd communicate my point ;-)
<barry> :-D
<beuno> kfogel, any news on the LP badge?
<beuno> deryck, description editing on edge, woooooooooooooooooo
<deryck> beuno, excellent!!!
<beuno> deryck, what do you think about making the descriptiuon text larger?
<deryck> beuno, totally fine with that.  I did wonder if it was small once.  Early on. :)
<beuno> :)
<deryck> beuno, I hate to be too lazy, but do you mind opening a bug on that for me?
<beuno> deryck, damn, I was about to ask you the same thing
<deryck> heh
<beuno> you win for being slightly less lazy
<barry> leonardr: i'm going to get some lunch.  ping me if you need a review.  would love to get 0.9.4 out today (for my talk tonight)
 * barry -> lunch
<deryck> beuno, and that's the grown-folks version of the little kids "not it!" played out in IRC.
<leonardr> gary: since barry just left, would you review https://pastebin.canonical.com/21222/ ?
<beuno> deryck, LOL
<gary_poster> leonardr: yes. looking
<gary_poster> leonardr: r=gary
<leonardr> yay
<leonardr> gary: argh, i forgot this part
<leonardr> === modified file 'src/lazr/restful/version.txt'
<leonardr> --- src/lazr/restful/version.txt        2009-08-17 13:38:04 +0000
<leonardr> +++ src/lazr/restful/version.txt        2009-08-17 16:23:45 +0000
<leonardr> @@ -1,1 +1,1 @@
<leonardr> -0.9.3
<leonardr> +0.9.4
<leonardr> gimme an ok on that and i'll do the release
<gary_poster> leonardr: +1
<leonardr> barry: 0.9.4 is out
<gary_poster> leonardr: awesome thanks
<rockstar> sinzui, could I get you to look at https://answers.edge.launchpad.net/launchpad/+question/80132 ?
<sinzui> rockstar: I am replying. I need to read the code first
<rockstar> sinzui, great, thanks.
<bigjools> beuno-lunch, sinzui: I made a few tweaks: http://people.canonical.com/~ed/dsp_mockup_with_linkage.png
<bigjools> any comments?
<sinzui> bigjools:  If you review my involvement branch, I can fix a big error on edge and you get a one-line replacement for the dsp involvement portlet.
<bigjools> sinzui: can its context be set differently to the pillar?
<bigjools> sinzui: I can review it, but I have to disappear for 2h first, it's food + kids bed time
<sinzui> bigjools: I was *very* clever in my branch, I adapt to the pillar, read the official apps, then enable only those  menu items
<bigjools> sinzui: in my case, it needs to work with a DSP, not a D
<sinzui> bigjools: I was thinking of you when I wrote the branch
<bigjools> even though the pillar is a D (distribution)
<bigjools> anyway, bbiab
<sinzui> bigjools: I still do not understand th latest releases portlet. How often does *all* that information change. It looks like package details which I expect to be in the main content.
 * sinzui is still an idiot about anything that has a sourcepackage in its name
<bigjools> sinzui: it *can* change on any upload, whether it does or not is another matter
<sinzui> bigjools: for example, I always expect the maintainer and version to be the first portlet in the top-left of the main content like project and product
 * bigjools has to go, I can chat about this later!
 * gmb -> food
<gary_poster> leonardr: getting some basic failures from attempt to switch to distributions for lazr.* .  One: "import lazr.restful.testing.layers" fails.  Indeed, that module does not exist in 0.9.4.  Where is it now?  (See lib/canonical/lazr/testing/layers.py for this particular usage)
<leonardr> gary: sorry, i gotta go pick up lunch. i have questions for you as well; we'll swap when i come back
<gary_poster> leonardr: cool, I'll do the same
<barry> leonardr-lunch: thanks!
<greg-g> dang, edge.lp just got even sexier with the inline description editing and new description layout
<beuno-lunch> bigjools, in the portlet
<beuno-lunch> "Uploaded by:" should be in a separate line than the person's name
<flacoste> rockstar: sorry, forgot to hit ENTER before getting distracted by something else: SSL, we are using to secure logged in connection, we should drop it for anonymous users
<flacoste> there is a bug open about that
<rockstar> flacoste, well, I think the user was confused.  He was calling it an "SSL leak" because Google could index our bugs.
<flacoste> hmm, yeah, that is confused
<beuno> salgado, how are those breadcrumbs going?
<salgado> beuno, I need to talk to flacoste about them, but if he's ok with the idea of using canonical_url(obj, rootsite='mainsite') for the links there, I should have it ready for review RSN
<flacoste> salgado!!!
<flacoste> salgado: can I call you?
<salgado> flacoste, sure, I'm ready
<barry> sinzui: i guess you can't have a searchless main_side page, eh?
<beuno> barry, did you file the bug about the language editing not working anymore?
<barry> beuno: i thought so, but maybe not :/
<sinzui> barry: indeed we cannot. Have you discovered a new layout? "collection" is what I would name it if we need it.
<barry> omg bork!  someone confirm that https://edge.launchpad.net/lazr-js is giving a TraversalError
<barry> that looks like a bad typo that slipped through :(
<beuno> barry, it is, and sinzui knows all about it
<barry> beuno: well then, good!  otoh, i can't confirm whether i filed a bug on that or not ;)
<beuno> barry, go for another one, free karma
<deryck> sinzui, hi.
<sinzui> beuno: barry: the fix is being reviewed now
<sinzui> Hi deryck
<salgado> flacoste, https://wiki.canonical.com/Launchpad/UI/Navigation
<barry> beuno: bug 413793
<mup> Bug #413793: inline editing doesn't play nicely with launchpad 3.0 UI <LAZR Javascript Library:New> <https://launchpad.net/bugs/413793>
<deryck> sinzui, can you look at my question on bug 413611?
<mup> Bug #413611: Convert the comment add templates to 3.0 UI <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/413611>
 * sinzui looks at diff
<sinzui> deryck: The answer is not good
<deryck> thanks!
<deryck> oh bummer
<sinzui> deryck: form does not use the form-layout-macros, so the label is not being made for you
<beuno> flacoste, joey, kiko, one second drop with the new design: http://www.webpagetest.org/result/090812_22DN/1/details/   vs    http://www.webpagetest.org/result/090817_235W/1/details/
<sinzui> deryck: I think we should hack the missing pieces in
<beuno> I don't quite understand the request count though, ti says it only went down by 4
<kiko> beuno, how about we get some sprites in there now? :)
<deryck> sinzui, I wondered if it was because of the custom form class.  But was confused by the branch using edit-generic showing the same issue.
<beuno> kiko, yeah. Although, the biggest impact would be if flacoste finished his CSS compression branch so we don't make so many calls
<kiko> beuno, why doesn't the JS start loading earlier?
<beuno> kiko, 13 calls *just* for CSS
<kiko> I know
<kiko> beuno, note the 404 btw
<beuno> kiko, order on the page. The JS comes after all those CSS
<beuno> kiko, yeah, no idea what that is about, but should be looked into
<sinzui> deryck: Many forms that have a good schema can use generic-edit.pt. which calls the form macros. Some pages forms need some extra-form info so they need their own template.
<sinzui> deryck: I'll copy the diff, and pastebin a suggestion
<kiko> beuno, can you put the JS before and see if it makes a difference?
<deryck> sinzui, right, but shouldn't my branch using the generic-edit.pt have the correct heading styles applied to page?  (This is a second question, apparently unrelated to the comment branch diff you looked at.)
<sinzui> no
<sinzui> deryck: the macro makes that, not the template
<joey> beuno: they both look great to me. no immediate pref
<sinzui> deryck: This is the macro used in *most* forms that make the label a <h1> and get the cancel button right:
<sinzui>     metal:use-macro="context/@@launchpad_form/form"
<beuno> kiko, I'll look into it, yes
<sinzui> deryck: does the view descend from LaunchpadFormView?
<beuno> kiko, it looks like it should make a difference
 * deryck looks....
<beuno> will test tough
<beuno> though
<deryck> sinzui, no, it's:  LaunchpadEditFormView --> BugEditViewBase --> BugEditView
<deryck> sinzui,  this is my problem then, no?
<sinzui> deryck: that is great, we can still us use it
 * sinzui hacks
<deryck> excellent, thanks for the help.
<leonardr> gary: here's my question
<gary_poster> leonardr: cool, listening
<leonardr> i've got a branch at lp:~leonardr/lazr.restful/django-helpers that adds a useful django bit to the django zcml file
<leonardr> to test this zcml bit i need to import a django class
<leonardr> but i don't want lazr.restful to depend on django
<leonardr> what do i do?
<gary_poster> leonardr: maybe you could get away with something less drastic depending on the goal of your test(s), but sys.modules hacks are an option.
<leonardr> you mean create a fake version of that class?
<leonardr> would you take a look at the branch and tell me what you'd do?
<gary_poster> leonardr: yeah, in a fake module, stuffed into sys.omdules.  sure
<kiko> beuno, it should, since it's the largest file and it seems to be downloadable together with the CSS right?
<gary_poster> leonardr: Looked at it.  I don't see too many options other than a sys.modules hack or simply not testing it. :-/  Are you asking for guidelines in the evils of sys.modules hacks?
<leonardr> gary: since that's your suggestion, yes please
<sinzui> deryck: https://pastebin.canonical.com/21228/
<beuno> kiko, yeap. Will let you know how it goes
<kiko> beuno, is 150ms time to first byte not a lot?
<kiko> beuno, and actually, 1s for the actual HTML
<kiko> wow
<kiko> oh maybe that is the time to render the actual page
<deryck> sinzui, thanks!  Reading through it and trying to get things working...
<beuno> kiko, 821 ms for the first byte
<beuno> DNS + Initial connection + SSL
<kiko> beuno, I mean why so different between the two different page loads you showed?
<beuno> kiko, hrm, I didn't notive that
<beuno> notice
<kiko> beuno, maybe do a few runs to see if it's stable
<beuno> kiko, very flaky: http://www.webpagetest.org/result/090817_235Y/1/details/
<beuno> 4067 ms TTFB
<gary_poster> leonardr: I'm writing up an example and making sure it works.  didn't see an example with a quick Google search. Meanwhile, did you see my previous question about the lazr.restful.testing.layers?
<beuno> kiko, I wonder if it's LP server or their servers?
<leonardr> gary: yeah, i'll look into that
<sinzui> beuno: https://devpad.canonical.com/~curtis/editlang.png
<sinzui> ^I tripled the number of languages the user can see in the form.
<kiko> beuno, no idea either. but the JS change and the 404 alone are worth the time investment
<beuno> kiko, I'm working on a branch for the JS, and will look into the 404
<kiko> cool
<beuno> sinzui, left-to-right ordering is bad
<beuno> sinzui, if it's going to have that layout, I think I'd prefer a one column list
<sinzui> beuno: yes it is, but it is better than it was before
<beuno> sinzui, https://edge.launchpad.net/@@/images/code-arrow-right.png
<beuno> that is being referenced in /bzr
<beuno> and, as you can see, the arrow for code is missing
<sinzui> That is fixed in my branch. It passed review, I am testing it noe
<sinzui> and the blueprint arrow is fixed
<sinzui> and the specifications spelling is fixe
<sinzui> and the portlet runs on pillars, series, and sourcepackages
<sinzui> I rock
<beuno> kiko, tests from the UK are *much* faster, but flaky as well: http://www.webpagetest.org/result/090817_2361/
<beuno> repated tests, that is
<beuno> sinzui, AWESOMENESS
<leonardr> gary: the MockRootFolder defined in testing/layers.py has been moved to testing/webservice.py
<beuno> sinzui, I think that languages in 3 columns are actually harder to find
<gary_poster> leonardr: back atcha: https://pastebin.canonical.com/21231/
<beuno> sinzui, so, a one column, longer, scrollable, is a big win
<sinzui> beuno: I can fix that
<leonardr> gary: great, should i worry about tearing that down afterwards? i don't think it matters since we aren't using django
<gary_poster> leonardr: if you were being super careful, you'd only do that if the import doesn't work in the first place, and yes, you'd tear it down if you had to set it up.  If I were doing it, I would be obsessive enough to do all of that, I suspect; and if I were reviewing, I'd ask for it, I suspect.  It wouldn't add much, and it's best practice.  OTOH, I don't object if you just see if it gets past your reviewer, because you are rig
<leonardr> gary: ok, just tell me how to tear it down. del?
<gary_poster> leonardr: yeah
<gary_poster> leonardr: MockRootFolder is in __all__ of webservice.py but is not actually defined :-/
<gary_poster> (not defined anywhere in package)
<gary_poster> leonardr: if you don't need MockRootFolder in lazr.restful maybe I'll move it back out to lib/canonical/lazr/testing...
<beuno> intellectronica, bug 414982
<mup> Bug #414982: Long milestone names break the bugtask table <Launchpad Bugs:New> <https://launchpad.net/bugs/414982>
<beuno> BjornT, the new bug comment button is super mega cool
<intellectronica> beuno: yeah, using the long names was a bit short sighted. i'll switch back to the short name
<gary_poster> leonardr: doing that gets all -t blueprint tests to pass, which has been my smoke test. could you recommend a test command to exercise lazr.restful within launchpad?
<gary_poster> trying -t webservice
<beuno> intellectronica, ah, cool, you know about it
<intellectronica> beuno: yeah, just noticed this happening earlier today when playing with a foundations bug
<leonardr> gary: -t webservice
<beuno> intellectronica, super
<gary_poster> leonardr: cool.  Total: 620 tests, 33 failures, 3 errors in 1 minutes 23.013 seconds.
<gary_poster> leonardr: this is a big culprit for many of the failures: AttributeError: 'LaunchpadWebServiceCaller' object has no attribute 'domain'
<gary_poster> leonardr: have a quick suggestion to try to fix, or should I just pass this to you?
<gary_poster> (or I can dig in on it; I'll probably move on to something else for now though unless you have an immediate suggestion)
<leonardr> gary: paste the failruies and i'l take a look
<gary_poster> leonardr: http://pastebin.ubuntu.com/254676/ which is 17000+ lines, but if you just look at the first traceback you've seen the partinent bit
<gary_poster> pertinent
<leonardr> ok
<kiko> beuno, sinzui: in general I really like the new project pages, good job
 * beuno high-fives sinzui 
<kiko> sinzui, minor quirk: listing the milestones for the current series in the project group's project listing would make my life a lot easier
<sinzui> kiko: salgado and I discussed that
<sinzui> kiko: I ask him not to make changes just yet, I want the same listing on project, product, distro, and +series
<beuno> flacoste, kiko, any of you interested in reviewing the javascript move on the header?   https://code.edge.launchpad.net/~beuno/launchpad/move-js-in-header/+merge/10267
<kiko> okay, but if you look at the listing at
<kiko> sinzui, https://edge.launchpad.net/launchpad-project you'll see what I mean
<kiko> beuno, what does the code look like?
<kiko> beuno, also, does it actually change the rendering profile? I'd be happy to cowboy that onto staging and then run a test against it
<gary_poster> leonardr: hm, this looks a bit tricky.  Seems to come down to a switch from the zope caller to the wsgi intercept bit...
<sinzui> I will add a consistent representation of milestones when I update the other pages.
<kiko> sinzui, cool
<beuno> kiko, just moves it on the main-template. I need to run it on staging to show the rendering profile, so if we can cowboy it in, that would be great
<flacoste> beuno: what is this about?
<beuno> flacoste, if you look at: http://www.webpagetest.org/result/090817_235W/1/details/
<flacoste> beuno: the diff on the m+p is screwed up
<beuno> flacoste, you'll see that, in theory, if the large javascript file was loaded first, we'd get more parallelization
<beuno> argh....
<beuno> why did that happen to the diff?
<beuno> flacoste, the diff is very simple
<beuno> just moves in in the main template
<kiko> sinzui, ugly ugly: OOPS-1325ED287
<kiko> TraversalError: (<canonical.launchpad.webapp.tales.MenuAPI object at 0x2aaaad048bd0>, 'specications')<br />
<beuno> flacoste, look at like 450
<kiko> somebody's not testing something :-(
<intellectronica> thekorn_: nice catch! (the overly eager bug linkification). should be very easy to fix. would you be interested in having a go at that? i'll be happy to help
<leonardr> gary: here's a suggestion
<leonardr> add a super() call to LaunchpadWebServiceCaller
<leonardr> pass in a domain based on base_url
<gary_poster> leonardr: ah!  ok, and the protocol from that too
<flacoste> beuno: why is the diff screwed? do you have merge unmerged branches?
<flacoste> beuno: badly stacked?
<flacoste> beuno: can you try it out on staging?
<beuno> flacoste, no idea. I updated trunk locally, branched it, and pushed
<beuno> flacoste, did what I always do
<flacoste> ok
<beuno> flacoste, if you can get it on staging, we can test to see if it does help loading or not
<thekorn_> intellectronica, sure, if you could point me to the right direction (file to look at), I can look at it tomorrow
<kiko> sinzui?
<kiko> bac, EdwinGrubbs: can either of you look into that OOPS?
<sinzui> kiko: It was fixed in my branch las friday
<kiko> sinzui, oh, but not on edge?
<sinzui> kiko: I am testing the branch now. The fix will be merged in about 2 hours
<kiko> sinzui, perfect thanks.
<beuno> sinzui, shouldn't this case be an h2 for the project's name?  https://code.edge.launchpad.net/~launchpad
<kiko> sinzui, some untested code somewhere?
<sinzui> kiko: yes.
<sinzui> kiko: We intended to replace the involvement portlet with something better. I started work on the issue since we already had plans
<intellectronica> thekorn_: see lib/canonical/launchpad/webapp/tales.py
<sinzui> beuno: I think so. Think about the bread crumbs.
<sinzui> beuno: I think this relates to the misnamed heading-slot.
<sinzui> beuno: I really need to rename that before more mistakes are made
<beuno> sinzui, yeah. Who needs to make the change?  code? noodles? or salgado?
<sinzui> code forced the <h1> into the heading-slot
<sinzui> Can I rename it context-slot?
<beuno> uhm, I don't care   :)
<sinzui> beuno: barry is making an action menu for /people
<sinzui> beuno: barry is adding Register a team
<beuno> sinzui, great
<sinzui> beuno: but should he also as "Register yourself" if you are not logged in. yes it duplicates the login, but it is also consistent
<beuno> sinzui, yes, although maybe not with those words
<beuno> "Create an account"?
<sinzui> Yes, thate is better
<barry> beuno, sinzui cool, i'll add it with 'Create an account'
<sinzui> beuno: I think the top collection pages need two menus: the action menu on the side to create items like projects and team, and a related menu at the bottom of the content for things like browse Projects.
<beuno> sinzui, sounds like a plan
<sinzui> beuno: this is the first legitimate use for an action menu and related menu on the same page. This then may need to happen for /bugtrackers and /lauguages
<beuno> sinzui, yes, I'm fine with that
<EdwinGrubbs> beuno: ping
<beuno> EdwinGrubbs, pong
<EdwinGrubbs> beuno: for the team index page, poolie had a couple of suggestions that I want to run by you first
<EdwinGrubbs> beuno: 1. remove the map
<beuno> EdwinGrubbs, completely remove it?
<EdwinGrubbs> beuno: 2. The portlets have a black link in the row for the portlet's title, such as ">> All members". He thinks they should be blue and inside the portlet body.
<beuno> re: 2, screenshot?
<EdwinGrubbs> beuno: well, he said the map was really useful, so putting it towards the bottom would probably also be ok.
<EdwinGrubbs> beuno: see the links in the Related Projects and Latest Questions portlets in this screenshot https://dev.launchpad.net/TeamIndexPage
<beuno> EdwinGrubbs, I agree that it's not the primary thing there
<beuno> the map, tha tis
<beuno> EdwinGrubbs, sounds like the "created by" should be in the same place it is for every other object?
<beuno> top-right?
<beuno> sinzui?
<sinzui> Hi beuno
<beuno> EdwinGrubbs, the polls portlet looks very messy
<sinzui> hmm
<bac> hi sinzui.  i just sent in a MP for the +announcements branch.  would you like to review it?
<sinzui> I was going to hack on poll to ight
<sinzui> bac: thanks
<beuno> EdwinGrubbs, I think the location of those links are fine
<beuno> not sure if theys hould be blue
<sinzui> poll have always been a problem
<beuno> EdwinGrubbs, I'm inclined to say they should be, and maybe drop the triangle as well
<EdwinGrubbs> beuno: so, yes to blue, in the body, and no triangle.
<beuno> EdwinGrubbs, no, the location is fine
<beuno> so minus the "in the body", yes
<beuno> and I think moving the map down is ok, in place of the "Members" portle
<beuno> EdwinGrubbs, related projects portlet is wonky
<beuno> as the link is aligned to the far-right
<beuno> it should be closer to it's content
<beuno> as ion, shouldn't use up 100% width
<sinzui> EdwinGrubbs: The polls portlet is doing three things. Current and "(+) Register a new poll" are legitimate. Recent polls needs to be a link to (i) Show recent polls. I do not think we should be showing polls that are not active yet to non-owners. We only show pending annoucements to owner, the same rule should apply
<sinzui> EdwinGrubbs: why is your pool portlet with square corners?
<sinzui> EdwinGrubbs: The lines that divide content are not in 3.0 style. The fact that it has more than one heading indicates it does too much
<EdwinGrubbs> sinzui: the square corners are purely accidental. What is the css class for 3.0 style content dividers?
<sinzui> EdwinGrubbs: we do not support dividers in 3,0
<sinzui> A portlet uses class="portlet"
<sinzui> EdwinGrubbs: It get 1 <h2>
<EdwinGrubbs> 	ok
<sinzui> EdwinGrubbs: The poll portlet does not justify dividers or two heads
 * beuno feels 3.0 in the air
<sinzui> EdwinGrubbs: The basic structure of other portlets on ths side look like this: https://pastebin.canonical.com/21243/
<sinzui> EdwinGrubbs: The challenge then is to settle what information goes into the Poll item. Just the heading? I think the poll close time is important
<sinzui> EdwinGrubbs: when you want to create a list of links at the bottom of content such as in a portlet, use <ul class="horizontal"> To be consistent
<bac> sinzui: can you paste the URL for the page template assignments, please?
<sinzui> bac: https://dev.launchpad.net/UI/ThreeDotOPages
<sinzui> bac: I have approval to land all the form pages for distromirrors and packages You only need to do the
<sinzui> main pages
<bac> sinzui: ok
<thumper> hi ho, hi ho, it's off to work I go
<bac> sinzui: so here: https://edge.launchpad.net/ubuntu/+cdmirrors you are saying i need to do 'cd mirrors' and 'archive mirrors' but you've already done 'register mirror'?
<sinzui> Correct
<bac> sinzui: and what is the "package" portion of that task?
<sinzui> Wow. I don' think there is anything to do for mirror except incorporate the menu and add the missing RSS feed
<thumper> beuno: did you read my rambling email about the branch page?
<sinzui> bac: You should coordinate with soyuz bigjoolshas already proposed a DSP. Only the SP needs design I think
<bac> sinzui: ok
<sinzui> bac: I might give you something harder like Polls
<beuno> thumper, I did. I've been trying all day to sit down and make changes to the mockup. Have failed.
<bac> ok
<sinzui> Or the completely unintelligible +releated-software
<thumper> beuno: heh
<rockstar> thumper, is jml still on holiday?
<thumper> rockstar: yep
<thumper> rockstar: just you and me baby
<rockstar> thumper, so it's just us again today?
<thumper> rockstar: call?
 * rockstar is not thumper's baby
<rockstar> Just FYI
<rockstar> thumper, sure
<thumper> OMG, edge has been updated
<thumper> damn
<thumper> now I *have* to fix the bug about the branch context
<rockstar> thumper, the internets, they fell over.
<thumper> sinzui: ping
<thumper> sinzui: where has the query count gone?
<sinzui> Hi thumper
<thumper> https://code.edge.launchpad.net/~beuno
<thumper> sinzui: it used to be easy to find with firebug
<thumper> now, not so much
<sinzui> thumper: The whole meta data comment is missing !
<thumper> yeah
<thumper> can we have it back?
<thekorn> what is the best way to run one doctest, let's say ./lib/canonical/launchpad/doc/displaying-paragraphs-of-text.txt
<rockstar> thumper, https://edge.launchpad.net/blogsharp
<sinzui> thumper: We need to make a change to base-layout.pt to print for beta as well as devmod
<sinzui> thumper: <tal:template tal:condition="not:  is_lpnet">
<sinzui> will fix the issue
<thumper> we don't do it for prod?
<sinzui> or...lets always print it
<thumper> sinzui: yes please
<thumper> sinzui: always
<sinzui> I do not see any reason to not print this info
<thumper> me neither
<sinzui> Do you agree this is a regression?
<thumper> oh, yes
<sinzui> I will prepare a branch for this in a few hours. I wan a test to show it is there.
<thumper> flacoste: ping
<wgrant> Why are lots of links on the project indexÂ view black?
<wgrant> Aren't LP links meant to be blue or green?
<thumper> wgrant: link?
<wgrant> thumper: https://edge.launchpad.net/launchpad
<wgrant> Note the 'Uses Launchpad for' section.
<wgrant> Each of those is a link.
<wgrant> This is unobvious.
<thumper> wgrant: looks like a bug to me
<wgrant> thumper: But a deliberate bug.
<wgrant> Like those 'See all blahblah' links that appear in the top right of sections in the body.
<wgrant> That look like non-links with expanders.
<rockstar> wgrant, well, it could be that we just had a CSS oversight.
#launchpad-dev 2009-08-18
<wgrant> cprov: Is it considered a bug that the component listed for a build sometimes lies?
<wgrant> It can change after the build completes, if the package is promoted/demoted.
<wgrant> That can be a bit confusing, as the only way to work out where it really built is checking the override-sources-list line in the build log.
<spm> *** FYI. restarting codehosting for a Cherry Pick ***
 * wgrant beats the AJAX milestone picker with a how-did-you-get-around-the-security-policy bat.
<cprov> wgrant: sort of, it changes according to subsequent overrides.
<wgrant> cprov: Right.
<cprov> wgrant: ideally we would store the component at the time the source was dispatched, on Build table
<wgrant> cprov: That's what I thought. But I guess it's rare enough that it's not worth it.
<cprov> wgrant: I suspect it would be useful for spotting component mismatching.
<wgrant> But it might be a bit stranger when package sets come into it.
<cprov> wgrant: yeah, good point ... we need to study some real use-cases.
<wgrant> Where would I add a test for c.l.w.tales.ObjectFormatterAPI.api_url? c.l.w.tests.test_tales doesn't seem right.
<deryck> wgrant, ping
<wgrant> deryck: Hi.
<deryck> wgrant, hi.  So I see you're working on bug 415166.  Thanks!
<mup> Bug #415166: Launchpad says I don't exist when I subscribe to a bug <Launchpad Bugs:In Progress by wgrant> <https://launchpad.net/bugs/415166>
<deryck> wgrant, did you talk over your proposed fix with anyone?
<wgrant> deryck: No, but it is less trivial than I thought, so I will.
<deryck> wgrant, yeah, I thought it there might be more than that at first appears.
<deryck> wgrant, what were you thinking?
<wgrant> deryck: the obvious thing to do was pass rootsite='api' in ObjectFormatterAPI.api_url.
<wgrant> But that gives the API site, not the API bit of the main site.
<deryck> wgrant, right.  You get an https://api.launchpad.net... absolute URL, right?
<wgrant> deryck: Right.
<wgrant> I'm currently poking around to work out how to get an https://launchpad.net/api/beta/...
<deryck> wgrant, but all the JS code assumes "me" is a relative URL, right? i.e. "/~me"
<wgrant> That seems like it will be very difficult, though...
<wgrant> deryck: Hmmmm. I suppose so.
<deryck> wgrant, there are a lot of places in the js that make that assumption.  That LP.client.links['me'] is a relative URL, that the links in HTML scraped by JS are relative, etc.
<deryck> wgrant, so I don't think there's a single spot to fix this and have it work.
<wgrant> deryck: But ObjectFormatterAPI.api_url did work before. It just got broken by the canonical_url default chnage.
<wgrant> Actually, that change should have been on edge before yesterday. So maybe it isn't that.
<deryck> wgrant, right.  Let me say it another way.  You can fix "me" to be right and I suspect subscribing may still be broken in other ways.  The current bug is a symptom, not the problem.
<beuno> wgrant, I got to give it to you, we open up Launchpad, and you've started fixing bugs
<wgrant> beuno: You didn't think I would?
 * deryck is quite happy wgrant is fixing bugs!
<wgrant> Although I filed a lot this morning, too :(
<deryck> good bug reports are never a problem, no matter the number.
<wgrant> deryck: Assuming that api_url gets fixed, subscribing should work. What is broken about it, besides being fragile?
<beuno> wg	most people don't  ;)
<beuno> wgrant,  (tab fail)
<wgrant> beuno: True.
<wgrant> I imagine that will change over time.
<deryck> wgrant, first, if "me" isn't relative the Subscriber js object won't initialize correctly, and second, unsubscribing won't work because the links in HTML won't be relative either.
<deryck> wgrant, allow the second point may just be DOM update fail.  the unsubscribe API call may not depend on the HTML href.  Can't recall right now.
 * deryck is up late
<wgrant> deryck: You are probably right. This is indeed looking more difficult.
<wgrant> I forgot about team unsubscription.
<deryck> it's a tangled web.  inline subscribing is actually very complex.
<deryck> wgrant, I'm not trying to discourage you though.  Please keep at it! :)
<wgrant> Should I leave it to you, then?
<wgrant> OK.
<deryck> wgrant, just didn't want you to be disappointed if you fixed "me" and the rest was still borked.
<wgrant> Ah.
<BjornT> wgrant, deryck: wouldn't fixing fmt:api_url to always return a relative url fix the problem?
<deryck> wgrant, and naturally if you work out any of the rest, or see hints of whats going on in light of what you know now, you'll be better able to file bugs on the rest. :)
<wgrant> BjornT: I think so.
<wgrant> BjornT: I'm testing team unsubscription now.
<deryck> BjornT, I'm not sure.
<deryck> BjornT, I thought we relied on user links in the DOM being relative, and so the API call may succeed, but if fmt:link was used, and it isn't relative, it may look like a fail in the UI.
<wgrant> deryck: Team unsubscription doesn't use the fmt:link URLs.
<wgrant> I'm not sure how it gets the other ones, though...
<deryck> wgrant, what do you mean by "other ones"?
<wgrant> deryck: I can see it making webservice requests with a person of https://bugs.launchpad.dev/~team
<wgrant> deryck: But fmt:link should now give https://launchpad.dev/~team
<deryck> wgrant, I think everything other than "me" is inferred from DOM.  or the subscriber_ids object.
<deryck> wgrant, BjornT -- ok, so maybe I've just added confusion. sorry. :)  And now I must sleep if I'm to be worth anything the coming morning. :)
 * wgrant digs into the JS.
<wgrant> Night deryck.
<wgrant> Fixing the me-link was as easy as I initially suspected after all.
<deryck> good deal then
<wgrant> (just needed rootsite=None, not rootsite='api')
<deryck> ok, night
<BjornT> wgrant: can i see the patch? i think there might be another solution
<wgrant> BjornT: bzr diff is being a little slow, but I just replaced c.l.w.tales.ObjectFormatterAPI.api_url's self.url() call with self.url(rootsite=None)
<wgrant> As various subclassess now specify rootsite='mainsite' as the default.
<wgrant> This reverts to the previous behaviour.
<BjornT> wgrant: ok, that's a sane solutoin. but i have a question for you. why not change api_url() to always return a relative path?
<wgrant> BjornT: That's what it does.
<wgrant> Although maybe that's just by accident -- I haven't dug all the way down the call stack.
<BjornT> wgrant: not really. canonical_url() can't always return a relative url. note the parameter name: 'path_only_if_possible'
<BjornT> wgrant: note that i don't know the answer to this question, and i don't expect you to either :) but it's worth thinking about.
<BjornT> wgrant: in short, i think your patch is good, since it reverts to the old behaviour. i would go with your patch, and raise the issue i mentioned on the list.
<BjornT> wgrant: btw, did you manage to write a test for this?
<wgrant> BjornT: Sorry, the switch got angry and decided my packets were unworthy of retransmission...
<wgrant> I haven't written a test, no.
<wgrant> I'm about to find the best place to put it.
<wgrant> Is there some repository of class-specific TALES tests somewhere?
<wgrant> Ahh.
<wgrant> c/l/doc/tales.txt
<wgrant> I didn't expect there to be anything there, as the others are in c/l/w/tests/test_tales.py
<BjornT> wgrant: unfortunetaly, i think that tales.txt is the right place for now.  it seems like api_url() is untested :(
<wgrant> BjornT: It is.
<wgrant> Not for much longer, hopefully.
<wgrant> BjornT: Should I just add api_url tests for the three problematic classes, next to the tests that show fmt:link always goes to the mainsite?
<wgrant> Or should I add a new section?
<BjornT> wgrant: i think there should at least be a section for fmt:api_url
<BjornT> wgrant: do you know how to go about making the test fail without your fix?
<wgrant> BjornT: Um, what? You mean running the test?
<BjornT> wgrant: nope. i meant writing the test, so that the pre-conditions are the same as in the bug report
<thumper> BjornT: what time is it for you right now?
<wgrant> Oh, right.
<wgrant> thumper: I was wondering that...
<wgrant> Isn't it like 06:30 over there?
<BjornT> thumper: 6.30 am. woke up a bit earlier than usual today
<wgrant> BjornT: I think I can fairly safely just check that api_url returns something relative, although I suppose that isn't testing exactly what we want.
<thumper> wgrant: what you probably want to test is that the fmt:api_url always returns api.launchpad.net as the base
<wgrant> thumper: No, that's exactly what we don't want.
<thumper> so perhaps something like:
<thumper> no?
<thumper> what is the problem then?
<BjornT> wgrant: i think such a check is ok. i do suspect that you need to do some setup to make api_url return a relative url
<thumper> I must have misunderstood
<wgrant> thumper: api_url is actually a path-only absolute URL.
<wgrant> thumper: Nothing to do with the API, except that it's used by some flaky JS.
<thumper> wgrant: and what is it doing right now?
<wgrant> thumper: Returning an absolute URL to the main site, since fmt:url for person/team/pillar was changed to do that by default.
<thumper> wgrant: why would it be wrong to check that the urls are always api.launchpad.net?
<wgrant> thumper: Because they should never have a domain, and api.launchpad.net is particularly we don't want -- api.launchpad.net isn't usable from the webapp.
<BjornT> wgrant, thumper: to be more exact, it's returning the url to the mainsite, unless calling it from the mainsite
<wgrant> BjornT: Indeed.
<thumper> BjornT: ok
<thumper> wgrant: I'd make sure then that you test with the main pillars
<thumper> wgrant: created by the factory, and test the explicit url with test_tales
<thumper> wgrant: person, product, project, distribution
<wgrant> thumper: Thanks.
<wgrant> But first... lunch.
<wgrant> Some of these factory tests don't seem to be much better than the sample data ones.
<wgrant> I'd even say they're worse.
<wgrant> Some depend on the order in which objects were created.
<wgrant> So I throw in an innocent makeProduct and makePerson, and some of the subsequent tests start complaining that the numbers in the names are different.
<thumper> wgrant: haha
<thumper> wgrant: and here comes the magic of the factory
<thumper> wgrant: factory.makePerson(name="eric")
<thumper> wgrant: always provide what you want to test to the factory
<wgrant> thumper: Right. But I'm going to have to fix other bits of the test.
<wgrant> So it's a bug that the other tests test the name, but don't provide it?
<thumper> wgrant: so if you are checking the url, make sure you don't have unspecified parts
<thumper> wgrant: yes, that is very wrong
<wgrant> But now I have to come up with more names ;'(
<thumper> wgrant: ask and I will provide
<thumper> wgrant: foo, bar, baz, fubar, widget, frobrisher
<thumper> those are what I use
<thumper> except for the last one
<thumper> I just made that up
<wgrant> Haha.
<thumper> I use eric a lot for my random person
<thumper> because there is no eric in the sample data, and I like Eric the Viking
<wgrant> I've seen a few of him.
<thumper> probably me
<ajmitch> eric, john, graham, michael, terry
<ajmitch> I'm sure you could think of a few more
<thumper> wgrant: for multiple people, I also use abe, bob, charles, dave
<thumper> xray, yankee, zulu for teams
<spm> thumper: not "Eric the 'alf a Viking"?
<thumper> spm: :)
<rockstar> I use random naming schemes, depending on what's on my mind at the time.
<thumper> rockstar: there is a 3.0 branch for some code-import pages if you are up for it
<rockstar> thumper, I'll look at it in the morning.  Trying not to break my stride right now.
<rockstar> Also, my media server's PSU just died, so I don't even get music anymore...  :/
<wgrant> How does the JS build system work?
<thumper> what do you mean?
<wgrant> Do I make changes in lib/canonical/launchpad/javascript, and 'make run' will propogate those changes to lib/canonical/launchpad/icing/build?
<wgrant> Oh.
<wgrant> They're symlinks.
<wgrant> That's easy, then.
<sinzui> wgrant: I am tired but it think the answer to your question is that we have a script in utilities that scans the template we list the scripts in. The utility builds he compressed js.
<wgrant> sinzui: But that's not relevant for development purposes?
<sinzui> No, but it is relevant to YUI.Test. I recall have to run make build a few times.
<wgrant> Ah.
<wgrant> Thanks.
<sinzui> I think the issues related to the html page that acts as a harness. It wants the built libs  plus the lib under test.
<thumper> sinzui: hi, got a minute
<thumper> for a question?
<thumper> sinzui: what's the status of the new breadcrumbs?
<thumper> sinzui: I sent out an email earlier
<sinzui> I may not have a comprehensible answer
<wgrant> To fix unsubscribing of teams, LP.client.normalize_uri needs to be convinced to prepend the root when operating on an absolute URL, which it currently explicitly doesn't do. Does anybody know why, before I go hunting?
<sinzui> thumper salgado proposed a generic mechanism that will DTR thing on most cases to flacoate.  I believe there are exceptions and there will be a way to change the bread crumb
<thumper> sinzui: yeah, I figured we'd need to annotate the breadcrumbs for branches
<thumper> sinzui: which was the main point of my email, "what do we show"
<thumper> sinzui: here's another idea
<sinzui> thumper I wont know more until salgado wakes and I attain some form of caffeine induces consciousness.
<thumper> sinzui: rename code -> branches for the "tab", and add a "code" tab for projects that goes to loggerhead
<sinzui> +1
<thumper> I'll copy that into an email for beuno
<sinzui> I recall beuno_ wanted to do that, I wonder if that was shelved to 4.0 as being too invasive for 8 weeks of development
<thumper> sinzui: lets see
<wgrant> BjornT: Is it a sufficiently civilised time to request a review from you?
<wgrant> I figure I'll get this fairly clean branch out of the way, rather than landing one polluted with JS changes as well.
<rockstar> Ugh.  Why do we even have a test like notfound-traversals ?
<sinzui> rockstar: I deleted a few today
<rockstar> sinzui, it just fails with something that looks entirely unrelated.
<rockstar> It's impossible to debug, it's a dumping ground for tests.
<sinzui> rockstar: why do we test nofound + do pagetest 404 + view check_permissions? I think some drugs were involved
 * sinzui only writes view check_permissions tests and deletes all others.
<rockstar> If drugs are a requirement, I suggest that they be administered as part of rf-setup.
<sinzui> rockstar: I think notfound was originally for URL that we wanted to retire. It is now an opportunity to not write a good test
<rockstar> sinzui, yes, I would agree.  I'm willing to bet most of the code stuff in notfound-traversals is tested elsewhere in a better manner.
<stub> notfound-traversals was a reaction to poor test coverage. A quick way to ensure the pages at least rendered, at a minimum.
<stub> (or generated the correct error code in the first round, hence the name)
<stub> I agree it should wither and die
<rockstar> It'll probably shave eleventy billion minutes off the total time to run the test suite as well.
<rockstar> Dangit.  Looks like I got a little overzealous while deleting templates.  One test failure left though.
<adeuring> good morning
<noodles775> hi adeuring :)
<adeuring> hi noodles775!
<lantash> danilos: Do you think it's time to make a merge proposal for https://code.edge.launchpad.net/~lantash/launchpad/bug-392154 ? I guess I'm supposed to write a merge proposal as suggested at https://dev.launchpad.net/DetailedCoverLetterTemplate and send a contributor agreement to you or kiko. What about running the whole test suite?
<danilos> lantash: hi, let me take a glance at it
<danilos> lantash: about the full test suite, it's generally preferred to do it ('make check'), but if it's problematic for you, running "bin/test -vvt lp.translations" (takes <15 minutes on my machine) should be enough
<lantash> danilos: Thanks. I'll do that. Don't hesitate to tell me if you dislike anything about the newly introduced code or if there's anything missing.
<danilos> lantash: looking at the revision log, I'd say you are mostly ready to submit it for review
<danilos> lantash: don't worry, I am not shy about it, though it's very much appreciated you spent your time to help us improve Launchpad :)
<henninge> wgrant: Hi. Anybody looking at your MP already?
<wgrant> henninge: No. I discussed the patch with BjornT and deryck earlier, but if it seems sane to you then go ahead.
<BjornT> henninge: i'm looking at it now
<wgrant> Thanks BjornT.
<henninge> BjornT: I already have, was about to review
<henninge> BjornT: so you can save your time if you want ... ;-)
<BjornT> henninge: were you about to start reviewing, or write up the review?
<henninge> the latter
<henninge> BjornT: ^
<BjornT> henninge: ok, go ahead then
<lantash> danilos: For some reason, my bin/ directory is gone. Looks like "make clean" removed it, which seems to have been invoked by "make check" (which failed by the way: "Error: Couldn't find a distribution for 'zc.buildout==1.4.0dev-gary-r102684'."). Can you tell me how to regenerate it?
<danilos> lantash: once you merged with trunk, some dependencies (listed in versions.cfg) have changed; it should be enough for you to cd into download-cache and do a 'bzr up' there
<wgrant> And then 'make' again.
<danilos> lantash: and do 'make' again, as wgrant said (if it's not clear he was continuing on what I said :)
<lantash> danilos,wgrant: It works fine now. Thanks! I'd run "make lint" too, but unfortunately, it fails on my 9.04 machine: "pkg_resources.DistributionNotFound: pylint==0.18.0"
<wgrant> lantash: Odd. download-cache is up to date?
<wgrant> And the branch is up to date with devel?
<lantash> wgrant: If you mean running "bzr up" in download-cache and "bzr merge lp:launchpad/devel", then yes. I ran both commands just seconds ago. Just FYI, this isn't a new issue, I've never been able to successfully run "make lint" since I branched lp.
<wgrant> lantash: Odd. It has always worked fine for me on Jaunty and Karmic.
<wgrant> lantash: Do you have the pylint package installed?
<danilos> wgrant, lantash: I don't see pylint in versions.cfg, so I'd expect that you'd need to install it yourself
<lantash> wgrant: yeah, I'll check there's a version I installed by hand that conflicts with the one in the repositories.
<danilos> of course, launchpad-developer-dependencies should do it for you, but there might be a bug
<wgrant> maxb: Do you want to find a sponsor to get the necessary stuff from ~maxb/launchpad into ~launchpad/ppa to get things working on Karmic, or shall I?
<mrevell> Hello my friends :)
<hijacker_> hi mrevell
<mrevell> hey there hijacker_ :)
 * mrevell cuts down on the smilies
<lantash> wgrant: did some investigation. ;-)
<lantash> pylint 0.18 (which is required by lp) is in /usr/lib/python.2.6/dist-packages
<lantash> pylint 0.15.2 can be found in /usr/lib/python.2.[45]/site-packages as well as pyshared (0.15.2 is in the Jaunty repos).
<henninge> I am trying to submit a remote branch (wgrant's) to ec2test and pqm but ec2test complains like this:
<henninge> To send email, a remotely accessible smtp_server (and smtp_username and smtp_password, if necessary) must be configured in bzr.  See the SMTP server information here: https://wiki.canonical.com/EmailSetup .
<henninge> I know I have done this before so I wonder if something changed about this.
<henninge> for the record: yes, the smtp server is configured ...
<wgrant> henninge: Other people have repushed it, I think.
<wgrant> But I'm no expert on sponsoring...
<danilos> henninge: smtp server is probably configured for your LP repo, and not for remote others' repos; you can try moving smtp settings to your global bzr config
<henninge> Ok, now it is working. I moved the smtp configuration from location.conf to bazaar.conf
<danilos> henninge: that's it :)
<henninge> danilos: ;-)
<henninge> wgrant: ok, branch is in ec2test and will find it's way into the tree. Thanks again.
<wgrant> henninge: Thanks!
<danilos> lantash: note that LP uses python 2.4, so it'll probably try to use pylint 0.15.2, and that should be fine; it's probably 0.18 installation that causing the problems
<maxb> wgrant: Hi, I was just thinking about that. The proper way would be to cherrypick my changes into individual small branches and submit those one by one, right?
<maxb> Or, is submitting a branch with a one-line change considered a bit of a waste of time, and should I try to batch unrelated small changes?
<wgrant> maxb: I mean the PPA packages.
<maxb> Oh, right
<wgrant> Just for 2.4 now.
<wgrant> Since that works, and is better than nothing.
<maxb> Well, works for you :-)
<wgrant> Well, yes. Rather odd.
<maxb> I guess I should try to talk to flacoste about that, based on the authorship of most of the packages in ~launchpad/ppa
<wgrant> Probably.
<lantash> danilos: Removing /usr/local/pylint as well as the 0.18 installation solved the problem. Thanks! Fortunately, the changed files are lint clean.
<danilos> lantash: cool, let me know once MP (merge proposal) is up, so we can move to #launchpad-reviews to discuss it :)
<maxb> I'm really annoyed with myself, I carefully started using launchpad~maxb in .deb versions in my ppa with the intent that launchpad versions would be higher when official. But then I did some uploads whilst too sleepy, and made some of them maxb~launchpad instead
<danilos> bigjools: is this something you can help maxb with? ^
<bigjools> not much I can do about that
<maxb> No, the version numbering is entirely my screwup
<bigjools> you could start a new PPA
<bigjools> thumper!  working late?
<thumper> bigjools: hey
<thumper> bigjools: yeah, just a bit
<maxb> Well, yeah, but the numbers are in the wild now, the PPA's advertised on dev.lp.net and I know people are using it
<maxb> Anyway
<maxb> I would like to help populate the ~launchpad ppa for karmic. What is the preferred form for submitted packages for sponsored upload / copy into there?
<bigjools> good question
<bigjools> check with flacoste when he's around later, but if necesarry we can add you as a named uploader
<maxb> ok, if I don't catch flacoste later today, I'll ask launchpad-dev@
<maxb> Separate topic - I'd like to start submitting code changes to support python2.5 - I thought I'd start small, with this one: http://bazaar.launchpad.net/~maxb/launchpad/python2.5/revision/8974
<thumper> if I have a security wrapped product
<thumper> and adapt it to something else
<maxb> Are branches with a one-line change wanted, or is it better to try to collect a few one-liners into a single branch?
<thumper> does the something else get security wrapped?
 * thumper thinks not
<thumper> maxb: one liners are fine
<thumper> maxb: several one liners together are fine
<thumper> maxb: several 50 line fixes should be broken up
<thumper> maxb: keep changes easily reviewable
<thumper> maxb: that's your axiom
<bigjools> thumper: I think it does
<bigjools> once wrapped, always wrapped
<thumper> bigjools: adaptation doesn't go through a secured utility
<bigjools> have you tried it?
<thumper> by accident once
<thumper> bigjools: but I have a test I'm writing
<bigjools> I remember seeing some code somewhere that used an adapter so that we got proxied objects
<thumper> bigjools: I'll let you know :)
<bigjools> thumper: I'll honestly be very surprised if an adapter turns a proxied object into a non-proxied one
<thumper> bigjools: well, the adapter is a class that takes the wrapped object as a parameter
<wgrant> Don't trusted adapters get proxied (but get unproxied access to the wrapped object)?
<thumper> bigjools: so it won't wrap the new object
<wgrant> But IIRC non-trusted adapters don't get proxied, but rely on the proxy around the wrapped object.
<thumper> wgrant: where are the docs about trusted adapters?
<maxb> uhoh, ajax bug subscribe broken on edge for everyone or just me?
<thumper> maxb: yep, broken
<wgrant> maxb: I have a branch landing for that ATM.
<wgrant> thumper: No idea. I just remember this from when I played with some Zope 3 code a couple of years back.
 * wgrant Googles.
<wgrant> thumper: http://docs.zope.org/zope3/ZCML/http_co__sl__sl_namespaces.zope.org_sl_zope/adapter/index.html, the trusted attribute seems relevant.
<thumper> ta
<thumper> wgrant: fantastic, thanks for that
 * wgrant knows enough Zope 3 to survive.
 * bigjools hoped to never have to know that much Zope3
 * wgrant doesn't mind it.
<mpt> Oh hooray, the global search field is going back down into the page footer
<lifeless> ah, so people can't use it ?
<mpt> eh?
<lifeless> will people see it at all down at the bottom?
<mpt> Well unless you're at the front page, the main reason to use the global search is because there's nothing on the current page relevant to where you actually want to be
<mpt> My hypothesis (and it's only a hypothesis) is that you're more likely to come to that conclusion once you've scrolled through a page than when you're at the top
<lifeless> mpt: my feeling is that search at the top is great, but it should always be contextual; if you want global search hit the home page
<lifeless> or something like that
<lifeless> it would be interesting to make sure we can track the result of the change being made
<mpt> There are quite a lot of pages with context-sensitive searches, e.g. project Bugs pages, distribution pages
<mpt> If all pages had a single search field it would be hard to tell when someone was wanting context-sensitive results (e.g. show me only bug reports about only this project) and when they were wanting site-wide search results
<deryck> Morning.
<deryck> wgrant, thanks for your work on tracking down (and fixing!) those inline subscribing bugs.
<lifeless> mpt: thats true, which is why I suggest being always context sensitive and letting users request site wide
<wgrant> deryck: The second one wasn't at all as hard as I suspected, fortunately.
<deryck> wgrant, yeah, I think once you understand the general subscribing process in js, all of these should be fairly easy to fix.
 * deryck needs to look closer at each bug though
<wgrant> deryck: It took a while to work out how it all worked.
<wgrant> There's a bit of JS there...
<deryck> indeed there is.
<mrevell> jtv: http://blog.launchpad.net/translations/screencast-importing-translation-templates-from-a-bazaar-branch
<jtv> mrevell: listening to your voice now...
<mrevell> jtv: That's nice to know :)
<jtv> mrevell: "you might notice that this is a copy of Barry Warsaw's I Have a Colon Full of Cookie project"..?
<jtv> mrevell: do you expect many people to pick up on that?  :)
<mrevell> jtv: Only in that there is the rather odd phrase "I have a colon full of cookie" in the pot. I think this was the tenth take after several Audacity crashes :)
<jtv> mrevell: and how many retakes from starting to laugh when you said the phrase?
<mrevell> jtv: Heh, I was closer to tears after all the crashes
<jtv> "oh good"
<mrevell> jtv: there's a factual error in that I say imports happen once a day but I'll fix that when I re-record it for the new UI
<jtv> mrevell: you say "a few minutes instead of a day or two," though that's about the approval process rather than the import process.
<mrevell> jtv: Yeah, which I clarify later on
<jtv> mrevell: where "clarify" is defined as "distort with lies and misinformation?"  :-P
<mrevell> jtv: If the voiceover is actually misleading, I'll re-record. Do you want to give me a list of "bugs"?
<jtv> mrevell: I just hit the point where you say "daily."  I'll be sure to note anything else, but no other mistakes have caught my ear so far.
<jtv> mrevell: these imports get triggered as soon as you push your changes.
<mrevell> jtv: I'll re-record.
<mrevell> jtv: I think it's an important fact to get right :)
<jtv> mrevell: well it's not actually harmful since everything else including your demo very clearly says "a few minutes."  So one could interpret the "daily" as "continually."
<dpm> mrevell: I've just watched the screencast, and I found it excellent! Just a comment/suggestion: in the last few seconds, when you are typing the translation in the textbox, it might be worth clicking on the radio button or on the arrow button of the original string to show people that they can be easily copied to the translation textbox with a mouse click.
<mrevell> jtv: The gods of audio recording seem to be smiling on me today, so it won't be too much effort to re-record. I like talking to myself anyway
<jtv> mrevell: did danilo ask you about these screencasts btw?  Joey wanted something like this as well.
<wgrant> Somebody want to help in #launchpad before things get too off course?
<wgrant> mrevell: Note that nat/canonical/..
<mrevell> dpm: Thanks for that suggestion! I have to confess I didn't even consider that. I'll mention that in the voiceover as that's easy to re-record and I think that's all we need for an extra value tip like that.
<mrevell> wgrant: Yeah, I'm still used to be able to recognise everyone's name :)
<mrevell> jtv: yeah, danilo pung me about this yesterday
<mrevell> jtv: I've fixed the import video. Now I'm going to record the export video.
<jtv> mrevell: looking forward to that, for obvious reasons.  :)  I really liked getting the information in this format.
<mrevell> jtv: Is there any way to cheat/force the export? I guess I can wait until tomorrow to record the part where I go and look for the export in my branch, but joey might find this useful, as you said.
<jtv> mrevell: you're not the first to ask...  May be worth a new feature, though obviously we're not going to work on it very soon.
<jtv> otoh for now the script performs so well that it looks like we might run it much more frequently.
<mrevell> jtv: Ah ok. So, there's no special "I'll buy you a pint jtv" button :)
<mrevell> jtv: When does the export occur?
<jtv> mrevell: buying me a pint is fine, but getting an extra cron job approved & executed might not get it done much faster than just sitting and waiting.
 * jtv looks up the times
<mrevell> :)
<jtv> mrevell: between 03:00 and 04:00 UTC
<jtv> or BST, if that's what the logs are in.
<mrevell> jtv: Cool, thanks
<wgrant> gmb: If I want to fix bug #415165, do I have to change all sites that set it to use the new method? Or can I just set the field readonly and export a mutator, to only protect the webservice side?
 * gmb looks at the bug
<gmb> Ah, right.
<gmb> wgrant: The problem specifically effects anything that uses the webservice, so exporting the mutator should be sufficient. You can then file a follow-up bug to make everything else use the new method, but that's less urgent.
<wgrant> gmb: Thanks, I was just wondering if I would be committing Evil by not changing the rest.
<gmb> wgrant: Nah - what's there already has worked up until this point.
<gmb> (And as I said, what's there already for non-webservice stuff isn't all that broken)
<henninge> jtv, danilo-food: wanne take a look at my TranslatableMessage draft?
<henninge> jtv: https://pastebin.canonical.com/21250/
<jtv> henninge: looking...
<henninge> jtv: actually I am thinking of even more high-level methods.
<henninge> jtv: like "getAllTranslations"
<jtv> henninge: a small note... names like is_empty and is_imported don't really mesh with the choice of Translat*able*Message.
<henninge> ;-)
<barry> sinzui said: No.one menu must be bound to the oject, the other to the view, so you must pass each so that when we use nearest(INavigationMenu) we get the right menu
<henninge> jtv: well they are really "(Re)TranslatableMessage)
<jtv> henninge: I think you've made a good start with these low-level things; this should not become a 2-year project after all.  :-)
<henninge> jtv: meaning
<henninge> ?
<jtv> henninge: about the names, I mean that is_empty etc. should be something like current_translation_is_empty etc. to reflect that it's the translation, not the POTMsgSet, that is empty (or whatever).
<henninge> jtv: ok, no problem
<jtv> henninge: about the other thing, I mean don't worry too much about pulling in more functionality; you'll risk making more changes than needed and complicating things.
<barry> sinzui: nearest() seems like a rather magical (and error prone) way to find the menu.  why is it not explicit?
<sinzui> barry: You are using the zope, This is how all menus work
<henninge> jtv: You mean, the rest can be done in the view?
<jtv> henninge: I'm not making any predictions, just saying be conservative in what you move in here because it's going to pile up anyway.  :)
<barry> sinzui: my point is, i guess, that we should do better
<sinzui> barry: if it was very explicit, people would be making menus everywhere and the pages would be a mess. NavigateMenus were design to work with two scenario, items about the object and items about the objects content
<henninge> jtv: I see.
<sinzui> barry: I loath to change the way something has worked for 18 months
<sinzui> barry: remember that lots of pages are using them.
<barry> sinzui: then we should be building a better mechanism that new pages would use.  but i'll drop this for now.
<sinzui> I think the way I outlined it ensures there one link definition, that we allowed two menus per page. The only oddness is the marker interface
<allenap> sinzui: Hi, I have a question when you have a moment. I'm converting a page from onecolumn to main_only, and collapsibles are now not working. I notice that the code that sorts them out is in the page-javascript macro, but I don't think I want to be using that (it seems to be to support main-template). Any ideas how I should approach this?
<jtv> henninge: overall, what you have here looks to me like the kind of interface we'd want to have.
<henninge> jtv: good to hear, thank you
<sinzui> allenap: head-epilogue-slot is where I have placed javascript
<bigjools> sinzui: I think we also need .side h2 {font-weight: bold;} I think I might have said that before.
<sinzui> yes,
<sinzui> bigjools: I leave beautification to beuno
<allenap> sinzui: Okay. Previously several calls were made on every page (activate_collapsibles(), and a few others). Is the policy now to only call those that each page needs?
<gary_poster> mthaddon: when you get a chance would like to investigate the problem landing sourcecode branches on pqm that intellectronica and I wrote about.
<sinzui> allenap: I do not know.
<allenap> sinzui: Do you reckon beuno is the person to talk to?
<sinzui> allenap: I think the problem is that those scripts were never converted to YUI, so we do not know what to do with them
<mthaddon> gary_poster: ok, will be about 30 mins or so
<gary_poster> mthaddon: cool thanks
<sinzui> allenap: if there a problem with the epilogue slot?
<wgrant> Should all schema circular import patches live in c.l.i._schema_circular_imports? It took me ages to find one that doesn't live in there.
<allenap> sinzui: Those calls used to happen in every page, to set up sortables, inline help, collapsibles, etc. None of those things will work unless every template adds a block to the head_epilogue.
<allenap> sinzui: The one I'm interested in - Y.lp.activate_collapsibles() - has been converted to YUI, so maybe I should add it to base-template.pt to ensure it gets run on every page?
<sinzui> allenap: then I think we want to add that to the new template. There is a macro that makes discretional page javascript. We can add them to that or we add a new part the template loads non YUI scripts
<sinzui> allenap: I think we want to update base-layout-macros.pt define-macro="page-javascript" to do this
<sinzui> If you look, you will see it does a setup, loads the main scripts, then does some post setup
<allenap> sinzui: Yeah, that macro is used by main-template.pt, but not by base-layout.pt, and adding it to the head_epilogue slot means that the load-javascript macro ends up being included twice in the page.
<sinzui> allenap: I see Y.lp.activate_collapsibles(); in the define-macro="page-javascript" macro. It should be there now
<allenap> sinzui: Yes. I'll break out the <script> block containing Y.lp.activate_collapsibles() into a separate macro so that I can include it in base-layout.pt.
<sinzui> allenap: no
<bigjools> sinzui: did you look into a way of automatically putting the file size in the sidebar download links?
<sinzui> allenap: look at line 72 of  lp/app/templates/base-layout.pt
<sinzui> allenap: load-javascript is meant to just provide libraries and by special pages like the timeline. I do not think we should be loading it in base-layout. It should call page-javascript, which does the required pre and post setup of those libraries.
<sinzui> allenap: So I think we need to change line 72
<sinzui>      use-macro="context/@@+base-layout-macros/page-javascript" />
<allenap> sinzui: Okay, that seems good.
<sinzui> bigjools: I have not. Salgado looking to a way and used the tooltip because there was room in many of the uses for download files.
<sinzui> bigjools: I think the answer is when there is a table, show the information. When you are making a fast action button, just show the file name
<bigjools> sinzui: it would be nice to put it next to the release date IMO.  release date won't work for me on the DSP page anyway since it's the package upload date that counts
<sinzui> Will it always fit?
<bigjools> what is "it"?
<sinzui> bigjools:I do not think we can. the release date should only appear one in a list of download buttons.
<bigjools> ah interesting
<sinzui> bigjools: "it" was the file size
<gary_poster> leonardr: ping
<leonardr> gary: yo
<bigjools> it should fit, but won't work too well if we don't want to put the release date in every button
<gary_poster> leonardr: ready for call?
<leonardr> yeah
<gary_poster> cool
<allenap> sinzui: Switching load-javascript to page-javascript in base-layout.pt is working nicely. However, initInlineHelp() breaks (because there's no #help-close element) necessitating a change to stop it from throwing an exception. Is inline help entirely going away for 3.0?
<sinzui> hmm
<sinzui> allenap: I think that mean we need to add the missing help info. Is the issue more complex than that.
<allenap> sinzui: No, I don't think so. There's a div#help-pane in main-template which I can just copy into base-layout.
<sinzui> allenap: I intentionally made the lp/app/browser/tests/base-layout.txt test very verbose to ensure that we know exactly what each layout provides. You should update one or all the layout sections to verify that #help-close is present
<allenap> sinzui: Okay, cool. Thanks for you help :)
<beuno> EdwinGrubbs, hi
<EdwinGrubbs> beuno: hello
<beuno> EdwinGrubbs, would you like to have a call to figure out the UI you're working on?
<sinzui> salgado: is Bug 415133 update?
<mup> Bug #415133: Update code-of-conduct pages to UI 3.0 <Launchpad Registry:In Progress by salgado> <https://launchpad.net/bugs/415133>
<henninge> abentley: Hi!
<abentley> henninge: Hi!
<henninge> abentley: Are you knowledgable about the job system?
<abentley> henninge: Yes.
<henninge> abentley: I see a lot of stale "running" jobs.
<henninge> abentley: that is jobs that remain in state "1" forever.
<abentley> henninge: What kind of jobs?
<henninge> abentley: rosettabranchjobs
<henninge> abentley: but I just saw that there are other (old) jobs still in that state, too.
<abentley> So, when a job terminates, the JobRunner should set its status appropriately.
<henninge> abentley: what happens if it crashes?
<salgado> sinzui, there are a few pages left to convert
<sinzui> okay
<abentley> henninge: You mean outside of normal python exception handling?
<henninge> abentley: possibly ;-)
<henninge> abentley: these are all rosettabranchjobs not in state "2" as of last night.
<henninge> https://pastebin.canonical.com/21251/
<james_w> could I get a review of https://code.edge.launchpad.net/~james-w/wadllib/fix-simplejson-unicode/+merge/10180 please?
<henninge> abentley: looking at lines 65 to 70 you see 4 jobs for window-picker-applet but nothing ever happens, meaning nothing gets uploaded.
<intellectronica> james_w: you're best trying in #launchpad-review, where the on call reviewers hang out. but if you can't find a reviewer there i'll be happy to review your fix
<flacoste> gary_poster, adeuring, intellectronica: my fix for submission to sourcecode branches is #4 in PQM right now
<intellectronica> hallelujah
<adeuring> flacoste: thanks!
<james_w> intellectronica: but I'm the only person in that channel!
<gary_poster> flacoste: thank you!  mthaddon did you see that?  no investigation needed, probably
<james_w> ah, -reviews
<mthaddon> gary_poster: sounds good to me :)
<gary_poster> :-)
<abentley> henninge: Well, if it raises an exception, the job will be marked "failed" and an oops will be reported.
<abentley> henninge: At least, that's what's meant to happen.
<abentley> henninge: If the job causes a segfault, the job will be left in 1 state forever.
<bigjools> sinzui: did you involvement portlet thing land?
<bigjools> your*
<henninge> abentley: I guess that is the problem, then.
<henninge> abentley: I guess that is the problem, then.
<sinzui> bigjools: yes!
<bigjools> sinzui: woooo!  can I just copy the runes from the product-index template?
<abentley> henninge: There have been some changes in that area recently, so it might work now.
<henninge> abentley: the last failures were yesterday.
<abentley> henninge: Drat.
<henninge> that i know of.
<abentley> henninge: Have you looked at the job system oopses?
<sinzui> bigjools: <div tal:replace="structure context/@@+get-involved" />
<henninge> abentley: yes, there are none, or at least not matching the job failures
<bigjools> sinzui: in fact I just tried it and it looks a bit wonky, for the DSP page it adds "Register a Blueprint" which doesn't make sense does it?
<bigjools> and it links to +addbranch
<henninge> abentley: that is oopses for rosettauploadjobs
<sinzui> bigjools: \o/ you found a bug
<bigjools> sinzui: "Help translate" also just goes to the translations root site
<sinzui> bigjools: yes it does
<abentley> henninge: The only thing I can think of is trying to reproduce the failure locally.
<abentley> henninge: Or maybe on staging?
<henninge> abentley: are branches copied to staging, too?
<henninge> abentley: it does not happen to all branches, just certain.
<abentley> henninge: Only a few are copied, but you can push them.
<thekorn> intellectronica, hi, right now, I try to fix bug 414992, and I have a question: there is a test in lib/canonical/launchpad/doc/displaying-paragraphs-of-text.txt line 224/225 which indicates that this is expected behaviour,
<mup> Bug #414992: 'bug $ID' markup in descriptions and comments does not respect new lines <Launchpad Bugs:New> <https://launchpad.net/bugs/414992>
<bigjools> sinzui: I guess the text is wrong, +addbranch is sane for packages now
<thekorn> intellectronica, so: is the testcases wrong, or isn't it a bug at all?
<sinzui> bigjools: lp/registry/browser/pillar has an exception for IProject, add one for IDistributionSourcePackage
<bigjools> sinzui: okay
<EdwinGrubbs> beuno: sorry, I didn't see your last comment. sinzui was saying that the problem with the duplicate headings is due to the base templates, so a fix doesn't really belong in my branch. We can have a call if you like, but I think sinzui should be involved, unless there is a different issue.
<intellectronica> thekorn: sounds to me like the behaviour is wrong. i don't understand why you'll want to do that other than in one case - some text can come from email, where it may have been broken down
<intellectronica> thekorn: let me have a look
<beuno> EdwinGrubbs, if you're clear on what you need to do, then it's ok. If you're not 100% sure on design, let me know, and we'll have a call to figure it out
<thekorn> intellectronica, thanks for looking at it
<bigjools> sinzui: doesn't seem to work for DSP, the pillar is IDistribution in that code
<bigjools> sinzui: maybe examine the context instead?
<jtv> mthaddon: I have to go now, but I've written up my request for later: https://pastebin.canonical.com/21261/
<jtv> mthaddon: with apologies for asking you to hold the baby, is that something you can work with while I go and slack off?
<EdwinGrubbs> beuno: sinzui said that whatever changes that need to be done to the heading are up to you, so I couldn't even start working on that in a separate branch.
<beuno> sinzui, do I owe you an answer then?
<sinzui> bigjools: the __init__ needs to set the specs, code, and tranlations, to false if IDistributionPackage. just like IProject
<bigjools> sinzui: it's ok, I have fixed it
<sinzui> beuno: EdwinGrubbsI do not undersand the issue until I have seen it.
<bigjools> sinzui: however, I am wondering why there's no Code link, even though the tab is enabled
<sinzui> bigjools: Does Ubuntu have official_code?
 * sinzui does not think so
<bigjools> might be right, where the heck is it set ....
<sinzui> bigjools: the involvement menu enforces the official status
<mthaddon> jtv: sure - can you email that to losas and I'll have one of my new minions have a crack at it
<sinzui> bigjools: <Change details>?
<bigjools> sinzui: nope :/
 * sinzui looks at model
<bigjools> sinzui: why does "Help translate" go to the translations rootsite?
<sinzui> Wow!
<bigjools> when it doesn't on the existing page
<bigjools> or is that a bug?
<sinzui> bigjools: official_codehosting is a property allways set to false. There is a not about sourcepackage branches you shoudl read
<bigjools> ha
<intellectronica> thekorn: don't know, i think the reason i mentioned above is the only reason i can think of why we'd want to do that. if we wanted a really clever solution we could do the linkification only if the number on the next line is preceded by #, though i think it's worth changing even if we don't do that
<intellectronica> i sort of feel like someone needs to be devil's advocate here
<sinzui> bigjools: You might wan the view to falsify official_codehosting if distribution.full_functionality
<sinzui> bigjools: That is were the link always goes as far as I understand.
<bigjools> ok
<bigjools> in the meantime, abentley, do you guys have plans to fix IDistribution.official_codehosting?
<henninge> abentley: you have lots of "running" jobs, too... https://pastebin.canonical.com/21262/
<intellectronica> BjornT: do you have an opinion on whether it makes sense to linkify 'bug\n123'? we currently do, and i can think of one reason why that would be good to do (text coming from email might be broken up for line length) but it's a bit confusing when entering lines starting with a number
<henninge> abentley: this was the query run on staging: https://pastebin.canonical.com/21260/
<abentley> bigjools: I lack context.
<BjornT> intellectronica: i assume you mean that we don't do this currently?
<bigjools> abentley: it always returns False, and there's a comment from you on 2008-01-22
<intellectronica> BjornT: we currently do linkify across line boundaries. we even have a test demonstrating this
<bigjools> abentley: doesn't seem right any more now we have source package branches?
<BjornT> intellectronica: oh. so in what way is it confusing? can you give an example?
<intellectronica> BjornT: https://launchpad.net/bugs/414992
<mup> Bug #414992: 'bug $ID' markup in descriptions and comments does not respect new lines <Launchpad Bugs:New> <https://launchpad.net/bugs/414992>
<abentley> bigjools: I don't think that's on our radar, but jml is most familiar with sourcepackage branch issues.
<bigjools> abentley: ok, no rush anyway, just wondered.  Ta!
<abentley> bigjools: Is it possible for a distribution's sourcepackage branches to be unofficial?
<bigjools> abentley: I don't think so
<abentley> bigjools: So perhaps we need to force it True.
<bigjools> I'll wait for jml to comment when he's back
* mthaddon changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/ | Staging.lp.net going down for hardware maintenance 15:00 UTC - 15:30 UTC
<abentley> henninge: I'll investigate that, but I've no idea at the moment.
<henninge> abentley: just like me ;-)
<danilos> henninge: we should either turn all of those into properties, or turn them all into methods... I don't see a reason to be inconsistent like this... is_empty would be better if it was the opposite like is_translated, but that's ultimately equivalent to current not None and not current not is_empty
<danilos> henninge: it might make sense to keep expensive operations as methods, and cheap ones as properties, but then everything might turn into methods :)
<bigjools> sinzui: with the portlet changes: http://people.canonical.com/~ed/dsp_mockup_with_linkage2.png
<sinzui> bigjools: What did you do with the help translate link? Should it change for an DSP?
<bigjools> sinzui: yes, it should retain the pillar
<bigjools> I've not fixed that
<bigjools> sinzui: what do you think about the new layout though?
<sinzui> I like it
<sinzui> bigjools: we normally do not want a line (border, rule) between the <h1> and the content.
<sinzui> bigjools: I am not sure what to do in this case
<bigjools> sinzui: me neither
<sinzui> bigjools: We could set the top two portlets to class="top-portlet"
<sinzui> bigjools: Is there any narrative information we can place at the top of main?
 * sinzui thinks not
<bigjools> not relly
<bigjools> the product info is the best narrative
<bigjools> sinzui: so using top-portlet makes it sit right against the title now. noodles775 observed that on a review of something else earlier, it's a global problem
<sinzui> yes, because top-portlet assumes that some real blocks are in it
<noodles775> bigjools, sinzui: I haven't checked, but I've got a feeling it probably only affects top-portlet's where the first content is a table/form.
<bigjools> sinzui: heh, on top of that, the <dt> have lost their styling
<sinzui> :(
<sinzui> bigjools: where does the explanation of what the package does come from when I use apt? is that available here?
<gary_poster> salgado: please let me know what you think of https://pastebin.canonical.com/21264/ when you get a chance, and let me know what you think we ought to do next.
<bigjools> sinzui: that's a different package you're seeing the description for - they're binary remember
<bigjools> this is source
<jtv> danilos, henninge, mthaddon: I'm off!
<mthaddon> jtv: did you email losas@?
<jtv> mthaddon: I did.  Didn't notify you because I figured you'd get the email anyway.  :)
<mthaddon> cool, thxc
<bigjools> sinzui: the class="summary" on the description looks really crap to me as well
<rockstar> abentley, chat?
<abentley> rockstar: sure.
<henninge> danilos, jtv, mthaddon: so am I!
<sinzui> bigjools: yes, since we are not using it as narrative we should not use the class
<danilos> jtv, henninge: cool, enjoy it
<salgado> gary_poster, I like that it seems like a lightweight solution for future changes, but doing that for all existing entries in versions.cfg will be a bit of a PITA, won't it?
<thekorn> intellectronica, ok, thanks. so I guess best is to wait until someone notes a decission about this on the bugreport
<intellectronica> thekorn: yes, i suggest let's put this question in the bug report and try to make a decision quickly. i'd say just do it, but the fact that someone went through the pain of making sure that it works the way it does makes me a bit cautious - maybe there's a really good reason we don't understand
<bigjools> sinzui: instead of narrative, I can put something in that used to be on an old mockup, like "This package has 14 open questions and 139 untriaged bugs"
<sinzui> oh
<sinzui> bigjools: That is nice. Why aren't we showing them as portlets on the page? Is the information not interesting enough? Do you link to those bugs and questions?
<gary_poster> salgado: We only have four ATM (Storm is 1.15).  It will be a bit of a PITA, yeah.  I think it's most important for feedvalidator, since right now we don't have any prospect of improving the situation (getting a real release).  The other three are hopefully on their way to being merged and officially released upstream, so I'd be +1 on letting them through as-is on a grandfather clause. :-)
<gary_poster> So, to be clear, maybe just redo feedvalidator to comply with this.
<bigjools> sinzui: I'm wary of putting too much on the page and slowing it down.  I would be happier to link to the relevant page.
<sinzui> +1
<bigjools> cool
* mthaddon changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/
<salgado> gary_poster, oh, I thought we were doing the comments even for non-custom distributions.  I think that'd be good to kind of force people to update the comment in case they change it to a custom one, but it might be too much effort for not enough benefit
<salgado> (your pastebin clearly says it's only for custom local distributions; I misread it)
<gary_poster> salgado: cool.  if it is a non-custom distribution, then I think that's not Launchpad's responsbility to make those releases anyway (unless we are the upstream, like with lazr.*, but I think documenting that release process needs to be handled within those packages, not within launchpad).
<gary_poster> salgado: so, are you +1 then?  Should I make any changes, or just put it on the wiki and invite comment?
<salgado> gary_poster, big +1 from me. :)
<gary_poster> salgado: :-) k cool thanks
<danilos> kfogel: did we come up with a recommended PQM submit message to credit our contributors when submitting branches for them?
<kfogel> danilos: no, because we're just going to parse the logs (the inner revisions) directly.  Which, coincidentally, is what I'm working on right now :-).
<danilos> kfogel: ok, cool
<kfogel> danilos: (and the result will feed to a wiki page automatically, keeping our contribution logs up-to-date)
<sinzui> barry:  can you take 30 minutes to look at bug 403606. I haven't a clue what is up.
<mup> Bug #403606: ExpatError errors should be handled to not generate the OOPSes <oops> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/403606>
<kiko> sinzui, is it currently possible to subscribe a private team to code reviews? no, right?
<sinzui> kiko: I think it can. We fixed a related bug in June
 * sinzui tries
<bigjools> sinzui: are the same links as the tabs available as global Links somewhere?
<sinzui> bigjools: No :(
<bigjools> bugger
<sinzui> bigjools: I lied, but getting a link can be hard
<bigjools> sinzui: so I shall have to duplicate them in my view then
 * sinzui looks at old revision on involvement to see how it was done
<sinzui> bigjools: I had to use the translations menu to get links. That is not good. I have been putting links in  mixins so that it is easy to share links between menus
 * sinzui reads ancient code for hacks
<sinzui> bigjools: view/menu:facet returns a list of links. you cannot access them by name :(
<bigjools> sinzui: the help_translate link returns "/"
<sinzui> bigjools: yeah, that is why I created the pillar menu which makes a rooted url
<bigjools> sinzui: if I change it to "" it does what I expect
<bigjools> well, sort of :)
<bigjools> actually, no it doesn't. Crap.
<kiko> sinzui, got an answer for me?
<kiko> matsubara-afk, Ursinha: what about you, do you know if I can subscribe a private team to a public or private code branch?
<Ursinha> kiko, nope, not sure, rockstar?
<sinzui> kiko: private teams are supported
<sinzui> kiko: I am creating a private membership team to verify it
<rockstar> kiko, I don't know why you couldn't subscribe a private team, although it's existence might be leaked.
<sinzui> rockstar: you could not in June because of validation contraint
<sinzui> bac fixed it
<rockstar> sinzui, Ugh.  Sometimes privacy is a real pain.
<sinzui> kiko: rockstar: private and private-membership teams can subscribe to a public or private branch
 * sinzui vows to conslidate and rename tests so that he can find them
<kiko> thanks sinzui
<kiko> sinzui, the new guided project registration is really nice, but we need a separate "import a project" workflow now, I realize
<kiko> I used to think you could do that as part of the same workflow
<kiko> but now I don't think you can
<sinzui> kiko: yep
<kiko-fud> I think "Register a new project" and "Import a project from somewhere else" are different things
<kiko-fud> that the user sees really differently
<kiko-fud> anyway, fud
<rockstar> ALL:  I'm going to hunker down and hack.  If you need something, please text me, as I'll be ignoring IRC and email for the next few hours.
 * gmb EoDs
<salgado> sinzui, any suggestions for the next group of pages to convert? maybe poll-related ones?
<sinzui> salgado: They
<sinzui> salgado: I listed poll-edit, polll-newoption, polloption-edit as the ones to convert
<salgado> sinzui, do you mean we're not converting the others or that these are the ones that should go first?
<sinzui> salgado: we are converting all. I listed those pages in my notes to convert next.
<salgado> sinzui, so you're doing them or can I take them?
<sinzui> salgado: take them
<bigjools> sinzui: can we put GET data on a Link() ?
<bigjools> other than hacking the crap out pf it I mean
<sinzui> bigjools: I do not understand?
<bigjools> sinzui: never mind, I've hacked it, I don't see another way.  While you're there, check out these tweaks: http://people.canonical.com/~ed/dsp_mockup_with_linkage2.png
 * bigjools has to go in 5 minutes
<maxb> flacoste: Are you around today? I was hoping to discuss how to submit packages for inclusion in ~launchpad/ppa
<flacoste> maxb: i am, on the phone, though
<sinzui> bigjools: looks nice, beuno will want the links with the counts to have the colours of  the apps
<bigjools> sinzui: do we have a style for that?
<maxb> flacoste: ok, I'll be around for several hours, let me know if you have time for a chat
<beuno> sinzui, you're becoming my evil, but better looking twin
<bigjools> more eccentric twin you mean? :)
<sinzui> bigjools: maybe, I did it on the milestone page
<bigjools> sinzui: ok I'll look on there, ta
<bigjools> beuno: any comments on that page now?
<flacoste> maxb: ok, i just hung up, i have a couple of minutes before it rings again :-)
<flacoste> maxb: these are packages for karmic?
<maxb> Yes - basically the entire python2.4-using modules for karmic
<beuno> bigjools, it looks 7000 times bettar than when you started. And, a few other things, that I'll take to -reviews now
<bigjools> beuno: I need to finish coding the data-retrieval for the table and write tests, so in a couple of days I'll be pinging you for that
<maxb> I have packages in https://edge.launchpad.net/~maxb/+archive/launchpad - some of which are just copy-with-binaries from ~launchpad/ppa jaunty - what's the best way for things to get into ~launchpad/ppa for karmic?
<flacoste> maxb: i think we could copy the binaries over
<flacoste> bigjools: do you have any better suggestion?
<maxb> Sounds good if you're happy with that approach
<bigjools> flacoste: +1
 * bigjools has to go
<flacoste> maxb: why did you drop the python2.4-foo in launchpad-dependencies?
<maxb> That's because I'm simultaneously trying to make it work with both 2.4 and 2.5 - and not all of the packages provide pythonX.Y-foo vdeps anyway
<maxb> Where possible I've done no-change rebuilds to re-add the python2.4 binaries - no source patching at all
<flacoste> maxb: hmm, the problem is that if there is no python2.4 dep, it's possible for the ubuntu package to be selected instead of the PPA one
<flacoste> that was the way we had to make sure that the PPA package was installed, or not removed on upgrade
<maxb> Hmm. OK then
<maxb> So either I need to get nifty with substvars or I have to abandon sticking with no-change rebuilds
<flacoste> right
<flacoste> i did the latter for Jaunty
<flacoste> because i'm not a deb package sho-dan
<barry> beuno: ui sadness :(
<flacoste> maxb: so i'll copy over the other packages now
<maxb> the other packages?
<flacoste> maxb: other than launchpad-dependencies
<maxb> hmm - but some of the others are going to need rebuilding anyway if you would like a python2.4-foo provides inserted
<flacoste> right...
<flacoste> anyway, it's already done :-)
<flacoste> i can copy again later :-)
<maxb> heh, ok
<flacoste> maxb: let me know when there is more stuff you want to move over, either by an email to the list or IRC
<flacoste> maxb: and thanks for doing this, this is really appreciated, especially since we are nearing beta and everybody will need to move over to Karmic
<maxb> sure. btw, I never did a python2.4 version of python-lxml or python-setuptools because I couldn't find anything that needed them any more
<maxb> ditto python-xml
<flacoste> python-setuptools isn't needed anymore
<flacoste> we can drop it from l-d
<flacoste> python-lxml is still needed i think though
<flacoste> for some tests
<deryck> barry, hi.
<maxb> Does launchpad-dependencies have a branch on which I can propose changes? Or what's the best way to submit a proposed change for it?
<flacoste> python-xml, i can't recall
<deryck> barry, your email about milestone links is bug 415156.
<mup> Bug #415156: Can't get to milestone from bug <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/415156>
<flacoste> maxb: actually, that's a very good point
<flacoste> we should now use a branch!
<barry> deryck: cool, thanks!  i'm gonna metoo it :)
<flacoste> i don't think we have one yet
<deryck> barry, heh. :)
<maxb> flacoste: I could run a bunch of bzr import-dsc, and push one?
<flacoste> maxb: that would be awesome
<flacoste> i guess, i'll then need to copy over the branch to ~launchpad and make it an "official" branch of some sort so that merge-proposal goes to it?
<flacoste> (i haven't use the feature yet)
<barry> ubuntu tells me it wants to reboot.  what is this, a mac?
<gary_poster> leonardr: I'm seeing a webservice request in the tests that looks like this.  Does this look well-formed?  http://api.launchpad.dev/beta/product-name4/+bug/16/comments/1
<mup> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <Launchpad Translations:Fix Released by daf> <https://launchpad.net/bugs/16>
<gary_poster> heh
<leonardr> gary: apparently so!
<leonardr> i don't see anything wrong with it. are you having problems?
<gary_poster> leonardr: :-) ok.  Yeah, problems in the lazr.* migration, but wanted to make sure that the problems were not above where I was looking.
<gary_poster> thank you!
<leonardr> np
<salgado> beuno, the icon of the 'Setup a new poll' link on https://launchpad.dev/~ubuntu-team/+polls overlaps with the text; how can I fix that?
<beuno> salgado, is it a sprite?
<salgado> let me check
<salgado>       <ul class="add" tal:condition="context/required:launchpad.Edit">
<salgado>         <li><a href="+newpoll">Set up a new poll</a></li>
<salgado>       </ul>
<salgado> guess not
<beuno> salgado, so the add button is b0rked?
<beuno> remove the "add" class from the ul
<beuno> and add class="sprite add" to the href
<salgado> cool, thanks beuno
<beuno> thumper, let me know if your up early
<beuno> and feeling lonely, wanting to talk
<beuno> woooo, 79 templates converted, and the number of templates dropped to 375
<kiko> unconverted
<beuno> yes, unconverted dropped to 375
<beuno> from 400+  (can't remember the exact number)
<beuno> actually
<beuno> yeah, that makes no sense
<beuno> the total number dropped, because the scales changed
<barry> sinzui: ping
<sinzui> hi bary
<barry> sinzui: hi
<barry> sinzui in your review you mentioned merge people, merge team and merge accounts.  i moved those inline so i don't feel a need to stick them in the menu.  wanted to see if you thought that was enough
<barry> sinzui those don't feel like universal actions for all top level containers, like the other ones do
<sinzui> but, barry, every other object puts at admin links in the action menu. The admins do not read the page.
<barry> sinzui: then maybe they shouldn't go inline also?  it doesn't feel right to me.  maybe beuno can weigh in?
<sinzui> barry: consider who we are designing for. The LOSAs. 4 people who have a lot to do and the only thing they read is BOFH.
<beuno> barry, admin-only links can go on portlets
<sinzui> barry: I do not think they need to be inline. That is content we become obligate to mainstain
<beuno> but only if they're super-admin things that only 3 people in the worl dsee
<sinzui> 4 next month
<kiko> sinzui, did you see that https://edge.launchpad.net/helioviewer is still oopsing? didn't this fix land on edge yet?
<sinzui> we need to capture this ruling
<beuno> ok, call me when it's over 1000
<sinzui> kiko: no PQM was closed for a CP
<barry> sinzui, beuno okay, sounds good.  admin links into the portlet and out of inline
<barry> thanks guys
<gary_poster> EdwinGrubbs: ping
<EdwinGrubbs> gary_poster: pong
<gary_poster> EdwinGrubbs: When I run multiple tests in a branch that I'm doing some surgery on, I'm getting a postgres disconnection error after the first test.  so--the first test passes, the subsequent tests (in the same layer) fail with the disconnection error in the setUp.
<gary_poster> EdwinGrubbs: (1) am I correct in assuming that normally we never disconnect from the db?
<gary_poster> (or rarely, not normally between tests)
<EdwinGrubbs> gary_poster: I believe we only disconnect in tests when we are testing that functionality.
<gary_poster> (2) can you suggest a break point I can put in to see who is calling the disconnect?
<gary_poster> EdwinGrubbs: cool, that's what I thought
<gary_poster> EdwinGrubbs: (not sure you saw my question #2 above.) Probably a ``disconnect`` method I should use? :-)  Trying to grep myself, but advice would be welcome.
<sinzui> barry: ping
<sinzui> barry: is it possible to show the latest teams registered on the /people page in 30 minutes of work? See https://edge.launchpad.net/projects
<EdwinGrubbs> gary_poster: the code you are looking for might be _reset_store() in canonical.launchpad.sqlbase. If that doesn't work, it might be easiest to wrap the _raw_connection object that storm holds, and watch for a close() method call.
<barry> sinzui: maybe, but... mission creep? :)
<gary_poster> EdwinGrubbs: awesome, thank you!
<sinzui> barry: yes it is
<barry> sinzui: open a bug.  maybe later
<sinzui> barry: I do not know why that page has the team portlet. We can add it when we extract it from the project page
<barry> sinzui: i don't understand
<sinzui> barry: you are doing the project page next
<sinzui> barry: I mean /projects page
<sinzui> barry: I just cc'ed you on a reply to thumper. He is also playing with /projects
<barry> cool
<thumper> sinzui: one issue is we are redirecting from a view on LaunchpadRoot, to the default view on /projects for the code site
<thumper> sinzui: does our redirection infrastructure allow this easily?
 * thumper runs Maia to playcentre
<sinzui> thumper: I see the rootsite in the directive. I think it works
<flacoste> anyone knows where are the instructions on how to upload an .ogg recording the desktop?
<sinzui> thumper: it was written for support.launchpad.net/<pillar>/+ticket/<id> to redirect to answers.launchpad.net/<pillar>/questions/id
<barry> sinzui: well, at least ec2 is happen with my branch
<sinzui> barry: \o/
<barry> sinzui: now i just have to get through this review :)  nearly there
<thumper> beuno: ping
<thumper> barry: did you get my mail about mailman and missing people?
<beuno> thumper, leaving home in 10
<beuno> thumper, will try to come back online so we can talk in an hour
<thumper> beuno: ack
<beuno> thumper, I've continued working on the mockup
<beuno> not much, but fed some of the feedback back in
<beuno> now, really gone for an hour
<flacoste> sinzui, beuno: here is what the launchpad-project home page looks for me
<flacoste> https://devpad.canonical.com/~flacoste/launchpad-project-top.png
<sinzui> a giant list and whitespace?
<flacoste> https://devpad.canonical.com/~flacoste/launchpad-project.png
<flacoste> sinzui: yes, but the side is also at the bottom
<flacoste> and there is whitespace on the right
<flacoste> and the left
<sinzui> flacoste: I am rearranging the the portlets on that page as a part of my portlet preparation for the disrto page
<sinzui> flacoste: all see it
<flacoste> you mean, it's not flowing on the right for anybody?
<sinzui> It should be fixed in 2 days
<sinzui> flacoste: no YUI-G is a grid and it does not like variable width, which is what we do
<flacoste> ah, ok
<sinzui> flacoste: We are changing the layout to be more like 1.0 to accommodate it.
<flacoste> and https://devpad.canonical.com/~flacoste/launchpad-project-code.png
<flacoste> is the code page
<sinzui> flacoste: This wasn't a surprise. We wanted to see severalc ases before making a decision about how to fix it
<flacoste> there it always needs scrolling
<flacoste> and the right column is tight with the scrollbar
<flacoste> sinzui: ok, got it
<sinzui> flacoste: this last pic is odd
<flacoste> yeah, kiko wasn't seeing it
<flacoste> i am using firefox
<sinzui> flacoste: is there a very large unwrappable branch path?
<flacoste> not that i can see
<flacoste> all branches have amble of white space
 * sinzui looks himself
<barry> thumper: i did, but i haven't had time to think about it yet
<flacoste> well, unless there is a padding-right on the name column
<flacoste> in which case lp:~adeuring/launchpad/hwdb-db-schema-subvendor-subproduct-columns would explain it
<flacoste> if there is someting like 20em of padding-right
<sinzui> flacoste: I am looking at https://code.edge.launchpad.net/launchpad-project
<thumper> who wrote the code for showing the pillar on the 3.0 pages?
<flacoste> yep same here
<sinzui> I see a 20px right margin, no scrolling
 * sinzui force-reloads
<flacoste> hmm, this is weird
<flacoste> me gets the same thing after a force-reload
<sinzui> I see missing row borders and rows that are uneven height. I cannot account for the irregularities in this page.
<flacoste> sinzui: do you see the same errors after force-loading?
<sinzui> yes
<sinzui> My page is readable, which cannot be said for yours
<sinzui> My browser window is set to 1024 wide
<sinzui> yours is 1225
<thumper> I have some questions about the logo in the corner
<thumper> who do I ask?
<rockstar> sinzui, I has a question about a failing answers test - Do you have a minute?
<sinzui> i do
 * sinzui prepares for uncode nonsense.
<rockstar> sinzui, so, it looks like there is some sort of ACL for linking bugs to questions, as an admin seems to be able to link a bug that another person can't unlink.
<sinzui> rockstar: bug linking is based on the user being an answer contact (which is voluntary)
<rockstar> sinzui, hm.  Okay, so I haven't changed any actual underlying code here, but the test  answersbugs/stories/question-buglink.txt is failing at line 155.  I'm not sure how a minor template change would break that.
<sinzui> rockstar: I just looked at the answersbugs/configure.zcml and see that +linkbug and +ublinkbug are AnyPerson
<rockstar> Yeah, that's how I've understood it.
<rockstar> sinzui, so I don't completely understand why there would be a test for not being able to unlink a bug.  This is what I'm trying to sleuth.
<thumper> sinzui: I don't like that our primary context is derived by IHasLogo
<thumper> sinzui: shouldn't we have a definitive interface like IPrimaryContext
<thumper> sinzui: I'm trying to work out how to fix branches
<rockstar> Oh wait, it looks like bug #6 is set to private in the test.
<mup> Bug #6: "next 10 entries" at bottom of page <Launchpad Translations:Invalid by carlos> <evolution (Ubuntu):Invalid> <https://launchpad.net/bugs/6>
<sinzui> thumper: you are welcome to introduce the interface. You can solve the ISprint problem while you are at it ;)
<thumper> sinzui: also if the context doesn't provide IHasLogo, it walks up the canonical_url_iterator
<rockstar> However, that still doesn't explain why the text is gone.
<thumper> sinzui: what is the ISprint problem?
<sinzui> rockstar: I see and think that is related
<rockstar> sinzui, I think I figured it out.
<sinzui> rockstar: There are nasty unicode issues in the tests where something prints fine (but has unicode in it) then the next test fails, leaving you confused
<rockstar> generic-edit is proving less and less useful - or maybe the extra information we have is proving to be more of a pain in the but.
<sinzui> thumper: Sprints have IHasLogo, so they get branding. Should they?
<thumper> sinzui: what are we calling this thing in the top corner?
<sinzui> thumper: I think Sprints really belong in a registry, but it bound to projects via a blueprint
<thumper> sinzui: are we calling it our primary context?
<sinzui> I call it a watermark
<thumper> sinzui: and it should be one of Person, Product, Project, Distro ?
<sinzui> The context is in the breadcrumbs. It is generated by the heading-slot
<thumper> sinzui: is it ever something else?
<sinzui> thumper: apparently there is Sprint
<thumper> sinzui: *should* it ever be something else ?
<spm> sinzui: we also read alt.sysadmin.recovery, not just BOFH
<rockstar> thumper, I think that generic-edit.pt should have a way to show the "extra_info" slot idea.
<sinzui> thumper: Anything that a top-level collection can return may be viewed as the root, so outside of the collections we just named, I will add bugtracker and language
<rockstar> thumper, that would mean we could get rid of more templates.
<sinzui> thumper: But I am unsure of them. there are several bugs about how we treat top-level collections or these rare objects so we are feeling out the rules as we implement their pages.
<sinzui> rockstar: I am sorry about these tests. I am sure many failed because they assumed a certain HTML structure. I now only use ids to find and test content.
<thumper> sinzui: ok, how about this: IWatermark interface, watermark:heading and watermark:logo tales path adapter
<rockstar> sinzui, not a big deal.  This one was my fault, actually.  There were some others where I had WTF moments, but I have that pretty regularly anyway.  :)
<thumper> sinzui: adapts the context to IWatermark.
<thumper> sinzui: we register adapters for the pillars
<thumper> sinzui: failure to adapt gives launchpad.net
<sinzui> thumper: That is too close to IHasLogo. And the reason the design uses that is because branding is important. Let's rename IHasLogo if you are thinking about IWatermark.
 * thumper thinks about walking the url...
<thumper> sinzui: but what about sprints that have a logo?
<thumper> sinzui: wouldn't it be more important to kill the logo of a sprint?
<sinzui> Yes it does and I am not sure it is wrong to show it. It is branded so I think we want to show it
<thumper> sinzui: if we are using IHasLogo to determine the watermark, then lets just use that
<thumper> sinzui: but *should* it be branded?
<sinzui> I think so
<thumper> why?
<thumper> sinzui: it seems strange to provide an adapter for IBranch to IHasLogo for some reason...
<sinzui> Because they exist outside of teams and projects. I do not think they need a blueprint to exist.
<sinzui> thumper: I agree
<sinzui> Let's return to IPrimaryContext
<thumper> ok
<sinzui> My concern is that the content of the page is about the context, not the IPrimaryContext. like a milestone, or a bug
<thumper> what about the watermark tales adapter?
<sinzui> I like that suggestion
<sinzui> I am considering IRegistration to make the "Registers by <person> on <date>" in the header
 * thumper nods
<thumper> although the content should be overridable
<thumper> speling fail
<sinzui> make more sense than my spelling
<thumper> sinzui: how do you traverse to a sprint?
<sinzui> https://edge.launchpad.net/sprints
<sinzui> https://edge.launchpad.net/sprints/uds-karmic
<thumper> oh holy bejezus
<sinzui> thumper: ubuntu is the major user. the feature is hidden. I like it. I think it would be used if it was not so tightly coupled with blueprints
<thumper> those pages need some love
<thumper> sinzui: we should not hide it so much
<sinzui> thumper: I believe that will be barry's effort
<thumper> sinzui: bring on those project management features :)
<barry> sinzui: more on your review
<barry> sinzui using the menu on the inline text makes the tal look horrible.  how strongly do you feel about it?
<sinzui> barry: You put me in an awkward position
 * barry is a contortionista
<barry> sinzui: oh and context/menu:overview is empty
<sinzui> barry: I feel strongly that consistency is often better than beauty
<barry> sinzui: "strongly" is an acceptable answer :)
 * sinzui thinks
<sinzui> menu:usefor=IPersonSet -> context/@@+global-actions
<sinzui> barry: there is another option for a shortlist use <ul class="horizontal"> to make links like the project page external links. You can fit about 5 links in the space.
<barry> hmm
<sinzui> barry: did you update the menu directive in ZCML?
<sinzui> barry: if not do you want to say FTW and just register them al in python like a real man.
<sinzui> thumper: I think IRootContext or IFirstContext is better than IPrimaryContext. I think that because "primary" implies the content of the page to me, which is not your case when the breadcrumb are a level below root
<thumper> IRootContext WFM
<thumper> sinzui: do we have a nearest_adapter?
<thumper> sinzui: the nearest method in c.l.webapp.publication only checks for providedBy, not adaptation
<thumper> sinzui: sould we have IProduct, IProject, IPerson, IDistribution inherit from IRootContext?
<thumper> sinzui: or should we adapt to it
 * sinzui looks in menu
<thumper> I've got to take the car to the mechanics now
<thumper> there is some issue with the brakes they fitted a couple of weeks ago
<thumper> shouldn't be long
<sinzui> thumper: I would make them inherit
<thumper> sinzui: ok
<sinzui> from canonical.lazr.canonicalurl import nearest_adapter
<sinzui> ^ thumper
<thumper> sinzui: I think we should do something like this instead of nearest
<thumper> sinzui: otherwise we need to provide adapters for everything under branches too
<thumper> sinzui: sound ok?
<sinzui> thumper: that is the same reasoning salgado gave for IRegistrant
<thumper> sinzui: I'll write it up and get you to review
<sinzui> thumper: I think it is and I think it better if we take the same kind of approach to solving the header issues.
 * thumper nods and leaves
<wgrant> cprov: buildd-manager isn't as async as you think it is. Both upload processing and ensurePresent block it.
<kiko> hey
<kiko> sinzui, barry: can I get a mailing list approved?
<beuno> kiko, Canonical DX Team Commits?
<kiko> beuno, yep!
#launchpad-dev 2009-08-19
<beuno> kiko, approved
<beuno> although it makes me wonder why *you* can't approve it  :)
<kiko> beuno, sinzui: https://edge.launchpad.net/notify-osd persistently oopses with the same error I saw yesterday -- sorry I was out, but is this still not fixed?
<beuno> kiko, PQM was closed, so the branch didn't go in
<beuno> not sure if sinzui managed to get it in now
<wgrant> devel r9131 - it landed like 20 hours ago.
<beuno> there you go
<beuno> the benefits of being open source *and* having wgrant around
<kiko> heh
<kiko> okay, I gotta split
<kiko> catch you all later
<rockstar> Oh bugger, looks like I need to port a bugs page...
<thumper> beuno: you around for a chat?
 * thumper is a very frustrated monkey
 * thumper does lunch
<cprov> wgrant: that's not true, all xmlrpc commands on the master side are asynchronous
<cprov> wgrant: the slave side isn't.
<wgrant> cprov: But I've seen it cease to make XML-RPC requests to the other slave while the first one is downloading the chroot.
<wgrant> (I verified this morning)
<cprov> wgrant: are you using daemon/buildd-manager.tac ?
<wgrant> cprov: That's the one.
<wgrant> It certainly looks like it should be async.
<cprov> wgrant: right, check BuilddManager.scan(), the slave used for dispatching is non-blocking
<wgrant> cprov: I'll try again this evening when I have my other buildd back, but I'm pretty sure it ceased to scan while the download was occurring.
<wgrant> Which makes no sense, given the code.
<cprov> wgrant: maybe you can add more debug to the manager in order to prove your hypothesis
<wgrant> cprov: How do I inform twistd that I want to increase the logging level?
<wgrant> There's lots of useful debug logging points, but they're not shown.
<cprov> wgrant: you don't twistd doesn't accept args, needs code/config change
<wgrant> cprov: Ah, OK.
<cprov> wgrant: BM._setupLogger()
<wgrant> cprov: Yup, just found that.
<cprov> wgrant: you probably need more debugs, specially for ensurePresent() at the xmlrpc proxy. The current logging timestamp precision should be enough for spotting blockers.
<wgrant> cprov: It is definitely synchronous somehow. I added a time.sleep(30) in the slave's ensurepresent, started a build on a real builder, and marked a non-existent builder as OK. As expected, I can see it calling ensurepresent for each file for the build. 32 or so seconds later, it logs the response.
<wgrant> There is no scan in between.
<wgrant> And my builder that is uncontactable is still marked OK, when it should have been deactivated 90 seconds ago.
<wgrant> Once the build call went through after the 30 second wait for each file, the scanning started again and killed the bogus builder.
<wgrant> So it is synchronous, somehow.
<cprov> wgrant: the scan cycle is synchronous with and 5 s delay, it won't finish the cycle if the dispatching started haven't finished.
<wgrant> cprov: Ohh, I see. That's a bit bad. It is still fairly synchronous!
<cprov> wgrant: not really, there is an async burst of dispatching ... and that combined with 60 s timeout on the xmlrpc proxy guarantees that cycles won't take much longer than that.
<cprov> wgrant: of course we could be more async, I don't see any harm on that, but it requires more refactoring.
<wgrant> cprov: This explains why builds often seem to take ages to finish. I'd been wondering about that.
<cprov> wgrant: how so ? *ages*  to be scanned again ?
<wgrant> cprov: Right.
<wgrant> Often I'll see a logtail that is right near the end of the build.
<wgrant> But the build won't complete for a couple of minutes afterwards.
<cprov> wgrant: this perception comes mostly from the collecting task
<cprov> wgrant: specially when we have to collect and process dozens of jobs, calling process-upload several times.
<wgrant> Yep.
<wgrant> And starting that isn't exactly quick...
<cprov> wgrant: the dispatching cycle itself will always take about 80s (10s resuming, up to 60s dispatching, and some cruft) for 1 or 100 builders
<cprov> wgrant: no, initZopeless() takes about 8s (IIRC)
<cprov> wgrant: one change that would immediately remove that would be replacing the process-upload calls by directly instantiation of UploadProcessor()
<wgrant> cprov: Why wasn't that done in the first place?
<cprov> wgrant: the only gotcha with it is that we need to switch db_user
<wgrant> cprov: Isn't it more appropriate to grant the builddmanager DB user the required privs?
<cprov> wgrant: because the gain on async dispatching was higher
<wgrant> Ah.
<cprov> wgrant: ehe, not from the isolation PoV
<cprov> wgrant: uploading and publishing binaries doesn't necessarily fit in build-dispatching domain.
<wgrant> cprov: True.
<cprov> wgrant: but if you ask my personal opinion, I'd say that we have too-many-db-users atm ;)
<cprov-zzz> good night, guys!
<thumper> who changed make TAGS to make the tags file 53Meg? at 15 it was bad enough
<thumper> or is it just the result of buildout chagnes?
<sidnei> thumper: i suspect it should exclude the paths that contain the dependencies
<thumper> arse
<thumper> for the second time in as many days my laptop's keyboard stops responding
<thumper> Hmm, some bugs say slow-keys
 * thumper must check that next time
<jtv> jml, did you get word of the Mysterious Unfinished Branch Jobs?
<gmb> Hmm. Did the session DB get nuked when I wasn't looking?
<adeuring> good morning
<stub> gmb: Yup
<gmb> stub: Okay. As long as I've not gone mad.
<gmb> Okay, madder.
<stub> Thats a seperate bug
<gmb> Argh! I've just double-filed two bugs. Damn chromium.
<gmb> Hitting enter for form auto-completion apparently submits the form, too.
<jtv> hi henninge
<jtv> hi stub, gmb & all the rest :)
<henninge> hi jtv !
<gmb> jtv: Goedemorgen.
<jtv> gmb: Geweldig, je spreekt Nederlands!
<gmb> jtv: Niet erg veel.
<jtv> gmb: I seem to be making progress with your language as well: I think in the past week at least 4 Brits had me pinpointed as English with absolute confidence.
<jtv> gmb: my girlfriend's learning Dutch... want to set up a weekly practice session on skype?  :)
<gmb> jtv: That generally means that you're making all the right mistakes. As BjornT once told me: English doesn't have many rules, but it has a lot of exceptions.
<gmb> jtv: It's tempting. I think I'll try to convince someone to let us sprint in Amsterdam first. It's nice to have an aim in mind :)
<jtv> gmb: English is the lest prescriptive European language I can think of... matches the legislative culture as well.  You just do whatever everyone else does.  :)
<gmb> :)
<jtv> Oooh, sprint in Amsterdam...  high time for another one of those
<jtv> gmb: the drawback is that more than any other European language, English makes me feel I don't know the meanings of many words.  I merely _associate_ them with things.
<gmb> jtv: Oh, that isn't how language is supposed to work? Damn, I've been doing it wrong all this time...
<gmb> But yes. that's a problem even for native English speakers.
 * jtv finally looks up "acrid"
<jtv> Apparently it means "The program 'dict' is currently not installed."  Some examples follow.
<gmb> jtv: The trouble is that once you learn the words there's a good chance you'll hold on to their meanings when no-one else does and become something of a sesquipedalian.
<jtv> Sharp and harsh, or bitter and not harsh; pungent (but presumably in some particular way).  Basically a copout for "we don't know either, we only ever use it to describe gun smoke"
<jtv> dict sesquipedalian
<jtv> a dwarf?
<gmb> jtv: Also, the smell of powersupply smoke.
<jtv> lol
<gmb> jtv: Sadly, not a dwarf. Though the idea is interesting. Sesquipedalian == "Person who uses long words." Synonyms: Smartarse.
<jtv> ah, from: one apt to the usage of words like sesquipedalian
<jtv> Dict said "measuring or containing a foot and a half; as, a sequipedalian pygmy."
<gmb> Awesome!
<gmb> And, this being English, probably completely accurate.
<gmb> Yes, according to wiktionary anyway, "a foot and a half" is it's literal meaning.
<jtv> In Dutch, or German, or French etc, when you look up a word, you expect a definition.  Not a series of loose associations, a list of references in last year's TV programs, and an artist's impression.  (Yes Wikipedia, I'm looking at you).
<jtv> Now Thai, Thai is the master of loosely-associated words.  Try "translating" some on thai2english.com.  It won't even find all the words' beginnings and endings, let alone conclusive meanings.
<gmb> lol.
<gmb> That used to be a game on some radio station or other: Translate a song title into Thai, translate it back again, see what comes out.
<jtv> gmb: an observation.  Like English, Thai doesn't normally distinguish between orange the fruit and orange the colour. The word for juice also means water, or pretty much anything that's fluid or gel-like (basically anything you could take on a plane before 2002 but not after).  And "100%" basically means "to a significant extent."
<jtv> Thus, the Thai for "100% orange juice," strictly read, says no more than "a fluid that is to a significant extent orange in colour."
<gmb> Excellent.
<mrevell> Hello!
<wgrant> gmb: Does PQM still hate me?
<gmb> wgrant: It did earlier this morning. You're number 3 in the queue at the moment so we should know within an hour whether you're cursed or not.
<wgrant> gmb: It has so far expressed its intense dislike for me twice on this branch?
<gmb> wgrant: Well, once was because we were in testfix, the other *looked* like a testfix issue but there's no email for a relevant breakage so I don't know.
<gmb> wgrant: You have to remember, though, that PQM hates *me*. You, OTOH, might well have done nothing wrong :)
<gmb> (Ask sinzui; it hates him too)
<wgrant> Heh.
<wgrant> Third time lucky..
<gmb> Here's hopping
<gmb> Er.
<gmb> Hoping.
<wgrant> bigjools: Um, so it's not a bug that the pillar shown on the DSP code index is the distro?
<wgrant> Oh, but the app tabs link to the source package.
<wgrant> That's confusing,.
<bigjools> on phone, one sec
<thumper> launchpad just passed 200000 branches \o/
<wgrant> thumper: Ouch.
<wgrant> thumper: Can you say how much disk space?
<thumper> wgrant: we'll hit 300k before all the package branches are up
<thumper> wgrant: lots
<wgrant> Ah, PQM is alive after all.
<bigjools> wgrant: yes it's confusing
<danilos> mrevell: shall we mark https://launchpad.net/launchpad/2.1 as either 'stable', 'supported' or 'obsolete'?  (I hate how it's showing up among active series on the graph on launchpad.net/launchpad)
<bigjools> we talking about having a packaging tab, but that would screw over bugs
<wgrant> bigjools: A packaging tab only makes sense for products/projects/people.
<bigjools> exactly
<bigjools> so if it's a bug on a package ...
<wgrant> And has little to do with this strange dual-context thingy.
<bigjools> well it has a lot to do with it
<mrevell> danilos: I'm not sure what applies in our case. Obsolete I guess because you can't really run 2.1.
<danilos> mrevell: yeah, I'd likely agree
<mrevell> danilos: done
<danilos> mrevell: great, thanks (fwiw, that's what we have on old series like https://launchpad.net/rosetta/1.0)
<mrevell> danilos: Cool, I'll keep on top of that then, at least until our PM starts :)
<danilos> mrevell: yes, prime minister :)
<mrevell> heh
<wgrant> PM? New project manager?
<bigjools> yes, there a position open
<wgrant> Ah.
<bigjools> can you say "singing from the same hymn sheet?" and "blue-sky thinking" ?
<wgrant> Huh?
<bigjools> PM BS bingo
<wgrant> Ah, right.
 * wgrant isn't quite sure who is what.
<stub> The closest I can get is 'drinking from the same toilet'.
<bigjools> laying the same cable
<mrevell> :)
<wgrant> Heh.
<gmb> wgrant: So, I suck at reading regexes. Resubmitting again. Should work this time.
<wgrant> gmb: Thanks.
<deryck> good morning, all.
<wgrant> Morning deryck.
<bigjools> hi deryck
<jtv> jml: did you get word yesterday about the mysterious lingering branch jobs?
<wgrant> gmb: I presume it didn't?
<wgrant> Or is PQM even slower than I thought?
<BjornT> wgrant: pqm is processing a lazr.restful branch, which means that it runs the full test suite
<wgrant> BjornT: Ah.
<barry> bac: ping
<bac> good morning barry
<barry> bac: good morning!  i have a question for you regarding private teams
<bac> ok
<barry> if i'm an admin for a private team, but not an owner, it appears as if i cannot make other members admins
<barry> bac: i'm not sure of the exact combination of PMT/private, owner/admin, etc
<barry> bac: is this a bug or a feature?
<bac> barry: that is true of all teams.  even on public teams only the owner can beknight others
<bac> barry: i think it is a (questionable) design decision
<barry> bac: i guess when i've done this before i've been the owner too
<barry> bac: agreed
<bac> yeah, i was surprised when i first discovered that behavior
<barry> bac: thanks.  i'm going to file a bug on this, unless you know there's already one open
<bac> barry: should be a super easy fix.  i don't know if there is a bug yet.  it's worth a discussion on the list, though, to ensure there is no reason for why it is so.
<barry> bac: cool, thanks
<gary_poster> intellectronica: I saw you tried to land the lazr.restful thing on pqm last night.  I got a bunch of librarian-related failures on mine that seem verrry unlikely to be caused by my change (a two line patch that casts a token from unicode to str and passes on ec2test).  Did yours succeed?
<intellectronica> gary_poster: yeah, my patch landed
<gary_poster> intellectronica: huh.  ok, I'll just try again, I guess.  I have a branch I'm working on now to switch lazr.* out of sourcecode/pqm land, but canonical-identity-provider and shipit will be pqm forever atm. :-/  thanks
<intellectronica> gary_poster: oh cool, does that mean that we'll converge on a single restful trunk which will be included using buildout?
<gary_poster> intellectronica: yes
<intellectronica> excellent!
<deryck> EdwinGrubbs, ping
<EdwinGrubbs> deryck: pong
<sinzui> Why wasn't edge update?
<danilos> sinzui: hi there, I have a case where object doesn't have canonical_url defined (and it shouldn't), but there are subpages on it
<sinzui> ??
<danilos> sinzui: that totally breaks with new templates with something like "NoCanonicalUrl: No url for <Translator at 0x64dfb90> because <Translator at 0x64dfb90> broke the chain."
<sinzui> danilos: what breaks? The code that makes the branding?
<sinzui> yes, I bet that is it
<danilos> sinzui: yeah, or perhaps breadcrumbs (I'd suspect breadcrumbs)
<danilos> if there are breadcrumbs :)
<sinzui> danilos: the breadcrumb code is from 2.0
<barry> reviewers (and lurkers) -> #launchpad-meeting in 4m
<sinzui> danilos: The branching searches (traverses) to IHasLogo
<danilos> sinzui: it might come as a surprise then that this page was never migrated to 2.0 either (I am actually trying to use generic-edit.pt for the form)
<sinzui> danilos: Send an email to thumper. He is creating an alternate way to get branding...IRootContext. I think his solution will fix your problem
<danilos> sinzui: right, it does fail in IHasLogo, will do that
<barry> reviewers (and lurkers) -> #launchpad-meeting
<flacoste> Chex: hi there! could you delete the following vcs-import when you have time: https://code.edge.launchpad.net/~vcs-imports/windmill/trunk ?
<flacoste> Chex: nevermind, it seems i have permission to do so
<sinzui> danilos: thanks for bring this up. your use case is better justification than the ones I was thinking of
<danilos> sinzui: sure, thanks
<Chex> flacoste: ok, no problem :)
<barry> beuno: do you want to join our reviewer's meeting?
<beuno> flacoste, http://morgamic.com/2009/08/18/optimizing-your-js-and-css/
<flacoste> beuno: tell me something i don't already know :-)
<beuno> flacoste, this is my attempt to keep the CSS minifying on the table, rather than informing!  :)
<james_w> did edge rollout this morning?
<james_w> something seems to have happened at ~08:44
<flacoste> james_w: i think there was an edge server that didn't updated properly
<flacoste> james_w: btw, we should be upgrading to HAProxy soon for load balancing, that should really makes thing better for you
<flacoste> as it catches when backend server are not available
<flacoste> james_w: https://wiki.canonical.com/IncidentReports/2009-08-19-launchpad-edge-fail/
<james_w> that might be related
<james_w> I'm still seeing issues though
<james_w> not described there
<flacoste> james_w: what issue?
<james_w> hmm, might have *just* gone away
<james_w> bug 415943
<mup> Bug #415943: branch.lp_save() often give PreconditionFailed <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/415943>
<james_w> nope, still there
<flacoste> leonardr: could you help out james_w in diagnosing the source of bug 415943?
<mup> Bug #415943: branch.lp_save() often give PreconditionFailed <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/415943>
<leonardr> flacoste, sure
<flacoste> thanks
<james_w> ah, a little more insight I think
<james_w> so something changed this morning that means lp_save() on a branch will now fail if you didn't change anything
<james_w> but before it worked whether you changed it or not
<leonardr> james_w: the first step in diagnosis is to set httplib2.debuglevel = 1 before creating the Launchpad object
<leonardr> this will give you dumps of the http requests/responses
<leonardr> we're especially interested in the http headers ETag, Last-Modified, If-Modified-Since, and If-None-Match
<leonardr> since those are the ones that determine whether the server will give you Precondition Failed
<james_w> http://paste.ubuntu.com/255765/
<leonardr> you commented on bug 336866. that bug was caused by an interaction between an ObjectModifiedEvent and the unmarshalled field cache
<mup> Bug #336866: When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed" <lazr.restful:Fix Committed by leonardr> <python-launchpadlib (Ubuntu):Invalid> <https://launchpad.net/bugs/336866>
<leonardr> i backported a fix to the lazr.restful branch used by launchpad, but apparently launchpad didn't pick it up, because people are still having that problem
<leonardr> are there any interesting ObjectModifiedEvents triggered when save() is called on a branch object?
<james_w> I think my comment on that bug was mistaken
<james_w> I think when I was getting this before the errors were legitimate, as scanning updates the last_scanned entry in the branch or something
<james_w> and that would happen shortly after pushing, around the time I was setting the status
<james_w> I implemented retry support to handle that
<james_w> but this morning the retries don't help
<james_w> further to the paste above, retrieving the object again gives the same ETag: 7bdbf8234351ddfa1c58adf96ab423eb41ab8f6e
<leonardr> thanks, i was just about to ask that
<james_w> so something fishy is going on
<leonardr> james_w, can you reproduce this in your local launchpad installation?
<james_w> I haven't tried
<abentley> sinzui: It seems like account creation refuses to create accounts for email addresses used by SSO, etc, but password recovery only works for Launchpad accounts.  Is that possible?  example address: paul.szwajkiewicz@wp.pl
<sinzui> salgado: ^
<leonardr> james_w: please give it a try, as the only ways to debug it at this point are by backtraces in the code or manual examination of the code
<leonardr> on the http level everything looks like it should be working
<bigjools> sinzui: where is PillarView tested?
<sinzui> abentley: I believe this /was/ true, but salgado fixed it
<james_w> leonardr: yeah, that's why I'm asking if edge rolled out today, that would narrow it down
<salgado> abentley, password recovery on login.launchpad.net should work for SSO accounts
<james_w> I'll try and get launchpad.dev fired up
<sinzui> lp/registry/browser/tests/pillar-views.txt
<abentley> sinzui: It seems to not be fixed as of r9129
<intellectronica> adeuring: gary_poster mentioned something about failures related to the librarian he had trying to land branches
<adeuring> intellectronica: thanks!
<abentley> sinzui, salgado: Try the example address I gave on edge.
<bigjools> sinzui: thanks, grep was not my friend
<abentley> sinzui, salgado: paul.szwajkiewicz@wp.pl
<gary_poster> adeuring, intellectronica: yes, I don't see the background in history, but I got a *lot* of librarian failures on pqm
<salgado> abentley, if that email is of an SSO account, then it can't use edge.launchpad.net
<gary_poster> adeuring: I just retried, since intellectronica had success
<adeuring> gary_poster: OK, I'll try that
<abentley> salgado: Just tested on prod, and it also doesn't work there.
<salgado> abentley, prod shouldn't work either
<salgado> only login.lp.net should work
<abentley> salgado: !?
<salgado> abentley, this is not a launchpad account -- it's an SSO one
<abentley> salgado: A user tried to create an LP account and was told they couldn't, because the address was already in use.  So they tried to recover their password, and they couldn't, because it wasn't a Launchpad account.
<salgado> abentley, as I said earlier, they can reset the password on login.launchpad.net.  once that's done they can use the new password to log into launchpad.net
<abentley> salgado: I think that we should make that much easier for users, potentially by letting them recover an SSO password from launchpad.
<abentley> salgado: There is nothing to indicate to the user that they need to do this.
<salgado> abentley, agreed, but when we prevent the user from registering we say that they can use the SSO credentials to login
<salgado> (agreed about making it easier, I mean)
<abentley> salgado: But we don't say how to recover the SSO credentials, so that's not really enough.
<abentley> salgado: Is the launchpad.net password recovery a subset of the login.launchpad.net password recovery?  If so, I think it would be sensible to always use the login.launchpad.net password recovery.
<salgado> it's not
<salgado> abentley, ^
<abentley> salgado: What are you pointing me to?
<salgado> the line above, where I said it's not a subset
<abentley> salgado: Okay, in that case it would be great if we could add "If you have forgotten your password, use login.launchpad.net (not this page) to recover it."
<rockstar> barry, I think you forgot that we decided I'd attend the AsiaPac reviewer meetings now.
<abentley> salgado: To the specific error.
<barry> rockstar: right!
<salgado> abentley, agreed, can you file a bug about that?
<gmb> I'm sick of IRC clients now. Can we please go back to carrier pigeons?
 * gmb goes to find a cup of tea
<abentley> gmb: Actually, I'm using a Pidgin right now :-)
<rockstar> abentley, boo.  :)
<gmb> Argh. Didn't want to change my nick. Damn thing...
<james_w> leonardr: I can't seem to reproduce with the latest devel
<leonardr> aaargh
<leonardr> james_w: what about my earlier question about ObjectModifiedEvents?
<leonardr> that's almost certianly not the problem because you'd have it reliably
<james_w> "<leonardr> are there any interesting ObjectModifiedEvents triggered when save() is called on a branch object?" ?
<leonardr> yes. more generally, does anything unusual at all happen when you save a branch, that doesn't happen for other objects?
<james_w> I assumed you were asking your fellow LP devs, I don't know the answer, sorry
<leonardr> oh, i see
<james_w> I've just updated the bug
<leonardr> rockstar, maybe you can help?
<james_w> lp.me.lp_save() also gives the error
<maxb> flacoste: New python-apt available in ~maxb/launchpad for syncing to ~launchpad/ppa (in response to new version in karmic primary)
<flacoste> maxb: great, thanks! i'll copy over
<flacoste> done
<rockstar> leonardr, james_w, we haven't gone out of way to do anything special on save through the API.  What's the actual issue?
<leonardr> rockstar: james_w gets a 412 Precondition Failed every time he saves a branch object
<leonardr> apparently this just started happening recently
<rockstar> Hm, does it say what the precondition is, or give an oops?
<leonardr> rockstar: well, the precondition is almost certainly an etag failure
<leonardr> meaning the server-side calculated etag doesn't match what he sent
 * rockstar hasn't gotten that far in the Rest book yet...
<james_w> {'status': '412', 'content-length': '0', 'via': '1.1 wildcard.edge.launchpad.net', 'x-powered-by': 'Zope (www.zope.org), Python (www.python.org)', 'vary': 'Cookie,Authorization,Accept', 'server': 'zope.server.http (HTTP)', 'x-content-type-warning': 'guessed from content', 'date': 'Wed, 19 Aug 2009 15:05:22 GMT', 'content-type': 'text/plain'}
<leonardr> but when he GETs the object again immediately after the failure, it still has the same etag
<rockstar> So the etag is kinda like a hash then?
<jtv-night> mrevell: just watched the screencast... Love it!  The only thing missing is that the screen that says "The Next Day" should be while lettering on a scratchy and wobbly black background, bordered in Art Nouveau style, and accompanied by piano music.
<jtv-night> white.  White lettering.
<mrevell> jtv-night: :-D
<mrevell> thanks jtv-night
<jtv-night> :)
<leonardr> rockstar: yes
<leonardr> it's calculated from the current values of all the object's non-read-only fields
<rockstar> james_w, do you have a script I can test?
<leonardr> rockster: he put a really simple on in the bug
<james_w> lp.me.lp_save()
<james_w> or yeah, see the bug
<leonardr> <https://launchpad.net/bugs/415943>
<mup> Bug #415943: lp_save now gives PreconditionFailed if unchanged <Launchpad Foundations:New> <https://launchpad.net/bugs/415943>
<rockstar> james_w, where's the bug?
<leonardr> james_w: you're getting it on lp.me?!?!
<james_w> yeah, I said that 10 minutes ago! :-)
<leonardr> i must have missed it in the confusion
<leonardr> ok, so it's a thoroughly general problem
<leonardr> and since it only shows up in production i think it might have something to do with an intermediary
<leonardr> such as a cache
<leonardr> rockstar: nm, it isn't a problem with branches per se
<rockstar> So I'm off the hook then.
<rockstar> Yay!
<leonardr> james_w: give me a minute to get a branch into review and then i'll pay more attention to this
<james_w> thanks
<salgado> sinzui, how much time should I spend trying to improve https://devpad.canonical.com/~salgado/poll-shots/poll-30.png?
<sinzui> salgado: Did we commit to redesigning that page?
 * sinzui looks
<salgado> sinzui, I hope not.  where is the list of pages that we committed to redesign?
<sinzui> salgado: I would not spend more than 1h cleaning the presentation.
<salgado> ok
<gary_poster> yo barry.  We didn't talk about transferring the wiki stuff that I saw in the reviewers mtg.  that should be a reviewers mtg action item for next week, and we ought to coordinate.  Maybe coordination should just be as simple as pinging the other person whenever we start doing a bit of it, so we don't bump into each other
<leonardr> james_w: i can't duplicate your problem with launchpad.me.lp_save(), either on staging or edge
<james_w> neither can I now :-/
<leonardr> nor with your original load() code
<leonardr> james_w: are you willing to come back to this if/when it recurs?
<leonardr> i think the problem may have been some transient problem with the cache
<james_w> I'll be back, don't worry
<james_w> it's rather unsatisfying though
<leonardr> agreed
<james_w> the last failure I have is slightly before 17:00
<kfogel> danilos: http://paste.ubuntu.com/255805/   :-)
<kfogel> Note the huge block under wgrant's name.
<danilos> kfogel: yeah, looks great :)
<leonardr> james_w: when it happens again we should probably get the losas involved, because a problem with this profile is almost certainly being caused by an intermediary
<leonardr> since the http looks fine
<james_w> something dropping Etag in the response perhaps?
<leonardr> james_w: if something were modifying the ETag on the request before launchpad saw it, launchpad would say "this doesn't match" and give a 412
<leonardr> i know that apache plugins for things like content compression munge the etag on the response (in a way that defeats the purpose of etags)
<james_w> yeah, that's what I meant
<james_w> nothing like what I actually said, granted :-)
<leonardr> but i don't know of anything that would modify it on the request
<james_w> did anyone do anything 20 minutes ago?
<james_w> restart servers, move a cache or anything?
<rockstar> sinzui, I just noticed that question-add.pt is not in the zcml but in the view code.  Is there a reason for this?
<statik> hi! does launchpad have a trademark policy? i'm making a project that stores bug data from launchpad into couchdb, and I was considering calling it "offpad", but I don't want to have any hassle over the name
<statik> short for "offline launchpad"
<rockstar> kfogel, ^^
<leonardr> <mthaddon> leonardr: I updated edge - the auto update failed overnight so we had servers on different versions, was just fixing that
<leonardr> james_w -^
<intellectronica> statik: you should call it lounge-pad
<kfogel> statik: Launchpad is trademarked by Canonical.
<james_w> thanks leonardr, mthaddon
<kfogel> statik: I can ask internally about the "offpad" name if you want; my guess is the legal department would have no choice about enforcing there, but I'm not a lawyer, so can't be sure without asking.
<kfogel> statik: shall I?
<leonardr> james_w: <mthaddon> leonardr: edge was in an inconsistent state - two app servers on one revno and two app servers on another revno
<kfogel> intellectronica: nice :-)
<james_w> leonardr: could that have caused it?
<leonardr> absolutely
<leonardr> the etag incorporates the current revno
<james_w> leonardr: if they were calculating etags from different sets of parameters
<james_w> oh
 * sinzui looks at what rockstar is seeing
<james_w> well, there we go then
<leonardr> if GETs go to rev N and PATCHes go to rev N-1, you'll see exactly the behavior you describe
<rockstar> sinzui, it looks like it's more about using the same view for two templates.
<sinzui> rockstar: yes and SearchQuestionsView does the same I think
<rockstar> sinzui, yeah.  I just found them when I was checking for templates I forgot to port.
<sinzui> rockstar: you really should have been landing these small branches
<rockstar> sinzui, well, I've divided them up into three branches.
<sinzui> you wont conflict with anyone, so it is not a problem I think
<rockstar> (One's in review currently, I'm fixing tests for the 2nd and third one now)
<sinzui> rockstar: is you change the workflow rules to allow the [Add comment] to always display, you will be a hero
<rockstar> sinzui, I will do that in a separate branch, but I think that's how it should be.
<sinzui> rockstar: while the fix to canAddComment() is just a test self.user is not None, I believe test_question_workflow will be angry.
<sinzui> well. I can know the answer to that right now
<rockstar> sinzui, well, of course the test workflow test would fail, since you're changing the workflow.
<rockstar> If it didn't, I would be afraid.
<sinzui> rockstar: it does not! The comment is designed to not influence the workflow. I was certain the test verified it the non-event could not happen until after the bug is solved or invalid
 * sinzui sees he ran only the unittest
 * sinzui boggles and to success
<sinzui> rockstar: I'll subscribe you to the bug and the change I made. I think I am doing something wrong because the tests I expected to fail did not
<rockstar> sinzui, huh.  Okay, I'll make sure that the workflow test actually tests the workflow then.
<statik> kfogel, thanks. I like intellectronicas suggestion of loungepad even better. when you say "would have no choice about enforcing", do you mean that you think the name is too similar, or not similar enough to worry about?
<sinzui> rockstar: they do...comments are meant to outside the workflow. I thought there was verification that the comment button does not appear when the question is OPEN, ANSWERED , or NEEDSINFO.
<kfogel> statik: well, they'll have to determine that.  What I mean is that trademark law is funny in that if you let the name get diluted too much, you lose the trademark by default.
<kfogel> statik: let me ask them; I'll CC you.
<statik> kfogel, thanks!
<rockstar> sinzui, ah, you and I were thinking about different views.  Now I understand.
<rockstar> kfogel, random question: Does that mean "Kleenex" is no longer a trademark, since we use it when we mean "tissue" ?
<kfogel> rockstar: Kleenex polices it as best they can, but it's a constant danger.  Try marketing a product using that name and see how fast you get a phone call :-).
<kfogel> statik: sent
<statik> wikkid
<leonardr> flacoste, grant_w, i've marked bug 415943 invalid with an explanation
<mup> Bug #415943: lp_save now gives PreconditionFailed if unchanged <Launchpad Foundations:Invalid> <https://launchpad.net/bugs/415943>
<intellectronica> statik: is that a funky misspelling of 'wicked', or the past tense of a novel verb meaning 'to edit a wiki page'?
<statik> intellectronica, with me it's always funky misspelling, i don't even know what a tense is
<statik> i'm pretty sure i know what verbs are and i don't like them one bit
<intellectronica> you seem very tense
<statik> it's living in this teepee that does it
<statik> i want to trade it in for a yurt
<rockstar> statik, I want whatever you're on.
<rockstar> (Unless it's the pink pants, then I'd prefer to get my own.)
<barry> sinzui: eta for bug 413158 follow up review?
<mup> Bug #413158: Convert /people page to UI 3.0 <ui> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/413158>
<sinzui> barry: I am sorry. I am still writing emails
<barry> sinzui: no worries
<intellectronica> rockstar: it's a competition. we're trying to see who can fail the turing most elegantly
<intellectronica> the winner gets to be canonical's submission for the next loebner prize
<mrevell> see you tomorrow guys
 * gmb -> dinner, etc. Back later.
<beuno> barry, how's our "projects use launchpad by default" plan going?
<beuno> abentley-lunch, I hate the changes done to reviewing in MPs
<beuno> can we talk at some point about them?
<beuno> I no longer have a "review" button close to the reviewers list
<beuno> and now ahve to scroll down to the bottom of all the comments
<beuno> please lets not do these changes without some broader agreement
<barry> beuno: on hold for 3.1 ui conversions
<beuno> barry, roger, thanks
<beuno> flacoste, I love you for using google calendar
<flacoste> beuno: :-)
<salgado> sinzui, beuno, is there any reason why style-3.0.css defines font-weight:bold for <dt>s only when they're inside a portlet?
<salgado> .portlet dt {
<salgado>     font-weight: bold;
<salgado>     }
<sinzui> salgado: I did not want to presume
<sinzui> salgado: bold might be right for all cases since we expect that by default
<salgado> I used a <dt> in a page and wanted it to be bold as well, but it doesn't get that automatically because it's not inside a class="portlet"
<sinzui> salgado: the same may also be true for <th>
<salgado> indeed
<sinzui> salgado: I think you should make the change. There are very few uses of <dt> out side of 3.0 pages, and we can fix them if we discover an issue
<salgado> sinzui, cool, I'll do that
<beuno> agreed
<barry> beuno: so i'm now using a generic action menu for the top level overview pages.  on /people it makes sense to have an action for +requestmerge.  it probably don't make sense to put that on the /projects page, but... does it hurt?  of course it's more work to selectively remove it, but i can do that if you want
<barry> beuno: similarly for the admin tasks, which make sense on /people but maybe not on /projects.  otoh, maybe these are useful conveniences anyway, and maybe consistency on the top level collections is more important.  thoughts?
<beuno> barry, I don't think we should have people merging on /projects
<beuno> so, keep the relevant links on the relevant pages
<barry> beuno: right, agreed. actually, it should only be a minor refactor, but i'll do that in the /projects branch instead of the one sinzui is reviewing currently
<barry> beuno: thanks
<beuno> cool
 * barry thanks abentley for looms once again
<beuno> intellectronica, how about pasting the number of converted and unconverted templates in the weekly emails?
<salgado> beuno, before: https://devpad.canonical.com/~salgado/poll-shots/poll.png
<salgado> after: https://devpad.canonical.com/~salgado/poll-shots/poll-30.png
<salgado> ui=you? ;)
 * beuno looks
<beuno> salgado, almost
<beuno> it has 2 titles
<salgado> where?
<beuno> and, I don't understand the "Your current vote" and "Vote now" headings
<salgado> wrong screenshots
<beuno> salgado, "a public poll that never closes" and "Vote"
<salgado> damm
<beuno> :)
<salgado> https://devpad.canonical.com/~salgado/poll-shots/index.png
<salgado> https://devpad.canonical.com/~salgado/poll-shots/index-30.png
<salgado> beuno, those (^) are the correct ones
<beuno> salgado, MUCH better
<beuno> no h2?
<beuno> "A public pole.." should be an H2, no?
<beuno> also
<beuno> cahnge details should be in the actions portlets
<beuno> and maybe
<beuno> opens and closes
<salgado> <h2>A public poll that has not opened yet</h2>
<beuno> should be beneath eachother
<beuno> ah
<beuno> I meant H1
<beuno> h2 is the projects' name
<beuno> which is correct
<beuno> there's always an H2 and an H1
<salgado> beuno, do you really think it's worth moving the 'Change details' to a side portlet even if it's going to be alone there and take a good 20% of real estate?
<salgado> the page will never have any side portlets or anything
<beuno> salgado, yes
<beuno> consistency
<salgado> beuno, what should be in the H1?
<beuno> and, we don't need that much space on that page
<beuno> salgado, the H1 is "A public poll that has not opened yet", which I assume is the polls' name
<salgado> right
<salgado> so just turn the existing h2 into an h1?
<beuno> yeap
<beuno> salgado, and, this may be too much design on the conversion
<beuno> but
<beuno> you could isntead of having an "active" column
<beuno> just say "Active" or "Inactive"
<beuno> but that's just for the bonus points  :)
<salgado> right, right, I'll think about that
<salgado> beuno, should the +newoption link be in the side menu as well?
<salgado> or just in the main area?
<beuno> salgado, no, I think that's the right place to put it
<salgado> ok, now I need to find out how to achieve that
<abentley> beuno: You reviewed that as Needs Fixing, I replied, you never responded, eventually I merged it.  https://code.edge.launchpad.net/~abentley/launchpad/comment-as-review/+merge/7685
<beuno> abentley, was the wrong thing to do
<abentley> beuno: I thought you were making non-madatory suggestions.
<beuno> abentley, it says "needs fixing"
<beuno> abentley, please revert
<salgado> beuno, that's not easy to achieve. is it a problem if I leave the +newoption link both in the main area and side menu for now?
<intellectronica> beuno: that's a good idea. i'll do that in next week's report
<abentley> beuno: Needs fixing was intended as the equivalent of BB tweak.
<barry> beuno: how would you like to do a quick review of some screenshots?
<intellectronica> beuno: a while back you mentioned that we may have licenses to use balsamiq. is that still on? what do i need to do to get one?
<beuno> intellectronica, I will forward it to you
<thumper> abentley: actually for the equivalent of BB tweak we tend to use Approve with comments
<intellectronica> beuno: awesome, thanks
<thumper> abentley: need-fixing I consider blocking
<beuno> me too
<abentley> thumper, beuno: Okay, but "resubmit" is meant to be the blocking one.
<thumper> abentley: needs-fixing means that you need to fix it :)
<beuno> barry, sure, hit me, I'll put it on the queue
<barry> beuno: awesome, there's three, should be self evident...
<barry> https://devpad.canonical.com/~barry/projects-anon.png
<barry> https://devpad.canonical.com/~barry/projects-search.png
<barry> https://devpad.canonical.com/~barry/projects-user.png
<barry> beuno: ^^
<abentley> thumper: Well, I suggested calling it "tweak" :-)
<thumper> anyway...
<beuno> abentley, setting aside this issue, which we need to clear up, please revert the cahnge
<beuno> change
<thumper> abentley: what is the issue
<thumper> beuno: what is the issue here
<beuno> thumper, the approach os wrong on the UI
<beuno> for that MP
<beuno> s/os/is
<beuno> and
<beuno> now, to review something you haven't been requested, you need to scroll down in bewtween commetns and the diff
<beuno> *very* hard
<beuno> I don't agree with merging in comments and reviews
<thumper> surely if you are going to review, you are going to read the comments?#
<beuno> they are not the same thing
<beuno> thumper, I am not
<abentley> beuno: That is why, in my mp-tweakage branch, I move the add comment or review button up.
<thumper> beuno: *everyone* else does
<beuno> I don't care about the code, I do UI reviews
<beuno> and
<beuno> I may ahve read them already
<beuno> vie email
<beuno> or last time I was on that page
<beuno> it VERY HARD to find that link
<abentley> beuno: I would like to improve the situation, not go back to status quo.
<beuno> and, review and commenting are separate things
<beuno> abentley, me too
<thumper> beuno: no, they are not
<beuno> thumper, yes they are
<beuno> I've thought about this, discussed this with other people using the system
<beuno> it's consistent
<abentley> beuno: They are not.  Even you've said you don't know whether it's a comment or review until you're partway through.
<beuno> I've discussed with kiko as well
<beuno> reviews and comments are not the same
<beuno> they are not the same anywhere else
<beuno> and
<beuno> this branch makes things worst
<beuno> please revert it
<beuno> commenting is a lightweight well-known operation
<beuno> reviewing is not
<beuno> cramming them together beacuse they make sense to *you* is the wrong thing to do
<beuno> it's why I did not approve the branch
<beuno> and the change, besides that issue, made commetning *and* reviewing harder now
<abentley> beuno: You abandoned that review.
<abentley> beuno: It's not like you disapproved.
<beuno> abentley, yes, at "needs fixing". You should follow up, not merge it.
<beuno> abentley, I will be more blunt in the future then
<thumper> beuno: with due respect, he tried
<abentley> beuno: I did follow it up.
<beuno> you did not address the concerns
<beuno> and landed it
<beuno> only following up on one bit, and landing, is not exactly following up
<abentley> I followed up on the specific issue that you're complaining about now.
<beuno> "I'm glad we've re-introduced reviewing from comments, but I feel that there's no point in removing it from the table. We can have it in both places, leaving the option in the obvious place."
<beuno> I mentioned on IRC
<beuno> that the complaints where not about that
<beuno> "If you don't select a value for "Reviewer says", then it's a comment.  If you select a value, it's a review."
<beuno> how are users suppose to guess that?
<beuno> every other review I've done, as long as the status is "needs fixing", it needs fixing
<abentley> beuno: Well, we could improve the labels.
<abentley> beuno: anyhow, I will revert the change.
<beuno> barry, I wonder if we want all thos info icons
<beuno> barry, also, coloring the "7 bugs reported, 3 have tran.." would rock
<abentley> beuno: At the time, you said "I'm glad we've re-introduced reviewing from comments...".  Now you seem to be saying the opposite.
<beuno> barry, other than that, it looks nice
<beuno> abentley, yes. Not so happy that we loose the (perceived) ability to comment because of it
<beuno> commenting and reviews rock
<beuno> but why do we have to kill commenting because of it?
<abentley> beuno: I don't think we do.
<beuno> right, me neither
<beuno> or, reviewing from where the reviews are
<beuno> so the problem with the branch as that it introduced other orthognal UI changes
<abentley> beuno: They are not orthagonal, they are related.
<beuno> related, but not needed as part of "add comments to reviews"
<beuno> adding comments to reviews:  awesome
<beuno> removing the link from the reviews table, and moving the review link to a hard-to-fine place: bad
<abentley> This branch was about adding the ability to review from a comment.
<beuno> that was what we've been talking about on the MP and on IRC
<beuno> right, inver the awesome phrase
<beuno> it needs more thought on how to do it
<abentley> beuno: I have been trying to put the link in an easy to find place, and the branch is stalled, waiting for your reply, since Aug 4.
<beuno> ok, so you can either prod me on IRC to remind me, or land it
<beuno> I'm upset because I pointed out, especially on IRC that this was a regression, and you picked the latter
<beuno> I'm sorry I stalled on getting back to you
<abentley> beuno: You understand that the branch which is currently stalled is not the one I landed?
<beuno> abentley, I do not
<beuno> the MP I'm looking at is merged
<abentley> beuno: The mp-tweakage branch is the one where I move the link right into the review table: https://code.edge.launchpad.net/~abentley/launchpad/mp-tweakage/+merge/9475
<barry> beuno: yeah, i'm not sure what to do about the info icons.  i think on the whole i like them, otherwise we should also remove the add and edit icons, or it'll look weird
<beuno> barry, well, one is a link, and the other is an action
<beuno> not sure
<barry> beuno: actually, i don't think it will be easy to remove the icons because i'm using "structure view/@@+global-actions" and "structure context/@@+related-pages"
<barry> beuno: so all that rendering "just happens"
<beuno> barry, it's not a super-popular page
<barry> beuno: oh, but maybe i can remove them in the menu code
<beuno> so if it's going to take a lot of time, it's fine
<barry> beuno: let me mock it up and take a screenshot.  if it takes me more than 90 seconds i'll leave it :)
<barry> beuno: as for coloring, i removed the colored numbers from the original template because /people doesn't color its stat numbers.  i'd like for them to be consistent, so... what color would you like them to be?! :)
<beuno> abentley, so you removed the link next to the reviewers table, and that branch, among other things, adds it back in a different form?
<beuno> barry, see https://edge.launchpad.net/bzr/+milestone/2.0
<abentley> beuno: It moves the existing "add comment or review link".  The difference is that it does not have the greyed-out review link for yourself, which was a cause of confusion and complaint.
<beuno> barry, specifically,  0 blueprints  and 27 bugs  targeted
<barry> beuno: ah, app colored
<barry> beuno: i think i can do that
<beuno> barry, cool, other than that, I can smell it landing today
<barry> beuno: it's dependent on the big branch sinzui's reviewing, so that has to land first, but yes!
<barry> beuno: https://devpad.canonical.com/~barry/projects-noicon.png
<beuno> abentley, ok. So, add a link to review/comment back on the reviewers table, and we'll go from there
<barry> beuno: as an aside, the column headings on https://edge.launchpad.net/bzr/+milestone/2.0 is there a policy on the heading text color?  i know bugs are red and code is gray, but what about top level collections?  the one i did for people i just left the default text color
<beuno> barry, registry is black
<barry> beuno: a musician like me can get behind that
<sinzui> Registry is the *new* black
<beuno> hehe
<barry> :-D
<abentley> beuno: Okay.  I'll extract that change from the mp-tweakage branch into a separate branch and post it for review.  Have I understood you correctly?
<barry> beuno: so, icons or no icons?
<beuno> abentley, yes. And will try and work on a mockup for MPs like I did for the branch index, so we can discuss around something easy to change
<beuno> barry, can I see no icons cheaply?
<abentley> beuno: Roger wilco.
<barry> beuno: https://devpad.canonical.com/~barry/projects-noicon.png
<beuno> barry, no icons!
<beuno> and
<beuno> maybe
<beuno> jsut maybe
<beuno> drop the word "View"?
<barry> beuno: mockup on its way...
<barry> beuno: https://devpad.canonical.com/~barry/projects-succinct.png
<beuno> barry, what do you think?
<barry> beuno: i don't like all the whitespace to the right of the words
<barry> beuno: but i think that's hardcoded in the portlet templates
<beuno> barry, whitespace is like air
<barry> beuno: so i'd probably keep either the icons or the View...
<beuno> you need reasonable amounts of it
<beuno> barry, I super like this
<beuno> :)
<barry> beuno: you da man.  we'll go with this then!
<beuno> it's easy to scan
<barry> beuno: only thing i'd change is s/People/Peeeeeeeeeople/  :)
<beuno> barry, I will look the other way if you do  ;)
<beuno> brb
<beuno> fsck needs me
<barry> :-D  thanks beuno
<rockstar> abentley, how do I diff against the lower pipe again?
<rockstar> Er, s/lower/previous/
<abentley> rockstar: bzr diff -r branch::prev
<rockstar> Ah, okay.
<barry> beuno, sinzui you know what would be helpful?  if style-3.0.css had a list of app colors like it does for font-size percentages
<rockstar> barry, fwiw, I agree.  In my personal projects, that's usually the first thing after reset I put in the css file.
<sinzui> barry: If only I knew what those colours were
<sinzui> barry: I am not convinced there is just one colour for each app either
<barry> rockstar: yep!  sinzui dang
<sinzui> barry: To start, someone could record the <h2> colours used in style.css as a comment in style-3.0.css
<barry> sinzui: i think i will steal them from the milestone page to start with and i'll document them in this branch i'm working on
<sinzui> barry: secondly the app is a class of the body so
<sinzui> body.bugs h2, body.bugs th {color: #89abcd;}
<sinzui> barry: the milestone page only shows two colours
<barry> sinzui: it shows blueprints in the blueprint color and bugs in the bugs color
<barry> blueprint color: #3594BB
<barry> or rgb(53,148,187)
<sinzui> barry: yes, I stole them from the h2 declarations in the css
<barry> sinzui: perfect.  cargo cult ftw
<sinzui> keep the rgb() out of the CSS. I think in hex, not that Windows nonsense.
<rockstar> sinzui, https://pastebin.canonical.com/21332/  I didn't change anything here, so I'm not sure why it's failing.
<barry> it's already in the old code, but yes agreed
<rockstar> sinzui, what I'm wondering is "Does this really matter?"  and "Can I change the test?"
<sinzui> rockstar: could this be a merge screw up from changes made to projectgroups that landed last Friday?
<rockstar> sinzui, possibly.  Lemme merge from trunk and find out.
<sinzui> rockstar: Sorry, you cannot. It is not possibly to ask a question in a project (I think that is wrong). The title and the heading should indicate that the user must choose a project from the form....
<sinzui> rockstar: I know
<sinzui> rockstar: you added page_title to the view, but the view is used by two cases, IProject, and IQuestionTarget
<rockstar> sinzui, okay.  Just as long as there's a real constraint.
<sinzui> rockstar: So we have a choice. 'fuhgetaboutit', or add a condition to the property to change the title is IProject.providedBy(self.context)
<rockstar> sinzui, well, the pagetitles.py was using view.pagetitle, so I just renamed it to view.page_title.  I didn't change the implementation.
<sinzui> rockstar: questions often ignored pagetitles. We hated that file.
<rockstar> sinzui, I'll take the former.  I just want to be making mechanical changes here.  I have just a few more tests failing, and there's light at the end of the tunnel.
<rockstar> :)
<rockstar> sinzui, _I_ hate that file. :)
<sinzui> rockstar: many views implement page_heading or something like that that provides alternate titles
 * sinzui looks are view
<sinzui> rockstar: look at ProjectAddQuestionView.pagetitle
<sinzui> rockstar: That method can be renames to page_title to fix the failure
<rockstar> sinzui, ah, thanks.
<rockstar> sinzui, I have seen a few views in registry that might go better in answers.
<rockstar> That view is a good example.
<sinzui> rockstar: Sorry. I always though I would be doing answers. I knew I was going to s/def pagetitle//def page_title/
<rockstar> sinzui, actually, I quite like answers now that I know the various views.
<sinzui> It predates LaunchpadView so it is a bit quirky, but it does teach you a lot about zope formlib
<bac>  sinzui: i'm stuck and need some help.  i'm trying to get an "(i) show all announcements" link on the announcements index page and cannot get it to work.
<bac> sinzui: i've tried creating a Link( ) but cannot get it to format and render.  was looking at the top_contributors link used in product-index.
<sinzui> bac: did you add the link to an ApplicationMenu with the 'overview' facet so that you can do context/menu:overview/show_announcements
<sinzui> bac: paste a diff
<bac> sinzui: i did try that.  recall i want this to be different from the global-actions.  i'm stuck trying to have that set of links in the portlet and this other link in-line
<sinzui> bac: links that are inline are in an ApplicationMenu. I think the menu and the link definition should be the same as product
<bac> sinzui: ok, i think i need to basically make an AnnouncementEditApplicationMenu like AnnouncementEditNavigationMenu
<sinzui> No
<sinzui> That does not sound right
<sinzui> bac I think you want
<sinzui> class AnnoucementOverviewMenu(ApplicationMenu):
<sinzui>     facet = 'overview'
 * sinzui now looks a code because he really does not know what he is typing.
<sinzui> bac: I think ProductOverviewMenu is what you want to copy. It ieven has the announcements link in it
<sinzui> Oh!
<sinzui> bac: we can cheat
<rockstar> abentley, can I stick a pipe between two pipes?  I have two existing pipes that I'd like to stick a pipe between and hack on.
<abentley> rockstar: Absolutely.  bzr add-pipe --before $SECOND or bzr add-pipe --after $FIRST
<rockstar> abentley, this plugin is a godsend.
<abentley> rockstar: glad you like it.
<rockstar> But not a Cthulusend.  He probably wouldn't send us something so nice.  :)
<thumper> flacoste: if you can do the call earlier, I may be able to fill and hour :)
<flacoste> thumper: ok, i'll let you know as soon as i hung up the phone
<thumper> flacoste: don't suppose you are free yet
 * rockstar goes on a short walk
<flacoste> thumper: i am now
<barry> holy crap.  pqm is 9 deep.  yay for week 3!  but wait, we're not rolling out 2.2.8, so i guess people are having fun with ui
<wgrant> gmb: I see it landed. Thanks again!
<jamone> I'm trying to set up a launchpad server on Ubuntu 9.04, while following the official WIKI's guides I try to use bzr to get rocketfuel-setup and it fails. It appears the WIKI's address to the rocketfuel-setup script is wrong
<jamone> I manually browsed the src online and got rocketfuel-setup and it ran, but when it came time for it to download the rest of launchpad it failed also
<jamone> it gave this: Making local branch of Launchpad trunk, this may take a while...
<jamone> Got a 200 response when asking for multiple ranges, does your server at bazaar.launchpad.net:80 support range requests?
<jamone> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/1d0252d21c3632af79515b5e8c497c15.pack is redirected to https://launchpad.net
<jamone> ERROR: Unable to create local copy of Rocketfuel trunk
<wgrant> jamone: I'd just try again. It's possible that the branch changed significantly on the server while you were downloading it.
<barry> thumper, jml, abentley let's meet today, in 45m
<abentley> barry: I already attended a reviewer meeting today, and I have plans for this evening.
<barry> abentley: coolio
<abentley> barry: perhaps you meant rockstar?  (I'm the one who plays flute :-P)
<jamone> I can try running the rocketfuel-setup script again, but I had the same issue when trying to get the rocketfuel-setup script the way the wiki said, and I tried that a bunch
<jamone> Ok I just reran rocketfuel-setup and got this make: *** No rule to make target `install'.  Stop.
<jamone> ERROR: Unable to install apache config appropriately
<wgrant> spm: Ping?
<spm> wgrant: heyo
<wgrant> spm: I need a branch made private, apparently.
<rockstar> barry, I don't think we'll have jml today.
<barry> rockstar: cool
<rockstar> thumper, standup?
<thumper> rockstar: yes, just finishing with flacoste
<barry> rockstar: -> #launchpad-meeting
<beuno> thumper, I'm off to the supermarket. If I get back before my gf, maybe we can have a call?
<thumper> beuno: when do you think you'll be back?
<beuno> thumper, 30-40 minutes
<thumper> beuno: ok
<beuno> thumper, unless you want to call me on my mobile
<thumper> beuno: no
<beuno> I'm off, but do so if you'd like, number is in the directory
<beuno> aight
<thumper> sinzui: how do I create a sprint?
<thumper> sinzui: nm
<thumper> oh clucking bell!!!
#launchpad-dev 2009-08-20
<cprov-afk> wgrant: your doctests are good, but I wonder if it would be nicer if we could extract the code that locates the key file and unittest it.
<wgrant> cprov-afk: A good idea.
 * wgrant works out how to add unittests.
<cprov-afk> wgrant: there is on slip when the key file is found via glob, its content is not escaped.
<cprov-afk> wgrant: we could have a locate_key(root, term) function
<wgrant> cprov-afk: Well, it's no worse than before. But I suppose it should be improved.
<wgrant> Oh.
<wgrant> oops.
<wgrant> I misunderstood.
<wgrant> You're right.
<cprov-afk> wgrant: np, it's our chance to make zeca a nicer app
<thumper> spm: why is pqm stopped?
<thumper> btw, edge is unusable on IE
<spm> thumper: actually atm it's not. there's a sourcecode run going  thru. *then* it'll be stopped for try 174 of bac's megamerge
<spm> thumper: is that a value judgement against IE?
<spm> yay. naturally as soon as I type I waiting for PQM; it finishes. woot.
<thumper> spm: I don't suppose you could let the queue through before the cp?
<spm> thumper: I was just thinking I might do that anyway tbh.
<thumper> spm: that'd be great!
<thumper> spm: given the 13! waiting branches
<spm> thumper: aye!
 * thumper goes to put the roast chicken in the oven
<spm> thumper: actually it's not a CP, is a manual merge; so the "rules" are a bit more lax in that regard.
<noodles775> Hi sinzui - I just saw your comment on thumper's branch re 'branding vs watermark'. I'll update my renaming branch to do 'branding-apps-portlet' -> 'watermark-apps-portlet' ?
<sinzui> noodles775: thanks.I think that is best though not clear to everyone
<noodles775> OK, will do.
<sinzui> noodles775: Are you an insomniac?
<noodles775> sinzui: heh, nope - just got up but wanted to check with you before you go to bed ;)
<sinzui> I should have been in bed an hour ago.
<wgrant> gary_poster: Why is the new buildbot still invisible?
<gary_poster> wgrant: (I'm not really here  ;-) ) The real reason: that's the way it was set up before.  The reason that it might stay that way for a little bit: we're behind the times on the buildbot debs, and there have been some XSS problems that we need to catch up on.
<wgrant> gary_poster: I see, thanks.
<gary_poster> np
<adeuring> good morning
<thumper>     - Created 0 seconds ago
<thumper>     ?         ^       -
<thumper>     + Created 1 second ago
<thumper> lib/lp/soyuz/tests/../stories/ppa/xx-copy-packages.txt
<thumper> failing on db_devel builder
<thumper> please don't put time in tests like this
<thumper> elide it out
<thumper> please!
<noodles775> thumper: I just had the same failure on ec2test and so fixed it with my landing.
<thumper> noodles775: thanks
<thumper> noodles775: may have to manually get it into db-devel though
<noodles775> so it's included in devel 9171.
<thumper> noodles775: where did your branch land?
<mrevell> Morning
<noodles775> thumper: so my r9171 with the fix for that spurious time-dependent test failure missed build 23. Do you want me to submit a patch directly to db_devel (as it could be quite a while before the patch goes from stable->db_devel?)
<thumper> noodles775: I think the best solution is to wait until is passes on the lp builder, then create a branch of db-devel, merge in stable, and submit that as a testfix
<noodles775> Morning mrevell - when you get a chance, could you do the normal mailing list moderations?
<mrevell> noodles775: sure thing :)
<wgrant> Some of the production Processor titles suck.
<wgrant> "artigas (sparc) builds The SPARC architecture binaries"
<deryck> Good morning, all.
 * wgrant loves Windmill. Tested JS is so much better.
<gmb> wgrant: I love tested JS (The YUI unittest framework isn't bad, actually). But I don't think that Windmill has got it right, yet. Far too fragile.
<deryck> wow, did someone just use the words love and Windmill together?
<gmb> deryck: I was trying to find a diplomatic way of backing away slowly, to be honest with you.
<deryck> heh
<wgrant> gmb, deryck: Well... it makes everything nicer than when you have to do manual testing.
<gmb> This is true. Up to a point, anyway.
<gmb> wgrant: Actually, to be fair, once I'd learned to bump all the timeouts up by an order of magnitude whenver I ran the tests on my desktop machine, it wasn't all that bad.
<gmb> But it's annoyingly time-consuming.
<deryck> I have made peace with Windmill and appreciate it when it goes well.  I might hold hands with her, but I ain't in love yet.
<deryck> :0
<deryck> :) rather
<gmb> 0.o
<gmb> Can anyone think of a good reason why I shouldn't use datetime.astimezone() when converting a non-UTC timezone to UTC? ISTR there being a reason not to do it (and other code that I've written actively avoids using it), but I can't remember what that reason is.
<stub> gmb: I think that is fine. I've got an example of that in the pytz documentation at http://pytz.sourceforge.net/
<gmb> stub: Awesome, thanks.
<gmb> Perhaps I just didn't know about astimezone() when I wrote the old code.
<BjornT> gmb: what does the old code look like?
<gmb> BjornT: Well, I'm just looking at it, and it's basically this:
<gmb> utc_datetime = other_tz_datetime - timedelta(seconds=utc_offset)
<gmb> BjornT: Even though I have a timezone name available.
<gmb> And it's in the TestBugzillaXMLRPCTransport rather than actual production code, so I wonder if it wasn't just a quick-and-dirty hack on my part.
<BjornT> gmb: do you have a unique timezone name?
<gmb> BjornT: What do you mean by unique? I have the short form of the name available (e.g 'EST', 'CET', 'UTC'). I wonder if that's why I'm not quite happy about doing it this way - I can't guarantee that the tz name will actually make sense to pytz.
<wgrant> Those aren't at all unique.
<BjornT> gmb: for example EST is used both in the US and Australia
<gmb> wgrant, BjornT: Right, yes. Hmm. The long form of the name is also available...
<wgrant> That should be unique. But not necessarily lookable up.
<gmb> Right.
<wgrant> (see the recent rename which kept crashing the wikis until they got a newer pytz)
<gmb> BjornT: Do you ahve time for a brief call about this? There's a related issue that's bothering me and I'm not sure what's the best way to deal with it.
<BjornT> gmb: but the plugin doesn't guarantee that the timezone name will be unique, so better not to rely on it, not even in tests
<gmb> BjornT: Right.
<BjornT> gmb: sure, we could have a call
<gmb> BjornT: Cool. Skype?
<BjornT> yeah
<gmb> BjornT: Calling you now.
<bac> can i submit to pqm with [ui=sinzui]?
<bac> i mean, has the regex been expanded to accept non-beuno ui reviewers?
<bac> hmm, looking at recent landings it doesn't look so...
<intellectronica> bac: i think not. we should arrange that, actually
<bac> intellectronica: yeah, that would be good.  for now i'll use ui=rs
<intellectronica> bac: a workaround is to land with ui=rs and the mention the real reviewer later in the message, but let's talk to the losas when we can and change that
<bac> great minds...
<intellectronica> leonardr: the bug you just edited - do you have any ideas what it might be? also, do you really think it's a bug in lplib (rather than the webservice itself)?
<leonardr> intellectronica: see my follow-up comment
<leonardr> i think it's a guy who told launchpad to hide data from launchpadlib and forgot that's what he did
<intellectronica> leonardr: right, yes, that makes sense. i couldn't reproduce it but haven't thought about that option
<cprov> morning, launchpadders!
<beuno> hiya cprov
<maxb> Hi, does anyone have any idea what launchpad uses python-lxml for?
<maxb> (wondering whether it could be dropped from launchpad-dependencies)
<beuno> maxb, grep the source and find out  :)
<wgrant> All I could find when I grepped last week was lazr.restfulsomething
<maxb> There's one mention in a docstring in ./lib/canonical/launchpad/scripts/hwdbsubmissions.py which is clearly lying
<beuno> maxb, sounds like a patch to me
<beuno> ;)
<wgrant> One of lazr.restful's tests uses it, but that's it.
 * gmb -> lunch
<wgrant> allenap: Some of those failures were being fixed by intellectronica.
<wgrant> Not sure if that's all of them, though.
<beuno> intellectronica, are you playing with balsamiq for the bug index?
<allenap> wgrant: Okay, cool.
<intellectronica> beuno: yeah, i'm just trying to finish a mockup for the bugs index
<beuno> intellectronica, awesomeness, looking forward to it
<beuno> how do you like the software?
<allenap> intellectronica: If you're fixing any of failures that wgrant mentions <http://paste.ubuntu.com/256336/>, can you point me to a branch that I can merge to see what remains to fix?
<intellectronica> allenap, wgrant: what failures?
<wgrant> allenap: I'm rerunning those tests with devel merged.
 * intellectronica looking
<allenap> intellectronica: See the paste; it has an ec2test summary log.
<intellectronica> allenap, wgrant: xx-also-affects-distribution-default-values.txt  is the only one i've fixed. the others, i guess, are a result of the new security changes?
<intellectronica> beuno: it's really really good. especially for someone like myself who couldn't draw if my life depended on it
<wgrant> intellectronica: Looks like it. Most of the rest seem to cascade from Milestone not being found.
<allenap> intellectronica: Thanks Tom :)
 * wgrant reruns those tests.
<sinzui> bac: I think noodles775, rockstar, or beuno should have a look too.
<noodles775> allenap: could you take a look at this bugs question (about dup emails): https://answers.edge.launchpad.net/launchpad/+question/80508
<allenap> noodles775: Sure.
<noodles775> sinzui: what's the branch/mp? (I can't see anything of bac's in +activereviews)
<noodles775> (nor does my chat history find anything :/ ).
<sinzui> noodles775: https://code.edge.launchpad.net/~bac/launchpad/lp3-announcements/+merge/10275
<sinzui> ^ My mistake, I approve the whole MP last night.
<noodles775> Np - it's already merged according to the status :)
<allenap> intellectronica: Can you help me out with https://answers.edge.launchpad.net/launchpad/+question/80508? I am baffled by how LP chooses who to send mail to :-/
 * wgrant declares BugTaskEditView to be one of the world's great evils.
<intellectronica> allenap: sounds like either a bug or the user is confused by something. you shouldn't receive the email twice
<wgrant> intellectronica, allenap: The team has a mailing list.
<wgrant> Nothing LP can do.
<intellectronica> ah of course
<allenap> wgrant: Ah, because the bug mail machinery can't or doesn't take into account subscriptions to mailing lists?
<intellectronica> but that's not quite the same as him receiving the email twice
<wgrant> intellectronica: It is if you don't do filtering.
<intellectronica> allenap: because it doesn't know who's on the mailing list
<wgrant> allenap: Can't, doesn't, or shouldn't. I think the last.
<allenap> wgrant: Yes, thinking about it, I agree.
<bac> sinzui: ^^ are you referring to my announcement change?  you want them to do a UI review?  they can, but it's already through PQM.
<wgrant> allenap: I think BugTaskEditView has got the better of me.
<sinzui> bac: That is fine. I need it landed to complete distro. I am not a full UI reviewer so someone else should also take a lot
<sinzui> look
<bac> sinzui: ok, i'll arrange it today.  my fault for assuming you were.
<allenap> wgrant: Heh :) I'll have a look.
<wgrant> allenap: It will not make that field editable :(
<allenap> wgrant: Odd. I'm just going to answer the mailing list question then I'll have a go.
<wgrant> allenap: Thanks.
<cprov> wgrant: hi there, re. your changes on zeca almost done, few tweaks and we can land it. Thanks for working on it.
<wgrant> cprov: Hrm, so the test methods should contain the function name even though the function is mentioned in the class name?
<cprov> wgrant: yes, let me find the corresponding guideline reference.
<cprov> wgrant: https://dev.launchpad.net/TestsStyleGuide#Python%20Test%20Cases -> 'testing alternatives for a LP method'
<wgrant> cprov: Thanks.
<sinzui> barry: EdwinGrubbs, bac, salgado: Update your bugs. please
<bac> sinzui: i prefer to wait until i know if i have to have another pass after the UI review.
<sinzui> bac: okay
<barry> sinzui: nothing to update yet (go pqm, go!)
<wgrant> cprov: Fixed, pushed, replied. Thanks.
<cprov> wgrant: no, thank you. Do you want me to land it for you ?
<wgrant> cprov: Please do.
<sinzui> salgado:  look at this list and updat any bugs you fixed or may have change: https://bugs.edge.launchpad.net/launchpad-registry/+bugs?field.searchtext=polls&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMIT
<salgado> sinzui, UnexpectedFormData: Unexpected value for field 'status'. Perhaps your bookmarks are out of date or you changed the URL by hand?<br />
 * salgado appends TTED to the end of the URL and it works
<salgado> sinzui, ^
<sinzui> crack
<sinzui> salgado: https://bugs.edge.launchpad.net/launchpad-registry and search for polls
<sinzui> salgado: I think you may have fixed bug 335516
<ubot3`> Malone bug 335516 in launchpad-registry "Team polls page has no main heading and misuses "recent"" [Low,Triaged] https://launchpad.net/bugs/335516
<salgado> sinzui, I didn't; I only touched pages where the context was IPoll[Option], so ITeam's +polls was left untouched
<sinzui> salgado: you just found you next page to fix
<salgado> :)
<sinzui> salgado: bac and barry observed that collections are context objects so I assume you will need to pass a <h1> to the heading-slot
<salgado> sinzui, I'm not following you
<wgrant> allenap: Any ideas on BugTaskEditView? It has me confused.
<allenap> wgrant: Me too, but I'll persevere. It's not going to beat me today :)
<allenap> wgrant: The milestone widget appears on the main bug page, but not on the +editstatus page (logged in as test@canonical.com). Weird.
<wgrant> allenap: It beat me yesterday, so I'm going to bed... good luck!
<allenap> wgrant: Cool, hopefully I'll have something for you when you're back on.
<sinzui> salgado: I think the default context-heading will be wrong because polls is affectively the +index for IPollSet.
<wgrant> allenap: Thanks.
<salgado> sinzui, oh, right, the +polls page is on IPollSubset, IIRC
 * salgado checks
<sinzui> salgado: so if you think the heading is wrong, then pass the <h1> to the heading-slot, and it fixes bug 335516
<ubot3`> Malone bug 335516 in launchpad-registry "Team polls page has no main heading and misuses "recent"" [Low,Triaged] https://launchpad.net/bugs/335516
<matsubara> stub, herb, flacoste, rockstar, cprov, Ursinha, danilos, sinzui, intellectronica: meeting in #launchpad-meeting in 13 min
<danilos> matsubara: thanks
<cprov> matsubara: thx
<intellectronica> matsubara: thanks for the reminder
<salgado> sinzui, right, I've just fixed that.  should I spend some time redesigning this page or should I do just the mechanical changes plus fixing obvious mistakes?
<herb> Chex, mbarnett, mthaddon: meeting in #launchpad-meeting in 4 min ^^^^
<mthaddon> thx herb
<sinzui> salgado: no redesign. convert to 3.0, fix anything that is easy.  I would limit myself to 1h of UI changes
<flacoste> matsubara: gary_poster will now be standing in that meeting for foundations
<matsubara> flacoste, right. I'll update MeetingAgenda. thanks
<barry> EdwinGrubbs: ping
<EdwinGrubbs> barry: pong
<barry> EdwinGrubbs: hi.  re: label and page_title.  are you sure about this?  page_title seems to work, but not label
<barry> hmm...
<sinzui> barry: can you follow up on bug 403606
<ubot3`> Malone bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<mup> Bug #403606: ExpatError errors should be handled to not generate the OOPSes <oops> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/403606>
<mup> Bug #403606: ExpatError errors should be handled to not generate the OOPSes <oops> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/403606>
<mup> Bug #403606: ExpatError errors should be handled to not generate the OOPSes <oops> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/403606>
<barry> sinzui: sure
<Ursinha> thanks barry :)
<EdwinGrubbs> barry: label only works if you remove fill-slot="heading" from your template.
<barry> EdwinGrubbs: i did remove that, and added label='People and teams' but it doesn't pick that up
<barry> EdwinGrubbs: it's getting the label apparently from the content object
<barry> EdwinGrubbs: and the Conversion page shows the fill-slot="heading" in there
<EdwinGrubbs> barry: for which view is it not working?
<barry> PersonSearchView
<barry> people-index.pt
<barry> EdwinGrubbs: if you want, i can push the changes
<EdwinGrubbs> sinzui: I thought the view/label was included by the base layout templates, but I can't find where it gets included.
<sinzui> EdwinGrubbs: no. It is optional for LaunchapdFormView
<sinzui> EdwinGrubbs: form-macros converts the label to a <h1>
<sinzui> EdwinGrubbs: So I think the page you are working on does not use form-macros
<EdwinGrubbs> barry: ok, ^^^^ clears it up. The LaunchpadFormView also has a "heading" slot, but since you are not using a form, the label isn't used.
<sinzui> EdwinGrubbs: you can manually call it to place it as the first element in the main slot
<barry> EdwinGrubbs: sorry, i'm back now
<barry> EdwinGrubbs: so i'm inclined to leave the heading slot in there, unless i can figure out why this isn't working
<salgado> sinzui, beuno, shouldn't <h2>s have some margin-top to make some space between them and what comes above, just like the space between them and what comes below them.
<sinzui> salgado: My instinct says yes, but I suspect they do not because we assume they are the first item in a portlet that sets a margin or padding.
<salgado> sinzui, we have a rule to clear the margin when the h2 is in a portlet
<sinzui> hmm
<sinzui> I think they should be adjusted to look good, but I would ask beuno's opinion of the change
<beuno> ah
<beuno> then yes
<beuno> good call salgado
<salgado> beuno, should it be the same value used for margin-bottom (0.3em)?
<beuno> salgado, yes
<salgado> cool, /me changes it
<beuno> thanks salgado
<beuno> salgado, has the new breadcrumb layout landed yet?
<salgado> beuno, layout?  we didn't talk about layout
<beuno> salgado, UI
<salgado> beuno, we have the vhost-specific breadcrumbs for the 'bugs' vhost and the ones for 'blueprints' and 'answers' should land today.  that will get us very close to the breadcrumbs we have on https://wiki.canonical.com/Launchpad/UI/Navigation
<barry> EdwinGrubbs: sigh.  i don't know if you've been responding.  irc is teh suck
<barry> leonardr: yes, i will work on that lazr.restful branch
<barry> sinzui: what do you know about fill-slot="heading" ?
<leonardr> barry, great
<sinzui> barry: everything
<salgado> beuno, but we didn't talk about the presentation of breadcrumbs. I thought noodles775 was in charge of that, but I don't remember where I get that idea from
<sinzui> it should be named context-heading. It is not the page heading/title unless we are making the index of an content object or collection
<sinzui> ^ barry
<EdwinGrubbs> barry: I'm pulling your branch again, just to make sure I'm not telling you something wrong.
<beuno> salgado, ah, maybe. noodles775, was that on your plate?
<barry> sinzui: the UI/Conversion page says to use fill-slot="heading"
<sinzui> barry: what object are you working with?
<EdwinGrubbs> barry: where is PersonSearchView.
<barry> EdwinGrubbs: lib/lp/registry/browser/person.py
<sinzui> barry: I think is you read more carefully it qualifies that the to +index of a content object, which most pages are nto
<barry> sinzui: this is for /person and /project
<EdwinGrubbs> barry: is that a new part of your branch that isn't pushed up? I only see PersonSearchQuestionsView
<sinzui> barry: override the slot. for the +index
<barry> EdwinGrubbs: let me push an update
<sinzui> barry: if there are alternates, (like /projectgroup/+all) then you place a <h1> in main. So that  the context-heading is "Project Groups" and the page <h1> and title is something like Browse all project groups.
<barry> EdwinGrubbs: r9161 lp:~barry/launchpad/415542-projects
<barry> sinzui: so wait, you're saying for the object's +index page, you do have to put the label in the template explicitly?
<EdwinGrubbs> barry: I still don't see a PersonSearchView.
<barry> EdwinGrubbs: sorry.  it should be PeopleSearchView
<EdwinGrubbs> barry: yes, you will need to fill in the heading slot yourself, since PeopleSearchView is not a LaunchpadFormView and probably wouldn't work well as one.
<barry> EdwinGrubbs: agreed.  question though, is this something we should push into LaunchpadView?  not that i'm suggesting doing that right now :)
<rockstar> sinzui, it has become apparent that I have no idea what I'm doing with menus.  Tell me again why I can't use the menus already created?
<sinzui> rockstar: Answers never got NavigationMenus
<EdwinGrubbs> barry: I don't think it would hurt, but it probably wouldn't be as beneficial, since non-edit pages are more likely to use several templates with the same view class, which means you couldn't specify a distinct label in the view.
<rockstar> sinzui, okay.  So maybe I need to figure out what the difference is between NavigationMenus and ApplicationMenus
<sinzui> rockstar: It has ApplicationMenus (context/menu:facet/link_name)
<sinzui> rockstar: We want to remove all ContextMenus
<barry> EdwinGrubbs: you might be right.  anyway, i'm not going to worry about it and it's good to know i'm not going crazy.  also, moving page_titles is a good thing
<rockstar> sinzui, and how do I identify ContextMenus?
<sinzui> rockstar: We are using ApplicationMenu's for inline links. I think this is a waste
<barry> EdwinGrubbs: i'll respond to your review in a few minutes.  thanks
<sinzui> rockstar: because the links are often in NavMenus. In many cases I moved the AppMenu links to a mixin, then let the AppMenu and NavMenus define the facet and the links
<sinzui> rockstar: class AMenu(ContextMenu) <- they are used by the menubox view and template
<rockstar> sinzui, what do you mean by "menubox view and template" ?
<rockstar> There seems to be a vocabulary you're using that I'm not familiar with.
<sinzui> rockstar: If you do not know about them, then it is clear we do not need them. The menubox draws the combined application and context menu in the 0 and 1 designs
<rockstar> sinzui, okay.  So I'm not even going to worry about ApplicationMenus at all, because it seems there's no point.
<sinzui> rockstar: 2.0 switched to NavMenus and AppMenus. I have serious doubts about their overlap
<sinzui> rockstar: did you move any links inline? Wasn't answers crafting links without using a menu?
<rockstar> sinzui, it seems like it.  That's a big concern of mine.
<rockstar> sinzui, I have not moved any links inline.  I haven't yet found a case where I need to.
<sinzui> rockstar: I know answers did because when I added the FAQ portlet, it failed because the link from the page was trying to go to a context object that did not support the link. The menu will faile if you make a link to an unregistered view
 * sinzui cursed answers at that point
<rockstar> sinzui, yeah, so the FAQCollection stuff is what I'm working on now.
<rockstar> sinzui, for instance, see https://answers.edge.launchpad.net/launchpad/+faqs
<sinzui> this outlines the expected way the menus will work: https://dev.launchpad.net/VersionThreeDotO/UI/Conversion#Adding%20a%20NavigationMenu
<rockstar> sinzui, yeah, I'm reading that, and I think I'm confusing myself.
<sinzui> rockstar: to get to this form., create a FAQLinksMixin and move the appmenu links into it. The appmenu just needs a facet and a list of links
<rockstar> sinzui, yeah, that's what I was doing.  I'm wondering why we need the marker interface and all that.  It seems like overkill.
<sinzui> rockstar: You may be special
<sinzui> rockstar: well faq and answers may be special. I am sure you did not ride the short bus
<rockstar> sinzui, well, the short bus was for gifted children here (because there were less of them) but I still just walked to school.
<sinzui> rockstar: To change a context object you can define a menu that will always be present on content object (IFAQCollection, IFAQ, IAnswersCollection, IQuestion) so you no not need a marker interface
<rockstar> sinzui, yeah, I think that's what I need.
<sinzui> rockstar: the marker interface is only need to tie a menu to 1 or more views.
<rockstar> Because it's always the same.  When I discovered the FAQ views (I didn't know about them before yesterday) I thought they used separate views, but they don't.
<sinzui> https://answers.edge.launchpad.net/launchpad/+faqs
<sinzui> ^ The show... links are view based, th creation/modifcatiobn links are context-based
<sinzui> rockstar: so we want to move all the show links in line. If we cannot we create a navmenu on the view. I think this page has links we need to toss.
<sinzui> rockstar: (+) create a FAQ and (+) Set answer context belong in the action menu (a nav menu on the object)
<sinzui> rockstar: I do not know where we put (+) Ask a question, maybe inline maybe in the menu
<rockstar> sinzui, well, I think we need a large button for "Ask a question" like we have "Register a branch"
<sinzui> rockstar: There are no large buttons in 3.0
<rockstar> Yes, I know this, but I don't like it.
<sinzui> There is an involvement portlet that provides that, but is also blurs out intent so I do not think it should be used
<rockstar> sinzui, yeah.  So much for "only mechanical changes" in answers...  :)
<sinzui> The other links (I) Open questions, (i) Answered questions, (i) My questions, (i) Need attention questions  either go inline or we create a nav menu with a marker interface to add these to the bottom of every page so users can find the related pages.
<sinzui> menus are mechanical
<rockstar> sinzui, so, for the show (Open|Answered|Mine|Need Attention) - How should they be put inline?
<sinzui> rockstar: when you put the required icons on the links, it becomes easy to see which are actions and which as views
<rockstar> sinzui, could we have maybe a mid-implementation call then?
<sinzui> We know these links will be appears on most of the lists and _index pages in answers, so I think we want a navmenu attached to the view and we use view/@@+related-pages as the last portlet in main
<sinzui> sure
<sinzui> rockstar: I am ready
<mrevell> okay guys, I'm off for the day
<sinzui> https://answers.edge.launchpad.net/launchpad/+question/80521
<sinzui> rockstar: https://edge.launchpad.net/bzr
<sinzui> rochttps://answers.edge.launchpad.net/launchpad-registry/+question/77453
<sinzui> rockstar: https://answers.edge.launchpad.net/launchpad-registry/+question/77453
<matsubara> rockstar, thank you!
<rockstar> matsubara, no, thank you, and welcome to open source contributions.  :)
<matsubara> :-)
<beuno> sinzui, font is a tad big, no?
<beuno> https://edge.launchpad.net/ubuntu/+search?text=gnome-do
<sinzui> tad? wtf? That is huge
<beuno> :)
<sinzui> beuno: I think this is a byproduct of CSS changes. I did not look like that when I landed it...it had to be the same size as the 2.0. I think this is 50% larger
<sinzui> !!
<beuno> sinzui, joey noticed it
<sinzui> beuno: The classes uses summary, which is intended for 1 per page. We are using the summary for listing so we need a rule to set the selector context right
<barry> flacoste: i think i got disconnected from our pvt chat
<barry> beuno, sinzui is there any good reason why project group searching shouldn't look very similar to project searching?
<flacoste> barry: you did
<beuno> barry, none
<barry> beuno: i was hoping you'd say that :)
<barry> beuno: i might have some screen shots for you soon
<beuno> barry, I aim to please
<sinzui> barry: make it look the same. Please. It is "broken" in that I think it prefers to search for products not projects. look at how the view does the search
 * sinzui thinks it is using unwanted params too
<barry> sinzui: i'm not so sure.  i think it is searching project groups.  if you search on /projects for 'test' you get 4 projects, but if you search on /projectgroup for 'test' you get only the apache project group
<sinzui> barry: look at bug 60055 and bug 390922
<mup> Bug #60055: IProductSet.search() and IProjectSet.search() have unused untested optional arguments <registry> <ui> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/60055>
<mup> Bug #390922: lp.project_groups.search doesn't return a result for exact matches <Launchpad Registry:Triaged> <https://launchpad.net/bugs/390922>
<ubot3`> Malone bug 60055 in launchpad-registry "IProductSet.search() and IProjectSet.search() have unused untested optional arguments" [Low,Triaged] https://launchpad.net/bugs/60055
<ubot3`> Malone bug 390922 in launchpad-registry "lp.project_groups.search doesn't return a result for exact matches" [Low,Triaged] https://launchpad.net/bugs/390922
<mup> Bug #60055: IProductSet.search() and IProjectSet.search() have unused untested optional arguments <registry> <ui> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/60055>
<mup> Bug #60055: IProductSet.search() and IProjectSet.search() have unused untested optional arguments <registry> <ui> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/60055>
<mup> Bug #390922: lp.project_groups.search doesn't return a result for exact matches <Launchpad Registry:Triaged> <https://launchpad.net/bugs/390922>
<mup> Bug #390922: lp.project_groups.search doesn't return a result for exact matches <Launchpad Registry:Triaged> <https://launchpad.net/bugs/390922>
<barry> sinzui: it's a bit of a mission creep to address those while doing the 3.0 conversion.
<sinzui> We did commit to add functionality to features we committed to redesign, That is why it is not mechanical
<sinzui> barry: allI am asking is that you consider fixing them if they can be done in less that 2 hours
<barry> sinzui: cool, that's what i was looking for :)
<sinzui> barry: consider the pages were did not commit to redesign like answers. rockstar still needs to talk about the layout because the pages have sidebar content that has to move into the main area. He is doing layout work.
<sinzui> We we commit to redesign a page, we are really asking what features to users need this to do for this to be effective, and how do we design that.
<rockstar> barry, I'm learning that sometimes we end up doing things we didn't sign up for.  abentley and bzr-pipelines to the rescue!  :)
<barry> sinzui, rockstar sure.  but given how many pages need to be redesigned, this doesn't seem like a high priority right now
<barry> sinzui: as we discussed, i think we do the mechanicals we can take care of quickly and then come back around and do deeper redesigns/fixes
<rockstar> barry, I don't know what you're working on, but what I'm working on blurs the line between "mechanical changes" and "redesign" to the point of there being no line.
<sinzui> barry: yes
<barry> rockstar: i sometimes stray too, but have to be careful!
<sinzui> rockstar: you are not asking what features does the user require of this page? That is true redesign
<barry> rockstar: btw, working on top level collections /projects /projectgroups /people /distros /sprints
<barry> (2/5 done)
<rockstar> sinzui, yeah, I guess you're right, but when I think redesign, I think CSS and markup and all that jazz, which is where I'm about to head (hopefully)
<sinzui> I have had to change the markup on most pages I have changed. We do not used the excessive table and div markup used in 2.0-
<beuno> intellectronica, working on the edit icon problem. Will send you something to look at within the next 30-40 minutes
<sinzui> My only happy moments are when the changes are so extreme I can throw it all away and use generic-edit.py
<intellectronica> beuno: that's excellent, thanks!
<rockstar> sinzui, yes.  I've eliminated many templates that way.
<sinzui> rockstar: I did not mention that when I needed narrative about the page, I moved the 1.0 help section into the top-portlet
<rockstar> sinzui, I don't think I need to do that.
<EdwinGrubbs> sinzui: I'm at the point where I only have four items to do to the team index page, but they are nontrivial. They are the info from karmacache, moving the contact this team link to sidebar, listing members with timezone, and fixing the recently approved query.
<sinzui> EdwinGrubbs: You have found a good stopping point
<EdwinGrubbs> sinzui: I was also wondering if you had any idea why the google map stopped working. It looks like it falls back on some stubs that don't do anything but prevent errors.
<sinzui> EdwinGrubbs: I too hit the karmacache problem I will not fix it for 3.0
<sinzui> EdwinGrubbs: I am not aware that the map stopped working. The page view registers that is needs the small map if the user has not deactivated it
<EdwinGrubbs> sinzui: I must have broke it. It is disabled since this function is set to always return false:     gBrowserIsCompatible = mapping.RETURN_FALSE;
 * rockstar goes to lunch
<EdwinGrubbs> sinzui: there's nobody oncall right now. Could you review it?
<beuno> intellectronica, http://people.canonical.com/~beuno/400997.html
<sinzui> EdwinGrubbs: I would have thought the contact this team link would be easy to move the to sidebar. I am happy for that to be done later. I can do it when I do contact this person
<EdwinGrubbs> sinzui: it's just that it is currently in a view and not in a menu. It shouldn't be too hard, but I'm not exactly sure how hard.
<sinzui> EdwinGrubbs: As I said. you are at a good point to start landing. You really do not want a branch open for more than two days. We can add the other features net week or the week after
<intellectronica> beuno: that looks lovely
<intellectronica> especially if the icon will be better aligned with the text
<beuno> intellectronica, so, I don't know if I'll have time to work on this
<beuno> but I can land the icon, and see if someone else picks it up before I do
<intellectronica> beuno: no worries, i'll take care of integrating it
<beuno> intellectronica, will land today then, and re-assign it to you   :)
<beuno> \o/
<beuno> thank you
<EdwinGrubbs> joey: ping
<joey> hi EdwinGrubbs
<EdwinGrubbs> joey: can you check if bug 402747 is fixed for you now? I can't recreate the problem on my workstation and I don't have access to that page on edge.
<mup> Bug #402747: The requested URL /@@popup-window was not found on this server. <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/402747>
<ubot3`> Malone bug 402747 in launchpad-registry "The requested URL /@@popup-window was not found on this server." [Low,Triaged] https://launchpad.net/bugs/402747
<mup> Bug #402747: The requested URL /@@popup-window was not found on this server. <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/402747>
<mup> Bug #402747: The requested URL /@@popup-window was not found on this server. <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/402747>
<joey> hmm sure
<joey> mup vs ubot3
<sinzui> Two men enter, one man leaves
<flacoste> hey, nice post a bug comments AJAX!
 * sinzui thinks mup is cheating just like Master Blaster
<joey> EdwinGrubbs: so, there's still an error but not the same one. The new pop-up gives me a red error which says "Loading results failed."  nothing further
<joey> EdwinGrubbs: let's see if I can send you a screenshot over irc
<joey> EdwinGrubbs: actually, how about if I just attach it to the bug
<barry> beuno: https://devpad.canonical.com/~barry/pgroup.png
<barry> beuno: that's project groups ui 3.0
<sinzui> barry: The icons are missing from the links
<barry> sinzui: they're supposed to be.  see beuno :)
<sinzui> barry: I assume you moves /people?
<barry> sinzui: all top level pages will be consistent
<sinzui> What of the alternate views like list all?
<beuno> barry, I loves it
<beuno> the description text is too tiny
<barry> sinzui: anything that uses the shared menu will look exactly the same
<barry> beuno: do you mean "There are 8 project groups..." part?
<sinzui> barry: projects and project groups have a +all view
<beuno> barry, no, the results' description
<sinzui> barry: I fine with removing +all, maybe google will not be
<barry> beuno: do you want it the same size as the descriptive text at the bottom, somewhere in between?
<joey> Ursinha: do you know who owns ubot3?
<Ursinha> hmm
<Ursinha> ubot3`, owner
<ubot3`> This bot is owned by jussi01 - Questions about ubottu should be asked in #ubuntu-bots
<joey> Ursinha: wondering if we can get it removed or similar so we don't have it competing with mup
<Ursinha> the same as ubottu
<beuno> barry, isn't there a standard CSS style for it?  the answer would be in between
<Ursinha> joey, I think ubot3` is better since it recognizes oops urls
<barry> sinzui: i can redesign +all pages next.  those are different templates.  are there bugs open for those pages?
<beuno> :)
<Ursinha> :(
<beuno> ah
<beuno> oooop
<barry> beuno: i don't think there is yet in style 3.0, that's why i was asking :)  i'll add it
<Ursinha> bad bad operator
<joey> beuno: lol
<beuno> I knew I shouldn't of created an alias for that
<Ursinha> LOL
<sinzui> barry: no, because I did not consider them separate. They are links the the same view, often with a template that should not exist
<barry> beuno: i want to make projects and projectgroups consistent
<joey> lol
<beuno> :)
<joey> sorry, beuno
<joey> I couldn't resist
<Ursinha> that was mean
<joey> I'll go back into my hole now
<sinzui> barry: +all is doing search trickery to the view
<beuno> I desirved it
<joey> flacoste: : I still own the LP channels (I think).  You should appoint someone to look after them probably.  Like the ubot3 vs mup issue.
<joey> flacoste: I can make the request to make all the changes to the freenode staff (I think I'm the registered LP contact)
<barry> sinzui: i'll attack those as part of bug 273209
<mup> Bug #273209: /projects, /distros, /people pages are missing application tabs <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/273209>
<sinzui> barry: thanks.
<joey> flacoste: but I'm happy to keep them if you don't really care. I know Ursinha will help me. :-)
<flacoste> joey: ok, i'm making a note of that
<Ursinha> :)
<thumper> morning
<sinzui> rockstar: ping
<barry> beuno: 116% looks good
<rockstar> sinzui, hi
<sinzui> rockstar: beuno okayed 'show' links on the top-level colleciton pages. You may want to ask for the same permission for the answers and faq listings
<sinzui> rockstar: I mean show links in the side portlet, separate from actions, but in the side
<rockstar> sinzui, yeah, I was planning on having all of this UI reviewed, because it's not really all mechanical anymore.
<barry> intellectronica: thanks!
<beuno> thumper, hi
<thumper> beuno: hi
<beuno> I just bumped into something interesting
<beuno> https://code.edge.launchpad.net/~beuno/launchpad
<beuno> is context-less
<thumper> yes?
<beuno> for the tabs at least
<beuno> bah, not context-less
<beuno> wrong words
<beuno> "tabs" don't take you anyway
<beuno> anywhere
<beuno> I guess because you don't know where to take me
<thumper> that is because they are not enabled
<thumper> no
<thumper> it knows where to take you
<thumper> but no other app supports it yet
<beuno> aha
<beuno> true
<beuno> and there's no link to that anywhere, right?
<thumper> not yet
<thumper> we are wanting to change the personal listings
<thumper> but there are so many edge cases
<thumper> it is proving difficult
<beuno> got it
<beuno> ok, it's cool
<beuno> thumper, I'm off home, have a 40 minute drive from this hotel
<beuno> I'll try and catch you for that call
<thumper> ok
<rockstar> thumper, standup?
<thumper> rockstar: yesarooney
<thumper> rockstar: skype says your not on line
<rockstar> thumper, I just saw abentley get on.
<rockstar> thumper, I just called you and hung up.
<wgrant> Can somebody please ec2test-submit https://code.edge.launchpad.net/~wgrant/launchpad/make-zeca-useful? cprov did overnight, but it failed due to the breadcrumb breakage.
<beuno> thumper, up for that quick chat in 10?
<thumper> wgrant: can you go to https://code.edge.launchpad.net/groff ?
<thumper> wgrant: I'm wonding about timeouts
<thumper> wgrant: I know it will follow a different code path for you and me
<thumper> CP in progress?
<thumper> beuno: sure
<wgrant> thumper: It's fairly quick, but the new templatehas lost the queries/time data.
<thumper> wgrant: yeah, sinzui knows and I think is fixing
<thumper> wgrant: but no timeouts?
<wgrant> thumper: Not even close.
<thumper> cool
 * thumper marks bug fix committed
<wgrant> Great.
<beuno> thumper, ready when you are
#launchpad-dev 2009-08-21
<sinzui> Launchpad UI 3.0 Question and answer meeting in #launchpad meeting in 6 minutes
<thumper> sinzui: how long will it go for?
<sinzui> I will linger for 45 minutes. It will really on only if people have questions that I can answer
<thumper> sinzui: I don't have any questions, and I have to head out to meet Rachel
<thumper> sinzui: I'm not sure who else will be around, but good luck :)
<sinzui> fair enough
<wgrant> One month since the open sourcing!
<lifeless> \o/ happy birthday lp:)
<lifeless> hmm, sourceforge has useful timelines now ><
<wgrant> lifeless: You mean the project feed?
<lifeless> http://sourceforge.net/projects/japt-proxy/develop for instance
<wgrant> Yep.
<wgrant> Google Code has had something like that for ages.
<wgrant> Now somebody just needs to go and fix the karma system to do that.
<lifeless> mmm
<lifeless> 'someone needs to go and do that' +1
<lifeless> using karma for it.... different discussion
<wgrant> I suppose you could also just collate lots of collections of other activity records.
<lifeless> we have rss feeds for projects
<wgrant> But, well, there aren't such records.
<wgrant> There are RSS feeds of new revisions and new bugs.
<wgrant> And announcements.
<wgrant> Stuff I miss from Google Code is changes to and comments on bugs.
<stub> Anyone looking into what revision broke xx-productset.txt ?
<noodles775> stub: yes...
<adeuring> good morning
<wgrant> Hrmph. stable is ancient.
<mrevell> Morning compadres
<bigjools> morgen
<gmb> Got to love it when ec2test just sort of stops and shouts "No! Lalala, I'm not going to test your branch."
<wgrant> Is PQM happy again?
<wgrant> It has been a bit unhappy today.
<allenap> wgrant: I looked into the BugTaskEditView stuff, and basically concluded that we needed to change all the other call-sites to use transitionToMilestone(). However...
<wgrant> allenap: Hm? Why? No direct callsites should care about the schema.
<allenap> wgrant: It may actually make more sense to change mutator_for to allow use on a read-write attribute, perhaps by passing a allow_read_write parameter, just so it's not the default.
<elmo> ** bouncing apache on vanadium for emergency update
<allenap> wgrant: My logic may have been flawed :) But the milestone widget was behaving weirdly in the form, and simply changing it to be handled like status and importance seemed like the simplest fix.
<allenap> wgrant: Well, not simplest, but an already tried and working approach.
<wgrant> allenap: status/importance are readonly=True. I was unable to work out what was magical about them to make them writable.
<wgrant> i'm not sure that callsites outside the form need to be updated.
<allenap> wgrant: I think it's the bit around line 1235 in browser/bugtask.py that makes sure they can be edited, then there's some juggling in updateContextFromData to apply the changes.
<mrevell> danilo-afk: http://blog.launchpad.net/translations/screencast-sharing-translations-between-releases-of-the-same-project
<wgrant> allenap: Right, updateContextFromData will probably need changing. But my main concern at this point is getting the right widgets to show up.
<allenap> wgrant: Okay, I'll come back to you in a few minutes.
<wgrant> allenap: 1235 seems to replace the writable status/importance widgets with read-only ones if the user lacks privileges.
<wgrant> allenap: Which suggests that the writable widget is forced in place before that.
<allenap> wgrant: In my copy it does the opposite :)
<gmb> Did the session DB get dumped again?
<allenap> wgrant: But I'll go and experiment some more.
<wgrant> allenap: Thanks. I have a couple of ideas which I'll try...
<gmb> Ooh, timeout filing a bug.
<wgrant> gmb: Um, people have been complaining about that for weeks...
<gmb> wgrant: s/weeks/years (on and off). True, but I'd never experienced it filing a bug on Malone before.
<wgrant> bigjools: Why is the CoC required?
<wgrant> It seems quite irrelevant.
<bigjools> why?
<wgrant> bigjools: Hm, I guess there are a couple of relevant points in it.
<wgrant> My memory was foggy.
 * wgrant goes back to beating formlib into submission.
<bigjools> it needs it
<allenap> wgrant: Heh, sorry, you're right about line 1235.
<wgrant> bigjools: Not really. BugTaskEditView is just purest evil.
<wgrant> allenap: Phew.
<wgrant> allenap: Concerning that it's so hard to understand, though :/
<bigjools> there's a lot of purest evil, most of it in old Soyuz code :(
<mrevell> bigjools: doc fixed
<intellectronica> wgrant, allenap: the magic is using a mutator and i agree that this is a good approach
<wgrant> bigjools: But I can understand most of the Soyuz code.
<bigjools> mrevell: fanks
<wgrant> intellectronica: That's not the dark magic here.
<wgrant> intellectronica: The real magic is making the widget editable on +editstatus.
<wgrant> And BugTaskEditView's existing method of doing that is not transparent.
<bigjools> wgrant: care to let your eyes bleed over the perl in the buildd? :)
<intellectronica> wgrant: wow, you understand soyuz but not the bugtask edit view? do you also wear your socks over the shoes? :D
<wgrant> bigjools: I've hacked sbuild before for doing archive rebuilds... not pretty.
<wgrant> bigjools: Soyuz is easier to setup than dak/wanna-build/buildd!
<bigjools> :)
<noodles775> +1 for soyuz ;)
<intellectronica> wgrant: oh right
 * gmb genitally hates BugTaskEditView.
<gmb> Er.
<gmb> *genially
<gmb> Is the word I was going for there.
<wgrant> intellectronica: Hm?
<bigjools> how Freudian
<wgrant> Nicely done.
<al-maisan> intellectronica: after all these Soyuz reviews you should know it by heart now ;)
<intellectronica> :)
<wgrant> So...
<wgrant> Is there any good reason that it does things in this order: maybe overrides the status widget with something writable, maybe overrides the status and importance widgets with something read-only, then maybe overrides the importance with a writable widget?
<wgrant> Or is that just there to confuse people?
<allenap> wgrant: Just to confuse I think.
<allenap> wgrant: But probably something will break if done in a different order :(
 * wgrant finds a similarly nefarious order in which to place the milestone code.
<allenap> wgrant: Something I noticed. On the main bug page, milestone_source is not None. On the +editstatus page it's None, so the milestone field is not replaced (at around line 1221 in browser/bugtask.py)
<wgrant> allenap: Ahaa.
<wgrant> So.
<wgrant> We need to dig a restrictive milestone vocab up from somewhere.
<wgrant> But formlib must magically do that already.
<wgrant> As IBugTask.milestone's vocab looks global.
<wgrant> Or we convince formlib to generate a writable widget to start with. Argh.
<allenap> wgrant: Have a look at http://pastebin.ubuntu.com/256793/ - it seems to do something approximating correct. I haven't tested it much (and I intend to use copy_field at some point).
<allenap> wgrant: I'm not sure if lines 30 and 31 are needed either. I just threw them in.
<wgrant> allenap: copy_field then overriding readonly was going to be my next attempt. Let's see...
<allenap> wgrant: The tests pass at least!
<wgrant> allenap: I think those two are needed.
<wgrant> Oh.
<wgrant> So you don't need to override readonly?
<wgrant> Ah, you're not copying yet, right.
<allenap> wgrant: Yeah, the actual desired effect is obscured.
<allenap> wgrant: Here's my attempt with copy_field: http://pastebin.ubuntu.com/256798/
<wgrant> allenap: Mine is similar, although I didn't know that one could give it kwargs like that.
 * wgrant is testing that.
 * gmb -> restarting proxy, bbiam
<wgrant> allenap: Now I know that copy_field kwarg trick, I've spelt it http://pastebin.ubuntu.com/256803/
 * wgrant runs the tests.
<wgrant> I don't think you need that 26/27 change.
<allenap> wgrant: Cool.
<wgrant> So it was actually easy.
<wgrant> The existing complexity was deceptive.
<wgrant> allenap: Thanks. Pushing the change that I pastebinned -- care to ec2test?
<wgrant> All the failing tests pass.
<allenap> wgrant: Cool, will do :)
<wgrant> Now I just need to convince cprov that the failures in my other branch were because devel was broken, and that will be landing #10! Yay.
<allenap> wgrant: Wow, that's good going.
<deryck> Morning, all.
 * wgrant considers looking at PPA package download counters.
<bigjools> wgrant: that needs some more foundations work
<wgrant> bigjools: Really? What does it need?
<bigjools> wgrant: I don't remember exactly, but the current log parser only looks at librarian downloads
<wgrant> bigjools: It's easy enough to refactor.
<bigjools> oh for sure
<bigjools> just sayin' like
<wgrant> bigjools: So, assuming I refactor the log parser...
<bigjools> wgrant: talk to salgado first, he wrote the existing one, he'll give you tips
<wgrant> bigjools: Thanks.
<wgrant> bigjools: Model-wise, I'm thinking an ArchivePackageDownloadCount, like LFDC except referring to an archive and a source or binary package. Does that sound vaguely in the right direction?
<bigjools> wgrant: I think so, although we need to think about whether nullable foreign keys are wanted
<wgrant> bigjools: Why wouldn't they be?
<bigjools> APDC, with columns [source|binary]packagerelease, archive, count
<wgrant> That's right.
<bigjools> because you can have source and binary
<wgrant> [sb]pr are nullable, with a constraint to ensure exactly one isn't.
<bigjools> might be better to have 2 tables
<wgrant> Possibly.
 * bigjools goes back to figuring out how a change in das:+index broke das:+builds
 * gmb lunches
<deryck> sinzui, ping
<sinzui> hi deryck
<beuno> noodles775, hi
<noodles775> hey beuno
<beuno> noodles775, how are you today?
<noodles775> beuno: why, well thankyou :), and how would you be?
<noodles775> Just doing some packaging in between planning a ui change :)
<beuno> I'm the only way I can posibly be during a 2 month ui cycle: fantastically well
<noodles775> heh
<beuno> noodles775, have you seen that salgado's breadcrumb changes landed?
<beuno> for example, bug 165293
<mup> Bug #165293: collisions through uploading same-named .pack files not handled correctly <packs> <Bazaar:Confirmed> <https://launchpad.net/bugs/165293>
<noodles775> beuno: nope - haven't seen it, but great!
<noodles775> beuno: very nice!
<beuno> noodles775, while he works out some of the remaining issues, how do you feel about jumping in and moving them beneath the titles?
<Knut-HB> Hi, it's me... again. We got some problems while uploading files. A team member wants to upload template.pot and receives this error: http://paste.ubuntu.com/256915/
<noodles775> beuno: has the formatting been separated out from the hierarchy? That was the main issue last time I checked (the hierarchy was rendering itself manually)...
 * noodles775 checks
<beuno> ah, good question
<beuno> salgado should know
<beuno> salgado, btw:  wooooooooooooooooooooooooooo
<salgado> noodles775, no, the hierarchy still renders itself
<beuno> salgado, is changing that in your plans?
<salgado> beuno, not until it gets in my way or someone convinces me it's a good idea. ;)
<noodles775> salgado: you don't think it would be a good idea for the hierarchy to use a template to render itself, rather than the html code in the view?
 * noodles775 hasn't looked closely - maybe there's a good reason for the way it's done.
<salgado> noodles775, oh, absolutely!
<salgado> I thought you were talking about moving the rendering into the breadcrumbs themselves
<noodles775> salgado: no, just using templates to render them so it's much easier (1) to change and (2) to add the new formatting html for breadcrumbs on baselayout while letting the old template use the current breadcrumb formatting.
<salgado> right, that makes total sense
<salgado> but it'd be easy to fix, no?
<noodles775> salgado: I'm not sure - it looks like quite a bit of custom html construction going on in that render method.
<beuno> salgado, none of that HTML is needed for the 3.0 design
<beuno> er
<beuno> noodles775, ^
<salgado> let's throw it away, then
<beuno> it's simple text and links, with separators and a special rendering for the last item
<salgado> and break all pages not yet converted to 3.0
<noodles775> beuno, salgado: hangon - but that means all pages that *haven't* been updated to the 3-0 base-layout will go awol.
<sinzui> UI 3.0 question and answer session in #launchpad-meeting in 6 minutes. Everyone is welcome to ask questions. (no questions about lemurs please)
<beuno> noodles775, I think that it doesn't matter
<beuno> this is why we're not rolling out to production
<maxb> It turns out that mdz had a bzr branch for launchpad-dependencies back in the Dapper era (the source packages contain the bzr branch). Does anyone know where it might have gone? Did it see continued use after launchpad-dependencies went completely canonical-internal? It seems to have disappeared by the time launchpad-dependencies went to a PPA
<beuno> it will just have breadcrumbs rendered on top instead of underneath the title
<noodles775> beuno: no, they'll remain where they are, the formatting will just be 3.0 I assume.
<noodles775> beuno: sorry, ignore me... that's what you said.
<beuno> noodles775, right. I'm fine with that.
<beuno> more pressure to move the old pages  ;)
<noodles775> :)
<bigjools> sinzui: what's a lemur?
<noodles775> beuno: OK, Sounds like another fun job - just pm bigjools to talk with him.
<beuno> noodles775, think about it this way, if we drop the current breadcrumb rendering, we drop 14 HTTP requests on all pages
<sinzui> bigjools: A primate native Madigascar. The most famous one is King Julian played by Sasha Baron Cohen.
<noodles775> beuno: really? how is that? (the images are all cached right?)
<bigjools> sinzui: I should not have asked
<beuno> noodles775, they are cached, but they are in icing, so every night, the URL changes. And, for people who come to LP from a google link, well, it's their first time visit
<noodles775> beuno: sheesh...
<matsubara> wgrant, around?
<barry> beuno, sinzui can you think of any reason why /projectgroups should not be viewable by ordinary or anonymous users?
<sinzui> I want it visible. I think we get questions about it because users cannot find it
<barry> sinzui: it actually gives you an Unauthorized right now
<barry> sinzui: i think i'll open that up in my /projectsgroup branch
<sinzui> yes, but I am not sure we need to do that anymore
<beuno> barry no reason that I can think of
<barry> sinzui: agreed.  beuno cool
<barry> beuno: why the 0.1% granularity in font sizes in style-3.0.css?
<beuno> barry, I don't know, I still need to work on the font sizes  :)
<danilos> allenap: did you not want to submit the fix in PQM to db-devel instead?
<barry> beuno: adeuring has a good point in a review of my branch:
<barry> >I find the 0.1% "granularity" a bit exaggerated ;) If we assume
<barry> >that the base font size is 20 pixel on some monitor, 0.1% would
<barry> >mean a precision of .02 pixel. I don't think that any anti-aliasing
<allenap> danilos: Shite.
<barry> >algorithm will produce different result for font sizes specified
<barry> >as 24.6 and 24.62 pixel.
<barry>  
<danilos> allenap: it should be rejected (there are, I hope, DB changes in the db-devel you merged :), but you'll need to resubmit
<danilos> and I can't trust your [testfix] to land, so I'll need to resubmit as well :)
<allenap> danilos: Phew.
<beuno> barry, valid point
<danilos> mthaddon: perhaps, you can clean up the PQM queue (the testfix should go to db-devel, not devel, and the other one will fail anyway)
<danilos> beuno: fwiw, we've got 'stuff to review' up on your translations page :)
<beuno> danilos, where!?
<danilos> beuno: on edge, try translations.edge.launchpad.net/~beuno
<danilos> beuno: the rest of the page is still a mess, but there's one nice looking box with interesting stuff :)
<adeuring> barry, beuno: consider my comment about the font sizes as, let's say, a nitpick about another nitpick: It really doesn't matter if we specify the font size with that precision or not. Leaving the 0.1% is fine for me, even if I find it a bit odd ;)
<beuno> adeuring, I agree with you though
<beuno> danilos, nais!
<danilos> :)
<beuno> danilos, any reason why you picked a 2 column layout?
<danilos> beuno: it's not a 2 column layout, we've just used the max-width so it doesn't extend over the entire page... once we get to actual migration of that page, we can think it over :)
<adeuring> beuno, barry: But it might make sense to move the relative font size into its own CSS class, it if appears not only in barry's two branches but elsewhere too.
<beuno> danilos, awesome. Happy to see things from our sprint leaking through
<danilos> beuno: yeah, totally
<intellectronica> leonardr: around?
<leonardr> intellectronica, yeah
<intellectronica> leonardr: do you remember, by any chance, if we have an easy way of getting the _web_ url of an api object
<intellectronica> leonardr: from javascript
<leonardr> intellectronica: i believe bac asked that question a few days ago
<leonardr> and ended up filing a bug for it
<leonardr> bac, do you recall?
<intellectronica> i think gmb also asked that question a few days ago
<gmb> I did.
<intellectronica> if we don't have anything in place, maybe i should do that
<bac> leonardr: you said there was a bug already filed.  since my need was not urgent i let it go at that.
<gmb> And I got encouraged to fetch the object as XHTML, as I recall ;)
<gmb> (Although it made sense in context)
<intellectronica> leonardr, bac: if the solution to the bug is not too difficult i'll pick it up now, since my need is a bit urgent
<sinzui> beuno: can you confirm that the top-level objects (IPrimaryContext) (pillars, people) will never have breadcrumbs?
<leonardr> intellectronica: in fact, i believe BjornT was working on a solution, but not really making it a priority
<intellectronica> one thing i was thinking about is simply adding a web_url attribute to each object coming from the webservice
<leonardr> or at least he was working on a way to turn a web service request into a website request, which is a prerequisite
<intellectronica> leonardr: yes, that's done, but not sufficient
<leonardr> intellectronica: yes, that's the consensus solution
<intellectronica> leonardr: oright, now if you find the bug feel free to assign it to me
<leonardr> intellectronica: actually would you call it web_link instead of web_url?
<leonardr> that fits our naming convention
<leonardr> or web_self_link if you want to be verbose
<intellectronica> makes sense
<intellectronica> my_web_self_link
<beuno> sinzui, yes
<beuno> I confirm
<sinzui> okay
<sinzui> noodles775: beuno: I think we have a rule to automatically suppress the context heading when the context is IPrimaryContext. This will drop the redundant <h2> headings and may mean no one will every need to pass to the heading-slot...the <h1> in the content with DTRT
<beuno> sinzui, it sounds like a good idea
<sinzui> We need to keep the slot for the templates that are using it, or update every template to not use it
<noodles775> +1
<sinzui> beuno: I am traveling Saturday, but I think I can do this for a Monday landing
<beuno> sinzui, perfect
<sinzui> beuno: noodles775. I am hiding from a beach next week
<beuno> ooooh
<beuno> that sounds nice
<beuno> Florida?
<sinzui> noodles775: thanks for helping me understand the issue
<noodles775> sinzui: I hope you're not taking your laptop then? (if you're on holidays!)
<noodles775> sinzui: np!
<barry> sinzui: i thought you were alergic to the beach :)
<sinzui> beuno: A North Carolina barrier island.
<sinzui> I can find the vacation from hell warthogs email to remind everyone why I am hiding
<bigjools> sinzui: I look forward to another holiday report :D
 * bigjools still has that email
<sinzui> I did not report that my wife set a box of crustaceans on me last year
<beuno> sinzui, maybe you should jusst give up on holidays
 * beuno hides
<sinzui> I like mountains and hiking
<noodles775> yeah, me to :)
<bigjools> s/h/b/
<gmb> Argh. Can we implement bug dependencies for 4.0, please?
 * gmb wonders why he forgot to add that to his "top 3" list.
<sinzui> bigjools: when is the DSP page landing?
<bigjools> sinzui: when it's finished! :)  Seriously, I need a few days yet, prob a week
<sinzui> okay
<bigjools> I need to codify that complicated table and re-write all the tests
<sinzui> I have been removing a lot of tests that were verify the markup structure.
<rockstar> ALL:  I'll be ignoring IRC for the next few hours. If you need me, please SMS or call me.
<gmb> Is anyone else finding ec2test to be massively, painfully slow to start up today?
<gmb> It's bugging the hell out of me.
<intellectronica> rockstar: congrats on branch->bug linking. when i use it, the spinner appears above the action icon, instead of over it. is that intentional?
<mrevell> Okay guys, see you Monday!
<rockstar> sinzui, what is the role of the facet property on menus?
<barry> beuno-lunch: ping -> #launchpad-reviews when you return
<sinzui> facet binds the menu to a specific application bugs, or answers for example
<sinzui> rockstar: it is a dead branch in zope evolution. we should be using ILayer
<rockstar> sinzui, so my facets should be 'answers' ?  I'm seeing things like 'overview'
<rockstar> I'm just not sure what they do.
<EdwinGrubbs> rockstar, abentley: Can I assign one of you a question concerning pushing a branch to LP and the user gets 'different rich-root support' errors?
<abentley> EdwinGrubbs: Sure.
<EdwinGrubbs> abentley: thanks
<EdwinGrubbs> danilos: can I assign you a translations question?
<EdwinGrubbs> abentley, rockstar: could one of you respond to the email message on launchpad-users with the subject "merge request resubmission"?
<rockstar> EdwinGrubbs, I'll take care of it.
<EdwinGrubbs> rockstar: thanks
<gary_poster> have a good weekend!
<wgrant> matsubara-afk: I am now.
<EdwinGrubbs> bac: ping
#launchpad-dev 2009-08-22
<wgrant> If I wanted to factor the non-LFA-specific bits out of the librarian apache log parser, where would they go?
<bac> hi EdwinGrubbs
<rugby471> hi guys
<rugby471> working on some launchpad integration for memaker (the avatar creator)
<rugby471> wondering how is the most slick way to obtain authentication from the user
<rugby471> is there no way of getting around the page on launchpad where you can to select what the consumer can do on your account?
<rugby471> ie. I have this code at the moment http://pastebin.com/d4f2f239f
<rugby471> is this the best way to obtain the tokens etc.
<rugby471> ?
<wgrant> rugby471: If there was a way to get around it, it would defeat the purpose.
<rugby471> yeah
<wgrant> rugby471: Is there a reason you're not using Launchpad.get_token_and_login?
<rugby471> it's just it is slightly clunky when using it in an application
<wgrant> Oh, memaker is a GUI app, isn't it?
<rugby471> ie. you have to go to a browser window etc.
<wgrant> Right.
<rugby471> yeah
<wgrant> But it's necessary for security.
<rugby471> ok
<rugby471> btw another question
<rugby471> does the api only work if you are in the beta testers team?
<rugby471> even if you are using the main launchpad api (api.launchpad.net/beta)?
<wgrant> rugby471: Good question. I think it will work regardless, but let me check...
<rugby471> cool, thanks
<wgrant> rugby471: It doesn't look like there are any such restrictions, but it's possible I'm missing them.
<rugby471> ok
<rugby471> well I'll certainly find out when I present the integration o the rest of the memaker team :-)
<rugby471> thanks for your help
<wgrant> Indeed.
<wgrant> np
<wgrant> What integration is there going to be?
<rugby471> wgrant: basically one click chaning of the launchpad user's mugshot
<rugby471> chaning > changing
<james_w> anyone around who can check the state of the edge appservers?
<james_w> I think they might be in an inconsistent state again
<james_w> yeah, at least one appserver is on an old revno
<wgrant> james_w: They are.
<wgrant> Yep
<james_w> ok, anyone around that can fix it then? :-)
<maxb> This is perplexing, the googletestservice won't start properly so my tests are broken
<maxb> but it doesn't log anything of any use at all
<maxb> oh, duh. I broke it by mapping launchpad.dev at a nonlocal IP address, and then moving to a different wifi network
#launchpad-dev 2009-08-23
<wgrant> (I)BugNotification really don't match very well.
<wgrant> Er, (I)BugNomination
<wgrant> Can somebody please look up the exception message for OOPS-1331S486 for me?
* gmb changed the topic of #launchpad-dev to: Edge is giving the "Please try again page"; Canonical IS have been alerted | Launchpad Development Channel | Week 3 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/
 * kfogel is away: packing up laptop to go to onShore.  again.
* elmo changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/
<elmo> should be fixed now
<gmb> elmo: Thanks.
<thumper> morning
<jml> Good morning Launchpadders!
<jml> Have to confess, that's something of a trial run. I'll be back in a moment with coffee and maybe food and then I can try again.
<spm> morning jml, good to have you back in the right TZ! :-)
<thumper> jml: you back now?
<thumper> jml: we should have a call :)
<spm> thumper: you have a streak of cruelty I'd never suspected. :-P
<jml> thumper, now that I have coffee and food, I would love nothing better.
<thumper> spm: what?
<jml> spm: hi :) thank you.
<thumper> jml: I'll just get a cuppa and a scone :)
<spm> thumper: jml gets back and straight into a call. cruel. ;-)
<thumper> spm: that isn't cruel
<thumper> spm: that's easing him back into it
<spm> heh
* jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 2.2.8 | https://dev.launchpad.net/ |  Please use #launchpad for support. | https://launchpad.net/~launchpad-dev | Get it: https://dev.launchpad.net/Getting | http://people.canonical.com/~herb/ | http://paste.ubuntu.com/
<lifeless> welcome back
<lifeless> jml
<jml> lifeless, thanks.
#launchpad-dev 2010-08-23
<weather15> Problem with Apache
<weather15> I modified the Apache config as specified on the wiki
<weather15> I then entered this into my web browser http://10.0.0.5 and I get the Apache It Works page
<weather15> What can I do?
<weather15> Hello Everone
<weather15> *Everyone
<thumper> hi weather15
<weather15> Does any one know what to do when you get the Apache it Works page when trying to access Launchpad for the first time?
<weather15> OPen SOurce of course
<weather15> Do I have to enable the Launch Pad SIte?
<weather15> and Disbale the default site?
<lifeless> j
<weather15> I disbale the default site
<weather15> *disabled
<weather15> and then I get the SSL cert error
<weather15> But Then after accepting it:: The page isn't redirecting properly
<weather15> What can I do about ^
<weather15> >> ^
<lifeless> I odn't understand the question
<lifeless> perhaps you should start with a more regular development environment ?
<wgrant> Firstly, what are you trying to do?
<weather15> I downloaded the Launch Pad Installer
<weather15> Followed these instructions: https://dev.launchpad.net/Running
<wgrant> For what purpose?
<weather15> Then These : https://dev.launchpad.net/Running/RemoteAccess
<weather15> To Use Launch Pad Open Source
<weather15> After starting using: make run
<weather15> I tried to access LaunchPad via http://launchpad.dev
<ajmitch> wouldn't the default virtual host config generally be matched first before the launchpad one?
<weather15> Then Firefox throws this error: The page isn't redirecting properly
<weather15> Any idea as to what to do?
<weather15> I disabled the default Apache Site becuase I just got the It Works Page! when try to access Launch Pad
<ajmitch> you probably do need to access it by name
<wgrant> Right. Launchpad uses virtual hosts extensively.
<wgrant> So you need to access it as 'launchpad.dev'
<weather15> I'm using this: launchpad.dev
<weather15> I did how ever need to set this in my Hosts file
<weather15> as my DNS does not seem to resolve that name
<lifeless> thats expected
<lifeless> please note
<lifeless> that what you have downloaded is not an installer for launchpad
<lifeless> it is the launchpad source code - there are no installers
<weather15> I understand that as I have followed the wiki instructions to get it to run
<lifeless> ok
<lifeless> \o/ milestones branch passed ec2 land
<jcsackett_> lifeless: thanks for the suggestion on the tests for my usage_enums branch; i was looking for a cleaner solution, and at midnight nothing was coming to me. :-P
<weather15> I think I found the error
<weather15> [Sun Aug 22 19:43:59 2010] [info] Initial (No.1) HTTPS request received for child 0 (server bazaar.launchpad.dev:443) [Sun Aug 22 19:43:59 2010] [debug] mod_deflate.c(615): [client 10.0.0.3] Zlib: Compressed 284 to 217 : URL / [Sun Aug 22 19:44:14 2010] [debug] ssl_engine_io.c(1892): OpenSSL: I/O error, 5 bytes expected to read on BIO#7fe8b8ba53c0 [mem: 7fe8b8be6c40] [Sun Aug 22 19:44:14 2010] [info] [client 10.0.0.3] (70007)Th
<weather15> Just what can I do about it?
<lifeless> jcsackett_: my pleasure
<weather15> ?? ^
<lifeless> weather15: I don't know
<michaelh1> Hi there.  Is there a way of linking directly to the Launchpad-hosted Changelog for a release?
<michaelh1> I'd like to link to the Changelog text on https://launchpad.net/gcc-linaro/4.4/4.4-2010.07-0
<lifeless> wgrant: around?
<lifeless> michaelh1: not AFAIK
<michaelh1> OK.  I'll submit a feature request.
<lifeless> a patch would be better :)
<lifeless> actually, more seriously
<lifeless> why?
<lifeless> michaelh1: ^
<michaelh1> lifeless: oh, we want to do a summary page in the Linaro wiki that lists the projects involved in the current release, a link off to the download, and a link off to the change log
<wgrant> lifeless: Sure.
<lifeless> I'm looking at
<lifeless> https://launchpad.net/ubuntu/+search?text=smplayer
<lifeless> timeouts
<wgrant> Ew DistroSeriesPackageCache
<wgrant> And DistroSourcePackageCache.
<lifeless> yes
<wgrant> Kill them with fire.
<lifeless> 8000ms queries
<wgrant> Ow.
<lifeless> what should be used
<lifeless> also I recall you had a query to establish the archive ids
<lifeless> to reproduce things on staging
<lifeless> I wanted to snarf that from you (or hell, just the ubuntu archive ids would do)
<wgrant> The magic number is 534.
<wgrant> That's parter.
<wgrant> primary is 1.
<wgrant> s/parter/partner/
<wgrant> lifeless: I looked last week, and one of those caches is pretty useless.
<wgrant> I think DistroSeriesPackageCache.
<wgrant> But DistroSourcePackageCache might be slightly more performant than a straight query.
<lifeless> wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/618372
<_mup_> Bug #618372: Distribution:+search slow 50% of requests <dba> <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/618372>
<lifeless> its nice that the timeout predictor well, predicted
<wgrant> How bad is the plan?
<lifeless> dunno yet
<lifeless> but clearly pretty bad
<wgrant> Heh.
<lifeless> so to get the plan
<lifeless> I need values for distribution
<lifeless> ubuntu - 1 I'm guessing
<lifeless> releasestatus
<wgrant> releasestatus is an enum.
<wgrant> ubuntu might not be 1.
<wgrant> I'm not sure.
<lifeless> its 1
<lifeless> grah
<lifeless> wgrant: lib/lp/registry/browser/distribution.py - I want a second opinion on line
<lifeless> 479
<lifeless> I think its nuts; I don't see why it would work even.
<wgrant> Regardless, it's irrelevant now.
<wgrant> Storm is fixed.
<wgrant> Delete delete delete.
<wgrant> It may be that DRS has a workaround that's now gone since the original bug is fixed.
<wgrant> s/has/had/
<lifeless> argh
<lifeless> has_exact_matches()
<lifeless> sigh
<lifeless> is there a tal construct for 'show this <> if <iterator> iterates 1 or more times ?
<wgrant> Not directly, I don't think.
<wgrant> Anyway, I'm gone.
<lifeless> we need one
<lifeless> ciao
<lifeless> thanks
<thumper> ââ¹
<thumper> damn simplistic freaking tests
 * thumper taps fingers....
 * thumper hackerates
 * thumper fixes \\o/
<lifeless> ffs openid-apache-module-hate-hate-hate
<lifeless> poolie: so
<lifeless> poolie: I'd like you to send a hand-off mail to lp-dev, if you would, on flags
<lifeless> poolie: just a 'I'm not moving this forward for <period>, folk that want to can look at <url>, and I'd do <X> next' or something
<lifeless> poolie: if you have an in-progress branch, snapshotting that and including its details would be awesome
<poolie> yeah, good idea
<poolie> i was still thinking of doing another increment on it today, but i will at least send that
<poolie> i am a bit disappointed nobody else replied
<poolie> i guess it needs some examples of actually being useful though
<lifeless> the lp dev list has an odd dynamic.
<lifeless> Not to worry; we will fix.
<thumper> lifeless: you'll fix the dynamic?
 * thumper runs when he looks at the time
<lifeless> thumper: https://code.edge.launchpad.net/~lifeless/launchpad/milestones/+merge/32855
<lifeless> thumper: what does 'no longer in the source branch' mean? perhaps it should link to help.lp.net?
<thumper> what it means is that the approved revision isn't in that branch
<thumper> due to something like a push overwrite
<lifeless> ok
<thumper> lifeless: is it right?
<lifeless> yes
<thumper> is it because you reused the branch?
<lifeless> I had a bunch of cruft, which I collapsed into one commit
<lifeless> so reused - yes, but for that same mp.
<lifeless> history-edit
 * thumper feels like a primal scream 
<thumper> clucking canonical_url fallout
<thumper> and broken code
<wgrant> lifeless: Any luck?
<lifeless> thumper: :(
<lifeless> thumper: I thought c_u fix landed?
<lifeless> wgrant: plan is in the bug
<thumper> lifeless: it has
<lifeless> thumper: untested code paths died as a result ?
<thumper> lifeless: in my next branch, I've found lib/lp/testing/menu.py
<thumper> which is wrong
<thumper> so my fix for it breaks stuff
<thumper> grr...
<lifeless> :(
<thumper> didn't find it in the old branch as nothing that triggered the bug was being tested
<lifeless> spm: hi
<lifeless> spm: I'd like a kcachegrind please ;)
<spm> lifeless: err...
<lifeless> spm: ...rre?
<spm> of what where and probably more significantly, how :-)
<lifeless> spm: we did this before your sprint
<thumper> ââ¹
<spm> um, no we didn't. :-)
<lifeless> spm: you change the setting on staging, I hit up the url, you change it back
<lifeless> spm: yes, we did.
<spm> oh THAT. right. debug.
<lifeless> actually
<lifeless> nvm, I suspect that the underrepresentation of sql may be a factor
<lifeless> so I'm going to fix the darn sql
<lifeless> if its still naffed after that, we'll get a cleaner kcachegrind file
<spm> nod
<lifeless> sorry for the interrupt
<lifeless> wgrant: so - has the distribution search changed recently?
<wgrant> lifeless: Not since 3.0, AFAIK.
<lifeless> wgrant: if not, then its likely a transient DB issue, as its bad on edge and prod
<lifeless> and wasn't showing up as such before
<lifeless> so I've subscribed stub via the dba tag
<lifeless> however
<lifeless> the plan shows loop on loop on loop
<lifeless> for thousands of items
<wgrant> Yes, the plan makes me cry.
<lifeless> thats going to add up any which way
<lifeless> stub: I've tagged another bug dba
<lifeless> slow query, no code changes recently, wondering if you could see if its an operational issue / bad query design etc
<lifeless> stub: also, the PPR seems to have broken over the weekendish
<stub> jtv: Should suggestivepotemplate.potemplate be a foreign key reference to POTemplate (ON DELETE CASCADE I suspect as this is a cache)
<stub> jtv: Should suggestivepotemplate.potemplate be a foreign key reference to POTemplate (ON DELETE CASCADE I suspect as this is a cache)
<mwhudson> thai internet doing well today, it seems
<stub> bouncy bouncy
<StevenK> mwhudson: Do you remember the discussion we had at least 3 weeks ago about my branch that added the beginnings of job support for InitialiseDistroSeries?
<mwhudson> StevenK: vaguely
<StevenK> mwhudson: I removed job_type like you suggested, but now the test for InitialiseDistroSeriesJobDervied fails, since .create() doesn't raise an AttributeError
<mwhudson> StevenK: err
 * StevenK suspects he has lost mwhudson
<noodles775> Morning!
<lifeless> hi noodles775
<lifeless> noodles775: I has a question for you
<lifeless> noodles775: lib/lp/registry/browser/distribution.py
<lifeless> line 479
<lifeless> is that still relevant ?
 * noodles775 looks
 * noodles775 pulls a recent version of devel
<noodles775> lifeless: So the associated bug has been released, and we're using a version of storm that includes it. So I would say no. Remove it, and see (or I can do it if you're done for the day).
<adeuring> good morning
<lifeless> noodles775: I'm well done ;)
<lifeless> noodles775: I'd love it if you could; I found that code while starting to look at a perf issue
<noodles775> lifeless: np, I'll do it now.
<lifeless> thanks!
<wgrant> It'd be nice if we had a tool which would report XXXs referring to closed bugs.
<lifeless> that would be nice
<lifeless> it would make an awesome bzr precommit check too
<bigjools> or even better, a ....
<bigjools> that
<lifeless> night all; its only 8:30 but 5am starts really takes it out of you
<wgrant> Night lifeless.
<lifeless> and I want to be alert for perf tuesday! :)
<noodles775> Night lifeless.
<deryck> Morning, all.
<jml> good morning deryck
<deryck> is there a rockstar in the building?
 * rockstar is a rockstar
<rockstar> deryck, how can I help you?
<bigjools> james_w: hi
<jml> bigjools, I've replied to your review. Megapologies about the delay.
<deryck> sinzui, ping
<sinzui> hi deryck
<maxb> erm, this is a bit special. python-testtools is "Published" in jaunty in ~bzr/proposed, but doesn't occur in the Packages file
<jml> g'night all.
<lifeless> moin
* lifeless changed the topic of #launchpad-dev to: hpad Development Channel | Week 1 of 10.09 | Performance Tuesday! | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews
<deryck> oops, forgot I marked myself away for lunch
<deryck> bryceh, your branch looks good to me.  r=me.
<deryck> hi lifeless
<bryceh> deryck, great thanks
<deryck> brianchidester, oh, wait.  Did you test the new status conversions?
<deryck> gah, tab expansion death
<deryck> bryceh, oh, wait.  Did you test the new status conversions?
<deryck> if externalbugtracker-bugzilla.txt is not exhaustive, then no worries.  If it was, then we should keep it so.
<bryceh> deryck, it isn't exhaustive
<bryceh> deryck, it just spot checks.  I could add a few if you think it'd help
<deryck> bryceh, nah, what you've added is fine then.
<bryceh> okie
<lifeless> deryck: hi
<lifeless> deryck: my bugtaskset change is in :)
<deryck> excellent :-)
<lifeless> so
<lifeless> lets see whats timing out today
<lifeless> I suspect bug attachment api calls
<lifeless> deryck: has anyone claimed that yet
<lifeless> ?
<deryck> lifeless, no, no one is on that yet.
<lifeless> deryck: also while you are here
<lifeless> have you seen https://bugs.edge.launchpad.net/malone/+bug/607935
<_mup_> Bug #607935: timeout on bugtask:+index <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/607935>
<lifeless> 367 sql calls :)
<deryck> lifeless, I have seen that in that I saw the few bugs you filed around the same day.  And I just haven't got to prioritizing that yet.
<lifeless> deryck: it seems to be one-by-one retrieving people
<lifeless> I'm guessing its subscriptions or something
<deryck> lifeless, ok, that's one of my spots I wanted to look at anyway next.
<deryck> I'll be doing OOPS and timeout poking the rest of this cycle while the others finish up the subscriptions noise story.
<lifeless> \o/
<lifeless> I'd love to help you
<lifeless> but we're in rather different tz's
<lifeless> :)
<lifeless> although, what time is it for you, now ?
<deryck> well, work hours anyway. :-)
<sinzui> deryck, I see from the config that there is mention of a bug-heat user/script. I think it is gone. Is this right
<deryck> it's only 3 PM for me.  But that's EOD.  I timeshift to match Europe better.
<lifeless> deryck: ah!
<deryck> sinzui, yes, should be.
<sinzui> deryck, thanks
<deryck> np
<lifeless> well, I'll try to be up @ 6 tomorrow and we should get 2 hours of overlap
<deryck> Sure, that would be fun.
<deryck> But I hate to ask you to get up early :-)
<lifeless> deryck: getting someone else to do perf stuff on tuesday is a pleasure, not a penalty!
<deryck> heh, cool then
<deryck> ok, so until tomorrow then....
<lifeless> gary_poster: I saw your update of Foundations/Webservice
<lifeless> gary_poster: perhaps we should file a bug asking for a "%s.%s" % (__module__, self.__class__) to be gathered too ?
<gary_poster> lifeless: I thought about that when we were first implementing.  At the time I thought it would be unnecessary: it would make for a more unwieldy pageid, and we can always grep.  I'm less sure now, but TBH I think the story of going from the named operation to the method is more annoying, at least potentially.
<lifeless> gary_poster: I'd like all the steps to be easy :)
 * lifeless is lazy
<mwhudson> morning
<jelmer> hello
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1695L1219 should so not be a soft timeout
<lifeless> 45 seconds!
<lifeless> thumper: when you're around, a brief call would be nice
<thumper> ack
<lifeless> is that 200 OK, or 101 please wait
<thumper> 101
<lifeless> kk
<lifeless> If I said object X is "a request timeline", what would you think it does ?
<lifeless> gary_poster: ping
<lifeless> gary_poster: does zope have something already existing for tastefully annotating request objects.
<lifeless> e.g. I have an object (say the db statement list we generate) that I want to associate with a request, such that I can, whenever I have the request, get this other object.
<lifeless> Its a little distateful to write to that object directly
<lifeless> and a weakrefkeydict is a little ergh to work with, though doable.
#launchpad-dev 2010-08-24
<wgrant> lifeless: Our requests don't have an IAnnotations adapter?
<gary_poster> lifeless: there is a .annotations attribute for that purpose
<gary_poster> I hope it is available as an IAnnotations adapter, but I don't remember if it is
<gary_poster> But, obviously, the direct access is pretty clear
<lifeless> wgrant: well, webapp/adapter uses thread locals rather than looking up the request and using that
<lifeless> gary_poster: thanks
<lifeless> gary_poster: so its .annotations.thing ?
<gary_poster> lifeless, .annotations is a dict
<lifeless> ok; request.annotations[
<lifeless> 'thing']
<gary_poster> yeah
<lifeless> I don't think I can use it for this work anyway, because webapp.adapter is involved
<lifeless> but I may do a pass at that to make it better in future.
<lifeless> wgrant: gary_poster: did you see my question above about timelines ?
<gary_poster> no, looking
<lifeless> in case you didn't, would value both your responses to :
<lifeless> If I said object X is "a request timeline", what would you think it does ?
<gary_poster> I would think it would what I called in another context an "object log":
<gary_poster> an iterable of records of things that happened to the object
<gary_poster> in order of when they happened
<gary_poster> where each record is an object or a dict or something else code-friendly
<gary_poster> (as opposed to just a string)
<gary_poster> so, that, for the request
<wgrant> I'd think it would record events like request start, traversal start, traversal finish, template rendering times, that sort of thing. Possibly SQL too.
<gary_poster> yeah, that's what I'd expect to see in what I described
<lifeless> ok cool
<lifeless> lp.services.timeline is born
<lifeless> last 'boy don't you wish robert knew zope well' question
<lifeless> is there a way to 'get me the current request please' ?
<mwhudson> lifeless: get_current_browser_request()
<lifeless> mwhudson: thanks
<mwhudson> lifeless: it's in canonical.launchpad.webapp.mumble
<mwhudson> probably .publisher
<lifeless> ok
<lifeless> and for tests, how does one set that ?
<mwhudson> req = ...
<mwhudson> login(ANONYMOUS, req)
<lifeless> ah sweet
<lifeless> gary_poster: was that previous code open ? Could we just grab it ?
<gary_poster> lifeless, ZODB based IIRC.  I'll look...
<gary_poster> lifeless, not ZODB directly, actually, but I don't think it is quite what you want: http://pypi.python.org/pypi/zc.objectlog FWIW
<lifeless> yeah, different focus
<lifeless> this is small enough, I hope, that any duplication of effort will be minimal
<lifeless> if not, we can merge the common bits later
<lifeless> thanks
<lifeless> I'm off to sign back the rental property
<thumper> <lifeless> lp.services.timeline is born ?!?
<thumper> lifeless: is this what I think it is?
<lifeless> I don't know, what do you think it is?
<lifeless> thumper: ok, really gone; back ~ 3 and we can diskuss then
<lifeless> thumper: turns out I can leech some wifi here :P
<thumper> :)
<lifeless> thumper: so you were asking what lp.services.timeline is
<thumper> I was
<lifeless> +"""lp.services.timeline provides a timeline for varied actions.
<lifeless> +
<lifeless> +This is used as part of determining where time goes in a request.
<lifeless> +
<lifeless> +NOTE that it is not LP's timeline-view for products, though they are similar in
<lifeless> +intent and concept (If a better name presents itself, this package may be
<lifeless> +renamed).
<lifeless> +
<lifeless> +Because this part of lp.services, packages in this namespace can only use
<lifeless> +general LAZR or library functionality.
<lifeless> +"""
<thumper> :(
<lifeless> what were you thinking it was?
<wgrant> A project timeline, which everybody has wanted for approximately ever?
<wgrant> Ah, I see that's covered in the docstring. Heh.
<lifeless> grep for timeline in the source; there is a timeline thing already
<lifeless> product timeline that is
<wgrant> Er.
<wgrant> I've never seen one.
<thumper> not an aggregated timeline of interesting events
<wgrant> (which every other hosting site has)
<thumper> I have a half-baked plan for project timeliens
<thumper> I really should put it back in the oven some more
<lifeless> I'd love timelines
<lifeless> for objects
<lifeless> rss feeds interact with this
 * thumper nods
<lifeless> everything in a timeline should be in the feed
<lifeless> and vice verca
<lifeless> IMNSHO
<thumper> agreed
<wgrant> Yep.
<thumper> lifeless: perhaps we (two) should have a sprint on this?
<thumper> lifeless: you could come down
<wgrant> But feature development doesn't seem to happen much these days.
<lifeless> or you could come up :)
<thumper> lifeless: or we could just remote sprint
<lifeless> thumper: I'd be delighted to help you scratch that itch
<thumper> lifeless: but actually dedicate time to it
<thumper> lifeless: it'd have to be after francis is back
<lifeless> when we have RFWTAD I'll have a slot open in kanbam
<thumper> :(
<thumper> just noticed I have a crack in my laptop keyboard
<thumper> probably from carrying it around badly
<lifeless> :<
<thumper> is there any way to do a reverse view lookup?
<thumper> from a name to get the layer?
<lifeless> 'the', not 'a' ?
<thumper> lifeless: a view may or may not have a layer defined
<thumper> lifeless: I'm after a way to simplify some of the tests
<thumper> lifeless: so instead of having to specify the rootsite of 'code' for the +recipe view
<thumper> we know that the +recipe view is only ever on the 'code' site
<thumper> so we shouldn't have to pass it in
<lifeless> makes sense to me
<mwhudson> thumper: basically you want to know 'for which X will queryMultiAdapter((context_object, X), name='+recipe') not return None' ?
<thumper> mwhudson: yeah
<mwhudson> thumper: doesn't look easy at all
<thumper> mwhudson: no
<lifeless> this stuff isn't half crufty
<lifeless> also, I hate the import fascist with a vengeance
<StevenK> lifeless: Well, *duh*, it's a fascist.
<lifeless> just saying
* StevenK changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.09 | Performance Tuesday! | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews
<lifeless> also
<lifeless> its a bit annoying that set_request_started *doesn't take a request*
<lifeless> anyhoo
<lifeless> I think I'll have a timeline happy by EOD
<lifeless> stub: thanks for fixing the ppr
<lifeless> stub: did you have a chance to look at the dba tagged bug ?
<stub> Didn't fix a thing. Just devpad being its usual reliable self I guess.
<lifeless> the test suite breaks -hard- when set_request_timeout is naffed
<lifeless> stub: heh, well you can take the credit :)
<stub> Always do
<wgrant> WTF
<wgrant> Why am I in the db_lp blamelist?
<wgrant> I haven't had anything landed for quite a while.
<lifeless> stub: so
<lifeless> stub: dba bugs - did you have a chance, or not ?
<stub> did one, can't remember the other
<lifeless> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=dba
<lifeless> both pending your input
<spm> wgrant: oh didn't we tell you about that patch to buildbot? lp:~spm/buildbot-configs/always-blame-wgrant we figured you'd understand
 * spm runs away on the school run; so as to allow a colder dish of revenge to be savoured by M. Grant.
<wgrant> Heh.
<lifeless> matsubara-afk: hi
 * thumper EODs for now, prolly back later for more chats :)
<lifeless> thumper: ciao, we should have a weekly when you're back
<lifeless> thumper: bug 615647 needs your input
<_mup_> Bug #615647: BranchMergeProposal:+index timeout <dba> <timeout> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/615647>
<lifeless> stub: did the OOPS on that one help at all ?
<stub> it demonstrates that the normally fast query can block. I suspect branch scanner inserting 10k or more rows to that table in a big transaction.
<lifeless> ok
<lifeless> is there something we can do to gather data about the cause of blocks like that ?
<stub> It also shows the master db is being used, but for this page that is silly
<lifeless> (I thought MVCC is meant to help)
<stub> Not yet.
<stub> MVCC does help. We are maintaining indexes on half a billion rows remember.
<lifeless> true
<lifeless> I wasn't meaning to be critical -- I just thought that the design meant readers weren't blocked
<stub> So PG 8.4 will help. Code team has eventual plans to drop this table entirely. There is a branch that has been lost dealing with dropping the id column (narrower table will perform better and speed replica and staging rebuilds noticeably and save several gigabytes of disk)
<stub> The design does mean readers should not be blocked. To be honest, I don't understand why it could be blocking for that long.
<lifeless> should we escalate to our support mob ?
<stub> They might be able to tell us why. Not sure if that helps us though.
<stub> Normal pg mailing lists would give the same or better answer.
<lifeless> Would depend on the answer I think.
<lifeless> I think we should contact someone ;)
<lifeless> spm: yes, i can see the issue there; the respondant isn't all charm either.
<spm> lifeless: oh yes. I wasn't going there. A sledgehammer has *two* faces after all. :-)
<wgrant> So, seriously, what's with that db_lp failure?
<spm> I killed the ec2 instances. i suspect they should be focibly restarted.
<wgrant> Yes, but why am I in it!?
<lifeless> because you have a godlike demeanor
<wgrant> ...
<lifeless> ^W^Wchildlike demeanor ?
<lifeless> wgrant: seriously, noone knows.
<stub> Start with #postgresql
<lifeless> wgrant: is it worth digging ?
<wgrant> lifeless: Probably not.
<lifeless> stub: cool, thanks
<wgrant> Just wondering if there was any obvious reason (eg. it started two weeks ago and hung).
<wgrant> It concerns me when the CI system does inexplicable things.
<StevenK> I don't think db_lp and lp have been building for a while ...
<StevenK> Since lucid_{db_,}lp is the new hotness
<lifeless> StevenK: I repeat, I checked
<lifeless> StevenK: they are both meant to build until we migrate completely.
<lifeless> bbiab, foodingk.
<stub> <xmlrpc@launchpad_prod_3:21247> 2010-08-08 21:19:20 BST LOG:  process 21247 still waiting for ShareLock on transaction 1884213882 after 1000.106 ms
<stub> Different problem, but some insight into the xmlrpc slow stuff
<spm> ouch
<henninge> Morning! ;)
<henninge> Does anybody have an idea how an error like this can happen on an EC2 test run?
<henninge> http://paste.ubuntu.com/482770/
<henninge> jtv: ^ that's on the recife branch after merging db-stable.
<jtv> henninge: looking...
<jtv> henninge: on ec2, that's strange.
<jtv> stub: any idea why ec2 might give the "you need to run make schema" error? ^^
<jtv> maybe need to rebuild the sampledata?
<stub> I don't know why that would happen
<stub> Perhaps a badly named db patch, which is picked up by the has-this-patch-been-applied checks but not picked up by the apply-patches script.
<jtv> Perhaps something broke the patch, and we ignore that failure (e.g. because we know that this check will cover it)?
<stub> Look for oddities in the patch filename, such as _ instead of -, not enough digits, typo in 'patch' or 'sql'...
<henninge> Despite that message the test suite runs without fail or error.
<jtv> stub: it says patch-2207-96-0.sql has been applied to the db but is not in the source treeâ¦ anything weird about that name?
<stub> Yes, it is old. The new baseline landed and patches are now 2208, not 2207
<stub> Is LaunchpadDatabaseRevision in the sampledata?
<jtv> dunno
<jtv> stub: yup, it is
<henninge> stub: So we need to rename the patch to 2208-96 ?
<jtv> So chances are the patch was removed from the directory but not from the sampledata.
<jtv> henninge: is that our Recife patch by any chance?
<jtv> In which case we may need a new patch number for the 2008 seriesâ¦
<stub> henninge: Yes - patches numbered 2207 will explode. I can give you a new number of you had an official one given out.
<henninge> jtv: yes, of course. ;)
<henninge> stub: I don't think it was an official number.
<jtv> The Translations team frantically digs for the DB review...
<jtv> henninge: my version of the recife branch doesn't have that patch any more.  :( :( :(
<jtv> henninge: hmmâ¦ looks like our patch was numbered 99, not 96
<jtv> So what was in 96
<jtv> ?
<jtv> Was there ever a patch-2207-96-0.sql?  Google says no.
<henninge> No idea
<henninge> Wow, the mystery of the patch that never was ...
<jtv> I just found one hit on google, but I'm fairly sure it's not supposed to redirect to 01proxy.com
<henninge> DON'T CLICK!
<henninge> ;)
<jtv> Too late
<jtv> It's actually a hit on 01proxy.  :(
<jtv> Google's cached version of the 01proxy.com page shows an MP by Curtis, rejected by himself... MP 22810.
<jtv> bug 538024
<_mup_> Bug #538024: No way of saying "This project is not packaged" <qa-ok> <Launchpad Registry:Fix Released by sinzui> <https://launchpad.net/bugs/538024>
<lifeless> I need a tip/hand with 'requests' in 'scripts'
<jtv> Patch description: "Added date_last_packaging_check column to Product."
<lifeless> specifically :-
<lifeless> I have some code
<lifeless> it keys off of request as its context
<lifeless> but scripts which haven't setup a 'current_browser_request' try to use it.
<lifeless> e.g. checkwatches.
<lifeless> is calling 'login(ANONYMOUS, ScriptRequest())' there sane ?
<lifeless> or should I just make my code (which is the sql gathering oops helper) silently do-nothing ?
<lifeless> (its defined as doing nothing in that case anyway)
<lifeless> mwhudson: ^ I hear you've done a bit of out-of-appserver-stuff, care to comment ?
<henninge> Why do I keep seeing this when running make clean?
<henninge> rm: Entfernen von â/var/tmp/bazaar.launchpad.dev/rewrite.logâ nicht mÃ¶glich: Permission denied
<henninge> (No, I am not talking about the German text for "removal not possible" ... ;)
<lifeless> ls -l /var/tmp/bazaar.launchpad.dev/rewrite.log ?
<bigjools> because it gets created as root by Apache
<bigjools> it's seriously annoying
<henninge> lifeless: I already sudo deleted it ...
<bigjools> not to mention having the rewrite process running all the time (which I disabled)
<henninge> bigjools: Thanks, it's not on my end, then.
<spm> henninge: "export LANG=C ; make clean" should sort out the german text problem? <== not helping :-P
<henninge> Hi spm! ;-)
<spm> heya!
<bigjools> LANG=queens_en.utf8
<adeuring> good morning
<jtv> bigjools: that'd be en_QUEENS.UTF-8 and it'd probably be taken by Queens, NY
<jtv> hi adeuring
<bigjools> jtv: impossible!
<adeuring> hi jtv!
<jtv> bigjools: not at all.  They invented democracy and English, so why shouldn't they have grabbed this one as well?
<lifeless> so, any comment on my login query ?
<lifeless> it feels wrong to use lp.testing.login() in a script.
<bigjools> jtv: ha :)
<jtv> lifeless: no idea on this end, sorry
<lifeless> thanks
<jtv> (just saying: you're not being ignored in favour of jokes)
<lifeless> jtv: hey, I havne't reviewed your thing yet.
<jtv> lifeless: carefulâQuotes is just a few clicks awa
<jtv> y
<lifeless> jtv: please get a general review of it done and land it; I'll look at it when I get a cycle
<jtv> lifeless: ok.  Not much there, it's really tiny.
<jml> good morning
<thumper> lifeless: why are you logging in for a script?
<thumper> jml: hi
<jtv> hi jml, hi thumper
<thumper> jtv: do you know the recursive sql syntax for postgresql?
<thumper> jtv: or put it another way, could you write a correct recursive query?
<thumper> jtv: mine didn't work
<jtv> thumper: haven't tried yet
<thumper> jtv: ack
<jtv> Still too intimidated by the SQL Mandelbrot
<jtv> All I remember is the "with" is basically a pipe, and you can feed the outcome of the query back into that pipe as it were
<jtv> thumper: what kind of problem are you trying to solve?  Transitive closure-type stuff?
<thumper> jtv: trying a recursive query to identify if a revision is in a branch based on the revision and revision parent tables avoiding the branch revision table
<thumper> I'd love to be able to test the query on the staging db
<thumper> jtv: part of the problem though is that the tree we are traversing is likely to be deep and narrow
<jtv> thumper: this was actually one of the test questions I was asked as part of the hiring processâ¦ guy named Pool.
<jtv> Wonder what made him think of this problem.  :)
<lifeless> thumper: we should have a participation in place
<thumper> eh?
<lifeless> thumper: for security proxies etc to work
<lifeless> thumper: and for things keyed off of that to work too
<thumper> lifeless: ah, EOLDCONTEXT
<thumper> are we in testfix mode?
<lifeless> thumper: I've refactored get_request_statements to not use a thread local variable
<lifeless> thumper: and to store much more than sql
<lifeless> like email, rabbit, memcache, bzr times
<lifeless> but, sadly, I now need to learn about our scripts stuff
<jml> thumper, I guess so, since the last build "failed"
<lifeless> jml: ah, you know about this stuff; see my question above
<jml> lifeless, which one?
<lifeless> 19:16 < lifeless> I need a tip/hand with 'requests' in 'scripts'
<lifeless> ...
<jml> lifeless, in answer to your question, yes, I think using ScriptRequest() there is sane
<jml> hmm
<lifeless> jml: so, setupInteraction(ANONYMOUS, participation=ScriptRequest()) ?
<lifeless> or will we need a celebrity or some such to represent the scripts (do we have one already) ?
<jml> lifeless, I think so. No celeb.
<wgrant> Don't scripts mostly run with PemissiveSecurityPolicy?
<jml> it's been so long since I needed it.
<wgrant> Soyuz ones do, at least.
<lifeless> wgrant: I've not heard of that
<jml> wgrant, they (almost?) all do
<jml> lifeless, ahh, right.
<jml> some more context for you then!
<lifeless> but if it means 'ANONYMOUS can write' then I'm happy
<jml> they also load less zcml
<jml> in a half-hearted effort to have them run faster
<wgrant> Do they really?
 * wgrant checks.
<jml> wgrant, they used to
<wgrant> It certainly doesn't feel like it.
<jml> wgrant, I should say "a subset of our zcml" to hedge my bets.
<wgrant> Heh.
<jml> initZopeless is key here, iirc.
<wgrant> Well, sort of.
<wgrant> execute_zcml_from_scripts is a separate thing.
<wgrant> But they are usual called alongside each other.
<jml> ahh right.
<wgrant> s/from/for/
<jml> it floods back like a wave of mutilation.
<wgrant> initZopeless does the transaction setup.
<wgrant> execute_zcml_for_scripts does ZCML and security and stuff.
<jml> and exec_zcml_for_scripts sets up the interaction
<wgrant> Scripts call both.
<wgrant> Yep.
<jml>     # This is a convenient hack to set up a zope interaction, before we get
<jml>     # the proper API for having a principal / user running in scripts.
<jml>     # The script will have full permissions because of the
<jml>     # PermissiveSecurityPolicy set up in script.zcml.
<jml>     setupInteractionByEmail(ANONYMOUS)
<lifeless> so
<wgrant> lifeless: Scripts shouldn't need anybody logged in.
<lifeless> is it, in principle, as simple as adding ScriptRequest() to that ?
<wgrant> In PermissiveSecurityPolicy, all permissions are held at all times.
<wgrant> This, confusingly, does not mean that all operations are possible.
<lifeless> should is a strong term
<jml> lifeless, not sure. It ought to be.
<jml> lifeless, try it?
<lifeless> jml: I will.
<jml> lifeless, "should" is an ambiguous term.
<lifeless> jml: what file was that ?
<jml> lifeless, c.l.scripts.__init__
<bigjools> jml: why do we use tac files instead of just running the reactor from a .py?
<jml> bigjools, because we get daemonization and logging and a bunch of other stuff from twistd for free
<bigjools> ok
<lifeless> jml: its a bit annoying that that isn't a two-liner to get from a py file
<jml> lifeless, yes. known bug.
<jml> it's *also* a bit annoying that there are tac files and there are "twistd plugins", and that the latter are somewhat nicer to use but harder to write.
<lifeless> agreed
<jml> Hmm.
<jml> I was about to say that it was unfortunate that no-one pays me to hack on Twisted full time.
<lifeless> hah
<lifeless> AttributeError: 'ScriptRequest' object has no attribute 'interaction'
<jml> But I've never really seriously pursued it as an option.
<jml> Hmm.
<jml> I can't remember if the standard request object is a participation or whether it gets adapted to one.
<lifeless> I'm digging
<lifeless> the root of this is me wanting to write clean code
<jml> tsk tsk.
<lifeless> and adapter._local being a) fugly and b) not in lp.services
<lifeless> wgrant: going back to what scripts need.
<lifeless> wgrant: I think its reasonable to say that scripts are always acting on *behalf* of someone modelled in the systme.
<lifeless> wgrant: be it a celebrity or user
<wgrant> lifeless: Probably, yes. But that's not how they're implemented.
<lifeless> wgrant: being implemented differently gives us two environments to write code for, without justification for that split.
<lifeless> wgrant: this is, I argue, harder than it needs to be. So we should change it.
<wgrant> Oh yes, and it results in ugly ZCML and probably security holes too.
<lifeless> however, the trivial didn't work, so I'm going to workaround, bug is filed, putting details in it.
<thumper> an interesting tidbit of information...
<thumper> approximately half of the 600 million branch revision rows are for launchpad branches :)
<lifeless> jml: wgrant: I would appreciate comments on https://bugs.edge.launchpad.net/launchpad-foundations/+bug/623199
<_mup_> Bug #623199: scripts do not establish valid zope partiticipations <Launchpad Foundations:New> <https://launchpad.net/bugs/623199>
<wgrant> thumper: How hard would it be to remove the table itself, and not just the primary key?
<thumper> :)
<thumper> wgrant: there are half a dozen use-cases for it
<wgrant> thumper: I mean, it's all redundant... but I guess postgres might not be excellent at dealing with that sort of data.
<thumper> which I'd like to replace
<lifeless> well
<lifeless> for one, it needs to be migrated from SQLBase
<lifeless> if it hasn't already
<thumper> lifeless: it needs to be stabbed in the neck
<wgrant> lifeless: No, it needs to be deleted.
<thumper> wgrant: hi five
<lifeless> 'to delete the id column you cannot use SQLBase'
<StevenK> It's moving, kill it!
<thumper> or high five
<wgrant> lifeless: I want to delete the *table*.
<lifeless> I was answering your fairly specific question
<wgrant> Not just the column.
<lifeless> someones
<thumper> wgrant: jam had some interesting ideas to make it better
<wgrant> StevenK: More "It's redundant, huge and slow, kill it!"
<lifeless> wgrant: preprocessing is pretty standard for graph problem domains
<lifeless> this particular preprocessing layout isn't ideal.
<lifeless> but running from the adjacency list is also going to be terrible.
<lifeless> if you're interested in tackling this, RMQ transform papers are a good place to start to get ideas.
 * thumper EODs again
<lifeless> something like the graph db stuff twitter has opened source might be nice too
<mrevell> Morning
<jml> mrevell, good morning.
<jml> lifeless, what about storing it all in one big 2a repo?
<StevenK> wgrant: Suprised you haven't commented on my latest branch, Stalker!
<jml> lifeless, hey, you know what would help me write cleaner code?
<StevenK> wgrant: And, "It's moving, kill it" is a movie reference, I just can't remember which.
<jml> lifeless, usability improvements to testrepository :P
<wgrant> StevenK: Uni workload is making my stalking less effective, sadly.
<wgrant> A GINA BRANCH!?
<wgrant> What is this?
<wgrant> Nobody works on gina.
<lifeless> jml: yes, they are really high up
<StevenK> wgrant: I just proved you wrong :-P
<wgrant> :(
<stub> We delete the BranchRevision.id column because it is unnecessary and dropping the entire table is a larger, unscheduled and not ready to code task.
<stub> Think of it like getting 10% more effective ram on the master database.
<stub> Well, maybe not that much but quite noticible.
<stub> noticeable
<lifeless> mpt: hey
<mpt> hi lifeless
<lifeless> mpt: so, have you heard anything negative about the search changes we did?
<mpt> lifeless, nothing at all, negative or positive :-)
<lifeless> well, no noose is good noose
<wgrant> Search was bad... it's now very slightly worse.
<lifeless> wgrant: really ?
<lifeless> wgrant: which search is worse ?
<wgrant> Dupe search.
<lifeless> you're finding it noticable less powerful ?
<lifeless> or you've seen folk comment on it ?
<wgrant> I've found a couple of cases where it wasn't really optimal.
<wgrant> Specifics I cannot currently recall.
<lifeless> ok
<lifeless> and that you felt sure the other behaviour would have done bette r?
<thumper> stub: I'll look at it with my new fella
<stub> Ta. There was work done at the Epic. jtv will recall the details. I don't recall who was actually doing the work and how far it got.
<jtv> huh?
<stub> jtv: Dropping BranchRevision.id
<jtv> ah
<jtv> I left it in Jon's capable hands, pushing him from time to time to bloody get on with it.
<jtv> As I recall, we:
<jtv>  * Stormified the class.
<thumper> jtv: really?  did it land?
<jtv> The stormification did.
<thumper> jtv: but not the id column removal?
<jtv> Then, we removed a bunch of references to the id.  Not sure whether that landed.
<thumper> jtv: thanks, I'll chase jam in the morning
<jtv> And I prepared a branch for him to work off of that made it use (branch, revision) as the primary key.
<jtv> Is "bloody" a documented permitted splitting of infinitives?
<jml> Fowler's article on the subject is worth a read.
<bigjools> to go bloody?  or to bloody go?  valid, and very different :)
<mpt> To bloody go where no vampire has gone before!
<stub> stop bloody wasting time
<stub> to boldly split infinitives that no man had split before
 * bigjools eats shoots and leaves
<jtv> noodles775: arghâwhat script produces the BuildFarmJobs again?
<jtv> or maybe bigjools knows
<noodles775> jtv: No script produces BuildFarmJobs on their own?
<bigjools> jtv: what do you want to do?
<noodles775> When BinaryPackageBuilds are created, BFJs are also created...
 * noodles775 thinks that's a better question.
<jtv> Okay, when are BinaryPackageBuilds created?
<bigjools> jtv: what do you want to do?
<jtv> I want to verify that pushing an intltool-enabled branch that's set up to generate translation templates is really generating TTBJs
<bigjools> ok
<wgrant> The scanner creates TTBJs.
<jtv> wgrant: thanks
<wgrant> So 'make sync_branches' will do it locally.
<jtv> This is on stagingâ¦  it's one of those changes that need verification on each environment we deploy them in.
<wgrant> (also, TTBJs aren't BFJs yet -- but I hope you're going to fix that soon?)
 * bigjools hopes so too
<jtv> Yes yes yes, it's on our shortlist!
<bigjools> stub: I'm trying to get dogfood running and it's bitching about patch-2207-00-0.sql being in the DB but not in the tree.  HALP.
<stub> bigjools: I suspect you have patch-2207-* files in database/schema
<bigjools> yes :/
<bigjools> thanks
<lifeless> well, I'm going to halt(); this fallout is annoying :(.
<lifeless> so gnight.
<wgrant> :(
<wgrant> My branch to eliminate BuildBase is massively oversized.
<wgrant> Too much code to move around.
<jml> wgrant, by oversized, do you mean "could be split up" or do you mean "more than 800 lines"?
<wgrant> jml: The latter.
<wgrant> It could possibly be split, but it's mostly just moving content from a couple of files to a couple of other files.
<jml> wgrant, I'm happy to do the review
<jml> although maybe not before you sleep.
<wgrant> It's not exactly pretty yet, but I figure I'll get it all moved across before cleaning up.
<wgrant> I'll propose the review shortly.
<jtv> henninge: any luck with the recife branch?
<henninge> oh, you missed that, I guess...
<jtv> yes, I was out for lunch
<henninge> jtv: It's landed.
<jtv> thanks henningeâI'll land my branches
<henninge> jtv: .. and you were disconnected
<wgrant> jml: https://code.edge.launchpad.net/~wgrant/launchpad/buildbase-must-die/+merge/33505, if you have time.
<jml> wgrant, sure. I'll do that now, in fact.
<wgrant> Ah, I feel less bad with that 1800-line rootsite change having just landed :)
<jml> something I'm not going to ask you to change, but feel is worth mentioning:
<jml> > + Â  Â  Â  Â  Â  Â build.dependencies = unicode(slave_status.get('dependencies'))
<jml> ^^^ that is a point of fragility.
<wgrant> Indeed it is.
<wgrant> I've noticed that many times, but was never sure how to fix it.
<wgrant> Since it is really a bytestring.
<deryck> Morning, all.
<jtv> hi deryck
<jml> wgrant, I guess for a start I would spell it as slave_status.get('dependencies').decode(), give it an encoding and tell it how to handle encoding failures
<jtv> Yay everyone, staging's back!
<wgrant> jml: Well, yes, but the encoding is probably just ASCII, and I don't really know how best to handle failures here.
<wgrant> So it might as well just crash ;)
<jml> wgrant, perhaps. depends a lot on how helpful Python's exception is.
<jml> _handle_status_OK is... interesting.
<wgrant> Um, yes.
<wgrant> It's pretty awesome.
<wgrant> It's also largely untested :)
<bigjools> which planet's definition of awesome?
<jml> I meant "interesting" in the "May you live in interesting times" sense.
<wgrant> Soyuz brings quite enough interestingness, TYVM.
<wgrant> Hmm. LP looks nice in UbuntuBeta.
 * bigjools orders another kilo of coffee from HasBean
<jml> wgrant, ooh, has it landed?
<wgrant> jml: Apparently.
<wgrant> Since launchpad.dev now uses it.
<wgrant> Although it makes the badly aligned sprites look even more badly aligned.
<jml> :(
<jml> hah, but one revision off from being on edge.
<wgrant> :(
<jml> wgrant, review done.
<wgrant> jml: :(
<wgrant> But will fix.
<jml> wgrant, thanks.
<jml> wgrant, I always feel a little lousy asking people to change code they've pretty much only moved, and for enforcing the trivial points of our coding standard, so it's very much appreciated.
<wgrant> I'm all for enforcing the coding standard as much as possible.
<wgrant> I was just hoping to avoid it in this already massive branch. But the changes you've requested are tiny, so I'll do them.
<jml> ta
 * bigjools is currently making a lp.soyuz.enums
 * wgrant stabs the test suite for not working when a local buildd is already running.
<jml> wgrant, ping me once they're pushed up. I'll submit to ec2 immediately & then go to lunch instanter.
 * bigjools sighs at PackageCopyStatus.CANCELING and PackageCopyStatus.CANCELLED
<wgrant> jml: Sure. It'll be a few minutes, since I need to do a test build manually.
<jml> np.
<bigjools> are we enforcing the multiline import style in doctests?
<jml> bigjools, probably yes.
<wgrant> But they weren't migrated.
<bigjools> exactly
<jml> wgrant, a sound point.
<bigjools> I'm not convinced it's a good idea in doctests
<wgrant> Alternatively, we could just enforce no doctests.
<bigjools> heh
<bigjools> I like doctests when they're done properly
<bigjools> admittedly I don't like much here
<jml> tbh, I don't care as much about the coding standard within doctests.
<jml> since it's not actually code.
<bigjools> good point
<jml> but I also see little point in being inconsistent
<jml> especially since the documents have no target audience
<jtv> mrevell: don't forget to dig up the text & link for the popup balloonsâ¦ could you email them to me?  I'm pretty much at the point where my egg needs a chicken.
<jtv> Or vice versa.
<mrevell> jtv, Yes, no problem. Will do that now.
<jtv> thanks :)
<wgrant> bigjools: I am quite a fan of the new buildd-manager design.
<bigjools> glad to hear it
<bigjools> I lost most of my hear, some sweat and some blood making it
<wgrant> Now we just have to fix updateStatus and others to stop pretending that it's all synchronous.
<bigjools> yes, I have a sprint planned in September with jml to fix that
<wgrant> Excellent.
<jml> there will be a method that does a scan and returns a Deferred that fires when that scan is done.
<jml> e
<jml> and there will be much rejoicing among the people.
<bigjools> also jelmer has a fix in progress that puts build uploads in a queue that we can process outside of b-m
<wgrant> Yup.
 * jml relogs.
<wgrant> I wonder how well it will scale after that.
 * bigjools rejoices with jml
<bigjools> jml: but it's not as simple as that - there's a bunch of synchronous XMLRPC that we need to convert as well :)
<wgrant> Currently RecordingSlave lies by reporting success for everything :(
<bigjools> yeah, I have that in my sights
<bigjools> we can get rid of it and turn the existing BuilderSlave into a twisted implementation
<wgrant> And that means we have a good reason to kill slave-scanner.
<bigjools> we don't already?
<wgrant> IIRC you wanted to keep it.
<wgrant> It's only like 30 lines, anyway.
<bigjools> I did, but I rescind that desire
<wgrant> Yay.
<wgrant> Since buildd-manager sucks less now?
<bigjools> since we have more than zero confidence in it now :)
<wgrant> Heh.
<jml> bigjools, sure. nothing is ever that simple. but "eyes on the prize" and all that.
<bigjools> yarp
<maxb> Anyone happen to know what to pass into archive.syncSource(to_series=....) in the api ?
<noodles775> The distroseries name.
<maxb> >>> ta.syncSource(from_archive=fa, source_name='subunit', version='0.0.4-4ubuntu4', to_pocket='Release', to_series='jaunty')
<maxb> 400 Bad request: subunit 0.0.4-4ubuntu4 in hardy (same version already has published binaries in the destination archive)
 * noodles775 is just reading the api doc.
<wgrant> maxb: include_binaries=True
<wgrant> Hm.
<wgrant> But they're different archives?
<wgrant> Must already be in the target somehow, anyway.
 * maxb boggles... you're rigjt I was missing include_binaries=True in my interactive example... but my script which failed originally did have include_binaries=True
<wgrant> So it fails the same way, even with include_binaries=True?
<maxb> Yes
<maxb> except not any more, because the publisher has run
<wgrant> Ah.
<maxb> The scenario is trying to syncSource the same source+binaries that is published in multiple series in one archive, into the same multiple series in another archive
<jml> gror
<bigjools> jml: did you forget your pills today?
<jml> bigjools, no. my IRC proxy was playing up.
<jml> now, some 90 minutes later than intended, I'm off to get lunch.
<leonardr> jamesh, if you have a minute i'd like you to look at a workaround i wrote for bug 620508
<_mup_> Bug #620508: Slicing a ResultSet breaks subsequent len() calls. <Storm:New> <https://launchpad.net/bugs/620508>
<leonardr> jkakar, if you're available, you could do it instead
<noodles775> james_w: did you see the second question in my lp-dev email (re. regarding comments per package or per version). (it was in a second email after my fat fingers sent the first prematurely ;) ).
<james_w> yes, replying now
<noodles775> Ta.
<bigjools> james_w: hi, while you're around, I need to remind you to add AGPL headers, module docstrings and __all__ to your new files :)
<james_w> yeah, I sometimes forget, sorry
<bigjools> your reviewer should have seen that :(
<noodles775> (see standard_template.py and standard_test_template.py in the lp root folder)
 * bigjools is still not sure about seeing PackagePublishingPocket in registry.interfaces
<sinzui> It does not belong there
<sinzui> bigjools, wgrant and I talked about moving it last year, but neither of us did it
<bigjools> didn't jml put it there?
<jtv> mrevell: nag, nag.  :)
<jml> yes I did.
<jml> in early 2009, if memory serves.
<jml> lp.code needs some way of referring to things like "karmic-backports"
<bigjools> I think code depends on Soyuz really.
<bigjools> Code, even
<jml> that aspect of lp.code (i.e. basic branch mgmt) has nothing to do with archives, build farms, upload servers or anything else.
<bigjools> pockets are a soyuz thing
<sinzui> baltix, fedora and debian do not use them. Only Ubuntu and future derivatives can use them
<jml> I would be much more comfortable with code depending on soyuz if soyuz were itself more clearly defined
<bigjools> what is not clear about it?
<jml> sinzui, well, the fact that code needs to care about pockets at all is a bug.
<sinzui> yes
<jml> <jml> that aspect of lp.code (i.e. basic branch mgmt) has nothing to do with archives, build farms, upload servers or anything else.
<jml> I don't want code to depend on all of that.
<jml> and yet all of that is frequently called "soyuz"
<bigjools> build farms are not soyuz
<bigjools> maybe I should put the publishing definitions in archivepublisher
<jml> if there were a Suite class, where would it live?
<bigjools> soyuz
<jml> but distro would stay in registry?
 * jml thinks
<bigjools> yes
<bigjools> soyuz is responsible for setting up and managing suites
<jml> I guess I don't know how distroseries & suites relate outside of an Ubuntu context
<jml> I mean, the current relationship is a distroseries has many suites; a suite has a single distroseries
<sinzui> bigjools, jml, distroseries appears to be a nexus of circular imports. I do not know how to separate soyuz and registry. I am not sure what comes first, packages, or distros
<bigjools> jml, sinzui: in the Debian world, suite is arbitrary.  Only Ubuntu formalised that into series-pocket.
<jml> bigjools: yeah, I know.
<bigjools> jml: to refine your statement, a distrseries can have one or many suites
<jml> bigjools: is there any qualitative difference?
<bigjools> sort of, if there's only one suite then its name is the same as the series
<jml> isn't that an implementation detail?
<jml> I'm trying to figure out what "Target to release" means in relation to suites, if anything.
<bigjools> what is your context for "target to release" ?
<jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/622290
<_mup_> Bug #622290: Color of info box varies after subscribing to a branch <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/622290>
<jml> ugh, sorry.
<jml> https://bugs.edge.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/178038
<_mup_> Bug #178038: npviewer.bin crashed with SIGSEGV  <apport-crash> <metabug> <nspluginwrapper (Ubuntu):Confirmed for anthonyhunt55> <https://launchpad.net/bugs/178038>
<jml> any distro bug.
<bigjools> ok
<bigjools> so they don't care about suites
<bigjools> only the series
<bigjools> the suite is selected on the basis of archive management
<bigjools> (in the case of Ubuntu)
<jml> hmm. perhaps it's N:N rather than 1:N, and only 1:N for Ubuntu.
<bigjools> that wouldn't make sense to me I don't think
<bigjools> but maybe I'm too used to the status quo
<jml> well, what I really mean is that a suite has a single distro, rather than a distroseries
<jml> but of course that would make the way we currently do branches very tricky.
<jml> I should draw a picture.
<jml> I should make it easier to draw computer pictures
<jml> Or someone should port OmniGraffle to Linux.
<jml> back soon.
<jml> back
<jml> wondering if I should buy http://www.amazon.co.uk/Fundamentals-Queueing-Theory-Probability-Statistics/dp/047179127X/ref=sr_1_1?ie=UTF8&s=books&qid=1282663085&sr=8-1
<bigjools> jml: I fell asleep during a queuing theory lecture
<jml> bigjools, what? were you marked on attendance at your university?
<bigjools> no
<bigjools> it was just so uninteresting
<jml> hah
<jml> it appears to be rather useful though.
<bigjools> that's the bloody annoying part of it :)
<jml> also, I have great faith in the ability of most lecturers to make any topic as dull as "Stephen Hawking reads the Yellow Pages"
<jtv> jml: you attended that one?  How did it end?
<jml> jtv, a surprise impromptu concert by ZZ Top
<jtv> Man, I knew there was a surprise ending!
<jtv> I'm definitely going next time.
<bigjools> jml: one of my lecturers has a sex change.  That was the most interesting thing about the lecture.
<bigjools> had*
<jml> bigjools, not during the lecture, I hope.
<bigjools> he announced it at the end of one, and turned up at the next as a bird
<bigjools> Goodbye Frank, hello Frances
<jml> I'm sorry, but now I've got a picture of Owl from Winnie the Pooh giving you a lecture on queueing theory
<noodles775> On that note, 'evening all :)
<leonardr> salgado, quick question. given a request object, how can i determine which oauth token it was signed with?
<leonardr> i would expect to see that in IOauthSignedRequest, but that's just a marker interface
<salgado> leonardr, I think you'll have to poke at the request to get the OAuth header and extract the token ID from there
<salgado> IIRC, when we do that to authenticate, we extract the person associated with the token and throw the token away
<salgado> so you could also change that code to store the token somewhere along with the principal
<salgado> get_oauth_authorization(request) is how you'd go about extracting the OAuth header
<leonardr> salgado, i don't need the token per see, i just need principal.access_level
<leonardr> that should do nicely
<jml> g'night all. would really appreciate reviews of my two small outstanding patches.
<leonardr> i realize it may seem strange for me to ask this question, but has anyone published a field that's writable normally but read-only through the web service?
<lifeless> moin
<jelmer> hi lifeless
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.09 | Performance Tuesday! | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.09 | PQM is OPEN | firefighting: - | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews
<rockstar> lifeless, it's still Tuesday last time I checked... :)
<lifeless> rockstar: I can put it back if you like, but its been 24 hours; every has woken up to it like that on their tuesday :)
<lifeless> rockstar: would you like it back? Are you doing performance?
<rockstar> lifeless, I'm just bustin' your chops.  :)
<lifeless> 'pow'!
 * beuno stops doing performance
<rockstar> lifeless, actually, I am doing performance checking on the javascript that I'm writing.
 * rockstar has nice tools for that, so it's easy.
<lifeless> rockstar: nice
<lifeless> abentley: did you want to talk more ?
<abentley> lifeless, you bet.
<abentley> lifeless, https://wiki.canonical.com/Launchpad/NewTaskSystemRequirements
<abentley> lifeless, apparently, skype isn't a reliable system.
<mwhudson> lifeless: did you get an answer to your question?
<lifeless> mwhudson: which one?
<lifeless> abentley: sorry, was waterinating and chatting with Lynne
<mwhudson> <lifeless> is calling 'login(ANONYMOUS, ScriptRequest())' there sane ?
<mwhudson> <lifeless> or should I just make my code (which is the sql gathering oops helper) silently do-nothing ?
<mwhudson> <lifeless> (its defined as doing nothing in that case anyway)
<mwhudson> <lifeless> mwhudson: ^ I hear you've done a bit of out-of-appserver-stuff, care to comment ?
<lifeless> oh right
<lifeless> see my mail to the list
<lifeless> I got a bit of and answer
<mwhudson> ah ok
 * mwhudson -> email 
<thumper> morning
<jelmer> 'morning thumper, mwhudson
<abentley> thumper, morning.
<thumper> abentley: hi
<lifeless> mwhudson: see my changes to adapter.py to see the sort of mess i'm making
<jelmer> thumper: So, I'm not really sure what to do about the chicken repository. It seems to be broken on the server side now.
<beuno> loggerhead hates bzr!
<abentley> thumper, rockstar, I need to get going at 5:30.  Do you want to have a stand-up now?
<beuno> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/builtins.py
<jelmer> thumper: I can confirm that at least some of the other http repositories get fixed by the newer version of bzr-git.
<beuno> it won't load that for me
<beuno> oh, and NOW it does!
<rockstar> abentley, it looks like thumper's busy with flacoste-like calls right now.
<jelmer> beuno: it seems to be doing that for a lot of branches - working after one or two refreshes
<thumper> abentley: I'm talking with gary right now
<rockstar> abentley, I'm happy to chat with you right now, but that might defeat the purpose...
<thumper> abentley: if you want to chat with rockstar, he can fill me in later :)
<abentley> thumper, isn't rockstar also unavailable later on?
<beuno> please make bzr files smaller so loggerhead is happy. kthxbye
<thumper> abentley: he's coming back :)
<rockstar> abentley, yeah, I just have class, and then I'll be back.
<abentley> rockstar, okay, so let's chat.
<rockstar> abentley, cool.
<mwhudson> beuno: in this case they should stop editing it so often!
<mwhudson> beuno: of course, loggerhead shouldn't annotate by default either
<beuno> we should contract someone to work on loggerhead
 * beuno ducks
<mwhudson> fantastic idea
<beuno> sinzui, I'm lovin the project set-up of each app
<beuno> the progress bar not so much, as it may be incomplete for ever, which is a bit awkward
<beuno> but it's awesome
<sinzui> beuno, not forever, only for the next week
<beuno> sinzui, aha!  I forgot you always have a deck of cards up your sleeve
<sinzui> beuno, we are landing the changes needed to make the progress bar now. We are landing the new app front pages this week and next,..
 * beuno will keep his eye on it
<sinzui> Apps are off unless you tell Lp how it is used.
<sinzui> I expect a lot of blueprint pages to disappear until users users^h masochists decide they want to enable them
<beuno> heh
<beuno> still no takers to fix blueprints?
<sinzui> many volunteers, in the bug comments, but not many landings
 * beuno still remembers the 2 weeks he spent in blueprints and shivers
<rockstar> beuno, mtaylor said he wanted to fix blueprints
<beuno> brave man
<sinzui> The notification bugs are at least 2 man-months of work
<wgrant> sinzui: It's really tempting to hide the option to turn Blueprint on unless people go looking for it.
<sinzui> wgrant, I think we can accomplish that in the next 7 days
<sinzui> really
<rockstar> I want the same option for Answers.
 * rockstar heads to class.
<wgrant> Because Blueprint looks awful, and it's not clear that it's unmaintained.
<sinzui> that too will happen
<wgrant> So it should be hidden.
<sinzui> Apps will behave like bugs. It is not on unless you choose to enable them. It can be implicit in the case or branches.
<wgrant> Code should always be available. But the use flag needs to be explicit.
<sinzui> We want people to tell use when the branch is. It is okay to be a mirror, "just tell us"
<wgrant> Ah, right.
<mtaylor> beuno: yup. I'm going to get them all fixed
<sinzui> mtaylor, I assume you are bring a portable army to do that.
<beuno> mtaylor, I have  "personal heroes" page on my blog for people like you
<mtaylor> sinzui: trying :)
<sinzui> just exposing api means you do not need to fix a lot of the issue...just build a simple replacement app
<rockstar> sinzui, the problem with that is that the blueprint api is the scariest part.
 * rockstar heads out for real this time.
<wgrant> jml: Thanks for landing that.
<thumper> mtaylor: hey
<thumper> mtaylor: getting started on LP hacking now?
<thumper> mtaylor: also the location of the LP epic in January has been set as Dallas, TX
<wgrant> Dallas again!?
<mwhudson> wgrant: i think bigjools is very happy about this, to judge by fb
<thumper> yup
<wgrant> Heh.
<sinzui> :(
<wgrant> mwhudson: I saw that last night, but didn't know what it referred to...
<sinzui> I may have to contract marburg that week
<thumper> sinzui: ?
<mwhudson> sinzui is not compatible with texas
<gary_poster> sinzui: hey.  If I want to change some css, is modifying style-3-0.css the right way to go to a first approximation?
<mwhudson> (famously)
 * sinzui does not understand why Canonical does not see the upper or lower parts of North America as legitimate places to hold a sprint
<thumper> sinzui: like Mexico?
<sinzui> sure
<sinzui> Canada might have a conference facility
<gary_poster> running, back later
<sinzui> gary_poster, style-3-0.css.in if it is a non-app-specific hack
<mtaylor> thumper: oh cool
<mtaylor> thumper: and no - but _real_soon_now_
<lifeless> mwhudson: if I can get some cycles form you on this issue I would love that
<mwhudson> lifeless: i've read all my other mail now :-)
<mwhudson> and am reading yours carefully
<lifeless> mwhudson: thanks!
<mwhudson> lifeless: gnnaaaaaaaaar i hate this duplication of information across different thread-locals :(
<lifeless> mwhudson: yes, and I want to reduce it
<lifeless> the primary lever seems to be 'really make interaction^WIRequest-in-an-interaction the context. I mean really.'
<mwhudson> yeah quite
<lifeless> if thats wrong headed I'd like to back away quickly
<mwhudson> as discussed, no thread-locals would be nice
<mwhudson> but if we have to have one for now, the interaction seems like it should be it
<lifeless> if its right headed, I need some clue inserted - or collaborated on - to get over the initial hump
<lifeless> afk for a few, need to unload more wood
<thumper> where have the query counts gone from the bottom of the pages?
<thumper> and why is LP even slower than normal today?
<thumper> this is insane
<mwhudson> thumper: they're still there for me?
<wgrant> Query counts are still there for me too.
<mwhudson> they might not be present on pages that don't use the main template, or something like that
<wgrant> And it was really slow yesterday, but it's not so bad now.
<thumper> 41 seconds to approve a code import
<thumper> no time out
<thumper> mwhudson: this was for a branch page
<thumper> I think it didn't get the entire page
<thumper> as it was missing everything after the ( in the footer
<mwhudson> thumper: as per rob's mail, maybe sending mail from the webapp is slower for some reason?
<thumper> ?!?
<thumper> that wouldn't impact loading a page
<thumper> unless it was queued for ages
<thumper> waiting for a thread
<mwhudson> *shrug*
<mwhudson> just a guess
<lifeless> back
<lifeless> its entirely possible that a slow mail dispatch routine stalls a webapp request
<lifeless> there are two bugs
<lifeless> one, on foundations, that this doesn't timeout-and-go-boom
<lifeless> two, that we can't tell where the time is going.
<thumper> yes
 * thumper goes to encaffeinate
<lifeless> third bug
<lifeless> that these external calls are not equipped with timeouts
<wgrant> Why karmaactions in the DB?
<wgrant> That's insane, and makes my bootstrap script fragile :(
<lifeless> wgrant: expand please :)
<lifeless> mwhudson: so, I tried using ScriptRequest
<lifeless> but it doesn't implement IRequest
<lifeless> subclassing BrowserRequest made it start failing to assign during __init__ :(
<mwhudson> well
<lifeless> I could use LaunchpadTestRequest in script/__init__.py but it may make some people cry
<wgrant> lifeless: KarmaActions are basically constants stored in the DB. Code expects them to be there. If one is added to the code and you don't add it to the DB, the code will crash.
<mwhudson> the fact that we're calling get_current_BROWSER_request suggests to me that it's perhaps not the thing to use in non-webapp specific code
<wgrant> They're rather like celebrities, except that they'd be much better handled by having a dict in the tree somewhere.
<lifeless> wgrant: enums ?
<wgrant> lifeless: Or that.
#launchpad-dev 2010-08-25
<lifeless> enums seems to be our canned answer for this
<mwhudson> i think it's a big case of WHUI
<lifeless> WHUI ?
<mwhudson> We Haven't Used It
<mwhudson> a SteveA-ism
<lifeless> google was ... un helpful
<mwhudson> something like KarmaAction is in the db so we can tweak the constants to adjust the way karma is allocated without landing code changes
<lifeless> mwhudson: so, we're talking IRequest
<mwhudson> but of course we don't
<lifeless> etc
<mwhudson> stub will know more
<mwhudson> lifeless: i'm actually replying to your email
<lifeless> mwhudson: cool
<lifeless> mwhudson: the big question, is an unknown
<lifeless> mwhudson: is it shallow enough I should plunge on and doit
<lifeless> mwhudson: or should I thread-locals-it.
<mwhudson> lifeless: what's 'it' ?
<wgrant> lifeless: 'karmacategories' in http://bazaar.launchpad.net/~wgrant/launchpad/bootstrap-db-from-scratch/annotate/head:/utilities/bootstrap-lp-db is the data in question.
<lifeless> mwhudson: it is
<lifeless> mwhudson: making scripts have an IRequest always, so that when they do sql it is logged in my new code
<lifeless> the second it
<lifeless> is
<lifeless> the new code : change requesttimeline to be a threadslocal thing
<mwhudson> lifeless: ok, my email is nearly done
<mwhudson>     # This is a convenient hack to set up a zope interaction, before we get
<mwhudson>     # the proper API for having a principal / user running in scripts.
<mwhudson>     # The script will have full permissions because of the
<mwhudson>     # PermissiveSecurityPolicy set up in script.zcml.
<mwhudson> ha ha
<mwhudson> i wonder when that was written
 * mwhudson bets on 2005
 * mwhudson wins
<mwhudson> timestamp: Tue 2005-04-12 09:37:50 +0000
<mwhudson> from the arch days
<mwhudson> steve.alexander@canonical.com/launchpad--devel--0--patch-368
<mwhudson> lifeless: ok, mail sent
<lifeless> thanks
<lifeless> mwhudson: followup sent btw
<mwhudson> lifeless: i replied one more time, happy to talk about it in irc now :-)
<mwhudson> although i don't think there's much need
 * mtaylor thinks you're both wrong and obviously everything should be re-written in google go
 * mtaylor falls on the floor laughing
 * mtaylor is obviously in an odd mood
<StevenK> mwhudson: Patches welcome
<StevenK> Doh
<StevenK> IRC tab fail :-(
<lifeless> mwhudson: I think I'm good.
<lifeless> mwhudson: I guess that under setupInteractionByEmail(ANONYMOUS) in script base
<lifeless> mwhudson: I'll add something??? that sets up a participationwithannotations ?
<mwhudson> lifeless: setupInteractionByEmail takes a participation as an argument
<lifeless> mwhudson: yeah
<lifeless> actually though
<lifeless> set_request_started is where scripts expect to do stuff
<lifeless> so *it* needs to check and see if there is a participiation...ICanHasAnnotations, and if not setone up
<lifeless> we still need to unify these two things
<lifeless> I like your approach, but I'm not sure we don't actually want - eventually - scripts to say they are in requests via participations rather than set_request_started
<mwhudson> i admit i don't really know what set_request_started is about
<mwhudson> lifeless: in the particular case of checkwatches, it does it's one interaction management
<mwhudson> -'
<lifeless> mwhudson: kindof-management
<lifeless> mwhudson: but yes
<mwhudson> lifeless: it looks like it probably suffers locally from the kind of confusion it would be good to clear up globally
<lifeless> with_interaction looks like exactly what needs clearing up
<lifeless> vis-a-vis transactions, security & context
<lifeless> also @statement_logging is just bong
<mwhudson> i'm not sure i'm correct or expressing this clearly
<mwhudson> but i wonder if there's a bit of a tension between things that don't care at all about participations (like most scripts and tests) and the few things that do (like checkwatches)
<lifeless> most scripts do work on behalf of someone
<mwhudson> also, i wonder if thinking about how you'd like stuff bundled up in an oops report is a good guideline towards how long your participations should be current for
<lifeless> the work doesn't just 'appear'
<lifeless> I think that bundling point is exactly on the spot
<lifeless> its certainly how I think abou tit
<lifeless> excuse me; brain flagging food needed
<mwhudson> so for example, each job you process in a job running script should have it's own participation
 * mwhudson reads errorlog.py, is surprised to find it reads db statements out of the request, realizes it's because lifeless' branch is merged in
<lifeless> mwhudson: huh, no.
<lifeless> mwhudson: oh righ, locally perhaps :)
<lifeless> anyhow, our webapp adapter is essentially tracking units of work
<lifeless> called 'requests'
<lifeless> I think that this is fine and sensible, even for scripts, but what isn't fine or sensible is having this separate to the object representing the work - the IRequest
<wgrant> ARGH.
 * wgrant curses whoever decided that doctest log levels should be specified in the test registration, and should not be overridable within the test itself.
<lifeless> wgrant: welcome to doctests
<wgrant> Baaah.
 * StevenK finishes QAing gina
<StevenK> That was ... fun
<wgrant> It's even more fun when you have to do it locally, because there are no configs for that.
<StevenK> I have mawson for that sort of thing
 * wgrant fixes build logging.
<wgrant> But buildd-slavescanner.txt seems to want me dead.
<StevenK> wgrant: Not just you, I suspect.
<wgrant> Rarely have a found a doctest so slow and seemingly so fragiley malevolent.
<lifeless> mwhudson: does my point about 'on behalf of' make sense?
<lifeless> hmm
<mwhudson> lifeless: yes, but i'm not sure how relevant it is
<StevenK> wgrant: I see your buildd-slavescanner.txt and raise you gina.txt
<wgrant> StevenK: True. That one is really really slow.
<lifeless> mwhudson: thats interesting; I thought it was the heart of the issue
<mwhudson> lifeless: scripts use the PermissiveSecurityPolicy by default, so in some sense at least the current principal doesn't really matter
<lifeless> mwhudson: I think the PSP is essentially undesirable
<mwhudson> lifeless: maybe
<lifeless> if:
<lifeless>  - we started scripts with an anonymous participation with a stubbish request
<lifeless>  - and the regular sec policy
<lifeless>  - and they called login() as soon as they identified the work they were doing
<lifeless> would we need the PSP at all ?
<mwhudson> lifeless: well
<mwhudson> there's stuff like IBranch['updateScannedDetails'] that the scanner calls
 * mwhudson pauses, backtracks
<mwhudson> lifeless: i'm not sure this is really a good example, but there's a branchChanged method on branches
<mwhudson> this is called by codehosting to record the format & tip of a branch
<mwhudson> no this is a really bad exmple
<mwhudson> lifeless: basically the point i'm trying to make is that i have this feeling that many scripts call 'internal' apis
<mwhudson> that we wouldn't want the user to call via the webservice api say
<mwhudson> for example, the stuff the build manager calls to record that a build has finished
<lifeless> so thats a great example
<lifeless> there is a nonce
<lifeless> which is security sensitive
<wgrant> It's not a nonce, and it's not security sensitive.
<wgrant> But OK.
<lifeless> wgrant: if we want to allow the buiild slaves to push results, it becomes security sensitive
<lifeless> wgrant: and I think it was julian who called it a nonce.
<lifeless> there is this thing
<mwhudson> :)
<lifeless> if you don't have it, we would not believe a claim that <data> is the result of a build
<lifeless> if you do, we can believe that.
<wgrant> (That's one explanation for its existence, but I don't think it's correct. Nobody really knows.)
<lifeless> wgrant: it was added in to support slaves pushing back
<lifeless> wgrant: I know this because I was tolk thats why
<lifeless> its a WHUI case, but one we should.
<lifeless> anyhow
<lifeless> *IF* you imagine that we submit build results via the API
<lifeless> I imagine we'd check something like
<lifeless> source ip address (are you a build slave)
<lifeless> and
<lifeless> (do you have the right nonce)
<lifeless> if you have those two things, you can say a build is finished, if you don't, you can't.
<lifeless> *noone* except the dispatcher can read the nonce
<lifeless> (this is ideally, not describing what we have today)
<lifeless> mwhudson: anyhow, I think it fits fairly well; finishing a build is conceptually a request from the builder
<lifeless> mwhudson: garbo tasks *don't* fit well unless we have a celebrity with the right permissions
<mwhudson> lifeless: i guess where this leads to is that, yes, we could replace the use PSP in scripts with something else
<lifeless> but, coincidentally, thats exactly what we do do for the DB; I don't see why we shouldn't do it higher up too.
<mwhudson> but i don't think you could easily replace it with the LaunchpadSecurityPolicy
<mwhudson> because that's all based around principals that are Persons
<lifeless> mwhudson: I think a good mental exercise is to ask 'what would it take to make script X an API client
<lifeless> we probably need to get pgbouncer installed at some point
<lifeless> but even then, it would be nice to have less sources of idle connections
<mwhudson> lifeless: well funnily enough i did that fairly recently
<lifeless> mwhudson: and what did it entail ? :)
<mwhudson> i changed code imports to do all their communication with the db via the internal xml-rpc server
<mwhudson> lifeless: calling removeSecurityProxy a lot :(
<lifeless> mwhudson: thats kindof cheating
<mwhudson> yep
<lifeless> mwhudson: can we do better ?
<mwhudson> not even kindof
<mwhudson> lifeless: i don't konw
<mwhudson> lifeless: i wrote some mails about this this a while back, lemme hunt
<mwhudson> lifeless: does saying "Message-ID: <4B8C8089.1030105@canonical.com>" help you with your mail setup?
<lifeless> hahaha
<mwhudson> lifeless: or http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg02733.html
<lifeless> mwhudson: subjects are normally enough
<mwhudson> "using PermissiveSecurityPolicy when serving private xmlrpc requests"
<lifeless> thanks
<mwhudson> mutable global state aaaaaaaaaaaaaaaa
<lifeless> mwhudson: what just  bit you ?
<lifeless> also, you know we have a database, right ?
<mwhudson> lifeless: the thing i refer to in the first mail in that thread
<mwhudson> it's not really possible to use a different interaction class for a given request
<mwhudson> interaction class == security policy btw
<lifeless> so
<lifeless> I think I'm fairly happy with saying:
<lifeless>  - PSP is almost certainly covering bugs and security holes
<lifeless>  - it divides our code arbitrarily and makes moving code out of web requests into backend systems hard and fragile
<lifeless>  - I don't see, and haven't seen a case for PSP existing other than 'its how we made stuff work way back when'
<mwhudson> maybe a special principal that LaunchpadSecurityPolicy does something different with would be ok
<mwhudson> or special class of principals
<lifeless> mwhudson: I don't see why impersonation isn't totally sufficient
<lifeless> have a privileged version of login()
<wgrant> You also need a superpowered principal.
<lifeless> grant script principles access to that
<wgrant> Since lots of operations shouldn't even be possible for ~admins.
<mwhudson> lifeless: you said earlier that "<lifeless> mwhudson: anyhow, I think it fits fairly well; finishing a build is conceptually a request from the builder"
<lifeless> mwhudson: I did
<mwhudson> lifeless: by builder did you mean 'person who uploaded the source package' ?
<thumper> :(
<thumper> it appears that facets are still used
<lifeless> mwhudson: no, I meant the build slave
<thumper> :((
<lifeless> mwhudson: the one that builds
<mwhudson> lifeless: the build slave isn't a Person
<mwhudson> and Persons are the only sort of principal we really have today
<lifeless> mwhudson: we have celebrities for this; we might want something better.
<lifeless> (I dislike celebrities hugely)
<lifeless> but, they are square, and the hole is square.
<mwhudson> eww
<lifeless> mwhudson: we have a celeb for the software centre agent, for instance.
<lifeless> which is doing *exactly* this sort of thing
<mwhudson> yes, i guess so
<mwhudson> doesn't mean it's not horrible though
<lifeless> sure
<lifeless> I agree
<lifeless> I'm happy though, to trade two, pervasive, icky things, for one pervasive icky thing and a clear concept for work-on-behalf-of.
<lifeless> and then we can look at the remaining icky thing.
<mwhudson> hang on
<mwhudson> two pervasive icky things?
<mwhudson> one is PSP
<mwhudson> what's the other?
<lifeless> celebrities
<mwhudson> ah ok
<mwhudson> i think i misread you then
 * wgrant despairs at buildd-manager logging priorities.
<wgrant> A build failed? CRITICAL! I can't communicate with a builder? Debug.
<spm> wgrant: ho hum.
<spm> wgrant: actually - Not being able to communicate with a Builder is perhaps info at best. outputting a critical on network blips would be a complete pita; and has been a problem with soyuz.
<spm> for services of this nature, the best I can describe: if a human *MUST* intervene, it's critical. if they don't have to, s/w can recover on it's own? it's error or lower.
<mwhudson> There is no blueprint named "" in kubuntu, or krunch-desktop-plan isn't valid dependency of that blueprint.
 * mwhudson hearts the blueprints code
<thumper> mwhudson: you forgot your sarcasterisk
<mwhudson> tis true
<spm> thumper: i dunno... in this case I don't think it was needed. the bright flashy neon lit sign with ***sarcasm ahead*** and awoooogah "sarcasm warning" horn, were a bit of a giveaway. ???
<lifeless> mwhudson: do you think its ok to have Participation support annotations ?
<mwhudson> lifeless: probably
<mwhudson> i didn't realise in my first mail that Participation was a launchpad thing
<wgrant> spm: I'm thinking of making communication errors like that a warning, disabled builders errors, and nothing critical.
<wgrant> Everything that was previously critical could only be a warning at most.
<spm> sweet
<mwhudson> does anyone know by what mechanism the doctests in lp.registry.browser.tests get run?
<wgrant> mwhudson: Not test_views?
<wgrant> That instantiates a LayeredDocFileSuite.
<mwhudson> wgrant: ah yes, thanks
<mwhudson> oh yes doctests, how do i hate thee, let me count the ways
 * mwhudson stares at this one and thinks about converting it to a unit test
<wgrant> Who is your victim today?
<mwhudson> wgrant: part of vocabularies.txt
<wgrant> yay.
<thumper> lifeless: remember we were talking about the project cloud the other day?
<thumper> lifeless: this seems to be a much more performant (and relevant) query: select product.name, count(*) as commits, count(distinct(revision_author)) as author_count, max(revision_date) as last_commit from revisioncache, product where revisioncache.product = product.id and not revisioncache.private group by product.name order by count(*) desc limit 500
<thumper> not sure which value should be the size though...
<thumper> commit count or author count
<thumper> suggestions anyone?
<lifeless> commits per author ?
<wgrant> Some combination of commit and author counts seems best.
<lifeless> we don't want just kde, gnome etc showing up
<lifeless> and they are biased to large commit counts & authors, but their normalised contributions should be much smaller
<wgrant> But KDE and GNOME are not projects, hopefully.
<lifeless> shrug
<lifeless> if you want to be picky
<wgrant> The projects within GNOME and KDE should not be overwhelmingly active.
<lifeless> wgrant: I'm 99.9999999% sure you know what I am talking about.
<thumper> we have size and colour to use
<thumper> perhaps size is based on number of commits
<thumper> and darkess grouped on committer numbers
<lifeless> if your metrics are highly correlated
<lifeless> then this will just mean small=dark big=light (or vice versa
<thumper> yeah... mostly
<lifeless> and thus it would be simler to just have one figure you calculate
<lifeless> and show small=dark, big=light
<thumper> although not always the case
<lifeless> OTOH, if they are not highly correlated, it may look fugly.
<lifeless> :)
<thumper> openerp-hr-payroll-cr          |     568 |           11 | 2010-08-06 21:37:17.629
<thumper>  mplayer                        |     103 |           11 | 2010-08-07 18:23:31.786
<thumper>  ubuntu-seeds                   |      18 |           10 | 2010-08-07 03:31:38.477
<thumper> commits is second
<thumper> count is third
<thumper> author count that is
<lifeless> personally, I don't think folk try to get stats out of the cloud
<thumper> no, they don't
<lifeless> wearing my colourblind-critic hat
<thumper> perhaps just don't bother with shade :)
<lifeless> I'd really rather keep it simple
 * thumper nods
<thumper> ok, just size based on commit count in the last 30 days
<thumper> agreed?
<lifeless> perhaps size based on commit count/author count
<lifeless> to let small but prolific show up
<thumper> ah, ok
<lifeless> perhaps thats a bad idea; I don't know.
 * thumper runs to guitar lesson :)
<lifeless> ciao
<mwhudson> i wonder how many times people view code.launchpad.net
<mwhudson> in the 3.0 design it's not easy to get to
<lifeless> mwhudson: project group clouds can die too
<mwhudson> lifeless: what are they?
<lifeless> erm, I may have the wrong context
<lifeless> thumper said when we were tlaking on th ephone
<lifeless> that the global cloud is just worst
<lifeless> that smaller ones also have trouble from time to time
<mwhudson> i didn't realize we had smaller clouds
<wgrant> The only other clouds I know of are the bug tag ones.
<StevenK> Argh, why does PQM hate me
<StevenK> Are we in testfix?
<spm> * fyi * about to stab the buildbot master, have a new hardy-slave built and want to ensure it gets picked up
<noodles775> Morning
<spm> heya noodles
<noodles775> Hi spm
<spm> * fyi * buildbot master appears to be happy again; new hardy-slave picked up. we return to your regular unscheduled building.
<lifeless> grah detoxing from caffeine headache :(
<lifeless> also hate hate hate untested code
<spm> lifeless: ?? isn't the cure for a caffiene headache to have more caffeine? If you keep this up eventually the headache WILL go away; Of course you'll also be dead, but that's considered a mere side effect
<nigelb> 'mere side effect', heh
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv
<jtv> Is anyone else getting what looks like missing CSS on edge?
<adeuring> one some pages, yes
<noodles775> jtv: yep.
<noodles775> jtv: have you let a losa know?
<jtv> And it's on r11435â¦ I think it was on 11430 an hour or so ago
<jtv> I'm just finding out.
<spm> argh. not again!?!?!
<jtv> spm: see for yourself
<spm> so I do
<jtv> then it's not just the rest of us
<jtv> I _think_ it upgraded from 11340 to 11345 just now.
<adeuring> The missing CSS lets me spot new details of the pages. I did not know that we have a "progress bar" for configuration on the main project pages and that https://edge.launchpad.net/launchpad is only 75% configured
<jtv> spm: is this something you can do anything about?
<jtv> Or at least, does anyone know what causes this?
<spm> launchpad-rev-11415 to launchpad-rev-11435
<jtv> ahhh I see you're fixing stuff already
<spm> should be in the edge restore email to the error list
<jtv> thanks for the fast reaction
<spm> :-)
<jtv> yay!  CSS!
<jtv> Actually in some ways I kind of liked our new, back-to-basics look.
<spm> adeuring: nice find for the silver lining there! ;-)
<adeuring> yeah ;)
 * jtv wonders if that phrase is taken as a name for a cloud computing-related infrastructure project
<wgrant> Hm, still broken for me.
<spm> ahh crap. I need to do the FE's as well. ta.
<jtv> Hi mrevell, thanks for the email
<mrevell> Hu
<mrevell> Or should I say, Hi?
<jtv> I think Hi is better.
<mrevell> jtv, My pleasure, I'm sorry for the delay.
<mrevell> :)
<jtv> npâ¦  I'm hitting something hard and serrated with my ongoing feature work though, so I many not get back to it today.
<spm> right that should be fuixed?
<jtv> spm: it's fixed again for me
<jtv> On to the next oneâ¦ I have a MP in "updating diff" state more than an hour after the last change was pushed: https://code.edge.launchpad.net/~mwhudson/launchpad/move-SpecificationDepCandidatesVocabulary/+merge/33611
<wgrant> Looks good. Thanks spm.
<wgrant> bigjools: Morning
<spm> jtv: gah. lookin'
<jtv> we're sure getting our money's worth out of Steve this evening.
<spm> ....
<bigjools> wgrant: g'day
<spm> yeah. the m-p jobs task has gone gaga; killin'
<wgrant> bigjools: Do you have time to talk about ddebs?
<bigjools> wgrant: at some point but not just now
<wgrant> bigjools: Sure.
<bigjools> how long are you around?
<spm> jtv: that seems to be processing again. and fwiw, it apepars to be all mwhudson's stuff that caused the problem.
<StevenK> Haha
<jtv> spm: otpâ¦ thanks
<spm>  (accusation based on no scientific evidence, beyond his branches in the follow 'is working' log)
<wgrant> bigjools: Four or five hours, probably.
<bigjools> ok
<jml> adeuring, the 75% thing is a known bug that I'm told registry will fix any moment now
<jtv> jml: ISTR you mentioned a TAL macro a few years ago that would turn a bunch of fragments into a neat "a, b, and c"âstyle list.  Can't seem to find it now.
<jml> jtv, otp
<wgrant> jtv: I don't know that there's a TALES expression for it, but there is canonical.launchpad.helpers.english_list
<jtv> wgrant: thanks, that's the one I was thinking ofâI thought it was TAL so no wonder I didn't find it!
<deryck> Morning, all.
<jtv> hi deryck!
<jtv> jam: people are getting eager for that BranchRevision weight-loss program we worked on in Prague.  :)
<jtv> mrevell: prototype for the translations help-bubble changes at lp:~jtv/launchpad/bug-517700 â playing with the real thing is probably more useful than me describing it in detail.  Still some rough edges, I think.  I'm EOD, but would appreciate feedback later!
<mrevell> Thanks jtv, I shall take a look at this next.
<jtv> See you tomorrow, folks!
<salgado> bigjools, do you have a minute to talk about the removal of the security upload policy?
<adeuring> bigjools: ...and another question: ProxiedLibraryFileAlias.http_url ensures that the returned URL does not start with "api.lp.net". The reason seems to be bug 354373, which I don't really understand. I have at present the opposite problem: I _need_ a webservice URL for ProxiedLFAs, see bug 620458.
<_mup_> Bug #354373: [API] build.build_log_url and build.upload_log_url provide wrong URLs <api> <Soyuz:Fix Released by cprov> <https://launchpad.net/bugs/354373>
<_mup_> Bug #620458: cannot access attachments of private bugs any more <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <https://launchpad.net/bugs/620458>
<adeuring> bigjools: so, I could either write a variant of ProxiedLFA.http_url which does not enforce the usage of IWebBrowserOriginatingRequest. like "default_http_url", or I could change the behaviour of http_url so that the current request is always used and add a property like web_browser_http_url which has the currnet behaviour of http_url.
<adeuring> but: why is this overriding necessary?
<bigjools> adeuring: why do you need webservice URLs for librarian files?
<adeuring> bigjools: so that lplib scripts can access private data
<adeuring> bigjools: see bug 620458
<_mup_> Bug #620458: cannot access attachments of private bugs any more <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <https://launchpad.net/bugs/620458>
<bigjools> ok
<bigjools> sounds fair enough - I think we overrode it because it was breaking something else though
<adeuring> bigjools: OK, so, changing the behaviour of ProxiedLFA.http_url, keeping the current behaviour in something like web_brwoser_http_url and using this in the affected code would be OK for you?
<bigjools> adeuring: I can't think of all the ramifications right now, but as long as you don't have to change any of the soyuz tests to make them work then it sounds fine.  I'd check with Gary though to see if he has any thoughts.
<adeuring> OK, gary_poster: ^^^
<wgrant> It's not so bad any more, since api.launchpad.net doesn't require auth.
<wgrant> However, some API clients will still want webapp URLs, so they can serve up links to private files.
<wgrant> So we really want both :/
<adeuring> wgrant: You can meanwhile access private files via the webservice
<wgrant> adeuring: Not if I'm serving links to web clients.
<adeuring> wgrant: ?
<wgrant> If I use an API client to create a web page, I need to serve webapp URLs, since my users aren't authenticated to the API host.
<adeuring> wgrant: ah, right!
<salgado> bigjools, did you see my ping earlier about removing the security upload policy?
<bigjools> salgado: yes, sorry, I am dealing with other things before getting around to you
<bigjools> but there's a lull, so fire away
<deryck> gmb, can I get an "amen!" to my changes here:  https://help.launchpad.net/Bugs/ImportFormat ?
<salgado> bigjools, soyuz-set-of-uploads.txt depends on that policy, and I've tried changing it to use another policy that accepts the same kinds of uploads but it fails and leaves me with no clue as to why
 * bigjools checks
<salgado> bigjools, line 326
<gmb> deryck, Amen, brother.
<gmb> Looks good.
<bigjools> salgado: I see
<bigjools> what's the error?
<deryck> excellent.  thanks, gmb
<gmb> np
<salgado> bigjools, Failed upload(s): ['unstable_1.0-1'] instead of the rejected exception
<salgado> that's when I use the 'buildd' policy
<bigjools> salgado: what does the next output say (for read_email())
<salgado> None
<bigjools> awesome
<gary_poster> adeuring: Please confirm if I understand the situation correctly.  http_url was a url friendly to the webservice.  It has changed recently to be a url friendly to the browser.  This is problematic for a number of reasons, many of which go under the category of "backwards compatibility".  You propose to reinstate the previous behavior and create a new attribute named "browser_url" or something similar.  That's my 
<gary_poster> right?
<adeuring> gary_poster: yes.
<adeuring> gary_poster: the alternatvie would be to add something like "default_http_url"
<adeuring> which looks a bit odd to me
<wgrant> That's not my understanding -- ProxiedLibraryFileAlias has returned a browser-friendly URL for 18 months. Bug attachments just started using it a couple of weeks ago.
<jml> jelmer, I'm warming up to the idea of a testr integration branch.
<jml> jelmer, lack of incremental output is hurting me.
<adeuring> wgrant: well, yes. But http_url is not vey specific to ProxiedLFA
<gary_poster> wgrant, ok, thanks for clarification.
<gary_poster> adeuring, wgrant, I'm in favor of using the webservice versioning for this.  1.0 and beta should keep the current behavior, whatever it is, since that appears to not be breaking anything and wgrant says it has been stable.
<jelmer> jml: Yeah, that's particularly annoying with a project as large as lp.
<gary_poster> I like http_url for webservice and browser_url for browser for the devel service, but there's an obvious downside of surprising migration (it's easier to know to migrate when a attribute disappears than when it subtly changes meaning).
<adeuring> gary_poster: OK... what about leaving http_url as it is and adding web_url and api_url?
<salgado> bigjools, how about I remove that test and add a unit test to AbstractUploadPolicy.setDistroSeriesAndPocket(), which is what raises that exception shown in the email message?
<wgrant> The failure mode here is probably just that private files become inaccessible. So it's not that bad.
<bigjools> salgado: +1, that doctest needs to die in flames
<deryck> adeuring, hi.  Can we get a card into WIP on the Kanban board for that attachment work you're doing?
<adeuring> deryck: sure
<deryck> adeuring, thanks!
<gary_poster> adeuring: http_url will effectively be alias for web_url in your proposal?
<adeuring> gary_poster: no necessarily. web_url and api_url should enforce the hostnames code.lp.net and api.lp.net, repsectively
<gary_poster> So what is the value of http_url then?  Why would I use it instead of web_ or api_?
<salgado> bigjools, cool.  however, there's also a big chunk starting at line 606 for testing staged uploads to the security pocket.  I know there are other tests for staged uploads, so maybe I can just nuke that?
<salgado> lib/lp/archiveuploader/tests/test_buildduploads.py has those tests for staged uploads
<adeuring> gary_poster: well... I'm trying to find a way to cop out from changing soyuz code while having somewhat same property names ;)
<adeuring> Actually, I could simply add api_url -- that's all I need
<adeuring> s/same/sane/
<gary_poster> adeuring: heh, ok fair enough. :-)  from this conversation, http_url seems poorly defined and unclearly named though.  I'd prefer you add api_url and web_url, and make a note in http_url that that users should cuse api_url and web_url instead, and http_url may be removed in a future version of the webservice.  Maybe that's too aggressive...
<gary_poster> That's my preference, but I would be OK with only adding api_url and putting a bug in against the webservice about this problem, so that when leonardr and benji start trying to clean up the webservice generally this is one of the issues they consider tackling.
<adeuring> gary_poster: good proposal; I'll go for it.
<gary_poster> adeuring: cool, thank you!
<leonardr> gary, adeuring, are you aware of rockstar's work on this? has he completed the work and that's cuasing the problem?
<gary_poster> leonardr: I have no knowledge of this :-/
<adeuring> leonardr: no, maybe his work will fix my problem, no idea.
<adeuring> leonardr: the code I'm talking about is from r8166
<leonardr> gary, adeuring, at the epic rockstar started working on a 'web_link' that was like 'self_link' except it pointed to the object on the website
<leonardr> but given that revision number i imagine you're not talking about something added to lazr.restful
<gary_poster> leonardr: Is that pertinent to the library files?
<adeuring> leonardr: right, its about lp code itself. and as gary says, about library files
<adeuring> ProxiedKFA, more specifically
<adeuring> ProxiedLFA
<leonardr> so, the library files used to have an http_url that used whatever host the reuqest came from?
<adeuring> leonardr: yes, and that points _not_ to the webservice
<adeuring> making access to the files from a webservice client impossible from private files
<adeuring> s/from/for/
<leonardr> ok, i see
<gary_poster> adeuring, just a warning, we're about to have a team call, so will be away for just a moment
<adeuring> ok
<leonardr> in that case, you can check for request.version to see which version of the web service is in use, and change behavior based on that
<leonardr> i don't have an opinion on what you should implement, i just wanted to make sure this wasn't overlapping rockstar's work
<rockstar> leonardr, I should get back to fixing that one day.
<gmb> Aaaaaaaaa
<gmb> So.
<gmb> Why would assertRaises() in a test case *not* catch the exception that I'm asserting the callable raises?
<jml> hmm
<salgado> bigjools, did you my msg earlier about the staged-upload test on soyuz-set-of-uploads.txt?
<jml> gmb, I'm thinking about that.
<jml> gmb, I'm fairly sure the answer is that you are doing it wrong.
<gmb> jml, Specifically, the exception is zope.security.interfaces.Unauthorized
<gmb> And the code is:
<gmb>         self.assertRaises(
<gmb>             Unauthorized, self.bug_tracker.resetWatches,
<gmb>             "Unprivileged users should not be allowed to reset a "
<gmb>             "tracker's watches.")
<jml> gmb, ahh, I know this one :)
<gmb> Oh goodie.
<gmb> Do share.
<jml> gmb, it's getattr(self.bug_tracker, 'resetWatches') that's raising the Unauthorized
<bigjools> salgado: sorry missed that, looking now
<jml> gmb, rather than the actual method call.
<gmb> jml, Ah, because it's launchpad.Admin'd.
<gmb> so an unpriv'd user can't get at the method, let alone call it.
<jml> gmb, and because zope security works on attribute access.
<jml> gmb, exactly.
<gmb> D'oh. So obvious.
<gmb> jml, Thanks.
<jml> self.assertRaises(Unauthorized, getattr, self.bug_tracker, 'resetWatches') has worked well for me in the past.
<jml> (although arguably that's a custom assertion method / matcher waiting to happen)
<jml> gmb, np.
<bigjools> salgado: I think we can nuke the test
<salgado> bigjools, cool, the problem now is that the test hangs after I removed that section.  I'll see if I can find out where/why
<bigjools> salgado: argh.  That test is a nightmare.
<salgado> bigjools, btw, would you like to have a look at the other branch which replaces the can_upload_* attributes with a single enum?  jtv has approved it, but I thought you might want to have a look anyway?
<bigjools> salgado: I can but I'm not sure when!
 * bigjools is too busy :(
<salgado> bigjools, maybe jelmer or StevenK can have a look?  or if you think it's not necessary, I've already got jtv's approval anyway
<salgado> btw, it's publish-distro.py that hangs
<bigjools> salgado: don't block on landing it, we can look later.  jelmer may be very interested anyway as he's changing the upload processor a bit at the moment.
<salgado> ok, cool
<jml> "testr run failing" doesn't do what I meant
<deryck> gmb, the an MP I approved for a "scratch" branch of yours.  Can that be landed?
<gmb> deryck, Er. Hang on, I don't remember that.
<gmb> Blimey, that was a while back.
<deryck> Judging by the diff I wonder if you merged it in another branch?
<gmb> deryck, Ah, I think that first bit was to do with the fix for the initial_message problem.
<gmb> Hrm.
<gmb> deryck, I'll do some digging and find out what's landed and what's not.
<gmb> I suspect that diff is a lie.
<deryck> ok, cool.  Thanks!
<gmb> deryck, Yes, there's some lying going on. Well, not lying, but basically the diff is against the ancestor revision of the scratch branch; when I merge devel it conflicts with what's already landed. I'll clean it up and submit it.
<deryck> gmb, ok,cool.
<jelmer> salgado: I see you're having fun with huge interdependent soyuz doctests
<salgado> jelmer, yes!  it's been such a long time since it last happened that I'd almost forgotten how much fun they can be
<jelmer> salgado: :-)
<leonardr> i'd like to talk to someone who understands zope permissions well, maybe gary, or salgado-lunch once he returns from lunch
<gary_poster> leonardr: benji-lunch would be a good choice too.  I better go get some lunch because I have a call in 24 min :-/
<gary_poster> otherwise I should be available 3:30 or 4
<leonardr> ok
<leonardr> i'll just explain the problem
<gary_poster> ok
<leonardr> i've created a security policy for IOAuthAccessToken that basically says:
<leonardr> if you're trying to look at this oauthaccesstoken through the website, the old rules apply: it has to be your token, or you have to be an admin
<leonardr> if you're trying to look at this oauthaccesstoken through the web service itself, the rules are more restrictive.
<leonardr> you can only look at your own token, and your request must itself be signed by an oauthaccesstoken that has the GRANT_PERMISSIONS access level
<leonardr> this works fine for prohibiting writes to the token, and it also keeps the token from showing up in lists in the web service (since you don't have launchpad.View on the token)
<leonardr> but, you can still guess the url and get the token data that way
<leonardr> so i added this bit to oauth.zcml
<leonardr>       <require
<leonardr>           permission="launchpad.View"
<leonardr>           interface="canonical.launchpad.interfaces.IOAuthAccessToken"/>
<leonardr> and that protects the objects themselves
<leonardr> however, there's a catch-22: to determine whether the request is signed by an appropriate OAuthAccessToken, you need to be able to look at an OAuthAccessToken object
<leonardr> that's where i'm stuck
<gary_poster> leonardr: which component needs to be able to look at an OAuthAccessTokenObject?
<gary_poster> leonardr: a mediator is a typical pattern for this
<gary_poster> mediator rips off security proxy and does what needs to be done and returns answer
<leonardr> gary: well, right now, the code that signs the _outgoing_ request needs to be able to look at it. the request isn't even being made
<gary_poster> would mediator work in context?
 * gary_poster really should get some food
<leonardr> go ahead
<jml> gary_poster, stay hungry, the TL meeting will be shorter for it :)
<leonardr> i'll try some stuff
<gary_poster> jml :-)
<leonardr> gary: two well-placed removeSecurityProxy calls solved the problem
<jml> g'night all.
<gary_poster> leonardr: great.
<bigjools> nn jml
<leonardr> benji, got another problem with my permissions. the 'view' permission seems to work correctly, but the 'edit' permisison check is failing without my code ever being called
<leonardr> let me know what kind of details will help
 * benji scrolls back to get context.
<leonardr> benji: basically i updated the AuthorizationBase subclass for OAuthToken objects
<leonardr> so that you can only modify them from the web service under certain circumstances
<leonardr> my code is running when it comes to _viewing_ objects through the web service
<leonardr> but when i try to modify one, i get Unauthorized, and the code from security.py never runs
<leonardr> setattr(context, self.name, value) raises an exception
<benji> leonardr: What is the security checker for the object in question?  Also, I'm trying to figure out how your AuthorizationBase subclass tied into zope.security.  I've not touched the LP-specific security stuff any yet.
<leonardr> benji, i believe the seucirty checker is canonical.launchpad.webapp.authorization.LaunchpadSecurityPolicy
<leonardr> benji: NEVER MIND. i brought this problem on myself
<benji> leonardr: I'd put some breakpoints in one or two methods of LaunchpadSecurityPolicy and then execute your setattr; tracing through what happens should...
<leonardr> there is a real problem, but i understand why this is happening
<benji> :)
<leonardr> benji: the real problem is in webapp/authorization.py, _checkRequiredAccessLevel
<leonardr> an AccessLevel of GRANT_PERMISSIONS doesn't have the ability to 'write'
<leonardr> i want a situation where GRANT_PERMISSIONS has the ability to 'write', but only to OAuthACcessToken objects
<benji> makes sense
<leonardr> i have no clue how to do this. i can use the zcml guards to attach an AuthorizationBase subclass to OAuthAccessToken
<leonardr> i guess i could change AuthorizationBase to explicitly forbid writes if the AccessLevel is GRANT_PERMISSIONS, but that seems hacky
<leonardr> i think salgado might have some insight into this
<lifeless> .
<salgado> leonardr, maybe, but I'd need more context
<leonardr> salgado: so, take a look at LaunchpadSecurityPolicy._checkRequiredAccessLevel
<leonardr> this code says "no matter what permissions the principal has, if the access level is not high enough, access denied"
<leonardr> i would like GRANT_PERMISSIONS to be considered a 'read' access level for everything _except_ oauth access tokens
<leonardr> i implemented permissions to this effect (you can only write to an oauth access token if you are using GRANT_PERMISSIONS)
<leonardr> but since GRANT_PERMISSIONS is considered a 'read' access level globally, you never get to use those permissions
<leonardr> the only thing i can think of is to make GRANT_PERMISSIONS a 'write' access level, and special-case the superclass of all write-permission checkers so that GRANT_PERMISSIONS does _not_ give you any write permisson
<leonardr> or, give up and just make GRANT_PERMISSIONS a 'write' access level
<benji> leonardr: it wouldn't seem too bad for GRANT_PERMISSIONS to have write access; after all if something has GRANT_PERMISSIONS then they could just give themselves write access, right?
<leonardr> benji: yes, the idea is more to make sure that a GRANT_PERMISSIONS script doesn't suffer feature creep and become a do-all-sorts-of-things script
<benji> mmm
<benji> giant ascii art warning perhaps?  :P
<leonardr> if we could determine when to print that warning, we could just deny access :P
<mwhudson> morning
<salgado> leonardr, what about forcing all tokens with permission==GRANT_PERMISSIONS to be scoped to OAuthToken?  that way the client would have whatever access_level is defined in GRANT_PERMISSIONS for OAuthToken but read-only access for everything else
<leonardr> salgado: that's a good idea, but i'm pretty sure scoped tokens don't work and never did work
<leonardr> but, it's possible the internals work and the interface was never completed
<salgado> I think that's the case, but even if it doesn't work it should be easy to fix it
<leonardr> ok, i will look into this tomorrow
<mwhudson> ec2 land is blowing up for me
<mwhudson> Exception AttributeError: "'SmartSSHClientMedium' object has no attribute '_ssh_connection'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://mwhudson@bazaar.launchpad.net/)> ignored
<mwhudson> regular bzr operations work fine though
<mwhudson> any ideas anyone?
<mwhudson> sinzui: did you get my mail about menus?
<mwhudson> hm, probably not
<mwhudson> sinzui: https://lists.launchpad.net/launchpad-dev/msg04367.html
 * sinzui looks
<sinzui> mwhudson, I did not see this reply
<mwhudson> sinzui: yeah, i screwed up my mail server config somehow
<sinzui> Well I will reply shortly
<mwhudson> it's not a very deep reply, mostly a series of questions....
<mwhudson> cool
<rockstar> wallyworld, do you have something like this in ~/.ssh/config http://pastebin.ubuntu.com/483652/
<wallyworld> i'll look
<lifeless> sinzui: https://edge.launchpad.net/landscape/+milestone/later
<lifeless>  At least 81 queries issued in 11.15 seconds
<lifeless> sinzui: seems a bit healthier
<lifeless> (and I'm seeing the private bugs)
<sinzui> yep
<wgrant> lifeless: I wouldn't call it healthy -- there are still massive scaling issues.
<wgrant> Takes 1.1s here.
<wgrant> 69 queries.
<lifeless> wgrant: I wouldn't call it healthy either
<lifeless> wgrant: 20, constant, would be healthy.
<lifeless> wgrant: but healthier, eys.
<wgrant> I wonder where the extra 10s comes from.
<wgrant> Sure not those 12 queries.
<lifeless> OOPS-1698EA2488 may tell us
<wgrant> Do you want an OOPS from mine as well to compare?
<rockstar> wallyworld, I think you're looking for /etc/apache2/sites-available/local-launchpad
<rockstar> wallyworld, do you have bazaar.launchpad.dev in your /etc/hosts ?
<wallyworld> yep - 127.0.0.99
#launchpad-dev 2010-08-26
<lifeless> wgrant: are you looking at the same url ? if so, sure
<lifeless> spm: is OOPS-1698EA2488 mirrored yet ?
<lifeless> or something wrong with lp-oops ?
<lifeless> wgrant: 4.18 seconds, hitting it again.
<lifeless> wgrant: so it -can- be fast; we may have caused disk io
<mwhudson> working on blueprints presents interesting challenges
<mwhudson> like not trying to fix absolutely everything
<wgrant> Delete delete delete.
<mwhudson> i mean really
<wgrant> Hm?
<mwhudson> oh sorry just venting
<mwhudson> and some silly code
<thumper> mwhudson: I feel your pain
<thumper> been there
<lifeless> mwhudson: have you looked at the query counts for blueprints
<mwhudson> lifeless: no, but given the naivety of the code i've just been looking at, i imagine they might be crazy
<mwhudson> thumper: you around ?
<thumper> kinda
<mwhudson> thumper: can i call you at some point?
<mwhudson> no massive hurry
<thumper> sure, I'll ping you
<mwhudson> cool
<mwhudson> i think i'm going to end up with another preparatory branch
<mwhudson> first was: move code i want to change
<mwhudson> second looks like being: de-stupid code i want to change
<mwhudson> OMG
<mwhudson> ls lib/lp/blueprints/stories/blueprints
<mwhudson> sequential page tests!
<lifeless> mwhudson: almost certainly
<gary_poster> eek: I haven't used make lint in a while, and I just ran it on a branch.  it seemed to have linted just about every file in the tree.  That wasn't particularly useful.  ./bin/lint.sh doesn't seem to point to any glaring mistake I made either :-/
<mwhudson> gary_poster: if there are no changed files (bzr st) it should do a diff against the parent (bzr info) i think?
<lifeless> gary_poster: did you have any uncommitted files ?
<lifeless> if not - what mwhudson said
<gary_poster> no uncommitted files
<lifeless> gary_poster: while you're here
<lifeless> gary_poster: did you see the thread on lp dev about scripts and participations ?
<mwhudson> gary_poster: bzr st -r parent: ?
<gary_poster> bzr: ERROR: Requested revision: u'parent:' does not exist in branch: BzrBranch7('file:///home/gary/launchpad/lp-branches/devel/')
<mwhudson> heh, that just blew up for me
<lifeless> if you didn't, mwhudson and I would appreciate your thoughts
<gary_poster>  parent branch: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
<lifeless> mwhudson: :parent I think
<mwhudson> lifeless: oh right, that's what blew up
<gary_poster> crashed for me
<mwhudson> i just said the wrong thing to gary
<gary_poster> lifeless: I saw it fly by but did not look closely; will look
<mwhudson> "ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles"
<gary_poster> yeah, same here
<lifeless> mwhudson: personally, I'd do 'bzr st -r ancestor:..'
<lifeless> where ... is (for me) ../devel
<mwhudson> lifeless: ah yeah, probably better
<gary_poster> bzr st -r ancestor:../devel/ gives me the kind of list I expected make lint to use
 * gary_poster will try make lint again for amusement sake
<gary_poster> eek, no
 * gary_poster googles "bzr set parent branch"
<mwhudson> gary_poster: maybe you should just fix all the lint in the tree!
<gary_poster> thanks a lot mwhudson :-)
<gary_poster> OK, so I think this is the problem:
<gary_poster> parent branch: bzr+ssh://bazaar.launchpad.net/~mars/launchpad/lsprof-on-demand/
<gary_poster> I want it to be my local devel (or a remote devel, whatever)
<mwhudson> ah yes
<mwhudson> i think bzr pull --remember will set parent
<gary_poster> I tried bzr merge --remember ../devel/
<mwhudson> although of course bzr pull won't actually work
<mwhudson> gary_poster: vim .bzr/branch/branch.conf is probably as easy as anything :/
<gary_poster> ok :-/ if it works that would be good though :-)
<mwhudson> i don't know if the --remember config setting happens before or after the 'pull' part
<gary_poster> all fixed, thank you
<mwhudson> aararargh
<mwhudson>         if (ISpecification.providedBy(self.context) and
<mwhudson>             specurl == getattr(self.context, 'specurl')):
<mwhudson>             # The specurl wasn't changed
<mwhudson>             return
<mwhudson> why getattr there?
<gary_poster> lifeless: I have to go, but you were talking about the email thread from this week titled "performance tuesday - transparency," right?
<mwhudson> gary_poster: yes
<gary_poster> ok, will read and reply tomorry
<thumper> mwhudson: it is just there to make you tear your hair out
<thumper> mwhudson: shall I get a coffee before our call?
<mwhudson> thumper: a cunning plan
<mwhudson> thumper: yeah, i've become distracted by the craptitude of this code, i need to remember what i wanted to talk to you about :-)
<thumper> :)
<mwhudson> i want to cry
 * spm hands mwhudson a box of kleenex
<spm> synmpathy from a losa only goes so far.....
<wgrant> How long is it since Blueprint was maintained? 3ish years?
<ajmitch> possibly because it drives people mad?
<mwhudson> it's a bit of a chicken and egg problem there
<mwhudson> i'm making a small corner of it better at least
<jtv> wgrantâhi!  Say, how is BuildFarmJob coupled to a Job or BuildQueue?  Is there any chance that the state of a BuildFarmJob fell out of sync with that of the Job?
<jtv> We've got a bunch of TranslationTemplateBuildJobs that were starved out of the build farm as far as we can tell, but now the build farm is mostly idle again and those jobs aren't being picked up.
<wgrant> jtv: Yes, there are a few ways they can become inconsistent.
<wgrant> Although less for translations jobs.
<wgrant> let's see...
<wgrant> jtv: The i386 virt queue is still 500 items and 11 hours deep.
<wgrant> That's not what I'd call idle.
<jtv> ah
<jtv> so many i386 builders idleâ¦ all nonvirtual?
<wgrant> Yes.
<jtv> oic
<wgrant> There used to be just three, but as of yesterday there are five.
<wgrant> I'm not sure where all the virt builders have been for the last week.
<jtv> so that ought to help a little
<wgrant> How?
<wgrant> Translations jobs build on virt builders.
<wgrant> So the extra non-virt ones just slow down buildd-manager for you :)
<jtv> Oh, the extra ones are non-virtual.  I misunderstood that.
<wgrant> There are normally 15 or so i386 virt builders.
<wgrant> Now there are 6.
<jtv> that'd explain a few thingsâ¦
<jtv> wgrant: I don't see anything that would associate a BuildFarmJob with a Job or BuildQueue.  How does it connect to things?
<wgrant> jtv: Ha ha ha.
<wgrant> jtv: Well.
<wgrant> jtv: http://people.ubuntu.com/~wgrant/launchpad/buildfarm/current-build-model.png
<wgrant> That's how it roughly is at the moment.
<wgrant> Except that it's been partially converted to http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png
<wgrant> But the link tables (BuildPackageJob, SourcePackageRecipeBuildJob) are still in place.
<jtv> (That's a relief, because I didn't see any BuildFarmJob at all in the former)
<jtv> (I still say the arrows look the wrong way around to me)
<wgrant> The parts of the new model that have so far been adopted are the merging and splitting of BinaryPackageBuild and SourcePackageRecipeBuild into BuildFarmJob, PackageBuild, BinaryPackageBuild, and SourcePackageRecipeBuild.
<wgrant> Yes, shutup :P
<wgrant> Everything else hangs on the translations jobs being ported to sit on top of BFJ.
<wgrant> BuildPackageJob and other link tables need to remain in place until we have you off the old infrastructure.
 * jtv is disappointed to see that shaking his head doesn't clear the cobwebs
<wgrant> Hmm?
<jtv> It's just dizzying.
<jtv> Being somewhere inbetween these two schemata.
<wgrant> Yes :(
<jtv> With the arrowsâsorry, but it's really not helping!âall pointing the other way.
<jtv> wgrant: also, I _still_ don't see how the translation template build jobs are linked to buildfarmjobs.
<wgrant> jtv: Even in the second diagram?
<wgrant> A TranslationsTemplateBuild has a BuildFarmJob and a Branch.
<jtv> wgrant: I mean in the current schemaâthere being no TranslationTemplatesBuild table.
<wgrant> Ah.
<wgrant> In the current model, they're not linked to a BuildFarmJob.
<jtv> The link to BuildFarmJob has to remain memory-only, which ISTM is getting more and more tenuous.
<wgrant> There's just a TranslationTemplatesBuildJob (BranchJob) linked to a Job linked to a BuildQueue.
<wgrant> You're different from the others, since you don't have a permanent object.
<jtv> So does the absence of a buildfarmjob currently matter?
<wgrant> Only in that it prevents us from radically simplifying the mess.
<jtv> So it's not likely that we've got jobs stuck forever just because of this, but all the more urgent that we update our part of the schema.
<wgrant> Right.
<wgrant> I don't think you have stuck jobs.
<wgrant> I think they're just at the end of the queue.
<jtv> Almost certainly, if it's true that the farm is currently swamped by PPA jobs coming in mostly at a score of 2505.  Until the cherrypick that spm deployed for us just now, our jobs went in at 1000.
<wgrant> jtv: You can see at https://launchpad.net/builders that the queue is large.
<jtv> wgrant: quite
<jtv> It's just hard to get an impression of more subtle aspects such as "what's the queue like for the group of builders that can handle our jobs?"
<jtv> Whoops, did my local launchpad repository just break?
<jtv> Can't pull any of the LP branches now.
<jtv> No such file or directory: u'/home/jtv/canonical/lp-branches/.bzr/repository/indices/f16f01b514931e8ff2433001ed359d47.rix'
<jtv> lifeless: what do I do about a broken repo?
<thumper> bzr check?
 * jtv tries
<jtv> That's busily checking away
<mwhudson> argl
<jtv> mwhudson: try argvâit's called a vector, not a list for some reason
<jtv> ECONTEXT
<mwhudson> oh, ./bin/ec2 is slightly broken
<jtv> argh
<thumper> really?
<thumper> hmm
<thumper> I still use utilities/ec2 :)
<mwhudson> well
<mwhudson> that's just a symlink
<mwhudson> it only matters if you have "debug_flags = hpss" in your config, i think
<mwhudson> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/624434
<_mup_> Bug #624434: ec2 needs to initialize bzrlib <Launchpad Foundations:New> <https://launchpad.net/bugs/624434>
<mwhudson> about 50% of the time needed to fix this bug is waiting for "make build" :(
<wgrant> mwhudson: make compile isn't enough?
<thumper> :)
<wgrant> It skips the WADL and related crap.
<wgrant> So it doesn't take five minutes.
<mwhudson> yeah, that probably would have been ok here
<thumper> the WADL generation is being moved out of make build
<thumper> and WADL will be checked into the tree
<thumper> see gary for details :)
<mwhudson> that'd be nice
<wgrant> Um, what happens if it changes?
<lifeless> jtv: depends on the breakage
<lifeless> jtv: #bzr is a good place to ask
<jtv> lifeless: thanks.  "bzr check" has been recommended to me, and I'm running that now.
<mwhudson> jtv: do you have other files called /home/jtv/canonical/lp-branches/.bzr/repository/indices/f16f01b514931e8ff2433001ed359d47.* ?
<mwhudson> or well /home/jtv/canonical/lp-branches/.bzr/repository/*/f16f01b514931e8ff2433001ed359d47.*
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.cix
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.iix
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.pack
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.rix
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.six
<jtv> obsolete_packs/f16f01b514931e8ff2433001ed359d47.tix
<jtv> that's it
<mwhudson> mmm
<mwhudson> looks like pack-names didn't get updated properly?
<jtv> does it?
<mwhudson> maybe
 * jtv is devoid of clue
<mwhudson> lifeless would know more than me
<mwhudson> jtv: bzr stores all data in packs, named after some checksum of the contents
<mwhudson> jtv: the pack-names file lists which pack files are curreent
<mwhudson> jtv: repacking coalesces pack files, so removes some
<mwhudson> so one way you could get in this situation is if packs were combined, the old ones moved to obsolete_packs and then the update of pack-names file didn't succeed for some reason
<mwhudson> but i don't know the order things happen in off the top of my head
<mwhudson> in fact i would guess the pack-names update would be done _before_ obsoleting the packs
<jtv> I think this happened while I was pulling several branches at the same time.  Maybe a race condition?
<jtv> let me also try if my fs is still writeable; it corrupts itself sometimes
<jtv> yup, still writable
<lifeless> a missing index
<lifeless> means your fs failed to complete a write
<jtv> so a previous instance of fs corruption is the most likely causeâ¦ odd though that it started failing in the middle of a bunch of pulls though.
<lifeless> we only do IO as required
<lifeless> so we don't check that every index is there every time
<lifeless> so, a pack-name update that wasn't flushed looks plausible
<lifeless> you could see if there is a tmp file with a newer date
<lifeless> and if so, (in a copy of the repo, of course)
<lifeless> try putting it in place
<jtv> lifeless: where would I find that?  And shouldn't I wait for "bzr check" to complete first?
<lifeless> check doesn't handle this sort of problem
<lifeless> .bzr/repository
<lifeless> and - seriously - hop into #bzr
<lifeless> grab - probably spiv right now
 * mwhudson eods
<wgrant> jtv: Looks like your build score changes worked.
<jtv> wgrant: are we building one?
<wgrant> jtv: Yeah.
<wgrant> https://edge.launchpad.net/builders/rhenium
<jtv> yup, see it!
<jtv> Thanks for the heads up
<wgrant> However, the i386 queue is looking pretty sad.
<wgrant> I wonder if lamont rolled out the new lp-buildd this morning.
<wgrant> Then we can easily reassign some amd64 builders to i386...
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<noodles775> allenap: will you be landing your alternative property cache branch soon? It looks great (tests will be much nicer to read :) ).
<noodles775> actually, just saw that there is canonical.cachedproperty.is_cached too.
<mrevell> Hello
<wgrant> bigjools: Yes, db-devel merges into devel have really bad revnos :(
<jtv> mrevell: just dumping a branch on you may have been a little rough yesterdayâ¦ would you prefer a series of HTML snapshots?  Won't show the full interaction, but will show the different forms the message can take.
<mrevell> jtv, No a branch is fine, I'm just in the middle of transcribing a particularly difficult to understand interview. I'll have that finished this morning and will get to the translations help this afternoon, thanks.
<danilos> mrevell, particularly hard-to-understand? I don't remember talking to you!
<mrevell> danilos, heh
<jtv> mrevell: thanksâlooking forward to it!
<jtv> (ignore the danilo)
<danilos> mrevell, who deals with commercial emails on feedback@lp?
<mrevell> danilos, me
<danilos> mrevell, there's one from 17th that I haven't seen a response to
<danilos> mrevell, and another one 5 days ago
<mrevell> Anything that old  will definitely have been dealt with.
<noodles775> wgrant: Thankyou for removing BuildBase :)
<jtv> Q: do we have anything that actually runs the tests in lib/canonical/launchpad/windmill/jstests/launchpad_ajax.js ?
<wgrant> noodles775: Still need to move the last couple of things from the interface file.
<wgrant> noodles775: I'll move BuildStatus to BuildFarmJob, but I'm not sure where to put BUILDD_MANAGER_LOG_NAME.
<noodles775> wgrant: I'm assuming BuildStatus should go to lp.buildmaster.enums?
<wgrant> noodles775: I guess it could.
<wgrant> if anybody other than Code is doing that now, which it seems is the case now.
<noodles775> Yep.
<wgrant> bigjools: Where should lp.buildmaster.interfaces.buildbase.BUILDD_MANAGER_LOG_NAME go?
<wgrant> I think it should probably not be BUILDD_MANAGER_*, since that's an implementation detail.
<bigjools> wgrant: ummm, I wonder if it's worth making lp.buildmaster.constants
<bigjools> or it could go in enums
<noodles775> Why does it even exist? It's used in two places and represents a logging config name...
<wgrant> slave-scanner is still hardcoded in several places.
<wgrant> It should be used more widely, or we should pass loggers around more aggressively.
<jelmer> wgrant, my branch makes us do that
<wgrant> Or we could just resolve to hardcode it more heavily.
<wgrant> jelmer: Ah!
<jelmer> (pass loggers around more aggressively)
<wgrant> Excellent.
<wgrant> jelmer: Is BUILDD_MANAGER_LOG_NAME still used anywhere?
<wgrant> jelmer: Is this your Popen removal branch?
<jelmer> wgrant: yeah
 * noodles775 would prefer to see the module names used with getLogger (ie. getLogger('lp.buildmaster.manager') and the logging configs updated to do the right thing - where possible)
<jelmer> wgrant: IIRC BUILDD_MANAGER_LOG_NAME is still used once or twice.
<wgrant> noodles775: But I don't think that's entirely correct, since it's not necessarily buildd-manager that's calling things.
<wgrant> noodles775: Although it will be the only caller, once we remove SlaveScanner.
<wgrant> jelmer: :(
<jelmer> wgrant, I'm sure we can fix that afterwards..
<wgrant> Yeah.
<noodles775> wgrant: I thought the reason for using the module name as a standard for getLogger was to indicate the context of the log message, not the call-site?
<wgrant> noodles775: Ah, I just took your lp.buildmaster.manager example in the context of the calls I was thinking of, which are not in fact in buildd-manager itself.
<wgrant> Never mind me.
<jml> +1 for passing loggers around
<noodles775> jml: is that from experience, or is there an good article you'd recommend? From reading about pythons logging configuration options, I'd assumed part of their intention was to remove the need to pass loggers around?
<jml> noodles775, experience
<jml> noodles775, every time I think mutable global state is a good idea and actually try it, it turns out to be a bad idea
<bigjools> last I heard, flacoste was not so keen on passing loggers around
<wgrant> danilos: I question the fix suggestion in bug #522800. From what was it derived?
<_mup_> Bug #522800: Broken link in PPA package details page (404) <ppa> <QGIS:Invalid> <Soyuz:Triaged> <https://launchpad.net/bugs/522800>
<jml> passing them around is easy to read, easy to write, easy to change and doesn't reduce functionality
<wgrant> The problem is a bit less serious than that fix suggests.
<bigjools> wgrant: I forgot what you said about it
<jml> it also makes it _really_ obvious what needs a logger and what doesn't
<wgrant> bigjools: The query returns the oldest LFA with the given name.
<wgrant> bigjools: It should filter out expired ones.
<bigjools> ah right
<bigjools> would you mind updating the bug?  I think you said you were going to do that :)
<wgrant> There are unexpired ones there. I can see them through the librarian's search interface.
<wgrant> Heh, possibly. Uni has been keeping me busy.
 * wgrant updates the bug.
<bigjools> Uni didn't keep me busy
<bigjools> well - not academically :)
<wgrant> Heh.
<wgrant> The team project is actually taking up time. The first subject to actually do so :(
<danilos> wgrant, the fix suggestion came from bigjools, but I see you already resolved that :)
<bigjools> I'll tell you a story about one of mine next time we meet up
<wgrant> Heh.
<bigjools> danilos: yeah I was wrong in my assumption :()
<wgrant> See, this project has classically been done over a year.
<wgrant> This is the first time they've crushed it into a semester.
<danilos> wgrant, can you update the description or should I (while I have the bug open)?
<wgrant> I'm not sure they've really thought it through.
<wgrant> danilos: I'm doing it.
<danilos> wgrant, cool, thanks
<bigjools> geez, LP's test suite even brings my four-core to its knees.
<jml> is it using more than one core?
<noodles775> jml: but to add a logging statement to a method that previously didn't log anything, you've got to update the method signature and (possibly) all call-sites, and potentially the signatures of the callsites which may not yet have the logger themselves? I'm not clear why you think it's good that the decision to log something in a method changes the method.
<wgrant> bigjools: Need more SSD!
<bigjools> jml: yes, but not in the way you think
<bigjools> disk access is the killer
<noodles775> jml: but that scenario might just indicate badly-factored code anyway.
<bigjools> and memory hogging
<jml> noodles775, for the case where "log" is little more than a print statement, that's a fair point
<bigjools> wgrant: I think I can soon start heating my office from the machines in here
<jml> noodles775, but so often with Launchpad, logging is srs bsns
<wgrant> bigjools: Have you acquired a new one to replace your previous quad-core?
<jml> I dunno. I'm also going through a phase of making interfaces with methods that correspond to events I care about, and using that for logging.
<bigjools> wgrant: nope I'm still happy with this one
<bigjools> unless you count the pseudo 4-core in the i5 :)
<StevenK> That's not a real quad-core
<bigjools> jml: personally I agree with noodles775 here, changing method signatures to accommodate logging objects sounds quite evil
<jml> indeed, "pseudo" could imply little else.
<bigjools> yeah I was about to say ...
<StevenK> Oh, bleh
 * StevenK goes back to terrorizing dogfood
 * bigjools likes to call it a fork-whore in honour of the Two Ronnies
<StevenK> bigjools: The only thing I know from Two Ronnies is "and that's good night from 'im" :-(
<jml> bigjools, I've more frequently encountered evil where I've had to mix code that each does it's own logging and neither bits of code have given me permission to touch their logging
<jml> because it's acquired from a global rather than passed in.
<jml> or refactoring a chunk of code that has log statements all over the place
<jml> in any case, more often I pass logging objects into constructors
<noodles775> ah, that would help :)
<bigjools> StevenK: http://www.youtube.com/watch?v=qu9MptWyCB8
<noodles775> jml: but I wonder if the evil you've encountered is related to logging not being configured correctly in the first place? (/s/correctly/optimally) Not sure.
<jml> noodles775, maybe. I can't recall enough detail.
<jml> noodles775, things not being right in the first place is certainly a strong theme in the soundtrack of my programming career :)
<noodles775> jml: but being right in the end I'm sure too :)
<jml> noodles775, software is never finished, it just runs out of funding
<danilos> Ursinha, hi (when you are around), does this bug activity look like a problem with qa-tagging scripts? https://bugs.edge.launchpad.net/rosetta/+bug/618987
<_mup_> Bug #618987: gc.get_objects() interacts badly with bzrlib lazy imports <qa-untestable> <tech-debt> <Launchpad Translations:In Progress by thumper> <https://launchpad.net/bugs/618987>
<deryck> Morning, all.
<jml> morning
<allenap> noodles775: I tried to land it yesterday but there were some test failures. I'm away until Tuesday and I probably won't have enough time to fix it before then, sorry. I'll migrate any code that lands before then though.
<noodles775> allenap: np. Enjoy your break!
<allenap> noodles775: Cheers :)
<leonardr> salgado, i'm looking into the oauth token scope thing we talked about yesterday, but i'm remembering other problems with it. for instance, a web service client with a scoped oauth token can't get the service root
<leonardr> because the service root is not in scope
<leonardr> an oauth token is also scoped to a person, but the person will be out of scope
<salgado> leonardr, when things are out of scope the client should have read access still, no?
<leonardr> salgado: we'll find out. i don't know if i actually tested this
<leonardr> so it could still work
<salgado> maybe that's not how it works today, but I think that's how it should work
<leonardr> that makes sense
<leonardr> wgrant, we have a solution to the timeout problem i last talked with you about on july 20th
<leonardr> i'm delegating to benji the responsibility for updating the script you're running on optusnet.com.au
<leonardr> basically, you need to upgrade to the latest versions of launchpadlib and lazr.restfulclient
<leonardr> you need to make your script use edge (until the changes are deployed in the next launchpad release)
<leonardr> and if you were using the ._wadl_resource.total_size hack to get the length of a collection, you need to change that code to use len()
<leonardr> gary -^ delegating to benji
<gary_poster> ack thanks
<leonardr> salgado, i see how the oauth context could be a specific project or distribution or whatever, but not how it could be a particular _class_ of object. do you have any ideas?
<salgado> leonardr, indeed, the scope is a db object and not a python class.  you could scope it to the person, but I guess that wouldn't help you in this case?
<leonardr> scoping it to the person would be a good start
<leonardr> or maybe not... since the person's oauth tokens are probably not considered to be in scope
<leonardr> i'll give it a try
<deryck> wow, comment fonts are huge on my system now.
<deryck> Feel like I'm reading a large print old-folks book.
<benji> deryck: I just noticed the same thing; I like big text but that is taking it a bit far :)
<deryck> benji, indeed :-)
<deryck> It's falling back to monospace for me and at 116%
<deryck> perhaps the percentage worked for whatever font we used to request.
<benji> I'm not aware of a way to have different sizes for different type faces... but I'm no CSS expert either.
<deryck> I don't seem to have a mono version of the ubuntu font either.
<deryck> jml, hi.  See my good-god-that's-a-huge font comments above. ^^
<deryck> jml, should I file a bug on launchpad-web?
<jml> deryck, huh what, yes.
<deryck> heh
<jml> deryck, there's no Ubuntu monospace yet.
<jml> soon, I'm told.
<deryck> ok, I didn't think so.
<deryck> jml, should we just scale back the percentage on the monospace then, since we know we're only using that currently?
<jml> deryck, sorry, otp, that sounds reasonable
<deryck> jml, np.  Sorry to interrupt.  I'll work up a branch now and see how it looks.
<jml> deryck, np
<jml> deryck, a bug with screenshots would help the reviewer.
<deryck> jml, ack
<jml> deryck, beuno, fwiw, they don't look huge to me.
<jml> oh, 'comment fonts'
<beuno> jml, right
<beuno> and merge proposal diffs
<jml> no, same as ever.
<deryck> beuno, they do look huge to you?
<beuno> deryck, yes, huge
<beuno> I'll take a screenshot
<deryck> beuno, yeah, they look huge to me, and benji confirmed.  But just making sure.
<deryck> jml, they don't look huge to you?
<deryck> I've add my own screenshot at bug 624666
<_mup_> Bug #624666: Monospace fonts too large after adding Ubuntu font to font-family declaration <launchpad-web:Triaged by deryck> <https://launchpad.net/bugs/624666>
<benji> do my fonts look big in this?
<deryck> benji, I just meant you said comment fonts looked large to you too.
<benji> that was a (failed) joke, a la "does my butt look big in this"
<deryck> I assumed this happened with the font change, bzr blame says sinzui changed the 116% rule for comments.
<deryck> benji, :-) Ah.
<sinzui> I landed the branch
<deryck> ah
<jml> benji, I chuckled.
<benji> at least I'm not a total failure
<adeuring> gary_poster: could you help me get a clue why the tests in lines 155, 165 from this diff https://pastebin.canonical.com/36336/ are failing? And why the test in line 145 is _not_ failing (it should, because I commented out lines 59,60)? Or: How should I set up test for ProxiedLFA.(http|api)_url for webservice requests?
<deryck> I just thought benji's fonts looked fine
<benji> deryck: that's what you always say
<deryck> sinzui, you have no objections then to me changing the 116% to get a sane look
<deryck> heh
<sinzui> go ahead
<gary_poster> adeuring: looking
<sinzui> deryck, I do not see a size change in the diff
<beuno> deryck, jml, FWIW: http://ubuntuone.com/p/Dwt/
<beuno> sinzui, ^
<adeuring> gary_poster: https://pastebin.canonical.com/36340 has the test failures
<sinzui> deryck, the 116% has been there a long time. I think the font is just different
<gary_poster> ack
<adeuring> so, the host name is wrong, and 'api/devel' is missing in the URL
<deryck> sinzui, ok, that's what I thought.  But the rule used to just be "monospace" if the diff is to be believed.  Since there's no ubuntu monospace, we should still be using that.
<deryck> but at any rate, a percentage change will not harm us, I think.  Until we have the real font.
<deryck> 116% seems too large to me anyway.
<jml> beuno, it's kind of meaningless without a "before" screenshot.
<beuno> jml, really?  the huge-ass difference isn't meaningful?
<deryck> jml, the fonts don't look large to you?
<sinzui> deryck, You could have the real font, or the beta font, or you could choose to keep Monospace (system font--either dejavu or Bitstream depending on the ago)
<beuno> I'll take a screenshot of production
<leonardr> salgado, i've shelved the scope thing for now. i think it might work, if we hack the 'container' code (about which i know nothing) or hack the code that uses the container code so that the service root and top-level collections are always considered to be in scope
<beuno> I think jml is doing drugs again
<leonardr> i have another problem, which i hope you or benji can help with
<jml> deryck, beuno: they look obviously configured differently to what I have.
<deryck> jml, do you have the ubuntu mono font?
<deryck> installed, I mean
<beuno> jml, but look at the difference in size between the diff and everything else
<leonardr> i thought i had traversal set up correctly, and indeed i can access /~salgado/+oauth_access_tokens/token-name with GET
<beuno> I do not have the ubuntu font, tw
<jml> deryck, no.
<deryck> jml, ok.  Can you use an inspector and see that the rules for the fonts are for you?
<leonardr> but when i PATCH that same URL, i get a 404. it looks like launchpad is trying to find token-name directly under ~salgado and ignoring the +step_into that tells it (should tell it?) to look up an access token
<leonardr> does this problem seem familiar?
<jml> deryck, I use Courier for monospace in my browser, for example
<deryck> ah
<jml> beuno, irrelevant. that stuff is totally browser configurable.
<sinzui> deryck, I switched the Ubuntu fonts the day of the announcement, and I set a custom CSS in my browsers so that I always saw the fonts...bold was very ugly for a few weeks
<beuno> jml, so what are you saying?
<deryck> So I would think the size rule should be sane for the default, and if people are configuring fonts in the browser, they can adjust accordingly there.
<jml> beuno, that to file a useful bug about font changes being bad, you need to have before & after screenshots
<deryck> would jml, sinzui, beuno agree? ^^
<beuno> jml, deryck, sinzui, here's a screenshot of production: http://ubuntuone.com/p/Dx1/
<gary_poster> adeuring: here's one thing.  setUpApiInteraction correctly sets up the request, *but not the publication* or the virtual host bits.  So that *might* be important for your test.  However, my suspicion is that your test is actually showing a real problem either wat.  If it is a web interaction *or*an api interaction, api url should be stable, I would think, yes?
<beuno> deryck, sure, I have not changed any default
<adeuring> gary_poster: yes
<beuno> jml, there, before and after. Go nuts.
<jml> deryck, agreed.
<adeuring> gary_poster: I mean, the URLs should be the same
<jml> beuno, Already gone.
<gary_poster> adeuring: right.  So whether or not setUpApiInteraction is sufficient seems irrelevant
<adeuring> gary_poster: erm, probably ;)
<deryck> beuno, can you attach those as before/after shots on  Bug #624666?
<_mup_> Bug #624666: Monospace fonts too large after adding Ubuntu font to font-family declaration <launchpad-web:Triaged by deryck> <https://launchpad.net/bugs/624666>
<beuno> deryck, sure
<gary_poster> aseuring, how you calculate api_url is relevant, of course.  I'm not sure what a proper way of doing that would be.  What are you trying?
<deryck> thansk!
<deryck> "s" took over for both gary_poster and I there.
<adeuring> gary_poster: Basically, I copied the approach for http_url which enforces non-api URLs
<gary_poster> lol, true deryck
<Ursinha> StevenK, hi, can I  mark bug 449408 as qa-ok?
<_mup_> Bug #449408: Need scriptactivity monitoring of "gina" <boobytrap> <canonical-losa-lp> <gina> <qa-needstesting> <Soyuz:Fix Committed by stevenk> <https://launchpad.net/bugs/449408>
<gary_poster> adeuring: Unless you really want me to look at that code, I'm going to run away, since we appear to have agreed that the test itself is not (exactly) at fault. ;-) I'm late for a call.  Do you want me to ping you later?
<adeuring> gerthat would be great
<gary_poster> ok cool
<bigjools> Ursinha: he's in bed but he did already QA it
<Ursinha> ah, cool
<Ursinha> thanks bigjools
<beuno> sinzui, the only difference I see is in the font-family (font-family:"UbuntuBeta Mono","Ubuntu Mono",monospace;)
<beuno> production doesn't have the first 2
<sinzui> beuno, yes. I think the font has different metrics than dejavu/vera
<bigjools> Ursinha: the qa bot is removing ok/untestable tags which is really annoying :(
<Ursinha> bigjools, it removes the tags if you place them before it being available to qa...
<bigjools> Ursinha: that's bogus, we might have already tested it on dogfood
<Ursinha> bigjools, if you commit a fix with incremental or no-qa tag, it won't replace untestable tags
<bigjools> ah
<Ursinha> bigjools, I recall having this discussion with you two months ago :)
<bigjools> yes
<rockstar> Ursinha, maybe your bot can check for the tags that it shouldn't be replacing.
<rockstar> I think adding more noise to the commit message is sub-optimal.
<Ursinha> rockstar, I think suboptimal is leaving things untested behind :)
<Ursinha> rockstar, point is script should replace. if you have something qa-ok, and you land another branch related to the same bug, you need to qa that
<Ursinha> so script replaces
<rockstar> Ursinha, it should add, not replace, methinks.
<Ursinha> if that doesn't need qa or is a partial fix, there are two clauses to express that
<Ursinha> rockstar, two qa tags in a bug is confusing
<Ursinha> specially considering the new mergeworkflow lifeless planned
<rockstar> Ursinha, I don't think it's all that confusing.  As long as it shows up in the qa-untestable list, it's served its purpose, right?
<gary_poster> rockstar, we're talking about scripts that have to parse these tags and interpret them according to agreed-upon rules.
<Ursinha> what gary_poster said
<gary_poster> Certainly we can change those scripts, but then we need to agree on the rules again.
<jml> when I get back from hols, I'm going to start trying to get down some requirements from you guys re QA
<jml> (OEM, Platform & others want something built-in to LP)
<gary_poster> And arguably this is an example of an impedance mismatch between using tags, a rather imprecise tool by intent, to control QA, which is supposed to be much more precise and controllable.
<leonardr> salgado, fun fact: my lp_save() on the oauth token seems to have *dissociated it from the user*, which is why i'm getting that 404
<gary_poster> Yeah, that would potentially address the impedance mismatch, jml.
<jml> *nod*
<jml> there's also an issue building tools that work with an informally managed staging environment (i.e. dogfood)
<gary_poster> yeah.  a one-size-fits-all qa feature, or even a one-size-fits-many, will be tough.  Our roll-our-own-locally qa integration has its advantages.
<deryck> jml or abentley, I'm playing local dev server with MPs.  How do I generate the diff locally?
<jml> deryck, no idea, sorry.
<deryck> np, thanks anyway.
<leonardr> salgado: ARGH. the access token was disappearing because i was setting its expiration date to a date in the past
<salgado> leonardr, heh.  but does it work when you set a date in the future?
<salgado> I mean, can you change it?
<leonardr> finding that out now
<leonardr> we need to change lazr.restful (or possibly the client) to understand what happens when setting a field value causes the object to disappear
<leonardr> salgado: yes, i can change the expiration date to a date in the future. (however, i have given up hope for the time being of making GRANT_PERMISSIONS anything more than an all-powerful access level, so it's not too surprising)
<deryck> This YUI cssfont stuff is confusing to me.
<deryck> sinzui, there are places where our rules to use the ubuntu font work, but others where yui's rules have precedence.  I don't understand why.
<sinzui> really. I think all font-family's were changed
<deryck> sinzui, YUI has the arial,helvetica, blahblahblah line that wins out for some items.
<sinzui> deryck, But at what level? I think our rules supersede them
<sinzui> deryck, can you show me a page that is using YUI's font rules?
<deryck> sinzui, I would have thought so, too.  That's why I'm confused.
<deryck> sure, digging for link
<sinzui> I have never seen arial in any launchpad page that I inspect. I do that a lot. I recall we had a nasty bug hunt in YUI to ensure it's widget rules (like the calendar) never surfaced
<sinzui> oh, rockstar updated our YUI rules last month. I wonder if our older version was directly hacked.
<rockstar> sinzui, what YUI rules?  I haven't landed the newest YUI yet (I need to squeeze more into lazr-js first)
<deryck> ok, so I think I got the problem wrong.
<sinzui> rockstar, good to know
<deryck> it's not that the YUI rule has precedence.  It's that *no* rule applies.  See comments on any MP, for example.  What font is that?
<deryck> sinzui, ^^
<rockstar> sinzui, I'll send an announcement when I do it.
 * sinzui looks with inspector
<deryck> rockstar, hi.  How do I generate diffs in a local dev server for MPs?
<rockstar> deryck, there's a script called create_merge_proposals I think.
<deryck> rockstar, cool, thanks.  Was searching for scripts with "diff" in the name :-)
<sinzui> deryck, you may be looking too close to the text. merges...
<sinzui> deryck, pre defines monospace in YUI, but I see our rule is ignored
<rockstar> deryck, LPCONFIG=development bin/py cronscripts/merge-proposal-jobs.py
 * sinzui looks at source
<deryck> sinzui, what I'm trying to work out is why this patch fixes comments having the large font for bugs and leaves MP comments unchanged?  http://pastebin.ubuntu.com/484011/  And playing with the inspector, if I delete all font rules on MPs the font is unchanged.
<jcsackett> can someone help me understand an odd comment/if statement in the validate method of lp.bugs.browser.bugtask.BugTaskEditView?
<jcsackett> method is here, with comment asking for clarification: https://pastebin.canonical.com/36347/
<deryck> jcsackett, I can likely help.  looking....
<jcsackett> thanks, deryck.
<sinzui> deryck, since our pre matched YUI's pre, we did not define a font rule. Ours does not match, so we want to define one now
<sinzui> deryck, you must put the ubuntu fonts back
<sinzui> the UX team have a hammer and they hit everyone who disobeyed them last year when they defined font rules
<deryck> sinzui, right.  I want the Ubuntu fonts. :-)  I'm trying to understand why changing the rule has the affect it does.
<deryck> the patch is not what I'm proposing as a fix.  Merely as a reference to get to a real fix.
<sinzui> deryck, we need to add fonts to "pre, code, samp, tt, .console {"
<sinzui> and I think we want to change the font-size from 116%; to 108% or 100%
<deryck> sinzui, ok, that makes sense.  And this is going to change the look of bugs and MP comments.  And we don't currently use the monospace font there, so I assume make it the same Ubuntu choice in html, body?
<deryck> i.e. UbuntuBeta, Ubuntu, 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif
<sinzui> ??
<deryck> sinzui, what I mean is comments don't currently use a monospace font, right?  on lpnet.
<sinzui> deryck, I think you are saying that we did not set font-family because YUI was providing what we wanted "Monospace".
<deryck> no, sorry
<sinzui> deryck, I think we are changing scope here, but you will close a lot of bugs if all comments were made monospace
<sinzui> UbuntuBeta Monospace, Ubuntu Monospace, Monospace
<deryck> yeah, I'm not sure if I want to go that route yet, only because there doesn't seem to be agreement about that.
<deryck> but I could just JFDI
<deryck> ;)
<deryck> jcsackett, sorry for delay.  Doing too much at once here.  So old_product and new_product reference just products.  "pillar" is a wrapper method that gets at the target regardless of being a product or a distribution.
<sinzui> deryck, lets get the font size right, and define the the expected monospace fonts on "pre, code, samp, tt, .console"
<jcsackett> deryck: okay, so in that instance, though we're working with products predominantly, the target isn't necessarily old_ or new_ product?
<deryck> sinzui, agreed.  Working that up now, testing locally to see fall out.
<deryck> jcsackett, I read the comment below the if check to suggest the check against pillar there is to make sure we don't somehow have a distro task.
<jcsackett> deryck: okay, thanks.
<deryck> I'm not sure how we would, but evidently it happened once :-)
<jml> deryck, the 'if old_product is None' is surely about not being a distro task
<jml> s/not//
<jml> scratch that correction.
<deryck> jml, right.  If old_product == None this would be a distro.
<deryck> re-thinking the question about doing new_product.official_malone
<jml> I guess you can't change the bugtask of a product that doesn't use Launchpad because the remote tracker won't detect it?
<jml> or something?
<deryck> jml, right.  You create a watch if it doesn't use malone.  But the question jcsackett has is why not new_product.official_malone.
<deryck> jcsackett, I'm rethinking this.
<jml> deryck, why not instead or why not in addition to
<deryck> sorry, why not right it as new_product.official_malone instead.  Why do we need to check on the pillar, rather than the new_product.
<jcsackett> deryck, that was sort of my confusion.
<deryck> jcsackett, jml -- so doing it on the pillar prevents having to spell it (new_product is not None and new_product.official_malone)
<deryck> maybe, that's it?  I'm not entirely sure.  Were it me, I would change it and run bugtask tests and see what fails.
<jml> lemme check again
<jml> deryck, has the new_product been set on the bugtask at the time of the if statement?
<deryck> I'm jumping on a standup now, so an as exercise in "hey remember when we ..." I'll ask if anyone knows :-)
<jcsackett> deryck: sounds good. :-)
<deryck> jml, this is a validate method.  So you could submit the form without supplying new_product and it would be None.
<jml> deryck, that's what I mean, bugtask.pillar will be old_product (or a distro), not new_product
<deryck> right
<deryck> so it really seems wrong
<jml> deryck, unless there's a reason for preventing changing bugtasks that are on products that don't use malone officially
<deryck> ah
<deryck> yes
<deryck> so we don't want to move a bugwatch off
<deryck> or move a task that is for a watch
 * deryck is on call now
<jml> not actually on topic, but I'm reminded of how much look-before-you-leap sucks
<jml> mrevell, wb
<mrevell> thanks jml ... power cut ... country living, etc
<mrevell> bac, every 15 mins, I believe
<cody-somerville> when did the text for bug change history get so big?
<maxb> losa ping: The branch on which lp:~launchpad-pqm/bzr-builder/trunk is stacked has been renamed, and the bzr-level stacking pointer is now wrong.
<maxb> Please could you download this script: http://j.maxb.eu/~maxb/bzr-set-stacked-url.py - and run bzr-set-stacked-url.py lp:~launchpad-pqm/bzr-builder/trunk lp:bzr-builder
<Chex> maxb: let me take a look at that for you
<maxb> thanks
<jml> :(
<jml> cody-somerville, today.
<Chex> maxb: get a failure when I try to run it: https://pastebin.canonical.com/36352/
<maxb> Chex: I can't see pastebin.canonical.com
<Chex> maxb: sorry about that.
<Chex> http://pastebin.ubuntu.com/484045/ try that
<Chex> maxb: ^
<maxb> oh, I see. First run 'bzr launchpad-login your-lp-id' so bzr knows how to connect via bzr+ssh
<jml> abentley, a bunch of changes on the recipe LEP
<mthaddon> maxb: erm, is there really no better way of doing this?
<mthaddon> maxb: I'm not very happy about download a random script off the internet and having an admin run it
<maxb> Well, you could hack the .bzr/branch.conf directly if you like
<maxb> er, .bzr/branch/branch.conf
<mthaddon> maxb: there's no way to do this in the web UI?
<maxb> no
<mthaddon> maxb: if not, it seems to me like there should be a bug report about it rather than trying to work around it
<mthaddon> (or at the very least, a bug report and trying to work around it)
<maxb> The fundamental problem is that when a branch changes name, Launchpad doesn't update the bzr-level metadata in stacked branches to say so.
<maxb> I believe someone mentioned they were actually working on fixing that next cycle
<mthaddon> sounds very much like the basis of a bug report to me
<mthaddon> :)
<maxb> I'm assuming that if someone's already decided to work on it next cycle, there's already a bug filed
<mthaddon> maybe, but we really should have asked you for that info before going ahead and doing it :)
<maxb> bug 377519
<_mup_> Bug #377519: Stacked on location breaks if the stacked upon branch is renamed <branch-stacking> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/377519>
<maxb> mthaddon/Chex: It doesn't seem to have changed yet, did you want me to describe fixing it by editing files rather than using the script?
<jml> I'm off. Have a great time folks.
<maxb> mthaddon? Chex ?
<Chex> maxb: hi there
<Chex> maxb: yes it may make more sense for you to describe the files we need to look at
<maxb> OK then, please edit the file lp:~launchpad-pqm/bzr-builder/trunk/.bzr/branch/branch.conf (either directly or over sftp) such that the stacked_on_location line now reads: stacked_on_location = /~bzr-builder-devs/bzr-builder/trunk
<Chex> maxb: sorry, looking around now
<adeuring> gary_poster: ping
<gary_poster> adeuring: didn't forget, call day
<adeuring> gary_poster: ah, ok
<maxb> Chex: Hi, I'm semi-afk for ~15 minutes, then ircing from a phone only for the rest of the evening. I will read anything you say here, but my responses might be delayed/limited
<Chex> maxb: thats fine, we have a process/script to handle this issue, apparently
<Chex> running it now, just slow going
<Chex> maxb: all set, should be fixed now. in the future, remind us admins of this equest by asking for the 'LP process to Fixing Broken branches'
<Chex> request, that is
<maxb> thanks Chex, with any luck lo will get fixed properly soonish to not create this issue
<maxb> s/lo/lp/
<Chex> maxb: agreed. your welcome
<lifeless> morning
<lifeless> Ursinha: I think ther emay be room to permit not-replacing, but it will need careful thought about race conditions
<Ursinha> lifeless, I agree with that
<lifeless> mthaddon: if you're around, I would love to touch base, however briefly, on the staging-with-prod-schema progess.
<lifeless> and I ashamed to say, its entirely a 'are we there yet' question.
<Ursinha> lifeless, I have to reply your bug comment about tags
<lifeless> gary_poster: so, private librarian
<lifeless> gary_poster: have you seen the wildcard-dns proposal ?
<gary_poster> on calls today lifeless--but it doesn't ring a bell unless it was the branch stub was looking at with you a few weeks ago
<lifeless> yeah that one
<lifeless> I'm thinking of picking it up
<lifeless> librarian is consistently very high up there
<gary_poster> ah, yes.  It looked like a great idea to me
<lifeless> ok cool
<gary_poster> lifeless, btw, have been concerned lately thinking about edge/production on same machines/processes: it gives us arguably a bit less safety in trying out big infrastructure changes--say, trying a broad change to the template implementation.  Now, if edge service degrades significantly, there is an escape hatch.  edge will no longer be an easy way to do that.
<gary_poster> I don't think this is a necessarily huge deal, but I do suspect that it will drive us into some new patterns.  One is for us to be able to easily upgrade a single load balanced machine with certain code changes and evaluate its performance.  If that's relatively easy and lightweight for devs and LOSAs, that might work.
<gary_poster> And it might be a better story than what we have now, for the end users.
<lifeless> from what I know of the deployment process, that should be straight forward
<lifeless> we'd qa the the change so we're happy with performance on staging
<lifeless> which btw, implies we want a load test harness
<lifeless> then, when we're happy, we can rollout the icing, and some N appservers, and monitor them,
<lifeless> gary_poster: I think it will be a better story than we have today, once we get the db schema changes more agile
<lifeless> in the interim I think it should be no worse.
<gary_poster> sounds reasonable.  load test harness: ack and agreed.
<lifeless> I understand that SSO was tested with such a thing; I don't know if its scalable in terms of request pattern complexity to LP
<lifeless> it might be nice to just take a days worth of logs
<lifeless> or a week
<lifeless> and toss the exact same pattern at a staging env; with something special to handle POSTs
<gary_poster> yeah; POSTs/webservice is the trick, I think
<lifeless> one thing we could do is ask for volunteers; use a featureflag to enable it and capture their posts
<lifeless> would only work if we had a point-in-time recovery for the to-be-tested environment rather than 'current data' recoveryt
<lifeless> anyhow, EFUTUREWORK
<gary_poster> lifeless: exactly what I was going to say about point-in-time and POSTs, agreed.  and yes EFUTUREWORK.
<lifeless> gary_poster: great minds
<gary_poster> ;-)
<gary_poster> adeuring: if you are still around I have about about 12 min
<adeuring> gary_poster: great!
<gary_poster> where should I look?
<adeuring> gary_poster: https://pastebin.canonical.com/36336/ and https://pastebin.canonical.com/36336/
<gary_poster> right thanks
<adeuring> https://pastebin.canonical.com/36340/
<gary_poster> ok...
<adeuring> gary_poster: I also tried setupInteraction() but only got even more weird results
<gary_poster> heh
<gary_poster> adeuring: ok, I think I see your strategy now.  You want getURL to come up with the right URL on the basis of the request passed in.  I am afraid it needs to be more sophisticated...or canonical_url needs to be more sophisticated :-/ .  Lemme go look at that implementation again.
<adeuring> gary_poster: ok
<gary_poster> adeuring: I think you need to explicitly pass in the right rootsite to canonical_url.  Seeing if I can learn more...
<adeuring> gary_poster: that's what I tried, via setupinteraction() -- seems that I messed thatup ;)
<deryck> bryceh, Just fyi....  without reviewing too closely, I think your model/db changes are on track.
<bdmurray> I'm having issues running make build on devel No local packages or download links found for zc.buildout==1.5.0
<bdmurray> and Link to http://pypi.python.org/simple/zc.buildout/ ***BLOCKED*** by --allow-hosts
<bdmurray> How can I sort this out?
<deryck> I thought we had out own zc.buildout.  You shouldn't have to hit pypi.
<bryceh> deryck, ok
<deryck> bdmurray, the first "no package" error I've seen before, and fixed by various combinations of updating source deps, make clean, make.
<gary_poster> bdmurray: make sure your download-cache is up-to-date
<gary_poster> ``cd download-cache && bzr up``  in the common case
<gary_poster> leonardr: I am trying to look at an issue for adeuring.  He is trying to generate API urls for objects.  AFAICT, canonical_url doesn't have sufficient smarts for this--in particular, it does not insert a webservice version into urls.  It also has no way of guessing what version of the webservice should be used if you are not already coming in on a webservice request.
<gary_poster> Do you know if there is a pattern for this already?  http_url in lib/canonical/launchpad/browser/librarian.py returns the current request's url, AIUI, right adeuring?  He would like to generate a url for a librarian file proxy even if the current request is not a webservice request, right adeuring?  adeuring, do you want a specific policy as to what version should be returned, or would you want a function to retu
<gary_poster> versions, or...?
<gary_poster> sorry, he would like to generate a *webservice* url for a librarian file proxy...
<lifeless> does that really make sense ?
<lifeless> I mean, isn't the proxy an implementation detail; we havce the LFA separately
<gary_poster> only if there's a use case :-)
<adeuring> gary_poster: well, the code works fine when you access launchpad.dev via launchpadlib. My main issue is the test...
<lifeless> and the LFA can and should be on the API; but the proxy itself, really that should just be the launchpadlibrarian.net URL
<leonardr> gary: you can convert a website request into a webservice request, and i think when you do you can specify a version (or it will use the latest version)
<lifeless> we *do not want* to serve librarian contenxt via the API
<lifeless> adeuring: ^
<lifeless> adeuring: what is your use case
<gary_poster> leonardr: ah, that makes sense, thanks
<adeuring> lifeless: the usecase is access to ProxiedLFAs via launchpadlib. The is a bug about it, just a second...
<gary_poster> lifeless, adeuring, I'm getting out of the way :-)  I was just trying to help
<lifeless> gary_poster: you're not in the way at all :)
<adeuring> lifeless: bug 620458
<_mup_> Bug #620458: cannot access attachments of private bugs any more <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <https://launchpad.net/bugs/620458>
<lifeless> gary_poster: I'm just leaping on the meta issue
<gary_poster> heh, but I want to consider myself in the way so I can go do other things ;-)
<lifeless> gary_poster: fair enough ;)
<leonardr> gary: specifically, you can cast a request to IWebServiceClientRequest--but i don't know what is the launchpad adapter
<adeuring> leonardr: the adapter works fine -- testing this is a problem for me...
<lifeless> adeuring: ok, I see
<lifeless> uhm
<lifeless> I'd really rather just finish fixing the private librarian to emit correct public urls
<lifeless> adeuring: I can almost guarantee that this API will hard timeout a huge amount
<lifeless> the apport retracer runs in the DC
<adeuring> lifeless: sure...
<lifeless> can we not just give it the restricted librarian URL for now ?
<adeuring> lifeless: hrm.... what about other people who ant to acces private librarian files via launchpadlib?
<adeuring> s/ant/want/
<gary_poster> sinzui: ping
<lifeless> adeuring: what about them ? :)
<lifeless> adeuring: if they are in the DC, its easy.
<sinzui> hi gary_poster
<lifeless> adeuring: if they are not, then we'll *increase* the chance of timeouts and simply not be serving them well
<lifeless> adeuring: we'll also, because the librarian client has bugs, run a real risk of DOSing the entire appserver cluster.
<gary_poster> hi sinzui! the linter doesn't like a line in schema-lazr.conf because it is too long
<gary_poster> is this alright?
<gary_poster> -cookie_domains: demo.launchpad.net, staging.launchpad.net, launchpad.net, launchpad.dev
<gary_poster> +cookie_domains: demo.launchpad.net,
<gary_poster> +                staging.launchpad.net,
<gary_poster> +                launchpad.net,
<gary_poster> +                launchpad.dev
<gary_poster> things still work
<gary_poster> tests pass and such
<gary_poster> but you are keeper of those keys
<lifeless> adeuring: I have a branch that is about 40% done, which will expose the restricted librarian publically
<lifeless> adeuring: using an access token.
<lifeless> adeuring: when that is done, the API can be used to get an access token for such a file.
<lifeless> adeuring: the basic mechanism will be:
<lifeless>  - LFA can hand out a token on request
<adeuring> lifeless: I remebr you idea
<sinzui> gary_poster, yes that works because indentation implies continuation, *and* the callsite is splitting on whitespace
<lifeless>  - the token goes into a short lived store
<lifeless>  - the user gets https://contenthash.restricted.launchpadlibrarian.net/name?token=XXX
<lifeless> adeuring: cool
<sinzui> gary_poster, that fix is okay, but I would not assume that always works. I think we should tell lint to not check for long lines in conf files
<gary_poster> sinzui: ok.  Should I not make that change then, do you think?  I have one other question for you: a mini review of a CSS change.  let me put a pastebin up one sec
<sinzui> gary_poster, I can make the pocket-lint change.
<adeuring> lifeless: so, you think we should for now simply return the restricted librarian URL in the property api_url in this diff: https://pastebin.canonical.com/36336/ ?
<sinzui> I can review the CSS
<adeuring> (SORRY, ITS A BIT LATE FOR ME)
<gary_poster> sinzui: ok thank you, I will revrt the line changes to the conf file then.  Here's the CSS.  http://pastebin.ubuntu.com/484149/
 * adeuring cant turn off caps lokÄk,,.
<gary_poster> (it is a bit late for you, after all :-) )
<gary_poster> sinzui: this is CSS for developer-only profiling bits
<gary_poster> by biggest question is where it should go in the file, though of course you may have other concerns
<sinzui> gary_poster, is profiling_info used by more than one page?
<gary_poster> sinzui: potentially by every page in LP
<gary_poster> it will be used when someone puts a ++profile++ in the URL
<lifeless> adeuring: I think that that would work. I am really very concerned (maybe I shouldn't be) about the risk of very long requests on the appserver farm
<lifeless> adeuring: alternatively
<lifeless> adeuring: you could flip the bit back to how it was before your change, to let apport work ?
<adeuring> lifeless: erm, then we would have againa public attachment in prvate bugs, right?
<lifeless> adeuring: yes, but we tolerated that for 5 years or so
<sinzui> gary_poster, hide_reveal_profiling implies it is a link because it is underlined but it is red. we use blue or green else where
<gary_poster> sinzui, ok fair enough.  (this is developer-only, but consistency is nice)
<adeuring> lifeless: yes, but frankly, i would feel quite uncomoftable when we "opened" the attachments again
<adeuring> let's try the restritced librarian URL
<sinzui> gary_poster, yes, the point of pointing something in the global css is consistency :)
<gary_poster> :-) true
<sinzui> gary r=me with the  colour change. Thank you very much for structuring the rules so clearly
<gary_poster> thank you sinzui!
<lifeless> adeuring: it will need an RT ticket to open firewall access, but that should be quite trivial
<adeuring> lifeless: OK; let's discuss this tomorrow (or in the evening your time) -- it's too late for me now ;)
<thumper> aah... nice coffee smoothing the pain of morning
<cr3> thumper: I noticed I was getting older when it started taking more coffees to smooth the pain
<thumper> cr3: :)
<mwhudson> morning
<mwhudson> i don't think that's "older" i think that's just "too used to coffee"
<mwhudson> go without for a month and it starts to have more of an effect again :-)
<thumper> mwhudson: back on the coffee again?
<mwhudson> thumper: somewhat
<mwhudson> trying not to have more than 2 cups of coffee a day
<thumper> I'm trying to limit myself to around 6 shots a day
<thumper> normally taken 2 at a time
<thumper> home espresso machines are good
 * lifeless is detoxing
<lifeless> been *so tired* for the last two days
<lifeless> thumper: good, evil, its a fine line
<lifeless> thumper: you want a catch up?
<mwhudson> oh man, the week where i first stopped drinking coffee about a year ago was horrid
<thumper> lifeless: yes, I'll ping you later
<mwhudson> lifeless: i'm not sure you should be hacking canonical.launchpad.webapp under these circumstances :-)
<lifeless> mwhudson: indeed
<wgrant> added: lib/lp/archiveuploader/tests/test_securityuploads.py.THIS
<wgrant> (from devel r11453)
<wgrant> That seems like a mistake.
<jelmer> wgrant: yep
<jelmer> wgrant: also, hi :-)
<mwhudson> whoops
<wgrant> jelmer: Morning.
<jelmer> thumper: I'd be interested in having a pre-implementation call about code import bug linking sometime.
<jelmer> wgrant: Thanks for removing buildbase btw. It conflicted quite heavily with my builddmaster async branch, but it's great to finally see it gone.
<wallyworld> morning
<jelmer> hi wallyworld
<jelmer> wallyworld: Welcome :-)
<wallyworld> thanks :-)
<thumper> hi
<wallyworld> thumper: g'day
<mwhudson> hi wallyworld
<wallyworld> g'day mw
<wgrant> Hi wallyworld.
<thumper> wallyworld: see... already more interaction than yesterday
<wallyworld> hi william
<wallyworld> thumper: yes, indeed
<wgrant> :( Distribution.getDevelopmentSeries doesn't return FROZEN series.
<wgrant> So my scripts are broken :(
<thumper> wgrant: really?
<thumper> wgrant: I thought it would
<wgrant> So did I.
<lifeless> .
<wgrant> Really?
#launchpad-dev 2010-08-27
<maxb> It would appear that Google Maps is rejecting Launchpad's requests
<maxb> e.g. https://launchpad.net/people/+me
<wgrant> Bug 624981
<_mup_> Bug #624981: The Google Maps API server rejected your request <maps> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/624981>
<lifeless> spm: when you are around, I want a profile please
<spm> lifeless: your name is Rob, Your Y yrs old; live in Z ??
<lifeless> spm: funny man :P
<lifeless> spm: on staging
<lifeless> as soon as it finishes updating
<lifeless> I want to hit up https://api.staging.launchpad.net/1.0/bugs/414746/attachments
<_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
<lifeless> also
<lifeless> https://api.launchpad.net/1.0/1.0/bugs/414746/attachments/+login har!
<_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
<lifeless> when an API times out
<lifeless> it gives the usual OOPS
<lifeless> with a link to login
<lifeless> which then blows up
 * spm is running out of tabs that aren't doing 'useful stuff' I may have to open a 2nd konsole of 16+ terminal tabs....
<lifeless> did you say konsole?
<spm> aye. best terminal around, I've found.
<spm> tabs at the *bottom* <== biggest positive feature over any other I've found
<lifeless> <- xterm
 * wgrant quickly emails Ng.
<lifeless> well, technically, uxterm.
<spm> heh
<spm> wgrant: i don't think he cares too much. and well, if it makes him cry? I see that as a plus.
<spm> lifeless: so the restore is gtetting there; just doing the importds atm. maybe 5-15 mins eta?
<lifeless> spm: cool cool
<wgrant> The linter doesn't run henninge's thing, does it?
<wgrant> Would be handy, to stop imports from going bad.
<spm> lifeless: revised eta, another 5-15 mins. sigh. still going. looks to be doing stuff on the staging buildmaster...
<lifeless> spm: hows it looking ?
<spm> [10:22:28] <spm> staging codebrowse just went down, so must be getting closer...
<spm> make build LPCONFIG=staging <== on multiple builds/machines. painfully slow. we should probably look into parallelising that. but /me worries about KISS and debugging obscure staging update woes.
<lifeless> oh yay, db-devel merge failures
<lifeless> and so it begins
<thumper> lifeless: want to catch up?
<mwhudson> spm: we really really shouldn't be running make build from scratch on every machine
<mwhudson> that's just bong
<spm> and wrong
<lifeless> thumper: sure
<lifeless> spm: I can haz profile ?
<spm> one sec, working iwth u1 atm
<spm> lifeless: asuka is doing the nightly.sh run, so be ware it will be slower than usual; if you consider that actually possible
 * spm is still trying to unstack/pop about 4 levels of yesterdays interrupts... sigh/woe is me/ etc etc etc
<lifeless> spm: yes I still want a profile
<wgrant> LP needs a GitHub-like commercial offering.
<lifeless> define that please
<wgrant> At the moment, you need to get a private project set up manually and poke sysadmins and blah blah.
<wgrant> And it's far more expensive than GitHub's cheaper offerings.
<mwhudson> lp would also need to start supporting commercial customers better & it's not clear that this is a useful use of resources
<wgrant> Well, there are no other bzr hosting solutions around.
<wgrant> And GitHub is a really compelling reason to use Git.
<persia> So the social benefit of causing more engineers to use bzr for their closed-source efforts is expected to outweigh the social benefit of making it easier to host open-source stuff?
<wgrant> Well, the former would probably cause more wide-spread use of bzr.
<wgrant> At the moment, if your company wants to use a DVCS, they are probably going to choose Git. Because GitHub is there. That's what I've heard so many people say.
<maxb> Personally, I think bzr needs self-hostable hosting solution to properly enable corporate use of bzr
<wgrant> For many cases, yes.
<wgrant> win 41
<wgrant> Gah.
<lifeless> so, self hosted via self deployed LP is possible, but traumatic
<lifeless> it would be nice if that was easier
<lifeless> wgrant: that story does need to be easier; for sure.
<wgrant> I guess we need Vostok, but ripping out everything but Codehosting instead.
<lifeless> there was talk at one point of developing a self-hosted solution for bzr completely separate to LP
<lifeless> spm: ping me when you're ready
<thumper> lifeless: there was but it was shot down with a BIG gun
<thumper> I didn't agree with the argument
<thumper> I think there should be a simple deployable codehosting solution for corporates
<thumper> based on bazaar
<lifeless> spm: ping me when you're ready
<spm> lifeless: timing is everything.was just loggng into asuka to set that up :-)
<lifeless> thumper: I think there should be too. I would love it if it had common code with codehosting
 * thumper nods
<spm> lifeless: just about to restart app server
<lifeless> duh da
<lifeless> duh da
<lifeless> duh da duh da duh da
<spm> .... waiting.....
<spm> yay. down.
<spm> starting....
<lifeless> I'm glad it starts up quickly
<spm> it lives!
<lifeless> ok, you can turn that off, thanks.
<thumper> anyone fixing the merge conflict?
<thumper> anyone?
<spm> lifeless: you may wish to try again; it's only just started working, ish.
<lifeless> if you can expedite the rsyncing of the trace and oops (OOPS-1700S32) that would be great.
<thumper> beuler?
<lifeless> thumper: its his day off
<thumper> haha
<lifeless> no, I'm not currently fixing it
<spm> lifeless: all done? I'll restart
<lifeless> spm: yes
<spm> oki
<lifeless> spm: though I won't know the quality till I get the files ;)
<spm> nmp
<spm> sorry. forgot the 'I wear evil horns' smily there... oh well, it was implied.
<thumper> wallyworld: feel like trying out fixing the merge conflicts?
<thumper> wallyworld: you can say no if otherwise engaged
<spm> lifeless: they should be synced
<thumper> lifeless: is "from datetime import datetime, timedelta" ok with our new import style?
<thumper> lifeless: or do I have to put them on multiple lines?
<lifeless> its fine
<wallyworld> you mean some issues caused by my branch?
<thumper> wallyworld: no
<thumper> wallyworld: I mean the current merge failure between stable and db-devel
<thumper> wallyworld: are you getting those failure emails?
<lifeless> spm: hmm, i'm not seeing my oops :(
<spm> lifeless: ahh. pebkac. one sec.
<wallyworld> thumper: i've subscribed to canonical-launchpad digest but hadn't been looking in too much detail
<thumper> wallyworld: ok, I'll fix it
<wgrant> lifeless: I was under the impression that the exception was only in place for single-symbol imports.
<lifeless> wgrant: < 78 chars or whatever
<wallyworld> thumper: i don't mind doing it but if it's time critical then you will be faster than me. but i can look at it np
<spm> lifeless: hrm. not pebkac; looks like a script buglet somewhere. but there now: /srv/launchpad.net-logs/staging/asuka/profiling/
<thumper> wallyworld: I'm sure we'll get some practise next week
<lifeless> wgrant: frankly I think any time spent talking about it is too much :)
<thumper> I'll take this one
<wgrant> lifeless: https://dev.launchpad.net/PythonStyleGuide?action=diff
<lifeless> wgrant: sorted one per line when there are many gets better merge conflicts; when there aren't many, anyway its done is ok
<lifeless> meh
<lifeless> ok-by-me then
<lifeless> spm: its thinking rather more now ;)
<lifeless> spm: its almost like it hasn't been rsyncing since the 3rd
<spm> lifeless: mmmm. possibly.
<lifeless> -rw-r--r-- 1 robertc robertc 239303 2010-08-27 14:11 2010-08-03_02:04:49.560-MailingListApplication:MailingListAPIView-OOPS-1676S234-Dummy-3.prof
<spm> I dod suspect a script buglet - we have a new shiny ponies script; so...
<lifeless> was the newest file I had
<lifeless> note - 27th was when I got it, 08-03 when it was made
<spm> nod
<lifeless> spm: I has it, thanks
<lifeless> anyone familiar with bugs code around ?
<wgrant> I know parts of it.
<wgrant> What's the issue?
<lifeless> https://bugs.edge.launchpad.net/malone/+bug/618849
<_mup_> Bug #618849: Timeout accessing bugs' attachments using the API <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/618849>
<lifeless> have a look at that to get the context where I'm looking
<wgrant> Wow those are fat comments.
<lifeless> mine?
<wgrant> All comment fonts are huge. The CSS must be broken.
<lifeless> you have the beta installed don't you ?
<wgrant> Yeah.
<wgrant> Is anybody working on the broken profile page thing?
<lifeless> ?
<wgrant> lifeless: All profile pages are broken due to the Google Maps thing.
<wgrant> They pop up an alert().
<lifeless> so, its a maps problem
<lifeless> for now we're waiting to see if they resolve it
<wgrant> Is it? The Google thing that Curtis mentioned looks irrelevant to me.
<lifeless> AIUI
<lifeless> why? didn't fit the symptoms ?
<wgrant> Well, it seems specific to another Google service. But perhaps it is more general.
<lifeless> omg
<lifeless> omg omg omg omg omg
<lifeless> lib/lp/bugs/browser/bug.py line 522
<lifeless> *this is not safe*
<wgrant> .....
<wgrant> Haha.
<lifeless> lets go and pull 140+ objects from the database
<thumper> the font size issue is known
<mwhudson> lifeless: oof
<thumper> and being worked on I believe
<mwhudson> lifeless: makes me think of some of this spec code
<mwhudson> "find all specs named $x then filter out the ones that aren't targeted at $foo"
<mwhudson> (fortunately given how specs are used this probably isn't so bad, but...)
<wgrant> mwhudson: In Python, not SQL?
<mwhudson> wgrant: yes
<wgrant> Yay.
<persia> mwhudson, specs get used (or not) the way they do because of the limitations of the impementation, rather than the intent of the users.
<mwhudson> persia: well, maybe, but also it's actually unlikely that there are many specs in the system with the same name
<persia> There are social conventions in place to avoid that, leading to exceedingly frustrating names for Ubuntu specs (${release-target}-${responsible-team}-${relevant-area}-${real-spec-name})
<mwhudson> persia: well yeah, but even if you just used ${real-spec-name} i conjecture that there would be <10 duplicates for any given name
<mwhudson> it's not like lifeless's code that could be getting 100s of objects for no good reason
<persia> Potentially.  I was involved in the nomenclature discussion, but most example cases were 2-3 with the same name, rather than >10.  I agree it's good optimisation, I just think it's dangerous to base "how to design blueprints" based on current blueprints usage (as opposed to theory, which is safe)
<spm> persia: you're not suggestion that stakeholders are consulted are you? that's: 1. crazy talk and 2. heresy!
<mwhudson> persia: sure
 * mwhudson has one of these "how does this code work at all" moments
<persia> spm, No.  I'm just asking for blueprints design based on blue-sky theory, rather than partial analysis of current usage in an attempt to divine the potential desires of conceptual stakeholders.
<mwhudson> awesome!
<mwhudson> it doesn't
<wgrant> mwhudson: What's broken?
<wgrant> Apart from the entirety of Blueprint?
<mwhudson> wgrant: go to add a dependency to a blueprint, click choose, type some text and search
<mwhudson> though it's timing out for me actually, not exploding quite like i expected
<persia> That's blueprints.  Expected behaviour
<mwhudson> ok, it's not completely broken
<mwhudson> just stupid
<lifeless> mwhudson: can I encourage you to do one thing.
<mwhudson> lifeless: sure
<lifeless> mwhudson: add query-capped tests to the views you touch.
<mwhudson> lifeless: um
<lifeless> mwhudson: doesn't matter what the count is, just put a ratchet there ;)
<mwhudson> heh
<mwhudson> actually probably not touching any views really
<mwhudson> but ok
<lifeless> mwhudson: we currently have no insurance for query blowouts
<lifeless> mwhudson: its all 'someone analysed this once and made it good', then something changes, and because our code has the property that what looks like good python performs terribly, *boom*
<thumper> if I have a method that yields and is used as a generator
<thumper> and I have an edge case where I don't want to yield anything
<thumper> what do you do?
<thumper> raise StopIteration?
<lifeless> return
<mwhudson> thumper: 'return'
<lifeless> it will be a generator because of the yield statements
<thumper> ok
<lifeless> mwhudson: so anyhow, I think its sensible to put *an* insurance policy in place.
<mwhudson> lifeless: ok
<lifeless> what is salgado used for in tests ?
<mwhudson> too much
<mwhudson> the default webservice caller uses him i think
<mwhudson> which is crazy, because he's an admin in sample data :(
<thumper> how do we ask that we are running in a test environment?
<thumper> I have a view that uses the slave store
<thumper> but for my test I need to use the master
<thumper> to see the new data
<thumper> stub: any magic I can use?
<wgrant> In Soyuz we just commit. It's ugly, but I think it's better than a special case that might break.
<stub> thumper: Sounds like you need a database policy that returns the master store even when the slave is requested. I think there is one in dbpolicy.py already.
<thumper> stub: where is that?
<stub> thumper: nah.... need to add MasterOnlyDatabasePolicy - SlaveOnlyDatabasePolicy can be cargo culted for that.
<stub> thumper: lib/canonical/launchpad/webapp/dbpolicy.py
<stub> with MasterOnlyDatabasePolicy(): [...]
<thumper> stub: this is for a pagetest, is your solution still sane?
<stub> I don't know
<thumper> I think the answer is no
<thumper> can I ask the config which environment we are in?
<thumper> is that sane?
<thumper> or just insane?
<stub> I've done it before, but then the code your testing isn't the code that will run on production
<stub> How come you can't just commit the changes you made to the master so they are available to the slave?
<thumper> I'll just commit
<lifeless> hmm, exported_as doesn't work if there is an attribute with the same name that isn't exported.
<lifeless> what project should I put the bug on? lazr.restful ?
<mwhudson> yes
<lifeless> https://bugs.edge.launchpad.net/lazr.restful/+bug/625102 \o/
<_mup_> Bug #625102: exported_as does not handle overriding an unexported attribute <lazr.restful:New> <https://launchpad.net/bugs/625102>
<noodles775> Morning
<noodles775> thumper: When I want to split a pipe into two, i add a new pipe before the last one, then how did you interactively include only certain changes? It was something similar to shelve?
<noodles775> thumper: sorry, just realised you've probably EOD. nm, enjoy your evening!
<noodles775> Ah, merge -i... wonderful.
<wgrant> Yep, merge -i is pretty awesome.
<lifeless> wow
<lifeless> adding one attachment adds 10 queries ><
<adeuring> good morning
<bigjools> stub: do you know if it's possible to use the result from store.execute() like a ResultSet?
<stub> The interface is a little different
<bigjools> I need it to work in the batch navigator
<bigjools> so count and slicing is all that's needed I think
<stub> It might work
<bigjools> I shall give it a go then :)
<stub> Otherwise convert it to a store.find   (store.find(Foo, SQL("hairy where clause")))
<bigjools> (I'm trying to put the results of findBuildCandidate into a page)
<bigjools> I doubt that would work, take a look at findBuildCandidate... :/
<jkakar> FYI, am getting a Javascript alert complaining about an invalid Google Maps key when navigating to https://edge.launchpad.net/~nick-moffitt
<stub> Are we using Vouchers or is that dead code?
<wgrant> They're still used for commercial subscriptions, AFAIK.
<jtv> lifeless: any reason why installFixture should not return its argument?
<jtv> mrevell: Any comments on the help bubble so far?  I put the branch up for review, since it's a substantial code improvement in any case.  If there's anything you _hate_ about it I can still opt not to land, or if there's something that's not quite the way you want it then we can do that as a separate bug.
<jtv> What's wrong with EC2?  I'm getting "remote host identification has changed" errors all the time, meaning I have to delete ~/.ec2/known_hosts again.  Also, startup takes ages.
<jtv> Also, does anyone know how I can choose a different EC2 site?  I can think of one that must be at least 4 megameters nearer than the one I'm getting now.
<jelmer> jtv: IIRC you can change EC2 sites in the console. IIRC there are only sites in east/west coast of the US and Europe though
<jtv> jelmer: and singapore!
<jtv> thanks
<jtv> Singapore is quite, quite nearby in terms of internet infrastructureâ¦  Some ISPs here will probably take traffic for a US EC2 _through_ Singapore.
<jtv> (And then it gets slow due to poor bandwidth allocation, so in principle I could speed things up by running a proxy in the Singapore EC!)
<davidstrauss> Where can I find the Bazaar SSH smart server integration into Twisted Conch?
<davidstrauss> Is it the Poppy code?
<jelmer> davidstrauss: Hi
<davidstrauss> jelmer, hi!
<jelmer> davidstrauss: No, poppy is the server code that's used for package uploads.
<davidstrauss> jelmer, ah
<davidstrauss> jelmer, what is the twisted daemon for branches?
<jelmer> davidstrauss: My guess is lp.codehosting.sshserver
<davidstrauss> jelmer, thanks
<bdmurray> I received an error when trying to land a cherry pick on production devel that I could use some help sorting out
<bdmurray> All lines of log output:["PQM Cannot merge between different VCSsystems.
<bdmurray> 'bzr+ssh://bazaar.launchpad.net/~brian-murray/launchpad/cherry-pick-bug-modifier'(pqm.Baz1_1Handler) and
<bdmurray> '/home/pqm/archives/rocketfuel/launchpad/production-devel'(pqm.Bazaar2Handler) are different
<jelmer> bdmurray, are you sure 'bzr+ssh://bazaar.launchpad.net/~brian-murray/launchpad/cherry-pick-bug-modifier' exists?
<jelmer> bdmurray, pqm seems to think there is a bazaar 1 ("baz") repository at that location
<bdmurray> jelmer: yes, I'm sure - would the fact that it is a private branch affect it?
<jelmer> bdmurray: probably - is the launchpad pqm able to access that branch?
<jelmer> bdmurray: I think it has to be subscribed.
<bdmurray> jelmer: no, I'll give that a shot then
<bdmurray> that's a rather unhelpful error message
<jelmer> bdmurray: It probably defaults to thinking there is a "baz" repository there if it can't find anything else.
<bdmurray> jelmer: any idea how I could try resubmitting the branch?  bzr lp-land is failing since it is a private branch
<jelmer> bdmurray: You can use "bzr pqm-submit", which is part of the bzr-pqm plugin.
<jelmer> Alternatively, you should be able to construct a PQM email manually.
<noodles775> bdmurray: you can subscribe launchpad-pqm to the branch and it should then work.
 * noodles775 realises that's been tried.
 * rockstar physically relocates
<lifeless> morning
<daker> hello
<daker> can anyone explain to me what is this http://is.gd/eH471
<daker> ?
<lifeless> yes, we believe its a known outage at Google
<lifeless> https://bugs.edge.launchpad.net/launchpad-registry/+bug/624981
<_mup_> Bug #624981: The Google Maps API server rejected your request <maps> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/624981>
 * sinzui is experimenting with a brute force use of featureflags to control gmp2
<benji> I was thinking along the same lines.  Seems like a perfect use for them.
<daker> lifeless, thanks
<sinzui> benji, the controller objects are not all in production. I am writing my code to what I see in a production test instead of what is in our development tree
<benji> mmm
<lifeless> sinzui: \o/
<benji> I would suppose your result will be trivially translatable to the real thing once it's deployed.
<sinzui> yes
<sinzui> this is not the first time google has failed us
<sinzui> we talked about a way to toggle maps on/off last year
<lifeless> sinzui: a flag ?
<lifeless> ah
<lifeless> thats what gmp2 is
<lifeless> ?
<sinzui> lifeless, there are many versions of gmap. we use a specific version. We need to track their version. Having flags for the version we want is ideal
<lifeless> cool
<lifeless> I think feature flags can return a value
<lifeless> if they can't, its a small tweak to make them do so
<lifeless> or you can use different flags, one for each version
<sinzui> correct. We had some adventures shortly after we added maps and the versions changed.
<cr3> if I run testr -t my_application, it seems that 62 tests match, so is there a way to specifically run the tests for my application?
<lifeless> testr -- -p packagename
<lifeless> it depends on your app structure really
<cr3> lifeless: I'll give that a try
<lifeless> its runnin bin/test under the hood
<cr3> lifeless: ./bin/test --help seems to indicate that -p is for progress (where testr -- -p package gets translated to xvfb-run ./bin/test --subunit  -p package
<lifeless> cr3: the -- says 'to the right, pass onto the test process
<lifeless> cr3: I was told -p was package
<lifeless> perhaps its -m you want
<lifeless> anyway, all I'm saying is that its a bin/test problem for defining 'my application'
<cr3> lifeless: heh, understood :)
<lifeless> I'm no expert on bin/test :P
<cr3> what's the difference between lib/lp/<application>/scripts/tests  and lib/lp/<application>/scripts, where both sometimes contain test_*.py files?
<cr3> the first path is apparently recommended for containing tests as detailed here: https://dev.launchpad.net/Testing
<cr3> actually, my mistake, scripts doesn't contain test_*.py files (not that I've seen anyways), my mistake. nevermind :)
<lifeless> :P
<cr3> lifeless: I'm obviously writing my first test for launchpad
<cr3> lifeless: how can I use testr to show the details about the tests that were run instead of just the number of tests?
<lifeless> apply one of jmls patches I haven't merged
<lifeless> or
<lifeless> subunit-ls < .testrepository/XX
<lifeless> testr will show failures always
<cr3> lifeless: looking good, thanks!
<cr3> is there a document on dev.launchpad.net for modifying the database schema? I see lots of files under the database/schema directory and I could tentatively create a patch with a sequentially numbered filename, but I'm not sure that'll make everyone happy
<salgado> cr3, https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
<cr3> nevermind, found the answer in the README file conveniently located under that directory
<salgado> (from database/schema/README)
<salgado> :)
<cr3> I'm running preliminary tests and would like to access the database, so I'm using getUtility(IStoreSelector).get(MAIN_STORE, DEFAULT_FLAVOR). but, when I try to retrieve rows, I get: ProgrammingError: permission denied for relation result
<cr3> might there be an obvious reason for this?
<cr3> in a test, setting a breakpoint with pdb.set_trace() doesn't seem to show anything when running testr. should this be done otherwise?
<lifeless> you haven't granted permission in security.py
<lifeless> do that
<james_w> cr3: are you running as a special db user do you know?
<lifeless> and run make schema again
<cr3> aha! nevermind that last question, running ./bin/test directly and not piping to testr load works fine
<lifeless> cr3: ?! thats new, and I have no idea how that could be happening
<cr3> james_w: I looked around for special db privileges and didn't find anything, but it certainly feels that way since I'm getting an error from storm execute
<james_w> cr3: take a look at database/schema/security.cfg
<james_w> there is where the permissions for various tables are granted to various users
<james_w> if you aren't running a script in your test then it is likely that you are just running as the "launchpad" user
<cr3> james_w: crap, I didn't get to step 13 yet in the database policy. my bad, thanks!
<james_w> add public.result = SELECT, INSERT to [launchpad_main] and you should be good to go
<cr3> james_w: awesome, I was just wondering how to prevent UPDATE and DELETE on the table so that solves another problem :)
<cr3> james_w: while I have your attention, is there a special user with autocommit isolation level?
<james_w> don't know
<cr3> I'll grep around, that should be easy to find if such a user at least exists
<james_w> you probably don't want that if you are running the webapp context are you?
<cr3> in some cases, it is desirable to run some statements that way
<james_w> well, you have transaction.commit()
<james_w> you may want to defer some of your processing in to a script outside the webapp context
 * james_w -> dinner
<cr3> maybe I'll have a function that checks for the conflict exception, whatever that might be. lots of exploration to do, we'll see
<cr3> security.cfg did the trick, thanks folks!
#launchpad-dev 2010-08-28
<wgrant> buildd-manager appears to have met some form of unpleasant demise ~2 hours ago.
<cody-somerville> wgrant, why does it always die on the weekends? lol
<persia> The folks standing over it slowly pouring the lubricant at just the right rate take a break.
<wgrant> cody-somerville: :(
<cody-somerville> And it appears devpad is on the fritz so I can't even see whats wrong.
 * cody-somerville will escalate to IS in the morning if it hasn't been fixed by then. Hopefully lifeless or some other lp developer will come around and they can do the escalating instead. :)
<persia> Already nighttime in NZ.
<elmo> buildd-manager got stuck on an ssh to a dead/dieing arm
<elmo> I killed the ssh but it didn't recover
<elmo> stabbing the whole thing in the face now
<persia> \o/
<wgrant> elmo: Thanks.
<wgrant> Odd that it didn't recover, though.
<elmo> sigh, it's stuck on kaylaberry again
#launchpad-dev 2010-08-29
<lifeless> what are snapshots used for ?
<cr3> how can I run doctests from a specific lib/lp/<application>/stories/webservice directory
<lifeless> bin/test -t application/stories/webservice
<lifeless> cr3: I hope you're not adding a new application though
<lifeless> cr3: or that your definition of application is not mine
<cr3> lifeless: sure am
<cr3> lifeless: maybe a bit from column A and a bit from column B
<cr3> lifeless: I'm adding the /+results namespace for the Results Tracker
<lifeless> I thought that that was going to use a different DB
<lifeless> as per the discussions you me & jml had it prague
<cr3> lifeless: flacoste and jml preferred it to be in the same db
<lifeless> mmmm
<lifeless> do you have minutes from that? I was there with jml when we talked about this
<cr3> lifeless: yeah, different db was indeed my original intention but that changed following discussion in montreal with both parties mentionned
<lifeless> and he didn't express such a preference at the time
<cr3> lifeless: are you sure that discussion was in prague rather than belgium?
<lifeless> Could you please drop me, jml, flacoste and thumper (virtual flacoste for a few weeks) a mail about this. Is there a LEP for what you're working on ?
<lifeless> cr3: after the LP epic, at the platform sprint. Very sure.
<cr3> lifeless: https://dev.launchpad.net/LEP/ResultsTracker
<lifeless> cr3: I don't believe jml has been to montreal since then
<cr3> lifeless: right, that's why I'm surprised the idea of a separate db was still around in prague
<lifeless> because:
<lifeless> well, actually, let me read the LEP
<lifeless> ok, I've read it
<lifeless> uhm.
<lifeless> When did you last sync up with jml on this ?
<cr3> lifeless: last we spoke was on the 15th of june, haven't had an opportunity to start working on the project since
<cr3> lifeless: I've quite excitedly started end of last week and perhaps it's been so long that a resync would be in order
<lifeless> well
<lifeless> here's my understanding
<lifeless> you were going to build a separate system, and integrate it into the LP UI
<lifeless> it was going to be separate because:
<lifeless>  - there's no solid schema for it yet, and changing schemas in LP is *extremely hard*
<lifeless>  - its not part of the core LP mission [today], and jml has a sort-of moratorium on putting more stuff in LP until we're actually really polished on we do do
<lifeless> I'm personally very excited about what you're working on.
<lifeless> If I have misunderstood, thats cool.
<lifeless> I have a -very- important thing for you though, either way.
<lifeless> *do* land every little thing separately.
<lifeless> *do not* get it all working and then submit it. LP's review process will not accept such a proposal.
<cr3> my initial proposal was design mostly to address the second concern rather than the first one. however, during my discussion with flacoste and jml in montreal (before the epic), it was decided that the results tracker should be in the core Launchpad (to my surprise :)
<cr3> lifeless: heh, that's actually why I'm working today. I started having too much code and I wanted to split that a bit into minimal chunks
<cr3> and when I say "too much", I really don't mean that much, but more than minimal :)
<lifeless> cr3: have you seen the review policy LP has on this?
<cr3> lifeless: I've been reading much of dev.l.n, but not the review policy. I've heard about the 600 or so line diff thing
<lifeless> ok cool
<cr3> lifeless: I'm very conscious (and afraid) that the review policy is probably very strict and conservative, so I'm developing accordingly... as is launchpad was a little squirrel and I don't want to scare it away :)
<cr3> s/as is/as if/
<lifeless> many things in LP are not structurally clear
<cr3> lifeless: do you still want me to drop you guys an email?
<lifeless> so its easy to end up reinventing stuff
<lifeless> cr3: Absolutely
<cr3> lifeless: will do
<lifeless> If its in LP, stub and I will need to get across your entire design to do a schema patch review, and consider all your use cases for indexing, performance, etc etc
<lifeless> its a freaking huge deal
<cr3> lifeless: tracking results is not trivial, so I'm actually glad it's a huge deal as it should be
 * cr3 is taking this freaking seriously
<lifeless> another reason not to put it in the same big bag
<lifeless> We have very limited scalability in LP today.
<lifeless> in 12-18 months I'd expect to be able to handle whatever your workload is; at the moment while we can scale for reads, we can't scale for writes.
<cr3> lifeless: in 12-18 months, I think we'll have a solid schema so timing might be right
<cr3> lifeless: for now, I'm quite happy making the interface strictly open to members of a specific team. the initial objective is to meet specific user stories one by one
<cr3> my current user story is tracking upgrade results from mvo
<lifeless> cr3: please drop (at least me) a mail, I'll ping jml this evening and flumper during the day
<cr3> lifeless: for some reason, bin/test -t results/stories/webservice doesn't run my doctest in the file xx-results.txt.
<lifeless> don't stop what you're doing
<cr3> lifeless: you can't make me! :)
<lifeless> cr3: you probably haven't setup the doctestsuite
<cr3> lifeless: how's that done?
<lifeless> have a look at one of the other domains
<lifeless> btw, your result tracker stuff probably belongs in either lp.services.resultstracker or as part of registry.
<lifeless> sinzui will know more
<cr3> lifeless: I'll ask him tomorrow, thanks
<cr3> lifeless: I looked at the hardwaredb domain and then tried ./bin/test -t hardwaredb/stories/webservice: 0 tests
<james_w> -t is funny about some things, sometime it has to be -t hardwaredb/tests/../stories/webservice
<cr3> james_w: that worked for hardwaredb, funny indeed
 * cr3 gots docs tests!
<lifeless> cr3: also btw
<lifeless> cr3: in launchpad, doctests are loathed
<lifeless> cr3: unless they truely are documentation
<lifeless> cr3: so, ask yourself: would the doctests you are writing be sensible to include on help.launchpad.net
<lifeless> cr3: if not, they should not be doctests. Please.
<cr3> lifeless: yeah, I read something about doctests being loathed in one of the Guides. however, that's where the api seems to be tested which probably makes sense to have on help.launchpad.net too
<lifeless> cr3: no
<lifeless> some of the api is tested in doctests, but like nearly every other doctest thats a hangover
<lifeless> don't copy it
<lifeless> really don't.
<lifeless> if you want to write *docs* for something, use doctests.
<cr3> lifeless: do you have an example of good unit tests for the api then?
<lifeless> if you want to write *tests* for something use tests
<lifeless> cr3: I only know a small fraction of the code base
<lifeless> perhaps ask on the list
<lifeless> or look in the code section; they are pretty gung ho testers, I'd expect webservice pyunit tests there
<lifeless> also remember to be clear what you're testing
<lifeless> if you're testing that A an B are hooked up in a certain way, test that, rather than testing that calling through A and B to C, D and E works.
<cr3> maybe if I have a unit test case use WebServiceLayer, that might work out well
<cr3> lifeless: don't worry, I was just testing that the web service worked, I wasn't testing the model layer which actually doesn't exist yet :)
<lifeless> test_bugs_webservice is one test file I know of that tests webservice stuff via a unit test
<lifeless> cr3: uhm, that sounds like a valueless test; we know the web service works.
<cr3> lifeless: I'm expecting the web service layer to be very thin, most of the code should be in the model layer which should probably use the DatabaseFunctionalLayer (still learning)
<lifeless> cr3: right, which means you should have approximately zero webservice tests.
<cr3> lifeless: we don't know that the '+results' namespace works though
<cr3> (note that I also want to talk about that namespace with sinzui tomorrow)
<lifeless> cr3: but we know the machinery; if you're registered you can do a multiadapter lookup to confirm it works against the relevant model objects, and you're done.
<lifeless> you might want *a* smoke test
<thumper> morning
<mwhudson> morning
<lifeless> hi thumper, mwhudson
<lifeless> do either of you know what 'snapshots' are for ?
<thumper> yeah
<lifeless> what are they for ?
<lifeless> thumper: also, did flacoste mention 'test result tracker' to you at all?
<thumper> working out which fields have changed in order to raise the object modified events
<thumper> lifeless: no, I didn't get a heads up about the result tracker
<thumper> but I have an email from Marc
<lifeless> ok, I will hunt jml down
<lifeless> yes, I twisted his arm into mailing :)
<lifeless> thumper: you probably don't need to do anything regarding it
<thumper> good
<thumper> :)
<lifeless> so, is there every any point in having CollectionFields snapshotted ?
<lifeless> mmm, rather 'which is more comment: CollectionFields should be | should not be snapshotted'
<lifeless> s/comment/common/
<thumper> it is a bit fluffy
<thumper> for example
<thumper> ...
<mwhudson> lifeless: intuition says 'should not' would be more common, but i doubt there's a one-size fits all answer
<thumper> no, actually I think it should be more  common for collections fields to be NOT snapshotted
<lifeless> mwhudson: Yeah, I'm thinking we should change the default
<lifeless> thumper: you just agreed with mwhudson
<thumper> lifeless: yes I did
<thumper> we do that sometimes
<lifeless> the 'no' confused me ;)
<mwhudson> there's something about the whole objectnotmodified event thing that makes me a bit uneasy somehow
<mwhudson> we don't use it very much
<lifeless> !
<mwhudson> and it's a very general mechanism that in full generality is very expensive
<thumper> eh?
<mwhudson> lifeless: am i wrong?
<thumper> we have a NOT modified event?
<mwhudson> oh sorry
<mwhudson> :-)
<mwhudson> objectmodified event
<lifeless> mwhudson: I'm just surprised at having an event for objectnotmodified
<mwhudson> dunno where that came from
<lifeless> mwhudson: some good toenails :)
<thumper> lifeless: can you add ian.m.booth to canonical-bazaar team plz?
<thumper> lifeless: actually, don't bother
<lifeless> I'm not sure I can
<lifeless> but if I can I will if you like
<lifeless> thumper: looks like jml is awl, so we may need to talk about the test tracker thing brielfy
<thumper> lifeless: ok
<lifeless> please name a time
<thumper> how urgent is it to talk about?
<lifeless> well
<lifeless> we have a new component, with many unknowns, no in-team maintainer, nor committed-resources-to-handle-oops-etc-from-out-of-team being developed.
<lifeless> its important to various teams to have it built, and built well, and there is also some confusion over the previously discussed design approaches which occured both before and after I became TA
<lifeless> so it doesn't have to be today
<lifeless> but if we do want to change the course, better to do it up front IMO
 * mwhudson glares at staging
#launchpad-dev 2011-08-22
<lifeless> do we still use the keyring trust analyzer ?
<wgrant> lifeless: I doubt it and I hope not.
<wgrant> But it doesn't seem to log to scriptactivity, so we'll never know.
<lifeless> hmm
<lifeless> where is that cronscripts branch
<wgrant> It's not in there.
<lifeless> ah, you checked ?
<wgrant> wgrant@lamuella:~/launchpad/lp-production-crontabs$ bzr grep email-clus
<wgrant> wgrant@lamuella:~/launchpad/lp-production-crontabs$
<wgrant> It was added in 2005 and hasn't really been touched since.
<wgrant> I blame jamesh.
<wgrant> Maybe he knows something.
<wgrant> I suspect it's been obsolete for 5 years, but we'd best check.
<lifeless> I think I had something to do with it too :P
<lifeless> I'll just delete it.
<wgrant> You appear too, yes.
<wgrant>    * robert.collins@canonical.com/launchpad--keyring-trust-analyzer--0--patch-1
<wgrant>      snapshotting current pgp work
<wgrant> But jamesh is all the later stuff.
<lifeless> IIRC I did the plumbing
<wgrant> Gets rid of stupid tests from canonical.launchpad, too.
<wgrant> Kill it!
<wgrant> Ah, I didn't do too badly last week.
<lifeless> ?
<wgrant> My stale appserver pid file is from before EOD on the Friday before!
<lifeless> class LogCollector(logging.Handler):
<lifeless> -yet- -another- -yes-
<wgrant> Heh.
<wgrant> They're mostly cleaned up!
<wgrant> lifeless: I guess there wasn't much fdt progress last week?
<lifeless> you guess well
<lifeless> not as much code as I hoped
<lifeless>  7 files changed, 750 deletions(-)
<wgrant> :(
<lifeless> can has revooo https://code.launchpad.net/~lifeless/launchpad/bug-830789/+merge/72371
<wgrant> Huh, only three gpghandler methods?
<lifeless> indeed
<lifeless> I'm not sure what to do with zeca
<lifeless> it seems massively overkill for it to be a twisted daemon
<lifeless> but I'd hate to have a transitive dependency on twisted for a web.py microservice
<wgrant> Probably.
<lifeless> so I need to either rewrite it, or have two entirely separate packages with gpg support stuff
<lifeless> I'm thinking rewrite
<wgrant> lifeless: Approved, but with lint.
<lifeless> hah
<lifeless> at least its valid
<wgrant> Yes.
<lifeless> wgrant: did you see privmsg ?
<wgrant> Missed that, sorry.
<jamesh> wgrant: I don't think we ever put the keyring trust analyzer code into production (at least, we didn't while I was working on LP)
<wgrant> lifeless!
<wgrant> You deleted the pygpgme sourcecode!
<wgrant> Yay.
<wgrant> Burn!
<StevenK> Re-add it so we can delete it again!
<lifeless> wgrant: yes, I did.
<lifeless> wheee 1800  OOPS-2059AY24   POFile:+translate
<StevenK> wgrant: It moves to an egg
<wgrant> StevenK: Yes.
<wgrant> But at least it's not a patched branch in sourcecode.
<StevenK> Bah, why do I still have a sourcecode/shipit directory
<jtv> I wish the test suite wouldn't leave my /tmp full of launchpadlib caches and my swap full of librarians.
<lifeless> jtv: you're experiencing librarian leakage?
<jtv> Yes.
 * jtv had no idea such a word existed
<lifeless> grah. I thought we'd squashed that
<lifeless> jtv: does that happen when no failures happen?
<lifeless> or only when you have failures / errors?
<jtv> No idea.  Don't know what the lifetime of a librarian is currently supposed to be, so I have no basis for comparison.
<jtv> I can tell you that the launchpadlib caches and the createdb templates (whatever those may be) are leaking with successful test runs.
<lifeless> its meant to be the lifetime of the layer
<lifeless> the createdb templaes - launchpad_ftest_template_1234 ?
<lifeless> or launchpad_ftest_1234?
<jtv> Trying it again now.
<lifeless> the former has a lifetime of test-runner-process
<lifeless> the latter is a lifetime of one-test
<jtv> A limited test run just leaked lp.createdb.launchpad_ftest_template_13091 and lp.createdb.launchpad_ftest_template
<lifeless> so the leak points for them are different
<lifeless> jtv: oh, these are files in /tmp ?
<jtv> Yes
<StevenK> I would really like to squash the test suite creating odd files
<lifeless> ok, please file a bug on them leaking;
<lifeless> they exist to workaround postgresql behaviour on concurrent CREATE DATABASE calls
<jtv> StevenK: so would I.  Passionately.
<lifeless> the former we can fix leaks of easily - when the test runner cleansup the temp template db it can remove the lock
<StevenK> One of the archiveuploader tests creates a strange file
<lifeless> the latter file is a bit harder to nuke safely
<jtv> lifeless: if the leak points are different, should they be the same bug?
<lifeless> jtv: could go either way
<jtv> StevenK: a big source of leaks on publisher tests for me has been the lack of publisher config pointing to temp directories.
<jtv> I'm trying a passing test that uses the librarian now, to see if that leaks.
<StevenK> jtv: I'm not really concerned about files in temporary directories -- I'm concerned about tests that dump random files into the source tree
<jtv> StevenK: yes, that's what I'm talking about.
<StevenK> steven@liquified:~% ls -1 /tmp/lp.createdb.* | wc -l
<StevenK> 105
<StevenK> RARGH
<jtv> It's a good thing suspend and hibernate don't work, so I reboot regularly anyway.
<jtv> lifeless: a successful test with the librarian just now did not leak a librarian.
<lifeless> thanks
<jtv> I wish I had time deal with that storm problem that broke the fake librarian.  :/
<jtv> lifeless: bug 830845
<_mup_> Bug #830845: Tests leak "lp.createdb" files in /tmp <Launchpad itself:Triaged> < https://launchpad.net/bugs/830845 >
<StevenK> I bet it's nascentupload
<jtv> I think I just got it from running registry browser tests.
<StevenK> I can recall one from archiveuploader and one from code tests
<jtv> lifeless: these look like empty marker files.  Would it help debugging to dump a stack trace into them?
<wgrant> Hmm, the unlock is in a finally: :/
<wgrant> lifeless: Do you understand sinzui's comment in bug #829105?
<_mup_> Bug #829105: Able to target to release that I cannot upload to <disclosure> <regression> <target-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/829105 >
<lifeless> jtv: no, they are just lock files
<lifeless> jtv: we use a lock to prevent calling CREATE DATABASE with the same template concurrently, because doing that breaks postgresql
<jtv> Exactly.  If you need to know where they are leaked from, it might help to know more about where they are created.
<lifeless> jtv: there is only one place that makes them
<lifeless> jtv: the stacktrace will be identical every time
<jtv> OK
<lifeless> the one without a number in it is made when we clone launchpad_ftest_template to a per-runner template
<lifeless> that reduces contention on db cloning in parallel test environments
<lifeless> the one with a number in it is made when we clone each concrete test db (because the same code runs each time)
<lifeless> wgrant: which unlock ?
<lifeless> wgrant: I think sinzui means 'before the recent retargeting work you could not do this' + 'if someone does it the impact is severe because of the inability to delete the task'
<wgrant> lifeless: The recent retargeting work is unrelated.
<wgrant> lifeless: The lp.createdb unlock.
<lifeless> wgrant: I can't remember which lock system I used
<lifeless> wgrant: but most won't delete the lock  because doing so can be racy
<wgrant> Ah.
<lifeless> e.g. with a lockdir, the lockdir itself is racy-as, but the object so locked can be locked reliably
<nigelb> Morning!
<wgrant> Hi nigelb.
<nigelb> Can haz review? https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
<nigelb> Morning wgrant
<nigelb> (actually, is it afternoon for you?)
<wgrant> It is 14:30
<nigelb> Ah
<lifeless> not its not, its 16:30
<nigelb> woah, didn't know you were living that far ahead in the future.
<wgrant> New Zealand doesn't exist.
<StevenK> nigelb: I think 'Checks if links of the form /bugs/100' should be re-worded
<_mup_> Bug #100: uploading po file overwrites authors list <iso-testing> <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/100 >
<nigelb> ah, yes.
<stub> I had a branch that set $TEMPDIR etc. per test, but then made the mistake of trying to enforce stuff to clean up temp files and it never landed :-(
<nigelb> StevenK: At, remove the first 'if'? :)
<nigelb> *Aah
<StevenK> That sounds better
<wgrant> jtv: Your em dashes offend me.
<jtv> Good.
<StevenK> Dear bzr push, GO FASTER
<stub> No problem here with the UK, but the US?
<jtv> StevenK: well I found out why my dputs to dogfood didn't work.  Next questions are why, and what to do about it.  In dput config section [dogfood], "incoming = %(dogfood)s/ubuntu" translates to "ubuntu".
<nigelb> StevenK: updated.
<StevenK> jtv: If you just ran dput dogfood <changes>, then that would explain it
<jtv> That's what I've always been told to run.  Is it wrong?
<StevenK> It can be. Where do you want your uploads to go?
<StevenK> If you say "Onto dogfood", I'll slap you
<jtv> âWherever on dogfood a test upload for an Ubuntu series is supposed to go.â
 * jtv thinks he dodged that slap rather nicely
<nigelb> heh
<StevenK> jtv: It depends if you are uploading to a ppa as well, you see
<jtv> I'm not
<jtv> As far as I know.
<jtv> I'm trying to upload to Ubuntu Ridiculous Rat
<StevenK> I think /ubuntu should be okay then
<jtv> Not /srv/launchpad.net/ubuntu-queue/ubuntu or somesuch?
<jtv> I mean, the poppy log suggests it's trying to write to /ubuntu
<jtv> (Unless it's not being very clear, which is also possible)
<jtv> exceptions.OSError: [Errno Path not allowed:] /ubuntu/farewell_1.0-1.dsc.tmp.1313988369.200371027.15260.1143614958
<StevenK> Hm
<jtv> Something called rootpath seems to be empty for some reason.
<jtv> But it's got to be something on my end, because it was working for RaphaÃ«l.
<StevenK> It's been too long since I dealt with poppy
<jtv> Oh, no, rootpath is okay; it's just that the path does not begin with it.
<jtv> Maybe it needs a restart.  One of the line numbers in the traceback was off by one.
<StevenK> jtv: My incoming = %(dogfood)s, and I think for distro uploads I use dogfood:ubuntu
<jtv> I was told to set incoming = %(dogfood)s/ubuntu (and then I use just dogfood, not dogfood:ubuntu)
<jtv> I see we have a script for starting poppy on dogfood.  How do we stop poppy though?
<wgrant> kill;
<jtv> There's no pidfile?
<StevenK> ps aux | grep poppy
<jtv> Grr
<lifeless> there should be a pid file
<StevenK> It could be created on prod by start-stop-daemon
<wgrant> But poppy is a twistd.
<wgrant> There should be one.
<wgrant> But ps is easier than tracking it down.
<StevenK> It's been running for 5 minutes, so I guess jtv has restarted it
<jtv> Yup
<jtv> But I'd much prefer to automate it.
<nigelb> StevenK: One moreround of reviews? :)
<jtv> wgrant: twistd generates pidfiles by default?  I didn't see anything in /var/run
<StevenK> nigelb: I didn't review the last one?
<StevenK> It does, yes. The default is ./twistd.pid
<StevenK> Which has to be the most useless thing EVER
<jtv> /var/tmp/poppy/poppy.pid!
<nigelb> StevenK: Oh. If you're busy, should I wait for OCR?
<StevenK> jtv: Which is wrong
<jtv> Oh
<jtv> It's definitely got the wrong pid in it, yes
<StevenK> And was created over 18 months ago
<jtv> Yup.  Delete.
<StevenK> nigelb: It gets awkward when jtv starts arguing with himself
<nigelb> Hehe
<StevenK> jtv: So we can fix startpoppy.sh to write a pid file
<StevenK> Personally, I don't care at all.
<StevenK> I track it down via ps and shoot it in the face
<jtv> Which is wonderful makework but personally I'd like to avoid participating in it.
<StevenK> Then don't complain when poppy doesn't have a pid file :-P
 * nigelb looks for another interesting bug to start work on.
<jtv> StevenK: I'm not complaining that poppy doesn't have a pidfile, I'm trying to clean up one bit of the mess that dogfood has become by people personally not caring at all.
<lifeless> wow, mega disrupted day. where did it go.
<stub> How do I create a private branch again? Registering a branch before push only seems to let me do a +junk branch
<wgrant> stub: code.launchpad.net/launchpad
<lifeless> OTOH 2 branches landed
<lifeless> stub: we should do a catchup call; we missed last week (but not right now)
<stub> k
<stub> Think we missed the previous week too :-)
<nigelb> what's the recommended way to update devel?
<nigelb> rocketful-get or just doign bzr pull inside it?
<nigelb> I've done rocketful-get, but I don't know if its "The Right Way (tm)"
<wgrant> rocketfuel-get is a good way to make sure sourcecode/download-cache/devel are up to date.
<nigelb> hmm, wonder rif I can get two branches landed on same day. *tries*
<lifeless> stub: we got the week before ;)
<lifeless> anyhpw
<lifeless> -> groceries
<jtv> StevenK: the dogfood:ubuntu did do the trick after all, thanks!
<jtv> I thought the "/ubuntu" in my config would obviate that.
<jtv> BTW poppy has a pidfile now, and startpoppy.sh has a sibling stoppoppy.sh.
<nigelb> all information related to user profile like timezone, go into registry, right?
<stub> What changed with gpgme recently?
<wgrant> We're using an egg instead of a branch.
<StevenK> Which is good.
<wgrant> No.
<wgrant> It's just better than a branch.
<stub> Make is failing until devel is merged in
<wgrant> poolie: You no longer need to retarget to null.
<wgrant> poolie: Expand the bugtask row and retarget to Ubuntu directly.
<stub> (gpgme is gone from sourcecode, but buildout won't build the egg until versions.cfg etc. has the update)
<stub> We don't test logout() anywhere. Fails when it attempts to redirect through codehosting to clear any secure codehosting auth cookie, which isn't running under the test suite.
<nigelb> ok, small world. I just realized who the author of pytz is.
<wgrant> stub: It's not tested end-to-end, no.
<wgrant> stub: That would be difficult, as I don't think testopenid supports logout.
<stub> Which would have been the next roadblock :-P
<wgrant> (it doesn't support login)
<stub> It doesn't? I thought it was the same as we use running a local dev instance.
<stub> (And logout fails on my local dev instance because... no codehosting.)
<wgrant> The redirect path is launchpad->codebrowse->OP
<StevenK> stub: There's a special make run for codehosting on .dev
<wgrant> I don't think testopenid.dev exposes a logout interface.
<stub> Or is it just my setup that doesn't have a working bazaar.launchpad.net?
<wgrant> Because it doesn't have authentication.
<StevenK> run_codehosting or something
<wgrant> Well, doesn't cache authentication.
<stub> So it would be a noop
<lifeless> we should move auth cookie maintenance to a microservice anway
<wgrant> It's SSO all the way down?
 * stub has a single line fix and no way to test it
<wgrant> stub: Oh?
<lifeless> wgrant: well, one possibility is to talk directly to sso; but that won't work with being openid consumer unless we teach sso about that too
<stub> I'll try getting a codehosting setup running locally
<stub> So the hardcoded redirect path works
<lifeless> wgrant: another possibility is a microservice (xmlrpc on the main appservers initially) which maintains session cookies
<jtv> StevenK, wgrant: any objections to a publish-ftpmaster run on dogfood?
<wgrant> lifeless: Oh, you mean for codebrowse?
<stub> lifeless: Not sure how that solves the problem, which is we need to clear cookies on a number of domains that are not always available.
<StevenK> stub: 'make run_codehosting' rather than 'make run'
<wgrant> jtv: None.
<lifeless> stub: it removes the cookies from those domains
<StevenK> jtv: Only that it will take EONS
<jtv> StevenK: all the more reason to get started as soon as possible!
<stub> lifeless: How does that work without requiring the authentication being treated as a web bug and blocked?
<jtv> Also, this run shouldn't take as long as normal ones do.
<lifeless> stub: let me check an assumption: these are all LP domains right ? *.launchpad.net ?
<wgrant> lifeless: Not quite. We go all the way through to SSO.
<stub> oh, yes. So no idea why we need to bounce through codehosting.
<wgrant> Well, unless you count login.launchpad.net as *.launchpad.net, in which case get out.
<lifeless> wgrant: I do
<wgrant> Die.
<lifeless> anyhow
<wgrant> Don't mess with SSO.
<wgrant> login.launchpad.net is hopefully not long for this world.
<lifeless> redirecting to SSO isn't what I was mumbling about.
<wgrant> We should treat it opaquely.
<lifeless> it was codebrowser + the wikis
<lifeless> which we only slightly log out of at the moment
<wgrant> The wikis aren't part of LP yet.... I'm not sure we should go near them.
<lifeless> anyhow, the real key point is we don't need to clear the cookie
<lifeless> we need to invalidate the session
<wgrant> Yes.
<lifeless> which is really quite different
<wgrant> We need to rewrite all our session management for everything.
<wgrant> Because it's wrong and inconsistent and hard to manager.
<lifeless> s/r\././
<wgrant> Yes.
<wgrant> I can't type.
<lifeless> aiieee
<lifeless> that paged in a phil collins song
<stub> logout is still broken running run_codehosting
<wgrant> Hah.
<StevenK> stub: What happens in that situation?
<stub> I don't seem to have bazaar.launchpad.dev
<wgrant> StevenK: 503
<lifeless> check your hosts
<lifeless> StevenK: you don't get logged out
<wgrant> Well, you only get logged out of LP.
<wgrant> Rather than LP+codebrowse+SSO
<StevenK> % grep bazaar.launchpad.dev /etc/hosts
<StevenK> 127.0.0.99      bazaar.launchpad.dev
<lifeless> which is still horribly partial
<lifeless> do we invalidate api tokens too
<lifeless> ?
<wgrant> Not sure if serious.
<lifeless> me? I am, logging out really should Log You Out.
<wgrant> What if I want my many cronscripts to not need resetting every time I want to log out on some machine somewhere?
<lifeless> provide an advanced partial logout
<lifeless> sane defaults and all that
<lifeless> your many cronscripts case is not the common case
<wgrant> So logging out on one machine should log you out of *all* machines?
<wgrant> There should be a way to revoke sessions and tokens, sure.
<wgrant> But having that be the default is insane.
<stub> INF [20110822-13:16:27.297] [47438788081408] loggerhead: Processed err https://bazaar.launchpad.dev/%2Blogout?next_to=https%3A%2F%2Ftestopenid.dev%2F%2Blogout [0.001 seconds]: ['TypeError: oops_start_response() takes exactly 2 arguments (3 given)\n']
<wgrant> lifeless!
<lifeless> stub: thank you!
<wgrant> lifeless: Does any other webapp do the s/Log Out/KILL EVERYTHING/ thing you are suggesting?
<lifeless> fixing
<wgrant> I've never seen it.
<lifeless> wgrant: its recommended by security folk AIUI
<wgrant> I've seen revoking all sessions and tokens on *password changes* recommended.
<wgrant> But never on logout.
<lifeless> wgrant: the distinction between oauth, browser session and machine session is not well understood by casual users
<wgrant> So we should make the default action blow everything up for advanced users?
<stub> tokens should only be revoked that are being used by the web browser on logout, not the ones that have been setup for use by command line/desktop integration etc.
<wgrant> Let me just log out...
<wgrant> Oh fuck now I have to reauthorize 30 scripts on 10 servers.
<lifeless> wgrant: don't conflate default-setting with UI
<lifeless> we could fix the 'get /logout' logs you out bug, moving logout to an actual post; supply a confirmation form with everything checked and let you unselect stuff you want kept (with the current session having an 'online this session' option beside it for quick selection.
<stub> Logout isn't logout everywhere - it is logout the web browser. Not logout on your laptop too, and deauthorize all your other clients.
<lifeless> stub: this is exactly the point, that subtlety is lost on casual users.
<lifeless> stub: they don't understand that e.g. the 'log in with gmail' button establishes a persistent 3rd party session
<stub> It doesn't
<stub> (ok - replace with twitter oauth argument)
<wgrant> We should certainly fix the OAuth token view to be a general authentication session management view, and make that obvious and next to the logout button.
<wgrant> But the browser logout button should log the browser out.
<wgrant> Not destroy the world.
<nigelb> from where does things go into the context?
<stub> I don't think the subtleties are lost. Most of what I see is that people expect their tokens to be destroyed on password change, not logout.
<wgrant> In a view, 'context' is normally the object that the view is on.
<wgrant> nigelb: ^^
<wgrant> stub, lifeless: Facebook doesn't do this, AFAIK.
<wgrant> And if Facebook doesn't, then I think even non-technical users are probably not too terrible about this concept.
<nigelb> wgrant: argh. So, how would I add a variable to that?
<lifeless> ugh
<wgrant> (replace "Facebook" with "99% of websites on the Internet" and it will still fit)
<lifeless> its wsgi oops thats broken
<lifeless> fixing
<lifeless> who knew... http://www.python.org/dev/peps/pep-0333/#the-start-response-callable
<stub> wgrant: No, which surprises people when they change their twitter password and linkedin is still connecting.
<wgrant> nigelb: Find the class, add an attribute to it.
<stub> wgrant: But that is password change
<wgrant> stub: Yes.
<nigelb> wgrant: the class I found from configure.zcml, but I can't find the other attributes defined there, which confuses me.
<wgrant> stub: I think defaulting to reset stuff on password change may be permissible, as long as it's very obvious what is about to happen.
<wgrant> But on logout is just insane.
<stub> wgrant: yes, and reset tokens on password auth is what I've seen recommended. I don't think I've seen it recommended for logout either (I thought initially lifeless meant the tokens being used by the javascript api, but I'm not sure they actually exist?)
<wgrant> stub: JS just uses the cookie for now.
<wgrant> We should certainly make it easy to do.
<wgrant> At present there's no way to revoke a remote machine's session.
<wgrant> Unless you are stub.
<stub> urg
<wgrant> s/machine/browser/
<stub> thought you meant an oauth token there :)
<wgrant> No, those have had a view to manage them since day 1 :)
<wgrant> Anybody up for a rather trivial review? https://code.launchpad.net/~wgrant/launchpad/bug-830803/+merge/72378
<wgrant> And https://code.launchpad.net/~wgrant/launchpad/bug-830849/+merge/72379 is a little bigger.
<StevenK> wgrant: r=me for the first.
<StevenK> wgrant: For the second, r=me, if there are already tests for _syncSourcePackages
<lifeless> stub: http://paste.ubuntu.com/672219/ should fix it for you
<lifeless> stub: I'm working on a test now
<lifeless> stub: (thats to python-oops-wsgi, easiest way is for you to checkout the trunk, set develop= . ../path/to/that/checkout and run bin/buildout again
<stub> Nah, its easier to do something else until it winds its way through ;)
<wgrant> StevenK: Thanks. It is tested somewhere (I ran into it some time in the last 15 branches), but I will add direct tests on transitionToTarget.
<StevenK> wgrant: In that branch itself?
<wgrant> StevenK: Yes.
<nigelb> StevenK: review? https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575 :D
<StevenK> nigelb: You know, stub is OCR today :-P
<nigelb> Is there a page saying who's reviewing when?
<wgrant> https://dev.launchpad.net/ReviewerSchedule
<nigelb> ah
<nigelb> stub: could you review the brach above?
<nigelb> :)
<stub> yo
<stub> nigelb: Not sure I approve of calling a private bug a bug with an invalid link - seems a separate case to test to me.
<wgrant> Hahahah
<wgrant> He was doing that, but then lifeless said they were the same case :)
<nigelb> That ^
<nigelb> Also, its similar to what happens in the UI.
<nigelb> I'm open to changing the text to make it clearer.
<stub> I think it is better to be explicit. Saves fallout if we linkify private bugs (which we can do if it is client side).
<nigelb> So, say "Bug 123 is either invalid or not visible to you"
<_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
<wgrant> nigelb: We treat invisible private bugs as not existing.
<wgrant> Say something like "Bug 123 does not exist", perhaps.
<_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
<stub> nigelb: No, it is invalid if you don't have access. Same as we 404 private bug pages rather than a no-permission errorcode.
<nigelb> I'm confused now.
<wgrant> *Test* both cases.
<nigelb> In one case, there's a private bug you have access to, it linkifies correctly.
<wgrant> The cases behave the same way.
<stub> nigelb: Simplest thing to keep me happy is a second invalid link, which is really invalid, in addition to the private bug, which is only invalid if you don't have permissions.
<wgrant> But test both.
<nigelb> stub: It does that.
<nigelb> The private bug case linkifies correctly if you do have permission
<stub> make_invalid_bug_links returns a single link, a link to a private bug.
<nigelb> My test case, however, uses a user who doesn't have access.
<nigelb> wgrant: Grar, lifeless told me to do the opposite.
<stub> Right. So we are testing that we handle private bugs correctly, but not utterly broken urls
<nigelb> Test one case since it should behave the same anyway.
<wgrant> nigelb: Yes. Normally I would agree. but this is a bit of an odd case, and I disagree with him.
<stub> Unless we defer that to searchBugs
<nigelb> Ok, so how do I create an invalid bug for sure?
<nigelb> (inside a test)
<stub> Bug a helper called 'make_invalid_bug_links' that returns a perfectly valid bug would certainly need a comment to avoid a WTF.
<nigelb> heh
<stub> nigelb: make a bug and add one to its id would be good enough.
<nigelb> okay, I'll update the test with both the cases.
<stub> (or add 1000 - add one will only be invalid until the next makeBug call.
<lifeless> jml: hi
<lifeless> stub: wgrant: testing the behaviour of searchIds is inappropriate for a view test :(
<wgrant> lifeless: It's a very unobvious implementation detail.
<wgrant> I think it's reasonable to test it here, as long as it's not too long.
<lifeless> mmm, this is really just exposing searchIds on an adhoc API
<stub> lifeless: make_invalid_bug() that returns a valid bug is WTF.
<lifeless> stub: the test being unclear ? sure :)
<nigelb> wtf, gpgme error when I run tests.
<stub> nigelb: Merge devel, run make.
<nigelb> okay.
<stub> nigelb: So lifeless and me sort of agree.
<nigelb> okay
<nigelb> so just add a comment to the test?
<stub> That would work.
<stub> 'As far as searchBugs() is concerned, this is an invalid bug to the currently authenticated user' or similar.
<lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/72380 can has review
<lifeless> stub: I'll land it with a version bump and do a new egg etc after the review
<lifeless> actually I see you are distracted
<lifeless> I will land a 0.0.2 tarball + lp simple tweak to use it, and you can review later.
<wgrant> StevenK: Test added.
<nigelb> stub: updated, could you land it as well?
<jtv> lifeless: I'll review it.
<lifeless> ok, man sensible-browser lies
<nigelb> I'm trying to fix bug 188187, should I add another property to the view class for that? Is that the right way?
<_mup_> Bug #188187: Please display offset to UTC with timezone info for profiles <easy> <feature> <lp-registry> <profile> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188187 >
<lifeless> jtv: thanks
<lifeless> nigelb: I would do it in the formatting of the field
<stub> nigelb: ok
<nigelb> lifeless: hm, where do I look to find that. I've been unsuccessful in finding that. I traced the it from the configure.zcml file and then got lost.
<nigelb> stub: Thanks!
<jtv> lifeless: done
<lifeless> nigelb: well, start with the view
<lifeless> nigelb: see what it does, does it do a formatter call, or access an attribute of the timezone object..
<nigelb> it access a context variable
<lifeless> jtv: you may not know this , but pep8 mandates indent by 8 for function call continuation lines
<jtv> I didn't, no.
<jtv> So does that mean we're going to have a mess of inconsistent indentations now?
<lifeless> its under code layout 'When using a hanging indent the following
<lifeless>     considerations should be applied; there should be no arguments on the
<lifeless>     first line and further indentation should be used to clearly distinguish
<lifeless>     itself as a continuation line.'
<lifeless> jtv: uhm, I don't know what we should do in LP itself; these new trees are pure PEP8 though
<lifeless> jtv: so I wouldn't expect any inconsistency within a single project
<jtv> Phew.  :)
<wgrant> lifeless: You mean function definition?
<jtv> Although I must say the 8-char indent would help the broken-if-condition situation.
<jtv> wgrant: no, this is function call.
<lifeless> wgrant: it applies to both
<wgrant>           # Further indentation required as indentation is not distinguishable
<lifeless> wgrant: function calls are listed as optional
<wgrant>           def long_function_name(
<wgrant> \    Optional:
<wgrant>               var_one, var_two, var_three,
<wgrant>               var_four):
<wgrant>               print(var_one)
<wgrant>           # Extra indentation is not necessary.
<wgrant>           foo = long_function_name(
<wgrant>             var_one, var_two,
<wgrant>             var_three, var_four)
<wgrant> I'mnot seeing the mandated indentation by 8 for function calls.
<wgrant> Only function definitions.
<lifeless> wgrant: its a contextual rule, not specific to function definition or calling
<jtv> wgrant: just so you know, this isn't working very well in my IRC client.
<wgrant>  and further indentation should be used to clearly distinguish
<wgrant>     itself as a continuation line.
<nigelb> please use etherpad?
<wgrant> For a function call it is already clearly distinguished.
<lifeless> wgrant: yes, thats what I quoted above:)
<wgrant> There's no following block.
<lifeless> wgrant: not always (e.g. call within an if)
<wgrant> Huh?
<wgrant> Oh, within an if statement, not an if block?
<lifeless> correct
<lifeless> jtv: the del exc_info is there to avoid circular references
<lifeless> jtv: its advised by the wsgi pep
<jtv> I thought the python gc had some special trick for dealing with circular references.
* henninge changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: henninge | Critical bugs: 238 - 0:[#######=]:256
<lifeless> jtv: it puts its hand up in the air, runs around and gibbers.
<jtv> Oh, OK.  That makes sense.
<lifeless> jtv: some of the time this works, other times it leaves uncollectable objects.
<wgrant> lifeless: I still see nothing that suggests two levels of indentation for normal function calls.
<lifeless> s/objects/cycles.
<jtv> lifeless: don't forget the closing /
<lifeless> jtv: a cycle of objects is uncollectable (today) if any have __del__
<jtv> To avoid the horrors of object revival through finalization?
<lifeless> jtv: so avoiding cycles is pretty important for library code.
 * jtv loves constructors, hates finalizers
<lifeless> jtv: to avoid race conditions or injecting altered state into the objects
<lifeless> e.g. A -> B -> A, and A has a __del__
<lifeless> if you delete B first, A's __del__ might use B and boom. if you delete A first, its ok.
<lifeless> I don't recall if the gc handles one __del__ ok, or only fails when there are two involved.
<jtv> Or as I put it, the horrors of object revival through finalization.  :)
<lifeless> IIRC it just taints the cycle when it finds a __del__ and moves on.
<lifeless> one common trick, while we're on this, is to have A -> B, C  then B->A and C has the __del__
<lifeless> it handles that just fine
<jtv> EPARSE
<jtv> AâB, C?
<lifeless> A holds a reference to B and C
<lifeless> B holds a reference to A
<jtv> Ah.
<lifeless> 'points at' :)
<jtv> Not what I meant.
<jtv> "A â B, C then BâA and C has the __del__" is ambiguously scoped.
<lifeless> jtv: how would you layout the dict better? even out of the assert those lines are just too long
<lifeless> they are already only 4 characters in
<jtv> One item per line, with comma after each item.
<jtv> AHHHH
<jtv> Ignore me.  I think I just figured out why I couldn't get something to work.
<lifeless> jtv: so the problem bit isn't in the dict, its the expected start_response args
<jtv> lifeless: could beâa bit hard to say given the current layout.
<lifeless> jtv: how does this grab you
<lifeless> http://paste.ubuntu.com/672245/
<adeuring> good morning
<jtv> lifeless: Gently and not altogether unpleasantly.
<jtv> Even so, I may sue.
<lifeless> is that +1?
<jtv> hi adeuring.  I bet you're wondering what all that was about, but you missed it and now it's too late.
<jtv> lifeless: yes
<adeuring> ?
<jtv> :-P
<lifeless> hmm
<lifeless> lxc-stop -n lucid-test-lp is dropping my box of the network for 60 seconds
<lifeless> this is not coincidentally the default bridge watchdog timeout
<lifeless> no liky
<lifeless> stub:  all the bits you need are in trunk
<stub> ta
<lifeless> stub: I suspect loggerheads is further broken based on lp's qastaging behaviour
<lifeless> stub: ... so please try before I sleep :)
<mthaddon> lifeless: sorry, I'm stealing stub at the moment for some emergency U1 work
<stub> Got u1 replication, then I need to guilt mthaddon into doing the pgbouncer LP config updates
<mthaddon> heh
<henninge> hm, was the StyleGuide overview page removed from the dev wiki on purpose?
<henninge> https://dev.launchpad.net/StyleGuides
<henninge> It's still linked from here https://dev.launchpad.net/PatchSubmission
<lifeless> jml: ping
<jtv> hi henninge!  Review?  https://code.launchpad.net/~jtv/launchpad/post-824553/+merge/72389
<henninge> jtv: r=me
<jtv> thanks
<henninge> although I had to look up the exact meaning of "vestigial" ... ;-)
<jtv> rvba: it prints None.
<jtv> henninge: good, so we're all learning.  :)
<rvba> jtv: arg ... thank you!
<jtv> rvba: want me to make any changes?
<mrevell> Hello
<rvba> jtv: I'll change it a bit and ask you to run it again if you don't mind, thanks for the offer :)
<jtv> OK
<jtv> hi mrevell
<rvba> jtv: http://paste.ubuntu.com/672274/
<jtv> coming
<jtv> rvba: pretty-printed for your convenienceâ¦ http://paste.ubuntu.com/672278/
<rvba> jtv: thank you!
<jtv> rvba: by the way, the default argument for dict.get defaults to None.
<jtv> So {}.get('x') == None.
<rvba> jtv: ah, right :)
<rvba> Thanks
<jtv> rvba: I still have the shell open so if there's anything more you need from that variable, say the word.
<rvba> jtv: great, I'll ask you if I need another execution on "real" data.
<jml> lifeless: hi
<jml> lifeless: got a call w/ rickspencer3 scheduled now. let me juggle a bit
<lifeless> jml: FYI its now 2030
<lifeless> jml: we're about to eat
<jml> lifeless: oh, ok. then go eat.
<lifeless> jml: in about 15 I'll be available
<jml> lifeless: ok, thanks.
<stub> AttributeError: https://api.launchpad.net/1.0/~nigelbabu/launchpad/4595-upgrade-bug-linking object has no attribute 'queue_status'
<stub> Anyone else having issues with ec2 land?
<StevenK> That's a branch
<StevenK> Not an MP
<stub> ahh
<nigelb> er, do I need to do anything? :)
<StevenK> nigelb: Yes. Tell stub he is a numpty :-P
<stub> A better reviewer?
<StevenK> Haha
<StevenK> stub: It used to say "Entry" object has no attribute, which was ... handy
<nigelb> heh
<stub> raise PEBKAC("You suck")
<stub> Thats better - back to the usual 3rd world ISP issues
<nigelb> My first non-trival branch to LP! :)
<nigelb> Meaning of course my code diff is comparable to the size of the tests diff.
<lifeless> jml: ok
<jml> lifeless: hi
<jml> lifeless: skype?
<lifeless> sounds good
<lifeless> jml: except
<lifeless> jml: its evening here and my isp is fail
<lifeless> jml: can you ring my landline ?
<jml> lifeless: oh. sure.
<lifeless> e..g skypeout to that
<jml> yeah, I have skypeout.
<stub> nigelb: Have you done all the contributer's agreement stuff?
<nigelb> stub: Yeah. Its my 6th branch :)
<stub> Cool.
<jml> lifeless: I dialled the number in the directory. Got a beep, then no sound.
<jtv> jelmer: are you up to date on Q/A?  The production report seems a little behind the times but it looks like you're set to be the next blocker after bac gets his Q/A done.
<jelmer> jtv: I checked up on it yesterday, but it appears that tellarium is down at the moment and that blocks my QA.
<jtv> Ah.  Sometimes I wonder if IS sprints are organized just to remind us to appreciate our admins.  :)
<jelmer> (-:
<jamesh> lifeless: sorry for the late feedback, but I did find one obvious problem with python-oops-wsgi: https://bugs.launchpad.net/python-oops-wsgi/+bug/830931
<_mup_> Bug #830931: python-oops-wsgi's proxy start_response callback does not handle a third argument. <python-oops-wsgi:New> < https://launchpad.net/bugs/830931 >
<wgrant> jamesh: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops-wsgi/trunk/revision/9 might be relevant.
<jamesh> ah.  probably should have checked that before filing the bug report
<wgrant> It's only a couple of hours old :)
<danilos> bigjools, hi, can you perhaps lend a hand with triaging bug 829253?
<_mup_> Bug #829253: issues with virtualized buillds? <soyuz-build> <Launchpad itself:New> < https://launchpad.net/bugs/829253 >
<bigjools> danilos: it's not a launchpad issue, it's either an RT or a buildd problem
<StevenK> Or a Xen bug
<bigjools> indeed
<wgrant> Or a package bug.
<bigjools> I'd retarget to buildd and raise an RT
<danilos> bigjools, ok, I'll do that, but what should I put in the RT?
<bigjools> danilos: link to the sme build pages as in the bug
<bigjools> same*
<bigjools> and ask if it's a buildd problem
<nigelb> mrevell: hi!
<mrevell> Hey there nigelb :)
<nigelb> mrevell: Morning! Were you able to look into that bug? :)
<mrevell> nigelb, Not yet but it is on my list for today. As Gary said last week, it's likely we'll want to do some testing on it.
<nigelb> mrevell: Yeah, that sounds good.
<mrevell> nigelb, At first it sounds pretty obvious that we need a "Subscribe me" button but, as Gary said, there are a few things to consider. I'll update the bug report and ping you when I've done something about it :)
<danilos> bigjools, another one for you: in bug 798611 cjwatson asks if we could run the sync more frequently? (if you think we could, I'll file an RT or simply propose a merge against launchpad-production-configs)
<_mup_> Bug #798611: Package Auto Sync seems to get ahead of +localdiff calculation <derivation> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/798611 >
<bigjools> danilos: leave it with me
<danilos> bigjools, ack
<danilos> thanks
<nigelb> mrevell: sounds good :)
<allenap> those possessing Zope knowledge: Do you know if there's a standard way to test security proxies? I've done it by hand in some recent code (see https://code.launchpad.net/~allenap/launchpad/job-status-validator/+merge/62509, line 532) but it's the kind of thing for which I suspect someone else has already come up with a good solution.
<bigjools> StevenK, wgrant: can you think of how we could possibly close LP bugs when syncing?  The current code requires a changes file.
<bigjools> which ain't gonna fly for syncs
<nigelb> gah @ qastaging timeouts
<wgrant> bigjools: We'll have to parse them from the changelog-since-base manually.
<bigjools> they are mentioned there?
<bigjools> as in, Debian changlogs reference LP bugs?
<wgrant> bigjools: Occasionally, yes. Most Ubuntu developers, and some Debian-only developers, put LP bug references in Debian uploads when they fix LP bugs.
<wgrant> So they can sync through and the bugs sort themselves out.
<bigjools> ok ta
<rvba> henninge: Hi, could you have a look at these 2 (tiny) MPs?
<rvba> https://code.launchpad.net/~rvb/launchpad/ids-fix/+merge/72398
<rvba> https://code.launchpad.net/~rvb/launchpad/queue-bug-830983/+merge/72406
<henninge> rvba: Hi! Having a look ...
<rvba> ta
<henninge> rvba: IDS = "Intrusion Detection System" ?
<rvba> henninge: InitializeDistroSeries ;)
<henninge> ;-)
<henninge> First line of diff reveals it but it confuses in the cover letter ...
<henninge> rvba: why did you move those methods in test_initialize_distroseries.py?
<rvba> henninge: To put them in InitializationHelperTestCase which is the base class for the new tests in test_initderiveddistroseries.py.
<rvba> henninge: And of course because the new tests use them.
<henninge> rvba: ok
<rvba> henninge: BTW, these branch depend on one another for no other reason than the fact that these are tiny fixes that I want to land in one go.
<rvba> branches*
<henninge> rvba: why did you add the "return true"
<henninge> ?
<henninge> rvba: did you just do it so you can use "assertTrue"?
<rvba> henninge: Exactly.
<henninge> rvba: no need for that
<rvba> For the test to be more "explicit".
<rvba> More "readable".
<henninge> rvba: but it is not, it is more confusing ;-)
<bigjools> better to assert the behaviour
<rvba> henninge: The behavior is that no exception is raised.
<henninge> I understand that
<henninge> but your test does not mention that.
<rvba> I could assert that it returns None.
<henninge> it never returns "False" so there is no point in "assert True"
<henninge> but that is not what you are testing ...
<rvba> henninge: makes sense, so you would recommend changing that to assert that None is returned then.
<rvba> ?
<henninge> rvba: it is perfectly fine to just call  the method under test and add a comment like "This should not raise an exception"
<henninge> rvba: no, assert nothing
<henninge> (and remove the "return true")
<rvba> Okay.
<henninge> then everybody knows you are just running it to see if it won't raise an exception.
<henninge> rvba: that's why we have "assertRaises" but we don't have "assertRaisesNot" ... ;-)
<henninge> rvba: Same issue with the other branch.
<rvba> henninge: Yep, I'm fixing this right now.
<henninge> rvba: cool, thanks ;-)
<henninge> r=me with those fixes.
<rvba> henninge: thanks a lot!
<bigjools> henninge, rvba: if something isn't raising an exception then presumably something else happened which can be tested?
<henninge> bigjools: that is a good point!
<rvba> bigjools: this is IDS.check() so completing without raising an exception is what I want to test.
<bigjools> rvba: that's not a good test though
<StevenK> I think .check() returns None if everything was fine
<rvba> StevenK: exactly
<StevenK> So assert that it did so, and you're good
<bigjools> I could make a function return "wibble" and check for that.
<bigjools> doesn't test much :)
<henninge> No, I think a funtion should be clear about it's interface.
<henninge> it either communicates by raising exceptions or by returning values.
<StevenK> IDS.check() returns None if everything is good, or it raises an exception with the problem. What's the issue?
<rvba> IÂ agree with StevenK's question :)
<henninge> if it communicates by raising exceptions, not raising one is a valid test according to the functions interface.
<henninge> StevenK: because it changes nothing and does not improve the test.
<henninge> the function will either raise an excpetion OR return None
<henninge> but the None is useless
<bigjools> if it returns None when everything is ok then the test needs to make sure everything is actually ok
<bigjools> otherwise how do you know returning None was correct?
<henninge> bigjools: I agree that the test could check for data that was changed by a function after it completed without an exception
<rvba> bigjools: I see this the other way around: I setup data to test for a specific case, then I test that ids.check() does not raise an exception for this case.
<henninge> only that a validation function should be definition not modify data ...
<bigjools> rvba: I think that is a poor test
<henninge> bigjools: it is no different to testing that a constant value is returned.
<henninge> that is equally poor and misleading
<rvba> and of course I have other tests to make sure the proper exceptions are raised when it's appropriate.
<henninge> because reading the test you think the None (or True in rvba's case) has some meaning which it does not have.
<bigjools> if there are other tests to make sure that certain inputs DTRT then that excuses this test, I was just taking the test in isolation
<henninge> rvba: exactly, I expected those to be there.
<rvba> henninge: bigjools these tests *are* already in the same file.
 * rvba is ready to pull the "ec2 land" trigger on this.
<henninge> rvba: I expected that, otherwise some previous reviewer did a poor job ;-)
<henninge> rvba: go ahead, this reviewer approves ;-)
<henninge> and goes to lunch
<jtv1> Anyone here familiar with recipe builds?
<jtv1> I pushed a change to meta-lp-deps and got some emails along the lines of "[recipe build #73739] of ~launchpad meta-lp-deps-on-demand in lucid:	Chroot problem"
<_mup_> Bug #73739: unstoppable (probably) gnome-panel looping crash <gnome-panel (Ubuntu):Invalid by desktop-bugs> < https://launchpad.net/bugs/73739 >
<jtv1> Shut up mup.
<StevenK> Chroot problem is not a recipe problem
<jtv> No, but I need to know what this implies.  Did something break fatally?  Do I need to push it again?
<StevenK> No and no
<jtv> Thanks.
<StevenK> Something is broken, but you didn't break it
<StevenK> Link me the URL in the body of the mail?
 * jtv digs
<jtv> Here's one: https://launchpadlibrarian.net/77594282/buildlog.txt.gz
<jtv> And: https://launchpad.net/~launchpad/+archive/ppa/+build/2721413/+files/buildlog_ubuntu-natty-i386.launchpad-dependencies_0.98%7Enatty1_CHROOTWAIT.txt.gz
<jtv> And: https://launchpad.net/~launchpad/+archive/ppa/+build/2721414/+files/buildlog_ubuntu-oneiric-i386.launchpad-dependencies_0.98%7Eoneiric1_CHROOTWAIT.txt.gz
<StevenK> Certainly not your probnlem
<jtv> There's also links in the sigs.  Need those?
<StevenK> No, I have enough
<jtv> OK
<StevenK> jtv: When did you push, around now-ish?
* benji changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: henninge, benji | Critical bugs: 238 - 0:[#######=]:256
<bigjools> StevenK: when does the debian publisher run, exactly?  And do you know typically how long it takes to complete?
<StevenK> bigjools: I have no idea.
<bigjools> StevenK: ok :)  Do you know where I can find out?
<StevenK> bigjools: Mail/bug Ganneff?
<jtv> StevenK: Friday IIRC
<soren> bigjools: https://answers.launchpad.net/launchpad/+question/161595
<soren> bigjools: the last line is (if I'm reading it correctly) from Debian.
<soren> bigjools: No idea how long it takes, though.
<StevenK> So, based on that question, we give Debian 2 hours to run dinstall *and* for ftp.uk.debian.org to pulse and update. I don't think that's long enough.
<bigjools> soren: thanks
<bigjools> in fact 2h13m
<StevenK> And in fact, there is another missing piece
<bigjools> yes, our own rsync
<StevenK> When does debmirror on iron run, since *that* is what gina pulls from
<StevenK> jtv: Right. I think that mess has been sorted out.
<jtv> Good, thanks.
<bigjools> StevenK: 52 2,8,14,20
<StevenK> Let me see if I can resurrect stuff
<bigjools> so we give debian 1hr to publish and sync
<StevenK> And sync from ftp.debian.org to ftp.uk.debian.org
<StevenK> I don't think that's long enough
<bigjools> StevenK: how do you know we get it from the uk mirror?
<wgrant> ftp.uk.debian.org shouldn't sync from ftp.debian.org
<wgrant> It'll sync direct from ftp-master.
<StevenK> wgrant: Right
<StevenK> bigjools: Since I had to help fix debmirror, and I *think* it pulls from ftp.uk.debian.org. A LOSA could confirm.
<bigjools> StevenK: ok ta
<jkakar> I've been doing some reviews in GH with pull requests... at first glance the thing where you add comments to a diff seems nice, but in practice I miss the simple textarea from Launchpad where I can copy and paste code and review my review before I send it.
<jkakar> With GH the line items to add to a diff are visible, in realtime, to everyone else.
<jkakar> Sometimes fancy isn't better.
<soren> jkakar: I've never really used it, but it also seems to be that if the patch is revised based on the feedback, how will you be able to tell a) which line a comment pertains to now (since the line number and/or content might have changed) and b) whether it's still relevant.
<soren> jkakar: I tend to prefer LP's e-mail interface for code reviews, though.
<jkakar> soren: No idea.  I'm finding GitHub generally confusing so far and I miss a number of things from Launchpad.
<jkakar> For example, there's on way to specify a prerequisite branch when you create a pull request... and it isn't smart enough to figure it out for itself.
<wgrant> jkakar: Oh, I always assumed GitHub line-based comments were still done in sort of a single transaction, like Launchpad's.
<jkakar> wgrant: No, they're not.  They're realtime... people can respond to your comments while you're reviewing.
<nigelb> bah, test failure
<jkakar> Which seems a bit useless really.  When a review is so important that you need that kind of response just phone someone and do it in person, or do it on IRC or something.
<jkakar> Pull requests also have no state beyond open and closed.  I miss 'Needs Fixing' and 'Needs Information'.  I also miss the +activereviews page where you can see pull requests you can do, that need your attention, etc.
<jkakar> GH does have a much more polished UI than Launchpad.  And being able to follow people is pretty cool.
<jkakar> The biggest reasons we've switched to GH are (a) price (b) builtin wikis and (c) perceived easier UI.
<jkakar> Probably in a, c, b order.
<soren> GH looks much more like an OS X app than Launchpad, yeah.
<jkakar> soren: Yeah.  It also has some wicked features, like builtin webhooks and builtin services like commit bots.
<jkakar> But the things I use on a daily basis leave me feeling a bit underwhelmed after Launchpad (bugs + merge proposals).
<nigelb> jkakar: I always like launchpad for its +activereviews page and overall better review panel.
<jkakar> Maybe it'll just time to get used to it.
<soren> jkakar: But as you point out, pull requests and issues lack of lot of metadata.
<jkakar> nigelb: Yeah, me too.
<nigelb> I constantly use both.
<StevenK> I seem to be allergic to git. Every time I try and use it, I break out into bouts of vicious swearing.
<nigelb> There's creams for that sort of thing now :P
<nigelb> Achivement Unlocked: Broke a bucketload of tests on landing.
<jkakar> StevenK: The sense that I have to punch someone in the face everytime I use it is dwindling with experience.
<jkakar> StevenK: I don't find it any faster or slower than Bazaar, which is interesting since speed is the thing everyone goes on and on about.
<jkakar> As far as I can tell they're the same: local operations are fast and network operations are slow.
<wgrant> Two years ago bzr was really slow.
<wgrant> And nobody has used it since then.
<nigelb> I *think* most of what that git can do can be accomplished with bzr.
<nigelb> But some are not out of the box.
<nigelb> are co-located branches out of the box yet?
<wgrant> Very nearly.
<wgrant> jelmer has been working on that, I believe.
<wgrant> But bzr-colo does a pretty damn good job.
<nigelb> I agree. So, the last time I checked that was my only irk, except I learn that's around in bzr too.
<wgrant> I find colocated branches to be a downside at times.
<jelmer> yeah, colocated branches are slowly making their way into core bzr
<Daviey> I've noticed bzr bisect doesn't seem as reliable as git bisect, but that is meerly a module.
<nigelb> Launchpad UI though could use some work :)
<Daviey> merely*
<nigelb> I heard there was a whole bunch of work coming that way too.
<jkakar> I was initially quite frustrated with colocated branches (in Git) after being used to Bazaar.  I'm getting used to it.
<nigelb> when you work with the github workflow more, its fun
<nigelb> you start doing the branching with git checkout -b, etc
<jkakar> nigelb: I'm not having more fun yet.  Maybe that'll change.
<jkakar> I guess so much of this is just about familiarity.
<nigelb> jkakar: hehe, so some irritating bits in git include, things like "git st", "git co" not working. Create alias instead
<nigelb> I got used to bzr st
<jkakar> nigelb: I don't mind those things so much.  I can alias or adapt.
<nigelb> some things in git is pretty rad.
<jkakar> nigelb: But things like git remote are confusing.  I don't care (or want) the staging area.  I know about commit -a, but I just don't want to even care about it.
<nigelb> heh
<nigelb> I agree, coming from bzr, that's a bit confusing.
<nigelb> I somehow would like to have that in bzr
<nigelb> (please don't stab me :P)
<jkakar> Heh :)
<jkakar> I don't stab.
<jkakar> I cut.
<nigelb> hehe
<nigelb> jkakar: do you use zsh? There's some neat plugins to show to you which branch you're in.
<nigelb> Many times I've commited to the wrong branch.
<jkakar> nigelb: No, I use bash.
<jkakar> nigelb: You probably wouldn't commit to the wrong branch with a directory-per-branch. ;b
<nigelb> ah, so there's something I wrote which shows you which branch you're in
<nigelb> hah
<nigelb> I like the colocated feature
<jkakar> Anyway, it's interesting to be a longtime Launchpad/Bazaar user trying tools from "the other side".
<nigelb> It happens to me every so often that I type bzr commit in a git repo or vice versa
<jkakar> I've heard a lot of GH/Git users complaining about Launchpad being hard to use... so far, I miss LP, but as I said, perhaps it's just familiarity.
<jkakar> nigelb: Yeah, I do that a lot too. :)
<nigelb> heh :)
<nigelb> jkakar: Did you move from Canonical or does Canonical have stuff in GH now?
<jkakar> nigelb: I left Canonical in March.  I'm at Fluidinfo now.  We've just moved from Launchpad to GitHub this week.
<nigelb> jkakar: Ah. Yeah, github has a pretty healthy eco-system :)
<jkakar> nigelb: Canonical putting stuff in GH would be a pretty bad sign. :)
<nigelb> hehe
<nigelb> GAH! I broke tests all over the place including soyuz.
<jkakar> :)
<StevenK> nigelb: Welcome to Launchpad
<nigelb> StevenK: haha
<wgrant> Don't let Soyuz consume your soul.
<nigelb> ok, I need some help with the soyuz tests because I'm not sure if parts of is my breakage
<nigelb> http://dpaste.com/600458/
<nigelb> I don't understand the first bit
<nigelb> lines 6 to 9
<StevenK> Ah yes, doctests are fun
<nigelb> and lines 21 to 25
<StevenK> nigelb: Right, so 6-9 are red herrings
<wgrant> nigelb: Look at the ++++++++ bits.
<wgrant> Those are yours.
<StevenK> The meat is 14 and 17
<nigelb> I got those
<nigelb> I fixed too.
<StevenK> nigelb: "..." means some text
<StevenK> And doctest errors suck
<bigjools> doctests show all diffs even if you didn't change it
<bigjools> IYSWIM
<wgrant> Right, only the expected text is elided.
<StevenK> Oh God, it's xx-sourcepackage-changelog.txt
<StevenK> Kill it, it's moving!
<nigelb> the 20 to 21 is weird, cos it shows lines added
<wgrant> The actual text is shown in full, which makes the diffs rather difficult to interpret.
<nigelb> StevenK: haha
<bigjools> nigelb: fix 14/17 and you're done
<nigelb> phew, okay
<wgrant> nigelb: 21-24 are normally captured by the '...' on 20.
<nigelb> aaah.
<StevenK> Which is what is also going on with lines 6-9
 * nigelb moves on to next set of tests
<bigjools> doctests with more than a couple of lines out output  to match are a nightmare
<nigelb> So much breakage.
<bigjools> s/out/of/
<nigelb> should I have run throw the entire tests before my MP?
<nigelb> or is this sort of breakage common?
<bigjools> nigelb: BTW have you see utilities/paste?
<StevenK> nigelb: Did you get a mail from ec2 with a subunit stream?
<nigelb> StevenK: yes, I'm fixing breakage from that.
<nigelb> bigjools: no, does it pastebin whatever I want it to paste?
<bigjools> nigelb: yes, takes stdin
<nigelb> (in thise case, its from my mail, so entirely useful)
<StevenK> nigelb: testr init ; zcat <subunit> | testr load ; testr run --failing
<bigjools> so bzr diff|utilities/paste is v useful :)
<StevenK> testr failing --list # if you want to see how many tests you broke
<wgrant> bigjools: --syntax=diff!
<nigelb> that's for doctests?
<StevenK> nigelb: No, that's in general for failures from ec2
<nigelb> but shouldn't I need some sort of access to see that?
<StevenK> nigelb: As in, "Aiee, I broke 100 tests, how can I be sure if I fixed them all"
<wgrant> nigelb: To see what?
<nigelb> StevenK: ah.
<nigelb> wgrant: to see the out put of what StevenK said :)
<wgrant> nigelb: It's in the email.
<bigjools> wgrant: I'm sure it could use file magic to do that
<wgrant> bigjools: Probably.
<nigelb> StevenK: subunit = bugs/soyuz etc?
<StevenK> nigelb: Sorry, the subunit stream is the gzipped file that was attached to the mail from ec2
<bigjools> nigelb: watching the cricket?
<nigelb> StevenK: AH!
<nigelb> bigjools: No, I gave up :P
<bigjools> nigelb: :D
<StevenK> nigelb: So you can zcat it into testr load and then testr can tell you exactly which tests failed without you having to read 500,000 lines of librarian log
<wgrant> StevenK: I think that bug is fixed now, actually.
<StevenK> bigjools: Oh, so England has discovered that they can actually hit the ball properly if they hold the padded bit of the bat?
<wgrant> Saw something fly past a day or two ago.
<bigjools> StevenK: #1 test team.  Suckit.
<StevenK> [r=bac][bug=828151][no-qa] Truncate the librarian log before each test run.
<StevenK> bigjools: That would require caring about cricket. Which I don't.
<bigjools> StevenK: ah so you just care about trolling about it? :)
<StevenK> OH, ALLENAP. Come here, so I can have your babies.
<StevenK> bigjools: Exactly!
<bigjools> what did allenap do?
<bigjools> to deserve your generous offer
<allenap> StevenK: I always hoped to get an invitation like that from an attractive woman, but it's been a long time so I guess you'll have to do.
<StevenK> allenap: Haha
<nigelb> lol
<bigjools> not sure I'd be that desperate allenap
<nigelb> And here I thought StevenK was married :P
<StevenK> allenap: IOW, *thank you* for fixing the librarian log truncation.
<StevenK> nigelb: I am
<allenap> StevenK: No worries, it sounds like it bothered me as much as it did you.
<nigelb> StevenK: I know :)
<nigelb> StevenK: btw, testr is in LP? Or do I install it separately?
<nigelb> python-zope.testing?
<allenap> nigelb: Separate, python-testrepository.
<nigelb> thanks allenap :)
<abentley> bug 823850
<_mup_> Bug #823850: AssertionError raised upgrading a branch that doesn't need upgrade <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/823850 >
<nigelb> fuuu, looks england might win by an innings
<bigjools> nigelb: again
<StevenK> So India needs to hold the padded bit of the bat?
<nigelb> bigjools: The best quote about India's perfomance was "India is like a faithful husband. Only performs at home"
<nigelb> StevenK: Yeah :|
<nigelb> grar, no testr still.
<bigjools> ;0
<StevenK> % dpkg -S /usr/bin/testr
<StevenK> testrepository: /usr/bin/testr
<StevenK> nigelb: ^
<nigelb> I installed everything but that. WIN.
<StevenK> Haha
<nigelb> StevenK: when I do that, tests are supposed to pass?
<nigelb> or does it just show me the ones that failed in EC2
<StevenK> nigelb: When you did which?
<nigelb> testr init ; zcat ~/Downloads/4595-upgrade-bug-linking-r13582.subunit.gz | testr load; testr run --failing
<gary_poster> Thank you for the galapagos hint, StevenK
<StevenK> gary_poster: Welcome.
<StevenK> nigelb: The last command is what runs the failing tests
<StevenK> nigelb: If tests aren't failing, you've already fixed them? :-)
<nigelb> ok, so seeing everything fail is probably not a good thing.
<StevenK> nigelb: Well, it's probably the expected thing
<nigelb> wait, I know I fixed these.
<nigelb> does the fix have to be committed?
<StevenK> nigelb: You might be seeing testr load output
<StevenK> It spams everything to stdout
<nigelb> ah
<gary_poster> deryck, sw your reply.  perfect, thanks
<nigelb> failures 7
<nigelb> bah
<deryck> gary_poster: np! Thank you for putting the email notes together.
<gary_poster> welcome
<nigelb> I can run make test to be extra sure right? (worse case)
<StevenK> nigelb: make check, but yes
<StevenK> nigelb: It will take AGES
<nigelb> gah
<StevenK> nigelb: Or you can ask someone to resubmit it to ec2
<nigelb> the testr is showing me false positives.
<nigelb> fffffuuuu, brb, production server at work died.
<nigelb> ok. back.
<nigelb> let me look at the diff to see if I caught them all. If so I'm just going to ask someone to submit it again
<nigelb> ok, so can someone re-land https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
<jelmer> henninge, benji: can I add a MP to your queue?
<benji> jelmer: sure; I can do one now.
<jelmer> benji: thanks - it's at https://code.launchpad.net/~jelmer/launchpad/re-enable-test_import_bzrsvn/+merge/72411
<nigelb> benji: could you re-view and re-land my branch?
<benji> nigelb: sure, which one?
<nigelb> https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
<benji> jelmer: done
<jelmer> benji: merci !
<bac> hi jelmer, your branch for bug 826136 is now next on the QA hot seat.
<_mup_> Bug #826136: dictionary changed size during iteration <oops> <qa-needstesting> <loggerhead:Fix Committed by jelmer> < https://launchpad.net/bugs/826136 >
<jelmer> hi Brad
<bac> jelmer: just letting you know since i got my blocker done
* henninge changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 238 - 0:[#######=]:256
<jelmer> bac: Thanks
 * henninge is done reviewing
<jelmer> bac: I'm waiting for tellarium (storage space for code imports) to come back up, once that happens I'll be able to do the QA
<bac> jelmer: great
<benji> nigelb: I'm afraid that revision is essentially unreviewable, the diff is over thirteen thousand lines long.
<nigelb> benji: wait, what
<benji> do you have a diff of just the changes you made to fix the failures?
 * nigelb checks
<nigelb> benji: ah, I merged in devel as well.
<nigelb> The changes are more easily reviewed on the merge page
<nigelb> My initial code only touched 3 files
<benji> I'll do that.  It would have been nicer if I knew what had been changed to fix the test failures instead of having to re-review all the changes.
<benji> You could have accomplished that by merging from devel in one revision and making your changes in another.
<nigelb> benji: I should have. Noted for next time.
<benji> cool
<benji> nigelb: the branch looks good, I'm starting the landing process now
<nigelb> benji: thanks! Sorry again for the messed up diff.
<benji> no worries
<rvba> Thanks for the review benji.
<benji> my pleasure
<nigelb> bigjools: its all over :(
<bigjools> nigelb: a while ago :)
<nigelb> bigjools: I wasn't actually watching. my roommate has it on and I just realized I'm listening to the presentation ceremony
<henninge> good bye
<sinzui> jcsackett, do you have time to mumble?
<jcsackett> sinzui: i can mumble now.
<jcsackett> sinzui: are you still free?
<LPCIBot> Project devel build #982: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/devel/982/
<abentley> deryck: could you do a review for me?  The OCR is offline, and it should be pretty straightforward: https://code.launchpad.net/~abentley/launchpad/unnecessary-upgrade/+merge/72480
<LPCIBot> Project db-devel build #815: STILL FAILING in 6 hr 33 min: https://lpci.wedontsleep.org/job/db-devel/815/
<deryck> abentley: I can do it.
<abentley> deryck: thanks!
<deryck> abentley: I have to go pick up my daughter from school in 15 minutes, so if I'm not done by then, I'll finish when I return.
<abentley> deryck: that's cool.
<lifeless> morning
 * jelmer waves to lifeless
<gary_poster> hiya lifeless
<gary_poster> abentley, could you take a look at https://answers.launchpad.net/launchpad/+question/168602 and either give me some advice or take it yourself, as you see fit?
<abentley> gary_poster: looking
<gary_poster> thank you
<abentley> gary_poster: I doubt it's because a particular revision takes a long time.  I bet it's just because the whole branch takes a long time.
<gary_poster> abentley, that's certainly what the log looks like.  So should I toss it to Jelmer, or say "so sorry," or...?
<abentley> gary_poster: I think canonical staff may have done one-off imports like he's requesting in the past.
<gary_poster> ah
<gary_poster> ok abentley, I'll check with a losa if that is something they are familiar/comfortable with then
<abentley> gary_poster: Okay.
<abentley> gary_poster: comparing to "hg clone" isn't really the right comparison.  You'd want to compare to "bzr branch" with bzr-hg installed.
<gary_poster> ok abentley, I guess I could try that locally for the heck of it...
<deryck> abentley: looks good to me.  Sorry it took me so long.
<abentley> deryck: no worries.
<lifeless> gary_poster: jelmer_: hiya
<jelmer_> does anybody have an idea what this sort of thing might indicate:
<jelmer_> Fault: <Fault -1: 'Unexpected Zope exception: DisconnectionError: FATAL:  database "launchpad_ftest_9581" does not exist\n'>
<jelmer_> not enough layers?
<lifeless> that should be set up by your test process
<lifeless> whats it coming from ?
<jelmer_> a twisted callback
<jelmer_> hang on, I think I know what might be happening
<lifeless> sounds like you have a test helper running after the main test process is shutdown
<jelmer_> leftover launchpad processes; I suspect it was tlaking to one of them
<jelmer_> killing them seems to fix the problem
<jelmer_> lifeless, yeah, indeed
<lifeless> flacoste: oh, I remembered one thing
<lifeless> flacoste: you're probably gone though ...
<flacoste> lifeless: no, i'm still here for an hour
<lifeless> flacoste: what do you think of us having a launchpad-sites or launchpad-deployments or something project - no code, but a place for bugs that are filed by community folk but really about how things have been deployed.
<flacoste> lifeless: you mean for things related to Launchpad deployment outside of launchpad.net?
<lifeless> flacoste: e.g. things like the help wiki needing moin upgrades would sit there
<flacoste> lifeless: we already have a project for the help wiki though
<flacoste> and dev
<lifeless> or python-openid upgrades on lp-oops, or new haproxy or apache versions being needed
<lifeless> things like needing a shared ssl session cache
<flacoste> we track those usually through RTs
<lifeless> right, *we do*, but if a community member files a ticket in any of these spaces
<flacoste> which is obviously not community accessible currently
<lifeless> we have nowhere to leave it as a placeholder
<lifeless> e.g. our moin projects are labelled 'themes'
<lifeless> which does involve code changes; I'm purely talking stuff with no code
<lifeless> anyhow, its a thought
<flacoste> lifeless: i'm not hot on the idea, but i wouldn't mind trying it out, we can assess if this pulls its weight after a while
<flacoste> which reminds me
<lifeless> I'll let it percolate
<flacoste> we should probably kill the lp-<old-team> tags
<flacoste> we said we would eventually
<flacoste> doesn't look like anybody misses the projects
<lifeless> :)
<lifeless> allenap: lol! love your review cover letter.
#launchpad-dev 2011-08-23
<LPCIBot> Project devel build #983: STILL FAILING in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/983/
<StevenK> !!!
<StevenK> Jenkins is back!
<LPCIBot> Project db-devel build #816: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/816/
<gary_poster> Hello everybody.  I believe trunk is still broken.  This fixes the last test (monkey-see monkey-do from what wgrant submitted for fixing the other tests) but I don't know if it is correct.  http://pastebin.ubuntu.com/672811/ Can anyone verify?  If so, I'll do another testfix.
<gary_poster> lifeless, wallyworld, are either of you around and able to verify correctness?
<gary_poster> FWIW, this runs the failing test:
<gary_poster> ./bin/test -cvvt lp.bugs.model.tests.test_bugtask.TestValidateTransitionToTarget.test_sourcepackage_to_sourcepackage_in_same_series_works
<wallyworld> gary_poster: i'll have a look
<gary_poster> thank you wallyworld
<wallyworld> np
<wallyworld> gary_poster:  i think wgrant submitted a test fix - are you saying it's still broken?
<wallyworld> or is this a different issue?
<gary_poster> yes wallyworld.  He missed one test.  I copied his fix pattern to the remaining one.
<wallyworld> ah, right
<wallyworld> perhaps we should nuke bb
<StevenK> No LOSAs
<wallyworld> still?
<StevenK> Not in this timezone
<gary_poster> s'alright.  If I land a testfix it will immediately run the next test, with only an email compaint.
<gary_poster> I mean, immediately after the current one fails
<gary_poster> so there shouldn't actually be any outage for you guys
<wallyworld> ok, thanks!
<wallyworld> the pastebin looks ok to my untrained eye. running the test to verify
<gary_poster> wallyworld, I'll treat this effectively as an r= and then self-approve :-)
<gary_poster> (once you run the test
<gary_poster> )
<wallyworld> ok, doing it now
<gary_poster> wallyworld, I still intend to take you up on more of the PyCharm hints (like the bzr plugin).  Things have felt a bit up-in-the-air lately so I haven't attempted the full PyCharm switch yet
<gary_poster> StevenK, btw, know that I would have begged for your assistance by name too had I remembered that you were around. ;-)
<wallyworld> gary_poster: whenever on pycharm. bigjools likes it :-)
<wallyworld> gary_poster: the test passes :-)
<gary_poster> cool wallyworld :-)
<wallyworld> thanks for fixing
<gary_poster> test passing: great thanks wallyworld, and I'm taking that also as affirmation that, to your best guess, you think it is not making the test pass...by asserting broken functionality or something.  :-) OK, off to submit...
<StevenK> gary_poster: Haha
<gary_poster> :-)
<StevenK> And here I was thinking that I was loud and annoying enough to not be forgotten.
<wallyworld> gary_poster: well, don't take me as someone who knows about this bit of the product :-) so my best guess is not necessarily all that good
<wallyworld> but the fix seems like it's in line with the observed failure
<nigelb> FUUUUUUUUUU More test failures.
<gary_poster> wallyworld, yeah.  Fair enough.  Here's hoping, then.  Right, and it looks like what wgrant did.
<nigelb> I can't figure out what I broke
<wallyworld> nigelb: what's up?
<nigelb> wallyworld: two attempts at landing that branch and I have test failures
<gary_poster> nigelb, trunk is broken fwiw, and was broken worse before.  If the errors look like "IllegalTarget: Package unique-from-factory-py-line3362-24070 not published in Distribution-24050" then wait a sec and then pull from trunk once I have the last fix in.
<wallyworld> nigelb: some test failures occurred due recently due to some broken code elsewhere. perhpas you are seeing that issue
<wallyworld> do you want to pastebin the failures?
<nigelb> gary_poster: Indeeed it does!
<StevenK> nigelb: It happens like that sometimes, sadly.
<gary_poster> nigelb, well, good news, for some definition of good news. ;-)  I'll ping you when it's in.  Should be <5 min.
<nigelb> \o/
<nigelb> gary_poster: Thanks :)
<StevenK> nigelb: Did you want your branch tossed at ec2 for the 3rd time?
<nigelb> StevenK: sec, there's one failure that's fallout from me.
<nigelb> let me fix that
<nigelb> doctests *stab* *stab* *stab*
<wallyworld> StevenK: if it's just the distro packaging failures we could lp-land it?
<gary_poster> wgrant, any objections to http://pastebin.ubuntu.com/672811/ ?  About to land it?
<StevenK> gary_poster: Only if you format sp2 correctly
<StevenK> sp2 = self.factory.makeSourcePackage(
<gary_poster> StevenK, bah, that's PEP8 compliant last time I checked :-P
<StevenK>     distroseries=sp1.distroseries, publish=True)
<gary_poster> If lint complains I'll do it...waiting...
<wgrant> gary_poster: Huh, that mustn't have come up in the summary...
<wgrant> Let me check.
<gary_poster> StevenK, linter likes my code more than you do ;-)
<gary_poster> Thanks wgrant
<StevenK> gary_poster: Bah! :-)
<wgrant> gary_poster: Argh, no, I just misread. thought it was part of TestValidateTarget.
<gary_poster> wgrant, ok cool, so I'm assuming you approve of what I did.  I'm about to lp-land
<wgrant> gary_poster: That diff looks fine.
<wgrant> Thanks.
<gary_poster> thank you
<gary_poster> nigelp, merge trunk and all those other ones should go away.  good luck.
<gary_poster> nigelb, even :-P
<nigelb> hehe, okay
<wgrant> wallyworld: 274	+        var filter_msg = Y.substitute(
<wgrant> 275	+            'Showing <strong>{filter}</strong> matches for "{search_terms}".',
<wgrant> 276	+            {filter: current_filter_value,
<wgrant> 277	+            search_terms: this._search_input.get('value')});
<wallyworld> yeees?
<wgrant> wallyworld: It's not exploitable, as it's only displaying immediate user input, but it is wrong.
<wallyworld> security issue?
<wgrant> It would be, if search_terms didn't happen to come from a textbox.
<wallyworld> so the problem is?
<wgrant> Search terms involving HTML will break the world.
<wgrant> And it's using a forbidden pattern which people will follow.
<wallyworld> well if anyone types in html they deserve it to break
<wallyworld> i just cargo culted the pattern myself
<wgrant> Right.
<wgrant> Let's not perpetuate this.
<wallyworld> i dont' see this instance as a huge issue in this case
<wallyworld> but yes, as a drive-by....
<wgrant> In the current form it is barely exploitable, true.
<wgrant> But it is a terrible pattern, and could very easily accidentally become exploitable.
<wallyworld> sure, so next time someone is in the neighbourhood.....
<wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/fix-codebrowse-oopses/+merge/72515
<StevenK> wgrant: r=me
<nigelb> StevenK: could you land https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575 again? :)
<wgrant> StevenK: I want to wait for lifeless, as this was obvious enough from the logs that I think I might be missing some other issue.
<nigelb> Third time's the charm I hope.
<cjwatson> if anyone types in html> such as web browser developers looking for bugs involving certain kinds of HTML, for example ...
<wgrant> cjwatson: Surely not!
<wgrant> Nobody would ever do that.
<wgrant> Web applications can break in bad ways in some cases.
<wgrant> All good.
* gary_poster changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256
<lifeless> wgrant: hi
<wgrant> lifeless: I tried loggerhead locally and got a pretty obvious traceback. Did that not appear on prod?
<wgrant> s/prod/qas/
<lifeless> qas just ISE'd on us
<lifeless> I prepped a monkey to get into pdb and see what is causing it -
<lifeless> ok pages are ok
<lifeless> but failing pages didn't seem to oops
<lifeless> its in the -ops history
<wgrant> http://paste.ubuntu.com/672845/
<lifeless> hahhhhhhahhahahaha bloody ha ha
<wgrant> Yes.
<wgrant> That stuff didn't make it into qastaging's debug.log?
<lifeless> no
<wgrant> Yay
<wgrant> Shall I land the fix, then?
<lifeless> hell yes
<lifeless> if thats s/oopsid/id/
<wgrant> It is.
<wgrant> It even works.
<wgrant> Sad that this isn't tested.
<lifeless> thank you & sinzui very much
<wgrant> But let's unbreak it first.
<wgrant> lifeless: Do I want a --rollback?
<wgrant> Since it's already been fixed once, right?
<wgrant> Let's see the report...
<wgrant> Ah, there was no --rollback last time.
<wgrant> I shall put it on this one.
<StevenK> lifeless: O hai
<StevenK> lifeless: Can you peer at http://pastebin.ubuntu.com/672806/ when you have a tick?
<lifeless> wgrant: the cascade thing had me suspicious
<lifeless> wgrant: I figured I could lp-land a no-op --rollback easier than unlanding one that didn't fix it
<StevenK> lifeless: I'd like the query to return every BPR that has unexpired BPFs and doesn't already exist in BPRC.
<lifeless> StevenK: what context is it running in?
<StevenK> lifeless: Garbo job
<lifeless> 18 seconds is tolerable to seed the job
<StevenK> lifeless: wgrant's concern was that the performance is like that and BPRC only has 1 million rows on DF -- it's only going to get worse
<lifeless> well
<lifeless> the binarypackagereleasecontents_pkey index will allow fairly efficient determination of bpr's
<lifeless> the merge join took most of the time
<lifeless> whats thesecond query ?
<lifeless> this is inefficient:  AND NOT EXISTS
<StevenK> It's the same query, cold and hot
<lifeless>     (SELECT BinaryPackageReleaseContents.binarypackagepath
<lifeless>      FROM BinaryPackageReleaseContents
<lifeless>      WHERE BinaryPackageReleaseContents.binarypackagerelease = BinaryPackageRelease.id)
<StevenK> lifeless: Are you fiddling for something more efficient?
<lifeless> yes
<nigelb> ah, its wgrant's review day.
<wgrant> So it is.
<nigelb> StevenK: did you get a chance to land that? Should I poke wgrant into landing?
<StevenK> 4595-upgrade-bug-linking => devel  [OK]     (up for 1:09:13.836563)
<lifeless> StevenK: Time: 5.961 ms
<lifeless> http://paste.ubuntu.com/672861/
<lifeless> StevenK: this takes advantage of the fact that we expect:
<lifeless>  - most rows to need analysis
<lifeless>  - and we're walking a batch upward
<lifeless> with analyze http://paste.ubuntu.com/672862/
<nigelb> StevenK: aha, thanks :)
<StevenK> lifeless: Why the first limit 1000?
 * nigelb heads for caffeine and breakfast
<lifeless> StevenK: thats large enough that we won't get lots of empty batches
<lifeless> StevenK: its a guess. It just needs to be large enough that we'll get 1 (one is enough) rows most of the time
<wgrant> lifeless: Won't an empty batch cause it to think it's done?
<lifeless> yes, the driver logic needs tweaking
<lifeless> it should say something like 'max id - last seen id < 1000'
<lifeless> and/or
<lifeless> always increments the last seen id by 20 if no results were found
<lifeless> when it exceeds the max id, we're done-done.
<lifeless> and can switch to a simpler plan using the highest ids and working back or whatever
<jamesh> lifeless: in case you're interested, I added a first-go patch to https://code.djangoproject.com/ticket/16674 that makes django work with python-oops-wsgi
<jtv> wgrant: have you had a chance to look at that buildbot failure?  With you, me, and the big J on the blamelist I guess it's not as easy as "oh it's packaging-related, I know who it is."  :)
<wgrant> jtv: It was my fault. It is fixed.
<jtv> Oh good, thanks.
<lifeless> jamesh: I am
<lifeless> jamesh: do we want a python-oops-django containing the django glue ?
<jamesh> lifeless: ideally I'd like it if no glue was necessary
<jamesh> hence the django bug report
<lifeless> yeah
<lifeless> me too
<lifeless> jamesh: thanks for digging into this!
<lifeless> I'm going to be hacking on more gpg extraction / gpgverifyd today
<lifeless> but should be back on oopses tomorrow
<lifeless> and probably on leave monday
<wgrant> lifeless: On Monday, or from Monday?
<jamesh> lifeless: you said that some other web frameworks had the same problem of hiding the exception context when producing an error page.  Perhaps the best solution would be to patch a few other popular ones and hope that python-oops-wsgi is compelling enough to convince others to patch the remaining ones
<nigelb> jamesh: that's interesting.
<nigelb> jamesh: I was just thinking the other day what it would take to use python-oops with django
<nigelb> (after all the excitement lifeless was making with python-oops :P)
<jamesh> nigelb: well, hopefully the patch in that bug (or a better version of the same) will make it into a future version of Django
<jamesh> then the answer is just "wrap Django's WSGIHandler() with python-oops-wsgi and embed in your favourite WSGI container"
<nigelb> :)
<StevenK> nigelb: In reference to your G+ post: <ESC>:shell
<nigelb> StevenK: I used byobu instead
<nigelb> with a vertical split
<StevenK> Cheater
<nigelb> heh
<nigelb> Its pretty nifty actually.
<nigelb> I like commiting often and a terminal right below the editor helps
<wgrant> Hmm.
<wgrant> https://bugs.launchpad.net/launchpad/+bug/411409
<_mup_> Bug #411409: AJAX "Link to a bug report" could be improved <confusing-ui> <disclosure> <javascript> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/411409 >
<wgrant> The attachment link there no longer works.
<wgrant> (I always used to insert odd characters into attachment names to break things... but I think this one used to work)
<wgrant> Interestingly it works locally.
<StevenK> The number is the LFA?
<StevenK> (In the URL, I mean)
<wgrant> BugAttachment.id
<nigelb> How much work is that bug?
<nigelb> Its tempting to pick up
<wgrant> http://launchpadlibrarian.net/30110664/what%3F.png works
<wgrant> nigelb: Pickers are not something you want to get into.
<wgrant> At least not yet.
<nigelb> Hmm, ok.
<StevenK> Yes, that picker sucks
<wgrant> That's not even a picker.
<wgrant> it should be.
<StevenK> Do we even have a picker that can search by bug number?
<wgrant> No.
<wgrant> We want one that can search by ID/summary/description.
<StevenK> True
<StevenK> Can haz FDT now
<StevenK> lifeless: So I need another number for {B,S}PPH indices -- is it another -1 and goes to db-devel?
<wgrant> StevenK: That can be done live.
<wgrant> Once the column is there.
<wgrant> Wait until then, I suspect.
<StevenK> Bleh
<StevenK> We probably need more than just CREATE INDEX binarypackagepublishinghistory__binarypackagename__idx ON BinaryPackagePublishingHistory(binarypackagename) anyway
<wgrant> Hah, yes.
<StevenK> (And the correspending SPPH, of course)
<StevenK> wgrant: Suggestions for what we want to index?
<wgrant> Depends what you want to make fast.
<StevenK> The DSP vocab
<wgrant> The current indexes are pretty arbitrary and useless.
<wgrant> StevenK: Do you have an example query?
<wgrant> Given the
<StevenK> Not handy
<wgrant> possible new DSP cache table approach, this may all be irrelevant.
<StevenK> wgrant: Yes, I wanted to talk about that too
<wgrant> Since we'll have a cache table which has (archive, sourcepackagename, [binaries]) or so.
<StevenK> We will?
<wgrant> I hope so.
<wgrant> Something like DistributionSourcePackageCache, except not stupid and less useless.
<wgrant>  binpkgnames        | text         |
<wgrant> Also without that.
<wgrant> plural -> text
<StevenK> And not like DistributionSourcePackageInDatabase? :-)
<wgrant> Uh, yeah.
<wgrant> StevenK: Have you, sinzui and bigjools discussed this at all?
<wgrant> I saw bigjools decrying the idea that something could be in a distribution without a publication, but that's about it.
<StevenK> The thing that sinzui and I have discussed is populating the DSP table for series older than maverick
<wgrant> And for other series.
<wgrant> It doesn't need populating for old series.
<wgrant> It needs reconceiving, reworking, and reimplementing.
<wgrant> Then you can think about populating it.
<jtv> wgrant, are you reviewing today?  You might enjoy this one. https://code.launchpad.net/~jtv/launchpad/fix-some-utilities/+merge/72523
<StevenK> wgrant: So we have DSP, DSPC, and DSPID. /wrists
<wgrant> StevenK: Right. We need to talk about how this should work.
<wgrant> jtv: Sure.
<wgrant> jtv: The number of selfs in interfaces is disturbing.
<jtv> Yes, maybe we should just add a grep to "make lint."  :-)
<wgrant> StevenK: (DSPC is presently updated by a script that takes like 20 hours)
<StevenK> And DSPID is perpuated by IPublishingSet.newSourcePublication()
<wgrant> It's not quite clear what should happen to DSPID.
<wgrant> It possibly still has a place in the world.
<wgrant> jtv: Approved.
<jtv> Thanks.
<wgrant> StevenK: I think we need to take DSP, DSPC, DSPC and DSPID, all their users, and some other stuff and work out WTF we have and what we want.
<wgrant> (no the two DSPCs are not a mistake: DistributionSourcePackageCache and DistroSeriesPackageCache)
<wgrant> I can hear your wrists from here.
<StevenK> That's funny, I didn't think blood pooling on the carpet was that noisy.
<nigelb> Is StevenK slashing his wrists again? :P
 * StevenK logs into the ec2 instance that is testing nigelb's branch and injects a few failures.
<nigelb> gah!
<wgrant> lifeless: https://bugs.launchpad.net/python-oops-wsgi/+subscriptions <- please unsubscribe launchpad-security
<wgrant> Anyone can add the subscription, but only a team admin can remove it :)
<nigelb> hm, isn't there something wrong with that?
<StevenK> wgrant: So I think DSP is used by a *lot* of stuff -- and DSPID is tied directly into most of it. The two DSPCs, I don't really know
<wgrant> Merging DSP and DSPID is going to be really fiddly and time-consuming, if it ever happens.
<wgrant> It may be best to add a flag on DSPID indicating officialness.
<wgrant> Or just assume that is presence is official.
<wgrant> But then you'd also need to join against DSPC to do the binary lookup.
<wgrant> DSPC has the complication that it has an archive.
<StevenK> So I think you're right. It's a horrid horrid mess, and it needs to die.
<wgrant> You know what would be cool?
<wgrant> If Launchpad wasn't a monolithic monster with no separation or interfaces.
<StevenK> Hah
<StevenK> Right, DSP fills me with despair
<wgrant> But if we can work this out, then Soyuz will be much closer to its own little world.
<wgrant> s/world/insane asylum/
<wgrant> Since Bugs will have no fingers left in the Soyuz pie.
<wgrant> Oh, curses.
<wgrant> Components.
<wgrant> And bug nomination permissions.
 * wgrant dies.
<StevenK> Yes
<StevenK> I'm making a list, and getting more depressed by the microsecond
<wgrant> Anyway, let's see what still uses DSPCÂ²
<wgrant> I think most of its users are long-dead.
<StevenK> Which DSPC?
<wgrant> Â²
<wgrant> ie. both.
<wgrant> They are similar.
<wgrant> And have the same name.
<StevenK> OH, WHAT THE
<wgrant> ?
<wgrant> The name is slightly different
<wgrant> DistroSeries vs DistributionSource
<StevenK> DistributionSourcePackage.getPersonsByEmail(email_addresses)
<StevenK> SERIOUSLY?
<wgrant> Pardon?
<wgrant> lib/lp/registry/model/distributionsourcepackage.py:    def getPersonsByEmail(email_addresses):
<StevenK> It's in there, and the DSP view calls it
<wgrant> O_O
<wgrant> You are correct.
<wgrant> It will die before EOD.
<StevenK> Can I kill it?
<wgrant> brb, qannotate
<StevenK>         the_changelog = '\n'.join(
<StevenK>             [spr.changelog_entry for spr in sprs
<StevenK>              if not_empty(spr.changelog_entry)])
 * StevenK now feels depressed and ill
<wgrant> That evil is somewhat necessary, unfortunately.
<StevenK> Icky
<wgrant> Debian changelogs are, yes.
<StevenK> If we're logged in, pull every single e-mail address out of a constructed changelog, call that abomdination of a method, and then drop persons that have hidden mail addresses
<StevenK> *Disgusting*
<wgrant> It does seem to be the sort of thing that built up slowly over 5 years into an unfathomable monster, which could have been avoided if it had been redesigned half way through.
<wgrant> Hmm, like something else...
<wgrant> Launchpad!
<lifeless> hang on
<lifeless> why do we drop those people?
<wgrant> Probably so we can show the email addresses, just unlinked because why.
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https:dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256
<lifeless> well
<lifeless> couldn't we show the person and not show the email addresses ?
<wgrant> The changelog is indexed by numerous other places.
<wgrant> Anybody putting their email address in a changelog but wanting it to remain private is even more misguided than someone who wants their email address to remain private.
<wgrant> And that is saying something.
<lifeless> sure
<lifeless> but thats a separate argument, AIUI we're currently not linking to the persons
<lifeless> which seems bizarro
<wgrant> Not necessarily.
<wgrant> To link them would allow you to determine the owner of an address.
<lifeless> you can probe for (many) by sending a comment to a bug with a custom from
<wgrant> s/an address/a private address/
<wgrant> Ja.
<lifeless> over half our users in fact
<wgrant> Hm?
<lifeless> does 'private address' mean 'do not show', or 'do not link against from other data sources'
<lifeless> I think its intended to be the former
<wgrant> lalalala
<lifeless> IIRC the UI says 'hide address' not 'pretend it does not exist'
<wgrant>  Hide my email addresses from other Launchpad users
<lifeless> right
<StevenK> wgrant: And if we're going to attack DSP/DSPID, what about its bastard half-sibling, DSPR?
<wgrant> StevenK: It's unrelated.
<wgrant> It exists solely for the URL space.
<StevenK> wgrant: Have you finished looking for DSPC usage?
<wgrant> You distracted me.
<StevenK> Heh
<StevenK> I suppose screaming blue murder is a bit distracting.
<lifeless> wgrant: how did l-s get subscribed ?
<wgrant> lifeless: It's the bug supervisor.
<wgrant> lifeless: Bug supervisors get a subscription by default, because someone likes to confuse people.
<lifeless> aieee
<lifeless> so there will be a few more to clean up
<lifeless> is there a page showing all l-s's subscriptions
<wgrant> Yes.
<lifeless> and the docs need tweaking
<wgrant> Possibly... I think it might ahave been cut.
<wgrant> Let me try to find it.
<lifeless> https://launchpad.net/~launchpad-security/+subscriptions
<wgrant> Yeah./
<lifeless> which mingles structural and explicit.
<lifeless> or perhaps only shows concrete objects
<lifeless> StevenK: indices on non-empty-or-close-enough tables are separate patches, yes.
<lifeless> wgrant: cleaned up the ones i can remember making
<wgrant> lifeless: Thanks.
<wgrant> https://launchpad.net/~launchpad-security/+structural-subscriptions
<lifeless> and the docs are updated
<wgrant> Three left.
<lifeless> I wonder
<wgrant> Bug mail for Launchpad Security about Timeline is filtered; it will be sent only if it matches the following filter:
<wgrant> This filter allows all mail through.
<wgrant> Yay.
<lifeless> can you subscribe an arbitrary team by setting bug-supervisor
<lifeless> apparently I am in a team cxalled 'morfose'
<wgrant> You used to be able to.
<wgrant> I think only team members can now, though.
<lifeless> fixed those as well
<wgrant> Thankyou sir.
<StevenK> wgrant: DSPC, or did lifeless distract you? :-)
<wgrant> blargh dying
<lifeless> wgrant: on and from
<wgrant> lifeless: Monday?
<lifeless> yes
<wgrant> :(
<lifeless> jamesh: re patching other frameworks. Perhaps ;) certainly though they must have some way of glueing in already and making users upgrade their platform isn't really a goal of python-oops-wsgi : so both hacking around, and doing the Right THing, is probably needed
<StevenK> Surely we already have a method to return Persons given an iterable of e-mail addresses
<wgrant> StevenK: I doubt it.
<StevenK> wgrant: So, I hack the view to call IPersonSet.getByEmail(), but that strikes me as slow
<wgrant> Impractically slow, yes.
<wgrant> You need to introduce a sensible method to do it in one query.
<StevenK> On IPersonSet, do you think?
<wgrant> Next to getByEmail, yes.
 * StevenK attempts to not swear in a branch name
<wgrant> getByEmail becomes a convenience wrapper.
<StevenK> Sounds like a plan
<jamesh> lifeless: I wouldn't be surprised if other frameworks are as easy to fix as Django.
<jamesh> lifeless: and for some there might be an option to disable error recovery, letting everything fall through to the wsgi container
<lifeless> jamesh: sure
<jamesh> lifeless: having some way to report the exception from deep in the stack might be enough to hack around frameworks that don't do the right thing: that is essentially how we're currently using wsgi-oops's logging support.
<lifeless> wheee
<lifeless> 831035 is a dupe isn't it ?
<LPCIBot> Project devel build #984: STILL FAILING in 5 hr 54 min: https://lpci.wedontsleep.org/job/devel/984/
<wgrant> lifeless: Fixed.
<lifeless> pop quiz
<lifeless> rewrite zeca as simple server, as a paste app, web.py, or keep it as twisted ?
<wgrant> Should be pretty trivial to make it Paste/webpy, right?
<lifeless> yes
<wgrant> It's like 300 lines.
<StevenK> Given a result set which returns two columns, can I call something on it to just return the first column and first row?
<wgrant> StevenK: Do you have a more specific example?
<lifeless> StevenK: slice it to get the first row; then call .values()
<lifeless> StevenK: but better to decide what you want to query in the first place
<StevenK> I have a query which returns (Person, EmailAddress), I want the first Person only
<lifeless> for clarity, I like twisted, but its seems a heavy dep for this
<lifeless> and I *hate hate hate* .tac files
<wgrant> It is only a test dep, though, right?
<nigelb>  \o/ TEST SUCCESS
<lifeless> wgrant: yes
<nigelb> StevenK: Thanks! :)
<lifeless> but I need to extract ready service and a tonne of stuff
<wgrant> True.
<lifeless> ahh, wsgiref
<wgrant> lifeless: It seems like porting it would be pretty easy.
<lifeless> wgrant: onh for sure
<lifeless> it raises the question that perhaps readyservice is needed for other tests
<wgrant> And just about anything but Zope is lighter than Twisted.
<wgrant> True.
<lifeless> OTOH I think importing zcml is the problem.
<lifeless> 'microservice' + 'zcml' are incompatible
<wgrant> Heh.
<wgrant> Not necesarily :)
<StevenK> ProgrammingError: operator does not exist: text = bytea
<StevenK> Sadface
<wgrant> You fail at Unicode.
<wgrant> And Python 2 doesn't help.
<StevenK> Yes
<StevenK> I think I have purged the evil
<wgrant> Excellent.
<StevenK> % bzr di | diffstat | tail -n 1
<StevenK>  5 files changed, 23 insertions(+), 28 deletions(-)
<wgrant> I'm still working out how best to fix DSP(CÂ²|ID)?
<wgrant> StevenK: diffstat -s
<StevenK> I shall have to try and remember that.
<StevenK> OPENID! STAB!
<jtv> wgrant: what say you we make make lint grep for "self" in interface methods?
<lifeless> some actually classes are in interface modules
<lifeless> (and need to be)
<lifeless> As long as they are catered for, it makes sense to me.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/dsp-getpersonsbyemail-stab-stab-stab/+merge/72528
<jtv> lifeless: that's a nuisance.  Got any examples for me?
<lifeless> not offhand
<jtv> I can think of enums, but they don't have methods.
<lifeless> jtv: stuff in bugs probably, and things raised in notify() are commonly in the interface (and thats a zope inherited idiom)
<jtv> Thanks, that gives me something to look for.
<jtv> StevenK, wgrant: do I remember correctly that you were scheming to add source package names to SPPH?
<wgrant> jtv: The patch has landed.
<jtv> wgrant: soâ¦ in db-devel now, to be rolled out RSN?  It may well be useful to what I'm doing right now.
<wgrant> jtv: Yeah. Then we need to populate it and add indices and stuff.
<wgrant> jtv: What are you up to? gina deletions?
<jtv> Yup.
<wgrant> Indeed, it would make that rather quick.
<wgrant> However, after the first run it should only have like 20000 publications to consider.
<wgrant> So it won't be that slow even without it.
<jtv> I'm not too worried about the number of publications to considerâAIUI I only need to worry about ones where superseded is null, and that helps massively.
<jtv> I'm worried about client-side memory.
<wgrant> supersededby is not relevant here.
<jtv> Why not?  I only need to delete SPPHs in "published" or "pending" statuses, right?  Can an SPPH be superseded yet be in one of those states?
<wgrant> No.
<wgrant> But supersededby does not determine supersededness.
<wgrant> yes, anything with supersededby set is not Published or Pending, but it's not the correct discriminator.
<lifeless> jamesh: around ?
<jtv> wgrant: it doesn't have to be the correct discriminator and it doesn't need to determine supersededness.  It only needs to eliminate lots of SPPHs that I'm not interested in very effectively.
<wgrant> jtv: Filter on status.
<wgrant> status IN (1, 2)
<wgrant> Done.
<wgrant> That eliminates all the SPPHs you're not interested in, and is probably the most indexed column on the table.
<jtv> Well of course I'm filtering by status.
<jamesh> lifeless: yeah
<wgrant> Then why are you interested in supersededby?
<lifeless> jamesh: some of lp's gpghandler looks like things gpgme could sensibly have
<lifeless> jamesh: what do you think ?
<jtv> wgrant: like I said, I'm looking for ways to eliminate uninteresting SPPHs.  But if status does that well enough, then fine.
<jtv> As I said, it's not important.
<wgrant> jtv: You need to consider everything that is still active.
<jamesh> lifeless: is this significantly different to the gpg utility thingee I'd remember from 2008, or something different?
<lifeless> jamesh: doubt it
<lifeless> jamesh: things like 'santizei a fingerprint'
<jtv> wgrant: And you just said that this wouldn't affect that.  As I'm said, it's not that important.
<lifeless> 'import a secret key' -> checks the key was imported, and only the one key
<wgrant> jtv: Right, but your initial comment about "superseded is null" had me somewhat concerned.
<lifeless> (and can disable the agent temporarily for tests)
<jamesh> lifeless: okay.  Where abouts is this code?  If you're talking about some code I haven't seen then I can't sensibly answer the question.
<lifeless> jamesh: I doubt it is different to what you've seen
<lifeless> jamesh: I'll get you a url though, one sec
<lifeless> jamesh: (I think the sense of my reply got inverted somehow)
<jamesh> oh.  you meant you doubt it is different rather than doubt it is the same.
<lifeless> yes :)
<lifeless> 'is it different?' 'doubt it' :P
<lifeless> jamesh: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/launchpad/utilities/gpghandler.py
<lifeless> jamesh: I'm pulling out the for-test-only stuff into lp:gpgfixtures
<lifeless> jamesh: e.g. making a GNUPGHOME dir
<lifeless> jamesh: stashing test keys
<lifeless> jamesh: running a test keyserver.
<lifeless> jamesh: most of the rest looke like gpgme code to me. In the spirit of better-than-what-it-wraps.
<lifeless> PymeUserId can just get deleted though
<lifeless> and be replaced with a zope decl.
<lifeless> or at least, its not a candidate for moving into pygpgme
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<jtv> All well?
<lifeless> jamesh: so, your thoughts ?
<jamesh> lifeless: I guess some of them might make sense.  The sanitisefingerprint one looks a bit mysql-ish the way it truncates long input
<lifeless> jamesh: so, it clearly doesn't belong in LP :)
<lifeless> jamesh: I could make a third library to wrap gpgme, but that seems an arbitrary split
<jamesh> I'd be happy to include some helper utilities along side the extension module.
<lifeless> whats your preference? Like I say, I want to gut (most of) this stuff from LP, and AFAICT its in three camps: test code, input handling, sane-default-wrappers-of-gpgme-things
<jamesh> it'd be worth checking on a case by case basis whether the helpers make sense though.
<lifeless> the test code -> gpgfixtures, because I think its inappropriate to impose that on every user of gpgme
<lifeless> [though gpgme's test suite could well use gpgfixtures if you don't mind a test-only dependency]
<jamesh> some of the checks it is doing are no longer necessary (e.g. explicitly checking for multiple signatures as a possible concatenated clear signed message attack, which gpg has errored out on for a while now)
<adeuring> lifeless: could you also review my MP you already commented on?
<lifeless> adeuring: sorry, no
<wgrant> jamesh: Hm, does it really?
<lifeless> adeuring: if you can't find another reviewer I will, but I have approx 24 hours work time to get microservices live, before I'm away for a while
<wgrant> jamesh: Given a few recent vulnerabilities I've found, I'm not so sure about that.
<adeuring> lifeless: ok, no problem
<lifeless> jamesh: that wouldn't be harmful to handle though, would it? (In case of folk running old gpg)
<jamesh> wgrant: I used to have tests for concatenated clearsigned blocks in the pygpgme test suite, and they stopped passing
<wgrant> Hmm.
<wgrant> Must be slightly different.
<jamesh> lifeless: it'd be really old gpg though.
<mrevell> Hey good morning#
<lifeless> jamesh: so, its your call. I am going to extract what I need to test gpgverifyd from LP; thats definite. If you'd like it in gpgme as a place for others to reuse and iterate, I'd be delighted to add it there (with tests etc)
<lifeless> jamesh: if you don't want it, no skin off my nose ;)
<lifeless> jamesh: And if you do want it, I'll happily to modest tweaks to meet whatever style or other criteria you have.
<jamesh> lifeless: the best option is probably to file bugs against pygpgme, and we can work from there.
<lifeless> jamesh: that really doesn't work for me; I have a very short time to do a lot of stuff, so the round trips involved there would destroy any hope of getting what I need to get done done.
<lifeless> jamesh: sorry
<lifeless> jamesh: in case that came across as a bit dicky, I guess I mean I need to action it now, and can round trip in review etc, but doing a pre-flight-check on it all just seems to front load round trip discusssions that review will need anyhow.
<jamesh> lifeless: I don't necessarily mean do it all individually.  If you've got an idea of what you would like to see moved, I'd be happy to review that all in one go.
<jamesh> lifeless: that said, if all the helpers do is wrap StringIO()'s around the arguments, I'm not sure if that adds a lot of value
<lifeless> well, they check for bytestrings, check how many signatures are found, sanitise input
<jamesh> the gpghandler interface was originally wrapped around a different gpg interface, so there is a fair bit that would be different if pygpgme was the starting point
<lifeless> pygpgme still exposes what gpgme does though right? its very up-to-the-user-to-interpret? [which most of this lp non-test-code is - interpretation]
<jamesh> and I don't remember why the code configures "keyserver-options auto-key-retrieve" and also has code to directly download keys from the keyserver's http interface
<lifeless> thats test code
<lifeless> as I said, its not what I'm talking about
<lifeless> that will be in gpgfixtures.GPGHomeFixture
<lifeless> for pygpgme I am talking about: sanitizeFingerprint, getVerifiedSignature importPublicKey importSecretKey encryptContent(possibly) signContent(possibly)
<lifeless> _submitKey might be intereseting
<jamesh> okay.  It is just that most of the helpers include the http key download, which I would have thought was handled if your gpg config is for auto-key-retrieve
<lifeless> the encrypt and sign stuff aren't really interesting to me at this point, and they probably need a lot more consideration
<lifeless> jamesh: I can test that
<lifeless> you're talking about the comment for handling of subkeys, yes ?
<lifeless> which is in getVerifiedSignature
<jamesh> everything that calls retrieveKey() is potentially doing an HTTP request
<StevenK> Oh, bah.
<lifeless> yes, which is only getV..S.. of the ones I listed
<StevenK> Now it's +31/-28
<StevenK> I am disappoint.
<lifeless> StevenK: delete 3 random lines.
<lifeless> jamesh: for the win : we don't test that subkey code path anyhow
<lifeless> aieee http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/lib/canonical/launchpad/utilities/gpghandler.py
<lifeless> well, perhaps in gpg-signatures.txt. If that still exists
<jamesh> I'd be hesitant to accept things like getVerifiedSignatureResilient(), fwiw :)
<lifeless> jamesh: not on my list
<lifeless> jamesh: noddy things are noddy
<jamesh> right.  it is just things like that that make me nervous about you initially talking about merging gpghandler into pygpgme.  The smaller set of methods seems a lot more sane.
<jamesh> wgrant: fyi, here's the CVE about the message concatenation issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1263
<jamesh> you'd have to be using particularly old code to be vulnerable
<wgrant> jamesh: Ah. Not the same thing, right. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1829 and a few related things are what I discovered. Only one signature, but some unsigned bits.
<jamesh> ah.  I guess that is what happens when you roll your own gpg interface ...
<wgrant> Inline signatures must die.
<wgrant> Yes!
<wgrant> LP/dak were similarly vulnerable.
<wgrant> (mostly because the LP code was copied straight from dak)
<wgrant> We need good libraries.
<jamesh> prior to the CVE I linked, you couldn't distinguish between a single clearsigned document signed by two keys and two concatenated clearsigned documents signed with one key each using gpgme
<jamesh> now you can because the second form errors out
<lifeless> heh, so a quick test suggests that retrieveKey going to the keyserver is indeed needed
<lifeless> digging further
<lifeless> (I replaced the http lookup with a key search, but that doesn't find the key)
<lifeless> so - verifying the signature just-in-time obtains the signing subkey, not the master key.
<lifeless> ah, wants GPGME_KEYLIST_MODE_EXTERN
<jtv> gmb: morning!  Can I trouble you for a review?  https://code.launchpad.net/~jtv/launchpad/pre-830890/+merge/72535
<stub> Anyone fixing the merge conflict?
<lifeless> jamesh: ok, so heres what a quick poke got me
<lifeless> jamesh: the auto key retrieval only gets the specified key
<lifeless> jamesh: some keyservers return the master, some don't (this I remember from way back :P)
<lifeless> jamesh: setting context.keylist_mode = context.keylist_mode | gpgme.KEYLIST_MODE_LOCAL | gpgme.KEYLIST_MODE_EXTERN
<lifeless> jamesh: does do an hkp lookup, but seems to not work - and there are mailing list messages asking about this same behaviour upsream
<lifeless> jamesh: so it looks like some nontrivial debugging is needed to identify whats going on (possibly not very hard, but very much a yak I didn't plan on shaving)
<jamesh> hmm.  The gpg man page also mentions an "include-subkeys" keyserver option, but it says "Note  that  this  option is not used with HKP key servers, as they do not support retrieving keys by subkey id"
<lifeless> yes
<stub> I've got the merge conflict - just looks like imports
<jamesh> ah.  it is saying that hkp supports retrieving subkeys by subkey id, but not the whole keys by the subkey id
<lifeless> anyhow, I think I need to keep the http lookup because the test case (which does still exist) does fail.
<lifeless> jamesh: exactly, and we're running with hkp.
<jamesh> fair enough.
<lifeless> you have to do two requests, one for the subkey, and one for the master, and the 'obvious' way to make get_key do the retrival for us doesn't work.
<jamesh> so the utilities would need to know about an http keyserver?
<lifeless> e.g. just doing get_key(sig.fpr) barfs, with or without keylist_mode set
<lifeless> jamesh: I think its fugly to have the python code doing the lookups
<lifeless> jamesh: I don't know how deep the rabbit hole to avoid that is ;)
<lifeless> its pretty clear that the Right Thing depends on whether the gpg.conf has a keyserver setup and whether it has auto-key-retrieval setup
<lifeless> so certainly *some* degree of configuration is needed
<lifeless> whether that should be supplied (Wrapper(keyserver=xxx)) or inferred by grepping gpg.conf, etc I dunno
<lifeless> I think at this point I'm inclined to rename gpgfixtues to gpgsupport or gpgwrappers or something, bundle the http code and all into it
<lifeless> and file a bug saying that this aspect is fugly and point in the right long term direction
<gmb> jtv: Sure, I'll take a looks shortly
<jtv> thx
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 238 - 0:[#######=]:256
<lifeless> jamesh: what do you think?
<jamesh> lifeless: that might be a good short term option.  I'm still open to moving parts that make sense to gpgme.
<jamesh> pygpgme, even
<gmb> jtv: Approved. Good stuff; I likes me a cleanup.
<jtv> yay
<jtv> thanks again
<gmb> np
<lifeless> jamesh: thanks
<adeuring> gmb: could you review this MP: https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-fix-issues-for-unprecise-result-length/+merge/72473/+index ?
<gmb> adeuring: Certainly
<adeuring> thanks!
<lifeless> night y'all
<bigjools> nn
<wgrant> Yay, loggerhead OOPSes work again.
<wgrant> jelmer: I guess you were trying to QA stuff?
<jelmer> wgrant, yep
<wgrant> jelmer: Although the bzr-svn rev is much less interesting right now that the SafeBranchOpener one.
<jelmer> wgrant, I'm looking at both - the SafeBranchOpener one was why I was asking about loggerhead
<wgrant> Ah, of course.
<wgrant> Thanks.
<StevenK> wgrant: DistributionSourcePackage.createBug() makes me sad.
<wgrant> StevenK: ... does anything use it?
<StevenK> Yes, sadly.
<wgrant> Ew what/
<wgrant> Surely not +filebug.
<wgrant> But it looks like it may.
<StevenK> wgrant: Two soyuz tests, at least.
<StevenK> wgrant: But there are a large amount of methods called createBug()
<StevenK> Distribution and Distroseries have one, as does Product ...
<wgrant> Looks like it's a standard IBugTarget method.
<gmb> adeuring: Approved.
<adeuring> gmb: thanks!
<gmb> np
 * gmb lunches
<henninge> gmb: when you are back from lunch: I have a branch here that I hope you'll have as much reviewing, if you can, as I had writing the code. ;-) Seriously.
<henninge> https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-2/+merge/72546
<henninge> it's slightly oversized, though.
<henninge> s/slightly//
<benji> nigelb: there were some test failures for https://code.launchpad.net/~nigelbabu/launchpad/4595-upgrade-bug-linking/+merge/71575
<benji> I pasted them as a comment.
<LPCIBot> Project devel build #985: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/985/
<gmb> henninge: Sure, I'll take a look shortly
<henninge> gmb: great, thank! ;-)
<henninge> s
<nigelb> benji: I fixed them and got it rebuild and merged.
<nigelb> (retested)
<benji> cool
<nigelb> You would have caught it, except I gave you a useless diff yesterday :)
<deryck> Morning, everyone.
<gmb> henninge: Nice work! Approved.
<henninge> gmb: Thank you! ;)
<gmb> danilos, henninge, jtv: Can one of you help radifar over in #launchpad? He seems to be getting a weird error when trying to review a translation.
<jtv> gmb: sorry, too far past EOD here.
<gmb> jtv: No worries
<jtv> Ta
<bigjools> stub: still there?
<stub> yo
<bigjools> stub: patch-2208-78-1.sql won't apply on DF because there's loads of null owner columns - do you know if the production data was massaged outside of a patch?
<stub> bigjools: There was a garbo job that cleaned the data
<bigjools> crap
<stub> bigjools: Which will be the standard way of doing data migration now, so need to get that running regularly on DF.
<bigjools> *cry*
<bigjools> ok
<bigjools> thanks
<stub> Should be able to fix the data with a single update if you don't want to chase the old garbo... hangon.
<bigjools> yeah DF is not there to test bugs stuff so I don't care if I poke it with Joe Blogs
<stub> update bugmessage
<stub> set owner=message.owner
<stub> from message
<stub> where message.id = bugmessage.message;
<bigjools> ta
<bigjools> stub: should I run -daily or -hourly?
<stub> bigjools: I don't think we have standardized which is needed for data migration - might need both (and soon -frequently too once the db-devel merge is unblocked), but you don't need to run them all that often.
<bigjools> stub: well I was going to cron one in on DF to run late at night when nobody is using it so that I don't have to sit and wait again like I am now :)
<deryck> henninge, ping for standup.
<henninge> deryck, abentley: sorr y guys, my phone is acting up ...
<henninge> need to reboot
<deryck> henninge, np.  we'll start and join when you can.
<bac> gmb when you have time could you look at https://code.launchpad.net/~bac/launchpad/bug-823490/+merge/72577
<gmb> bac: sure
<gmb> bac: Approved.
<bac> thanks gmb
<nigelb> qastaging is continously timing out.
<gmb> nigelb: WFM. Can you give a specific URL?
<nigelb> gmb: worked after continously abusing F5 ;)
<gmb> Heh.
<nigelb> bugs.qastaging.launchpad.net/bugs was what timed out for me :)
<abentley> gmb: could you please review https://code.launchpad.net/~abentley/launchpad/bad-state-transition-2/+merge/72592 ?
<gmb> abentley: Sure.
<abentley> gmb: thanks.
<gmb> abentley: approved
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256
<abentley> gmb: Thanks!
<gmb> np
<LPCIBot> Project db-devel build #817: STILL FAILING in 6 hr 22 min: https://lpci.wedontsleep.org/job/db-devel/817/
<LPCIBot> Project devel build #986: STILL FAILING in 4 hr 54 min: https://lpci.wedontsleep.org/job/devel/986/
<mrevell> G'night all!
<jml> Are all the Virginians alright?
<jml> And NCers too
<benji> jml: yep, but we've used up this month's supply of adrenaline
<nigelb> heh
<jml> benji: heh. glad to hear all is well :)
<bac> jml: people 7 miles north and 25 miles east of here felt it ... but there was nothing where i am.
<bac> but that's ok, as we have a hurricane four days out
<nigelb> heh
<nigelb> we're happend to lend you adrenaline :P
<nigelb> *happy
<deryck> cr3, ping
<cr3> deryck: pong, what's up?
<bac> matsubara: what's the procedure for clearing out the staging/qastaging imap mbox?  it's pretty big and i'd be happy to zap it.
<matsubara> bac, I thought there was a script running deleting those messages. Ursinha used to run it
<matsubara> bac, I think old emails can be safely deleted from the mbox
<bac> matsubara: ok
<matsubara> or any bug email
<matsubara> since those are the ones that takes the most space
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256
<lifeless> gary_poster: ping
<gary_poster> lifeless, hi
<lifeless> gary_poster: with buildout develop = ...
<lifeless> gary_poster: is there a way to set that without editing a version controlled file in the LP tree ?
<bac> abentley: an ec2 job just failed due to the new test_memory_hog_job.  have you seen any spurious failures with it before?  i can't reproduce locally
<gary_poster> lifeless, should be, if I understand you.  ./bin/buildout section:key=value works IIRC, so ./bin/buildout buildout:develop=foo ought to work.  I'll go confirm with docs...
<lifeless> gary_poster: that sounds great.
<lifeless> I will edit our docs :)
<abentley> bac: No, I haven't seen spurious failures before.
<lifeless> gary_poster: this is the bit I was referring to - https://dev.launchpad.net/HackingLazrLibraries 'In this software's buildout.cfg, in the [buildout] section, look for a
<lifeless> develop key. I'....
<gary_poster> ah gotcha lifeless.  Yes, I remembered correctly, at least generally, and that ought to work for this specific case. (http://pypi.python.org/pypi/zc.buildout/1.5.2#command-line-usage fwiw)
<lifeless> gary_poster: care to check my recording of it ? https://dev.launchpad.net/HackingLazrLibraries
 * gary_poster looks
<gary_poster> lifeless, do these contradict? "A reasonable option is to add it in the top-level directory of this software." vs "The best thing to do is to locate it in a sibling tree so that its separation is clear."  If so, let's settle on one; if not, it needs some clarity.
<gary_poster> "but that will get committed and as such is rarely what you want": *really* rarely as long as bzr doesn't support externals ;-) Once we have externals, it can be nice in some cases.
<gary_poster> "When you want to switch back to using an egg for that other component run bin/buildout build:develop=.": Actually, you should just need to run "bin/buildout".  You won't be overriding the set value anymore on the commandline, so...it should just work.
<lifeless> gary_poster: ok, so one needs to keep supplying the key until done ?
<gary_poster> yes lifeless
<lifeless> gary_poster: I would like to delete the nesting options
 * gary_poster on call
<lifeless> gary_poster: given that we're using buildout for getting at stuff, one system is preferrable to three, all other things being equal
<gary_poster> ack
<lifeless> gary_poster: tweaked further, if you can let me know after your call that would be great
<gary_poster> cool
<sinzui> jcsackett, do you have time to mumble?
<jcsackett> sinzui: sure.
<jcsackett> sinzui: i hear you. i presume you cannot hear me.
 * sinzui looks at sound preferences
<gary_poster> lifeless, I just read the lazr page: looks good, thank you
<lifeless> gary_poster: thanks
<lifeless> jelmer: had you heard of 'python-gitdb' before its ITP ?
<jelmer> lifeless: yeah, it's from the author of python-git
<lifeless> jelmer: he didn't like your stuff ?
<jelmer> lifeless: although I was a bit surprised to see the ITP - python-gitdb is EOL, and merged into python-git
<jelmer> lifeless: python-git existed before dulwich, but was always more of a wrapper around git itself
<jelmer> lifeless, he's only recently started looking at a pure-python implementation
<lifeless> its a bit sad he's not using dulwich
<jelmer> yeah
<jelmer> lifeless: apparently python-git has support for multiple backends - gitdb being one of them, and dulwich and pygit2 (Python wrapper around libgit2) being other backends
<lifeless> jelmer: interesting, though you have to wonder why gitdb is needed then ;)
<LPCIBot> Project db-devel build #818: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/818/
<LPCIBot> Project devel build #987: STILL FAILING in 5 hr 51 min: https://lpci.wedontsleep.org/job/devel/987/
#launchpad-dev 2011-08-24
<StevenK> wgrant: http://pastebin.ubuntu.com/673437/
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 238 - 0:[#######=]:256
<wgrant> https://answers.launchpad.net/launchpad/+question/158269
<wgrant> Intriguing.
<wgrant> People really seem to care about revision numbers matching.
<lifeless> yes
<lifeless> we could make bzr handle sparse mainlines ;)
<wgrant> You are a bad person.
<wgrant> Still.
<wgrant> At least not as bad as whoever designed Mercurial revnos.
<lifeless> I am an awesome person
<lifeless> solving the world, one line at a time.
<wgrant> Compared to whoever designed Mercurial revnos, yes.
<wgrant> Do you know how they work?
<wgrant> They are really, really useless.
<lifeless> yes
<lifeless> they are perfectly useful for the purpose designed
<lifeless> just extremely local in scsope
<lifeless> (and sparse on any given branch)
<wgrant> Grarrr.
<wgrant> >>> u.newPackagesetUploader(packageset=lp.packagesets.getByName(name='zope', distroseries='/ubuntu/oneiric'), person=lp.people['wgrant'])
<wgrant> <archive_permission at https://api.qastaging.launchpad.net/devel/ubuntu/+archive/primary/+upload/wgrant?type=packageset&item=zope&series=oneiric>
<wgrant> newPackagesetUploader is in IArchiveView, so we are qa-bad.
<wgrant> Yay.
<wgrant> We will be doing a 60-70 rev deploy tomorrow :D
<lifeless> oh, assign-me-permissions to anhyone ?
<wgrant> Yeah.
<lifeless> win
<wgrant> This deploy will also have some really risky stuff in it.
 * wgrant dies.
<lifeless> :(
<lifeless> anything I can do to help?
<wgrant> No.
<wgrant> Apart from declaring devel frozen.
<wgrant> production is now 57 revisions behind tip :/
<wgrant> I guess we should deploy the first 10 that we can do today.
<lifeless> if its qa ok yeth
<wgrant> Hm?
<lifeless> I agree conditional on that being qa-ok :)
<wgrant> Heh.
<wgrant> We have 13 deployable.
<wgrant> Let's do that.
<StevenK> wallyworld: (Wow, no underscores) WRT https://code.launchpad.net/~wallyworld/launchpad/rename-private-team-795771/+merge/72516 , does that mean that private teams can be renamed or this is just UI gubbins?
<wallyworld> StevenK: just ui
<StevenK> wallyworld: So you can't use the UI to perform a rename?
<wallyworld> StevenK: you can once the branch lands
<wallyworld> for private teams
<wallyworld> whereas before private teams you couldn't
<StevenK> wallyworld: Then I'd like a test that actually *tests* that. At the moment your test only checks the widgets on the +edit page
<StevenK> And the error conditions
<wallyworld> StevenK: that's all the doc tests that were replaced by unit tests ecer did
<wallyworld> the testing checks that the name field is or is not readonly in the right places
<wallyworld> ie it is read only for those situations where the team cannot be renamed
<wallyworld> from there on, when the user hits Save, it's just a normal domain model update operation
<StevenK> wallyworld: Even so, you (correctly) removed a test that private teams can not be renamed -- I'd still like to see an end-to-end test where you initialize the +edit view, submit it and assert the team name has changed.
<wallyworld> but if the name field is not display only, then existing tests will cover that
<wallyworld> scenario
<wallyworld> all we need to test here is whether the name field is display only or not
<wallyworld> since that's what the previous functionality did for private teams
<wallyworld> seems like we would be duplicating tests
<StevenK> wallyworld: No, existing tests will not. Since the code was previously written to forbid renaming private teams, I find it highly suspect that there is another test for what I'm asking.
<wallyworld> so you think there is an existng end-end test for private team renaming? there's nothing at the db layer to prevent private teams being renamed (there is for the mailing list restriction though)
<wallyworld> the code that was previously written to forbid private team renaming was just inthe view and alit did was disable the name field
<StevenK> wallyworld: No, I think there is *not* an existing end-to-end test for private team renaming.
<wgrant> If you're removing a special case like this, it's probably not immensely beneficial to test the special case that you're removing.
<StevenK> I'm concerned that something else will pop up during QA
<wallyworld> i can add an end-end test if you insist but it will be a brand new test - afaik we don't normally test simple crud stuff in the view tests?
<wallyworld> so it wouldn't be a view test but a test in the model layer?
<wallyworld> view tests normally just check that the view has rendered correctly and the actions have been wired up?
<lifeless> anyone up for a simple review ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72640
 * wallyworld has to go pick up kid from school for orthodontist appointment $$$$ :-(
<lifeless> StevenK: ^
<StevenK> Yes, yes, I'm already looking
<lifeless> thanks
<lifeless> I couldn't tell
<StevenK> I'd be worried if you could
<StevenK> lifeless: So why is there a lone '\' on line 284 of the diff?
<lifeless> StevenK: that was a test. You pass.
<lifeless> StevenK: (deleting it ;))
<lifeless> hah
<lifeless> StevenK: I forgot one commit
<lifeless> to wire it all up ><. Doing that now
<lifeless> StevenK: rev 18 pushed - should be able to look at it incrementally anytime now
<StevenK> lifeless: r=me
<StevenK> I already voted as approve, so meh
<lifeless> StevenK: thanks!
<lifeless> jamesh: python-oops-wsgi 0.0.3 (in trunk now) should have everything
<jamesh> lifeless: looks good.  Have you guys looked at things like SQL statement logging yet? (or any other data collection mechanism)
<lifeless> jamesh: yes, thats handled via the on_create hooks
<jamesh> adding something to the WSGI environment that could be used to log additional info during the request processing stage could be useful
<lifeless> jamesh: yes. Another way is thread locals, which is how I'd expect storm glue to be done, given storms global variable tracer implementation
<lifeless> jamesh: FWIW lp is now running with on_create hooks for its sql gathering
<jamesh> cool.
<jamesh> there was code for that in wsgi-oops, but it probably doesn't make sense to put storm-specific stuff in python-oops
<lifeless> so tracer -> request_timeline   and in the on_create there is an attach_timeline which grabs the request_timeline (which ends up being a TLS thing) and snarfs it out into th db_statements variable
<lifeless> jamesh: right, that was one of the headaches I had when considering generalising wsgi-oops
<lifeless> jamesh: tarballs of 0.0.3 in lp/pypi and the lp download cache (in a minute)
<jamesh> and soon in the Ubuntu archive? :)
<lifeless> in freeze at the moment
<lifeless> hopefully one this stabilises a little (e.g. some of the key names are noddy) I can talk to pitti about adsorbing some of apport
<lifeless> jamesh: so for instance, to do the 404 thing:
<lifeless> set oops_on_status=['404'] in make_app
<lifeless> and separate
<jamesh> I read the diff.  What you've added looks pretty good.
<lifeless> add to config.filters a callback to decide which 404's you trapped you actually want.
<lifeless> that callback might be generic enough with currying that we can put it in -wsgi
<lifeless> or even (for twisted & zope environments) a common oops-http or even oops itself.
<jamesh> lifeless: for the WSGI case, one issue is that I might not know what oops config the middleware is using.  That is why I was suggesting putting something in the wsgi environment
<lifeless> jamesh: I don't quite follow how you wouldn't know
<jamesh> do you suggest storing the config in a global variable somewhere?
<lifeless> jamesh: perhaps. What bit of code wants to know the config ?
 * jamesh should probably read through the rest of the python-oops code
<lifeless> http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/createhooks.py is the default hooks
<lifeless> and
<lifeless> http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/config.py
<lifeless> is the core event notifier
<jamesh> lifeless: so for example, lets say I want to add the Django user name to my OOPS report.  I create a special Django middleware class to run after the auth middleware and read request.user
<jamesh> where should I stash that so that it makes it into the OOPS report created by python-oops-wsgi?
<lifeless> ok, so we'd want a on_create hook to grab the data from the context
<lifeless> stashing the data in the environment would be the easiest thing there
<jamesh> as an example, if python-oops-wsgi added a "oops.data" value to the wsgi environment as a dictionary that would be merged into the new OOPS, it could be as simple as: request.environ['oops.data']['username'] = request.user.username
<lifeless> def attach_username(report, context): report['username'] = context.get(wsgi_environ, {}).get('django_user', None)
<jamesh> I suppose I could do my own hook for that, but it seems like it could be a useful addition as a general purpose way of collecting data.
<lifeless> sure, i can see that
<lifeless> with the current rfc822 serializer we're quite limited
<lifeless> I really want to nuke that, hopefully oops-tools will be using the interface soon and then we're very close to migrating away
<james_w> def attach_data(report, context): report.update(context.get(wsgi_environ, {}).get('oops.data', {})) :-)
<jamesh> I understand that.  I'm just saying that the wsgi environment is pretty easily available in Django (and is definitely available if you're doing a plain wsgi app)
<jamesh> rather than doing N different collection methods, we might be able to provide one that can be used for many simple cases.
<lifeless> jamesh: yes, I'm in favour of that.
<jamesh> I would be able to rewrite the hacky traceback capture code U1 is using at the moment to work with that kind of API
<jamesh> to work without patched Django
<jamesh> request.environ['oops.data']['exc_info'] = exc_info
<lifeless> we need to decide if it goes into the oops context, or the report directly.
<lifeless> that exc_info example would make sense for going into the context.
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<lifeless> pehraps two variables
<lifeless> oops.report oops.context
<lifeless> include a default hook in install_hooks to copy oops.report verbatim
<lifeless> and do an update of the context from oops.context.
<lifeless> note that the rfc822 serializer drops anything unknown on the floor :( so need to work within that for the mean time - but you probably already are.
<jamesh> again, I haven't read all of your new oops code yet.  I'd probably be a bit more coherent if I had
<lifeless> sure
<lifeless> you're making plenty of sense.
<jamesh> While arbitrary data collection would be nice (and hopefully we can support it with a new report format), I'd be happy with a simple way to collect the standard data from deep in the request
<lifeless> yah
<lifeless> I need to context swtich for a bit
<lifeless> care to file a bug?
<jamesh> sure.
<jamesh> lifeless: filed: https://bugs.launchpad.net/python-oops-wsgi/+bug/832477
<_mup_> Bug #832477: Provide a simple way to capture oops info from deep in the request <python-oops-wsgi:New> < https://launchpad.net/bugs/832477 >
<lifeless> thanks
<lifeless> StevenK: can I bug you for a follow-on ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72649
<LPCIBot> Project db-devel build #819: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/819/
<nigelb> hm, when is next push to production?
<mwhudson> nigelb: wgrant will laugh at you shortly
<mwhudson> nigelb: in seriousness, i think there are quite a stack of revisions due to be deployed
<wgrant> s/laugh/sob/
<wgrant> There's around 60 revisions waiting to be deployed.
<nigelb> mwhudson: hehe, oh QAblocking?
<wgrant> Currently held up by the buildbot slaves being contaminated by some nasty substances.
<nigelb> wow
<lifeless> wgrant: thats worth noting to the list I think
<wgrant> lifeless: I was hoping it would be resolved before EOD.
<wgrant> But if it is not, I might notify the list.
<lifeless> even if it is
<nigelb> Ok, timeto find another bug to work on.
<lifeless> helps folk be aware of what caused grief/headaches
<lifeless> doesn't need to be a -long- message ;)
<nigelb> Subject: Deployment blocked by something nasty on buildbot slaves<EOM>
<nigelb> :D
<LPCIBot> Project devel build #988: STILL FAILING in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/988/
<lifeless> so
<lifeless> txtacfixture
<lifeless> mwhudson: ping
<lifeless> mwhudson: how do you spell 'pick an ephemeral port' for .tac files
<mwhudson> lifeless: specify 0 as the port number maybe?  not sure though
<lifeless> so
<lifeless> and this will make folk weep
<lifeless> in the config we specify 0 as the port
<lifeless> start the service
<lifeless> then rewrite the config with the real port. Win!
<lifeless> + parser to get the ports out of the readyservice handler I guess.
<lifeless> StevenK: hi
<StevenK> lifeless: Hm?
<lifeless> Slightly off-topic, but every time I try to subscribe someone to a bug
<lifeless> report, the first time fails with "() Couldn't get subscriber details
<lifeless> bah
<lifeless> 15:49 < lifeless> StevenK: can I bug you for a follow-on ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72649
<StevenK> lifeless: No. You've reached your branch limit.
<lifeless> 1 is the limit ?
<StevenK> I didn't specify the duration
<lifeless> heh. So are you serious or teasing?
<StevenK> Seriously teasing? :-P
<StevenK> lifeless: No real comments, r=me
<lifeless> thanks!
 * StevenK grumbles at Jenkins faulures
<lifeless> jamesh: ok, so thats in place. I'm going to hold off releasing for a day or two, let you see what else is needed.
<StevenK> lifeless: Oh, did you bump the version, or no point?
<lifeless> StevenK: I didn't
<lifeless> StevenK: waiting for more feedback from jamesh :)
<StevenK> Ah
<wgrant> StevenK: That's interesting. The hg equivalent of those failed with a timeout or something on buildbot this morning.
<StevenK> Interesting
<StevenK> I suspect the only failures we're left with are races or other buggy stuff
<wgrant> Yeah.
<jtv> wallyworld: you're approved.
<wallyworld> jtv: excellent, thanks
<jtv> StevenK: very simple review?  https://code.launchpad.net/~jtv/launchpad/fix-more-utilities/+merge/72666
<StevenK> jtv: I'm concerned about the clonePackages() change
<jtv> Good.
<jtv> StevenK: but taunts aside (sorry), what's the problem with it?
<StevenK> jtv: It seems I had misremembered -- r=me
<StevenK> jtv: Please don't land it yet
<jtv> Thanks.  You were right to be concerned about it, but I think the change I made here isn't the problem.
<jtv> Why not land it?
<StevenK> jtv: Because we have a large amount of revisions to deploy, and wgrant and I would prefer people consider devel "soft-frozen" so we can get into a deployable state.
<jtv> Fair enough.
<wgrant> Let's not try to break the record of 4 interlocked reversions.
<lifeless> so I shouldn't r=me the upgrade to wsgi-oops 0.0.3 ?
<wgrant> Or was it 5.
<lifeless> bah oops-wsgi
<lifeless> cause you know you want me to
<wgrant> yes, after all that testing you did on loggerhead :P
<lifeless> something like that
<StevenK> wgrant: I think 4
* StevenK changed the topic of #launchpad-dev to: devel "soft-frozen" until we're deployable | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<StevenK> wgrant: It looks like DSP.latest_overall_component can die horribly
<wgrant> Hmmm, that is a surprise.
<wgrant> That sort of thing is still used a bit, but apparently not that one.
<StevenK> +0/-8 makes me a little happy
<StevenK> jtv: Tiny MP for you: https://code.launchpad.net/~stevenk/launchpad/lose-dsp-loc/+merge/72676
<StevenK> wgrant: That also removes components from DSP
<wgrant> StevenK: Ah, most stuff uses latest_overall_publication.component.
<wgrant> Amusing.
<StevenK> Haha
<lifeless> so it turns out
<lifeless> our keyserver implementation is much more than we use
<lifeless> it has a human play-with-me interface
<lifeless> which I doubt anyone has used in 3 years
<lifeless> jamesh: I dunno if you've had a chance to look at python-oops-wsgi tip, but if you have feedback is solicted ;)
<jamesh> lifeless: I looked at the merge proposal you attached to the bug report, and it looked pretty good.
<lifeless> cool
<lifeless> jamesh: that djano specific bug, I'm not sure its actionable in python-oops-wsgi, is it ?
<lifeless> like, if upstream reject it and the log hacking route is still needed, that isn't a generic wsgi glue, its django specific
<jamesh> lifeless: probably not, after having investigated it.
<lifeless> how would you feel about marking it invalid in oops-wsgi?
<jamesh> lifeless: and I think we could do equivalent hacks to what we currently do using the oops.report/oops.context extensions.
<jamesh> sure.
<jamesh> unless you want a tracking bug for "python-oops-wsgi should work with django apps"
<jamesh> I'll leave that up to you though.
<lifeless> i think it can do that with the upstream task
<lifeless> uhm
<lifeless> yeah
<lifeless> actioned
<lifeless> jamesh: thanks very much for kicking the tires on this beast
<jtv> StevenK: I'm looking at your reviewâsorry, everybody bothering me at once.
<jtv> StevenK: done
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<mrevell> Morning
<nigelb> Good Morning!
<jtv> adeuring, you may be the best person to deal with this: my experimental interfaces checker found one or two small mismatches in HWDB utilities.
<nigelb> g22
<nigelb> gah
<lifeless> ok, calling it. see you all tomorrow
<bigjools> wgranted (n): to roll back a bad commit
<jtv> adeuring: canonical.launchpad.systemhomes.HWDBApplication does not fully implement lp.hardwaredb.interfaces.hwdb.IHWDBApplication: the title attribute was not provided.
<adeuring> jtv: argh
<lifeless> bigjools: (vt) surely
<jtv> It's not serious, but it is the sort of thing I want to automate checking against.
<adeuring> right, i can look into this
<jtv> (ahem, I'm talking to adeuring here)
<bigjools> lifeless: it's too early to think about verbs and nouns and I've only had one sip of coffee
<lifeless> early hah!
<lifeless> we can talk early at the TL meeting :)
<jtv> adeuring: thanks.  The other one was HWSubmissionDeviceSet.create having too many parameters, but if that was a "self" then I've got a fix in EC2.
<bigjools> 2 hours kip all night, feels like I've not actually been to bed :)
<lifeless> stub: any word on pgbouncer?
<lifeless> bigjools: ugh
<lifeless> bigjools: kids ?
<bigjools> I wish it were but no
<bigjools> medical issues ...
<lifeless> :(
<stub> lifeless: same same. Waiting on the config file rollout, which is really frustrating when I keep seeing these NDT rollouts happening.
<stub> lifeless: Think we need to bump the priority to 90?
<lifeless> I'm not quite there yet.
<lifeless> I will ping mthaddon now - he's said its getting worked on this week
<wgrant> There's still a lot of puppet breakage right now.
<wgrant> Several hosts failed to roll out.
<lifeless> :(
<lifeless> not unexpected tho
<wgrant> No.
<mthaddon> yeah, there's a puppet branch in progress that should fix it
<wgrant> Great, thanks.
<wgrant> Then i guess I should RT the rest of the cronspam.
<StevenK> wgrant: buildbot done, waiting for asuka
<LPCIBot> Project devel build #989: STILL FAILING in 5 hr 26 min: https://lpci.wedontsleep.org/job/devel/989/
<poolie> mrevell: i'm glad the bugs page is going to get some love
<poolie> i wonder if some of the ones you're retagging may be better off with a task-oriented view rather than getting the user to customize them though
<mrevell> poolie, Hey there, at the moment I'm tagging anything that could fall in the scope of our "customisable bug search columns" project, which is coming up next. I'm not sure what you mean by a "task-oriented view". Could you help me understand,please?
<poolie> sure
<poolie> for instance, if i ask about inprogress bugs, the assignee is likely to be relevant
<poolie> if i ask about new bugs, the heat is more likely to be relevant
<poolie> if i ask for bugs sorted by #affected, the #affected is probably interesting
<mrevell> Oh, yes, I see.
<poolie> i don't know if this actually works but istm it is at least indicated by some of the bugs and comments
<poolie> it's a chance to do better than the typical nerdy "you can configure every possible query, why aren't you happy" :)
<poolie> it may be too hard to predict what people want to see
<mrevell> Heh. I like the idea. I think that some user research could come up with some pointers towards what people want to see.
<mrevell> I was the QA CoP sprint for a day last week and it seems they have some  scenarios where they need particular info; they've partially solved that with a Greasemonkey script so far
<jml> were it me, I'd still try to provide the 'customizable columns on advanced search' feature first
<poolie> oh
<poolie> 'by milestone' is especially poignant because it doesn't show you the milestones
<poolie> perhaps adding the generic thing first is better, it's just an idea i was reminded of seeing them go past
<mrevell> jml, Yeah, agreed, poolie's idea seems to me to build on that. A set of canned customisations, almost ... for want of a better way of describing it.
<poolie> configuration plus sensibel defaults
<jml> right
<jml> fwiw, the reason it's been scheduled next is because it was requested by a bunch of stakeholders. it's also the first feature we've had in the feature queue that isn't massive.
<jml> for my part, more than privacy or derived distros or whatever, I think that each week spent on it is another week without, say, a combined issue tracker.
<jml> but maybe it's better to improve the default bug searches
<wgrant> Mmmm, the last two features didn't need to be massive.
<jml> not my place to say, and I don't really have an thought out opinion.
<wgrant> They could have been split into several each.
<wgrant> But I guess they'd been hanging around for three years and needed to be dealt with :/
<wgrant> At least they're nearly done now.
<jml> wgrant: basically, I agree with what you just said. :)
<jml> privacy seems not nearly done, but maybe that's just because project pages aren't being updated.
<wgrant> It's barely started.
<wgrant> But DDs is nearly done sort of maybe.
<jml> 80% done, 80% to go?
<jelmer> poolie: before I forget, are you happy for me to land the import of the other three tools from ubuntu-dev-tools in lptools as well?
<poolie> yes, thanks!
<poolie> i wonder if it ought to be mentioned on u-devel or something
<poolie> or perhaps it can be just handled through dpkg dependencies
<poolie> to make sure people don't see those tools just disappear
<jelmer> poolie: We were going to handle it through dependencies (add a Recommends: lptools)
<poolie> wfm, thanks
<jelmer> we'll need a new upload of lptools to Debian as well though (ubuntu-dev-tools is in Debian)
 * jelmer looks at lifeless
<poolie> don't rely on mail to humans to do what machines can d
<poolie> can i persuade someone to make a release of lp:restfulclient to get the fix for bug 626960 out?
<_mup_> Bug #626960: Collection dictionary access incorrectly folds all HTTP errors to KeyError <lazr.restfulclient:Fix Committed by mbp> <Ubuntu Distributed Development:In Progress by mbp> < https://launchpad.net/bugs/626960 >
<cjwatson> what am I doing wrong to get http://paste.ubuntu.com/673718/ from buildmailman.py?
<cjwatson> lib/lp/services/mailman/monkeypatches/defaults.py exists; lib/canonical/launchpad/mailman/monkeypatches/defaults.py doesn't
<bigjools> cjwatson: you might need to make clean;make
<cjwatson> trying that, thanks
<bigjools> that's guess, don't shoot me if it doesn't work :)
 * cjwatson nods
<mwhudson__> shoot barry instead!
<matsubara> bigjools, hi :-)
<bigjools> matsubara: ok so ""Parent series has sources waiting in its upload queues that match your selection, see help text for more information." means that there's stuff in +queue
<bigjools> the help text doesn't exist - yet :)
<matsubara> bigjools, right. it's in my notes to file a bug about that help text
<bigjools> matsubara: we recently added extra checks to make sure that you cannot init from a series that has builds or binaries in +queue that match the sources you're copying
<matsubara> bigjools, is there any way for me to cancel whatever is in +queue so I can play with the initialization?
<cjwatson> bigjools: excellent, thanks, that seems to have worked
<bigjools> matsubara: check with rvba, he's doing some QA.  Otherwise, pick different packagesets.
<matsubara> ah, so if I choose different sources that those in the +queue, I should be able to initialize?
<bigjools> cjwatson: the Windows approach.....
<matsubara> good. thanks!
<matsubara> bigjools, I don't see anything here: https://qastaging.launchpad.net/testbuntu/foo/+queue. is it another +queue page?
<matsubara> I tried all the filters and they return nothing
<jml> jelmer: great stuff btw.
<bigjools> matsubara: it's the parent's queue
<matsubara> bigjools, ah right. I tried with natty as the parent and the series initialized successfully. thanks!
<bigjools> matsubara: do you understand what is happening?
<matsubara> bigjools, I understood the check, don't know why it's in place though.
<bigjools> matsubara: that's what we'll explain in the help text :)
<matsubara> if the parent has the same packagesets queued, it won't allow derived ones to be initialized with the same packages. is that right?
<matsubara> ah, cool!
<bigjools> matsubara: it's packages that matter, not packagesets
<bigjools> but basically if there's a pending build upload or a build in progress, you can't inherit it
<matsubara> unfortunately I can't see https://qastaging.launchpad.net/ubuntu/oneiric/+queue as it's timing out.
<bigjools> yes that page is a PITA
<matsubara> right. is that because would be a waste of resources to initialize from a old, previously built for that parent series, given that we know there's a new build in progress?
<bigjools> matsubara: not exactly - the problem is that you get complications later because you built your own binaries that will differ from the ones the parent compiled
<matsubara> bigjools, ok. and could we not schedule the initialization to fire automatically after the in progress ones are finished? or this adds too much complexity to the use case?
<bigjools> matsubara: way too much :)
<jelmer> jml: thanks, which stuff? :)
<matsubara> bigjools, :-)
<jml> jelmer: getting rid of lptools stuff from ubuntu-dev-tools
<jelmer> jml: ah
<wgrant> rvba: Will you be able to QA bug #826870 today?
<_mup_> Bug #826870: native syncs from Debian non-free default to Ubuntu universe <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/826870 >
<stub> We reverted bzr to 2.3 ? Looking at the merge conflict stable -> db-devel
<wgrant> stub: I believe 2.4 is still only in db-devel.
<wgrant> For testing on staging.
<jelmer> stub: no, but db-devel has 2.4 for testing
<wgrant> jelmer: ^^
<wgrant> Heh.
<stub> Ta. I'll keep db-devel on 2.4 then.
<rvba> wgrant: for that I would need my changes to make it into db-devel (I need to test that on DF)
<wgrant> rvba: stub should be arranging that as we speak.
<wgrant> rvba: But you can always merge devel on DF.
<jelmer> is there any news on pgbouncer and when staging will be updated?
<wgrant> jelmer: The next staging update is meant to work.
<wgrant> If it hasn't disabled itself due to failures...
<wgrant> Somewhat concerningly, it stopped logging 9 days ago.
<wgrant> stub: Do you know what's going on there?
<wgrant> stub: Doesn't look like it's going to retry, so the sudo access isn't much good.
<wgrant> (looking at https://staging.launchpad.net/successful-updates.txt)
<stub> losa ping: Lock needing to be killed for staging updates to work again?
<rvba> wgrant: *I* cannot since I don't have shell access to DF ;). But I'll QA this as soon as r13769 is included into db-devel then.
<wgrant> rvba: Ah, forgot that detail.
<rvba> wgrant: I'll monitor db-devel and ask you to update DF and restart it when my changes will be db-devel.
<wgrant> rvba: Sure.
<rvba> Thanks.
<cjwatson> Could somebody with access update the EC2 test images (https://dev.launchpad.net/EC2Test/Image)?  There was some discussion about it on #soyuz but it was inconclusive
<StevenK> cjwatson: I've done so
<wgrant> stub: You're not in the access list...
<wgrant> Grar.
<wgrant> StevenK: ^^
<StevenK> cjwatson: I'm waiting for a deployment, and then I'll land my branch that adds me to VALID_AMI_OWNERS
<wgrant> Ah.
<StevenK> (As well as two others)
<StevenK> rvba: Or you could just ask for your branch to merge anyway
<wgrant> DF is currently restarting...
<StevenK> Well, duh. If it's on the deployment report, it's certainly in db-devel
<StevenK> (The duh is at me for being a numpty.)
<wgrant> StevenK: Not necessarily.
<wgrant> StevenK: There was a conflict.
<wgrant> Sitting around for a few hours until stub resolved it a few minutes ago.
<StevenK> Again? That's like the fourth in 2 days.
<wgrant> We haven't merged db-devel for several weeks.
<wgrant> 6.5 weeks, in fact.
<StevenK> The proposal to merge lp:~jtv/launchpad/fix-more-utilities into lp:launchpad has been updated.
<StevenK>     Status: Approved => Merged
<StevenK> JTV!
<StevenK> And he's not here. How convient.
<StevenK> Who can I yell at now? :-(
<wgrant> Meh, it was harmless.
<wgrant> If need be we can kill buildbot.
<wgrant> Again.
<wgrant> rvba: dogfood should have your rev now.
<StevenK> And then gary has 3 revisions of QA.
<StevenK> And bac
<nigelb> Buildbot b0rk is fixed?
<bac> StevenK: mine is easy...doing it now
<StevenK> nigelb: Yes
<nigelb> \o/
<StevenK> gary_poster: O HAI! You haz two lots of QA to do so we can deploy many many lots revisions.
<jelmer> just when I thought I was getting the hang of strine
<StevenK> "many many lots" is from one of the Discworld books
<jelmer> ouch, now I am embarrassed
<StevenK> Where many many lots in this instance is 45 revisions
<rvba> wgrant: Thanks for the heads up.
<jelmer> StevenK: that is indeed quite a few
<gary_poster> StevenK, ack, on it
<rvba> wgrant: I'm trying to QA #826870 andÂ think I need your intervention: I've called """archive.copyPackage(source_name="emacs23-non-dfsg", version="23.3+1-1", from_archive=from_archive, to_pocket='release', to_series=oneiric.name)"""
<_mup_> Bug #826870: native syncs from Debian non-free default to Ubuntu universe <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/826870 >
<rvba> But now I suppose the job needs to run on DF.
<rvba> wgrant: could you please do that for me?
<wgrant> rvba: It's hopefully running now.
<rvba> wgrant: Thank you, I'll see if my package shows up in oneiric's queue.
<wgrant> rvba: Ah, it actually runs automatically every 2 minutes.
<wgrant> Rejected:
<wgrant> emacs23-non-dfsg 23.3+1-1 in wheezy (same version has unpublished binaries in the destination archive for Oneiric, please wait for them to be published before copying)
 * StevenK prepares a bug list
<StevenK> 45 revisions, 2 rollbacks, 31 bugs
<rvba> wgrant: Ok, I'll find another package from non-free.Â Thanks again.
<nigelb> StevenK: *wheee* :)
<StevenK> nigelb: One of them is your four-digit bug closure ...
<nigelb> StevenK: I know! I'm waiting ernestly and patiently to see it marked Fix Released.
<deryck> Morning, all.
<rvba> wgrant: done: qa-ok
<cjwatson> StevenK: the archiveuploader tests all pass for me with dpkg-xz-support and updated launchpad-dependencies, FYI
<StevenK> cjwatson: Excellent.
<cjwatson> I thought that would be the case but had to check ...
<StevenK> Gah!
<StevenK> abentley: QA! You're lucky last.
<abentley> StevenK: take a pill
<StevenK> abentley: I'm perfectly calm. But I'd like to deploy before I go to bed, and that time is fast approaching
<abentley> StevenK: my work day just started, and I am in fact investigating wgrant's QA of my work.
<dobey> any code hosting/reviews masters around? i am seeing a very odd issue that i'm trying to debug. there is a branch proposed for merge into another, but the target thinks it has no proposals.
<deryck> adeuring, ping for standup.
<adeuring> deryck: oops thanks
<deryck> np
<dobey> making it very hard for tarmac to land this branch :(
<abentley> StevenK: qa done.
<matsubara> abentley, that's bug 829460
<_mup_> Bug #829460: TypeError: object of type 'NoneType' has no len() loading qastaging oops report <OOPS Tools:Triaged by matsubara> < https://launchpad.net/bugs/829460 >
<StevenK> abentley: Thanks!
<abentley> matsubara: okay.
<matsubara> abentley, I'll try to get that fixed this week.
<matsubara> bigjools, does the series initialization process needs a script to run to successfully complete?
<matsubara> bigjools, on qastaging I mean
<jam> benji: are you around? (I'm not sure what your regular work schedule is)
<benji> jam: yep, I'm here
<jam> benji: just wondering if you worked out some of the loggerhead stuff or not.
<jam> it sounds like it got put on the back burner
<jam> but I figured I could try to help out
<benji> I'm working on it now.  I may have some questions in a couple of minutes.
<benji> jam: when I try to push with a specified port number I get a connection refused: http://paste.ubuntu.com/673831/
<benji> but when I remove the port number I get a password prompt but the user's LP password doesn't work
<jam> benji: are you running raw on your machine, not in a vm, etc?
<jam> benji: well you probably have openssh running on your machine
<jam> so it makes sense that you can get a password prompt
<benji> jam: it's in a VM
<benji> ah, I forgot that bzr+ssh runs over the normal ssh port
<jam> benji: then 'localhost' doesn't make sense, or are you running that in the VM as well
<benji> jam: I am
<jam> but certainly the VM is running openssh, or you wouldn't be connected
<benji> to clarify: I'm running these commands in a shell on the VM
<jam> right
<bigjools> matsubara: yes
<bigjools> matsubara: we're not running the DD scripts on staging yet until the new hardware arrives
<jam> benji: so you have to use "bzr+ssh://user@127.0.0.88:5022"
<jam> it doesn't bind to all addresses
<jam> http://bazaar.launchpad.net/+branch/launchpad/view/head:/configs/development/launchpad-lazr.conf
<jam> 'localhost' usually resolves to 127.0.0.1 I think
<matsubara> bigjools, can you run them for me? Or it can't be run on the current hardware?
<jam> I set up an ssh config alias, and forgot about it
<benji> jam: progress!  It's complaining about not having an ssh key now, I'll add my public key to the user I'm using
<jam> right
<benji> jam: hmm: http://paste.ubuntu.com/673840/
<jam> progress
<jam> sort of
<jam> what command are you running to run the host?
<jam> (to run launchpad + codehosting)
<jam> In the past, I've seen that failure when the Twisted ssh service is running, but the LPForkingService is not
<jam> I think "make run_codehosting" should be enough, though.
<wgrant> benji: I found that the forking socket is sometimes left around. rm /var/tmp/launchpad_forking_service.sock and make run_codehosting again
<wgrant> benji: You can also use 'utilities/make-lp-user $yourusername' to create a user with the name and your SSH key.
<benji> wgrant: killing the socket and restarting worked!
 * benji needs to write this down somewhere.
<wgrant> benji: The service will fail to create it if it already exists.
<wgrant> I guess it should try to remove it.
<bigjools> matsubara: I can't run them personally, you need to poke a losa
<bigjools> matsubara: this one will init the new series: cronscripts/run_jobs.py -vv initializedistroseries
<benji> jam (or wgrant): now when I visit http://bazaar.launchpad.dev/~name16/+junk/1/files I get redirected to https://launchpad.dev/
<matsubara> bigjools, will do. thanks!
<benji> oh, maybe I need to kick off a branch scan
<jam> benji: try bazaar.launchpad.dev:8080 (still in the VM)?
<matsubara> bigjools, how long should it take approximately?
<wgrant> benji: Restart apache.
<jam> benji: shouldn't need a scan for loggerhead
<bigjools> matsubara: how many packages did you copy?
<wgrant> benji: branch-rewrite probably isn't running (it's a LP script run by apache, yeah, a bit evil)
<benji> jam: adding the port worked (no I generally run my browser on my host, not the VM)
<matsubara> bigjools, I initialized 2 series, both derived from Natty, one with the core package set and the second only with the kernel. the first series is set to copies the packages while the second to rebuild the packages
<benji> wgrant: thanks, I'll try that
<jam> benji: If you run :8080 it goes directly to the loggerhead process. Apache proxies it
<bigjools> matsubara: should be quick-ish, probably 15-30m
<benji> jam: gotcha
<matsubara> bigjools, great! thank you
<wgrant> bigjools: That's almost /Quotes worthy.
<benji> the apache restart got the proxying working
<benji> jam: thanks much; now I just need to reproduce the original race and then verify that my branch fixes it
<bigjools> wgrant: /me waving hand around furiously
<jam> benji: right. So if you have the original code, "make run_codehosting" and load something that is 'slow' in 2 browser windows should work
<jam> The key, is that after the *first* request succeeds, generally you have no more lazy-import objects around
<benji> "slow"?
<benji> oh, it doesn't have to be a loggerhead request per se?
<jam> benji: it needs to be a request on loggerhead, such that you get 2 of them at the same tim.
<jam> time
<benji> k
<jam> so the first time a loggerhead instance comes up, it gets > 1 request immediately
<jam> well, I should say
<jam> whenever it gets 1 request, there is already a second request.
<jam> (the first request)
<benji> jam: hmm, I'm having trouble getting an exception; I have http://bazaar.launchpad.dev:8080/~name16/+junk/1/files loaded in five tabs, I stop and restart codehosting, and tell firefox to reload all tabs; all of them load fine and there are no errors reported on stdout
<benji> I'm trying now with ab doing 10 concurrent requests.
<henninge> deryck, abentley: bad news, the problem already existed in my last branch, so it will break js on some pages but I don't know how badly.
<wgrant> henninge: Should the rollout be aborted?
<henninge> wgrant: oh, are we having a roll-out?
<abentley> henninge: oh dear.
<deryck> henninge, "the problem" ?  What is the problem?  And yeah, should we abort and do a rollback?
<henninge> I thought that was held off
<wgrant> henninge: It is in progress.
<wgrant> We've been holding off for a week now :)
<henninge> wgrant: let me check how bad the breakage is.
<deryck> henninge, what is the problem exactly?
<deryck> henninge, not including the mockio from testing?
<henninge> importing from app/testing
<henninge> it is, yes
<wgrant> henninge: If it is rollout-blocking-critical, you need to revert it now.
<wgrant> We have already got two reverts and 50 revisions in the pipeline; we cannot afford to risk a fix.
<wgrant> And also poke someone to abort the rollout :)
<henninge> wgrant: np, nothing depends on it.
<deryck> henninge, yeah, what wgrant said :)  abort the rollout, revert, and land it correctly.
<wgrant> Don't land it correctly until we are safely rolled out and confirmed good.
<henninge> wgrant: it hadn't started yet.
<wgrant> Ah, good.
<wgrant> Anyway, you have 90 minutes to land the revert.
<wgrant> Before the next buildbot run.
* wgrant changed the topic of #launchpad-dev to: please avoid landing things before we've rolled out -- qa is a mess right now | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<deryck> wgrant, I don't follow why we should avoid landing things?  not arguing, just not sure I see what not landing gets us.
<wgrant> deryck: Landing gets us into this situation.
<wgrant> We now have three chained rollbacks, making around 55 revisions undeployable.
<deryck> wgrant, how does a new rev get us into this?  marking qa-ok when it's not gets us into this, no?
<wgrant> deryck: If there is another bad rev in there, and people land stuff before we can detect and roll it back, we can then not deploy until all those new revisions are QAed, and we have to hope they are not bad.
<wgrant> The last three times this has happened this week, one of those revisions has been bad.
<wgrant> So we end up in a chain of non-deployability, and have to deploy a week of work in a very risky and difficult to roll back operation.
<wgrant> That is, we now have: ... bad revision a ... bad revision b ... rollback a ... bad revision c ... rollback b ... rollback c
<wgrant> Nothing between bad revision a and rollback c can be deployed.
 * deryck is thinking
<wgrant> Basically, we need a more thorough, quicker test suite, so QA is less important and able to be done more quickly.
<deryck> wgrant, I don't think saying "stop landing things" is the right way to fix this.  if we feel it's serious enough to stop landings, then we should block the builders merging to stable while we sort it out.
<deryck> wgrant, and completely agree we need a quicker test suite :)
<wgrant> It's half-past midnight and I'm not sure I can be bothered walking a LOSA through reconfiguring PQM.
<wgrant> But I also don't want to break the rollback record.
<wgrant> We currently have more than 6 days of work blocked.
<wgrant> By the time this is fixed, it'll be 7.
<wgrant> Any more breakage that lands in the meantime will take it over 8.
<wgrant> And large deployments have a very bad track record of reliability.
<deryck> wgrant, I take the seriousness of it.  I don't think changing the topic here is the way to fix it.  I'll start a thread on the launchpad-dev list taking up the issue there if that's cool with you.
<wgrant> Sure.
<deryck> wgrant, cool.  thanks for the chat about it.
<wgrant> Reconfiguring PQM is heavyweight and awkward, so I am reluctant to do it.
<deryck> completely understand.
* deryck changed the topic of #launchpad-dev to: deployment is a mess right now, be cautious or avoid landings until fixed | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<benji> jam: ok, I think I'm now able to reproduce the race, but I'd like to make sure this 500 is the one I'm looking for, where does loggerhead log errors?
<dobey> deryck: congratulations. i choose you! there seems to be an issue with merge proposals, and private branches?
<deryck> dobey, ok, rockstar is also telling me something similar.
<rockstar> dobey,  I'm already chatting with deryck about it.
<rockstar> :)
<wgrant> Possibly r13716
<deryck> I wonder if our aborted rollout is somehow to blame, or a bad landing.
<wgrant> If it was a regression just today.
<wgrant> We deploy 13715-13727 today.
<wgrant> deployed
<rockstar> Well, I don't know if it's a regression just for today.
<rockstar> At some point, we did have a test that covered this situation.
<dobey> i am pretty sure it's a regression just for today
<dobey> at least, today is when i get people asking me about it :)
<rockstar> Yeah, today is also when we noticed (it breaks tarmac's ability to find things to land)
<wgrant> danilo_: ^^
<deryck> wgrant, and is the rollback of r13716 in the stuff we aborted?
<deryck> wgrant, or no one knows r13716 is bad?
<deryck> I'm guessing this is new, just looking at qa pages and bzr logs.
<wgrant> deryck: 13716 is not known to be bad, but is very relevant.
<deryck> I understand now.  Thanks, wgrant.
<wgrant> It was deployed today, and alters the MP privacy code.
<deryck> gotcha,
<wgrant> Woo, #4/
<wgrant> Going for the record.
<deryck> abentley, it seems merge proposals and private branches have an issue now.  see scrollback.  Can you take this issue, open an incident report, and start tracking down what's going on?
<wgrant> It would be excellent if it was diagnosed and rolled back in the next 60 minutes :)
<wgrant> But it is 1am, so I should really leave again.
<abentley> deryck: looking...
<deryck> wgrant, go sleep. :) we got it.
<deryck> abentley, thanks!
<wgrant> Thanks abentley, deryck.
 * wgrant sleeps.
<sinzui> mrevell, I fell off IRC and you may have thought I was off this week
<mrevell> sinzui, Company calendar says you are :)
<sinzui> yuck
<sinzui> I am pretty sure I am off next week
<henninge> abentley: what was it that I had to do to keep the rollback-revision from removing my stuff next time I merge devel?
<henninge> is it bzr revert --forget-merges ?
<abentley> henninge: merge the revision immediately before the rollback; commit; merge the rollback revision, do "bzr revert ."; commit.
<henninge> oh, the ".", right.
<henninge> abentley: thanks
<abentley> henninge: np
<abentley> deryck: this preloading stuff is not my fortÃ©.
<deryck> abentley, so we need a db/preloading expert to jump in here?
<abentley> deryck: that would help, yes.  Also, we could use a test that used to pass, but fails now.
<deryck> abentley, I would have recommended allenap help, but he is afk.
 * deryck looks around more....
<mrevell> sinzui, otp just now, ping you in a mo
<sinzui> okay
<abentley> rockstar: can you give me an idea what test I need to write to detect this issue?
<deryck> abentley, yeah, let's pursue that angle, i.e. finding a test to confirm, and I'll look at the suspect rev more closely with you here in a second.
<dobey> abentley: we have merge proposals that are generally fine, except the target doesn't think it has any merges proposed for it. and this seems to only affect private branches.
<rockstar> abentley, it appears that a private branch doesn't have any landing candidates even though there are merge proposals.
<abentley> rockstar: do we know whether all users are affected, or just Tarmac?
<rockstar> abentley, it appears that even the website is affected.
<rockstar> So you can look at the Branch Merges section of a branch page and see that they are missing.
<abentley> rockstar: okay, so it sounds like the view check is broken, then
<mrevell> sinzui, Are you available to talk now?
<sinzui> yes
<bac> hi bigjools, would you have a moment for a preimp call about a build recipe bug?
<bigjools> bac: I am not an expert on recipes but I can try
<bac> bigjools: i'm looking at bug 828914
<_mup_> Bug #828914: +request-daily-build oops with an AttributeError: 'NoneType' object has no attribute 'published_archives' <oops> <recipe> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/828914 >
<bac> bigjools: skype?
<bigjools> yup
<bigjools> or I am already on mumble
<bac> i haven't used mumble in a while and may take some setup
<bigjools> ok
<deryck> abentley, did you start and incident report yet?
<deryck> s/and/an/
<abentley> deryck: no.
<deryck> abentley, I'll start one and update topics.
<mtaylor> any of you guys run wiki.ubuntu.org?
* deryck changed the topic of #launchpad-dev to: deployment is a mess right now, be cautious or avoid landings until fixed; abentley looking into issues with merge proposals and private branches | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<mtaylor> and/or have any idea how they integrated it with login.ubnutu.com?
<deryck> mtaylor, no, not us.  maybe ask in #ubuntu-devel?
<beuno> mtaylor, it's a moin open id plugin
<beuno> https://launchpad.net/moin-openid
<deryck> abentley, I started https://wiki.canonical.com/IncidentReports/2011-08-24-LP-merge-proposals-and-private-branches
<deryck> abentley, it's a skeleton, but I'll fill in what we know now.
<mtaylor> beuno: thanks!
<mtaylor> beuno: wow. that's so not open source :)
<beuno> mtaylor, it is AFAIK
 * beuno looks
<abentley> deryck, rockstar: does this test look like it would pass if the error is fixed? http://pastebin.ubuntu.com/673926/
<beuno> hm
<beuno> flacoste, ping. The moin-openid page says you have the task of looking to open sourcing
<beuno> any ideas on where that's stalled?
<flacoste> beuno: really!!?!
<flacoste> beuno: i don't know, that's now owned by ISD, I'd ask maris or stuartm
<beuno> flacoste, that's what this says in the comment: https://launchpad.net/moin-openid
<deryck> abentley, as I understand the problem, yes, I think that's good.  I'll wait on rockstar to say for sure, though.
<beuno> thanks flacoste, I'll chase them
<abentley> deryck: I've gone back 400 revisions and it's not passing.
<beuno> mtaylor, it seems we're not using that anymore, the plugin is now in upstream as of moin 1.9
<deryck> abentley, hmmm, that doesn't sound good then.  can't be correct.
<mtaylor> beuno: oh neat!
<abentley> rockstar: are you using getMergeProposals or landing_candidates?
<beuno> mtaylor, if you run into problems integrating into login.u.c, you can head over to #canonical-isd
<rockstar> abentley, landing_candidates
<abentley> rockstar: okay, I think the problem is that landing_candidates should be the same as getMergeProposals, but is not.
<rockstar> abentley, yeah, I was thinking they were.
<abentley> rockstar: or rather, it was not, but now is, and getMergeProposals has always been broken.
<rockstar> abentley, does that also explain why the merge proposals aren't listed on the page?
<abentley> rockstar: dunno what that page uses.
<rockstar> Oh, I guess that would explain it.
<deryck> rockstar, abentley -- are we certain the web version is broken and not just an api/tarmac thing?
<rockstar> deryck, I am, yeah.  That's what made me escalate.  dobey pointed it out when we were debugging.
<deryck> ok
<abentley> rockstar, deryck: I rolled-back 13716 and the landing_candidates version of my test passed.
<deryck> abentley, ok, cool.  so let's land a rollback of that and update the corresponding bug.
<abentley> deryck: we could, but I think the fix is a one-liner.
<deryck> abentley, hmmmm
<deryck> abentley, here's why I'm hesitant.....
<deryck> abentley, the deploy has already been delayed a lot.  I worry this fix either blocks the deploy another day or doesn't make it in the deploy, and then is 2 days out from being deployed.
<deryck> so I wonder if the straight rollback isn't easier to get this fixed quicker.  we can easily hold the deploy for one more rollback, I think.
<abentley> deryck: Here's the fix: http://pastebin.ubuntu.com/673945/
<abentley> deryck: A rollback would affect the other work, too.
<deryck> abentley, yeah, true.
<abentley> deryck: But if you prefer, I'll do the rollback.
<deryck> abentley, land the real fix.  let's make sure we understand from rockstar how to easily qa this when it lands, so we don't lose time waiting on qa for it.
<rockstar> deryck, abentley, I bet the easiest way to QA it would be checking to see if a private branch's page has merge proposals in the Branch Merges section, when it really does have merge proposals.
<abentley> rockstar: probably.  At this point, I haven't confirmed that.
<deryck> abentley, so I need to step away for 5 minutes, sorry.  but I'm fine to go ahead with landing the proper fix.
<abentley> deryck: ack.
<adeuring> abentley: fancy a lazr.batchnav review? https://code.launchpad.net/~adeuring/lazr.batchnavigator/slicing-error-for-too-short-last-backwards-batch/+merge/72745
<abentley> adeuring: handing an incident.
<adeuring> ah, ok
 * adeuring needs to learn to read the channel topic more carefully
<adeuring> StevenK: are you up for a review? https://code.launchpad.net/~adeuring/lazr.batchnavigator/slicing-error-for-too-short-last-backwards-batch/+merge/72745
<abentley> rockstar: is there a bug?
<abentley> rockstar: I mean has the bug been reported?
<nigelb> mrevell: Congrats!
<mrevell> Hey thanks nigelb :) I still have the bug on my to-do list :)
<nigelb> mrevell: sure, I've been busy well, so I didn't want to poke you and not have time myself :)
<rockstar> abentley, no.
<deryck> abentley, are you filing a bug for the incident?
<abentley> deryck: did: bug 833147
<_mup_> Bug #833147: landing_candidates does not show proposals for private branches <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/833147 >
<deryck> abentley, cool.  added the regression tag, just to help with the tracking of this sort of thing.
<abentley> deryck: also updated incident report.
<deryck> abentley, thanks!  I'll handle all the successes and problems sections, and make sure it's all complete.
<abentley> deryck: The fix landed as r13779
<deryck> ok, cool.
<nigelb> mrevell: Oh, btw, for that bug. I was thinking if we could have a heading in there. Helps a lot!
<mrevell> nigelb, Could you add that as a comment please?
<nigelb> sure, still needs  userting though.
<Ursinha> mrevell: \o/
<mrevell> :)
<mtaylor> any losas around, we've been waiting on a bug import for a while... https://answers.launchpad.net/launchpad/+question/168463
<nigelb> mrevell: also, ironically, I'm not subscribed to the bug ^-^
<abentley> deryck: I am going on lunch.
<deryck> abentley, cool.  Thanks for taking care of that this morning!
<abentley> deryck: you're welcome.
* deryck changed the topic of #launchpad-dev to: deployment is a mess right now, be cautious or avoid landings until fixed | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256
<james_w> congratulations mrevell
<LPCIBot> Project devel build #990: STILL FAILING in 5 hr 59 min: https://lpci.wedontsleep.org/job/devel/990/
* abentley changed the topic of #launchpad-dev to: deployment is a mess right now, be cautious or avoid landings until fixed | https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 238 - 0:[#######=]:256
<mrevell> thanks james_w :)
<LPCIBot> Project db-devel build #820: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/db-devel/820/
<lifeless> *yawn*
<lifeless> jelmer: hi; don't look at me for updating lp-tools in debian, EWAYTOOBUSY just now :(
<lifeless> jelmer: you can add yourself to uploaders though :)
<nigelb> lifeless: is it hard to fix bug 520413?
<_mup_> Bug #520413: All changes by user must be revertable <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/520413 >
<nigelb> well, at least the bits that you mentioned in there.
<lifeless> nigelb: glad you qualified it :)
<nigelb> hiding the comments by a user when their account is disabled
<lifeless> nigelb: so, as tom berger said there are few journals of changes within Launchpad
<lifeless> there may be enough for *bugs* in particular with the bugactivity log.
<lifeless> I think its a multi-part issue
<nigelb> lifeless: no no, I'm only looking at your comment, not my bug :)
<lifeless> oh
<lifeless> easy
<lifeless> minimally - and perhaps too minimal (might not get past 'is it a good idea' :P) just check the authors status as part of querying for bug comments to show
<nigelb> hmm, can I *try* to do it? :)
<lifeless> thats probably too minimal because folk that were legitimate users of LP may well get suspend when only a few of their artifacts are a problem.
<reed> hello folks
<bac> matsubara: OOPS-2062AZ69 shows a past week count of 13.  can you tell me the ids for those related OOPS?
<lifeless> hi reed
<nigelb> lifeless: hm, this means introducing a new field into the db along with deactive.
<nigelb> deactive and hide interacation.
<nigelb> or some such
<lifeless> nigelb: less minimal, extend the account status/standing enum to have 'dude was a spammer' and exclude that status specifically - and then if we believe a user was nothing but a spambot we set it to that, so less automatic but also less false-positives
<nigelb> this involves doing a db migration.
<lifeless> nigelb: I don't believe it needs a new field. its entangled with being inactive.
<reed> wondering if you've evaluated integrating this zope3 based http://www.groupserver.org/groupserver/ into LP
<nigelb> a new state rather
<nigelb> hm, intereting.
<nigelb> *interesting
<nigelb> I should dig into the code to figure out if I can even read the bits that are relevant
<lifeless> nigelb: so it needs: teach the code about the new enum value but don't set it
<lifeless> nigelb: then once thats deployed add code to set it.
<nigelb> ooo, so change the display bits first
<nigelb> and then change the enum bits.
<nigelb> do one in devel and one in db-devel?
<lifeless> nigelb: close enough :) - change the things that -read- the enum first. Land. Deploy. Then change the things that -set- it.
<lifeless> nigelb: otherwise you have a race condition where the new value could be read by old code that does not expect it.
<nigelb> Right, makes sense :)
<lifeless> reed: I don't believe anyone has looked at it
<reed> thanks lifeless... now my next question is: where can I find the roadmap for the LP mailing list future development?
<lifeless> reed: it looks like 50-60% overlap with our existing code, but direct assumptions about layout and schema that would make running it as an integrated service non trivial
<lifeless> reed: things that are planned in the short term are at dev.launchpad.net/LEP
<lifeless> reed: things that are far enough out that noone is directly planning when they will work on them just live as bugs
<lifeless> reed: https://bugs.launchpad.net/launchpad/+bugs?field.tag=mailing-lists
<reed> got it ...  thank you
<lifeless> reed: also zope 5 - aieeee.
<jelmer> lifeless: g'morning
<jelmer> We seem to get almost 24 hour coverage with just .au and .nz alone..
<lifeless> well, .nz is +12 ;)
<nigelb> I see lifeless almost every hour that I glance in here :P
<nigelb> Or wgrant.
<bigjools> did you not know that they are bots?
<nigelb> controlled by each other? :P
<matsubara> bac, <Oops: OOPS-2056DQ6>, <Oops: OOPS-2056AU7>, <Oops: OOPS-2056E8>, <Oops: OOPS-2056F11>, <Oops: OOPS-2056DZ13>, <Oops: OOPS-2056EC14>, <Oops: OOPS-2056N16>, <Oops: OOPS-2055D50>, <Oops: OOPS-2055H38>, <Oops: OOPS-2055N31>, <Oops: OOPS-2062AZ69>, <Oops: OOPS-2062O68>, <Oops: OOPS-2062DR81>
<bac> matsubara: thanks!
<matsubara> you're welcome
<jelmer> lifeless: wrt lptools; thanks, I know you're busy. Happy to add do an upload myself though.
<mtaylor> reed: I see you've met our friend lifeless
<reed> mtaylor: that sentence is sooo meta ...
<mtaylor> reed: I'm good like that
<reed> meeting lifeless friend
<mtaylor> lifeless: reed is working with me over in openstack-land
<reed> hi lifeless, i'm the new community manager
<lifeless> cool
<lifeless> mtaylor: reed: I'm just OTP at the moment, you'll have my attention soon
<reed> lifeless: no worries, nothing urgent
<lifeless> mtaylor: reed: ok, am here :)
<nigelb> qastaging.lp.net timesout
<nigelb> and suggets I visit the homepage
<nigelb> which of course, is qastating.lp.net, which what timed out in the first place!
<nigelb> recursion ftw.
<deryck> jcsackett, ping
<jcsackett> deryck: pong.
<deryck> jcsackett, hey hey.  where are we at with qa for r13774, "Updates dsp vocab to use the dsp in db in the search query." ?
<jcsackett> oh, we're done and i forgot to update the bug. :-P
<jcsackett> one sec.
<deryck> jcsackett, oh happy day, thanks!
<jcsackett> deryck: updated. report should reflect it shortly. :-)
<deryck> jcsackett, rockin!  Thanks man!
<deryck> jcsackett, you're not blocking yet.  but soon would have been.
<abentley> statik: Just figured out an easier way to access a remote launchpad instance.  Use ssh's built-in SOCKS proxy (ssh -D 8080) and then set your browser to use that proxy.  Assuming you have the standard mappings of lp.dev to 127.* in your /etc/hosts.
<statik> abentley: thanks!
<mtaylor> lifeless: I think reed was wanting to poke about better mailing list archives
<deryck> Later on, everyone.
* abentley changed the topic of #launchpad-dev to: deployment is a mess right now, be cautious or avoid landings until fixed | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256
<lifeless> mtaylor: sure would love that :)
<lifeless> reed: mtaylor: for that, I would look at - https://dev.launchpad.net/ArchitectureGuide/ServicesRoadmap
 * reed reading
<lifeless> reed: mtaylor: specificxally <https://dev.launchpad.net/ArchitectureGuide/ServicesRoadmap#mhonarc (the lists.launchpad.net UI)>
<reed> lifeless: read that ... any plans to include reply and post via web UI?
<lifeless> reed: none so far but actually it should be very easy.
<lifeless> reed: step 1) implement that refactoring above; step 2)  add reply/post buttons on the now-live web pages
<lifeless> you could do step 2 directly with cross-domain links back into LP itself
<lifeless> if step 2 is particularly urgent
<reed> the basic need is to give users the possibility to pick their fav system between mlist or forum
<lifeless> ok
<lifeless> there are many differences between email and forums
<lifeless> do you want to reconcile all of them, or just provide a web UI to the mailing list ?
<reed> well... a mlist with a great looking web UI to post/reply would be good enough
<reed> I don't like forums particularly, never found one that was pleasant to hang around but I see the value for casual, non committed users
<reed> gmane.org does a decent job (the ui needs work though)
<wgrant> Morning.
<wgrant> Are we up to #5 yet?
<wgrant> No, but qastaging is screwed.
 * wgrant sighs.
<wgrant> Oh, buildbot is broken.
<wgrant> Yay
<wgrant> And has been since 2 hours after I went to bed.
<lifeless> wgrant: we're up to 7 I believe.
<wgrant> Sadly only 4.
<wgrant> With one very hairy bit of QA in the middle.
<wgrant> Hmm.
<wgrant> buildbot was broken, but the deployment report is the really broken thing.
<wgrant> qastaging is on 13779, deployment report still 13775
<wgrant> Hasn't updated in 2 hours.
<wgrant> lifeless: Can you investigate, please?
<lifeless> is staging down ?
<wgrant> That doesn't normally affect the stable report.
<wgrant> And no.
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
<lifeless> INFO:qa-tagger:Last revision now is 13779.
<wgrant> WELL
<wgrant> This is amusing.
<lifeless> wgrant: looks fine to me
<wgrant> Wed Aug 24 22:28:40 UTC 2011 Finished updating code
<lifeless> Last revision deployed to QAStaging is 13779. There are 35 revisions waiting in the queue.
<wgrant> Thankyou, qastaging, for that absolutely perfect timing :)
<wgrant> Argh, no --rollback.
<wgrant> Ah, but production wasn't reverted, so qa-tagger will happily ignore that.
<wgrant> Yay, green.
<LPCIBot> Project devel build #991: STILL FAILING in 5 hr 20 min: https://lpci.wedontsleep.org/job/devel/991/
<lifeless> reed: sorry I went quiet on you
<reed> lifeless: np, I think I know what I needed to know
<lifeless> reed: we'd be delighted to support sensible reply-in-the-web, and anything making the archives nicer would be great.
<lifeless> reed: we have no specific work queued in this area but its all fairly straight forward if someone wants to patch it.
<reed> lifeless: at the moment I don't know what resources I have, i'll let you know though
<lifeless> of course
<lifeless> if you or someone you know wants to work on it, we will mentor
<lifeless> nigelb here has been doing patches recently, with great success ;)
<reed> tnx
<lifeless> mtaylor: interesting mail on ppas
<mtaylor> lifeless: it seems to have stirred up a few shitstorms
<lifeless> indeed
<lifeless> btw
<mtaylor> lifeless: especially where I perhaps wasn't clear enough on the "I think PPAs are amazing" front
<lifeless> If you want callbacks from PPAs, I know whats involved ;)
<mtaylor> lifeless: hehe.
<lifeless> oh oh
<mtaylor> lifeless: well, I _do_ want callbacks - but I also want synchronous runs and streaming output :)
<lifeless> mtaylor: new toy you might like - lp:python-oops / lp:python-oops-wsgi
<mtaylor> ooh. /me goes to look
<lifeless> mtaylor: we have the latter, the former you're already escalated in priority
<mtaylor> lifeless: you have streaming output in my jenkins?
<lifeless> mtaylor: no, we have (slightly jerky) 'streaming' in LP build logs :)
<mtaylor> hehe
<lifeless> thats a shallow fruit to tune FWIW
 * lifeless mixes metaphors
 * mtaylor tunes fruit. picks a seed out from his muffler
<mtaylor> lifeless: I think the main points that are harder to handle are "I need to be able to build packages for debian in a way similar to ppas" (the hard one) and "I'd really like to get things more integrated in to my CI system" (doable, but definitely some dev work- especially with no java launchpad api)
<mtaylor> lifeless: callbacks would make #2 doable - but jenkins isn't really good at the wait and respond to async events for job completion thing ... and jenkins url triggers are COMPLETELY broken when openid SSO mode is enabled (sigh)
<mtaylor> but then we'd still be stuck on #1
<lifeless> so url trigger fixing is a bug :)
<lifeless> uhm
<lifeless> debian is technically doable.
<lifeless> One way you could do it that avoids any political aspects would be a custom LP instance just for debian builds
<lifeless> same API
<lifeless> etc
<wgrant> You could take the well-separated Soyuz and run it for Debian PPAs.
<wgrant> There's already an LP instance for Debian PPAs.
<lifeless> mtaylor: ^
<StevenK> Or you could submit patches? :-)
<lifeless> well
<StevenK> Although, PPAs for multiple distributions is going to break a LOT
<lifeless> its not clear that we *would* build for Debian. But that is a whole-different-discussion.
<wgrant> StevenK: Only two bits need changing.
<wgrant> StevenK: The activate form and URLs.
<wgrant> Everything else works.
<mtaylor> it is a whole different discussion, most of the time I've brought it up over the last 2 years it's been met with "no"
<wgrant> The issue is mostly builder time.
<wgrant> I believe.
<StevenK> Is deployment still a mess?
<LPCIBot> Project db-devel build #821: STILL FAILING in 5 hr 29 min: https://lpci.wedontsleep.org/job/db-devel/821/
<wgrant> We hope not, but maybe.
<wgrant> We'll see in a couple of hours when the deployment is done and tested.
<StevenK> wgrant: Did you have a branch to move the updating into DSPC?
<wgrant> They are approved.
<StevenK> I'm guessing they're both used? :-/
<wgrant> DSPCÂ² are both used slightly, yes.
<StevenK> Used slightly? How slightly?
<wgrant> DistributionSourcePackageCache is used for package searches, DistroSeriesPackageCache for searches and some DSBP and DSPR properties.
<wgrant> Both are also used to create the package counts for PPAs, but that is easily fixed.
<StevenK> I looks like DistributionSourcePackageCache might be the easiest to remove
<wgrant> Right, it can probably be replaced by the new DSP or whatever we end up with.
<wgrant> DistroSeriesPackageCache is a little harder.
<StevenK> Bah, I was hoping to just remove DistributionSourcePackageCache :-)
<lifeless> please do
<lifeless> its implicated in some seriously poor performing queries.
<lifeless> of course, you need to get replacement queries as fast first.
<wgrant> lifeless: Are you sure? It's only ever used in package searches on Distribution.
<lifeless> wgrant: bug 816870
<wgrant> Well, unless you count the 20h update-pkgcache.py as a poor performing query.
<_mup_> Bug #816870: Distribution:+search (package search) timeouts <Launchpad itself:Triaged> < https://launchpad.net/bugs/816870 >
<wgrant> Hah.
#launchpad-dev 2011-08-25
<lifeless> wgrant: and bug 739051
<_mup_> Bug #739051: Product:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739051 >
<wgrant> Blah, yes, but that should die.
<lifeless> wgrant: you asked if I was sure.
<lifeless> wgrant: 4% or so of our timeouts-by-pageid involve this table :)
<StevenK> wgrant: Still not clear how the new DSP should look
<wgrant> Oh good, I don't even have to update the topic.
<wgrant> Because 10 bugs have been filed, and 10 fixed.
<StevenK> But deployment is still a mess? :-)
<wgrant> Until we have no complaints for two hours, yes.
<StevenK> I can't land branches! Does that count?
<wgrant> :(
<lifeless> we can freeze landings to devel if needed
<mtaylor> lifeless: is there anything I can currently watch to see if if new packages have landed in a ppa?
<wgrant> mtaylor: getPublishedSources and getPublishedBinaries
<lifeless> mtaylor: e.g. see bzr-builder 's --watch option
<lifeless> mtaylor: which may still be in a branch if james_w hasn't merged it yet.
<mtaylor> sweet
<lifeless> I need a buildout hand
<lifeless> I have a project which I want to build its own interpreter for, I don't want it importable by lp.
<lifeless> how do I tell lp's buildout to -literally- shell out and buildout that subproject rather than recursing into it and its dependencies
<wgrant> lifeless: Probably the 'develop' option.
<lifeless> nope
<wgrant> Really?
<wgrant> Huh.
<lifeless> that symlinks the develop egg in
<lifeless> so that you can import the thing
<lifeless> without it having a versioned egg
<mtaylor> lifeless: please tell me you're building a stackless interpreter because you need to
<lifeless> mtaylor: I'm not building one; sorry.
<mtaylor> lifeless: DAMN
<lifeless> mtaylor: I hear that $language de jour will save the world.
<lifeless> wgrant: look at the tip of lp:python-gpgfixtures
<mtaylor> lifeless: yup
<wgrant> Uhoh, plural? This can't be good.
<wgrant> lifeless: LP needs to be able to upload too.
<lifeless> wgrant: you might think that.
<wgrant> We generate keys.
<wgrant> And upload them to keyservers.
<wgrant> That needs testing.
<lifeless> indeed
<lifeless> I will not reduce test coverage with what I do.
<lifeless> wgrant: the implications of that statement may terrify you. And rightly so.
<wgrant> I am wondering what your plan is.
<lifeless> ah
<lifeless> there is one use of /pks/add in the test suite
<wgrant> Not just the test suite.
<wgrant> Production code does it too.
<lifeless> I know prod does it
<lifeless> it looked untested to me
<wgrant> Ah
<lifeless> see the commented out calls to generateSigningKey, fo rinstance.
<wgrant> Ahaha lovely.
<lifeless> and the other ones that say 'no key is generated cause we reuse here...'
<lifeless> There is one more though, which appears to genuinely exist.
<lifeless> but we don't test the error path.
<lifeless> so I'll need to add enough glue to pull out the key fingerprint and id and shove them in /keys.
<lifeless> but most of our code can diaf
<wgrant> Yep.
<wgrant> The difficult bit is working out the fingerprint, as you say.
<lifeless> there is a gpg parser on pypi
<lifeless> but I'll just use a gnupghomefixture for the lifetime of the request + a mutex to avoid os.environ race conditions
<LPCIBot> Project db-devel build #822: STILL FAILING in 1 min 53 sec: https://lpci.wedontsleep.org/job/db-devel/822/
<mtaylor> lifeless: I haz made patch. simple one-liner with no recipe does what I want now
<mtaylor> lifeless: thanks for pointing out the obvious :)
<LPCIBot> Project db-devel build #823: STILL FAILING in 0.57 sec: https://lpci.wedontsleep.org/job/db-devel/823/
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256
<StevenK> OH! I can land stuff now?
<wgrant> 3 hours, OOPS levels around normal, no complaints.
<wgrant> Go wild.
 * StevenK lands 3 branches in 80 seconds.
<StevenK> buildbot gave up waiting after the third and started, strangely enough
<wgrant> 35 of our 305 tables are unused or only used by a small bit of unimportant code :(
<StevenK> Can we remove some of them?
<wgrant> Yeah.
<wgrant> Once we have fastdowntime I'll do it.
<wgrant> ALthough some of them have ancient data that we should archive.
<wgrant> Probably.
<stub> wgrant: Which tables are you looking at?
<wgrant> stub: http://paste.ubuntu.com/674281/
<wgrant> stub: The top list is either entirely unused or only used by person merges.
<wgrant> The bottom three are used by things that shouldn't exist any more.
<wgrant> And each require deleting like 10 lines of code.
<StevenK> Didn't we utterly remove bounties?
<stub> The tables have never been purged
<stub> wgrant: Nothing there requires archiving.
<stub> (that hasn't already been archived, like shipit)
<wgrant> k
<wgrant> Once we have fastdowntime I will do the honours.
<wgrant> Drop foreign keys in one downtime, then remove the merge code, then do away with the tables.
<StevenK> wgrant: staticdiff has a *lot* of code associated with it
<wgrant> Grar.
<wgrant> Except we can't actually drop them with slony, can we?
<wgrant> StevenK: It's mostly unused.
<wgrant> StevenK: It was for review diffs, but they are dead now.
<wgrant> StevenK: It is the hardest of the list to remove, though, right.
<StevenK> wgrant: I was told by lifeless to not remove stuff related to that.
<wgrant> StevenK: That was incrementaldiff.
<StevenK> They aren't related?
<StevenK> If they aren't, what's the difference?
<wgrant> There are three types of MP diffs.
<wgrant> staticdiffs (review diffs), previewdiffs (preview diffs), and incrementaldiffs (incremental diffs)
<wgrant> incrementaldiffs are incremental.
<wgrant> staticdiffs were from back when you had to run mad to update MP diffs. LP would generate the staticdiff, and it would never change.
<wgrant> previewdiffs were what mad generated -- they could update.
<StevenK> Can you expand 'mad' ?
<wgrant> But now LP updates previewdiffs itself, and I don't believe staticdiffs are used.
<wgrant> mad = Merge Analysis Daemon
<StevenK> Oh
<wgrant> lp:mad
<StevenK> Sounds hideous
<wgrant> Yes.
<StevenK> Right, so I will look at ripping out the use of staticdiff
<wgrant> No, it's not in scope :)
<wgrant> launchpad_dogfood=# SELECT MAX(date_created) FROM branchmergeproposal WHERE review_diff IS NOT NULL;
<wgrant>             max
<wgrant> ----------------------------
<wgrant>  2010-01-27 08:16:31.060926
<StevenK> I'm either blocked on FDT for SPPH-SPN denorm, or working out how to hell to reimplement DSP?
<wgrant> StevenK: Have you got the garbo jobs and indices sorted out?
<StevenK> For denorm? Yes
<wgrant> fdt is probably not going to happen this week.
<StevenK> I can't do anything at all with them until the patch lands
<StevenK> The branches are up, thanks to the magic of sync-pipeline
<wgrant> StevenK: Ah, I saw they were still in Next and assumed they weren't implemented.
<StevenK> wgrant: Yes, because I don't want to utterly take over Coding single-handedly when I'm blocked by FDT
<StevenK> wgrant: So, I can either remove staticdiff, or we can argue about DSP.
<StevenK> Personally, the former sounds a little more fun
<wgrant> We need to sort out DSP in the next week or so.
<StevenK> Except I'm on holidays next week ...
<wgrant> Ah, forgot that bit.
<wgrant> And so is Curtis.
<StevenK> Yes.
<wgrant> So I guess we won't be pushing the in-progress stuff too hard.
<StevenK> wgrant: So, which of the two do you to tackle?
<StevenK> wgrant: Do you want to have a friendly argument about DSP?
<wgrant> StevenK: Do you have a list of uses of DSP and DSPID?
<StevenK> I do
<StevenK> The only thing that's stopped me writing stuff up is a name for the new hotness
<wgrant> Hm, pad.ubuntu.com looks sadly UDS-specific.
<StevenK> -> tea
<wgrant> StevenK: http://pad.ubuntu.com/cWLmLex2tc
<wgrant> StevenK: Where a caller is listed for something, that is all of the callers.
<wgrant> (apart from the maintenance methods, which are moving onto the classes themselves in ec2 now)
<nigelb> oooh, we deployed. Nice :)
<StevenK> wgrant: I don't have a list of callers, but I suspect they are numerable
<wgrant> nigelb: Yup. Your code works, too!
<StevenK> wgrant: Added my notes
<nigelb> \o/
<wgrant> nigelb: Got any more 4 digit bug fixes?
<nigelb> wgrant: If they're relatively easy to fix, I'm interested.
<wgrant> That doesn't sound like an adequate sense of adventure.
<nigelb> THat's making sure I can fix them in a lifetime.
<nigelb> Let me see if I can get into top-5 list in this week.
<nigelb> 5 more bugs to fix to get there.
<wgrant> Just two more merges, IIRC.
<wgrant> 1 more will bring you to equal 5th place.
<nigelb> ooh. 2 more. Interesting.
<wgrant> Sadly, 127 more are required to bring you to 1st place.
<nigelb> Yeah.
<nigelb> That's hard, but not undoable.
<nigelb> A fix per week for 2+ years.
<nigelb> hmm, what needs to be done for bug 50661
<_mup_> Bug #50661: Magic words in comments (e.g. bug NNNN) should be documented <docs> <easy> <lp-web> <ui> <Launchpad itself:Triaged by matthew.revell> < https://launchpad.net/bugs/50661 >
<nigelb> I could just take stuff documented in one of the doctests that I boke.
<nigelb> *broke
<StevenK> wgrant: Where's this list of top-5?
<nigelb> https://dev.launchpad.net/Contributions
<StevenK> Ah, nice
<nigelb> woah, bug 811028 is easy? Lies!
<_mup_> Bug #811028: Time frame 'a moment ago' incorrectly concatenated  to 'on' <easy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/811028 >
<StevenK> Bleh
<wgrant> sinzui fixed something like that for questions in the last deployment.
<StevenK> Yeah, looks like I missed a spot
<StevenK> That's registration of product etc, isn't it?
<wgrant> It says bug.
<wgrant> But bugs are fine.
<wgrant> I think...
<nigelb> bah.
<wgrant> Oh, it uses fmt:displaydate.
<StevenK> And bugs say 'Reported by ...'
<wgrant>     def displaydate(self):
<wgrant>         delta = abs(self._now() - self._datetime)
<wgrant>         if delta > timedelta(1, 0, 0):
<wgrant>             # far in the past or future, display the date
<wgrant>             return 'on ' + self.date()
<wgrant>         return self.approximatedate()
<StevenK> Right
<lifeless> stub: are you actually here, or just caffeinating ?
<stub> I'm here
<StevenK> approximatedate() returns a moment ago for =< 10
<lifeless> care to have a brief catchup now ?
<nigelb> wgrant: that means its fixed, right?
<stub> lifeless: sure
 * stub fires up skype
<wgrant> nigelb: Not necessarily.
<wgrant> Should test...
<nigelb> I hope qastaging doesn't timeout for me again.
<lifeless> bwahaha
<nigelb> well, in the first 5 tries.
<wgrant> Reported by William Grant a moment ago
<nigelb> hah
<StevenK> Looks fine to me
<wgrant> Registered a moment ago by William Grant
<wgrant> Projects are fine too.
<nigelb> what else? blueprints and answers?
<StevenK> Uploads?
<lifeless> commits ?
<wgrant> Asked by William Grant a moment ago
<wgrant> Questions are fine now too.
<lifeless> wgrant: add support pushed
<wgrant> Registered by William Grant on a moment ago
<StevenK> lifeless: I seriously doubt commits make use of approximatedate
<wgrant> Blueprints are bad.
<StevenK> Text?
<lifeless> wgrant: supports more keys which I think real keyservers do too :P
<nigelb> ah, blueprints are broken, yes.
<StevenK> Can haz paste?
<lifeless> wgrant: in general, or in principle?
<wgrant> nigelb: Want to clarify that in the bug and fix?
<wgrant> lifeless: Heh.
<StevenK> In this case
<nigelb> Registered by Nigel Babu on a moment ago
<nigelb> wgrant: yup, fixing in a bit.
<StevenK> That might be what the reporter actually meant
<wgrant> I presume so.
<wgrant> It's the only object I've found that uses that dext.
<nigelb> Possibly, blueprints is the unloved child.
<wgrant> Projects use "Registered", but put the name at the end.
<nigelb> I should careful that I don't end up owning it with 5 of my 6 fixes in blueprint I think.
<StevenK> Bwahah
<nigelb> *be careful
<StevenK> wgrant is going to not like me.
<StevenK> % bzr di | diffstat -s
<StevenK>  14 files changed, 11 insertions(+), 335 deletions(-)
<nigelb> did you remove more tests?
<wgrant> StevenK: StaticDiff?
<StevenK> wgrant: Yah
<wgrant> StevenK: What did you do with the review_diff fkey on BMP? a few things still seemed to use it.
<wgrant> I'm not sure they used it for anything.
<wgrant> But they used it.
<StevenK> I binned it
<wgrant> Ah, it was just constructors.
<wgrant> Easier than I expected.
<StevenK> I have missed stuff, though
<StevenK> Right
<StevenK> Now to fish around in sampledata
<nigelb> Hrm, need to learn to read configure.zcml better.
<StevenK> nigelb: Don't. Your eyes will bleed.
<StevenK> wgrant: The only I can't work out what to do with is lib/lp/codehosting/tests/test_jobs.py
<nigelb> StevenK: I'm submitting MP's to LP, one should assume that they've already started bleeding.
<StevenK> nigelb: But XML means the wounds can not be cauterised
<nigelb> heh
<nigelb> so, I see tal:content="context/bug/datecreated/fmt:displaydate"
<nigelb> where do I look to see the code behind it?
<wgrant> StevenK: Erm. It looks like RevisionMailJobs use StaticDiff, but apparently they don't stay around in the DB...
<nigelb> or rather, how do I figure out where to look.
<wgrant> In fact, they never hit the DB.
<StevenK> wgrant: That's disappointing
<wgrant> nigelb: lib/lp/app/browser/tales.py
<nigelb> ooh, thanks
<wgrant> StevenK: Nothing has been added to the table since January last year, as expected. But it looks like RevisionMailJobs should be calling StaticDiff.acquire, which instantiates and returns a StaticDiff.
<wgrant> And StaticDiff inherits SQLBase, so that should automatically add it to the DB.
<StevenK> Perhaps the commit gets dropped
<wgrant> The sequence should still be incremented, though, right?
<wgrant> Unless it gets reset on DF.
<StevenK> wgrant: So I wonder if I we should fix RMJ to use previewdiff?
 * nigelb is gettign "chmod: changing permissions of `/var/tmp/bazaar.launchpad.dev/rewrite.log': Operation not permitted"
<wgrant> nigelb: Apache creates that sometimes, so it ends up owned by root or www-data.
<wgrant> nigelb: sudo chown it.
<nigelb> wgrant: chown to my user or apache user?
<wgrant> nigelb: Yours.
<nigelb> ah
<StevenK> It even calls transaction.commit()! WTF
<wgrant> StevenK: Yes.
<wgrant> It makes very little sense.
<wgrant> Instantiating a StaticDiff must not add it to the store.
<wgrant> (the commit is necessary because the diff is stored in the librarian)
<StevenK> Ah, I bet that is the issue
<StevenK> It isn't added to the store
<wgrant> SQLBase does that automatically, normally.
<wgrant> >>> from lp.code.model.diff import StaticDiff
<wgrant> >>> StaticDiff()
<wgrant> <StaticDiff at 0x8382410>
<wgrant> >>> transaction.commit()
<wgrant> Traceback (most recent call last):
<wgrant> IntegrityError: null value in column "from_revision_id" violates not-null constraint
<nigelb> gah, I broke it. I can't read tal.
<StevenK> Ah. No wonder I can't find it. My branch removes it.
<nigelb> can someone spare a few minutes to explain how this works? I think I have no clue what I'm doing.
<StevenK> nigelb: Pastebin your diff
<StevenK> nigelb: bzr di | utilites/paste # if your friend
<nigelb> StevenK: I don't have a diff
<nigelb> because I don't know what to diff on.
<nigelb> :(
 * nigelb pastbin's broken diff
<nigelb> http://pastebin.ubuntu.com/674302/
<nigelb> I brain-deadly pasted what works for answers. Which I now realize is wrong.
<wgrant> Erm, that was from answers?
<nigelb> yeah
<wgrant> +        tal:attributes="title context/bug/datecreated/fmt:datetime"
<wgrant> bug?
<nigelb> baaah
<wgrant> I wonder if sinzui stole that from Bugs.
<nigelb> no
<nigelb> my bad
<nigelb> messed up paste :|
<wgrant> StevenK: Ha ha ha.
<nigelb> oh lol
<nigelb> Now I have on 10 minutes ago
<StevenK> wgrant: Hm?
<nigelb> Okay, so current diff http://pastebin.ubuntu.com/674304/
<wgrant> StevenK: http://paste.ubuntu.com/
<wgrant> Er.
<wgrant> Bah, wants a name.
<wgrant> Nasty creature.
<wgrant> http://paste.ubuntu.com/674305/
<wgrant> Note that it ran a REVISIONS_ADDED_MAIL job, not a REVISION_MAIL job.
<wgrant> I wonder if REVISION_MAIL is unused.
<wgrant> Code seems to be full of dead code.
<wgrant> Oh dear.
<wgrant> StevenK: lib/lp/codehosting/scanner/email.py +55
<wgrant> StevenK: If it's not an initial scan, it uses REVISIONS_ADDED_MAIL
<wgrant> StevenK: If it is an initial scan, it uses REVISION_MAIL, but disables diff generation.
<StevenK> Haha
<wgrant> So I think all that code is actually unused.
<wgrant> But grepping harder.
<wgrant> All the callsites I can see set perform_diff=False.
<wgrant> And we've seen there have been none in the DB for more than 18 months.
<wgrant> I think we can be fairly confident it's dead, but we should check with Aaron.
<StevenK> wgrant: http://pastebin.ubuntu.com/674308/
<wgrant> StevenK: Care to remove perform_diff from RevisionMailJob, delete that remaining test, and send it off to ec2 test?
<wgrant> Note that we can't drop the table yet.
<wgrant> But do revoke perms.
<wgrant> So, test_jobs.py can be deleted.
<StevenK>  17 files changed, 12 insertions(+), 415 deletions(-)
<wgrant> All the revno/diff handling from RevisionMailJob can go.
<StevenK> Even revno?
<wgrant> The only revnos passed in are 'removed' and 'initial'. The int stuff can go.
<wgrant> So drop the if/else in create(), drop the perform_diff argument, and delete most of getMailer.
<StevenK> Already done
<wgrant> Just passing None as diff_text instead.
<StevenK> Done that too
<wgrant> Does that leave BranchDiffJob unused/
<nigelb> StevenK: got a chance to look at the diff?
<wgrant> Seems to.
<StevenK> No, it is still RMJ's parent, and it calls .getMetadata
<wgrant> StevenK: RMJ has no cause to use it any more.
<StevenK> Oh, the update can probably DIAF too
<wgrant> StevenK: Since it's not generating diffs, it doesn't need the metadata.
<wgrant> It has no revno any more, remember.
<StevenK> """A Job that calculates the a diff related to a Branch."""
<nigelb> ok, so what's the difference beteen tal:attributes and tal:content?
 * StevenK smirks
<wgrant> Heh.
<StevenK> Not any more it don't.
<wgrant> nigelb: tal:content sets the value inside the element. attributes sets attributes on it.
<StevenK> wgrant: """A Job that sends a mail for an initial scan of a Branch."""
<wgrant> StevenK: Or scans where revisions are removed.
<nigelb> hah. Nailed it!
<StevenK> ... for a scan of a Branch
 * nigelb wonders how many tests he broke
<wgrant> nigelb: <a tal:attributes="href context/owner/fmt:link" tal:content="context/owner/displayname" /> will turn into <a href="/~wgrant">William Grant</a>
<nigelb> wgrant: AH!
<nigelb> okay, now I understand what the code in answerws is doing
<nigelb> Except for this bit
<wgrant> tal:replace replaces the element entirely.
<nigelb>         <span
<nigelb>           tal:attributes="title context/datecreated/fmt:datetime"
<nigelb>           tal:content="context/datecreated/fmt:displaydate">2005-10-05</span>
<wgrant> So '<a tal:attributes="href context/owner/fmt:link" tal:replace="context/owner/displayname" />' just turns into 'William Grant'
<nigelb> what is that 2005-10-05 doing there?
<wgrant> nigelb: That's just a default value. If, say, someone views the template in a web browser directly.
<wgrant> tal:content replaces any existing content.
<nigelb> ah, that gets replaced by tal:content
<nigelb> ok, I understand this beast better.
<wgrant> StevenK: Up to -500 yet?
<nigelb> Also, if I do a "bin/test lp.blueprints" does it run doctests as well?
<StevenK> nigelb: It probably will, yes
<wgrant> nigelb: Probably.
<wgrant> nigelb: Some are a bit special.
<wgrant> But I think it should get all the blueprint ones.
<nigelb> I'll let the special ones be caught by ec2 land.
<StevenK> wgrant: No, sadly.
<wgrant> StevenK: Pick random lines of code to delete until you meet the quota.
<StevenK> Bwahah
<nigelb> heh
<nigelb> rm -r blueprints will get you a long way and make wgrant a happy man.
<StevenK>  19 files changed, 31 insertions(+), 483 deletions(-)
<StevenK> But the diff is 1,000 lines
<nigelb> find 7 more lines to delete?
<StevenK> That's only 490! FAIL
<nigelb> bah, 17 more!
<StevenK> Math fail
<nigelb> ok, not test failure in blueprints.
 * nigelb proposes MP
<StevenK> steven@liquified:~/launchpad/lp-branches/no-more-staticdiff% bzr log -r -1.. | tail -n 1
<StevenK>   Consign StaticDiff and all that supported it to a watery grave.
<wgrant> bzr log --line -r-1
<nigelb> hm, why does make lint error out...
<nigelb> bzr: ERROR: unknown command "pipes"
<nigelb> am I missing a bzr plugin?
<StevenK> You are
<wgrant> It should work OK without it, though.
<StevenK> wgrant: Beh
<StevenK> wgrant: That doesn't quite work
<StevenK> % bzr log -r-1 --line
<StevenK> 13780: Steve Kowalik 2011-08-25 Consign StaticDiff and all that supported it...
<wgrant> Bah.
<StevenK> cjwatson: You should just need to merge devel into your xz branch and get it re-tossed at ec2
 * wgrant does that locally.
<StevenK> I hope the image works
<nigelb> lifeless: Could you review? https://code.launchpad.net/~nigelbabu/launchpad/811028-time-frame/+merge/72831
<nigelb> I wonder if he's OTP
<wgrant> Or EOD.
<wgrant> Given that he starts at 0645 on Thursdays.
<nigelb> ooh.
<nigelb> wgrant: Could spare a few minutes to review in that case?
<wgrant> nigelb: Do you know what existing tests there are for this?
<nigelb> wgrant: No, I don't
<nigelb> I ran the tests for blueprints and none seem to have failed
<wgrant> It would be nice to add one to check that it doesn't say "on a moment ago"
<nigelb> hm, use factory? ;)
<nigelb> :)
<wgrant> Yeah. Create a blueprint using the factory, then render the view and check that text.
<nigelb> okay
<nigelb> I may need help for some part of it, but let me get there.
<wgrant> Sure.
<wgrant> It will be short, and good practice :)
<nigelb> How do I check if a certain content exists in a view?
<nigelb> I've done this before but I now forget.
<wgrant> html = create_initialized_view(someobj, '+index')()
<wgrant> self.assertIn('some string', html)
<StevenK> And self.assertNotIn()
<StevenK> And branch just got tossed out of ec2 in the make stage
 * StevenK pouts
<wgrant> What happened?
<StevenK> Disagreement between the code and ZCML, I think
 * StevenK will look when he gets home
<nigelb> StevenK: are you not working from home?
<nigelb> co-working place?
<nigelb> wgrant: added test and pushed
<wgrant> nigelb: That test will only fail if html is a substring of 'on a moment ago', which doesn't seem hugely likely.
<wgrant> I'd do this:
<nigelb> actually, GAH
<nigelb> It will never fail.
<wgrant> You should probably use extract_text.
<nigelb> because I just realized the span's title attribute will be the time_stamp
<wgrant> Otherwise you'll get the <span> and stuff, yeah.
<wgrant> extract_text() will remove all that.
<nigelb> ah, ok
<wgrant> self.assertIn("a moment ago", extracted_text)
<wgrant> self.assertNotIn("on a moment ago", extracted_text)
<wgrant> Maybe.
<wgrant> Possibly better to use extract_text and then assertTextMatchesExpressionIgnoreWhitespace, though.
<wgrant> Since there are newlines in the string.
<nigelb> okay
<wgrant> cjwatson: Your branch seems to be in ec2 happily enough.
<wgrant> Hopefully for the last time.
<nigelb> whats the false test for assertTextMatchesExpressionIgnoreWhitespace?
<wgrant> There isn't one. So I'd just test the whole "Registered by Foo Bar a moment ago" string.
<nigelb> mm, so create a person too?
<wgrant> self.factory.makeSpecification(registrant=self.factory.makePerson(displayname="Some Person"))
<wgrant> Or something like that.
<nigelb> okay
<adeuring> good morning
<nigelb> hm, where does extract_text live?
<nigelb> nvm, found it
<mrevell> Mornin'
<wgrant> Morning mrevell, and congrats!
<nigelb> Morning mrevell
<mrevell> Thanks :)
<nigelb> wgrant: the assertTextMatchesExpressionIgnoreWhitespace does not work.
<wgrant> nigelb: :( why not?
<wgrant> Apart from having an obscene name.
<nigelb> Says, not found
<wgrant> Have you printed it out to see what it really looks like?
<nigelb> Can I manually add the /n and test with AssertIn instead?
<nigelb> I don't know what assertTextMatchesExpressionIgnoreWhitespace looks like but I now know what the output of extracted_text looks like.
<wgrant> lib/lp/testing/__init__.py has that method.
<nigelb> oh.
<nigelb> regular expression
 * nigelb lunches
<bigjools> morning
<cjwatson> wgrant: I can dream.  Thanks.
<wgrant> cjwatson: (it failed due to probable AWS breakage, but is back in again)
<wgrant> No, AWS being flaky again. Can't connect to the second instance.
<wgrant> Yay
<lifeless> nigelb: partly EOD partly debugging a u1 pqm issue with spm, partly cooking dinner
<lifeless> nigelb: you might prefer assertThat(foo, DocTestMatches(bar))
<wgrant> Ah, forgot about that one.
<lifeless> optionally with ,ELLIPSIS in the doctestmatches constructor
<wgrant> I wish the API didn't encourage putting everything on the model objects.
<jml> wgrant: +1
<wgrant> I guess it's not really lazr.restful.
<wgrant> We can expose *Set perfectly well.
<wgrant> But security has to be done manually.
<wgrant> Maybe we want a custom zope.security checker to make that sort of thing easier.
<wgrant> Decorate methods with the context argument and permission, or something.
<jml> wgrant: well, I also think that *Set objects are mostly a waste of time too.
<wgrant> jml: Mostly.
<wgrant> The security benefits are just about nil, so I tend to just try to sneak static methods through reviews nowadays..
<wgrant> Or even functions.
<wgrant> Zope seems to treat Python like Java :(
<jml> functions.... wuuuu....
 * jml likes functions
<jml> the utility stuff might be useful for cases where you want to sub out a utility for something that has the same interface
<wgrant> But API methods need to be on a *Set or model object, and people lean to putting stuff on model objects, which means you end up with Distribution having more than 200 lines of imports from every LP package.
<nigelb> lifeless: ah, thanks :)
<jml> but I don't see us doing it aynwhere
<jml> wgrant: yeah. makes it hard to separate stuff.
<wgrant> Rather than having, say, getPendingAcceptancePPAs on ArchiveSet, where it belongs.
<jml> although sometimes it seems as if lifeless says that it ought to be like that
<jml> grumbles about special type-based checking for PPAs aside
<wgrant> Heh.
<wgrant> I think lifeless is mainly against arbitrary divisions and siloization.
<wgrant> This is just proper layering.
<wgrant> And separation.
<nigelb> wgrant: doing the DocTestMatches compares it to the HTML directly.
<nigelb> should I be doing a extract_text before that?
<wgrant> nigelb: Probably, yeah.
<wgrant> Most doctests use extract_text if there are spans and stuff involved.
<nigelb> I knew this bug fix was way too easy.
<nigelb> Hence the tests are challenging.
<wgrant> You learn how to do them after a while.
<wgrant> Well, you learn where to look and how to grep for similar ones.
<wgrant> Then you look at how they do it :)
<wgrant> And try to work out whether they are best practice from now, or worst practice from 2005.
<nigelb> heh
<bigjools> SoupMatcher FTW
<bigjools> grep for it
<wgrant> Or I guess lazr.restful adapter support would solve lots of this as well.
<wgrant> lifeless: Any reason gpgfixtures can't replace zeca tomorrow?
<nigelb> bigjools: no results.
<nigelb> I only looked in lib/lp though.
 * bigjools finds example
<wgrant> nigelb: soupmatchers
<wgrant> It's a module.
<wgrant> containing various matchers like Tag, HTMLContains
<bigjools> nigelb: look here: lib/lp/soyuz/browser/tests/test_publishing.py
<bigjools> grep soupmatchers
<nigelb> hah, I grepped for SoupMatcher
<bigjools> also look in lib/lp/registry/browser/tests/test_distroseriesdifference_views.py
<bigjools> nigelb: sorry, my bad
<nigelb> :)
<nigelb> How evil is line 26 in https://code.launchpad.net/~nigelbabu/launchpad/811028-time-frame/+merge/72831
<bigjools> fairly
<nigelb> sigh, I gussed as much
<nigelb> bigjools: I can't use soup matcher because I need to extract the text.
<bigjools> you could use DocTestMatches if whitespace is not a concern
<nigelb> whitespace isn't a concern
<bigjools> soup matcher extracts text
<nigelb> maybe I should look up how doctestmatches is used.
<bigjools> you just need to grab the right tag
<bigjools> some tests use a div with an id just for that
<nigelb> hmm
<wgrant> In this case you can hopefully just pick out the registering slot.
<nigelb> but I get the fugly span bits
<nigelb> which I don't want
<wgrant> With soupmatcher?
<bigjools> soupmatchers is powerful but the syntax is a bit awkward
<nigelb> wait, soupmatches solves the fugly span problem too?
 * nigelb tries
<bigjools> if the text is all in that tag, yes
<nigelb> Its sadly, not.
<nigelb> which is why I wrote that evil code
<bigjools> ah
<bigjools> I'd go for DocTestMatches then
<bigjools> http://readthedocs.org/docs/testtools/en/latest/for-test-authors.html#matchers
<wgrant> If you use extract_text, then you shouldn't need ELLIPSIS.
<wgrant> Just a default DocTestMatches should do.
<bigjools> yup
<nigelb> doctests returns everything one below the other
<nigelb> *doctestmatches
<nigelb> isn't that similar to simply using extract_text?
<bigjools> use both
<nigelb> Ah.
<bigjools> it solves your nasty use of \n
<nigelb> :D
<wgrant> Because doctests are... slightly liberal with whitespace.
<wgrant> (hi gina)
<bigjools> grrr
<nigelb> gina?
<bigjools> I fixed that recently
<bigjools> gina is the archive importer
<nigelb> ah
<LPCIBot> Project devel build #992: STILL FAILING in 6 hr 5 min: https://lpci.wedontsleep.org/job/devel/992/
<nigelb> I.. I'm confused.
<nigelb> http://paste.ubuntu.com/674407/
<nigelb> I'm doing things wrong, but I can't figure out what's right.
<jml> nigelb: other way around
<jml> nigelb: assertThat(extract_html(thing), DocTestMatches("... foo ...", doctest.ELLIPSIS))
<jml> also probably doctest.ELLIPSIS | doctest.NDIFF
<nigelb> ah
<jml> nigelb: as a rule, assertThat(observed, Matches(expected))
<LPCIBot> Project db-devel build #824: STILL FAILING in 6 hr 5 min: https://lpci.wedontsleep.org/job/db-devel/824/
<nigelb> jml: I'm still doing something wrong. The test is failing with http://paste.ubuntu.com/674413/
<jml> nigelb: well, yeah, but now it's failing *properly*
<nigelb> haha
<wgrant> Unless you extract the registering slot using BeautifulSoup, you'll need to wrap your match string in ellipsis.
<nigelb> I couldn't parse that.
<wgrant> Append and prepend '...' to your match string.
<nigelb> ah
<lifeless> wgrant: jml: yes, siloisation -1, layering +1.
<nigelb> argh!http://paste.ubuntu.com/674417/
 * nigelb fails at seeing what's going wrong.
<jelmer> anybody up for a review of a small refactoring?
<wgrant> It does default to NORMALISE_WHITESPACE, doesn't it?
<nigelb> wgrant: ok, got it. I should have just followed the instructions on the testtools manual ^-^
<nigelb> wgrant: commited and pushed, could you review? :)
<jml> wgrant: I don't think so, actually.
<jml> wgrant: have been tempted to add a version that has normalize, ellipsis & report_ndiff as standard
<nigelb> jml: It does't, I had to add that.
<wgrant> nigelb: That test looks much better, thanks! Just two tiny things left.
<wgrant> nigelb: Your find_tag_by_id and extract_text imports are around the wrong way; they should be sorted alphabetically.
<wgrant> And test_time_frame is probably not a great test name.
<wgrant> test_registration_date_displayed, possibly.
<nigelb> okay, fixing
<nigelb> Fixed!
<wgrant> nigelb: Sorry, one further thing I missed: the testtools import is in the LP section, but it should be in the third-party library section (with lazr.*)
<wgrant> Apart from that, looks ready for ec2.
<lifeless> wgas for gpgfixtures, I have a branch using the homedir fixture, not the keyserver itself yet
<lifeless> wgrant: ^
<lifeless> wgrant: *as for...
<wgrant> lifeless: Aha.
<lifeless> wgrant: I probably won't finish the migration, but it should be a superset of the facilities we need now.
<wgrant> I may look at that in your absence.
<lifeless> the main thing will be finding tests that assume the server is pre-seeded with all keys and have them seed it with the keys they need
<wgrant> Yep.
<lifeless> using the json api
<wgrant> A good thing to do anyway.
<lifeless> wwhat else
<lifeless> oh, we need a fixture to either a) bring up the server in the test process as a thread or b) bring it up as a child process and read-back the port its on; either way shove that into the live config
<lifeless> shallow stuff
<wgrant> I think we're going to need to rework lazr.config soon.
<lifeless> nn
<wgrant> Night.
<nigelb> wgrant: done
<wgrant> nigelb: approved. Should I send it off to ec2?
<nigelb> wgrant: yes, please :)
<wgrant> nigelb: Could you set a commit message on the MP?
<nigelb> set
<wgrant> nigelb: Instance starting.
<nigelb> okay, I'll watch my email ~4 hours from now
<wgrant> nigelb: AWS has been a bit flaky this evening, so it might fail, but we'll see.
<nigelb> oh, ouch. okay.
<wgrant> I've had two instances not start, another one not be connectable, and two die with block device errors.
<nigelb> ah, aws b0rks?
<wgrant> I can only assume.
<nigelb> lol. I deal with it everyday at day job :)
<nigelb> we had one instance disappear taking all the data with it.
<nigelb> It was a backup instance, but got everyone jolted awake ^-^
<wgrant> The instance has started, at least.
<nigelb> what region?
<wgrant> nigelb: us-east
<nigelb> hehe, same as us :D
<nigelb> bigjools: My dislike for bling and shiny is one of the reasons I haven't upgraded :D
<nigelb> Xubuntu is probably where I'm headed when I upgrade
<jelmer> wgrant: hmm, deployment hasn't happened to the code importds?
<jelmer> It's a bit confusing that the related bugs are still marked as fixreleased
<wgrant> jelmer: It should have.
<wgrant> But I saw the failures, and wondered when you'd ask me :P
<wgrant> mthaddon: Could you confirm that the importds are in nodowntime and running the latest rev?
<wgrant> hloeung said they were, but it seems not.
<nigelb> At UDS, I saw this guy in a Launchpad T-shirt and asked him  "Are you a Launchpad guy? Could you help us?
<nigelb>  and proceeded to ask something about blueprints API
<nigelb> Later, I realized that was flacoste :)
<wgrant> Haha
<mthaddon> wgrant: they're running 13697 and are in ndt
<wgrant> Erm.
<wgrant> ndt is 13779 :/
<mthaddon> interesting...
<wgrant> Rather!
<mthaddon> I'll update them now, suspect this is because one of the importd servers (galapagos) is dead and hadn't been removed from the list
<jtv> Anyone else getting a failure in test_versioninfo, caused by revno being a string instead of an int?
<wgrant> Yeah.
<bigjools> nigelb: luddite!
<wgrant> I thought the deployment was a bit quick today.
<wgrant> mthaddon: Is it easy enough to check the rest of ndt?
<mthaddon> wgrant: yep, will do once that's finished
<mthaddon> wgrant: also I think we should add a step at the end of NDT to confirm revnos on all the servers we've deployed to (I'll do that)
<nigelb> bigjools: I prefer stable and working over bleeding edge
<wgrant> mthaddon: Indeed, that would be helpful.
<wgrant> Thanks.
<wgrant> It would be nice if there was a list of what's running what.
<bigjools> +1
<mthaddon> wgrant: devpad:/srv/launchpad.net-logs/code_check
<wgrant> Oh. That's a bit perfect.
<wgrant> Has that always been there?
<mthaddon> yep
<wgrant> Yes, for 3.5 years.
<mthaddon> one of the best kept secrets of LP
<wgrant> Does that check all the deploymgr trees?
<wgrant> bilimbi's on there, so it seems reasonably up to date.
<mthaddon> yep, it does all
<bigjools> nice!
<wgrant> Very tempting to fix sourcedeps.cache.
<mthaddon> https://pastebin.canonical.com/51693/
<wgrant> This should probably be mentioned on LPS or something.
<mthaddon> good idea - feel free to add it somewhere that seems relevant
<wgrant> Ah, it only runs daily?
<mthaddon> yep
<jtv> Anyone know what the current "versioninfo" buildbot failure is about?
<wgrant> I guess it should probably trigger after each deploy, as you said earlier, I guess.
<wgrant> jtv: Where?
<wgrant> jtv: The current runs look successful, AFAICT.
<jtv> wgrant: oh, I can't load up the log but devel is failing for me.
<jtv> (I wonder why this is: some https pages won't load at all, even when others work fine)
<wgrant> No tracebacks in the lucid_lp log that I can see.
<jtv> Has lp.app.tests.test_versioninfo run yet?
<wgrant> No.
<wgrant> Oh, you're seeing this locally?
<jtv> Grumble.  Why do other logs load just fine for me, but this one stays stuck in both chromium and FF?
<wgrant> You said "buildbot failure" :)
<wgrant> buildbot leaves it open because it's not done yet.
<wgrant> So it streams.
<jtv> Yes, I thought I saw a buildbot failure but https not working confused my research.
<wgrant> There was spectacular buildbot breakage a few hours ago due to a double master massacre, but looks fine now.
<jtv> wgrant: don't know if it's the same thing but I get similar symptoms with some bugs, for instance.
<wgrant> Been working OK for me.
 * wgrant blames Thailand.
<jtv> Yeah, it could be censorship.  They said something about censoring https a while back.
<jtv> wgrant: do you get the failure locally, if you first "make clean && make"?
<wgrant> jelmer: The importds are upgraded now.
<wgrant> jelmer: Thanks for noticing.
<wgrant> AssertionError: '13785' != 13785
<wgrant> May be the bzr upgrade.
<jtv> Yup.  I got that from EC2 too.
<jelmer> wgrant: thank you
<wgrant> I've had a few successful ec2 runs today.
<jelmer> wgrant: where is that AssertionError from?
<jtv> wgrant: for me it appeared just very recently.
<wgrant> jelmer: lp.app.versioninfo is returning a str instead of an int.
<jelmer> wgrant: which lp branch?
<jelmer> (bzr in devel is still on the old bzr, only db-devel has moved to 2.4+)
<wgrant> jelmer: devel, and that's a very good point.
<jtv> AFAIC the test could cast both sides to int and sidestep the whole issue.  But I don't know what else that would upset.
<wgrant> I wonder if that runs with the system bzr.
<wgrant> But that wouldn't explain ec2.
<wgrant> It appears to use the system bzr.
<jelmer> wgrant: hah
<jelmer> wgrant: then I think I know what it is. In 2.4 one of the "bzr version-info" fields was changed to a string to support dotted revnos
<wgrant> jelmer: That would do it.
<wgrant> I wonder if the ec2 image uses a PPA with 2.4.
<jelmer> doesn't it use the bzr ppa?
<wgrant> I'm checking.
<bigjools> jtv: your branch that I'm reviewing shows deleted bzr conflict markers in the diff, which means the preq branch is conflicted I guess?
<wgrant> lib/devscripts/ec2test/instance.py:deb http://ppa.launchpad.net/bzr/ubuntu $DISTRIB_CODENAME main
<wgrant> lib/devscripts/ec2test/instance.py:deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu $DISTRIB_CODENAME main
<wgrant> Yup.
<jtv> bigjools: possibly.  I'll resolve.
<wgrant> I wonder why this didn't affect my three successful runs with the new image.
<StevenK> wgrant: The ec2 image would have just been updated with 2.4
<wgrant> StevenK: Yeah, but I've used the image multiple times today.
<wgrant> Current run has a str there... I guess we'll see if it succeeds.
<StevenK> wgrant: So you're happy with the image itself?
<wgrant> It seems to work.
<StevenK> Huzzah, I have fixed make for my branch of evil
<wgrant> What was broken?
<wgrant> dpkg-xz-support-619152 => devel  [OK]     (up for 2:52:55.425176)
<wgrant> We may have success.
<StevenK> I forgot to remove a class and securedutility for BranchDiffJob
<wgrant> StevenK: If abentley appears before you vanish, you should probably ask him about the history here.
<StevenK> 19 files changed, 31 insertions(+), 492 deletions(-)
<wgrant> StevenK: You've stopped deleting the table, right?
<StevenK> Indeed
<StevenK> As in, I haven't done so
<StevenK> Tossing back at ec2
<wgrant> The original diff appeared to have the table gone from sampledata.
<StevenK> That was removing triggers
<wgrant> Ah.
<nigelb> What advantage does PQM have over tarmac?
<StevenK> None.
<nigelb> Oh.
<jelmer> StevenK: It supportts tla, arch and baz
<jelmer> s/arch/arx/
<jelmer> :P
<jelmer> s/StevenK/nigelb/
<jelmer> sigh
<jelmer> nigelb: It supportts tla, arx and baz
<nigelb> what are those?
<wgrant> They are probably or hopefully old enough that nigelb doesn't....
<wgrant> right.
<wgrant> baz was bzr's predecessor.
<wgrant> tla and arch are older and even crustier.
<jelmer> wgrant: not arch, arx
<jelmer> (which is yet another fork of arch)
<wgrant> Oh, I didn't know it supported that.
<wgrant> Impressive.
<nigelb> Ah, so just support for more VCS?
<wgrant> nigelb: Crucially, VCSes that have been obsolete for more than 5 years.
<nigelb> heh
<wgrant> And nobody ever really used anyway.
<nigelb> I dream of one day being able to say approved and launchpad doing the merges itself with pqm or tarmac in the backend.
<wgrant> Maybe eventually. It's awkward, though, as most projects hopefully want to have a test suite.
<nigelb> Ah.
<nigelb> hah. http://www.reddit.com/r/programming/comments/jsudd/you_see_rasmus_lerdorf_creator_of_php_wrecking/
<danilos> jelmer, hi, what's the status of the loggerhead trunk? can we move LP to it? what is missing? should I perhaps revert the problematic changes in loggerhead trunk, get that revision into LP, and then reland them on loggerhead trunk?
<jelmer> danilos: I'm not sure, I haven't followed loggerhead much recently.
<jelmer> What are the problematic changes?
<danilos> jelmer, wasn't there a problem that you were working on?
<jelmer> danilos: I fixed a bug that affected loggerhead, but don't recall working on loggerhead itself recently
<jelmer> danilos: as far as I know loggerhead trunk is fine :)
<danilos> jelmer, LP is not using the latest rev from trunk because of some regressions
<wgrant> danilos: That was misdiagnosed.
<wgrant> danilos: The regression was in an unrelated change of jelmer's.
<danilos> wgrant, ah, so that's all sorted?
<jelmer> danilos: yep, should be
<wgrant> danilos: It still needs to be relanded.
<danilos> jelmer, sorry to have bothered you then :)
<danilos> wgrant, I'd be happy to do that because there's another revision I care about
<wgrant> lifeless and I reverted it hastily upon seeing an extra 3000 loggerhead OOPSes a day, without noticing there was a non-threadsafe SafeBranchOpener in the same deployment.
<danilos> jelmer, wgrant: thanks for your input, I'll go up our loggerhead to the latest trunk
<wgrant> Great.
<nigelb> wgrant: Is there an inside joke to your email? "2008/02/29 and dodgy date manipulation code for that."
<wgrant> nigelb: I am guessing that ChanServ thinks a year is 365 days.
<wgrant> But 2008 had 366 days.
<nigelb> Ahhh.
<wgrant> cjwatson: Landed. Sorry it took so long.
<nigelb> wgrant: the fix for that bug is to just remove int(output) to be outpuut instead?
<nigelb> really?
<nigelb> (or change revno to be str(revno))
<cjwatson> wgrant: hooray, thanks!  now I just have to wait for bug 809123 and I can flush my queue ...
<_mup_> Bug #809123: we cannot deploy DB schema changes live <fastdowntime> <qa-ok> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/809123 >
<wgrant> nigelb: Maybe. We need to see what other stuff uses that value.
<wgrant> nigelb: It's displayed in the footer of every page, for example.
<nigelb> ah
<wgrant> cjwatson: Getting there. I believe there's only 5 or so hosts that aren't pgbouncer-capable, which is the last major blocker to fastdowntime.
<wgrant> Hopefully by early next week we'll be ready.
<wgrant> And this is actually a somewhat realistic estimate, I think :)
<StevenK> Bah, I meant this channel.
<wgrant> Well, aren't you a failure.
<StevenK> wgrant: Clearly.
<StevenK> wgrant: It seems that test_branch{,job} still referenced BranchDiffJob all over the place.
<wgrant> Ah.
<cjwatson> wgrant: incidentally, roughly when should I expect cocoplum to be updated?  I don't know its update schedule nowadays
<StevenK> cjwatson: cocobanana needs to be requested.
<StevenK> cjwatson: With 24 hours notice for 5 minutes of downtime
<wgrant> cjwatson: It's no longer scheduled.
<wgrant> So, as StevenK says.
<wgrant> It still requires poppy downtime, so by convenition we must give 24 hours notice.
<wgrant> Unless Platform wants to waive that requirement, I suppose...
<cjwatson> What is cocobanana?
<wgrant> cocoplum
<cjwatson> Enough hostnames in the DC are quite similar that I find deliberate misspellings rather confusing ...
<cjwatson> cocoplum is at least not too far back; r13727
<wgrant> Yeah, we deployed on Monday.
<StevenK> cjwatson: Sorry, I should have said. cocobabana/cococabana is an LP in-joke
<StevenK> cocobanana, even. Sigh.
<wgrant> cjwatson: Actually, cocoplum isn't important here.
<wgrant> cjwatson: Since binaries are all uploaded to cesium.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 237 - 0:[#######=]:256
<StevenK> And cesium is NDT
<wgrant> Right.
<wgrant> It'll hopefully have this tomorrow morning.
<wgrant> In 12 hours or so.
<StevenK> abentley: O hai
<abentley> StevenK: Hai!
<StevenK> abentley: wgrant and I are of the opinion that StaticDiffs are unusd as of Janurary 2010. I've put together an MP to remove them, would you be able to take a peek at it?
<wgrant> RevisionMailJob still calls BranchDiffJob to generate but them, but RevisionAddedJob is now used for that instead.
<StevenK> abentley: Mind you, I'm not asking for a review, more a "Yes, this looks fine to do." or "No, please watch out for X, Y and Z."
<wgrant> RevisionMailJob is only ever called for initial and removed scans.
<cjwatson> oh, yes, good point.  excellent.
<wgrant> No staticdiff has been created in 18 months.
<abentley> StevenK: they are no longer used in new reviews, but do we want to delete them from old reviews?
<wgrant> cjwatson: I hope we've not blocked too much... Debian's only been at it a week or so, right?
<cjwatson> about that, yes.  it was a problem for an eglibc upload the other day, but quickly worked around and I haven't heard of any other instances yet.
<StevenK> abentley: TBH, it's 18 month old data, at least, and the code tries a PreviewDiff first if that exists, right?
<cjwatson> I think it's worked out OK.
<abentley> StevenK: Yes, it is old.  Trying a preview diff first shouldn't be relevant, because old reviews won't have a preview diff.
<StevenK> Let's see ...
<StevenK> 33k static diffs on DF. That's a little more than I was hoping.
<dobey> abentley: morning :)
<abentley> dobey: morning.
<dobey> abentley: i don't think that bug is quite fixed yet :(
<dobey> abentley: bug #833147 that is. see my last 2 comments on it
<abentley> dobey: Is this about +activereviews?
<_mup_> Bug #833147: landing_candidates does not show proposals for private branches <qa-ok> <regression> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/833147 >
<dobey> abentley: yeah, and the count seems wrong
<StevenK> wgrant: What do you think?
<abentley> dobey: according to danilos, +activereviews doesn't use landing_candidates.
<dobey> huh
<wgrant> StevenK: If we do want to keep them, we could turn them into fake previewdiffs or something.
<wgrant> Keeping the legacy table around forever seems undesirable.
<StevenK> Hmmmm
<abentley> dobey: you may be thinking of bug #833184
<_mup_> Bug #833184: Branch.getMergeProposals breaks with private branches. <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/833184 >
<danilos> abentley, well, I confirmed that the query count is still not insane on the page (for the timeout I was fixing, it was about 250 today when it used to be around 1500)
<danilos> abentley, I've basically changed +activereviews to not use landing_candidates so I could make it use getMergeProposals() with eager loading of a bunch of related data
<abentley> danilos: was that in the same branch?
<dobey> abentley: is that what is used by the bit in launchpad that sets a proposal/branch to 'merged' once it's been merged into its target?
<danilos> abentley, I think so, yes
<abentley> dobey: I don't recall which APIs are used by that.
<dobey> abentley: ok. it's also not working now :(
<dobey> abentley: we have a branch that landed ~13 hours ago, but i haven't got a mail from LP and it hasn't set the proposal/branch to 'merged'
<abentley> danilos: I don't see that change in the diff.
<StevenK> wgrant: That sounds like a good idea -- do you think that blocks the branch I've worked on.
<abentley> danilos: found it.  Darn.
<abentley> dobey: no, the merge detector is using landing_candidates, not getMergeProposals.
<dobey> abentley: hrmm. i wonder why it's not working then :-/
<abentley> dobey: What are the names of the branches involved?
<dobey> abentley: lp:~pedronis/ubuntuone-servers-common/sqlalchemy-uris -> lp:ubuntuone-servers-common
<wgrant> Status: Merged
<wgrant> The MP is still Approved, but the branch merge was detected.
<wgrant> StevenK: Your branch drops access to the staticdiffs, so yes, probably.
<dobey> ok, so it's half-broken then :)
<wgrant> abentley, danilos: Any reason not to roll back both the branches?
<deryck> henninge-lunch, ping for standup
<dobey> maybe related to the fact that the number of activereviews is wrong?
<abentley> wgrant: I don't think so.
<wgrant> If you land the reversion now we can probably deploy it in 10-12 hours.
<wgrant> I'd be reluctant to roll production back 80 revs now, though.
<abentley> wgrant: OTP
<StevenK> wgrant: When you say make them previewdiffs, do you mean a garbo job or a query?
<wgrant> StevenK: It's only 30000 rows. Query.
<wgrant> StevenK: But we need to determine if that is acceptable.
<StevenK> SELECT count(*) from branchmergeproposal where review_diff is not null; => 12111
<StevenK> So 20,000 of those are effectively abandoned?
<StevenK> abentley: Okay, so if wgrant and I can work out a migration plan, you're happy to see it be removed?
<abentley> StevenK: sure.
<StevenK> abentley: Excellent, thank you.
<wgrant> abentley: Any problem with just turning all those ancient ones into fake preview diffs?
<abentley> wgrant: I don't think so.
<StevenK> So am I right that ~20,000 are dead/unlinked?
<wgrant> StevenK: They're possibly from RevisionMailJobs, but I'd really expect more...
<abentley> danilos: I will go ahead and (mostly) roll back our revisions.  Cool?
<wgrant> abentley: Please roll back entirely, unless you have an extremely compelling reason not to.
<abentley> wgrant: I will not roll back the test that I added to ensure this doesn't happen again.
<wgrant> Makes tracking easier, and gets us back to a known-good state.
<wgrant> Ah.
<wgrant> That sounds like a good idea.
<StevenK> Bah, Curtis, stop that!
<abentley> wgrant: Is it possible that dobey's misseed merge detection happened before the deployment?
<bigjools> StevenK: he's only after the karma :)
<StevenK> bigjools: Are you getting the e-mails too?
<wgrant> abentley: It probably did.
<bigjools> yes
<wgrant> abentley: The deployment was 14 hours ago.
<dobey> abentley: i don't know how it could have merged before the deployment, since it landing depended on the landing_candidates fix?
<wgrant> abentley: But Branch:+activereviews is still empty, Product:+activereviews shows 1 branch, and Branch:+index shows 2 branches.
<wgrant> So something is still pretty screwed.
<abentley> wgrant: I grant that activereviews is screwed, but if something's wrong with merge detection, it's a separate something, because merge detection uses landing_candidates.
<wgrant> abentley: Ew.
<wgrant> abentley: That's not ideal.
<wgrant> abentley: I guess we should check scanner logs...
<danilos> abentley, sure, I don't think I can fix it today
<danilos> abentley, (sorry, otp)
<jelmer> jcsackett: thanks for the reviews
<jcsackett> jelmer: you're welcome. :-)
<wgrant> abentley: Of course, I can see trunk, so I can just check when the merge happened.
<wgrant> Ahem.
<wgrant> Date: 2011-08-24 23:46:49
<wgrant> Middle of the rollout.
<wgrant> Ah.
<wgrant> But appservers generally update before loganberry.
<wgrant> s/loganberry/ackee/, now.
<abentley> wgrant: so, race condition.
<wgrant> So tarmac would have seen the branch before the scanner was fixed.
<abentley> dobey: it appears the scan happened halfway through the deployment, when the scanner was broken, but the API was fixed.
<dobey> abentley: ok, so just bad timing?
<abentley> wgrant, danilos, deryck: landed rollback as r13787
<wgrant> abentley: Thanks. All except that test?
<abentley> wgrant: Yes.
<wgrant> Great.
<wgrant> I will see that it's rolled out ASAP in the morning.
<deryck> abentley, indeed, thanks for doing this!
<abentley> wgrant: Oh, darnit, I forgot to use --rollback.
<danilos> abentley, thanks
<danilos> abentley, it's already rolled out so not a big deal, I'd say
<wgrant> abentley: Not too critical, since we're not rolling back prod.
<wgrant> qa-tagger won't see the bad rev even if we mark it bad.
<wgrant> abentley: Care to update the IncidentReport?
<abentley> wgrant: true.
<abentley> wgrant: sure.
<dobey> abentley: can we make the scanner run for that branch again? or should i just set status manually? there was some reason we stopped having tarmac set the status, but i don't remember what exactly. just remember it messed with LP automagic stuff
<abentley> dobey: just set the status manually.
<dobey> ok
<dobey> so just the reviews count and +activereviews issue it seems.
<dobey> wgrant, abentley: thanks guys
<wgrant> dobey: https://code.launchpad.net/ubuntuone-servers-common/+activereviews should still work.
<wgrant> Just the branch-specific one is broken.
<dobey> right, ok
<bigjools> anyone got any strong opinions on whether constants can/should go in enums.py or do we need a constants.py?
<bac> i'd vote for enums
<bigjools> that's what I was leaning to as well
<sinzui> jcsackett, do you have time to review my two branches?
<jcsackett> sinzui: i'm actually looking at your first one now.
<sinzui> thank you
<nigelb> wgrant: failed with that error you emailed about.
<wgrant> nigelb: Landed.
<wgrant> Night all.
<nigelb> wgrant: Thanks. Night!
<benji> hi jelmer, my bzr branch (https://code.launchpad.net/~benji/bzr/bug-702914/+merge/72239) has landed so the last thing to do is to either apply that patch to the LP snapshot or re-snapshot the current trunk.  I'm happy to do either of those if you point me at the branches in question.
<jelmer> hi benji
 * jelmer looks at the bzr.dev log
<jelmer> benji: so, either way, I'll have to update my bzr-2.4b4 branch
<henninge> jcsackett: Hi!
<jelmer> that's currently on db-devel at the moment, so we can do some extended QA on staging
<jelmer> s/currently/
<henninge> jcsackett: I have to go now but if you could have a look at my latest branch, I'd be very pleased. ;-)
<henninge> jcsackett: https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-3/+merge/72908
<jcsackett> i'll take a look just as soon as i'm done with sinzui's, henninge. :-)
<jelmer> benji: So I guess the question is how urgent your fix is, and whether it can wait until bzr on launchpad is updated to bzr 2.4.0
<deryck> abentley, I'll be about 5 minutes late to our call, but meet you in mumble then, if cool with you.
<henninge> jcsackett: there are links to diffs in the cover letter as the branch is quite big.
<henninge> jcsackett: thanks, that's great! ;-)
<abentley> deryck: sure thing
<benji> jelmer: it's relatively low on the urgency scale, and also quite low on the risk scale too, so I'm cool with however you want to handle it
<jelmer> benji: in that case, let's just take a slightly newer revision of bzr.dev when we update devel to bzr 2.4
<jelmer> benji: that seems like both the safest thing to do, and involves the least amount of work
<benji> jelmer: cool.  In that case I'll consider my work done.  Thanks
<jelmer> benji: thanks for fixing that :)
<benji> my pleasure
<LPCIBot> Project devel build #993: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/993/
<bac> abentley: do you have time to talk for a bit about a but i'm working?
<abentley> bac: OTP
<bac> abentley: ok.  perhaps in a little while
<jcsackett> is diff generation for MPs down? i've been waiting for about 30 minutes for a diff on henninge's mp to generate ...
 * jcsackett digs through email to see if he missed a script failure notice
<adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-7/+merge/72917 ?
<jcsackett> adeuring: sure.
<adeuring> thanks!
<jcsackett> adeuring: r=me.
<adeuring> jcsackett: thanks!
<LPCIBot> Project devel build #994: STILL FAILING in 2 hr 26 min: https://lpci.wedontsleep.org/job/devel/994/
<mrevell> Night all
<abentley> deryck: so, that bug turned out to be a surprisingly simple fix.  Who do we have who's up on Twisted?
<deryck> abentley, hmmm, so I'd point you at allenap, bigjools, lifeless, or wgrant, I think. :)
<abentley> deryck: Cool, thanks.  We need a table for this.
<LPCIBot> Project devel build #995: STILL FAILING in 30 min: https://lpci.wedontsleep.org/job/devel/995/
<abentley> deryck: pre-imp?
<deryck> abentley, do you mind asking someone else?  Sorry to pass.  Just have couple things I need to get done before EOD.
<deryck> abentley, but I absolutely will if no one else is available.
<abentley> deryck: okay.
<abentley> sinzui: pre-implementation call?
<dobey> hrmm
<dobey> when one marks a milestone inactive, aren't the bugs targeted to that milestone supposed to still show that milestone value in the bugs page?
<dobey> i thought it didâ¦
<sinzui> abentley, okay. in a few minutes one I extract myself from a breakpoint
<sinzui> abentley, I am on mumble?
<abentley> sinzui: okay.
<abentley> sinzui: bug 82077
<_mup_> Bug #82077: [apport] gnome-volume-control crashed with SIGSEGV in g_type_class_meta_marshal()  <GNOME media utilities:Fix Released> <gnome-media (Ubuntu):Fix Released by desktop-bugs> < https://launchpad.net/bugs/82077 >
<abentley> sinzui: bug 820077
<_mup_> Bug #820077: TeamMembershipTransitionError: Bad state transition from DECLINED to INVITED  <oops> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/820077 >
<bac> cjwatson: colin could you have a look at https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/158404 when you get a chance?  the user has sent email to us asking for some resolution or a comment.
<sinzui> abentley, https://bugs.launchpad.net/launchpad/+bug/109716
<_mup_> Bug #109716: Cannot join open team if there's an existing membership pending approval <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/109716 >
<LPCIBot> Project db-devel build #825: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/db-devel/825/
<lifeless> hi flacoste :)
<lifeless> you have mail; we might want to touch base on the general principle today.
<lifeless> bah, no gary. I wonder who else knows buildout really really well :)
<james_w> lifeless, is this still the recursive issue?
<lifeless> yeah
<james_w> does something like http://pypi.python.org/pypi/cp.recipe.cmd/0.1b help?
<lifeless> possibly
<lifeless> I'd like something with a -little- more awareness of options and so on
<flacoste> hi lifeless
<flacoste> lifeless: i don't think we need to touch base over that, i completely agree with your last email
<flacoste> lifeless: about buildout, i probably enough to get into trouble, i've reviewed and discussed all of gary's work on it at length with him
<flacoste> probably _know_ enough
<lifeless> :)
<lifeless> flacoste: ah good, I'm glad we agree. Buildout:
<lifeless> flacoste: I have this gpgfixtures project extracting gpg stuff; a wsgi, in-memory keyserver and so on
<lifeless> flacoste: I'd *like* to demonstrate the microservice fake setup where LP *runs* the fake service without being able to *import it*
<lifeless> flacoste: so it looks like a complete abstraction barrier
<flacoste> lifeless: i think i know how to do this, voice is probably better, want to skype me?
<flacoste> lifeless: it's seems even easy :-)
<lifeless> sure
<lifeless> 2 secs
<lifeless> flacoste: lp:python-gpgfixtures
<lifeless> flacoste: btw skaet is having trouble - https://bugs.launchpad.net/launchpad/+bug/834082
<_mup_> Bug #834082: Regression? can not target to series or update assigned to for ubuntu bugs <Launchpad itself:New> <Ubuntu:New> < https://launchpad.net/bugs/834082 >
<lifeless> is there someone still live in maintenance to look ?
<flacoste> deryck: if you are around ^ ^ ^
<deryck> I'm around.
 * deryck looks back
<deryck> hmmmm
<deryck> that sounds more like the group or her group membership changed.
<lifeless> flacoste: bin/py -m gpgfixtures.keyserver
 * deryck looks at bzr log
<LPCIBot> Project devel build #996: STILL FAILING in 1 hr 57 min: https://lpci.wedontsleep.org/job/devel/996/
<lifeless> interestingly
<lifeless> mdz took techboard out of udd today, but I don't htink that that would have been granting privilieges
<deryck> lifeless, I can't imagine.  If it's easy enough, might be worth adding it back as a simple test to see if she can work again. :)
<deryck> I can't really see anything that looks like it would have changed series nominations and assigning bugs.
<deryck> sinzui, do you know of any change that might now be keeping skaet from setting bugs to series and assigning bugs to a team?
<sinzui> deryck, no clue
<deryck> sinzui, ok, cool.  thanks.
<sinzui> deryck, I do not see a skaet in launchpad
<sinzui> https://launchpad.net/people/?name=skaet&searchfor=all
<deryck> sinzui, she filed a bug.  bug 834082
<_mup_> Bug #834082: Regression? can not target to series or update assigned to for ubuntu bugs <regression> <Launchpad itself:Triaged> <Ubuntu:New> < https://launchpad.net/bugs/834082 >
<sinzui> deryck, that relates more to bug nominations than bug targeting
<deryck> sinzui, indeed.  Did I say targeting?  Sorry.
<lifeless> well
<lifeless> she is rm
<lifeless> so she never nominates :)
<deryck> semantically, that's true, but it still goes through Bug.addNomination, I believe.
<sinzui> I see she is a direct and indirect driver for the series. I believe she should have permission.
<deryck> yeah, i would think so, too.
<sinzui> deryck, I think the picture already shows that the bug is nominated and accepted
<sinzui> This might be a case where we allow users to attempt a non-change action, and then show an error
<deryck> sinzui, oh, right.  I didn't even catch that.
<sinzui> deryck: I think the action here is that he wants to assign teams and target milestones. which the image implies she can do, but a bug-nomination constraint is being called after the bug is already accepted? Since the behaviour/checks are different between the DSP and (series)SP contexts, I think something has changed to distroseries bugtargets
<deryck> ah, yes.  hmmmm
<lifeless> sinzui: she :)
<deryck> So she's not using the drop down form under the task.  She's trying to target to maverick and assign desktop team....
<deryck> and is using the page via the "target to series" link and the js assign someone widget....
<deryck> so this smells like group changes, not code changes, to me.  since the two are really unrelated.
<deryck> sinzui, lifeless ^^
<lifeless> tada
<deryck> hi skaet, we're talking about you ;)
<lifeless> deryck: skaet: You've probably met :P
<deryck> indeed
<skaet> :)
<deryck> skaet, this feels to me like it has to be something changed in the groups, since targeting to series and assigning someone to the bugtask are not really related.
<skaet> deryck,  not aware of any changes to my groups recently.
<sinzui> deryck, the drivers for maverick and oneiric are identical: ~ubuntu-drivers, ~ubuntu-release. BugNomination.canNominate() will exit early with True for a driver member. The series are only different because one is a conjoined slave
<deryck> sinzui, so I'm doing some poking at the code myself, and see it's BugNominationView that raises the error and does its own check.
<sinzui> Excellent the view ignores the object's own definition of who can change it
<deryck> exactly.
<deryck> but it is basically the same, a check against launchpad.driver.
<deryck> this stuff hasn't been touched in awhile, if bzr blame is to be believed.
<sinzui> deryck,  the driver check between the view and the object look identical and she is in both driver teams
<deryck> sinzui, yeah, agreed.  I don't see how this could be failing.
<lifeless> \o/
<deryck> is there some insight there, lifeless?  or just general excitement? :)
<deryck> skaet, so is this accurate -- you *can* target to series when there isn't one set, but *cannot* target to series when there is one already set?
<skaet> deryck,  don't believe that is the case.    See the links in the bug.   series has been set in both cases (same bug).
<deryck> skaet, but the one you did was set for one task, but not another?  and you set it to Oneiric for the other?  or no?
<skaet> deryck,  it was set to Oneiric before I encountered it.
<skaet> if it has /oneiric/ in the path,  I can't seem to target series.
<deryck> oh!  I get what you're saying now.
<skaet> :)
<deryck> skaet, so you're clicking through from a series list of bugs and then can't target to a different series from that url?
<lifeless> skaet: what happens if you go to the other task on the bug
<lifeless> and then target to maverick or whatever you're trying to target to ?
<lifeless> skaet: (or are you trying to target to oneiric ?
<skaet> lifeless was going to target it,  so it got looked at for maverick.
<lifeless> ok
<deryck> skaet, but it works if you drop the "oneiric" from the url?
<lifeless> so yeah, head to the upstream task, and try to add a task there for maverik
<skaet> deryck,  yes,  that is what works.
<deryck> skaet, ok, so at least we have a work around for that :)
<deryck> not nice, but at least you can get by until we figure it out.
<deryck> skaet, but you have nothing working for assigning to a team?  Or this also works from the non-oneiric url?
<skaet> derych,  no pencil icon beside name on either link, but dropdown seems to work from path without /oneiric/ in it.
<skaet> deryck, ^^
<skaet> so work around there too.
<deryck> skaet, ok.  so at least you can work around that, too.
<deryck> right
<skaet> yup,  will use these for now.   But given the beta bug set about to hit,  please, please, please get the more efficient ways working again.
<deryck> skaet, oh, definitely.  I'll add it to my squad's board to figure out as soon as we can.
<skaet> deryck, thanks!
<deryck> skaet, np!
<deryck> ok, I'm out.  Later on, everyone!  Thanks, sinzui, for the help thinking about that issue.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256
<nigelb> ok, so apparently, I can't join here until identified.
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 237 - 0:[#######=]:256
<wgrant> Ahh, quality sampledata.
<wgrant> foobar-1.0.dsc
<wgrant> iceweasel-1.0.dsc
<StevenK> Haha
<wgrant> Why do people insist on hyphens :(
<wgrant> NOT VALID
<james_w> I didn't think the filename was actually important?
<StevenK> It is!
<james_w> i.e. you could have annoy-wgrant.dsc and it would still be valid if the contents made sense
<StevenK> The format of the filename is specified in Policy, I think
<wgrant> james_w: It's certainly important for all the other files.
<wgrant> james_w: Otherwise dpkg-source can't know what to do with them.
<james_w> yeah
<james_w> they obviously have to match the names listed in the .dsc
<wgrant> But this stuff probably isn't specified in Policy.
<wgrant> I'm not sure any of the source formats are.
<james_w> I'm sure there are many things (I'm sure I've written some) that assume the filename format, but I don't see why it would be strictly required
<wgrant> Just the source package layout itself.
<james_w> from a schema point of view
<james_w> http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives
<wgrant> Hah.
<wgrant> So the dsc is indeed unspecified.
<wgrant> Although that sectioin is a few years out of date...
<james_w> yeah
<james_w> so maybe those files are named like that to test that files named like that are handled, as there are some old files in Debian like that :-)
<wgrant> We don't handle them.
<wgrant> Except for a couple of methods.
<wgrant> They certainly can't make it all the way through.
<wgrant> Never could.
<wgrant> They're only used for a few small unit tests.
<james_w> ok
<james_w> that concludes today's episode of pedantry, as you were
<wgrant> I think it's generally safe to assume that terrible old stuff in LP is just terrible old stuff, and not actually real.
<wgrant> Heh
<lifeless> kiko will know :)
<lifeless> for those things in particular
<wgrant> I'm currently fixing a unit test for a method in a script that was never used, which just feeds data to archiveuploader which will reject hyphens anyway.
<wgrant> So I'm not sure it's particularly important :)
#launchpad-dev 2011-08-26
<StevenK> wgrant: Down to one failure in my no-more branch
<wgrant> Excellent.
<StevenK> How did this fail before? I don't get it
<wgrant> Hm?
<StevenK> wgrant: http://pastebin.ubuntu.com/674932/
<wgrant> StevenK: It possibly was relying on the branch not existing on disk.
<wgrant> StevenK: Try checking the output on devel.
<StevenK> ERROR   Job execution raised an exception.
<StevenK>  -> http://localhost:33770/93/bLqgyciAI0wS9vOJ96yNSjGCqMV.txt (Not a branch: "lp-internal:///~person-name-870614/product-name-870620/branch-870616".)
<StevenK> Whereas that doesn't happen for my change
<StevenK> So I guess it wants a job for a branch that doesn't exist on disk?
<wgrant> Right. Use a RevisionAddedJob or so.
<wgrant> Since RevisionMailJob doesn't touch the disk any more.
<StevenK> wgrant: Fixed.
<wgrant> StevenK: Using RevisionAddedJob?
<StevenK> wgrant: Yes
<wgrant> Great.
<StevenK> Now to craft evil queries
<wgrant> Should be pretty trivial.
<wgrant> And there's only like 11000.
<wgrant> Possibly less, if some of them have preview diffs.
<lifeless> wgrant: what are you doing ?
<wgrant> lifeless: StevenK is abolishing review diffs.
<StevenK> SELECT count(distinct(review_diff)) from branchmergeproposal where merge_diff is null; => 5213
<lifeless> did you talk to aaron about difftasticd ?
<lifeless> s/d //
<StevenK> Not about difftastic, that had utterly slipped my mind
<lifeless> well, review diffs and difftastic are pretty linked
<StevenK> They are?
<lifeless> I'd hate to see that deleted rather than fixed.
<lifeless> perhaps I misunderstand
<StevenK> I thought difftastic was used for incremental diffs?
<wgrant> lifeless: Those are incremental diffs.
<lifeless> I probably do misunderstand :)
<wgrant> Review diffs are what came before preview diffs.
<wgrant> Back in the days of lp:mad.
<StevenK> Named in DB as *static*diff
<wgrant> <= 2010/01
<lifeless> ah
<lifeless> cool cool thanks!
<StevenK> wgrant: So, we have a query to clear review_diff where preview_diff is not null
<StevenK> launchpad_dogfood=> UPDATE branchmergeproposal set review_diff = null where review_diff is not null and merge_diff is not null;
<StevenK> UPDATE 6860
<wgrant> launchpad_dogfood=> SELECT merge_diff IS NOT NULL, review_diff IS NOT NULL, COUNT(*) FROM branchmergeproposal GROUP BY merge_diff IS NOT NULL, review_diff IS NOT NULL; ?column? | ?column? | count
<wgrant> ----------+----------+------- f        | f        |  3061 f        | t        |  5251 t        | f        | 36774 t        | t        |  6860
<wgrant> Fail.
<StevenK> Haha
<wgrant> But there are 6860 with both, 5251 with just a staticdiff.
<StevenK> Right, so the update for 6860 rows is fine
<StevenK> Now a query to create previewdiffs
<wgrant> Are preview diffs always used in preference to review diffs?
<StevenK> From my reading of the code, yes
<StevenK> There's only 746 MPs with a staticdiff, no previewdiffs and aren't merged
<StevenK> And 4505 where date_merged is not null
<wgrant> Even merged ones would be nice.
<StevenK> I'm just a little lost how to loop on branchmergeproposal, creating rows in previewdiff and updating
<LPCIBot> Project db-devel build #826: STILL FAILING in 5 hr 29 min: https://lpci.wedontsleep.org/job/db-devel/826/
<wallyworld_> wgrant: StevenK: dumb question of the day - what's the difference between a review diff and a preview diff?
<StevenK> wgrant: reviewdiffs are static and ancient
<StevenK> RARGH
<StevenK> wallyworld_: ^
<wallyworld_> StevenK:  ah, so review diffs do not get updated if someone pushes a change to the branch after it is put up for review?
<StevenK> wallyworld_: They have not been generated in the database for over 18 months, it's probably not worth learning about, TBH
<wallyworld_> ok
<wallyworld_> delete away.... :-)
<wgrant> Bah.
<wgrant> No index on previewdiff(source_revision_id, target_revision_id)
<StevenK> wgrant: Do we need one?
<wgrant> StevenK: Probably. We should try on staging without it.
<wgrant> But DF definitely does.
<wgrant> http://paste.ubuntu.com/674955/
<wgrant> Or you end up with thousands of seq scans of the table.
<StevenK> Right
<StevenK> wgrant: Is that in a transaction?
<wgrant> StevenK: Yes.
<StevenK> Right
<wgrant> Should also set review_diff = NULL, I guess.
<wgrant> But it's fast enough to do all this directly.
<StevenK> I have a query for that already
<StevenK> If we do that at the end, we can use it to clean up for us
<wgrant> We might as well do it in the one UPDATE.
<StevenK> UPDATE branchmergeproposal SET merge_diff = (SELECT id FROM previewdiff WHERE from_revision_id = source_revision_id AND to_revision_id = target_revision_id) FROM staticdiff WHERE staticdiff.id = review_diff AND merge_diff IS NULL;
<StevenK> UPDATE branchmergeproposal set review_diff = null where review_diff is not null and merge_diff is not null;
<StevenK> Are the two of them
<wgrant> I guess we need to unset all of them, whereas my UPDATE only needed to consider those without a preview_diff.
<wgrant> So indeed.
<james_w> OOPS-2062F5
<james_w> hmm, no bot? I'll have to do this by hand
<mwhudson_> those numbers seem small
<lifeless> not really
<wgrant> mwhudson_: Which?
<lifeless> its 0142
<mwhudson_> in the oops
<mwhudson_> ah right
<wgrant> 2 hours in, 60 appservers.
<james_w> Date: Aug. 24, 2011, 2:01 a.m.
<lifeless> which makes it 0101
<lifeless> if you use a real tz :P
<wgrant> :(
<wgrant> Dropping a foreign key requires a lock on both tables.
<lifeless> oh or its a couple days back :)
<wgrant> How stupid.
<lifeless> either way
<james_w> yeah
<lifeless> wgrant: thats because fk's are triggers.
<james_w> I was just making sure the oops had synced :-)
<wgrant> lifeless: Ah.
<lifeless> wgrant: (apparently :P) - they get presented differently of course, but are built on that mechanism.
<james_w> it
<james_w> it's doing the count(*) twice?
<lifeless> wallyworld_: uhm
<wallyworld_> lifeless: ?
<lifeless> wallyworld_: are you *trying* to make the public -stacked-on-private branch obfuscated?
<wallyworld_> no
<lifeless> why do you need a metaclass then ?
<lifeless> and __setattr__
<wallyworld_> so that code in storm queries can still go "Branch.private == xxx"
<wallyworld_> (the metaclass does this bit)
<lifeless> yes, but this means that aBranch.private and Branch.private are now totally different htings.
<lifeless> this is horribly confusing
<wallyworld_> and so that exisitng code which creates a branch via Branch(name=xxx, private=True) still works
<wallyworld_> (the setattr does this)
<StevenK> wgrant: Ah, I forgot we need to drop the FK as well
<StevenK> And then after my evil branch lands we can drop the column and table
<wallyworld_> lifeless: the other option then is to s/Branch.private/Branch.explicitly_private
<lifeless> wallyworld_: please
<lifeless> wallyworld_: thats what we've done in the past: KISS
<wallyworld_> ok. it wasn't confusing to me :-)
<wallyworld_> i was trying to do it behind the scenes so to speak
<lifeless> wallyworld_: its not confusing to me either, cause I've seen the diff. But imagine someone looking at the rest of LP
<james_w> I can't find a bug for this timeout, would someone take a look, or should I just file one?
<lifeless> who comes to this code, and sees no difference visually.
<lifeless> wallyworld_: unless you rename the column I suggest actually not renaming
<lifeless> wallyworld_: instead add a property 'effectively_private' or something, which would honour self.private + self.stacking etc.
<lifeless> wallyworld_: and reference that from security adapters, views etc.
<lifeless> wallyworld_: this will keep the class .private and the schema .private in sync with each other.
<wallyworld_> lifeless: that's a big change
<wallyworld_> why not just rename the private property to explicitly private
<wallyworld_> and use dbname="private" in the property
<wallyworld_> this will have the smallest footprint in terms of change to the code
<wallyworld_> and still be quite clear i think
<james_w> I think that's better, so that you don't have to remember that the obvious "private" attribute isn't likely what you usually want
<lifeless> wallyworld_: I'm thinking about the mapping from object to schema
<lifeless> james_w: file a bug :)
<wallyworld_> james_w: agreed.
<lifeless> wallyworld_: but sure.
<lifeless> wallyworld_: my main concern is that what folk think they are reading is what they are reading.
<lifeless> wallyworld_: they should be able to guess at the behaviour of the code, with high accuracy rates, without having read the entire implementation.
<lifeless> wallyworld_: if private is a property and *not* the db column, then 'foo.private = True' will not do what they expect.
<lifeless> however, I see that that is not meant to happen here anyway
<lifeless> folk are meant to call setPrivate
<wallyworld_> that bit will do what they expect. ie make the branch private. but if they say foo.private = False it may not
<lifeless> so +1
<wallyworld_> lifeless: ok. we can iterate later and change the column if needed
<lifeless> wallyworld_: well, it will only do that with either a property or a setattr
<james_w> https://bugs.launchpad.net/launchpad/+bug/834293
<_mup_> Bug #834293: Product:+code-index times out <Launchpad itself:New> < https://launchpad.net/bugs/834293 >
<lifeless> wallyworld_: ok; so for clarity - you're doing:13:50 < wallyworld_> why not just rename the private property to explicitly private
<lifeless> 13:50 < wallyworld_> and use dbname="private" in the property
<lifeless> wallyworld_: dropping the metaclass and setattr
<wallyworld_> lifeless: yes
<lifeless> wallyworld_: to be clear, I don't object to metaclasses and setattr per se; just that they should really be enhancing things, not obfuscating :)
<lifeless> wallyworld_: thanks!
<lifeless> james_w: please don't use lp-oops urls
<lifeless> james_w: just the oops id
<wallyworld_> lifeless: np, input is appreciated. i can see how it's clear to me because i'm close to it but not to others who may be looking in from the outside
<wallyworld_> lifeless: will you have time to do that loggerhead review before you go and spend your evening changing shitty nappies?
<james_w> lifeless, why?
<lifeless> james_w: a) we linkify anyway so theres no different in click-through, b) its easier to read and copy, c) the garbage collection code ignores url style oops references so they will get deleted.
<james_w> ah, I didn't realise there was any integration
<james_w> the latter seems like a bug though :-)
<lifeless> james_w: it is
<lifeless> james_w: but anyhow, its intended for users that have no access to the reporting UI
<lifeless> your having access to it is the exception :)
<james_w> yeah
<lifeless> frell
<lifeless> another regression
<wgrant> lifeless: Where?
<lifeless> bug 834266
<_mup_> Bug #834266: "831884 is not a valid bug number or nickname" <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/834266 >
<wgrant> lifeless: I think that's the second time you've declared this bug to be a regression.
<wgrant> lifeless: The case that's handled in marking a master as a dupe.
<wgrant> s/in/is/
<wgrant> Trying to find the dupe..
<wgrant> There.
<lifeless> wgrant: thanks :)
<wgrant> grar.
<wgrant> Why do people insist on implementing non-auditable copying.
<wgrant> Seriously.
<wgrant> Stupid.
<jtv> Hey, good morning everyone!  I think I'll implement some non-auditable copying today.
<wgrant> jtv: No, your squad already did that last week.
<wgrant> You're too late :(
<jtv> Oh, but there's always more to do.
<jtv> I insist on implementing non-auditable copying.
<wgrant> Good, good.
<wgrant> What could go wrong.
<jtv> hi wallyworld___, your collection of underscores is coming along nicely I see.
<jtv> Any reviews for me to approve?
<LPCIBot> Project devel build #997: STILL FAILING in 6 hr 0 min: https://lpci.wedontsleep.org/job/devel/997/
<StevenK> lifeless: O hai -- wgrant and I would like to remove all references to staticdiff -- the queries take approximately 12 seconds on DF and it will be a once-off. Or are you going to make me write a garbo job?
<wgrant> 12s include an index creation that can be done whenever.
<wgrant> 4-5s without.
<jtv> Over a hundred broken tests in buildbot.  That's impressive.
<wgrant> Yeah.
<wgrant> A revision was landed that depended on a revision that was reverted a few hours earlier.
<lifeless> the index creation is nonblocking
<lifeless> if its done CONCURRENTLY
<wgrant> Right.
<lifeless> so, that seems fine to me.
<wgrant> Hence can be done whenever, including in the patch, if required.
<lifeless> 4-5s is too long to do as one transaction though if its hitting 6K rows
<StevenK> We can split it up
<lifeless> yup
<StevenK> 2s per transaction or so
<lifeless> that works for me
<wgrant> lifeless: 6k merged proposals from before 2010? :)
<StevenK> Only 5k
<lifeless> wgrant: FK references.
<lifeless> wgrant: never underestimate the MVCC lock monster
<jamesh> lifeless: looks like the django ticket for passing the exception info up has progressed to "Design decision needed".  Hopefully that isn't a black hole
<wgrant> jamesh: It normally is with Django...
<lifeless> jamesh: win.
<lifeless> course, we could patch it in Ubuntu :)
<jamesh> it seems one of the issues is that not all exceptions might make it to handle_uncaught_exception(), so capturing errors there might not be perfect
<jamesh> I've added a comment that all the errors in my view code generally pass through that code path though
<lifeless> cool
<lifeless> if they swallow exceptions and don't reach that code path, that seem like a separate bug :)
<lifeless> as opposed to a reason not to do this
<jtv> wgrant: you asked why I didn't re-implement [BS]PPH.setDeleted in terms of PublishingSet.setMultipleDeleted.  The answer is that the latter bypasses the ORM, which is more likely to be harmful in code that requests deletion of individual objects.
<wgrant> jtv: True. Although it doesn't have to bypass the ORM.
<wgrant> Do you know about ResultSet.set()?
<wgrant> It gets far too little use.
<jtv> No, I don't!  I knew there was something like that for delete, but it gave us endless trouble anyway.
<jtv> (There were all sorts of queries it didn't support)
<wgrant> yeah, but for this sort of thing it's probably fine and a lot less ugly.
<jtv> I'll file a bug to fix that.  It'd save some test commits.
<wgrant> Right.
<wgrant> jtv: Do you like lp.soyuz.model.publishing's wonderful test coverage?
<wgrant> Truly exemplary  stuff.
<StevenK> How sarcastic are you being?
<jtv> wgrant: I'm picking up a hint of sarcasm there, but I'm told that I wouldn't understand because I'm not American.
<wgrant> Just a bit.
<jtv> Thanks.  It helps to be clear about these things.
<StevenK> wgrant: That's like calling a fish 'just a bit wet'
 * wgrant deletes more of Distribution.
<jtv> A-khah.  This vhat British capitalist call, understatementâda?
<StevenK> wgrant: Excellent.
 * StevenK fights with Jenkins
<lifeless> jtv: you managed to create two bugs
<jtv> That explains why I got two confirmation boxes.
<lifeless> jtv: I wonder if we have a bug in our request retry logic or something
<jtv> Or a very late failure triggering a retry after db commit maybe?
<jtv> I don't suppose the browser would retry the POST unless it got an unambiguous application-level failure response?
<wgrant> Sure you didn't click submit twice?
<jtv> Very.
<wgrant> POSTs are not permitted to be retried automatically.
<wgrant> At the browser-level.
<jtv> This is chromium though.  Full of optimizing cleverness.
<wgrant> Heh
<jtv> BTW I see now that I expressed myself badly:
<lifeless> I know what you meant
<jtv> I meant, I don't suppose the browser would retry the POST just because it did not get an unambiguous application-level failure response.
<lifeless> and yes I think post-commit retry is the most plausible epxlanation
<wgrant> jtv: How did you file those bugs?
<jtv> wgrant: could you be more specific?
<wgrant> I only see one bug filing in the appserver logs, and that was 90 minutes ago.
<wgrant> Are you using edge or something?
<jtv> Nope.
<lifeless> wgrant: appserver bug
<lifeless> wgrant: we retry requests in the appservers.
<lifeless> wgrant: on POST, on conflicts.
<wgrant> lifeless: The bug in question was filed only 30 minutes ago.
<wgrant> I do not see even one POST for it.
<lifeless> wgrant: that is how it was posted, no ?
<lifeless> oh, I see 90 vs 30
<lifeless> wgrant: you've got all the appservers ? :>
<lifeless> actually. EOD. EOW. SOL.
<wgrant> lifeless: Good plan. See you eventually, I suppose. Good luck!
<jtv> lifeless: enjoy your weekend.
<wgrant> jtv: Weekend?
<jtv> wgrant: yes, it's that bit where the office goes nice and quiet so you can work in peace.
<jtv> When that happens, the rest of us are having something called a week-end.
<lifeless> wgrant: I think jtv is  being sensible about disclosure of private data
<wgrant> Bah.
<lifeless> which is nice
<wgrant> I wonder if puppet broke stuff.
<wgrant> Not all the logs are here.
<wgrant> Probably means we're missing OOPSes, too.
<lifeless> that vould be a vorry
<wgrant> But not surprising.
<lifeless> hangon, I was going.
<wgrant> See you.
<lifeless> wgrant: I'm pushing up my gpfixtures WIP for LP
<wgrant> lifeless: I may have a poke at it and get it finished.
<lifeless> lp:~lifeless/launchpad/usegpgfixtures and of course lp:python-gpgfixtures
<lifeless> it needs a ServerFixture to invoke the process etc, which would live in python-gpgfixtures for now. Its not a perfect demo of the soa test fake layout.
<lifeless> perhaps it should be, but one step at a time
<wgrant> Yeah.
<wgrant> Anyway, shoo.
<lifeless> both branches pushed.
<lifeless> enjoy.
<wgrant> Thanks.
<lifeless> heh, the keyserver in fixtures is shorter than the one in LP; including the main() stuff and the json API.
<lifeless> \o/
<wgrant> Nice.
<lifeless> not a totally fair comparison, but shrug
<StevenK> Right, Jenkins is in money-suck mode
<danilos> jtv, hi, can you perhaps give me another short review, mostly for a branch you've already reviewed: https://code.launchpad.net/~danilo/launchpad/bug-826692-take2/+merge/72996 (it was broken for private branches, and the fix is easy, and I add a test for it)
<danilos> jtv, you can perhaps just look at the incremental diff in http://paste.ubuntu.com/675046/
<jtv> danilos: okay okay, you've sold me.  Don't try to buy it back.  :)
<danilos> heh, thanks
<wgrant> danilos: Given its history, you might want to coerce a LOSA to merge that on staging so you can try it out for real.
<danilos> wgrant, sure, though when you do anticipate a problem (or when there are tests for it), it makes a big difference :)
<wgrant> danilos: Bah, who needs tests.
<danilos> not us the real men! our test suite are our users
<danilos> wgrant, what was the commercial team name again? I need to find who can make me a few private branches on staging
<jtv> danilos: âMerge proposals against private branches are visible to *the* branch owner.â
<wgrant> danilos: ~commercial-admins and LOSAs.
<wgrant> danilos: I have access to U1 branches, if that helps.
<danilos> wgrant, are they on (qa)staging? I have access to landscape branches, but they ain't there
<wgrant> danilos: The content doesn't matter, does it?
<danilos> jtv, thank you :)
<jtv> danilos: is this the branch that caused (some of) those 93 failures and 17 errors we had in devel earlier?
<wgrant> The DB stuff is there, and that's all that matters.
<danilos> wgrant, nope, I just need merge proposals against them
<danilos> jtv, nope, the reversion of this branch and gary's revision using some of the stuff in this branch is what caused the failures
<wgrant> danilos: gary reverted that before you emailed me, btw.
<danilos> wgrant, it is? oh right, logging in might help see them
<jtv> danilos: oh, I heard about those but didn't think it was the same failure.  There are far too many lately.  :/
<danilos> jtv, this is just a regular distributed development fallacy, I don't think there's anything we could do about it except make the test suite run shorter thus reducing the chances of something like this happening
<wgrant> danilos: I agree that that's about all we can do.
<danilos> wgrant, yeah, I've seen that as well, sorry if I bothered you :)
<jtv> danilos: for a moment I thought you were saying I was completely wrong, but now I suspect "fallacy" isn't really the word you meant.  :-)
<wgrant> If we had a one hour test suite again (which is practical with parallelisation), the occurrence and impact of this sort of thing would be far, far lower.
<jtv> Yes.
<jtv> Although the past few days, Q/A has played a large role as well.
<wgrant> jtv: That's made worse by the fact that QA can rarely happen until 10 hours after the branch is submitted.
<wgrant> Which means a lot more breakage can slip into devel before it's noticed, and it's less likely to be noticed because the wrong people are doing it.
<jtv> Absolutely.  Getting a branch from submission to Q/A readiness is still an overnight process.
<jtv> Which reminds me of another suspect in our current problems: staging updates.
<wgrant> What staging updates?
<wgrant> It hasn't updated in a while :)
<danilos> :)
<jtv> Oh well that's alright then.  :)
<wgrant> The ticket is only 85.. we should probably get it bumped.
<jtv> danilos: I rejected the MP based on the missing "the" in the comment.  Please try again Monday.
<danilos> jtv, fair enough, thank you very much, I'll be back on Monday
<danilos> (I'll go spend weekend fixing all the missing articles in the LP tree, however you take that ;)
<jtv> np
<jtv> danilos: *the* weekend.  You did that on purpose, didn't you?
<danilos> spend the weekend?
<jtv> Yup.  :)
<danilos> heh, yeah, I can usually find them missing only on re-reading the sentence, and that never happens with comments for tests :P
<LPCIBot> Project devel build #998: STILL FAILING in 16 min: https://lpci.wedontsleep.org/job/devel/998/
<StevenK> Uh
<StevenK> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/9e62132dbdc7acb42f1156c7a4128cf2.pack is redirected to https://launchpad.net
<StevenK> RARGH
<wgrant> Yay
<lifeless> wgrant: -  1. [[#william_grant|William Grant <me {_AT_} williamgrant.id.au>]] ''(133 top-level landings)''
<lifeless> +  1. [[#william_grant|William Grant <me {_AT_} williamgrant.id.au>]] ''(134 top-level landings)''
<lifeless> wgrant: lies
<wgrant> lifeless: I merged a rev from a branch from December :)
<StevenK> Haha
<wgrant> I thought I cherrypicked it.
<wgrant> But apparently not well enough.
<wgrant> Ah, it was the first rev in the branch.
<wgrant> lifeless: Are you here?
<wgrant> lifeless: If so, a prio bump on https://rt.admin.canonical.com/Ticket/Display.html?id=47551 would be nice, since staging hasn't restored for two weeks now and we'll likely be fastdowntime-capable next week...
 * 31NAAXP81 hates doc tests. too hard to debug :-(
<StevenK> Haha
<wallyworld_> shutup
<wgrant> Underscores, random characters... what next?
<StevenK> Nice nickname
<wallyworld_> i'm already way too grumpy
<wallyworld_> @%^@#%^!@^
<LPCIBot> Project devel build #999: STILL FAILING in 3.5 sec: https://lpci.wedontsleep.org/job/devel/999/
<wallyworld_> smart arse
<StevenK> Oh damn it!
<StevenK> JENKINS!
<wallyworld_> 3.5 is pretty short
<StevenK> The slave was already corrupted
<henninge> wallyworld_: Hi! ;)
<wallyworld_> henninge: hi there
<wallyworld_> i assume you saw my comments :-)
<henninge> wallyworld_: yes, thank you ;)
<wallyworld_> np. i hope they made sense
<henninge> wallyworld_: I replied rather lengthy
<henninge> very much so
<wallyworld_> ah right. i'll look at my email
<wallyworld_> henninge: right, i see the disabling of the form submit button now. and it will be re-enabled if a request build succeeds or partially succeeds?
<henninge> wallyworld_: not currently, no.
<wallyworld_> i think the original request build form did this?
<henninge> wallyworld_: AFAIUI the user is supposed to close the dialog and re-open.
<henninge> no
<henninge> it did not
<henninge> or, let me check that ... ;)
<wallyworld_> ok. i thought it was either re-enabled or else the user could click an as yet unbuilt distro series and it would be enabled
<wallyworld_> without requiring the form to be closed and reopened
<henninge> I just checked, the button is only enabled in the connect function.
<wallyworld_> s/connect/correct ?
<henninge> wallyworld_: There are other things to fix in this dialog, and also in its code but that is outside of the scope of what I am doing here.
<henninge> (which as alread widened a lot ;)
<wallyworld_> sure. i'm just a bit concerned that the button used to work a certain way but may not have kept the same behaviour]
<henninge> wallyworld_: the connect_requestbuilds function that connects the link
<henninge> actually, it is done in the click handler, when the dialog is opened
<henninge> the enabling, I mean.
<henninge> possible, but that change was before me ;-)
<henninge> s/was/happened/
<wallyworld_> perhaps
<wallyworld_> so in the case hwere the user clicks 2 out of 3 series, and the build for one of them is queued but the other has an "already building" error or something. they should then be able to click the 3rd series that was not part of the original selection and request a build
<wallyworld_> without having to close the form
<henninge> wallyworld_: I agree completely!
<wallyworld_> i'm fairly sure that's how it worked before. perhaps it has changed in a branch previous to yours. if it works diffeently now, it would be cool if a bug were raised so that we didn't forget to fix it. or if the behaviour is different because of the changes in your mp, it would be cool to see it fixed in there
<wallyworld_> sorry for being a pain in the arse
<henninge> wallyworld_: I just looked at the code previous to mine (bzr cat -r :submit) and the button is never re-enabled.
<wallyworld_> ah ok. seems like you are off the hook :-)
<wallyworld_> i'll update the mp with r=me and get jtv to mentor
<jtv> oh, hi wallyworld_!
<henninge> wallyworld_: I am about to start the fourth branch to fix this one bug about error reporting, so I will be very reluctant to add anything else to it ... ;-)
<wallyworld_> i thought that would wake yu up :-)
<henninge> wallyworld_: Thank you!
<wallyworld_> henninge: sure. any fix to the submit button warrents it's own bug
<henninge> yup, I'll file that
<wallyworld_> awesome. thanks.
<wallyworld_> jtv: over to you. it's beer o'clock for me but i'll pop back later to check on things https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-3/+merge/72908
<jtv> wallyworld_: cheers
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256
<jtv> in more sense than one
<wallyworld_> no, thank you
<wallyworld_> :-)
 * jtv gives wallyworld_ a puzzled frown
<wallyworld_> it's been along day. i've resorted to converting a doc test to a unit test so i can debug
<wallyworld_> jtv: sorry, the subtlety of my Two Ronnies reference was obviously lost
<jtv> Evidently.
 * jtv needs to catch up on his Two Ronnies.
 * wallyworld_ opens a bottle and drinks :-)
<wallyworld_> ahhhh
<jtv> And "resorted to" converting a doc test to a unit test?  You deserve, if not a medal, then at least a cool beer!
<wallyworld_> yep :-)
<jtv> Wow, that was timely
<wallyworld_> still only 3/4 of the way through
<wallyworld_> frustrating day today
<jtv> wallyworld_: this'll cheer you upâ¦ <compose>34
<henninge> jtv: Â³Â¼?
<henninge> wallyworld_: bug 834463
<_mup_> Bug #834463: Re-enable submit button in request builds overlay. <Launchpad itself:Triaged> < https://launchpad.net/bugs/834463 >
<jtv> henninge: that's cheating!  You did <compose>^3<compose>14, didn't you?
<henninge> jtv: well, I think "Alt Gr" is the compose key on the German keyboard and if I hold it down an press 34, I get Â³Â¼
 * jtv fondly remembers the can't-get-used-to-metric-but-we'll-give-decimal-a-go Â²Â²/ââ pricing at US petrol stations.
<wgrant> henninge: Alt Gr is not quite the same thing.
<wgrant> It's just a third set of characters, AIUI.
<wgrant> Compose is a little more powerful :)
<jtv> But good to know there's yet another standard to confuse things.  âº
 * henninge hates to be lacking power â¦ :(
<wgrant> henninge: I don't know of any layout that has a "Compose" key. In Ubuntu, at least on US keyboards, you have to configure it manually. I use RAlt.
<henninge> ah, I see
<wgrant> It is displeasing that there is not one configured by default.
<henninge> RAlt *is* Alt Gr
<wgrant> But perhaps there are people around who use RAlt or Menu for their traditional purposes.
<soren> For many European keyboard layouts, RAlt is already special.
<henninge> We need it here for {[]}â¬~
<soren> The menu key... Not so much.
<henninge> oh, and for \
<henninge> one more reason to hate DOS paths
<wgrant> At least it's not a French keyboard.
<wgrant> rvba is a bad person.
<wgrant> German keyboards aren't actually too bad.
<wgrant> But French, aaaaaaa
<rvba> wgrant: I think you did very well with a French keyboard. I shall bring you one next time we meet :)
<henninge> I can live with it
<henninge> :-D
<jtv> What happens when you try to type qwertz on an azerty keyboard?
<jtv> You probably turn Alsatian.
<adeuring> good morning
<jtv> hi adeuring
<adeuring> hi jtv!
<mrevell> Mornin'
<jtv> hi mrevell
<wgrant> henninge: 404
<henninge> wgrant: yes, that's the point ;)
<wgrant> Ah!
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 243 - 0:[#######=]:256
<henninge> Anybody know if Matt owns a baseball bat?
<mrevell> henninge, This Matt does. Is this the Matt you're looking for?
<henninge> yup
<henninge> mrevell: http://yuilibrary.com/something.html
<mrevell> heh
<bigjools> mrevell would need a cricket bat
* adeuring changed the topic of #launchpad-dev to:  #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 237 - 0:[#######=]:256
<mrevell> The unmistakable sound of willow against bugs.
<bigjools> we really need to block MPs on vcs imported branches
<wgrant> Yeah.
 * bigjools files a bug
<bigjools> mrevell. henninge: the lockerz.com website has a good oops page, it's a space man floating around on the page with a message "Houston, we've had a problem!"
<henninge> bigjools: they seem to have different ones. Now I see a dog licking my screen .... ;-)
<bigjools> lol
<stub> Given we are going to have 5 minute outages a couple of times a week, if anyone is bored...
<wgrant> No reason we can't get them sub-minute :)
<nigelb> wgrant: Thanks for qa-ing :D
 * nigelb was asleep
 * wgrant needed to get a regression fix out.
<nigelb> stub: I now know exactly how you feel when your clock is messed up.
<jtv> wgrant: please tell me you fixed that brittle bzr versioning test!
<wgrant> jtv: 'fraid not.
<wgrant> Feel free to do the 5-character fix, though.
<nigelb> int()?
 * nigelb can do it right away
<jtv> Yup
<jtv> Oh thanks
<jtv> I'd be happy to review it.
<nigelb> have the bug number handy?
<nigelb> no wait, I have it
 * jtv digs
<jtv> oh
<nigelb> bug 833743
<_mup_> Bug #833743: test_versioninfo fails when system has bzr 2.4 <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/833743 >
<bigjools> wgrant: do you know if the ec2 image got updated with the deps for the xz branch?
<StevenK> Yes
<StevenK> I did it
<bigjools> thanks
<bigjools> and thanks
<nigelb> I wish the Updating diff page had ajaxy magic not forcing me to refresh every few seconds.
<StevenK> nigelb: Wait
<StevenK> It was demo'd at the epic
<nigelb> oooooooh \o/
<nigelb> I need to keep wishing for more :P
<nigelb> jtv: https://code.launchpad.net/~nigelbabu/launchpad/833743-revno-fail/+merge/73008
<jtv> nigelb: done
<jtv> nigelb: need me to land it?
<nigelb> Yes, please :)
<jtv> Well, that should fix that devel failure.  Thanks nigelb!
<jtv> adeuring: could I beg you for a review?  https://code.launchpad.net/~jtv/launchpad/bug-832661/+merge/73009
<adeuring> jtv: sure
<jtv> thanks
<wgrant> bigjools: It landed via ec2, so I hope so :)
<wgrant> bigjools: Image version 519
<wgrant> German has infiltrated the channel again :(
<bigjools> nigelb: my team will be finishing that work after we finish derived distros
<bigjools> wgrant: good. I got fed up with ec2 randomly kicking out 2 of my branches all week so I just lp-landed them.
<wgrant> bigjools: Odd, the image was fixed a day or so before it landed.
<jtv> adeuring: argh!  I just realized (because everyone keeps %$#@ distracting me) I forgot to set up the branch dependency.  That diff should be a lot smaller.
<adeuring> jtv: ah, cool :)
<jtv> Branches that were unable to land because buildbot has been near-permanently broken the past few days.
<jtv> adeuring: re-submitted as https://code.launchpad.net/~jtv/launchpad/bug-832661/+merge/73012
<adeuring> ack
<nigelb> jtv: \o/
<nigelb> bigjools: Yay!
<bigjools> nigelb: the basic code is working but we need to make it production-worthy which will be tricky as we have to set up some stat counting for Rabbit
<nigelb> ooh, rabbitmq, neat
<nigelb> did you guys deal with the HA rabbit thing that was on the list a while back?
<bigjools> yeah, once this is done we'll be able to add more async updates to pages that wait for jobs
<nigelb> something like the sync pages you guys did?
<bigjools> that sort of thing
<bigjools> we'll do popular pages first though :)
<bigjools> can't remember where we got to with HA rabbit
<wgrant> bigjools: Rabbit metrics will be pretty easy with the plugin.
<wgrant> And I think it has an HA exemption.
<wgrant> The hardest bit is probably getting OOPSes into txlongpoll.
<bigjools> yes
<wgrant> But that won't be terrifyingly difficult.
<bigjools> which plugin is this?
<wgrant> With lifeless' work this week.
<wgrant> bigjools: rabbitmq-management
<wgrant> ppa:wgrant/rabbitmq
<bigjools> ah cool, didn't know about that
<nigelb> Doesn't LP already install rabbitmq by default?
<wgrant> Has packages.
<wgrant> nigelb: Yes, but it's not actually used.
 * nigelb remembers having rabbit on his ystem
<wgrant> bigjools: It provides a web UI and JSON API with counters and rates and stuff.
<bigjools> nigelb: you can turn it off, the tests that need it will start it
<bigjools> wgrant: oh, awesome, just what we need
<wgrant> bigjools: Exactly.
<bigjools> just need to work with the losas to get that nagiosed
<wgrant> Works on Lucid->Natty, not sure about Oneiric.
<wgrant> Oneiric has 2.5, so we should probably upgrade to that everywhere.
<wgrant> Will investigate that next week.
<nigelb> bigjools: nah, I use it occasionally with other stuff
<nigelb> (like celery)
<nigelb> Oooh. I just realized. With that 5 char fix. I now have 5th non-canonical LP contributor spot.
<bigjools> LP generally need a very, very solid and easy story to communicate between components
<bigjools> or SOA will be awful
<nigelb> Heh, yeah. Fun.
<nigelb> This means writing tests for that stuff will be further fun.
<wgrant> bigjools: Well, most SOA stuff will not be through rabbitmq, but some hopefully will ebe.
<bigjools> wgrant: either way, it needs to be easy to communicate :)
<wgrant> bigjools: Indeed.
<wgrant> bigjools: At least OOPSes for WSGi apps are just about trivial now.
<wgrant> bigjools: Have you seen the zeca replacement?
<bigjools> wgrant: there's a zeca replacement?
<adeuring> jtv-afk: r=me
<wgrant> bigjools: lp:python-gpgfixtures
<wgrant> bigjools: lifeless wrote it, to be less huge and not depend on Twisted.
<wgrant> So lp:gpgverifyd doesn't need a Twisted dep.
<bigjools> cool
<jtv-afk> thanks adeuring!
<wgrant> And once gpgverifyd is up, poppy's time in the tree can come to an end.
<jtv-afk> That's it for me.  Have a good weekend, people!
<bigjools> and there was much rejoicing
<bigjools> nn jtv-afk
<wgrant> Night jtv-afk.
<nigelb> Night jtv-afk!
<jtv-afk> nn
<nigelb> Waiting for MFBT :/
<wgrant> nigelb: I see you are #5 now!
<nigelb> wgrant: I noticed! \o/
<nigelb> 3 more branches to #4
<nigelb> I landed 3 branches this week. If I keep this up, I just may have a chance to beat you :D
<wgrant> Yup.
<bigjools> activate the HIREBOT
<nigelb> lol
<wgrant> Heh.
<nigelb> Did anyone come up with stats for the LP team yet?
<nigelb> It would nice to see how outside contributors compare with the actual team :D
 * bigjools wants to eradicate security.cfg
<wgrant> nigelb: I have a branch which gets it mostly working for ~launchpad too.
<nigelb> oooh :D
<wgrant> nigelb: But for some idea, 'bzr stats' is helpful.
<nigelb> hmm
<nigelb> need to try it when I get to my computer. (at work)
<bigjools> wgrant: what is the number that stats is outputting? It doesn't say anywhere, not in the output nor the help.
<jelmer> bigjools: number of commits
<bigjools> jelmer: including all levels I guess?
<jelmer> bigjools: yep
<bigjools> jelmer: ok thanks.
<bigjools> so it shows who does local commits the most :)
<jelmer> so it's not a terribly good metric for e.g. Launchpad, given some people do a commit for each two lines they write and others only \
<wgrant> Yup.
<jelmer> a couple of times per landing
<bigjools> the one exception is Celso
<nigelb> Celso?
<bigjools> he was basically a coding machine
<nigelb> heh
<nigelb> I like commiting multiple times
<nigelb> (because I keep making stupid mistakes)
<wgrant> Ste
<wgrant> StevenK is the worst offender :P
<nigelb> lol
<wgrant> One 1100 line commit per branch or so.
<nigelb> but he uses perl to remove code
<wgrant> True.
<wgrant> Makes it even worse.
<nigelb> That's cheating :D
<bigjools> it needs to be weighted by lines per commit
<jelmer> it'd be hard to distinguish between actual lines changed and lines moved
<bigjools> yeah it's not perfect but better than just commits I think
<bigjools> ok I need help because security.cfg is such a monstrosity I have no idea what tables I need to add to it so my process can close a bug
<bigjools> how do I ascertain what I need?
<wgrant> Hahaha
<bigjools> this is a leading question :)
<wgrant> Look at process-accepted
<bigjools> I am
<bigjools> but ...
<bigjools> you see where I am driving with this?
<wgrant> Yes, it's hard.
<wgrant> Partly because LP grew into a 700KLOC monstrosity.
<bigjools> security.cfg just needs to die
<wgrant> I'm not sure whether it's worth it.
<wgrant> But it would be a lot easier if it wasn't all one thing.
<bigjools> given that the webapp has carte blanche anyway, why are we restricting scripts?
<wgrant> I can only think of a couple of bugs that have been revealed by the restrictions.
<bigjools> ok how evil is it to inherit queued in sync_packages?
 * jelmer remembers a few incidents with security.cfg being too strict
<bigjools> because I simply cannot be arsed to work this out
<bigjools> jelmer: indeed
<bigjools> it just seems to cause problems, not solve any
<wgrant> Only a few? :)
<bigjools> we could do something more intelligent in security.cfg and have groups that represent actions, not scripts
<wgrant> I've been considering that for a while.
<bigjools> there's a little of that already - well done to whoever made "translations_approval"
<wgrant> I don't think there need to be too many.
<wgrant> Since bug actions need like 20 tables, that probably covers a lot of the lcutter.
<bigjools> well since PCJ does all of what queued does, I am going to inherit it, screw it
<wgrant> Sounds like a plan.
<wgrant> A not very good plan, but an effective one :)
<bigjools> I'd rather it was too wide than too narrow
<wgrant> Indeed.
<bigjools> I'm really not sure what we are achieving with the permissions
<LPCIBot> Project devel build #1,000: STILL FAILING in 4 hr 48 min: https://lpci.wedontsleep.org/job/devel/1000/
* bac changed the topic of #launchpad-dev to:  #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 237 - 0:[#######=]:256
<bac> good morning adeuring
<adeuring> good morning bac!
<henninge> Anybody got an idea why the LibrarianLayer might be failing locally like this? http://paste.ubuntu.com/675201/
<bigjools> henninge: clear out /var/tmp stuff
<bigjools> including pid file
<henninge> bigjools: I don't see anything testrunner or launchapd specific in /var/tmp
<henninge> the only pid file was development-google-webservice.pid
<mrevell> le
<mrevell> matsubara, hey mumble?
<matsubara> mrevell, hey, yes!
<wgrant> henninge: Chameleon does some very evil stuff; I need to talk to gary_poster about removing that or it.
<wgrant> henninge: dpkg -S setuptools.egg-info
<wgrant> Oh, gary_poster is here.
<wgrant> gary_poster: Hi.
<gary_poster> wgrant, on call will ping
<wgrant> k
<wgrant> henninge: Which Ubuntu release has this machine been upgraded from?
<wgrant> henninge: I suspect you have a non-dpkg-managed /usr/lib/python2.6/setuptools.egg-info, as we found on loganberry and several other production machines.
<henninge> wgrant: from maverick to natty
<wgrant> henninge: We deleted it, and everything worked.
<wgrant> henninge: Hmm.
<wgrant> So, /usr/lib/python2.6/dist-packages/setuptools.egg-info is meant to be a symlink.
<wgrant> I suspect it's a directory on your machine.
<henninge> python-setuptools: /usr/lib/python2.6/dist-packages/setuptools.egg-info
<henninge> python-setuptools: /usr/lib/python2.7/dist-packages/setuptools.egg-info
<henninge> python-setuptools: /usr/share/pyshared/setuptools.egg-info
<gary_poster> wgrant, I'm aware of one evilness--z3c.ptcompat is perhaps the hairiest Python I've ever seen. Perhaps.  It sounds like you have another?
<gary_poster> z3c.ptcompat can eventually go
<gary_poster> which was why I was not overly worried about that one
<wgrant> gary_poster: I invite you to read the top of chameleon/template.py
<gary_poster> heh, ok, going wgrant
<cjwatson> there are problems with migrating dpkg-managed filesystem entries between symlinks and directories - it has to be done by manual maintainer script code (for some excellent reasons)
<wgrant> gary_poster: It hashes, in undefined order, the versions of every package it can find on the system.
<cjwatson> unfortunately .egg-info entries became one or the other at the whim of complex build systems
<cjwatson> (i.e. a simple rebuild could change without any obvious reason in the source package)
<wgrant> cjwatson: Yay
<cjwatson> it's probably simplest to rm -rf the .egg-info file in question and then reinstall the package that owns it
<wgrant> cjwatson: Interestingly, on the production machines the package was no longer installed.
<wgrant> I presume it was removed after the upgrade.
<wgrant> But didn't remove the directory, because it was meant to be a symlink.
<cjwatson> that's a bit harder to explain, but perhaps if dpkg expects it to be a directory it uses rmdir not unlink
<cjwatson> rather than unlink => if EISDIR rmdir
<wgrant> Yeah.
<wgrant> Anyway, on production where it's been a problem we've just deleted the directory, and reinstalled the package if it was still installed.
<wgrant> All seems happy.
<wgrant> But that part of Chameleon really worries me.
<gary_poster> wgrant, that's nothing compared to z3c.ptcompat, IMO. :-P
<gary_poster> Anyway, the undefined order is probably barely alright practically for what the purpose appears to be, which is to enforce some kind of "rebuild when things change," given that the undefined order is stable in a Python release, and a new Python release ought to trigger this kind of thing anyway.
<gary_poster> But we certainly can and should convince the person to order them.  Beyond that, given that Chameleon is a compile-to-Python template system, the basic idea strikes me as reasonable, within the context of the kind of task Chameleon has set itself to.
<wgrant> gary_poster: It is revolting and causing cronspam and breaking the test suite. I guess we may need to clean up all production and dev machines.
<gary_poster> wgrant, "revolting" is a wildly unnecessary description, IMO, not that I have anything to do with it. Just seems unproductive to talk that way. Causing cronspam I saw; it is because of broken packages in our distro's packaging system, which is a chronic and annoying problem for anyone who does work with system Pythons.  I have not seen a broken test suite.
<gary_poster> wgrant, practically, what machines have been taken care of?
<cjwatson> somebody should file an Ubuntu bug about that python-setuptools problem if they haven't already; we should be able to take care of it in an update
<cjwatson> if you can't rely on system packages, that's a pretty serious problem from our POV
<gary_poster> cjwatson, when I've experience this in the past, I was unable to identify a cause.  My suspicion has been distro upgrades not cleaning things up properly.
<cjwatson> gary_poster: I've roughly outlined the cause above.
<cjwatson> gary_poster: a bug about the fact of the problem is sufficient
<gary_poster> I have no hard evidence to support this and have been unable to dupe reliably, so it's the kind of...ok OK!  Great, cjwatson, I'll read the backlog and file it then.  Thanks
<cjwatson> (or at least, the very likely cause)
<gary_poster> heh, good enough
<cjwatson> we can go through the history and hunt for symlink<->directory chnges
<cjwatson> *changes
<cjwatson> I agree it's likely to be a pain to come up with a coherent reproducer for
<cjwatson> but let's not burn too many people's time on that when we have a pretty good hypothesis
<gary_poster> +1
<wgrant> cjwatson: I tried a clean hardy->lucid upgrade with python-setuptools installed, and it worked fine.
<wgrant> But AFAICT on loganberry that's what broke it.
<wgrant> It's possible there was some old launchpad PPA package, though... I don't have logs to find out.
 * cjwatson will have a quick hunt through publishing history
<gary_poster> cjwatson, wgrant, https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/834698
<_mup_> Bug #834698: setuptools.egg-info can end up as a directory when it is meant to be a symlink <python-setuptools (Ubuntu):New> < https://launchpad.net/bugs/834698 >
<wgrant> It's not just setuptools. That's just the most common one.
<wgrant> Ah, you say that in the bug.
<gary_poster> yeah
<wgrant> bigjools: Oh, you're using changelog_entry to create the aggregate changelog?
<wgrant> bigjools: I was expecting to use the real librarian changelog, but I guess that's probably OK...
<wgrant> Except not.
<wgrant> It's bad.
<wgrant> It searches for all SPRs in any context, doesn't it?
<bigjools> yes, hmm
<bigjools> I thought that was ok but maybe not
<wgrant> It'll count all PPA uploads, Ubuntu uploads, Linaro uploads, etc.
<bigjools> yes
<wgrant> As well as the general badness and unreliability that changelog_entry entials.
<wgrant> entails.
<bigjools> what is wrong with changelog_entry?
<wgrant> It is a guess.
<wgrant> A historically error-prone guess.
<bigjools> can you be a bit more explicit?
<wgrant> Let me find some bugs.
<wgrant> I'm looking :)
<wgrant> Ah, it's change_summary that is the cause of bug #144620. But changelog_entry for the gina case is a guess, and for Ubuntu it is frequently wrong because people build packages badly.
<_mup_> Bug #144620: Some displayed sourcepackagerelease changes files don't have attribution <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/144620 >
<wgrant> Worse still, if Linaro then copy from Ubuntu, they will miss everything.
<wgrant> Because Ubuntu only has the last SPR.
<bigjools> doesn't matter does it?
<wgrant> Why not?
<bigjools> it's only for acceptance emails
<bigjools> it's right that each SPR has only its changelog
<bigjools> what sync-source does is crack
<wgrant> Er, no :)
<bigjools> can you try to be less condescending?
<wgrant> An upload's changes file is meant to contain all the intermediate changelog entries.
<wgrant> Acceptance emails should too.
<wgrant> So they actually list the changes.
<wgrant> And not just the last change.
<wgrant> And isn't this to be used for bugs too?
<wgrant> If we restrict the SPR search to those published in the origin archive, Debian->Ubuntu copies will work.
<wgrant> But Debian->Ubuntu->Linaro copies will magically only have the last SPR.
<wgrant> So the acceptance emails will be truncated, and not enough bugs will be closed.
<wgrant> This is easily solved by just using the actual changelog, I think.
<bigjools> including previous version's changelogs in a particular SPR is weird
<wgrant> We shouldn't include them in the SPR.
<wgrant> We should consider them as part of the upload/copy.
<wgrant> That's the whole point of this change, isn't it?
<wgrant> To include more than just the actual SPR that is being copied.
<bigjools> correct
<wgrant> To do that only for the first copy seems less than ideal.
<henninge> deryck, abentley: From the w3c spec:
<henninge> 10.4.1 400 Bad Request
<henninge> The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
<wgrant> Particularly when changelog_entry is a reasonably awful thing in the first place, and we have the changelog file a couple of milliseconds away.
<henninge> But I will still use 400 if that is how we do it around here ... ;-)
<bigjools> what does gina put in changelog?
<abentley> henninge: right.  The HTTP spec provides no way to signal that the request was unacceptable for reasons other than bad syntax.
<wgrant> bigjools: I think it puts everything between the last SPR published and the current one.
<StevenK> wgrant: Personally, I'd like to kill changelog_entry
<deryck> henninge, I don't think it's a perfect match, but it's close enough.  the spec makes me feel better about it actually. :)
<wgrant> StevenK: I very much would.
<henninge> abentley: because it was not unacceptable.
<wgrant> StevenK: It is very wrong in the new world.
<wgrant> StevenK: Because it depends on the previous publication.
<abentley> henninge: it was unacceptable.  The request could not be performed.
<wgrant> It's really part of the upload, not the source package.
<henninge> abentley: no, it was performed, at least in part
<StevenK> And even so, we don't even keep the .changes file around
<wgrant> StevenK: We do...
<henninge> abentley: I would expect a 4xx to mean that nothing was changed on the server.
<wgrant> StevenK: We strip the sig, but we keep the changes file for every well-formed upload.
<abentley> henninge: perhaps we differ on what "perfomed" means.
<wgrant> henninge: As would I.
<henninge> but as I said, I am not going to go against our customs here ...
<henninge> ... at least not in this branch.
<henninge> wgrant: oh, so you are aware of our misuse of 400s? ;-)
<wgrant> bigjools: I think changelog_entry is a near-adequate compromise for displaying in the web UI sometimes, but we should avoid it where possible. And it's now possible to go direct to the changelog and get a correct result, so we should do that.
<wgrant> henninge: No :(
<wgrant> henninge: Where? :(
<henninge> everywhere, so I am told.
<bigjools> wgrant: I am verifying what gina does, I don't trust it
<wgrant> henninge: Most 400s should abort the transaction, so the only server changes will be sessions and OAuth nonces...
<wgrant> henninge: Is that not the case?
<wgrant> bigjools: It is not trustworthy.
<wgrant> bigjools: But I think it looks at the last published SPR, and takes the entries since then.
<bigjools> and looking at gina code makes me want to scratch my eyeballs out
<wgrant> bigjools: To do anything else would make little sense.
<henninge> wgrant: nope, at least not for the case I got here.
<cr3> does that apache configuration for serving static files on launchpad do anything special for etags?
<wgrant> cr3: gary_poster changed all that to be much better recently, I believe.
<wgrant> henninge: Which is that?
<henninge> wgrant: it returns a 400 if not all builds for a recipe could be requested.
<wgrant> Ahh.
<cr3> wgrant: might that be available somewhere for me to see?
<wgrant> cr3: I'm hoping gary_poster will be able to tell you :)
<wgrant> henninge: That sounds bad to me.
<cr3> wgrant: lets mention his nick, gary_poster, as often as possible to get his attention :)
<wgrant> henninge: I would assume that a 400 meant no changes had been made.
<henninge> no need to convince me ... ;-)
<wgrant> I guess the really corect thing to do is use a 207... but aaaaaaaaa
<bigjools> this Gina code makes me want to go back to C++
<gary_poster> wgrant, cr3, hiya :-)
<wgrant> bigjools: gina does not age well.
<henninge> deryck: I think abentley understood that situation.
<bigjools> it's hideous
<wgrant> bigjools: Although it wasn't ideal in the first place either, no.
<gary_poster> cr3, yes, it does do something special for ETags
<wgrant>             # XXX kiko 2005-11-05: this is very funny.
<gary_poster> heh
<cr3> gary_poster: awesome, could I have a looksee at the apache config?
<abentley> henninge: Well, not completely, but I do feel that if it wasn't completely successful, the status code should reflect that.
<bigjools> wgrant: where is it checking to see what was previously published?
<abentley> henninge: ideally, we'd have a separate status for each request.
<wgrant> bigjools: It's not.
<wgrant> bigjools: It just takes the first entry.
<bigjools> oh. yay
<wgrant> bigjools: This is, as we say, "wrong".
<bigjools> so my hunch was write
<bigjools> ffs
<bigjools> right
<wgrant> bigjools: changelog_entry is not to be trusted. It doesn't really belong on SPR at all.
<bigjools> ok so I will switch to changelog
<wgrant> bigjools: It's mainly there to permit fast access for views, and because we didn't store changelogs in the librarian.
<wgrant> We should remove it from everywhere we can.
<bigjools> but I think I still need to parse backwards through what's published
<wgrant> ... starting with this code that will DoS everyone if I upload 100 packages with similar versions to a PPA :)
<wgrant> bigjools: See the base version calculator.
<henninge> abentley: that would either mean the 207 or making seperate xhr requests for each build.
<wgrant> bigjools: It walks through them until it sees the common ancestor.
<bigjools> I need to go and lie down
<gary_poster> cr3, that's a question for the LOSAs, I don't have it.  I can tell you that we generate ETags for launchpad API docs and WADL and JSON; it is tied to file size and mtime; we synchronize mtime for these files based on the last bzr revision so that it should be stable across machines that share the same revision
<wgrant> bigjools: python-debian makes it fairly trivial.
<henninge> abentley: We can file a bug to fix that. ;-)
<bigjools> we store last common version
<abentley> henninge: yeah, 207 seems the most reasonable.  I didn't know about that RFC.
<wgrant> bigjools: Actually, IIRC we create a set of the common versions, and take the max. You need to do the same, but then walk back through the entry iterator until you hit that version.
<gary_poster> cr3, I'm not sure if the Apache file will tell you more than that; and I'm only familiar with the api.[qastaging.|staging.|edge.]launchpad.net rules
<wgrant> It'll be pretty painless once you realise how awesome python-debian is.
<bigjools> what iterator?
<wgrant> bigjools: the changelog entry iterator from python-debian.
<wgrant> s/iterator/generator/
<cr3> gary_poster: thanks, that's definately something I can grep in launchpad but I'll still ask for the apache config in #launchpad-ops out of curiosity. I'm sure there's a trick or two I can learn
<bigjools> hang on
<gary_poster> cool cr3
<wgrant> cr3: Default Apache etags are generated from inode number, mtime and size.
<gary_poster> yup
<wgrant> cr3: inode number obviously isn't portable between machines.
<wgrant> cr3: But if you reconfigure FileETag and make sure your mtimes are the same, the etags will match across machines.
<wgrant> bigjools: Check DSD._updateBaseVersion
<wgrant> And the getAncestry that it calls.
<bigjools> I need to step back from this
<bigjools> it's not straight to me exactly what needs to happen any more
<matsubara> adeuring, bac: hi there, are you available for a review? https://code.launchpad.net/~matsubara/python-oops-datedir-repo/improve-db-statement-matches/+merge/73059
<bigjools> what I need is an example case
<adeuring> matsubara: sure, I'look
<wgrant> bigjools: Do you know how sync-source.py does this?
<matsubara> thanks adeuring
<wgrant> bigjools: It does it the same was as normal uploads: it calls dpkg-genchanges with -v$LATEST_VERSION_IN_UBUNTU.
<wgrant> This causes dpkg-genchanges to include in the changes file all changelog entries strictly later than $LATEST_VERSION_IN_UBUNTU.
<gary_poster> cr3, now a question for you. :-) could you either make ~launchpad the admin of https://launchpad.net/launchpad-results , add ~launchpad to ~launchpad-results ?  Since it is part of the Launchpad project, we are responsible for triaging bugs
<wgrant> Or remove launchpad-results from launchpad-project, possibly.
<gary_poster> s/ add / or add/
<gary_poster> yeah that too
<cr3> gary_poster: I think the problem with that is that I'm not a member of ~launchpad which might prevent me from working on the project, but please correct me if I might be wrong :)
<wgrant> Since it's not code managed by our team, it probably shouldn't be in launchpad-project.
<gary_poster> cr3, yeah that leaves you two options
<cr3> wgrant: I was following the process here though: https://dev.launchpad.net/CreatingNewProjects
<bigjools> wgrant: you're not talking about my aggregate changelog stuff any more are you?  you're talking about gina?
<wgrant> cr3: That's for split-out parts of Launchpad.
<gary_poster> cr3, I agree with wgrant that maybe it should not be in launchpad-project.  Alternatively, if you add ~launchpad to ~launchpad-results, at least everyone responsible would be able to to what they need.
<wgrant> bigjools: They are intertwined, but I'm not talking about gina at all now.
<bigjools> why are you talking about parsing changelogs then?
<wgrant> bigjools: Because traditional syncs do that.
<gary_poster> cr3, but unless there's a good reason to have it be part of launchpad-project, again, I agree with wgrant
<wgrant> bigjools: That's the baheviour we're trying to emulate.
<cr3> gary_poster, wgrant: I have a call scheduled with lifeless later today, I'll add that to the agenda depending on where we want to go with the project
<gary_poster> cool cr3
<bigjools> wgrant: which requires fixing in gina AIUI
<wgrant> bigjools: Not if we make native syncs parse the changelogs too.
<cr3> I'm easy either way, I did feel strange seeing the launchpad folks getting bug reports about the project so I feel your pain :)
<bigjools> euargh
<gary_poster> for now then, cr3, perhaps you could simply triage https://bugs.launchpad.net/launchpad-results/+bug/833854 ? :-)
<_mup_> Bug #833854: Unable to submit results with results2launchpad on natty <Launchpad Results:Confirmed> < https://launchpad.net/bugs/833854 >
<wgrant> bigjools: Classic/legacy/traditional/ohgodgoaway syncs don't use changelog_entry. They create a normal upload, which parses the changelog to work out which entries to include in the changes file.
<bigjools> wgrant: you said that gina doesn't import all of the changelog
<wgrant> bigjools: Right.
<bigjools> so we can't parse it
<cr3> gary_poster: fair enough, done :)
<wgrant> bigjools: But that's not too relevant if we ignore gina.
<gary_poster> thanks cr3 :-)
<wgrant> bigjools: No, it doesn't import all of the changes into *changelog_entry*.
<wgrant> bigjools: debian/changelog is imported into the librarian verbatim.
<wgrant> bigjools: There is no possible error there.
<bigjools> wgrant: ok *that* is what was confusing me
<wgrant> bigjools: changelog_entry is generated based on a dodgy heuristic.
<bigjools> let's ignore changelog_entry then
<wgrant> Yes :)
<bigjools> assume changelog is complete
<wgrant> If it's not, then it's still not a regression from the old method.
<wgrant> Because normal uploads and legacy syncs just parse the changelog.
<bigjools> I'm not convinced that changelog parsing is needed
<bigjools> if gina makes a composite one for a particular import then we never saw the oldver versions anyway
<wgrant> bigjools: If you fix gina to make a composite one, then maybe.
<wgrant> bigjools: But using the real changelog is definitely safer, and probably easier.
<bigjools> wgrant: hang on
<bigjools> right, I think I am finally tuned in.  I need more sleep.
<wgrant> Perhaps I should change the docstring of changelog_entry to "Red herring."
<wgrant> bigjools: Anyway, you should probably revert that revision.
<wgrant> Or things could get *very* confusing and noisy.
<bigjools> hmmm
<wgrant> I mean, the current implementation is clearly practically flawed.
<wgrant> Because it will pick up PPA uploads etc.
<bigjools> it will yes
<bigjools> a bad oversight
<wgrant> Hmm. I wonder what happens if I delete a package and copy it back in. I guess it includes every SPR ever seen by Launchpad.
<wgrant> That could be amusing.
<wgrant> With the right SPN, that is.
<wgrant> I suppose I should sleep at some point.
<wgrant> bigjools: You're not around Monday, I suppose?
<bigjools> wgrant: I am actually
<wgrant> Oh.
<wgrant> I thought it was a holiday.
<bigjools> it is but I swapped it
<wgrant> Ahh.
<adeuring> matsubara: r=me
<matsubara> thanks adeuring
<wgrant> Night all.
<bigjools> night
<matsubara> adeuring, I have another one from oops-tools which is related to that MP: https://code.launchpad.net/~matsubara/oops-tools/829460-typeerror-qsmmx/+merge/73062 could you take a look as well, please?
<adeuring> matsubara: sure
<cr3> gary_poster: you mentionned generating etags for api, wadl and json. however, I'm seeing an oddly short etag for .css files, for example, and I'm not seeing anything about FileETag in the apache configuration nor anything special in the launchpad code, any ideas where I should look?
<adeuring> matsubara: kiko has a good point about your mp
<matsubara> adeuring, yep, I'll reply to kiko's comment. Apart from that, are there other things to change in the mp?
<adeuring> matsubara: no, otherwise, the MP looks good
<matsubara> adeuring, cool. I'll grab some lunch and sort this out afterwards. thanks for the review!
<adeuring> matsubara-lunch: enjoy lunch!
<adeuring> matsubara-lunch: note that I'll have EOD in about an hour, and I'll leave home then
<LPCIBot> Project devel build #1,001: STILL FAILING in 4 hr 4 min: https://lpci.wedontsleep.org/job/devel/1001/
<gary_poster> cr3, I don't know.  I haven't touched ETags for CSS, at least intentionally
<cr3> gary_poster: I think I found what's going on: seems to be a server context FileETag config I'm not seeing in the launchpad virtualhost. I'm double checking with chex just to make sure
<cr3> that's all I could assume being from the outside looking in :)
<gary_poster> hm, ok cool cr3
<cr3> can someone help me rationalize what goes under lp.services? for example, I would tend to think there shouldn't be anything that depends on a database layer there, but that probably means I don't get the purpose of that namespace
<gary_poster> abentley, you looked at https://answers.launchpad.net/launchpad/+question/167859 last week.  We have two almost identical SourceForge subversion branches, one of them importing and one of them not.  I tried the failing one locally and it worked fine.  I was thinking of asking LOSAs to clear out past attempts to see if that would help somehow.  Does that sound reasonable, and/or do you have a better idea?
<gary_poster> cr3, I think of it as "general-purpose sorts of things go here, like things that might go into a library, or things that are LP-specific but used as tools throught the code base."  That said, I'll deny everything if you claim I told you anything about this. ;-)
<gary_poster> abentley, I spoke too soon.  The local checkout eventually failed after almost completing with "bzr: ERROR: A Subversion remote access command failed: REPORT of '/svnroot/ifolder/!svn/vcc/default': SSL handshake failed: Secure connection truncated (https://ifolder.svn.sourceforge.net)"
<gary_poster> Perhaps I should assign this to Jelmer?
<abentley> gary_poster: makes sense.
<gary_poster> ok thanks
<abentley> sinzui: I think I found a bug in addMember: http://pastebin.ubuntu.com/675383/
<sinzui> yes you have
<sinzui> oh, hold on
<sinzui> approved is a member, invited is not. how can that happen. I think approved would have to go to deactivated first
<abentley> sinzui: or you could consider it a bug in the browser code.
<sinzui> abentley, is this a case where I add a team twice? Once I invite, the other party accept and the state goes to approve, but invite the team again. This should be a no op. there is nothing to do and no status should change
<abentley> sinzui: yes, this is adding a team twice.
<abentley> sinzui: how much of a no-op should it be?  would we still reset the expiration date, etc?
<sinzui> I would not think so
<sinzui> I understand your point, but I do not think that is a way team admins force renewals. Lp sends them out and the other team accepts them. If the admin wanted to extend the expiration date, he can do that from +members
<abentley> sinzui: Is there a legitimate way for a team to become PROPOSED? I can do it using force_team_add.  If so, should the transition from PROPOSED to INVITED legitimate?
<sinzui> A team is proposed when the admin of the team is the user doing the add.
<sinzui> abentley, proposed -> invited  should not happen. That action is an implicit acceptance by admins of both teams of the user, so I expect the membership to be approved
<abentley> sinzui: ISTM that if the admin of the target team then attempts to add the team, the status should go to APPROVED?
<sinzui> we agree
<gary_poster> Anyone else getting lots of errors in ec2 tests with complaints like this?
<gary_poster> [<bzrlib.lockable_files._LockWarner object at 0x142dc510>]
<bdmurray> what's the url that contains info regarding staging's database updates?
<gary_poster> bdmurray, getting it for you, and it hasn't bee since the 15th IIRC.
<bdmurray> gary_poster: okay, I thought I'd put the url in https://help.launchpad.net/StagingServer
<gary_poster> explanation, btw, from stub: "the account running the update has lost its
<gary_poster> sudo access, probably puppet fallout. I've opened RT #47499"
<_mup_> Bug #47499: Sources.list are set to Australia <Ubuntu Express:New> < https://launchpad.net/bugs/47499 >
<gary_poster> bdmurray, is this what you had in mind? https://staging.launchpad.net/successful-updates.txt
<bdmurray> gary_poster: yes firefox wasn't helping me remember it
<gary_poster> cool
<abentley> sinzui: with my changes, I think I can prove that TeamMemberAddView.add_action never triggers a TeamMembershipTransitionError.  Should the same be true for Person.addMember itself?
<sinzui> abentley, that would be nice, but I think that is impossible given that users call that via poorly written scripts.
<abentley> sinzui: ISTM that currently addMember can be used to demote someone from ADMIN to APPROVED or PROPOSED.  Does that make sense?
<sinzui> NO
<sinzui> oh
<sinzui> I think there is a related bug. maybe you found the root cause
 * sinzui looks
<gary_poster> abentley, I wonder if you could help me for a moment.  If you don't think you can do so easily, no problem; writing this has helped me gather good diagnostic information.  I was going to put it on IRC, but it was too much, so here's what I have: http://pastebin.ubuntu.com/675475/
<gary_poster> mm, lemme try making that wrap...
<gary_poster> abentley, try again: http://pastebin.ubuntu.com/675476/
<abentley> gary_poster: So when we say "garbage", we mean "stuff that the garbage collector should have collected".
<abentley> gary_poster: I have poked at this before, and my impression was that the garbage collector is not perfect.
<gary_poster> abentley, yes, I believe so.  If I had to guess, I would say that the message I see locally is not being rendered for some reason
<gary_poster> abentley, heh
<sinzui> abentley, bug 480157 which clearly states what you found
<gary_poster> abentley, can I somehow force the file that the message references to unlock?
<_mup_> Bug #480157: IPerson.addMember() should not demote admins <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/480157 >
<abentley> gary_poster: So I can take a look at that test and see if the lock lifetimes are broken.
<gary_poster> ok thanks abentley.  Please let me know if I can help.  Given that these are keeping my ec2 land from passing but they are occurring oin buildbot and not causing a stop-the-line, I guess I'll submit directly for now; I'll also shoot a quick note about the situation to the list.
<abentley> gary_poster: the test looks correct.  I think the puller really is failing to unlock the branch.
<gary_poster> abentley, so it smells like a bzr error?
<abentley> gary_poster: no.
<gary_poster> oh?
<abentley> gary_poster: it smells like a puller error.
 * gary_poster thought puller was bzr, and is corrected
<abentley> gary_poster: puller uses bzrlib.
<abentley> gary_poster: but it is part of codehosting.
<lifeless> cr3: hi
<gary_poster> ok, gotcha.  abentley, do you want me to pull on that as a matter of my own edification, or should I leave you to it?
<abentley> gary_poster: Have a look at it.  There are supposed to be symmetrical Branch.lock(read|write)/Branch.unlock calls.  It seems like they're not organized correctly.
<gary_poster> cool abentley.  I'll take a glance.  May I treat you as a mentor for this one?
<cr3> lifeless: hola senor
<abentley> gary_poster: sure.
<gary_poster> cool thanks
<lifeless> cr3: do you have skype ?
<cr3> lifeless: I might, let me have a looksee
<lifeless> or I can do voip
<abentley> gary_poster: The traditional pattern is that branch.lock_(read|write) is followed by a try/finally block that does branch.unlock.
<gary_poster> makes sense
<lifeless> I think we have a decorator too - a with write_locked(branch):
<cr3> lifeless: yep, marcatinterunion
<lifeless> IMBW
<abentley> lifeless: indeed.
<abentley> gary_poster: anyhow, you should be able to tell from the URL which branch isn't being unlocked appropriately.
<abentley> gary_poster: Oh, it might be relevant that locks are tracked on a per-instance basis.  So another instance of "default-stack-on" is probably being opened and locked elsewhere.
<abentley> gary_poster: that would be why stack_on.unlock said "LockNotHeld"
<gary_poster> abentley, hm, ok.  per instance of what?  is the puller in another process, or at least in another bzrlib instance?
<abentley> gary_poster: per instance of the branch class.
<abentley> gary_poster: class instance, not bzrlib instance or process.
<gary_poster> ah ok abentley.
<gary_poster> abentley, they shared directory names though.  That's to be exoected?
<gary_poster> expected
<gary_poster> That is, the lock file when it said "LockNotHeld" was the same
<gary_poster> path as the lock file that gc complained about
<abentley> gary_poster: that's to be expected.
<gary_poster> oh ok
<gary_poster> (that seems mystifying on the surface of it, but I don't think digging into it will be necessary.)
<abentley> gary_poster: if you open a branch twice, you get two instances of the branch class, referring to the same files.
<gary_poster> abentley, ah so the instance does not hold the lock that exists?
<gary_poster> (for another instance, and the whole multiple instance thing is presumably the whole point)
<abentley> gary_poster: I don't understand the question.
<gary_poster> yeah I think I just realized how obvious the answer to my confusion was
<gary_poster> you can have multiple class instances, each pointing to the same file.  In order to manage threads and processes and so on, bzr gives locks to its files.  When I tried to unlock the instance, the error message was not "there is no lock" but "the lock over there isn't mine"
<gary_poster> that was the obvious bit, yeah, abentley?
<abentley> gary_poster: bzrlib isn't really built with threading in mind.  The read-locking enables caching.  The write-locking pysically prevents other bzrlib clients from making changes.
<gary_poster> abentley, ack
<abentley> gary_poster: The error message was "I'm not locked", without saying anything what other objects may or may not be locked.
<gary_poster> ack
<gary_poster> abentley, well...let me make sure I am on the right track here.  if I have branch file F, and bzrlib branch instance A of F, and bzrlib branch instance B of F, and A has a lock, if I tried to unlock B, it would say "I'm not locked."  That's what you mean here, yes?
<abentley> gary_poster: right.
<gary_poster> cool
<gary_poster> abentley, the bug is within bzrlib, or we aren't using it correctly somehow.  We never get the repo pack to unlock it ourselves, and bzrlib doesn't do it because the code path apparently expects "fallback.unlock()" (whatever that is) will do it, but that is not around for us.  Here are the details: http://pastebin.ubuntu.com/675505/
<gary_poster> s/repo pack/repo back/
<lifeless> cr3: bug 799271
<_mup_> Bug #799271: cache entries get corrupted and lead to hard to diagnose failures <launchpadlib :Triaged> < https://launchpad.net/bugs/799271 >
<abentley> gary_poster: Okay, it looks like a bzrlib bug.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build #1,002: FIXED in 4 hr 10 min: https://lpci.wedontsleep.org/job/devel/1002/
<abentley> gary_poster: I think the lock_read must not happen until we are sure that we'll add it as a fallback repository.
<gary_poster> abentley, ok, that makes sense.  Let me see if that works...
<abentley> gary_poster: or else we need to manually unlock if we we're exiting without adding it.
<gary_poster> right
<lifeless> cr3: https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis
<gary_poster> abentley, I don't know how much of an indication of correctness this is, but ./bin/test -vvc lp.codehosting.puller.tests.test_worker passes (and without the locked file complaint) with the reordering you suggested.  I'm inclined to branch bzr and make the change, but I'll probably need some serious help with a test.  But you agree that I should make a bug, work up a full branch for an MP, and make an egg for LP, yes?
<gary_poster> and I'll try for the test with help first :-)
<gary_poster> though maybe hints on what tests to run would be good--I saw that the bzr test suite is 3.5 hours now
<gary_poster> mm, I saw your faultline plugin; that might help
<abentley> gary_poster: True.
<abentley> gary_poster: Yes.  For bzr itself, faulline adds an "--auto" flag that will automatically determine the tests to run.
<abentley> gary_poster: IOW, "bzr selftest --auto" is your friend.
<gary_poster> ok cool, abentley.  So...in order to get faultline to trigger I just need to add a comment to where I intend to make the change?
<gary_poster> then I can look at those tests, try to figure out what to write new, and go from there
<abentley> gary_poster: You can do it that way, or you can just specify the file.
<gary_poster> oh ok
* bac changed the topic of #launchpad-dev to:  #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256
<sinzui> jcsackett, do you have a few minutes to mumble?
<gary_poster> abentley, had trouble with faultline fwiw. the --auto hack uses FaultFinder.from_tree, while the trunk has FaultFinde.from_trees. Simply fixing the name is insufficient.
<gary_poster>   File "/home/gary/.bazaar/plugins/faultline/faultline.py", line 250, in run
<gary_poster>     finder = FaultFinder.from_trees(target.basis(), target,
<gary_poster> AttributeError: 'WorkingTree6' object has no attribute 'basis'
<gary_poster> bzr fault-line works fine
<abentley> gary_poster: sorry 'bout that.
<gary_poster> abentley, no apology needed, just telling you. you want me to file a bug?
<jeblair> i have an launchpad openid sso problem:
<jeblair> when lp:~gandelman-a logs into my site, he shows up with the local_id https://login.launchpad.net/+id/QAxGXJy
<jeblair> but his account page, https://launchpad.net/~gandelman-a
<jeblair> says his local_id should be https://login.launchpad.net/+id/KeeKF87
<jeblair> and i can't work backwards from QAxGXJy to find out what account it's for.
<jeblair> why would it show up as something different, and how can i verify his identity?
#launchpad-dev 2011-08-27
<LPCIBot> Project devel build #1,003: FAILURE in 4 hr 7 min: https://lpci.wedontsleep.org/job/devel/1003/
<luke-jr> Is there a git-supporting branch yet?
<LPCIBot> Project devel build #1,004: STILL FAILING in 4 hr 4 min: https://lpci.wedontsleep.org/job/devel/1004/
<nigelb> who's around today? :)
<StevenK> I am, but I don't want to think about code.
<nigelb> I'm just thinking if python had a way to do utc offset from any timezone.
<LPCIBot> Project devel build #1,005: STILL FAILING in 4 hr 33 min: https://lpci.wedontsleep.org/job/devel/1005/
#launchpad-dev 2011-08-28
<LPCIBot> Project devel build #1,006: STILL FAILING in 4 hr 30 min: https://lpci.wedontsleep.org/job/devel/1006/
<nigelb> Gah, no jtv.
<nigelb> I think I caused a bunch of lint problems :(
<wgrant> nigelb: Oh?
<nigelb> wgrant: Yeah, jtv emailed me saying there are a bunch of lint warnings. Updaging devel and branching to poke at it.
<nigelb> *updagint
<nigelb> GAH
<nigelb> *updating
<nigelb> hm, what's pipes?
<nigelb> bzr plugin?
<StevenK> nigelb: Yes. lp:bzr-pipeline
<wgrant> nigelb: bzr-pipeline
<wgrant> It's packaged.
<wgrant> At least in oneiric.
<nigelb> Installed.
<nigelb> No lint warnings.
<nigelb> Not from a fresh branch from devel
<wgrant> make lint only lints changed files.
<wgrant> Because the tree has so much damn lint still.
<nigelb> what if I have no changed files?
<wgrant> To lint the whole tree would cause you to die.
<wgrant> jtv wasn't talking about your branch?
<nigelb> yeah, excepct I have no idea which one :D
<wgrant> What does the email say?
<nigelb> http://dpaste.com/603990/
<wgrant> Ah.
<wgrant> Anyway, now you have bzr-pipeline installed you'll see lint for any future branches.
<wgrant> And people will fix the lint you've just created as they see it.
<nigelb> Okay, so I don't need to get worked up into fixing it right now.
<wgrant> Right.
<wgrant> Just try to avoid it in future :)
<nigelb> I should just use lp-propose, why I didn't so far is baffling me
<nigelb> Hrm, I'm trying to add (UTC+foo) to person-index
<nigelb> Except I'm failing spectacularly.
<wgrant> Does pytz give you that information?
<nigelb> Not easily.
<nigelb> I wrote a function that does this. http://dpaste.com/603992/
<nigelb> I'm fairly sure somone is going to stab me for that.
<nigelb> More importantly, I just have oops than it working.
<wgrant> >>> pytz.timezone('Australia/Melbourne').utcoffset(datetime.datetime.utcnow())
<wgrant> datetime.timedelta(0, 36000)
<nigelb> Adding this as a property to the PersonView class is the right thing?
<wgrant> datetime.datetime.now(pytz.timezone('Australia/Melbourne')).strftime("%z") is slightly less confusing that what you wrote, but I think it might be what you want.
<wgrant> Unless you want to convert the 36000 to +1000 yourself.
<wgrant> Which seems silly.
<nigelb> This works as well.
<nigelb> Trying
<nigelb> Yay OOPS
<nigelb> grrr
<nigelb> "LocationError: (<Person at 0xe7d252c name16 (Foo Bar)>, 'show_time_offset')<br /> "
<nigelb> Does that mean my function is not in the object?
<nigelb> hm, OOPS-2066CP26
<nigelb> I can't see the https://code.launchpad.net/~launchpad-pqm/launchpad/devel page
<nigelb> How do I fix "./bin/lint.sh: line 125: pocketlint: command not found"?
<wgrant> nigelb: sudo apt-get install python-pocket-lint
<wgrant> Do you have launchpad-developer-dependencies installed?
<nigelb> wgrant: I followed the instructions to set up launchpad
<nigelb> I don't know if the developer dependancies wewre part of it
 * nigelb fails at tests
<LPCIBot> Project devel build #1,007: STILL FAILING in 4 hr 46 min: https://lpci.wedontsleep.org/job/devel/1007/
<lifeless> nigelb: the dependencies package is part of the scripts
<lifeless> nigelb: did the scripts glitch or error ?
<nigelb> lifeless: Installing python-pocket-lint fixed it.
<nigelb> and the scripts were not working actually.
<nigelb> I now realize doing a make lint until today was ineffective :(
<nigelb> I'm having some trouble with create_initialized_view
<nigelb> I did a html = create_initialized_view(person, '+index')()
<nigelb> html turns out empty
<wgrant> lifeless: Go away.
<lifeless> I am gone.
<wgrant> Good :)
<jelmer> hehe
<jelmer> wgrant: 'morning
<jelmer> wgrant: do you know what the status of staging is?
<wgrant> Still broken.
<wgrant> Don't expect it for a few more days at least.
<wgrant> It's a little over two weeks out of date now.
<jelmer> ok :-/
<jelmer> Thanks.
<wgrant> What does it do that you desire? bzr 2.4?
<jelmer> yeah, I landed my bzr 2.4 branch on db-devel two weeks ago with plans to do extensive QA on staging.
<wgrant> I will try to coerce LOSAs into unbreaking it today, but failing that I will convince bigjools to bump the prio of the ticket.
<wgrant> Or maybe I need flacoste.
<wgrant> Probably.
<wgrant> Oh good, qastaging is broken now too.
<wgrant> Hmm.
<jelmer> wgrant: seems alright here
<wgrant> Maybe buildbot-poller.
<wgrant> It's 20 revisions out of date.
<wgrant> Yeah, buildbot poller is broken, it seems.
<wgrant> Stale lock.
<wgrant> LOSA ping.
<spm> howdy
<wgrant> spm: Could you please bzr break-lock lp:~launchpad-pqm/launchpad/stable?
<wgrant> Unable to obtain lock  held by launchpad-pqm@bazaar.launchpad.net
<wgrant> at crowberry [process #1008], acquired 64 hours, 30 minutes ago.
<spm> done
<wgrant> Thankyou sir.
<wgrant> It worked.
<jelmer> \o/
#launchpad-dev 2012-08-20
<StevenK> lifeless: O hai?
<lifeless> hai
<StevenK> lifeless: I've been refactoring auditor
<StevenK> lifeless: python setup.py test is very unhappy, and I've been trying to work out WTF for a bit
<StevenK> lifeless: http://pastebin.ubuntu.com/1156558/ is a snippet, all 11 tests are very similiarly unhappy
<StevenK> Well, that's ... handy
<wgrant> Heh
<mwhudson> what is ROOT_URLCONF set to in settings?
<StevenK> mwhudson: ''
<mwhudson> that would seem to explain the error message...
<StevenK> Hmm
<StevenK> mwhudson: That would indeed be it, thanks!
<StevenK> (Read as, down to 7 errors)
<lifeless> bah, NM fail.
<lifeless> StevenK: you were saying
<StevenK> lifeless: Since your internet is pure fail and you dropped off, mwhudson helped me.
<lifeless> NM decided to associate to a random wifi point in the middle of nowhere
<lifeless> StevenK: cool. What was wrong?
<StevenK> lifeless: http://pastebin.ubuntu.com/1156576/ is what you missed.
<lifeless> kk
<StevenK> steven@undermined:~/auditor% bzr di | diffstat -s
<StevenK>  11 files changed, 90 insertions(+), 200 deletions(-)
<lifeless> cool
<StevenK> lifeless: Do you want to eyeball the diff?
<lifeless> Were there any surprises ?
<StevenK> Only the ROOT_URLCONF gotcha in runtests that tripped me up.
<StevenK> lifeless: http://pastebin.ubuntu.com/1156585/ just in case you have any suggestions
<lifeless> StevenK: A copyright nod to where runtests came from might be nice.
<lifeless> StevenK: A copyright nod to where runtests came from might be nice.
<StevenK> lifeless: What was your plan with auditorfixture?
<lifeless> give it the django project (on the child side of the process boundary)
<StevenK> lifeless: As in, I should embed an emptyish django project into auditorfixture? How do I then have buildout slap the egg into it?
<lifeless> how was the fixture ensuring it had auditor before ?
<StevenK> lifeless: It was in test_requires, and the buildout-written bin/auditor-manage did stuff to import the module
<lifeless> so, same thing
<lifeless> more or less - handwaving furiously.
<lifeless> You could createa a django project on the fly if you wanted an alternative.
<lifeless> but the basic approach is going to be unchanged
<StevenK> lifeless: So I embed the effectively four files for a django project into the fixture and convince buildout to copy the unpacked auditor egg into it, and then call ../auditor-proj/manage.py runserver
<lifeless> StevenK: I don't understand why you're talking about the egg
<lifeless> StevenK: you didn't copy it around before, why would you now?
<StevenK> lifeless: Because the django project needs to import it?
<lifeless> StevenK: you'll have your own manage.py in fixture, thats django project stuff, you don't need manage in auditor....
<lifeless> StevenK: how is that connected to copying it around ?
<StevenK> lifeless: I thought django would want it in the same layout
<lifeless> no, thats the point of apps, they just get located via import once they are listed in INSTALLED_APPS
<StevenK> lifeless: So you were envisioning manage.py and settings.py in auditorfixture base directory?
<lifeless> yes
<lifeless> or something like that
<lifeless> given all the variou scruft you'll be dealing with. manage.py might be something buildout writes for you, for instance.
<StevenK> I was going to generate a django project and copy the two bits in
<StevenK> Munging as I go
<lifeless> sure, that sounds fine too
<lifeless> I don't have an exact blueprint for you ;)
<lifeless> the key bits were to get rid of the project level stuff from auditor, make a dedicate version of just the project stuff for staging and production deployments, and similar for the fixture.
* adeuring changed the topic of #launchpad-dev to:  http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2
<jam> dpm: I saw that you fully opened the translations queue for Quantal. I'd like to go through the checklist here: https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings
<jam> just to make sure everything got finished, or if we need to update the checklist for any changes (so the person doing it for R will have a clear checklist)
<jam> If you could let me know when you could look at it with me, that would be great.
<jam> jtv: ^^ in case you were involved as well.
<jtv> jam: this time I mostly wasn't, which is actually great news!
<jam> jtv: yeah, very good to hear.
<dpm> jam, sure, we can do it now, if you want.
<jam> dpm: so I left off around step 5 (jtv and I validated that the translation copy looked sane.)
<jam> (would you rather do this on mumble/g+ ?)
<dpm> jam, sure, g+ is fine? Give me 5 mins to have a quick look at the document and then we can jump into a call
<jam> np
<cjwatson> stub: Brad suggested that I should get you to look over https://code.launchpad.net/~cjwatson/launchpad/queue-filter-source/+merge/119225 for possible improvements
<cjwatson> (There's an attempt at a performance analysis in the linked bug)
<dpm> jam, sorry for the delay, ready to start a hangout now
<jam> dpm: https://plus.google.com/hangouts/_/fc76b32f50b23d671cf435628e74f3e79e11d871?authuser=2&hl=en#
<stub> cjwatson: commented
<cjwatson> stub: thanks - yeah, a feature flag might make sense, I shall ponder that
<rick_h_> morning
<smartboyhw> Er, hi, anyone here?
<mgz> that question always asks for the response "no"
<smartboyhw> mgz: Sorry
<cjwatson> ...
<mgz> I'm not succeeding at building the launchpad development community
<wgrant> Well then
<cjwatson> Bug 1036597: would it seem reasonable to put UEFI signing keys for PPAs in <signing_keys_root>/uefi/<archive.owner.name>/<archive.name> (and get ops to generate them on a case-by-case basis - there should only be a handful of PPAs that ever care)?  That doesn't clash with anything else currently in signing_keys_root, and it's nicely outside the published PPA tree.
<_mup_> Bug #1036597: No UEFI signing configuration for PPAs <uefi> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1036597 >
<cjwatson> It does mean that any future horizontal scaling of the PPA publisher would have to keep those keys in sync, but that would have to keep signing_keys_root in sync anyway.
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 4.0*10^2
<deryck> Morning, all
<czajkowski> deryck: morning
<abentley> rick_h_: On http://people.canonical.com/~rharding/app/project_home.html I get "The requested URL /api/devel/privatemockup was not found on this server."
<rick_h_> abentley: heh ok. Hadn't gotten that when walking through.
<rick_h_> thanks for the heads up
<abentley> rick_h_: np
<jam> jelmer: did you get a chance to upload py2.6 to ~canonical-bzr/py27 ?
<jelmer> jam: working on that atm
<mgz> why ~canonical-bzr?
<jelmer> mgz: what would you suggest?
<mgz> ~pythoneers
<mgz> or whatever launchpad group cares about packaging
<jelmer> mgz: I would like to force a rebuild of everything, so a new ppa is easier
<jelmer> mgz: I'd like to leave ~pythoneers, it's adding to my daily spam
<mgz> you can unsubscribe, no?
<mgz> but this is a temporary measure so I guess it doesn't really matter, a throwaway ppa would be fine
<jelmer> mgz: no, ~pythoneers has a bunch of structural subscriptions
<jelmer> I can mute mail from individual bugs, which isn't particularly helpful
<mgz> ah, yeay for launchpad email. I just stick it all in a tag I don't look at...
<deryck> benji, hi there.  I have a branch for review.
<wgrant> jelmer: You can mute team structsubs
<wgrant> eg. on https://bugs.launchpad.net/launchpad-project/+subscriptions
<wgrant> As long as the team doesn't have a contact address set (since in that case the email is sent before you're even considered)
<benji> deryck: congratulations! you are the one millionth customer! you recieve a lifetime supply of diffs
<deryck> benji, heh.  Long line today?
<benji> nope, just in a goofy mood ;)
<deryck> benji, ah nice :)
<deryck> benji, it's here: https://code.launchpad.net/~deryck/launchpad/reauth-gpg-363916/+merge/120401
<rick_h_> lol, I'll want to use that sometime. "lifetime supply of diffs"
<jelmer> wgrant: but that means muting it for everybody, doesn't it?
<wgrant> jelmer: I don't think so
<wgrant> jelmer: That would be pretty useless
<wgrant> Since the same could be achieved by removing the subscription
<jelmer> wgrant: hmm, but that means manually muting all 88 structural subscriptions of ~pythoneers manually?
<sinzui> flacoste: We will start the sharing beta within 24 hours. We are waiting for a important branch to land, qa, be for all out important branches to be released...
<wgrant> jelmer: Or convincing barry that team subscriptions are vile
<sinzui> flacoste: ...~launchpad's projects can take immediate advantage of the beta some of us are both members of ~launchpad and ~commercial-admins. We can invite other to participate in the beta a few days later when my work to change permissions allows project maintainers to configure projects using UI and API.
<jelmer> wgrant: or just leaving ~pythoneers, which I shouldn't really be in anyway :)
<jelmer> wgrant: I can see how team subscriptions make some sense in this case - you wouldn't want all ~pythoneers members to individually track the set of packages relevant for that team
<sinzui> flacoste: I have a draft API script for OEM. They can reconfigure their projects after my permission changes are in place. I image they can participate in the beta with a day of receiving the script.
<wgrant> If that's the entire point of ~pythoneers, indeed
<flacoste> sinzui: thanks!
<mgz> wgrant: well, it also contains some packaging ppas that we wanted to use for this ***** backporting of python2.7 to lucid thing
<wgrant> Heh
<sinzui> flacoste: once we enter beta, wgrant will close 10 bugs. I hope to see a drop in the predicted days to complete sharing
<wgrant> I think there's a few more that get closed as well
<sinzui> wgrant: I am off next week. I expect you to pass my bug closings for disclosure.
<sinzui> sorry not pass but surpass
<wgrant> We'll see :)
<sinzui> You may need to hide from IS and not work on incidents like last week
<wgrant> I think the last significant issue is being resolved as we speak.
<wgrant> Basically I get to blame everything on firewalls and IS fixes it :)
<sinzui> jcsackett: are you available to discussing allowing commercial admins to help setup project sharing?
<jcsackett> sinzui: sure.
<abentley> wgrant: why did you set bug #1032717 to "in progress"?
<_mup_> Bug #1032717: blueprint data model doesn't support private projects <qa-ok> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/1032717 >
<sinzui> abentley: maybe because it is not the devel branch yet?
<sinzui> It can only be use on staging?
<abentley> sinzui: I believe it's in devel.  It landed in db-devel more than a week ago.
<abentley> sinzui: landed in r15768, with wgrant as the reviewer.
<sinzui> I agree that I see it in devel. I think the bug is fix released
<abentley> sinzui: I tend to agree.  I wondered whether wgrant was referring to the lack of an index, but that needs to be a separate bug.
<sinzui> indexes would indeed be separate.
<sinzui> abentley: maybe wgrant is thinking model as in code. Your branch provided schema. lp.blueprints.interfaces.specifications.py does not know about InformationType
<sinzui> abentley: I would change the bug title to be about schema and mark it fixed release.
<sinzui> really
 * sinzui is tempted to do it right now
<sinzui> abentley: I have revised the bug to make it clear it is about the schema, and since that change is in production, it is fix released.
<abentley> sinzui: Cool.
<sinzui> abentley: np.
<lifeless> abentley: sinzui: there is an idiom wgrant has been using where successive landings for the same bug are used to add schema, tune, and then deliver the thing.
<lifeless> Rather than bug per landing.
<lifeless> This is a useful idiom because it makes it clear you can't land more than one branch at a time when you're doing the schema-code-schema-code etc dance.
<lifeless> So I suspect he assumed you were doing the same, and was helping in that process.
<lifeless> (its fine to do it differently, just explaining what I see that would line up)
<czajkowski> is anyone else seeing an issue where you go to edit your mails and you're made relogin again ?
<abentley> lifeless: In the past, I've found that multiple-landings-per-bug confused qa-tagger, so I actively avoid doing that.
<cjwatson> I do it a fair bit, but you do have to careful to serialise things (and that isn't always appropriate), or else deal with a bit of QA confusion.
<cjwatson> (Perhaps because I picked up LP development processes somewhat osmotically.)
<sinzui> lifeless: I don't like that idiom. I will not QA someone else's bug if it has more than one branch associated because I cannot tell what the nuances of QA are. Aaron's branch adds value (specifically infrastructure for more than one developer to extend)
<sinzui> Someone could land an index on the db in one branch, while I land a interface and model change that makes the feature work over API. (4 hours work for 2 independent developers)
<lifeless> abentley: it should be fine unless you have >1 branch undeployed-but-landed at any time. Which you shouldn't with the db change sequence.
<lifeless> sinzui: I'm agnostic, was only seeking to explain the behaviour.
<rick_h_> welcome back deryck
<deryck> rick_h_, thanks!  very frustrating.  it's like a once a week event here at the shop now.
<rick_h_> what's the net at the new place?
<rick_h_> gotta call ahead and get that fiber line run to the front door :P
<deryck> rick_h_, it's cable.  pretty stable for my friend who telecommutes in the same neighborhood.
<sinzui> Fiber is only as good at the vendor's own desire to keep a net work up. I loose DNS several times a week because Verizon sucks marginally less than Cox Cable (which name is a homonym for what I really think of them)
<deryck> heh
<rick_h_> never use providers DNS, lesson I learned back on comcast days
<sinzui> +1
<sinzui> I now add my own to keep the house running
<rick_h_> yea, I run one on an ec2 box and use google as a backup
<sinzui> I have yet to find a solution for U1 backups that incite Verizon to block my house. I suspect they think U1 is a warz site.
<lifeless> sinzui: it is :P
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2
<cjwatson> wgrant: https://dev.launchpad.net/Contributions ;-)
<wgrant> cjwatson: Heh, well done
<sinzui> wgrant: Do we want to say this bug is closed when beta starts? This instance looks fixed by sharing, though the technical issue could still happen from untrusted users: https://bugs.launchpad.net/launchpad/+bug/900431
<_mup_> Bug #900431: branch visibility queries do not consider visibility of stacked on branches <403> <branches> <disclosure> <privacy> <sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/900431 >
<wgrant> sinzui: It's not truly fixed
<StevenK> steven@undermined:~/launchpad/lp-branches/destroy-security-contact% bzr di | diffstat -s
<StevenK>  14 files changed, 10 insertions(+), 713 deletions(-)
<StevenK> Bloody hell, and I'm not done yet.
<StevenK> wgrant: Something must be wrong. You're at -502 and I'm at -1280
#launchpad-dev 2012-08-21
<wgrant> wallyworld: Hum, interesting regression
<wgrant> wallyworld: https://code.launchpad.net/~timkross/cjdns/cjdns
<wgrant> wallyworld: Look at the "Edit import source or review import" link
<wallyworld> you mean it's split?
<wgrant> wallyworld: It's overridden by JS to display a bug picker
<wallyworld> ah, i had logged out, just a sec
<wgrant> Ah
<wallyworld> so it is :-(
<wallyworld> i'll have to fix it
<wallyworld> it's got an id of linkbug, that can't be sensible
<wgrant> Heh
<maxb> How... special :-)
 * mwhudson wonders if that is his fault
<wgrant> wallyworld: Thanks for the quick fix
<wallyworld> needed to be done
<StevenK> wgrant: Is POLICY_ALLOWED_TYPES in branchnamespace private? I'm using it, but it's not in __all__.
<wgrant> StevenK: That's a very good question
<wgrant> StevenK: I'd rename and expose it
<wgrant> StevenK: Same with the stuff in bugtarget
<wgrant> Which I added a few hours ago
<StevenK> Has that landed?
<wgrant> Yeah, at 4am or something
<wgrant> Not through buildbot yet
<StevenK> Right, I'll rebase this on current devel
<lifeless> flacoste: http://www.amazon.com/Running-Lean-Iterate-OReilly-ebook/dp/B006UKFFE0/ref=pd_sim_kstore_1
<lifeless> flacoste: looks intruiging
<bigjools> lifeless: it does
<StevenK> steven@undermined:~/launchpad/lp-branches/destroy-security-contact% bzr di -r submit: | diffstat -s
<StevenK> Using submit branch /home/steven/launchpad/lp-branches/devel
<StevenK>  52 files changed, 61 insertions(+), 1240 deletions(-)
<StevenK> Right, I think that's security contact eradicated
<StevenK> ForbiddenAttribute: ('remove', <storm.store.ResultSet object at 0x114dfa90>)
<StevenK> Hm. I thought that worked.
<wgrant> No
<wgrant> It's usually used on an unproxied resultset
<wgrant> Not one that was returned from a model object
<StevenK> Well, I don't care about the APGs I get back, I want to remove them
<StevenK> Maybe I want to add revokeByPolicy()
<wgrant> That would be the correct thing to do, yes.
<wallyworld> wgrant: i've got things all working for the team access policy stuff. one point to note - the bug says private teams need an APG but in fact any team needs an APG to see +junk private branches
<wallyworld> perhaps I should check non teams as well
<StevenK> Non teams?
<StevenK> The owner can implicitly access a personal +junk private branch
<wallyworld> StevenK: when the owner was a team, they couldn't
<wallyworld> without a subscription
<StevenK> wallyworld: Right. The owner of the team can
<StevenK> wallyworld: So non teams has to be people
<wallyworld> sure, s/non team/person
<wallyworld> i'm wondering now though, it we create an APG for +junk, we don't need to create the subscription anymore
<wallyworld> it's sort of pointless subscribing to one's own +junk branch i would think
<StevenK> wallyworld: We don't subscribe the team to a +junk branch
<StevenK> The owner or the team owner do get subscribed
 * StevenK refactors the garbo job to work on sets rather than looping
<wallyworld> StevenK: incorrect i think - we do a subscribe(self.owner....)
<wallyworld> and self.owner may be a team
<wallyworld> so if we do the APG for +junk, then we can forget the subscribe(self.owner...) for +junk
<StevenK> Hm, probably
<wallyworld> well, that's my theory right now. i'll do the tests for it all and see how it pans out
<wallyworld> actually, i wrote the tests for the team owners first, i need to add other tests
<wgrant> wallyworld: Well, private +junk branches on public teams aren't meant to exist, but they can
<wgrant> The default subscription is partly there for MP notifications, IIRC
<wgrant> check the initial mail settings
<wallyworld> yes, it's nominally for MP notifications. but that then also grants access
<wallyworld> i guess if the subscription were to be deleted
<wallyworld> we would then rely on the APG
<wgrant> Right, exactly
<wgrant> And the owner loses access
<wgrant> And everyone is sad because nobody can recover it except ~admins :(
<wallyworld> ok. i'll incorporate that into the tests. i'll also only create the AGP for private teams
<wallyworld> APG
<wgrant> I'm not quite sure when the AP/APG should be created. It's a bit of a difficult question
<wallyworld> i do it in transitionVisibility
<wallyworld> if visibility == private
<StevenK> Which isn't called if say the team is private?
<StevenK> I think PersonalNamespace.createBranch() is the right place
<wallyworld> it's called when the team is created. we do need data migration for existing teams
<StevenK> I don't think we want an AP for every team
<wallyworld> i create the AP in transitionVisibility and the APG in _reconcileAccess
<wallyworld> i could move it though to all be done in createBranch
<wallyworld> i guess when the branch is deleted, or the team is deleted, stuff needs to be cleaned up also. plus merges too?
<wgrant> wallyworld: I'd suggest renaming AP.team to AP.person
<wgrant> As it's conceivable that we might want them for people as well, if we permit people to move private branches to their person
<wallyworld> i did have that originally but it is a team
<wallyworld> hmm. ok
<wgrant> We only clearly need them for private teams right now
<wgrant> But it may end up that we need them for others
<wgrant> I suspect
<wallyworld> ok
<wallyworld> wgrant: with deletions and merges, the AP and APG will need to be cleaned up to right?
<wgrant> wallyworld: Yeah...
<wgrant> I think we currently forbid merges if there are private branches involved
<wgrant> So you should be able to just delete the APG and AP
<wgrant> Since they can't be referenced.
<wallyworld> do we clean up now for pillar APGs for deleting bugs and branches, i can't recall?
<wgrant> No
<wgrant> StevenK's working on a garbo job that will remove unused APs and APGs if the project policy forbids them
<wallyworld> so i propose i don't to the cleanup in this branch and defer it to another
<wgrant> So
<wgrant> I would suggest that we actually put it in _reconcileAccess or BranchNamespace or something, maybe
<wgrant> It'll work for any person, then
<wgrant> and a counterpart to StevenK's garbo job can clean them up if they're unused
<wgrant> It's slightly evil
<wgrant> But it's consistent.
<wallyworld> the APG bit is in _reconcileAccess
<wallyworld> the AP creation for the team is in transitionVisibility
<wallyworld> for if i do it in createBeanch, both can be done together
<wallyworld> s/for/but
<wgrant> Oh
<wgrant> The APG and AP stuff should really be together
<wgrant> Why the difference?
<wallyworld> AP and APG for pillars are not done together
<wgrant> Also, not just createBranch, but moveBranch, and transitionToInformationType :/
<wgrant> wallyworld: Do you mean APG or APA?
<wallyworld> APG
<wallyworld> no
<wallyworld> APA
<wgrant> That makes more sense :)
<wallyworld> yeah, sorry too many TLa for disclosure
<wgrant> For non-pillars, each AP has one immutable APG
<wgrant> So they should probably be managed together
<wallyworld> wgrant: fuck, forget what i said just above. yes, the AP and APG are done together
<wgrant> Right
<wallyworld> the APA is done in _reconcileAccess
<wgrant> So the only concern is where we put them.
<wgrant> Yep
<wallyworld> the code is right, but i lose something in he translation typing into irc for some reason
<wgrant> Easy to do :)
<wgrant> I'm really not sure which is the best place to put this
<wgrant> _reconcileAccess is the safest
<wallyworld> i put the AP and APG in transitionVisibility because we only want to do that for private teams
<wallyworld> and then the APA in _reconcile can assume the AP/APG is all set up
<wgrant> wallyworld: It's not actually clear that we only want to do that for private teams.
<wgrant> The immediate problem is only for private teams, though
<wgrant> But what if I make my team public
<wgrant> Or move a private branch to my public team
<wallyworld> you lose access to the private branch for public teams since we don't support that i thought
<wgrant> That might be a reasonable answer, yeah
<wgrant> But letting artifacts go into an unrecoverable situation is bad, if we can easily avoid it
<wallyworld> you mean when a team goes private -> public?
<wgrant> I guess we should check on branch move that the information type is legal in the target
<wallyworld> yes, i think that's best
<wallyworld> like we do for bugs
<wgrant> Currently I can do something like https://code.qastaging.launchpad.net/~wgrant/+junk/test6
<wgrant> Which is a private branch on my person
<wgrant> By setTarget()ing it from a project with private branches
<wgrant> That reminds me
<wgrant> We should probably add a safeguard in reconcile_access_for_artifact
<wgrant> That the correct number of APs is returned
<wgrant> Otherwise eg. if a bug happens to get a task added on a project that doesn't have a matching policy, it'll silently work but be partially invisible
<wgrant> Should probably crash instead
<wgrant> If you're near that code atm and it looks easy, could you throw that into your current branch? If not I'll do it
<wallyworld> ok, i'll take a look. but i probably won't to it till tomorrow, since i want to write some more tests etc
<wgrant> Sure
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: 4.0*10^2
<adeuring> good morning
<jelmer> mÃ¸rgen
<adeuring> frankban: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/specification-auth-check/+merge/120430 ?
<frankban> sure adeuring
<adeuring> thanks!
<jam> jelmer: I just saw a failure on your build, will it actually stop it?
<jam> jelmer: http://paste.ubuntu.com/1158664/
<jelmer> jam: doesn't look like it has :)
<jam> jelmer: would it fail at the end, there is also: http://paste.ubuntu.com/1158667/
<jam> (running bzr selftest vs bzr selftest -1)
<StevenK> jelmer: You didn't look at my branch :-(
<mgz> jam: the python test suite is less fancy than ours
<jam> mgz: sure, but it can a) Stop on first failure or b) Record a failing test suite at the end
<jelmer> StevenK: Sorry
<jam> or c) have failures and just ignore all of them
<jelmer> StevenK: I did look :)
<jelmer> StevenK: Just not get back to you
<jelmer> StevenK: The changes all seem reasonable to me
<jelmer> Including switch subvertpy to 0.9.0
<jelmer> *switching
<StevenK> jelmer: Ah ha. I'll land it tomorrow then, thanks.
<jam> jelmer: hmm.. interesting, looks like lots of failures, but still a clean pass
<jam> mgz: looks like it is (c) after all
<jam> why run a test suite if you aren't going to have it pass
<mgz> for giggles!
<jam> mgz: yeah, but it would save a lot of time building python if we don't do steps that just get ignored anyway :)
<jam> jelmer: so, next step is python-defaults?
<jam> also, *my* lucid vm is 32-bit. so I can't actually use the amd64 one... :(
<rick_h_> morning
<jam> jelmer: so where are we at for the python-2.6/7 stuff? need to dput python-defaults and ping to get it to jump the queue?
<jelmer> jam: Yes, that's what I'm on atm
<jelmer> jam: since 2.6 built ok
<jam> jelmer: how's it going? (Just finished up a couple of interviews)
<BjornT> how long does the staging.launchpad.net code update usually take?
<jelmer> jam: about to do another upload
<wgrant> BjornT: About five minutes, but there's nothing usual about this one
<wgrant> BjornT: staging currently has no database due to the DC move. It'll be another day or so before it's rebuilt
<wgrant> BjornT: Can you use qastaging instead?
<BjornT> wgrant: ok. i guess i could try qastaging instead.
<wgrant> jelmer: Do you want a score boost on that build?
<jelmer> wgrant, that would be awesome
<jelmer> wgrant, I'll ping one of the buildd admins once I've done the upload
<jelmer> I guess you're still a buildd admin?
<wgrant> Yeah
<cjwatson> Or I can if wgrant's asleep
<abentley> wgrant: Did lifeless have the right explanation of why you marked bug #1032717 "in progress"?
<_mup_> Bug #1032717: blueprint schema doesn't support private projects <qa-ok> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/1032717 >
<wgrant> I marked the model one in progress
<wgrant> Oh
<wgrant> It was renamed :)
 * wgrant checks IRC logs
<abentley> wgrant: It was really intended for the schema change, I just vague it up because lifeless doesn't like bugs that request a particular technical solution.
<wgrant> Ah, missed the ping, sorry
<wgrant> Yeah, lifeless' explanation was correct
<abentley> wgrant: np.
<wgrant> Sorry if I misunderstood the bug
<abentley> wgrant: Okay, np.  Perhaps my fault for vague bug.
<abentley> rick_h_: I don't know if this would be too much work, but it might be nice to mess with the other links on the walkthrough so that you can't wander off onto qastaging by accident.
<rick_h_> abentley: yea, if I have time I'll try to hook up the ones that I end up with pages for
<rick_h_> for instance, as I create the code mockup, the code links in the heading cam go somewhere
<abentley> rick_h_: right.
<rick_h_> but after that, I'll probably just set something to kill other links if I get time to clean it up
<abentley> rick_h_: Maybe you could just rewrite qastaging links dynamically onload :-)
<rick_h_> some delegate listener for all links that check for qastaging in the url and just halt() on that
<abentley> rick_h_: or that.
<rick_h_> or that, but yea
<cr3> hi folks, I pushed changes to a branch over an hour ago, but the branch page on launchpad still shows "updating branch..." and the recent revisions doesn't show the one I pushed yet. is this a known problem?
<abentley> cr3: that does happen occasionally.  The branch may have taken too long to scan and the scan been terminated.
<cr3> abentley: anything I can do to help things alog, like push again or something?
<cr3> s/alog/along/
<abentley> cr3: Yes, pushing again will re-trigger the scan.
<cr3> abentley: thanks, and we are just talking about a branch and not a merge request, right?
<abentley> cr3: yes.
<cr3> even though I've had similar problems with merge requests, I don't mind exceptionally setting those to "merged" manually
<abentley> cr3: Could you be more specific about "similar" problems?
<cr3> abentley: instead of "updating branch..." in the branch, I would see "updating diff..." in the merge request
<abentley> cr3: It will say that if a scan is needed, i.e. the branch page says "updating branch".
<cr3> abentley: makes sense, so the problems are related.
<abentley> cr3: right.  The fact that "merged" isn't set is because the scan hasn't completed, not because the diff hasn't been updated.
<abentley> cr3: however, if you can specify *which* branch we're talking about, we can check the logs and see what happened.
<cr3> abentley: this is the breanch I'm talking about: https://code.launchpad.net/~canonical-hw-cert/checkbox-editor/trunk
<cr3> abentley: I tried pushing again, when you suggested it a few minutes ago, and we can still see: updating branch...
<abentley> cr3: So, it looks like scans of your branch are oopsing, but the root cause is being masked by a database exception: https://oops.canonical.com/?oopsid=OOPS-20a29e8a7bf4295727dddba3ddb75792
<cr3> abentley: permissions on the project relating to that branch were changed recently, might that be a reason? I can't imagine it would be because of the size of the branch, it's tiny and not many revisions
<abentley> cr3: It's really hard to say, since we can't see the actual failure.  I'm not aware of any cases where permisions would affect branch scans, but...
<cr3> abentley: branching the project returns the right revision, so only having the web interface updating the branch will not prevent me from getting work done. is there anything I should do to help, in case this might be a real bug that might affect other projects?
<abentley> cr3: Bug 1039556 also involves checkbox.
<_mup_> Bug #1039556: No diff generated when making a merge request or just uploading a branch <Launchpad itself:New> < https://launchpad.net/bugs/1039556 >
<cr3> abentley: the symptoms look the same but, for your information, the checkbox-editor branch I mentionned earlier and checkbox don't share anything as far as bzr is concerned. however, they might have similar project configurations like driver, maintainer, etc.
<abentley> cr3: The actual failure in the oops is different, too.  Very strange.
<cr3> abentley: should I added a comment about the checkbox-editor branch mentionned earlier to the same bug report?
<abentley> cr3: I'm filing a new bug report.
<cr3> abentley: thanks!
<abentley> cr3: bug 1039638
<_mup_> Bug #1039638: Scans of ~canonical-hw-cert/checkbox-editor/trunk oops with a database error <Launchpad itself:Triaged> < https://launchpad.net/bugs/1039638 >
<cr3> abentley: should bug #1039556 be deprecated by that one?
<_mup_> Bug #1039556: No diff generated when making a merge request or just uploading a branch <Launchpad itself:New> < https://launchpad.net/bugs/1039556 >
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2
<abentley> cr3: No, they could be separate issues.
<cr3> abentley: ok, thanks!
<abentley> cr3: np.
<cr3> is it possible to build arm packages in a public personal ppa?
<jelmer> cr3: IIRC yes, but there's a flag in the PPA that has to be enabled by a commercial admin to allow ARM building
<cr3> jelmer: excellent, so I should open a question against launchpad itself then. thanks!
<lifeless> fun - bug 1039702
<_mup_> Bug #1039702: Comments not posted <Launchpad itself:New> < https://launchpad.net/bugs/1039702 >
<sinzui> StevenK: This is my quick change to reconcile API and mail with UI
<StevenK> sinzui: Found it and approved it.
<wallyworld> sinzui: https://pastebin.canonical.com/72614/
<wallyworld> sinzui: StevenK: https://pastebin.canonical.com/72745/
<sinzui> wallyworld: +1 from me
#launchpad-dev 2012-08-22
<StevenK> wgrant: Do I have to drop indicies that reference a column before dropping it or will Postgres just deal?
<wgrant> StevenK: postgres will drop any indices that involve the column
<wgrant> StevenK: This can sometimes be undesirable, in the case of compound indices
<wgrant> So be careful
<StevenK> product is fine, just a partial index, no compounds
<StevenK> distribution is also fine, one index, no compounds
<wgrant> StevenK: Right
<StevenK> wgrant: make newsampledata seems to ignore the column drop
<wgrant> StevenK: You've applied the patch to launchpad_dev and launchpad_ftest_playground?
<StevenK> Hmm, my apply ... didn't.
 * StevenK stabs it harder
<wgrant> StevenK: Fail
<wgrant> StevenK: Instead of subscribing the security contact or the maintainer, you now unconditionally subscribe the maintainer
<wgrant> That block should go
<wgrant> Both of them
<wgrant> 1121+ getattr(info, 'bug_supervisor_tasks').append(value)
<wgrant> That can be simplified
<StevenK> wgrant: http://pastebin.ubuntu.com/1160033/
<wgrant> what the driver
<wgrant> Oh
<wgrant> That's during the transition
<wgrant> Hm
<wgrant> I think that diff is correct
<wgrant> But I was never a fan of the unsubscription rules
<StevenK> wgrant: Thanks, I've commited and pushed that bit
 * StevenK stabs the branch scanner for being terrible
<StevenK> Dear branch scanner, DIAF.
<StevenK> wgrant: Is https://code.launchpad.net/~stevenk/launchpad/db-destroy-security-contact cursed?
<wgrant> StevenK: Let me consult with my colleagues
<wgrant> StevenK: The spirits have indeed placed a curse upon it
<wgrant> Rename and repush
 * StevenK sacrifies wallyworld to the branch scanner.
<wallyworld> no not me, i've also had the same issues
<wallyworld> so i vote to sacrifice wgrant
<StevenK> He's useful to have around.
<wallyworld> but he's a young virgin and the gods like those
<StevenK> ROFL
<wallyworld> quotes page :-D
<StevenK> wallyworld: It looks like threatning to sacrifice you was enough
<wallyworld> yay
<wgrant> Heh
<wgrant> StevenK: Did you create an early MP or subscription or anything on that branch?
<wgrant> Before it had first scanned?
<StevenK> wgrant: Nope
<wgrant> :(
<StevenK> I didn't touch it for fear of a curse.
<StevenK> And it got cursed anyway
<StevenK> wgrant: Hahahaha
<StevenK> wgrant: You added POLICY_ALLOWED_TYPES to code/model/branchnamespace.py for branches and bugs/interfaces/bugtarget.py for bugs.
<wgrant> StevenK: Is that a problem?
<wgrant> Their meanings are different
<wgrant> And they were private until you came along
<StevenK> wgrant: I was amused at the model vs interface split
<wgrant> Ah, right
<wgrant> I wasn't quite sure where to put the latter
<wgrant> Since it's not used by model.bugtarget
<wgrant> But by the things that inherit it
<wgrant> Whereas for BranchNamespace it's only used by that class and tests.
<StevenK> And now a garbo job
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-unused-sharing-garbo/+merge/120698
<wgrant> StevenK: The RAM, oh god, the RAM
<wallyworld_> StevenK: just running out for school pickup, can look when i get back
<StevenK> wgrant: What do you think we should do to get the used or even better, the unused APs?
<wgrant> StevenK: You could search for artifacts for each and use is_empty
<wgrant> Means a couple of extra queries
<wgrant> But meh
<StevenK> Isn't apas = getUtility(IAccessPolicyArtifactSource).findByPolicy(
<StevenK> Already doing so?
<StevenK> And looping over it is bad?
<wgrant> StevenK: That's finding all the APAs, not just the APAs' distinct policies
<wgrant> launchpad_dogfood=# SELECT policy, COUNT(*) FROM accesspolicyartifact GROUP BY policy ORDER BY COUNT(*) DESC LIMIT 20;
<wgrant>  policy | count
<wgrant> --------+-------
<wgrant>     137 | 45598
<wgrant>   68775 | 10233
<StevenK> Yeah, I see what you mean.
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/moar-auditor/+merge/120706
<wgrant> StevenK: Why's lp.services.auditor.server not in testing/fixtures/something?
<StevenK> I was following txlongpoll's pattern
<wgrant> StevenK: Antipattern
<StevenK> Still
<StevenK> wgrant: Back to the garbo job: http://pastebin.ubuntu.com/1160294/
<wgrant> unused_aps = [ap for ap in candidate_aps if apa_source.findByPolicy([ap]).is_empty()]?
<StevenK> wgrant: http://pastebin.ubuntu.com/1160307/
<wgrant> StevenK: I'd tend to wrap just before the 'if' for cleanliness
<StevenK> wgrant: http://pastebin.ubuntu.com/1160309/
<wgrant> StevenK: Also, unless the two args to both get() calls don't fit on one line, please wrap before the first arg. But apart from that it looks excellent.
<wgrant> And I'm glad access is no longer policing.
<StevenK> wgrant: http://pastebin.ubuntu.com/1160312/
<StevenK> Yes, access made constable.
<StevenK> wgrant: No opinion?
<wgrant> StevenK: Looks good
<StevenK> wgrant: Thanks, pushing it up.
<StevenK> wgrant: Diff *finally* updated
<adeuring> good morning
<StevenK> wgrant: No approval for me? :-(
<wgrant> StevenK: Could you a docstring to the TunableLoop and perhaps some comments describing what it's doing and why?
<wgrant> Apart from that it's fine
<wgrant> I accidentally the whole thing, but anyway
<cjwatson> Spads: Hi.  Since the DC move, we've been short all the dogfood.lp builders, and rather a lot of Launchpad revisions are now blocked on a single revision that requires dogfood build QA.  There's been some insinuation that we might be able to get king for a while, but I'm assuming that's non-trivial since it hasn't happened yet; is there any chance we might be able to temporarily steal a production PPA builder for the ...
<cjwatson> ... task?  It should only take maybe half an hour.
<cjwatson> Err, why did that end up on #lp-dev
<cjwatson> Given that Spads isn't here
 * cjwatson moves to a cleverer channel
<BjornT> is something wrong with qastaging? i get timeouts (OOPS-64204c86af12c8a1d8c6fa597795a531) and oopses (OOPS-307f7eabfe6fed73cfa46b6dbb3b21d5) all the time
<rick_h_> BjornT: the db on there isn't primed up with requests and it times out a lot more often
<rick_h_> BjornT: are you trying to qa something or just tinker with disposable data? There are some smaller projects that tend to work ok for testing purposes
<wgrant> BjornT: Project group bug listings on qastaging... good luck with that
<wgrant> They're slow on production
<wgrant> And not indexed well
<wgrant> I'd try something else, or a very very small project group :)
<BjornT> rick_h_: i'm trying out an api script of mine. i guess i could try on a smaller project. although, i get oopses just looking at bugs as well (OOPS-6bdbc2384d11ecd88e64f635d5162828)
<wgrant> Hm
<wgrant> BjornT: Oh, that one's an OOPS, not a timeout
<wgrant> qastaging lacks a DB patch
<czajkowski> wgrant: any update on the DB patch on qastaging ?
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 4.0*10^2
<rick_h_> abentley: ping
<abentley> rick_h_: HI.
<deryck> adeuring, abentley, rick_h_ -- hey there.  Everyone good to join now?
<rick_h_> deryck: rgr
<adeuring> deryck: sure
<abentley> deryck: yup
<sinzui> jcsackett: I am having terrible connectivity issues
<sinzui> jcsackett: can you rollback cjwatson's rev that blocks deployment: http://lpqateam.canonical.com/qa-reports/deployment-stable.html
<wgrant> BjornT: qastaging has had the missing column added, so it should have stopped OOPSing. But I'm afraid there'll still be lots of timeouts
<mpt> Hey, does the Launchpad code include a PPA picker in the same way that it has a person picker and a project picker?
<sinzui> no
<sinzui> mpt: no ppa-picker
<wgrant> There is actually a PPA picker
<wgrant> It's very basic
<sinzui> roe recipes?
<sinzui> for
<wgrant> Precisely.
<sinzui> sorry, network and stress make my only tpy in Curtisese
<wgrant> The "Daily build archive" field on SourcePackageRecipe:+index uses it
<mpt> wgrant, basic in what way? That it lets you choose from only your own PPAs?
<wgrant> mpt: And your teams'
<wgrant> mpt: Without searching
<cjwatson> Is that the same as the terrible list drop-down on +copy-packages?
<wgrant> cjwatson: It's arguably worse
<wgrant> although it at least shows the actual name
<wgrant> Not just the displayname
<wgrant> But it's paginated
<cjwatson> (Which is ambiguous if displaynames ever collide across teams)
<wgrant> And unsearchable
<mpt> wgrant, perfect. (For the purpose I'm thinking of, at least. Not necessarily Colin's.)
<cjwatson> +copy-packages would be improved by having to toggle in the PPA name in octal
<wgrant> Indeed
<wgrant> It's probably from back in the good old days when PPA names were immutable.
<cjwatson> (Also, IIRC it defaults to the copy target being the same PPA and same series.)
<wgrant> (although that still would have run into the duplicate person display name issue)
<jcsackett> sinzui: i can.
<sinzui> thank you.
<sinzui> I am switching dns servers at this moment so I was not certain I missed your reply
<jcsackett> sinzui: should it be marked qa-bad bad-commit &c?
<jcsackett> (the bug on said rollback branch)
<sinzui> jcsackett: yes, for our purposes
<jcsackett> sinzui: ok.
<jcsackett> i'll tag it as well.
<sinzui> jcsackett: we cannot prove it is safe to release so we do not want it to go out with the sharing code
<jcsackett> dig.
<jcsackett> sinzui: two more things. do you want to look at the MP, or are you cool with rs=me, and do we know if a rollback of this branch is safe to bzr lp-land or does it need to play on ec2?
<cjwatson> Should be safe to lp-land.
<sinzui> cjwatson: thank you
<cjwatson> Nothing else since then has touched related code.
<sinzui> jcsackett: use rs=you since cjwatson is the authority in this case
<jcsackett> cjwatson: thanks.
<jcsackett> sinzui: got it.
<jcsackett> sinzui: it's off.
<sinzui> thank you very much
<sinzui> jcsackett: cjwatson: buildbot now sees my restore of rev 15823. I think everything is now good. I have some hope another branch will land in the next few hours to justify the  build we have queued in build bot.
<cjwatson> Phew.
<abentley> deryck: I'm the OCR.  Do you have the time to review https://code.launchpad.net/~abentley/launchpad/upgrade-badly-stacked/+merge/120854 ?
<deryck> abentley, sure
<deryck> abentley, heh.  "I have a LOC credit of 1860."  Now you're just showing off there. ;)
<abentley> deryck: :-)
<sinzui> I believe wgrant is -26,000 LoC. I an -10,000 LoC since we started Disclosure
<sinzui> PS. The squad is as whole is +10,000 because of the new features
<elmo> is there a black market in LoC?
<elmo> if not, should I file a bug about implementing one in LP itself?
<abentley> elmo: I can hook you up.  There's some code that I know is going obsolete soon :-)
<deryck> It's like a bunch of MMO gold farmers up in here.
<deryck> abentley, r=me, looks good.
<abentley> deryck: thanks.
<sinzui> fab, I was going to as if that branch needed a review
<StevenK> wgrant: http://pastebin.ubuntu.com/1161748/
<StevenK> wgrant, wallyworld: What kind of sanity check does reconcile_access_for_artifact need?
<wallyworld> StevenK: when adding a new bug target, the target project may not have the relevant access policy defined
<wallyworld> so a check needs to be done that pillar count == policy count (in simplistc terms)
<wallyworld> wgrant says we should just raise an exception in that case
<StevenK> >= surely
<wallyworld> yes
<wallyworld> other way round perhaps
<StevenK> Ah, no, we need to make sure that each pillar has an AP.
<StevenK> And if no, croak
<wallyworld> each pillar needs to have an access policy for the relevant bug information type
<wgrant> wallyworld, StevenK: I think an exact match is best
<wallyworld> reason being?
<wgrant> There should be exactly one for each
<wgrant> If there isn't, something is wrong
<wgrant> If something's wrong, better to crash than corrupt
<wgrant> (eg. a private junk branch is being transferred to a public team somehow)
<wallyworld> ok, be interesting to see how many times we need to raise an exception in practice
#launchpad-dev 2012-08-23
<wgrant> Blah, smartmeter installation
<wgrant> No power for an hour
<wallyworld> you have solar?
<wgrant> No
<wallyworld> i only got my smart meter because i got solar
<wgrant> They're replacing them nation-wide eventually. And state-wide now
<bigjools> wgrant is going to feel like he's had an arm cut off with no interwebs
 * StevenK peers at Jenkins
<wallyworld> wgrant: StevenK: +7/-4 https://code.launchpad.net/~wallyworld/launchpad/edit-sharing-policies-1040336/+merge/120894
<StevenK> You can't keep but add lines :-P
<wallyworld> i know :-(
<wallyworld> little choice here though
<StevenK> wallyworld: r=me, with one thing to keep in mind.
 * wallyworld looks
<wallyworld> thanks
<wallyworld> StevenK: i looked at the other choice source popups which have descriptions (there are only a few on bugtask), and they are all ok
<StevenK> wgrant: BAH, tharwted by your factory.makeBug(target=) rather than product=
<wgrant> StevenK: Oh?
<StevenK> wgrant: Muscle prompted makeBug(product=product)
<StevenK> Muscle memory, rather
 * wallyworld needs to go buy coffee. !caffeine === bad
<bigjools> see you in 5 :)
<StevenK> Hmmm, wasn't test_getAllPermissions_constant_query_count failing about a week ago?
<wgrant> StevenK: Yes
<StevenK> wgrant: It failed in my destruction of security_contact with 19 != 20
<wgrant> Hmm
<StevenK> Hmm, it may not be failing locally.
<StevenK> wgrant: I can paste the query log from the ec2 failure if you wish.
<wgrant> Probably spurious
<wgrant> Land :)
<StevenK> wgrant: Hmmm, I may have introduced an unintended change.
<StevenK> I think that the bug supervisor will be subscribed to private bugs.
<StevenK> Er, PRIVATESECURITY bugs
<wgrant> That would be bad
<StevenK> Right, the bug supervisor is subscribed to PRIVATESECURITY bugs if the pillar has private_bugs.
<StevenK> Still bad?
<wgrant> If it's a regression, yes.
<wgrant> But it might not be
<StevenK> wgrant: In createBug it used to be if information_type in SECURITY_RELATED, grab security_contact, else if pillar.private_bugs, grab the bug_supervisor
<wgrant> Hum hum
<wgrant> I'd restore the old behaviour
<wgrant> Subscribe the supervisor if pillar.private_bugs and it's not in SECURITY_RELATED
<StevenK> RIght
<StevenK> wgrant: xx-upstream-bug-privacy.txt is also dumb. I had to change it from name12 to name16 because name12 was no longer subscribed
<StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/sanity-for-rafa/+merge/120912
<wallyworld> StevenK: i think it looks ok. i think we want a business exception rather than a ValueError though
<wallyworld> actually, the logic may be a bit out
<wallyworld> ah, no, ok
<StevenK> wallyworld: Happy to do so, I just couldn't think of a name, so went for ValueError
<wallyworld> yeah, i'm not sure if we have one already
<StevenK> raise SharingViolation("wgrant is very displeased with you.")
<wallyworld> it's more a SharingIntegrityError perhaps?
<StevenK> wgrant: ^
<wgrant> I think an assertionerror is probably correct
<wgrant> It's not a valueerror or typeerror
<wgrant> something is just broken
<wgrant> It certainly doesn't deserve its own Exception subclass
<wgrant> It'll hopefully never happen
<StevenK> Oh, then I'll just assert
<wgrant> No
<wgrant> Do not just assert
<wgrant> Raise AssertionError
<wgrant> asserts are skipped sometimes, eg if running optimised
<wgrant> Which we don't but still
<wgrant> We prefer to raise AssertionError explicitly for important sanity checks, I believe
<wallyworld> StevenK: i should have asked this up front sorry - could we include the info type in the message? not sure if we want to list the pillar names also?
<StevenK> Hmmm
<StevenK> Just trying to figure out how to phrase it
<wgrant> raise AssertionError("oh shit") :)
<StevenK>         raise AssertionError("All pillars require access policies.")
<wallyworld> It's more for us so we can look into the problem easier
<StevenK> Which is what I have now.
<wgrant> Right
<wgrant> So a list of pillars and APs might be useful
<wallyworld> These pillars (ccc, xxx, ccc) required access policies for information type xxxx but do not have one
<wallyworld> s/required/require
<wallyworld> or something
<StevenK> Well, I don't know which one is missing, I just know one is.
<wallyworld> you can figure out which one(s)
<wallyworld> the returned polices have pillars
<wallyworld> and compare that to the pillars parameter
<StevenK> wallyworld: http://pastebin.ubuntu.com/1162099/
<wallyworld> StevenK: look good. perhaps  ", ".join(...
<StevenK> wallyworld: http://pastebin.ubuntu.com/1162104/
<wallyworld> StevenK: great, thanks for the changes. +1 from me
<StevenK> wallyworld: Pushing it up now, since I got distracted.
<wallyworld> that's ok, i already +1
<StevenK> Yeah, I just saw, thanks.
<adeuring> good morning
<cjwatson> StevenK: I thought I'd testfixed test_getAllPermissions_constant_query_count.
<cjwatson> StevenK: Try sticking an extra list(self.main_archive.getAllPermissions()) before the record_two_runs call and see if that tickles it into appearing locally.
<StevenK> cjwatson: So far, I'm ignoring it hoping that buildbot doesn't get infected.
<cjwatson> The previous failure depended on test ordering.
<cjwatson> I'll be away for the next week, so your problem to fix it if it breaks. :-P
<czajkowski> heh
<czajkowski> cjwatson: random non LP question.  when I plug my laptop into charge, it does start to charge, however the screen brightness doesnt change, if I reboot machine it picks this up, any ideas ?
<cjwatson> No idea.  Not a kernel guy
<czajkowski> cjwatson: you're also not a LP guy either but know a fair deal, so just thought I'd chance my arm :)
<cjwatson> The kernel is a total blind spot for me
<bigjools> czajkowski: check to see if the acpi events are picked up in scripts in /etc/acpi/
<bigjools> night all
<czajkowski> bigjools: nn
<czajkowski> will do
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 4.0*10^2
<sinzui> sorry wallyworld. I see you have discovered that anything that adds a reference to the Person table require code to manage merges
<rick_h_> deryck: abentley adeuring I forgot to ask int he stand up, any JS issues? Thinking of flipping 3.5.1 for ~launchpad?
<abentley> rick_h_: I haven't noticed any issues.
<adeuring> rick_h_: i haven't noticed any
<deryck> rick_h_none that I've found
<rick_h_> ok thanks
<rick_h_> deryck: any reason to hold off on increasing the range on the FF then?
<rick_h_> I think we've been on it 1.5wk
<deryck> rick_h_no, I think it's safe.  flacoste, any concerns about turning lp on to yuk 3.5 for everyone on launchpad?
<deryck> yui rather
<sinzui> deryck: JFDI. We can always change the flag if we are proven wrong
<deryck> sinzui, ah, good advice.  Thanks :)
<deryck> rick_h_^^
 * sinzui wishes how could say the same about sharing flags
<rick_h_> ok, will do
<sinzui> jcsackett: once again fate pulls the chair out from under sharing
<jcsackett> sinzui: oh no.
<sinzui> jcsackett: Lp still does not permit structural subscriptions on ubuntu. It is not possible for the security team to subscribe to private security in ubuntu
<jcsackett> sinzui: can we rectify that? what is/was the reason for no structsubs on ubuntu?
<sinzui> I have hacked a url: https://bugs.launchpad.net/ubuntu/+subscriptions
<jcsackett> sinzui: so it's possible, we just don't have the UI in place?
<sinzui> jcsackett: I do not have permission to compete the change
<jcsackett> sinzui: ah, yes. i just did that same experiment.
<sinzui> So the question, is, If a webops did that, can he select the ubuntu-security, and can he save
<sinzui> Well, I will try this in a dev instance to verify if the security contact role role can create its own subscription
<sinzui> then I will try admin
<sinzui> then I will ponder the value of going on immediate vacation
 * jcsackett laughs
<sinzui> bugger. Dev permits anyone to subscribe to ubuntu
<sinzui> Ubuntu is configured different;y in production
<jcsackett> oh goody.
<flacoste> deryck: +1 to what sinzui said
<sinzui> gary_poster: benji: gmb: bac: can any of you remember what controls/blocks structural subscriptions on Ubuntu? Alas our own stories in dev show it can be done. I think a config option is preventing me (well I want ubuntu-security team) from creating a subscription to all private security bugs in Ubuntu
<gary_poster> sinzui, I don't but maybe if I tried to duplicate what you want to do it would ring a bell.
<sinzui> gary_poster: there is not link to subscribe to bug on ubuntu. not on the front page or on the bugs page. I can hack the url https://bugs.launchpad.net/ubuntu/+subscriptions and I can say what I want, but I get permission denied on save
<sinzui> http://people.canonical.com/~curtis/configure-ubuntu-security-notifications.png
 * benji hears bells far, far in the distance.
<gary_poster> sinzui, I duped.  ISTR something hard coded about subscribing to all ubuntu bugs. I don't think we touched it, and I could be making it up.  IOW, I'm not much help.
<sinzui> gary_poster: Indeed that is what I thought...but our dev instance lets me do it. I think I will try API or SQL to prevent ubuntu-security from getting a regression
<wgrant> sinzui: Looks like you need to be in the bug supervisor
<wgrant>         if IDistribution.providedBy(self) and self.bug_supervisor is not None:
<wgrant>             if subscriber is None or subscribed_by is None:
<wgrant>                 return False
<wgrant>             elif (subscriber != self.bug_supervisor
<wgrant>                 and not subscriber.inTeam(self.bug_supervisor)
<wgrant>                 and not subscribed_by.inTeam(admins)):
<sinzui> ah, thank you
<wgrant>                 return False
<wgrant> Oh, not just you, but the subscriber
<wgrant> I suspect an admin will have to do it through the API
<wgrant> Except ubuntu-security is in ~ubuntu-bugcontrol
<sinzui> fab
<wgrant> So an ~ubuntu-security admin can probably do it
<sinzui> They can do it.
<sinzui> I will show them my picture of what I recommend
<jcsackett> sinzui: so we can pick the chair pack up for sharing?
<sinzui> jcsackett: anyone with a clear head actually. wallyworld set a pre-emptive testfix to rollback a bad revision in db-devel. But since buildbot was running, it was ignored. Do I want to force a build to land a trivial testfix change to make the buildbot restart
<jcsackett> sinzui: i think so, yes. i mean, right now db-devel buildbot isn't running, right?
<sinzui> not running
<sinzui> ^ jcsackett does forcing a build pul the latest revision? if not I want to land a trivial testfix change to poke buildbot
<jcsackett> sinzui: i think you're right. forcing doesn't pull, it just restarts the known build.
<sinzui> okay. I will find a trivial text change to act as the test fix.
<sinzui> flacoste: Do you approve enabling writable sharing for everyone in production? https://pastebin.canonical.com/72918/
<flacoste> sinzui: of course!
<sinzui> This is just a formality
<sinzui> flacoste: sharing is one for everyone. I am making change to /launchpad now to repeat my qastaging activities to very all is well
<flacoste> \o/
<sinzui> ha, yes, I can finally get rid of all the deactivated user and structural subscription spies on ~launchpad's projects
<lifeless> sinzui: congrats
<sinzui> wtf? lifeless baby alarm go off?
<sinzui> I think I could celebrate by writing a api script that will share with a team, then unshare with the team members to cleanup any project's shares
<lifeless> sinzui: lifeless' alarm baby went off
<lifeless> Its like a baby alarm but organic.
<sinzui> :0
<sinzui> :)
<cody-somerville> What is the 'findReferencedOOPS' API call on projects about?
<lifeless> cody-somerville: it finds reference OOPS.
<lifeless> cody-somerville: OOPS that are not referenced are gcable by oops-tools.
<lifeless> if we had a generic fast RE engine across all project content, that method could go.
<cody-somerville> lifeless, What does it mean for an OOPS to be 'referenced' in this context though? I didn't think Launchpad itself stored information about OOPs?
<lifeless> If the text OOPS-123456 etc is in a text field in an asset relevant to the project.
<cody-somerville> ah, ok. So if someone mentions an OOPS in, for example, a bug report?
<lifeless> yes
<lifeless> oops.c.c sees I dunno, 40/50K per day
<lifeless> we toss most
<lifeless> ones folk put in bugs we keep
<lifeless> we keep them long enough for short term datamining
<lifeless> just long term we toss
<lifeless> after (IIRC) 5 days
<cody-somerville> Ok, Cool.
<sinzui> does anyone know if there is a team representing former canonical staff?
<sinzui> I have written a script that shares a project with a team, the revokes the direct access for the team members so that it is easy convert from subscriptions to shares
<jcsackett> sinzui: https://code.launchpad.net/~jcsackett/launchpad/kill-lazr-1/+merge/121079
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2
<lifeless> sinzui: there is
<lifeless> http://lmgtfy.com/?q=launchpad+not+canonical :P
<sinzui> thank you lifeless
 * mwhudson learns from that about a couple of people who've left...
<cjwatson> not-canonical includes people who never were
#launchpad-dev 2012-08-24
<wgrant> Yay
<wgrant> just configured a new commercial project on qastaging
<wgrant> With proprietary everything
<wgrant> As an unprivileged user
<lifeless> and an entitlement I presume ?
<wgrant> Right, you need a commercial subscription to activate the proprietary bits
<wgrant> But you get a complimentary 30 day sub automatically
<wgrant> So
<wgrant> Let's do a nodowntime
<wgrant> And then we can declare victory over Launchpad privacy
<wgrant> wallyworld, StevenK: https://oops.canonical.com/oops.py/?oopsid=9944a90ab5ba3bb77a3c7f4a17c39512
<wgrant> We have a problem
<wgrant> Huh, I'm not even sure why that's trying to filter by pillar
<wallyworld> looks easy enough to fix
<wgrant> I'm not sure there's a good reason to not just drop the pillar arg
<wgrant> But if we want to keep it then just grabbing the .pillar attribute should work~
<wallyworld> pillar is used for things like error recipients etc
<wallyworld> so we do need it
<wgrant> Hm, really?
<wgrant> Also, we should maybe guard that behind a privacy check
<wgrant> I thought the error recipient was just the requestor
<wallyworld> checkout the SharingJob getErrorRecipients and getOperationDescription methods
<wallyworld> pillar owners should be informed
<wgrant> Oh right
<wgrant> That was a late change
<wgrant> Forgot that
<wallyworld> so we just ned to extract the distro from DistributionSourcePackage and we are ok i think
<wgrant> Right, and BugTarget has a handy pillar attribute nowadays
<wgrant> So it's just a matter of adding that
<wallyworld> i can fix it. how often are we oopsing?
<wgrant> Probably on every transition that involves a DSP
<wgrant> I don't have numbers
<wgrant> But it won't be uncommon
<wallyworld> someone at front door, back in a sec
<wgrant> It'd be great if you could fix it, as I'm not exactly clear on what tests we have here
<wgrant> Sure
<wallyworld> hopefully that will be the only problem we find today
<wallyworld> StevenK: are you removing disclosure.unsubscribe_jobs.enabled ?
<StevenK> Yes
<wallyworld> StevenK: in that case, my fix for the oops will conflict. it's 1 line. so you could add it to your branch or i could remove that flag https://pastebin.canonical.com/72985/
<wallyworld> i added a drive by while i was there
<StevenK> Right
<wallyworld> bug 1040948
<_mup_> Bug #1040948: oops retargeting a bug to a distribution source package <bugs> <disclosure> <sharing> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1040948 >
<wallyworld> did you want to take it then?
<wallyworld> with the flag gone, no new tests will be required
<wallyworld> so it's a dead easy fix
<wgrant> We need the OOPS fix ASAP
<wgrant> The flag removal will break hundreds of tests
<wgrant> (I suspect, at least -- DB permissions are probably going to be scary)
<StevenK> Shall we cowboy the OOPS fix then?
<wallyworld> that might be an idea
<wgrant> Indeed
<wgrant> Given that it's Friday, that would be my suggestion
<wgrant> How close are we in terms of QA...
<wallyworld> QA of?
<wallyworld> the patch?
<StevenK> wgrant: We are nowhere near
<wgrant> There's a whole lot of disclosure-relevant revisions that we should really deploy today if possible
<StevenK> Still wondering how to QA my security_contact removal
<wgrant> Mmm, indeed
<wgrant> Might not be deploying today
<StevenK> Running test -vvm registry locally has tossed me 29 failures
<StevenK> And it's still going
<wgrant> Heh
<StevenK> wgrant: I guess I need to wait for the destruction of security_contact to be deployable before I land the DB patch that drops the columns.
<wgrant> StevenK: Not deployable
<wgrant> Deployed
<StevenK> Which is what I meant, but I thought so.
<wallyworld> hurry up branch scanner ffs
<wallyworld> sigh, looks like branch scanner fucked by branch
<wallyworld> my
<wallyworld> StevenK: wgrant: https://code.launchpad.net/~wallyworld/launchpad/retarget-bug-oops-1040948/+merge/121111
<StevenK> And a drive-by
<wgrant> wallyworld: r=me
<wgrant> But do check that it actually works :)
<wallyworld> already did that
<wallyworld> so now i request a cowboy?
<wgrant> qas first
<wallyworld> so lp-land, ask and for the rev to be cowboyed to qas?
<StevenK> Or wait six hours for buildbot
<wgrant> And 24 hours for QA
<wgrant> So what wallyworld said
<wgrant> StevenK: Up to 100 failures yet? :)
<StevenK> No, it was 30 for -m registry
<StevenK> Down to 6
<StevenK> And they're all celery
<StevenK> Oh, BLEH.
<StevenK> test_transition_to_{PRIVATESECURITY,USERDATA}_information_type all rely on the code that fires if the feature flag isn't set.
<StevenK> wallyworld: ^
<wallyworld> um
<wallyworld> so can you just change the expected subscribers in the test?
<wgrant> That sounds best
<wgrant> It's also possible that the tests are now pointeless
<wgrant> And can simply be deleted
<wallyworld> well, even if expected = [], then we should still test
<StevenK> I wasn't certain, which is why I bought it up
<wallyworld> since we want to avoid leaks
<wallyworld> StevenK: so i would modify the tests to change the expected subscribers list
<StevenK> MismatchError: There were 3 matchers left over: Equals(<Person at 0xfdf7990 bugsupervisor (Bugsupervisor)>), Equals(<Person at 0xddebf50 person-name-100016 (Person-name-100016)>), Equals(<Person at 0xd9eef10 subscriber (Subscriber)>)
<StevenK> For example
<wallyworld> so from memory, we no longer subscriber bug supervisor
<wallyworld> not sure about the other 2
<StevenK> Yeah, I'm not sure either
<StevenK> I think it requires more discussion, so I'm close to reverting the unsubscibe_jobs flag changes and proposing it
<wallyworld> what i normally do is construct each person with a name reflecting the role eg 'bug supervisor' or 'pillar owner' on then it's clear who the subscribers are in the logged error
<wallyworld> StevenK: ^^^
<StevenK> Well, it's quite obvious the tests are checking that bit of code only
<StevenK> http://pastebin.ubuntu.com/1163826/
<wallyworld> so you no longer allow for required subscribers
<wallyworld> on lines 16, 17
<StevenK> wallyworld: Are those two blocks unrelated then?
<StevenK> Because they're guarded by the same flag
<StevenK> And prod certainly isn't running that code
<wallyworld> are they really guarded by the same flag? i may have misread the diff
<wallyworld> i though that the flag was all about whether to run the job or not
<wallyworld> the flag is not about whether to remove unnecessary subscribers (from memory)
<StevenK> -                if len(subscribers_to_remove) and not bool(
<StevenK> -                    getFeatureFlag('disclosure.unsubscribe_jobs.enabled')):
<wallyworld> oh right, yes
<wallyworld> i didn't connect the dots properly
<wallyworld> i think we still need to understand whats going on here
<StevenK> I think the tests can pass as-is iff we run the RASJ
<StevenK> Or I can keep the behaviour and drop the FF guard
<StevenK> But I'm concerned because I think prod is not running that code
<wallyworld> maybe a check on qas to see what's happening?
 * wallyworld is late for school pickup
<StevenK> Yeah, I have to disappear for a bit too
<StevenK> wallyworld: I'll leave this for now, probably toss it at ec2, and we can chat about it on Monday
<wallyworld> ok, sounds good
<StevenK> wallyworld: Haha, db-devel failed in buildbot again
<wallyworld> sigh
<wgrant> It's StevenK's fault this time
<StevenK> Wat
<wallyworld> Exception: Timeout waiting for auditor to start.
<wallyworld> setup failure
<StevenK> I bet that's the port in use crap
<wallyworld> force it?
<StevenK> Yah
<NCommander> Need a SAN check: WAITING state in launchpad-buildd is when the buildd is waiting for buildd-manager to grab files or something of that matter?
<lifeless> could bug linking branches be broken in the World Order ?
<wgrant> lifeless: Yes
<wgrant> NCommander: yes
<wgrant> lifeless: It may be fallout from our work, but it's not clear.
<wgrant> at all
<wgrant> Hopefully blue can investigate the failures
<wgrant> And then throw them at us if it does prove to be our fault
<NCommander> wgrant: thanks. Second thing. THere doesn't seem to be much w.r.t test cases in launchpad-buildd; what is acceptable for tests in this case?
<NCommander> (I have a test_buildd_live-image script similar to the other ones that exist)
<wgrant> lalala
<NCommander> uh oh. I think I broke wgrant
<StevenK> Disclosure already broke him.
 * NCommander vaguely wonders if H.P. Lovecraft wrote parts of Soyuz
<NCommander> At least this part of this project approaching something resembling to completion. It properly handles dispatch builds, and two of the three build engines are almost fully coded. Need to add some slightly better error handling, and a more conclusive test runner
<NCommander> I know DEPFAIL builds get auto-retired at least for normal builds. If I have an image that skews, I don't think I want to give this state to Launchpad lest it try to spin images automatically
<StevenK> DEPWAIT
<nigelb> Oh dear, does wgrant have a case of the FRIDAY?
<NCommander> StevenK:     DEPFAIL = "BuildStatus.DEPFAIL"
<NCommander> StevenK: DEPWAIT as a state doesn't exist in the buildd code
 * StevenK quickly patches and merges it so it does.
<StevenK> You were saying? :-P
<nigelb> lol
<wgrant> It's DEPFAIL on the buildd
<wgrant> MANUALDEPWAIT in Soyuz
<StevenK> Yes, and it's automatically re-tried.
<StevenK> Who said Soyuz was confusing?
 * StevenK stabs the precise upgrader.
<StevenK> Why do you want to remove portmap? I need that!
<StevenK> Fetched 222 MB in 6s (15.2 MB/s)
<StevenK> Love my local mirror
<wgrant> StevenK: Just wait until it starts silently defaulting to NFSv4 and hanging
<StevenK> I don't want NFSv4 :-(
<StevenK> And anyone who tells me it's the future will be stabbed.
<ajmitch> with extra kerberos on top?
<StevenK> NFS was just FINE without KRB.
<wgrant> For not very big values of fine
<wgrant> NFS before Kerberos belongs in the 60s
<StevenK> Well, it did expand to No File Security rather than Network File System, but it was fine!
<StevenK> wgrant: Oh, so before Ethernet, and UNIX?
<StevenK> mgz: Some Launchpad branches are failing to scan too, and without using --fixes
<czajkowski> speaking of which mgz StevenK wgrant https://bugs.launchpad.net/launchpad/+bug/1040777
<_mup_> Bug #1040777: Scanning of branches with linked bugs is broken <Launchpad itself:New> < https://launchpad.net/bugs/1040777 >
<mgz> StevenK: thanks
<mgz> yeah, that's probably a misdiagnosis
<mgz> I can push branches with --fixes and they work, but ubuntuone-client seem to have a high incidence of failure
<wgrant> StevenK: Yes, it should never have been used :)
<wgrant> mgz: ubuntuone-client has more private bugs
<wgrant> Possibly relevant
<czajkowski> wgrant: and is the bug valid or was it being done wrong ?
<lifeless> --fixes private bug...
<wgrant> The bug is certainly valid
<wgrant> I don't know if the diagnosis is correct
<wgrant> Someone should test it
<adeuring> good morning
 * NCommander feels that Soyuz was written by taking the Necronomicon and rewriting the summoning instructions for a Great Old One in Python
<StevenK> Damn it, NCommander is catching on.
 * NCommander looks for commits by Abdul Alhazred
 * czajkowski is off to find tea in this place 
<NCommander> StevenK: re: NFS. Meh, upgrade to AFS. Less arcaic voodoo
<StevenK> Eh? What? Are you smoking crack. There's *MORE*.
<wgrant> Far more voodoo, but it's far less archaic and terrible voodoo :)
<StevenK> I was thinking about iSCSI
<NCommander> ATE is less pain
<NCommander> NFS == why stateless protocols suck
 * NCommander ducks
<StevenK> Now, I wonder if I need dkms for 3.2.0 on this machine
<StevenK> Sigh, yes.
<StevenK> Because updating the version of the atl1e driver is too hard.
<jam> jelmer: just checking in with you how the py2.7 stuff is coming. I see the 3 packages in ~jelmer/+archive/py2.7 which looks good.
<jam> is it time for us to start copying the other packages into there?
<jelmer> jam: yep, I'll put them all in the ~canonical-bazaar ppa
<jam> jelmer: sounds good, is the build system working a bit smoother yet, or do we still have a large backlog?
<jam> jelmer: looking here: https://launchpad.net/~jelmer/+archive/py2.7 i see 'failed to build' 3 days ago.
<jam> does that mean they were retried and successfull?
<jam> ah, missing dependencies seems to be claimed
<jam> 'libtinfo-dev'
<jam> it is in depwait
<jelmer> Hmm, that's definitely one I fixed
<jelmer> jam: I'll just upload to ~canonical-bazaar, should be fine there
<jam> https://launchpadlibrarian.net/113212101/buildlog_ubuntu-lucid-i386.python-defaults_2.7.3-0ubuntu6~lp1_FAILEDTOBUILD.txt.gz
<jam> seems to say there is a problem with deb helper and compat levels
<jam> dh_clean: Sorry, but 7 is the highest compatibility level supported by this debhelper.
<jam> I don't see anything about a libtinfo in https://launchpad.net/~pythoneers/+archive/lts/
<jam> so I don't really know what that means
<jelmer> jam: I've simply dropped that dependency, which was fine
<jam> jelmer: k, can we consider the py2.6 as Done-Done then, (it certainly built correctly)
<jelmer> jam: sure
<jam> jelmer: I'll chat with webops about coordinating getting packages into -cat, though we still need to vet everything in EC2, right?
<jelmer> jam: yep
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 4.0*10^2
<jam> jelmer: so do you want me to copy the packages to ~canonical-bazaar, or do we need to do a change to drop the extra dependency, etc.?
<jelmer> jam: I'll upload to ~canonical-bazaar
<jam> k
<jelmer> hmm, was +roadmap removed at some point?
<wgrant>   [r=gmb] Fix bug #174480 by removing the specificationtarget roadmap
<_mup_> Bug #174480: Person's +roadmap page contains blueprints they're not assigned to <lp-blueprints> <Launchpad itself:Fix Released by intellectronica> < https://launchpad.net/bugs/174480 >
<wgrant> It's been gone a while
<czajkowski> jelmer: I know what ti di wutg tgat queston
<wgrant> heroux: ^^
<czajkowski> got the answer last night off flacoste
<czajkowski> but want to talk to mrevell about the update of the page
<jelmer> czajkowski: ah, cheers
<czajkowski> thanks
* bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: 4.0*10^2
<bac> yes please
<bac> https://docs.google.com/a/canonical.com/spreadsheet/viewform?formkey=dGpha1NHV2t4VU1ZSU9FZDdMRnlEZWc6MQ&ifq&pli=1&auth=DQAAAKEAAABo3bjn2-seKH26Wayo7aGz3TXRSLqxBB0kow7ltNjO6Be3g2CPijNFrSW7HBWMiRM3Qya0NGza7qgUzNGIejTm3cICSpVWTOiTZmr2lSkoSC6Tm7nUliaLq-Y5SnyAFYZYYdE5HtDqP9YM8TuJfUXgWwQoAWvpFvFZZD9Og7S4rCW34QrxE77EPctJubSTZpWjTv6FvlUz44rQxQCxRQaz7UjNHh7yL6MFoyuY9SWIbw&authuser=1
<bac> nm
<bac> gary_poster: ^^
<jam> jelmer: hows the package uploading going? I'm pretty sure we're not going to quite get it all vetted for web-ops review by the end of the day.
<jelmer> jam: Sorry, was distracted trying to finish off some of my other work. They're uploaded now.
<jam> jelmer: to what ppa? (I'm not seeing it browsing around)
<deryck> adeuring, abentley, rick_h_ -- hi there.  I'm here today after all.
<deryck> Late news yesterday that my home wouldn't close today.
<jelmer> jam: https://launchpad.net/~canonical-bazaar/+archive/py27, though I don't see them either yet
<wgrant> jelmer: py27, not py2.7
<wgrant> 2012-08-24 12:55:13 DEBUG   Launchpad failed to process the upload path '~canonical-bazaar/py2.7':
<wgrant> 2012-08-24 12:55:13 DEBUG
<wgrant> 2012-08-24 12:55:13 DEBUG   Could not find a PPA named 'py2.7' for 'canonical-bazaar'.
<jam> jelmer: right
<jam> I see it now, but it looks like 16-24 hr backlog
<sinzui> adeuring: your branch is blocking a rollout http://lpqateam.canonical.com/qa-reports/deployment-stable.html
<adeuring> sinzui: sorry, qa'ed th branch earlier today, but forgot to update the bug. done now
<sinzui> rock
<sinzui> thank you adeuring
<czajkowski> does this make sense to anyone https://bugs.launchpad.net/pybars/+bug/1040096  :/
<_mup_> Bug #1040096: Missing a context variable causes an exception <pybars:New> < https://launchpad.net/bugs/1040096 >
<rick_h_> czajkowski: yea, makes sense
<rick_h_> czajkowski: have to see if that's design or bug
<sinzui> jcsackett: Bug #1035298 need qa
<_mup_> Bug #1035298: lazr namespace in js modules should be removed <javascript> <qa-needstesting> <tech-debt> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/1035298 >
<rick_h_> looks like the bug says it's different so guess it's a bug
<czajkowski> rick_h_: k cheers
<jcsackett> sinzui: done.
<sinzui> thank you!
<sinzui> have a nice vacation
<wgrant> sinzui: I'm not sure where you're thinking of deploying up to, but I'd be fairly reluctant to do 15857 (the security_contact removal) on a Friday night.
<wgrant> The rest looks quite sensible
<sinzui> wgrant: I am somewhat more reluctant to release the features that I know are needed for commercial admins to complete sharing participation
<wgrant> sinzui: I think all the important changes are before the security_contact revision
<sinzui> wgrant: http://pastebin.ubuntu.com/1164503/
<wgrant> So it should be doable
<wgrant> sinzui: Hm?
<wgrant> Those two hunks look unrelated
<sinzui> ^ my change to ensure the commercial admins only get access to commercial project sharing requires a grant to the mailprocessor. You expressed some concern that the change could affect other scripts
<wgrant> Oh, right.
<sinzui> We can apply the index in production now. But my change might really be for you to deal with monday
<wgrant> We already cowboyed a similar permission fix tonight, as you may have seen
<wgrant> Agreed
<wgrant> Though the index is not important now...
<sinzui> So I will list a release as required for czajkowski and yourself to help users next week
<wgrant> Also, I think that index may already be on production
<czajkowski> sinzui: this will be for me and mrevell
<czajkowski> to go through things right ?
<sinzui> czajkowski: Lp is caught in an ironic state in production. We are one release away from the fix. Lp only lets commercial admins set the bug and branch sharing policy, but they cannot see the sharing page. The fix is to let use see the page for commercial projects and let maintainers set the policies themselves
<sinzui> At this moment in Lp, we commercial admins can only configure the policies for our own projects. wgrant and I just updates Lp's projects. Cody can configure his projects if he chooses. That is about it
<jam> jelmer: so it looks like the python-2.6 i386 build got promoted and completed quickly, is it possible to do the python-2.7 and python-defaults?
<jam> If they are all going to queue for a while, it would be good to get them done over the weekend.
<wgrant> jam, jelmer: I've given that whole PPA a score bump
<jam> wgrant: thanks
<wgrant> So new uploads should build quickly
<czajkowski> sinzui: ah ok
<jam> wgrant: yeah I saw it hit score of 99999 or something like that :)
<czajkowski> mgz: could you look at https://support.one.ubuntu.com//Ticket/Display.html?id=21263 please
<wgrant> sinzui: So, I'll organise QA with StevenK on Monday, hopefully deploy in the morning, watch for missing permissions, and hope nothing breaks while the UK is on holiday
<wgrant> sinzui: Have you talked czajkowski/mrevell through what needs to be done?
<sinzui> I was preparing it when I got the urge to do the release
<wgrant> Great
<czajkowski> as you do :)
<wgrant> I shall see you in a week and a bit, then
<sinzui> we can review sharing on qastaging now if your like
<jelmer> wgrant: ah, thanks :)
<sinzui> czajkowski: ^ you can see what we are advising users to do
<sinzui> https://qastaging.launchpad.net/fusionapp/+sharing
<sinzui> maybe I can get a sql report that will suggest the mapping of old rules to new sharing?
<mgz> czajkowski: looking
<mgz> ...that's... not the most useful question
<mgz> answered.
<deryck> abentley, I'll send you my updated doc in 20 minutes.  And how about we talk around 30 minutes after that?  To give you time to review it and think on it.
<abentley> deryck: sounds good.
<deryck> abentley, great, thanks!
<rick_h_> deryck: abentley opinions on feature flag naming? Was going to use private.project.enabled
<abentley> rick_h_: I think we're supposed to name the application first if applicable.  registry.project_privacy.enabled?
<deryck> rick_h_, I think I would go with disclosure.private_projects.enabled
<rick_h_> abentley: yea, wasn't sure on that. purple seemed to use disclosure. so stuck with that
<rick_h_> ok, can jump on their space they carved out
<deryck> oh, sorry, missed abentley's reply
 * abentley does not have a big stake in this.
<deryck> I think the goal was to keep all related work under the disclosure project under that name.
<rick_h_> yea, figured I'd just sanity check, will stick with disclosure
<rick_h_> deryck: rgr
<deryck> I'm not picky if the middle bit is private_projects or project_privacy or some other form of that
<abentley> rick_h_: We need to consider how we display People associated with blueprints (those who have access, and those who are subscribed).  Could we chat about this at some point?
<rick_h_> abentley: sure thing
<abentley> rick_h_: When's good for you?
<rick_h_> abentley: give me 5 to look over the blueprint stuff and we can hangout
<abentley> rick_h_: Cool.
<rick_h_> abentley: normal standup hangout ok?
<abentley> rick_h_: sure.
<abentley> sinzui: We've stumbled over some UI issues with subscribers on blueprints and access grants.  Do you have time to chat about what you're doing with bugs?
<sinzui> abentley: I am
<sinzui> sorry for the delay...my lunch appoint was interrupted by a kind police officer that pointed out my car was not street legal
<abentley> sinzui: Cool.  Could you meet me and rick_h_ in http://tinyurl.com/orange-standup ?
<sinzui> I had to detour to get the car inspected to prove it was legal
<lifeless> sinzui: So, cop was wrong.
<lifeless> sinzui: ?
<sinzui> No, my stickers expired last month
<sinzui> I don't drive often enough to notice
<lifeless> sinzui: ah. I had that earlier this year. Having baby blew our attention away from such things. OOPS.
<sinzui> Wow. 16 people have viewed the sharing video I uploaded within 15 minutes. I haven't even finished the blog to announce it
<wgrant> Oh
<wgrant> wallyworld
<wgrant> 's db-devel revert landed on devel
<wgrant> That explains the conflict
 * wgrant disentangles
#launchpad-dev 2012-08-25
<StevenK> ~/aw
<psychognite> helo sir, i have some problem out there
<psychognite> i have a ppa which is showing that it has been deleted
<psychognite> how can i activate that ppa or create a new ppa with same name ... ?
#launchpad-dev 2012-08-26
<wallyworld_> wgrant:  StevenK: hi, so we should look to do a deployment this morning. if you were to get your qa done, we could almost do to the end of the current revision list
<wgrant> Indeed, just trying to sort out why I can't actually connect to Europe still
 * wgrant tunnels through US
<wallyworld_> wgrant: also, i need to do a FDT of 11862 (or 11864 i guess) but fdt is currently blocked according to the LPS page?
<StevenK> We need to switch back to wild, choke and hack before we can attempt a FDT.
<wallyworld_> ok. timeframe for that?
<StevenK> druk and whatever the other one are precised.
<wgrant> Right, if we're lucky we *might* be able to fdt tomorrow night
<wallyworld_> ok. np. i have about 3 cards in the landing lane that will stay there until then
<wgrant> Hm
<wgrant> I think this is actually *faster*
<wgrant> because I'm tunneling everything through a v6 connection to my US VPS
<StevenK> Hah
<wallyworld_> StevenK: do you know if those bb failures due to the auditor fixture setup are sorted or whatever?
<wgrant> Someone should convince someone to check pilinut to see if there's any stuff left around
<StevenK> wallyworld_: It was just one.
<wallyworld_> i'm also not sure about the latest db devel failure in test_getAllPermissions_constant_query_count
<wallyworld_> i saw 2 i'm sure
<wallyworld_> but maybe not
<wgrant> wallyworld_: btw, not sure if you saw, but I reverted your reversion of db-devel in devel, then reverted the reversion of the reversion in the stable->db-devel merge
<wallyworld_> i think one was in devel and one in db devel
<wgrant> Since you mislanded it
<wallyworld_> oh, sorry. what did i do?
<wgrant> Your initial person merge testfix (reverting the DB patch entirely) landed on devel
<wgrant> That's why it didn't fix db-devel
<wallyworld_> oh bollocks
<wgrant> That explains why we were all so confused and buildbot didn't auto-kick :)
<wallyworld_> thanks for fixing it then
<wallyworld_> yeah, that explains it
<wallyworld_> so this  test_getAllPermissions_constant_query_count failure, do you recall seeing that before? it seems vaguely familiar
<wgrant> We'll need to be very careful with the next db-stable merge, though
<StevenK> wallyworld_: I'm still wondering *how* to QA my death to security contact branch ...
<wgrant> cjwatson added that a couple of weeks ago
<wgrant> It spuriously failed for a while
<wgrant> then cjwatson fixed it
<wgrant> but it's apparently not quite fixed
<wallyworld_> yeah, so do we comment out that test?
<wgrant> How common is it?
<wallyworld_> or just leab db devel bb for a bit
<wallyworld_> not sure how common
<wallyworld_> just see that it's broken now
<wallyworld_> i guess since fdt is stalled, we can leave it for him to fix maybe
<wallyworld_> StevenK: that's the branch to delete security contacts?
<StevenK> wallyworld_: It does not delete them from the DB. It drops the code from the model, UI and tests.
<StevenK> The DB branch can not land until that branch is deployed.
<wallyworld_> sure
<wallyworld_> so i guess it's a matter of filing some security bugs on qas and managing subscriptions etc - all the stuff that used to touch security contact - and see what breaks
<wgrant> And non-security private bugs, on both private_bugs=True and False
<wgrant> And check transitions as well
<wallyworld_> do we seem to be getting a lot of "slave lost b b errors lately?
<wgrant> That's usually ops restarting things
<StevenK> wgrant: So I have a new project -- security contact isn't in the UI, so that's a plus. I've set private_bugs=True so now I should file a security bug to see that it stays as PRIVATESECURITY and a normal bug to see it gets overridden to USERDATA?
#launchpad-dev 2013-08-19
<StevenK> wgrant: Blah, specification has two zope subscribers and the first is caching the work_items cachedproperty
<wgrant> StevenK: :(
<StevenK> wgrant: http://pastebin.ubuntu.com/6001464/
<wgrant> StevenK: Why is the caching a problem?
<StevenK> wgrant: Because it is caching an empty list which means the second subscriber thinks that nothing on the spec has changed
<wgrant> StevenK: Shouldn't the method that is adding workitems be invalidating the cache?
<StevenK> wgrant: ISpecification.updateWorkItems() invalidates the property cache for work_items
<wgrant> StevenK: Then why is the thing being cached a problem?
<wgrant> If the only thing that updates it invalidates the cache..
<StevenK> wgrant: I'm not sure why the first zope subscriber sees no workitems and so caches []
<wgrant> I'd try to work that out.
<wgrant> As it seems to be the key to the problme.
<wgrant> jelmer: Thanks. I can land the bzr-git branch myself once you do the dulwich one.
<jelmer> wgrant: great - you managed to get a hold of jam?
<wgrant> Yep
<jelmer> wgrant: what are the plans with regard to codehosting in Launchpad, is it just going to stay as is for the near future?
#launchpad-dev 2013-08-20
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/distroseries-spec-preload/+merge/180046 is updated, and it failed ec2 last night, but the only failures were related to builders and Fault 8002.
<wgrant> StevenK: When last night did you start it?
<wgrant> I thought I fixed the 8002s in the early afternoon.
<wgrant> Hum
<wgrant> No, 21:06
<StevenK> wgrant: It finished at 9pm, so 5ish
<wgrant> Right, so you had the bad lpbuildd
<wgrant> So that's fine
<wgrant> I'll review after lunch
<wgrant> :)
<StevenK> wgrant: Than microservices!!
<wgrant> I'm melting strawberry atm.
<StevenK> Poor strawberry
<StevenK> wgrant: It's after lunch; good news, bad news, no news?
 * StevenK takes that as 'no news'
<wgrant> Soon soon
<stub> StevenK: You can review my branches if you are bored ;)
<wgrant> StevenK: I've done a bit of testing of buildd-manager on DF.
<wgrant> Have you looked at all?
<StevenK> I have not.
<wgrant> I think it's probably OK to deploy, particularly now that the ARM buildds don't suck; slightly overzealous error handling isn't going to be a huge problem any more.
<StevenK> The pandas are still around, just manualed, right?
<wgrant> I believe they're inactived.
<wgrant> But probably not actually switched off yet.
<wgrant> Yeah, still not there on /builders.
<StevenK> They seem to be gone, indeed
<StevenK> We probably need a fitz, though
<StevenK> wgrant: If the new stuff works fine with un-upgraded buildds, then I agree about the error handling, and we should deploy.
<wgrant> If something goes terribly wrong we can always undeploy :)
<StevenK> wgrant: WRT lines 125-127, the method involved is one that deletes workitems that aren't referenced any more and is only called by updateWorkItems. I wanted to be certain it grabbed whatever was latest. But I can change it to use the cached version if you wish.
<wgrant> StevenK: I thought the one I pointed out was in workitems_text
<wgrant> The one after was updateWorkItems
<wgrant> But I may be wrong
<StevenK> The one after is lines 134-137
<StevenK> That one doesn't used the cached version since we just deleted non-matching workitems, and the old code duplicated the method anyway.
<StevenK> And we blow the cache away at the end of the method anyway
<StevenK> wgrant: workitems_text is lines 88-89 and 97-102
<StevenK> And does make use of the cached property, for obvious reasons.
<wgrant> Ah, you're right
<wgrant> I was looking at the wrong part of the file.
<StevenK> wgrant: Your objection is withdrawn?
<wgrant> Indeed
<StevenK> wgrant: I'm looking into your suggestion about rewriting the horrible double loop
<StevenK> wgrant: Blah, I forgot about a comment I rewrote to be less like a novel, but: http://pastebin.ubuntu.com/6005501/
<wgrant> StevenK: That makes a lot less nonsense.
<StevenK> I didn't want to stuff around with going back from specid in work_items_by_spec.keys() to spec so I could get a cache -- if the spec id isn't in work_items_by_spec it returns [] anyway since it's a defaultdict.
<wgrant> StevenK: Oh, since you're going through rows this time you can remove the code that presets the work_items cache to []
<StevenK> Good point, killed.
<StevenK> I shall push and land
#launchpad-dev 2013-08-21
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/hide-related-blueprints/+merge/181198
<wgrant> StevenK: k
<StevenK> wgrant: Re bug 1128655 ; http://pastebin.ubuntu.com/6009086/
<_mup_> Bug #1128655: Creating a recipe and then requesting a build has an incorrect PPA selected by default in the build request dialog <confusing-ui> <easy> <ppa> <recipe> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1128655>
<wgrant> StevenK: What will happen if the user can't write to either the last build PPA or the daily build PPA?
<StevenK> wgrant: The list is populated with PPAs the user has upload permission for, so if the initial value is not in that list, I'd hope its ignored.
<wgrant> StevenK: Right, which means you have the same problem.
<wgrant> It ends up selecting the first PPA in the list.
<StevenK> In the case of the daily build PPA or last build PPA being unappendable, I think that's okay
<wgrant> I don't think so.
<wgrant> It's too easy an accident to make, and lots of people make it.
<wgrant> I think it should default to the daily build archive or nothing.
<wgrant> Probably.
<StevenK> Only probably?
<StevenK> wgrant: Like http://pastebin.ubuntu.com/6009118/ , then?
<wgrant> StevenK: Right, but you'll also need to change something so the <select> has an option for no value, and ensure that the form rejects that.
<StevenK> Oh, so the default is empty string or something
<StevenK> (With no daily build archive)
<StevenK> wgrant: http://pastebin.ubuntu.com/6009155/
<wgrant> StevenK: Does ensuring that the archive field is required not work?
<wgrant> The form infrastructure has some built-in functionality to add a "(no value)" option.
<wgrant> Or some text like that.
<StevenK> wgrant: The only thing I can see like that is missing_value for Field
<StevenK> But that doesn't add it to the vocab
<wgrant> StevenK: It doesn't need to be in the vocab, just the form field.
<wgrant> eg. +copy-packages overrides it to say "The same series"
<StevenK> wgrant: Which requires a new class that subs from LaunchpadDropDownWidget -- all the existing code has a Choice()
<wgrant> StevenK: Have you looked at the internals to see how you can make the option appear?
<StevenK> I've tried. zope.schema eats babies.
<StevenK> wgrant: http://pastebin.ubuntu.com/6009237/
<wgrant> StevenK: Can you possibly just override the field used by the *widget* to have required=False, so the validation can see required=True as normal, obviating the need for the extra code in validate()?
<StevenK> wgrant: I could, if I could figure out how to do that
<wgrant> StevenK: You can do it using a custom_widgets attribute on the form, I think.
<StevenK> Really?
<StevenK> I thought I would have reach into setUpWidgets and such
<wgrant> You might have to.
<wgrant> custom_widgets might just let you specify custom classes.
<wgrant> Not sure.
<StevenK> I think it's just custom classes, yeah.
 * wgrant mocks tests down from 3s to 0.008s.
<StevenK> wgrant: I recall self.fields.omit() -- but it seems widgets don't work like that
<GuidoPallemans> Hi everyone, I'm planning on building a launchpad app for the Ubuntu touch project, but I don't personally use launchpad actively. Can anybody help me what this app needs? it's going to be pretty basic
<StevenK> wgrant: So yes, I can add a widget with required=False, but TBH, it's easier to change the field in the schema and eat the check in validate
#launchpad-dev 2013-08-22
<wgrant> StevenK: mm
<StevenK> wgrant: http://pastebin.ubuntu.com/6012298/ its pretty ugly
<wgrant> StevenK: I think that's still more consistent, and not that ugly.
<StevenK> wgrant: Except that the initial value no longer works, and the ordering of the form changed to have distroseries at the top
<wgrant> Hmm
<wgrant> OK, maybe the other way is better.
<StevenK> Now for some tests
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/set-initial-archive-daily-build/+merge/181440
<wgrant> StevenK: Sounds good
<wgrant> About to land a 2kline buildd-manager branch, btw.
<wgrant> Extracting all the twisted stuff out of the Builder DB class.
<StevenK> wgrant: OMG
<lifeless> don't forget to ask for special dispensation :P
<wgrant> The Twisted stuff isn't completely layered on top of the DB stuff yet, but it's close.
<StevenK> wgrant: It stops the commit madness?
<wgrant> No.
<wgrant> But letting the Twisted stuff run without touching the DB objects is a prerequisite.
<wgrant> So they need to be split.
<StevenK> Right.
<StevenK> wgrant: So this is the first step, cool. It won't conflict with Colin's abort work?
<wgrant> StevenK: His remaining b-m branch is small and merges pretty easily, but I've prepared a merge branch.
<StevenK> wgrant: So I get to spend an hour reviewing twisted and having my brain leak out of my ears?
<wgrant> No, it's sufficiently mechanical, Twisted and brain-melting that it's not worth reviewing. It's well-tested, pretty simple, and so repetitive that you'd be unlikely to notice any issues.
<wgrant> The next branch will probably want review :)
<lifeless> it being 2K LOC is also why you wouldn't notice issues
<wgrant> It's not very splittable, because the bits all interact.
<lifeless> I get that
<lifeless> just saying, part of the problem is size.
<wgrant> Sure
 * StevenK waits for lifeless to start banging buildd-manager-as-a-microservice drum
<wgrant> 800 lines of anything is reviewable :)
<StevenK> Speaking of, microservices!
<wgrant> And this is a big part of splitting buildd-manager out into a
<wgrant> more separate thing.
<StevenK> wgrant: Talking to the DB how?
<wgrant> Probably XML-RPC initially. But that's way down the line.
<wgrant> The main thing now is to get sane structure.
<lifeless> StevenK: I don't need to bang the drum, you guys are on it
<StevenK> Mostly as a humour device
<lifeless> boom tish
<wgrant> StevenK: You broke the build.
<StevenK> I could have sworn I ran tests before proposing
<StevenK> wgrant: I'll fix when my tea that isn't dishwater is done
#launchpad-dev 2013-08-23
<StevenK> wallyworld: Can I pick your brain?
<bigjools> he's in my kitchen
<StevenK> You've put him to work?
<bigjools> only thing he's good for
<StevenK> True
<StevenK> bigjools: He's chained to the cooktop?
<bigjools> actually I think he's stealing my food
<StevenK> That sounds more like wallyworld
<bigjools> will have to send him to Port Arthur
<StevenK> I didn't think he was cooking you anything :-)
<wallyworld> StevenK: hello there
<StevenK> wallyworld: What did you score? :-P
<wallyworld> fresh bread
<StevenK> wallyworld: I'm looking at the BMP page, and I can't work out how the inlineedit widgets get created to start with
<wallyworld> lol. i can't recall ottomh. i can look at the code
<StevenK> wallyworld: javascript/branchmergeproposal.reviewcomment.js uses them in Y.lp.widgets[name], but I can't work out what populates them
<wallyworld> i'll have alook
<wallyworld> except i need to re-install some stuff cause my raring went tits up a couple of weeks ago and i had to rebuild, so give me a minute
<wallyworld> StevenK: so, branchmergeproposal-index.pt loads the javascript, wheich then hooks up the widgets, is that the bit you are after?
<StevenK> wallyworld_: I can't work out what populates Y.lp.widgets[name]
<wallyworld_> StevenK: ok, let me look. my fucking computer shutdown due to low battry. i thought it would have suspended, but noooooo
<StevenK> I think it's the trickery in branchmergeproposal-index.pt <tal:widget replace="structure view/commit_message_html"/>
<StevenK> Which returns a TextAreaEditorWidget
<StevenK> wallyworld_: Or am I barking up the wrong tree?
<wallyworld_> StevenK: so, BranchMergeProposalView has a property commit_message_html
<wallyworld_> which loads a TextAreaEditorWidget
<wallyworld_> which has a template text-area-editor.pt
<wallyworld_> which has javascript with a line: lpns.widgets['${view/content_box_id}'] = widget;
<wallyworld_> so the tal replace injects the value of the property
<wallyworld_> which uses the editor tal to render some html
<wallyworld_> make sense?
<StevenK> wallyworld_: Yes, clear as mud
<wallyworld_> you sure?
<wgrant> StevenK: Hm, does your workitem preloading not exclude deleted ones?
<StevenK> wgrant: It would seem not :-(
<wgrant> StevenK: Can has fix? :)
<StevenK> wgrant: Should I change load_referencing to ignore them, or just not add them to the defaultdict if deleted?
<wgrant> StevenK: load_referencing might already take extra conditions. If not, I'd suggest letting it take extra conditions.
<wgrant> It seems like it would be generally useful.
<StevenK> wgrant: No extra conditions
<StevenK> wgrant: Is there a bug?
<wgrant> StevenK: I don't think so.
<StevenK> wgrant: http://pastebin.ubuntu.com/6016516/
<wgrant> StevenK: Looks reasonable.
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-preload-deleted-workitems/+merge/181708
<wgrant> StevenK: Land it.
<wgrant> :)
<wgrant> StevenK: Your caching introduced a seriously weird bug where adding workitems to a blueprint that has none returns an empty workitems_text
<wgrant> I'm investigating, but it's really really weird.
<wgrant> The new SWIs aren't being flushed immediately for some reason.
<wgrant> Will investigate and fix tomorrow.
<StevenK> wgrant: Why are you playing with workitems, out of interest?
<wgrant> StevenK: QAing your thing.
<wgrant> Hm
<wgrant> SWI is a StormBase, not an SQLBase, so it shouldn't have been working without an explicit add.
<wgrant> I wonder how they are being added today.
<StevenK> Heh
<wgrant> I intend to deploy your fix shortly.
<stub> Because fixing SWI flushing is what you do on Saturday :-P
<shadej> hi
<shadej> I want to participate on ubuntu devt software localization
<shadej> quick start help?
<dowson> The instructions mentioned here: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally is out of sync with the source tree here: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/files
<dowson> I can't find a lib/canonical/buildd folder in the launchpad-buildd source tree.
<wgrant> dowson: That's now in lp:launchpad-buildd
<wgrant> Or you can just install launchpad-buildd from ppa:launchpad
<dowson> I want to build from sources. I tried the following command: bzr branch lp:launchpad-buildd
<wgrant> That's correct.
<dowson> is that the correct command?
<dowson> I want to try out the local build slave
<wgrant> Yes.
<dowson> https://dev.launchpad.net/BuildFarm/TryOutBuildSlave
<dowson> Build the package
<dowson>   cd lib/canonical/buildd
<dowson>   debian/rules package
<dowson>   dpkg-buildpackage -b
<dowson> so there is no lib/canonical/buildd folder
<wgrant> No, it's just in the root now
<wgrant> Because it's in its own branch.
<dowson> what should I be doing?
<dowson> should I create the folder lib/canonical/buildd
<dowson> and then execute the the rest of the commands?
<wgrant> dowson: No, omit the cd
<wgrant> The package is in the root of lp:launchpad-buildd
<dowson> I'm sorry, I can't find it.
<dowson> the root of the package doesnt have a lib folder to begin with
<wgrant> There is no lib/canonical/buildd
<wgrant> That tree was moved into a separate branch
<dowson> oh, so just run the second set of commands .. ok got it now.
<dowson> if I have to setup a pbuilder chroot, does the rest of the instructions still hold good here: https://dev.launchpad.net/BuildFarm/TryOutBuildSlave
<wgrant> dowson: A pbuilder chroot?
<wgrant> For what?
<wgrant> Launchpad doesn't use pbuilder.
<dowson> this for soyuz.
<wgrant> HowToUseSoyuzLocally describes where to get a prebuilt chroot.
<dowson> the instructions in the link above talked about setting up a pbuilder root. I will be trying to cross compile Ubuntu for ARM locally on an X86_64 machine.
<wgrant> Why are you trying to do that?
<dowson> I want to build for my i.MX6 board, with a specific toolchain generated from the Yocto project, and then use that to fully rebuild a Ubuntu for ARM distro, using that toolchain.
<dowson> I get an error while running the debian package command
<dowson> dh_clean
<dowson> make: dh_clean: Command not found
<dowson> make: *** [clean] Error 127
<dowson> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
<dowson> debuild: fatal error at line 1350:
<dowson> dpkg-buildpackage -rfakeroot -d -us -uc -S failed
<wgrant> Doing that with Launchpad without thoroughly knowing Launchpad from a normal user's perspective is going to be quite a challenge.
<wgrant> And without knowing Debian packaging well.
<dowson> I know, but I want to give it a shot.
<dowson> I'm familiar with cross compiling using Yocto and openembeded, I haven't done building Ubuntu before.
<wgrant> Those two are designed for cross-compilation.
<wgrant> Ubuntu can't be cross-compiled as such; if you want to do it cross-arch then you have to build it with qemu
<dowson> yes, i understand.
<dowson> I plan on using an Yocto generated QEMU for this.
<dowson> I just need to know how to tie in my Yocto generated QEMU to the Ubuntu build infrastructure, and where to get the package specifications to perform a build of Ubuntu 12.04 for ARM, using a custom toolchain, also generated using Yocto.
<dowson> is there a file that you can point me to, where the qemu image and cross-compiler toolchain location and name is specified?
<wgrant> There's no easy way to just rebuild Ubuntu.
<wgrant> There's nothing like that.
<wgrant> We don't generally cross-compile, except for some relatively experimental ARM PPA builds, which just use qemu-user-static.
<wgrant> Which isn't terribly reliable.
<dowson> I have an actual target board as well, a freescale i.MX6 quad, which already has ubuntu running on it. but I want to bootstrap it from scratch
<dowson> I prefer to try the QEMU approach first if possible, rather than native compilation.
<dowson> Is there some documentation that describes how to build Ubuntu with qemu?
#launchpad-dev 2014-08-20
<Pali> hello, I have problem with importing svn repo into launchpad bzr (via launchpad auto import service)... for 5 days it trying to import svn repo every 30 minutes and something is not working
<Pali> bzr repo is still empty
<Pali> it is normal?
<Pali> here is repo: https://code.launchpad.net/~pali/llvm/llvm-3.5
<wgrant> Pali: Subversion imports are done incrementally, a few thousand revisions at a time.
<wgrant> Something like LLVM has hundreds of thousands of revisions of history; it will take many attempts before it completely imports.
<wgrant> Ah, 500 revisions at a time, in fact.
<Pali> wgrant: so I just need wait more time?
<wgrant> Pali: Right.
<wgrant> Importing a large Subversion history can be very slow due to the nature of the protocol.
<Pali> ok
<Pali> looks like llvm has 216045 revisions, so it will take about 216045/500/2/24 ~= 9 days?
<Pali> wgrant: bzr repos from svn branches do not support stacked bzr?
<Pali> because there is already autoimporting llvm trunk branch into bzr (from svn), but not branch 3.5
<Pali> and both branches have big same history
<wgrant> Pali: They do not.
<wgrant> Imports are always independent.
<Pali> ok
<Pali> thanks for info, I will wait 4 days and if there will be problem I ask again
<Pali> wgrant: another question: it is possible to check how many revs are imported now?
<wgrant> Pali: No, you'd have to estimate from the number of imports so far.
<Pali> ok
<jelmer> wgrant: imports should be stacked I think
<jelmer> wgrant: or did I have a branch for that that never landed?
<wgrant> jelmer: I know you had an incomplete branch at some point. I don't remember how far it got, except that it certainly doesn't work on the side of the importer.
<wgrant> They may be stacked on codehosting, but they're certainly independent on the importd intermediary.
<wgrant> And the latter is all that matters for performance.
<jelmer> wgrant: ah, yeah. That must be it.
<jelmer> codehosting does stacking, and my branch to use stacking on the importer never landed.
<jelmer> (I remember we had bugs with regards to stacking for code imports)
#launchpad-dev 2014-08-21
<wgrant> jtv: Translations continues to try to lure me into its deep, dark traps.
<wgrant> jtv: Any chance you could try to dig out some memories of it to advise me on a couple of changes?
<wgrant> eg. http://bazaar.launchpad.net/~wgrant/launchpad/translationsplitter-no-manual/revision/17171
<wgrant> I see no reason I can't do that. All the tests pass.
<wgrant> But the code I replace is just three years old.
<danilos> wgrant, it seems it should be fine, though it might be slower (you'd be looking at all the templates that are not in the sharing subset anymore, but it used to look at all the templates that could have been in the sharing subset but are not anymore)
<danilos> wgrant, at least from the quick glance, and I don't have the extra context
<danilos> wgrant, the difference is in "could have been part of the sharing subset but not anymore" vs "all that are not part of the sharing subset"
<wgrant> danilos: Right, but the sharing subset is rarely going to be more than a few tens of templates.
<wgrant> So precalculating that list of IDs should be faster.
<wgrant> But I'll profile:)
<danilos> wgrant, right, and not(sharing_subset) is going to be a huge number of templates
<danilos> wgrant, though I am sure I am missing on some context there
<wgrant> Right, that's deliberate, because it's almost always going to be faster go to the other way.
<wgrant> I want the OtherTemplate to be the very last filter.
<wgrant> danilos: While you're here...
<wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/translations/translationmerger.py#L376
<danilos> wgrant, yeah, it looks good, but it has been a whiiileee :)
<wgrant> I don't understand the difference between mergePackagingTemplates and mergeModifiedTemplates. The former is used when adding/removing a link between a sourcepackage and a productseries, the latter when altering a POTemplate.
<wgrant> The former just calls mergePOTMsgSets, while the latter calls mergeAll.
<wgrant> I can't see any explanation for why they don't both mergeAll.
<danilos> wgrant, it's probably about leaving the "default" (or selected) translation messages between products and packages different
<wgrant> danilos: Except that mergeModifiedTemplates merges over the entire sharing subset, so I think the first modification of an involved template will do a mergeAll anyway.
<wgrant> Hm, though mergePackagingTemplates very deliberately sorts the templates, so maybe it's just trying to carefully ensure that the newest ones win.
<wgrant> Not sure it's actually deliberately trying to do less.
<danilos> wgrant, mergeAll seems to be introduced with https://code.launchpad.net/~danilo/launchpad/bug-814580/+merge/69978 where the important point was about removing a single template from a set of sharing templates
<danilos> wgrant, perhaps some of the code is now stale, the above was introduced because old code only seemed to detect when packaging links were changed, yet template might leave the sharing set if it's simply renamed
<danilos> wgrant, I can't think of why that would end up using different code paths, but maybe just some further refactoring was never completed
<danilos> (leave/join, that is, because this was about a template joining a set)
<wgrant> danilos: Yeah, a lot of it just seems to need more cleanup.
<danilos> wgrant, oh, definitely... and if you are really in for some fun, just look at the translation views for the +translate page :)
<wgrant> (I'm currently just trying to quickly fix some blocking issues with sharing between Ubuntu and other distros, for the RTM work.)
<wgrant> danilos: I have that on my schedule for next month.
<wgrant> Reworking the way the suggestions are done so the performance doesn't totally suck.
<wgrant> Already made some improvements there in June, but a lot to go... and it's quite a mess.
<danilos> wgrant, you can simply turn off the global suggestions :P
<wgrant> I deleted about 400 lines of dead translation view code.
<wgrant> Heh
<jtv> Ugh
<wgrant> There's still a config option for that.
<danilos> wgrant, yeah :)
<jtv> Hi chaps
<danilos> hi jtv
<wgrant> Evening jtv.
<jtv> Cleaning up old code?  Great.  And also, brave.  :-)
<wgrant> Un-hardcoding Ubuntu throughout LP has proven quite an adventure.
<wgrant> (the distros will still be linked more than they perhaps should be, due to TM.is_current_ubuntu applying to both, but that's actually desirable here)
<danilos> wgrant, a word of warning, a bunch of those queries were hand-optimized for the DB characteristics at the time
<wgrant> danilos: Yeah, but that's all gone out the window now that the indices no longer fit in RAM.
<wgrant> Sadly.
<danilos> wgrant, yeah, we figured that would happen, which is why the flag is named "is_current_ubuntu"
<wgrant> But we'll have SSDs $soon which should improve things...
<danilos> wgrant, i.e. as long as they are derived distros, if you can override translations for their series, you are golden
<wgrant> Yep.
<danilos> wgrant, but I am sure that still does not make it easy :)
<wgrant> The main issue with translations is that I don't know it very well and it's a bit of a mess :)
<wgrant> But there's nothing fundamentally difficult about this, and it all works now apart from TranslationSplitter being a bit aggressive.
<danilos> wgrant, "bit of a mess" is an understatement... sharing stuff is complicated and somewhat messy, but the non-sharing stuff is just mess all around
<wgrant> Heh
<wgrant> Yeah
<danilos> some of the messiness results from the fact that we were running code that supported both old, non-sharing and a sharing model at the same time
<wgrant> Right, there are still lots of jtv XXXs around saying that this code can die when sharing is universal.
<jtv> And now some of that is going to happen?  Brilliant.
<wgrant> Well, I'm not cleaning for the sake of cleaning. I'm making cross-distro sharing work properly, cleaning up as I go, and taking the opportunity to work out how to make suggestion performance not totally suck.
<danilos> wgrant, first thing to try out with suggestions performance is to try not to do it in 200 queries :)
<wgrant> Yeah
<danilos> wgrant, the other thing is to load global suggestions over ajax or something similar
<wgrant> I got +translate down by about 50-70% in June, but there's still a lot left.
<wgrant> I'm hoping that SSDs + reduced query count will obviate the need for AJAX.
<wgrant> Because that's more work than I have time for atm :P
<danilos> wgrant, right
<danilos> wgrant, you could also introduce an intermediate table for global suggestions that is updated daily or something, because these don't have to be always up-to-date, though that's another complication
<wgrant> danilos: I've experimented adding a couple of new columns to TranslationMessage to do that.
<wgrant> msgid_singular being the main one.
<jtv> It might make sense for the super-common strings, just to get some of the nastiest cases out of the way.
<wgrant> But also denormalising SuggestivePOTemplate onto it, which is a bit more of a pain to maintain.
<wgrant> But that makes suggestions super-fast.
<wgrant> Because they can be done in a single index scan on TM, rather than joining over five.
<jtv> *whistle*
<jtv> Do we cluster TMs?
<danilos> I'd still be weary of widening TM considering the size of it... :)
<wgrant> Right, it's a tradeoff.
<wgrant> I vleive it's worth it here, but I need to retest once we see how the new DB servers work.
<wgrant> believe.
<jtv> Yeah.  My instincts keep going "no, don't widen it, narrow it!"
<jtv> Worst thing is when you cross some magical buffer size boundary and hit the badness again with what you thought was a really fast query.
<danilos> wgrant, for re-testing, try with cases like translations for "New", "File" and similar very common messages
<wgrant> danilos: Right, most of the timeouts that are left have strings like that.
<jtv> Yeah, I've often wanted to cache suggestions just for those...
<wgrant> And IIRC it doesn't even do the DISTINCT server-side.
<wgrant> So it'll load 2000 suggestions into Python, and only then realise that all 2000 have exactly the same msgstrs.
<jtv> I think we had a case where that turned out not to be a win _last time we checked_
<wgrant> Right.
<jtv> because it forces the choice of indexes.
<danilos> yeah, if it was like that, there probably was a reason :)
<jtv> And of course that tradeoff can shift at any time.
<wgrant> Which is why I'm deferring all this until we have SSDs and more RAM, which will change everything.
<danilos> the blocker for us was that all the +translate views would need serious refactoring to be able to cleanly and easily do all this
<jtv> Ah yes, that was another evil at the root of much of this: framework-imposed structure.
<danilos> and then you dive into .pts and get even more discouraged
<jtv> danilos: I've also been wanting to inject SMT-generated suggestions for selected languages... we have the perfect corpus for training an SMT engine.
<danilos> jtv, oh yes, lack of ideas and things we'd like to see was never the problem :)
<wgrant> Heh
<jtv> Nope.  That was never it.
<wgrant> The suggestions are already somewhat separated from the structure of the view.
<wgrant> But I'm going to have to rip them all the way out.
<danilos> wgrant, yeah, they should be done for the entire batch (just like the actual translations should be, but never were)
<wgrant> And then throw in a second batch of preloading, and that should hopefully be that.
<wgrant> The translations are now!
<danilos> wgrant, ah, cool :)
<wgrant> That's one of the things I fixed recently.
<wgrant> Bulk loading about 10 types of objects.
<jtv> Rob's approach of phasing the preloads really helped.
<jtv> We used to do it all in thousands of queries, then wrap it all into one big one.
<jtv> Thing-I-would-have-liked-to-do #428: take the header field out of POTemplate/POFile so loading them in UI code doesn't waste so much python time.
<jtv> (And also, so the tables would be more compact)
<wgrant> I did that with some big filds on SourcePackageRelease. Turned them into a property that lazily loads them for the like one place that needs them.
<jtv> I really wanted the headers out of the tables completely.  IIRC almost everything else was fixed-width and narrow.
<wgrant> Those should all be TOASTed, I believe, but yeah.
<wgrant> It's not very nice.
<jtv> I never really looked into TOAST apart from saying hey, maybe large objects aren't needed all that often.  Does it keep the strings separately?
<wgrant> Right, it keeps large things compressed in a separate table.
<jtv> Ah OK
<wgrant> Which totally sucks if you need to read them often, as it's an extra seek.
<wgrant> But for these big string fields that's rarely a problem.
<jtv> Of course if you have a lot of repetition it's probably great...
<jtv> IIRC we only needed those headers for import/export, and it always grated me to have them implicitly handled all over the place.
<jtv> Are you going to get rid of SuggestivePOTemplate at some point?
<jtv> (Not saying I have a problem with the table, just curious)
<wgrant> It needs to be flattened into the suggestion table.
<wgrant> Which may end up being TM for cache reasons.
<danilos> I don't even remember the SuggestivePOTemplate :)
<wgrant> SuggestivePOTemplate just has a single column.
<wgrant> It contains POTemplate IDs that are valid suggestion candidates, which I think is just any template in a project that officially uses rosetta.
<jtv> danilos: it was just a way to eliminate some repetition from the suggestions query... "all templates that are  suitable for taking suggestions from."
<danilos> oh, ok, I guess it came "after my time" :)
<jtv> No referential integrity, and the whole thing just gets rewritten periodically, instead of "managed."
<jtv> Yeah, that was something I did in my last days on Rosetta.
<jtv> I just loved being able to use the database relationally for a change.  :)
<danilos> heh, yeah, most of our optimizations involved denormalizing further ;)
<wgrant> So to look up suggestions I have to wander through TTI to POTMsgSet to TranslationMessage back through POTMsgSet then TTI then POTemplate then SuggestivePOTemplate.
<wgrant> But SuggestivePOTemplate means you don't have to further walk through ProductSeries and Product as well.
<danilos> wgrant, you could just construct a helper template linking matching potmsgsets or TTIs
<jtv> It was just a very low-effort way to eliminate a few seconds of query time from the page as a whole.
<danilos> s/helper template/helper table/
<danilos> it would probably end up being big, though
<wgrant> Denormalisation is critical to performance on these large tables.
<wgrant> see eg. BugTaskFlat.
<wgrant> It just needs a lot of testing to work out what's worth it.
<danilos> yeah, we moved from joins over 3 tables >50M to a single ~60M row TM table at one point, then with sharing we reduced TM from 130M to 70M rows, etc.
<wgrant> And TM is close enough to a suggestion table that I suspect adding a few extra bytes is going to have less of a negative impact than adding a whole new table to the hot set.
<danilos> yeah, the only way to do it is to try it out and profile
<danilos> though, the biggest benefit of sharing was that TM does not grow another 30M with every ubuntu release :)
<danilos> though I wouldn't be surprised if it hit >100M again
<danilos> anyway, back to sprinting :)
<wgrant> danilos, jtv: Thanks for your help.
 * jtv points at danilos, who did all the helping
<danilos> wgrant, yw
<danilos> jtv, ha
<wgrant> I'm slowly getting the hang of translations.
<danilos> wgrant, so am I :)
<jtv> Beginning of the end.  Any grey hairs yet?
<jtv> Oh, the irony ^
<danilos> good timing for henninge :)
<danilos> heh, same thinking
<wgrant> Heh.
<wgrant> People say Soyuz is bad, but I'm pretty sure Translations is still more of an unclean mess :P
<danilos> wgrant, well, when we did the translation jobs from soyuz, soyuz was messed up :) but I guess it's mostly about where are you coming from, so they are probably both equally bad
<jtv> I think it corresponds roughly to the age of (most of) the codebase.
<jtv> The closer to the core of Launchpad's job, the older and darker and more convoluted...
<wgrant> heh, indeed
<wgrant> all the build job stuff has been rewritten since then, fortunately
<jtv> Phew.  That was just sheer overengineering Hell.
<cprov> uhm, is that a quiz "which LP component sucks more in your opinion ?" we will have to start talking about codehosting and it's bloated revision table or the lazr.restful and its funny peculiarities. I guess *all* code is broken until *you* fixed :-/
<wgrant> cprov: Heh.
<wgrant> Codehosting's pretty OK except for stuff like BranchRevision.
<wgrant> And we don't talk about lazr.restful.
<cprov> wgrant: right, I can do that :-)
<jelmer> :)
<jelmer> what about git support ? (-:
<wgrant> Getting there, but I've had other priorities lately.
<jtv> So... we still don't compress BranchRevision then?
#launchpad-dev 2014-08-22
<Pali> hello, I have problem with importing git repo to launchpad via import service
<Pali> launchpad is reporting some weird error
<Pali> here is that repo: https://code.launchpad.net/~pali/ocl-icd/trunk
<Pali> git clone of original git repository working fine, so there is no problem with it
<Pali> launchpad show in log: bzrlib.errors.TransportNotPossible: Transport operation not possible: Transport  has not implemented list_dir (but must claim to be listable to trigger this error).
<jelmer> Pali: I don't think the bzr-git used by launchpad supports "dumb" git repositories
<Pali> jelmer: bzr branch <that git repo> working fine on my precise box
<Pali> directly bzr can clone full that git branch
<jelmer> Pali: yes, launchpad is not running the same version of bzr-git as your precise machiine though
<Pali> ah, so launchpad has some older version and older version of bzr-git did not supported git reposiories via http?
<Pali> I have 0.6.8-1
<wgrant> The particular way that Launchpad uses bzr-git does not currently work well with dumb HTTP repositories.
<wgrant> Smart HTTP repositories work fine.
<wgrant> I haven't seen a dumb one in the wild for a long time..
<Pali> so there is no way to import dump git repos over http to launchpad?
<Pali> only smart protocol via ssh or git is supported?
<jelmer> Pali: the smart protocol works over http too
<Pali> how can I check if server supports smart protocol or not (via http)?
#launchpad-dev 2014-08-24
<beauman> hello! I get "Version older than that in the archive" from launch pad. Anybody who knows what I'm doing wrong?
<beauman> Here's a paste of the mail I received http://slexy.org/view/s26LOvWBZT
#launchpad-dev 2015-08-19
<cjwatson> wgrant: the setup_requires thing you mention in https://code.launchpad.net/~stub/launchpad/trivial/+merge/245822 - is that that zc.buildout just doesn't support it?
<cjwatson> I've been experimenting with some upgrades lately, and seem to be going round in circles.  ZTK 2.0a1 plus latest zc.buildout has trouble because site-packages isolation has gone away.  Twisted >= 14.0.0 has trouble because it ideally wants new pyOpenSSL and that conflicts with a system package, but even if I ignore that, it hits https://github.com/testing-cabal/testtools/pull/149.  Even once that or similar is merged, upgrading to ...
<cjwatson> ... current testtools requires new pbr, which requires the swiftclient upgrade, and so we're back to buildout ...
<cjwatson> And if we're ever to fix Twisted-based SSH servers to support OpenSSH 7.0 default config, we're going to have to upgrade Twisted at some point
<cjwatson> Maybe we have to bite the bullet and convert to virtualenv and pip, perhaps with multiple virtualenvs so that we can have some of them configured with system site-packages which we seem to need
<lifeless> what site packages do you need ?
<wgrant> lifeless: python-debian, python-apt, IIRC
<wgrant> cjwatson: zc.buildout can't support it.
<wgrant> I believe I have a workaround for pbr, but I would have to look up my notes.
<wgrant> But basically setup_requires in its current implementation is the worst idea ever, unfortunately.
<StevenK> Worse than Zope 3?
<wgrant> Substantially.
<wgrant> Zope 3 is actually possible to use.
<lifeless> wgrant: whats the pbr problem ?
<wgrant> lifeless: setuptools has a PyPI fetish
<wgrant> "oh there's a setup_requires that isn't installed when you import setup.py? i guess i'll just go and download it from PyPI and install it for you that sounds like a good idea doesn't it"
<wgrant> If you can't convince buildout to install pbr first, setuptools will try to install pbr itself.
<wgrant> Firewalls (and good security practice) disagree with that.
<lifeless> you could write a recipe
<lifeless> like the one in the mock bug I was whinging about earlier
<cjwatson> wgrant: https://pip.pypa.io/en/latest/reference/pip_install.html#controlling-setup-requires might be helpful, perhaps?
<wgrant> cjwatson: Yeah, .pydistutils.cfg works
<wgrant> It is rather unfortunate, however.
<wgrant> cjwatson: If we were using pip, though, we could just convince it to install pbr beforehand.
<wgrant> We don't have that option with setuptools, unless we like add a special eggs-setup config key to the recipes we use.
<wgrant> s/setuptools/buildout/
<cjwatson> We'd probably want .pydistutils.cfg anyway for robustness, but switching to pip is feeling increasingly like a good idea.
<cjwatson> Not a trivial amount of work though.
<wgrant> It's easier if we can kill python-apt entirely :P
<cjwatson> Are you sure that's the only one?
<cjwatson> Also python-debian comes from eggs, not a system package
<wgrant> It's by no means the only one.
<wgrant> But it's the only really weird one I know of.
<wgrant> Well, other than tickcount.
<cjwatson> It's kind of a zero or any thing.
<lifeless> wgrant: or add a recipe
<wgrant> It is.
<wgrant> But python-apt is the only really weird thing.
<wgrant> lifeless: Indeed, it's looking tempting to use a custom buildout or z3c.recipe.scripts in the short term.
<cjwatson> Not z3c.recipe.scripts please, that doesn't work with buildout 2.
<cjwatson> At least we need a way to migrate to something more like zc.recipe.egg
<wgrant> I think we may only need that for the weird stuff we do with site-packages, but I forget.
<wgrant> It's been a while since I've looked at buildout in depth.
<cjwatson> Yes, I believe z3c.recipe.scripts is just for site-packages mangling
<wgrant> Does anything stop us from using virtualenv+pip once we no longer need site-packages mangling?
<lifeless> https://github.com/testing-cabal/mock/issues/310 may provide some inspiration for you
<wgrant> We use a consistent versions.cfg, so the isolation between txlongpoll etc. and LP is not critical.
<cjwatson> Does anything stop us from using virtualenv+pip even while we do still need site-packages mangling?  We could use multiple virtualenvs.
<cjwatson> One with --system-site-packages and one without.
<wgrant> But we can't install the new Twisted in a system-site-packages virtualenv, can we?
<wgrant> So there's not much point, other than as an hour-long migration strategy.
<wgrant> I don't have an issue with it, I just don't see how it solves the problem.
<cjwatson> We ... can't?  http://paste.ubuntu.com/12123638/
<wgrant> cjwatson: What was the pyOpenSSL issue?
<wgrant> "Twisted >= 14.0.0 has trouble because it ideally wants new pyOpenSSL and that conflicts with a system package"
<cjwatson> lifeless: I can see how that would be helpful, though the fact that it would have to be based on z3c.recipe.scripts for buildout 1 and zc.recipe.egg for buildout 2 makes migration rather entertaining
<cjwatson> wgrant: Stuff like http://paste.ubuntu.com/12123660/ which turns out to be because python-openssl 0.12-1ubuntu2.1 is installed
<cjwatson> And indeed is a dep of launchpad-dependencies
<cjwatson> The scripts stanza in buildout.cfg uses system site-packages.
<wgrant> Right.
<wgrant> So that's why we can't install the new Twisted in a system-site-packages virtualenv.
<wgrant> Or something.
<wgrant> Your motivation for moving away from system-site-packages was the pyOpenSSL issue.
<wgrant> I thought.
<cjwatson> It doesn't work in a buildout 2 environment with no virtualenv at all, but it works fine in a system-site-packages virtualenv.
<wgrant> Ahh, I see.
<cjwatson> Well, I need libffi-dev or something for it to actually install here, but at least pip seems to resolve things fine.
<lifeless> pyopenssl works fine in a pure virtualenv too
<lifeless> the pip cache can mitigate the compilation time
<cjwatson> It would probably work with buildout 2 and appropriate virtualenvs, but I'm not sure doing it that way round is easier than just migrating to pip first
<wgrant> Yep, that might be reasonable.
<cjwatson> I mean, that seems like strictly greater work.
<cjwatson> At least if we plan to use pip eventually.
<wgrant> I was just confused as to why you provided the site-packages stuff as a motivation for not moving to zc.buildout 2.0, and then proposed switching to a system-site-packages virtualenv in its place.
<cjwatson> Right, it's the lack of any virtualenv-like facility (even buildout 1's limited isolation support) in buildout 2 that causes the problem.
<cjwatson> buildout 2 says to use virtualenv if you need that.
<wgrant> Well, it says to use virtualenv if you need isolation.
<wgrant> But you're suggesting using it even if we *don't* need isolation.
<wgrant> With evidence, which seems reasonable.
<cjwatson> Oh, right, yes.
<wgrant> It just seemed totally insane without that critical piece of rationale.
<cjwatson> Actually it must be a problem even in buildout 1, thinking about it.
<cjwatson> Because my attempt to upgrade twisted didn't include my attempt to upgrade buildout.
<cjwatson> I believe that we currently have pyOpenSSL in versions.cfg but do not actually rely on buildout to install it.
<cjwatson> The problem comes as soon as something depends on a newer version.  So we could alternatively backport a newer .deb, I suppose
<wgrant> Yeah, or we could just move to pip with system-site-packages since it seems to sidestep it.
<wgrant> exclude-site-packages is simply a sensible default; I doubt txlongpoll/txpkgupload actually require it.
<wgrant> So we can probably get away with one.
<cjwatson> Fair point
<cjwatson> So the next worry is how to cope with all the magic on praseodymium
<cjwatson> I wonder if I have a copy of the relevant bits anywhere
<wgrant> Most of that magic is actually on carob
<wgrant> Recall that carob builds the tree, including all the eggs, then runs "make clean_buildout"
<wgrant> I'm not sure carob even builds the tree itself, since we used to have i386 machines.
<wgrant> Er.
<wgrant> Not sure *praseodymium* even builds the tree
<wgrant> IIRC everything uses make targets, except for the weird config-manager bits.
<wgrant> But they don't directly affect this.
<cjwatson> carob does a "make build_eggs"; what deals with syncing the eggs directory around?
<wgrant> The eggs directory is a subdirectory of the tree.
<cjwatson> Since that would presumably need to do the equivalent for a pip cache
<wgrant> So it just gets synced along with it.
<wgrant> (this is why make sync-stable sometimes fails hilariously; the tree build on carob is by no means atomic)
<cjwatson> Oh, right, it's only a symlink in development setups
<wgrant> Oh
<wgrant> I forgot rf-setup did it that way.
<wgrant> I don't.
<cjwatson> And AIUI our deployment-manager configs run "make compile" or equivalent on each target host, so in the new world order that would install stuff from the pip cache into an appropriate virtualenv.  And we would need something site.py-like to cause our scripts to stick themselves into the right virtualenv.
<lifeless> I'd seriously consider building the virtualenv to go and then syncing it out rather than building on each host
<cjwatson> The make targets I see that would now have silly names and need to have compatibility preserved at least for a transition period are build_eggs and clean_buildout
<cjwatson> lifeless: Right, make compile could do nothing if it was there
<wgrant> lifeless: We could do that now, since the last i386 machines are dead
<wgrant> But that only happened a year ago :/
<cjwatson> Would it cause any problem in the case of heterogeneous Ubuntu releases?
<cjwatson> Or Python versions?
<wgrant> Yeah
<cjwatson> (Sure, everything's 2.7 now, but I don't want to put further roadblocks in the path of 3.x)
<wgrant> I guess our eggs dir is sort of like a wheel cache.
<wgrant> But I'm not sure wheels can be deployed for everything yet, can they?
<lifeless> so
<lifeless> wheels aren't perfect
<lifeless> but the cache and shipping it around is doable
<lifeless> however my point is more about deploy reliability
<lifeless> you're deploying to enough machines
<cjwatson> I would be very happy to reduce the time taken by make compile during deployments, if nothing else.  But I don't want to leave landmines in the process.
<lifeless> that its worth the complexity of a build+distribute mechanism rather than distributed builds
<wgrant> make compile is mostly slow because half our machines are piles of crap.
<wgrant> make compile on a fast machine is pretty quick.
<lifeless> as far as moving to new pythons goes
<cjwatson> I'm not at all arguing against build+distribute, just trying to make sure I understand the issues.
<lifeless> virtualenvs are not particularly portable
<lifeless> even minor cpython builds can break them
<cjwatson> Not all our deployment targets have the same paths, either.
<lifeless> so the requirement to do build+distribute is that for each target machine you have the same python locally
<cjwatson> And the virtualenv docs caution against expecting path identity
<lifeless> and yeah, their paths are embedded in the virtualenv
<lifeless> but a container can address both things easily
<cjwatson> This is really sounding like a later step that we should make sure we don't design ourselves out of, rather than something to do in the first run; where I came in was trying to cut Gordian knots
<lifeless> sure
<cjwatson> I mean, not dodging the issue or anything, just trying to avoid having to change All The Things at once
<lifeless> I get it
<lifeless> I'm just surfacing options
<cjwatson> Yeah
<lifeless> running pip on a prod server with --no-index -f <path> should be reliable as long as you've neutered easy-install via .pydistutils.cfg
<wgrant> Yeah, I was hoping to avoid that.
<lifeless> no, you must neuter it
<lifeless> otherwise you'll be auditing forever
<wgrant> There was discussion a while ago about making pip pass options down so easy_install would be neatured
<wgrant> neutered
<wgrant> but I haven't seen whether that actually got done
<lifeless> there are no such options
<lifeless> and pip can't do it until we have declarative metadata for setup_requires used by *every package including old releases*
<lifeless> e.g. never
<lifeless> there is a route that might work
<lifeless> which is to make it error out with the missing dep
<wgrant> Right, easy_install had, or was going to grow, options for allow-hosts and find-links
<lifeless> and have pip parse the output
<wgrant> Which would be respected.
<cjwatson> We can put the pydistutils.cfg in the virtualenv, I think?
<cjwatson> Which seems a little easier to arrange than either system-wide or user-wide configuration
<wgrant> Oh, can we?
<lifeless> you can always export a custom HOME
<cjwatson> Or even setup.cfg, according to the docs
<cjwatson> https://docs.python.org/2/install/index.html#distutils-configuration-files
<wgrant> That seems too easy.
<cjwatson> Or is that setup.cfg of the package being processed?
<wgrant> Huh
<lifeless> setup.cfg isn't accessible to you
<lifeless> because yes
<cjwatson> Right, bah.
<wgrant> lib/python2.7/distutils/distutils.cfg might work
<wgrant> Maybe
<wgrant> But I doubt it.
<wgrant> Again, too easy.
<cjwatson> virtualenv writes out a template file that claims it works.
<cjwatson> http://paste.ubuntu.com/12123833/
<wgrant> !
<cjwatson> Also /path/to/env/.pydistutils.cfg, according to the changelog for virtualenv 1.3.3
<cjwatson> Allegedly, though I'm not seeing that in the code.
<cjwatson> Oh, yes I do, in the source.  Couldn't find it in the installed virtualenv.py because it's helpfully zlib-compressed and base64-encoded.
<wgrant> I don't know why people also don't xor things with "Beware of the Leopard" while they're at it.
<cjwatson> So env/.pydistutils.cfg seems by far the easiest
<wgrant> if it works, indeed that is amazing.
<cjwatson> wgrant: http://paste.ubuntu.com/12124302/  actually a success for .pydistutils.cfg!
<cjwatson> (that "succeeds" if I remove .pydistutils.cfg, so correctly blocked.)
<wgrant> Aha
<wgrant> Excellent.
<wgrant> I knew ~/.pydistutils.cfg worked, but if the virtualenv one works too then all the better.
<cjwatson> Right, this is the virtualenv one.
<cjwatson> OK, that can actually install everything - just needed a couple of wheel conversions and suchlike.  The next steps are figuring out how to handle sitecustomize and buildout-templates.
<wgrant> cjwatson: Does "everything" include our dpkg deps?
<cjwatson> wgrant: They're accessible from virtualenv/bin/python, if that's what you mean
<wgrant> Er of course
<wgrant> Sorry, neutron ate my brain.
<cjwatson> I'm not sure I'm seeing this alleged wheel caching working.  Maybe I need to install wheel first ...
<wgrant> What're you using wheels for here?
<cjwatson> Nothing yet, but installing the world from sdist doesn't appear to be very quick.
<wgrant> Quite.
<cjwatson> (Well, except for two packages that were previously installed from eggs.)
<cjwatson> I grabbed pytz's wheel from PyPI, and ran 'wheel convert' for meliae.
<wgrant> I haven't actually investigated wheels in depth.
<wgrant> I didn't think they were totally a thing yet, but it seems they are.
<cjwatson> http://paste.ubuntu.com/12124493/ is my output so far.
<wgrant> Very slow, but functionality is half the battle.
<cjwatson> Yeah.  Will shelve for a little while, don't want to accidentally spend the entire day on it
<blr_> morning cjwatson, how was your trip?
<cjwatson> blr_: Legoland++
<blr_> cjwatson: I've heard it is quite impressive :)
<lifeless> wgrant: wheels are very much a thing :)
<lifeless> cjwatson: wgrant: I presume you both know about 'pip wheel' ?
<cjwatson> Yes
<lifeless> oh right, wheel convert is a totally different thing
<cjwatson> Yeah, things I did not want to spend any time on whatsoever included figuring out how to make a binary distribution of meliae and have it match the existing egg
#launchpad-dev 2015-08-20
<maozhou> When I run "cronscripts/process-job-source.py IInitializeDistroSeriesJobSource",  it output deug message "Running <InitializeDistroSeriesJob for distribution: kylin, distroseries: ginkgo, parent[overlay?/pockets/components]: utopic[False/Release/main], architectures: (u'amd64', u'arm64', u'armhf', u'hppa', u'i386'), archindep_archtag: None, packagesets: None, rebuild: True> (ID 2044) in status Waiting".  How to debug it ?
<wgrant> maozhou: Debug what?
<maozhou> wgrant: How to make it  initialize the series ?
<wgrant> maozhou: You've said that it said it initialised the series, but nothing further.
<wgrant> There's no problem.
<maozhou> wgrant: But , it's this status for hours
<wgrant> Ah, that is an important piece of information.
<wgrant> Is it doing anything?
<wgrant> if your machine is slow that may not be unreasonable.
<maozhou> No, my machine is not slow.And  there is no building job now.
<maozhou> The build queue is empty
<wgrant> Series initialisation does not create builds.
<wgrant> Is the script still running?
<maozhou> The script maintain this status
<wgrant> I don't understand what you mean.
<maozhou> http://i1.tietuku.com/74d40e72869ead18.png
<wgrant> So it is still running, and has been running for several hours?
<wgrant> Is it issuing database queries?
<maozhou> Yes, it's has ben running for several hours.
<maozhou> I search  the ID  which belong to the package ,the package has been builded successful.
<wgrant> The package?
<wgrant> IDS does not touch builds.
<maozhou> The ID of 2044 , is it the package ID ?
<wgrant> No, that's a job ID.
<wgrant> IDS doesn't touch a single package.
<wgrant> It touches an entire series.
<wgrant> You should find out from postgres whether it is still actively issuing queries.
<maozhou> which is postgres?
<wgrant> PostgreSQL, the database that Launchpad uses.
<maozhou> Which table can I find the job ID 2044?
<wgrant> Either Job or DistributionJob, I forget.
<maozhou> Need I modify the database manual ?
<wgrant> No
<wgrant> You need to work out whether the job is actually hung.
<wgrant> strace it, look in pg_stat_activity to see if it's running DB queries, etc.
<maozhou> ok, thank you
<maozhou> wgrant:  In  table pg_stat_activity ,  I find the job is actually hung. How to deal with it?
<maozhou> http://i1.tietuku.com/7bcb98edbf3a5831.png
<wgrant> The transaction start time isn't very interesting, but the query start time is.
<maozhou> I don't understand.
<wgrant> maozhou: IDS can use long transactions, that's fine.
<wgrant> The question is whether a single query has hung, and if so what that is.
<wgrant> Those are other columns in pg_stat_activity that you haven't disclosed.
<maozhou> I only select "datid,datname,pid,usename,Xact_start" from the table "pg_stat_activity"
<wgrant> There should also be the query start time and query text.
<wgrant> Those are interesting.
<cjwatson> just select *, it's not that wide
<cjwatson> better than messing about
<cjwatson> and use a text pastebin rather than pointlessly turning text into an image :-)
<maozhou> http://i3.tietuku.com/e31c6b656b8c47ce.png
<maozhou> The output message is like this.
<maozhou> the query is "idle in transaction | SELECT BinaryPackageBuild.arch_indep, BinaryPackageBuild.archive, BinaryPackageBuild.build_farm_job, BinaryPackageBuild.builder, BinaryPackageBuild.date_created, BinaryPackageBuild.date_finished, BinaryPackageBuild.date_first_dispatched, BinaryPackageBuild.date_started, BinaryPackageBuild.dependencies, BinaryPackageBuild.distribution, BinaryPackageBuild.distro_arch_series, BinaryPackageBuild.distro_series, Binar
<maozhou> yPackageBuild.failure_count, BinaryPackageBuild.id, BinaryPackageBuild.is_distro_archive, BinaryPackageBuild.log, BinaryPackageBuild.pocket, BinaryPackageBuild.processor, BinaryPackageBuild.source_package_name, BinaryPackageBuild.source_package_release, BinaryPackageBuild.status, BinaryPackageBuild.upload_log, BinaryPackageBuild.virtualized FROM BinaryPackageBuild WHERE BinaryPackageBuild.archive = 18 AND BinaryPackageBuild.source_package_release
<maozhou> = 6079 AND BinaryPackageBuild.distro_arch_series = 71 ORDER BY BinaryPackageBuild.id"
<cjwatson> That would appear to be making progress.
<maozhou> The query start time is "2015-08-20 15:39:18.258064+08"
<cjwatson> query_start two minutes before you gave the paste URL here, if I have your timezone correct
<cjwatson> No, it's not
<cjwatson> That's the xact_start
<cjwatson> query_start is 2015-08-20 17:22:12.816189+08 (which if you'd used a text pastebin I would have been able to copy and paste rather than having to retype it)
<maozhou> Oh, yes , query start time is  "2015-08-20 17:22:12.816189+08"
<maozhou> Why It's idle in transaction?
<wgrant> Because it is thinking, most likely.
<wgrant> How big is the series you're copying from?
<cjwatson> Or waiting for a lock
<wgrant> No, idle means no query is in progress.
<wgrant> (and waiting is false)
<cjwatson> oh, true
<cjwatson> (I blame openssh having eaten my brain)
<wgrant> Heh
<wgrant> What are you doing to it?
<wgrant> Or is it conch?
<maozhou> This series is derived from Utopic
<wgrant> Your utopic.
<wgrant> How big is your utopic?
<maozhou> Will it spend long time for that?
<maozhou> 114G
<cjwatson> wgrant: 6.9p1 packaging, followed by fixing conch, followed by 7.0p1 packaging
<wgrant> Aha
<cjwatson> or hopefully fixing conch, anyway
<cjwatson> which will then require upgrading twisted, hence my arguing with pip recently
<cjwatson> btw, do you already have a yak-shaving machine factory or do I need to build one?
<wgrant> All the yak-shaving machine capacity for the next year is alread spoken for, I'm afraid.
<cjwatson> damn.
<maozhou> Oh, it's finished ,thank you.
<cjwatson> wgrant: tempted to make an LP-specific fork with https://github.com/msabramo/setuptools-git/pull/10
<cjwatson> (OK, won't help once we move to git, but would already have saved me the time I spent writing it)
<cjwatson> A pip install of LP's dependencies is down to 36 seconds with that plus a wheel cache, which is still a lot slower than buildout's ~5 seconds but maybe now not prohibitively so
#launchpad-dev 2015-08-21
<wgrant> cjwatson: That seems too easy.
<wgrant> Where does the other 30 seconds go, though?
<Spads> Mars.
<Spads> http://www.thirtysecondstomars.com/ <-- Proof.
<wgrant> Heh
<cjwatson> wgrant: it spends a fair bit of time in _find_all_versions for each requirement (i.e. the "Collecting" steps)
<cjwatson> I would like a way to say "don't use setuptools.file_finders no matter what" in LP's setup.py
<cjwatson> because we care not about the sdist and having to patch setuptools-git is a ridiculous distraction
<cjwatson> wgrant: But once the virtualenv is populated, it's 3.5 seconds to rerun, which I guess is actually more analogous to buildout's behaviour with a symlink to a populated eggs directory.
<cjwatson> Oh, indeed, without the eggs symlink, buildout takes 155 seconds vs. the current figure I have for a full virtualenv build with pip of 52 seconds (my previous figure was badly measured, I missed a bit at the start)
<cjwatson> So performance is not an issue any more and I just need to sort out the large pile of details
<cjwatson> The pip figure is actually cheating because I had cached wheels; without those it's 164 seconds.  But that's sufficiently close to the comparable buildout run that I don't care
<cjwatson> I found a reasonably horrible but just about tolerable way to cut setuptools-git out of the loop in our setup.py
<cjwatson> lifeless: How would I go about debugging 'pip install "zope.security[untrustedpython]"' not actually installing the untrustedpython extra in my in-progress pip conversion of LP?
<cjwatson> (this is, hope you understand, several layers deep in a rabbit hole, but it's where I've got to thus far ...)
<lifeless> pdb ?
<lifeless> try pip install -v ... first
<lifeless> if that doesn't enlighten
<lifeless> show me a pastebin
<cjwatson> http://paste.ubuntu.com/12144491/
<cjwatson> I was hoping for an answer other than pdb, but I guess I can give that a try ;-)
<cjwatson> should be installing RestrictedPython, but isn't; works fine if I explicitly request RestrictedPython
<cjwatson> zope.security's metadata.json looks right, contains {"requires": ["RestrictedPython"], "extra": "untrustedpython"}
<cjwatson> so if this isn't just something that plain doesn't work yet in pip, I can certainly attack with pdb, just wanted to check first since that's likely to take me a while
<cjwatson> I know you've been working on various corners of pip's requirement handling
<lifeless> I'm not at all sure that metadata.json is consuled
<lifeless> I'd need to check the embedded pkgresources - I think it may still be reading METADATA
<cjwatson> METADATA has
<cjwatson> Provides-Extra: untrustedpython
<cjwatson> Requires-Dist: RestrictedPython; extra == 'untrustedpython'
<lifeless> so it works for me :)
<lifeless> Successfully installed RestrictedPython-3.6.0 zope.component-4.2.2 zope.event-4.0.3 zope.i18nmessageid-4.0.3 zope.interface-4.1.2 zope.location-4.0.3 zope.proxy-4.1.6 zope.schema-4.4.2 zope.security-4.0.3 zope.untrustedpython-4.0.0
<lifeless> hmm, I wasn't using a constraints file
<lifeless> whats in your constraints file ?
<cjwatson> zope.security 4.x goes through a different chain, but it does seem to work with a fresh virtualenv, let's see
<cjwatson> http://paste.ubuntu.com/12144571/
<cjwatson> oh and also an initial run before that with http://paste.ubuntu.com/12144573/ as -r
<lifeless> cjwatson: are you capturing both stderr and stdout ?
<cjwatson> yes
<lifeless> hmm
<lifeless> I'm not seeing 'collecting'
<cjwatson> that was in an env that already had lp installed
<lifeless> -at all-
<lifeless> yeah, its the constraints file
<lifeless> workaround - put the [] in the constraints file
<lifeless> I'll file a bug now
<lifeless> [I wrote the constraints support for pip :), so was a very good choice to ask]
<cjwatson> aha, the constraints implies a null set of extras?
<lifeless> no
<lifeless> its worse
<cjwatson> brilliant, thanks - I thought you might be
<lifeless> pip doesn't merge together extras references from different places in the dependency graph
<lifeless> which is a subset of the 'does not do resolving at all'
<lifeless> problem
<cjwatson> I'm using 7.1.0 FWIW but 7.1.1's changelog doesn't look different here
<cjwatson> and confirmed that adding the [] in the constraints file fixes it, thanks
<lifeless> https://github.com/pypa/pip/issues/3046
<lifeless> yw
<cjwatson> now I wonder how to grep for what extras *should* be installed - I guess just compare with the buildout-installed package list
<lifeless> well, they'll be getting in the dependency list somehow
<lifeless> so I think a two-phase thing
<lifeless> phase 1, any extras you define
<lifeless> phase 2, interrogate the dist-requires of all the things you depend on, transitively
<lifeless> you could automate phase2 by runnign 'pip install' of each thing you directly dep on separately, and looking in the output:
<lifeless> perhaps
 * lifeless shrugs ;)
<cjwatson> I just did the stupid thing and did bin/buildout -vc buildout.cfg, mangled output into roughly compatible form, compared with pip list
<cjwatson> some noise from buildout 1's semi-isolation vs. virtualenv --system-site-packages just allowing everything
<lifeless> auditing the final output is probably sufficient
<lifeless> you might end up there coincidentally and be missing a extra for the future
<cjwatson> yeah, I really only have to do this once
<cjwatson> true
<lifeless> but, we're going to get that bug fixed
<lifeless> so its a time limited window
<cjwatson> once we're on virtualenv/pip, it's a lot easier to upgrade
#launchpad-dev 2015-08-23
<blr> morning
<wgrant> Morning blr.
<blr> hey wgrant, how was your break?
<wgrant> Pretty good, pretty good.
<wgrant> You are well again?
<blr> wgrant: not entirely, but well enough to somewhat useful.
<blr> ^be
<blr> wgrant: did you get out of the city?
<wgrant> blr: Ah, unfortunate, but good that you are on the mend.
<wgrant> I did not.
<wgrant> But I was detached from IRC for a continuous 40 hours!
<blr> wgrant: most impressive :)
<blr> wgrant: do you have any thoughts on following the same pattern we used for the turnip client in LP, with the build manager?
<blr> wgrant: also out of interest, do you run your local buildd in a separate lxc container?
<cjwatson> AIUI he uses a VM to avoid having to run an unconfined LXC container
<blr> cjwatson: and yourself?
<cjwatson> I use a container because I'm lazy, but you do have to make it unconfined.
<cjwatson> (lxc.aa_profile = unconfined)
<cjwatson> Which sucks
<cjwatson> In theory something like lxc-container-default-with-mounting should work but last time I tried I wasn't able to get it to work and gave up on that
<blr> cjwatson: was thinking I should update the advice on the wiki to use a chroot
<cjwatson> A VM is probably better if you're starting from scratch without baggage of existing setups
<cjwatson> I wouldn't recommend a chroot - you'll get port clashes if you try to run more than one out of the box, and while of course you can work around that it's annoying
<cjwatson> And it would be better to have it off on an isolated bit of network
<blr> cjwatson: sorry, I meant, the wiki currently recommends a chroot, which I think I should update.
<cjwatson> Oh, right, yeah, https://dev.launchpad.net/BuildFarm/TryOutBuildSlave is fairly dire
<cjwatson> The pbuilder stuff should die, in favour of either mk-sbuild or (probably preferably) just downloading one from production the way that https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally recommends
<cjwatson> And its existing chroot upload documentation is broken
<cjwatson> I think it would be better to merge the one useful bit of TryOutBuildSlave (the hints on poking it with xmlrpclib by hand) into HowToUseSoyuzLocally, and make the latter recommend a VM
<blr> cjwatson: ok, that sounds sensible
<cjwatson> (well, possibly the stuff about translation templates is slightly useful as well)
<cjwatson> Anyway, silly to have two documents about the same thing.
#launchpad-dev 2016-08-26
<bigjools> wgrant: thanks :)
<wgrant> bigjools: np!
<tsimonq2> if I really took the time to fix this and present an MP against Launchpad, would it be accepted? My PPA says You can update your system with unsupported packages from this untrusted PPA by adding ppa:tsimonq2/test to your system's Software Sources. (Read about installing) sudo add-apt-repository ppa:tsimonq2/test sudo apt-get update"
<tsimonq2> it could be fixed to sudo apt update
<tsimonq2> but the thing is, in precise, that's not supported yet
<tsimonq2> you have to use apt-get
<tsimonq2> so I assume that sort of change wouldn't be appropriate yet?
<cjwatson> tsimonq2: indeed; and it wouldn't be a "fix", it's just a bit cosmetically better
<tsimonq2> or maybe it could be corrected to that but show something like, "On systems running Ubuntu 12.04, run this instead:" ?
<cjwatson> tsimonq2: no point in causing compatibility confusion for the sake of somewhat nicer progress output
<tsimonq2> I see cjwatson
<cjwatson> no, sudo apt-get update is still perfectly valid on more recent systems too
<cjwatson> it's not wrong, it's just not the newest hotness
<cjwatson> but that's fine
<cjwatson> let's not complicate the UI further
<cjwatson> I mean, yes, I use sudo apt update myself, but changing LP can wait a bit more :)
<tsimonq2> cjwatson: maybe I could wait until precise is EOL? ;)
<tsimonq2> I mean, totally the choice of the Launchpad team
<cjwatson> we would probably consider it after that point, yes
<tsimonq2> ok :)
<cjwatson> maybe not like the next day, there'll still be a whole bunch of precise users around and we don't delete precise PPAs or anything
<cjwatson> but with some kind of respectable interval :)
<tsimonq2> well which is why I suggested adding that switch, to make that show up only if there's precise packages (if even possible) and then just reverting it when the time comes :)
<tsimonq2> but I guess I can live with it until then
<tsimonq2> thanks cjwatson
#launchpad-dev 2017-08-23
<RemonShai> hey guys... how to set SSH on launchpad ?
<cjwatson> RemonShai: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Registering_the_key_with_Launchpad
<RemonShai> thanks cjwatson :)
#launchpad-dev 2019-08-19
<SpecialK|Canon> where can I see logs for CI runs for MPs to launchpad itself?
<tomwardill> http://lpbuildbot.canonical.com/
<SpecialK|Canon> ah, thank you!
<SpecialK|Canon> and thanks to Wikipedia for helping me learn to pronounce sluagh
<SpecialK|Canon> oh hey it looks like modern buildbot has dropped the "slave" terminology, yay
<tomwardill> yeah, that was underway a few years back when I was working with buildbot
 * tomwardill still really likes buildbot
<SpecialK|Canon> I confess I thought buildbot was no longer maintained, and was pleasantly surprised
<SpecialK|Canon> I gather there was talk of possibly moving to Jenkins - I'm guessing that was to leverage existing infra rather than any dissatisfaction with buildbot?
<tomwardill> I'd assume so, but I don't know for sure
<SpecialK|Canon> So I can totally get why, but I'm still mildly entertained by the existence of https://github.com/buildbot/buildbot/blob/master/.circleci/config.yml
<tomwardill> hah
<SpecialK|Canon> Hm, as far as I can tell, lpbb doesn't build MPs against LP - I'm guessing partly due to config and/or security model
<tomwardill> speaking beyond what I know for sure, but probably mostly due to legacy
<tomwardill> that and the test suite is > 4 hours
<SpecialK|Canon> ah
<SpecialK|Canon> so it's a combo of assess-by-eye, trust author to run tests themselves, handle issues retroactively, I guess
<tomwardill> it runs the tests during landing, and will reject the merge
<tomwardill> via the pqm bot
<SpecialK|Canon> ahh sorry right, because it's not an actual "merge", it's lp-land?
 * SpecialK|Canon was just reminded of https://dev.launchpad.net/LandingChanges
<SpecialK|Canon> tomwardill: do you run tests locally, use https://dev.launchpad.net/EC2Test, or something else altogether?
<tomwardill> SpecialK|Canon: I run them locally via `bin/test -vvct <test file>`
<tomwardill> I don't think EC2Test is a thing anymore
<tomwardill> I've never run the full suite
<SpecialK|Canon> tomwardill: bin/test not testr...? (cf. https://dev.launchpad.net/Testing)
<tomwardill> never used testr
<SpecialK|Canon> ah
<SpecialK|Canon> ok, thanks!
<tomwardill> oh hey, TIL LP_PERSISTENT_TEST_SERVICES
<tomwardill> I wondered if something like that might exist
#launchpad-dev 2019-08-20
<wgrant> LP_PERSISTENT_TEST_SERVICES doesn't work with parallel tests, but I think it still works in normal mode
<wgrant> Tests aren't run before merge any more because it was too much of a bottleneck, but buildbot now runs the test suite in parallel so it only takes about 40 minutes
<SpecialK|Canon> that wasn't quite the overnight test run I was hoping for heh https://pastebin.canonical.com/p/rmgpw3hkRZ/
<SpecialK|Canon> wgrant: neat, cheers
 * SpecialK|Canon goes digging
#launchpad-dev 2019-08-21
<mwhudson> wgrant: i'm trying to test some apport integration by reporting bugs against staging but it seems the bug data on staging is never processed?
<mwhudson> wgrant: e.g. https://bugs.staging.launchpad.net/subiquity/+filebug/9e6444e6-c3c3-11e9-9244-18a9056479cc?field.title=block+probing+failed+with+ZeroDivisionError has been refreshing every 10s for several minutes now
<mup> Bug #9: Rosetta's po parser is too strict <lp-translations> <Launchpad itself:Fix Released by carlos> <https://launchpad.net/bugs/9>
<mwhudson> is this expected or did i break it somehow?
<wgrant> mwhudson: Hm, the processing job runs minutely on staging
<wgrant> It's possible it's broken somehow
<mwhudson> wgrant: is that something you can determine or do i need a webop?
<wgrant> mwhudson: I'm having a look
<mwhudson> wgrant: tia
<wgrant> But logrotation is apparently misconfigured so the log is 3.8GB
<wgrant> will take a while to sync...
<mwhudson> oof
<wgrant> mwhudson: Well that's weird. It got a 503 while trying to talk to the librarian.
<wgrant> Have you tried more than once?
<wgrant> Some caches may have been cold or something
<mwhudson> wgrant: i've tried twice
<mwhudson> and uhh
<mwhudson> wgrant: so it might be worth trying a few times?
<wgrant> mwhudson: The answer to that on staging is always yes
<wgrant> It's still got the full terabyte database, but the hot set is rarely hot
 * mwhudson tries three more times
<mwhudson> wgrant: my other three reports don't seem to be being processed either :(
<wgrant> Hmm. Let's get IS to investigate after this network maintenance, then.
<mwhudson> ok
<mwhudson> well i need to go actually, so i'll try again tomorrow and then bug a sysadmin if it still doesn't work
<cjwatson> SpecialK|Canon: Moving to Jenkins is a possibility, but it'd require a fair bit of work to make sure we don't seriously regress test runtime (would probably need us to run on lots of parallel instances or something).  What I was actually planning to do when we finish the move to git was to use Jenkins to process approved merge requests but without running tests, so it would replace bzr lp-land ...
<cjwatson> ... rather than replacing buildbot.
<wgrant> I mean the current parallel buildbot slaves are on super beefy machines from 2011
<wgrant> Which means we could probably get reasonable performance from some moderately beefy VMs from 2019
<cjwatson> Right, I'm sure it can be done, but it probably wouldn't work well if done naively.
<cjwatson> Needs some attention rather than just whacking stuff into ols-jenkaas.
<wgrant> Yep
