#launchpad-dev 2009-11-30
<thumper> mwhudson: ping
<mwhudson> thumper: hi
<thumper> mwhudson: outlaws evaded
<thumper> (for now)
<mwhudson> thumper: :-)
<thumper> mwhudson: I've been thinking about the duplicate personal vote issue
<thumper> mwhudson: and I'm not sure we can guarantee that we won't screw up :(
<thumper> mwhudson: can I talk through it with you?
<thumper> OMG
<mwhudson> thumper: sure, skype away
<thumper> my headset isn't muted!
<thumper> someone fixed that annoying bug \o/
<mwhudson> :)
* spm changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<spm> thumper: woooo! official fix committed! (celebrations in losa land!)
<thumper> spm: works on edge, QAed even
<spm> scary
 * thumper EODs
<mwhudson> thumper: good idea
<spm> night NZ
<lifeless> thumper: argh
<lifeless> thumper: I want you back. https://code.edge.launchpad.net/bazaar/+activereviews is broken.
<lifeless> spm: ^
<spm> urgness
<lifeless> so is https://code.edge.launchpad.net/bzr/+activereviews
<spm> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1430EB306 ==> TypeError: can't compare datetime.datetime to NoneType
<spm> awesome. is busted on prod too.
<spm> something in the bzr et al data set I suspect. as it works for eg launchpad
<lifeless> I'll ring tim
<spm> +1
<lifeless> he's out for 15-20; hav left message
<spm> oki
<thumper> hmm
<thumper> that shouldn't be able to happen :-|
<thumper> something isn't being set right
<thumper> spm: skype?
<spm> thumper: not right now, no. sorry.
<spm> lp just shat itself
<thumper> ok
<thumper> I'll come back in 5 or 10 min?
<spm> 10-15 maybe; ta
<thumper> spm: now?
<spm> sure
<poolie> spm/thumper: all good now?
<spm> poolie: your issues with the reviews? yeah. the rest is still being painful.
<adeuring> good morning
<mrevell> Morning Launchpadders
<wgrant> gmb: Can I convince you to perform the import requested in https://answers.edge.launchpad.net/launchpad/+question/91604? Managers getting irritated with multiple bugtrackers, blah blah blah.
<gmb> wgrant: It's on my to-do list for today.
<gmb> Thanks for the reminder though.
<wgrant> gmb: Thanks.
<bigjools> wgrant: howdy
<wgrant> bigjools: Hi.
<bigjools> wgrant: was there a reason not to land the branch of yours I just approved?
<wgrant> bigjools: The test suite will fail when buildbot tries to run it.
<wgrant> bigjools: Because buildbot is using a dpkg that is too old.
<wgrant> It too needs the backpotr.
<bigjools> that was it
<bigjools> my sleep-deprived brain is not adjusted to GMT yet
<wgrant> Heh.
<bigjools> jet lag blows
<wgrant> Yes :(
<wgrant> NZ is convenient for avoiding that.
<bigjools> well I might disagree :)
<wgrant> Pfft.
<bigjools> wgrant: do you know if the backported dpkg made it to the LP-dev-deps PPA?
<wgrant> Hm.
<wgrant> LP is gone?
<wgrant> Ah, no, just caching because of that broken offline page.
<wgrant> Ah, so it *was* broken.
<wgrant> bigjools: It's not.
<bigjools> wgrant: ok do you know if it's in another PPA somewhere?
<mwhudson> bigjools: fwiw, i find europe <-> nz to be less bad for jetlag than europe <-> us or us <-> nz
<mwhudson> 12-13 hours seems to just reset my body clock, about 8 just messes it up
<bigjools> mwhudson: I find that once I get >5h difference it's all the same shite anyway
<wgrant> I had no problems when I went to UDS Jaunty, which was a little strange.
<wgrant> bigjools: It doesn't look like it's anywhere.
<wgrant> bigjools: I have the diff, so that could be easily fixed.
<bigjools> wgrant: if you put it in your own PPA I'll copy it over
<wgrant> bigjools: Probably best for somebody else to do it. My immediately available connection is only 64kbps.
<jml> good morning
<asabil> hi all
<jml> hi
<asabil> small question concerning launchpad
<asabil> it seems like for some reason no matter how I change the configs, it always look for the launchpad_dev table
<asabil> I hacked around it by editing lib/canonical/lp/__init__.py
<asabil>      dbname = match.group(1)
<asabil> +    dbname = "launchpad"
<asabil> is this a known issue ? or is it some misconfiguration ?
<deryck> Morning, all.
<asabil> morning
<wgrant> bigjools: So, any ideas on how to get the new dpkg-dev into the PPA and the images?
<bigjools> wgrant: as soon as I get a copy I can sort it out
<wgrant> bigjools: Great, thanks.
<bigjools> wgrant: if I can get a copy ....!
<wgrant> bigjools: I got hold of the diff from cjwatson a few days back, if that would help.
<bigjools> wgrant: yes it would
<wgrant> bigjools: http://paste.ubuntu.com/327212/
<bigjools> excellent, I'll get that sorted today
<bigjools> cheers
<wgrant> Great.
<wgrant> Do you know how lamont's progressing with the buildds?
<bigjools> I don't, I need to catch up with him
<wgrant> gmb: Thanks.
<gmb> wgrant: np
<jml> beuno, hi
<noodles775> Hi deryck, I was just doing some QA, and happened to use the text-area inline edit on staging... have you tried editing the description of a bug on staging today?
<noodles775> (or is what you see there - just a style issue - known? I couldn't find a bug for it).
<deryck> noodles775, you mean, how the icons slip when in edit mode?  It is known.  Haven't had a chance to look at it due to the holidays last week.
<deryck> noodles775, I'll look at it today, though.
<noodles775> deryck, ah, as long as it's a known issue. Thanks!
* salgado changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<beuno> jml, hi
<jml> beuno, I'd like to talk with you about icons and stuff
<jml> beuno, specifically, I was wondering if we could have a badge for "this bug has patches attached"
<beuno> jml, sure. You need to get in touch with Iain Farrel, get some graphic designer time for it
<jml> beuno, as UI reviewer, would you have any objections to badging bugs that have patches attached?
<beuno> jml, quite the opposite, I'd love to see it happen
<jml> beuno, cool.
<jml> beuno, maco almost but not quite volunteered to do it at UDS
<beuno> jml, another cheap thing to do in that regard, is split attachements from bugs on the bug page
<jml> beuno, *nod*
<jml> beuno, the other icon I'm thinking about is a "has recipe" icon.
<beuno> jml, on a branch?
<jml> beuno, yes, probably. maybe on a source package too.
<jml> beuno, in my head, all of this is under a very large umbrella with a very large question mark on it
<beuno> jml, that would be one approach. The other would be to have a PPA icon on a branch, and a branch icon on a PPA
<beuno> (less types of icons can only be good)
<jml> beuno, do we have a PPA icon?
<bigjools> yes we do!
<jml> may I see it?
<bigjools> check out +graphics
<jml> I knew you were going to say that :(
<bigjools> :)
<bigjools> https://edge.launchpad.net/@@/ppa-logo
<bigjools> howzat?
<jml> thanks.
<bigjools> s/logo/icon/ as appropriate
<jml> brb. changing proxy config.
<mars> sinzui, ping, do you know if Edwin will be in today?
<sinzui> mars: He will
<mars> sinzui, thanks
<mars> deryck, ping
<deryck> hi mars
<mars> good morning deryck
<mars> was just looking at bug 487975
<mup> Bug #487975: javascript error assigning a bugtask on staging <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/487975>
<mars> deryck, it seems to be blocked on bug 489342
<mup> Bug #489342: "'display_name' is undefined" JavaScript error on development <javascript> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/489342>
<mars> deryck, I'm going to ask Edwin about the display_name bug when he gets back online.  You probably want to fix the first bug, as that is the broken Assign Me link :(
<deryck> mars, tom's comment the first bug suggests you're fixing it.  is that comment wrong?
<mars> deryck, IIRC the fix is easy, just one line, but you can't test it because the display_name bug gets triggered first, before the fix has time to execute.
<deryck> mars, ok.  so what do you need from me? :)  to apply the one line fix? :)
<mars> deryck, I am working on the fix for it.  Sorry, I meant "You (we) will want to see that it is fixed"
<deryck> mars, ah, ok :)
<mars> the one-line fix is untested?
<deryck> mars, I follow now, sorry.  Yeah, I can follow up that it's correct when it's done.
<deryck> mars, and this one line fix is something different from bug 443217?
<mup> Bug #443217: Changing a bug's affected project or description doesn't ever finish <bug-page> <js> <ui> <lazr.restful:New for intellectronica> <Launchpad Bugs:Triaged by intellectronica> <https://launchpad.net/bugs/443217>
<mars> that's new
<deryck> mars, ok.
<mars> deryck, that was over a month ago?  The symptoms are the same though.
<mars> Probably different. I know that the Assign Me bug is related to the upgrade.
<mars> they fixed a bug in Y.DOM.create(), and our workaround for the bug created a bug
<deryck> gotchas
<mars> deryck, do you use the JS tag for your own purposes?
<deryck> mars, not really.
<mars> deryck, mind if I change it to 'javascript'?  That's the tag I track.
<deryck> mars, not at all.
 * deryck breaks for coffee
<mars> darnit, I just tried editing the bug tags on edge.  The display_name bug triggered, and the autocomplete popup is still there
<jml> mars, ever get to the bottom of that one?
<mars> jml, no, unfortunately.  I discovered that it may be blocking a bunch of other stuff though.
<flacoste> morning launchpadders
<mars> morning flacoste
<jml> flacoste, hello
<beuno> mars, hey. I saw your balsamiq mockups of the mps-in-bugs, and they are very promising  :)
<mars> beuno, that is a fun tool to play with
<henninge> danilo_: Hi!
<danilo_> henninge, hi
<henninge> danilos: shouldn't we be tracking the work for pot generation etc in a blueprint?
<henninge> danilos: any bugs filed already?
<danilos> henninge, yeah, we should be tracking it in a reasonable way
<henninge> danilos: are you going to do that? I feel you have a better overview than me.
<danilos> henninge, yeah, I'll do it
<sinzui> EdwinGrubbs: I notice you report a lot of bugs, but do not triad them.
<EdwinGrubbs> sinzui: do you mean I don't put them in the right project or I don't assign them to a person and set the importance/status?
<sinzui> EdwinGrubbs: You should know when reporting a bug whether is it critical, high, or low, which means it is triaged.
<EdwinGrubbs> sinzui: ok, I can do that from now on.
<sinzui> It helps a lot. I just found bug 405476 in launchpad in New. This would have been address a long time ago if it were triaged at the same time
<mup> Bug #405476: sprite class bleeds extra images in tall elements <post-3-ui-cleanup> <sprite> <tech-debt> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/405476>
<sinzui> mars: bug 488399 and bug 488491
<mup> Bug #488399: automate yui unit tests <build-infrastructure> <javascript> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/488399>
<mup> Bug #488491: tests/test_lp_collapsibles fails <build-infrastructure> <javascript> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/488491>
<henninge> danilos: I am almost done. Just so that I can finish the script tomorrow morning (forgot about being OCR), let's find a place for it.
<danilos> henninge, sure, let's
<henninge> danilos: lp/translations/scripts ?
<danilos> henninge, I'd say something like lp/translations/utilities/templategeneration/ or something like that
<danilos> henninge, I'd like to keep it all in the same place, because we'll have much more than just intltool support
<henninge> ok
<danilos> henninge, "templategeneration" does sounds unsuitably ugly though, so if you can find something better... :)
<henninge> henninge: templategeneration is awfully long, though
<henninge> danilos: but you are sure about the utilities subdir?
<danilos> henninge, you can also make a completely new subdir as well :)
<danilos> henninge, as long as it's all in a separate subdir, I'm fine :)
<henninge> danilos: I'd like that better, the import statements get soooooo long ;)
<henninge> danilos: "building"
<henninge> ?
<danilos> henninge, I was thinking of something like lp.translations.model.utilities.bridingthegap.templategeneration ;)
<henninge> oh yeah, let's do that ! ;)
<henninge> lp.translations.building
<danilos> henninge, "building" is way too broad, don't do that :)
<henninge> lp.translations.generating :-P
<henninge> lp.translations.generate
<henninge> lp.translations.potgeneration
<danilos> henninge, hum, potgeneration, I like it but it's not really according to our coding style :)
<danilos> henninge, just go with something, and I'll look the other way if I don't like it :)
<danilos> henninge, we can always rename it later, it's not too hard :)
<henninge> danilos: potgeneration it is, then :)
<danilos> henninge, cool :)
<henninge> danilos: "pot" *is* an English word!
<danilos> henninge, I know :)
<henninge> lp.translations.pottery ;)
<danilos> henninge, heh, right...
<danilos> henninge, it's actually not a bad name for if we decide to extract it out of Launchpad :)
<danilos> henninge, so, I won't mind even if you call it that :)
<henninge> cool, I will!
<jml> lp.translations.hydroponics?
 * jml signs off IRC for the day
<jml> g'night all
<mars> BjornT_, still have time for that call?
<BjornT_> mars: yes. skype?
<mars> BjornT_, yep
<BjornT_> mars: audio problems...
<mars> BjornT_, "Remote sound problem"?
<mars> BjornT_, http://blog.davglass.com/2009/04/git-helper-for-yui-contributors-v1/
<mrevell> night sall
<mrevell> or even all
<bac> hi sinzui -- can you think of a reason why getAdministratedTeams would need to include merged teams?  my proposed fix for bug 429802 is to not include merged teams in that property
<mup> Bug #429802: Merged teams showing up in the web ui <oops> <Launchpad Registry:In Progress by bac> <https://launchpad.net/bugs/429802>
<sinzui> bac: I really do not think merged teams should show up in a vocab. I am not sure they should appear in the UI either (except to LOSA)
<sinzui> bac: I am continually surprised that I can see merged teams since they are useless and uninteresting
<bac> sinzui: afaict even admins can't do anything with them.
<mwhudson> morningish
<sinzui> I think you are right
<bac> sinzui: i will fix bug 255798 while i'm at it
<mup> Bug #255798: ValidTeamVocabulary and ValidPersonOrTeamCache not really valid <tech-debt> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/255798>
<sinzui> !!
<sinzui> bac: I was looking for that
<sinzui> bac: +1 and then +10
<thumper> mwhudson: found the impossible code path!
 * thumper takes Maia to playcentre
<bac> hi salgado
<salgado> hi bac
<mwhudson> thumper: ?
<thumper> mwhudson: the bit that makes the active reviews page blow up
<mwhudson> thumper: oh, good
<mwhudson> thumper: it's not just very old merge proposals then?
<thumper> no
<mwhudson> glad you found it then :)
<thumper> me too, I thought I was going nuts
<rockstar> thumper, I'm available to chat whenever you are.
<mars> abentley, ping, is bug 487209 fix and/or QA'd
<mup> Bug #487209: Replying to code review comments broken after YUI-3 upgrade <code-review> <yui-3-upgrade> <Launchpad Bazaar Integration:In Progress by abentley> <https://launchpad.net/bugs/487209>
<mars> ?
<abentley> mars: It is QA'd.
<mars> abentley, cool, so it is OK to mark it Fix Released?
<abentley> mars: We haven't released yet, so no.
<mars> well
<mars> abentley, I'm having some trouble pulling the db-devel merge number.  Would you mind updated the bug with it?
<mars> abentley, nm, got it: 8729
<thumper> mars: I don't think you got back to me about the edit link review
<mars> thumper, I did not see your reply.  I'll look at that now.  If you have a moment, care to review what I just posted to the reviewer's channel?
<mars> flacoste, rc-ping, could you please look at https://code.edge.launchpad.net/~mars/launchpad/fix-picker-result-parsing-487975/+merge/15436 ?
<thumper> rockstar: you're up
<rockstar> thumper, five minutes plz.
<thumper> ok
#launchpad-dev 2009-12-01
<thumper> lifeless: was there a bug about the +activereviews fubar?
<thumper> lifeless: FWIW I've found the bug and fixing it
<lifeless> thumper: I think it was lp death spiraling
<thumper> lifeless: no, it wasn't
<lifeless> thumper: and no, we didn't file a bug
 * thumper files one
<lifeless> thanks for fixing it.
<thumper> every time I think of the question I need to talk to gary about, it is my afternoon and he is away :(
<wgrant> LP doesn't work on Lucid :(
<wgrant> Should I upload fixes to my own PPA, and get somebody to copy them in?
<lifeless> wgrant: yes
<ajmitch> wgrant: I hope it's mostly due to python 2.5 support going away, and nothing more major
<wgrant> ajmitch: That's right.
<mwhudson> wow typing out model code is boring
 * wgrant yearns for bug tag editing in bug listings.
<lifeless> mwhudson: model code?
<wgrant> How do I create a WIP MP?
<mwhudson> lifeless: the python code that reflects the database tables
<mwhudson> wgrant: you create a ready for review one and change the status i think
<wgrant> mwhudson: Ah. That's a bit crap.
<mwhudson> (or "use the api", maybe)
<mwhudson> wgrant: yes
<thumper> wgrant: you used to be able to ..
<thumper> wgrant: but the option got removed for simplicity
<thumper> wgrant: I want to add an "Extra options" area like bugs
<thumper> wgrant: and bring it back
<thumper> AAARRRGGGHHHH!!!!!!!!!!!!!!!!!
<thumper> ââ¹
 * thumper files a bug
 * thumper doesn't file a bug, but just fixes the damn problem
<adeuring> good morning
<jelmer> 'morning
<noodles775> Morning jelmer :-D
<thumper> jelmer: hi, starting officially today?
<jelmer> thumper: hi - yep
<thumper> jelmer: welcome and congratulations
<bigjools> good morning jelmer
<jelmer> thumper: Thanks :-)
<wgrant> Morning.
<noodles775> Hi wgrant
<wgrant> bigjools: Did you get around to uploading that dpkg? My connection has returned to full speed, so I can do it if needed.
<bigjools> wgrant: not yet, I was half-way through editing the changelog
<bigjools> wgrant: I was trying to think of an appropriate version :)
<wgrant> bigjools: Some use the CAT version, others use ~launchpad1...
<bigjools> yeah I was going with the latter
 * wgrant prepares a lucid Launchpad PPA.
<bigjools> wgrant: it's uploading now
<wgrant> bigjools: Thanks
<wgrant> bigjools: Now I guess somebody needs to poke $LOSA and $EC2TEST_AMI_UPDATING_PERSON...
<bigjools> yarp
<bigjools> when the package is built I'll do that
<wgrant> Thanks.
<bigjools> wgrant: it was buildbot and ... ?
<wgrant> bigjools: ec2test images
<bigjools> that's the same thing in my head
<wgrant> bigjools: (and cocoplum and germanium and iron... how are those RTs going?)
<wgrant> They're different images.
<bigjools> can you tell I don't use ec2? :)
<wgrant> :(
<bigjools> wgrant: https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1374027
<bigjools> balls
<wgrant> Um.
<wgrant> That's odd.
 * wgrant looks.
<bigjools> debhelper(inst 6.0.4ubuntu1 ! >= wanted 6.0.7)
<mwhudson> i can rebuild the images for ec2 test
<bigjools> cool thanks.  I'd like to get the package built first :)
<mwhudson> just drop me a mail when the ~launchpad ppa has the new hotness
<bigjools> yarp
 * mwhudson shouldn't be at the computer any more...
<mwhudson> running away now
<jml> flee
<wgrant> bigjools: Let me check how my PPA managed to build it.
<wgrant> Ah, of course, it's not exactly the same.
<wgrant> mine's an older version.
<wgrant> You could use debhelper from hardy-backports, or ask cjwatson how he did it...
<wgrant> bigjools: You retried it?
<bigjools> no
<bigjools> wtf
<thumper> jml: please QA your bits :)
 * thumper runs away too
<wgrant> bigjools: The depwait giver-back is being rather too lenient, then?
<bigjools> yes
<bigjools> I thought it waited longer
<bigjools> I will copy the hardy-backports dpkg
<bigjools> s/dpkg/debhelper/
<wgrant> bigjools: Using the forbidden UI?
<bigjools> shhh
<wgrant> It is handy for that.
<bigjools> I don't mind making it more public if we can force people to specify package names up front
<wgrant> Right.
<wgrant> Although I don't see why it has to time out while listing them all.
<wgrant> Rebuild archives manage to list their packages.
<bigjools> yeah we can possible make the same optimisations
<bigjools> possibly*
 * bigjools stabs intel xorg
<jml> thumper, !
<wgrant> bigjools: Still broken, even on Karmic?
<bigjools> yes
<wgrant> bigjools: What's wrong with it?
<bigjools> z-order is totally borked sometimes, you get the wrong windows half-painted over the top of the one that has focus
<wgrant> I see that sometimes during Compiz transitions, but never otherwise.
<wgrant> (well, except for Firefox, but that's Mozilla)
<wgrant> bigjools: You didn't just retry it before it was published, did you?
<bigjools> I didn't
<wgrant> Or was that the depwait giver-back thing again?
<wgrant> Ah.
<bigjools> yes :/
<jml> if a revision broke the test suite because it was actually behaving badly, how should that be marked on the QA plan?
<bigjools> jml: BAD
<jml> bigjools, thanks.
<jml> I did some refactoring on the upload permission stuff
<jml> how should I QA that?
<bigjools> jml: ?? (untestable)
<jml> bigjools, is there some way to at least smoke test it?
<jml> make sure that people can still upload to their PPAs & what-not.
<bigjools> jml: yeah you can use dogfood if it was up :(
<jml> bigjools, hmm. ok.
<wgrant> bigjools: Still updating?
<wgrant> *restoring
 * jml writes a launchpadlib script to test the final QA item
 * wgrant tracks down the retry-depwait bug.
 * bigjools tries to get into dogfood
<wgrant> Well, it doesn't take pockets into account.
<wgrant> That would do it.
<bigjools> that's.... suboptimal
<bigjools> ooo nice race condition
<bigjools> retry build, click rescore, then see if you can beat it getting dispatched
<bigjools> if not, OOPS!
<wgrant> bigjools: Oh, do you want to review my gina 3.0 branch?
<bigjools> wgrant: I can, stick it in my queue
<bigjools> wgrant: it built \o/
<wgrant> bigjools: Excellent.
<mrevell> morning
 * bigjools retries other arches
<lifeless> random question
<lifeless> arch all packages
<lifeless> what controls what queue they go to? Is it code, or a db entry?
<wgrant> distroseries.nominatedarchindep
<wgrant> It's in the DB.
<lifeless> I was wondering, if we could just make it roundrobin through some  sort of hack
<wgrant> Sort of.
<wgrant> Bug #285206 is better.
<lifeless> just putting the idea out there.
<mup> Bug #285206: builddmaster needs to be able to deal with "random arch" buildds <oem-services> <soyuz-build> <Soyuz:Triaged> <https://launchpad.net/bugs/285206>
 * bigjools would love it if lifeless fixed that :)
<wgrant> It should be nearly free after BFB, I think.
<wgrant> The main problem is queueing.
<bigjools> yeah
<wgrant> s/queueing/ordering/
<jml> if I have a python dictionary corresponding to the JSON dict of a launchpad rest resource, can I somehow bless it into an actual launchpadlib object?
<jml> (also, is the rest service _slower_ than the rest of Launchpad?)
 * jml discovers launchpadlib.uris. Is happy.
<jml> hmm. http://paste.ubuntu.com/332235/
<jml> you know, if that got split out into a method that took 'representation' as a parameter, unit testing would be much easier, and I'd be able to do what I want.
<lifeless> jml: you should do that :)
<jml> lifeless, I should do a lot of things.
<jml> I need help dealing with a bad QA item. Who do I talk to?
<lifeless> whats bad about it
<lifeless> jml: I need a quick review (real quick): https://code.edge.launchpad.net/~lifeless/testtools/meta/+merge/15479
<jml> lifeless, done
<lifeless> thanks
<maxb> Hmm. Launchpad is confused. It has sent me a mail claiming "You are receiving this email because you are the uploader of the above PPA package." for bigjools upload of dpkg to launchpad PPA
<bigjools> !
<bigjools> that's special
<bigjools> maxb: ah I know why
<bigjools> it's because you're listed as a separately permissioned uploader
<bigjools> it's deliberate
<bigjools> but the email template is wrong of course
<maxb> It's still wrong :-)
<bigjools> yeah :(
<bigjools> it was done for our OEM team so they get all upload notifications sent to a list
<maxb> In a perfect world we'd extend the concept of subscriptions to PPAs
<bigjools> yes, that's the eventual plan
<bigjools> then we can remove the emails that go to the owner's address
<wgrant> Hm.
<wgrant> I note a lack of lpia Lucid PPA builds
<wgrant> Has the chroot been removed, but not yet the DAS?
<bigjools> yes
<wgrant> Ah.
<asabil> hi all
<asabil> is it possible to configure launchpad not to use subdomains ?
<jml> no, not really.
<asabil> ok
<jml> barry, hey, you know 'make run_all'?
<jml> barry, can we stop it from doing that mailman spew?
<barry> jml: it should only spew if something earlier up fails
<jml> 127.0.0.88 - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:07 +0100] "POST /mailinglists HTTP/1.0" 200 392 4 0.135702133179 46 47 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
<jml> 127.0.0.88 - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:08 +0100] "POST /mailinglists HTTP/1.0" 200 392 3 0.0679800510406 25 36 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
<jml> 127.0.0.88 - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:13 +0100] "POST /mailinglists HTTP/1.0" 200 392 4 0.0281419754028 20 46 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
<jml> barry, I mean that spew.
<barry> jml: oh
<barry> jml: well, i guess shut off logging in the xmlrpc server?
<jml> barry, what's making the requests?
<allenap> mars: I'm about to look at bug 489342, but I wondered if you know if anyone else has already done some work on it?
<mup> Bug #489342: "'display_name' is undefined" JavaScript error on development <javascript> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/489342>
<barry> jml: it's the mailman xmlrpc queue runner.  it polls launchpad.dev every so often
<jml> barry, hmm.
<mars> allenap, jml and I looked into it on Friday.  We thought it may have been a change in the last week, but I was able to reproduce on an old branch of db-devel.
<mars> allenap, I'm really puzzled by the bug's absence on staging and edge.
<jml> barry, I think what I might do is abandon 'make run_all'
<barry> jml: unless you really need the other services, that's the best advice i can give
<jml> mars, out of curiosity, have you diffed the various outputs?
<mars> jml, the on-page outputs?  No, good idea though.
<mars> allenap, ^
<jml> mars, yeah, that's what I meant: js, css & html.
<jml> mars, it might not locate the problem, but you might find out what's different about edge & staging.
<allenap> mars: Okay, I have no idea what that refers to yet, but I'll take a look :)
<jml> barry, codehosting needs the private XML-RPC service
<barry> jml: iirc, there are ways to start services selectively.  i don't remember the details, but you should be able to make run_all and not start mailman.  read the Makefile for details (there's a make variable)
<jml> barry, hmm. thanks.
<mars> allenap, details are in the bug description.  The bug doesn't show up in production, only on devel.  By capturing and diffing the output of a real page, we might be able to narrow down what is different between production and devel.
<jml> barry, even if there's a variable, I might make a helper though. It's _really_ useful to be able to fire up codehosting without thinking too much.
<jml> barry, even if there's a variable, I might make a helper though. It's _really_ useful to be able to fire up codehosting without thinking too much.
<barry> jml: copy the run_all target and remove mailman from the bin/run -r option
<jml> ok. I'll do that.
<jml> although, it's week 4
<jml> why are we even talking about making small improvements to increase developer speed :(
<barry> jml: exactly. jfdi
<jml> barry, I can't!
<jml> barry, week 4 means I can't.
<barry> jml: so now you've started to find the root cause.  rinse and repeat :)
<jml> barry, well, there's already some interest in thawing during week 4
<barry> jml: that would rock
<allenap> gmb: Have you got 10 minutes to talk about bug 489342? I think it's related to the async subscriber portlet work.
<mup> Bug #489342: "'display_name' is undefined" JavaScript error on development <javascript> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/489342>
<gmb> Oy.
<gmb> allenap: Sure.
<gmb> Skype?
<allenap> gmb: Cool, Skype? Ready? :)
<EdwinGrubbs> bac: ping
<jml> is there a PPA with all of the latest launchpadlib stuff in it?
<bigjools> jml: I hear we have this great search thing in LP ...
<cody-somerville> I heard its crap
 * bigjools takes cody-somerville off his xmas list
<cody-somerville> :-(
<bigjools> jml: also see the cool expander at the bottom of here https://edge.launchpad.net/ubuntu/+source/python-launchpadlib
<jml> bigjools, you know what, I tried searching for 'launchpadlib ppa' and I found a broken link to one of your PPAs at item eight or so
<bigjools> jml: or you can go to https://edge.launchpad.net/ubuntu/+ppas :)
<bigjools> umm ew, broken icons
<jml> hmm. no one seems to have packaged the latest release
<mars> beuno, ^ looks like more sprites are broken, this time on https://edge.launchpad.net/ubuntu/+ppas
<beuno> hrm
<mars> same problem, the sprites have been applied to a block-display <li> tag
<beuno> yeah
<beuno> they need to be applied to a span
<jml> anyway, where was I.
<jml> one of my QA items is bad. An API I added doesn't behave as advertised. Instead of returning a dict mapping URLs to branch objects, it returns a dict mapping URLs to branch json dicts.
<jml> how can I tell what db queries are used to load a person via the API?
<mars> jml, is there a way to tell which queries are used on a regular launchpad page?
<mars> versus the API
<jml> mars, yes. you can add ++oops++ as the suffix of the URL to generate an oops report
<mars> jml, oh, neat.  I assume you tried that with the API URL?  Might work, depending on how the publisher machinery views the request.
<sinzui> have I mentioned how much I hate ZCML recently? Well I still do.
<jml> well, I tried entering an API url into my browser. All I get is "Unknown consumer (None)."
<mars> sinzui, hehe
<jml> mars, whether I use the suffix or not
<jml> mars, https://dev.launchpad.net/Debugging was where I got the ++oops++ trick from, btw
<mars> jml, try it via the launchpad.net/api/ URL
<mars> jml, the url that the JS uses
<jml> no joy
<jml> different stuff, no oops love.
<bac> EdwinGrubbs: hi
<mars> jml, wow, thanks for the debugging page link.  That is useful!
<jml> mars, np. please update it as you think of stuff.
<mars> jml, just tried it myself, and you're right.  No oops for API ++oops++ urls.  darnit.
<jml> '* * * * *' means "run every minute" in cron, right?
<jml> hmm.
<jml> can 'links' log in to Launchpad, I wonder.
<mars> jml, on devel, tried "$ LP_DEBUG_SQL=1 make run"
<mars> it doesn't return too much
<mars> I wish I could tell were the session and auth SQL statments begin and end though
<mars> also works in curl: $ curl -k https://bugs.launchpad.dev/api/beta/~name12
<jml> mars, not quite as convenient as being able to generate an OOPS, sadly.
 * jml starts gathering data on how long it takes to do a named get for a particular api
<EdwinGrubbs> bac: I had some questions about private teams and vocabularies. I see that you currently allow private teams in the ValidTeam vocabulary if the user is a participant of the team, but a private-membership team is never in the vocab.
<bac> EdwinGrubbs: yes as PMTs can never be used for anything
<sinzui> EdwinGrubbs: we are trying to remove them because they really cannot be used for anything
<EdwinGrubbs> bac: currently, if a form field uses PublicPersonChoice with the ValidTeamVocabulary, it displays "Invalid value" for non-members trying to enter in a form and hides it from the picker. However, for members of the private team, the form displays "Constraint not satisifed" since PublicPersonChoice rejects it although it actually shows up in the vocabulary for members. This also means that the picker allows you to select a team t
<jml> hmm. something is going on that I don't understand
<jml> it looks like the first time I hit a bug via wget it takes a while to load, and then following hits take less time: http://paste.ubuntu.com/332535/
<bac> EdwinGrubbs: your last sentence got truncated.
<EdwinGrubbs>  bac:... This also means that the picker allows you to select a team that can't be used.
<bac> EdwinGrubbs: that indeed sounds like a problem.
<EdwinGrubbs> bac: so, I'm wondering whether the security measure should be primarily handled by the vocabulary or by the *PersonChoice. I can explain the pros and cons.
<bac> EdwinGrubbs: perhaps we need two vocabularies
<bac> EdwinGrubbs: one vocab to use with PublicPersonChoice and one to use with ParticipatingPersonChoice
<Ursinha> danilos, here is better, I guess :)
<Ursinha> or danilo_
<danilo_> Ursinha, hi, yes :)
<Ursinha> danilo_, rite :P
<danilos> Ursinha, so, what test is bothering you? :)
<Ursinha> danilos, lp.translations.browser.tests.test_product_view.TestProduct.test_primary_translatable_with_package_link failed
<Ursinha> danilos, I went to the test to see why, and it
<Ursinha> grrr
<bac> mthaddon: ping
<Ursinha> it's testing a behavior I wasn't expecting
<danilos> Ursinha, right, let me take a look
<Ursinha> danilos, the way I implemented, primary_translatable is or the translation focus or the development focus
<EdwinGrubbs> bac: the advantage of the vocabulary is that it does all the work, however, if you are allowed to pass in any vocab to PublicPersonChoice, etc., then you can confuse the programmer.
<Ursinha> that test expects that if the devel focus has a link to a package, we should return nothing
<Ursinha> danilos, ^
<danilos> Ursinha, well, it expects that for a reason, let me take a closer look :)
<Ursinha> danilos, I couldn't find an explanation where that properties were defined, so thanks for looking :P
<EdwinGrubbs> bac: Either, the PublicPersonChoice has to duplicate the privacy check in case an inappropriate vocab is used, or it has to restrict which vocabs are allowed, or we could have one Choice class per relevant vocab: PublicPersonOrTeamChoice, PublicTeamChoice, etc.
<danilos> Ursinha, did you change in any way how development_focus is used as primary_translatable other than giving precedence to translation_focus?
<Ursinha> danilos, I'm pretty sure I didn't, but I'll double check
<danilos> Ursinha, because, I don't see how your code would have broken the test since the test itself doesn't set the translation_focus
<Ursinha> danilos, indeed
<danilos> Ursinha, where's your branch so I can see how the test is failing as well :)
<bac> EdwinGrubbs: and we are currently doing #1, correct?
<EdwinGrubbs> bac: The advantage of putting the restriction only in the Choice classes instead of the vocabulary is that it prevents creating new two vocabs when we have orthoganol search criteria. For example, you could use PublicPersonChoice(vocab=ValidTeamOwner) or ParticipatingPersonChoice(vocab=ValidTeamOwner) instead of having two separate vocabs.
<Ursinha> danilos, https://code.edge.launchpad.net/~ursinha/launchpad/add-translation-focus/
<bac> EdwinGrubbs: at the expense of doing more in python than in SQL
<EdwinGrubbs> bac: actually, we are currently checking the value in both places.
<EdwinGrubbs> bac: although, you only have to check one value in python, which is not really as expensive as checking all the possible values in SQL.
<EdwinGrubbs> bac: for the picker search that is.
<EdwinGrubbs> bac: actually, nevermind that last point, since it only makes sense for private-membership teams which are going away.
<bac> EdwinGrubbs: if the constraint only lives in the Choice won't we get more situations where an inappropriate team is presented only to be rejected by the constraint?
<Ursinha> danilos, I think I know what I did wrong
 * jml now gathering data on how long stuff I care about takes
<danilos> Ursinha, cool
<EdwinGrubbs> bac: yes, but this does have the advantage of providing the user a clear error as to why the team can't be used, so they don't think the picker is broken when it can't find a team they know exists.
<sinzui> How do I clearsign the new COC for sample person?
<Ursinha> danilos, hm, no, false alarm :(
<bac> EdwinGrubbs: and what will that error look like?  something better than "Constraint not satisfied"?
<sinzui> dholbach provided a branch to update the COC, but we need a signed version by name12 to pass the test
<EdwinGrubbs> bac: I remember beuno mentioning at some point that it would be nice if unselectable items showed up in the picker, but it didn't let you click on them, but vocabularies don't really have a system for that built-in.
<EdwinGrubbs> bac: Yes, I was thinking of "Private teams are not allowed." for users that can see the team, but it will automatically default to "Invalid value" for other users.
<EdwinGrubbs> bac: The vocab would still filter out teams based on the user's ability to see them, but the Choice would handle whether a private team is an appropriate value for a given field.
<bac> EdwinGrubbs: I think what you describe sounds well thought-out and a simplification.
<EdwinGrubbs> bac: cool, so I didn't just waist a bunch of time staring at zope code for no reason.
<bac> EdwinGrubbs: that would never be wasted time.  well...
<Ursinha> danilos, it seems I created a translation_focus property to translations and it wasn't needed :) I guess I complicated what was simple
<danilos> Ursinha, could be, I tried playing with your branch and hit some issues with my LP tree
<Ursinha> danilos, well, fixed, pushed, running tests again
<mars> jml, check that the subsequent wgets are not returning a 304: Unchanged HTTP status code
 * mars <- back to lunch
<mrevell> night all :)
<EdwinGrubbs> bac: I see that ParticipatingPersonChoice only allows private teams and not public or private-membership, however, the docstring says it allows any non-private-membership team.
<mwhudson> good morning
<jelmer> hey mwhudson
<mwhudson> jelmer: https://code.edge.launchpad.net/~mwhudson/launchpad/code-import-paranoia/+merge/15467 btw
<mwhudson> jelmer: do you manage to test RemoteGitBzrDirFormat at all in bzr-git's tests?
<bac> EdwinGrubbs: that doesn't sound right
<EdwinGrubbs> bac: can you look at lib/canonical/launchpad/fields/__init__.py for me?
<bac> EdwinGrubbs: what you said is not correct
<bac> EdwinGrubbs: ParticipatingPersonChoice constraint is *not* of is_private_membership
<jelmer> mwhudson, yes, you're right - it's not tested
<bac> EdwinGrubbs: so it allows private and public
<jelmer> mwhudson: We need more test infrastructure for that
<jelmer> mwhudson, most of the underlying infrastructure is
<bac> barry: ping
<mwhudson> jelmer: did you see the thread about file:/// urls in the database on launchpad-dev?
<mwhudson> it's somewhat related
<jelmer> mwhudson, no, where was that? launchpad-dev?
<EdwinGrubbs> bac: sorry, I confused myself. It makes sense now.
<mwhudson> jelmer: yes
<bac> EdwinGrubbs: understandable
<mwhudson> jelmer: i guess automatically testing bzr-svn over http is pretty challenging :-)
<mwhudson> create an apache config file, run it, test, tear down the server
<mwhudson> but blearg
<mwhudson> jelmer: https://lists.launchpad.net/launchpad-dev/msg01828.html
<jml> mwhudson, hello
<mwhudson> jml: hello
<jml> mwhudson, mthaddon was asking today about memory problems we're having on bazaar.lp.net
<jelmer> mwhudson, I've just replied
<jelmer> mwhudson: bzr-local-test-server provides some help there
<jelmer> but it's far from trivial
<mwhudson> jelmer: i see
<mwhudson> jml: do we know what was using the memory?
<jml> mwhudson, lots of bzr processes.
<jml> mwhudson, some of them are hours old, which makes mthaddon suspect that bug 260171 has reared its head again
 * mwhudson waits for mup
<jml> 'Codehosting server used a lot of memory and not releasing "old" processes'
<jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/260171
<jml> for some reason it's private
<mwhudson> jml: well afaict nothing has changed here
<jml> mwhudson, yeah, that's what I was thinking.
<jml> mwhudson, which means we still don't know why the memory usage is so high.
<jml> mwhudson, or what to do in a situation where we're running dangerously low on memory
<mwhudson> jml: yes, i don't have a good answer for that last point
<maxb> wgrant: You seem to have mislanded a local change into     lp:~launchpad-committers/ubuntu/lucid/python-defaults/ubuntu-unofficial. Mind if I push --overwrite it?
 * maxb checks you have the revision in another branch, and does it
<mars> anyone able to help spot the problem with the following pqm-submit command?  It says I'm "Not authorized to commit to branch": http://paste.ubuntu.com/332582/
<mars> And I included the trailing slash on the --submit-branch this time.
<sinzui> bac: EdwinGrubbs: I am looking at bug 490224. I recall some decision a long time ago that affected the content-type of downloads, but I do not know the rules.
<mup> Bug #490224: .tar.bz2 download has wrong Content-Type <Launchpad Registry:New> <https://launchpad.net/bugs/490224>
<salgado> mars, can you do a --dry-run and paste the output?
<mars> sure
<mars> salgado, http://paste.ubuntu.com/332588/
<salgado> mars, I think what you want is to remove the trailing slash
<mars> alright
<bac> sinzui: looking
<EdwinGrubbs> sinzui: I can't remember any possible root cause for the wrong content-type. What doe
<EdwinGrubbs> sinzui: oops, I was going to ask what does the db row for that file say the content-type is?
<sinzui> EdwinGrubbs: I do not know
<bac> EdwinGrubbs, sinzui: we are using mimetypes.guess_type to figure out the content type
<bac> sinzui, EdwinGrubbs: for "*.bz2" it returns (None, None) so we default to "text/plain"
<sinzui> ha ha
<bac> sinzui: it is in ProductReleaseEditView
<sinzui> that sounds familiar. Did we have some hacks to second guess other types?
<bac> sinzui: sorry, ProductReleaseAddDownloadFileVIew
<bac> sinzui: if we did we don't now
<EdwinGrubbs> sinzui, bac: it also seems bad that it returns Content-Encoding:gzip when it is already compressed with bz2.
<bac> but i don't think we did
<wgrant> maxb: Argh, damn, sorry. Must have checked that out rather than branched it.
<bac> EdwinGrubbs: using 'wget -S' i don't see that Content-Encoding
<maxb> I guess we should start populating the PPA for lucid :-)
<wgrant> maxb: Right, I've mostly done it in https://launchpad.net/~wgrant/+archive/launchpad
<wgrant> maxb: But lucid's pylint is currently uninstallable, and I decided that merging logilab-common at 1am was inadvisable.
<bac> sinzui, EdwinGrubbs: the mimetypes package for python2.6 returns (None, 'bzip2')
<maxb> joy
<bac> EdwinGrubbs: you have an XXX note about using python-magic.  Was any progress made on that?
<sinzui> bac: did you init()
<bac> sinzui: i don't understand?
<EdwinGrubbs> bac: in which file is the XXX?
<sinzui> bac:
<sinzui> >>> mimetypes.init()
<sinzui> >>> mimetypes.guess_type('file.tar.bz2')
<sinzui> ('application/x-tar', 'bzip2')
<bac> sinzui: no i did not
<EdwinGrubbs> bac, sinzui: btw, the odd Content-Encoding:gzip only occurs on HEAD requests, so it is irrelevant.
<bac> sinzui: but if i do "init()" i get the same results of (None, None)
<sinzui> oops. We do not call init in the class
<bac> sinzui: you sure you're using 2.5?
<bac> EdwinGrubbs: browser/productrelease.py
<sinzui> I am using 2.6, but the mimetype.init() requirement is ages old.
<maxb> wgrant: In order to point out that it's being worked on already, shall I copy your python-{defaults,support} into the launchpad PPA?
<bac> sinzui: it does not seem to change the results on 2.5
<sinzui> I see 2.5 is buggered
 * sinzui checks 2.4
<sinzui> Well that's below average
<bac> sinzui: calling init is not required. it looks like guess_types calls it if not done yet
<sinzui> I see it has an inited attr
<wgrant> maxb: That's probably a good idea.
<sinzui> bac: in any case, we either need to update to python 2.6, or hack the Finder and ProductReleaseAddDownloadFileView classes. In all cases we need a db update
<bac> sinzui: why a db update?
<maxb> done. I'll ignore the no-change rebuilds for now
<maxb> unless you think otherwise
<sinzui> because all the bz2 files uploaded via the View are the wrong content type
<sinzui> bac: Finder defaults to application/octet-stream
<bac> sinzui: ah, you mean we need to update the data we've stored.  right.
<bac> sinzui: can we install a mimetypes file that includes knowledge of .bz2 and use it when we init mimetypes?
<bac> sinzui: or just provide a wrapper around it that knows about .bz2
<sinzui> bac: I am not sure what to do.
<bac> sinzui: perhaps look at the diff in the mimetypes.py from 2.5 and 2.6 and see if we can hack the difference
<sinzui> We are close to getting to 2.6
<sinzui> gary_poster: barry: was there an estimate of effort or time needed to get to 2.6?
<barry> sinzui: at the time we thought maybe another week or two
<bac> sinzui: it looks like they just add new entries into suffix_map and encodings_map
<barry> sinzui: it kind of depends on the dependencies
<bac> sinzui: i think mimetypes provides means to do that cleanly
<gary_poster> sinzui: we don't plan to move to 2.6 until Lucid unless there is something really compelling
<sinzui> bac: the easiest is to make the Finder and AddDownloadFile agree that the default is application/octet-stream
<bac> sinzui: why not x-tar?
<bac> sinzui: look at the comment in /etc/mime.types
<bac> sinzui: recall .bz2 and .gz are compression not encodings, so we need to figure out what has been compressed
<maxb> I was planning to start getting in the residual changes from the python-migration2.6 branch this week, but then I noticed it was week 4, so I figured I might as well do it next week instead
<sinzui> bac: yes, I agree with you
<sinzui> bz2 appears to be the only broken type of the common types. I think we can add a rule to set the type to application/x-tar for bz2
<sinzui> barry: mwhudson: I vaguely recall that we could drop our hacks to urlsplit, urlparse, and safe_hasattr when we switched to python 2.5.
<barry> sinzui: i think that's right.  i don't remember the details though
 * mwhudson doesn't remember anything about this sorry
<sinzui> bac: I loath to do extensive hacking to fix mimetypes since we will toss it out when we get to 2.6
<bac> sinzui: i agree.  it just depends on the window...
<bac> sinzui: but will there be others we discover?
<sinzui> If we add up the time to add and remove 2.6 hacks, we may just find that we would save time helping launchpad get to 2.6
<bac> sinzui: probably.  but i still wonder if our users won't always be ahead of the mimetypes package so having the infrastructure in place to update it might be useful.
<bac> sinzui: BjornT_ would probably know about urlsplit, etc
<sinzui> bac: excellent argument. We know the ones we must support. we can call init(mimetypes.knownfiles + ['launchpad,mimetypes']) to ensure we do not get regressions
<BjornT_> bac: i just confirmed that urlparse and friends are fixed in both 2.5.4 and 2.5.2, so we should be able to remove our versions
<sinzui> \o/
<wgrant> Can anyone think why bootstrapping LP on lucid would be attempting to grab 'distribute'? I didn't think LP used it at all.
<wgrant> My upgraded installation works fine, but bootstrapping a new one fails.
 * mwhudson also wonders why launchpad-dependencies doesn't want to install on hardy
<wgrant> mwhudson: What does it whine about?
<wgrant> Hmm, new dpkg-dev not liking old devscripts, maybe?
<mwhudson> wgrant: http://pastebin.ubuntu.com/332660/
<wgrant> There was something like that in my previous experiments, but it didn't appear to be a problem here.
<mwhudson> wgrant: yes, something very much like that
<wgrant> mwhudson: Try devscripts from hardy-backports.
 * mwhudson wonders if hardy-backports is enabled...
<wgrant> Not by default.
<wgrant> Ah, EC2. Inconvenient.
<mwhudson> i guess there's no wonderful "sudo enable-backports" command?
<wgrant> mwhudson: Not beyond 'echo "deb http://archive.ubuntu.com/ubuntu hardy-backports main restricted universe multiverse" >> /etc/apt/sources.list'
<mwhudson> wgrant: i guess i'll do something like that then
<wgrant> mwhudson: The devscripts from hardy-backports is indeed new enough to not fall afoul of the new dpkg-dev.
<mwhudson> yes, this seems to be Doing Stuff
<wgrant> mwhudson: If that works, just copy 2.10.39ubuntu2~hardy1 from https://edge.launchpad.net/ubuntu/+archive/primary/+copy-packages?field.name_filter=devscripts&field.status_filter=published&field.series_filter=hardy
<mwhudson> wgrant: "copy existing binaries" ?
<wgrant> mwhudson: Yes.
<mwhudson> hm
<mwhudson> i wonder if this is going to time out
<mwhudson> yes
<wgrant> It didn't when I tried it last week :(
<wgrant> Ah, looks like I didn't copy binaries.
 * mwhudson confuzzed
<wgrant> Anyway, I have a train to catch.
<mwhudson> now i get The following source cannot be copied:
<mwhudson>     * devscripts 2.10.39ubuntu2~hardy1 in hardy (same version already building in the destination archive for Hardy)
<mwhudson> wgrant: thanks for the hints so far
<wgrant> Um.
<wgrant> Odd.
<wgrant> Oh.
<mwhudson> so it looks like the copy was actually ok and the time out was rendering the resulting page
<mwhudson> maybe
<wgrant> Did it maybe time out while trying to render +copy-packages again?
<wgrant> Right.
<wgrant> Yeah, it copied fine.
<wgrant> Anyway, /me leaves.
<mwhudson> so i just have to wait until it's published and then we'll be happy
<EdwinGrubbs> sinzui: I sent my response to your review. I could work on an oops bug tonight, if there is something you would like fixed before the rollout.
 * sinzui looks.
 * maxb wishes LP defaulted to "copy binaries". Deciding to rebuilt already built source ought to be a deliberate choice
<sinzui> EdwinGrubbs: We do not have any RC candidates. I see two bugs Bug #230801 and Bug #406751 that I think are short
<mup> Bug #230801: AssertionError triggered renewing team membership <oops> <registry> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/230801>
<mup> Bug #406751: misprint in title of "/@@/maybe" image  <trivial> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/406751>
<sinzui> EdwinGrubbs: neither needs to be done this week
 * mwhudson watches x11 being installed on the ec2 image
<mwhudson> that's a little odd
<mwhudson> hm, only x11-common
<EdwinGrubbs> sinzui: I'll look into the first one
 * mwhudson lunches
#launchpad-dev 2009-12-02
<thumper> rockstar: around for a chat? 5m?
<rockstar> thumper, dog's in the backyard.  5m is good.
<rockstar> thumper, call anytime.
<rockstar> thumper, plugged in, my headset was not.
<thumper> rockstar: I'll call you when I've finished nom'ing
<rockstar> thumper, okay.
<lifeless> http://howsmycode.com/
<rockstar> lifeless, awesome.  I need to take a look at this.
<wgrant> mwhudson: Is the image happy now?
<mwhudson> wgrant: seems so
<mwhudson> wgrant: i guess i should boot it and check all the versions are right, can you tell me what versions i should look for?
<wgrant> mwhudson: dpkg-dev >= 1.15
 * wgrant checks the exact version.
<wgrant> dpkg-dev 1.15.4ubuntu2~launchpad1~bigjools1 is the important one.
<mwhudson> ok
 * mwhudson taps his fingers
<wgrant> Hm, so 3.1.12 is actually only two weeks long?
<mwhudson> wgrant: ii  dpkg-dev                          1.15.4ubuntu2~launchpad1~bigjools Debian package development tools
<mwhudson> looks ok
<wgrant> mwhudson: Thanks muchly.
<wgrant> Now... the buildbot AMIs need doing too. spm?
<spm> wgrant: once we get lp-deps updated, sure
<spm> but perhaps not the day before a release :-)
<wgrant> spm: Probably not, true.
<mwhudson> tests appear to be running, should make this image public then i guess
<wgrant> mwhudson: If you want to test that it actually works, lp:~wgrant/launchpad/distroseries-source-format-selection is the branch that needs it.
<mwhudson> wgrant: would running the tests on that branch be useful at this stage?
<wgrant> mwhudson: It's done and approved, but hasn't had a full test run yet, so probably.
<mwhudson> wgrant: ok i'll give it a go
<wgrant> mwhudson: Thanks.
<mwhudson> wgrant: you can follow along at http://ec2-75-101-192-167.compute-1.amazonaws.com/current_test.log
<mwhudson> (assuming i did the security group thing right)
<wgrant> mwhudson: You did. Thanks.
<wgrant> Who is this Vikram character, and why is he giving bad advice on Launchpad questions?
<spm> example?
<wgrant> https://answers.edge.launchpad.net/launchpad/+question/92507
<spm> oh him/her. right. sigh.
<wgrant> I've seen many similar cases :(
<mwhudson> spm: is staging down?
<spm> mwhudson: yes
<mwhudson> spm: rather, is staging expected to be down
<mwhudson> spm: ok
<mwhudson> spm: eta on back up-ness?
<spm> mwhudson: wrong db configs/versions/brokenness I was hoping it'd fix itself. bzzt.
<spm> mwhudson: not yet, no.
<mwhudson> wgrant: boggle
<mwhudson> spm: ok
<wgrant> While that solution will probably work, it's not really a solution, and is wrong.
<spm> wgrant: they popped up on #lp last week. "I am **the** LP answer contact". Asked if they could have admin privs because of. I was impressed at the ignorance; polite, but impressed.
<wgrant> spm: Yes, I saw...
<spm> I was also impressed at my ability to not lol in their face :-)
<ajmitch> spm: but why didn't you give them admin privileges? You're so mean...
<spm> ajmitch: it goes with the territory of being a sysadmin. sign says "<rude word related to bum>" on the door. sorry. ;-)
<ajmitch> spm: and I suppose you have the BOFH calendar on your desk as well
<spm> the 128 column dotmatrix one? not anymore. ;-)
<spm> mwhudson: oh bugger. michael did a private branch landing on staging - and db update as well; hence the boomsville. crap. will need to disable staging updates, as they wiped the merge.
<mwhudson> spm: yay
<spm> mwhudson: should be back-ish now.
<mwhudson> class IPackageUpload(Interface):
<mwhudson>     """A Queue item for Lucille"""
<mwhudson> this is not all that helpful
<mwhudson> wgrant: what's 'lucille' ?
<wgrant> mwhudson: Looooong before my time, but I believe it was the original name for archivepublisher/archiveuploader/buildmaster
<wgrant> ie. Soyuz
<mwhudson> oh
<mwhudson> so that really isn't a very helpful docstring
<ajmitch> back when everything was a proper name, like in debian
<wgrant> Not terribly helpful, no.
<wgrant> What's left? gina, zeca, poppy...
<wgrant> Must be something else.
<ajmitch> There used to be a list somewhere of the names that Debian used, I don't know if there was something for ubuntu & launchpad
<wgrant> The Debian list (inside the dak source) includes a list of Canonical names.
<mwhudson> wgrant: what does gina do?
<wgrant> mwhudson: Imports Debian archives into LP.
<mwhudson> that's another thing i've never gotten straight in my head either
<mwhudson> oh ok
<wgrant> Or, more often, breaks.
<mwhudson> heh
<ajmitch> does it break like the package branch importing is sometimes doing these days?
<wgrant> That relies on gina to notify it of new Debian packages.
<ajmitch> wonderful
<wgrant> mwhudson: Solved Soyuz yet?
<mwhudson> wgrant: haha
<ajmitch> wgrant: I thought you were doing all the soyuz fixing :)
<mwhudson> wgrant: lp:~wgrant/launchpad/distroseries-source-format-selection passed tests
<wgrant> mwhudson: Excellent. Thanks.
<mwhudson> i could forward you the email i guess, but it's not very exciting
<wgrant> I would imagine not.
 * thumper EODs
<mwhudson> gosh, IBuild is a pretty fat interface
 * mwhudson finds https://dev.launchpad.net/StormMigrationGuide and https://dev.launchpad.net/Database/StormMigrationGuide
 * ajmitch wonders if they were meant to be 2 different URLs, or is one a redirect to the other?
<bigjools> good morning hackers
<henninge> Hi bigjools!
<henninge> :)
<bigjools> hey henninge
<henninge> noodles775: Hi!
<noodles775> Hi henninge :-)
<henninge> noodles775: Have you been using balsamiq? Do we have something like an "empty LP page" to start from?
<noodles775> henninge: no, I haven't, so not sure.
<BjornT_> jml: you wouldn't happen to have a bzr plugin that queries launchpad and lists all my unmerged branches, would you?
<jml> BjornT_, sadly no.
<jml> BjornT_, I did, however, write this plugin yesterday, which isn't actually directly useful or related, but kind of cool: http://paste.ubuntu.com/332980/
<BjornT_> jml: i wonder, would it be hard to have a base 'lp bzr plugin' class, which would automatically log in to lp, and have switches for choosing whether to use edge or staging, and probably a few other useful things as well?
<jml> BjornT_, not hard at all!
<jml> BjornT_, I really want to get such a thing into bzr-core
<BjornT_> yeah, that would be cool
<jml> BjornT_, but there are some dependency issues to navigate, so it should probably be in an external plugin for now.
<jml> BjornT_, btw, do you know about launchpadlib.uris?
<jml> BjornT_, this branch has my previous attempt to get that stuff into bzr: https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth
<jml> BjornT_, I've also squatted 'https://launchpad.net/bzr-launchpad' just in case.
<BjornT_> jml: i think i now a bit about launchpadlib.uris. i didn't add it, but i know where it comes from
<jml> BjornT_, I don't :) I only discovered it recently and thought "gosh, now I can delete code from a dozen little scripts"
<jml> (well, I can as soon as someone packages a version of launchpadlib that has the module)
<ajmitch> jml: so if I'm looking at this API for blueprints, should I reassign the bug to me?
<mrevell> morning
<jml> ajmitch, with my blessing.
<jml> mrevell, hello
<bigjools> BjornT_: rocketfuel-status is supposed to do that
<bigjools> not as nice but it works
<BjornT_> bigjools: not as nice == totally unreadable, and include all my abandoned branches. it also doesn't work for my lazr-js branches, and appears to take a really long time
<jml> BjornT_, oh, I should mention that I've written a plugin called 'bzr-removable' that looks at your branches on disk and tells you which can be removed (i.e. no changes, are merged)
<jml> it also has an inverse command, if you are into that sort of thing.
<jml> BjornT_, I haven't used it in anger since we got *four trunk branches* though.
<BjornT_> jml: fwiw, http://tillenius.me/blog/2009/12/02/wanted-bzr-plugin-to-manage-branches-in-launchpad/
<jml> BjornT_, I got a 500 when I tried to comment :)
<BjornT_> jml: hmm... :)
<jml> BjornT_, the comment is there though, so no need to drop everything :)
<BjornT_> jml: yeah, i noticed that now, after succesfully adding a test comment myself
<mrevell> BjornT_, Just Idented/Twittered your post :)
<BjornT_> mrevell: thanks, i hope some will will actually implement it :)
<jml> BjornT_, well, I _do_ have a thirty hour journey this week
<BjornT_> jml: that's nice to hear :)
<jml> james_w, hah! I am now tasting the bitter sting of 503 errors from launchpad APIs!
<jml> I wish I could take a train to Australia. It would be so much easier to get some coding done.
<deryck> Morning, all.
<mpt> mrevell, <https://dev.launchpad.net/> links to <https://dev.launchpad.net/Foundations>, which doesn't exist
<mrevell> thanks mpt, I'll fix that
<BjornT_> matsubara: could you try editing a bug status and milestone on staging using chrome (for bug 490796)? i've confirmed it works in both firefox and opera
<mup> Bug #490796: "Target to milestone" takes you to +editstatus <Launchpad Bugs:Fix Committed by bjornt> <https://launchpad.net/bugs/490796>
<matsubara> BjornT_, sure
<BjornT_> thanks
<matsubara> BjornT_, works fine on Chromium 4.0.257.0 (Ubuntu build 32926)
<matsubara> BjornT_, one small thing, when I click the green plus sign in the milestone control, I'm redirected to +editstatus
<matsubara> BjornT_, clicking on the "Target to milestone" link works as expected though (i.e. I get the overlay and can set the milestone accordingly)
<BjornT_> matsubara: right, i see the same in opera and firefox :(
<BjornT_> matsubara: it doesn't seem to be a regression, though. i see the same behaviour on edge and launchpad.net
<matsubara> BjornT_, ok, if it behaves the same in all the major browsers, it's fine. thanks for fixing it. :-)
<jml> o/` hug the mountain o/`
 * jml -> lunch
<barry> reviewers, hackers, lurkers -> #launchpad-meeting in 5m
<barry> reviewers, hackers, lurkers -> #launchpad-meeting
<al-maisan> do we use the zope class registry anywhere? Is it safe to use within Launchpad? I am primarily interested in getClassesThatImplement(iface), please see http://docs.zope.org/zope3/Book/inspect/classregistry/show.html for details.
<al-maisan> If not is there anything similar in Launchpad that I can use?
<jml> al-maisan, hmm. not that I know of. (Also, it sounds similarish to the bzrlib registry)
<jml> james_w, hello
<james_w> hi jml
<al-maisan> jml: thanks for the info!
<jml> james_w, I've got five things to talk with you about. Can we have a call sometime?
<james_w> jml: sure thing
<james_w> jml: this week?
<jml> james_w, yes please. I'll be in Australia next week, which will make voice comms more challenging
<james_w> ok
<jml> (it's a long way to shout)
<adiroiban> are there any plans for moving this wikipage to dev.lp.net ? https://launchpad.canonical.com/SearchingTranslations
<adiroiban> it is linked from the Rosetta Search blueprint
<mrevell> adiroiban, Probably no plan but let me take a look at that page
<mrevell> danilos, are you happy for this page to move to the dev wiki? https://launchpad.canonical.com/SearchingTranslations
<sinzui> adiroiban: there are too many pages on that wiki, most are rubbish We have made every blueprint public that has been requested. In general, any spec over 18months old is probably worthless.
<adiroiban> sinzui: ok. no problem. I just wanted to know the plans for that blueprint
<adiroiban> sinzui: but I will talk with Danilo about it
<bigjools> jml: I am wondering if there is a way of namespacing this recipe stuff other than using the owner in the URL
<jml> bigjools, interesting.
<jml> bigjools, any specific ideas?
<bigjools> jml: nothing specific yet, I only just started to think about it
<bigjools> maybe tie them to projects, I dunno
<jml> bigjools, projects would be interesting. I think that would replace the source package, rather than the owner though
<bigjools> or we could just invent a new namespace
<jml> sure :)
<jml> I think I originally suggested lp.net/+recipe/<ID> :)
<jml> of course, recipes should probably have names
<bigjools> :)
<jml> and once they need names, you need namespaces.
<mars> jml, is there a spec for recipes?
<bigjools> IDs don't look so bad after all
<bigjools> maybe allow duplicate names and prefer the ID
<jml> mars, probably not in the way that you are hoping.
<bigjools> mars: see the long email thread in progress now...
<mars> jml, perhaps the 'plan for generic build system jobs' thread?
<jml> mars, I'm probably going to hammer some out rsn.
<jml> bigjools, what are your concerns with having owner, sourcepackage and recipe name in the URL?
<mars> ok, I'm just trying to get the elevator pitch for it :)  I'll check the thread.
<jml> mars, elevator pitch == "easy-to-make daily builds of your favourite upstream projects"
<mars> ah, so user-generated source package flavours
<mars> :)
<mars> jml, cool, thanks
<jml> I'm not sure what "flavour" means there
<jml> but if it works for you...
<jml> mars, check out bzr-builder for some more info on what recipes are in themselves
<mars> flavour means a slight customization of an existing construct
<jml> yeah, that's about it.
<mars> so that's why you are wondering about namespacing then.  Because they are user-generated, but are also not portable between packages?
<jml> mars, yes.
<jml> mars, also, one day, recipes will be able to refer to other recipes
<jml> (he says, confidence and ignorance walking hand-in-hand across his soul)
 * mars hears stub's distant screams of "Feature creep!"
<mars> :)
<mars> jml, interesting idea though.
<mars> jml, bigjools, you might find inspiration in the webservice API address scheme.
<mars> branch links come to mind as a similar concept: something that bridges between two pillars
<sinzui> I wish that porn spammer did not appear in in our oops reports. It seems like each day he tries to find an XSS hole in each application
<mars> jml, why would you use /+recipe/1 instead of /recipes/1 ?  The latter is a bit easier for users to understand in the address bar, assuming they can browse that URL.
<jml> mars, because people should be allowed to have a product named "recipes"
<mars> ah
<bac> hi sinzui
<sinzui> Hi bac
<bac> sinzui: do you have time today for a rescheduled 1:1 call?
<sinzui> yes, from 2-5 today
<bac> sinzui: wow, i don't think i can talk for three hours
<sinzui> You can listen to my ever growing fears about the software center
<bac> sinzui: how about a 2pm call?
<bac> timeboxed to 35 minutes
<sinzui> okay
<mrevell> night all!
<mwhudson> good morning
<mwhudson> i guess it's good to get the debate going and get the ideas out of my head, but i think al-maisan's mail is inaccurate in every point it makes :(
<lifeless> mwhudson: !
<mwhudson> jml: did you want to have a call?
<rockstar> mwhudson, abentley, stand up?  I believe thumper is unavailable today.
<abentley> rockstar: sure
<rockstar> abentley, you should host.  I've been jumping between ISPs today.
<mwhudson> rockstar: sure
<abentley> rockstar: Okay, just waiting till you show as online.
<rockstar> abentley, one sec...
<mwhudson> rockstar: can you hear us?
<rockstar> mwhudson, yes, through the speakers though, not through my headset.
<rockstar> abentley, try now.
<abentley> rockstar: you went quiet
<mwhudson> rockstar: yay skype
<rockstar> abentley, mwhudson, yes, I noticed after I finished my whore schpiel.
<abentley> rockstar: We don't need to know about your whores.
<rockstar> s/whore/whole/
<rockstar> abentley, call again?
<mwhudson> twinkle?
<rockstar> mwhudson, my connection may just be terrible today.  We have some sort of crew at the end of the street working on something, possibly damaged by the snow.
<abentley> rockstar: was there more you wanted to add?
<rockstar> abentley, if there is, I'll reply to the notes.
<mwhudson> abentley: :)
<mwhudson> oh, it's xx:45
<abentley> mwhudson: Skype ftw/wtf (your choice)
<abentley> mwhudson: That issue stopped affecting my irc connection, so I thought it was gone :-(
<mwhudson> abentley: :(
<mwhudson> abentley: i guess we were more or less done
<mwhudson> abentley: i was just trying to ask, is there stuff about dependent jobs in the database already?
<abentley> mwhudson: Yeah, but I'd like to discuss testing my sftp change in a minute
<abentley> mwhudson: No, job dependencies were vetoed.
<mwhudson> i hadn't reallly thought about things in that light until now so I haven't looked
<mwhudson> abentley: woo
<maxb> Shall I file a bug that you can't request a vcs-import into a package branch, or is that deliberate?
<maxb> https://dev.launchpad.net/Maintenance has not been updated for this planned maintenance
<maxb> Perhaps it should be obsoleted in favour of one of the other communication methods
<mwhudson> maxb: it's certainly not deliberate, there might already be a bug though
<mwhudson> maxb: please have a look/file one
<maxb> It's sort of related to bug 402915
<mup> Bug #402915: Can no longer move a branch to another project <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/402915>
<mwhudson> yes
<abentley> mwhudson: chat?
<mwhudson> abentley: ok
<mwhudson> maxb: i'm surprised more people haven't given us grief over this bug
<james_w> maxb: I think it was intentionally left unimplemented as a first cut
<maxb> Ah, bug 369761, there's my bug.
<mup> Bug #369761: New code import page will not work for package branches <branch-picker> <code-import> <package-branches> <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/369761>
<abentley> mwhudson: http://paste.ubuntu.com/333394/
<maxb> sinzui: Around? I'd argue bug 400643 is not fixed - it now shows "Sid (98)" on edge - how is the number 98 meaningful to Debian sid?
* mbarnett changed the topic of #launchpad-dev to: **Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update** This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is lo
<sinzui> maxb: 98 is meaningful to some people the way that 9.04 is We decided that we cannot make the name-people and the number-people happy. We compromised and made the presentation of name (version) consistent though out  launchpad
<wgrant> sinzui: No. 98 is picked out of nowhere to make Launchpad happy.
<wgrant> Same with experimental's 99.
<wgrant> sid/experimental do not have version numbers at all.
<wgrant> But Launchpad doesn't cope with that.
<sinzui> wgrant: I do not want to fight with people. Launchpad cannot give each distribution separate version/name rules
<maxb> Yet clearly displaying made-up synthetic numbers in the UI is a bug
<wgrant> sinzui: The correct solution is to make the version optional.
<sinzui> If a distroseries should not have a version, then that is a separate bug. I do not see that bug reported
 * wgrant checks how hard that is.
<wgrant> Hmm, sorting. /me gives up already.
<sinzui> I think soyuz really wants the distroseries to be a number
 * maxb imagines a boolean "version is irrelevant" flag
<wgrant> maxb: I considered that.
<maxb> that, or you need a separate numeric sortkey
<sinzui> I think letting version be None would suffice
<sinzui> We handle milestones with None for code_name. It would be the same...
<maxb> sinzui: But there is an ordering relationship between squeeze, sid, and experimental which needs to be modelled
<sinzui> except that I do not know why a productseries and distroseries treat name and version differently
<lifeless> meep
<lifeless> I don't recall why either
<lifeless> where is kiko when you need him, or stub.
<sinzui> thumper: ping
* mbarnett changed the topic of #launchpad-dev to: **Launchpad will be down/in read-only from 22:30 UTC until 23:30 UTC for a code update** This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is lo
<sinzui> I see a mixed security warning on https://code.edge.launchpad.net/~jelmer/subversion/trunk. I do not see what is causing it
<wgrant> sinzui: A colleague noticed the same thing last week. We could not work it out.
<ajmitch> it's not something loaded indirectly from JS?
<sinzui> I recall IE did stupid things like pull in the http feed (that is a meta) and  declare that the page was unsecure
<sinzui> ajmitch: I suspect so
<ajmitch> or firefox could be looking at the atom feed as well
<wgrant> sinzui: Other LP pages with HTTP feeds are fine, so that's not it.
<ajmitch> firebug will probably tell you what it's fetching
<wgrant> Hm, some YUI stuff is HTTP.
<wgrant> http://yui.yahooapis.com/combo?3.0.0pr2/build/widget/assets/skins/sam/widget.css&3.0.0pr2/build/widget/assets/skins/sam/widget-stack.css&3.0.0pr2/build/overlay/assets/skins/sam/overlay.css& is pulled in by JS somehow.
<wgrant> Isn't all the YUI stuff meant to be embedded in one file?
<ajmitch> that's the only http-only request I can see
<sinzui> I think code.branchstatus in the YUI.use() instruction is at fault. code.branchstatus is not listed in base-layout-macros.pt's load-javascript. Since the script is not compiled, YUI makes a call to retrieve it, and I know it always uses http.
<wgrant> sinzui: A team merge will transfer everything across, won't it? Subscriptions, memberships, etc.?
<sinzui> yes, if it does not fail
<sinzui> well
<sinzui> I have learned that I can keep merging until it succeeds. With barry, that takes 22 merges
<barry> sinzui: that's better than all the karma points in the world
* mbarnett changed the topic of #launchpad-dev to: **Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update **  This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is 
<mwhudson> sinzui: hooray for finding that js problem on the code page
<sinzui> mwhudson: I have not founded it
<mwhudson> sinzui: oh
<sinzui> mwhudson: I added the suspect to the build script, but nothing was fixed
<sinzui> :(
<mwhudson> :(
<mwhudson> it's sooo hard to figure out how this is happening :(
<mwhudson> can you get yui to drop into a debugger when it makes the request somehow?
<sinzui> indeed. I was going to remove pieces of the script to find the cause
<sinzui> mwhudson: I do not think so.
<sinzui> The yui loader was the cause of problems in the past. We fixed it by ensuring that all the scripts were loaded by the page or in our compressed script
<sinzui> \o/
<sinzui> mwhudson: I enabled the net tab in firefox and loaded a branch page
<mwhudson> sinzui: did you learn anything interesting?
<sinzui> mwhudson: when I mouseover the get combo line I see the browser got assets from Yahoo
<mwhudson> sinzui: yes, that's what wgrant said earlier isn't it?
<sinzui> We seem to be missing widget.css, widget-stack.css, and overlay.css
* mbarnett changed the topic of #launchpad-dev to: **Launchpad will be down/in read-only from 0:00 UTC until 01:30 UTC for a code update ** This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
<sinzui> mwhudson: Since we upgraded YUI on staging and I do not see the same error. I am not going to worry about it anymore
<mwhudson> sinzui: oh that's good
<mwhudson> yay for problems that evaporate
 * wgrant wonders how everyone is going to know that the downtime is now two hours later than planned.
<wgrant> The downtime window is about to expire, and nobody has told identi.ca, or the appservers.
<adiroiban> can someone tell me what I should read in order to understand the "request/lp:person/fmt:link:mainsite" part from <a tal:replace="structure request/lp:person/fmt:link:mainsite" />
<lifeless> jml: where is that bug about testresources in lp
<wgrant> adiroiban: It's in canonical.launchpad.webapp.tales
<wgrant> adiroiban: lp:person would call RequestAPI.person, and fmt:link will call ObjectFormatterAPI.link
<wgrant> (although the second one has derivatives -- in particular you might want PersonFormatterAPI
<adiroiban> wgrant: thanks. I'll look into it
#launchpad-dev 2009-12-03
<lifeless> jkakar: On Wed, 2009-12-02 at 17:36 -0700, Jason Earl wrote:
<lifeless> Gordon Tyler <gordon@doxxx.net> writes:
<lifeless> >
<lifeless> > > lp:~doxxx/bzr/bzrmeta-ignore
<lifeless> > >
<lifeless> > > This is the first stage of my branch converting .bzrignore to
<lifeless> > > .bzrmeta/ignore. It does not have any backwards-compatibility handling
<lifeless> > > of .bzrignore which is the next stage I will be tackling. All tests
<lifeless> > > pass and I've updated the docs except the non-English stuff.
<lifeless> > >
<lifeless> > > If .bzrignore exists and 'bzr ignore blah' is used to add an ignore
<lifeless> > > pattern, should it add it to the existing .bzrignore or should it
<lifeless> > > convert the .bzrignore to .bzrmeta/ignore and add the new pattern to
<lifeless> > > that?
<lifeless> >
<lifeless> > This seems like a pretty simple question to me.  If you use the existing
<lifeless> > .bzrignore file, then old clients will continue to work.  If you convert
<lifeless> > the existing .bzrignore file to .bzrmeta/ignore, then old clients will
<lifeless> > stop working.
<lifeless> >
<lifeless> > Using the .bzrignore file if it exists means that projects can migrate
<lifeless> > to the new structure on their own terms.  New projects will end up with
<lifeless> > the proper .bzrmeta file, and existing projects can migrate as the need
<lifeless> > arises.  If a particular project wants to allow older clients then
<lifeless> > someone simply has to create the proper .bzrignore file (once) and
<lifeless> > everyone is happy.
<lifeless> >
<lifeless> > Jason
<lifeless> >
<lifeless> >
<lifeless> >
<lifeless> oh, fail.
 * lifeless is very very sorry
<lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
 * lifeless also hates firefox for not selecting properly
<lifeless> jkakar: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
<mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
<mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
<jkakar> lifeless: Thanks!
<lifeless> I had forgotten the details. I'm posting a couple of updates there.
* mbarnett changed the topic of #launchpad-dev to: **Launchpad will be down/in read-only from 01:30 UTC until 02:30 UTC for a code update **  This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
<maxb> oh dear. I guess rollout didn't go so well :-/
<mwhudson> "just" delayed, i think
<spm> prep had lots of issues. lots of lessons learned, so for all the badness, it's bad in a positive outcomes way.
* mbarnett changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<jml> lifeless, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
<mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
<adeuring> good morning
<mrevell> morning
<jml> good morning
 * jml would like to write a computer program
<bigjools> jml: I have plenty waiting, and my rates are very unreasonable
<jml> bigjools, sadly, I have wiki pages to edit first
<bigjools> jml: what an exciting life you lead in London!
<wgrant> He'll be back with us soon!
<bigjools> wgrant: BTW wellington is a go.
<bigjools> did someone contact you?
<wgrant> bigjools: Not yet, unless they were very spammy.
 * wgrant checks filters.
<bigjools> it would have been from Marianna
<bigjools> perhaps you should contact her and ask for booking agent details
<bigjools> anyway, I have a call, bbiab
<jml> will bzr-svn imports be in this rollout?
<wgrant> gmb: Intriguing. I'm trying that bug import, and it worked the first time on both my local system and an ec2 instance. But a 'make schema' and retry later, and it fails as you said...
<gmb> Oh ho... that's very weird.
<gmb> wgrant: ... And thinking about it, I didn't do a make schema before testing it on the machine where it worked.
<wgrant> gmb: Hrmhrm.
<wgrant> 'WTF' comes to mind.
<gmb> Indeed.
 * wgrant kills all clients, drops the DB, and makes schema.
<gmb> Let me just get this branch on the review queue and then I can take a proper look at this weirdness.
<wgrant> Thanks.
<wgrant> gmb: Oh. It does some crazy bug number map caching thing. That explains the issue here.
<wgrant> Once I kill that file, it works perfectly.
<gmb> wgrant: Ah, okay. What's weird is that when I encountered the problem I was running without a cache.
<gmb> Unless it creates one on the sly and doesn't tell me...
<wgrant> gmb: It does.
<gmb> Hah.
<gmb> Beautiful.
<wgrant> Make sure you get the latest version of the file, or you'll get a couple of errors.
<gmb> wgrant: Yep, I'm up-to-date there.
<gmb> Jeeesus, make schema takes ages on this machine.
 * gmb really needs something with a bit of punch
<deryck> Morning, all.
<wgrant> gmb: David and I are looking through it now, but it all seems to have worked properly.
<gmb> wgrant: Excellent. I'll move straight onto the ec2 bit then.
<gmb> Save me wasting time waiting for make schema to complete.
<wgrant> gmb: What's the purpose of the ec2 test?
<gmb> wgrant: Well, actually, that's a fair point :)
<gmb> Habit.
<gmb> Is all it is.
<gmb> wgrant: so, scratch that, I'll get it on staging today.
<wgrant> gmb: Great, thanks.
<jml> what's the correct query to do to get the current development series for Ubuntu?
<maxb> Can someone raise a LOSA? http://bazaar.launchpad.net/<anything> is broken - redirects to LP root
<mrevell> mthaddon, around? ^^^^^^
<salgado> mthaddon is on leave, and the LOSAs from the US should not be around yet
<salgado> elmo, ^
<mrevell> thanks salgado
<vila> Sorry to arrive late in the game but is there any estimate for bazaar.launchpad.net come-back ?
<maxb> We seem to be lacking in UK LOSAs. It might have to wait until the US wakes up.
<vila> maxb: thanks
 * jml posts a note to launchpadstatus
* jml changed the topic of #launchpad-dev to: HTTP access to branches is down | This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<jml> let's escalate this thing properly, eh
* maxb changed the topic of #launchpad-dev to: Loggerhead and HTTP access to branches are down | This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<vila> looks like  http://bazaar.launchpad.net is back
<matsubara> stub, Chex, gary_poster, rockstar, bigjools, danilo_, sinzui, allenap: LP production meeting in 15 min @ #launchpad-meeting
<sinzui> matsubara: Can we add an agenda item to the meeting. gary_poster, bigjools, danilos, and myself as in another meeting at the same time. It would help if the production meeting could be held an hour later
<matsubara> sinzui, sure thing. I'll add it to the proposed items section and we can discuss.
<danilos> matsubara, thanks :)
* beuno changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<jml> beuno, thanks! next time please also update identi.ca/launchpadstatus.
<beuno> jml, will do
<henninge> sinzui: ping
<sinzui> Hi henninge
<henninge> sinzui: FYI, I have a branch ready to land that adds three-column-list to style-3-0.css
<henninge> ;-)
<henninge> sinzui: first file in this mp: https://code.edge.launchpad.net/~henninge/launchpad/bug-425583-languages/+merge/15594
<sinzui> henninge: I wonder if we can use that on the root pages then remove the old 3 column markup
<henninge> sinzui: I don't see what you mean.
<henninge> two/three-column-list only works well with elements of equal height.
<sinzui> The root pages have  3 column layouts that use float right and float left
 * sinzui has a branch that removed 1100 lines from the CSS
 * henninge reviewed it (or part of it?)
<henninge> sinzui: root pages are pages like https://answers.edge.launchpad.net/ ?
<sinzui> yes
<sinzui> We never developer a 3.0 design for them
<sinzui> The tour button is 1.0
<sinzui> beuno: would prefer that the counts be higher on the page as we show on other 3.0 pages
<henninge> which counts?
<sinzui> look at the footer of that page
<henninge>  1312134 strings in 19148 translation templates
<henninge> 289 languages, 43469 translators and 32 translation groups
<henninge> oh!
<henninge> "higher on the page"
<henninge> not "counts be higher" ...
<henninge> :-D
<sinzui> English sucks
<beuno> sinzui, in what page?
<henninge> too few commas ....
<sinzui> beuno: https://answers.edge.launchpad.net/ has counts at the bottom of the page as an after thought
<sinzui> The icons are hacked in that page too, the sprite has better spacing
<beuno> argh
<beuno> https://pastebin.canonical.com/25324/
<beuno> (when hitting code.lp.net
<beuno> )
<henninge> beuno: got it too, and on translations
<beuno> sinzui, counts on those top level pages seem to be on the bottom
<sinzui> yes, 1.0 style
<beuno> sinzui, I think the counts are fine on the bottom
<sinzui> okay
<beuno> I'd like them formatted the same way as the homepage
<beuno> salgado cooked up a formatter
<asabil> hi again
<asabil> is there a list of the cron jobs that I need to have running in order to run launchpad properly ?
<mpt> beuno, hi, is there a scalable version of the PPA icon?
<beuno> mpt, hi. I think not, because it had to be pixeled in the end
<beuno> let me search though
<mpt> beuno, it would be nice if we could use it for PPAs in the Ubuntu Software Center too
<beuno> mpt, 64x64 too small?
 * beuno is pinging the designer who do it
<mpt> beuno, oh, it wasn't you?
<mpt> hm, this would require signing Canonical Contributor Agreement
<mpt> beuno, unless they have already
<beuno> mpt, I didn't do the pixel-munging, no
<beuno> mpt, we contracted out the work
<beuno> we own it
<mpt> ah, great
<mpt> anyway, I have to leave now, back in an hour or so
<mwhudson> morning
<mwhudson> jml: you around?
<bigjools> mwhudson: he's on the way to the airport
<bigjools> and morning!
<mwhudson> bigjools: hello!
<bigjools> did you read my reply to your email?
<mwhudson> bigjools: i just did
<mwhudson> bigjools: it seems i was only confusing on one minor point this time :-)
<bigjools> well that's an improvement :)
<bigjools> I have to go for food now but I'll be back later
<mwhudson> bigjools: to do with buildstate
<mwhudson> ok
<mrevell> back later to check up on the roll-out, if I can, if not see you tomorrow.
<bigjools> bbiab
<sinzui> beuno: I have a plan to give karma to all the project maintainers during my weekends this month. 1) Extend structural subscriptions to include project lifecycle event. 2) ensure that events are published, give karma for the important events
<beuno> sinzui, you have my blessing and admiration for it. Make sure you blog about it, there's quite a few project owners who feel they should be getting more karma for being the maintainer of the project
<sinzui> getting more...they get NONE
<beuno> right, so it's easy to give them more!  :)
<sinzui> I am very aware of the bug that lets someone get more karma then me when I have slaved by weekends to make a wonderful too
<beuno> sinzui, if you need any UI, let me know and I will weekend it as well
<sinzui> beuno: I may take you up on that. I need to extend the structural subscription page (which only shows bugs)...
<mwhudson> jml: jabber gave you away
<sinzui> beuno: We could do something interesting on the structural subscription page, like show that there is a notification level for bugs: Nothing, lifecycle, metadata, and comments
 * beuno looks up the current page
<mpt> beuno, any luck finding a vector PPA icon?
<beuno> mpt, it's in your inbox
<mpt> oh excellent
<mpt> thanks very much beuno
<beuno> y'er welcome mpt
<beuno> sinzui, so the current structural subscription is done via de bug index page. Would we add it on the overview as well?
<beuno> move it more towards "project subscription"?
<sinzui> beuno: intellectronica landed a nice update that ensures that the structural subscription link appears correctly for most of the objects on the over view page.
<sinzui> beuno: The edit page says, bugs, but that is a label. We set it to bugs because that is all that it shows
<sinzui> I may need to ad the link to objects that I want to subscribe to, but do not have bugs.
<bac> hi sinzui.  for the snapshot bug we've talked about product.branches.  i'm confused as to where it comes from.  it isn't in the interface and i don't think it should be in the model.  do you know anything about it?
<sinzui> bac: The problem I faced was a year ago. The attr may have been removed from the interface since then. I think I must have because private branches (branch visibility) requires a method
<sinzui> s/I think I must/I think IT must/
<bac> sinzui: i've removed it from the model and 'test -vvm lp.registry -t product' passes
<sinzui> umm
<sinzui> well
<bac> sinzui: i think it is a leftover
<sinzui> I wonder if anything uses it
<bac> sinzui: i can't find anything.
<sinzui> Nothing obviously uses it in python or template
<sinzui> bac: the only use I suspect is 'context/branches' in branch-listing.pt
<bac> sinzui: and i'll be that is an oversight
<bac> bet
<sinzui> bac: I think you are right. I do not see an tests in code for product.branches
<sinzui> I see that potemplate still thinks it has a calendar
<sinzui> Who wants to remove schoolbell and links to the calendar that was removed fore the release of 1.0
<bac> sinzui: in branch-listing.pt the context is an IBranchBatchNavigator not an IProduct, so that's not affected
<sinzui> I think then that problem has passed
<bac> great.  de-crufting now
<mpt> bigjools, I have a question about the Release files in PPA
<bigjools> mpt: shoot
<mpt> bigjools, <http://www.debian.org/doc/manuals/repository-howto/repository-howto#release> says "Label: Some label adequate for the packages or for your repository."
<mpt> bigjools, but <http://ppa.launchpad.net/yorba/ppa/ubuntu/dists/karmic/Release> for example simply has "Label: Ubuntu"
<mpt> bigjools, should it perhaps be the display name of the person/team that owns the PPA instead?
<mpt> bigjools, e.g. "Label: Yorba"
<bigjools> mpt: sorry phone went off
<bigjools> let me look
<mpt> ok
<bigjools> mpt: it could be changed I guess
<mpt> bigjools, the reason I ask is that for the Ubuntu Software Center, we want to show a nice display name for each PPA
<bigjools> heh, you're very trusting of display names set by users then :)
<mpt> bigjools, and (I'm assuming) it would be easier if we could just get that from the Release file we've already read, rather than using the Launchpad API to get the archive's display name
<mpt> but showing "Ubuntu" as the name of every PPA wouldn't be so great
<bigjools> mpt: it's a trivial change to make if that's what you want, file a bug and I'll get it sorted
<bigjools> I've seen some pretty awful display names mind
<mpt> bigjools, users need to add PPAs manually in the first place, so I don't think it's a big deal
<mpt> though I'm willing to be persuaded otherwise
<mpt> bigjools, display names of PPAs?
<bigjools> yeah
<mpt> Any examples you remember?
<bigjools> not off hand, just really short crpytic stuff
<mpt> hm
<mpt> maybe it appearing like that in the USC will be a forcing function to get them to make the names sensible
<mpt> or maybe it won't
<bigjools> https://edge.launchpad.net/ubuntu/+ppas?name_filter=
<bigjools> see there
<wgrant> bigjools: LP doesn't even suggest a possibly correct value any more.
<wgrant> So users have no idea what to put.
<bigjools> yep
<bigjools> "PPA for wangker".... awesome
<mpt> If we can't trust the display name the maintainer provides, there isn't anything else we could use, really
<bigjools> mpt: do you have plans to inclide all PPAs?
<bigjools> or only reviewed ones?
<mpt> We could use "PPA for {owner}", but that fails in the case of multiple PPAs
<mpt> bigjools, only ones the user has added.
<bigjools> mpt: heh we've been through that before, we set the title to "PPA named X for <owner>"
<wgrant> And then created keys with those names :(
<mpt> bigjools, I guess the Release Label: should actually be set to the PPA display name
<bigjools> it should be yeah
<mpt> ok, I'll report a bug for that.
<bigjools> but I think we need more than that
<bigjools> Something like Launchpad PPA "<displayname>"
<mpt> By v4, users should be getting software from PPAs without knowing either what Launchpad is or what PPAs are
<mpt> This is just a tiny step along that path, but putting either "Launchpad" or "PPA" in the display name would be something we'd eventually have to go back on I think
<mpt> However, all PPAs will have the PPA icon to distinguish them from official Ubuntu or Canonical archives
<mpt> We have "LP-PPA-" in the Origin: header
<bigjools> that's for pinning
<mpt> Well maybe, but it would also tell us that it's a PPA, even if the URL didn't
<mpt> bigjools, reported bug 492077. Thanks for your answers.
<mup> Bug #492077: Release file for PPA contains nondescript "Label: Ubuntu" <Soyuz:New> <https://launchpad.net/bugs/492077>
<bigjools> np
<mwhudson> bigjools: what build state precedes FULLYBUILT or FAILEDTOUPLOAD ? that's all i'm confused over
<bigjools> mwhudson: NEEDSBUILD
<wgrant> BUILDING, you mean?
<bigjools> err, yes :)
<bigjools> but technically I was still right :)
<wgrant> True.
<mwhudson> "immediately precedes" :)
<wgrant> bigjools: Is dogfood going to come alive again at some point?
<wgrant> Would be nice to test out the 3.0 stuff on something production-like soonish.
<bigjools> wgrant: very soon, the restore finished and subsequent upgrade is done now I looked at my screen session
<wgrant> bigjools: Ooh, finally.
<wgrant> How long did it end up taking?
<bigjools> 17 days
<wgrant> Ouuuch.
<bigjools> will be qucker next time
<bigjools> maybe a week .... :/
<bigjools> I'll remember to restore into a tmp db first so I can drop the old one and rename the restored one
<wgrant> Good idea.
<james_w> wgrant: hi. By any chance have you ever used getPublishedSources for Debian?
<ajmitch> 17 days seems to be unusably long
<bigjools> \o/ dogfood lives
<ajmitch> yay
<wgrant> james_w: I have used it occasionally, but not for anything regular.
<wgrant> james_w: Why?
<wgrant> bigjools: Excellent.
<bigjools> ajmitch: yeah there was a bug in the restore script but it will be considerably shorter next time
<james_w> wgrant: just wanted a sanity check that it actually worked :-)
<wgrant> james_w: Assuming that you're querying for stuff that gina likes, sure.
<james_w> I'm investigating why it never seems to do what it does for Ubuntu
<wgrant> bigjools: Speaking of gina, it seems to be not picking up some stuff in squeeze properly.
<bigjools>  /o\
<wgrant> It picks the same source up in sid, but doesn't catch the testing migration.
<james_w> yeah, I reassigned a bug the other day that looked like that
<wgrant> james_w: boost1.40, wasn't it?
<ajmitch> the one that I filed?
<james_w> yeah, that was it
<wgrant> Actually, I wonder if the mirror is just out of date.
<ajmitch> bug 491193
<mup> Bug #491193: Debian import of boost1.40 out of date <Launchpad itself:New> <https://launchpad.net/bugs/491193>
<wgrant> Because lots of new sid stuff isn't there either.
<bigjools> gar
<wgrant> (eg. dpkg)
<bigjools> 3.0 formats?
<ajmitch> most of this stuff isn't, I know boost1.40 isn't
<bigjools> k
<bigjools> I'll check the logs tomorrow
<bigjools> admins are a tad busy at the moment
<wgrant> Ah.
<wgrant> dpkg seems to now be 3.0, so that explains that.
<wgrant> Gaaah.
<bigjools> ?
<wgrant> dpkg >= 1.15.5 is itself 3.0 (native)
<wgrant> Already.
<wgrant> So that explains the lack of dpkg imports.
<bigjools> ha
<james_w> it ran about 5 hours ago and imported ['augeas', 'emacs-goodies-el', 'gtkhtml3.14', 'lxsession', 'mpdtoys'] apparently
<wgrant> james_w: Is anything new in squeeze, though?
<ajmitch> augeas was only uploaded to sid today, so that part is up to date
<james_w> 'xfce4-power-manager' is new in squeeze in the last 60 hours
<james_w> plus a few more
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | **Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update** PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is lo
<barry> sinzui: ping
<sinzui> hi barry
<barry> sinzui: hi.  you're going to love this.
 * sinzui waits for the message that we need to keep moderation
<barry> sinzui: bug 409588 is ready.  it's probably a substantive 20 characters or so change.  2325 line diff
<barry> sinzui: lots of deletions though
<sinzui> ha ha
<barry> sinzui: lots of test repair
<sinzui> send it to me
<barry> sinzui: you are the man
<sinzui> barry: what is the delete to add ratio?
<barry> sinzui:  22 files changed, 312 insertions(+), 1003 deletions(-)
<sinzui> \o/
<barry> sinzui: it might be a little bit before i get the merge proposal pushed.  just watch your email.
<sinzui> I am available most hours of the day
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | || Launchpad will be down/in read-only from 22:00 UTC until 23:30 UTC for a code update || PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is 
 * thumper afk for a bit
<barry> sinzui: mp send.  i hate to do this to you, but i'm away early today.  ping me tomorrow morning with any questions.  good luck!
<sinzui> barry: np
<james_w> anyone know of any changes in the way launchpadlib/wadllib handle the case of the method?
<james_w> I'm seeing caching broken, apparently because wadllib uses "return self.tag.attrib.get('name').lower()" for the method
<james_w> and httplib2 only checks against upper case method names
<james_w> so it invalidates the cache every time because the method isn't a GET
<james_w> however, I don't know why this would have changed on this machine
<james_w> because I don't think the packages have been upgraded
<sinzui> james_w: I do not see any changes for the current milestone: https://edge.launchpad.net/launchpad-foundations/+milestone/3.1.11
<sinzui> or any bugs in launchpadlib about this
<james_w> I can't work out what has changed
<james_w> I'm pretty sure the cache used to work
<sinzui> no api bugs reported in launchpad-foundations either
<sinzui> could this by a change from python 2.4 to 2.5?
<james_w> ah, good question
<wgrant> But isn't this a client-side issue?
<lifeless> no, lp is slow so a cache is a must :P
<sinzui> wgrant: I assume it should be, but the wadl is not on the client
<sinzui> so as james_w asks, maybe the wadl file changed
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | || Launchpad will be down/in read-only from 23:00 UTC until 23:45 UTC for a code update || PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
<wgrant> Uhoh.
<james_w> no, not a 2.4/2.5 issue
<james_w> this machine was always 2.5 default it seems
<james_w> so, the wadl has methods specifed as GET
<james_w> but when you use a NamedOperation it is lower cased
<ajmitch> rollout delayed again?
<james_w> this is passed down to httplib2, which doesn't uppercase it, but compares with GET
<sinzui> ajmitch: the rollout yesterday wa aborted
<ajmitch> sinzui: So I saw, what broke?
<sinzui> james_w: named ops have certainly been problematic for my work, but I do not see any changes to them recently (me watches for fixed)
<sinzui> ajmitch: The switch to read-only did not work on all machines.
<james_w> actually, I don't think it's a regression
<james_w> I think it's never worked
<james_w> I just only noticed now as I recently added a lot more code that would use operations that weren't cached
<sinzui> james_w I think  I agree.
<james_w> simple test case: http://paste.ubuntu.com/334146/
<james_w> create /tmp/cache
<james_w> run that
<lifeless> anyone around that knows how the oauth support is glued into httplib requests?
<james_w> and then you won't have a file in /tmp/cache with "ssss" in the name as you should
<lifeless> I mean, I can check the code, but pointers appreciated.
<james_w> lifeless: in launchpadlib?
<lifeless> I want to use an oauth ticket to support screen scraping a non-lp oauth protected site.
<lifeless> james_w: no
<lifeless> or rather ys
<sinzui> There may be some justification to not cache, but an explicit cached arg may help
<lifeless> yes I want to know how its glued to gether in lplib, so that I can use it from python to do non lplib things
<james_w> lifeless: class OAuthSigningHttp(RestfulHttp):
<james_w> in launchpad.py in the launchpadlib code base
<james_w> RestfulHttp is in lazr.restfulclient, it's a subclass of Http from httplib2
<james_w> overrides _request to add the signing headers, then calls the super
<sinzui> lifeless: I do not think you need lplib. It is reading you mozilla cookies and passing that info in your requests. The login is automatic if you have authenticated/set-access-privs for the script.
<lifeless> sinzui: I don't quite follow, how would python get at mozilla cookies?
<sinzui> the lib is reading your filesystem
<james_w> https://code.edge.launchpad.net/~james-w/lazr.restfulclient/fix-caching/+merge/15635
<james_w> not nice that that is the fix, but it works
 * james_w goes back to working around the issue by only ever calling each method once
 * mwhudson lunches
#launchpad-dev 2009-12-04
<wgrant> Something is broken.
<wgrant> I appear deactivated.
<wgrant> Maybe the email addresses have gone AWOL again.
<elmo> wgrant: err?
<wgrant> elmo: All LP people appear to be deactivated at the moment.
<elmo> you mean we're in read-only mode?
<wgrant> Yes, but it doesn't normally go like this.
<elmo> oh, I see what you mean
<elmo> wow that's special
<elmo> and not in a good way
<wgrant> It's not terribly surprising.
<elmo> it's not?
<flacoste> wgrant: how do you see you are deactivated?
<elmo> flacoste: you're in grey
<elmo> and go to launchpad.net/~flacoste
<wgrant> I'm grey, and my user page is blank.
<elmo> for exampel
<wgrant> As is everyone else.
<flacoste> i see
 * thumper needs food badly
<flacoste> this would point at the ValidPersonCache being screwed :-/
<mwhudson> i guess noone cares all that much right now, but 'make schema' seems screwed on devel :(
<wgrant> mwhudson: What breaks? It worked for me yesterday.
<wgrant> Hm, although that might have been db-devel. I forget which ec2 demo -t uses.
<mwhudson> wgrant: comments.sql seems to contain comments for columns that have now been deleted
<mwhudson> like build.estimated_build_duration
<mwhudson> (it's possibly some local fuckup)
 * ajmitch tries on a clean devel branch
<wgrant> mwhudson: I don't find it likely that columns have been deleted from devel lately.
<mwhudson> wgrant: you have a point there
<flacoste> mwhudson: that sounds like a build refactoring patch you and others have been working on
<ajmitch> of course, getting "not a branch" from bzr when I try rocketfuel-get isn't helping
<mwhudson> flacoste: yes, but i don't get it
<mwhudson> i'll worry about it after the current chaos is over i guess
<flacoste> ajmitch: codehosting is down
<flacoste> for the upgrade
<wgrant> Is the upgrade working a little better this time?
<ajmitch> flacoste: ok, I figured it was update-related, I was hoping it was 'normal' :)
<mwhudson> wgrant: a little
 * elmo snorts indescriminately in the background
<wgrant> The link in the read only notice points to blog.launchpad.net/maintenance, which only points to dev.launchpad.net/Maintenance, which points to identi.ca.
<wgrant> I wonder if that could be done better.
<mwhudson> ah well at least when launchpad is down i don't get so much mail
<thumper> mwhudson: haha
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | || Launchpad will be down/in read-only from 23:00 UTC until 05:00 UTC for a code update || PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only.  salgado is this cycle's RM | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
<wgrant> gmb: While the staging import wasn't a terribly good test (we've reorganised milestones and such since staging last restored), please perform the import on production when you can.
<gmb> wgrant: Will do, thanks.
<mrevell> hey
<bigjools> gmb: did you land this for jelmer? https://code.edge.launchpad.net/~jelmer/launchpad/bug390845/+merge/14924
<gmb> bigjools: No; I lost track of that one and jelmer mentioned landing it himself the other day.
<bigjools> ok
<henninge> bigjools: are you already onto the branch to fix the translations uploads?
<bigjools> henninge: I've not started it yet, but you can take over if you want? :)
<bigjools> it's a one-liner
<henninge> bigjools: you were just going to add the permission for the translationgroup table, right?
<bigjools> yep
<bigjools> for the queued user
<henninge> I'll take it. It's my code that's failing ... ;)
<henninge> bigjools: btw, are the LCA-conf attendees all booked now?
<bigjools> henninge: not at all
<henninge> bigjools: jeroen just replied from his vacation, thinking it's too late.
<bigjools> ah ok
<bigjools> henninge: for going to the daily build sprint the week before as well?
<bigjools> ah I see his email, nm
<henninge> bigjools: AFAIK he was planning to go there
<henninge> bigjools: he just sent it, so he may be at a computer now ... ;)
<deryck> Morning, all.
<bigjools> howdy deryck
<bigjools> wgrant: fyi dogfood has the backported dpkg, when the DF buildd gets fixed up as well (Tuesday) we'll be able to do some testing
<bac> morning sinzui
<sinzui> Yes it is
<bac> sinzui: i thought about the snapshot problem some more and think we made things way too complicated
<bac> what do you think about this instead?
<bac> http://pastebin.ubuntu.com/334532/
<sinzui> I would worry about this approach
<bac> sinzui: i realize we'd have to filter out form data that doesn't correspond to attributes on the object
<bac> what is your concern?
<sinzui> There are many views that update extra attributes to reconcile state. eg change A, B must be reset
<sinzui> bac: consider that when you change the status of a bug, Lots of other things change too.
<sinzui> This wont work with automated changes either. The janitor updates answer statues and send out an email that causes a change notification to go to all answer contacts
<bac> sinzui: yeah, ok.
<bac> sinzui: it just feels like we're doing too much work in the snapshot and tagging things to exclude is cumbersome.
<bac> sinzui: but i see the other approach is incorrect
<sinzui> bac: we really do not wan to exclude anything
<sinzui> we are only excluding items that we learn as an after-thought, that we do not think users want to know about in emails.
<flacoste> morning launchpadders
<bac> morning flacoste
<BjornT_> gary_poster, salgado: do we have any documentation on how to update launchpad-developer-dependencies?
<gary_poster> BjornT_: no we do not.  I have wanted that too, and I think I have been bitten by it enough to be able to write a start on the document.  We could then have salgado review (and maybe maxb too).  Do you need this now, or if I write this today would that be OK?
<salgado> BjornT_, I don't think so, but maybe maxb has written something
<maxb> yes
<maxb> dev.lp.net/LaunchpadPpa
<maxb> BjornT_: ^
<gary_poster> wow, thanks maxb!
<BjornT_> maxb: thanks!
<BjornT_> maxb: so, any documentation on how to add a new dependency, for someone who knows next to nothing about packaging? :)
<maxb> Edit the debian/control file in a hopefully fairly obvious way
<maxb> And definitely definitely take time to learn the "dch" tool for updating debian/changelog files
<BjornT_> maxb: right. i figured out i had to change control, but i didn't know how to update the changelog
<BjornT_> gary_poster, losas: btw, do you know which packages were installed in in the jscheck buildbot builder to make windmill tests runnable?
<gary_poster> BjornT_: I do not.
<EdwinGrubbs> thumper: ping
<EdwinGrubbs>  /nick Edwin-afk
<henninge> bigjools: I am not getting anywhere with the test, though.
<henninge> bigjools: as in, I cannot reproduce it.
<henninge> it = the error
<bigjools> hum
<bigjools> henninge: you're calling spr.attachTranslationsFiles ?
<henninge> bigjools: now, one further down
<henninge> TranslationImportqueue.addOrUpdateEntriesFromTarball
<bigjools> did you remove your "fix" from before and did a make schema?
<henninge> bigjools: yes
<bigjools> henninge: as user queued?
<henninge> yes
<bigjools> henninge: is it reaching the code that accesses translationgroup?
<bigjools> as per the stack trace
<henninge> bigjools: hm, need to check that ...
<henninge> bigjools: ah, prerequisite is an existing entry that is being updated
 * henninge updates test
<bigjools> ah
<bigjools> excellent, we found a buggy test :)
<sinzui> beuno: ping
<beuno> sinzui, pong
<sinzui> beuno: take a look at http://people.canonical.com/~curtis/linked-packages.png
<sinzui> beuno: I am struggling with a bug where users can create a packaging link between their project and a source package. The problem we have is that the package may only be a PPA, so it is not offically in ubuntu. We do not want to link to the ubuntu series in this case
<sinzui> beuno: I removed the link, and added a poor explanation that there is not official version
<beuno> sinzui, drop the series requirement and become a hero
<sinzui> beuno: that does not help
<bigjools> sinzui: sounds like the package vocab might be wrong when picking one?
<sinzui> beuno: We will let users link to the project, and we will select the default series.
<sinzui> no
<bigjools> it's done the other way around?
<sinzui> bigjools: This is about the project, and it may link to fedora.
<sinzui> bigjools: This picture is an extension of a branch I have that filters out the unversioned sps from lucid/+packaging
<bigjools> so you need to check that the package is published in that distro before allowing the link
<sinzui> bigjools: this picture does that
<sinzui> bigjools: the issue is communication. Why is it not linked? Th answer is that there is no version in the official archive
<sinzui> bigjools: since you are here, let's discuss a real example: https://edge.launchpad.net/gdp/+packages
<sinzui> bigjools: Soyuz built those packages. I offer them in a PPA. It would be nice to tell the users it is in a PPA, not official ubuntu
<bigjools> sinzui: so you don't want to exclude packages only in PPAs?
<sinzui> Big there two pages for two perspectives
<sinzui> bigjools: ^
<sinzui> bigjools: https://edge.launchpad.net/ubuntu/lucid/+packaging
<sinzui> ^ This MUST only show what has a version. I do that in my branch by filtering out the packagings that have no version
<bigjools> timeout ... :(
<bigjools> ouch
<sinzui> bigjools: yep, it it loading all those bogus PPA packagings
<bigjools> sinzui: you need to join to a SPPH and Archive with the right purpose
<bigjools> sinzui: see Distribution.getCurrentSourceReleases for example
<sinzui> bigjools: https://edge.launchpad.net/gdp/+packages
<sinzui> ^ shows where my project is package for all distributions. It just so happens that I only make ubuntu packages. Someone can make a fedora RPM and link it on launchpad.
<bigjools> and that page can see PPA packages too?
<sinzui> bigjools: I think the error is in distroseries. Distroseries.packagings returns all packagings is disregard to SPPH
<bigjools> yeah that looks horribly fuct
<bigjools> it begs the question though
<sinzui> bigjools: I would like to know how to see PPAs, or at least point the user how to find the PPA.
<bigjools> how did a Packaging row get made for a package inly in a PPA?
<bigjools> only*
<sinzui> That is very easy
<sinzui> I keep saying it too. anyone can create a link beween an project and an SP in ANY distribution because Launchpad wants to model everything
<bigjools> ok well you can fix that property easily
<sinzui> bigjools: I do not think it is broken
<bigjools> assuming you only want to return packages published in the same series in the main archive?
<bigjools> what do you want it to do?
<sinzui> bigjools: yes, that is what my disrtoseries + packaging changes do...and our sample data is so bad it actually behaves like the bad data in production...easy to test \o/
<bigjools> you said " I think the error is in distroseries. Distroseries.packagings..."
<bigjools> heh
<sinzui> bigjools: yes, that is where I am fixing the issue
<sinzui> but thera are  *two* perspectives. the lucid perspective is easy to fix
<bigjools> how did you fix it?
<bigjools> right, you want to see distro and PPA packages separately, or at least identify the difference?
<sinzui> do not show unpublished source packages. I know that because the packagings has not currentrelease
<bigjools> so you join to SPPH with status in (1,2)
<henninge> bigjools: interesting, I get more "perission denied" errors now ... translationgroup has not yet been among them.
<bigjools> (pending, published)
<sinzui> for the project someone might has an archive with fedora, suse, and ubuntu pacckages, so users add a link. I believe you can see that same action on my gdp/+packages page.
<bigjools> henninge: that is worrying, it sounds like the publisher can go bang any any minute
<sinzui> bigjools: I will update the query
<bigjools> sinzui: if you're filtering on published packages it will never show links to non-ubuntu distros
<sinzui> bigjools: you are singlelu thinking of lucid, that is not an issue. it is easy to solve.
<sinzui> bigjools: the issue is the project. you have its own list,
<sinzui> bigjools: it has it's own list
 * bigjools is getting more confused
<bigjools> all I am saying is that if you add the fix you just suggested, you won't see anything for Fedora etc
<bigjools> but I am not sure I really understand your problem now!
<sinzui> bigjools: That is not so, because the fix for the distroseries -> packagings will not affect a project. You are, you need to remember that project -> series -> packagings is a legitmate relationship, We do not know what is in fedora, so we believe the user when he tells us that
<sinzui> In the example we are talking about, I know the package is in a PPA, and i wonder if it is possible for me it identify that and link to the ppa's info instead of the distroseries's official SP.
<bigjools> the gdp example?
<sinzui> It happens to be one that I know has package built in the last week
<bigjools> see Archive.getPublishedSources()
<bigjools> you can't re-use it as it is, but you can adapt its query to check all PPAs to see where something is published
<sinzui> that may help
<bigjools> actually
<bigjools> noodles775: which query is the PPA search using at the bottom of the DSP page?
<bigjools> sinzui: DSP.findRelatedArchives()
<noodles775> Sorry, yes.
<henninge> bigjools: ok, now I did reproduce the error. Had the wrong line commented out in security.cfg ... :(
<sinzui> that look very helpful
<bigjools> noodles775: np I was being lazy :)
<bigjools> henninge: !
<adiroiban> danilo__: can you please take a look at bug 491454. If its valid, I would like to look at it durring this weekend
<mup> Bug #491454: Search English string on entire Project / DistroSeries <search> <Launchpad Translations:New> <https://launchpad.net/bugs/491454>
<danilos> adiroiban, it's a valid use case, but it's harder than you might think: just a single series is probably much easier, but the main problem is dealing with performance
<adiroiban> danilos: i think,a single series would solve 90% of ubuntu translation needs regarding searching for english strings
<adiroiban> danilos: in most cases they know in what Ubuntu version they should look for a string
<adiroiban> no need to have a search in all active series
<danilos> adiroiban, I agree, it's still not trivial for performance reasons
<adiroiban> danilos: ok. thanks!
<danilos> adiroiban, in general, the only complication is figuring out right SQL; I do have a few ideas on how that would work, but basically, you'd have to test it with our data set (i.e. millions of rows in postgres)
<adiroiban> danilos: or with my 5 years old computer
<danilos> adiroiban, well, the other complication is how to come up with a good UI that will clearly explain that you are searching only through English and that it's impossible to search for non-English
<danilos> adiroiban, believe me, it's not the same :)
<adiroiban> danilos: you are saying it is very hard to reproduce the production installation on my computer?
<adiroiban> or that it is not possible :)
<danilos> adiroiban, yeah, it is... basically, the tests I did were on staging, which relatively closely resembles production databases, and I was able to get decent performance out of it
<adiroiban> danilos: ok. np. I will look into other bugs
<danilos> adiroiban, however, with postgres, it depends on a lot of other things as well, and ultimately, one can probably solve it with right partial indexes and full text search, but it's still requires a lot of testing to make sure it works
<danilos> adiroiban, sure, thanks... I can probably be convinced to look into it myself, but as I said, it's mostly about coming up with queries and decent performance in actual circumstances :)
<adiroiban> danilos: ok. I only took a brief picture of rosetta db ... i don't know if msgstr table is partitioned based on langauage
<danilos> adiroiban, it's not, and even if it was, you'd soon run into a postgres issue where it doesn't really choose optimal query plans even with partial indexes :)
<danilos> adiroiban, i.e. it does a sequential scan of the entire table first anyway if you are using (I)LIKE for matching
<adiroiban> danilos: i was hopping you can limit somehow the scan on only one table
<danilos> adiroiban, yeah, but it's not partitioned, and that's what partial indexes should be for, but it doesn't really work like that with postgres and large tables
<adiroiban> danilos: and partitioning  now would break any functionality  ?
<danilos> adiroiban, no, if done properly, it's just a lot of work
<danilos> adiroiban, one of the things is that there are many messages which are used in different languages (i.e. potranslation table contains only unique strings)
<adiroiban> ok. thanks.
<adiroiban> I will leave it for the future...
<danilos> adiroiban, if you want to take on that, I'd be happy to talk about it anytime and direct you exactly where to look
<adiroiban> danilos: yep. I still need to read about postresq... but if partial index are not working
<adiroiban> i think that in the long term, partitioning is a must.. and I will try to look into it
<danilos> adiroiban, oh, they are working, but not sufficiently well with like searches; it works better with FTS, but that increases the amount of data we store
<danilos> adiroiban, oh, indeed, that was part of the initial plans for implementing search as well, and the bug you filed was supposed to be the very next step, but we just never got to it :)
<adiroiban> danilos: thanks for all the details. I have to go now. cheers
<danilos> adiroiban, cheers
<danilos> adiroiban, btw, we should exchange our photos from UDS :)
<sinzui> bac: is pqm open?
<bac> sinzui: not yet.  mbarnett is going to do it soon.
<sinzui> bac: how did you manage this: https://edge.launchpad.net/launchpad-foundations/+milestone/3.1.12
 * sinzui has a lot of branches to land
<bac> sinzui: lazr.lifecycle does not go through PQM
<bac> sinzui: i merely pushed the fix up to the team branch
<sinzui> bac: https://edge.launchpad.net/lazr.lifecycle is launchpad-foundations
<bac> sinzui: i don't understand your point
<sinzui> bac: change the project from launchpad-foundations to lazr.lifecycle
<bac> https://code.edge.launchpad.net/~lazr-developers/lazr.lifecycle/trunk
<bac> ah, i see
<sinzui> I was ever so hopeful I could land my branches
<sinzui> bac: do we need that egg to to appear if rocketfuel before you can land the registry fix?
<bac> sinzui: i will push download-cache (thanks for the reminder!) before landing the branch
<sinzui> oh good, now i know the secret
<bac> sinzui: doc/buildout.txt is helpful
<bac> sinzui: even more so are the notes i took when gary_poster walked me through a change to lplib
<gary_poster> improvements to the shared instructions would be greatly appreciated.  What I wrote in doc/buildout.txt has made some happy; others, not so much.
<gary_poster> Myabe there should be different instructions for different...uh, kinds of thinkers?  Something.
<bac> sinzui, gary_poster: http://pastebin.ubuntu.com/334689/
<bac> sweet and simple
<bac> chopped from my history file, i think
<gary_poster> bac: Cool, thanks.  Maybe I should muck with it and put it somewhere, like on the dev wiki.  That's good for local changes.  It doesn't Do The Right Thing for actually releasing a dist for others...but I honestly am not sure how to do that myself (I know how to use pypi, which is easy, but we have a launchpadlib script to release across pypi and launchpad, which didn't work last time I checked).
<gary_poster> Leonard has some instructions for that on the wiki that I haven't tried lately (and things should be fixed now).
<gary_poster> bac: I'll put it on the dev wiki today
<bac> gary_poster: great, thanks
<bac> gary_poster: who actually "releases" lazr packages?
<gary_poster> anybody who has pypi privs to do so for the given package
<bac> gary_poster: for instance, i made those changes to lazr.lifecycle sufficient enough to support LP
<bac> but i didn't create a release, do the pypi bits, etc
<bac> should i request a release be packaged up or just wait for someone to notice?
<bac> or not worry since it is not a huge change
<gary_poster> bac: in a perfect world, you would do it.  In that perfect world, you would have a PyPI account, and the tools would exist to make releasing that a single line command.  That perfect world *almost* exists except (1) I don't know if you have a PyPI command and (2) to my knowledge Leonard is the only one who has used the wonderful on-line command that does all the PyPI and Launchpad stuff, and I don't want to make you do it if
<gary_poster> it works. So...
<gary_poster> bac: send me an email :-/ <shrug> :-)
<bac> ok
<EdwinGrubbs> sinzui: I know we talked about bug 67909 a while back, but I can't remember the details. The dates on the series definitely look wrong.
<mup> Bug #67909: product release finder set all release dates to 23/10/2006 <prf> <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/67909>
<sinzui> EdwinGrubbs: The finder is creating a milestone and a release and setting the value to something. The question really is "How do we know the true date that something was releases?" There is nothing in a file name that says that. We know "now'" is definitely wrong
<sinzui> EdwinGrubbs: I is may be possible to use the mod/create date fromt he remove file system. We need to change the finder rules to get a date with the listing. That is hard. doable, but always unreliable
<sinzui> EdwinGrubbs: We ultimately expect upstream adopters to fix this. They do not. They are happy to let the finder download 500 released for a single series.
<sinzui> EdwinGrubbs: Maybe the answer is to explore not having dates at all.
<EdwinGrubbs> sinzui: should I unassign myself from it? It doesn't sound like you really want me to work on it.
<sinzui> kiko:  reopened it, you were still assigned
<sinzui> EdwinGrubbs: unassign your self. It is not important because it is not targeted to a milestone
<sinzui> EdwinGrubbs: since we cannot commit to fixing the issue, the bug is thus low
<EdwinGrubbs> ok, cool
<bac> salgado: will you update the topic here when PQM opens?
<salgado> yep
<bac> thanks
<kiko> sinzui, so we can't use the file mod date from the listing? why? parsing unreliability?
<sinzui> salgado: I assume we are not doing a reroll.
<sinzui> kiko: the listing is a HTML page that may be formatted in many ways. We can guess
<salgado> sinzui, correct
<sinzui> fab. time to release some projects
<kiko> sinzui, pity
* salgado changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is closed; for RC only | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
* mbarnett changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.11 | PQM is open for srs bsns | I am Zero OOPS and So Can You! http://is.gd/4fkLl |   https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is
<adiroiban> is there a config option in LP to enable listing in terminal of strom SQL queries?
<sinzui> no, but I know you can enable postgress and or storm to log.
<sinzui> I do not know how to do that though
<adiroiban> thanks. there are some tips here https://storm.canonical.com/Tutorial#Debugging ... I think I can use them and enable debugging
#launchpad-dev 2009-12-05
<adiroiban> when using context/@@+fragment, is there a nice way to pass GET or POST variables to +fragment ?
<sinzui> adiroiban: we often add a initial_values property to the view that will provide a dict of sane values for the missing parameters
 * sinzui looks for example
<sinzui> adiroiban: LaunchpadFormView sets the missing params from the initial_values dict as is done in lp/registry/browser/announcement.py
<adiroiban> sinzui: thanks. I'll take a look
<adiroiban> sinzui: the current view is just a LaunchpadView. I have something realy simple, and I don't want to make it a LaunchpadFormView just for sending one GET variable
<adiroiban> i want to call https://translations.launchpad.dev/ubuntu/hoary/+translations?something
<adiroiban> and have "something" also visible in https://translations.launchpad.dev/ubuntu/hoary/+langchart
<sinzui> adiroiban: I would redefine the views __init__ to call initial_values  and have it inject the values into  view.request.form
 * sinzui wonders if that has been done before
<adiroiban> sinzui: I will try
<adiroiban> :)
<sinzui> adiroiban: there are several places where views are doing something like
<sinzui>     self.request.form['displayname'] = my_value
<sinzui> to ensure sane data is in the request before a redirect or some handoff to another process. I think doing this in an __init__ is okay.
<adiroiban> ok. I'll try and see what I can get
<sinzui> adiroiban: I think you want to check the form using this style:
<sinzui>    if request.form.get('something', None) is None:
<sinzui>         request.form['something'] = 'sane default'
<adiroiban> i'm still learning zope and lp... so I don't know if I should pass some flag over HTTP get or encode it in the url
<adiroiban> also I still need to read about the lifecycle/lifetime of a zope view component
<sinzui> adiroiban: I do not think zope will help you since we are using LaunchpadView and LaunchpadFormView
<sinzui> adiroiban: Those views in lib/canonical/launchpad/webapp define all the objects commonly available, the order they are gotten, and process the form data and do validation
<sinzui> adiroiban: The only zope knowledge I need to know is zope.formlib when I am doing something very strange in setupFields or setupWidgets. We have some many examples in views now that I do not think you need to learn that from Zope.
<adiroiban> sinzui: thanks.
<adiroiban> right now I'm trying to so simple things ... but then I still need to learn the LP way of doing things
<adiroiban> so I have this page: https://translations.launchpad.dev/ubuntu/hoary/+translations?all=yes
<adiroiban> which has an included fragment
<sinzui> adiroiban: the general execution path is View __init__ (we  rarely mess with this, but I think you want to in this case) -> initialize (setup form stuff) -> setupFields -> setupWidgets() -> validate -> Actions -> render()
<adiroiban> and I want to see the "all=yes" value in the fragment
<sinzui> adiroiban: Something like this I think:
<sinzui>     def __init__(self, context, request):
<sinzui>         super(MYVIEW, self).__init__(context, request)
<sinzui>         # This view may be included as a portlet using default values.
<sinzui>         if self.request.form.get('all', None) is None:
<sinzui>             request.form['all'] = 'yes'
<adiroiban> ok. but in my particular case. I have the same view for the main page and the portlet page ...
<adiroiban> does it mean I have to slit them in different views?
<sinzui> adiroiban: You could subclass to have different behaviours, but I think this is a case where the view should do the right thing for default and query cases
<sinzui> Since setting the form in __init__ is extraordinary, we need a comment to explain that the view is used as a portlet.
<adiroiban> sinzui: think I still need to read more as I have no idea when the __init__ or LaunchpadView.initialize() is called
<sinzui> init is called when the object is created...it is the constructor
<adiroiban> and when is that . Each time I'm accessing the specific URL ?
<sinzui> Yes, each time. All objects are garbage collected at the end of the request.
<adiroiban> and if I have something like this: <div tal:replace="structure view/translation_focus/@@+langchart" />
<adiroiban> it will not create a new request for that inclusion ?
<sinzui> That is right
<adiroiban> then I can no use that trick
<sinzui> The that syntax means: Lookup and execute the adapter for translation_focus (a series) named +langchart
<sinzui> adiroiban: why do you need a new request?
<adiroiban> sinzui: I don't need a new request.
<adiroiban> i have distroseries/+translate page
<adiroiban> that "includes" the +langchart page
<adiroiban> now I'm calling +translate?all=yes
<adiroiban> and I want that "all=yes" to be propagated to +langchart
<sinzui> ah
<sinzui> that is extraordinary
<adiroiban> maybe this is not the right way to do it
<sinzui> So you are not seeing the form when the +langchart is called?
<adiroiban> if it's from +translations , no
<adiroiban> direct access is OK
<adiroiban> direct - hacking the URL
<sinzui> I think you want to subclass the view then and set the all=yes as I suggested
<sinzui> you want to register the new view as a new name in browser/configure.zcml.
<sinzui>         <browser:page
<adiroiban> yep. I can have +translations and +translations-all
<sinzui>             for="lp.registry.interfaces.distroseries.IDistroSeries"
<sinzui>             class="lp.translations.browser.distroseries.AllLangsView"
<sinzui>             name="+alllangchart"
<sinzui>             template="../templates/distroseries-langchart.pt"/>
<adiroiban> or +langchart-all ;)
<adiroiban> so basically, there is no way to pass a HTTP or TAL "variable" to a fragment page?
<adiroiban> and the only way is to create a new view ?
<sinzui> There is, by way of define a metal macro instead of adapting to a view
<adiroiban> then maybe it is best to use a macro?
<sinzui> You would need to rewite the existing template to use the macro. I think that is more work then subclassing and registering
<adiroiban> sinzui: thanks for the help!
<adiroiban> so to finalize. there is no easy way for something like this: <div tal:replace="structure view/translation_focus/@@+langchart?all=yes" />
<adiroiban> easy, trivial
<sinzui> I do not think so
<adiroiban> the @@+fragment way of include is specific to Zope , or is a LP TALES extension?
<sinzui> It is TALES, which is neither zope or lp
<adiroiban> :)
<sinzui> Here is a quick reference I often use. http://www.owlfish.com/software/simpleTAL/tal-guide.html
<sinzui> TALES and METAL are associated with zope, but the engine is not specific to zope any more
<adiroiban> well. I will go with the sollution where multiple views are created and I will see what is the feedback from the reviewer :)
#launchpad-dev 2009-12-06
<mwhudson> happy new wekk, #launchpad-dev
<ajmitch> yay, monday?
<thumper> morning
<mwhudson> jelmer: https://code.edge.launchpad.net/~samba-team/samba/trunk <- you fixed this bug in bzr-git trunk already didn't you?
<matgeek> thumper: Matthew here.  It would be good to meet sometime before Xmas.
<mwhudson> code team lpnet errors for 2009-12-05 00:00:00
<thumper> matgeek: yeah, sure
<mwhudson> looks a lot like a checkwatches oops report
<thumper> mwhudson: yeah, I emailed matsubara about it :)
<thumper> mwhudson: ready for a call?
<mwhudson> thumper: one sec
<matgeek> thumper: Could I please phone you?
<mwhudson> thumper: ready when you are?
<jml> good morning Launchpadders
<wgrant> jml: You're back on the right side of the world again?
<jml> indeed I am
<jml> wgrant, in fact, I am southier than you are
<wgrant> jml: Aha.
<jml> (although not as far south as thumper, who is southest)
<ajmitch> not really much to the south of here, really
<jml> ajmitch, there's Invercargill
<jml> ajmitch, and Gorrrrrrrrrrre
<ajmitch> again, not really much to the south of here, really :)
<jml> heh heh
<jml> do you want to know one of the best things about working in Australia?
<jml> less than 20 emails on Monday morning
<ajmitch> and friday comes around sooner than for most
<maxb> wgrant: I've just updated my first machine to lucid, I expect I'll be joining with you in filling the PPA soonish :-)
<wgrant> maxb: It works fine, except for the setuptools issue.
<wgrant> maxb: And I need to retry bootstrapping now that I know how to fix that.
<thumper> mwhudson: http://christophe.delord.free.fr/tpg/
<jml> thumper, good morning.
<thumper> jml: morning
<maxb> wgrant: What pulls in the need for egenix-mx-base ?
<wgrant> maxb: psycopg2
<wgrant> maxb: It specifically wants mxdatetime.
<mwhudson> how quaint
<maxb> lack-of-dependency suckage :-(
<maxb> wgrant: I've copied the full content of wgrant/launchpad to launchpad/ppa, and am proceding with a rebuild of pysvn targetted at launchpad/ppa
<wgrant> maxb: Thanks.
<wgrant> I haven't run the full test suite, but at least 'make run' and Soyuz stuff works.
<maxb> or at least, I will be, once I manage to get the builddeps installed for a test build locally
<wgrant> Hopefully there will be no crazily obscure issues like there were for Karmic.
<jml> mwhudson, hello to you also
<mwhudson> jml: hello
<mwhudson> oh man, pysvn is made of sad
<wgrant> mwhudson: It sucks.
<wgrant> Particularly when you have to grep through svn source to work out what the numeric error codes mean... aarrrrrrrgh
<mwhudson> jml: how was your trip?
<jml> mwhudson, economical.
<mwhudson> jml: heh
<mwhudson> jml: we should talk at some point i think, but possibly not right now
<jml> mwhudson, ok
<jml> mwhudson, I'll be unavailable from 12-1 your time
<jml> mwhudson, but other than that, should be good.
<mwhudson> jml: after that then maybe?
<jml> mwhudson, yeah, that'll work.
<mwhudson> cool
<jml> mwhudson, I'm still resolving lunch plans with a plan-allergic friend
<maxb> Oh, *gah*. pysvn is the hard one
<jml> mwhudson, but sucks to him for not promises
<wgrant> maxb: What's wrong with it?
<mwhudson> so, random ubuntu user question: there is a thing (gnome-gpg?) that remembers my gpg passphrase for a while
<maxb> it's the one I had to do sourceful changes to
<mwhudson> how do i control how long it remembers it for?
<wgrant> mwhudson: Probably seahorse.
<mwhudson> jml: well, i have no plans for today, so "sometime later" is perfectly fine
<jml> mwhudson, cool.
<wgrant> mwhudson: System->Preferences->Encryption and Keyrings, PGP Passphrases tab.
<mwhudson> wgrant: i don't have "Encryption and Keyrings" :(
<wgrant> mwhudson: Tried running seahorse-preferences?
<mwhudson> not installed, it seems...
<wgrant> mwhudson: Maybe it's not seahorse-agent that you're using, then.
<ajmitch> encryption & preferences is most likely installed by default on karmic
<mwhudson> mm
<ajmitch> or maybe it's a holdover from the jaunty upgrade
<mwhudson> i lost something in this area on the upgrade from jaunty
<wgrant> mwhudson: Are there any *-agent processes running?
<mwhudson> anyway, seahorse-plugins is now installed, we'll see what happens next time i log out i guess...
<mwhudson> wgrant: gpg-agent is running
<wgrant> mwhudson: Ah.
<wgrant> Not sure about how to configure that one.
<mwhudson> ah well, need to reboot after a kernel update anyway
<mwhudson> brb
<jml> organizing documents is hard.
<lifeless> amen
<lifeless> so we shouldn't do it
<jml> I think I spot a flaw in your logic.
<wgrant> There were reports of the weekend of some even less desirable users.
<wgrant> s/of/over/
<wgrant> I believe feedback@ was emailed about them, but I'm not sure.
<wgrant> eg https://edge.launchpad.net/~staiaheat
<lifeless> jml: logic?
<lifeless> muhahaha
<thumper> mwhudson: I've created lp.code.errors
<mwhudson> thumper: woo
<thumper> mwhudson: I've only put in the bmp ones for now
<thumper> mwhudson: there is a little fallout
<thumper> mwhudson: but not too much
<mwhudson> thumper: yeah, doing it gradually makes sesne
<jml> thumper, yay
<thumper> I'd like to have things alphabetically where it makes sense
<thumper> but we have one case of a subclass
<thumper> and that makes it look less pretty
<thumper> :(
<jelmer> mwhudson, hey
<jelmer> mwhudson, yeah, that should be fixed in trunk
<mwhudson> jelmer: hi
<mwhudson> jelmer: do you want to work on getting the fix into launchpad?
<mwhudson> it needs to be pqm-submit-ed to ~launchpad-pqm/bzr-git/trunk and then a change to utilities/sourcedeps.conf landed on launchpad
<mwhudson> jelmer: how many imports will this affect, do you think we should cherry pick it?
<mwhudson> (bearing in mind this is only a two week long cycle)
<jelmer> mwhudson: Yeah, it would help for other things as well
<jelmer> mwhudson: I wasn't aware that being a launchpad team member implied having to do work :-)
<mwhudson> jelmer: it doesn'
<mwhudson> t, i can do it too
<mwhudson> but i wouldn't mind you suffering a little for bzr-git bugs i guess :-)
<jelmer> >-)
<jelmer> before when is this due?
<thumper> jelmer: last thursday :)
<mwhudson> lol
<maxb> 16 hour build queue on the PPAs !
<maxb> ouch
<maxb> guess we're not getting our lucidized pysvn tonight
<wgrant> jelmer could have rescored it :(
<maxb> jelmer: Do you suppose you could rescore the pending builds in https://edge.launchpad.net/~launchpad/+archive/ppa/+packages ?
<maxb> pysvn/{i386,amd64}
 * maxb afk ---> drive to London
<thumper> is that an abuse of power?
<maxb> well, slightly :-)
<jelmer> maxb: Sorry perhaps after I'm more familiar with the system
<jelmer> thumper: Ah, hmm
<thumper> jml: when you first write the "land" command for our ec2 util script I thought it was stupid
<thumper> jml: and now I use it every day
<thumper> (almost0
<jml> thumper, thank you, I guess :)
<thumper> jml: thanks for writing it, it makes things less error prone
<thumper> jml: like landing onto devel vs db-devel et al
 * jml afk for a bit
<mwhudson> what is bug q&a ?
 * thumper shrugs
<thumper> questions and answers?
 * mwhudson lunches
<poolie> hello thumper, mwhudson
<thumper> hi poolie
<spm> maxb: power abused. rescored.
<thumper> hmm....
<thumper> I wonder what would happen if LP got an email from a team email address
 * thumper looks at the code
#launchpad-dev 2010-12-06
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      296 / 6927  Archive:+index
<lifeless>       83 /  377  BugTask:+index
<lifeless>       43 /  169  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       22 /  261  Distribution:+bugs
<lifeless>       12 /   29  Archive:+copy-packages
<lifeless>       10 /  344  POFile:+translate
<lifeless>       10 /   27  MailingListApplication:MailingListAPIView
<lifeless>        9 /   34  DistroSeries:+queue
<lifeless>        8 /   29  Milestone:+index
<lifeless>        8 /   11  DistroSeriesLanguage:+index
<wgrant> lifeless: Do you have a +copy-packages OOPS? Is it repeated DistroArchSeries queries again?
<wgrant> Repeated DistroArchSeries and Archive queries, inf act.
<wgrant> (wow, that is a lot of Archive:+index soft timeouts. I wouldn't have guessed that it had that many hits)
<lifeless> wgrant: this is why I worry :)
<wgrant> lifeless: If you'd let PQM be taken out of RC earlier, it would be fixed by now :P
<wgrant> lifeless: Could you check a +copy-packages OOPS? I think it's the same issue as +queue -- SPR.getBuildByArch being awful.
<lifeless> wgrant: I'm on leave, nutting to do with me ;)
<wgrant> Pfft.
<lifeless> Archive:+index 20753
<lifeless> 99% under 15.84
<wgrant> Ow.
<lifeless> wgrant: I do
<lifeless> wgrant: https://bugs.launchpad.net/soyuz/+bug/575450
<_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts <ppa> <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/575450>
<wgrant> lifeless: Wow, those are really awful queries.
<lifeless> tada
<wgrant> Not what I thought it would be.
<wgrant> Thanks.
<lifeless> and 150 noddy repeats
<wgrant> Those are hopefully fixed by my Archive:+index branch.
<wgrant> But they will probably reveal more.
<lifeless> sure
<lifeless> a query scaling test for copy-packages would be nice
<wgrant> But by that point I probably won't have to pester you.
<wgrant> Yeah.
<wgrant> But it's so awful at the moment that it's pointless to test.
<lifeless> https://launchpad.net/ubuntu/+archive/primary/+copy-packages
<lifeless> looks similar to me
<lifeless> wgrant: its never pointless to stop the erosion
<wgrant> lifeless: Pointless? No. Depressing and embarrassing? Definitely.
<wgrant> lifeless: I think we need to segregate OOPSes by HTTP method.
<wgrant> Looking at that +copy-packages OOPS again, it's a GET, not a POST.
<wgrant> So it's just batchnavigator's COUNTing stupidity.
<lifeless> wgrant: file a bug on oops-tools, I think that that is a good, valid, heuristic.
<wgrant> lifeless: k, thanks.
<wgrant> lifeless: How are we going to fix batchnavigator? Can we get postgres to give us an estimate?
<lifeless> broadly
<lifeless> a) there is an estimator in the code base already
<lifeless> b) we don't want to pass storm result sets outside the persistence layer anyway
<lifeless> c) while counting can be slow, we should be able to do better than 3 seconds
<lifeless> \o/ parallel testing for testr
<lifeless> about 0.3 seconds (25%) off of the time to test testtools.
<wgrant> I love well-designed tests.
<lifeless> wgrant: did you file that bug about presentation of the 'Ubuntu also tracks bugs for packages derived from this project: bzr in ubuntu.' links ?
<wgrant> lifeless: I didn't.
<wgrant> I feel like I should talk to someone first.
<lifeless> thats a mispattern
<lifeless> I'm sure you can point out that the current approach doesn't scale to even just the distros hosted in LP>
<lifeless> the mispattern is needing discussion *before* creating a place to talk about the issues
<wgrant> Well, It is tempting to at least raise it with Curtis first.
<lifeless> its been 1? 2? weeks.
<lifeless> I call timeout
<lifeless> (the timeout should be ~ 5 minutes)
<wgrant> Wellll, I forgot.
<lifeless> wgrant: exactly
<wgrant> You are on leave; you cannot call timeout :P
<lifeless> can too; nyarh nyarh nyarh
<jelmer> mÃ¸rning lifeless, wgrant
<lifeless> Ã¸?
<wgrant> Evening jelmer.
<jelmer> I'm feeling creative this morning.
<wgrant> My compose key is sadly broken :(
<lifeless> Ã¶
<wgrant> ThÃ©re wÃ« go.
<jelmer> wgrant: do you need one for Strine?
<wgrant> jelmer: Apparently.
<adeuring> ood morning
<al-maisan> moin adeuring :)
<adeuring> hey al-maisan!
<lifeless> wgrant: btw, how many cpus do you have?
<wgrant> lifeless: 6 cores.
<wgrant> Morning adeuring, al-maisan.
<lifeless> wgrant: you might want to try glueing latest testr to running lp tests in vm's.
<lifeless> (one vm per test command invocation)
<al-maisan> hello wgrant, how are things?
<lifeless> wgrant: (if you want 6 way concurrency in an lp test run)
<wgrant> al-maisan: Pretty good.
<wgrant> Enjoying my final week of freedom.
<al-maisan> :)
<al-maisan> there are some pretty interesting discussions going on re soyuz :)
<wgrant> You could say that.
<StevenK> wgrant: Yeah, right. You're spending it working on Launchpad
<wgrant> StevenK: Says he who is on leave but present...
<lifeless> StevenK: if you love your job, you never need to work :)
<StevenK> I'm too attached to IRC to /quit
<al-maisan> true .. but also slightly dangerous ;)
 * StevenK is going to spend some time this work working on Hudson
 * jelmer waves to StevenK, al-maisan, adeuring
<StevenK> jelmer: O hai!
 * al-maisan waves back :)
<wgrant> lifeless: Is there any documentation on the testr parallelisation functionality?
<wgrant> Test runs in half an hour would be pretty cool.
<lifeless> wgrant: MANUAL.txt
<lifeless> wgrant: testr run --help
<lifeless> wgrant: NEWS
<wgrant> lifeless: I suppose I'll need a very recent (!)release?
<lifeless> tip
<wgrant> k
<lifeless> its not finalised
<mwhudson_> morning jelmer
<lifeless> I may tweak the config if it doesn't fit well with our needs here
<jelmer> hey Michael
<jelmer> mwhudson_: Thanks for landing that C introspection branch :-)
<wgrant> Bah, fixtures isn't packaged :(
<jelmer> wgrant: it is in the testing-cabal PPA
<wgrant> jelmer: Perfect, thanks.
<mwhudson_> jelmer: thanks for the prods
<jelmer> wgrant: ppa:testing-cabal/archive
<lifeless> tip testr is in that ppa too
<lifeless> wgrant: its also in Debian.
<wgrant> Maybe I should go back to unstable for a while.
<lifeless> or natty
<wgrant> I trust unstable more.
<lifeless> unstable is ~frozen
<wgrant> But it doesn't have Unity rewrite crack :)
<wgrant> Anyway.
 * wgrant investigates testr --parallel
<al-maisan> wgrant: you can use natty with the normal gnome desktop as well
<wgrant> But NM doesn't seem to really work :/
<StevenK> lifeless: Off the top of your head, will the Hudson EC2 plugin just deal with and mount an EBS volume, or does that require changes? I can't find much TFM to R
<lifeless> should just work
<lifeless> ^-WAG
<bigjools> morning
<wgrant> Morning bigjools.
<bigjools> inbox most definitely not zero today
<wgrant> I should clean up mine this week.
<wgrant> Because I guess I will acquire a new problematic one soon.
<wgrant> :(
<mwhudson_> i had a soul-crushing amount of email this morning
<bigjools> wgrant: you already subscribe to bugmail, that forms 80% of mine
<bigjools> then the oops reports
<bigjools> then warthogs on a bad day :)
<wgrant> bigjools: There's a lot of bugmail, sure, but it's nice and quick to get through.
<bigjools> hahaha
<mrevell> Hello
<bigjools> g'day mrevell
<thumper> wgrant: just one week to go :)
<thumper> mwhudson_: yeah, saw your tweet
 * thumper goes to make a cuppa tea
<thumper> hi mrevell
 * thumper waves at StevenK
 * thumper thinks that is everyone now
<mrevell> haha
<mrevell> Good work thumper
<wgrant> thumper: Indeed!
 * bigjools pouts
<wgrant> Uhoh.
<bigjools> wgrant: https://bugs.launchpad.net/soyuz/+bug/685076
<_mup_> Bug #685076: PPA deletion leaves unremoved publications <Soyuz:New> <https://launchpad.net/bugs/685076>
<bigjools> ARGH.
<wgrant> bigjools: How is that ARGH-worthy?
<bigjools> because I overlooked it
<wgrant> Heh.
<bigjools> there's a pheasant outside my window.  Pie anyone?
<lifeless> mmm
<lifeless> PIE
<bigjools> :D
<bigjools> wgrant: so all these bugs you're filing!
<bigjools> shall I just assign you to them now? :)
<wgrant> Maybe.
<bigjools> wgrant: I am not clearly following the timeline you wrote in bug 682692.  Could be my lack of caffeine though.
<_mup_> Bug #682692: Some PPAs have duplicated builds <soyuz-build> <soyuz-publisher> <Soyuz:Triaged> <https://launchpad.net/bugs/682692>
<wgrant> bigjools: What's ununderstandable?
<bigjools> I am having trouble understanding where the problem is in that example timeline
<wgrant> bigjools: The first copy was deleted 18 seconds before the second copy was performed.
<wgrant> So the status summary returned FULLYBUILT instead of FULLYBUILT_PENDING, so the copy was permitted with unpublished builds.
<bigjools> wgrant: can you condense that comment into a simple instruction to re-create the bug?
<bigjools> it will double as a QA test when we fix it
<bigjools> congrats on figuring it out
<wgrant> bigjools: Done.
<bigjools> wgrant: rock!  thanks
<wgrant> Hmm. Should I expect an acknowledgement when I reply to an rt.admin.canonical.com ticket?
<bigjools> wgrant: https://answers.launchpad.net/soyuz/+question/136685
<bigjools> wgrant: RT should reply but since it doesn't know you I expect it won't
<wgrant> bigjools: Have you looked at the end of that question?
<bigjools> the massive list of files you mean? :)
<wgrant> I was thinking more about my response and reviewed branch.
<bigjools> oh didn't get that far
<bigjools> carry on
<bigjools> wgrant: any further comments re my bug comment: https://bugs.launchpad.net/soyuz/+bug/684180/comments/3 ?
<_mup_> Bug #684180: Deleted sources can leave binaries hanging around forever <soyuz-core> <soyuz-publisher> <Soyuz:Triaged> <https://launchpad.net/bugs/684180>
<wgrant> bigjools: "Argh" just about covers it.
<bigjools> that's my Word of the Day
<wgrant> Deletion won't cover everything.
<wgrant> What if the source is superseded instead?
<wgrant> We can't block that.
<wgrant> We can, instead, cry.
<bigjools> it won't but it covers this case
<bigjools> we can block superseding surely?
<bigjools> it'll get caught later
<wgrant> Pllllllease don't.
<wgrant> That violates the very little layering we have :(
<bigjools> the layering sucks
<wgrant> Why?
<bigjools> we don't have layers, we have something organised into modules
<wgrant> Making the publisher depend on build statuses is unprecedented.
<wgrant> And slow.
<bigjools> in that case we need to make domination do more work
<bigjools> which is equally as unpaletable
<wgrant> We need to think about how binaries and sources interact.
<wgrant> For copies, for deletions, for dominations.
<bigjools> "badly" :)
<wgrant> It is all tied together.
<wgrant> And it is only consistent in one respect: it is fucked.
 * bigjools loses mouthful of coffee
<bigjools> wgrant: we can't auto-supersede binaries if the source is superseded
<bigjools> they might be a dependent
<wgrant> I know
<wgrant> Except that's not the reason.
<bigjools> my main issue is preventing the manual deletion that people do in PPAs
<bigjools> what reason?
<wgrant> We don't seem to care about breaking dependencies.
<deryck> Morning, all.
<bigjools> howdy deryck
<bigjools> wgrant: why do we have this then? http://people.canonical.com/~ubuntu-archive/NBS/
<wgrant> I guess it is sort of dependency-related.
<wgrant> But not entirely.
<wgrant> Right.
<wgrant> NBS.
<wgrant> I hate NBS.
<bigjools> that's why we can't auto-supersede the binaries
<wgrant> I don't like introducing a hack to partially fix a problem without at least thinking about how to fix the whole thing.
<bigjools> I contest your definition of a hack
<wgrant> Blocking deletion because builds are in the wild is a hack.
<bigjools> I disagree
<wgrant> We should just make them be created deleted. Or something like that.
<bigjools> that's a hack too then ;)
<wgrant> It's a less obtrusive one.
<bigjools> GRRR what has a maverick update done to my fonts
<wgrant> So, we can't really reject the binaries if the source is deleted. Blocking deletion is undesirable. This leaves us with accepting binaries for a deleted source.
<bigjools> we can just throw them away and mark the build superseded
<bigjools> if the build is not active then we mark it superseded immediately
<wgrant> We could. But that seems like a waste.
<bigjools> someone wants the package deleted - we're just doing what they want.
<wgrant> I think most of my problems with this area stem from the way we fail to treat sources and their binaries as a single unit.
<wgrant> And the way this interacts with copies.
<bigjools> how would you treat them as a single unit?
<wgrant> We already do. For copies. And in the UI. Everywhere except most of the code.
<bigjools> how would you do that in the code?
<wgrant> I don't know exactly. But it's terribly confusing the way it is now: the same source can have different builds in different series and different archives. Copy from Hardy to Lucid, and you can no longer copy from Lucid to anywhere else. Copy one of those to another archive, and it will have all the same archs, but exactly one of them is actually a different build. Copy to a non-virt archive, it now contains another superset of the builds ...
<wgrant> ... of the original archive.
<wgrant> Want to do a security update? hppa is being slow. Let's copy without it.
<wgrant> Oh look, can't copy it any more.
<bigjools> you conveniently forgot about copy with binaries
<bigjools> or mixed examples with it set/not set
<wgrant> All those cases are copying with binaries.
<wgrant> Without binaries it's boring.
<bigjools> " one of them is actually a different build" - how?
<wgrant> bigjools: Because I copied from Hardy in one PPA to Lucid in another. Lucid has armel, Hardy does not. Lucid gets a new armel build, different from the one in the origin archive.
<bigjools> why are we creating new builds for binary copies?
<wgrant> Because the target series or archive can have more architectures.
<bigjools> that's crack
<wgrant> I think it probably is.
<bigjools> it's a binary copy, I don't expect more builds
<wgrant> It's also really, really slow.
<wgrant> But inter-series it becomes awkward.
<wgrant> My intuition says that builds should live in a set. And only sets should be copiable. Atomically. Inter-archive that's fine, since if you want more archs you can just rebuild it all.
<wgrant> But inter-series it doesn't work.
<bigjools> yup
<wgrant> So perhaps there should be an exception, where a set can be extended within an archive by copying to a new series.
<wgrant> But then when somebody copies someone else's set to another archive, they are screwed. Because they can't append to it, and they can no longer rebuild it.
<wgrant> "Argh"
<bigjools> wgrant: but soyuz isn't that complicated, don't worry.
<bigjools> we'll just throw more people at it
<wgrant> :)
<wgrant> Yes, the model is somewhat overcomplicated... but it can't be simplified away.
<bigjools> it's the nature of the beast
<bigjools> wgrant: so I think I'll amend my suggestion on that bug to just throw away the builds that are in progress and mark the build record as superseded.
<wgrant> bigjools: When they try to finish?
<bigjools> I just need to decide whether to do it in p-a or the b-m
<bigjools> yes
<bigjools> if they are not dispatched yet then we can supersede immediately
<wgrant> They'll supersede automatically when they try to start.
<bigjools> good point, well made
<bigjools> I was thinking only of deletions
<bigjools> what do you think of the cleanup SQL I propose to do?
<wgrant> As long as there are no Published sourcepubs remaining, sure.
<bigjools> yeah, it's just superseding binaries where the source is already superseded without being published at all
<bigjools> should be safe
<wgrant> It's possible that it was revived later. But I guess we could ignore that.
<bigjools> some of the sources date back to 2009
<wgrant> Only?
<bigjools> 2009-10-06 is the earliest
<wgrant> Hmmmm.
<wgrant> That's pretty strange.
<bigjools> 245 SPPHes
 * bigjools -> fud
<allenap> I have a new frozenset subclass. When it gets wrapped in a Zope security proxy nothing is available, not even the usual frozenset methods. Does anyone know how to configure this in ZCML (or otherwise) without repeating the existing configuration. Right now I think I'm going to modify BasicTypes directly.
<flacoste> allenap: that's weird because frozenset is already part of _default_checker in zope.security.checker
<allenap> flacoste: Yeah :-/
<flacoste> allenap: have you try the security debugger on it?
<allenap> flacoste: Is that ZOPE_WATCH_CHECKERS? Not yet.
<flacoste> allenap: no, it's something else
<flacoste> hang on
<flacoste> looking for it
<flacoste> something i write a long time ago
<flacoste> it's in lazr.restful.debug
<flacoste> from lazr.restful.debug import debug_proxy
<flacoste> print debug_proxy(obj)
<flacoste> allenap: it will show all layers of wrapping, along the checkers registerd for security proxy
<allenap> flacoste: Cool, that sounds useful.
<allenap> flacoste: It gets: zope.security._proxy._Proxy (using zope.security.checker.Checker)
<flacoste> hmm
<flacoste> allenap: is that all?
<allenap> flacoste: Yes! That's it :)
<flacoste> allenap: it's weird, because it should be showing the permission declared on it
<flacoste> so it's like if the read_permission and write_persmission were unset
<flacoste> but the default _setChecker
<flacoste> is a NamesCheker that grant access to all the set procotol
<flacoste> i suspect that something is chaning the default one
<flacoste> hand on, i'll try something
<allenap> flacoste: Yeah, that's what's stumping me.
<flacoste> shit, my tree is out of date
<flacoste> allenap: try printing the checker in make harness on devel
<flacoste> see if it is the same thing
<allenap> flacoste: That's where I did it.
<flacoste> allenap: ok, let me compare notes (after my standup)
<allenap> flacoste: Okay, thanks.
<flacoste> mrevell, jml: http://leankitblog.com/2010/12/10-kanban-boards-leankit-kanban-style/
<timrc> We're granting people/ teams upload rights to ppas via newComponentUploader() in launchpadlib.  Our problem is that, when we do this, the PPA does not show up in +archivesubscriptions -- seems to me this should be happening?  Am I off my rocker?
<bigjools> timrc: sounds wrong.  Can you file a bug with the details to re-create that please.
<timrc> bigjools: sure, np
<bigjools> timrc: presumably it's a private PPA?
<timrc> bigjools: yep
<timrc> bigjools: I'll be sure to note that detail in the bug report
<bigjools> well you can't have subscriptions on them otherwise :)
<timrc> bigjools: the only way I know of to expose the subscription is to use Manage access via LP
<bigjools> thought I'd check the blindingly obvious first
<bigjools> you can use the API as well
<timrc> bigjools: but maybe +archivesubscriptions only lists archives that you can install from and not ones you can upload too? I dunno, I'm a newbie :)
<timrc> and not ones you can _only_ upload too?
<bigjools> timrc: it's possible that's happened, yes, and it would be a bug if that's the case.
<gary_poster> sinzui: might you know anything about https://bugs.launchpad.net/launchpad-foundations/+bug/683945 ?  I don't have anyone ATM who does.
<_mup_> Bug #683945: disabled lists are never completing disabling <canonical-losa-lp> <Launchpad Foundations:New> <https://launchpad.net/bugs/683945>
<flacoste> abentley: how's the release is going?
<abentley> flacoste: It's going fine.  We've nearly got QA complete.
<flacoste> abentley: did we sort out the DKIM QA?
<abentley> flacoste: poolie was supposed to do it on (his) saturday, but he hasn't updated the tags.
<flacoste> abentley: should we consider reverting it?
<flacoste> abentley: and should we do a no-downtime today with bzr 2.2.2?
<abentley> flacoste: I am hoping that he's done it and just forgotten to update the tags.
<abentley> flacoste: I was going to chase it down today.
<flacoste> abentley: ok, let's see what he says when he comes online later today
<flacoste> abentley: what about bzr 2.2.2?
<abentley> flacoste: I don't feel strongly either way.
<flacoste> hmm, ok
<abentley> flacoste: If we do, we might as well do 1206 as well, so we can nix both cowboys.
<flacoste> abentley: the cow-boys are not part of the nodowntime set
<flacoste> so it's probably not that useful
<abentley> Hmm, I thought one of them was not part of the nodowntime set because of the cowboys.
<gary_poster> losas, https://bugs.launchpad.net/launchpad-foundations/+bug/684672 is dealt with, right?  The bug report doesn't give a status update
<_mup_> Bug #684672: staging update broken on revno 10029 <canonical-losa-lp> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/684672>
<gary_poster> eh, sorry, going to ops
<timrc> bigjools: So, I found a minute to play around.  You have to call newSubscription() to have the PPA appear in  +archivesubscriptions .. which is fine as being 'subscribed' to the archive simply means you can install from it.  I suppose there is a use case where you'd like to make the archive 'write-only' in that a person / team can upload to the PPA, but not install from it (e.g. the PPA is upstream to another archive that is inst
<timrc> allable)
<bigjools> timrc: actually I think we have a bug somewhere about having implicit subscriptions for PPA uploaders.
<timrc> bigjools: so I think the takeaway here is that it'd be nice to see the access rights you have on a private PPA, regardless of subscription.. is there a way to do this from the UI?
<bigjools> you can query what rights someone has via the API
<timrc> bigjools: I was hoping there'd already be something out there to support our users :) but I'll put this on my list of TODOs
<bigjools> yeah some of this is a little clunky still
<timrc> bigjools: well I appreciate your time, thanks
<bigjools> timrc: no problem, let me know if you have more questions
<sinzui> gary_poster, sorry I was OTP. I marked the bug as fix released. Chex and I resolved the stuck Mm + XMLRPC combo
<mkanat> Hey hey. Any hope of getting my loggerhead update merged and staged?
<mkanat> This is the MP: https://code.launchpad.net/~mkanat/loggerhead/launchpad/+merge/42338
<lifeless> that won't get it deployed
<lifeless> you need to propose a source dep change to launchpad itself
<mkanat> lifeless: Right, but first I have to merge to this branch, which I don't control.
<lifeless> mmm, well both things I need
<lifeless> anyhow, right now - we're frozen.
<mkanat> lifeless: Okay. How long does that last?
<lifeless> I'm not sure, i'm on leave - check the -dev list archive, dates should have been announced there
<mkanat> lifeless: Okay, thanks.
<gary_poster> ack, thanks sinzui
<lifeless> sigh, the python3 shenanigans are just plain tiring
<benji> lifeless: which shenanigans in particular are getting you down?
<lifeless> benji: most currently the transform stuff
<lifeless> benji: but more generally the way its just so painful to do widespread compatibility with
 * lifeless things py3k was a mistake
<benji> unfortunately I have to agree; too much incompatability for such small gains
<benji> I still think someone who wanted to be BDFL 2.0 could take up Python 2 and run with it.
<mkanat> benji: What I hear is that 2.7 is the last 2.x release ever.
<benji> mkanat: right, the last official one; the python-dev folks won't be working on any more releases, but someone else could take it up -- they'd have to use a name other than "Python" though
<mkanat> benji: Ah, yeah.
<lifeless> benji: they could use Compatython
<benji> heh
<lifeless> benji: hi
<lifeless> benji: can you join #launchpad ?
<lifeless> benji: (generally every dev should be in that channel btw)
<thumper> morning
 * thumper relocates
<mhall119> question, if I have a launchpad username, can I get their openid identity_url from the launchpad API?
<thumper> mhall119: what problem are you trying to solve?
<mhall119> loco.ubuntu.com pre-creates Django users based on a team's admins
<mhall119> however, when those admins go to log in to loco.u.c, django-openid-auth sees an existing user with that username, and instead assigns them to $username+1
<mhall119> if they already had their openid identity_url set, it would just log them into the correct account
<mhall119> see https://code.launchpad.net/~mhall119/django-openid-auth/fixes-639772/+merge/38545
<EdwinGrubbs> lifeless: what do you think of this solution for specifying the store used by Set classes? http://pastebin.ubuntu.com/540423/
<lifeless> EdwinGrubbs: that makes a context specific item a global behaviour: thats undesireable
<EdwinGrubbs> lifeless: what do you mean? The dbpolicy is only being used during the duration of the with-statement.
<lifeless> right
<EdwinGrubbs> lifeless: Does that mean that the BaseDatabasePolicy shouldn't have had the __enter__() and __exit__() methods added so that someone could use "with MasterDatabasePolicy()"
<lifeless> EdwinGrubbs: the with statement you wrote changes the selector for all threads at once AFAICT
<lifeless> EdwinGrubbs: it may well mean that the __enter__ and __exit__ are bad ideas outside of the test suite.
<lifeless> EdwinGrubbs: but even if it was threaded
<lifeless> EdwinGrubbs: its still a risky idiom to change context-wide state when calling an object will a defined lifetime greater than ones own contect
<lifeless> *context*
<EdwinGrubbs> lifeless: then, Person.getOrCreateByOpenIDIdentifier() should probably stop using  a policy as a context manager also.
<lifeless> EdwinGrubbs: myself, I would have used the person_validity_queries static method that was on Person and not put anything onto PersonSet
<lifeless> EdwinGrubbs: re Person.getOrCreateByOpenIDIdentifier - yes, I suspect so.
<lifeless> EdwinGrubbs: I had a quick look through zope.component and zope.interfaces to see if I could find a threaded context in there - I couldn't, but its pretty convoluted code, so it could be anything.
<mhall119> if I have a launchpad username, can I get their openid  identity_url from the launchpad API?
<james_w> mhall119, it doesn't look like it
<lifeless> mkanat: https://api.launchpad.net/+apidoc/ has the api docs
<lifeless> bah
<lifeless> mhall119: ^
<lifeless> mhall119: That said, I think its probably undesirable to share that information about users to people other than the user themselves.
<mhall119> lifeless: if you view the source of https://launchpad.net/~lifeless
<mhall119> it's in there
<mhall119> <link rel="openid2.local_id" href="https://login.launchpad.net/+id/kPbPBDC" />
<lifeless> mhall119: hmm, we should nuke that
<lifeless> we use the ubuntu sso these days
<mhall119> why?
<lifeless> launchpad does not contain an authentication database.
<lifeless> we delegate to sso.ubuntu.com
<lifeless> login.launchpad.net is just a skin on sso.ubuntu.com
<mhall119> okay, any way to get the identity url from sso?
<mhall119> given a launchpad username
<lifeless> try asking in #canonical-isd
<mhall119> thanks
<lifeless> personally though, I'd just stop preallocating things
<lifeless> and do admin lookup on-demand.
<mhall119> we setup "user profiles" for admins in a team, so we can display their real names
<mhall119> but that requires that we have a django user account for them
<mhall119> which throws off django-openid-auth once the admin actually tries to log in for the first time
<lifeless> right
<lifeless> so do that setup *after* they login
<lifeless> its just a thought
<cody-somerville> Is this page cached? https://code.launchpad.net/~offspring-hackers
<cody-somerville> That page says the branch was modified 1 minute ago - the branch was last modified on the 3rd.
<lifeless> metadata changes count too
<cody-somerville> ah
<cody-somerville> right
<lifeless> mwhudson: get a losa to set the review bits properly
<mars> flacoste, pong?
<flacoste> hi mars
<benji> grr, the frequent firefox grey-screen-of-wait I'm getting lately is irritating
<poolie> lifeless/whoever: is there a bug or rt for live log feeds from production?
<poolie> should i file one?
<poolie> wbn
<lifeless> realtime? possibly
<lifeless> up to you
<wgrant> 17 minutes for DB changes!? I thought the last estimate was slightly under two hours...
<lifeless> recife branch was rolled back
<wgrant> Ahh.
<poolie> lifeless: well, at least frequently you don't have a multi-minute wait
<poolie> or apparently a 24h wait
<wgrant> Aren
<wgrant> Aren't they synced every 5 minutes?
<lifeless> poolie: EPARSE
<poolie> not from staging, apparently
<poolie> lifeless: if something i changed produces an error or debugging message on staging, i would like to be able to see that message
<poolie> at the moment i need to either prod a losa, or wait 24h
<poolie> iwbn if it was available to developers less than a minute after being emitted
<lifeless> poolie: sure, sounds nice to be better at
<lifeless> I wouldn't aim at realtime just yet
<poolie> near-
<lifeless> staging load is very high
<wgrant> Is the scripts split going to happen at some point?
<lifeless> poolie: I don't want to think about this deeply on leave
<lifeless> poolie: so, as I said before, up to you
<poolie> sure
<poolie> abentley, i'm back to qa now
<poolie> i think 643219 and bug 316272 are ok
<_mup_> Bug #316272: launchpad should verify gmail or DomainKeys authenticators <dkim> <feature> <qa-needstesting> <Launchpad Registry:Fix Committed by mbp> <https://launchpad.net/bugs/316272>
<poolie> spiv/wgrant/abentley: would you like to read my qa steps on those bugs and suggest any others?
<wgrant> poolie: Have you tried DKIM to an existing bug?
<poolie> i have, and it worked
<wgrant> Sounds good then.
<poolie> and gpg is still accepted
<wgrant> Yep, saw that.
<abentley> poolie: ideally, your reviewer will have seen your testing plan as part of your merge proposal, but I trust your judgement.
<poolie> that would be good
<poolie> nobody asked me for one
<poolie> i'm just checking the last bug is ok
<poolie> it doesn't seem to have regressed, at any rate
<poolie> i should now manually retag them qa-ok?
<abentley> poolie: yes.
<poolie> and they'll automatically go to fixreleased during rollout to lpnet?
<abentley> poolie: we have a standard template for proposals, which includes a section for testing it.  But very few people are using the template.  I should bring that up at the reviewer meeting.
<abentley> poolie: You don't have to worry about marking them fixreleased.  I believe sinzui runs a script to do that.
#launchpad-dev 2010-12-07
<poolie> k
<poolie> abentley: so the final gpg one: staging is oopsing too much to test it
<poolie> i don't seem to have broken anything at least :/
<abentley> poolie: did you create that merge proposal, or did it already exist?
<abentley> poolie: I think you're hitting the bug where the staging librarian oopses instead of falling back to the production one.
<abentley> poolie: I bet you won't have that issue if you create a fresh merge proposal.
<poolie> ah, it already existed
<poolie> ok
<poolie> abentley: everything is qa-ok now, i believe
<abentley> poolie: great.
<poolie> can you tell me the url where i can check the unreleased changes?
<thumper> what is the name of the single signon project?
<wgrant> canonical-identity-provider
<thumper> ta
<lifeless> poolie: you might like the buffer bloat stuff thats getting airtime right now
<lifeless> poolie: vis-a-vis bzr network perf issues
<poolie> where?
<lifeless> http://gettys.wordpress.com/category/bufferbloat/
<poolie> interesting
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      286 / 6529  Archive:+index
<lifeless>      110 /  328  BugTask:+index
<lifeless>       36 /  268  Distribution:+bugs
<lifeless>       21 /  143  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       15 /   32  DistroSeries:+queue
<lifeless>       14 /    0  BinaryPackageBuild:+retry
<lifeless>       13 /   18  Archive:+copy-packages
<lifeless>       10 /  264  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       10 /   39  MailingListApplication:MailingListAPIView
<lifeless>        9 /    7  Person:+bugs
<lifeless> mwhudson: hey, how is vostok
<mwhudson> lifeless: resting
<lifeless> ah
<poolie> there are so many intranet hosts called portal.*.com, and so few of them actually let you play the game :-(
<spiv> poolie: haha
<poolie> :)
<poolie> how are you?
<poolie> i'm doing one of max's reviews
<poolie> i was looking into splunk earlier and it looks very good
<spiv> Good, about to flood the review queue slightly :)
<poolie> :)
 * spiv shifts to #bzr
<poolie> thumper: don't suppose you're still here?
<thumper> poolie: not really
<adeuring> good morning
<mrevell> Morning
<bigjools> morning people
<wgrant> Morning.
<jelmer> hi mrevell, wgrant
<wgrant> Morning jelmer.
<bigjools> wgrant: yo
<wgrant> bigjools: Hi.
<bigjools> wgrant: so the zombie sources are all these I think: http://pastebin.ubuntu.com/540590/
<bigjools> does that query look sane to you?
<wgrant> It does.
<bigjools> it probably needs to ignore some more
<bigjools> stuff that went superseded in the minutes before the query runs will get picked up
<bigjools> maybe I can ignore stuff newer than an hour old
<wgrant> Yeah. Filter for older datesuperseded.
<wgrant> Or datecreated.
<bigjools> I'm going to convert that to an UPDATE to set spph.datepublished
<wgrant> Er.
<wgrant> Why?
<bigjools> fail
<bigjools> spph.scheduleddeletiondate
<bigjools> paste pebkac
<wgrant> The "Why?" still stands.
<wgrant> Mark the binaries Deleted, and the sources will be condemned automatically.
<bigjools> yes
<bigjools> I guess so, was gonna do binaries separately
<wgrant> The minimal hacker is to set the status and datesuperseded of the binaries.
<wgrant> Everything else will follow.
<wgrant> And I like minimal production DB hackery :)
<bigjools> yes ;)
 * bigjools cooks query to find associated binaries
<bigjools> wgrant: sane? http://pastebin.ubuntu.com/540597/
<bigjools> 5744 binaries!  (I forgot the time constraint)
<bigjools> http://pastebin.ubuntu.com/540605/ is better
<wgrant> bigjools: You need to constrain bpph.archive, but otherwise it looks OK.
<bigjools> yeah was just making that change
<bigjools> trying to think whether I need to constrain on distroseries too
<wgrant> Also constrain the status.
<wgrant> We only care about published ones.
<bigjools> yes
<wgrant> Thinking about the distroseries thing... it probably won't make a difference, but try it both with and without.
<bigjools> hmmm, zero rows
<bigjools> removing the archive constraint makes it 1684
<bigjools> 1584
<wgrant> Which archive constraint? bpph.archive = spph.archive?
<bigjools> yeah
<wgrant> That has to be there.
<wgrant> So sounds like we've got something wrong.
<bigjools> wgrant: I think I know
<wgrant> Oh?
<bigjools> they are probably all copied
<bigjools> but that doesn't explain the lack of binaries causing domination to not set scheduleddeletiondate
 * bigjools looks at the code
<wgrant> Right, they have to be in the same archive.
<bigjools> so they should get comdemned :/
<wgrant> Well, no. Our query is wrong.
<bigjools> that is the other obvious problem :)
<bigjools> http://pastebin.ubuntu.com/540608/
<bigjools> that's the current one
<wgrant>         bpph.id = binarypackagerelease.id and
<wgrant> Wut?
<bigjools> sigh
<bigjools> 2237 rows.  hurray
<wgrant> I love typesafety :)
<bigjools> now to restrict on series
<wgrant> And status.
<wgrant> Status is far more pressing.
<bigjools> heh
<bigjools> down to 141
<bigjools> which is odd, that's less than the number of source rows
<wgrant> Not terribly odd.
<wgrant> More relevant is how the number of archives in those rows compares to the number processed each time.
<bigjools> 141 again restricting the series
<bigjools> so that's pleasing
<wgrant> Excellent.
<bigjools> time to sweep up some cruft then
<wgrant> I'd compare the list of archives first...
<bigjools> mmm
<bigjools> 14 of them
<bigjools> wgrant: so there's actually 23 PPAs that come up on the query.  However 4 of them don't appear in the publisher log.
<wgrant> bigjools: Are those archives disabled or unpublishable?
<bigjools> ah let me check
<bigjools> yup that's it
<bigjools> all deleted
<bigjools> no harm in fixing those publications anyway
<wgrant> How many of the archives in the log does that leave unfixed?
<wgrant> We need to do a mass-fixup of deleted archives' publications anyway.
<bigjools> I don't know, it's very hard to see what's genuine and what's not
<bigjools> the only way to tell is to see it repeated in the log each run
<wgrant> Right.
<bigjools> wgrant: http://pastebin.ubuntu.com/540616/
<wgrant> bigjools: Do not touch SPPH. Set BPPH.status = Deleted and BPPH.datesuperseded = NOW()
<bigjools> wgrant: gah
<bigjools> right
<bigjools> I clearly need more coffee
<bigjools> if we set status=Deleted, I need to set the person who deleted it
<bigjools> or the UI will go bong
<bigjools> wgrant: http://pastebin.ubuntu.com/540622/
<wgrant> bigjools: I don't think the UI will go bang. But I guess it might.
<bigjools> it's bad data either way
<wgrant>         spph.datepublished is null and
<wgrant> I'm pretty sure that is crack, but it will only restrict the set to something less than it should be.
<wgrant> Otherwise it looks OK.
<deryck> gmb, I meant to ask you to look at bug 380362 if you could.
<_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. <Launchpad Bugs:New> <https://launchpad.net/bugs/380362>
<deryck> may be an old one that is fixed, but the linked bug watches still have "can't find bug" or some such error.
<gmb> Ah, the neverending saga of debbugs watches.
<gmb> deryck: It's on my list for today. I'll try to poke at it when the LOSAs are available (they're currently tied up with another issue).
<deryck> gmb, ok, thanks.
<flacoste> deryck, abentley: the revert is missing qa tags and isn't recognised by qa-tagger, you should probably manually tag the bug
<deryck> flacoste, abentley did.  That was my fault sorry.
 * deryck should never take theraflu during work days
<abentley> flacoste: Because deryck did not use --rollback, I have tried to emulate it from the documentation, which says "The bug will be tagged as bad-commit-*, all the qa-* tags will be remove..."
<abentley> flacoste: I think there's some difference between documentation and implementation, but I'm not sure what's supposed to be done in this situation.  Maybe roll it back to "in progress"?
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.12 | Performance Tuesday | PQM in RC mode | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<gary_poster> sinzui: A few questions about https://bugs.launchpad.net/launchpad-foundations/+bug/684668 : May I toss it to registry, since we have no knowledge of these bits?  If not, my impression is that this is not of high importantance: am I wrong?
<_mup_> Bug #684668: Unable to delete messages from list archive <canonical-losa-lp> <Launchpad Foundations:New> <https://launchpad.net/bugs/684668>
<sinzui> gary_poster, yes
<gary_poster> thank you
<sinzui> gary_poster, I am sure it is an ml-archive-sucks bug. We know the message was deleted, but the page generator/squid cache wont show it gone
<gary_poster> ah, gotcha
<jml> hello
<pitti> hello
<pitti> benji, gary_poster: how are you? jml said you are the right persons to talk about this new keyring thing?
<gary_poster> pitti: hi, yes.  did you see benji's reply on the pertinent bug
<pitti> yes, I just replied
<gary_poster> oh, lemme go look
<pitti> but I wondered why we deliberately broke existing API, instead of creating a new login_keyring() thing for keyrings
<pitti> that's not .. nice
<pitti> it suddenly breaks each and every script and cron job we've written
<pitti> and isn't noninteractive
<benji> your cron jobs use login_with?
<pitti> (and using a keyring by default is total overkill -- after all, you can just snatch the cookie from firefox)
<pitti> benji: sure
<benji> that's unfortunate
<pitti> that was _the_ primary function to get a Launchpad lib so far
<pitti> and it's also what the documentation said
<pitti> (e. g. https://help.launchpad.net/API/Examples)
<benji> even without the changes in the latest version, cron scripts using login_with are in a precarious sitution; if the credentials cache is ever removed or if the token is revoked on the server-side they will attempt to re-authenticate with a web browser
<benji> not to say that the situation isn't worth discussing, but one of the outcomes apparently needs to be some form of better advertising when the different APIs should be used
<pitti> benji: not really
<pitti> benji: first, it had a credentials_file argument, so that you can store them in a well-known placed
<pitti> and second, if you run the cron job manually the first time, it showed the URL to you, you could open it locally, and then you were fine
<gary_poster> benji, pitti, I'm a big +1 on getting pitti's scripts happy, both as an important user and as a representative.  I'm happy to weigh in if needed, but mostly intend to get out of the way.  A few notes:
<gary_poster> - the security implications of this have been looked at by many (including Kees, importantly), and I'd really prefer not to reopen them.
<gary_poster> - as you might expect, we believed that we were doing the right thing; what benji described was our understanding of the usage, and our expected usage.  The examples you cite were part of the general difficulty we find ourselves in: we want to make the right thing happen by developers who don't want to worry about it, and who have not worried about it in the past.
<gary_poster> - we changed the behavior of login_with because it meant users that we were interacting with would not have to make a change to get the uniform behavior.  uniformity on the desktop is very important for this effort.
<gary_poster> - our docs obviously needed and need improvement in this regard in particular.
<gary_poster> - leonardr, the person most connected with these changes, is not around this week, though benji and I should be able do a reasonable job.
<pitti> benji: I opened https://bugs.launchpad.net/launchpadlib/+bug/686690 about this
<_mup_> Bug #686690: 1.8.0 completely breaks login_with() API (and forces keyrings) <launchpadlib :New> <https://launchpad.net/bugs/686690>
<pitti> I think we should probably discuss it there, to have a better paper trail
<gary_poster> pitti, your "and second" is exactly the kind of thing benji was describing
<gary_poster> pitti, the paper trail is the upside.  The decreased speed is the downside.
<gary_poster> in this particular case, with leonardr not around, maybe the paper trail wins anyway
<pitti> I understand that you might want a different API on "desktopish" programs
<gary_poster> and we are dealing with an installed base
<gary_poster> that needs to be uniform
<pitti> but as it happens, most of our use cases (QA scripts, apport, ubuntu-archive-scripts, sru report, and what not) are not desktop apps
<pitti> the only non-"server"ish use case I know of is Ubuntu One
<gary_poster> nit: non-desktop apps are not a particular problem for this; cronscrpts are.
<gary_poster> ...a subclass...
<gary_poster> Ground Control
<gary_poster> others, I believe
<pitti> or in general, taking a well-established existing API and turning it into something entirely different
<pitti> even for desktop apps
<pitti> it now means that suddenly every desktop user needs to reauthenticate
<pitti> as their existing credentials files are ignored
<gary_poster> pitti, I think you are stretching your description ("entirely different").  from our perspective, the API presented a black box.  the credentials files are generally not intended to be the domain of a launchpadlib-using script.  But I also think that this part of the conversation is counter-productive.
<gary_poster> We have a use case and approach that has been vetted by more people than us.  There is a reason that it is the way it is, and it has been discussed.  I believe you have a valid, concrete concern for cronscripts that we did not foresee.  We need to determine a way around this.
<gary_poster> One obvious approach is to change the scripts to use our expected approach.  That is admittedly unfriendly, so even though I think that's the longer-term desire, we should do better now.
<pitti> couldn't we get a new API for using keyrings, and make keyrings optional?
<pitti> at least for a transition period of a year or so
<pitti> so that we have the new keyring API available for some time
<pitti> and everyone has time to port their stuff
<benji> we could; part of the motivation for the keyring integration is to support better desktop integration without the need for clients to change their API use.  It would be great if we can fulfill that goal while also addressing the cron script problem.
<gary_poster> pitti, keyrings are "optional" right now in that, if there is not one available, the keyring library will do something else.  You know that already.  I *think* what is more important to you is that, if legacy credentials files exist, they are used.  Is that in fact sufficient, or am I missing a detail?
<pitti> gary_poster: how can I make them optional?
<pitti> (and no, I don't know that already)
<gary_poster> oh
<pitti> if I run a script now, it creates a new keyring
<pitti> asks me for a passworrd
<pitti> (which can't be empty)
<pitti> and then subsequently asks me for that password again
<pitti> Waiting to hear from Launchpad about your decision...
<pitti> Please input your password for the keyring
<gary_poster> they are optional in the sense that, if there is not one around (e.g., not Gnome or KDE), it is not used.
<pitti> Password:
<pitti> that's what I get
<benji> I'm fairly certain that's the prompt for the encrypted file storage used when no keyring is available.
<pitti> well, I have GNOME running
<pitti> I didn't test it on a server with ssh yet
<gary_poster> right, the keyring library does not require a keyring implementation.  It provides a backup.
<benji> apparently python-keyring can't communicate with the keyring for some reason
<gary_poster> (my comment is pertinent to "I  didn't test it on a server with ssh yet")
 * gary_poster is going to be quiet about details because benji knows more than he about them
<pitti> benji: note that we currently have a very old version of p-keyring in the archive; did you test this with 0.5? it might work better
<gary_poster> so far it sounds to me like (1) python-keyring is not happy on pitti's machine, which is worrisome; and (2) I'm not sure yet whether, if the first problem didn't exist, my proposal ("if legacy credentials files exist, they are used") is a sufficient compromise for this backwards compatibility problem.
<pitti> gary_poster: if the credentials_file parameter and existing cred files could continue to work, that'd pretty much solve the API break, I think
<pitti> as for (1), I have no idea, I'm afraid
<pitti> as I pointed out in the MIR, we should update to the current 0.5 upstream version first
<gary_poster> pitti, do you always use the credentials_file parameter in your scripts?
<pitti> it drops its own gnome-keyring module and uses libgnome-keyring, which is the right thing
<benji> pitti: yep, the latest launchpadlib is meant to be used with python-keyring 0.5, but I'm not sure if using an older version would work more pooly
<pitti> gary_poster: only for apport; for most scripts we just use the default in ~/.launchpadlib/
<gary_poster> ah
<pitti> benji: ah, that could be it then
<pitti> (see above)
<pitti> sorry, need to leave for today
<pitti> thanks for the discussion so far!
<gary_poster> pitti, ack.  I was hoping to only accept existing cred files if credentials_file were passed, and then issue a deprecation warning
<gary_poster> but that still sounds not good enough
<gary_poster> ok thanks
<gary_poster> benji or I will summarize in the bug
<pitti> ah, thanks
<pitti> I also sent a summary
<pitti> thanks, and good night!
<gary_poster> excellent, thanks
<gary_poster> night
* abentley changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.12 | Performance Tuesday | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<bdmurray> How come the apidoc lists getSpecification but it doesn't actually appear with a launchpadlib client?
<benji> bdmurray: does the version of the docs you're looking at and verion of the API match?
<bdmurray> benji: yes I'm using devel for both
<benji> hrm, might be a bug
<sinzui> benji, ping
<benji> sinzui: hi
<sinzui> benji, I want to subclass a Choice field to guard conflicting transitions between values. I am not sure if I should redefine _constraint() or _validate()
<sinzui> benji, The crux of the issue is that while the value is valid, it cannot be accepted because it violates another relationship. (something like a invariant, but between a hierarchy of objects)
<bdmurray> salgado-afk: I'm having some troubles using ubuntu.getSpecifications() that should work on devel right?
<benji> sinzui: I suspect using constraint() (no leading underscore) will be slightly easier.
<sinzui> benji, yes, sorry for the underscores
<benji> sinzui: note the interface difference between the two: constraint() should return a boolean, validate() should raise an exception (or not)
<sinzui> ah
<james_w> bdmurray, it should yes
<sinzui> benji, so I think I may want to define both for their respecting uses.
<benji> makes sense
<james_w> bdmurray, do other specifications things work? natty.valid_specifications worked for me on qastaging last week
<sinzui> validate() could call constraint() and convert False to TeamSubscriptionPolicyError
<bdmurray> james_w: no valid_specifications doesn't show up either but I'm production which seems to have the right revision
<james_w> bdmurray, you get "AttributeError"?
<benji> sinzui: the default implmentation (from Field) does something similar, validate() is responsible for calling constraint() and raising a ConstraintNotSatisfied error if a false value is returned
<bdmurray> james_w: yeah
<james_w> bdmurray, are you using it anonymously?
<bdmurray> james_w: no, I've seen that bug report too
<benji> sinzui: (ConstraintNotSatisfied is a subclass of ValidationError)
<james_w> bdmurray, it's working for me using "edge"
<sinzui> benji, thanks. I will follow that pattern. I was thinking or returning a very specific class of error with a meaningful reason.
<benji> yep; the default "Constraint not satisfied" isn't real helpful.
<james_w> bdmurray, works for me against production too. My guess would be cached wadl or it not actually using devel for some reason.
<bdmurray> james_w: okay, thanks I'll poke at it some more
<james_w> np
#launchpad-dev 2010-12-08
<wgrant> Could someone please throw https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 at EC2?
<james_w> wgrant, I would, but: ec2: ERROR: Unable to set the commit message in the merge proposal.
<wgrant> james_w: Ah, you're not in ~launchpad?
<james_w> nope
<cody-somerville> wgrant, If you give me the command I need to run, I'll do it for you.
<wgrant> cody-somerville: I don't actually know how to do it yet, sorry.
<james_w> cody-somerville, ./utilities/ec2 land <url>
<james_w> the first will need --force as it isn't set to "Approved"
<LPCIBot> Project db-devel build (192): FAILURE in 6 min 21 sec: https://hudson.wedontsleep.org/job/db-devel/192/
<LPCIBot> Project db-devel build (193): STILL FAILING in 0.43 sec: https://hudson.wedontsleep.org/job/db-devel/193/
<wgrant> StevenK: Are you doing bad things to Hudson?
<LPCIBot> Project db-devel build (194): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/194/
<LPCIBot> Project db-devel build (195): STILL FAILING in 2 sec: https://hudson.wedontsleep.org/job/db-devel/195/
<LPCIBot> Project db-devel build (196): STILL FAILING in 0.44 sec: https://hudson.wedontsleep.org/job/db-devel/196/
<LPCIBot> Project db-devel build (197): STILL FAILING in 0.44 sec: https://hudson.wedontsleep.org/job/db-devel/197/
<LPCIBot> Project db-devel build (198): STILL FAILING in 0.56 sec: https://hudson.wedontsleep.org/job/db-devel/198/
<adeuring> good morning
<LPCIBot> Project db-devel build (199): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/199/
* mthaddon changed the topic of #launchpad-dev to: Launchpad down/read-only from 10:00-11:30UTC for a code update | Launchpad Development Channel | Week 4 of 10.12 | Performance Tuesday | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<mrevell> Greetings
<wgrant> bigjools: Since when do we support renaming Ubuntu series?
<bigjools> since recently
<bigjools> wgrant: so, we still have a few PPAs appearing in every publisher run
<bigjools> the ones I caught with the SQL have gone though
<wgrant> bigjools: I suspect it's the datepublished IS NULL
<wgrant> That constraint was unnecessary.
<bigjools> right
<bigjools> it was belt and braces
<wgrant> Yup.
<bigjools> it eats a few minutes in the publisher time for all these :/
<wgrant> Are cocoplum and germanium in nodowntime?
<bigjools> no
<wgrant> :(
<wgrant> I understand cesium.
<wgrant> But not those two.
<wgrant> Oh, poppy?
<bigjools> errr yes I meant
<bigjools> as in, they don't get rolled out to automatically
<bigjools> I hate that tag
<wgrant> That means they're *not* in nodowntime.
<wgrant> nodowntime means that they don't require downtime for updates. Not that no downtime is allowed.
<bigjools> exactly - confused yet?
<bigjools> the reason they are in nodowntime is because of the publisher and poppy
<bigjools> we're working on load-balancing poppy
<bigjools> wgrant: so removing the datepublished is null clause throws up over 900 PPAs.  That's not right :)
<wgrant> bigjools: Right, you need to exclude those with other active publications for the source.
<bigjools> eh?
<wgrant> Hmm. Let me think.
<wgrant> What's the query?
<bigjools> http://pastebin.ubuntu.com/540956/
<wgrant> bigjools: We need to check if there are any other matching sourcepubs in the same series.
<wgrant> I think.
<wgrant> That's the condition that the dominator users.
<bigjools> I can't think straight today, I have got the start of man flu
<wgrant> :(
<bigjools> wgrant: I can't get my head around what you mean
<wgrant> Nevermind, I'm crazy.
<wgrant> Can you tell what's wrong with the remaining PPAs?
<wgrant> It might not be the same issue.
<bigjools> well that's the theory I am working on, I need to debug it
<bigjools> self._setScheduledDeletionDate() makes me cry
<wgrant> Oh?
<bigjools> could really do with a mass-update instead of piecemeal
<bigjools> would be an order of magnitude quicker
<wgrant> Sure, but that needs the whole thing to be refactored to issue just a couple of queries per archive.
<wgrant> Not several per publication.
<bigjools> exactly
<wgrant> That method is the least of our worries.
<bigjools> I'd say it's one of the nightmares of soyuz personally
<bigjools> in fact domination.py generally :)
<wgrant> Sure.
<wgrant> It's better than it used to be. But still pretty horrific.
<bigjools> mmm it's nice and warm today, the high is -1
<wgrant> :( I want cold.
<bigjools> you don't :)
<bigjools> wgrant: so I have found an example of one where the source did get published and then deleted before the build finished.  The data looks entirely as expected, so I'm not sure why that other query picks up so many PPAs.
<wgrant> bigjools: I need to think about that. Can you investigate one of the other 900 PPAs and work out what's wrong?
<bigjools> yeah already looking
* mthaddon changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.12 | Performance Tuesday | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<bigjools> wgrant: so the other PPAs have packages that are naturally superseded
<wgrant> Right.
<bigjools> but the binaries are still published, so something is holding up the binaries
<wgrant> None Deleted?
<wgrant> Oh.
<wgrant> Of course.
<wgrant> A2...
<bigjools> however, they don;t appear in the publisher log!
<wgrant> I am stupid.
<wgrant> A2 marks pockets with *Deletions* dirty.
<wgrant> and Distribution.getPendingPublicationPPAs only looks for Pending and Deleted.
<wgrant> So PPAs with Superseded sources like this won't be processed by the publisher.
<bigjools> ho ho!
<wgrant> So it's plausible that we have 900 of them,.
<bigjools> so, how do we fix this ...
<wgrant> This is NBS.
<bigjools> right
<wgrant> It's not critical that we handle this now, since the performance impact should be close to zero.
<wgrant> Long-term we probably need UI for NBS.
<wgrant> And everyone will handle it themselves then.
<wgrant> For now: ignore.
<bigjools> it's very hard on PPAs to see that right now
<wgrant> Right.
<wgrant> So, restrict spph.status to Deleted.
<wgrant> And remove datepublished IS NULL
<wgrant> And see if that returns a set closer to the remaining PPAs from the publisher log.
<bigjools> so I can change the original query to just pick up status=4 and we should be ok
 * bigjools crosses with your suggestion
<bigjools> 58 PPAs \o/
<wgrant> Still large...
<bigjools> well this is on staging, it will be the original 23 plus new ones
<wgrant> Oh.
<wgrant> Is that closer to what we were expecting?
<wgrant> I don't have the publisher log at hand.
<bigjools> yeah it's about right
<bigjools> wgrant: this is what I will run: http://pastebin.ubuntu.com/540962/
<wgrant> bigjools: Set datesuperseded! Not scheduleddeletiondate.
<bigjools> Imeh
<wgrant> Otherwise it looks fine.
<wgrant> Then we need to get your fix out to cesium soonish.
<wgrant> And that should be the end of that.
<bigjools> http://pastebin.ubuntu.com/540963/
<wgrant> doit
<bigjools> async b-m up and running!
<wgrant> Woo.
<bigjools> oy, spammy log now
<bigjools> "Starting factory" messages for the getPage call :(
<bigjools> and corresponding "Stopping factory"
<wgrant> :(
 * bigjools -> coffee break
<bigjools> wgrant: that SQL change has picked up 7k5 rows... need to check it although the PPA count itself seemed sane
<wgrant> Hmm.
<bigjools> one archive has got 5951 binaries in this state
 * bigjools stares at ubuntu langpack
<bigjools> schooltool-owners has got 1307
<wgrant> schooltool packages hundreds of zope bits and pieces.
<wgrant> Both have hundreds of arch-indep packages at a time.
<bigjools> yes so langpack is costing us 3 minutes in every publisher run!
<wgrant> I wonder if that is relevant.
<bigjools> I doubt it
<bigjools> hmmm
<bigjools> wgrant: yes there's a bug there I think
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (200): FIXED in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/200/
<LPCIBot> Project db-devel build (201): FAILURE in 0.54 sec: https://hudson.wedontsleep.org/job/db-devel/201/
<bigjools> binary published 2010-06-08, source deleted 2010-11-24
<wgrant> bigjools: Same series?
<bigjools> there was a massive upload of langpacks very recently
<bigjools> same series what?
<wgrant> Are the binary and source in the same series?
<bigjools> yup
<wgrant> :(
<bigjools> wgrant: so there could be a bug in domination of arch-indep :/
<bigjools> which is rather concerning to say the least
<wgrant> Can you give me some source and binary pub IDs for schooltool?
<bigjools> 403127/4325526
<bigjools> 1.5 year gap for that one!
<wgrant> bigjools: This can't be domination, because it's deletion.
<wgrant> Let's see...
<wgrant> It may have been done through the API.
<bigjools> sorry, I mean condemning
<wgrant> Since it was a mass-deletion of everything in Intrepid.
<wgrant> No, the binaries are still Published.
<bigjools> hrmph
<bigjools> right
<wgrant> I think someone may have presumed that SPPH.requestDeletion deleted the binaries too.
<bigjools> I told you I had man flu
<bigjools> yeah
<bigjools> nicely spotted
<bigjools> oh dear
<wgrant> Oh dear/
<wgrant> ?
<wgrant> What have I destroyed now?
<bigjools> nothing, I am just wondering how to fix the API so it's backwardly compatible
<wgrant> Does it need to be?
<bigjools> it needs to call PublishingSet.requestDeletion
<wgrant> Right.
<wgrant> Any API users calling SPPH.requestDeletion are broken.
<wgrant> I don't know of any regular users.
<wgrant> So let's just change it to make it work sanely.
<bigjools> however, we don't have a publishing set to work with in the API call
<bigjools> in the meantime I am going to run that SQL
<wgrant> Unexport ISPPH.requestDeletion, and export as requestDeletion a new SPPH method that calls PS.requestDeletion.
<wgrant> And yes, please run that SQL.
<bigjools> that won't really work
<wgrant> Oh?
<bigjools> PS.rD needs a list of sources
<bigjools> we can munge it
<bigjools> but that's horrible
<bigjools> I guess it's the cheapest thing for now
<wgrant> We have no other way to do it until the API redesign goes through.
<bigjools> yeah :/
<bigjools> cock
<wgrant> ?
<bigjools> the API is frustrating like this
<wgrant> Yes. But it will be fixed soon.
<wgrant> henninge: Hi.
<bigjools> wgrant: can you think of any scenario where SPPH.requestDeletion should not delete the bins too?
<wgrant> bigjools: Not through the API, no.
<bigjools> I'm going to have to make a new method and export it with the old name
<bigjools> yay...
<wgrant> Yep.
<bigjools> wgrant: yay for factoring.  requestDeletion is in an interface common to both SPPH and BPPH.... *cry*
<wgrant> bigjools: Yup :D
<bigjools> wgrant: we don't ever want people to delete just the binaries, do we?  I can un-export it from BPPH entirely
<wgrant> bigjools: We should probably leave it, for the NBS case.
<bigjools> wgrant: I hate it when you point out stuff like that :)
<wgrant> As do I.
<bigjools> yay, last publisher run was 5 mins
<wgrant> Awesome.
<wgrant> How many archives were considered?
<bigjools> well, 6 mins
<bigjools> 21
<bigjools> and 8 private ones
<wgrant> Hm. still a few.
<bigjools> well the trick is to see if they appear repeatedly
<bigjools> I shall check after fud
<wgrant> True.
<bigjools> ttfn
<wgrant> And I guess that's quicker now.
<StevenK> wgrant: Not that I'm aware of, why?
<wgrant> StevenK: db-devel was failing very oddly.
<wgrant> StevenK: Complaining that the branch was a repo, not a branch.
<wgrant> Among other things.
<StevenK> The bzr pull failed, doesn't sound like a hudson issue
<wgrant> That was the first one.
<StevenK> That's #201, #202 is still building
<henninge> wgrant: hi! ;)
<wgrant> henninge: Hi. I replaced the doctests as you requested in https://code.launchpad.net/~wgrant/launchpad/bug-680889-arch-wildcards/+merge/42723
<StevenK> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/e550d33ce1999c89bbdf2123b7a8c930.pack is redirected to https://launchpad.net
<StevenK> Sounds like a production issue
<henninge> wgrant: ah cool,looking
<StevenK> I suspect the next builds of db-devel were unclean due to the build slave
<wgrant> StevenK: Ah, of course.
<StevenK> wgrant: Do you use Hudson a lot just because you don't have buildbot access? :-)
<wgrant> StevenK: Yes, but it also spammed the channel a lot earlier.
<henninge> wgrant: very good! And it is also so much clearer what is happening. ;)
<henninge> wgrant: r=me
<wgrant> henninge: Oh yes.
<wgrant> I wanted to do it.
<wgrant> But as I said I'm not a huuuuge fan of mixing them into the same branch.
<wgrant> henninge: Could you please throw it at EC2?
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 also need EC2ing, if someone has a moment.
<henninge> wgrant: Oh, one thing. Shouldn't there be a test for just "foo", i.e. an invalid arch?
<henninge> wgrant: sure, I can do that.
<henninge> wgrant: or is that the same as "kfreebsd-hppa" ?
<wgrant> henninge: It's already covered in a few places, perhaps most directly by testThreeArchitectures
<henninge> ok, fine ;)
<henninge> wgrant: argh, I just noticed a formal error in the doc test.
<henninge> sorry
<henninge> (for voicing approval prematurely)
<wgrant> What's the issue?
<henninge> wgrant: the schema for test method names is "test_methodName_extra_condition"
<henninge> so, in this case "test_determineArchitecturesToBuild_single_arch" etc.
<wgrant> I like to pretend that that rule doesn't exist, since it is inconsistent with everything else.
<henninge> ;-)
<wgrant> determineArchitecturesToBuild is redundant there, since it's already in the class. But you have a point about underscores rather than camelCase.
 * wgrant fixes.
<henninge> wgrant: right, since you are testing just that one method, it's not needed in the method name.
<henninge> thanks
<henninge> TestStyleGuide says exactly that ;-)
<henninge> (method name is not strictly needed)
<wgrant> henninge: Names changed.
<henninge> wgrant: cool, thanks a lot!
<wgrant> henninge: No, thank you.
<henninge> ;-)
<henninge> wgrant: don't touch the branch anymore, I will land directly from there. ;)
<wgrant> henninge: Great.
<wgrant> Less great.
<henninge> wgrant: don't touch the branch anymore, I will land directly from there. ;)
<henninge> wgrant: http://ec2-184-72-77-59.compute-1.amazonaws.com/
<wgrant> henninge: Thanks.
<wgrant> henninge: Did you end up sending off those other two as well?
<henninge> erm
<henninge> which other two ... ?
 * henninge must have forgotten about those.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 also need EC2ing. You didn't review them, but I thought you might be able to throw them at EC2 while you were at it.
<henninge> sure, np.
<wgrant> Thanks!
<henninge> wgrant: http://ec2-50-16-60-12.compute-1.amazonaws.com/
<henninge> wgrant: and finally http://ec2-75-101-182-41.compute-1.amazonaws.com/
<james_w> testing the API on qastaging is a bit hampered by caching of the wadl
<gary_poster> adeuring: do you know enough to answer pitti's question at the bottom of https://bugs.launchpad.net/launchpad-foundations/+bug/395960 (in which he asks if that change was supposed to fix bug 620458)?  I'm pretty sure the answer must be "no," but I don't have context to reply.
<_mup_> Bug #395960: proxying user supplied libarian files via the launchpad appserver domain has security and performance issues <librarian> <qa-ok> <Launchpad Foundations:Fix Released by lifeless> <https://launchpad.net/bugs/395960>
<_mup_> Bug #620458: cannot access attachments of private bugs any more <qa-ok> <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <OEM Priority Project:New> <https://launchpad.net/bugs/620458>
 * adeuring is looking
<gary_poster> thanks
<bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: meeting reminder
<bigjools> ta
<gary_poster> thanks
<adeuring> ok
<jtv> bac: I'm not here, sorry.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (202): FIXED in 3 hr 11 min: https://hudson.wedontsleep.org/job/db-devel/202/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12023
<LPCIBot> included.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=368600] Store and report database patch
<LPCIBot> application times.
<bdmurray> james_w: have you done any writing to specifications with the API?  I'm getting a 401
<james_w> bdmurray: I haven't. What are you attempting to modify?
<bdmurray> james_w: a work item in the whiteboard
<james_w> Hmm, I'll take a look after lunch
<bdmurray> james_w: Its working for me now
<james_w> good
<dobey> do launchpad teams end up as unix groups, or as users, on the server?
<jelmer> dobey: no, they just exist in the database
<mwhudson> mmm do we match revisions to authors by case insensitive email address or case sensitive?
<dobey> jelmer: how do permissions get handled on the filesystem for pushing branches and such? is that all done on the client via the xmlrpc check that happens before the actual pushing in bzr?
<jelmer> dobey: no, it's done server side
<james_w> how does one go about getting a nodowntime deployment?
<james_w> There is a set that the deployment report says can be deployed (admittedly containing only a single revision), and it would be spiffy to have that revision available
<jelmer> hey james_w
<james_w> hey jelmer
<dobey> jelmer: hrmm. via the launchpad server bzr plug-in somehow?
<jelmer> dobey: a custom ssh server
<mwhudson> it's the custom bzr transport really
<jelmer> james_w: I think there's a spec for it on the wiki, but IIRC it's basicallt that it it needs to be listed on the production status page and approved by a team lead
<jelmer> james_w: and your revision has to be qa-ok/qa-untestable of course
<james_w> ok
<james_w> it's already qa-ok, so I think I've done my part as the author
<jelmer> james_w: I assume there's a particular reason you need it to be rolled out soon ?
<james_w> jelmer, it's the final piece of the puzzle before we can make use of https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43136
<dobey> mwhudson: hrmm, i'm not really seeing much difference between bzr push lp:foo and bzr push bzr+ssh://foo.com/~user/foo/trunk, in terms of how the ssh bit works on the client side. but i can't really tell what happens on launchpad.net when i push lp: to it. and i'm trying to get an idea of how the filesystem layout works for bzr branch storage (where they get written to on disk, and how the permissions are handled)
<mwhudson> dobey: bzr has this abstraction called a transport
<dobey> right
<mwhudson> dobey: a bzr smart server process interacts with the underlying branch data via a transport
<mwhudson> on launchpad, the transport is not the LocalTransport that just read & writes to the obvious places on disk, but a custom thing that (a) checks the access control aspects
<mwhudson> and (b) translates the paths to a location based on branch id
<jelmer> james_w: If you just want it to go out with the next rollout of revisions, there's nothing you have to do except make sure your revision is landed and qa'ed.
<mwhudson> so a request to write to /~dobey/+junk/awesome/.bzr/repository/pack-names say
<james_w> jelmer, right, I'd just like it to be sooner rather than later :-)
<mwhudson> is mapped, after some checking to something like /srv/bazaar.launchpad.net/mirrors/00/00/43/00/.bzr/repository/pack-names
<dobey> ok
<dobey> thanks
<mwhudson> dobey: the code is in lp.codehosting.vfs if you're _really_ curious :)
<dobey> mwhudson: ah ok. yes, i am. i was poking through the server-side bzr plug-in in the launchpad tree, and the client smart/ssh code, and not getting much of anywhere
<mwhudson> dobey: so the magic in the server-side plugin you can find by searching for lp_transport and lp_server
<dobey> yeah i was looking at the lp-serve command, and figured out that the client was using the same "bzr serve" over ssh anyway, so got a bit confused. i'll look through the vfs bits later though :)
<dobey> should i bug you guys about some weirdness with PPA buildd issues, or losas, or what?
<mwhudson> dobey: although the client asks the ssh server to run the same command as on any other server, that's not actually the command that gets run
<mwhudson> that's in ... er.. lp.codehosting.sshserver.session i think
<dobey> hmm, ok
<wgrant> Woah, all three branches landed first time.
<mwhudson> we must have disabled some tests by mistake
<lifeless> wgrant: lies! :P
<lifeless> dobey: ask the CHR in #launchpad; if they aren't on, a question on answers.launchpad.net/launchpad
<wgrant> Or just ask #launchpad in general, and someone will respond.
<wgrant> That will probably be me, but yeah.
<lifeless> wgrant: will your work address https://bugs.launchpad.net/soyuz/+bug/687554 already ?
<_mup_> Bug #687554: DistributionSourcePackage:+publishinghistory timeout <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/687554>
<wgrant> lifeless: No.
<wgrant> That's an interesting one.
<wgrant> Since they don't want it batched.
<wgrant> But it should be easy enough to get it fast.
<lifeless> its only 3.6 seconds of sql
<lifeless> lsprof time
<wgrant> 10x what it should be, but yeah, not too bad.
<wgrant> Gar.
<wgrant> I wanted to see how 12031 went on qastaging. But it just missed the last buildbot :(
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.12  | PQM open for business | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
#launchpad-dev 2010-12-09
<bac> thumper, rockstar, stub, mwhudson, stevek: reviewers meeting
<mwhudson> something in the bugs page seems to make firefox go insane :(
<mwhudson> js-wise
<lifeless> jml: another recipe bug for you - https://bugs.launchpad.net/launchpad-code/+bug/687623
<_mup_> Bug #687623: No ability to manually trigger a build 'like the daily build system' <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/687623>
<spm> thumper: spiv: would appreciate your thoughts here: we have ~ 10 requests against BRANCH:%2Bbranch/tsumego20k/1.0 but https://code.launchpad.net/~branch says no code?
<spiv> spm: %2B is +, not ~
<spm> Ah
<spm> wrong group. that's a start.
<spm> https://code.launchpad.net/tsumego20k looks more like it
<spiv> But there's no 1.0 series.
<spiv> There's a 'stable' series (with a 1.0 release).
<spm> hrm. and their branch is only 472K as well.
<spiv> So, requests for that branch are presumably wrong, and ought to give "branch not found".
<spm> lp:tsumego20k  as in
<spiv> they probably mean /stable rather than /1.0?
<spm> well. it gets worse. that, and another branch are eating memory. just got a swap alert. I'm going to have to big stick shortly.
<spiv> Oh and for added fun the stable branch appears to have a broken stacked-on target.
<spm> would that be causing the pain that codehost is experiencing?
<spiv> I wouldn't *think* so
<spm> ah. they have another: BRANCH:~goadict/tsumego20k/release-1.0
<spiv> But it could be... it's hard to be sure.
<spm> mwhudson: so gist is we have one, maybe 2 or 3 branches that are spinning doing "something"; and eating memory and CPU
<spiv> I don't know of any open bugs that would cause this sort of spinning now that codehosting is running bzr 2.2
<mwhudson> ah ok
<spiv> Er, 2.2.2
<mwhudson> spm: have you whacked them with that gdb thing?
<spm> no, wasn't game to just yet.
<spm> haven't done any whacking - just watching/gathering.
<mwhudson> k
<spm> https://pastebin.canonical.com/40699/
<spm> https://pastebin.canonical.com/40700/ for a process listing
<spm> the db-devel ones, while alarming to have a few, don't seem to be problematic.
<spiv> Huh.
<spiv> Some say "+branch", some say "%2Bbranch".  I wonder why.
<spiv> Probably a red herring for this issue.
<spm> the cpu/load spike seems to be coming down tho. so I'm strongly tempted to just let things resolve on their own.
<spm> well... load. not cpu. that's still flat out.
<mwhudson> that's a lot of processes
<mwhudson> i wonder which user 2978124 is
<mwhudson> probably launchpad-pqm
<spm> how do we find out? select * from person?
<mwhudson> y
<spm> too obvious that. if even a sysadmin can guess correctly. /me files a big for greater obscurity.
<spm> bug, too.
<spm> launchpad-buildbot
<mwhudson> ah ok, that makes some kind of sense too
<spm> so something baout those branches tho is driving codehost to 100% cpu for ages, which is bad. :-(
<spm> worth a pygdb on one?
<spm> haha. on codehost itself, and it's easier to copy the branch from my local pc up.
<mwhudson> hee hee
<mwhudson> i guess you could run bzr get /srv/.../00/0x/xx/xx if you coudl be bothered
<mwhudson> yeah, i reckon pygdb one
<mwhudson> the user on the other end must be bored already by now
<spm> or afk
<spm> oh that's a bad sign... the backtrace.py is not showing a whole lotta activity...
 * spm lets it be for a bit longer
<mwhudson> :/
<spm> mwhudson: I gave up. it never progressed beyond 'Thread 1' as output. trying a gcore.
<mwhudson> spm: :(
<mwhudson> spm: maybe just attach with gdb and run 'bt'
<mwhudson> the process will only be single threaded
<spm> sure
<spiv> mwhudson: not necessarily (but probably)
<spm> err. pebkac? $ gdb 23558 ; (gdb) bt ==> No stack.
<spiv> mwhudson: the insert_stream verb in the server spawns a thread as that was easiest...
<spiv> spm: gdb -p 23558 ?
<spm> bah
<spm> that's better. ta
<mwhudson> spiv: whee
<spm> oh wow. it looks almost like recursion hell
<spm> pls to save me from rtfm - the command to disable gdb paging?
<spm> set pagination off
<mwhudson> i guess that might explain why pygdb didn't work so well
<mwhudson> though it prints the stack as it goes
<spm> holy crap. I'm copping 50k/s of gdb output. and it's not stopping.....
<spiv> spm: be careful what you wish for!
<spm> reckon
<spm> glad I don't have "infinite" buffers any more, or this'd suck
<mwhudson> well this sounds like fin
<mwhudson> fun
<spm> https://pastebin.canonical.com/40701/ for 3 pages of so far
<mwhudson> whisky tango foxtrot!!
<spm> https://pastebin.canonical.com/40702/ next 4 pages (i think...)
<spm> i call busticated.
<spiv> Huh, this is an lp-serve process?
<spm> codehost?
<spm> yes
<mwhudson> spiv: yes
<spiv> Ah, I see, it veers off into Twisted via lp.codehosting.vfs.transport.SynchronousAdapter
<spiv> So this is a bit disheartening :(
<spm> spiv: so it's your fault?
 * spm establishes random pin-the-blame-game early
<spiv> spm: well, I thought bzr 2.2.2 fixed this bug. :/
<spm> :-(
<spiv> Or rather, fixed one of the two issues that combined to cause it.
<mwhudson> oh, it's stringifying a traceback inside twisted's failure code
<spm> ah luverly, so we've maybe just discovered #3?
<spiv> It appears to be a error-handler-falls-over-and-recurses-into-the-error-handler death sprial.
<spiv> mwhudson: right
<spm> spiv: so stabby time, or more info would be useful?
 * spiv digs up the issue he thought he fixed.
<spiv> spm: hmm.  The traceback is probably enough.  Can you give me a minute to ponder?
<spm> sure. it's not wonderful, but getting this fixed is worth the pain
<mwhudson> spm: can you paste some more traceback actually?
<spm> easily
<spm> well.. easily but boringly. just sayin'
<mwhudson> just a couple more pages
<spiv> Argh, this really looks like the bug I fixed!
<mwhudson> i'm not sure if it's infinite recursion or just stupidly deep recursion
<spiv> repr of NotBranchError
<spm> https://pastebin.canonical.com/40703/
<spm> mwhudson: I don't believe there's a difference outside academia there :-)
 * spiv hmms
<spiv> Oh, *blah*
 * spiv thinks out loud
<spiv> NotBranchError guards against open_repository failing with unexpected exceptions
<spm> you think "*blah*"?? really!?!?!
<mwhudson> spiv: let me guess, it's partly twisted's fault?
<spiv> mwhudson: (yes)
<spiv> But open_repository is calling off into the lp VFS stuff
<spiv> Which calls into Twisted stuff
<mwhudson> anything traceback that has __getstate__ in it instantly makes me want to cry
<mwhudson> and punch glyph in the face in about 2001
 * spm hands mwhudson a tissue box, and starts playing a small violin
<spiv> Which thanks to the crumminess of Twisted's Failure class stringifies errors and tracebacks
<spiv> Which happens inside the lp codehosting VFS stuff, so my NotBranchError guard doesn't matter: Twisted tries to stringify a NotBranchError (whose bzrdir fails badly on open_repository)
<spiv> So off we go into the recursion.
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      146 / 5425  Archive:+index
<lifeless>       62 /  400  Distribution:+bugs
<lifeless>       61 /  233  BugTask:+index
<lifeless>       59 /    2  Person:EntryResource:retractTeamMembership
<lifeless>       38 /  419  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       20 /   28  DistroArchSeries:+index
<lifeless>       11 /   16  DistroSeries:+queue
<lifeless>       11 /    2  Cve:+index
<lifeless>       10 /   95  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        9 /    6  ProjectGroup:+milestones
<spiv> Roughly: repr(NotBranchError) -> open_repository -> codehosting VFS -> Twisted gunk -> repr(NotBranchError)
<wgrant> The fix for the top one should be on qastaging in a few minutes, hopefully.
<spiv> mwhudson: does that sound plausible?
<mwhudson> spiv: yes
<spiv> mwhudson: ok, now what can we do about it? :(
<mwhudson> spiv: make Failure throw away the traceback entirely?
<spiv> mwhudson: I *think* perhaps this isn't something bzrlib can sensibly fix.
<mwhudson> perhaps with a monkey patch?
<mwhudson> spiv: how can we reproduce this locally?
<spiv> mwhudson: IIRC the condition is something like a lookup on +branch/something/something causes a strange VFS error
<mwhudson> spiv: i don't quite understand why NotBranchError is getting raised in the smart server
<mwhudson> oh no, maybe that makes sense
<wgrant> mwhudson: Stacking, maybe?
<spiv> Because the codehosting VFS is returning that from a transport operation, or something odd like that?
<spiv> thumper may remember the details
<mwhudson> wgrant: stacking is mostly a client side thing though
<spiv> I'll see if I can dig out the relevant conversation from my logs
<mwhudson> spiv: is NotBranchError raised by BzrDir.open or something maybe?
<spiv> It's definitely an issue relating to how the server-side vfs translates stuff, maybe in weird cases like a dev focus stacked on itself, or something.
<spiv> IIRC it's at the point of trying to open the bzrdir that in LP would have the auto-stacking config
<spiv> IIRC +branch might be involved?  Or something?
<spiv> mwhudson: yeah, probably
<mwhudson> +branch shouldn't be involved unless someone has been editing .bzr/branch/branch.conf by hand
<spm> i'm about to break for lunch - need anything more before i run?
<lifeless> noone would be silly enough to do that :O
<spiv> spm: I think it's probably ok to kill before you run, if you want
<spm> spiv: okidoki
<mwhudson> spm: yeah, as spiv says
<spiv> mwhudson: see logs for this channel for Oct 11
<spiv> mwhudson: I think that's when I chatted with thumper about this initially
<spiv> just reviewing now
<spm> ugh. looks like the owner is kicking the branch/whatever operation(s) off again
 * spm has applied the sledgehammer :-(
 * mwhudson pokes around with sftp
<spiv> mwhudson: so in thumper's situation (which involved a patch he may have abandoned, so there may some red herrings here)
<mwhudson> i can't see anything unusual :(
<mwhudson> https://code.launchpad.net/~goadict/tsumego20k/trunk
<spiv> mwhudson: he encountered this problem on an open_branch HPSS call to ~user/proj (trying 'bzr revno ~user/proj/no-such-branch', I think)
<mwhudson> isn't a real branch
<mwhudson> hang on, let me check what it _is_
<mwhudson> spiv: hm
<spiv> mwhudson: default_stack_on = /~goadict/tsumego20k/trunk
<mwhudson> there's a bzrdir there, but no branch
<mwhudson> spiv: yeah, which is what one would expect
<spiv> mwhudson: in sftp://bazaar.launchpad.net/~goadict/tsumego20k/.bzr/control.conf
<mwhudson> spiv: right
<spiv> That is a branch AFAICT over SFTP?
<spiv> and not a stacked branch.
<mwhudson> spiv: parse error
<spiv> mwhudson: lftp bazaar.launchpad.net:~goadict/tsumego20k/trunk/.bzr> cat branch/format
<spiv> Bazaar Branch Format 7 (needs bzr 1.6)
<spiv> Why do you say that ~goadict/tsumego20k/trunk isn't a real branch?
<mwhudson> spiv: by mistake, sorry
<spiv> Ah.
<mwhudson> spiv: https://code.launchpad.net/~goadict/tsumego20k/stable
<mwhudson> spiv: ^ that one is just a bzrdir
<mwhudson> lftp mwhudson@bazaar.launchpad.net:/~goadict/tsumego20k/stable/.bzr> ls
<mwhudson> -rw-r--r--    1 1001     1001          141 Dec 09 02:21 README
<mwhudson> -rw-r--r--    1 1001     1001           35 Dec 09 02:21 branch-format
<mwhudson> drwxr-xr-x    2 1001     1001         4096 Dec 09 02:21 branch-lock
<mwhudson> the gdb trace is talking about ~goadict/tsumego20k/release-1.0/.bzr/repository though
<mwhudson> so maybe this stable branch is a red herring
<spiv> I don't think it is.
<spiv> My recollection is that accessing non-existent paths triggered this codehosting vfs issue.
<spiv> But maybe I'm wrong :/
<mwhudson> yeah, maybe that's it
<mwhudson> it's striking that all the problem processes are accessing paths that shouldn't work at all, like
<mwhudson> BRANCH:%2Bbranch/tsumego20k/1.0
<mwhudson> codehost
<mwhudson> the thing is of course that maybe the user is getting confused and flailing around creating and deleting things in the webapp
<spiv> mwhudson: also, the gdb trace includes stuff like:
<spiv> <Deferred at 0xa99a878  current result: <twisted.python.failure.Failure <class 'bzrlib.errors.NoSuchFile'>>>
<mwhudson> spiv: that's not so surprising really
<mwhudson> the synchronous launchpad transport wraps the asynchronous one
<spiv> mwhudson: argh, the data is changing from under us :)
<spiv> mwhudson: now ~goadict/tsumego20k/stable has a repo
<spiv> A bit odd:  _cache={'//~goadict/tsumego20k/release-1.0': ('BRANCH_TRANSPORT', {'writable': True, 'trailing_path': '.bzr/repository/format', 'id': 410572}, <float at remote 0x34d4cd0>)}
<mwhudson> writeable=True suggests that branch existed in the db at the time
<mwhudson> wow, i was a bit confused there -- was looking at launchpad.net not launchpad.dev :)
<mwhudson> of course launchpad.dev is impossible to use
<mwhudson> because of 1 miiiiiiiiiiiiiillion js files
<wgrant> devmode off
<wgrant> problem solved.
<mwhudson> GET /+icing/rev10399/yui/datatype/lang/datatype-date-format_it-IT.js
<mwhudson> GET /+icing/rev10399/yui/datatype/lang/datatype-date-format_it.js
<wgrant> Yes.
<mwhudson> COME ON!
<wgrant> And half of them OOPS.
<wgrant> So /var/tmp/lperr fills up.
<mwhudson> mostly 404ing
<mwhudson> where is devmode set?  configs/development/launchpad.conf?
<wgrant> That.
<mwhudson> $ du -sh /var/tmp/lperr/2010-12-09/
<mwhudson> 4.6M	/var/tmp/lperr/2010-12-09/
<wgrant> Yeah.
<mwhudson> spiv: well i don't know what's going on :/
<spiv> mwhudson: hmm
<mwhudson> spiv: i guess it might be interesting to see the bottom 100 lines or so of the traceback
<spiv> mwhudson: yeah
<spiv> mwhudson: also translateVirtualPath maybe should have a catch-all errback
<mwhudson> spiv: sounds plausible, without looking at the code or thinking terribly hard
<spiv> mwhudson: to avoid unexpected errors leaking out and confusing callers that expect only transport-related errors.
<spiv> I don't see any obvious routes for those to happen
<spiv> And I've just spent the last 30 min or so looking for one :)
<spm> bleh, they're still trying to get the code, or update or whatever. have sent the team members emails asking them to stop.
<mwhudson> spm: it would be good to know exactly what they're trying to do
<spm> mwhudson: spiv: would a copy of the raw branch(s) off crowberry be of any use to you guys in debugging? seeing as they're able to kill it time and again.
<spm> mwhudson: sure - do we have a formal bug yet? I'll send that to them and ask them to pls update with as much info as possible.
<mwhudson> spm: dunno, not sure
<spiv> spm: more use to mwhudson probably
<mwhudson> spm: how big are they?
<spiv> My local lp dev environment isn't quite functional
<mwhudson> spm: i haven't filed a bug
<spm> spiv: you're one up on me. don't have one at all. :-)
<spm> mwhudson: I was going to file "Weird shit happening with codehost" but felt it was lacking
<spiv> spm: "Error handling infinite recursion death spiral of doom" maybe?
<spiv> The "of doom" is a sure way to add some drama to a lacklustre title ;)
<spm> I like my subject better, nothing personal
<spiv> "Weird shit of doom happening with codehost" then :P
<spm> but yours is more technically accurate. I'll go with that
<spm> hahaha
<spiv> (A slow, painful doom...)
<mwhudson> weird-shit-of-doom sounds like a good bug tag
<spm> +1
<spm> mwhudson: the only one that works is tiny. http://bazaar.launchpad.net/~goadict/tsumego20k/trunk/files
<spiv> spm: for added laughs the user has been actively changing stuff while we've been looking
<spiv> Replacing an empty bzrdir with one with a repo etc.
<spm> well. trying to. I keep killing their processes off as it hurts
<spm> shame. codehost has dropped to #2 spot in firefox quick find for "filebug"
<wgrant> Does Soyuz win?
<spm> ha. no. most of my bugs are generically filed against launchpad these days. never quite sure where they go.
<lifeless> from mid jan 'launchpad'
<lifeless> one bug tracker. \o/
<wgrant> We'll see how that goes.
<spiv> wgrant: more successfully than lifeless' holiday, I hope... ;)
<wgrant> Indeed.
<spiv> lifeless: I'd suggest you visit some remote island with minimal internet access
<spm> spiv 1, lifeless 0
<spiv> lifeless: but you already moved to NZ ;)
<spm> spiv 3, lifeless 0
 * lifeless is on wow atm
<spiv> lifeless: that's more like it :)
<lifeless> so, I claim success.
<spm> spiv 3, lifeless -1
<lifeless> oi!
<spiv> Some people are so judgemental!
<spm> spm 1, spiv 0, lifeless -1
<lifeless> s/ w+!/sysadmins!/
<lifeless> wow
<lifeless> found the stone core
<spm> someone has to be. it's a burden that we take upon ourselves to spare the lesser folks aka developers
<lifeless> first quest in there...
<lifeless> 115K xp
<spm> https://bugs.edge.launchpad.net/launchpad-code/+bug/687653
<_mup_> Bug #687653: codehost error handling infinite recursion death spiral of doom <canonical-losa-lp> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/687653>
<wgrant> lifeless: https://qastaging.launchpad.net/~yavdr/+archive/stable-vdr/+packages is promising. 4s.
<wgrant> Ah, 2s with hot cache.
<wgrant> Not too bad.
<wgrant> OOPS-1804QS12
<lifeless> wgrant:
<lifeless> SQL time: 16441 ms
<lifeless> Non-sql time: 4324 ms
<lifeless> Total time: 20765 ms
<lifeless> Statement Count: 50
<lifeless> wgrant: also there are two repeats of a 1000ms query
<wgrant> Hmm.
<wgrant> A COUNT()?
<lifeless> 2203410171017SQL-launchpad-main-slave(SELECT SourcePackagePublishingHistory.archive, SourcePackagePublishingHistory.component, SourcePackagePublishingHistory.datecreated, SourcePackagePublishingHistory.datemadepending, SourcePackagePublishingHistory.datepublished, SourcePackagePublishingHistory.dateremoved,
<lifeless> ...
<lifeless> SourcePackagePublishingHistory.id, DistroArchSeries.architecturetag) EXCEPT (SELECT SourcePackagePublishingHistory.archive,
<wgrant> Oh, that one.
<LPCIBot> Project db-devel build (206): FAILURE in 13 min: https://hudson.wedontsleep.org/job/db-devel/206/
<bigjools> morning all
<wgrant> Morning bigjools.
<wgrant> We has a regression.
<wgrant> Which I already had a one-line branch to fix...
<wgrant> Without knowing about it.
<bigjools> wgrant: do tell
<wgrant> bigjools: Bug #687662
<_mup_> Bug #687662: Upload processor attempts to verify hashes against expired files <Soyuz:New> <https://launchpad.net/bugs/687662>
<bigjools> how did that happen?
<wgrant> Hmm?
<bigjools> oh, that change for getFile
<wgrant> Yeah.
<bigjools> do you think more pairs of eyes would have caught that?
<wgrant> Who knows.
<bigjools> wgrant: what affect elsewhere will your fix cause?
<wgrant> bigjools: It'll fix the +files/foo.orig.tar.gz 404. It could also impact other A.getFileByName callsites, but I doubt any rely on this behaviour, what with expired LFAs being useless and everything.
<bigjools> wgrant: right
<bigjools> wgrant: whack up an MP and let's get it landed
<wgrant> bigjools: MP is already there.
<wgrant> Oh. Branch is not linked.
<bigjools> yeah
<wgrant> Fix-ed.
<bigjools> woo JS regression, the bug page says "remove assignee" when there isn't one
<bigjools> wgrant: you've got all pt_br
<wgrant> bigjools: WFM
<bigjools> s/got/gone/
<bigjools> wgrant: the test should not be expanding the doctest, would you mind making a unit test?
<bigjools> test_archive.py
<mrevell> Hello
<wgrant> bigjools: k
<wgrant> bigjools: Should I take out the whole doctest while I'm at it? It's short enough.
<bigjools> wgrant: be my guest
<bigjools> the test style in test_archive should be obvious
<wgrant> Yeah, I've already added a few to it.
<adeuring> good morning
<henninge> Hallo adeuring!
<adeuring> moin henninge
<henninge> So, I am trying to update sample data that is used in tests.
<wgrant> Uhoh.
<henninge> I know, I should rewrite the test to not use sample data, but ...
<henninge> ... I want to finish this branch today. ;-)
<henninge> Anyway, I ran the migration script locally that updates the data the way I need it.
<wgrant> You need to run it on launchpad_ftest_playground.
<henninge> Did "make newsampledata" and updated current.sql and current-dev.sql.
<wgrant> Then make newsampledata.
<henninge> oh
<henninge> hm
<henninge> what do I get then?
<wgrant> newsampledata.sql and newsampledata-dev.sql, or something like that.
<wgrant> Then you clobber current(-dev).sql with those.
<henninge> Interesting. I just checked the (changed) current(-dev).sql that I have and what I did only changed current-dev.sql but not current.sql.
<wgrant> Right, you ran it on launchpad_dev, not launchpad_ftest_playground.
<henninge> I did not know that.
<wgrant> You may need to run with LPCONFIG=test-playground
<henninge> How do I ...
<henninge> .. thanks ;)
<wgrant> Oh yeah, thanks for running those three branches last night.
<wgrant> They all passed and landed first time!
<wgrant> This hasn't happened in many months.
<henninge> :-D
<henninge> Looking good, let's see if my tests passes now ...
<henninge> Hooray! ;)
<wgrant> Excellent.
<bigjools> wgrant: I had a thought
<bigjools> your change to getFileByName will revert us back to the old situation
<wgrant> Not entirely.
<bigjools> well pretty much, as soon as a file expires you can re-upload it
<wgrant> Right. We cannot prevent that.
<wgrant> Because somebody put the hashes in the LFC.
<bigjools> we need to
<bigjools> which was stupid
<wgrant> Yes.
<wgrant> It will stop the primary archive case.
<wgrant> And that is the one we really care about.
<bigjools> we care about people screwing up the PPA publisher too
<wgrant> They can't do that.
<wgrant> Since the files will have expired, the old source can't be copied any morew.
<bigjools> I'll have to think about it
<bigjools> my manflu is blocking rational thought
<wgrant> My fix makes us a quite a bit better than we were before. And it's as good as we can get without changing the data model.
<wgrant> I really wish people would think about what they're doing before they start irrevocably deleting data.
<bigjools> hahaha
<bigjools> LP has a great history of not deleting anything
<wgrant> Yes.
<bigjools> The librarian has a girth that rivals Ron Jeremy
<wgrant> Sure, and we need to delete things from it.
<wgrant> But there are better ways.
<wgrant> Like not deleting the hashes.
 * bigjools is filing a bug about that right now
 * wgrant makes a note to check it in a decade.
<bigjools> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/687752
<_mup_> Bug #687752: It's impossible to check a librarian file's hash once it's expired <Launchpad Foundations:New> <https://launchpad.net/bugs/687752>
 * bigjools notices that gary_poster is not a Foundations bug contact :)
<wgrant> Does he read the ML, perhaps?
<wgrant> Oh I hate doctests.
<lifeless> wgrant: so your fix looks good?
<bigjools> wgrant: I guessed it wouldn't be long before the "no ui" whingers started on the ppa stats bug
<wgrant> lifeless: For which?
<lifeless> Archive:+index
<wgrant> lifeless: It seems to behave OK on qastaging now.
<lifeless> cool
<wgrant> Not great.
<bigjools> lifeless: you do a really bad impression of someone who's on holiday :)
<wgrant> But I will look at that more when I don't have to pester too many people.
<lifeless> bigjools: I spent all day playing WoW :)
<bigjools> yes I know someone else who took holiday to do that :)
<lifeless> bigjools: the reason I take big blocks of holiday is it takes me ages to spin down and forget about work.
<lifeless> bigjools: 2 weeks in is about where I actually start to feel like I'm on leave
<bigjools> maybe disconnecting from IRC would help? :)
<lifeless> bigjools: I have many non work interests I wish to be on IRC for
 * wgrant searches for the banhammer.
<wgrant> bigjools: New tests are up, this time without conflicts.
<bigjools> bonus
<jml> lifeless: last time I went on leave, I also stayed on IRC but deliberately left many work-related channels.
<jml> lifeless: I found that helped
 * jml isn't really here
<henninge> Does anybody have an idea what this is about?
<henninge> http://paste.ubuntu.com/541413/
<maxb> traceback header with no traceback? thats a bit odd
<wgrant> maxb: Is there a librarian running?
<wgrant> Er, henninge ^^
<henninge> wgrant: oh, you mean an old process?
<henninge> yes :(
<wgrant> Hmm.
 * henninge slaps head
<wgrant> Looks like the new librarian fixture needs work.
<henninge> yes, possibly. But I just remembered that I had this issue before after forcibly terminating a test run.
<henninge> but I agree that something like this should be detected
<henninge> Tests are running happily now :)
<deryck> Morning, all.
<gary_poster> bigjools: I get those emails somehow or other
<bigjools> gary_poster: maybe you're subscribed to lp bug
<bigjools> s
<gary_poster> maybe so
<benji> mthaddon: I'm working on the script to run the LP tests in the new tarmac-based world and would like to write up how to set up the environment it needs; do you know of any server setup documentation for the current buildbot machines?
<mthaddon> benji: otp
<benji> mthaddon: thanks, no rush
<EdwinGrubbs> allenap: hi
<allenap> EdwinGrubbs: Hi there.
<allenap> EdwinGrubbs: I wrote down a kind of rationale for BugSubscriptionInfo: http://pastebin.ubuntu.com/541503/
 * EdwinGrubbs looks
<EdwinGrubbs> allenap: by "snapshot value factory", do you mean that getDirectSubscriptions() might return an existing value?
<EdwinGrubbs> allenap: what do you think the difference is between this solution and pre_iter_hook? Are you planning on adding more stuff to the BugSubscriptionInfo, which I just don't get to see yet?
<allenap> EdwinGrubbs: BugSubscriptionInfo is designed to work with a bug snapshot, so that (Zope) subscribers can find out deltas in subscriptions without having to issue many queries.
<EdwinGrubbs> allenap: do you think that there would be a case in the future that you would need to batch the results of getDirectSubscriptions?
<allenap> EdwinGrubbs: Some big queries are being hit 7 or more times in a single page request, when they only need to be executed twice.
<allenap> EdwinGrubbs: I doubt we'll ever have that many subscribers.
<allenap> direct subscribers.
<allenap> EdwinGrubbs: What would the pre_iter_hook do in this case?
<EdwinGrubbs> allenap: oops, I meant that pre_iter_hook would eliminate the need for BugSubscriberSet, not BugSubscriptionInfo. pre_iter_hook would take the place of the self.subscribers call made before returning BugScriptionSet.sorted.
<EdwinGrubbs> btw, those are two sentences, although it looks like the period is just separating a class and an attribute.
<allenap> EdwinGrubbs: Okay :) Sorry for being slow, my other half is badgering me for things at the same time.
<EdwinGrubbs> no problem
<allenap> EdwinGrubbs: A pre-iter hook when fetching the subscriptions would work, so it would mean 2 queries when fetching subscriptions. Might not be a bad thing though, because the person/subscriber is almost always referenced.
<allenap> EdwinGrubbs: That would make the implementation of BugSubscriptionSet and StructuralSubscriptionSet a bit simpler, but only by the same amount that BugSubscriptionInfo gets more complex.
<allenap> EdwinGrubbs: I don't think it removes the usefulness of BugSubscriberSet, because that's useful for its sorted property.
<EdwinGrubbs> allenap: sorry, the standup got delayed to just now.
<allenap> No worries :)
<EdwinGrubbs> allenap: the potential benefit of pre_iter_hook that may not apply here is that it only runs the main query and the pre_iter_hook query when it is iterated over. The BugSubscriptionSet runs the first query immediately to turn it into a frozenset, and then it runs the second query if the BugSubscriptionSet.sorted is used.
<EdwinGrubbs> allenap: I'm wondering what the benefit is to putting the results in a set and then putting them into a sorted list. Do you use the set directly someplace else?
<allenap> EdwinGrubbs: It's necessary to identify different subsets of subscribers. There's the obvious ones like direct and duplicate subscribers, but then there are duplicate-only subscribers (which I've added in a later branch), also notified subscribers, indirect subscribers. Many of these are remixes of the simpler subscription/subscriber sets.
<allenap> EdwinGrubbs: I could do these as UNION/EXCEPT queries, but the complexity shoots up.
<allenap> The reason it shoots up is because there are BugSubscription records which are not compatible with StructuralSubscription records, and because some of the queries involve joining through bugtask to target (i.e. product or productseries or ...).
<EdwinGrubbs> allenap: ok, I don't think I have any more questions about the sets. It just was bothering me to have an unusual implementation solve such a similar problem.
<EdwinGrubbs> allenap: I have a branch in pqm that effectively implements the same thing as load_people(). I'll not that in the mp with a few other small items. Thanks for explaining everything to me.
<EdwinGrubbs> s/not/note/
<allenap> EdwinGrubbs: Cool. I agree it's weird. I've tried something like this refactor before and a lot of subtle issues seem to crop up, so I started from the premise of having a sets-based API so that I could understand myself what was going on as I went along.
<gary_poster> jml, ping
<jml> gary_poster: hi
<gary_poster> hey.  Could matsubara and I pick your brain on mumble for a few minutes about some subunit/ec2 remote.py details?
<gary_poster> sorry, jml ^^^
<jml> gary_poster: sure. gimme a few seconds first.
<gary_poster> of course, thanks
<benji> mthaddon: when you get a minute; I have the script ready that will be the driver for the tests in the new tarmac-based SMM world; I think you're the one I should talk to about getting it installed
<mthaddon> benji: I'm past EOD I'm afraid - can you add the details to the RT?
<benji> mthaddon: gladly; I haven't done anything with RTs yet, how do I do that?  (is there something I should read on the RT system?)
<mthaddon> benji: I've added you as a cc to the ticket, and have sent you a reply - you should be able to just reply to the email
<benji> mthaddon: great, thanks
 * jml gone
<lifeless> gary_poster: jml has run, can I help ?
<gary_poster> lifeless, he was able to get in touch with us before he ran.  thank you very much!
<lifeless> ok, cool
<lifeless> if you're doing subunit stuff, it would be cool to wire up SubunitStream ( the table ) to the API for uploads.
<lifeless> I'd just love ec2test to add a stream to the branch it tests.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (207): FIXED in 3 hr 35 min: https://hudson.wedontsleep.org/job/db-devel/207/
<james_w> deryck, hi, I'm interested in what you say about not liking testing pages. You say that you have talked about this previously. Was that on a public mailing list?
<deryck> james_w, yes, several threads (2-3 maybe?) on launchpad-dev.  about ui, ajax, and testing all this.
<james_w> deryck, ah, specifically where js gets involved?
<deryck> james_w, mostly about that, yes.  though I do have some criticisms of our page tests in an old proposal thread of mine
<deryck> but that's probably less about testing web pages and more about bad tests generally
<deryck> :-)
<james_w> down with bad tests!
<james_w> deryck, have you had a look at soupmatchers that is now available in the LP testing infrastructure thanks to rockstar?
<deryck> james_w, I haven't yet, no.  though rockstar did rave to me about it.
<james_w> deryck, cool. I'd be interested in what you make of it if you find time to have a play with it
<deryck> james_w, ok, cool.  I will definitely look at it and let you know
<james_w> it's static html only, but I think it could be a lot better than the current approach of extracting text from elements and printing it etc.
<LPCIBot> Project devel build (285): FAILURE in 3 hr 12 min: https://hudson.wedontsleep.org/job/devel/285/
<LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Update testtools to r151.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][no-qa] Use the stdlib multiprocess module to
<LPCIBot> run WADL generation in parallel subprocesses.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=638924] Fixed timeout on ubuntu milestone
<LPCIBot> +index page.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=677511] Fix "invited members" link created by
<LPCIBot> javascript.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=193870] The bug subscriptions portlet for
<LPCIBot> StructuralSubscriptionTargets has been updated to improve readability.
#launchpad-dev 2010-12-10
<wgrant> Can someone please throw https://code.launchpad.net/~wgrant/launchpad/bug-522800-getFileByName/+merge/43159 at EC2? Julian ran it overnight with one failure, which I've fixed.
<LPCIBot> Project devel build (286): STILL FAILING in 3 hr 12 min: https://hudson.wedontsleep.org/job/devel/286/
<LPCIBot> Launchpad Patch Queue Manager: [bug=620458,
<LPCIBot> 629804] [r=gmb][ui=none][bug=629804] Back out hack to serve
<LPCIBot> restricted files directly from the internal restricted librarian port.
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       68 / 4938  Archive:+index
<lifeless>       44 /    0  Person:EntryResource:retractTeamMembership
<lifeless>       42 /  190  BugTask:+index
<lifeless>       37 /  307  Distribution:+bugs
<lifeless>       24 /  263  POFile:+translate
<lifeless>       14 /   18  DistroSeries:+queue
<lifeless>       11 /  367  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       11 /   39  Milestone:+index
<lifeless>        9 /   79  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        9 /   33  RootObject:+login
<wgrant> lifeless: Hmm, that's very odd.
<poolie> i hope that's a bot not really robert :)
<mwhudson> you only think there's a difference
<poolie> :)
<lifeless> should I feel complemented or insulted
<lifeless> wgrant: whats odd abou tit
<wgrant> lifeless: So few Archive:+index timeouts.
<lifeless> wgrant: we've had the odd 'good' day
<lifeless> wgrant: the soft timeouts are pretty consistent - many K
<wgrant> lifeless: True.
 * wgrant still needs someone to EC2 that regression-fix branch.
<lifeless> is it all gtg? commit message set etc etc etc
<poolie> does "number of affected users" now total up across dupes?
<adeuring> good morning
<mrevell> Hola
<wgrant> ... and the award for the revision with the most reviewers goes to r10047.
<bigjools> jml: hi, I'll be ready for our call in 5 minutes
<jml> bigjools: np
<jml> bigjools: I'm on the strategerie on mumble
<bigjools> jml: ok, I only just got back from my hospital appt.  I now need drugs and coffee.
<jml> bigjools: understood.
<deryck> Morning, all.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (287): FIXED in 3 hr 36 min: https://hudson.wedontsleep.org/job/devel/287/
 * beuno waves at deryck 
<beuno> are but attachments on private bugs, private?
<beuno> IIRC, there is such a thing as a private librarian
<deryck> hi beuno.  was on call, sorry.
<deryck> beuno, they are indeed truly private now.  but that's a source of great pain at the moment. ;) :)
<beuno> deryck, pain for whom?  :)
<deryck> beuno, private attachments aren't available over the api at the moment.  accept for an exception made for apport and the retracers.
<deryck> except, rather
<beuno> deryck, ah, gotcha
<beuno> I don't think we need to get them through the api
<deryck> beuno, btw, I'm very supportive of the cdn idea and getting a yui loader going. willing to help rockstar as he works on it.
<deryck> beuno, we need it desperately on lp
<beuno> deryck, awesome, I'm going to push for something canoni-wide if it gets traction, otherwise build something for u1 and slowly push it out for other teams
<deryck> beuno, yeah, we'll definitely take it up.  the 1.3Mb js file is killing us now.
<beuno> deryck, still carrying mochikit?
<deryck> beuno, yes, we are.  but I don't think it adds much.  yui itself is 1Mb.  lazr-js is the other largest bit.
<beuno> deryck, so, FWIW, I manually build a YUI combo file and brought it down to ~500kb
<beuno> instead of bringing in all of the -min files in YUI
<deryck> beuno, I had a little play at that and didn't have much luck.  but I could be including something we really don't need.
<deryck> I'm working on this over the next several weeks, so I look at that again.
<beuno> deryck, well, what I did, is use their online combo generator
<beuno> http://yui.yahooapis.com/combo?3.2.0/build/yui/yui-min.js&3.2.0/build/oop/oop-min.js&3.2.0/build/event-custom/event-custom-min.js&3.2.0/build/attribute/attribute-min.js&3.2.0/build/pluginhost/pluginhost-min.js&3.2.0/build/base/base-min.js&3.2.0/build/classnamemanager/classnamemanager-min.js&3.2.0/build/dom/dom-min.js&3.2.0/build/dom/dom-style-ie-min.js&3.2.0/build/event/event-min.js&3.2.0/build/node/node-min.js&3.2.0/build/widget/widget-min.j
<beuno> oooooops!
<beuno> sorry
<beuno> that covered 95% of yui
<beuno> 476kb
<beuno> so I use that as the YUI file, and tack on the rest of our js
<beuno> I have *no* idea why it differs so much from compressing it from the tree
<beuno> you can play with it here: http://developer.yahoo.com/yui/3/configurator/
<rockstar> deryck, could you pipe in on the list about the CDN as well then?
<beuno> rockstar, I was thinking we could also just proxy yui's cdn
<beuno> with https
<rockstar> beuno, maybe, but then we can't get to lazr-js or our own deps.
<beuno> right
<deryck> rockstar, yeah, I was planning to.
<EdwinGrubbs> deryck: how do I attach a bug to a series as opposed to a milestone in the UI?
<deryck> EdwinGrubbs, target to release link.
<sinzui> help. I created a new error type and provides a useful message for users, but the page shows the errors docstring. the TALES is just "structure error"
<EdwinGrubbs> thanks
<deryck> EdwinGrubbs, np
<jcsackett> salgado: ping.
 * deryck is getting excited about the BugJam next week
<Ursinha> abentley_, hi
<Ursinha> or abentley, hi
<abentley> Ursinha, hi.
<sinzui> jml, mumble?
<jml> sinzui: yes
<Ursinha> abentley, about bug 688092, do you have an example of how qa-tagger failed when you tried running that locally?
<_mup_> Bug #688092: It's too hard to start hacking on qa-tagger <qa-tagger:New> <https://launchpad.net/bugs/688092>
<abentley> Ursinha, not offhand, but I can get one for you.
<Ursinha> thanks abentley, that would be useful
<Ursinha> when you create something it's hard to identify things you should explain to others
<abentley> Ursinha, sure.  I've been there.
<salgado> hi jcsackett
<jcsackett> hi salgado. i'm working on the distribution mirror prober, and it looks like you've been the busiest in it.
<jcsackett> i'm wondering if you can help me figure out some issues i've introduced in trying to fix a bug.
<jcsackett> bug 681034
<_mup_> Bug #681034: UnknownURLScheme raised running distributionmirror-prober script <oops> <Launchpad Registry:In Progress by jcsackett> <https://launchpad.net/bugs/681034>
<salgado> jcsackett, sure, I can try.  although I haven't touched it in a while.  can it be in 15'?
<jcsackett> salgado: fifteen works just fine. gives me time to get stuff together so i can ask better questions. :-)
<salgado> cool. :)
<pcjc2> hen running a local launchpad instance (for bug import testing), I want to wipe it and start again. make schema has wiped most things, but I can't run the bug import script a second time - it claims the bugs have already been imported
<pcjc2> http://launchpad.dev:58080/93/sB5xaCAHZcRjyaqsZrDH2sV7pCj.txt (the bug has already been imported)
<salgado> jcsackett, I'm ready
<jcsackett> salgado, awesome.
<jcsackett> so, the problem in the bug is that on the machine being probed, there is a redirect, which we can't really do anything about. but it's causing an oops because unsupported url's trigger an exception.
<jcsackett> i'm trying to change the prober to simply log the bad redirect so a human can look at it, and move on with triggering the oops.
<jcsackett> salgado: this was my naive attempt: https://pastebin.canonical.com/40796/
<jcsackett> the problem is that the prober system is more complex than i expected, and i can't seem to find a way to do this that escapes the redirect method without having a timeout across the tests for the prober. :-(
<jcsackett> so: short question: do you have any ideas of how to tackle this? sinzui suggested refactoring the prober to test redirection before actually doing it. i tried that as well, and simply caused further timeouts.
<salgado> jcsackett, can I see the diff as well?
<jcsackett> ah, yes, one sec salgado.
<jelmer> deryck: ^
<deryck> pcjc2, hey, there is a .pickle file somewhere in the tree you need to remove.  I think it's called bugmap.pickle.
<deryck> jelmer, thanks! :-)
<pcjc2> ok, cool
<pcjc2> bug-map.pickle
<pcjc2> thanks so much
<deryck> bzr st should turn it up.
<deryck> right, that's it
<jcsackett> salgado: https://pastebin.canonical.com/40800/
<pcjc2> need to ask some questions at some point about the possibility of munging inline "bug 1423312" from the old SF bug reports to match new LP numbers
<pcjc2> (Would require changes of code on the LP import scripts), or possibly just have the format converter pick up on "Bug 412312", and turn it into a string which won't get auto-linked to a random LP bug)
<_mup_> Bug #412312: Implement Songbird support <daemon> <songbird> <Panflute:Fix Released by kuliniew> <https://launchpad.net/bugs/412312>
<jcsackett> salgado: my sense tells me the issue i'm running into is the callback stuff and the interaction between the prober and all the twisted machinery behind it. but that may just be suspicion born of ignorance.
<deryck> pcjc2, you'll have to get any changes to the importer back upstream to us, since we'll actually run the import.  Or sed your export file to change the form of the old link.
<deryck> or old text, rather
<pcjc2> I understand
<pcjc2> Any changes which require mapping to new LP bug numbers will have to be within the import scripts run on the LP production servers. I'm just playing locally here to tweak the SF -> LP conversion as best I can without creating too much work for the LP admins
<salgado> jcsackett, I haven't touched this code in a while, but I suspect the timeout is because upon an UnknownURLScheme exception you don't do anything that cancels the delayed call that triggers the timeout (e.g. connect() or fail())
<salgado> jcsackett, can you do a self._cancelTimeout(None) before your logger.error() call?
<jcsackett> salgado: i think i tried that, but let me give it another go.
<salgado> also, self.redirection_count will always be greater than 0 there
<salgado> so you don't need the if/else
<jcsackett> salgado: good to know. the tests, however, still show a timeout error.
<salgado> jcsackett, ok, have you pushed your changes?  that way I can merge and see what the failure looks like
<jcsackett> salgado: sure, i'll push it up now.
<jcsackett> salgado: https://code.launchpad.net/~jcsackett/launchpad/redirects-681034
<jcsackett> salgado: the test in question is the test in question is test_redirectawareprober_fail_on_unknown_scheme; right now that asserts that an unknown schema url exception is raised, and instead a timeout is raised. win condition is that fails because NO exception is raised. then i will figure out testing the logging.
<salgado> jcsackett, I think I know what's going on
<jcsackett> salgado: lay it on me. do not spare my ego. :-P
<salgado> unlike I previously thought, just cancelling the timeout is not enough
<salgado> you have to callback() on the deferred (or errback())
<salgado> so you do have to fail(e) on UnknownURLScheme
<salgado> and on a layer above that you can catch the exception and not raise an OOPS
<jcsackett> hm.
<salgado> jcsackett, but we already have support for that.  see ArchiveMirrorProberCallbacks
<salgado> it does a failure.trap(*self.expected_failures)
<jcsackett> salgado: ah yes, i see.
<salgado> at first I thought you could add UnknownURLScheme to expected_failures
<salgado> but that's not a good idea
<jcsackett> no, i would need to create a new excpetion.
<salgado> because I think we want an OOPS raised when that exception is raised on the first connect() but not when it's raised in a redirect()
<salgado> so, yes, a new exception which you pass on to self.fail() on redirect()
<jcsackett> salgado: it doesn't look like ArchiveMirror uses the RedirectAware prober...the only thing using redirect is MirrorCDImageProberCallbacks
<jcsackett> salgado: that doesn't seem right to me, does it make sense to you?
<salgado> that is right
<salgado>         # According to http://lists.debian.org/deity/2001/10/msg00046.html,
<salgado>         # apt intentionally handles only '200 OK' responses, so we do the
<salgado>         # same here.
<salgado> I think that has changed recently, but it was intentional that the archive prober doesn't use the redirect-aware factory
<salgado> s/that/apt
<jcsackett> salgado: ah. so then the assumption in the bug about it being redirect isn't necessarily accurate, because the RedirectAware prober wouldn't have been involved.
<salgado> it was not an archive mirror that caused the OOPS
<salgado> https://server4.bremer-it.de/ubuntu///maverick/ubuntu-10.10-server-i386.iso
<salgado> that's a CD image mirror
<salgado> and the traceback shows it was on redirect()
 * jcsackett didn't understand what CD image mirror was about. i get it now.
<jcsackett> salgado: okay, so basically i can crib from ArchiveMirror to handle expected errors, and add that to CDImageMirror stuff.
<salgado> oh, of course.  now I see how I mislead you
<salgado> yes, that's correct
<salgado> MirrorCDImageProberCallbacks is the one you want to change
 * jcsackett nods.
<jcsackett> salgado: thanks so much!
<salgado> jcsackett, don't thank me before confirming it actually works. ;)
<jcsackett> salgado: fair. :-)
<jml> flacoste: ping
<flacoste> hi flacoste
 * flacoste talks to himself
<flacoste> jml: hi
<jml> flacoste: mumble!
<EdwinGrubbs> benji: do you know if there is a way to override devmode without changing the launchpad.conf or creating a new config directory specified by the LPCONFIG env var?
<benji> EdwinGrubbs: hmm, let me see
<benji> EdwinGrubbs: I don't see a way.  We could fairly easily add command-line config overrides to bin/run if needed.
<EdwinGrubbs> benji: do you want me to open a bug for that?
<benji> EdwinGrubbs: if it's something you need, sure!
<jml> g'bye all. See you again on the 20th.
<EdwinGrubbs> deryck: ping
<deryck> hi EdwinGrubbs
<EdwinGrubbs> deryck: I'm working on the milestone +index page for distros, projects, and project groups. These pages list the bugs assigned to the milestone that do not have a conjoined master. For project groups, it's possible that a bug is on a milestone one of the projects and on the devfocus series for another project? Would this count as having a conjoined master? The old code did not count it, but my optimization started doing it as a
<EdwinGrubbs> side effect.
 * deryck is reading, processing that....
<deryck> EdwinGrubbs, I honestly don't know if that counts as a conjoined master.  It shouldn't as I understand conjoined bugtasks, but there may be a bug there.
<deryck> EdwinGrubbs, or do you mean "is it okay if they're conjoined after this work?"
<EdwinGrubbs> deryck: I really don't understand the workflow around this to know why we don't want bugs attached to the devfocus series to show up on the milestone page. yes, I mean, "is it ok?"
<salgado> jcsackett, did it work?
<jcsackett> salgado: seems to. i'm refactoring some code to properly trap things and cleanup some other details, but this seems to be the right path.
<salgado> cool!
<jcsackett> sorry i didn't ping you earlier; got wrapped up in pursuit of the solution. :-)
<jcsackett> thanks again!
<salgado> np; glad it worked
<deryck> EdwinGrubbs, I don't know why we wouldn't want it either.  I think the bug should appear if a task has linked the milestone....
<deryck> EdwinGrubbs, as to your issue, are the two projects on different tasks on the same bug?
<EdwinGrubbs> deryck: yes, so the bug would show up on the milestone page for one of the projects but not for the other one.
<deryck> EdwinGrubbs, ah, that's fine with me.
<EdwinGrubbs> deryck: so, you don't think anyone will complain that milestone X on one of the projects has the bug, but milestone X on the project group doesn't because a differ project has it linked to the devfocus series?
<deryck> EdwinGrubbs, ah, right.  yes, that would be wrong.  hard to get my head around it.
<EdwinGrubbs> deryck: ok, that's fine.
 * deryck will brb, rebooting
<flacoste> mbarnett: still around?
#launchpad-dev 2010-12-11
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       79 / 4508  Archive:+index
<lifeless>       33 /  272  BugTask:+index
<lifeless>       29 /  312  Distribution:+bugs
<lifeless>       18 /    0  Person:EntryResource:retractTeamMembership
<lifeless>       13 /  195  POFile:+translate
<lifeless>        8 /  112  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        8 /   17  DistroSeries:+queue
<lifeless>        7 /   22  Archive:+copy-packages
<lifeless>        6 /   25  DistroSeriesLanguage:+index
<lifeless>        6 /    0  Archive:+admin
<pcjc2> can anyone offer tips on getting some mods I've made to my local LP instance back upstream - as a hosted branch perhaps
<pcjc2> I've got the default bzr checkout as described in the "Getting" instructions as the topic of this forum (along with some config changes I need to remove from the diff)
<pcjc2> I'm not familiar with bzr, only git
<wgrant> pcjc2: Commit them to the branch, then bzr push lp:~pcjc2/launchpad/SOME-BRANCH-NAME
<pcjc2> can I commit just certain file, like git add <files I want>
<wgrant> bzr commit somefile
<pcjc2> I seem to recall bzr has no "staging area" ceoncept
<pcjc2> (typo)
<wgrant> That's right.
<wgrant> You'd normally use 'bzr shelve' (like 'git stash') to "unstage" unwanted changes, or just give filenames to 'bzr commit'
<lifeless> you can also commit --exclude foo
<pcjc2> cool, thanks
<wgrant> Ah, didn't know that one.
<wgrant> Handy.
<pcjc2> https://code.launchpad.net/~pcjc2/launchpad/allow-empty-comments
<pcjc2> (Not quite there yet)
<pcjc2> I need that (or something like that) to import our bug history nicely. Too many <empty comment> placeholders without it
<lifeless> why not just skip them ?
<lifeless> wouldn't that be simpler ?
<pcjc2> because the comment contains an attachment
<pcjc2> and it is _really_ ugly to have "Attached file <blah> ....
<pcjc2> <empty comment>"
<pcjc2> Wasn't that we wanted a big string of otherwise blank comments ;)
<pcjc2> I've got a load of mods to the SF -> LP bug import script which might be useful to contribute back too
<pcjc2> Making a local cache of downloaded attachments (for when you run it 300 times with different mods ;))
<pcjc2> And some other things which are vaguely useful - such as stripping some SF cruft from some of the comments
<pcjc2> And some local things to our project, such as turning certain release "groups" into tags, or different bug statuses
<pcjc2> http://bazaar.launchpad.net/~pcjc2/launchpad/allow-empty-comments/revision/12044
<pcjc2> I'm about at the stage where I am ready to request a test import into staging
<pcjc2> but it looks so much nicer when imported with the above change
<pcjc2> meh - code update in progress on staging, so can't play
<pcjc2> https://code.launchpad.net/~pcjc2/launchpad/allow-empty-comments/+merge/43449
<lifeless> pjdc: we already support adding an attachment without a comment in the core
<lifeless> bah
<lifeless> pcjc2: ^ - is that what you're - ah yes, I se
<lifeless> e
<pcjc2> any chance of seeing that merged?
<lifeless> probably, but not today.
<pcjc2> Or the <empty commit> behaviour dropped all together?
<lifeless> I would personally prefer to see that
<pcjc2> I'm trying really hard to convince our other developers that LP is the way forward for bugs
<lifeless> so your change is uncontentious as is
<lifeless> I'm sure we can merge it
<lifeless> if you could add a test that it does really do what you want, that would be awesome
<pcjc2> but one is running of setting up a Bugzilla server. I wanted to get something for people to play with on staging, so I can make sure people like it
<lifeless> I think the script is tested already
<pcjc2> where do the tests live?
<lifeless> generally in $package/tests/test_something.py
<pcjc2> ok, found it, thanks..
<pcjc2> in general, given an XML file, what would be the lead time in getting it imported for people to play with on staging.launchpad.net ?
<pcjc2> (The comment issue is really cosmetic, so shouldn't stop people having a poke at it)
<lifeless> I'm not sure; however - the sysadmins, who need to run it, are not around in weekends except for emergencies
<pcjc2> also - as  a Launchpad coding noob.. how do I run the tests / run this particular test?
<lifeless> bin/test -t <regex>
<lifeless> e.g.
<lifeless> bin/test -t test_bugimport
<pcjc2> Who are the sysadmins? (Might even half know one... Chris Jones (Ng)?)
<lifeless> hes a gsa
<pcjc2> (I say know.. I fixed a video bug for him)
<pcjc2> gsa?
<pcjc2> general sysadmin?
<lifeless> next one thats up is spm on Monday in roughly this tz now
<lifeless> yeah
<lifeless> you need a losa - l* operational sysadmin
<lifeless> so, pop back in 24 hours and there should be someone that can assist getting an import on either staging or qastaging for you; and once they start on monday there is usually 24 hour coverage through to friday us afternoon
<pcjc2> I won't pretend to understand what a losa -l* ... what you just said.. is ;)
<lifeless> heh
<lifeless> I need to run, I'll rad backscroll when I pop back if you had more questions
<pcjc2> thanks for your help, it is much appreciated
<pcjc2> * think I get LOSA now
<pcjc2> launchpad operational system administrator ;)
<pcjc2> to late for me, clearly
<wgrant> It's been expanded to Launchpad/Landscape/U1/ISD, but yes.
<maxb> Do we have any remaining known bugs that cause builds to get stuck in the "Uploading build" status?
<maxb> I had it happen to me again today
#launchpad-dev 2010-12-12
<wgrant> I don't know of any.
<wgrant> Which build?
<maxb> https://launchpad.net/~mercurial-ppa/+archive/staging-stable-snapshots/+build/2092164
<wgrant> I guess it's probably a new directory rename race.
<wgrant> I'll get a LOSA to poke around on Monday.
<jelmer> yeah, they should all be gone by now
 * jelmer has a look
<jelmer> wgrant: oh, right.. you're finally allowed to ping losa's on Monday :-)
<wgrant> jelmer: More importantly, I can see logs.
<jelmer> wgrant: ah, yeah
<jelmer> maxb: I'm inclined to close bug 682430 as Won't Fix
<_mup_> Bug #682430: Sourceforge http: (no SSL) imports now fail <code-import> <Bazaar Subversion Plugin:New> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/682430>
<maxb> jelmer: Seems reasonable. The workaround of https is entirely adequate
<maxb> if any fix was to be attempted, it seems like it would be best to fix the svn client libs to allow limiting the use of a single persistent connection, than add various retry logic in places
<maxb> Or better, tell sf to stop being silly with their http connections :-)
<jelmer> maxb: Yeah, the latter seems the most reasonable.
<jelmer> Perhaps they have put this into place to kill long expensive interactions with their SVN server, but that seems silly given this will a) make people retry more often an b) use SSL, which is more expensive CPU-wise.
<jelmer> hmm, odd, one of my daily builds just failed with a chroot error
<jelmer> maxb: perhaps they're just closing idle connections earlier?
<jelmer> maxb: other than what you mentioned in that bug report did you see any particular symptons?
<maxb> no, nothing else
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       54 / 4108  Archive:+index
<lifeless>       35 /  139  BugTask:+index
<lifeless>       22 /  245  POFile:+translate
<lifeless>       16 /    0  Person:EntryResource:retractTeamMembership
<lifeless>       14 /  175  Distribution:+bugs
<lifeless>        8 /    0  BinaryPackageBuild:+retry
<lifeless>        7 /  100  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        7 /   13  DistroSeriesLanguage:+index
<lifeless>        5 /   39  Archive:+packages
<lifeless>        5 /   16  Distribution:+archivemirrors
<pcjc2> Hi, any particular reason I can't see the SSO blueprint specs?
<pcjc2> https://wiki.canonical.com/LaunchpadLoginService  -> Not allowed to view this page
<pcjc2> https://launchpad.canonical.com/Launchpad-SSO/infrastructurespecs#login -> Not allowed to view this page
<lifeless> wiki.canonical.com is staff only.
<pcjc2> I was trying to get to grips to how things were working
<lifeless> I don't know if those specs /need/ to be private
<pcjc2> Have been exporting my local dev instance over SSH to some testers.. One couldn't log on
<lifeless> #canonical-isd has some of those developers.
<pcjc2> Turned out to be a cookie problem though.. he was using a text based browser, W3M
<pcjc2> With a a patch to stop it rejecting some LP cookies, it worked for me when I tried. LP has a related bug: Bug#385702
<_mup_> Bug #385702: statistics dont work in replay mode <Return To The Roots:Fix Released> <https://launchpad.net/bugs/385702>
<pcjc2> Urm.. no
<pcjc2> Bug #59510 (The other was the Debian Bug # for the same issue)
<_mup_> Bug #59510: Can't log in with w3m due to bad cookies <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/59510>
<lifeless> also bug 523229
<_mup_> Bug #523229: The Continue button isn't selectable in w3m for sso login <iso-testing> <Canonical SSO provider:Won't Fix> <Launchpad Foundations:Triaged by gary> <https://launchpad.net/bugs/523229>
<pcjc2> I'm amazed just how nice the LP code is
<lifeless> why thanks :)
<pcjc2> Or rather, how detached from the nasties of writing HTML it is.. and how awesome storm seems
<pcjc2> I might even try doing some coding ;) - Any mileage in a drop-down expand for viewing patch attachments to bugs inline with the comments?
<lifeless> that would be lovely
<lifeless> assuming something sensible xss wise
<pcjc2> xss?
<lifeless> cross site scripting attacks
<pcjc2> ok, will have to get someone to review it if / when I've done it ;)
<lifeless> I suggest discussing the broad approach here or on the launchpad-dev mailing list - we
<lifeless> we've got some very clueful guys who can help
<pcjc2> thanks
<kees> hi! where can I find the code that manages the ppa.launchpad.net port 22 listener?
<lifeless> its called 'poppy' in the code base
<lifeless> whats up?
<elmo> no, it's not
<elmo> that's the ftp one
<elmo> he means the ssh based one
<lifeless> elmo: I thought they had common code
<elmo> I hope not
<elmo> the ftp one is zope based
<elmo> the ssh one is twisted
<lifeless> oh yeah
<lifeless> we should fix that
<lifeless> anyhow, find the tests for one, you'll find the tests for the other
<lifeless> kees: whats up?
<jelmer> kees: lib/lp/poppy/twistedsftp.py ?
<wgrant> They do share some stuff.
<wgrant> Thanks elmo.
<jelmer> 'morning wgrant
<wgrant> Morning jelmer.
<lifeless> wgrant: welcome
<thumper> \o/ finished with email
<thumper> and a formal welcome to wgrant
<thumper> :)
<thumper> embraced fully at last
<wgrant> Heh, thanks lifeless, thumper.
<jelmer> Ah, right.. forgot it's already Monday over there. :-)
<jelmer> wgrant: Welcome!
<thumper> hi jelmer
<jelmer> 'morning Tim
<wgrant> jelmer: Were you able to work out which package supposedly has broken shlibs?
<wgrant> jelmer: synapse is the only one I can see, and it depends on (>= 0.2.14)...
<jelmer> wgrant: no, I didn't look into that issue further
<thumper> bug fixed for bugjam \o/
<thumper> well, was fixed months ago
<thumper> but closed is closed
<wgrant> No ~launchpad admins around at the moment, I suppose?
<thumper> wgrant: not until spm starts
<kees> lifeless, jelmer, cool, thanks. I was curious after reading https://bugs.launchpad.net/soyuz/+bug/689199
<_mup_> Bug #689199: SSHFP DNS record for ppa.launchpad.net <fingerprint> <ssh> <ssl> <Soyuz:Confirmed> <Ubuntu:Invalid> <https://launchpad.net/bugs/689199>
<kees> er, wrong one. this one: https://bugs.launchpad.net/soyuz/+bug/689213
<jelmer> kees: are you sure?
<kees> so is the poppy code the same as the ppa downloader?
<kees> jelmer: sure of what?
<jelmer> kees: That last URL, it gives me a 401
<kees> it's a private bug, that somehow didn't get lp security subscribed.
<kees> there, subbed now.
<kees> /lib/lp/services/sshserver looks more like the core?
<elmo> kees: poppy is the codename for the code behind upload.ubuntu.com and it's PPA equivalent
<elmo> kees: whether it's ftp (original) or ssh (newer)
<kees> ah righto, now I remember
<lifeless> kees: ppa downloader?
<kees> lifeless: I can't type. uploader.
<jelmer> kees: thanks
<lifeless> hah
<wallyworld> thumper: wanna chat?
<thumper> wallyworld: yeah man
<thumper> wallyworld: mumble?
<wallyworld> thumper: yep
<jelmer> lifeless: I think Jacob's point was that the fact that ssh server offered port forwarding was widening the attack surface.
<lifeless> I must have misunderstood things then
#launchpad-dev 2011-12-05
<wgrant> Trivial review for someone: https://code.launchpad.net/~wgrant/launchpad/prettier-private-build/+merge/84415
<huwshimi> wgrant: Btw, this fixed my lp-land issues: https://lists.launchpad.net/launchpad-dev/msg07986.html
<huwshimi> A trivial review for someone: https://code.launchpad.net/~huwshimi/launchpad/expired-status-colour/+merge/84417
<wgrant> huwshimi: Thanks, approved.
<huwshimi> wgrant: :)
<wgrant> huwshimi: I'm not a huge fan of the importance colour scheme, but apart from that the new listings are awesome.
<huwshimi> wgrant: Thanks for noticing
<huwshimi> wgrant: Yeah, it's really hard with the status colours being so bright I was trying to find a way to not make the colours fight too much. Any suggestions on how to improve them?
<wgrant> Not really, no :/
<wgrant> The status colours are pretty nice.
<wgrant> huwshimi: You're on your two bit of QA?
<huwshimi> wgrant: Ah right, thanks I'll do that now
<huwshimi> strange, must have missed those emails
<wgrant> Thanks.
<huwshimi> wgrant: Done
<wgrant> lifeless: Could you review https://code.launchpad.net/~wgrant/launchpad/prettier-private-build/+merge/84415? You are the only other reviewer in APAC this week.
<lifeless> this is very much a self review candidate...
<lifeless> theres no possible way a review could improve this :)
<wgrant> Reasonable point.
<huwshimi> A small css/js review for someone: https://code.launchpad.net/~huwshimi/launchpad/order-arrows-894535/+merge/84432
<wgrant> huwshimi: What's wrong with the current importance direction?
<wgrant> eg. if I order by size descending in Nautilus, the arrow points up.
<wgrant> If I order by importance descending on Launchpad.net, the arrow points up.
<huwshimi> wgrant: Are you sure
<huwshimi> ?
<huwshimi> wgrant: I guess it depends what ascending descending means for the importance
<wgrant> http://people.canonical.com/~wgrant/launchpad/nautilus-sort.png
<huwshimi> wgrant: Yeah, that's how my branch makes the arrows work in Launchpad. The problem I believe is in how Launchpad interprets how to ascend or descend
<wgrant> Seems to work that way for id/status/importance at least already.
<huwshimi> wgrant: Something is very wrong then. All the js presentation code that talks about ascending/descending is doing the right thing now, whatever is telling the js what order the items are in must be wrong
<huwshimi> I think
<wgrant> Heh
<huwshimi> I'm just reviewing now
<huwshimi> wgrant: Hmm... so there's a attribute that's passed to the ordering controls which looks like it might be statically set to "sort_order: 'desc'" which, if not updated might be wrong depending on what these queries default to
<wgrant> huwshimi: That would be quite amusing.
<huwshimi> wgrant: I might be wrong, but I can't see what else might be doing it
<huwshimi> wgrant: Although there does seem to be a bug which is causing my branch not to work perfectly too
<huwshimi> it defaults to descending for everything, so I guess it could be connected
<huwshimi> wgrant: So I fixed my issue
<huwshimi> wgrant: And it looks like the definition of a few things is off
<huwshimi> wgrant: But I'm very confused as to what
<wgrant> huwshimi: Howso?
<huwshimi> wgrant: I don't know, I'm confused :)
<nigelb> Morning Launchpaders
<wgrant> Heh
<wgrant> Morning nigelb.
<nigelb> Sig, yet another Monday.
<nigelb> *Sigh.
<huwshimi> wgrant: For one I don't know how the arrows point in the correct direction for some ordering when the presentation code says it shouldn't
<huwshimi> wgrant: My guess is it's back to everything default to 'desc'
<huwshimi> wgrant: Oh I see it wasn't actually following the ordering label. The actual direction of the arrow was based on what direction the arrow was pointing previously
<wgrant> Hah
<huwshimi> wgrant: My branch incidentally fixes
<huwshimi> *fixes that
<huwshimi> (as I determine the direction with ".hasClass")
<huwshimi> Another trivial html review: https://code.launchpad.net/~huwshimi/launchpad/checkbox-label-labels-894209/+merge/84437
<wgrant> huwshimi: That's not going to create duplicate IDs?
<huwshimi> wgrant: The same identifier is being used for the checkbox name property. The properties for that have to be unique so I assume it will be fine
<wgrant> Well, IDs are meant to be document-wide, but I guess it'll do.
<huwshimi> wgrant: I see what you mean
<huwshimi> wgrant: What do we normally do to namespace our forms?
<wgrant> lol
<huwshimi> wgrant: I see :(
<wgrant> But if you're unconcerned, then I shall approve.
<huwshimi> wgrant: I'm a little concerned
<huwshimi> wgrant: Both name and id should be namespaced on a form, I kind of assumed that would have already been taken care of, but maybe I need to add something
<huwshimi> wgrant: I don't want to mess with the name as that will have larger ramifications so I might just append "_id" to the ids. I think we do that elsewhere
<lifeless> I don't think we have currently; we certainly have some forms that have special casing to deal with the form being reused on one page (specifically batching facilities(
<huwshimi> wgrant: OK, I've pushed that change
<wgrant> huwshimi: Approved, thanks.
<huwshimi> wgrant: :D
<wgrant> huwshimi: In your arrow branch, the last hunk duplicates the HTML. Is that deliberate?
<huwshimi> wgrant: Erm, let me check
<huwshimi> wgrant: Oh, no that's not deliberate. I had intended to go back and fix that. Actually I didn't know where to store that html.
<huwshimi> wgrant: This is the file: http://bazaar.launchpad.net/~huwshimi/launchpad/order-arrows-894535/view/head:/lib/lp/app/javascript/ordering/ordering.js
<huwshimi> wgrant: And the html needs to be used by the renderUI and _updateSortArrows methods. Any suggestions?
<wgrant> huwshimi: Store it in a constant like LI_TEMPLATE, maybe?
<wgrant> I don't know if we have any conventions for this sort of thing.
<huwshimi> wgrant: That would work
<wgrant> huwshimi: The margin around the icon is also pretty huge here.
<wgrant> Looks a lot better with margin-left: 3px instead of 5px, and padding: 0 0 0 12px instead of 0 0 0 18px.
<huwshimi> wgrant: I'll fiddle with that a bit
<wgrant> Ah, the 18px is from the normal sprite styles, I see.
<huwshimi> wgrant: Yeah, I was balancing that out
<huwshimi> wgrant: but I should fix it up a little
<huwshimi> wgrant: OK, just pushed those changes
<wgrant> huwshimi: That's much better, thanks.
<huwshimi> wgrant: No problems. Thank you!
<wgrant> Approved.
<huwshimi> wgrant: Cheers
 * huwshimi will be back later
<adeuring> good morning
<danhg> Morning
<mrevell> Morning development squadrons!
<nigelb> Morning mrevell!
<mrevell> Everyone, I'd like to introduce frankban, who has joined the Launchpad team at Canonical.
<nigelb> Hi frankban!
<nigelb> Is he the new danilos? ;)
<wgrant> Welcome frankban!
<frankban> Hi all!
<mrevell> nigelb, Kinda
<nigelb> mrevell: heh
<mrevell> If we ever add a kanban-style feature to Launchpad, perhaps we should call it frankban's kanban.
<nigelb> haha
<frankban> :-)
<bigjools> welcome to the team frankban
<frankban> bigjools, thanks!
<allenap> frankban: Hello! Welcome to Launchpad :)
<cjwatson> wgrant: mawson> is this something I can reasonably ask people to do, or should I be looking to QA germinate changes some other way?
<wgrant> cjwatson: We could do it this weekend.
<wgrant> bigjools is probably the person to talk to.
<bigjools> mawson is the only place
<frankban> allenap, good morning and thank you!
<cjwatson> Well, by some other way, I mean perhaps without a DB restore
<cjwatson> I don't know quite how old and crufty mawson is right now; perhaps it's recent enough not to matter
<cjwatson> as long as I can run cron.germinate and have it succeed
<bigjools> its dump is from just before precise opened
<wgrant> It's from September 22, with a locally initialised Precise, IIRC.
<cjwatson> Oh, that's not so bad.  That would be fine for this testing then.
<cjwatson> I was confused by the last cron.germinate run saying natty.
<jtv1> Anyone willing to pick up a near-trivial review?  https://code.launchpad.net/~jtv/launchpad/bug-884599/+merge/84400
<jtv1> adeuring, I don't suppose I could trouble you for yet another one?
<adeuring> jtv: I'll look
<jtv> Great, thanks
<adeuring> jtv: r=me
<jtv> thanks adeuring!
<huwshimi> hmm... ec2 test errors I can safely ignore? http://paste.ubuntu.com/760285/
<wgrant> huwshimi: That's a new one... but not your fault, clearly
<wgrant> Ignore.
<huwshimi> wgrant: Thanks. I'm never sure if it's something that means that my branch hasn't been fully tested or something
<wgrant> huwshimi: It used to mean that sometimes, but it's reliable nowadays.
<wgrant> The test time and count at the top are a good indication.
<wgrant> They both increase over time :/
<huwshimi> wgrant: OK sure, I guess I'm find ignore things that aren't errors the look like they related to my branches then?
<wgrant> Pretty much.
<huwshimi> wgrant: Great :)
<huwshimi> ec2 list, why are you hanging?
<StevenK> huwshimi: An instance has probably just terminated and it's trying to ssh into it.
<StevenK> strace it
<huwshimi> StevenK: Oh, how do I do that?
<StevenK> huwshimi: 'which strace', first of all
<huwshimi> StevenK: '/usr/bin/strace'
<StevenK> huwshimi: Okay, run 'strace bin/ec2 list'
<StevenK> That will produce a *LOT* of output
<StevenK> It should hang near a connect() line
<StevenK> That will tell you if it is trying to connect to a downed instance
<huwshimi> StevenK: It doesn't seem to have hung
<StevenK> huwshimi: It has exit(0) or something similar at the end?
<huwshimi> StevenK: It sporadically adds more output on the end, but not terminating
<StevenK> huwshimi: Can you pastebin the last screen full?
<StevenK> Adding a --debug flag to bin/ec2 would be awesome
<huwshimi> StevenK: http://paste.ubuntu.com/760295/
<StevenK> huwshimi: That last line is attempting to connect to an ec2 instance on port 80
<huwshimi> StevenK: Is that normal?
<StevenK> huwshimi: Yes, that's the magic that ec2 list does in the background.
<StevenK> huwshimi: However, the magic isn't working since Amazon still lists the instance as terminating (I guess), but ec2 list still wants to talk to it. Wait about ten minutes and try again without the strace.
<huwshimi> StevenK: Sure, thanks :)
<huwshimi> ah, working now
<rick_h_> morning
<nigelb> Morning rick_h_
<bigjools> jelmer: any idea what's going on here? http://launchpadlibrarian.net/85989025/nvervelle-jmol-12.2.log
<bigjools> all imports fail https://code.launchpad.net/~nvervelle/jmol/12.2
<jelmer> bigjools: sourceforge's SVN server isn't very reliable, so it randomly hangs up on us
<bigjools> hurray
<jelmer> bigjools: there's an open bug about it, trying to find it..
<bigjools> ah ok thanks
<jelmer> bug 891887
<_mup_> Bug #891887: sourceforge imports fail due to connection hangup <code-import> <Bazaar Subversion Plugin:Triaged by jelmer> <Launchpad itself:Triaged> < https://launchpad.net/bugs/891887 >
<jelmer> the associated branch reduces the number of revisions we process in each batch, which will hopefully reduce the effect of the hangups
<bigjools> jelmer: ok thanks
<bigjools> jelmer: any idea with this one too? https://code.launchpad.net/~vcs-imports/xine-lib/trunk
<jelmer> bigjools: mercurial imports unfortunately aren't very reliable yet - bug 889530
<_mup_> Bug #889530: mercurial imports should be marked 'beta' <code-import> <ui> <Launchpad itself:In Progress by jelmer> < https://launchpad.net/bugs/889530 >
<bigjools> jelmer: thanks agin
<bigjools> again
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugtasks: 3*10^2
<allenap> gary_poster: Hi Gary. frankban had no questions for me, so I assume either the wiki pages are keeping him busy, or his broadband is down.
<allenap> gary_poster: I wondered if you would be up for reviewing a change to LaunchpadSecurityPolicy, following on from Raphael's work last week. I have taken a much different approach to his. Even if you don't have time for a full review, you might be interested in looking at it. https://code.launchpad.net/~allenap/launchpad/delegated-permission-caching-bug-890927/+merge/84473
<gary_poster> allenap, hi.  yeah, wiki pages kept him busy, and he doesn't have accounts & his new dev box shows up at about 1400 UTC.  Thank you
<gary_poster> allenap, I'd be happy and interested in reviewing it thanks.  I'll start in 5 min
<allenap> gary_poster: Thank you!
<gary_poster> of course :-)
<sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/bug-supervisor-labels/+merge/84343
<benji> sinzui: gladly
<cjwatson> I'm writing test code for my new germinate runner, and (for the time being; fixing this is future work) some of the tests are going to need to have a published archive to work with, at least the dists/ part.  Should I just run the PublishFTPMaster script to arrange for this, or is there something a bit more targeted I could be using instead?
<bigjools> cjwatson: you want published packages in a test?
<bigjools> or is this just for playing around
<deryck> rick_h_, ping for standup
<gary_poster> allenap, yay, this is nice.  I like IRC reviews, so you can tell mw when I'm wrong more quickly. :-) is that ok with you, and if so, may I start now?
<cjwatson> bigjools: in a test
<cjwatson> I at least need Packages and Sources files; the pool doesn't matter
<cjwatson> But I'd rather generate those by publishing rather than manual test data if possible
<bigjools> cjwatson: ok, I'd recommend generating some data in the tree
<cjwatson> You mean hand-writing Packages and Sources files?
<bigjools> it's too slow to publish for unit tests
<cjwatson> ah, OK
<bigjools> generating :)
 * cjwatson fixes his reading comprehension
<bigjools> there may be some helpers around
<bigjools> under lib/lp/archivepublisher/tests/
<cjwatson> yeah, I was just looking
<cjwatson> otherwise I guess I'll write my own
<cjwatson> I don't see any
<bigjools> some of the tests generate these files already but it's just single packages IIRC
<allenap> gary_poster: Yes, that's fine. I'll put my headphones on though so that I hear pings :)
<gary_poster> allenap, heh ok
<gary_poster> allenap, I'll start with what I expect to require the least discussion and work up from there.
<gary_poster> easy one: authorization.py: "breath-first" -> "breadth-first"
<allenap> Hehe, oops.
<gary_poster> :-)
<bigjools> cjwatson: lib/lp/archivepublisher/tests/apt-data/ contains some static data already, I'd recommend adding to it
<cjwatson> bigjools: How about the getPubSource stuff in lib/lp/soyuz/tests/test_publishing.py?  Would that be fast enough?
<gary_poster> allenap, this is a micro-optimization of pre-existing code, but I want us to rip out those two setdefault usages in authorization.py (lines 21 and 25 in diff).  The current code makes us always create a weakkey dictionary every time, even if it is thrown away.  We can easily make an idiomatic and readable version that performs better, so I suggest we go ahead and do it for such a central piece of code.
<deryck> adeuring, you lost sound?
<deryck> adeuring, ok, we hear you.
<bigjools> cjwatson: that just adds to the database
<bigjools> it is fast-ish
<cjwatson> It has a getIndexStanza which a couple of tests use
<deryck> adeuring, we're wrapping up, so no worries.  did you have anything else?
<bigjools> but doesn't write files
 * bigjools looks 
<cjwatson> or rather it returns an spph which has that
<allenap> gary_poster: Strangely enough, I tried doing that, and got an error that a weakref could not be created in one of the tests I ran. I couldn't figure out why.
<cjwatson> would save actually hand-coding the rfc822 data
<gary_poster> allenap, eek.
<cjwatson> Maybe it's too complicated for this though, I'm not sure
<gary_poster> allenap, I have no idea.  I guess I'll back off on it then.
<bigjools> cjwatson: yes you can use that.  In fact it would be quicker to call factory.makeSourcePackagePublishingHistory() although that cuts a lot of corners
<cjwatson> aha
<bigjools> the Test Publisher does it "right" but it's slower
<cjwatson> That sounds perfect actually; I'll look into that (and corresponding BPPH)
<bigjools> because it doesn't add librarian files
<deryck> rick_h_, ping me when you have a screenshot of that issue.
<bigjools> does, even
<gary_poster> allenap, in authorization.py, why only leaf-node cacheing? What's the argument?  If you keep that, I'd suggest changing the description: I wasn't quite sure what you meant until I read the code.
<rick_h_> deryck: will do, getting back from the reboot.
<cjwatson> bigjools: thanks, that saved me a lot of time
<bigjools> cjwatson: my pleasure
<cjwatson> when I get round to teaching this to suck pre-apt-ftparchive data straight out of the database, it will probably fit that model better too, since I'd need [SB]PPHs for that as well
<allenap> gary_poster: The first reason is that my implementation didn't make it easy to cache the non-leaf results. But I also realised that I was uncomfortable doing it; too broad a result to cache.
<gary_poster> allenap, you should only cache the top, right?
<gary_poster> allenap, I mean in addition to the leaf
<gary_poster> well, no
<allenap> gary_poster: I could add that, but it doesn't right now.
<gary_poster> allenap, I don't agree with the discomfort.  I'm ok with practically putting it aside for now.
<rick_h_> deryck: http://uploads.mitechie.com/lp/ppa_inline_edit_current.png http://uploads.mitechie.com/lp/ppa_inline_current_second_line.png and http://uploads.mitechie.com/lp/ppa_using_resizing.png
<rick_h_> deryck: so the first shot is the 1em "start" style in effect, and then it gets over ridden on any resize event after that.
<allenap> gary_poster: Okay. I am worried that we could end up with cached permissions based on 10s or even 100s of delegated permissions.
<deryck> rick_h_, let's jump back to mumble, cool?
<rick_h_> sure
<gary_poster> allenap, it would be trivial to also cache the checked object's permissions
<gary_poster> allenap and that would alleviate your explosion concerns
<gary_poster> (which I don't think are going to happen for us, but understand in theory)
<gary_poster> allenap, and that would mirror the existing behavior
<allenap> gary_poster: Do you mean the top-level object, objecttoauthorize?
<gary_poster> allenap, yes
<allenap> gary_poster: Okay, I can do that.
<gary_poster> cool allenap
<gary_poster> thx
<gary_poster> allenap, you write "# XXX: GavinPanella 2011-12-03 bug=???: Surely for delegated checks...".  I don't think this is pertinent.  The security machinery calls into this code, after already having done a lot of this stuff--especially zope.Public, for instance.  Can you elaborate on your concern?
<allenap> gary_poster: When checking delegated permissions, should we not check if it's requesting zope.Public? That's a silly example... I'm more worried about the block of code that calls LSP.checkPrivacy(). Should we do that for each delegated check?
<allenap> jelmer: http://launchpadlibrarian.net/86683207/vcs-imports-xine-lib-trunk.log is a known bug that, iirc, you're working on, right?
<gary_poster> allenap, mm, ok.  I want to dig into this.  So, I'm familiar with the zope.Public check so I'll start there.  Your thought there is "what if checkAccountAuthenticated returns (something, zope.Public)?" right?
<allenap> gary_poster: Yes.
<gary_poster> I see
<allenap> That seems like a daft thing to do, but it might happen.
<gary_poster> yeah, that one seems daft; I won't worry about it too much.  I'm more interested in LSP.checkPrivacy.  I'm not sure how that works, and that seems like it might be more serious.  Lemme take a look (unless you already know the details and can get me up to speed quickly here or on a call)
<gary_poster> allenap ^^
<jelmer> allenap: hi
<jelmer> allenap: yeah, the hg imports aren't very reliable yet
<allenap> gary_poster: No, I don't know the details; I have skimmed the code and it looks serious :)
<allenap> jelmer: Okay. I'm answering https://answers.launchpad.net/launchpad/+question/178945. Shall I just say that, or is there a bug I can point him to?
<gary_poster> allenap, ok :-) I'll look and report back
<allenap> gary_poster: Thank you :)
<jelmer> allenap: I'd suggest just saying that, I don't think linking a particular bug is useful
<allenap> jelmer: Okay, cool. Thank you!
<bigjools> allenap: I beat you to it I think
<allenap> bigjools: Ah ha :)
<bigjools> allenap: I shall leave you to it and finish my branch :)
<flacoste> benji, gary_poster: have you seen bug 899388?
<_mup_> Bug #899388: Some translation statistics are not up to date <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/899388 >
<benji> flacoste: I have ("Reported by Benji York on 2011-12-02") ;)
<gary_poster> Hm, there may be a dupe there
<flacoste> benji: yeah, just saw that :-)
<flacoste> sorry for the noise
<flacoste> i got confused by the email
<benji> flacoste: no worries
<flacoste> i thought it was reported by a user, but it was only follow-ups comments
<benji> yep; I'm really confused by the behavior and don't think it's related to the recent changes in the way statistics are updated (but I could be wrong)
<gary_poster> oh...so this is different from the "jobs are not working" bug benji?
<gary_poster> which you closed
<gary_poster> right
<benji> gary_poster: yep; I believe the job is working (because statistics are being updated) but the bug is that the statistics aren't right
<gary_poster> Oh, I see :-(
<flacoste> that's inconvenient!
<benji> the only changes we (intended) to make were to change the timing of the calculations, not the calculations themselves, so we shouldn't have introduced any new behavior
<benji> indeed
<gary_poster> benji, so the user comments indicate that the workaround you describe is insufficient?
<benji> gary_poster: yep, and it indicates that the statistics are indeed being updated (presumably by the cron job)
<gary_poster> benji, I see
<gary_poster> benji, if you want pairing from somebody, ask
<benji> gary_poster: will do
<benji> sinzui: https://code.launchpad.net/~sinzui/launchpad/bug-supervisor-labels/+merge/84343 looks good
<sinzui> thank you benji
<benji> my pleasure
<gary_poster> allenap, I had other stuff to quickly review but now I am back.  I'll look more at that LSP.checkPrivacy stuff later today but I want to make sure to bring up the other questions I had for you while we still overlap.  I have three more things, only one of which probably requires much discussion.
<gary_poster> 1) isinstance(result, Iterable) does not strike me as a good pattern for checking
<gary_poster> oh wait, that was the one we had to talk about :-P
<allenap> gary_poster: ?
<gary_poster> So try that again: 1) lib/lp/app/interfaces/security.py: In docstrings, please specify that all delegated results must be True in order for it to be considered True.
<gary_poster> allenap ^^
<allenap> Okay.
<gary_poster> allenap, 2) Am I correct that there are no tests for this change?  Is that because there are no tests for this generally?
<gary_poster> I see the tests for the new behavior in the authorization
<allenap> gary_poster: There are no tests for the new caching behaviour. All the existing tests pass unmodified, but I ought to test for caching of delegated auths. Fwiw, a follow-on branch from this does check (indirectly) that delegated auths are cached, so they're working.
<gary_poster> allenap, I was going to be concerned about isinstance(.., Iterable) but I see it is an ABC, so nm. :-)
<gary_poster> (and I see it experientially works for what I would want it to in the common case)
<allenap> gary_poster: Yeah. It's not great from a micro-optimization standpoint, but it'll do for now :)
<gary_poster> yeah, cool
<bigjools> benji: hi - can I bother you with a review please?
<benji> bigjools: absolutely
<gary_poster> allenap, ok cool.  So, this is conditionally approved with the comments I've given, and with some reading I intend to do today on checkPrivacy.  I'll plan to approve this today, probably after your EoD
<bigjools> benji: it's https://code.launchpad.net/~julian-edwards/launchpad/sponsor-syncs-bug-827555/+merge/84287
<bigjools> thanks
<allenap> gary_poster: Woohoo \o/ thank you :)
<gary_poster> allenap, btw, I really like your approach.  Thanks for pulling this along to the finish line in such a nice way.
<allenap> gary_poster: Thanks, I appreciate that.
<benji> bigjools: I added a comment to https://code.launchpad.net/~julian-edwards/launchpad/sponsor-syncs-bug-827555/+merge/84287 that I couldn't phrase well for IRC, but you might want to discuss it here
<bigjools> benji: my docstring is correct
<benji> in other words, I misunderstand?
<bigjools> the sponsored person overrides the requesting user
<bigjools> benji: yes, but must not have been clear enough for that to happen
<benji> oh! you're considering the requesting use as the sponsor
<bigjools> with an "I" in there  somewhere
<bigjools> yep
<benji> gotcha, yeah, if you add a statement to that fact, I think it'll clear it up
<bigjools> righto
<lifeless> morning
<sinzui> flacoste, ping. Do you have time to talk about users, team, interfaces, and security?
<flacoste> sinzui: sure
<flacoste> skype me
<bigjools> benji: thanks for the approval
<benji> bigjools: my pleasure
<lifeless> allenap: sinzui is da god of series, but AIUI downloads show 'newest' full stop, and latest series is done by a built in sort. Probably need to check the code to be sure.
<allenap> lifeless: Ta, I'll take a look. Looks like you got woken early :)
<lifeless> apparently ;)
<sinzui> allenap, lifeless the downloads page is a mess. we show the released for current development series at the top or the page (current development series is pulled out of naming sequence and shown first). Backport releases are show with their respective series series, but may fall off the page because of batching.
<lifeless> sinzui: https://answers.launchpad.net/launchpad/+question/180693
<sinzui> allenap, lifeless downloads exists to let packagers see the latest releases, but 7 people muddled the page to serve users and developers, which make it impossible to do the right thing
<lifeless> thumper: can you please list the queues on production ?
<lifeless> bah
<lifeless> ECHANNEL
<sinzui> ahh the downloads portlet
<sinzui> allenap, lifeless :that too is very ignorant of reality and we have too community of equal weight in contention. Let me find the bugs for that mess
<allenap> sinzui: I have to go now to collect kids, but I'll be back later. Are you happy to answer that question in the meantime, or would you prefer me to do it later?
<sinzui> allenap, bug 419733 and bug 669668 describe the fact that Lp really guess at what to show and users fight over what is the correct behaviour. I report the latter bug as a suggestion from UDS...which mightg addess the issue
<_mup_> Bug #419733: new Downloads portlet should show latest stable release as well as latest <lp-registry> <product-release-finder> <releases> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419733 >
<_mup_> Bug #669668: permit projects to specify the series that current release are made from <lp-registry> <releases> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669668 >
<lifeless> \o/ instant OOPSes on production.
 * lifeless dances the happy dance of a plan coming together
<allenap> Awesome!
<jcsackett> sinzui: you free to mumble? i'm trying to figure out what needs tackling the most on our board.
<sinzui> okay
<sinzui> allenap, I answered the question
<sinzui> jcsackett, I think I am mistaken about the pre-req bugs. There are several bugs about editing project/distro information inline, but none about the roles. I suspect the bug was rewritten to solve one use case. I think you should report bugs are you need to make pillar roles editable in the page via ajax
<mrevell> G'night all
<lifeless> statik: I have a CT scan on thursday thats going to play havoc with the day; we're booked for that morning for catchup- can we reschedule ?
<abentley> benji: could you please review https://code.launchpad.net/~abentley/launchpad/remove-hot-bugs/+merge/84503 ?
<benji> abentley: I was eating lunch; looking now
<abentley> benji: thanks.
<benji> abentley: https://code.launchpad.net/~abentley/launchpad/remove-hot-bugs/+merge/84503 looks good, I had one idea for simplyfying a template, but that's it
<statik> lifeless: sure, rescheduling is fine with me, my calendar is pretty accurate for open slots
<abentley> benji: cool, thanks for the suggestion.
<benji> abentley: my pleasure
<lifeless> statik: how about later today after I catch up with flacoste?
<lifeless> flacoste: also, we can call anytime, I am awake and around :)
<flacoste> lifeless: i'll have to postpone a bit, i hurt my back yesterday and have an appointment for it in 1h
<lifeless> flacoste: ow!
<lifeless> flacoste: ping me anytime
<lifeless> statik: how about now then ?
<lifeless> hmm, no gary
<lifeless> allenap: this is the thing I was looking at previously - https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715
<lifeless> allenap: (centering around whether we ever pay network / db server latency for result set rows)
<benji> lifeless: I'm doing some reviews and noticed that https://code.launchpad.net/~mbp/launchpad/show-timeline/+merge/80166 looks like it wants a comment from you before I review it
<thumper> lifeless: I'm assuming that message wasn't really for me?
<SpamapS> So.. in working on the juju charm distro .. I'd like to open up a new series and copy all the contents of the old one into the new one..
<SpamapS> I was hoping this would do that
<SpamapS> https://launchpad.net/charm/precise/+initseries
<SpamapS> But apparently thats some of the ubuntu-only magic.
<lifeless> thumper: it wasn't
<SpamapS> I'll write up an email but wondering if anybody can shed some light on how this is supposed to work?
<lifeless> thumper: failed tabcomplete for thedac who isn't lurking here
<lifeless> SpamapS: make a new series, and probably run the branch-new-distro script should do it fo ryou
<SpamapS> lifeless: in what package/bzr tree/multiverse does branch-new-distro reside?
<lifeless> lp source I think
<lifeless> it's only ever been run against ubuntu, so you'll want to eyeball it
<SpamapS> Yeah I'll give it a look
<lifeless> also IIRC it gets run by sysadmins
<SpamapS> I'm not quite ready to do it anyway.. since our branches will likely be copied backward to older releases quite a bit more than in Ubuntu.
<lifeless> abentley: around?
<abentley> lifeless: hi.
<lifeless> abentley: I was just looking at the update to https://bugs.launchpad.net/launchpad/+bug/899675
<_mup_> Bug #899675: When no bugs are available in a dynamic listing, the ordering controls are positioned above the search widget <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/899675 >
<lifeless> abentley: when I click on the link through to tag=madness, the page seems to hang
<abentley> lifeless: Not for me on Firefox.
<lifeless> abentley: by which I mean the top shows 'loading' for an extended period (several minutes so far) and the bug counts beside 'New' etc are not being filled in.
<lifeless> abentley: I'm on FF 8
<lifeless> https://bugs.launchpad.net/unity/+bugs?field.tag=madness is the url
 * lifeless tries a ctrl-refress
<abentley> lifeless: This is on production, not qastaging?
<lifeless> yes
 * lifeless tries qastaging
<lifeless> ah, I'm not in the team on qastaging
<abentley> lifeless: qastaging may be worse.
<abentley> lifeless: we've already got issues with the spinner on qastaging.
<lifeless> so this sounds similar/related?
<lifeless> abentley: would you like a new bug report from me for this?
<abentley> lifeless: yes, a report of pages hanging would be new.
<lifeless> roger wilco
<abentley> lifeless: I'm on FF8, too.  I don't understand why you're seeing something different.
<rick_h_> lifeless: ctrl-shift-del will bring up hard cache clearing form
<rick_h_> lifeless: as a "just in case" it's a bit more reliable than ctrl-reload
<abentley> lifeless: This "hanging" is shown via the native FF progress indicator or one of our spinners?
<lifeless> abentley: neither, lack of ajax post-render updates
<lifeless> bug
<lifeless> https://bugs.launchpad.net/launchpad/+bug/900480
<_mup_> Bug #900480: +bugs 'hanging' when no bugs found <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/900480 >
<lifeless> screenshot in a sec
<abentley> lifeless: Oh.  Yes, I can reproduce that, then.
<abentley> lifeless: I'm not sure what puts that there.
<abentley> lifeless: I can see the pathology, though.  An unconditional reference to an optional node.
<lifeless> cool
<lifeless> screenshot is up
<lifeless> rick_h_: thanks
 * lifeless tries statik: again
<statik> lifeless: sure, i can talk in 5
<lifeless> statik: ok, lets do this :)
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
#launchpad-dev 2011-12-06
<jtv> How do I push a branch to staging again?  It trips me up every time.  "Read-only transport," it says, whether I use lp: or bzr+ssh:
<lifeless> lp-staging://
<lifeless> or is it lp://staging/...
<lifeless> one of them
<lifeless> if its connecting and then saying read-only, you're not in the team :>
<rick_h_> jtv: qastaing? or staging? I used bzr push lp://qastaging/~rharding/... for qastaging with success
<jtv> lifeless: what team?
<jtv> rick_h_: I suppose I could try qastaging, thanks.
<lifeless> the one you are pushing to a branch of
<jtv> lifeless: I tried lp://staging/, which is what the UI tells me to do, but same error.
<lifeless> jtv: what was the full url
<jtv> lifeless: so "read-only transport" from bzr can actually mean that I don't have privileges?
<lifeless> it means it tried to write and failed
<jtv> lp://staging/~stellarium/stellarium/auto-po
<lifeless> either because its using http or can't write
<lifeless> jtv: and are you a member of ~stellarium on staging?
<jtv> No.
<lifeless> ok, so thats working as expected
<jtv> Except for the misleading error message.
<lifeless> bzr doesn't know the cause for being unable to write
<jtv> That's not very comforting to me, is it?  It tells me "read-only transport" when there's nothing wrong with the transport, only with where I'm trying to transport to.
<lifeless> indeed
<lifeless> its also exactly what will happen if you push locally to a directory you only have rx bits on
<lifeless> for instance
<lifeless> feel free to file a bug on bzr/bzr+lp
<lifeless> hah
<lifeless> dead code in LP's DB migration system
<lifeless> win
<wgrant> lifeless: Where?
<wgrant> jtv: Bug #894177
<_mup_> Bug #894177: run_jobs.py pofile_stats oopses: permission denied for relation productseries <oops> <translations-handoff> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/894177 >
<jtv> wgrant: oh, so what I filed was a dupe.  :(
<jtv> Looks like the script was converted to a job, and then not tested under realistic access rights.
<wgrant> Yeah. You might want to throw your info into that one.
<wgrant> Yes.
<jtv> Thanks.
<wgrant> Well.
<wgrant> It works fine for distro templates.
<wgrant> Just not product ones.
<wgrant> I've tested locally and product+productseries is sufficient.
<lifeless> wgrant: upgradelog
<lifeless> wgrant: implemented on non-slony environments only
<wgrant> I see no upgradelog
<lifeless> ah, its new, not dead
<lifeless> stub is capturing the sql executed
 * lifeless ports
<wgrant> Is that the thing I reverted over the weekend?
<lifeless> yes
<lifeless> because it was broken, yes.
<lifeless> did it break on qastaging or staging ?
<lifeless> if it broke on staging, its because the autodetect stuff for it was only on the non-slony case
<wgrant> buildbot
<lifeless> ah, interesting
<wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1617/steps/compile_1/logs/stdio
<wgrant>   File "upgrade.py", line 645, in get_bzr_details
<wgrant> ValueError: need more than 1 value to unpack
<wgrant>     branch_nick, revno, revision_id = out.split(' ', 3)
<lifeless> hmmm, I think I want to chat to sub. And I started early today; so going to EODish. (As in , will be back later)
<wgrant> kk
<micahg> it
<micahg> oops, was going to say that it's weird that I get E-Mails that I've assigned myself a bug faster than a page refresh
<lifeless> stub: can we have a call in ~ 1 hour about trusted.sql etc and lazr_postgresql ?
<stub> lifeless: sure
<stub> lifeless:  https://code.launchpad.net/~stub/launchpad/db-deploy/+merge/84231  will affect this work btw
<bkerensa> flacoste: You around?
<wgrant> bkerensa: Probably not for a few hours yet.
<wgrant> But there are lots of LP devs around.
<bkerensa> wgrant: K just looking for someone on the Launchpad team to interview for Dev News about the new Beta Bug Listing Features and other things being worked on
<wgrant> bkerensa: Most people who have been working on that (and flacoste) are in the Americas, so won't be around for a while.
<bkerensa> wgrant: k ;) I'm in the Americas but I'm also a night owl :P so perhaps I'll catch them tomorrow (I will just idle)
<wgrant> Heh
<adeuring> good morning
<frankban> good morning
<mrevell> Hello
<bigjools> has anyone else seen spurious errors in lp.buildmaster.tests.test_builder.TestSlave in ec2?
<lifeless> bigjools: new bug for you - https://bugs.launchpad.net/txlongpoll/+bug/900579 - I believe its pretty shallow.
<_mup_> Bug #900579: txlong poll reads any queue <txlongpoll:Triaged> < https://launchpad.net/bugs/900579 >
<lifeless> bigjools: (it may just be a deployment thing in fact)
<lifeless> bigjools: https://code.launchpad.net/+longpoll/?uuid=oopses&sequence=1 is a good url to make the impact clear ;)
<bigjools> lifeless: yeah, I tend to err on the side of permissions
 * lifeless really really goes now
<allenap> lifeless: Interesting (re. https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715). I may borrow that for an experiment. Ta.
<wgrant> bigjools: huwshimi had one of those yesterday. First I'd seen of it.
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 3*10^2
 * cjwatson bangs his head against bug 713764
<_mup_> Bug #713764: fake librarian columns cannot be looked up by storm <Launchpad itself:Triaged> < https://launchpad.net/bugs/713764 >
<stub> How do I revert a reversion on my branch?
<jelmer> stub: merge a reversion of the reversion :)
<jelmer> stub: e.g. "bzr merge -r-5..-4 ."
<stub> I mean the magic commit message tags - list it as a reversion there?
<jelmer> ah
<jelmer> stub: I'd add the same tags as in the original commit that landed it [bug=YYYYYY][r=...] etc, and a comment saying it's relanding something that was rolled back
<cjwatson> There must surely be other examples in LP of mock objects wrapping Storm objects that can still manage to be looked up by Storm, but I can't find a pattern that works
<cjwatson> Maybe I'll just have to use the full librarian the way everyone else who's run into this seems to have done :-/
<StevenK> stub: [rollback=<rev>]
<StevenK> stub: And tag the bug as bad-commit-<rev>
<stub> There is no bug
<stub> So that step is easy I guess ;)
<jelmer> StevenK: wouldn't that just be for the rollback itself, rather than the rollback of the rollback?
<StevenK> I'm guessing stub is rollbacking the commit, so [rollback= is fine
<wgrant> He's rollbacking my rollback.
<stub> The commit has already been rolled back. I'm rolling back that rollback (reapplying with what hopefully will fix the issue)
<wgrant> No [rollback= required.
<stub> k
<stub> My next trick would have been self referential rollback= statements to mess with qa-tagger
<wgrant> You're a bad person.
<stub> qa-tagger is broken. Early Christmas break everyone!
<bigjools> \o/
 * cjwatson tries to understand http://paste.ubuntu.com/761501/
<cjwatson> What, in general, do I need to do to let my tests get hold of an archive's PublisherConfig?
<bigjools> cjwatson: you are running in the wrong layer
<bigjools> you need zopeless
<cjwatson> I thought zopeless didn't give me a librarian
<cjwatson> however now that I work my way through the class hierarchy I see that's wrong
<cjwatson> Thanks.  Onto the next failure :-)
<rick_h_> morning party people
<wgrant> I really should delete ZopelessLayer at some point.
<wgrant> Since it doesn't actually do
<wgrant> much different any more.
<allenap> wgrant: Can you remove all layers please?
<wgrant> Turning the class hierarchy into a stick is a good way to start :)
<allenap> wgrant: Me no comprendo.
<wgrant> If the layer hierachy is closer to a stick than the complex tree it is now, it becomes easier to deal with .
<allenap> wgrant: You're being pragmatic again.
<wgrant> :(
<allenap> wgrant: One layer less would be a very healthy step.
<wgrant> Well, crucially, killing of ZopelessLayer also kills off ZopelessDatabaseLayer, LaunchpadZopelessLayer, and ZopelessAppServerLayer.
<bigjools> layers were a hack to have slow-starting fixtures available across tests
<bigjools> I think TestTools is gaining this ability RSN
<allenap> wgrant, bigjools: I'm sure we could come up with a layer-like wrapper around testresources. I experimented with something similar once before.
<jml> yay death to zopeless layer!
<rick_h_> gmb: you still around for a review?
<gmb> rick_h_: Sure
<rick_h_> gmb: https://code.launchpad.net/~rharding/launchpad/inline_editor/+merge/84528
<rick_h_> gmb: thanks
<gmb> Woah
<gmb> rick_h_: That's 1899 lines of diff
<rick_h_> well mostly -
<rick_h_> gmb: yea sorry, ripped out a lot
<gmb> rick_h_: Our usual per-branch limit is 800. I won't be able to review that in the time I have left online today.
<gmb> rick_h_: You'd be better off talking to someone on your squad to see if they have the time to take a look at that.
<rick_h_> gmb: cool, thanks
<gmb> Np
<Daviey> In regards to package set ACL access, is it viable to add a 3rd type, to help with package to team bug triaging?
 * Daviey asks to see if it is worth raising a bug.
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<deryck> abentley, ping for standup.
<abentley> adeuring: bug 894836
<_mup_> Bug #894836: Wrong order-by widget is highlighted when the page has loaded a previously select preference <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894836 >
<cjwatson> Anyone fancy reviewing https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 ?
<jtv> cjwatson: it's too late for me right now, but please tell me that's your massive speedup branch!
<cjwatson> It is
<cjwatson> Not that I've actually run it in situ yet to demonstrate speedup, merely a stripped-down version on my laptop
<jtv> Agonizing.  Human intuition is notoriously unreliable for these things.  Looking forward to seeing the real-world difference!
<cjwatson> Indeed.  I can't really tell for absolute sure without a full Soyuz instance, which is likely to be a bit much for anything I have locally :-)
<cjwatson> But I'm reasonably confident.
<cjwatson> There's a factor of three in the right direction between the old version on cocoplum and the stripped-down version on my laptop.  I don't think all of that can be overhead, and if my laptop is that much faster than cocoplum we're all in trouble. :-)
<jtv> We should all have laptops as fast as cocoplum!
<cjwatson> I might try syncing over Packages and Sources to mawson and running the stripped-down version there, or something
<cjwatson> Or even as an unprivileged user on cocoplum at a quiet time in the hour
<jtv> Not a job for dogfood?
<cjwatson> Yeah, mawson's probably better for it
<cjwatson> As long as I do a control run with current Packages/Sources first
<cjwatson> The control run I did yesterday took six minutes and produced output considerably smaller than current production, so I don't think it's a good comparator
<cjwatson> (comparand?)
<jtv> The latter, I suspect.
<jtv> But it's not my language.  :)
<bigjools> jtv: you don't get off that easily, you speak it better than the average teenager
<jelmer> ... and somehow manage to speak it without the annoying Dutch accent
<cjwatson> bigjools: perhaps this is premature, but at some point when you have a chance, I'd like to chat about the next stage in improving how germination is done: I'd like to move it before apt-ftparchive, so that we get rid of hysteresis and avoid the occasional need for manual action when seeds change
<bigjools> cjwatson: sounds good
<cjwatson> and I'd like to make sure I understand how to slot that into the publisher properly
<bigjools> is there a publisher hook for that stage?  I can't remember
<cjwatson> I think it would go in between B and C - there's no hook there at this point
<bigjools> ok, easy to add
<cjwatson> you think it ought to be a hook?  It'll need to talk to the DB
<cjwatson> so presumably can't just be the out-of-process kind of thing that distro-parts is
<bigjools> well germination is an Ubuntu thing - at least nothing else needs it but perhaps it might in the future
<cjwatson> agreed
<cjwatson> some kind of in-process hook then
<bigjools> there's no reason why it can't be a run-parts that access the DB
<cjwatson> oh - yeah, of course, duh, my generate-extra-overrides is exactly such a thing
 * cjwatson <- idiot
<bigjools> it's the soyuz effect, roll with it :)
<cjwatson> I'd like to have it mark pockets dirty when seed output changes, too; I guess there's no reason a hook couldn't do that as wewll
<cjwatson> *well
<bigjools> hmmm yes, that could be quite useful
<cjwatson> then no more having to keep the odd universe package in a queue around release time just in case we need to change seeds in a hurry, whee
<cjwatson> pre-index.d sound OK as a name?  (strawman)
<bigjools> yup
<cjwatson> then I get to find out whether I got the germinate API for this right ...
<cjwatson> there's a method that's supposed to yield a sequence of (enum, {header: value, ...})
<cjwatson> so I think I do dict(.buildIndexStanzaFields) on every PUBLISHED [SB]PPH and feed that in
<cjwatson> what I don't know is whether doing that extra [SB]PPH query (basically the same as those in _writeComponentIndexes) will be significantly slower than having germinate read and parse Packages/Sources; do we have numbers on how long the _writeComponentIndexes queries take on something Ubuntu-sized?  I know we aren't using that mode in Ubuntu at the moment
<bigjools> cjwatson: I suspect that reading from the DB is always going to be quicker than parsing a file
<cjwatson> bigjools: oh good
<bigjools> cjwatson: we used _writeComponentIndexes stuff on Ubuntu on dogfood once just to see what it did and it was comparable to running a-f in fact.  I'm sure we can optimise it some more.
<bigjools> the slow part of using a-f is writing its input files...
<cjwatson> it would get a bit slower if it were made fully-compatible - for instance it'd have to read extra override files
<cjwatson> (or we'd have to stuff them into the db)
<bigjools> yeah
<bigjools> well I want those in the DB
<bigjools> I want everything in the DB
<bigjools> then other parts of LP can benefit
<cjwatson> *cough* https://launchpad.canonical.com/ExtraPackageOverrides
<bigjools> yeah :)
<cjwatson> comparable to running a-f> germinate parsing those files takes seconds, so it needs to be in that ballpark
<bigjools> well I am talking overall publisher speed
<bigjools> right, EOD for me, good night all
<bigjools> hmm the update manager could do with a "shutdown after installing" option
<abentley> deryck: There's no OCR.  Could you review https://code.launchpad.net/~abentley/launchpad/fix-spinner-bugs/+merge/84633 please?
<deryck> abentley, sure
<abentley> deryck: thanks.
<deryck> abentley, I don't know if I understand fetch_only.
<deryck> abentley, does that mean, "we're doing XHR only" or "we're only changing out lists" or something else?
<abentley> deryck: it means fetch the data, but don't render it.
<deryck> abentley, ah ok. so we're still showing the spinner regardless of if the list is loaded from cache or XHR?
<abentley> deryck: technically yes, but when the list is loaded from the cache, the spinner is hidden again so quickly that you don't see it.
<deryck> abentley, right, that's fine.
<rick_h_> abentley: the main reason we added it so that the re-scroll to top would take effect if the data came from cache/not
<rick_h_> does that still take place?
<abentley> rick_h_: I expect it does.
<rick_h_> abentley: ok cool
<rick_h_> ic, the .success is always called, but the spinner might not have been visible. So we basically reassert it's hidden and run scroll to top
<abentley> rick_h_: success is only called if the event succeeded, and only if we were loading the batch in order to display it.
<deryck> abentley, r=me.
<abentley> deryck: thanks.
<rick_h_> benji: howdy, api question for you if you've got a sec
<benji> rick_h_: shoot
<rick_h_> so I'm looking at bug: https://bugs.launchpad.net/launchpad/+bug/808952
<_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
<rick_h_> and went checking out how the canonical url data stuff works
<rick_h_> and it seems the url generated in this oops was /1.0/ubuntu/+source/b...
<rick_h_> which fails, but if you /version/1.0 it works
<rick_h_> or take out the 1.0 completely
<rick_h_> so it seems to be something more in launchpadlib generating the urls?
<rick_h_> benji: oh sorry, I messed up. The "response" is a 404 when you take off the 1.0. I didn't realize that.
<benji> rick_h_: I'm glad you figured it out -- because I had gone to other things while you wrote and then forgot you had asked :(
<rick_h_> well, nothing figured out as far as the original issue, but at least I misunderstood it and got past that
 * benji wonders if he's the only one that needs people to mention his name to remember that they're talking to him.
<rick_h_> benji: no, I'm supposed to be working on that
<rick_h_> benji: updating irc habits along with other things
<benji> rick_h_: in that case let me check your question and see if I can suggest anything
<rick_h_> benji: basically something is up with the api talking to/about comment #11 on that bug
<rick_h_> benji: if I loop through all comments using the api it works, but if you try to link directly through the api to comment 11 it fails.
<rick_h_> benji: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/805938/comments/11 works though
<_mup_> Bug #805938: Totem set as default music player after install instead of Banshee <apport-bug> <i386> <iso-testing> <oneiric> <patch> <running-unity> <unity-2d> <unity:Fix Released> <banshee (Ubuntu):Invalid> <desktop-file-utils (Ubuntu):Fix Released> <unity (Ubuntu):Fix Released by canonical-dx-team> <banshee (Ubuntu Oneiric):Invalid> <desktop-file-utils (Ubuntu Oneiric):Fix Released> <unity (Ubuntu Oneiric):Fix Released by canonical-dx-team> <
<benji> rick_h_: I don't remember exactly how the URL generation is divvied up between LP and lazr.restful, but lazr.restful isn't very big and that's where I'd look first
<rick_h_> benji: ok cool. Will head there. I've been chasing the ICanonicalDataURL stuff in LP up until now
<lifeless> statik: flacoste: just confirming we have a call in 70 minutes? (e.g. did the calendar work...)
<flacoste> lifeless: yes
<flacoste> lifeless: 66 minutes actually :-)
<lifeless> clickety click
<abentley> deryck: I'm looking at bug 892211 and I can see the problem: updateFieldVisibilty is calling _extraRenderUI(), which is calling updateFromCookie.  Can we talk about solutions?
<_mup_> Bug #892211: reset to default in bug listing visibility widget doesn't work <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/892211 >
<bac> hi flacoste -- can we decide on the lplib recipe and get it done?
<flacoste> bac: on the phone, will ping you when i'm done
<bac> flacoste: perfect
<deryck> abentley, I'm not available today. cast about for someone else, or I can chat with you about it tomorrow.
<abentley> deryck: okay.
<sinzui> We have a branch that hardens teams to such a degree, that to write a test that logs in as the teamowner, you must first login as an admin
<sinzui> I think I will take a 30 minute break to ponder the irony
<lifeless> bac: out of tree is best here
<lifeless> bac: leverage (ha hate that phrase) the ubuntu packaging
<flacoste> bac: besides what lifeless is saying
<flacoste> what other open issues remains?
<flacoste> given jelmer pointers, i agree that having the debian tree separate is best
<bac> flacoste: where to put it. ~launchpad vs ~lazr-developers
<flacoste> i think ~launchpad is better
<flacoste> ~lazr-developers is hysterical raisins to me
<lifeless> branch ownership?
<lifeless> Its in the wiki
<lifeless> see dev.launchpad.net/CreatingNewProjects
<bac> lifeless: recipe ownership
<lifeless> (tl;dr: ~canonical-launchpad-branches)
<lifeless> LP is in that team, but so are other canonical folk like ex-launchpadders who may help maintain it if they have access
<flacoste> lifeless: any reasons that we kept "or '~lazr-developers'." on that page?
<lifeless> flacoste: wanted it to be consistent with current ownerships
<lifeless> flacoste: no deeper reason
<flacoste> ok, i'd prefer if we don't extend the set of things owner by that team though
<lifeless> flacoste: happy for us to remove if
<lifeless> editing now
<flacoste> thx
<flacoste> bac: so the recipe could be owned by ~canonical-launchpad-branches also then
<flacoste> and i would put this in a ppa on the launchpad team
<bac> flacoste: ok, i'll do that
<flacoste> bac: thanks!
<bac> lifeless: can you expand your thought on, ahem, leveraging the ubuntu packaging?  are you saying we don't need the packaging branch i created?
<lifeless> should be able to use the nest command to grab just the debian dir directly from ubuntu
<lifeless> you may need a packaging branch if we need to diverge
<bac> lifeless: but i'd like for us to be able to update the changelog, thus the branch
<lifeless> hmm, just realised. ~canonical-launchpad-branches may be an issue because of the insane notifications we do. Do we notify recipe owners always?
<lifeless> If so, then ~launchpad will be needed, even if its conceptually wrong.
<lifeless> bac: auto build recipes don't bother with that
<lifeless> bac: that said, it is up to you, I don't have a strong recommendation.
<bac> lifeless: they do get the debupstream version from the changelog
<lifeless> yes, but every build starts fresh from the branches
<lifeless> bac: ah, I think you mean 'I want the package major version to match our releases, not the latest version in Ubuntu'
<bac> lifeless: yes, for the PPA
<lifeless> bac:  you can do that three ways = custom packaging branch; just set it in the recipe rather than using debupstream; make sure we release into Ubuntu very quickly.
<lifeless> bac: the easiest is just to set it in the recipe instead of using debupstream
<bac> lifeless: as seen here: https://launchpad.net/~bac/+archive/ppa
<poolie> hi all
<benji> anyone fancy a quick review? https://code.launchpad.net/~benji/launchpad/bug-894177-2/+merge/84676
<poolie> o/ benji
<benji> poolie: thanks
<poolie> It looks plausible to me but you probably want another review from someone more experienced.
<benji> poolie: thanks
<lifeless> benji: there is a context manager for switching db user
<lifeless> benji: it might be nicer
<benji> lifeless: ooh, indeed it would; thanks
<benji> bac: absolutely, I'm now a card-carying QA instructionist
<lifeless> heh, 3 reviews :P
 * benji looses 10 cross-channel discussion points.
<lifeless> I missed that bac had
<bac> lifeless: sorry, i failed to claim it.
<benji> lifeless: I now feel very good about my MP, thanks ;)
<lifeless> bac: no worries
<bac> lifeless: but it's good as you added the cm bit
<bac> teamwork
<bac> redundancy
<cjwatson> Hmm.  My stripped-down version of lp:~cjwatson/launchpad/refactor-cron-germinate noddy-benchmarks at about twice the speed of the current implementation, for identical output; but I think I've got something wrong that means that it isn't extracting all the benefit it could
 * cjwatson wasn't expecting that
<lifeless> cjwatson: nice
#launchpad-dev 2011-12-07
<lifeless> ok, going quiet to get code written
<SpamapS> awesome.. bzr branch of lp:launchpad ... 10 minutes and counting
<SpamapS> 271502kB  1130kB/s | Fetching revisions:Inserting stream:Done 1297115/1297115
<wgrant> Only 10 minutes? Not bad.
<SpamapS> still not done ;)
<wgrant> It's nearly done.
<wgrant> Here it takes like 2 hours.
<SpamapS> 28952 clint     20   0  777m 693m 3820 R  100 17.6   9:49.48 bzr
<wgrant> LP's history is not small, and bzr 2a fetch is not fast :(
<SpamapS> well 12 minutes wasn't so bad
<SpamapS> $ du -hs
<SpamapS> 298M	.
<wgrant> That's remarkably good.
<SpamapS> considering.. :)
<wgrant> Are you in the DC or something?
<SpamapS> No, I have a 12Mbit downstream tho
 * SpamapS hugs his cable
<wgrant> I have 20Mbps downstream, but can't get more than 180KB/s from most parts of the DC :/
<wgrant> Except to canonistack, where I can saturate my connection.
<wgrant> Just to confuse things.
<SpamapS> Oh I was definitely saturating the 12Mbit
<SpamapS> Some days I can't get 512kbit
<SpamapS> but today has been really fast
 * SpamapS now begins the task fo figuring out how to populate an unbuilt distroseries via the API.
<wgrant> You want to create a new charms series, I guess?
<wgrant> What do you want to populate?
<cjwatson> Phew.  germinate 2.1 released, MP updated, IMO all good bar the shouting now.
<wgrant> Shouting?
<cjwatson> About three times the speed of the current implementation, on mawson anyway.
<cjwatson> http://dictionary.cambridge.org/dictionary/british/all-over-bar-the-shouting
<wgrant> Ah.
<cjwatson> Although it wouldn't surprise me if somebody wanted to shout at me about some bits of the test code. :-)
<poolie> wgrant, i think there is something odd in the network
<poolie> when we measured a while ago we saw substantially faster downloads from another dc machine than from lp itself
<poolie> which is a bit perverse
<wgrant> poolie: I have an RT ticket open.
<wgrant> I was going to blame Optus until I saw that I could download at full speed through the same route up to the DC, except to Canonistack.
<wgrant> So unless they're throttling some Canonical /24s and not others, when I've never had any evidence that they're throttling specific ranges at all..
<poolie> we've measured the same effect from the US
<wgrant> Huh
<wgrant> I've seen some slowness from elsewhere.
<wgrant> But never as slow as I see.
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 3*10^2
<jtv> wgrant: any chance you could help this user?  https://answers.launchpad.net/launchpad/+question/181066
<wgrant> jtv: Could you ask them to retry?
<jtv> I can, yes.  Do they need to bump their version number?
<wgrant> As you may be aware, the last 14 hours have been roughly disastrous.
<wgrant> No.
<jtv> 14 hours?  I heard there have been problems, but wow.
<wgrant> It's all been fixed for a couple of hours.
<wgrant> huwshimi: Could you QA https://launchpad.net/bugs/894535?
<_mup_> Bug #894535: Bug listing arrows appear to be backwards <bug-columns> <qa-needstesting> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/894535 >
<huwshimi> wgrant: Done
<wgrant> huwshimi: Thanks.
<lifeless> poolie: is your new bug a dup of 894535?
<poolie> about the order?
<poolie> no i'm talking about the horizontal order
<poolie> i would expect the headings to be in the same order as the data cells :)
<lifeless> ah, there is a different 89* bug about that
<wgrant> Mmm, unused portlets.
 * wgrant destroys.
<lifeless> right, time to EOD.
 * lifeless EODs
<wgrant> Night lifeless.
<huwshimi> The new https://bugs.launchpad.net/launchpad is a welcome change
<wgrant> Yep
<wgrant> One of the most annoying pages in LP has finally met its demise :)
<huwshimi> :D
<wgrant> Unfortunately the new listings leave me disappointed when I click on a bug, and the old BugTask:+index kicks me in the face.
<wgrant> With the old status/importance styles etc.
<SpamapS> wgrant: to answer your earlier question.. I want to populate the 'charm' distro's new series, 'precise' with all the branches from 'oneiric'
<wgrant> SpamapS: there's branch-distro.py to do that server-side, but it might not do exactly what you want.
<wgrant> Depending on how you want branches to behave between series.
<SpamapS> well I'm thinking that I want them to just be their own thing..
<SpamapS> I will write a script which auto-proposes merges when the branches diverge..
<SpamapS> Most changes to the 'precise' charms will be useful in the 'oneiric' charms.. but I think we're going to have to just manage them as branches.
<SpamapS> auto backporting won't work without something like tarmac verifying that the new charm works on the old OS
<SpamapS> wgrant: so if I read branch-distro.py's underlying code right.. it just copies all the branches from one series to the next. That sounds like what I want.
<wgrant> SpamapS: Heh, sort of.
<wgrant> Effectively, yes.
<wgrant> But it moves the branches to the new series, then creates fresh ones in the old series, stacked on the new series.
<SpamapS> I get that the old branch becomes stacked on the new one.
<wgrant> To the user it just appears that they've been copied, right.
<SpamapS> If our workflow becomes   commit to old branch, merge from old branch to new branch.. I don't see that as being problematic.
<wgrant> I think branch-distro would work for you.
<SpamapS> so I just need a LOSA to run that for me?
<wgrant> Once you're that's what you want, yep.
<wgrant> Once you're *sure*
<SpamapS> I kind of want to have them try it on staging and see what it looks like. ;)
<wgrant> staging doesn't have the branches on-disk, so that won't work.
<huwshimi> Hmm.. that new bugs index was not rolled out under a feature flag
<micahg> wgrant: I still see the bug listing arrows backwards, I did a forced refresh as well
<wgrant> micahg: Can I see a screenshot?
<SpamapS> wgrant: the one thing I'm concerned about is I'm not ready for the dev-focus to be changed to the new series.
<micahg> sure
<wgrant> huwshimi: No. Is that a problem?
<huwshimi> wgrant: I just expected it to be part of the new bugs listing beta. It's a fairly big change, I guess someone will blog about it later or something
<wgrant> huwshimi: It's not a huge change. It's basically just expanding the listing and changing the default sort order.
<wgrant> Which AFAICT nobody liked anyway.
<wgrant> I will be surprised if we hear a single person complaining.
<SpamapS> wgrant: also I can't "initialize" the series because this is an unpublished distro.
<SpamapS> wgrant: I'm guessing that there's another script which will do that.
<wgrant> SpamapS: Right, it doesn't make sense to initialise an unpublished distribution.
<huwshimi> wgrant: I guess
<wgrant> Initialisation copies the packages.
<huwshimi> wgrant: I guess it's not like everyone reads the blog anyway
<SpamapS> OH
<huwshimi> wgrant: Still I would have thought it's big enough change for people to wonder why things are different
<wgrant> huwshimi: Mmm, we don't normally blog about this sort of thing.
<micahg> wgrant: http://people.ubuntu.com/~micahg/bug_listings.png
<wgrant> Or we'd have a very, very noisy blog.
<wgrant> micahg: That's correct.
<wgrant> micahg: Check Nautilus, for example.
<SpamapS> wgrant: so when I'm ready.. how would I change https://launchpad.net/charm/precise to the active dev series?
<wgrant> The arrow points in the direction of increasing value.
<wgrant> SpamapS: That probably requires a Launchpad dev/admin.
<micahg> wgrant: that's how it was before :P, that's why I filed the bug
<wgrant> To change the status.
<SpamapS> ahh
<huwshimi> wgrant: Don't we? We blog about a lot of trivial changes
<wgrant> eg. I tend to do it for Ubuntu.
<wgrant> huwshimi: Recently, yeah.
<wgrant> micahg: Do you have an example of an application doing it the other way?"
<micahg> Increasing usually mean in ascending order
<wgrant> micahg: Right. Critical > High, so Critical should appear higher than High when the arrow is pointing up.
<micahg> no
<micahg> ascending importance should mean critical last
<huwshimi> micahg: Increasing in statuses means going from undecided > Critical
<micahg> right
<wgrant> micahg: Sure, but arrow pointing up is descending, not ascending.
<micahg> huh?
 * wgrant points at Nautilus and probably everything else.
<micahg> is everything upside down on the other side of the world?
<wgrant> Thunderbird as well.
 * micahg goes hunting for proof
<huwshimi> micahg: The arrow follows the content on the page
<micahg> gah, still seems counterintuitive, idk why I never caught it in thunderbird before
<huwshimi> micahg: Ordering by bug number might help you to visualise it
<micahg> no
<wgrant> It does seem somewhat counterintuitive.
<wgrant> But it's how everything else seems to do it.
 * micahg translates the arrow to ascending/descending which is probably the issue
<wgrant> Exactly.
 * micahg checks HIG
<SpamapS> arrows are a terrible way to denote sort order..
<SpamapS> .oO would be better
<SpamapS> arrows imply direction, but not origin
<huwshimi> micahg: bug #1 is at the top of the page down to #100 at the bottom so the arrow is pointing down, when #1 is at the bottom of the page and #100 is at the top the arrow points up. Both of these follow the direction of the content
<_mup_> Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Prog
<huwshimi> _mup_: Shhh
<micahg> huwshimi: right, that's what I take issue with :)
<wgrant> micahg: Which browser are you using? Your fonts are ugly and misaligned.
<micahg> firefox 9 beta
<wgrant> Hm, does it have any subpixel rendering at all?
<micahg> wgrant:  it should, but I might not have my display configured properly
<micahg> huwshimi: wgrant: the HIG in 6.14.1 seems to agree with what you've done, so I'll resign myself to being confused: http://developer.gnome.org/hig-book/3.0/controls-lists.html.en#controls-lists-sortable
<micahg> GNOME HIG that is
<wgrant> I was confused initially, don't worry :)
<wgrant> Probably because I mostly use sortable columns in Thunderbird, which defaults to the *bottom* of the list.
<micahg> right, I'm just used to ignoring the arrows in thunderbird I guess
<micahg> since I sort once and forget it
 * micahg seems to agree with gnome 305277
 * micahg guesses mup isn't ubottu :)
<micahg> https://bugzilla.gnome.org/show_bug.cgi?id=305277
<huwshimi> micahg: When you reported the bug there was actually a bug which meant the direction of the arrows was not consistent for ascending or descending which probably didn't help
<micahg> huwshimi: that's not why I filed the bug though :), I guess I didn't notice that since it was counterintuitive to begin with
<huwshimi> micahg: The Code was supposed to be in the opposite direction of what it is now (so, apart from the bug, it was originally in the directions your bug report wanted them to be)
<bkerensa> :D
<adeuring> good morning
<jtv> cjwatson: hope you don't mind the piecemeal review style.  I was also on call for other things today, so this was a way to mitigate risk of distraction.
<cjwatson> jtv: that's fine, I'm just trying to keep up. :-)
<jtv> :)
<cjwatson> jtv: hope in turn you don't mind lots of piecemeal commits to fix things
<jtv> I see you already restructured runGerminate.
<jtv> No, that's fine.
<jtv> It makes it a bit harder to follow but turnaround's fair play.  Plus, it's fun to see the changes happening!
<cjwatson> Still in progress on that.  I'm trying to sort out the inner body first and then figure out how/whether it should be split up further.
<cjwatson> The closure question is a bit difficult.  I'm trying to balance clarity there against having methods with too many arguments.  The functional programmer in me likes closures, but they don't seem to result in awfully clear Python sometimes.
<jtv> ISWYM.  It's a tough tradeoff.  In a functional language you don't have assignments to worry about.
<jtv> And a class is probably overkill.
<cjwatson> I actually want curried functions for composeOutputPath, really ...
<jtv> Yeah.  :)
<jtv> ISTR there being a bind() in the python standard library somewhere, but have always been too lazy to look it up.
<cjwatson> So I'll simplify everything else and see how it looks.
<wgrant> functools.partial?
<jtv> That'd have to be it.
<cjwatson> Interesting, quite a few callers in LP already.  I'll look up house idioms.
<wgrant> It's very handy.
<jtv> BTW, unrelated tip, for makeSeedStructure in the tests: instead of âif seed_name in seed_inherit:â you could probably have a single code path with seed_inherit.get(seed_name, [])
<jtv> Neat!  test_name_is_consistent & test_name_is_unique_for_each_distro
<cjwatson> .get> oh yes.
<cjwatson> Can't claim credit for that; that was stolen from test_generate_contents_files.
<jtv> It did sound familiar.  I think I wrote that.  :)
<cjwatson> Nice to know you like your own code. ;-)
<jtv> cjwatson: I must admit that, knowing that, my comment about the high quality of the branch seems a bit self-serving in retrospect.  :)
<cjwatson> Heh.  I mostly just used it to fill out an initial skeleton; I'm still unfamiliar enough with Launchpad that cargo-culting is a good strategy to get me started.
<rick_h_> morning
<jtv> cjwatson: I guess most of the test_germinate_output_task tests could be unit tests for an extracted âcalculate output taskâ method.  It would save a lot of setup.  But it's useful of course to have at least one test that does do all of that and tests the integration of a larger scope of the code.
 * jtv watches the code break into smaller parts
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<cjwatson> jtv: Yep, that's more or less what I did
<cjwatson> jtv: Oh, I think the reason I wrote makeSeedStructure that way was that I didn't want the trailing space in the no-inheritance case; that meant that I could just do a straight file comparison with the output.
<cjwatson> jtv: It got a bit twisty when I tried to use .get.
<cjwatson> ("%s: %s" % (seed_name, seed_inherit.get(seed_name, []))).strip() or something
<jtv> cjwatson: Or just treat the "%s:" % seed_name as one of the elements of the list, I guess.
<jtv> " ".join(["%s:" % seed_name] + seed_inherit.get(seed_name, [])) ?
<jtv> Also a bit involved, I must admit.
<cjwatson> jtv: on open(path).read(), Julian criticised a previous branch of mine where I did that in tests and asked me to use 'with' instead
<cjwatson> jtv: https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618
 * jtv reads
<bigjools> "critiqued" :)
<cjwatson> well, OK :-)
<rick_h_> context managers ftw
<jtv> Don't file handles get GC'd?
<rick_h_> eventually, context manager make sure it happens on exit
<rick_h_> well, exit of the block you use it with
<jtv> In this case, âeventuallyâ is fine AFAICT.
<rick_h_> good habits and all that
<jtv> If you neglect to do it while writing, python will generally punish you very quickly.
<cjwatson> I don't hugely mind either way in this case, but it does seem odd to be told to change A to B by one reviewer and B to A by another, so maybe some consistency would help. :-)
<cjwatson> (I agree there doesn't seem a desperate rush to close the handle, but whatever)
<bigjools> it's not the tardy GC as such, it's the open file
<jtv> But doesn't the GC also close the file?
<bigjools> yes - but when?
<jtv> Soon enough, evidently.
<cjwatson> You might imagine a situation where tests churn through file handles fairly quickly and the GC doesn't get round to dealing with them until you run out of file handles.
<cjwatson> Whether that actually happens in practice I don't know.
<bigjools> ARGH fucking cached WADL
<cjwatson> The system limit is typically large but not enormous.
<jtv> Python might even detect the situation and do an extra GC.
<soren> cpython closes it (pretty much) immediately, but other Python implementations (notably pypy) might take a while.
<bigjools> it's better to be explicit IME
<wgrant> Everything other than CPython is unreliable.
<wgrant> You're meant to close explicitly.
<wgrant> (and it's just so easy to do it with context managers nowadays)
<soren> And, for clarity, that is *fine*.
<soren> The Python spec doesn't say anything about this.
<wgrant> Sure.
<jtv> Crazy cat.  I just let you _in_.
<soren> So it's up to the implementation to make this decision.
<wgrant> Well, "Python spec"
<wgrant> lol
<soren> *g*
<soren> fsvo
<jelmer> wgrant: The only spec I trust is written in C :P
<wgrant> Heh
<rick_h_> but haven't you heard, pypy is fast :)
<wgrant> Anyway, Jython, IronPython, PyPy all have more sane GC processes than CPython. I suspect all alternate implementations do.
<wgrant> And considering how PyPy will hopefully rule the world in a couple of years...
<jtv> That takes me back to my JVM programming days.  "You caught us.  No it doesn't really work like the spec says.  But we have a solution for that: we call our code the spec, and not the thing we publish as the spec."
<bigjools> I want to make a new Python interpreter and call it TrouserSnake
<jtv> Him and his dirty mind.
<rick_h_> so debugging question for you all, if I had a pair of ids for Message objects, and I wanted to "see" them to find out wtf they were and maybe compare how they were different. How would I get at them? Normally I'd expect to just look at the db, but this is on production
<jtv> In some languages(*) python already means trouser snake.  There's instances of Python websites being censored because automated translation software says they could have naughty things on them.
<jtv> rick_h_: put together a query, ask an admin to run it against a production slave?
<wgrant> rick_h_: Oh, you are looking at that NoCanonicalUrl bug, aren't you...
<wgrant> Not a good thing to start on :)
<rick_h_> wgrant: yes
<rick_h_> heh, well originally we thought it was something where I could see how iMessage was used
<wgrant> bwahahah
<wgrant> Several people have looked at that and failed, IIRC>
<rick_h_> wgrant: but now I'm stuck digging at how half the url, lazr restful, and all that works
<wgrant> Yeah...
<rick_h_> wgrant: ok, well now I don't feel bad I didn't just *figure* it out yesterday afternoon
<wgrant> I think we may be getting a raw Message out where we're meant to have a BugMessage. But it's been a good year since I last looked.
<rick_h_> ok, but this is good, I'll finally poke at the database and maybe figure out how to generate a query to be run
<rick_h_> that'll be fun
<rick_h_> wgrant: yea, the thing I notice is that the failing one has a patch on it
<wgrant> You'll most likely fail, but you'll learn lots about our infrastructure :)
<rick_h_> wgrant: so I'm wondering if somehow the patch has a url/path getting generated?
<rick_h_> wgrant: yea, I guess the goal is for me to learn parts of the system and I can do that in failure. But man I hate failing...
<rick_h_> but my goodness is this whole url generating stuff convoluted. It's interesting to work on a project where I can't just download the prod db and fire in debug code/debugger steps
<wgrant> Hmm.
<wgrant> I think I know what it probably is.
<jtv> cjwatson: you have been reviewed.  I'm off for food now, before I start hunting for those crickets that I'm hearing like the cat does!
<wgrant> rick_h_: The message probably has a parent that isn't a comment on the bug.
<rick_h_> wgrant: yea, that's what I was kind of curious about. I see the stuff that iterates through the url looking for more parts to generate and curious how this comment differs from the one before/after which work
<cjwatson> jtv-afk: Yay, thank you.  I'll go hassle folks about the deployment steps ...
<wgrant> rick_h_: So, I can confirm that in this case the exception is generated about comment #11's parent message. And that parent message is not a comment on the bug.
<wgrant> Not a comment on any bug, in fact.
<wgrant> THat might help you reproduce it locally.;
<cjwatson> jtv-afk: I found a way to write makeSeedStructure that avoids multiple paths without being too twisty, I think.
<rick_h_> wgrant: ok, interesting. thanks
<rick_h_> wgrant: hmm, when I check each comment's parent attrib via the api I get None for all of the comments
<rick_h_> wgrant: different "parent"s?
<wgrant> rick_h_: That's the only message on the bug with a parent.
<wgrant> Only comments that were emailed in have parents.
<rick_h_> wgrant: how did you see it had a parent?
<wgrant> I'm magical.
<wgrant> And have access to dogfood's DB.
<wgrant> Which is a 2.5-month-old snapshot of prod.
<rick_h_> wgrant: strage that the api says it has no parent, but the db says so
<nigelb> I always knew wgrant was magical :D
<wgrant> rick_h_: Hm? The API doesn't say it has no parent. It crashes when trying to say that it *does* have a parent.
<wgrant> AFAICT
<rick_h_> wgrant: right, but if I launchpad.bugs[805938] and print parent for m in bug.messages I get None for all, including 11
<wgrant> rick_h_: Ahh
<wgrant> That's different.
<wgrant> Evilly different.
<rick_h_> wgrant: hmm, actually I show (via that api stuff) that comment 7 has a parent of comment 6
<wgrant> That uses a special property (Bug._indexed_messages or something) to precache the parents.
<wgrant> rick_h_: Bah, yeah, you're right, I missed one.
<rick_h_> wgrant: ah, ok I saw that stuff somewhere
<wgrant> 7's parent is 6, 11's parent is some other random message somewhere.
<wgrant> Not on any bug.
<rick_h_> wgrant: when it tries a couple of methods to generate the CanonicalUrlData it tries the cache and then if that fails generates one I think
<wgrant> Possibly on a mailing list or something.
<wgrant> rick_h_: Aha
<rick_h_> wgrant: more magic kicking in?
<wgrant> rick_h_: The problem is indeed what I said, and it's in _indexed_messages.
<wgrant> No more magic, no.
<wgrant>                 if parent is not None:
<wgrant>                     # If there is an IndexedMessage available as parent, use
<wgrant>                     # that to reduce on-demand parent lookups.
<wgrant>                     parent = message_by_id.get(parent.id, parent)
<wgrant> So, if the parent is a comment on the same bug, it will replace the BugComment's parent Message with the corresponding BugComment.
<wgrant> BugComments have URLs.
<wgrant> But if the parent is *not* a comment on the same bug, the parent will remain as a Message, which has no URL.
<wgrant> boom.
<rick_h_> wgrant: right, gotcha
<rick_h_> wgrant: ok, that makes sense since I could find no way to build a url to a message (was looking at that vs trying to hit the db quuery)
<wgrant> Best way to solve this is probably just to say the parent is None in that case. Since messages don't have URLs.
<wgrant> Since they may be referenced in many places.
<wgrant> eg. I can send one email to 200 bugs, it will be stored as one Message.
<rick_h_> wgrant: orly, interesting
<wgrant> At least that's how it's meant to work -- if the content and message-id are the same, it's meant to only store one copy.
<rick_h_> yea, I see that it stores the email id in the row
<rick_h_> so a Message can be either an email or form entered text?
<wgrant> Right.
<wgrant> In the case of an email, we parse In-Reply-To, look up the corresponding Message, and link it up with Message.parent.
<rick_h_> now could the parent be something else that *does* have a url?
<rick_h_> or is the parent always another message? and if it's a message it's either a bug/url-able or  an email (which is not urlable)
<wgrant> The parent is always another Message.
<rick_h_> and excuse my indicision on if url-able is hyphenated or not :)
<wgrant> URLable? :)
<benji> rick_h_: it's urlificable, obviously
 * wgrant should sleep.
 * rick_h_ smacks head
<wgrant> rick_h_: https://bugs.launchpad.net/launchpad/+bug/901124 and https://bugs.launchpad.net/launchpad/+bug/901122 have generated several complaints today -- the new bug listings cause pretty much constant timeouts on large Ubuntu bug searches. Can someone from your squad look at these pretty urgently?
<_mup_> Bug #901124: New bug listings get length of collection twice <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901124 >
<_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901122 >
<rick_h_> wgrant: I'll bring them up at our stand up in an hour
<wgrant> Thanks.
<mrevell> matsubara, Are you able to, easily, calculate the median len of a bug title? If not, I'll use your data to calculate one.
<matsubara> mrevell, I can give it a shot. My SQL knowledge isn't that great
 * matsubara looks for postgresql docs
<mrevell> matsubara, Oh, hey, I was just going to pop the data in a spreadsheet and then organise it into columns. Don't worry, I'll just do it.
<rick_h_> http://plusplus.wordpress.com/2009/11/18/finding-median-with-postgresql/
<rick_h_> matsubara: ^
<matsubara> mrevell, ok
<matsubara> rick_h_, thanks!
<rick_h_> deryck:  https://bugs.launchpad.net/launchpad/+bug/901124 and   https://bugs.launchpad.net/launchpad/+bug/901122
<_mup_> Bug #901124: New bug listings get length of collection twice <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901124 >
<_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901122 >
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 3*10^2
<lifeless> stub: hey
<adeuring> abentley: there are some differences between the names of display flags like "show_last_updated" and related sort parameters, like date_last_updated, while other names "relate better", for example "show_assignee" (display flag) and "assignee" (sort parameter), where one can simply add/remove the prefix "show_". Would something explode if I change the flags in templates/buglisting.mustache and in BugListingConfigUtil.field_display_names so 
<lifeless> flacoste: apologies for the TL meeting; will be getting a CT scan of my sinuses
<flacoste> lifeless: ok, sleep weel in the mean time :-)
<lifeless> flacoste: EBABY :P
<flacoste> gary_poster: since you are hosting ^^^
<abentley> adeuring: You cut off at "and in BugListingConfigUtil.field_display_names so"
<lifeless> flacoste: 0446 now, had alarm set for 0550 to get up anyhow, as its a bit of a drive
<adeuring> abentley: ...so that all "show_" names match corresponding sort options?
<abentley> adeuring: Nothing will explode, however, I think that we should try to make our internal names match the external names.
<abentley> "Last updated" is the text we're currently using.
<adeuring> abentley: I see your point-- but "correlating" the sort buttons and the "show_.*" flags is in this case a bit messy...
<adeuring> abentley: and "show_id"  does not match "Bug number" that well ;)
<adeuring> (in a very literal sense...)
<abentley> Is it a matter of the sort buttons or of the terminology used by orderby?
<jcsackett> sinzui: got a few moments to chat?
<adeuring> abentley: the code that shows/hides the sort buttons needs to have an idea about the relation between  sort parameter names (fixed)  and the field to display. I am curtrently  "translating" for example betwwen "bug_heat" (display flag "show_bug_heat") and the sort option "heat". That's ugly and error prone
<lifeless> allenap: you say to see the bug report for details, but the bug report says 'we should talk' :P
<allenap> lifeless: I wonder if I linked to the wrong bug :-/
<abentley> adeuring: But it also seems like you're reluctant to change the name of the sort option "heat".  I am guessing you are reluctant because it's used directly by orderby.  Is that right?
<lifeless> allenap: https://bugs.launchpad.net/storm/+bug/887240
<_mup_> Bug #887240: test_terminated_backend test failure <Storm:New> < https://launchpad.net/bugs/887240 >
<allenap> lifeless: Yes, I did, and my branch name is all wrong.
<allenap> lifeless: https://bugs.launchpad.net/psycopg/+bug/900702 is the correct bug.
<_mup_> Bug #900702: pgbouncer error in test suite, psycopg went psycotic <psycopg:New> <Storm:Triaged by allenap> < https://launchpad.net/bugs/900702 >
<allenap> Sorry.
<adeuring> abentley: yes, that would affect quite old code in the class BugTask, for example, including the need to have aliases for old sort names. People may have bookmakrek URLs with "?orderby=heat"
<stub> lifeless: yo
<lifeless> stub: categorising patches
<lifeless> stub: I think adding a suffix would do it simply enough - patch-2011-44-0-concurrent.sql
<lifeless> (meaning all nodes no xact)
<lifeless> options being std, direct, concurrent
<stub> lifeless: Or subdirs or something like that - yer.
<lifeless> stub: then the upgrade can do all ordered patches from $ next to apply up to the first type change.
<lifeless> stub: how does that sound?
<abentley> adeuring: That's what I thought.
<bigjools> lifeless: enjoying being a parent then? :)
<lifeless> bigjools: very much
<lifeless> bigjools: just not every second of:P
<bigjools> :D
<abentley> adeuring: if you want to change it so that our new values match the legacy orderby values, that will work.  I think if I was doing it, I'd just translate the new values into the legacy values when emitting orderbybar:sort
<lifeless> allenap: so yes, looks like you linked the wrong bug, and/or they are dupes
<stub> lifeless: Sure. One thing to ponder - originally we picked numbers and applied sequentially because we wanted to ensure patch 1 applied before patch 2 in case there was a dependency. By applying a subset of patches (those that can be applied by the currently selected process), we lose that a bit. Should the patch type be considered the first part of the patch number?
<stub> oic. up to the first type change.
<adeuring> abentley: there is at least one more translation necessary: When the "currently active sort button" is highlighted at page render time. That's possible, and probably not as ugly as my current implementation, but I don't like it that much nevertheless
<stub> yer, that would work and sidesteps my issue. Or non-issue, as dependencies are extremely rare in practice.
<allenap> lifeless: I'll remove the bit in 900702 that refers to test_terminated_backend. It keeps confusing me.
<allenap> I'd like to treat them as separate problems.
<lifeless> stub: they do happen though, actually quite a bit more now because of the 'split patches into bits to reduce downtime' effort
<lifeless> stub: so I think its good to keep that ordered protection
<stub> k
<lifeless> stub: we can have a --all mode which loops repeatedly doing the upgrades type by type (still in order)
<lifeless> e.g. 4 std's, 2 concurrents, 1 direct, 2 stds etc
<abentley> adeuring: yes, I can see how your solution would be simpler, then.
<adeuring> abentley: ok, so'll go that route
<deryck> adeuring, the bug you're doing on the kanban is bug 898200 which abentley marked a dupe of bug 295214, presumably because your fix will fix that old outstanding issue...
<_mup_> Bug #898200: Can't sort bug list by customized fields <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/898200 >
<_mup_> Bug #295214: match input and column headers searching bugs related to.... <bug-columns> <confusing-ui> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/295214 >
<deryck> adeuring, so I'll just fix up the card and the bug assignment, if you have no objections.
<adeuring> deryck: ok
<lifeless> allenap: so are we saying we are unsafe to run with psycopg2.4 ?
<bac> hi flacoste, the daily build into the ~launchpad PPA for python-launchpadlib is now working.  can we talk about whether an SRU is needed or not?
<lifeless> allenap: disabling the test seems to mean folk won't get warning that the entire disconnect codepath is unusable
<allenap> lifeless: Only if pgbouncer is killed unceremoniously, then we get a "psycotic" error.
<allenap> lifeless: Yeah, that's a fair point.
<flacoste> bac: on the phone, will ping you afterward
<lifeless> allenap: I'm not sure what to do about it, but it seems like a Big Red Light to me :)
<bac> flacoste: ok.  will disappear in 20 minutes for lunch.
<allenap> lifeless: There's a demand for a clean build. If a test is known to fail then it's not worth running it. A skip is added, so users running the test suite will get a message about it.
<flacoste> bac: ok, I'll grab you when i come back from lunch then
<lifeless> allenap: a clean build is important too :)
<lifeless> allenap: like I say, I'm not sure what to do about it, just raising it for consideration
<allenap> lifeless: Okay. If we ensure the tests are run with trial I could instead add a .todo attribute to the test method to mark it as an expected failure.
<lifeless> allenap: testtools/unittest2 also have xfail
<allenap> lifeless: Storm seems to be avoiding testtools. I guess I could change that.
<lifeless> +1
<lifeless> <- not biased AT ALL
<allenap> Spin up the yak shearers.
<allenap> :)
<allenap> Sometimes I dream that I'm back playing Quake, online from my college room, but weapon 1 is shears and I'm facing an undead yak horde.
<lifeless> \o/
<deryck> rick_h_, looking at your mpâ¦ a minor thing:  we spell "function (node) {" as "function(node) {" without the space.
<lifeless> allenap: I've been yak shaving for ~ 4 month straight now ;)
<rick_h_> deryck: sorry, thought I find/replaced all those
<allenap> Hehe :)
<deryck> rick_h_, I'm please to see you've cut down on your newline obsession too :)
<lifeless> allenap: gpgverifyd -> needs oops -> oops-* -> needs console -> oops-tools -> needs scriptactivity -> needs slony db migrations -> lazr-postgresql
<rick_h_> deryck: with monumental effort!
<lifeless> allenap: I am going to party -so- hard when I unwind this yak shaving chain
<deryck> rick_h_, those a minor, niceties, though. I'm working through the functionality now.
<allenap> lifeless: Wow :)
<lifeless> allenap: all in the name of having a demo microservice to point at!
<allenap> lifeless: It'll be worth it in the end.
<lifeless> totally
<lifeless> and the bits done so far are working very well, if I do say so myself
<rick_h_> deryck: hey, ? regarding running tests. I'm trying to run the test_bug_messages.py and I'm getting http://paste.mitechie.com/show/465/
<rick_h_> deryck: am I trying to run this wrong then?
<deryck> rick_h_, try spelling it:  ./bin/test -cvt test_bug_messages
<rick_h_> deryck: ah thanks, that seems to be doing something a bit better
<abentley> rick_h_: -t matches the test-id.  You can also match on module names.  I don't know if there's a way to match file paths.
<rick_h_> abentley: thanks, yea I originally started with test.py and the .py seems to be what got me off wrong
<allenap> lifeless: I say so too, they're tip top.
<lifeless> allenap: thanks!
<rick_h_> allenap: sorry, wrong channel
<bigjools> lifeless: where's the wiki page on using feature flags?  I am full of fail today
<rick_h_> allenap: skype/mumble work for you? Might be a bit easier
<allenap> rick_h_: Skype's good, I'm gavinpanella.
<lifeless> dev.
<allenap> rick_h_: What's the bug #?
<rick_h_> allenap: ok added, let me know if you don't see something in a sec
<rick_h_> https://bugs.launchpad.net/launchpad/+bug/808952 allenap
<_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
<bigjools> abentley: I match files with "bin/test -cvv <file>"
<allenap> rick_h_: Ring when you're ready.
<abentley> bigjools: I thought that only worked on module names.  It works on full file paths?
<bigjools> abentley: for file paths you need to use.a.dot.path IIRC
<bigjools> it works on files if not file paths as I said, at least
<abentley> bigjools: That's what I meant by "You can also match on module names."
<bigjools> ah I missed that
<bigjools> these dark nights screw with my head it seems
<sinzui> jcsackett, I do. Sorry about the delay, my house is flooding
<jcsackett> sinzui: no worries, a flooding house sort of takes priority. :-P
<lifeless> later y'all
<abentley> deryck: BugListingConfigUtil.setCookie() with no parameters doesn't clear the cookie for me, because it's not passing the "path" option to Y.Cookie.remove.  However, I can't reproduce this issue in a test.
<deryck> abentley, I thought remove only took the name of the cookie, i.e. in a foo:bar cookie, simply passing in "foo" as an argument.
<deryck> which is what I thought I did.
<abentley> deryck: No, you have to pass in the same options as you used to create the cookie (except Date, because deleting a cookie means setting expiry to the UNIX epoch)
<deryck> abentley, not according to the yui3 cookie docs I just checked.  unless our version is out of sync with the latest docs.
<abentley> deryck: "A cookie created with specific options can only be deleted by specifying the same options" -> http://yuilibrary.com/yui/docs/cookie/
<deryck> abentley, ah, ok.  sorry.  but the test does pass without specifying the options?  but it doesn't actually work?
<abentley> deryck: Yes, the test does pass, and I can see the cookie value changes when the test simulates a reset.
<abentley> deryck: changes to "", which I assume is "no cookie".
<deryck> abentley, essentially, yes.  but it would be better to delete the cookie entirely.
<deryck> abentley, so is the question "how do I test I've removed the cookie properly?"
<abentley> deryck: Actually, it looks like get Y.Cookie.get(this.cookie_name)) returns null if the cookie is not defined.
<deryck> abentley, yes, that would have been my suggestion.  Sorry, I didn't follow what you were asking initially.
<deryck> Assert.isNull(Y.Cookie.get('foo'))
<abentley> deryck: neither did I :-)
<deryck> abentley, heh. no worries then :)
<bigjools> abentley: can I bug you for a sec please, trying to write a new test for a merge proposal template change and failing miserably!   https://pastebin.canonical.com/56859/
<abentley> bigjools: looking
<abentley> bigjools: I don't know if we've ever executed the view in our tests before.  It looks like that gives us a traversal problem.
<bigjools> yeah I've had this before in other parts of the code base
<bigjools> the other option is to edit a story test....eek
<abentley> bigjools: Have you considered using getViewBrowser?
<bigjools> I havent', how does that change things?
<abentley> bigjools: That will use the proper infrastructure to initialize the and execute the view, then give you a Browser whose .contents will be the result.
<bigjools> worth a shot, let's see
<abentley> bigjools: see test_conversation for an example.
<bigjools> gotcha
<bigjools> abentley: test passing, thanks!
<abentley> bigjools: np.
<bigjools> I should look in lp/code more often, there's some testing gems in there
<bigjools> can't create MPs when the branch scanner is looking at your branch it seems :(
<deryck> rick_h_, so just looking at the code, I have no serious concerns.  Just a few stylistic comments I can add to the MP.  I'll mark it approved, but would like you to make the changes I post, unless you have strong concerns about anything I suggest...
<deryck> rick_h_, however, trying it locally manually, I see a bug, I think.
<rick_h_> deryck: sure thing on the style changes
<deryck> rick_h_, if I add a really long description to a bug, and then go into edit mode again to update it, the text area shrinks to a smaller default size, and then expands again to expected size after the first change.
<deryck> I say "default" size because it changes to that same smaller size when I enter edit mode each time.
<rick_h_> deryck: looking
<rick_h_> deryck: hmm, it looks as if the old code manually set a width on the textarea that I missed and I'm not setting. So it flows father out.
<bac> hi flacoste
<rick_h_> deryck: I'll look at the original code and see if I can find what I missed
<flacoste> hi bac
<deryck> rick_h_, ok.  and for me, it's excpetionallyy short.  but I used a *huge* description to test.
<flacoste> bac: so SRU or not
<bac> flacoste: yep.
<flacoste> why wouldn't want to SRU?
<bac> flacoste: the number of affected users is pretty tiny.
<rick_h_> deryck: I'm not following? I think what you're saying is that the textarea extends out past where the originall div that showed the content is?
<rick_h_> deryck: or do you mean something else?
<bac> flacoste: and a lot of the stuff rolled into the current version of lplib may not make it past the SRU guards, so we'd have to cherry pick the change.  it looks like a lot of effort for not much gain, IMO.
<deryck> rick_h_, no.  the text I added runs 50-60 lines long in the browser window.  I'm using a 1024 or 1180 size window.  when I enter edit mode, the size of the text area is only 20-30 lines long until I make my first edit...
<deryck> rick_h_, then it expands to the 60 or so lines as before.
<rick_h_> deryck: oh ok, that's different then.
<flacoste> bac: how do you know the number of affected users is tiny?
<rick_h_> deryck: ah ok, I can reproduce that. Thanks
<flacoste> most people who writes lplib script regularly have been affected by the issue
<flacoste> at least, that's the impression i got
<flacoste> i've encountered it
<flacoste> poolie did
<flacoste> james_w did
<flacoste> jml did
<deryck> rick_h_, cool
<bac> flacoste: i got the impression, perhaps from talking to steve, that he was the main person affect.  that could be wrong.
<flacoste> bac: ok, let's not request a SRU at this time, if they want to do one, they know where to get it
<flacoste> the fact that there is a PPA to get the latest version makes it easier anyway
<james_w> this is storing the wrong thing in the keyring?
<flacoste> james_w: yep
<bac> flacoste: ok.  that was my thought
<lifeless> I've missed the chat obviously ;) - we should request a new release into precise
<lifeless> once Ubuntu has *that*, the SRU process becomes largely internal.
<lifeless> (to Ubuntu)
<flacoste> lifeless: wow, they have WIFI in CT scan in New Zealand!
<bac> lifeless: 1.9.11 has been packaged into sid and wheezy
<lifeless> flacoste: I'm using my phone as an AP
<lifeless> bac: sweet
<james_w> I haven't hit that
<flacoste> lifeless: doesn't that interfere with the machinery? ;-)
<lifeless> bac: I haven't checked freeze dates recently, but thats probably sufficient
<flacoste> james_w: ah, my mistake then
<deryck> rick_h_, I think I'll mark this needs fixing after all, not to be a jerk about it. but just to be able to take a look again once it's fixed.
<deryck> rick_h_, and I'll add my other notes now.
<lifeless> flacoste: I'm not in the same room as the machinery at the moment :)
<james_w> but I've seen some complaints so I think it's worth SRUing
<rick_h_> deryck: no definitely, thanks
<flacoste> bac: what's in lucid?
<bac> flacoste: 1.6.0
<lifeless> flacoste: I doubt it would handle voip, but the phone does a decent job of basic connectivity
<flacoste> bac: but if i recall, the problems started with natty
<flacoste> bac: what's in natty?
<flacoste> and oneiric
<lifeless> flacoste: rmadison is your friend
<bac> 1.9.7 and 1.9.8
<flacoste> lifeless: yes, bac privmsg me the rmadison output
<lifeless> $ rmadison python-launchpadlib
<lifeless> python-launchpadlib | 1.6.0-0ubuntu1 |         lucid | source, all
<lifeless> python-launchpadlib |    1.6.1-1 |      maverick | source, all
<lifeless> python-launchpadlib | 1.9.7-0ubuntu2 |         natty | source, all
<lifeless> python-launchpadlib |    1.9.8-2 |       oneiric | source, all
<lifeless> python-launchpadlib |    1.9.9-2 |       precise | source, all
<lifeless> :P bah
<lifeless> whats the new tag again
<lifeless> selfinflicted?
<lifeless> (for bug 901332)
<_mup_> Bug #901332: AttributeError: 'SourcePackage' object has no attribute 'personHasDriverRights'  nominating a bug <bugs> <disclosure> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901332 >
<flacoste> lifeless: fallout
<flacoste> if regression isn't appropriate
<flacoste> bac: so everything after 1.9.8 is bug fixes and doc tweak really
<lifeless> flacoste: its both
<lifeless> flacoste: the use case used to work
<flacoste> how can it be both
<flacoste> so it's a regression
<lifeless> flacoste: now it doesn't
<flacoste> not a fallout
<lifeless> flacoste: the cause of it breaking is feature work
<flacoste> regression
<lifeless> flacoste: ok, so fallout is strictly 'something new that crashes' ?
<flacoste> yep
<flacoste> to get what isn't covered from regression
<bac> flacoste: and a script addition
<flacoste> right, but that shouldn't be a problem
<lifeless> flacoste: yeah, brain is a bit messed up from EBABY start at 4am.
<lifeless> flacoste: thanks
<sinzui> flacoste, I marked it fallout
<sinzui> I landed it as a pre-req for feature work
<lifeless> sinzui: its broken previously working nominations though
<lifeless> sinzui: doesn't that make it a regression ?
<sinzui> It can be both. I treat regressions (and fallout) as top priority kanban cards
<lifeless> sinzui: So francis wants tags to partition new criticals, so we can assess the sources.
<lifeless> sinzui: I don't think it can be both under that constraint - and as it affects existing users/use cases, I don't understand why it isn't a regression
<sinzui> okay I will switch to regression
<abentley> deryck: It appears that Y.Cookie._setDoc({cookie: ""}); prevents Y.Cookie.remove() from working properly, because the browser does the actual deletion, not JavaScript.
<deryck> abentley, ah, ok. that's needed for cookie testing in chromium though.
<bac> so flacoste did we come to a conclusion?
<flacoste> bac: let it lie for now, unless Ubuntu wants a SRU
<flacoste> which i'll check with them
<bac> flacoste: ok
<abentley> deryck: test_form_reset_removes_cookie is currently broken.  I guess I'll fix it on FF by doing Y.Cookie._setDoc(Y.config.doc)
<bac> flacoste: shall i mark those bugs as fix released?
<bac> i guess so since they are released *somewhere*
<deryck> abentley, on TL call now, but first reaction is that should work.
<deryck> abentley, I don't recall why I didn't do that.  I knew about that approach.
<flacoste> bac: yep
<poolie> sladen, hi, do you have any advice on https://code.launchpad.net/~mbp/launchpad/714831-beta-font/+merge/84716
<poolie> actually that should be https://code.launchpad.net/~mbp/launchpad/714381-beta-font/+merge/84716
<bkerensa> flacoste: You available?
<abentley> deryck: I'm the sole OCR and don't want to self-review.  Could you look at https://code.launchpad.net/~abentley/launchpad/fix-reset-to-default/+merge/84833 ?
<flacoste> hi bkerensa
<flacoste> bkerensa: if you want to talk about the new custom bugs listing, talking to deryck or mrevell (now offline) is probably better
<bkerensa> flacoste: Hi looking for someone to talk to on the LP Team about the new bug listings and any work your doing over the next couple weeks
<bkerensa> ahh ok
<bkerensa> :D
<bkerensa> deryck it is then :)
<deryck> hi bkerensa
<bkerensa> hi
<bkerensa> deryck: ^ :)
<deryck> abentley, can you ask around for someone? I've been busy all day and still need to spend some time on this timeout stuff.
<abentley> deryck: sure.
<deryck> abentley, or else I can get it here when I get some bandwidth
<deryck> abentley, ok, thanks!
<deryck> bkerensa, do you have specific questions, or just want me to give you a run down of where we're at and what's going on?
<bkerensa> deryck: Just  brief run down so I can put it in the Devel News :)
<deryck> bkerensa, ok. so we're fixing a few outstanding known issues this week.  issues both that we knew about going into beta and issues discovered in beta...
<deryck> bkerensa, we've got a little UI polish on going to -- the order by options should match the items displayed and we'll have a nicer loading indicator.
<deryck> bkerensa, the "bug-columns" tag on launchpad's bugs is a good one to watch for activity around this feature.
<deryck> bkerensa, there's some work going on to fix timeouts from the new data, too.
<deryck> bkerensa, I think that's about it.
<bkerensa> deryck: ok thanks :D
<deryck> np
<abentley> bac: Any chance you could do a reivew?  I'm OCR today and don't want to self-review.
<bac> abentley: sure, in a bit.  MP?
<abentley> bac: https://code.launchpad.net/~abentley/launchpad/fix-reset-to-default Thanks.
<abentley> bac: abort.  jcsackett took it.
<bac> abentley: ok
<flacoste> bac: bryce (who escalated the bug) would like SRU for natty and oneiric
<flacoste> bac: he's willing to help out with those
<bac> flacoste: i just saw that
<flacoste> i'll tell you'll be in contact
<flacoste> tell him
<bac> flacoste: ok
<bac> poolie had request it too.
<jelmer_> :q
<lifeless> ok, time to run for next medical thing. Ciao.
<poolie> bac, i'm happy to answer questions etc about the sru process
<poolie> it can tend to get stuck
<bac> poolie: thanks!
<sinzui> abentley, do you have time for a short review https://code.launchpad.net/~sinzui/launchpad/nomminate-driver-permissions-1/+merge/84850
<abentley> sinzui: sure.
<abentley> sinzui: "SourcePackage does implement all of the IHasDrivers interface." Does or does not?
<sinzui> abentley, reload the page
<abentley> sinzui: r=me.
<sinzui> thank you very much
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<abentley> sinzui: np
#launchpad-dev 2011-12-08
<cjwatson> [6~[6~ [5~/wg 61
<cjwatson> argh, lag
<lifeless> argh
<lifeless> set_up_tacfile_logging
<wgrant> That's not the problem here, AFAICT, but yeah.
<wgrant> I commented it out, still borked.
<lifeless> well
<wgrant> It's evil, though.
<lifeless> I'm yak shaving on the stdio thing
<wgrant> Ah
<lifeless> its that or yakshave on a manhole
<lifeless> so
<lifeless> the channel is set to pretend to be non-errors
<lifeless> which is why that function isn't the cause of the looping
<wgrant> Ah
<lifeless> channel = logging.StreamHandler(log.StdioOnnaStick())
<lifeless> thats what is connected to the python logging system
<lifeless> note further that the python logging stuff *also* needs a oops handler attached (with special gymnastics) because set_up_tacfile_logging turns errors into plain messages
<lifeless> special gymnastics because its calling 'normal' oops code in a twisted appserver.
<lifeless> climb through, if you dare
<lifeless> aaaaaaah
<lifeless> -> execute_zcml_for_scripts()
<lifeless> (Pdb)
<lifeless> and thats where my prompt disappears
<lifeless> it may just be horrendously slow under pdb.
<lifeless> ah yues
<lifeless> aieee
<lifeless> someone in twisted had a daft day
<lifeless> 623  -> def startLoggingWithObserver(observer, setStdout=1):
<lifeless> there appears to be no way to control that.
<wgrant> Heh
<lifeless> Twisted-11.1.0-py2.6-linux-i686.egg/twisted/application/app.py(228)start()
<lifeless> the use of -n doesn't stop this happening
<lifeless> so, interactive debugging -> nah, we can't do that
<lifeless> now, with that hacked in, lets see
<lifeless> oh joy
<lifeless> and then we re-setup logging doing that against as well
<wgrant> We have to be sure :)
<lifeless> via ib/lp/services/sshserver/service.py(174)startService()
<lifeless> yay.
<lifeless> now I have pdb, I am all powerful
<lifeless> 12K oopses written
<lifeless> then it stopped
<lifeless> 2 oopses this time
<lifeless> now 1
<lifeless> heisenbug
<poolie> lifeless, if we depend on python-fixtures is that likely to be released etc?
<poolie> backported even?
<lifeless> useless backtrace though
<lifeless> poolie: hi released for sure
<lifeless> poolie: I have no idea about backports to official ubuntu; it is in a ppa building for a wide set of releases
<poolie> i guess adding dependencies is a muscle that should be worked
<poolie> it hurts :)
<lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/901498/comments/5
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<lifeless> wgrant: :!ls -l /var/tmp/lperr/2011-12-08/ | wc -l
<lifeless> 5
<lifeless> wgrant: suggestions on making it break solicited
<wgrant> lifeless: That normally degrades into infinite recursion, I believe.
<lifeless> of course, it might be the setStdout thing
<lifeless> wgrant: hasn't for me
<wgrant> Even when you run without your hacks and without -n?
<lifeless> its the setStdOut parameter to startLogging
 * lifeless runs with 2>/dev/null
<lifeless> right
<lifeless> our logging is wired up to stderr
<lifeless> and we redirect stderr to be an OOPS
<lifeless> our *python* logging is wired up to stderr
<wgrant> Ah
<lifeless> we have logging wired up to stderr for scripts
<lifeless> where the stderr goes to lp-error-reports
<lifeless> for 'help me' reporting
<lifeless> wgrant: analyzed https://bugs.launchpad.net/launchpad/+bug/901498/comments/7
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<lifeless> oh wow. we export a function from a package.
<lifeless> bah
<lifeless> function from a module as the same name as the module
<lifeless> lib/canonical/launchpad/scripts/__init__.py line 31
<lifeless> ok, this is crazy. going in loops :(
<spm> while poppy=aaaaaa; do sudo crazy --user=lifeless ; sleep 5 ; done
<poolie> lifeless, i don't suppose you would be open to reconsidering https://code.launchpad.net/~mbp/launchpad/show-timeline/+merge/80166 to not consolidate it with ++profile++ for now?
<poolie> the profile code is a bit hardcoded
<poolie> i feel a bit averse to refactoring it
<poolie> at least until i know if this is actually useful
<lifeless> mmm
<lifeless> If you want to land it, and then either refactor or remove it in january sometime, thats fine
<lifeless> I don't want deliberate duplication in this area; it is as you note already clumsy, and duplication around it makes that worse.
<lifeless> so I'm *not* ok with landing it and then forgetting about it.
<poolie> ok, deal
<poolie> i promise to at minimum delete it
<lifeless> ok
<lifeless> thank you
<poolie> hopefully it will actually be useful and we can unify them
<poolie> i will add an integration smoke test
<lifeless> wgrant: feedback wanted
<lifeless> https://bugs.launchpad.net/launchpad/+bug/901498/comments/8
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<lifeless> I thnk I have a full handle on it now
<wgrant> lifeless: That sounds reasonable, I think.
<wgrant> But I don't know twistd.
<lifeless> StevenK will rejoice
<wgrant> Oh?
<lifeless> he has a branch to delete setup_tacfile_logging
<lifeless> I suggested that he needed to figure out this set of intricate pain to move forward and it stalled
<lifeless> having figured it out, it should be fairly straightforward to make a patch
<wgrant> Ah
<StevenK> lifeless: What's your plan, then?
<lifeless> StevenK: https://bugs.launchpad.net/launchpad/+bug/901498/comments/8
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<StevenK> Hmm, I'm can't recall that branch
 * StevenK looks
<StevenK> Found it.
<wgrant> lifeless: Does one just use https://lp-oops.canonical.com/admin/oops/prefix/ to assign appinstances to prefixes?
<lifeless> yes
 * wgrant fixes them up.
<lifeless> per the docco wiki page
<lifeless> its a bit horrible
<wgrant> Horrible? This is Django!
<lifeless> a bit, not a lot
<lifeless> jus tsome of the maniuplation gets clumsy
<StevenK> lifeless: So I should resurrect my branch?
<wgrant> Oh goody.
<wgrant> We have 'production' and 'lpnet' appinstances.
<lifeless> StevenK: I think so, especially if you're up to tweaking the other bits too
<lifeless> wgrant: production was scripts etc
<lifeless> wgrant: lpnet is just appservers
<lifeless> IIRC
<wgrant> Probably.
<StevenK> lifeless: I would, but I have no idea how to.
<wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-04319168ea720529358ae77eb667fea9
<lifeless> zomg links that work :P
<wgrant> YES
<lifeless> StevenK: I can give you pointers
<lifeless> wgrant: epic fail traceback
<lifeless> wgrant: the no URL thing is interesting
<wgrant> Yes.
<lifeless> wgrant: no req variables either
<wgrant> It probably happened aoutside the request.
<wgrant> It's in the disconnection.
<lifeless> wgrant: can you file a bug for this? it managed to keep the timeline though.
 * StevenK points lifeless to this whole annual leave thing.
<lifeless> StevenK: are you there now ?
<lifeless> StevenK: you could link your branch in as a starting point (just in a comment I mean)
<wgrant> Hmm.
<wgrant> Our DB needs pruning.
<lifeless> wgrant: oops DB?
<StevenK> lifeless: Comment 9
<wgrant> So many obsolete unreferenced prefixes.
<wgrant> Yeah.
<lifeless> wgrant: oh, prefix pruning.
<lifeless> wgrant: wait till we have the new configs streamline
<wgrant> 139 unreferenced prefixes.
<wgrant> SSO and crap.
<wgrant> Yeah.
<lifeless> poolie: the linaro thing is a sadness
<StevenK> Which thing?
<lifeless> zygmund? I forget the spelling - moved a linaro project to github, unilaterally.
<lifeless> with a bit of a rant about usability
<lifeless> some true aspects
<poolie> yeah
<poolie> some seems fairly easily fixable :/
<wgrant> Yes.
<wgrant> But the problem is they've been fairly easily fixable for 4 years.
<wgrant> And they're still not fixed.
<lifeless> a few good men
<StevenK> I'd suggest they get escalated, but what good will that do.
<poolie> wgrant,  they are actually a bit more easily fixable now
<wgrant> (I don't actually know what they are)
<lifeless> YHBTHANDHTH
<nigelb> ...
<poolie> you have been trolled etc
<lifeless> Wgrant sometimes needs the reciprocal branded on his forehead :)
<wgrant> I was being quite serious :)
<lifeless> except you didn't know the specific issues
<poolie> featurefixture assumes every defined feature is true :(
<poolie> can be fixed
<poolie> s//flag
<lifeless> so you were at minimum applying /some/ hyperbole
<wgrant> Some, yes.
<wgrant> But it was a reasonable assumption.
<mwhudson> lifeless: i was pretty unhappy he did that
<lifeless> mwhudson: I am too
<wgrant> So am I. Doesn't meant I don't see his points as valid :)
<lifeless> mwhudson: he could at least have offered some patches
<mwhudson> my upsetness is probably from a different direction though
<lifeless> mwhudson: sharable?
<mwhudson> lifeless: bad timing, and we're supposed to be a team dammit
<poolie> exactly
<lifeless> mwhudson: What made the timing bad? Team thing yes, I agree - thats kindof where my point was...
<lifeless> mwhudson: though I think that Linaro being a separate org makes that a little less clear.
<mwhudson> lifeless: the project is a bunch of scripts we use for deployment
<mwhudson> lifeless: he moved it <12 hours before we used them for the first time for a production deployment
<lifeless> oh wow
<lifeless> mwhudson: who reports to whom in this structure?
<mwhudson> zyga and i both report to paul larson
<poolie> short review anyone? https://code.launchpad.net/~mbp/launchpad/featurefixture-from-request/+merge/84887
<wgrant> lifeless: Did you have a fix for https://lp-oops.canonical.com/?oopsid=OOPS-5c5df29093442e212197300c3b8d2f8a?
<lifeless> bah, slid off plate
<lifeless> let me shelve my DB changes and I'll get on it
<lifeless> wgrant: you're landing the soyuz start tweaks?
<lifeless> wgrant: was there a bug for this ?
<lifeless> ah yes, 898638 is it
<wgrant> lifeless: They landed a few hours ago.
<wgrant> lifeless: Also, your (qa)staging de-oops-prefix-isation made various staging OOPSes show up on prod.
<lifeless> wgrant: win
<wgrant> Because there are prefixes configured in schema-lazr.conf, for some probably not very good reason.
<wgrant> eg. CB and CID
<wgrant> And CIW
<lifeless> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHHAAHA
<wgrant> And APPORTBLOB
<wgrant> Anyway.
<lifeless> caretokill ?
<wgrant> Not really.
<wgrant> Might as well just kill off all prefixes on Monday.
<wgrant> :)
<wgrant> Actually.
<lifeless> well, all script ones
<wgrant> I guess we can sensibly just drop those now, can't we.
<wgrant> Since we're using the new datedir-repo on prod everywhere.
<lifeless> set to none in the schema
<wgrant> Yeah, just was thinking it wasn't safe everywhere yet.
<lifeless> wgrant: we haven't updated the prod config yet
<wgrant> But it is.
<wgrant> They don't need to be unique any more, and reporter defaults to something sensible for scripts now.
<lifeless> yes, that part of it definitely
<wgrant> I'll remove all the prefix defaults now.
<lifeless> http://pastebin.com/3Q7v6YVD
<wgrant> aaaa
<wgrant> but ok
<lifeless> how do you propose to address it ?
<wgrant> I don't have any better ideas.
<lifeless> whee
<lifeless>   File "/usr/lib/python2.6/urllib.py", line 1222, in quote
<lifeless>     res = map(safe_map.__getitem__, s)
<lifeless> UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
<lifeless> close enough to demonstrating the problem IMO
<lifeless> and with the fix
<lifeless> wgrant: lp:~lifeless/launchpad/bug-898638
<poolie> lifeless, what is an 'extra oops message'?
<poolie> nm
<lifeless> wgrant: review -  https://code.launchpad.net/~lifeless/launchpad/bug-898638/+merge/84891
<lifeless> poolie: have a look in errorlog.py, should be fairly obvious
<poolie> like         with globalErrorUtility.oopsMessage(oops_message): ?
<lifeless> something like that yes
<lifeless> I don't know if there is a good API for 'and I am not raising right now'
<lifeless> I hope there is
<lifeless> otherwise I'm sending you off yak shaving again
<lifeless> (which wasn't my intent)
<wgrant> lifeless: APproved
<lifeless> we need a longpoll hook for changes to the MP other than diff
<lifeless> has stubs stuff landed again ?
 * lifeless checks
<wgrant> It has, yes.
<lifeless> wgrant: https://code.launchpad.net/~lifeless/python-oops-tools/prune/+merge/84892
<wgrant> I need to remember to not hit refresh.
<lifeless> wgrant: diff is there :P
<poolie> lifeless, according to some documentation, oops messages are not supported in the webapp because they're not thread safe
<lifeless> poolie: hmm, so I believe we have per-thread utilities
<lifeless> poolie: so if I wrote that, I was misguided.
<wgrant> lifeless: k
<wgrant> r=me
<poolie> where are oopses from make run now put?
<wgrant> /dev/null unless you have python-oops-tools set up, or kill rabbit.
<poolie> i guess i'm really asking, what's the easiest way to look at them
<lifeless> poolie: run up oops-tools locally.
<wgrant> It's actually pretty easy nowadays.
<lifeless> poolie: give me 5 minutes to land a switch to the LP sourcedep branch and it will be even easier.
<wgrant> Although it would be nice if you didn't have to create a special postgres cluster and blah.
<lifeless> wgrant: patches gratefully.
<poolie> srsly
<poolie> ok thanks
<wgrant> poolie: If you kill rabbit and cause an oops, it will appear in /var/tmp/lperr as before.
<lifeless> wgrant: is there an exchange by default ?
<lifeless> wgrant: w/no exchange they should be written to disk regardless
<wgrant> lifeless: Hmm, that's true.
<wgrant> Perhaps the dev rabbit is more persistent than I thought it was.
<lifeless> poolie: I'd expect by default they arrive in /var/tmp/lperr/
<lifeless> poolie: if you have oopstools you can glue it in very easily. I reference an email describing this from https://dev.launchpad.net/QA/OopsToolsSetup
<lifeless> the precise link is
<lifeless> https://lists.launchpad.net/launchpad-dev/msg08183.html
<lifeless> (but see https://dev.launchpad.net/QA/OopsToolsSetup#Deploying_locally_.28e.g._devpad.29 anyhow)
<lifeless> sadface
<lifeless>  bzr resolve --all download-cache/
<lifeless> bzr: ERROR: If --all is specified, no FILE may be provided
<wgrant> Yeah, that sucks :/
<lifeless>  bzr resolve --all -d download-cache/
<lifeless> bzr: ERROR: no such option: -d
<lifeless>  cd download-cache/ && bzr resolve --all && cd -
<lifeless> /home/robertc/oops-tools
<poolie> :/
<lifeless> man, I wanted to get so much more done today
<lifeless> E-TIME
<lifeless> of course, having rogue services check up gb's of queue memory is a good excuse.
<wgrant> Indeed.
<wgrant> 14M oopses from one service is quite the exceptional circumstance.
<lifeless> wgrant: you're missing the 700K it processed.
<lifeless> wgrant: that graph was depth, not volume
<wgrant> lifeless: True.
<wgrant> lifeless: Although some of that 700000 was from after the peak.
<wgrant> But before I hacked it to skip them.
<lifeless> wgrant: not really
<lifeless> wgrant: it had 9 hours of constant chewing on them
<wgrant> True.
<lifeless> wgrant: and ~20 minutes of quad consumer
<wgrant> Yeah
<lifeless> so thats 9*60=540 vs 80
<poolie> stub,  this is for stub, this is for https://code.launchpad.net/~mbp/launchpad/666765-features-no-reasons/+merge/84050
<poolie> any better ideas welcome
<lifeless> poolie: does the request flags controller know the scope values ?
<lifeless> poolie: if so, adding an oops hook, or extending attach_request, would be clean.
<poolie> yep
<poolie> i don't understand how the existing use of it is really safe
<poolie> i guess it's mostly stateless
<lifeless> its probably not
<poolie> in the way it's used in the webapp
<poolie> ok that should work
<lifeless> this is old and crufty code mostly facelifted
<stub> poolie: I think at the moment all data is attached to the request, which is effectively thread local and gets destroyed at the end of the request. The utility certainly should be stateless, or failing that use thread local storage.
<lifeless> certainly the amqp publisher has TLS built in
<lifeless> and the datedir repo publish function doesn't alter global state (though the old one did). All hail clean code.
<poolie> right except it has this concept of 'messasges' which mislead me
<stub> I attached something to the OOPS reports via request the other day but can't remember what it was now... :-/
<poolie> pulling it from the request at the time it's fired looks like it will work
<lifeless> stub: the previous oops
<poolie> and is even slightly clean
 * stub wanders off on his walking frame to grab a cup of tea
<stub> ahh... that's right
<lifeless> poolie:  trunk of python-oops-tools is now using the lp sourcedeps cache.
<lifeless> I'm going to mail the list a tl;dr summary in a second
<poolie> all my lp branches failed with that soyuz apparently spurious failure
<wgrant> Yeah, it's become extremely common lately.
<wgrant> Possibly 100% common.
<wgrant> I have two branches in ec2 now that I'm going to try to catch.
<jtv> wgrant: I've been trying to Q/A a change to PackageCloner.packageSetDiffâ¦ any idea how I exercise it?  I thought I could initialize a distroseries but haven't had much luck with that.
<jtv> (And what is a SetDiff?)
<wgrant> It's a diff of a package set. Note that a package set is not to be confused with a packageset.
<wgrant> Initialising a new distroseries in the same distribution should use the cloner.
<wgrant> But the easiest way is to use populate-archive to create a copy archive.
<wgrant> That uses the cloner.
<jtv> And specifically packageSetDiff?
<wgrant> Hmm.
<wgrant> I'm not sure that's ever been used.
<wgrant> The cloner was initially going to be able to do progressive copies, IIRC.
<wgrant> But that never got finished AFAIK.
<poolie> ok, night all
<wgrant> At least never used anywhere.
<jtv> night poolie
<jtv> wgrant: then I guess qa-untestable.
<wgrant> jtv: Probably.
<jtv> wgrant: Thanks.  By the way, it runs on cocoplum, right?
<jtv> The package cloner in general?
<wgrant> Yeah.
<wgrant> Mostly.
<jtv> Mostly..?
<jtv> âThey mostly come at night.  Mostly.â
 * jtv flashes wgrant a terrified look
<wgrant> It would occasionally be run from loganberry, probably, and will soon be on bilimbi.
<jtv> I'm filing NDT & cocoplum rollouts then.
<wgrant> Objection.
<jtv> ?
<wgrant> We can't roll out to cocoplum until next week.,
<wgrant> poppy is a bit fucked
<wgrant> Took down all of LP this morning.
<jtv> But that's germanium innit?
<wgrant> By overloading rabbit with 14 million OOPSes in 10 hours.
<jtv> whoopie
<wgrant> poppy is both cocoplum and germanium.
<jtv> Is that the new logging of GPG errors?
<wgrant> A bug in the new OOPS infrastructure.
<wgrant> Which causes the first error to create an infinite loop.
<wgrant> Of OOPSes.
<jtv> I shouldn't have joked about that the other day.
<wgrant> https://lpstats.canonical.com/graphs/ProductionRabbitOopsQueue/20111208/20111209/
<lifeless> wgrant: that should be on LPS in the cherrypick section I suspect
<wgrant> lifeless: It's in the cowboy section.
<lifeless> cool cool
<wgrant> I'll add germanium as well.
<lifeless> also  https://lpstats.canonical.com/graphs/AppServerRequestLpnet/20111208/20111209/ which we have no current clue about
<jtv> wgrant: is the upshot that rolling out to cocoplum doesn't work today?  Or that do so would break something, and if so, how?  Would it override a cowboy, for instance?
<wgrant> jtv: Rolling out to cocoplum will work for a few hours, and then cause all production services to hang.
<wgrant> Bug #901498
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<jtv> So it would break something.
<jtv> That's something I hate even more than just not being able to do it.
<lifeless> https://bugs.launchpad.net/launchpad/+bug/901498
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901498 >
<wgrant> lifeless: Well, it's nothing to worry about.
<wgrant> lifeless: Data collection on loganberry probably just hung for a while.
<wgrant> lifeless: Note that there's a gap, and then the next point is high -- it's the sum of the missing data.
<jtv> wgrant: argh.  As usual I didn't see the moin warning until I hit the button.  :(
<jtv> wgrant: I'm afraid I cross-edited LPS.
<jtv> Very sorry.
<jtv> I still want a red background with a skull-and-crossbones motif when that happens.
<wgrant> jtv: It's a far too subtle warning.
<wgrant> I think it's actually more subtle than the warning that other people will be warned.
<lifeless> restyle it
<lifeless> we have a branch with the theme
<wgrant> lifeless: wiki.c.c?
<wgrant> jtv: What'd you change? Added a deployment request?
<wgrant> Ah, yeah.
<wgrant> No conflict.
 * wgrant saves.
<lifeless> wgrant: yes, pretty sure. check with webops.
<jtv> No, edited my existing deployment request.
<jtv> Poppy oops loop.  Now there's something to say quickly.
<lifeless> or as I like to say
<lifeless> poops
<jtv> well if you had to say "poppy oops loop" a few times, chances you'd have ended up saying it anyway
<jtv> chances *are
<jtv> This keyboard lets my fingers fall too far behind my brain.
<wgrant> jtv: I've amended your suspended request further, to request germanium as well.
<wgrant> Because it's nice to keep them together.
<wgrant> They have the same downtime constraints, so there's no reason to let them diverge.
<jtv> I was wondering about that.  Is there any particular reason why we don't deploy those as a coherent set?
<wgrant> Because I only just altered LPS to recommend that that be done.
<wgrant> there's probably not much benefit in adding a special alias for them.
<wgrant> And we can't really merge the nodowntime-but-not-nodowntime targets into a single set, since they require codehosting.
<wgrant> (codehosting, mailman, librarian are nodowntime-but-not-nodowntime)
<jtv> nowdowntime-but-not-nodowntime..?
<wgrant> Able to be deployed without downtime, but not in nodowntime because their upgrades require handholding.
<jtv> Should we have a plus-zero-downtime set?
<wgrant> Heh
<lifeless> mailman needs to be divorced from LP
<lifeless> made into a separate consumable thing, not part of the same tree
<wgrant> Yes.
<lifeless> that will eliminate one of those
<lifeless> I've run that broad plan past elmo for comment, and he is (provisionally) cool with it
<adeuring> good morning
<jtv> morning adeuring
<adeuring> hi jtv
<mrevell> Hey
<jtv> hi mrevell
<micahg> given Bug #788819, do I need a second bug to be able to subscribe to all team branches?
<_mup_> Bug #788819: want to subscribe to all merge proposals project wide <code-review> <feature> <notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/788819 >
<lifeless> ocr: https://code.launchpad.net/~lifeless/python-oops-amqp/bug-901497/+merge/84915 plox
<lifeless> stub: around? should we catchup?
<lifeless> stub: I'll try to catch you tomorrow. EHALT now.
<lifeless> allenap: ditto for you (re the bug I was talking to julian about)
<bigjools> lifeless: allenap is not around reliably today
<stub> lifeless: night
<rick_h_> morning everyone
<nigelb> bigjools: Seen IND vs WI match?
<bigjools> nigelb: yes, amazing
<nigelb> :)
<nigelb> The office seems to be in party mode :P
<sinzui> jcsackett, can you check your email to verify you were notified that you were assigned a bug? I am verifying that email is working...you can ignore the bug
<jcsackett> sinzui: this was within say the last hour? (i have a misbehaving bug mail filter, so i'll need to search)
<sinzui> It was 15 minutes ago
<jcsackett> sinzui: i see no email.
<sinzui> okay
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugtasks: 3*10^2
<jml> hey, is there something wrong with the builders. the queue seems pretty big.
<jml> or is this just usual flux
<bigjools> jml: probably a result of the librarian outage the other day
<flacoste> bigjools: that and we were missing some builders
<flacoste> or are
<flacoste> back saturday i think
<bigjools> flacoste: nothing to do with that unfortunately
<flacoste> oops, don't list active feature flags right?
 * deryck goes afk for early lunch/errands, back in hour
<bigjools> jml: remember when we wrote some poppy tests and you duplicated them across ftp and sftp by using "multiply_tests" in the loader?
<jml> bigjools: yes.
<bigjools> jml: do you know how to run only one scenario?
<jml> bigjools: yeah, just pick the right regex
<bigjools> the test name that it prints when running is not recognised by -t
<jml> test.py test_poppy <regex>
<bigjools> well finding the regex is proving hard :)
<bigjools> for example:
<bigjools>  lp.poppy.tests.test_poppy.TestPoppy.test_bad_gpg_on_changesfile(sftp)
<jml> bigjools: don't use -t, use the two regex way of selecting tests
<bigjools> ahl ISWYM
<bigjools> jml: didn't work :(
<bigjools> unless ( and ) need escaping
<jml> probably they do
<jml> I'm guessing you just want ftp
<bigjools> aha there we go
<bigjools> how'd you guess :)
<bigjools> that did it, thanks jml
<jml> you could probably also change the name of the scenario
<adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/history-model/+merge/84973 ?
<jcsackett> adeuring: sure.
<adeuring> jcsackett: thanks!
<benji> I'm confused.  I didn't realize we still used the release-cirical-only mode of PQM any more, yet my branch just got rejected because of it.
<flacoste> benji: there were two buildbot failures earlier on
<jcsackett> adeuring: r=me, sorry for the delay.
<flacoste> unless a testfix was landed or a rebuild requested
<adeuring> jcsackett: thanks :)
<flacoste> we are in testfix mode
<flacoste> benji: so we are not using release-critical anymore
<flacoste> but testfix yes
<benji> flacoste: let me double-check, but I'm pretty sure the rejection email said release-critical and not testfix
<flacoste> benji: the message might be wrong
<flacoste> i think we are still in testfix
<flacoste> because nothing was done with the db_lp failures
<benji> flacoste: heh, my tendancy to read right to left combined with the fact that the regex has *both* testfix and release-critical in it bit me
<flacoste> what was the issue with "True != False: memcached is live but should not be."
<flacoste> these errors happened both on lp and db_lp?
<flacoste> was it deemed transient?
<flacoste> should we trigger a rebuild on db_lp?
<flacoste> or the same fix that got applied to lp should be to db_lp?
<deryck> rick_h_, hey.  can you just pastebin me the queries you want run, in order. Just the queries, no extra text.
<rick_h_> deryck: sure thing, sec
<rick_h_> deryck: http://paste.mitechie.com/show/466/
<gary_poster> flacoste, I came back in for only part of a conversation you were having with someone, and no-one replied.  I'm going to assume that we still need someone to investigate the issues that benji raised in email, and the buildbot failures.
<gary_poster> I'll arrange for it to be tackled.
<gary_poster> benji, could you try reverting the new germinate locally as Francis suggested?  I'm not sure how to do it, and if you are not either, I bet there are many people who could help you.
<deryck> rick_h_, I don't follow the "repeat" comment below. Do I need to change an id and run them again?
<rick_h_> deryck: yes please, I want to then get the same info for the parent messages of those two
<gary_poster> I guess that the memcache error on buildbot is about some memcache that started and shouldn't have.
<deryck> rick_h_, what is the parent message?
<rick_h_> parent field in the results
<rick_h_> message.parent
<gary_poster> I'll try to investigate that
<rick_h_> should be either null, or ids of messages as well
<rick_h_> deryck: ^^
<benji> gary_poster: I haven't upgraded it manually so I doubt I have the newest version, let me check
<deryck> rick_h_, I don't get anything for the first results.
<deryck> 0 rows
<gary_poster> benji, it  would be upgraded automatically when you upgrade stuff because we have Launchpad's PPA as a source
<rick_h_> deryck: http://paste.mitechie.com/show/468/ ?
<gary_poster> I guess you mean you didn't update launchpad dependencies, you just installed the missing dependency?
<gary_poster> If that's the case you should definitely update all your dependencies before you try again
<benji> gary_poster: by "when you upgrade stuff" do you mean running a blanket "apt-get upgrade"?  I haven't done that lately.
<deryck> rick_h_, https://pastebin.canonical.com/56886/
<rick_h_> deryck: ok, thanks
<deryck> adeuring, you linked a branch to bug 898200, which is the dupe. bug 295214 is the master bug.
<_mup_> Bug #898200: Can't sort bug list by customized fields <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/898200 >
<_mup_> Bug #295214: ordering options should match data that is displayed in bug listings <bug-columns> <confusing-ui> <lp-bugs> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/295214 >
<deryck> adeuring, well, sorry, maybe you linked both?  skimming through mail now. ;)
<adeuring> deryck: right, I linked both
<deryck> adeuring, ok, cool.  Sorry for the noise.
<adeuring> np
<rick_h_> deryck: one more please: http://paste.mitechie.com/show/469/
<benji> gary_poster (and flacoste): neither updating germinate or using an older version makes my errors (http://paste.ubuntu.com/763881/) go away
<cjwatson> gary_poster: I'd be surprised if the new germinate could have broken anything, since prior to https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 (which hasn't landed yet), it wasn't actually tested
<gary_poster> holy smoke, what happened yesterday on buildbot?  The currently running build has over 88 revisions, which start from over a week ago
<cjwatson> it certainly has nothing to do with builds
<cjwatson> as in buildmaster
<gary_poster> cjwatson, germinate not being a cause makes sense in general.  There does seem to be a difference between ec2 and buildbot results though, and deb dependencies would explain it.  That said, something appears to be seriously screwy here.
<gary_poster> in buildbot
<gary_poster> and our devel
<cjwatson> sure - just trying to help cut out probable red herrings
<cjwatson> code not run in any tests has a low probability of breaking tests :-)
<gary_poster> cjwatson, cool, thx.  when you said builds are not at fault, that's in response to looking at benji's pastebin (email)?  http://paste.ubuntu.com/763881/
<gary_poster> it looks build-y but I don't know that system.
<deryck> rick_h_, https://pastebin.canonical.com/56889/
<deryck> mrevell, I've seen so much mail about long bug titles and one line vs. two, I can't even follow it any more.
<deryck> mrevell, I feel like we're trying to solve too many problems.  What are we trying to solve?  Are trying to get everything on one line, or trying to make better use of the space?
<mrevell> Hey deryck. My priority is this: we should offer a one-line view that gives the same info you can get from the currently live non-beta bug listings. If there's a way that we can also cater to wider screen users by putting additional data to the right-hand of their wide page, rather than on a second line, then that'd be a nice bonus. I'm sorry this has become a confused issue over the past few days.
<mrevell> I believe we've solved that first part.
<deryck> mrevell, no worries, I just want to be clear. it feels a bit like we're talking about ideas, just to be talking now. And I was losing *why* we're discussing this. :)
<deryck> mrevell, my impression from the check point call was that we had done as well as good on this, and we'd come back to this if we could, but were not really trying to.
<deryck> mrevell, so I could have completely misunderstood, sorry.
<mrevell> deryck, Sorry, I should have given a clearer direction to the mailing list threads. The discussion I was hoping for was about whether it was possible to use people's widescreens more effectively, while not forcing horizontal scrolling or too much wrapping on narrower screen users. I agree, the discussion seems to have strayed. Got time for a quick call?
<deryck> mrevell, yeah, that might be useful.  I'm sorry. I think the discussion is happening across two different threads, too.
<deryck> mrevell, skype?
<mrevell> sure
<deryck> mrevell, ready when you are.
<lifeless> bigjools: you can use load-list to run one scenario precisely
<bigjools> lifeless: never mind that, help with me logging!
<bigjools> about to run out of hair
<lifeless> sure, give me 5 to do some essential I-just-woke-up-stuff
<lifeless> and you'll have my full attention, FWTW
<bigjools> TMI
<lifeless> mrevell: I *love* your attitude
<mrevell> You do? :)
<lifeless> mrevell: totally.
<lifeless> mrevell: re the thing poolie forwarded.
<lifeless> mrevell: your response has made my day, and it has only just started
<cjwatson> gary_poster: that wasn't what I meant actually; sorry to confuse.  What I said was that germinate is not involved in anything to do with the buildmaster
<cjwatson> or what I meant to say
<cjwatson> gary_poster: germinate is loosely-coupled to the publisher, rather than to builders
<mrevell> lifeless, Ah, cool :)
<lifeless> mrevell: FYI: I rarely do sarcasm online; it doesn't transcribe well enough to avoid confusion.
<lifeless> mrevell: so you can take emphatic positive statements as being what you see
<mrevell> Great :)
<bigjools> lifeless: I need to eat, I'll be back online in ~1hr
<lifeless> bigjools: ok. I'll look at your notes on the bug
<lifeless> bigjools: and repage it all in in prep.
<deryck> rick_h_, I took a look at your MP again.  Generally it looks great.  Can we chat via mumble or Skype about something with it?
<bigjools> lifeless: I solved the problem - sorta.  :)  You'll see ...
<rick_h_> deryck: sure thing
<lifeless> bigjools: I fear the pastch
<deryck> rick_h_, mumble or Skype?
<cjwatson> gary_poster: ah, Benji suggests python-lpbuildd in https://lists.launchpad.net/launchpad-dev/msg08641.html, which makes a lot more sense as that package is actually related
<rick_h_> deryck: mumble
<deryck> ack
<deryck> rick_h_, see if Skype is better?
<rick_h_> deryck: ok
<flacoste> gary_poster: i asked myself the same question about the 88 revisions build
<mrevell> Night all
<flacoste> and didn't find a satisfactory answer
<flacoste> there are like several testfix in there
<lifeless> flacoste: https://bugs.launchpad.net/python-oops-amqp/+bug/901449 is looking to me like its the longpoll code failing
<_mup_> Bug #901449: Rabbit failure when sending an OOPS seems to hang the producer <rabbit> <python-oops-amqp:Triaged> < https://launchpad.net/bugs/901449 >
<flacoste> benji: i think your failure is bug #779367
<_mup_> Bug #779367: spurious failure in test_builder.TestSlave <critical-analysis> <spurious-test-failure> <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/779367 >
<flacoste> lifeless: how so?
 * benji looks.
<lifeless> flacoste: unreliablesession is a longpoll thing
<lifeless> flacoste: the idea of 'big oopses' is a distraction. The issue was volume not size.
<flacoste> lifeless: i got that, so poppy was the source of the volume, which killed rabbit
<flacoste> and the app server dying is because of a bug in unreliable sessio?
<lifeless> flacoste: I *think* that unreliablesession is being hooked in automatically in the appservers; and it has (at least one) bug in handling rabbit issues (see comment 2)
<benji> flacoste: it might be, comment #3 is exactly the same as mine
<lifeless> flacoste: I think it may be. Doesn't mean we should stop looking
<lifeless> flacoste: there is also bug https://bugs.launchpad.net/python-oops-amqp/+bug/901497 which could indeed affect LP appservers during rabbit issues
<_mup_> Bug #901497: close_ignoring_EPIPE can trigger IOError <python-oops-amqp:Triaged> < https://launchpad.net/bugs/901497 >
<lifeless> I've just pushed a release for that
<bac> hi flacoste, trunk for lazr.uri is an old bzr format and it breaks dailydeb.  can you upgrade it?  for some reason that branch, unlike most other LAZR projects, is owned by PQM not ~lazr-developers
<bac> flacoste: btw, lazr.uri and lazr.restfulclient need to be backported for the natty SRU of launchpadlib
<rick_h_> deryck: ping, I've got the start working, but not sure if the look is going to pan out. http://uploads.mitechie.com/lp/limited_textinput.png
<rick_h_> deryck: before I go with it more, what do you think, do we want to keep going with it?
<flacoste> bac: if it's owned by PQM, it will need to be done by a losa
<deryck> rick_h_, well, if we can drop the scrolling and overflow, have the outer-styled element expand as the stuff overflows, and drop the border around the input, then yeah, that could work. ;)
<deryck> rick_h_, but if that leads to cascading issues, then I think it's not worth pursuing.
<bac> flacoste: any reason to not change the ownership at the same time?
<flacoste> bac: probably not
<bac> will do
<rick_h_> deryck: ok, yea didn't want to get too crazy changing all the css styles/etc. More meant the space on the side that appears and the fact that it'll cause more text to hit the default max_height setting of the resizing widget
<rick_h_> which brings up scroll bars
<rick_h_> deryck: I can remove the max height setting when used from the inline edit, but not sure if that would bring up other issues
<deryck> rick_h_, I leave that to your judgement. Sorry, just don't know the ramifications of the max height restrictions without working on it more myself.
<rick_h_> deryck: ok, sounds good.
<lifeless> bac: most lazr trunks *should* be pqm or tarmac managed (same user) - we just haven't got a round tuit
<bac> lifeless: oh, i thought this one was the outlier in the wrong direction
<bigjools> o/ lifeless
<lifeless> bigjools: oh hai
<lifeless> bigjools: do you want voice ?
<bigjools> lifeless: if I had remembered to bring my headset in....
<bigjools> lifeless: the more I see of Twisted logging, the more I shake my head in disbelief
<bigjools> lifeless: I got as far as noticing that the twisted stuff was monkey patching sys.stdout and then I quit in disgust
<lifeless> bigjools: right
<lifeless> that happens from self.logger.start(application) deep in twisted
<lifeless> we have to work with that
<lifeless> it framed the situation for my proposed solution
<lifeless> (sorry for the slight latency replying, helping lynne with meds for cynthia)
<bigjools> no worries
<bigjools> lifeless: so I expect this is part of the problem with sys.stdout not working in the stream handler
<bigjools> but what I can't fathom is the duplication if I use stdioonnastick
<lifeless> the looping ?
<bigjools> no
<bigjools> it prints each message about 20 times
<bigjools> *bizarre*
<lifeless> I did not see that
<bigjools> apply the diff in my paste
<bigjools> use the log.stdioonnastick option
<lifeless> ok, so RotatableLogFileObserver fits in as a replacement observer
<lifeless> we want that to be the fallback observer for the OopsObserver
<bigjools> ye
<bigjools> s
<lifeless> so, we don't want errors going to stdout/stderr because nothing is watching those streams on the daemon
<bigjools> tbh I was trying to rip out all use of the python logger and use twisted's
<lifeless> that would be ideal
<lifeless> but
<bigjools> but
<bigjools> Hooks has some debug logging
<lifeless> we use an unknown amount of LP code today
<lifeless> someone might add a logging output in there somewhere and screw us
<lifeless> so we have to handle it
<bigjools> right
<lifeless> if we get one solid recipe
<lifeless> we should be set
<bigjools> I have had an unpleasant day working all this out
<lifeless> I bet
<lifeless> So, I think we need to do:
<lifeless> logging.basicConfig(stream=sys.stdout)
<lifeless> before all the twisted application stuff kicks in - e.g. where setup_tacfile_logging happens is fine.
<lifeless> the fiddling with channels etc isn't needed
<bigjools> ok
<lifeless> we can pass level=X to that function too
<lifeless> http://docs.python.org/library/logging.html#logging.basicConfig
<lifeless> using getLogger('poppy-sftp') should be fine
<bigjools> *should* :)
<bigjools> but wasn't
<lifeless> once everything else is sorted I mean
<lifeless> we need to change the OOPSObserver setup
<lifeless> its participating in the loop
<bigjools> I am really worried this will screw over the  build manager
<lifeless> does the build manager call setup_tacfile_logging ?
<bigjools> no
<lifeless> we probably want what the builddmanager has
<lifeless> to fix the separate bug that poppy log rotation is terrible
<bigjools> it uses Rotatable...
<bigjools> right
<lifeless> we had 50G of poppy logs or something
<lifeless> it was taking a while to rsync after each rotation
<bigjools> yeah it logs excessively anyway
<lifeless> so yeah, the builddmanager could be affected
<lifeless> but, we have and end goal that makes sense for both
<lifeless> application.addComponent(
<lifeless>     RotatableFileLogObserver(options.get('logfile')), ignoreClass=1)
<lifeless> thats what builddmanager does
<lifeless> that won't give OOPS integration
<lifeless> it probably needs to be
<lifeless> application.addComponent(OOPSObserver(oops_config, RotatableFileLogObserver(options.get('logfile')), ignoreClass=1))
<lifeless> and may need a tweak to the OOPSObserver to pass down the rotation event. I don't know.
<bigjools> simples :)
<lifeless> that + a logging.basicConfig(stream=stdout, level=X)
<bigjools> RFLO installs its own signal handler
<lifeless> should give us everything we need
<bigjools> ok I am going to experiment now
<lifeless> this function: set_up_oops_reporting
<lifeless> in loggingsupport.py
<lifeless> is what creates the loop
<lifeless> (because it turns stderr output into oopses
<lifeless> and writes a msg on oops
<lifeless> and joins twisted msg() output to python logging
<bigjools> well I managed to stop the loop without changing that
<lifeless> which is joined to stderr by default
<lifeless> sure, you can break it at a number of points.
<bigjools> and I've seen looping in poppy before your changes
<lifeless> here, one sec
<lifeless> http://pastebin.com/LV3QtjT9
<lifeless> this is a sketch
<lifeless> we have techdebt all around
<lifeless> e.g. in the SSHServerService which self-configures oops reporting
<lifeless> rather than letting it be configured for it
<lifeless> you may want to add a flag to stop calling the setup rather than changing what it calls, etc etc
<bigjools> lifeless: yes that will affect a few things
<lifeless> yup
<bigjools> this, b-m and the branch server iirc
<lifeless> won't affect b-m
<lifeless> AFAICT from daemons/buildd-manager.tac
<lifeless> and manager.py
<lifeless> it only grabs the rotatablefileobserver from loggingsupport
<bigjools> sorry not b-m
<lifeless> we *should* change the buildd-manager to get oopses from it, but we should get poppy and the bzr service sorted first.
<bigjools> well this will fix the bzr server I hope
<bigjools> unless ...
<lifeless> right, once the code fallout is done :)
<lifeless> basically the SSHService can't do its own oops config, because its being used in cooperation with other services, but logging-glued-in oops configuration is global.
<lifeless> so it has to be pulled out of there.
<lifeless> it could have its own oops config object, for direct raising of soft reports.
<lifeless> but thats a totally different question.
<bigjools> right, separate bug
<bigjools> I shall fix this first
<lifeless> yeah
<lifeless> this is contained to:
<lifeless>  - stop sshservice configuring logs or oops
<lifeless>  - delete all the accumulated cruft around that
<lifeless>  - return an observer with rotation which we can use anywhere
<lifeless>  - and setup python logging to just stdout
<lifeless> -fin
<lifeless> oh, and it looks like a trivial 'delete set_up_logging_for_script' - just doing a full grep to be sure
<lifeless> aieee
<lifeless> supermirror-pull
<lifeless> that should be an easy fix - migrate across to the set_up_oops_reporting API and call t.python.log.startLoggingWithObserver(oops_observer))
<lifeless> or move it to the end of the set_up_logging_for_script call
<lifeless> either will work AFIACT
<lifeless> bigjools: you use 'longpoll' right as the tag?
<bigjools> lifeless: yes
<lifeless> FYI https://bugs.launchpad.net/launchpad/+bug/901844
<bigjools> prob need to make it official
<_mup_> Bug #901844: unreliablesession service causing oops during after-request processing <fallout> <longpoll> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901844 >
<bigjools> lifeless: so in your patch you've removed startLoggingWithObserver
<lifeless> right
<lifeless> twistd calls that itself
<lifeless> if the application thing that the buildd-manager uses works, it should be enough
<bigjools> yeah
<lifeless> I haven't traced through to see whats happening
<bigjools> I keep thinking that it won't but that's the txlongpoll stuff .... it's a TAP not a TAX
<bigjools> TAC
<bigjools> lifeless: I like your optimism of expecting "options" to be available in the tac file :)
<lifeless> bigjools: see buildd-manager.tac
<bigjools> ah different options
<james_w> would someone please review my branch? https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022
<james_w> jcsackett, are you still on call?
<jcsackett> james_w: i am.
<jcsackett> you have something for me?
<james_w> https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 if you would be so kind
<jcsackett> i would be happy to.
<abentley> jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/batch-dealising/+merge/85023 ?
<jcsackett> abentley: sure. it's next.
<abentley> jcsackett: tia
<bigjools> lifeless: what happens if set_up_oops_reporting is called twice?
<lifeless> you'll have two signal handlers installed ?
<lifeless> seems like a bad idea
<flacoste> lifeless: fwiw, googlebot doesn't execute javascript
<flacoste> http://code.google.com/web/ajaxcrawling
<flacoste> is the convention they suggest to make ajax site indexable
<bigjools> lifeless: just a theoretical question.  Anyway, your change has the same affect as my branch - nothing from the python log ends up in the twisted log
<flacoste> lifeless: and sorry for the out-of-context info :-)
<lifeless> flacoste: interesting
<flacoste> yeah, more server work
<flacoste> which is what we hoped to get rid of
<rick_h_> deryck: I've pushed changes to the inline editor, appreciate your feedback on if it gets the look you were thinking of
<lifeless> bigjools: hmm
<bigjools> lifeless: this is why I have no hair left today :)
<lifeless> bigjools: so, I suggest you push this current experiment somewhere
<lifeless> bigjools: I will dig while you sleep
<lifeless> bigjools: and hand-back your fri morning.
<lifeless> bigjools: its well past your EOD now :)
<jcsackett> james_w: is the interface addition of created_since_date to add a field on a form in the webapp? i don't see anything connecting it back, but i'm unfamiliar with the soyuz bits of the webapp and could see it just being automatically handled with that addition. just want to make sure that's the case.
<bigjools> lifeless: yes, I am 2 whiskies in to EOD
<james_w> jcsackett, I want it for the webservice, I don't think there's really anywhere it would fit in the webapp either
<james_w> jcsackett, I have an API client that needs the parameter to make it a billion times more efficient
<lifeless> flacoste: whats the bug # for the linaro-cannot-upload-releases bug? I can't seem to find it again..
<jcsackett> james_w: ah.
<james_w> lifeless, https://bugs.launchpad.net/launchpad/+bug/194558
<_mup_> Bug #194558: Project file uploads time-out but don't OOPS <escalated> <linaro> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/194558 >
<lifeless> james_w: thank you!
<flacoste> what james_w says :-)
<lifeless> bigjools: so yeah, pastebin or push to a branch, and make it my problem
<lifeless> bigjools: I'll get the basics hanging together properly.
<bigjools> lifeless: http://pastebin.ubuntu.com/764210/
<bigjools> I've actually been using it on a branch where I've added extra gpg debugging to poppy
<bigjools> good way to test the logging :)
<jcsackett> james_w: r=me.
<jcsackett> abentley: looking at yours now.
<james_w> jcsackett, merci
<james_w> now to see if I can actually land it
<lifeless> bigjools: cool, I saw the MP for that branch
<lifeless> bigjools: btw, I don't think we should log errors for these gpg failures if its a sigfail - thats a user problem (analgous to a 404). But lets worry about that *after* we sort out germanium
<bigjools> lifeless: right - this is purely for debugging since we have NFI why it fails
<bigjools> there's a "source" debug property that'll tell us where the error originated
<lifeless> bigjools: ah, I don't mean your change, I mean the existing code
<bigjools> lifeless: the logging comes from the FTP handler in Twisted :/
<lifeless> something, perhaps in twisted itself, is logging an isError
<lifeless> we'll want to add an oops filter to mask those from being oopses I think. eventually.
<bigjools> the writer handler just tells the parent class there was a failure and it does the rest
<lifeless> yup
<lifeless> flacoste: thanks for the link
<jcsackett> abentley: just to make sure i'm reading this all right, the purpose of this branch is to avoid reloading stuff and just grab the data we've already got, right?
<abentley> jcsackett: right.
<jcsackett> abentley: awesome.
<deryck> rick_h_, sorry, missed the ping somehow.  looking now.
<jcsackett> abentley: okay, given that my understanding is on the mark, this looks good to me. r=me.
<abentley> jcsackett: thanks.
<rick_h_> deryck: cool, I'm off to run around, but feel free to leave any notes and I'll check it out in the morning
<deryck> rick_h_, sounds good.  Have a nice evening.
<abentley> deryck: I'm having trouble reproducing 900398 locally.  I've set a bug to incomplete, and it still says "There are currently no open bugs."  Any tips?
<deryck> abentley, ah, expire able.  yeah, you'll need to back date a bug and back date when it was marked incomplete, by poking at db or in console.
<abentley> deryck: How old does it need to be?
<deryck> abentley, hmmm, that's a good question.  my impulse was >60 but not sure what the expireable view shows, since those should auto expire.
 * deryck looks at some things....
<abentley> deryck: that's why I find it confusing.  I thought all incomplete bugs were "expirable", and if they were >60 they'd be expired.  Well, invalid.
<wgrant> abentley: Assigned bugs or those with multiple tasks don't expire, IIRC.
<abentley> wgrant: Ah, that could be it.
<wgrant> abentley: I believe there are other exceptions as well. They used to be documented, but I'm not sure if it's up to date.
<abentley> wgrant: hmm.  I set https://bugs.launchpad.dev/ubuntu/+source/linux-source-2.6.15/+bug/10 to incomplete, and claims it will expire, but doesn't show in the list.
<_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 <lp-bugs> <Launchpad itself:Invalid> < https://launchpad.net/bugs/10 >
<deryck> abentley, also the project has to have expiry enabled for that view to work.
<deryck> abentley, and I think expiry is off by default
<abentley> deryck: Yes, I made sure that was checked.
<deryck> ok, hmmm.  can't be a dupe, can't be assigned, can't be targeted to milestone
 * deryck is thinking of every criteria
<deryck> abentley, ah.  and it is a config param for how old it needs to be.  config.malone.days_before_expiration
<deryck> abentley, and as I read the method to get the list, the bugs have to be created than that value.
<deryck> s/created/greater/
<abentley> deryck: It's particularly weird, because lp says it will expire on the bug page, but doesn't list it in the listing.
<wgrant> Oh, so +expirablebugs or whatever it is only makes sense when expiry is disabled?
<wgrant> Because otherwise everything there should already have expired...
<deryck> well, expiring has to be enabled for that page to have any bugs.  but yeah, I agree it doesn't make sense why a bug has to be ready to expire before it shows on that page.
<wgrant> "An Incomplete bug can remain in this list indefinitely, so long as the bug is regularly updated."
<abentley> I guess that would explain why it's a custom view, instead of searching on status=Incomplete.
<wgrant> That suggests it doesn't have the timeout.
<abentley> wgrant: I think that means that updates reset the timeout.
<wgrant> But then it wouldn't be on the list.
<wgrant> So it wouldn't stay on the list indefinitely.
<abentley> wgrant: Maybe the page doesn't know what it actually lists?
<deryck> the view uses findExpirableBugs which does: Bug.date_last_updated < CURRENT_TIMESTAMP AT TIME ZONE 'UTC' - interval '%s days'
<deryck> where the config value is the %s
<lifeless> have we finished the migration to the new ENUM as well ?
<wgrant> Yeah, the docs seem wrong.
<wgrant> That makes the view pretty useless.
<deryck> indeed
<abentley> deryck: do we want to fix this view or kill it?
<wgrant> Oh.
<deryck> you can only view them on that view when they're old enough to expire but before the script has actually run :)
<wgrant> But findExpirableBugTasks takes min_days_old as an argument.
<flacoste> wtf, i get this email back from PQM: http://pastebin.ubuntu.com/764259/
<flacoste> what is that supposed to mean
<wgrant> flacoste: Check the attachment.
<wgrant> flacoste: It will say the regex doesn't match.
<flacoste> ah!
<flacoste> attachments!
<flacoste> that must be new
<flacoste> wgrant: thanks!
<wgrant> deryck: Perhaps we should change BugTaskExpirableListingView to show everything older than 0 days?
<deryck> wgrant, yeah, I think so.
<deryck> abentley, ^^.  Just fix it to show anything that could expire when the time comes.
<wgrant> I guess for years it made sense to show only the stuff that was really expirable -- because they never actually expired.
<abentley> deryck: Okay.
<deryck> That's my understanding of what this view is meant to show.
<deryck> wgrant, heh. yeah.
<abentley> wgrant: older than 0 days == everything?
<flacoste> why are we still still in testfix mode?
<wgrant> abentley: I think so.
<flacoste> since both lp and db_lp are building happily?
<abentley> flacoste: because the last build attempt failed, and no one has landed a testfix.
<wgrant> flacoste: I'm not sure. It may be because the last devel build blew up really impressively, and buildbot apparently lost its memory.
<wgrant> abentley: That doesn't normally matter.
<flacoste> right
<wgrant> Normally as long as both are either successful or building, it's happy.
<flacoste> yep
<wgrant> But buildbot-poller probably doesn't handle results that end in an exception, I guess.
<flacoste> but the memory aspect might confuse buildbot-poller :-/
<flacoste> or something like that
<wgrant> abentley, deryck: Hah
<abentley> wgrant: I could have sworn I saw that behaviour yesterday when I forced a build.
<wgrant> That's a recent change.
<wgrant> 11057.8.2
<wgrant>   modify can_expire to use the days_before_expiration config option
<wgrant>      expirable_bugtasks = list(bugtaskset.findExpirableBugTasks(
<wgrant> -        0, getUtility(ILaunchpadCelebrities).janitor))
<wgrant> +        config.malone.days_before_expiration, getUtility(ILaunchpadCelebrities).janitor))
<deryck> ah interesting.
<abentley> wgrant: thanks.
<deryck> That's a bdmurray change.  I'm sure he and I talked about it, but don't recall now why we did that.
<wgrant>   [r=leonardr][ui=none][bug=595124] unexport IBug.can_expire which is
<wgrant>         confusing instead create and export IBug.isExpirable which can
<wgrant>         accept a custom number of days.
<abentley> It was proposed here: https://code.launchpad.net/~brian-murray/launchpad/595124/+merge/28543
<wgrant> Is the landing message.
<wgrant> How odd.
<wgrant> It seems unrelated.
<lifeless> ui=none is rather stale
<deryck> heh, I even discussed this and approved then.
<deryck> well, I unapprove my approval. ;)
<wgrant> deryck: It made sense back then :)
<wgrant> It was still switched off.
<abentley> deryck: lol
<wgrant> So it was useful for expirable-bugs to show what *would* happen.
<deryck> yeah, and as it is now, we'll never actually see them.
<deryck> unless the expiry script barfs. ;)
<wgrant> Yep.
<wgrant> revert revert revert
<wgrant> baaaah
<wgrant> **********************************************************************
<wgrant> Can't use pdb.set_trace when running a layer as a subprocess!
<wgrant> **********************************************************************
<wgrant> How nice.
<wgrant> Ah, OK, lp-buildd problem is clear now.
 * wgrant fixes.
 * wgrant was wrong to blame poolie :(
<abentley> deryck, wgrant: thanks.  Can now reproduce the issue.
<nigelb> wgrant: winpdb might help.
<nigelb> statik showed me that trick. It helped when I was debugging LP :)
<poolie> glad it wasn't me
<poolie> wgrant, what was it?
<wgrant> poolie: We added a new config option last week.
<wgrant> poolie: It's mandatory.
<wgrant> poolie: The config file is installed by python-lpbuildd, but the migrator is in launchpad-buildd.
<wgrant> So upgrading python-lpbuildd doesn't upgrade the config file.
<poolie> ah
<poolie> kind of my fault for not separating them better perhaps
<wgrant> Meh.
<poolie> i don't know if making it mandatory but added by upgrading makes sense, but i don't know the specific
<wgrant> I guess I'll move it, alter the migrator to also migrate for 111 if the option isn't in the file, and release a new one.
<wgrant> poolie: It's how all the path configuration is done, unfortunately.
<wgrant> It's all pretty ancient and bad.
<lifeless> poolie: http://lists.linaro.org/pipermail/linaro-dev/2011-December/009059.html suggests a place where git hosting would be valuable to LP users
<poolie>  yep
<lifeless> abentley: whats the expiry policy on your ajax batch cache ?
<abentley> lifeless: None.
<poolie> i think the clearest case for it is as a replacement for git.kernel.c.c. and git.l.c
<lifeless> abentley: so users have to refresh the page to see new results?
<abentley> lifeless: right.
<lifeless> abentley: you might like to have a bug noting this - one of the things we're trying to do long term is make LP more responsive, and having to refresh will conflict with that
<abentley> lifeless: the irony is, of course, that not loading is a great way of making Launchpad more responsive.
<lifeless> abentley: well, its a way. I don't think it gets used much at all - e.g. see poolies data that users use 'next' very rarely.
<abentley> lifeless: For users that don't use the cache, its expiry policy doesn't matter :-)
<lifeless> agreed
<lifeless> just noting that this is a side effect of the cache - part of the expected overhead of having a cache
<lifeless> It is a significant difference to the non-ajax behaviour where next/prev give live data.
<abentley> lifeless: So if they're not using the cache, then it neither makes launchpad more responsive nor forces them to reload.
<lifeless> It would be nice to have the user subscribe to the bugs visible in the batch, so they can be removed from the batch live
<lifeless> abentley: thats true. But we know some users do use the cache. And we haven't drilled into where that usage is distributed
<lifeless> I forget what the percentage was
<lifeless> call it N. It may be that N% of users use next/prev all the time.
<abentley> lifeless: Yes, I'd love to see that data by user rather than by hit.
<abentley> Anyhow, I will be happy to contribute to the effort to make pages update live.
<wgrant> poolie: Ah, actually, the config file I had was crufty. python-lpbuildd doesn't use the system config file at all. But there's a test-specific config file in the tree which wasn't updated.
<lifeless> abentley: I think for now a bug noting that this is the situation is appropriate (because its not obvious to users that this will be happening)
<lifeless> abentley: I can file it if you like
<abentley> lifeless: There's no spinner when retrieving from cache, so it should be obvious, but feel free.
<lifeless> abentley: folk in europe working with small batches probably won't register the spinner anyhow :)
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<lifeless> abentley: bug 901892
<_mup_> Bug #901892: bug search cache makes next/prev return old data <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901892 >
<lifeless> deryck: ^ FYI too
<lifeless> abentley: its a little entertaining to me that 7 years on we're still talking about cache implementations
<lifeless> :)
<deryck> ack, thanks
<deryck> later on, everyone.
<flacoste> need to run for the rest of the evening
<flacoste> cu later
<lifeless> ciao
<mtaylor> lifeless: so - I set up launchpad translations a while back for nova, and they seem to be working, even though nova doesn't have a .pot file in the repo (since it generates one through distutils-extra)
<mtaylor> lifeless:  I was starting to try to set up the same thing for glance, but I'm not sure I did it right - who should I bug with questions?
<lifeless> mtaylor: if there is a CHR listed in #launchpad, start there
<lifeless> mtaylor: failing that, just ask there - there are folk around
<mtaylor> ok. cool. thanks
<lifeless> mtaylor: failing that, open a ticket at l.n/launchpad
#launchpad-dev 2011-12-09
<lifeless> wgrant: see backchannel for poppy discussion
<wgrant> I read most of it, but apparently not enough.
<wgrant> Does anyone know what's happening with the pofilestatsjob DB permission fixes?
<wgrant> I saw a branch for it on like Monday.
<wgrant> But it hasn't landed.
<wgrant> I'm tempted to just cowboy the two permissions...
<james_w> hmm, ec2 land didn't appear to do anything, and I got no mail
<james_w> is there any way to find out what happened other than trying again?
<wgrant> Sadly not.
 * james_w fires it off again
<james_w> should I do it with --attached or whatever it is?
<wgrant> Possibly. The instance is completely gone?
<wgrant> We haven't had disappearing instances for nearly a year....
<wgrant> Apart from AWS glitches.
<wgrant> You sure it didn't just send to an unobvious email address?
<wgrant> It would have failed, because the build to fix them is still pending.
<lifeless> wgrant: btw remember the oops ajax thing the other day
<wgrant> lifeless: Yes?
<lifeless> wgrant: we emit X-Oops-ID now
<lifeless> not lazr
<wgrant> Ah
<wgrant> That would do it.
 * wgrant fixes.
<wgrant> (although that might break launchpadlib too...)
<lifeless> see oops_wsgi
<wgrant> lifeless: See SystemErrorView
<lifeless> ahem. I should say 'the wsgi stack does x-oops-id'
<lifeless> I may not have changed it throughout LP.
<wgrant> Hm, although I guess we don't use that for API requests.
<lifeless> but we should.
<james_w> I don't have any mail from the test run
<lifeless> james_w: if it totally blows up that happens
<lifeless> james_w: you can exceed the mx size limits
<james_w> maybe I've somehow got it configured to an email I no longer have access to
<james_w> e.g. @linaro.org
<james_w> anyway, I'll try --attached tomorrow and see what happens
<james_w> night all
<james_w> and thanks wgrant, lifeless
<wgrant> james_w: It should have gone to jameswestby.net
<lifeless> can has reviewer?
<lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/timeout/+merge/85056
<wgrant> Ugggh
<wgrant> Let's not.
<wgrant> Can't we solve our current crisis before creating another?
<lifeless> data is power
<wgrant> Data is hopelessness.
<lifeless> the swamp of despair is hopelessness
<lifeless> data isn't!
<lifeless> wgrant: so does that mean am I getting a review?
<wgrant> Sure.
<wgrant> lifeless: r=me
<lifeless> thanks
<wgrant> lifeless: Doesn't gpgfixtures provide better implementations for the stuff that sits *under* GPGHandler?
<wgrant> The stuff I've moved does not include any fixtures, and is all code that is either GPGHandler or pokes stuff into the DB through it.
<wgrant> Not relating to the underlying keyserver.
<wgrant> Unless gpgfixtures covers the LP DB as well, which would be somewhat worrying.
<lifeless> wgrant: it changes gpghandler
<lifeless> wgrant: and provides test keys too
<lifeless> wgrant: gpgverifyd replaces gpghandler
<lifeless> more or less
<lifeless> I guess I mean 'please check the fallout here, I have nasty WIP'
<wgrant> Ah, I thought that didn't exist past a prototype server implementation.
<lifeless> I'm on a 4 month yak shave to make that prod
<lifeless> currently on the 'and it needs reliable OOPS infrastructure' arc.
<wgrant> Right, but I didn't know any LP client code existed for it.
 * wgrant hunts.
<lifeless> gpgverifyd -> oops -> oops-tools -> pruning -> scriptactivity -> slony-db-migrations
<wgrant> Heh
<lifeless> wgrant: I'm pretty sure my branches are up on LP
<lifeless> wgrant: by heh I hope you mean 'heh that is terrifying'
<wgrant> lifeless: Huh
<wgrant> Did you just view your usegpgfixtures branch?
<lifeless> no
<wgrant> Because it didn't time out first time.
<lifeless> I did no
<wgrant> Hmmm.
<wgrant> How did that work, then...
<lifeless> existing disk cache
<lifeless> and branch tip matches
<lifeless> at a guess
<wgrant> Doesn't normally help, but perhaps it did here for some reason.
<lifeless> ah, found my bug - 708961
<wgrant> Bug #708961
<_mup_> Bug #708961: loggerhead oops reports are missing diagnostic data <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/708961 >
<lifeless> wgrant: https://code.launchpad.net/~lifeless/launchpad/deps/+merge/85005 is the context
<wgrant> Ah, not so bad one tiny import conflict in one of the tests.
<lifeless> what revno is my lp branch @?
<wgrant> usegpgfixtures r13758
<lifeless> 13759 locally
<lifeless> lets see
<lifeless> 'merge up with devel'
<wgrant> Heh
<lifeless> probably a bunch of conflicts or I wouldn't have bothered
<lifeless> pushing it it
<wgrant> Odd. Only buildout.cfg/setup.py conflicts here.
<lifeless> ENOIDEA
<lifeless> its up
<wgrant> Thanks.
<lifeless> thanks for investigating
<wgrant> I'm glad that LP uses four JS frameworks :)
<wgrant> YUI3 primarily, YUI2 for calendar widgets, jQuery for the tour, MochiKit for some old translations stuff and not much else.
<lifeless> ok, so lets see, get a handle on soyuz and I can week it a call
<wgrant> eparse
<lifeless> :)
<wgrant> Week it a call?
<lifeless> 'call it a week' with the object and verb transposed
<wgrant> Oh, blah, of course.
<wgrant> It is Friday afternoon, meh.
<wgrant> soyuz == poppy?
<StevenK> And wgrant is EOY'ing :-(
<StevenK> wgrant: Did sinzui complain about my branch that he tossed through ec2 again?
<lifeless> wgrant: yes
<wgrant> StevenK: Vaguely, but without details.
 * StevenK will thrash it to bits on Monday
<lifeless> I hate that ubuntu's pastebin does openid to get at the raw version
<wgrant> lifeless: spam
<lifeless> wgrant: how does that help, given that the html version doesn't do openid
<wgrant> No idea, but that's the rationale AFAIK.
<lifeless> yes
<lifeless> nevertheless, its a real nuisance when I want to apply a patch straight from it on a headless machine
<wgrant> Yes.
<lifeless> 5 out of 5 hunks FAILED -- saving rejects to file poppy-sftp.tac.rej
<lifeless> 1 out of 1 hunk FAILED -- saving rejects to file service.py.rej
<lifeless> 2 out of 2 hunks FAILED -- saving rejects to file loggingsupport.py.rej
<lifeless> I shouldn't have bothered.
<wgrant> Healthy.
<lifeless> EOL probably
<wgrant> I'd assume so.
<lifeless> sometimes I love twisted
<lifeless> sometimes not so much
<lifeless> https://bugs.launchpad.net/launchpad/+bug/901498/comments/20
<_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/901498 >
<lifeless> whats the zope thing to check an interface is provided ?
<lifeless> and implemented
<lifeless> from zope.interface.verify import verifyObject
<lifeless> ICanHasReiew? https://code.launchpad.net/~lifeless/python-oops-twisted/bug-902006/+merge/85065
<lifeless> wgrant: ^ still around - or have I missed you?
<wgrant> lifeless: Looks good.
<wgrant> But with that, I might EOY.
<lifeless> wgrant: see you on wed?
<wgrant> Wed?
<lifeless> australasia christmas do
<wgrant> Unlikely. It's a little way away, and I have little other cause to go to Sydney :)
<lifeless> no worries
<lifeless> see you in budapest hten
<wgrant> Indeedily.
<nigelb> YOu guys sprinting in Budapest in Jan?
<wgrant> Yeah, with platform^Wdistro^Wubuntuengineering^Wwhatevertheyarenow
<nigelb> heh
<lifeless> righto, poppy sorted.
<lifeless> lp:/~lifeless/launchpad has the gore
<lifeless> bah
<lifeless> lp:/~lifeless/launchpad/bug-901498 has the gore
<stub> Is this a spurious ec2 error? http://paste.ubuntu.com/764660/
<wgrant> stub: Yes. I fixed it this morning.
<stub> cool. lp-land then.
<wgrant> stub: Oh, new baseline?
<wgrant> I was wondering when that would happen.
<stub> wgrant: Yes. Just slow getting it landed
<stub> pebkac one day, ec2 fail one day...
<lifeless> stub: does this include emptyin trusted.sql ?
<lifeless> or is that separate
<stub> lifeless: yes. But fti.py is still being called.
<lifeless> thats fine
<lifeless> stub: the dump doesn't include the fti vectors by default?
<stub> lifeless: We can trash comments.sql too (I just want to catch production up first since the tree is more up to date at the moment)
<lifeless> stub: yeah, I'm not coding in support for comments.sql
<wgrant> Why empty it rather than removing it?
<stub> lifeless: The dump of the schema includes the fti columns. The sample data goes to lengths to set them all to NULL when generating the sampledata (using an fti.py magic option) and again uses fti.py to regenerate them to real values after restoration
<stub> wgrant: minimize code changes to db-devel
<stub> wgrant: And one step at a time - easy to back out if I forgot some corner case and we need to recover
<wgrant> Oh, didn't realise this was on db-devel.
<wgrant> Why's it on db-devel?
<lifeless> stub: so one way we could eliminate fti.py is to remove the null-on-dump, then do a no-op update, then remove fti.py ?
<lifeless> stub: which would get us to the 'apply patches to change things' state we have prod in, for devs too
<stub> lifeless: I like NULL on dump - no need to store generated data in the sample data. I'll just have a little helper we can use and trash fti.py
<stub> erm... like NULLs in the dump. Makes the diffs nicer, makes things easier to read
<wgrant> The sample data is *all* generated data.
<lifeless> stub: most of sampledata is generated in some way ;)
<stub> yeah yeah
<wgrant> However, I am tempted to agree with stub until we get rid of sampledata entirely.
<stub> I can think of one reason to put the fti data into the sample data dump - if we end up with bespoke fti indexes (say, a BugSearch table with its fti data updated from triggers on bug, bugtask, product etc) we can't really automate a way to rebuild it.
<stub> rebuild the data I mean
<lifeless> seems sound to me
<lifeless> another reason is that the content of the sampledata dump isn't really editable anyhow - thats why we load it up, then tweak live, then dump.
<wgrant> Well actually...
<lifeless> people do, doesn't make it a good idea
<lifeless> e.g. editing bugsummary extracted data in the dump will 'work' but generate invalid state
<stub> I'm comfortable enough with my hypocrisy to tell people not to while doing it myself...
<stub> I don't think I need to announce trusted.sql changes - almost always stored procedures arrive in db patches and I have to tell people to move the code.
<stub> trashing trusted.sql will have the nice side effect of making staging restores more readable
<jtv> lifeless, stub: good to have you both here.  DB review needed!  https://code.launchpad.net/~jtv/launchpad/db-849683-notnull/+merge/85076
<stub> jtv: r=stub
<jtv> th
<jtv> x
<adeuring> good morning
<jtv> morning adeuring
<adeuring> hi jtv!#
<jtv> stub: I wonder if we could safely run our sample data through âcat --squeeze-blankâ to normalize blank lines.  Getting so tired of that useless bit at the top of the diff.
<stub> jtv: it would bite someone eventually who tries to put a double newline in a string for formatting
<jtv> More to the point, would we have any sympathy?
<stub> jtv: A regexp that understants the basic string quoting used though would be fine.
<stub> jtv: Sure, especially if people want sample data to demonstrate markup for example
<jtv> But what about our no-new-sampledata rule?
<stub> that is for tests
<jtv> Ah, dev sampledata.  Hadn't thought of that.
<poolie> allenap, hi, can you reread https://code.launchpad.net/~mbp/launchpad/feature-modulus/+merge/84890
<jtv> morning bigjools
<bigjools> good morning
<bigjools> bliss is reading email before starting IRC
 * jtv parses
 * jtv ponders
<jtv> Who's Bliss?
<bigjools> lifeless: \o/
<jtv> Let me just go through a few reboot contortions to get audio working for the call.
<lifeless> bigjools: ?
<bigjools> lifeless: you fixed it
<lifeless> bigjools: ah yes
<lifeless> bigjools: was fairly straight forward, once I got the rest of my plate clear to actually look at it
<lifeless> bigjools: (getting to that point took all day :P)
<bigjools> lifeless: what a mess the logging code is :/
 * bigjools OTP
<lifeless> bigjools: I assume you're fine going forward?
<bigjools> lifeless: will talk after I get off phone
<stub> bigjools: twisted logging or logging module logging? Think I'm mainly responsible for the mess the latter is.
<bigjools> both
<bigjools> well, more twisted's
<stub> LibrarianLogger should die if that causes you any headaches.
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugtasks: 3*10^2
<allenap> poolie: Sure.
<poolie> thanks
<lifeless> night all, have a good weekend
<jelmer> have a good weekend lifeless
<bigjools> lifeless: still there?
<bigjools> stub: is the librarian logging to stdout right now?
<bigjools> ah no, the crazy twisted rotating nonsense
<jtv> bigjools: garbo is now cronned on dogfood.
<bigjools> rejoice for more timeouts on df
<jtv> I may be hammering it a bit hard.
<jtv> Then again, dblooptuner.
<rick_h_> morning
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugtasks: 3*10^2
<bac> hi adeuring, i'm going to grab stub's MP unless you're working on it
<adeuring> bac: no, i haven't had a look yet
<bac> ok
<bigjools> abentley: can you spare a couple of minutes please? I need to ask about some codehosting tests
<abentley> bigjools: I have stand-up in 6 minutes.  Do you want to talk before or after?
<bigjools> abentley: I'll try and fit it in now if that's ok!
<bigjools> in lib/lp/codehosting/puller/tests/test_acceptance.py there's a assertRanSuccessfully
<abentley> bigjools: certainly.
<bigjools> it checks to see that stdout is empty
<bigjools> do you know the purpose of that:?
<abentley> bigjools: no.  Let me annotate it...
<bigjools> reason I ask is because I am changing how logging works across our apps because there's a honking great bug with the new oops  stuff, and now I get a non-empty log
<bigjools> like this:
<bigjools> + 2011-12-09 18:13:30+0530 [-] Log opened.
<bigjools> + 2011-12-09 18:13:34+0530 [-] Main loop terminated.
<bigjools> which seems innocuous, but ...
<abentley> bigjools: I guess it might assume that logging is done to a file, not stdout.  That's the only reason I can think of.  You could ask jml; he wrote that.
<bigjools> yeah that's all I could think of too
<jml> It's running the cron job directly, so it's assuming no output
<jml> and logging to a file
<jml> see cronscripts/supermirror-pull.py
<bigjools> jml: I guess my logging changes didn't quite work for supermirror!
<bigjools> oh I see why, the test doesn't supply --logfile
<bigjools> abentley: would you mind checking over my logging changes in this branch please? It affects a couple of codehosting services and I'd feel happier if an expert looked. https://code.launchpad.net/~julian-edwards/launchpad/detailed-gpg-exceptions/+merge/85138
<abentley> bigjools: I'm sorry, but none of this is anything I have special knowledge about.
<bigjools> abentley: ok fair enough, thanks
<abentley> bigjools: np
<allenap> adeuring, bac: Please can you review my branch? https://code.launchpad.net/~allenap/launchpad/check-teamparticipation-fix-too-bug-897269/+merge/85148
<adeuring> allenap: sure
<allenap> adeuring: Thanks.
<adeuring> allenap: r=me
<allenap> adeuring: Thank you :)
<james_w> is lp.bugs.scripts.checkwatches.tests.test_bugwatchupdater.BugWatchUpdaterTestCase.test_known_error_handling the last test to run?
<james_w> my ec2 instance has gone away again, and I' wondering if it ran to completion first
<allenap> james_w: In what context, or is this ECHAN?
<allenap> james_w: Ignore me, I can't read.
 * allenap tries to find out.
<allenap> james_w: No, it's not the last for me.
<james_w> hmm
<james_w> would someone please throw https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 at ec2 land for me then please
<james_w> I've had it die twice with no indication of any failures
<allenap> james_w: Sure.
<james_w> thanks
<Laney> james_w: There is a typo there "teh `date_created`" ;-)
<james_w> damnit
<james_w> it's probably being rejected by the spell check then :-)
<Laney> unless you are being 31337
<bac> jcsackett: hi i'm looking at your branch for driver/maintainer picker -- thanks for making this long-needed improvement.
<bac> jcsackett: i notice, however, you got rid of the pop-up help for driver.  was that accidental?
<jcsackett> bac: it was. offhand i'm not sure how to include it back in though. i'll poke around.
<jcsackett> (i don't think just putting the anchor back in will look right b/c of the html around the button, but maybe)
<bac> jcsackett: ok.  i think we need to keep it since no one knows what a driver is.  r=me pending figuring that part out.
 * jcsackett nods.
<jcsackett> thanks, bac.
<lifeless> poolie: oh hai
<lifeless> poolie: btw we'll get soft timeouts from bazaar.launchpad.net now
<lifeless> poolie: may have to fiddle with oops-tools reports a little to get good summaries, but we'll know how many requests go over 7 seconds
<abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/fix-expirable-bugs/+merge/85181 ?
<bac> abentley: sure
<abentley> bac: thanks.
<bac> abentley: i don't understand why the original problem occured, producing the KeyError.  the only actual code change i see is using 0 instead of the config value.
<abentley> bac: The bug fix is through making BugTaskExpirableListingView a subclass of BugTaskSearchListingView, so that BugTaskSearchListingView.initialize sets up the correct IJSONRequestCache values.
<bac> ah, ok.  i overlooked that
<abentley> bac: I may not have explained that well.
<bac> abentley: no, my fault.  but that's why on-call reviewing is great.
<bac> done abentley.  thanks.
<abentley> bac: thank *you*.
<flacoste> woohoo for autmatically updated preview diff!
<Duditz> hi all! please, after I do launchpad actions, when my karma is updated?
<jelmer> Duditz: I think it's updated weekly or so
<Duditz> great, thanks jelmer
<flacoste> rabbit seems to have problems on the latest db_lp build
<flacoste> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1577/steps/shell_6/logs/summary
<sinzui> bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/series-package-subscriptions/+merge/85188 when the diff appears?
<bac> sinzui: i do
<sinzui> I see db_lp failed. I cannot reproduce the error: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1577/steps/shell_6/logs/summary Should I retry the build
<bac> sinzui: done.
<sinzui> thank you bac
<sinzui> jcsackett, do you have time to mumble
<jcsackett> sinzui: yes, one moment.
<abentley> bac: AFAICT, setup_subscription_link in lib/lp/registry/javascript/structural-subscription.js throws an exception if no subscription link is present.  Was this intentional?
<bac> abentley: yes, the link should be present
<abentley> bac: You're written code in lp.bugs.browser.structuralsubscription.StructuralSubscriptionMenuMixin that makes it not always present.
<bac> abentley: so for anon users the JS is throwing the error?
<abentley> bac: Actually, I'm getting the error on https://bugs.launchpad.net/charm
<abentley> bac: I don't understand why yet.
<abentley> bac: I believe it's the root cause of bug #902252
<_mup_> Bug #902252:  sort buttons that are missing on the distribution dynamic bugs listing <bug-columns> <fallout> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/902252 >
<abentley> bac: I think this is because I am not a member of the bug supervisor, juju Charm Contributors
<bac> abentley: yes, the logic behing userCanAlterBugSubscriptions is crazy.  it's an ubuntu thing.
<abentley> bac: So I think the error should be scaled back at most to a warning, maybe an info or debug.
<bac> abentley: that is probably a good idea.
<abentley> bac: cool, thanks.
<abentley> bac: I've confirmed that adding me to "juju Charm Contributors" fixes the bug.
<bac> abentley: that isn't very scalable!  :)
<abentley> bac:-)
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2
<james_w> FAILURE: lib/lp/bugs/javascript/tests/test_buglisting_utils.html
<james_w> is that a known failure currently?
<james_w> it's very unlikely to do with anything in my branch that just got rejected because of that failure
<lifeless> no
<james_w> well it passes locally on tip
<james_w> and with my branch merged
<james_w> so would someone please throw https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 at ec2 land again?
#launchpad-dev 2011-12-11
<lifeless> allo allo
<lifeless> \o/ lp-migrate success!
<jelmer> lifeless: what's lp-migrate?
<lifeless> an extraction of the LP schema migration stuff to an external tool
<lifeless> 'lazr postgresql migration'
<jelmer> ah, nice
<lifeless> lp:lazr-postgresql, though I haven't pushed up any content yet
<lifeless> ok, current code state pushed up
<lifeless> its ready for developer use, need to do the migration of slony bits still though
<wallyworld_> wgrant: morning. much happen last week?
<wgrant> wallyworld_: With just jcsackett, sinzui and I... not really.
<wallyworld_> i had virtually no internet so it was great to relax down the beach :-)
<wallyworld_> sooo much email to get through now though :-(
<lifeless> wallyworld_: got 10 minutes for a quick voice chat?
<wallyworld_> lifeless: sure. give me a sec to grab the headphones.
<lifeless> wallyworld_: great; skype me when ready
 * wgrant looks at r14459, and is suddenly glad he's not here this week.
<wallyworld_> lifeless: sorry. skype hates me. stupid mic doesn't work
<lifeless> have you unmuted the input ?
<wallyworld_> lifeless: been trying to fix it
<wallyworld_> yes i can hear you
<wallyworld_> tried that
<wallyworld_> +61733785902
#launchpad-dev 2012-12-03
<adeuring> good morning
<czajkowski> wallyworld: you about?
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: benji | Firefighting: - | Critical bugs: ~170
<wallyworld> czajkowski: hi, just got back from an awesome concert - saw The Living End
<deryck> Morning, all.
<rick_h_> morning
<czajkowski> wallyworld: oh excellent
<wallyworld> can i help with anything?
<czajkowski> it's ok now think sinzui is online and was just curious about a bug
<czajkowski> sinzui: morning https://bugs.launchpad.net/launchpad/+bug/1056788
<_mup_> Bug #1056788: Can't list members of private team that I own <Launchpad itself:New> < https://launchpad.net/bugs/1056788 >
<czajkowski> any thoughts on this.
<sinzui> no yet
<sinzui> czajkowski, The admin of the team is not a member of many of the private sub teams. The LP is raising forbidden. This is a corner case that was mostly likely caused by  team membership changes -- you cannot add the sub team unless you could see it from the start. We need to fix to ensure no team spys on another team.
<czajkowski> ah ok intersting
<czajkowski> *interesting
<czajkowski> was looking at different teams and members tryig to work it out :/
<czajkowski> sinzui: also re the other bug Inleft a comment on, know it's not qa'd but was adding the oops and page so afterwards I can just check it was all working, sorry :)
<sinzui> czajkowski, I did qa the bug: https://qastaging.launchpad.net/~locoteams and https://qastaging.launchpad.net/~launchpad-users both load
<czajkowski> great
<deryck> adeuring, rick_h_, jcsackett -- I'm coming for standup.  Hangout loading troubles.
<czajkowski> sinzui: how do we feel about the Waqf General Public License?
<sinzui> czajkowski, it discriminates. We accepted one because the project was dual-licenses as simple GPL
<czajkowski> nods
<czajkowski> sinzui: https://launchpad.net/elkirtassemaktaba  project in question
<sinzui> czajkowski, it is GPLed to so we would accept it. This was the debian discussion that re-enforced my belief that these project must be dual licensed: http://lists.debian.org/debian-devel/2010/07/msg00019.html
<czajkowski> oh
<czajkowski> sinzui: speaking of debian -https://support.one.ubuntu.com//Ticket/Display.html?id=25941  and https://support.one.ubuntu.com//Ticket/Display.html?id=25970  what do you do in cases like this ?
<sinzui> we have a bug for this.
<sinzui> Lp should not imply it can happen. We know a team cannot be merged with a user
<sinzui> czajkowski, this is bug 681367
<_mup_> Bug #681367: Do let users try to merge teams into people <lp-registry> <merge-deactivate> <Launchpad itself:Triaged> < https://launchpad.net/bugs/681367 >
<sinzui> Lp wont let it happen, it should not have implied it could happen, it should not have let the user try to get the team
<czajkowski> nods
<czajkowski> so should the title be do not let users try to merge teams into people?
<sinzui> oh, yes, "do not" I just fixed it
<czajkowski> ack
<czajkowski> have had users trying to do all srts of merges this weekend into other peoples accounts
<czajkowski> :s
<rick_h_> deryck: I need to add the product property to the Product object. It needs to make its ways into the LP.cache.context dump of data. I'm thinking this should go on IProductLimitedView. Does that make sense?
<rick_h_> Then it should show up for private projects, but not for public viewing/people without access to the product
<rick_h_> not that they should see the page anyway...
<deryck> rick_h_, reading... thinking....
<deryck> rick_h_, that sounds generally right to me, but you might want to run it by adeuring for a second opinion.
<rick_h_> ok, will do
<adeuring> rick_h_: I don't get the property: Product.product?
<rick_h_> adeuring: Product.private
<rick_h_> sorry, typo there
<rick_h_> adeuring: so looking at something like https://pastebin.canonical.com/79610/
<adeuring> rick_h_: yes, I would even think that we could make the property private public, after all, it has less information than information_type, from which it is derived
<rick_h_> adeuring: yea, that's kind of why I was asking. It seems there's a couple places it 'could' go and wondered where the best place was
<rick_h_> but useCanView was the only property on IProductPublic so seems not a place to stick most things
<rick_h_> but I guess these two kind of fit together so makes some sense (private and useCanView)
<adeuring> rick_h_: yes, the point is that information_type is defined elsewhere, canÃt remember exactly the location...
<rick_h_> it's in the model only
<rick_h_> it's not exposed at the interface level I can tell
<adeuring> ricit's defined in app.interfaces.IIformationType, and this is a base class of IProduct
<rick_h_> ah, missed that
<rick_h_> ok, so maybe I should add this to that interface?
<adeuring> rick_h_: well, check where IInformationType is used ;)
<adeuring> but generally, yes
<adeuring> rick_h_: if you want a full overview on all properties and permissions, look at lib/lp/registry/tests/test_product.py expected_get_permissions
<rick_h_> yea, I was copying this from the branch implementation
<rick_h_> so it'd be used there, bugs I'd imagine.
<adeuring> rick_h_: actually, private is already defined teher
<rick_h_> adeuring: in IInformationType? /me isn't seein git
<adeuring> rick_h_: I have no idea where it is defined at present -- but the securtiy checker knows about it ;)
<rick_h_> adeuring: heh, well I see it on productset, and I think I added it there
<rick_h_> for the icon stuff a while ago
<rick_h_> but not on product itself, and it's not exposed to LP.cache which I think is interface @expose based
 * adeuring tries fond the definition....
<adeuring> rick_h_: lp.app.interfaces.launchpad: IPrivacy -> IInformationType -> IProduct
<rick_h_> adeuring: ah ok...so it's there but not exported.
<rick_h_> adeuring: ok thanks. this makes sense. I saw one place that mentioned it was redefined in the comment for it
<rick_h_> that must be why
<adeuring> benji: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-1071589/+merge/137659 ?
<benji> adeuring: sure
<adeuring> thanks!
<sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/revision-karma-1/+merge/137660
<benji> sinzui: sure
<adeuring> benji: thanks for the review!
<benji> adeuring: my pleasure
<Masklinn> is there any support for service hooks in launchpad? Or any kind of "push" notification other than email?
<sinzui> Masklinn, no.
<sinzui> Masklinn, several groups have written API scripts that poll and then make the necessary notifications
<Masklinn> sinzui, I guess that's what I'll have to do as well.
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~170
#launchpad-dev 2012-12-04
<lifeless> bigjools: if they paste the error they are having they might get help!
<bigjools> lifeless: well, quite :)
<adeuring> good morning
<deryck> Morning, all.
<rick_h_> morning deryck
<rick_h_> adeuring: do you have time to do a hangout on this zcml fun please?
<adeuring> rick_h_: sure
<rick_h_> adeuring: woot! all the product tests passed. So back to my own new tests and making this work. Thanks!
<adeuring> rick_h_: welcome :)
<sinzui> jam, mgz: I don't understand the issue with this import to help the user. Can you help? https://answers.launchpad.net/launchpad/+question/215746
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: rick_h | Firefighting: - | Critical bugs: ~170
<rick_h_> adeuring: can you please review this branch we chatted about then since I'm OCR? https://code.launchpad.net/~rharding/launchpad/changing_maintainer_1077841/+merge/137849
<adeuring> rick_h_: sure
<rick_h_> thanks
<adeuring> ricr=me
<sinzui> rick_h_, do you have time to review https://code.launchpad.net/~sinzui/launchpad/cleanup-merged-people-1/+merge/137700
<rick_h_> sinzui: will do after call
<rick_h_> sinzui: r=me
<sinzui> thank you rick_h_
<adeuring> rick_h_: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-1086043/+merge/137882 ?
<rick_h_> sure thing adeuring
<adeuring> htanks!
<mattyw> I'm having a go at fixing bugs in loggerhead. I'm trying to run serve-branches but all I get from my browser is: The resource could not be found. Anyone able to offer a couple of minutes to help me work out what I'm doing wrong?
<rick_h_> mattyw: when I last ran it I could only get it to work against a single branch and not against a direcotry of them
<mattyw> rick_h_, from within my loggerhead source directory I do ./serve-branches (no args) correct? I believe that should give me one branch
<rick_h_> ok, what I had to do to get it working was install it as a bazaar plugin, and then use bzr serve --http
<rick_h_> mattyw: https://code.launchpad.net/~rharding/loggerhead/yui3.7.1 is the branch I had going to work on YUI update there and I had to go that plugin route to get it to run/verify
<rick_h_> adeuring: one question and one comment fix on your MP
<rick_h_> adeuring: your tests pass though, so maybe I'm mis-understanding things which is why you didn't have to move the displayname to the new interface as well?
 * adeuring is looking
<adeuring> rick_h_: I am pretty sure that displayname will be needed to fix bug 1086057. But the bug listings do not show the displyname; the series's name is needed in the call of canonucal_url()
<_mup_> Bug #1086057: Users with an artifact grant for a bug related to a private product can't view the bug page. <Launchpad itself:Triaged> < https://launchpad.net/bugs/1086057 >
<adeuring> rick_h_: but for now, I'd like to keep displayname protected by lp.View -- simply because it is not needed in the bug listing
<rick_h_> adeuring: right, so you moved displayname in the zcml from one block to the other. Then you moved name into IProductSeriesLimitedView, but not displayname
<rick_h_> adeuring: ah ok gotcha
<mattyw> rick_h_, thanks that seems to work
<adeuring> rick_h_: argh, yes, no I get the oddity. let me check again
<adeuring> rick_h_: milestone.displayname needs lp.LimitedView for bug listing page, but productseries.displayname is not needed there...  As said, I'll probably have to use lp.LimitedView for productseries.dispalyname in my next brnach
<rick_h_> adeuring: right ok. so r=me just wanted to dbl check there
<rick_h_> zcml turning my brain to mush today
<adeuring> rick_h_: thanks. YOur question made sense -- it was probably not the best idea to change the permission for two different classes in one branch ;)
<james_w> rick_h_, hi, would you take a look at the extra revisions on https://code.launchpad.net/~james-w/python-oops-tools/recent-oopses/+merge/137055 please?
<james_w> they are to fix the tarmac test failure under python2.6
<sinzui> rick_h_, do you have time to review https://code.launchpad.net/~sinzui/launchpad/revision-karma-2/+merge/137906
 * sinzui looks at james_w's branch
<james_w> thanks sinzui
<sinzui> ah, I see. r-=me
<sinzui> james_w, r=me.
<james_w> sinzui, merci
<rick_h_> sinzui: sure thing looking
<rick_h_> sinzui: r=me
<sinzui> thank you rick_h_
<mattyw> rick_h_, me again, I thought I'd look into this bug https://bugs.launchpad.net/loggerhead/+bug/358293. But I can't seem to even find the search box displayed anywhere.
<_mup_> Bug #358293: Search field is too narrow <trivial> <ui> <loggerhead:Triaged> < https://launchpad.net/bugs/358293 >
<rick_h_> mattyw: hmm, wonder if it's not displayed in a single branch view
<mattyw> rick_h_, hmmm, looks like this is what I see https://bugs.launchpad.net/loggerhead/+bug/1075907
<_mup_> Bug #1075907: Loggerhead - serving two directories from parent <loggerhead:Confirmed> < https://launchpad.net/bugs/1075907 >
<rick_h_> mattyw: right
<rick_h_> sinzui: forced another build-not build
<sinzui> oh, so did I
<rick_h_> heh, crush the buildbot!
<wgrant> deryck: Hi, did the definitional issue that I raised last night get sorted out before we announced private projects were out of beta?
<wgrant> I suspect we've released a definition of privacy that we can't support.
<wgrant> Specifically, AIUI we say that series and milestones are private from people who can only see a bug, when that's impossible.
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~170
<deryck> hi wgrant.  It's not landed yet, but abel has a branch nearly done.  Should be landing during his tomorrow.
<wgrant> Ah, great.
<deryck> wgrant, thanks for catching that and letting us know.
<wgrant> It just reveals some details of milestones and series?
<deryck> yeah
<deryck> well, and a list 403s
<wgrant> I mean, how does the fix fix it?
<deryck> wgrant, that was the yeah, and then I thought you meant something else.  sorry. :)
<wgrant> Right :)
<wgrant> Thanks
<deryck> wgrant, we fix it with limited view to reveal the name of the milestones and series.
#launchpad-dev 2012-12-05
<mwhudson> <branch vocab rage goes here>
<StevenK> mwhudson: Oh?
<mwhudson> StevenK: go to (e.g.) link branch to bp page
<mwhudson> type something that isn't an exact branch unique name
<mwhudson> --> timeout
<StevenK> Ah yes, substring matching over many many tables
<StevenK> There's a critical about it
<adeuring> ood morning
<BearIBeer> Hi All, I am a newbie to use launpad and I have a question. I following someone's instructions to review the weblink https://wiki.ubuntu.com/Bugs/HowToFix several times but I am still can not find out where to deploy the operations
<BearIBeer> modify totem by adding "Modified by $my_name" in the "About(A)"
<BearIBeer> Who can help me on this point?
<BearIBeer> I have create my account on Launchpad, https://launchpad.net/~gywxme is my home
<mattyw> anyone know how I can get to the search screen using loggerhead?
<adeuring> rick_h_: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-1086057/+merge/138086 ?
<rick_h_> adeuring: sure thing
<adeuring> thanks!
<rick_h_> adeuring: bzr hates your branch and won't update the diff :/
<adeuring> rick_h_: I've added the diff in a comment
<rick_h_> adeuring: thanks
<rick_h_> adeuring: r=me
<adeuring> rick_h_: thanks!
<deryck> Morning.
<rick_h_> sinzui: is this ok to fix release? https://plus.google.com/hangouts/_/b76127bb9aeef46eade6870be66c76f0b89fd4c0
<rick_h_> looks like you moved it to in progress
<sinzui> rick_h_, you pasted a hangout? If that right?
<rick_h_> doh
<sinzui> rick_h_, perhaps you meant my card for https://bugs.launchpad.net/launchpad/+bug/1050191 which *might be fix released* I am working with webops to confirm the truth
<_mup_> Bug #1050191: allocate-revision-karma.py is too slow to complete <branches> <karma> <lp-code> <oops> <qa-ok> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/1050191 >
<rick_h_> no, the bug that just deployed
<rick_h_> ok
<sinzui> there was a branch that fixes two bugs. I marked the one of them fix released since scripts missed it
<rick_h_> ok, that's what I thought, but wanted to dbl check
<james_w> is someone able to review https://code.launchpad.net/~james-w/python-oops-tools/decode-reports/+merge/138267 please?
<james_w> it's very small and blocking an oops deployment
<james_w> I've self-approved that to get this deploy done, I'm happy to get a post-merge review
<rick_h_> james_w: cool, sorry about that. Busy and somewhat empty ship today
<james_w> np
<rick_h_> james_w: seems small/simple enough so self-review ftw
<slank> I'm trying to authenticate to staging with the python library and it doesn't prompt me for credentials. How can I log out?
#launchpad-dev 2012-12-06
<james_w> https://code.launchpad.net/~james-w/python-oops-tools/recent-oopses/+merge/138356 if anyone can take a look
<rick_h_> james_w: ok by me I guess. I'm not sure who's doing full oops stuff these days.
<james_w> rick_h_, yeah, it's in a bit of limbo currently
<rick_h_> stupid south and the models garbage output
<rick_h_> yea, I don't konw the codebase well but your stuff looks ok on the surface here
<james_w> it's a pretty small change at least :-)
<james_w> thanks rick_h_
<rick_h_> james_w: np
<czajkowski> morning
<adeuring> good morning
<czajkowski> adeuring: hey there hows things?
<adeuring> czajkowski: good.First snow today (though minor amounts only)
<czajkowski> aye we've had similar over here but it's cold :/ -4
<czajkowski> snow not staying though :D
<adeuring> czajkowski: same here
<czajkowski> sinzui: you rock! thanks for covering for me for the last 2 days!
<StevenK> czajkowski: It was ~ 24 here today :-)
<czajkowski> :(
<czajkowski> heavenly
<StevenK> Apparently, 26 tomorrow
<nigelb> StevenK: I almost read that as -24 and went wtf :)
<StevenK> Haha
<StevenK> nigelb: It's Sydney, not Siberia
<nigelb> StevenK: Indeed. Also, isn't that particularly not-warm for summer?
<nigelb> I thought Australia got hotter than that.
<StevenK> nigelb: It was 37 last Saturday
<nigelb> that sounds more like australia :P
<StevenK> I like it being around the 20s. It means I can actually think
<nigelb> Hehe. No air conditioning in your home-office?
<StevenK> nigelb: Nope
<nigelb> Ouch.
<jcsackett> sinzui: thanks so much for reviewing my branches!
<sinzui> np. I knew you needed to find a reviewer since you were on-call
<jcsackett> indeed. was about to begin hunting people down when i saw you had reviewed them.
<james_w> does anyone have an instance where an oops mentioned in an LP bug report was deleted?
<james_w> (from oops.canonical.com, not lp-oops)
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: jcsackett | Firefighting: - | Critical bugs: ~170
<czajkowski> james_w: nope not seen that
<james_w> ta
<czajkowski> but sinzui is kicking ass on the criticals which many of them are oops
<sinzui> james_w it is not possible to delete a bug report
<james_w> sinzui, yeah, I'm looking for any instance where the oops was deleted from oops.canonical.com, even though the oops id was mentioned in a bug report
<sinzui> james_w, you can delete extra tasks and you can retarget a task, and that might look like a report was deleted
<sinzui> oh
<sinzui> neem
<sinzui> james_w, the pruner is too aggressive. We sometimes search neem for the actual oops files.
<james_w> sinzui, ok, thanks
<james_w> anyone want to talk ssl cert verification with me?
<james_w> oops.canonical.com is currently not removing anything from its db as the prune script is broken
<james_w> because it can't verify the cert of api.launchpad.net
<james_w> which works fine on Ubuntu because ubuntu carries a patch to use /etc/ssl/certs
<james_w> but oops uses httplib2 from buildout, so doesn't have that patch
<james_w> and fails to verify the cert
<czajkowski> james_w: hmm not sure who best to point you at
<czajkowski> james_w: flacoste may know who to direct you to as stub is in the other timezone
<james_w> so if you aren't using ubuntu's httplib2 you can't use launchpadlib against launchpad.net
<james_w> I see a few options:
<james_w> disable cert checking (no)
<james_w> add a patched version of httplib2 to oops' buildout - fixes it for oops, but not for anyone else, costs us to maintain a fork of httplib2
<james_w> override the cert path from lazr.restfulclient - fixes it for everyone that has /etc/ssl/certs, remains broken for anyone who has their certs elsewhere
<james_w> make the cert path configurable in launchpadlib - allows anyone to fix it, but all users would have to add platform detection if they wanted that, lots more work to change all the projects and do releases etc.
<james_w> any ideas I have missed?
<james_w> any opinions on the best option?
<james_w> currently I'm leaning towards the override in lazr.restfulclient
<james_w> as it fixes it for the most number of people without extra work for clients, and without having to work all the place where the certs can live on all the different platforms
<cjwatson> another option: get upstream to include the relevant cert, even if they don't want to take the system-ca-certs patch
<james_w> cjwatson, true
<james_w> or put LP's cert in a file and use that, regardless of the platform
<adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-1086876/+merge/138514 ?
<james_w> https://code.launchpad.net/~james-w/lazr.restfulclient/use-system-ca-certs/+merge/138520 if someone could review please
<czajkowski> sinzui: might you have time to be able to help daker in https://answers.launchpad.net/launchpad/+question/216116  please
<daker> czajkowski: thanks :)
<sinzui> I answered the question czajkowski
<czajkowski> sinzui: thank you
<czajkowski> daker: answered via sinzui
<daker> thanks sinzui czajkowski
<jcsackett> adeuring, james_w: i'll look at both. sorry for the delay, i was lunching.
<james_w> np
<jcsackett> adeuring: r=me.
<adeuring> jcsackett: thanks!
<jcsackett> james_w: r=me on yours as well. i believe you need someone to land that for you?
<james_w> jcsackett, yes please
<james_w> jcsackett, and I'd really like a release as well if possible
<jcsackett> james_w: i can land it today; i'll see about the release--can that wait till tomorrow if needs be?
<james_w> jcsackett, it's blocking me getting pruning working on oops.canonical.com to remove a couple of million rows from the db
<james_w> jcsackett, so I'd prefer today, but if I have to find someone else that's ok
<jcsackett> james_w: ack.
<sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/lazr.restful/component-lookup-error-404/+merge/138534
<jcsackett> sinzui: i will soon. finishing up with james_w.
<sinzui> jcsackett, np, I am going to move the MP to work because I should commit to doing the release too.
<jcsackett> james_w: landed and released.
<james_w> jcsackett, woop, thanks
<jcsackett> sinzui: i can look at yours now, or after you've made whatever changes you feel are needed to match up with release reqs.
<sinzui> jcsackett, I pushed up changes to the NEWS and version files so that I can release today
<jcsackett> sinzui: dig. i'll review your branch now then.
<james_w> sinzui, would you be able to add https://launchpad.net/lazr.restfulclient/trunk/0.13.2/+download/lazr.restfulclient-0.13.2.tar.gz to lp-source-dependencies for me please?
<sinzui> james_w, yes, I will be updating deps in about an hour I hope
<james_w> ok
<jcsackett> sinzui: r=me.
<sinzui> thank you jcsackett
<sinzui> flacoste, gary_poster, can either of you add me to the list of package index owners for lazr.restful, http://pypi.python.org/pypi/lazr.restful/0.19.9
<gary_poster> sinzui, on it
<gary_poster> sinzui, are you sinzui in pypi
<sinzui> good question. I am chovey
<gary_poster> sinzui, done
<sinzui> thank you very much gary_poster
<gary_poster> np, sinzui
<sinzui> james_w, lazr.restfulclient-0.13.2.tar.gz is in lp-source-dependencies
<james_w> thanks sinzui
<sinzui> james_w, I am landing a branch that increments lazr.restful. Do you want me to also land the increment for your package?
<james_w> sinzui, might as well I guess
<james_w> sinzui, could I trouble you to add http://launchpad.net/django-openid-auth/trunk/0.4/+download/django-openid-auth_0.4.tar.gz to download-cache too please?
<sinzui> okay
<james_w> just needs the file in there so I can use it in oops-tools prod
<sinzui> understood
<james_w> thanks sinzui
<jcsackett> is there any easy way to rerun all the tests that failed in a given ec2 result email?
<james_w> jcsackett, you can process the subunit stream
<james_w> jcsackett, I believe piping it to testr load, then run testr run --failing should do that all under the hood
<jcsackett> james_w: ah, cool.
<jcsackett> thanks.
<james_w> otherwise some subunit-filter and ./bin/test -F should get there
* You're now known as ubuntulog
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~170
#launchpad-dev 2012-12-07
<adeuring> good morning
<czajkowski> aloha
<adeuring> morning czajkowski
<ev> https://code.launchpad.net/~registry/pycassa/master looks busted (there have been commits since February). Would someone mind taking a look?
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: adeuring  Firefighting: - | Critical bugs: ~170
<ev> I've filed https://answers.launchpad.net/launchpad/+question/216171 to track this
<czajkowski> ev: I'll have to wait till sinzui comes on later as that's te only person on maintenance at present
<ev> czajkowski:okay, thanks
<wgrant> ev: it should fix itself after the next import
<wgrant> In fact, it just has
<ev> wgrant: AWESOME
<ev> thanks!
<wgrant> https://bugs.launchpad.net/launchpad/+bug/1072461
<_mup_> Bug #1072461: Code import from githhub does not take latest commits <code-import> <git> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1072461 >
<czajkowski> ev: see :)
<czajkowski> love the vote of confidence though :p
<ev> czajkowski: :D
<sinzui> adeuring, do you have time to review https://code.launchpad.net/~sinzui/launchpad/apply-commercial-subscriptins-1/+merge/138761
<adeuring> sinzui: sure
<czajkowski> sinzui: you're my hero for fixing the commercial voucher bug!
<sinzui> I am happy to make our lives easier
<czajkowski> :D
<adeuring> sinzui: r=me
<sinzui> thank you adeuring
<jcsackett> is there any reason casting an object to an interface (e.g. IQuestionTarget(thingy)) would change permissions on ther resulting object down the line?
<jcsackett> i have one spot where IServiceUsage(foo) is called, which adapts to a distribution. then later, IQuestionTarget(foo) is called, which adapts to the same distribution, but a method that shouldn't be forbidden now is.
<rick_h_> jcsackett: talk with abently about that, send him an email. I think he had a bug/case that sounds a lot like that he was asking gary_poster to look at
<jcsackett> rick_h_: thanks.
<rick_h_> jcsackett: https://bugs.launchpad.net/launchpad/+bug/1066063 is abentley's bug
<_mup_> Bug #1066063: Adaptation has side effects on checker <infrastructure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1066063 >
<rick_h_> (love infinite irc logs)
<jcsackett> rick_h_: well, on the downside, i see no solution. on the plus side i'm now fully justified in a work around and an XXX comment.
<rick_h_> jcsackett: so it matches up to what you're seeing then?
<rick_h_> I'm sure abentley would love to get a +1 on that. Drove him nuts for a couple of days I think
#launchpad-dev 2012-12-09
<StevenK> wgrant: So, why do we want to forbid substring matching for versions? The contrived example I can come up with is an API request for 'libuser' '2.0-1ubuntu' to see what the state of all Ubuntu modified uploads are.
<wgrant> StevenK: People can use the publication APIs for that if they want
<wgrant> This is just for querying the upload queue
<StevenK> Sure
<wgrant> We shouldn't add features unless people need those features
<StevenK> Like I said, my example is contrived
<wgrant> Particularly if those features cost performance
<wgrant> If you can see even the slightest reason to cut something, cut it.
<StevenK> wgrant: Ah, but if we allow substrings then it makes searchable_versions and searchable_names the same in the code, which saves LoC.
<wgrant> But it's also slow and relatively pointless.
<StevenK> Fair enough
<StevenK> I tried
<StevenK> :-)
<StevenK> wgrant: So I should land 40-1?
<wgrant> I think so
<wgrant> Well
<wgrant> Where are we at with deployment?
<wgrant> There's possibly a couple more private projects patches that are undeployed
<StevenK> I don't think 40-0 has hit prod
<StevenK> But I haven't thought about deployments for about nine days
<wgrant> There appear to be four DB patches in the queue
<wgrant> Argh
<wgrant> One of which is bad
<wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/12187
<wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/12198 is illegal as well
<StevenK> wgrant: Argh
<wgrant> So we'll need to talk to deryck
<StevenK> Well, I think 40-0 is first in the queue anyway?
<wgrant> The latter is not broken, just unwise and illegal
<wgrant> The former is broken
<wgrant> Ah, so it is
<StevenK> So we can deploy that today and get it out of the way?
<wgrant> Yeah
#launchpad-dev 2013-12-02
<wgrant> daker: Should be installable now.
<daker> wgrant: thanks, will test it tonight!
#launchpad-dev 2013-12-03
<wgrant> StevenK: What do you get from a test run with --layer YUI on saucy?
 * StevenK waits for bin/test -vv --layer YUI --subunit
<wgrant> The test_expander.html failure is a webkit change, and only appears when the window isn't shown, but the four yuixhr failures don't appear in my precise LXC
<wgrant> Hopefully they appear for you, otherwise I'll have to debug on radande.
<StevenK> steven@undermined:~/launchpad/lp-branches/devel% subunit-1to2 < lp.log | subunit-stats
<StevenK> Total tests:     102
<StevenK> Passed tests:     98
<StevenK> Failed tests:      2
<wgrant> Which failed?
<wgrant> test_choiceedit and test_expander?
<StevenK> Just trying to determine that now
<StevenK> % testr failing --list
<StevenK> lib/lp/app/javascript/tests/test_expander.html
<StevenK> lib/lp/app/javascript/choiceedit/tests/test_choiceedit.html
<wgrant> Right
<wgrant> test_expander appears from precise, test_choiceedit from quantal
<wgrant> The YUIXHRTests (eg. test_milestone_creation ran and succeeded?)?
<StevenK> So no yuixhr failures for you
<StevenK> test: lp/registry/javascript/tests/test_milestone_creation
<StevenK> successful: lp/registry/javascript/tests/test_milestone_creation
<wgrant> k
<StevenK> wgrant: You would have preferred death and destruction for 4 yuixhr tests?
<wgrant> Right, so I wouldn't have to puppet GSAs and webops :)
#launchpad-dev 2013-12-04
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/dkimpy/+merge/197637
<StevenK> wgrant: I'm off today
<wgrant> StevenK: Ah, I see.
<stub> That was smart. I'd managed to disable nearly all of test_gc with an incorrect inheritance order :-/
<stub> No, that should be correct. wtf are my tests not being discovered?
<wgrant> stub: How're you running them?
<wgrant> stub: The test failures showed up with -t lp.services.librarianserver here
<stub> bin/test -vv test_gc
<stub> Yes, found and fixed them. But also noticed I'm only running 6 tests from librarian_gc
<wgrant> stub: Hm, that finds them all on 2.6 here
<stub> wgrant: Do the rest pass btw?
<stub> oh, of course they don't
<wgrant> stub: Everything in lp.services.librarianserver passes, apart from the GC MD5 issues, and the 2.7ism, IIRC
<stub> Seems to be removing duplicate tests, and deciding that because the tests are defined on the Base they shouldn't be run on the subclass (despite the Base not mixing in TestCase)
<wgrant> Hm, that's weird.
<stub> I've used the same pattern in the past, so we should confirm the test count from the precise buildbot.
<wgrant> I checked before, it's only about 50 below the devel one, but that includes layer setup/teardown so it would need manual diffing
<lifeless> are you inheriting the base you think you are?
<stub> Yeah, I'm got print statements in the setUps at the moment
<stub> LibrarianSwiftGarbageCollectionTests inherits (LibrarianGarbageCollectionTestsBase, lp.TestCase)
<stub> LibrarianGarbageCollectionTestsBase has no base classes (apart from object)
<stub> lp.TestCase inherits (testTools.TestCase, fixtures.TestCaseWithFixtures)
<stub> Cute: http://paste.ubuntu.com/6518444/
<stub> test.py test_gc trims some tests, test.py --test=Swift can find them though. Neither get tests defined in the base class
<wgrant> It's probably to do with 2.7's discover support
<wgrant> In which case it won't affect full test runs
<stub> http://bazaar.launchpad.net/~stub/launchpad/swift-librarian/view/head:/lib/lp/services/librarianserver/tests/test_gc.py for anyone playing along at home
<stub> wgrant: I can land it and see what happens... just need to revert if the tests don't get run
<wgrant> Yeah, easy to check from the subunit :)
<wgrant> But I think it should be fine.
<wgrant_> stub: Are you looking at the GC test failures?
<stub> wgrant: Back from blinner, I'll look now
<wgrant> stub: Thanks.
<stub> One failed test, run twice. Maybe a trivial fix.
<stub> wgrant: Can I land http://paste.ubuntu.com/6519343/  with it?
<stub> That is how I can get the tests running locally. Certainly something crappy in test discovery in py2.7 or some test helper I have.
<wgrant> stub: I'd prefer not to have a workaround in that one file...
<wgrant> (to run them locally I just use '-t test_gc' to do pattern matching on the whole test name)
<wgrant> Rather than specifying a module, which will invoke 2.7's new discover logic.
<stub> Ok.
<stub> wgrant: testfix? http://paste.ubuntu.com/6519365/
<stub> oh, two redundant lines
<wgrant> stub: Are content_* used anywhere?
<stub> nuking
<wgrant> Yeah, that
<wgrant> Otherwise it looks fine :)
<stub> http://paste.ubuntu.com/6519371/
<stub> k
<stub> wgrant: Apart from large files and pulling the Swift creds from a config file rather than the environment, can you think of other stuff we need?
<wgrant> I don't think so.
<wgrant> Maybe?
<stub> I'll do the config file branch, then we can see what we trip over on staging I guess.
<wgrant> Yeah
<wgrant> Not quite sure how to fully test it there. Might want to inject a lot of files into the staging librarian, I suppose?
<stub> wgrant: Last time I checked I had about 250GB I could play with
<stub> wgrant: We need to confirm it serves files reliably (small and large), and that the disk-> swift tool works reliably in non-destructive mode.
<stub> So I guess rsync over a subtree, push it in, suck it back out from the Librarian.
<stub> Or just generate and upload some random content
<stub> But the first real test is that nothing acts any differently, since we haven't turned on the FF.
<wgrant> stub: Did you forget to land that with [testfix]?
<wgrant> It doesnt' seem to have made it in
<wgrant> stub: Yeah, that QA plan sounds relatively sane
<stub> Proposed commit message:
<stub> [testfix][r=stub][bug=1257636] Fix broken test_gc.py
<stub> Edit before sending? ([y]es, [n]o): Connection Timeout: disconnecting client after 300.0 seconds
<wgrant> Heh
<stub> attention fail ;)
<stub> The new house I'm moving too should have 1Mb/s uplink on Friday. Been stuck on 4Mb/512kb for too long.
<wgrant> stub: 20M/512K here :/
<wgrant> Australian HFC providers have a thing for 40:1...
#launchpad-dev 2013-12-05
<stub> utilities/js-deps -n LP_MODULES -s build/js/lp -x '-min.js' -o \
<stub>         build/js/lp/meta.js >/dev/null
<stub> Traceback (most recent call last):
<stub>   File "utilities/js-deps", line 4, in <module>
<stub>     from convoy.meta import main
<stub> ImportError: No module named convoy.meta
<stub> This seems to be why staging.launchpad.net is down (phew, not me)
<Spads> This is bad and you should feel bad.
<stub> I always feel bad.
<Spads> Jolly good.
<StevenK> Is python-convoy no longer installed then?
<stub> StevenK: It isn't in version.cfg or setup.py -- I'm just testing a branch
<StevenK> stub: It's a package, required by launchpad-dependencies
<stub> oic, so we need to update that
<StevenK> steven@lptests:~% apt-cache show launchpad-dependencies | grep Depends | cut -d, -f48
<StevenK>  python-convoy
#launchpad-dev 2013-12-06
<wgrant> stub: Could you poke me when you're around so we can finish off the librarian QA?
<stub> wgrant: pong. Around for a bit.
<wgrant> stub: Did you look any further into the staging header issue?
<wgrant> qas/DF are fine with the new code
<wgrant> (and I've tested gc on DF)
<stub> Not yet.
<stub> wgrant: Are the headers working on qas?
<wgrant> yes
<wgrant> I suspect arsenic
<stub> I guess it has to be a squid issue, yes
<stub> wgrant: So we known files are being served ok without the feature flag, you tested gc. I would be testing uploads except staging is asking me for a 2fa code.
 * stub wanders over to qas
<wgrant> stub: I ran a full end-to-end Soyuz test on the new non-swift code on DF
<wgrant> Though the largest file I tested was ~100M
<stub> That will be fine for testing the non-swift code paths.
<wgrant> Indeed.
<stub> So that can unblock the revision. I still need to setup and turn on the FF to test the Swift code paths.
<wgrant> Yeah, I mostly wanted to get the process-mail cronspam fix out before the weekend :)
<stub> wgrant: We could change the max segment size easily enough so we don't need to upload 15GB files for qa, but I guess we are also interested in how well Swift copes with the large uploads and downloads
<stub> (I've streamed the entire Launchpad DB basebackup from staging into as a test of another tool though)
<wgrant> SwiftWAL?
<stub> wgrant: Yes
<stub> I'll turn it on as soon as I've got a Precise staging
<stub> (I can run it using Launchpad's bin/py, but that seems a little weird for reliable WAL shipping)
<stub> wgrant: Do you need me for any unblocking? I'm not here today and need to head off soon.
<wgrant> stub: As long as you're comfortable with the librarian QA, I think that's it. Thanks
<stub> wgrant: I'm comfortable with the non-Swift code paths, yes :)
<stub> Email or call if anything explodes. I'll have my phone and a laptop while I hang around for a new ADSL line to go in.
<wgrant> :)
<lifeless> SwiftWAL, sounds fun
#launchpad-dev 2014-12-03
<rpadovani> o/ There is a way to have a json response from api online? On documentation there is written that response should be in json, but it's xml
<rpadovani> like https://api.launchpad.net/1.0/bugs/1
<mup> Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <patch> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice Productivity Suite:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid
<mup> by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by
<mup> shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Ubuntu:Fix Released by sabdfl> <Arch Linux:Confirmed> <Baltix:Invalid> <linux (Debian):In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
<wgrant> rpadovani: It respects your Accept header.
<wgrant> rpadovani: But it's overridable You can get JSON in a web browser by appending ?ws.accept=application/json to the URL.
<rpadovani> wgrant, thanks :-) I have a friend who wants to do an instant answer for DuckDuckGo and he needs the json document :-)
#launchpad-dev 2014-12-04
<ePierre> Hi there!
#launchpad-dev 2014-12-05
<rpadovani> wgrant, thanks for fixes to UI of lp released yesterday and today. Definitely better!
<wgrant> rpadovani: :)
<wgrant> Some more improvements are in the pipeline.
<rpadovani> \o/
<rpadovani> I definitely love that I finally right-click on top left links
<rpadovani> *can right-click
<wgrant> That worked in some browsers before.
<rpadovani> also, because now works on Ubuntu Touch Browser too
<wgrant> Yes, mobile webkit touch events were very problematic.
<wgrant> I haven't tested on the Touch browser, though I finally do have a device, but if anything else doesn't work please let me know.
<rpadovani> Sure! I like some LP features (bug tracker rocks, best I ever tried) but I think it's UI needs some improvement
<rpadovani> Keep up the good work!
<wgrant> That's putting it nicely :)
<wgrant> The UI is a bit bad.
<rpadovani> Yes, it's sad, because could be a very good competitor to GitHub - and it's opensource! But UI and Social things don't work
<wgrant> We were a lot more social than the other sites a few years ago, but then GitHub came along and did that much better.
<rpadovani> Uh, I take this opportunity to ask you about a feature: do you plan to add post commit hooks? They are so useful to deploy websites, and it's the only GitHub/Lab feature I really miss
<wgrant> We're looking at introducing webhooks next year, if that's what you mean.
<rpadovani> Oh, well, yes, I was just thinking to the use I do, but I mean webhooks. This is an awesome news, really! I think I'll read commits to trunk more often... Thanks for the news :-)
<wgrant> :)
<rpadovani> Do you know DuckDuckGo? I asked to a friend to implement support for launchpad bugs :-)
<rpadovani> https://cloud.githubusercontent.com/assets/8344987/5296484/ad0f46ec-7ba4-11e4-8268-209b85a82f3f.png
<rpadovani> and there is already a MR: https://github.com/duckduckgo/zeroclickinfo-spice/pull/1319
<wgrant> Nice.
<xnox> Ursinha: wgrant: infinity: cjwatson: as members of ~launchpad would you mind setting ~lazr-developers as the maintainer of launchpadlib project?
<xnox> or alternatively would you mind adding me to ~launchpad to make a launchpadlib release?
<xnox> (i'm guessing ~launchpad is actually important / too powerful team for me to be in)
<wgrant> ~launchpad is Canonical-only. I've siwtched launchpadlib's owner to ~lazr-developers.
<wgrant> I'll also try to remove ~launchpadlib-developers entirely.
#launchpad-dev 2014-12-06
<xnox> wgrant: \o/ merci beaucoup
<xnox> wgrant: ah, i wish launchpad would provide +sha256 on the downloadable files...
<xnox> maybe +sha1 as well, although most people have switched to sha256.
<wgrant> We store that, just need to render it.
<xnox> cool.
#launchpad-dev 2015-11-30
<cjwatson> wgrant: I should also point out that udev isn't a source package in anything newer than precise, and I think systemd diffs work fine.  But perhaps I should add a config option for undiffable source package names, and add cordova-cli to it?
<lifeless> cjwatson: this is the big diff problem?
<lifeless> cjwatson: wouldn't a resource limit of some sort be less maintenance?
<cjwatson> lifeless: This is in addition to such a thing.  See https://code.launchpad.net/~cjwatson/launchpad/limit-debdiff/+merge/278187, whose comments I'm following up on
<lifeless> k
<lifeless> cjwatson: commented there
<wgrant> cjwatson: Fair point.
<cjwatson> lifeless: Thanks, it occurred to me after the fact that an RLIMIT_FSIZE ulimit would be simple enough and useful.  I'll work out a reasonable value for that and add one when I get round to addressing William's comments.
<cjwatson> (I think that's the most useful measure - it's certainly the thing that directly causes problems first.)
<StevenK> cjwatson: Out of interest, instead of, or as well as the time limit?
<lifeless> belts + bracers  >> belts | bracers
<cjwatson> StevenK: Yeah, both.
<cjwatson> I mean why not.
<cjwatson> Both running out of disk space and starving the queue cause problems, so might as well act directly on both.
<dupingping> hi everybody.
<dupingping> I executed bzr branch lp:launchpad
<dupingping> How to launch a server for launchpad?
<dupingping> I already installed Ubuntu Server Trusty.
<wgrant> dupingping: https://dev.launchpad.net/Getting
<wgrant> What are you planning to do with Launchpad?
<dupingping> wgrant: I want to create a local server to create Ubuntu distro iso image automatically as launchpad.net
<wgrant> dupingping: Launchpad is a very large and complex application, probably excessive for your needs. Why do you need to run your own?
<dupingping> yes, I want to join in launchpad development.
<dupingping> wgrant: of course, I want to contribute for launchpad.
<wgrant> But you said you wanted to build Ubuntu ISOs.
<dupingping> To do it, I need to test it by myself.
<dupingping> yes, i said as that.
<wgrant> Anyway, the page I linked has instructions for getting a basic development instance up and running.
<wgrant> There are a few more steps after that to get ISO builds working.
<dupingping> oh, yes. thank you. let me try.
#launchpad-dev 2015-12-02
<dupingping> hi everyone.
<dupingping> I built a launchpad.dev server on my local.
<dupingping> And it shows me "Module zope.publisher.publish, line 132, in publish
<dupingping> result = publication.callObject(request, obj)
<dupingping> Module lp.services.webapp.servers, line 1508, in callObject
<dupingping> raise NotFound(self, '', request)
<dupingping> what should i do?
<wgrant> dupingping: Which URL are you accessing?
<wgrant> That can indicate that you're using an unrecognised domain.
<dupingping> yes, at the local lan, vm server.
<wgrant> Launchpad uses vhosts extensively, so you can't access it by IP address or the machine's hostname.
<wgrant> You need to use https://launchpad.dev/[...], or one of the recognised subdomains.
<wgrant> https://dev.launchpad.net/Running/RemoteAccess
<dupingping> oh, I did not use vhost. I installed it directly on my local pc.
<wgrant> The Launchpad application will only respond to domains that it knows about.
<wgrant> So you need to edit /etc/hosts (or a local DNS zone).
<dupingping> oh, yes, let me try now.
<wgrant> eg. I run LP in an LXC container, so in my host's /etc/hosts:
<wgrant> 10.0.3.45       launchpad.dev answers.launchpad.dev archive.launchpad.dev api.launchpad.dev bazaar.launchpad.dev bazaar-internal.launchpad.   dev blueprints.launchpad.dev bugs.launchpad.dev code.launchpad.dev feeds.launchpad.dev keyserver.launchpad.dev lists.launchpad.dev ppa.  launchpad.dev private-ppa.launchpad.dev testopenid.dev translations.launchpad.dev xmlrpc-private.launchpad.dev
<wgrant> xmlrpc.launchpad.dev
<dupingping> yes, It works as http://localhost:8085 in my PC.
<wgrant> utilities/rocketfuel-setup automatically configures /etc/hosts, if you used that script.
<dupingping> yes, i used it, rocketfuel-setup.
<wgrant> Does https://launchpad.dev/ work?
<dupingping> And how to register an account on that server?
<dupingping> yes, work.
<wgrant> The initial dev database has certain preconfigured accounts. You can log in as eg. admin@canonical.com for an admin account, no-priv@canonical.com for an unprivileged account, and various others that can be found in the "emailaddress" table.
<dupingping> yes, let me try.
<dupingping> oh, It shows me an error, I'll pastebinit soon.
<wgrant> Possibly an OpenID TLS cert issue, we'll see.
<blr> dupingping: there's also a script for generating new accounts/users in utilities/make-lp-user
<dupingping> blr, yes, let me try.
<dupingping> please look, http://paste.ubuntu.com/13613443
<wgrant> dupingping: Try going back to the homepage and logging in again.
<wgrant> I've seen that before on the very first session on a fresh DB, and then it works a second time.
<dupingping> wgrant: yes, let me try again.
<dupingping> wgrant: it's run on same PC but from another one. the launchpad.dev/+login page shows me You don't have permission to access /+login on this ...
<wgrant> dupingping: Edit the ACLs in /etc/apache2/sites-available/local-launchpad
<dupingping> wgrant: thank you, I did it. And I want to know how to build bootable iso image from many source packages?
<dupingping> please help me.
<dupingping> I just found launchpad-buildd script. I think that it's just a wrapper for debian livefs project.
<wgrant> There are many steps between where you are now and bootable images.
<wgrant> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally documents some of them.
<dupingping> yes, let me try, the steps. wgrant:
<wgrant> dupingping: But if you're just looking to build images, a full Launchpad really isn't the easiest way to do that.
<dupingping> wgrant: yes, And I think that i should build a local server same as launchpad.net to develop launchpad.
<wgrant> Right, if you want to develop Launchpad then that totally makes sense.
<wgrant> But I wouldn't necessarily start by building ISOs; that's a big chunk of complex infrastructure.
<dupingping> wgrant: So, please help me.
<wgrant> dupingping: If you want to develop Launchpad, ISO building is not a good first thing to work on. And if you just want to build ISOs, your own Launchpad is not a good way to do that.
<dupingping> wgrant: yes, but I could not understand how to run the launchpad.net fully.
<dupingping> And without fully understand, I could not join to develop launchpad.net
<dupingping> *develop* may contribute.
<wgrant> ISO building relies on all of the things described on HowToUseSoyuzLocally.
<dupingping> So i wanted to fully duplicate the launchpad.net to my local PC.
<wgrant> Understand all of that first, and then you can eventually move up to building ISOs.
<dupingping> wgrant: yes.
<dupingping> wgrant: yes.
<dupingping> wgrant:  what is the source build project of the launchpad.net?
<dupingping> e.g. launchpad-buildd build iso image from binary packages.
<dupingping> I mean that build binary packages steps.
<dupingping> from source packages.
<dupingping> wgrant: let's guess about following point.
<dupingping> If i modified libc package, so many packages needs to be rebuilt.
<dupingping> then how can i get the packages list to be rebuilt?
<dupingping> to get distro iso image.
<dupingping> wgrant: make sense?
<wgrant> dupingping: launchpad-buildd builds several different things, including binary packages and live images.
<dupingping> wgrant: yes. then it detects source depends packages?
<wgrant> dupingping: A glibc change doesn't require the entire world to be rebuilt.
<dupingping> wgrant: yes, right. it's just an example. If i modify a frequently used function's parameter.
<dupingping> how can i detect source packages that use it?
<wgrant> Launchpad has no facilities for automatically doing that.
<wgrant> You'd use external tools to analyse the archive.
<dupingping> external tools?
<dupingping> I'm sure i can detect dependency tree of binary packages. Is there a tool for source packages?
<wgrant> There are no fundamental differences between the two.
<dupingping> So is there a tool to do it?
<wgrant> It depends on exactly what you're going to do, but regardless it's not within Launchpad's remit.
<dupingping> wgrant: yes, i see.
<cjwatson> wgrant: Could you glance over my post-review changes to https://code.launchpad.net/~cjwatson/launchpad/limit-debdiff/+merge/278187 ?
<wgrant> cjwatson: I assume debdiff doesn't do anything silly like uncompressing the tarball onto disk before extracting it?
<wgrant> >1GiB single files are unlikely, but uncompressed tarballs are plausible.
<cjwatson> wgrant: It may call dpkg-source, which I don't *think* does that, but you never know.  Maybe I should bump that to 10GiB; the main purpose is just to defend against running haetae out of disk.
<cjwatson> wgrant: There were 22 diffs in dogfood's DB over 1GiB.  They must all have taken quite some time to generate (I didn't check).
 * cjwatson bumps that
#launchpad-dev 2015-12-03
<tsimonq2> https://bugs.launchpad.net/launchpad/+bug/779915 has caused me a lot of pain, so I was wondering if either someone in here could fix it, or how easy it would be to fix
<mup> Bug #779915: Messages can take days to appear in the MhonArc archive <feature> <mailing-lists> <ml-archive-sucks> <Launchpad itself:Triaged> <https://launchpad.net/bugs/779915>
<maozhou> There is a unauthorized error after running script of ''remove-package", how to fix it? (http://img.hoop8.com/attachments/1512/6381911610461.png)
<xnox> maozhou, can you open a question, or bug? with more details. text is prefered, not screenshots. Can you go and do things via the web-ui?
<xnox> e.g. cruitial info is missing - e.g. what is being removed, and from which archive.
<cjwatson> Not a bug, please.
<cjwatson> But a question would be fine.  And yes, please paste text rather than making us load images.
<xnox> and listen to an actual lp developer ^ rather than me =)
<cjwatson> You probably just need to get the owner of the relevant archive to grant you queue admin permissions.
<cjwatson> Or be in the team that owns the relevant archive.
<maozhou> ok, but how to do it via the web-ui?
<xnox> there is webui for ppas, but not distributions proper... so depending on what you are doing, there might not be web-ui. i think your question is way beyond my knoweledge, and you are better off chatting with cjwatson.
<cjwatson> Not everything is doable via the web UI, especially rarely used operations.
<cjwatson> Or administrative operations.
<maozhou> cjwatson: I have run "edit-acl" in directory of ubuntu-archive-tools to grant the admin permissions,isn't it right ?  how to grant the admin permissions?
<cjwatson> that would be usual, yes, but I can't debug your problem from here with so little information.
<cjwatson> you need to explain exactly what you've done, what users are involved, etc., preferably in text not in screenshots.
<cjwatson> and really, with your own LP instance it needs to be your responsibility to debug this kind of thing.
<cjwatson> we can't access the instance so it is difficult for us to debug it.
<maozhou> Ok, I know ,thank you
<xnox> cjwatson, well done on the ssh-2 support! =)
<cjwatson> thanks :)
<cjwatson> a relief to have that off my guilt lis
<cjwatson> t
#launchpad-dev 2016-12-06
<daker> cjwatson: hi, any chance you can clean up those spam questions https://answers.launchpad.net/ubuntu ?
<cjwatson> daker: am off work until Thursday
#launchpad-dev 2016-12-09
<cjwatson> I ran https://github.com/erikbern/git-of-theseus on Launchpad last night: http://people.canonical.com/~cjwatson/git-of-theseus/launchpad/
