#launchpad-dev 2009-09-14
<thumper> :)
<thumper> I shelved my filter machine
<thumper> it tastes a bit funny IMO
<mwhudson> oh, i don't use a machine
<thumper> mwhudson: what do you use to filter then?
<mwhudson> a filter cone
<mwhudson> this sort of thing: http://www.hrhiggins.co.uk/accessories/coffee/plastic_filter_cones
<mwhudson> (they are utter bastards to buy)
 * mwhudson votes for writing all wiki pages in latex
<jml> heh
<jml> thumper, want to catch up some time today?
<dhillon-v10> hi all
<thumper> jml: might be ackward today
<jml> thumper, ok. later this week then.
<jml> (next week, scheduling calls will be _much_ harder)
<thumper> jml: definitly
<thumper> my irc client needs check spelling as you type
<jml> heh
<mwhudson> jml: the vals thing in ec2test is horrible :(
<jml> mwhudson, yes.
<mwhudson> i think i'm ok with having perform() do environment-based interpolation
<mwhudson> that sort of thing has a tradition behind it after all
<mwhudson> jml: so you reviewed libraryize-ec2test
<jml> mwhudson, I believe so.
<mwhudson> jml: then i made some more changes
<mwhudson> jml: *then* i fixed it so it works
<jml> mwhudson, heh
<jml> mwhudson, would you like to give me an interdiff to review?
<mwhudson> jml: which is possibly backwards, but can i get you to look at the changes from libraryize-ec2test to ec2test-refactor-2 and then i'll land the latter branch?
<mwhudson> jml: yeah
<mwhudson> jml: https://pastebin.canonical.com/22056/
<jml> mwhudson, use a free pastebin :P
<mwhudson> jml: the full branch is at bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/ec2test-refactor-2 if you want to look at the result rather than the changes
<mwhudson> jml: oops
<jml> http://paste.ubuntu.com/270595/
<mwhudson> jml: thanks
<jml> mwhudson, sorry, I thought I'd deal with all of my work-related email first. Now I'm all over your diff.
<mwhudson> jml: no worries
<jml> ooh, a connection object
<jml> what a lovely idea
<jml> mwhudson, is ec2test going to end up looking an awful lot like a twisted program?
<mwhudson> jml: maybe
<mwhudson> jml: too early to tell, probably
<jml> mwhudson, why did you change the _pythonpath import to manual sys.path mangling?
<mwhudson> jml: because boto doesn't work with python2.4
<mwhudson> and _pythonpath _sets_ sys.path, it doesn't modify it
<mwhudson> so importing dynamically loaded modules doesn't work
<jml> sucks!
<mwhudson> jml: launchpad should work on 2.5!!
<mwhudson> and nearly does now, thanks maxb
<jml> mwhudson, only a couple of other comments on the diff
<jml> mwhudson, I don't know how I feel about user_p as a variable name
<jml> it makes me think it's a predicate function :)
<mwhudson> jml: heretic lisper!
<jml> mwhudson, and I don't know how to spell 'set up' in function names: set_up or setup
<mwhudson> jml: i think user_connection.perform is a bit too long
<mwhudson> maybe user_perform is ok
<mwhudson> jml: should probably be 'set up'
<jml> even as_user
<jml> mwhudson, other than those things, I'm happy with the branch. Definite improvement.
<mwhudson> jml: ok, thanks
<jml> mwhudson, do you know if maxb's timing patch landed?
<jml> if you don't, I'll find out myself
<mwhudson> jml: i have this vague feeling it did, not sure though
* bac changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 2 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html
<jml> mwhudson, Launchpad says it's moved.
<jml> merged, rather.
<mwhudson> jml: it's probably right
 * mwhudson dogfoods his ec2 branch and wanders off for lunch
 * ajmitch looks for an easy bug to chew on
<jml> ajmitch, the 'trivial' tag should be a good starting point.
<ajmitch> yeah, that's what I'm looking at
<jml> ajmitch, cool.
<jml> ajmitch, let me know if you need a hand with anything.
<ajmitch> oh I will :)
<ajmitch> I have LP running on karmic here at least, started looking at bug 238588, but saw that there is X-Launchpad-Message-Rationale being added
<mup> Bug #238588: "New code import" messages lack an X-Launchpad-Message-Rationale <email> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/238588>
<ubot3> Malone bug 238588 in launchpad-code ""New code import" messages lack an X-Launchpad-Message-Rationale" [Medium,Triaged] https://launchpad.net/bugs/238588
<mup> Bug #238588: "New code import" messages lack an X-Launchpad-Message-Rationale <email> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/238588>
<mup> Bug #238588: "New code import" messages lack an X-Launchpad-Message-Rationale <email> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/238588>
<ajmitch> so I now need to try & reproduce it on a local setup
 * ajmitch should just pick some simple UI bugs
<jml> hmm.
<jml> spm, do you know who maintains mup and/or ubot3?
<jml> spm, because I think one of them should die
 * ajmitch must agree, given the spam above
<mwhudson> at least ubot3 seems to have repetition protection
<mwhudson> otherwise there would be no end to it
<jml> yeah.
<jml> ajmitch, I'd definitely recommend a UI bug to start with.
<jml> ajmitch, the smaller the bug, the better -- especially for your first patch.
<ajmitch> less chance of doing things completely wrong
<jml> ajmitch, that, but also it's a good way of learning all the boring things about Launchpad hacking :)
<jml> ajmitch, i.e. it's a good way of separating learning about LP process from the LP code base.
<jml> on a completely unrelated note
<jml> where the hell is google gears for 64 bit linux?
 * ajmitch just gets a popup in firefox at random intervals that it can't be installed
<jml> yeah.
<maxb> ubot3: owner
<ubot3> This bot is owned by jussi01 - Questions about ubottu should be asked in #ubuntu-bots
<maxb> jml: ^
<maxb> (and yes I am awake in complete defiance of my physical timezone)
<jml> maxb, thanks.
<maxb> Quick opinion poll:
<maxb> lambda self: self.foo
<maxb> or
<maxb> from operator import attrgetter; attrgetter('foo')
<maxb> ?
<wgrant> maxb: I believe the style guide says the latter
<wgrant> Although I probably prefer the former.
<wgrant> https://dev.launchpad.net/PythonStyleGuide, section 13.
<maxb> oh
<maxb> the style guide is so big :-/
<wgrant> Ja.
<wgrant> Aren't you violating the "no coding after 3am" guideline?
<maxb> I slept, then I woke up at a nonsense time and didn't feel like falling asleep again straight away :-)
<stub> I like lambda. I forget operator exists so never use it ;)
<jml> maxb, lambda is fine.
<wgrant> jml: The style guide needs fixing?
<jml> wgrant, yes, it does.
<wgrant> :(
<jml> wgrant, I agree.
<jml> tbh, I think it over-legislates.
<jml> stub, attrgetter & itemgetter ought to be builtins, imnsho
<maxb> My disagreement with attrgetter is that IMO you should never write code in strings if you can possibly avoid it
<maxb> hmm, merge proposals really need an "update to latest branch revision in-place" button
<jml> maxb, although I agree with the principle...
<jml> maxb, since Python lacks a separate type for symbols, and thus uses strings, I think it's perfectly ok to use strings for attribute access
<jml> maxb, and although dynamic attribute access is over-used by some & can be confusing, I think forbidding it entirely is unnecessarily restrictive.
 * maxb wonders why superseding a merge proposal blocks the ability to further comment on it
<jml> maxb, there were reasons.
<jml> I'm reasonably confident that the whole workflow around updating diffs in being changed for the better.
<jml> but maybe thumper can say one way or the other.
<spm> jml: I do love how you always manage to ping me *just* after I go afk for eg lunch :-)
<jml> spm, it's rarely ever urgent :)
<jml> actually, I'm just about to go out to lunch.
<spm> jml: no, I'm not sure who maintains them. There was some noise around IS looking after same, but I'm unaware of the current status on that.
<jml> spm, I've asked jussi01 on #ubuntu-bots (who owns ubot3) to kill off ubot3
<spm> cool, ta.
<jml> spm, if they don't respond, I humbly suggest that we kickban ubot3 and send a polite email explaining why.
<mwhudson> booooooooooooot faster ec2!
<jml> maxb, I simply have to eat now. I'll review your branch when I get back from lunch.
<mwhudson> i can review it now, while i wait for ec2 instances to do stuff
<mwhudson> huh, property(attrgetter(attrname)) is a trick that hadn't occurred to me, i have to say
<maxb> That wizardry came from allenap
<jml> maxb, replied
<jml> I was just thinking, it'd be nice to use that trick to make an 'alias' helper that took the old attribute name and an optional readonly boolean parameter.
<maxb> jml: replied
<mwhudson> gosh our test suite is really slow
<jml> yeah, we should do something about that.
<mwhudson> jml: if we can make ec2test not rely on being able to ssh to devpad, it can be a bunch simpler
<mwhudson> jml: luckily you did something about that recently :)
<jml> mwhudson, because all the agent stuff goes away?
<mwhudson> jml: no, not that (we still need to ssh to launchpad) but some of the ssh config complexity
<jml> mwhudson, ahh, I see.
<mwhudson> (no need to dig out the proxycommand you and i use to connect through chinstrap)
<jml> I guess ec2test needs to use SSH to get branches still?
<mwhudson> yeah
<mwhudson> we could update most of them over http i guess
<maxb> ah, the old ProxyCommand ssh <somewhere> nc <somewhereelse> 22 trick?
<mwhudson> which would let us --headless earlier, but would be a bit slower overall
<mwhudson> maxb: yep
<mwhudson> btw
<mwhudson> does anyone know why i don't have a /usr/lib/jvm/default-java file?
<maxb> apt-get install default-jdk ?
<mwhudson> it looks like i have several jdk's installed
<mwhudson> maxb: hm, that's doing something indeed
<mwhudson> jml, thumper: do you have any branches that need ec2testing right now?
<mwhudson> (or anyone else internal, but you should all be asleep :)
<maxb> default-jdk is one of those packages which only really exists to serve as a build-dep
<maxb> It's so that the distro-wide choice of OpenJDK/GCJ/Whatever can be made in a single place
<jml> mwhudson, looking...
<jml> mwhudson, nope
<mwhudson> maxb: right, but i had openjdk, gcj and whatever installed already
<mwhudson> maxb: i was expecting it to be more like the alternatives stuff i guess
<mwhudson> maxb, wgrant: either of you have branches that need testing?
<maxb> sorry, you've landed them all :-)
 * mwhudson has a shiny new ec2test image
<maxb> though actually I did have a fairly mechanical change I was planning on doing...
 * maxb wields grep
<mwhudson> jml: want to look at another ec2test knocking-about diff? http://pastebin.ubuntu.com/270655/
<mwhudson> jml: it's still fairly horrible, but it allows one-step updating of the ec2test image
<jml> mwhudson, wuu
 * mwhudson runs "time ./utilities/ec2test.py --headless" for that branch
<jml> mwhudson, umm, could you please walk me through the changes?
<mwhudson> jml: so one strand is ripping stuff out of testrunner (particularly EC2TestRunner.__init__) so that having a testrunner isn't vital to doing anything at all
<mwhudson> jml: another strand is the stuff to add the bundling
<mwhudson> and there are the inevitable driveby cleanups
<mwhudson> jml: hang on, i'll annotate a diff
<jml> mwhudson, thanks.
<mwhudson> oh heh heh, i think i broke --headless
<mwhudson> jml: http://pastebin.ubuntu.com/270659/
<maxb> So, I have another branch which you could ec2test if you like...except launchpad is still falsely claiming it hasn't been pushed to yet :-/
<maxb> and I'm not getting the "Launchpad is processing new changes to this branch" banner on it either
<mwhudson> maxb: new branches never say "processing changes"
<mwhudson> (which is a bug)
<maxb> How long do I wait before deciding that something is actually broken?
<maxb> https://code.edge.launchpad.net/~maxb/launchpad/debuild--no-conf ftr
<maxb> hmm, I deleted the MP I created and it changed from "has not been pushed to" to "has not been scanned"
<mwhudson> hmm looks like the scanner is stuck
<mwhudson> spm: hi
<mwhudson> maxb: that's interesting
<mwhudson> but maybe just a coincidence
<spm> mwhudson: heyo; stuck scanner? looking.
<maxb> it may have just unstuck
<mwhudson> seems like it
<mwhudson> spm: can you sync the puller logs to devpad?
<spm> sure
<mwhudson> tia
 * mwhudson watches ec2test.py --headless do stuff
<mwhudson> jml: wow, bug #420198 is next
<ubot3> Malone bug 420198 in launchpad-foundations "ec2test --headless takes way too long to detach" [High,Triaged] https://launchpad.net/bugs/420198
<mup> Bug #420198: ec2test --headless takes way too long to detach <build-infrastructure> <Launchpad Foundations:Triaged by mwhudson> <https://launchpad.net/bugs/420198>
<mup> Bug #420198: ec2test --headless takes way too long to detach <build-infrastructure> <Launchpad Foundations:Triaged by mwhudson> <https://launchpad.net/bugs/420198>
<mup> Bug #420198: ec2test --headless takes way too long to detach <build-infrastructure> <Launchpad Foundations:Triaged by mwhudson> <https://launchpad.net/bugs/420198>
<jml> mwhudson, nice.
<jml> spm, do you have ops?
<spm> mup really needs a "30 sec delay" mindset on reprint the same bug id....
<spm> jml:  "ops"?
<spm> mwhudson: puller synced and bzrsyncd for good measure.
<jml> spm, IRC operator privileges
<mwhudson> fortunately mup is written in a programming language we all know really well
<mwhudson> (warning: may be a lie)
<mwhudson> spm: thanks
<jml> I do :)
<spm> jml: no. and given I've been irc'ing for ~ 15 months, I wouldn't trust me :-)
<mwhudson> jml: fwiw, i think "irc op" is quite different from "channel operator"
<jml> my mistake :)
<ajmitch> farewell, ubot3
<maxb> mwhudson: If you need something to ec2test, here's a (literally) one-liner change https://code.edge.launchpad.net/~maxb/launchpad/debuild--no-conf/+merge/11680
<mwhudson> maxb: ta
<jml> ajmitch, heh.
<mwhudson> it'll be back, when the banlist decays over time, as they always seem to do
<ajmitch> easiest way is to just nag the owner
<jml> ajmitch, this has been done :)
<ajmitch> I'm glad :)
<jml> mwhudson, ok, my attention is now returned to you
<mwhudson> jml: hurrah
<mwhudson> i think my stock of attention for today has almost run out ...
<jml> mwhudson, http://pastebin.ubuntu.com/270677/
<jml> mwhudson, here's the quick version:
<jml> mwhudson, yay
<jml> mwhudson, did you think of making make_instance a classmethod on ec2instance?
<stub> And coffee just doesn't work like it used too. Now if I drink too much coffee I'm wired but can't pay attention to anything.
<jml> mwhudson, demo_networks should be split out, save it for a separate branch. I know how it works, so I can happily help you there.
<jml> mwhudson, it's a shame 'credentials' has to be a public attribute on account
<mwhudson> <jml> mwhudson, did you think of making make_instance a classmethod on ec2instance?
<mwhudson> no, that's probably a good idea
<mwhudson> <jml> mwhudson, it's a shame 'credentials' has to be a public attribute on account
<mwhudson> is it?
<mwhudson> an EC2Credentials is a slightly strange thing, really
<jml> yes, it is.
<mwhudson> <jml> mwhudson, demo_networks should be split out, save it for a separate branch. I know how it works, so I can happily help you there.
<mwhudson> hooray
<jml> mwhudson, well, the only usage of the .credentials attribute is in bundle(), and it violates the Law of Demeter. I'm just worried (perhaps overly so) about tying this stuff together too much.
<jml> mwhudson, and one usage + lots of dots trips a flag.
<jml> mwhudson, but it's not a big deal.
<mwhudson> jml: yeah, fair point
 * mwhudson restructures a bit
<mwhudson> jml: interdiff
<mwhudson> http://pastebin.ubuntu.com/270681/
<jml> mwhudson, wonderful! :)
<mwhudson> jml: thanks
<jml> mwhudson, could you please add a docstring to make()?
<mwhudson> jml: i should probably do a read through the diff adding/editing docstrings
<mwhudson> jml: so sure
<jml> mwhudson, sweet.
<jml> mwhudson, btw, I have a note here to talk to you about pycon talk ideas
<mwhudson> jml: ok
<jml> mwhudson, but I don't really have that kind of energy right now.
<mwhudson> jml: heh, me neither
<mwhudson> jml: tomorrow, when the caffeine is still fresh in our veins?
<jml> mwhudson, sounds good :)
<mwhudson> jml: some docstrings to read: http://pastebin.ubuntu.com/270690/
<jml> mwhudson, 'demo_networks' is a list of network strings (e.g. "192.168.1.0/24") and IP addresses
<jml> mwhudson, it specifies who is allowed to connect to the server
<jml> mwhudson, but also, if it's set at all, then tests aren't run and some other stuff is enabled/disabled.
<mwhudson> jml: i.e. "represents a bunch of crack"
<mwhudson> jml: i think i'd almost write "???" in the docstrings than explain the current truth
<mwhudson> (and fix the current truth tomorrow)
<jml> mwhudson, fair enough. :)
<jml> mwhudson, just like _1984_!
<jml> mwhudson, it would be nice to have a little more explanation as to what make() does (or rather, how it's different from the constructor)
 * jml looks over the code to make a suggestion.
<mwhudson> perhaps there isn't much difference
<jml> hmm, yeah.
<jml> mwhudson, I'm happy to leave the current docstring as is.
<jml> maybe future code iterations will make the distinction clearer.
<jml> mwhudson, r=jml
<mwhudson> jml: awesome, thanks
<jml> mwhudson, no, thank you.
 * mwhudson is done for the day
<jml> mwhudson, g'night.
<beuno> good morning all
<beuno> noodles775!
<noodles775> Hi beuno !
<beuno> noodles775, how are things?
<noodles775> beuno: ok - we just landed the the ppa-index re-design at the end of last week... still some tweaks to be done, but was good to get it landed. How are you going?
<beuno> noodles775, I saw you guys won the race  ;)
<beuno> noodles775, things are great. Had a fantastic vacation
<beuno> very relaxing
<noodles775> beuno: Great to hear :) I hope it didn't take too long to get to the relaxed state :)
<beuno> noodles775, it took a day or two to really disconnect, but after that it was a smooth ride
<noodles775> Great!
<jml> so, is soyuz now turning its attention to blueprints templates?
<beuno> noodles775, did you manage to get your hand on the padding issues?
<noodles775> jml: we're planning to do blueprint templates along with other high-priority bugs.
<jml> noodles775, awesome :)
<noodles775> beuno: nope - I had to focus on the ppa-index last week. I did do a few flybys that I needed for the ppa-index, but I'll look for the general padding bugs now (or do you have a list?)
<beuno> noodles775, I don't have a list of bugs, not sure if they where filed
 * beuno looks through bugs
<noodles775> beuno: I know jtv filed one general one, but am not aware of others.
<beuno> noodles775, the main things I see is the breadcrumbs need more bottom padding, and the footer needs top padding
<beuno> I'll play around with it and see if I can provide a branch (or a patch, my rf is busted)
<noodles775> beuno: I did already add more padding to the bottom of breadcrumbs (well, margin actually) - but perhaps not enough?
 * beuno ponders
<beuno> noodles775, https://edge.launchpad.net/~openshot.developers/+archive/ppa
<noodles775> beuno: that's an exception - the editable description has negative margin :/
<beuno> I think it's a combination of the description text being small, and having an icon the the breadcrumbs
<noodles775> Hmm... although it's the same as https://edge.launchpad.net/builders/palmer
<beuno> I'm starting to think we don't want icons in the breadcrumbs
<beuno> and maybe, just maybe, need to be a smaller font
<noodles775> Yeah, I'd agree there too - icons seem to make the breadcrumbs a bit too noisy...
<beuno> I will file a bug
<beuno> I need to get back on track with my karma
<noodles775> heh
<beuno> noodles775, this page's header section is missing... something: https://edge.launchpad.net/ubuntu/+ppas
<noodles775> beuno: yes, it might be related to barry's landing which modified the way headings work - see the email. We all need to go through and re-adjust things a bit.
<beuno> noodles775, known issue then, great
<beuno> anyone know what could be causing this error?  http://paste.ubuntu.com/270724/
<jml> beuno, no, I don't. how do you get it?
<beuno> jml, "make"
<beuno> (I'm on karmic)
<jml> beuno, so am I.
<jml> beuno, are you up to date with dependencies, sourcecode and download-cache?
<beuno> jml, yes, running rf-get
<jml> beuno, and launchpad-developer-dependencies is up to date?
<beuno> jml, I'll look, but what does that have to do with it?
<beuno> ah, you mean the package
<beuno> yes
<beuno> actually...
<beuno> no
<beuno> argh
<beuno> updates are fun
<beuno> installing 290mb of deps (again?)
<beuno> thanks
<jml> beuno, np
<jml> beuno, what does 'bzr revno sourcecode/pygpgme' say?
 * beuno checks
<adeuring> good morning
<beuno> jml, 48
<al-maisan> moin abel
<jml> beuno, and no local changes? (cd sourcecode/pygpgme; bzr st)
<beuno> jml, none
<jml> beuno, thanks.
<jml> beuno, let me know if it doesn't work after the upgrade -- it does work for me, even after a make clean.
<beuno> jml, it's installing them already (560kb/sec!), I'll know in a minute
<mwhudson> er, that's a strange error
<beuno> jml, that fixed it
<jml> beuno, cool.
<beuno> jml, thank you
<mwhudson> maxb: hi
<mwhudson> maxb: lp:~maxb/launchpad/py2.5-unittest-compatibility failed tests
<mwhudson> lp.codehosting.puller.tests.test_scheduler fails to import
<beuno> jml, FYI, the ohloh thing got kicked off again when I used devel instead of db-devel. *no* idea why that worked and the other didn't
<beuno> s/db-devel/db-stable
<beuno> maybe someone needs some reconciling?
<jml> beuno, I was about to suggest that.
<jml> beuno, looks like it'll still be a week or so before the listing is processed.
<beuno> jml, yeah, I've been following it fairly closely
<beuno> my guess is weeks
<beuno> it seems to be doing a few thousand commits per day
<beuno> no idea why it goes through all the commits to count number of lines
<beuno> but maybe they do more than that
<jml> well, they are charting number of lines over time
<jml> my hunch is that if they asked the bazaar ML, they'd be able to make the whole thing a lot faster.
<didrocks> jml: hey o/
<jml> didrocks, hello :)
<didrocks> jml: enjoying Australia? :)
<jml> didrocks, yes :)
<wgrant> He's abandoning us soon :(
 * thumper waves at beuno
<beuno> thumper!
<beuno> hi
<didrocks> jml: I tried to setup launchpad on Friday evening and run into troubles. Apparently, nobody was there to have a clue: http://paste.ubuntu.com/269395/ (on up to date jaunty and karmic box). I'm a little bit stuck :)
<beuno> thumper, how are things?
<wgrant> didrocks: What does 'rocketfuel-get' say?
<thumper> beuno: somewhat frantic
<beuno> thumper, 3.0 blues?
<thumper> beuno: kinda
<didrocks> wgrant: unfortunately, I'm at work now and I don't have an available box. I can try to launch this this evening
<thumper> beuno: I'm going to tackle the title and breadcrumb issues for branch pages this week
<beuno> thumper, cool, I was noticing that headings are wonky now. How's the big redesigns going?
<wgrant> beuno: The root context header looks very boring now. Who stole all the colours?
<thumper> beuno: too slowly
<jml> didrocks, I think wgrant is on the right track, fwiw.
<beuno> thumper, :/
<jml> didrocks, give rocketfuel-get a go when you get home
<beuno> wgrant, do you think people really link them to applications?
<beuno> my experience is no
<noodles775> wgrant: I think the h1 heading above the breadcrumbs is the color-coded one?
<wgrant> beuno: Perhaps not, but they made it a bit less bland.
<wgrant> noodles775: I meant the app tabs, actually.
<noodles775> Ah.
<wgrant> Is there a bug about locationless <h1>s blocking access to the logout control?
<maxb> mwhudson: oh, weird :-(. I'll poke at it at my lunchtime and see what I can do
<beuno> wgrant, the original mockups had the colors, but the agreement was the the colors really don't mean anything
<didrocks> jml, wgrant: ok, thanks, I'll keep you posted :)
<beuno> so it was just noise
<beuno> intellectronica, around yet?
<wgrant> beuno: Pretty noise.
<mwhudson> maxb: i forwarded you the mail
<intellectronica> hi beuno
<beuno> intellectronica, hi!  how's it going?
<intellectronica> beuno: good good. had a nice holiday?
<beuno> intellectronica, best ever
<intellectronica> lovely
<mwhudson> maxb: your other branch passed though, the --no-conf one
<mwhudson> i guess that means my new image works
<mwhudson> for me at least
<maxb> Well if that one failed, I would have been really annoyed :-)
<mwhudson> anyone here have a branch they want to ec2test?
<beuno> intellectronica, I see the bugtask table is now fully ajaxified. Any reason why it can still be expanded?
<intellectronica> beuno: it's still the only way to add a comment and change metadata in one action. until we fix it so that we collapse them after the fact, it seems people still want to be able to do that
<mwhudson> nm
<noodles775> mwhudson: I will in a while (40mins maybe), if you want to email me new instructions to try.
<beuno> intellectronica, interesting...   will that feature make it to 3.0?
<intellectronica> beuno: probably not
 * beuno hmmms
<mrevell> Morning
<deryck> Morning, all.
<beuno> hi deryck
<beuno> hi mrevell
<mrevell> hey beuno
 * beuno waves at barry 
 * barry waves at beuno! 
<barry> beuno: how do like them new page titles? :)
<beuno> barry, they are a dream come true. Literally.
<barry> beuno: phew!  that was a helluva branch.  you might imagine with us printing browser.title everywhere, like every pagetest broke ;)
<beuno> barry, ay, that sounds painful
<beuno> thanks for getting it in, it was a critical change for 3.0
<barry> beuno: only until 0330 saturday morning :)
<barry> beuno: no worries man, it was actually fun!
<danilos> maxb, btw, thanks for all the work in getting LP to run on karmic: I just got a new laptop over the weekend and I ran into no problems at all (I've seen ~12 test failures in full 'make check', but that might be related to python-svn stuff, since they were all in codehosting; didn't investigate further)
<maxb> danilos: Nice :-). Try adding ppa:maxb/launchpad and upgrading
<maxb> There are updated packages there pending syncing to the launchpad ppa
<danilos> maxb, yeah, seen the email on the list, I'll try that later (got a few urgent things to fix first :)
<jtv> abentley, you available for a pre-imp call?
<abentley> jtv: I'd rather wait 20 minutes until I'm on duty.
<jtv> abentley: no worries
<beuno> sinzui, when you awaken, could you let me know if you're going to work on bug 429353?
<mup> Bug #429353: Move edge message to the footer, allow people to stop redirection <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/429353>
<sinzui> beuno: It is at the bottom of my list
<sinzui> beuno: I still have 38 pages to land in 4 days
 * sinzui 15 ready for review
<beuno> sinzui, so you're saying that noodles775, that did a fantastic job in soyuz, should do it?   :)
<beuno> hi, btw
<bigjools> hands off my staff!
<sinzui> beuno: anyone who is not on my team
<beuno> bigjools, it should be a 10 minute branch
<beuno> 15 tops
<bigjools> lol
<bigjools> last time you said that it took him 4 days ;)
<sinzui> soyuz is done
<sinzui> code has 3 pages to land + 3 answers pages
<sinzui> bugs has 7 pages
 * beuno stares at gary_poster 
<bigjools> he can potentially do it tomorrow or day after, if someone fixes bug 423105 :)
<mup> Bug #423105: Duplicate download icons in many places <Launchpad itself:Confirmed> <https://launchpad.net/bugs/423105>
<beuno> bigjools, I will fix that bug
<bigjools> ah good man
<beuno> if noodles775 fixes 429353
<beuno> :)
<gary_poster> beuno, uh?
<gary_poster> and hi :-)
<beuno> gary_poster, I was about to nag you about a foundations bug, but I think I've managed to convince bigjools
<gary_poster> heh, cool :-)
<beuno> I think he's talking to Michael in the background
<beuno> trying to convince him that this time it won't be so bad  :)
<bigjools> beuno owes me so many favours!
<beuno> he does
<gary_poster> :-)
<bigjools> beuno: so seriously, there's no such thing as a ten minute branch, but that looks like a couple of hours work so it's fine
<beuno> bigjools, yeah, I know. I'm not sure how much work it is, tbh
<beuno> it involves config files, among other things I think
<beuno> I tried to do it myself, but once I spend 30 minutes going around in circles, I give up and file a bug
<bigjools> beuno: can you do a quick investigation on it then?  it would be helpful to add that info to the bug
<bigjools> ok perhaps sinzui then
<beuno> bigjools, any competent lp developer should be able to find all the moving parts quickly
<beuno> I'm not very familiar with the configs aspect of it
<noodles775> beuno, bigjools
<noodles775> beuno, bigjools: that should be fine... I had to play/test config stuff to get the site_message updated in the previous branch.
<beuno> match made in heaven
<beuno> I'm fixing the download icon bug right now
<noodles775> beuno, bigjools: although I'm not sure about the redirection issue - did you look into that beuno?
<beuno> noodles775, it's a simple javascript call
<bigjools> moving the section to the bottom will be easy
<noodles775> Great.
<beuno> it's available on the home page to see it working
<bigjools> then add the stuff from the front page I guess
<noodles775> bigjools: yeah, it's easy now because it's part of the template - rather than a string in the method of IHierarchy :)
<bigjools> noodles775: I wonder who fixed that!
<BjornT> barry: i think you mentioned that running a specific test layer (e.g. MailmanLayer) isn't possible any more. did you file a bug for it?
<maxb> Whilst you're at it, -s seems to be being ignored too
<BjornT> maxb: yes, it's a similar issue. the problem is that bin/test specifies some default options, that you can't remove
<barry> BjornT: not yet
<barry> BjornT: but i will
<BjornT> barry: cool. do you intend to fix it as well? :) i know what the problem is (see my comment above)
<barry> BjornT: if you comment on the bug, i'll fix it :)
<gary_poster> barry: hiya.  I rearranged some things and lost my bookmarks to the old, old LP wiki.  I was going to try to make at least a tiny bit of progress on migrating the reviewer wiki bits.  What is the url of the ancient LP wiki again, do you remember?
<BjornT> barry: perfect :)
<barry> gary_poster: which one was launchpad.canonical.com? :)
<gary_poster> barry: the one I wanted!  Thanks :-)
<barry> phew! :)
<barry> BjornT: bug 429375 feel free to assign it to me after commenting
<mup> Bug #429375: bin/test --layer=MailmanLayer no longer works <Launchpad itself:New> <https://launchpad.net/bugs/429375>
<BjornT> barry: done
<gary_poster> barry: do you have access to this page?  https://launchpad.canonical.com/TipsForReviewers .  I get "You are not allowed to view this page"
<barry> BjornT: thanks
<barry> gary_poster: looking...
<barry> gary_poster: yes, i can view the page
<gary_poster> barry: mm. :-/
<gary_poster> barry: I mean...oh, great, so you can do it! ;-)  ...maybe I can ask mrevell or kfogel for view access.
<gary_poster> mrevell, kfogel: I want to transfer content from https://launchpad.canonical.com/TipsForReviewers (and other related pages) to dev.launchpad.net
<barry> gary_poster: hahahaha!
<mrevell> hi gary_poster
<gary_poster> mrevell: hi!  I get "You are not allowed to view this page."
<mrevell> gary_poster: Hmm. Odd. I only get that message when I'm not logged into the wiki.
<mrevell> gary_poster: I'm pretty sure you should have access but I'll happily move those pages over for you now.
<gary_poster> mrevell: oh, wow, thank you.  I am definitely logged in via openid (it shows my name)
<gary_poster> barry: look at mrevell's generous offer.  Can you maybe let him know what pages ought to be transferred?
<mrevell> gary_poster: Heh, I don't know what the cause would be, then, as I'm sure we opened the wiki up
<mrevell> barry: Yeah, just let me know which pages you wanna move
<gary_poster> barry, then you and I can see what, if anything, needs to be cleaned up.
<gary_poster> mrevell: thank you again!
<mrevell> np my pleasure :)
<gary_poster> :-)
<barry> gary_poster, mrevell awesome, thanks.  mrevell it might be a few minutes.  i need to pop my stack of a few things first
<gary_poster> barry: sorry to dump it on you :-(
<mrevell> cool
<barry> gary_poster: no worries!
<barry> rockstar: bug 427101 might help you
<mup> Bug #427101: [Karmic] Xorg crash after login. Returns to gdm which then hangs. <crash> <xserver-xorg-video-ati (Ubuntu):Confirmed> <https://launchpad.net/bugs/427101>
<flacoste> beuno: around to look at https://bugs.edge.launchpad.net/launchpad-foundations/+bug/429247 ?
<mup> Bug #429247: Locationless <h1>s block login/out widgets <story-ui-3> <Launchpad Foundations:New> <https://launchpad.net/bugs/429247>
<beuno> flacoste, sure
<henninge> beuno: ping
<beuno> henninge, hi
<henninge> Hi, beuno!
<henninge> Can you tell me something about https://bugs.edge.launchpad.net/rosetta/+bug/418610 ?
<mup> Bug #418610: New translate page needs new icons <Launchpad Translations:New for beuno> <https://launchpad.net/bugs/418610>
<henninge> ;-)
<beuno> henninge, I cannot
<beuno> but
<beuno> talk to iainfarrell
<beuno> on #design
<beuno> he's the new project manager
<beuno> and can get you resources
<henninge> beuno: ah, cool
<henninge> thanks, beuno
<bac> barry, sinzui: i'm starting on team-map.pt, team-members.pt, and team-mugshots.pt -- unless there are objections
<sinzui> take them
<didrocks> wgrant: here what I get with rocketfuel-get: http://paste.ubuntu.com/271002/
<bac>  sinzui: filed as bug 429455 for your tracking pleasure
<mup> Bug #429455: Update team map, membership, and mugshot pages to UI 3.0 <Launchpad Registry:In Progress by bac> <https://launchpad.net/bugs/429455>
<barry> bac: thanks.  i'm going to get some lunch and then will be back to take some conversions
<bac> barry: good idea.  i think i'll join you.
<barry> bac: come on over!  i've got extras.
<bac> barry: nah, i'm going uptown for the world's best BLT
 * barry drools: mmmmm bacon
<bac> may take jojo
<bac> he will drool
<barry> :)
<sinzui> flacoste: beuno: geser helped diagnose a unit issue were we defined widths in percentages, but margins in ems. I landed that fix. we may have something similar in the CSS. The rule in question relates to our effort to reset the old style sheet
<flacoste> sinzui: we can kill the old style sheet on friday i guess?
<beuno> flacoste, maybe. The bug index is still unconverted
<beuno> so it maybe be a bit of a disaster
<sinzui> flacoste: I hope so. then kill pagetitles.py on 3.0 +1 day
<beuno> I don't really know
<sinzui> beuno: person is unconverted. I took the page from salgado on Friday, then handed it back to him.
<flacoste> beuno: the bug index will be converted, don't worry, the bugs team are doing great work
<flacoste> beuno: and so is the person page, registry is also doing great work!
<flacoste> in fact, the whole team is pushing on this, so it will be delivered
<flacoste> it's amazing
<beuno> flacoste, aiight. I just want to make sure that we don't end up leaving people with unsable parts of LP for a few days
<beuno> MPs and branch pages also need updatin'
<beuno> I'm super keen on killing it as well
<sinzui> beuno: to be very clear, we are going to remove all the ids that we are reseting. We can merge the wanted style rules after we are sure the pages display
<beuno> sinzui, fair enough
<beuno> I'm looking forward to it
<allenap> maxb: Hi. Have I caused you more work with the py25-unittest branch by suggesting a property? Does the descriptor you had originally break too?
<maxb> allenap: The non-data descriptor fails to break when it probably should :-)
<allenap> maxb: Oh wow. Any ideas of how to work around it?
<maxb> A detailed reading of all the other TestCase classes that LP pulls in at varying points and adapting the fix appropriately
<mrevell> See you tomorrow guys
<ppalmers> hi all, I'm having some trouble with using the rocketfuel-setup script to fetch the launchpad dev tree as specfified in https://dev.launchpad.net/Getting
<ppalmers> I'm using the rocketfuel-setup script as described, but it fails with an import error on _pythonpath.py
<ppalmers> this is on 9.04 btw
<rockstar> ppalmers, have done the link-external-sourcecode thing?
<ppalmers> rockstar: is that before or after the rocketfuel-setup?
<ppalmers> rockstar: cause that on its own fails
<rockstar> ppalmers, well, after you branch, you need to link the sourcecode directory.
<ppalmers> rockstar: ok, let me just try this
<rockstar> ppalmers, I have a script that creates a new branch from devel (or db-devel), links the source-code dirs, and then runs `make build`
<ppalmers> rockstar: always interested...
<rockstar> ppalmers, it's just three commands: the branch command, the link command, the make build.  I just got tired of typing them all manually.
<ppalmers> rockstar: well, I don't really grok the thing yet...
<sinzui> geser: ping
<ppalmers> rockstar: I have a ~/launchpad/lp-branches/devel
<geser> pong
<rockstar> ppalmers, you should also have ~/launchpad/lp-sourcecode/sourcecode
<sinzui> geser: cprov is starting on bug 416412. Is it still valid after the CSS right-margin change
<mup> Bug #416412: +build missing a line break between the "title" and the "data" part <trivial> <ui> <Soyuz:Triaged by cprov> <https://launchpad.net/bugs/416412>
<ppalmers> rockstar: I do
<rockstar> ppalmers, so go into the devel folder and do `utilities/link-external-sourcecode ../../lp-sourcecode`
<geser> sinzui: I can't reproduce it anymore, so I'd say it's fixed
<ppalmers> rockstar: would that be s/lp-sourcecode/lp-sourcedeps/ ?
<rockstar> ppalmers, ah, yes.
<ppalmers> rockstar: done
<rockstar> ppalmers, I don't set up my dirs like that, so I hafta fudge it.
<sinzui> geser: thanks. I will set cprov onto one of my bugs
<rockstar> ppalmers, try `make build` now.
<cprov> geser: thanks
<gary_poster> flacoste, maxb: Hi.  I have a proposed fix for https://bugs.edge.launchpad.net/zope3/+bug/413335 .  I asked mgedmin to review, who was involved in the Zope 3 package initially.
<gary_poster> He thinks it looks good, but he said he was trusting me on the timelines. :-)  Are either of you available for a review?  I'd like to have someone from LP look at it too.
<mup> Bug #413335: Figure out what to do about zope.sendmail incompatibility with Python >= 2.5.1 <python-upgrade> <Launchpad Foundations:Triaged> <Zope 3:New> <https://launchpad.net/bugs/413335>
<gary_poster> Right now I just have a diff: http://paste.ubuntu.com/271076/
<gary_poster> checking if zope.sendmail is in LP...
<ppalmers> rockstar: "Unknown entry URL:" warnings are normal?
<rockstar> ppalmers, yeah.
<ppalmers> rockstar: ok, in that case this succeeded
<rockstar> ppalmers, I assume you'll also need to `make schema` to set up the database, and then you can just do `make run` and you'll have a dev server up.
<ppalmers> rockstar: ok
<gary_poster> The package is in LP, but no code.  I could put in a branch of trunk and then apply my diff if that were really desired.
<ppalmers> rockstar: thx
<maxb> mm, that looks nifty
<ppalmers> rockstar: the 'make build' was the magic step I didn't know of
<maxb> gary_poster: I can't spot an holes in that at first glance :-)
<maxb> *any
<gary_poster> maxb: ok. :-)  thank you for looking.  Is there some action I can try in LP to see if this solves the problem?  I haven't tried to duplicate except in your test program actually.  I expect that if I have not solved it, then when I make run I then cannot do an interrupt, but have to kill the process?
<maxb> If Ctrl-C shuts down "make run" cleanly, you've solved the problem
<gary_poster> maxb: ok cool.  thanks!
<maxb> oh, but check that it hasn't left any librarians behind silently too
<gary_poster> ok
<ppalmers> rockstar: thx, it's up and running
<bac> sinzui: i'm going to include wgrant's patch for bug 403561 in my mugshot conversion unless you object.  it makes life much easier when dealing with mugshots.
<mup> Bug #403561: Mugshot retrieval fails on development launchpad <librarian> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/403561>
<sinzui> bac: thanks...
<bac> sinzui: big thanks to wgrant
<sinzui> bac: I was going to suggest that then thought I should not change the scope
<bac> sinzui: changing scope is ok by me when it makes my life easier...
<sinzui> bac: yes, that is why I did the series and milestone pages. I added info that make my job easier
<sinzui> bac: have you seen https://edge.launchpad.net/launchpad-registry/+milestone/3.0 today?
<bac> sinzui: hadn't yet.  nice!
<sinzui> The summary of you and everyone else makes that page a little easier to read...but I need to fix the wrapping on names
<flacoste> gary_poster: lookin
<gary_poster> flacoste: thank you
<flacoste> gary_poster: looks good, btw, the reason that the process doesn't exits is not that the thread status is ignored, it's simply that the atexit handler is stopped waiting for the lock
<flacoste> gary_poster: once you release it, it moves on and will exit
<gary_poster> flacoste: no
<gary_poster> flacoste: not in my experiments
<gary_poster> If I take out the flag it will run forever, even though it was a daemon, if the atexit waited for the lock
<gary_poster> Tested with Py 2.5.2
<gary_poster> 2.5.4 I mean
<gary_poster> flacoste: if that were not the case I could have removed the _stopped flag entirely
<gary_poster> and simply relied on the daemon behavior
<barry> bac, sinzui what templates are you working on, or more importantly which ones can i do now?
<bac> team-map, team-mugshot, team-subscribers
 * sinzui looks at http://people.canonical.com/~beuno/conversions.html
<barry> maybe i should do the team-mailinglist ones?
<sinzui> barry: There are 3 left for you I think: team-invitations.pt, teammembership-index.pt, teammembership-invitation.pt
<sinzui> barry: I think bac is landing the membership ones
<barry> sinzui: um.  do you mean bac is doing the teammembers-*.pt's?
<bac> i have these in ec2:  teammembership-invitation.pt
<bac>     team-mailinglist-moderate.pt
<bac>     team-mailinglist-subscribers.pt, barry
<sinzui> barry: sorry, no, there is already a bug for the mailing list ones. bac is landing it
<barry> bac, sinzui gotcha
<barry> sinzui: i'll do the three you just gave me
<sinzui> so I think we will be done with team tomorrow morngin
<sinzui> only person will remain
<rockstar> flacoste, launchpad-developer-dependencies and launchpad-dependencies appear to be terribly broken for hardy.
<flacoste> rockstar: hmm, that's not too good
<kiko-afk> hardy?
<rockstar> kiko, yes, hardy.
<kiko> how much do we care? are our servers still hardy?
<rockstar> kiko, yes.  Plus, only recently did our stuff start working on Karmic, and I set up my chroot when it wasn't working at all on Jaunty.
<rockstar> flacoste, http://pastebin.ubuntu.com/271120/
<sinzui> Sweet. The registry colour is now fashionable black
<rockstar> flacoste, I also can't get l-d-d installed on Karmic.  Looks like I'm missing python2.4-svn - I'm dead in the water 'til this gets fixed.
<flacoste> rockstar: that's weird, others are reporting success on karmic
<flacoste> python2.4-subversion is in our repo
<rockstar> flacoste, python2.4-svn is a different package.  I see pysvn in there (which python2.4-svn is from) but I'm still getting errors installing.
<flacoste> rockstar: what's the trouble with it?
<rockstar> flacoste, I'm tracking down the actual issue now.  It's claiming python2.4-svn can't be installed, but I just installed it.  One sec.
<rockstar> flacoste, it's still claiming that it can't install python2.4-svn even though I just installed it.  I have no idea what's going on.
<rockstar> This is a fresh install, with just main restricted universe and multiverse enabled.
<rockstar> flacoste, it looks like it's selecting python-svn instead of python2.4-svn when installing.  Something's wrong with python2.4-svn apparently.
<rockstar> flacoste, did you need to pin anything?
<flacoste> i'm not on karmic
<flacoste> but there is no python2.4-svn package
<flacoste> only a python-svn
<flacoste> which should provide python2.4-svn
<maxb> hello
<flacoste> rockstar, maxb is on karmic
<flacoste> as is jml
<rockstar> flacoste, than l-d shouldn't be looking for python2.4-svn
<flacoste> well, yes, it should
<maxb> I suspect that the issue is that karmic's version of python-svn is higher that launchpad/ppa's
<flacoste> because python2.4 is only there if the package was built properly
<maxb> flacoste: You have a sync request outstanding from me to fix that :-)
<flacoste> that's possible
<flacoste> really!
<flacoste> ok
<rockstar> flacoste, please sync it, hurry, quickly, now, kthxbai.
<maxb> rockstar: ppa:maxb/launchpad in the meantime
<flacoste> maxb: does pycxx needs to be synced as well?
<flacoste> rockstar: i'm on it
<rockstar> flacoste, thanks!
<maxb> flacoste: It's purely a build-dep, but for completeness (and being able to rebuild things) sake, it should be
<flacoste> maxb: ok, syncing now
<flacoste> rockstar: copied, will be published on the next publisher run
<rockstar> flacoste, great, thanks.
 * maxb wonders what the deal is with hardy
<rockstar> maxb, no one uses it but me, apparently.  :/
<rockstar> Which seems kinda scary, since we deploy to hardy.
<maxb> heh
 * maxb tries an apt-get install l-d-d in a cowbuilder chroot
<flacoste> rockstar: IS doesn't use our repository
<flacoste> rockstar: they deploy from theirs
<flacoste> rockstar: so i gues they are using older versions which were fine
<rockstar> flacoste, yeah, I was fine too, until I installed Karmic from scratch and needed to re-create my chroot.
 * rockstar can has karmic dev environment
<maxb> apt-get seems happy to install l-d-d in my hardy chroot
<maxb> I'm not quite sure what to make of your pastebin
<bac> sinzui: hey curtis i'm getting failures in trunk on xx-distroseries-index.txt and some others.  could they be due to your branch that is playing now on buildbot?
<sinzui> bac: possibly.
<sinzui> I'll look
<bac> sinzui: Tests with failures:
<bac>    lib/lp/registry/tests/../stories/distroseries/xx-distroseries-index.txt
<bac>    lib/lp/registry/tests/../stories/teammembership/xx-renew-subscription.txt
<bac>    lib/lp/registry/tests/../stories/product/xx-product-files.txt
<bac>    lib/lp/registry/tests/../stories/foaf/xx-team-membership.txt
<bac> the last is probably mine
<sinzui> bac I get the error. It is translations
<sinzui> bac: I think jtv landed that change
<bac> sinzui: his has already gone through buildbot clean.  looks like maybe danilos
<sinzui> bac: The test should be updated to show the output. I am switching tasks. If you agree, I can fix and submit it now.
<bac> sinzui: ok.  i've backed out r9434 and running the failed tests
<bac> sinzui: but that is pointless as you are correct that the tests need updating
<bac> i wonder why ec2 didn't submit my branch.  argh.
 * bac rushes to resubmit before your [testfix]
<sinzui> bac: I will submit in 15 minutes...I'll give you a heads up
<bac> sinzui: fwiw all tests pass without rev 9434
<bac> sinzui: i just resubmitted mine.  i'll keep an eye on  it this time
<sinzui> I see two other translations tests failed too. I will fix them if they are titles, otherwise I will cry
<danilos> bac, sinzui: see the list, the testfix is in the pqm queue
<danilos> sinzui, they are titles
<sinzui> danilo. I just fixed the titles in my branch
<sinzui> There are two h2 printing I fixed too
<danilos> sinzui, that's all fixed in what's already in PQM (both with and without testfix tag)
<sinzui> fab
<danilos> sinzui, note that PQM is stopped for CP, I believe, so it will be a while before it gets in
<bac> danilos:  thanks.  i should've thought to look at the mailing list first.
<mwhudson> good morning
<maxb> Would be nice if PQM stoppages got mentioned on the public list too
 * mwhudson disappears for a bit, should be back for the call
<barry> sinzui: ping
<sinzui> hi barry
<barry> sinzui: hi.  on the +invitations page, when you click on a team you get to a page at something like: https://launchpad.dev/~launchpad/+invitation/landscape-developers
<barry> sinzui: this page's view is defined in a weird way, so it has no +hierarchy adapter
<barry> sinzui: and thus no breadcrumbs
<barry> sinzui: i spent 15 minutes trying to give it breadcrumbs and failed.  thus i am going to make page_title = label
<barry> sinzui: i can file a bug about this for later, or not worry about, or spend more time on it now.  i know what i want to do <wink>
<barry> sinzui: thoughts?
 * sinzui looks
<thumper> morning
<sinzui> barry: It does the oppose of do something. TeamMembership does not have  Hierarchy because it is subordinate to a team.
<sinzui> barry: file a bug
<sinzui> barry: This has been broken for 4 years
<barry> sinzui: exactly.  we think alike
<barry> sinzui: thanks
<Ursinha> sinzui, I'm getting a test failure on lib/lp/registry/stories/distroseries/xx-distroseries-index.txt, was that your change?
<sinzui> Ursinha: danilo-afk's he has already submitted a test fix. see scrollback and email
<Ursinha> sinzui, I've merged his branch but this one still fails
<thumper> mwhudson: ping
<sinzui> Ursinha: Then he did not fix everyone
<Ursinha> sinzui, I
<sinzui> The title needs to change in the test.
<Ursinha> sinzui, I'll change and submit then
<sinzui> I reverted my that change when I learned danilo-afk has submitted a fix
<Ursinha> sinzui, anyway.. IO
<Ursinha> I've fixed that and submitted my branch again
<mwhudson> thumper: pong
<maxb> A minor style question: class Foo(object):,  or depend on the __metaclass__  = type at the head of the file, and just write class Foo:    ?
<mwhudson> maxb: launchpad style is the latter
<maxb> thanks
<mwhudson> (which i dislike, but never mind...)
<maxb> Rather ironically, my py2.5-unittest-compatibility branch has headed almost full circle, and is back using a descriptor
<mwhudson> :)
<mwhudson> things should be as simple as possible, but no simpler
<wgrant> bac: Ah, great.
<maxb> On this py2.5-unittest-compatibility thing - I *think* I have something sane that works now. I've set my machine churning on a full test run. Should I wait for my own testrun to succeed (hopefully) before I ask for another ec2test attempt?
<maxb> gary_poster: Yay \o/  Now I can drop my lp-source-dependencies branch :-)
 * rockstar goes on a short walk
<wgrant> cprov: Do you have a moment to talk about PPA dbgsyms?
<gary_poster> maxb: :-)
<jml> hello
<cprov> wgrant: sure
<mwhudson> jml: hello
<wgrant> cprov: Great.
<jml> mwhudson, hi.
<cprov> wgrant: skype ?
<wgrant> cprov: Ah, not a bad idea. Let's see if it works.
<cprov> wgrant: cprovidelo
<dhillon-v10> deryck: hi how are you
<mwhudson> ec2test suffers from a particular anti-pattern: default arguments for a function/class constructor which is called exactly once, specifying all arguments
<wgrant> cprov: I've added you, and am currently hunting for my good headset.
<cprov> wgrant: okay
<wgrant> cprov: Looks like it's OK. I can't see you, though.
<cprov> wgrant: what's your nick ?
<wgrant> cprov: william.a.grant, sorry.
#launchpad-dev 2009-09-15
<mwhudson> jml, thumper, other canonicalers; have any branches to ec2test currently/soon?
<thumper> not yet
<jml> mwhudson, sorry, no.
<rockstar> Nope.
<mwhudson> slackers!
 * mwhudson tests the first 'faster --headless' thing
<thumper> rockstar: call?
<rockstar> thumper, sure.
<dhillon-v10> guys is deryck there
<rockstar> dhillon-v10, he usually cuts out about 4 hours ago.
<dhillon-v10> rockstar: alright, thanks
<dhillon-v10> rockstar: I wanted to talk to him about some code we talked about in mail
<rockstar> dhillon-v10, the bugs folks all work European hours.
<mwhudson> wow, detached in 8m31
<mwhudson> in other news: make build is really really slow
<mwhudson> three minutes of that was waiting for the instance to boot
<dhillon-v10> rockstar: ah, thanks...
<mwhudson> jml: want to review a really simple ec2test branch?
<jml> mwhudson, yeah sure
<mwhudson> or anyone else, it's really simple
<mwhudson> dammit, missed the */5
<thumper> rockstar: http://pastebin.ubuntu.com/271268/
<mwhudson> jml: you have mail now
<rockstar> thumper, just type "debugger;" in a single line
<jml> mwhudson, thanks.
<jml> mwhudson, so, make check depends on make schema?
<jml> mwhudson, also, won't this break test options like -1?
<mwhudson> jml: make check runs test_on_merge
<mwhudson> jml: which runs "make -C database/schema test"
<mwhudson> jml: which sets up enough database for the tests to run
<jml> mwhudson, what about 'make build'?
<mwhudson> jml: check: depends on build:
<jml> mwhudson, cool.
<mwhudson> jml: i'm not sure what you mean about "options like -1" ?
<mwhudson> jml: the fact that they start with a "-" ?
<jml> mwhudson, well, they aren't VERBOSITY
<mwhudson> jml: VERBOSITY is a lie in the makefile
<mwhudson> check: clean build
<mwhudson> 	# Run all tests. test_on_merge.py takes care of setting up the
<mwhudson> 	# database.
<mwhudson> 	${PY} -t ./test_on_merge.py $(VERBOSITY)
<jml> mwhudson, so if you pass in the perfectly cromulent options -vv -1, test_options='-vv -1', and then the 'make check' command will be incorrect
<jml> mwhudson, I think you need to quote test_options when you append it to command in build_test_command.
<mwhudson> jml: actually, i don't think so
<jml> mwhudson, why not?
<mwhudson> jml: because of the amount of times a shell gets to see the arguments
<mwhudson> jml: subprocess.call(["make", "check", "VERBOSITY=-a -b"])
<mwhudson> is the same as running
<mwhudson> $ make check VERBOSITY='-a -b'
<mwhudson> in your shell
<jml> hmm
<jml> ok
<mwhudson> actually i suspect it makes very little difference in the end
 * mwhudson runs ./utilities/ec2test.py -o '-v -v -v -t xx-codeimport' --headless to be sure
<jml> heh
<jml> mwhudson, approved.
<mwhudson> jml: thanks
<jml> mwhudson, I'm going to reboot my computer while spiv powercycles the router (!!!!!)
<thumper> mwhudson: you can combine those to -vvvt for conciseness :)
<mwhudson> thumper: of course, it's less of a test that way though
<thumper> are you testing the args?
 * jml would like to have phone calls today... :)
 * jml reboots
<mwhudson> jml: ok (!)
<thumper> jml: because laptop no worky?
<mwhudson> thumper: what do you mean?
<thumper>  ./utilities/ec2test.py -o '-vvvt xx-codeimport' --headless
<mwhudson> thumper: that's what i rand last time, that worked
<jml> thumper, no, because karmic has a new kernel
<jml> thumper, mwhudson: I think both of you owe me calls :)
<mwhudson> jml: yeah, i think you're right
<mwhudson> jml: i'm going to have lunch first though, is a call in about an hour ok?
<jml> mwhudson, that's fine
<thumper> jml: I'll call you after mwhudson
<jml> thumper, cool.
<mwhudson> jml: call now ish?
<jml> mwhudson, I'm on w/ flacoste now, sorry.
<mwhudson> jml: ok, ping me when you're done
<jml> mwhudson, will do.
 * mwhudson kicks EC2 in the head
<mwhudson> Started in 11 minutes 25 seconds
<rockstar> mwhudson, that's roughly half the time cut off, ent?
<mwhudson> rockstar: no, that was just the time it took the instance to start
<mwhudson> it was the first time booting a new AMI though, that might have been why it was slow
<mwhudson> rockstar: do you want to look at this ec2test branch?
<rockstar> mwhudson, sure.
<rockstar> mwhudson, I'm not sure I'm the best qualified to offer technical advice on ec2, but I can do my best.
<mwhudson> rockstar: here's the diff http://pastebin.ubuntu.com/271309/
<rockstar> Oh, I didn't know you could create an AMI with ec2test
<rockstar> mwhudson, why move the dirs instead of copying them?
<mwhudson> rockstar: faster
<rockstar> mwhudson, ah, okay.
<mwhudson> rockstar: that's the whole point of this branch, make ec2test --headless let go faster by updating the download-cache rather than checking it out from scratch
<rockstar> mwhudson, are there any tests for this?  I remember you remarking that there were no tests before, but I'm wondering if there are plans to change this.
<rockstar> mwhudson, yeah, I deduced it must have to do with making everything faster.
<rockstar> How does --extra-update-image-command play into making everything faster?
<mwhudson> rockstar: no tests
<mwhudson> oh right
<mwhudson> that doesn't
<mwhudson> ./utilities/ec2test.py --update-image launchpad-ec2test16 --extra-update-image-command 'bzr branch --standalone lp:lp-source-dependencies /var/launchpad/download-cache'
<rockstar> mwhudson, are you going to remove it though?  It seems like it might make be of use.  *shrug*
<rockstar> Ah, okay.  So you aren't going to remove it.
<mwhudson> ^ i ran that to make an image with download-cache already on it
<rockstar> mwhudson, r=me
<mwhudson> rockstar: thanks
<mwhudson> thumper, rockstar, jml: still no branches to ec2test?
<rockstar> mwhudson, not here.
<jml> mwhudson, no :(
<jml> mwhudson, I haven't actually done any coding today.
<rockstar> jml, who are you, and what have you done with the real jml?
<mwhudson> he got promoted
<wgrant> Is all that going to become clear to us at some point?
<wgrant> There seem to have been lots of changes.
<jml> yeah, we ought to send an email out, I reckon
<lifeless> quick storm question
<lifeless> whats the default cache for a store?
<jml> thumper, hi
<jml> thumper, call now?
<jml> I just came across this bug:
<jml> https://bugs.edge.launchpad.net/malone/+bug/276789
<mup> Bug #276789: inconsistent results for IBugTarget.searchTasks(has_patch=...) <Launchpad Bugs:New for intellectronica> <https://launchpad.net/bugs/276789>
<jml> abel has all but written a unit test as the bug report
<spm> sounds like a perfect bug report then? :-)
<jml> spm, hell yes
<jml> might be a good patch for a new developer to work on.
 * spm ponders if this might be a good way to take advantage of the open source nature of LP and fix some of the most niggly losa impacting bugs :-P
<jml> spm, you mean, write bug reports that include unit tests?
<spm> I actually (jokingly) meant write code
<spm> but given most of my coding experience is assembler, cobol, perl and C... you won't like the patches
<jml> spm, heh
<thumper> jml: I'm around now
<jml> thumper, shall we?
<rockstar> mwhudson, hi
<spm> jml: tho... I could perhaps draw on some php experience - would that help? I know you're a php coder by preference. ;-)
<jml> :(
<mwhudson> rockstar: hello
<jml> spm: the last time I touched PHP, the tip of my finger turned into pure energy.
<rockstar> mwhudson, is there ever a case where an import branch would not have a code_import?
<jml> spm, it took a month for my eyebrows to grow back
<mwhudson> spm: unittests in assembler would be awesome
<mwhudson> rockstar: certainly shouldn't be
<mwhudson> rockstar: there's no constraint in the db for that though
<rockstar> mwhudson, I just see a lot of unnecessary checking in the tal for the presence of code_import.
<spm> mwhudson: that implies a level of understanding of WTF the code is actually doing that, imho and experience, is missing from every assembler level program ever written. "keep randomly changing op codes, it's bound to do what we want eventually"
<rockstar> It certainly makes the page look funny if it doesn't exist, but I think that we have bigger problems should that occur.
<mwhudson> rockstar: branch-index.pt is a little.... organic, i think you could say
<rockstar> mwhudson, it's not anymore.  I fixededed it.
<mwhudson> rockstar: this sounds like one of the smelly bits
<rockstar> mwhudson, great.  Thanks.
<mwhudson> rockstar: np
<rockstar> mwhudson, I don't see a function in the factory that allows me to create an import branch and a code import together.  Is there one?
<mwhudson> rockstar: i think ICodeImportSet.new creates the branch along with the code import
<mwhudson> rockstar: i may be misremembering...
<rockstar> mwhudson, ah, it does.
<rockstar> So what's the point of makeImportBranch ?
<mwhudson> rockstar: argl
<mwhudson> rockstar: i guess it's a way of constructing test data that is somewhat inconsistent with that found in real life :/
<rockstar> mwhudson, yes, yes it is.
<mwhudson> rockstar: grep for it?
<mwhudson> i bet it's not called all that often
<rockstar> mwhudson, yea, I think I'm going to file a bug on it as well.
<rockstar> It should go away.
<rockstar> mwhudson, it was probably just a bi-product of when we broke up the makeBranch method to make all sorts of branches.
<mwhudson> rockstar: yeah, indeed
<mwhudson> rockstar: or redefine it to "return self.makeCodeImport().import_branch" i guess
<rockstar> mwhudson, yeah, something like that, although having two methods doing similar things seems a little odd to me.
<rockstar> thumper, hi
<jml> mwhudson, still no branches :P
<mwhudson> jml: i got stub to test one
<thumper> rockstar: hey
<rockstar> thumper, so it looks like branch titles have crept back in by way of the page headings.
<rockstar> :/
<thumper> rockstar: let's talk about this tomorrow in more detail
<thumper> rockstar: I might get up early even :)
<rockstar> Oh great, looks like ec2test.py is broken on karmic.  WTH
<wgrant> I thought jml fixed that last week.
<wgrant> How's it dieing?
<rockstar> Tells me my python-boto is not supported.  I pastebin.
<wgrant> That sounds out of date.
<wgrant> If you remove that check, it works.
<wgrant> But I thought that check was gone in devle.
<rockstar> wgrant, ah, yeah, now that I think about it, it probably is...
<wgrant> rockstar: It was removed in devel r9357.
<rockstar> wgrant, yeah, looks like I was still using the lp-dev-utils version
<wgrant> rockstar: Ah.
<rockstar> <underwhelmed>yay</underwhelmed>
<wgrant> Is there a design somewhere for these new breadcrumbs/titles?
<wgrant> I wonder if some of this breakage is intentional.
<mwhudson> wgrant: yes, there is
<mwhudson> wgrant: it's on some wiki page somewhere, aiui
<mwhudson> my brain is turning into fudge, time to stop for today
<wgrant> mwhudson: The only relevant one I know of is w.c.c/IForgetWhat/UI/Navigation
<wgrant> Could be there. Who knows.
<mwhudson> i certainly don;t
<wgrant> OK.
<rockstar> wgrant, well, I think there's been so much churn that any wiki page you find will probably be out of date.
 * rockstar also has a brain of fudge, needs to go eat dinner, and have his 1230 nap.
<jtv> rockstar: ironic... now you're a slave of the clock because of your time-saver.  ;-)
<rockstar> jtv, less is more, or something like that?
<rockstar> jtv, I've actually found ways to fudge the clock around get-togethers and such, because I can't always use my friend's bed for a nap.
<jtv> rockstar: I was never really comfortable with that expression, from a formal standpoint  :-)
<rockstar> jtv, :)
<jtv> rockstar: heh, it hadn't occurred to me...  You can't always expect to be at home at just the right time.
<rockstar> jtv, yeah, which sometimes leads to awkward situations.
<rockstar> I'm actually not even on Uberman anymore.  I still have 4 hours of straight sleep starting at 4 AM - this is for my wife's sanity more than mine.  :)
<rockstar> But that still means I'm only getting ~5 hours of sleep/day
<jtv> Uberman?  Strange name...  No umlaut?
<jtv> wow, that's gotta save you some tmie
<jtv> time
<rockstar> jtv, uberman is the hardcore polyphasic, I'm on a more hardcore "everyman" schedule right now.
 * rockstar goes to find viddles
<wgrant> I'm really not a fan of four thousand line LP Perl scripts that diverged from an unknown upstream version more than four years ago, with little useful VCS history.
<jml> wgrant, which ones are they?
<wgrant> jml: Just one four-thousand line one -- sbuild.
<wgrant> A nice fragile untested critical piece of lp-buildd.
<jml> :(
<jml> BjornT, hello
<BjornT> hi jml
<jml> BjornT, ready for a call?
<BjornT> jml: yes, in a minute. i'll get my laptop
<jml> BjornT, ok.
<BjornT> jml: i'm ready. skype? my username is bjorn.tillenius
<jml> BjornT, yes, skype. I've sent you an invite
<adeuring> good morning
<noodles775> Hi adeuring :)
<adeuring> hi noodles775!
<mrevell> Morning
<jml> mrevell, hi
<mrevell> hi jml
<beuno> noodles775, hi
<beuno> cprov, hi
<noodles775> hi beuno
<noodles775> beuno: I'm guessing (or hoping) that he's asleep.
<beuno> noodles775, isn't he in the netherlands?
<noodles775> beuno: nope.
<beuno> hm, ok. I guess he moves around a lot.
<beuno> noodles775, would you happen to know if it's easy (and cheap!) to get a count of the number of source packages in Launchpad?
<noodles775> beuno: it sounds like something easy for anyone with db access to do. Or you mean to display on a page?
<beuno> noodles775, display on the homepage
<wgrant> One would first have to work out what is meant by 'source packages'.
<beuno> it already hurts
<noodles775> wgrant, beuno: yes, I'm assuming you just mean all source packages.
<beuno> noodles775, lets say yes
<wgrant> noodles775: That's unlikely.
<beuno> well
<wgrant> As that wouldn't count PPAs.
<wgrant> Published SPRs, maybe?
<beuno> ok, I can see how this gets complicated
<beuno> which is why I left it out in my initial work
<beuno> which is why I left it out in my initial work
<beuno> er
<beuno> so
<wgrant> Maybe all SPRs, in fac.t
<beuno> I want to show some stats on soyuz on the home page
<wgrant> beuno: There are already some stats at https://launchpad.net/ubuntu/+ppas.
<beuno> aha!
<beuno> that is fantastic
<beuno> thank you wgrant, that takes me half way there
<beuno> as for Ubuntu packages?
<wgrant> beuno: You probably want an all-time count, not just currently published stuff?
<jml> beuno, hi
<beuno> wgrant, well, I don't know if it's as interesting to do an all time count
<beuno> jml, hello hello
<wgrant> beuno: All the rest on the home page seem to be, but OK.
<beuno> wgrant, true
<beuno> would this include all the versions?
<wgrant> Yes.
<beuno> it sounds like it would be hundreds of thousands
<wgrant> So, it's easy and pretty cheap to get the total number of almost-current (the number is updated by a cronjob; no idea how often that runs) sources across all of LP.
<beuno> wgrant, any hints on where to look for that number
<wgrant> beuno: SELECT SUM(sources_cached) FROM Archive; There's no method for that yet -- only one that restricts to PPAs of a particular distribution.
<beuno> wgrant, thanks
<wgrant> It would be nice to have realtime stats, but I don't know how expensive that would be.
<beuno> noodles775, any idea why no H1?  https://edge.launchpad.net/ubuntu/+ppas
<noodles775> beuno: yes, the branch barry landed assumes that view's implement the label property - that one doesn't yet.
<beuno> noodles775, cool
<noodles775> s/view's/views gar.
<noodles775> beuno: I'm just looking at bug 429353 - why do we want the 'Enable edge redirect' there in the site_message, if (1) it'll only be seen if people are on edge anyway (note: on the homepage at launchpad.dev there is an option to re-enable the redirection)
<mup> Bug #429353: Move edge message to the footer, allow people to stop redirection <Launchpad Foundations:In Progress by michael.nelson> <https://launchpad.net/bugs/429353>
<beuno> noodles775, one sec
<beuno> otp
<beuno> noodles775, back
<beuno> right, this is only for people on edge
<noodles775> beuno: I've got two other questions, I added them to the bug.
<beuno> noodles775, I'll reply there then
<noodles775> (well, one other question, one clarification).
<noodles775> beuno: great, thanks!
* mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 3
<wgrant> I think it's pretty important for the message to be obvious, at least for dogfood/staging.
<wgrant> Not so much for edge.
<beuno> wgrant, isn't the background obvious enough?
<beuno> I agree though, edge is my target
<wgrant> beuno: Mmm, possibly.
<wgrant> My preference would be to have the edge warning right down the bottom, with the others moved to immediately below the watermark. That actually looks pretty good, IMO.
<soren> mrevell: Did you relaly mean to remove all that stuff from the /TOPIC?
<mrevell> soren: No, not at all. Thanks for pointing that out.
* mrevell changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 3 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html
<soren> mrevell: Sure.
<jml> soren, what are you doing here?
<jml> soren, are you going to start hacking on Launchpad?
<beuno> wgrant, not sure how much freedom we have to diverge between the three
<soren> jml: It's called lurking :)
<wgrant> beuno: Three? Aren't there just two?
<wgrant> (but yes, that is a problem)
<jml> soren, but you've delurked now... does that mean you'll start sending in patches?
<beuno> wgrant, dogfood   :)
<soren> jml: If I had a clue where to start.. Maybe :)
<soren> jml: I haven't quite found my way around the code yet (not that I've tried all that hard).
<wgrant> beuno: Right, but staging and dogfood need the same kind of message.
<beuno> yes
<jml> soren, there's a lot of it :)
<jml> soren, I'm more than happy to help if you have a specific thing you want to try
<jml> but maybe not tonight. I'm starving.
<wgrant> beuno: There's already edge stuff hardcoded elsewhere, so it's not a significant additional evil to add something in the footer.
<beuno> wgrant, I'm fine with that, it's up to noodles775, who will need to pass the code review  :)
<noodles775> wgrant: where's the other hardcoded edge stuff?
<jml> g'night all
<jml> soren, happy lurking :)
<wgrant> noodles775: The timeout template, the home page.
<noodles775> wgrant: currently it's just a config site_messages option, that is only used on edge, staging and dogfood.
<soren> jml: I'll keep that in mind.
<soren> jml: Good night :)
<noodles775> wgrant: ah yep, the is_edge, is_demo, is_lpnet etc. Great.
<mwhudson> dear launchpad developers: please stop breaking the build
<deryck> Morning, all.
<kimus> hi, is there a way to get statistics (visitors, commits, downloads, etc) for our projects in LP?
<beuno> kimus, you can get some of them
<beuno> download stats, you've got in the download page
<beuno> commits, in the code page, it gives you some of that
<beuno> it's mostly scattered at the moment
<kimus> beuno: so where can I put a feature request for this?
<beuno> if you'd like something specific, feel free to file a bug, it will help us shape the information we present
<beuno> kimus, https://bugs.launchpad.net/launchpad/+filebug
<beuno> if it's something specific
<beuno> if you feel it needs discussion
<beuno> the mailing list is the best place
<deryck> beuno, hi
<beuno> deryck, hi!
<kimus> first I will file the bug... then I can go to discussion if needed :-)
<beuno> kimus, it's usually easier the other way around, but go for it!
<beuno> kimus, mailing list at: https://edge.launchpad.net/~launchpad-users
<kimus> beuno: the "Subscribe to mailing list" link does not work. I will go to mailman interface to subscribe :-)
<beuno> kimus, you need to join the team first
<beuno> are you logged into LP?
<beuno> I gave you an edge URL (sorry)
<kimus> beuno: do I need to join the team to subscribe to ml?
<beuno> kimus, yes
<kimus> ok...
<beuno> (we will change that in the future, curtesy of barry)
<beuno> flacoste, hi
<maxb> Hello. /me is around for 20mins or so, if anyone has thoughts on my py2.5-unittest-compatibility branch
<beuno> flacoste, around yet?
<beuno> deryck, has there been any decision on wether we're dropping mentoring?  (please do!)
<kfogel> beuno: I have a memory (trying to find the mail) that there was pretty broad consensus on that on-list.
<beuno> kfogel, on dropping it or on dragging it along?
<kfogel> beuno: dropping
<beuno> coolio
<beuno> thanks kfogel
<kfogel> beuno: wait, let me see if I can find
<kfogel> beuno: so far: https://lists.launchpad.net/launchpad-dev/msg00148.html, and then Martin Pool's response.  But I think we had a more definite thread, let me see.
<beuno> kfogel, don't worry
<beuno> your answer is good enough
<beuno> thank you
<kfogel> beuno: ok.  Well, sorry -- I do recall an even more definite statement coming later, from multiple people like flacoste, etc.  But my memory is like a... what's that thing called?... I can never remember...
<beuno> heh
<beuno> I feel like eating cheese now
<beuno> kfogel, while you're here
<beuno> any thoughts on the LP homepage?
<beuno> I'm working on a mockup
<kfogel> beuno: hmmmm.  let me take a look
<beuno> and then I'm back to my vacations
<beuno> so if there's anything you'd like to see in a mockup, now is the time
<kfogel> heh
 * kfogel pondering
<kfogel> beuno: only thought I have is that it might be nice if the "What's New?" section were an RSS headline feed straight from the blog.  But I'm sure that's been debated/considered before.
<kfogel> beuno: let me look at page stats for a sec
<beuno> kfogel, having a feed from the blog would be orgasmic
<kfogel> beuno: I'm looking at https://help.launchpad.net/PageHits to see if it offers any clue as to what should be directly on the LP front page.
<beuno> aha
<beuno> I did not know about that page
<beuno> WOW a *lot* of people visit /Legal
<beuno> kfogel, I guess this page is a good one to extract a few things: https://help.launchpad.net/NewToLaunchpad
<kfogel> beuno: to me the big surprise is PPA
<kfogel> by far the biggest help destination
<wgrant> cprov: I noticed a problem this afternoon with primary ddeb uploads. Because they skip NEW, they all land in universe.
<kfogel> beuno: one complaint about https://lpstats.canonical.com/graphs/ is that it doesn't offer any comparisons between categories.  A graph is about bugs, or it's about branches, say, but there aren't really any easy ways to get comparisons between bugs and branches.
<cprov> wgrant: shh, they don't have overrides at all, do they ?
<wgrant> cprov: They don't, but it seems wrong that they all land in universe.
<beuno> kfogel, agreed. You just need to put together some SQL for the LOSAs though, and they will get a graph
<cprov> wgrant: yes, we have to fix it.
<kfogel> beuno: do you think a "report bug in Ubuntu" would be a good idea?  Interestingly, Launchpad front page has no indication at all that the site is about building Ubuntu.  Of course, the degree to which it is or should be Ubuntu-centric is a big question.
<kfogel> beuno: yup (re SQL)
<mthaddon> beuno: you know there's a branch to propose merges to these days, right?
<cprov> wgrant: they could inherit the source component (maybe)
<wgrant> cprov: I thought that.
<bigjools> can they be linked back to the regular deb in any way?
<wgrant> beuno: But maybe we just strip -dbgsym off, or get pkg-create-dbgsym to stick the original binary name in a field somewhere.
<wgrant> Er.
<wgrant> cprov: ^^
<beuno> mthaddon, I do not!  how cool is that!
<beuno> kfogel, I've brought that up in the past
<beuno> kfogel, I think I'd like it, but it will also make Launchpad look even more Ubuntu-centric
<mthaddon> beuno: there was an email to the list about it - https://code.edge.launchpad.net/tuolumne-lp-configs
<wgrant> bigjools: The names should all follow the pattern of $ORIGINALBINARY-dbgsym. I suppose it's reasonable to reject if something doesn't match up.
<beuno> mthaddon, that is super great. Thanks for the tip.
<cprov> wgrant: if dbg_name.replace('-dbgsym', '') == name, yes, that would be an option
<wgrant> cprov: btw, pitti ack'd the pkg-create-dbgsym changes and suggests that they be SRU'd.
<kfogel> beuno: Anyway: PPAs are a somewhat underadvertised feature from the home page.  Might be nice to have a "Find or create Personal Package Archives" link (or something like that) under Get Started.
<bigjools> wgrant: ok, seems like it should be easy enough to account for that in the overrides check
<beuno> kfogel, interesting thought. I'll see what I can come up with
<kfogel> beuno: personally, I wish Translations and Blueprints tabs would switch places :-).
<wgrant> bigjools: Yep.
<beuno> kfogel, do it! change them, propose the branch  ;)
<kfogel> beuno: also, although "Answers" is a term of art for us (simply the label for our "Answers" feature), for the public it's a weird word to see.  "Oh, Answers?  Like, what is the flying speed of an unladen swallow?"
<beuno> kfogel, yeah, Q&A or support tickets is easier to understand
<kfogel> beuno: yeah!
<beuno> kfogel, "naming" sounds like a nice topic for our TL sprint  ;)
<kfogel> beuno: *cough*  adding now
<bigjools> wgrant: I'd be happy to sponsor a patch :)
<bigjools> kfogel: African or European?
<wgrant> bigjools: Working on another related one now, but I'll do that  soon.
<bigjools> wgrant: cool
<kfogel> bigjools: AiyaaaaaaaaaaaaaaH
<flacoste> kfogel: please, we already renamed that appliation
<kfogel> flacoste: which?
<flacoste> kfogel: it was called support and ticket when I joined to work on it
<flacoste> kfogel: Answers
<kfogel> flacoste: oh, we renamed it *to* Answers?
<flacoste> kfogel: and there are other 'Answers' service out there, Yahoo! Answers for example
<flacoste> kfogel: yeah, it was a big discussion
<kfogel> flacoste: yeah, but isn't Yahoo answers actually answers abuot anything?
<flacoste> kfogel: well, it's a general forum
<flacoste> anyway, the main rationale for renaming it was that support is confusing
<flacoste> Q&A might not be a bad name
<flacoste> but i don't think it's really a big problem
<kfogel> flacoste: or "Q&A Forum"
<kfogel> flacoste: I've removed the agenda item; I couldn't think of any other big naming problems, and didn't know the history here.
<flacoste> anyway, I'd want serious data gathering before any more renaming
<BjornT> flacoste: hi. when running windmill, do you remember that we had problems with uuid listening on the web app port after windmill exited? do you also remember how we fixed it?
<kfogel> flacoste: that seems rational
<flacoste> BjornT: no, that doesn't ring any bell
<wgrant> cprov: I'm dropping from lp.soyuz.model.publishing the block that avoids publishing PPA ddebs to disk. There is a test that tests for that -- should I drop it, or alter it to verify that publishing occurs?
<flacoste> BjornT: but head down to #windmill in a few hours people should be able to help there
<flacoste> BjornT: a big problem for you will be that this channel is mostly active on Pacific time
<BjornT> flacoste: ok. i'll try the list, to see if someone remembers it. i do recall us having that problem. i'll try #windmill as well, but it could be lp specific
<cprov> wgrant: i wonder if it's an useful mechanism to keep up to the last-minute.
<kfogel> cprov, wgrant: do you guys recall where/how you advertised your UDW "Hacking Soyuz" session?  Just trying to capture some knowledge for next time.
<cprov> wgrant: if the disk-publication suppressing bit is there we can check how much space it will take without actually requiring disk and the surrounding infrastructure
<wgrant> cprov: It actually seems like it's really dangerous.
<wgrant> cprov: Ah, true.
<wgrant> But careful publishing of all PPAs sounds expeeeeeensive.
<wgrant> kfogel: I don't recall any advertising outside the UDW brochure/wikipages.
<noodles775_> kfogel: we didn't get to - other than dholbach's work (and I blogged about it on the day - not much use - http://micknelson.wordpress.com/2009/09/04/testing-launchpad-soyuz-features/)
<kfogel> noodles775_: (see above question to cprov, wgran...)
<kfogel> heh
<cprov> wgrant: yes, ideally we should keep the corresponding SBPPH as PENDING
<kfogel> noodles775_: you're way ahead of me :-)
<noodles775_> :)
<kfogel> noodles775_: do you know what dholbach did?
<cprov> wgrant: but they would trigger PPA re-publication every cycle.
<wgrant> cprov: Indeed. I suppose somebody could always reset them when the time comes to actually do it.
<wgrant> There seems to be no non-evil way to do it.
<noodles775_> kfogel: lots of blogging (http://daniel.holba.ch/blog) and irc/email - but I'd check with him for details.
<kfogel> noodles775_: thank you
<cprov> wgrant: we shouldn't fear it much, if the buildmaster only request ddebs for the primary archive, their publication would be already skipped.
<noodles775_> np!
<wgrant> cprov: Right.
<cprov> wgrant: you can drop the publishing hack once you land the builddmaster flag.
<wgrant> cprov: One more question about the flag: what permission? lp.Edit or lp.Commercial?
<deryck> BjornT, ping
<BjornT> hi deryck
<cprov> wgrant: lp.Commercial, I'd say
<wgrant> cprov: Great, that's what I'd used.
<wgrant> cprov: I just realised that this gets very messy when deletions/copies/overrides/cruftchecks/unembargoings/anything happens.
<cprov> wgrant: *this* what ? but, yes, I see what you mean ;)
<wgrant> cprov: 'this' == 'separate DEBUG archive'
<cprov> wgrant: oh, yes, 'finding and suitable ancestor'
<wgrant> Not quite that, but it's related.
<wgrant> debug/security/ports seem to me to be in the same boat -- they're all different views of the primary archive. But some are implemented as post-publishing mangling, others as separate archives. ISTM that a concept of a 'publishing view' should exist, rather than overloading separate archives to do this.
<cprov> wgrant: i'm not sure 'publishing views' is a good concept, I would rather use 'archive collections' because of the archive<->repo relationship
<beuno> deryck, re: bug 346722
<mup> Bug #346722: crash report bug title box too small <trivial> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/346722>
<beuno> "wooooooooooooo"
<beuno> it's bugged me for ages  :)
<deryck> beuno, awesome. :)
<deryck> beuno, it does seem an easy fix with a lot of gain
<beuno> deryck, also, you know what would help a lot?
<beuno> being able to see the title and the dupes at the same time
<beuno> so you can compare the traceback
<beuno> otherwise you need to say "no, it's not", read, and scroll back up
<deryck> beuno, right.  I was thinking that too.  I'll update the bug.
<beuno> yay
<barry> salgado: ping
<salgado> hi barry
<barry> hi salgado what do you suggest for the breadcrumb adapter?
<barry> salgado: or do you have an example in the tree already?
<salgado> barry, something like TeamBreadcrumb in lp/registry/browser/person.py
<salgado> barry, then you register it using zcml and everything just works
<sinzui> barry, bac, salgado: I reported bugs for the person pages. I believe every unconverted page is not tied to a bug: https://edge.launchpad.net/launchpad-registry/+milestone/3.0
<barry> sinzui: s/not/now/ ?
<barry> salgado: that sounds easy enough!  thanks, let me try that
<sinzui> barry: yes, that reads better
<barry> sinzui: cool.  i'm going to work on the breadcrumbs for those two pages and then will take some bugs off that list
<beuno> salgado, hi
<barry> sinzui: actually.
<salgado> hi beuno
<barry> sinzui: i'm going to convert some other pages while the team ones are in review.  once those land, i'll work on the breadcrumbs for them
<beuno> salgado, did you see the bug I shamelessly assigned to you?
<sinzui> barry: okay
<salgado> beuno, which one?
<salgado> beuno, breadcrumb icons?
<beuno> salgado, yes
<beuno> I did not know what it involved, so I just assigned it to you so it wouldn't drop off the radar  (it makes breadcrumbs kind of icky)
<salgado> beuno, trivial change
<beuno> salgado, and that is why I love you
<kimus> beuno: hope not in a carnal way... :-)
<beuno> whatever makes UI happen  ;)
<kimus> :-D
<kimus> beuno: good answer
<bigjools> beuno is literally putting his ass on the line then
<beuno> lol
<beuno> took you a while, but an even better answer!
<bigjools> beuno: only just caught up with the channel :)
<rockstar> I'm not sure I want to know here beuno puts his ass.
<rockstar> Although maybe I do, but the UI is making me feel uneasy about it.
<beuno> cprov, do you know any magic words to just run the soyuz pagetests?
<bigjools> beuno: bin/test -vvt stories.soyuz
<bigjools> beuno: and bin/test -vvt stories.ppa for a few more
<beuno> bigjools, perfect, thank you
 * beuno is fixing bug 423105
<mup> Bug #423105: Duplicate download icons in many places <Launchpad Foundations:Triaged by beuno> <https://launchpad.net/bugs/423105>
<bigjools> I've never found a way to run every page test under lib/lp/soyuz/stories ... :(
<bigjools> beuno: it's not just soyuz that's affected by that
<bigjools> the bug mentions some bug pages too
<beuno> bigjools, I need URLs, and the only URL I have is from soyuz
<bigjools> I can't offer anything beyond the bug, sorry
<beuno> bigjools, it's ok, I'll fix soyuz, mark it as fixed, and when users give us URLs, we'll fix the other ones
<beuno> it's easy to fix
<beuno> you need to remove the "download" CSS class from UL's
<beuno> I could grep around, etc
<beuno> but I'm 1 hour from being on vacations again, so I'd rather do what i can finish  :)
<bigjools> beuno: here's another
<bigjools> https://edge.launchpad.net/ubuntu/karmic/+source/firefox-3.5/3.5.3+build1+nobinonly-0ubuntu2
<beuno> bigjools, fixed in my branch
<bigjools> coolio
<beuno> wtf?  I'm getting all kinds of test failures
<beuno> bigjools, does this ring a bell?  http://paste.ubuntu.com/271559/
 * jtv starts packing up for the night
<mrevell> Night all
<beuno> sinzui, ping
<sinzui> hi beuno
<beuno> sinzui, how are you?
<sinzui> exhausted
 * sinzui has another 8 pages converted, but unlanded
<beuno> I can imagine, you have been a non-stop 3.0 UI machine
<beuno> sinzui, I just wanted to check with you about some wonky font sizes we have in the new stylesheet
<beuno> we end up with things like: http://people.canonical.com/~salgado/long-email.png
<beuno> the left side has a smaller font than the right
<beuno> I understand why it's doing that, but it's obviusly not the result we want
<beuno> do you have any thoughts on this?
<sinzui> beuno: The right side may have something vestigial from from the old template. I moved the content without thinking...
<sinzui> beuno: note that the value is not under the label
<sinzui> oh!
<beuno> yeah, but not everything is under a label, so in many pages it looks off
<sinzui> beuno: salgado: I think I just said the answer. The left is <dl> which may be a little smaller, the right is not.
<beuno> I'm tempted to unify the sizes
<sinzui> beuno: salgado This example is struggling with the flaw in yui-grid, namely, the grid. We have been careful to selecte guaranteed content for the right side and format it. but in this example, the content is not formatted yet, and I am not certain it is guaranteed.
<sinzui> beuno: salgado. since there is so much content we could pack in the user info section I propose we
<sinzui> 1) merge the involvement into info
<sinzui> 2) place long values in the left
<sinzui> 3) use two-column-list for short values on the right.
<beuno> I think that sounds like a good middle point
<beuno> I'd be on board with that, if it looks good   :)
<beuno> now
<beuno> I have a lovely girl staring at me making me keep my promise that I'd return to my vacation after the second day of work
<beuno> I will be doing that now, and sneaking back to read email and private IRC pings
<bigjools> beuno: make schema
 * barry beats pagetitles.py with a baseball bat
 * maxb warns jml and rockstar against installing any karmic updates right now
<barry> maxb: uh oh.  i updated about an hour ago
<maxb> uh oh
<maxb> you might not want to reboot any time soon
<barry> maxb, salgado btw, python-boto is not a lp-dev-dep?
<barry> maxb: too late :(  what broke?
<maxb> X ? :-)
<maxb> dbus, hal, you name it
<barry> maxb: i must have made it under the wire, as my interaction on this irc channel is proof of :)
 * barry types into an emacs buffer
<salgado> barry, doesn't seem to be
<barry> maxb, salgado i did my first ec2 about 20m ago and needed to install python-boto by hand
<maxb> That might be an oversight, or it might be being kind to those of us who can't ec2test anyway :-)
<barry> maxb: ;)  we really need to fix that
<maxb> If you do, I will probably be more motivated to look into the state of python-boto on karmic :-)
<fromvega> which language is used to code launchpad?
<rockstar> maxb, thanks for the heads up.
<salgado> fromvega, python
<fromvega> tks
<rockstar> barry, maxb, I also wondered that last night when I did my first Karmic ec2test run.
<mwhudson> good morning
<maxb> mwhudson: hi
<mwhudson> gary_poster: did you see i finally have a single command to update the ec2test AMI?
<maxb> should you have a free moment in the next few hours, can I interest you in looking again at py2.5-unittest-compatibility?
<mwhudson> maxb: sure
<gary_poster> mwhudson: no!  cool!  where is it?  utilities?
<mwhudson> gary_poster: ./utilities/ec2test.py --update-image
<gary_poster> mwhudson: wow, awesome
<mwhudson> gary_poster: there's a better version in bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/cache-the-download-cache that i'm currently landing
<mwhudson> today is probably separating ec2test into something that has subcommands
<mwhudson> ec2 demo, ec2 update-image, ec2 test
<mwhudson> it's nice to know there's at least one site on the internet that's slower than launchpad: linkedin
<maxb> ugh
<maxb> Compare the page load time for a bug with many bugtasks between lpnet and edge
<maxb> MAJOR regression
<maxb> e.g. bug 237356
<mup> Bug #237356: iMac build-in iSight "Failed to resubmit video URB (-45)" <luvcview (Ubuntu):Fix Released> <https://launchpad.net/bugs/237356>
<maxb> oops
<maxb> e.g. bug 427356
<mup> Bug #427356: Boot Performance Updates <acpid (Ubuntu):Fix Released> <anacron (Ubuntu):Fix Released> <apport (Ubuntu):Fix Released> <at (Ubuntu):Fix Released> <avahi (Ubuntu):Fix Released> <cron (Ubuntu):Fix Released> <cryptsetup (Ubuntu):Fix Released> <cups (Ubuntu):Confirmed> <dbus (Ubuntu):Fix Released> <debhelper (Ubuntu):Fix Released> <gdm (Ubuntu):Fix Released> <hal (Ubuntu):Fix Released> <hostname (Ubuntu):Fix Released> <ifupdown (Ubuntu)
<mwhudson> yay mup
<maxb> bug 430288 filed
<mup> Bug #430288: Major page load time regression in 3.0-dev for many-bugtask bugs <Launchpad Bugs:New> <https://launchpad.net/bugs/430288>
<mwhudson> hooray firefox
<mwhudson> abentley: i think the puller is working, but http access to branches was broken
<mwhudson> abentley: could that explain what you were seeing earlier?
<mwhudson> (all on staging)
<maxb> urgh
<maxb> who made the 3.0 builders page not show auto/manual?!
<maxb> Do we have any tags for 3.0 regressions?
<gary_poster> maxb: I have not heard of one
<wgrant> cprov: Any ideas how to make all the PRIMARY operations affect related packages in DEBUG as well? ISTM that we will have to change the scripts to look in both, and a few [SB]PPH and Archive methods to do so too.
<wgrant> This seemingly limited in scope task just got a lot harder :(
<cprov> wgrant: the publishing operations have to use 'archive IN %(main_archives)' when the context is a main archive, I guess
<cprov> wgrant: the problem is that each op use its own lookup, it's messy
<danilos> salgado-afk, barry: hi, did anything ever happen with breadcrumbs on "leaf" views?
<barry> danilos: salgado-afk is working on it.  not sure if it's landed yet or not
<danilos> barry, do we have some decision on what it's going to be? eg. text or label property? (so we can start solving it even before the breadcrumbs provide it)
<barry> danilos: it will be view.page_title
<barry> danilos: however, that does only sets the last component in the breadcrumbs
<barry> danilos: it does not override the <title> unless also view.override_title_breadcrumbs = True
<wgrant> Argh. So many unStormified queries.
<danilos> barry, hum, I am surprised... what happens with the overrides of the page title then?
 * barry must remember to update the wiki page
<wgrant> Stormified ones would be easier to fix :(
<barry> danilos: by default, nothing.  or maybe i misunderstand the question
<danilos> barry, ok, so it's kinda kludgy, but will work for me :)
<barry> danilos: yeah, salgado-afk and i thumb wrassled over it :)
<danilos> wgrant, sorry about that, but stormified queries are sometimes harder to optimize (i.e. postgres can choose a bad query plan based on *text matching*; I've seen that with things like "AND is_something" vs. "AND is_something IS TRUE", depending on what exact condition is in the index, i.e. how it's spelled out)
<danilos> barry, right, thanks for the tip, very good to know
<wgrant> danilos: Ew ew ew.
<danilos> barry, however, I somehow have a feeling LaunchpadForms should use the `label` for it
<danilos> wgrant, of course, most of the non-storm queries are just old, never migrated code, but there are a few queries like these
<barry> danilos: wiki page updated
<danilos> barry, anyway, that's just random musings, having something is a great improvement
<danilos> barry, thanks!
<barry> danilos: you might be ultimately be right.  it would be easy to change and it would be nice to DRY.  maybe see what salgado-afk thinks?
<barry> danilos: sure!
<danilos> barry, can you please post to the list as well so everyone else can start figuring breadcrumbs in before Friday?
<barry> danilos: +1
<danilos> barry, sure, not sure if we can make it happen this week (i.e. I'd rather have something people can rely on than keep changing it this week :)
<barry> danilos: good point.  we're cutting it to the wire, so let's keep what salgado-afk has
<thumper> barry: are you available for a quick call?
<barry> thumper: not right this sec, but could be in a bit
<thumper> barry: could you ping me when you have some time?
<wgrant> cprov: Since there are quite a few callsites, would it be a good idea to create a general solution and add a property on IArchive listing all grouped archives? For now that would only be useful for primary, but it would make queries much simpler and seems more future-proof.
<cprov> wgrant: archive.distribution.main_archives ?
<wgrant> cprov: No problems will occur if partner is included?
<wgrant> I guess not.
<thumper> mwhudson: got a few minutes?
<cprov> wgrant: no, there is no intersection
<mwhudson> thumper: sure
<jml> maxb, what's the story with karmic?
<barry> thumper: i'm going to grab some dinner and will ping you when i'm done
<barry> jml: karmic works great!  you need to install python-boto by hand if you wanna do ec2 though
<maxb> as far as upgrading goes? Don't yet. Give it at least one more publisher cycle at a minimum, or if you want to be safe, wait until tomorrow
<barry> with that caveat
 * barry -> dinner
<jml> maxb, can do.
<jml> maxb, thanks for the warning
<jml> any registry folks still around?
<mwhudson> jml: good morning
<jml> mwhudson, hello
#launchpad-dev 2009-09-16
<kfogel> jml: morning!
<mwhudson> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/430354
<mup> Bug #430354: BazaarBrachStore needs to use push --overwrite <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/430354>
<thumper> mwhudson: ta
<mwhudson> jml: the bzr-git tests are failing in that not-really-failing way :(
<jml> :(
<jml> kfogel, hi :)
<mwhudson> jml: do you know how i can find out what the failure actually is?
<jml> mwhudson, what are the circumstances?
<jml> mwhudson, I'm afraid I know next to nothing about the problem.
<mwhudson> jml: https://pastebin.canonical.com/22151/
<jml> oh _those_
<jml> mwhudson, I'll need a coffee to help you properly, but I think I've put most of the relevant info in a bug report
<mwhudson> jml: can you remember which bug report ?
<jml> mwhudson, I'm looking for it now.
<jml> mwhudson, http://twistedmatrix.com/trac/ticket/4003
<jml> there's one in Launchpad...
<mwhudson> i've found the launchpad one
<jml> mwhudson, what is it?
<mwhudson> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/425113
<mup> Bug #425113: Some tests can fail without detection <build-infrastructure> <Launchpad Foundations:Triaged> <Twisted:Unknown> <https://launchpad.net/bugs/425113>
<mwhudson> it wasn't triaged (!)
<jml> launchpad overall is rather poor at triage
<mwhudson> man wtf
<mwhudson> oh
<jml> mwhudson, it's a nasty problem.
<jml> mwhudson, I can try to address it if you'd like, but I'd really also like to finish off the permissions branch I've started.
<mwhudson> jml: i'll dig for a moment myself
<jml> mwhudson, ok. let me know if you want context or to bounce ideas.
<thumper> mwhudson: how do you invoke ec2test now it is a module in the tree?
<mwhudson> thumper: ./utilites/ec2test.py is still tehre
<thumper> mwhudson: ok
<thumper> mwhudson: I noticed the move, but not the addition
<thumper> mwhudson: :(
<mwhudson> thumper: :( ?
<thumper> mwhudson: my "hack" of using an alias for ec2test doesn't work
<thumper> now it needs a path
 * thumper changes the symlink to an alias
<barry> thumper: ping
<mwhudson> jml: a fairly small hack to zope.exception gets things working again
<jml> mwhudson, oh nice.
<jml> mwhudson, diff?
<mwhudson> jml: well what's in eggs isn't in a bzr branch of course :/
<mwhudson> jml: but it's "f.f_locals" -> getattr(f, 'f_locals', {})
<jml> *nod*
<thumper> barry: hi
<jml> mwhudson, I still suggest twisted should change...
<barry> thumper: hi will you be around for a while?  i need to run out before the stores close
<thumper> barry: yeah, although I might head out for coffee and lunch soon
<barry> thumper: no worries.  it's gonna be 45m-1h anyway i'm guessing
<barry> thumper: will ping you when i get back
<thumper> ok
<mwhudson> jml: yes, but in the interests of not having undetected failures in our test suite...
<jml> mwhudson, oh yes.
<jml> mwhudson, I'm very happy to have urgent bandaids applied
<mwhudson> jml: maybe this is a cleaner/easier band-aid:
<mwhudson> from twisted.python.failure import _Frame
<mwhudson> _Frame.f_locals = property(lambda self: {})
<jml> mwhudson, yeah, I think so.
<jml> mwhudson, is there anything you'd like me to do wrt this?
<mwhudson> jml: review this branch in a bit, i guess
<jml> mwhudson, ok, thanks.
<jml> maxb, your unittest branch is up for review
<maxb> ok
<maxb> or was that a question?
<maxb> I know it's up for review, I marked the MP as such
<maxb> karmic appears safe again, btw, on amd64 and i386, at least if you're using archive or gb.archive
<mwhudson> oh, phew, the failures in the bzr-git tests are really shallow
<jml> maxb, sorry, yes it was a question.
<jml> maxb, I'll review it :)
<jml> oh, in fact I have
<jml> hurrah
<maxb> You reviewed it without realising?
<maxb> :-)
<maxb> jml: "peculiarly" as in "why repeat an operation that your base class is already doing?"
<jml> maxb, it's been a very distracted morning
<jml> maxb, iirc, it's there for Python 2.3 support
<jml> but I can't recall exactly.
 * jml does a science thing
<maxb> fair enough (and that'll be 2.4 support)
<jml> maxb, Twisted supports python 2.3 :)
<maxb> ok, 2.4 and earlier
<maxb> It's just a different way of providing such compatibility to which other TestCase subclasses have taken, and less intrinsically clear that it's there for compatibility
<maxb> hmm, I need to write more branches, that's my last one :-)
<jml> right.
<jml> "WARNING: The following packages cannot be authenticated!"
<jml> the list includes libc6.. wtf
<mwhudson> sadness is submitting a merge proposal at ??:?5:?? o clock
<jml> yeah.
<jml> Somebody should do Something about that.
<maxb> What's special about ??:?5:?? o clock ?
<jml> maxb, the diff on MP pages is generated by a cron job that runs at ??:05:??
<jml> rather than by, say, some daemon that's listening for events
<mwhudson> jml: thanks for the review
<jml> mwhudson, np
<barry> thumper: ping
<thumper> barry: pong
<barry> thumper: is this a good time to talk?
<thumper> barry: lets talk titles :)
<thumper> yes
<barry> thumper: cool.  skype?
<thumper> yep
<barry> firing it up
<jml> barry, hey
<barry> jml: hi
<jml> barry, I know you're talking to thumper right now, but do you know what's going on with the '+filebug' thing appearing in page titles?
<jml> actually what I mean to say is... look at the bug I'm about to link to :)
<barry> jml: salgado was supposed to be landing a branch that allowed views to fix this.  don't know if it landed yet
<jml> barry, but individual views must fix this?
<barry> jml: i haven't looked at his branch, but i believe this is the case.  there was some talk about labels getting in the act but dunno what the state of that is
<jml> barry, ok, thanks.
<jml> barry, it's a little sad that the default is quite so wrong
<barry> jml: agreed
<jml> barry, is there something we can do to improve the default?
<jml> (also, would it be more convenient for me to raise this on the list?)
<barry> jml: i think it would be better to raise it on the list.  i'm not sure what the state of salgado's branch is, or exactly what it changes
<jml> barry, ok, thanks.
 * jml away for a bit
<wgrant> Erm.
<wgrant> Why do I see tests for the new braindead titles?
<sinzui> wgrant: because we are out of time to do page conversions. It is faster for me to convert pages and send people to add the need breadcrumb adapter afterward
<sinzui> wgrant: salgado has a branch that fixes most of the bad breadcrumbs, that will also fix the titles
<wgrant> sinzui: Ah, thanks.
<sinzui> wgrant: I think I can send every team member to fix breadcrumbs after tomorrow
<wgrant> launchpad-project 3.0 is timing out: OOPS-1355EB146
<wgrant> Ah, there we go.
<wgrant>     At least 1397 queries issued in 15.77 seconds
<wgrant> Ah.
<thumper> phew
<thumper> wow
<thumper> which project?
<thumper> launchpad-project?
<wgrant> thumper: launchpad-project?
<wgrant> s/?/./
 * thumper wonders where all the queries are :)
<ajmitch> 1397? that's a little high
<wgrant> thumper: Doesn't the OOPS tell you?
<thumper> wgrant: well, yes
<thumper> wgrant: well, yes and no
<thumper> it'll tell you what they are, but not where they are called from
<wgrant> thumper: Ah.
<wgrant> I haven't looked extensively at the OOPS format.
<thumper> SELECT BugTag.bug, BugTag.id, BugTag.tag FROM BugTag WHERE BugTag.bug = %s ORDER BY BugTag.tag repeated 700 times
<wgrant> Ah, of course.
<thumper> SELECT OfficialBugTag.distribution, OfficialBugTag.id, OfficialBugTag.product, OfficialBugTag.tag FROM OfficialBugTag WHERE OfficialBugTag.product = %s ORDER BY tag 394 times
<thumper> I'm sure it is fast with no data
<thumper> :)
<wgrant> Indeed.
 * wgrant files a bug.
<wgrant> Is that malone or launchpad-registry?
<sinzui> wgrant: is that the 3.0 milestone page?
<wgrant> sinzui: Yes.
<sinzui> rock
<sinzui> That is my excuse to remove the tags
<wgrant> That does not follow.
<wgrant> Ah.
<sinzui> I think it makes the list hard to read, and I do think they help me understand the bugs I am seeing
<wgrant> sinzui: Did you mean "I do not think they help me[...]"?
<sinzui> wgrant: yes.
<wgrant> sinzui: They should be useful, but are not in their current location.
<wgrant> sinzui: And why do I have an empty sidebar on that page?
<sinzui> right
<wgrant> It takes up some large horizontal fraction of my screen, and is empty.
<sinzui> wgrant: You cannot subscribe to bugs on that page?
 * sinzui liked the page without the side bar
<wgrant> sinzui: I can't. That seems like a bug.
<sinzui> It is
<wgrant> Oh.
<wgrant> It's the project, not product, milestone page.
<wgrant> So it's not a real thing to be subscribed to.
<sinzui> right...
<sinzui> I can make the side discretional in the template.
<wgrant> sinzui: But that leaves a largely useless sidebar on other milestones.
<wgrant> Is there nowhere better to put the link?
<sinzui> I can use a horizontal list after the description. It breaks style and may confuse user, but *I* think it makes the page usable.
<stub> huh. I killed rocketfuel-get at the wrong point and managed to lock lp:~launchpad/lp-source-dependencies/trunk. Surprised pulling that branch requires a lock!
<wgrant> sinzui: Possibly put it at the bottom of the Activities portlet, with the bug stats?
<sinzui> wgrant: Edit and delete do not belong there.
<wgrant> sinzui: It's not editing in the traditional sense.
<sinzui> agreed, certainly not when the milestone has a release
<sinzui> I can make something that looks like the side portlets and float it to the right.
<wgrant> https://edge.launchpad.net/~wgrant/+archive/ppa/+packages does something not too bad.
<wgrant> Although I'm sure it breaks the guidelines.
<wgrant> It might be better if it had the same gray background.
<sinzui> It does, but a side portlet with one item is dumb
<sinzui> Yea. I will try that after I sleep
<wgrant> Great.
<thumper> sinzui: what's the status of the page_title breadcrumb?
<sinzui> salgdao is doing test fixes to the branch. I think I can land tomorrow
<sinzui> thumper: we have made it hard on him since we keep landing pages
 * thumper nods
<thumper> how come no one told me I needed to create a named IBreadcrumb adapter for "code"?
<thumper> I spent ages chasing why I wasn't seeing breadcrumbs
<sinzui> thumper: I'll ask salgado to explain what is happening
<thumper> sinzui: I think it'll help, but I understand it now
<sinzui> barry and salgado had a few meeting about this. I do not think their work plays well together
<thumper> sinzui: what would help is knowing how to add additional breadcrumbs
<thumper> sinzui: like "Active reviews for XYZ"
<thumper> I can create custom IHierarchy adapters (like we have now)
<thumper> I'm wondering if there is a simpler way
<sinzui> thumper, interesting problem. since crumb is a traversed object, I think you need to pop an object onto the stack, or ...
<thumper> it is a view, not an object
<thumper> I need to have a fake object that has a breadcrumb relating to the page
<sinzui> thumper: views are an object, that is why the view name is in the crumbs
<thumper> yeah, yeah
<thumper> ...
<thumper> I'm trying to fix my last few pages first
 * sinzui stumbles to bed
<thumper> I want to have a view that is registered against two interfaces
<thumper> the problem is that one object implements both interfaces
<thumper> :(
 * thumper wonders how helpful the #zope channel is
 * sidnei raises an eyebrow
<sidnei> thumper: you might get better help on #plone
<thumper> sidnei: really?
<sidnei> thumper: surely
<thumper> sidnei: ta
<BjornT> thumper: i don't see where the problem is. can you give an example of what you're trying to do?
<thumper> BjornT: normally zope complains if there are two directives that can apply to one context object
<thumper> BjornT: I have a view that I want for the majority of implements of IHasMergeProposals
<jml> back
<thumper> BjornT: but I want a special one for IPerson
<thumper> BjornT: and a person implements IHasMergeProposals
<BjornT> thumper: hmm, ok. i guess zope doesn't complain, but you don't know which of the views will get used for Person?
<thumper> I think it does complain
 * thumper checks
<BjornT> thumper: one solution would be to make IPerson inherit from IHasMergeProposal, except that registry shouldn't depend on code...
<wgrant> But Registry depends on *everything*... is that wrong?
<thumper> BjornT: it does right now
<jml> wgrant, it's a work in progress.
<stub> You might be able to do it by registering an adapter for Person -> view rather than IPerson -> view
<wgrant> jml: How will that work? Adapting things to ICodeProduct or whatever?
<jml> wgrant, well, we already do a great deal of that in lp.code
<jml> wgrant, see IBranchTarget, etc.
<wgrant> True.
<BjornT> wgrant: yes. in an ideal world, everything can depend on registry, but registry shouldn't depend on code, bugs, soyuz, etc.
<thumper> BjornT: however our API decisions violate that
<wgrant> BjornT: But that seems impractical unless a huge amount of adaption is involved.
<jml> wgrant, how it will work with the REST APIs is another, and much more interesting, question.
<wgrant> jml: True.
<thumper> BjornT: as we mix everything in
<jml> wgrant, "impractical"?
<jml> wgrant, dumping huge amounts of responsibility on Person and Product is equally impractical.
<thumper> BjornT: if there is interface inheritance, does it take the most derived?
<wgrant> jml: That's not impractical at all. It makes sense, unless you start splitting the apps up.
<BjornT> thumper: yes. i wonder, why do you need breadcrumbs for IHasMergeProposals? what does that view look like?
<thumper> BjornT: the breadcrumbs that beuno wanted was to show "Active reviews for XYZ" when looking at a bmp
<thumper> I'm not yet convinced
<thumper> but at least now I know more what I need to do to fix the breadcrumbs
<thumper> BjornT: I'm actually looking at the +activereviews registration
<thumper> BjornT: if I can register +activereviews against IHasMergeProposals, but specialise for IPerson
<thumper> BjornT: then that is a good thing
<jml> wgrant, I disagree.
<wgrant> jml: Why does it not make sense to have the methods of a Person on IPerson?
<jml> wgrant, it violates the principle of single responsibility
<wgrant> jml: A distribution has lots of binary packages. Distribution.searchBinaryPackages should not exist, simply because Soyuz owns BinaryPackageRelease?
<jml> wgrant, and they are not, intrinsically, methods of a person
<stub> thumper: You can avoid importing code into registry if you want. Create IPersonHasMergeProposals in code and attach that marker interface to Person in code's zcml.
<jml> wgrant, I'm not completely happy with the way we've decided to arrange our tree
<jml> and soyuz / registry seems a particularly thorny case
<wgrant> It is.
<wgrant> Some structural things ended up in Registry.
<wgrant> But others didn't.
<wgrant> And they're all very tightly bound to the rest of Soyuz.
<thumper> stub: but it adds a method that a person must implement
<thumper> stub: it uses the mixin idiom we use
<jml> wgrant, so I would love to hear of better ways to split up the tree
<stub> oic.
<thumper> although
<thumper> ...
<wgrant> jml: Run away!
<thumper> we could just adapt...
<stub> Indeed
<thumper> we have the technology
<BjornT> thumper: i think you can only do that, if IPerson inherits from IHasMergeProposals. looking at it, it looks like it does do that already. we have to think about how to handle this case with our new code structure
<thumper> stub: but right now, with the API, to give a person the abiltiy to getBranches we need a mixin
<thumper> BjornT: what are the planned changes?
<BjornT> thumper: IPerson is in registry, so it can no longer inherit from application-specific interfaces, like IHasMergeposals, IHasSpecifications, and so on
<wgrant> How is lazr.restful going to work?
<thumper> BjornT: I'd be happy for the change if we can work out the API
<thumper> it seems kinda kludgy right now
<BjornT> thumper: yeah. it's a nice idea in theory, but we don't yet know how to actually do it practically
<thumper> :)
<thumper> thinking is easy
<thumper> doing is hard
<jml> meh.
<jml> thumper, if you don't know what to do, you haven't finished thinking yet.
<thumper> :)
<thumper> true
<thumper> keep thinking jml
<jml> (but a good way to push thinking along is to do something!)
<lifeless> sounds like you want an Extension concept
<thumper> :(
<thumper> build failed
<thumper> no space left on device
<thumper> mwhudson: just rekick?
<mwhudson> thumper: yeah :(
 * mwhudson is reorganizing ec2tests command line parsing code
 * mwhudson is going to the pub later
<mwhudson> this is merely a happy coincidence
<jml> mwhudson, :D
<jml> which database are the tests using?
<mwhudson> launchpad_ftest
<mwhudson> which iirc doesn't actually exists apart from when a test is running
<mwhudson> it's copied from launchpad_ftest_template
<jml> thanks.
<jml> I'm trying to figure out why this apparently correct code isn't working.
<mwhudson> jml: soyuz hates you?
<jml> yes.
<jml> one day, I hope to make it afraid of me.
<thumper> sometimes zope is very cool
<jml> thumper, what's it done now?
<thumper> jml: registering views against IHasMergeProposals :)
<thumper> jml: what zope is good at
<jml> thumper, ahh yeah.
<thumper> jml: that with branch collection adaptation FTW
<jml> heh :)
<jml> thumper, jkakar has been sending me interesting emails about use of a similar pattern in landscape
<jml> I really must get around to actually reading them and maybe even replying.
 * thumper has just fixed (deleted) the last remaining old style template for code
 * thumper EODs for now
<jml> thumper, yay
<jml> thumper, have a good evening
<jml> the relationships between soyuz objects are very complicated.
<mwhudson> (+1, understatement)
<jml> I just hope that this actual behaviour I'm reaching for makes sense.
<mwhudson> flymake-mode has changed my life
<jml> mwhudson, heh :)
<jml> mwhudson, any particular instance this time?
<mwhudson> jml: just help when refactoring
<mwhudson> jml: copy paste block of code into function
<mwhudson> jml: add arguments to function until pink goes away
<jml> mwhudson, yeah.
<jml> that's a nice thing
<jml> although it always makes me wonder how much more automated it could get
<lifeless> brm
<jml> never really made my life any better when I used it
 * mwhudson EODifies
<mwhudson> jml: want to review this branch chock full of fun tomorrow?
<mwhudson> it's here for now bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/ec2-entrypoints
<jml> mwhudson, yes.
<jml> mwhudson, I might even review it today...
<mwhudson> jml: it needs docstrings, i know that much
<jml> heh heh
<mwhudson> oh and copyright headers and __all__ and so on
<jml> *nod*
<wgrant> jml: What are you fighting with Soyuz about this time?
<jml> wgrant, permissions, still.
<jml> wgrant, but I think I've won this battle
<maxb> jml: what was your feel on my py2.5-unittest-compatibility? You did "review approve" but not "merge approve"
<jml> maxb, I review approved.
<jml> maxb, but I confess I forgot that you can't land branches yourself :)
<jml> maxb, so I was expecting you to change the comment or not at your discretion and then land it :)
 * maxb reminds jml that self-landing is not an option :-)
<jml> maxb, do you want to tweak the comment? if yes, please do so and poke me. if not, I'll land your patch now.
<lifeless> maxb: what is the thing you find odd?
<lifeless> maxb: or rather what makes it odd to you?
<maxb> that it should redo logic that its base class's __init__ does too
<maxb> ok, one edited comment coming right up
<jml> maxb, heh, thanks :)
<maxb> I'd lost track of whether the "peculiarly" was in the BMP or the code itself
<lifeless> urgggle, unitteset._CmpToKey
<lifeless> that really should be in e.g. list.something
<jml> I'm doing too many tasks at once. Please give me a moment while I serialize a few of them.
<maxb> jml: "chooses to write to it .... as part of its own method of arranging for pre-2.5 compatibility" ?
<jml> maxb, perfect.
<lifeless> I must admit to curiousity about why the property is needed
<lifeless> I'm guessing something is being naughty
<maxb> pushed, many thanks for the attention during this branch's bumpy path to this point
<jml> maxb, np. I'll land that now.
<mwhudson> good grief, ec2 demo works
<jml> zomg.
<poolie> jml https://bugs.edge.launchpad.net/launchpad/+bug/430504
<poolie> (no action needed)
<mwhudson> (which probably isn't true on trunk btw)
<jml> mwhudson, has your headless improving branch landed on stable yet?
<mwhudson> jml: dunno about stable, it's in devel though
<jml> mwhudson, ok. I'll run from there, see how things work out. :)
<maxb> what's ec2 demo? make run, in an ec2 instance?
<wgrant> Yep.
<wgrant> Woah. ec2test is split.
<jml> heck yes
<jml> mwhudson has skills.
<jml> also, ec2test --headless takes much less time. hurrah.
<jml> maxb, your branch is submitted. you'll get an email when the test run finishes.
<wgrant> "# Perl allows for inplace editing unlike sed."
<wgrant> sed -i?
 * jml shrugs
<maxb> thanks
<maxb> bye
<jml> maxb, bye.
<jml> wgrant, you wouldn't happen to be rewriting it in Python, would you?
<wgrant> jml: Can't really do that without a public AMI!
<wgrant> And no.
<jml> oh. pity.
<adeuring> good morning
<jml> adeuring, hello
<adeuring> hi jml!
<mrevell> Guten morgen
<jml> g'night all :)
<wgrant> bigjools: Available for a few ddeb-related questions?
<bigjools> wgrant: yes, ask away, but I am pretty busy and have a call in 5m so I'll do what I can
<wgrant> bigjools: Great, thanks.
<wgrant> bigjools: process-death-row currently crashes on copy/debug archives, because they lack an archive_url.
<wgrant> I guess it's important for debug archives, but not copy archives as they're not published.
<wgrant> Should I define an archive_url for debug archives?
<bigjools> wgrant: yes, sounds sane
<bigjools> wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/244145
<mup> Bug #244145: process-death-row script chokes on rebuild archives <derivation> <Soyuz:Triaged by al-maisan> <https://launchpad.net/bugs/244145>
<wgrant> bigjools: Ah!
<wgrant> bigjools: Second one: ddebs really want to follow their debs around very closely. I plan to adjust the ftpmaster-tools and various internal methods to search for binaries owned by a source inside the debug archive as well, and possibly add some extra magic to change-override and lp-remove-package to drag the ddebs along when their debs are operated upon directly.
<wgrant> Sounds sane?
<wgrant> Third: Copies are going to get pretty broken and confusing after this. Argh.
<bigjools> wgrant: gimme a few mins, I have a call
<wgrant> bigjools: Sure.
<wgrant> I wonder whether forcing the archive in newSourcePublication is enough, or if it should be done at a higher level...
<wgrant> Time to write lots of tests, I guess!
<bigjools_> wgrant: it would be good if you could send email to -dev to enumerate all the places you need to fix for ddebs in the separate archive, then we can have a think about it, it's a somewhat scary change
<wgrant> bigjools: I shall prepare an email -- I hadn't thought about this aspect of it until yesterday.
<bigjools> wgrant: great, thanks
<deryck> Morning.
<bigjools> beuno, deryck: https://bugs.edge.launchpad.net/malone/+bug/430593
<mup> Bug #430593: New milestone listing page's bug tags are easily confused with the description <Launchpad Bugs:New> <https://launchpad.net/bugs/430593>
<deryck> bigjools, yeah, that is confusing.
<bigjools> deryck: right-floating them would help, but ideally a separate column on the same line
<deryck> bigjools, ok.
<bigjools> deryck: and if you can fix bug 262545 at the same time that'd be *great* :)
<mup> Bug #262545: Milestone listings should show the bugs' titles/descriptions in a tool tip <milestone-management> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/262545>
<deryck> heh
<wgrant> Bonus points for reducing the query count (OOPS-1355EB146)
<bigjools> :)
<bigjools> oh wgrant, what's the issue with package copies and ddebs again?
<wgrant> bigjools: I guess delayed copies should be fine, but a direct copy with binaries between distroseries or to a PPA is going to require Magic to both pick up the right binaries, and put them in the right place.
<bigjools> wgrant: right
<bigjools> wgrant: reminder: you have until next wednesday to give me your top three 4.0 wishes
<wgrant> bigjools: I'd remembered that, but have so far received zero responses on the mailing list. I will send a reminder.
<bigjools> ok :/
<wgrant> Something like that.
<bigjools> if I don't get anything, then I'll proceed with what *we* think is important, which may not be the same as what you guys think
<wgrant> Of course.
<bigjools> ta very much
<wgrant> I'll hopefully be able to give you something, but I can't unless others give me something.
<bigjools> if you don't hear anything, your opinion would still be better than nothing
<wgrant> Possibly.
<BjornT> can someone with a recent SUCCESS mail from a ec2test run tell me how many tests were run?
<simon-o> Hi, I tried to send an email to launchpad-dev@lists.launchpad.net but got an error message. Is this a known error?
<barry> simon-o: what error did you get?
<simon-o> barry: http://paste.ubuntu.com/272035/
<simon-o> If I try to connect to lists.launchpad.net on port 25, I get a "Connection refused"
<barry> simon-o: yep, i just tried the same thing and got the same error
<barry> simon-o: thanks for letting us know.  i'll ping our admins
<simon-o> barry: thanks
<danilos> bigjools, I see you commented on the last buildbot failure: do you know what that might be about?
<bigjools> danilos: the usual out of disk space
<bigjools> no idea why, our buildbot expert needs to take a lookl
<danilos> bigjools, heh, ok, figured that much out myself... ok, thanks
<danilos> bigjools, would it be worth retrying the build?
<bigjools> danilos: that one was the result of re-trying... but no harm in doing it again
<barry> simon-o: try it now.  mta on that box was just restarted and i can telnet to it okay
<simon-o> barry: telnet works fine and the email got through. thanks
<barry> simon-o: cool
<danilos> gmb, intellectronica: is there a known problem with bug description editing ("Entity body is not a well formed JSON object")?
<jtv> It's failing on staging as well.
<gmb> Urrr...
<gmb> Not one that I'm familiar with.
 * gmb looks
<danilos> gmb, I think I've seen this yesterday as well, but attributed it to my epiphany-webkit usage... having tried again today with firefox, it's really not working for me
<jtv> Hmm... I tried editing another bug on staging and replacing the description with just "x".  That worked.
<wgrant> There's a bug for that.
<jtv> (At least I hope I did that on staging ;)
<danilos> gmb, perhaps intellectronica added something like if user.inTeam(rosetta_admins): no fancy ajax editing for you
<danilos> wgrant, ah, ok, I thought I'd ask first
<gmb> Heh.
<wgrant> Bug #424625
<mup> Bug #424625: use native python for manipulating images <Photo Frame Prep:New> <https://launchpad.net/bugs/424625>
<wgrant> Not that one.
<wgrant> Bug #424645
<mup> Bug #424645: Entity-body was not a well-formed JSON document. <Launchpad itself:Confirmed> <https://launchpad.net/bugs/424645>
<gmb> wgrant: Ah, thanks.
<danilos> wgrant, thanks
<danilos> and it's "Confirmed"... we don't use "confirmed" :)
<gmb> danilos, jtv: Can't reproduce it on staging or edge atm, but I believe you :)
<jtv> weirdly enough, on staging, I can enter the same text in a different bug.
<jtv> A-hah!
<danilos> gmb, reassiging the bug to malone, fwiw, you guys can take it from there
<jtv> I was adding it to another bug.  If I put it at the top, it seems to break.
<gmb> danilos: Righto.
<danilos> allenap, the base branch is devel, you can look at the diff for now, but I'll take a look at what's going on there
<allenap> danilo-afk: Don't do anything! It was my fault.
<danilos> allenap, ok, and sorry about the wrong channel (though, we might be making kfogel happy :)
<allenap> danilo-afk: I pulled devel this morning, but it was on a different machine.
<danilos> allenap, heh, multiple machines are bad for your health
<allenap> danilos: Yes, I've not heard that one before, but I'll take your word for it :)
<intellectronica> danilos: that's a known problem. i think deryck might know a bit more about this
<danilos> intellectronica, cool, thanks
<intellectronica> danilos: and no, i have no objection for clerks from other departments using ajax, as long as they fill in the correct forms (in three copies)
<deryck> intellectronica, danilos -- yeah, entity body bug is known.  I thought the bug was triaged for this cycle.  But the one I was just subscribed to isn't.
 * deryck looks
<deryck> bug 423924 is the one that will be fixed.
<mup> Bug #423924: Entity-body was not a well-formed JSON document when updating bug description <Launchpad Bugs:Triaged by deryck> <https://launchpad.net/bugs/423924>
<deryck> and geez, it's wednesday, I need to hunker down on some bugs.
<deryck> barry, ping
<barry> deryck: pong
 * gmb -> out for a while; back later
<bac> hi sinzui -- i'm looking for templates.  the page shows 8 outstanding.  any taken?  any suggestions?
<sinzui> bac: yes. We have a dependency issue with these last templates
<barry> bac: i will be looking for more templates to convert too
<sinzui> bac: barry: lets discuss how to land these during our call. Lots of things breack when person +edit changes
<bac> sinzui: ok
<barry> sinzui: +1
<BjornT> barry: ping?
<barry> BjornT: pong
<BjornT> barry: why does AppServerLayer start an smtp server?
<barry> BjornT: originally it was because the mailman integration tests need to talk to a real smtp server.  it's possible we could move that into the MailmanLayer now though (i'm not sure what, if anything else not in that layer depends on it)
<BjornT> barry: hmm. registry/tests/test_mlists.py seems to use the smtp server. could it use MailmanLayer, instead of AppServerLayer? or do you have any suggestion of an easy way of not hard coding the smtp port number?
<barry> BjornT: i don't think we want to move that to MailmanLayer.  One problem with that layer is that it doesn't run by default and we have an open bug on running it in a cron
<barry> i'll have to think about the port hardcoding; it was difficult last time so i punted ;)
<barry> gary_poster: we suck again ;/  let's just admit we won't get to this until after 3.0
<mrevell> gary_poster: ping
<barry> gary_poster: and by "we" i probably mean "me" ;)
<gary_poster> barry: are you talking about the reviewer bits?
<gary_poster> mrevell: pong (sorry was on call)
<barry> gary_poster: yep
<henninge> barry: has the heading situation changed, again?
<henninge> barry: on normal pages, I provide a 'label' that is placed as an H1 *above* the breadcrumbs, right?
<kfogel> danilos: you made me happy :-)
<barry> henninge: not for 2 days now afaik :)
<barry> henninge: you need a label on your view yes, but it maybe be an h1 or an h2
<barry> henninge: depending on whether your view implements IMajorHeading or not
<barry> henninge: and it should only implement that marker interface if your page is the +index page of the root context
<henninge> barry: yes, but I am not talking about the latter
<henninge> barry: does this look correct? http://people.canonical.com/~henninge/screenshots/pofile-details.png
<henninge> barry: or this http://people.canonical.com/~henninge/screenshots/pofile-translate.png
<barry> henninge: yep, that looks right
<barry> henninge: second one looks right too
<henninge> barry: all I do is provide a 'label', nothing else.
<henninge> barry: cool, thanks
<barry> henninge: right.  for most pages, the default just DTRT
<barry> well, default + 'label'
<flacoste> Registry has 8 templates left!
<flacoste> wow, this was a marathon!
<BjornT> barry, flacoste: does this patch look sane? http://pastebin.ubuntu.com/272138/
<barry> reviewers -> #launchpad-meeting
<flacoste> BjornT: if it actually solves the problem, r=me!
<flacoste> looks sane to me anyway
<BjornT> flacoste: thanks, it does solve the problem! well, i'll try to run the mailman tests, to make sure it didn't break anything
<barry> beuno: do you want to join us over in #launchpad-meeting?
<jml> maxb, you around?
<allenap> intellectronica: On https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/427356 (and almost certainly every other bug index), lp.picker and lazr.activator get run multiple times. By that I mean that the message "loading lp.picker" (and "loading lazr.activator") are logged many times.
<mup> Bug #427356: Boot Performance Updates <acpid (Ubuntu):Fix Released> <anacron (Ubuntu):Fix Released> <apport (Ubuntu):Fix Released> <at (Ubuntu):Fix Released> <avahi (Ubuntu):Fix Released> <cron (Ubuntu):Fix Released> <cryptsetup (Ubuntu):Fix Released> <cups (Ubuntu):Confirmed> <dbus (Ubuntu):Fix Released> <debhelper (Ubuntu):Fix Released> <gdm (Ubuntu):Fix Released> <hal (Ubuntu):Fix Released> <hostname (Ubuntu):Fix Released> <ifupdown (Ubuntu)
<allenap> intellectronica: I've tried to figure out why, but can't, unless YUI().use(..., 'lp.picker',...) is not using the already loaded version.
<allenap> intellectronica: Ah, YUI().use(...) creates a new Y, so I guess it must run each module again. That would explain things. Seems a shame to do this so many times in a page load though.
<maxb> jml: for a few minutes
<intellectronica> allenap: that's not a problem, other the annoying logging
<intellectronica> allenap: there are multiple pickers because there are multiple rows
<allenap> intellectronica: Yes. The thing is that the lp.picker library code is being run ~20 times. If we did all the initialisation of the bugtask rows in a single YUI().use() block, then it would only be run once.
<intellectronica> allenap: i'm not sure i understand. the module is only loaded once (yui takes care of that). the widget is being initialized 20 times if there are 20 widgets (two for each bugtask). i don't see any way around that, nor do i think this is a problem. am i missing something?
<henninge> Since when did test_suite become obsolete in unit tests? Does anybody know anything about this?
<henninge> Are tests added automagically now?
<allenap> intellectronica: I think YUI is running the lp.picker module ~20 times, rather than just once, because the "loading lp.picker" message is within the Y.add() in lp/picker.js.
<allenap> intellectronica: And lazr.activator is being run ~20 times too because it's required by lp.picker.
<intellectronica> allenap: oh wow, you're right. that is truly bizarre!
<bac> sinzui: call?
<intellectronica> allenap: i would have expected yui to only load the module once. that's the whole point, innit?
<BjornT> flacoste: call?
<allenap> intellectronica: Yeah. The file is cached by the browser at least. I think, to create the Y that's passed into the function(Y) {...}, it has to run each of the modules mentioned in the use(...) call.
<sinzui> bac yes
<intellectronica> allenap: it doesn't make any sense to me. sounds like a bug. if you have to run all modules each time yui use() them, then it means that you should have as few uses as you can. but that means that it really doesn't make sense to do it the way we do, where we isolate every call
<allenap> intellectronica: Put another way: YUI().use('mod', 'another_mod', function(Y) {...}) creates an empty Y object then runs mod and another_mod in that namespace.
<flacoste> BjornT: yes
<intellectronica> allenap: more annoyingly, to get around that, we'll need to somehow pass all row data in one go. that's doable, but we can no longer rely on the template to do that
<allenap> intellectronica: Yeah, agreed. I don't think it's a bug, but perhaps the amount we use it is excessive.
<sidnei> intellectronica: it is possible to cache the global YUI object, by doing 'Y = YUI().use()....' and then pass 'Y' into your function
<intellectronica> sidnei: aha! that's a nice solution
<intellectronica> allenap: i think that's definitely worth doing on the bug page, since there are so many call sites
<allenap> intellectronica: The other way of doing this is to put the row data in a hidden <span class="row-data">{...json...}</span>, then the setup can run once, find these and use them.
<intellectronica> allenap: that's a pretty nasty workaround. if we have to do that we might as well generate it all in the view, no?
<intellectronica> i mean the top-leve view, not the row view
<allenap> intellectronica: Yeah, you're right. Probably easier to test too.
<intellectronica> sidnei, allenap: you should totally write about that to the rhinos ml. i had no idea, and this is likely to become an issue as we add more ajax to pages
<sidnei> intellectronica: good idea
<allenap> sidnei: You or me then?
<sidnei> allenap: you? :)
<allenap> sidnei: Okay :) I might do it tomorrow, but sure.
<intellectronica> my appreciation of YUI3 just dropped significantly (though of course it was based on completely bogus premises)
<deryck> intellectronica, allenap -- admittedly I'm only scanning scrollback just now, but I wonder if this is better in the beta release, i.e. that modules are more smartly re-used?
<deryck> I'm talking about the YUI discussion
<intellectronica> deryck: no idea. i also thought that this is a feature yui3 provides, and so i'm inclined to believe that this is improved in future versions, but maybe i simply expect too much from yui
<allenap> deryck: It might be. I'll write to the list; maybe someone there will either know or find out. However, owing to how the Y objects are created, I doubt there's a ton that can be done.
<allenap> deryck: Well, not really how they're created, but the fact that a new one has to be built for each invocation of YUI().use().
<deryck> intellectronica, allenap -- ok, thanks for chasing this down.
<allenap> deryck, intellectronica: By the way, although this stuff is slowing down the bug page, I don't think it's what's causing bug 430288, unless there's a very indirect cause and effect.
<mup> Bug #430288: Major page load time regression in 3.0-dev for many-bugtask bugs <Launchpad Bugs:Triaged by allenap> <https://launchpad.net/bugs/430288>
<deryck> allenap, but your comments on the bug do indicate where you think the troubles might lie?
<intellectronica> allenap: also, if by 'load times' what is meant is really 'initialization time' it's worth changing the bug summary. i thought it's about the time it takes to render the page and send back the response
<allenap> deryck: Yes.
<deryck> allenap, cool
<deryck> I think of load time as the whole process -- server response through browser render.
<deryck> but maybe that is just me
<allenap> intellectronica: Good point. I've updated the description and title.
<intellectronica> nah, maybe i'm just not used to thinking about it because that wasn't traditionally a problem on LP (while rendering the page has)
<allenap> deryck: Me too, but in this case it's probably worth being specific because the server time is roughly the same between lpnet and edge.
<deryck> yeah, definitely agree we should be more specific.  Was more just thinking out loud about the phrase "load time"
<intellectronica> i think we can conclude that if you can think out loud of the phrase "load time" and the page still hasn't loaded then we've got a problem :)
<bigjools> how do I get an email with a diff in it from the MP page?
<bigjools> abentley? ^^
<abentley> bigjools: There isn't a way.  See bug #307461.  However, you should have received it from your launchpad-reviews subscription.
<mup> Bug #307461: Provide a way to start doing a review by email from web page. <code-review> <confusing-ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/307461>
<bigjools> abentley: ah forgot about that, thanks
<mrevell> night all, back on later
<kees> I have an API search that seems to be hanging forever
<kees> the UI works fine:
<kees> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=Signal%3A+11&orderby=datecreated&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=apport-crash&field.tags_combinator=ANY&field.has_no_package.used=
<kees>     tasks = lp.distributions['ubuntu'].searchTasks(tags='apport-crash', order_by='-datecreated', omit_duplicates=True, search_text="Signal: 11")
<kees> but the API never returns
<kees> (or rather, it seems to be loading them ALL before returning....)
<kees> strace shows activity
<kees> is there something that can be done about this, or a way to report back progress?
<rockstar> barry, do you know if it's safe to upgrade karmic packages yet?
<barry> rockstar: i haven't upgraded today.  i got lucky yesterday though; upgrading before the fubar
<barry> rockstar: you feeling brave? :)  i probably won't attempt it until after i finish the next branch i'm working on
<rockstar> barry, well, I'm getting weirdness, so I almost did it before I remembered what maxb said yesterday.  I'm just going to ignore it and try my best to get my work done.
<barry> rockstar: i'm pretty sure maxb said it was safe to upgrade late last night
<maxb> Yesterday's fubar was past by around 0200 UTC IIRC
<barry> maxb: thanks!
<maxb> I'm not ruling out *new* weirdness, though :-)
<barry> :)
<rockstar> maxb, can you get identical hardware to me and test before I upgrade in the future?  kthxbai
<rockstar> :)
<maxb> jml: PQM sulked, I take it? :-)
<rockstar> maxb, jml is .au - so he is probably sleeping right now.
<maxb> ah, ok. I've just got a second ec2test success email for a branch, so I'm assuming the first submission to PQM vanished somehow
<maxb> On that topic, how long is normal from ec2test submitting to PQM, to it actually landing?
<maxb> Should someone remind Florian Effenberger on launchpad-dev@ about the image licensing terms?
<intellectronica> maxb: depends what machine size you're using, but i believe it's somewhere around 4h these days
<maxb> no, I mean from when ec2test completes and hands off to PQM
<intellectronica> maxb: oh, maybe i didn't read the question right. once ec2 submits to pqm it's only about 5 minutes, unless there's stuff in the queue before that
<maxb> I guess the queue's busy today
<intellectronica> maxb: the queue itself is variable. some branches need a test suite run, others don't (and only take about 5 minutes)
<intellectronica> maxb: there are two branches in front of yours in pqm. neither need a test suite run, so you can expect yours to land soon
<maxb> revisions seem to be going into devel at about 20 minute intervals right now
<dhillon-v10> deryck: hi how are you
<deryck> dhillon-v10, hi, on call :)  Sorry
<dhillon-v10> finally got a hold of you :)
<deryck> dhillon-v10, were we supposed to chat today?
<dhillon-v10> i have some time do you?
<dhillon-v10> if not then we can talk later
<deryck> dhillon-v10, on call right now
<deryck> dhillon-v10, let me email you later
<dhillon-v10> oh, sorry
<deryck> np
<flacoste> gary_poster: that's what i get when running python bootstrap.py in lazr.restful: http://pastebin.ubuntu.com/272305/
<flacoste> any idea?
<flacoste> http://pastebin.ubuntu.com/272306/
<flacoste> and that's what i get if I try python2.5 bootstrap.py
<gary_poster> flacoste: not off hand no
<gary_poster> have not seen that
<gary_poster> flacoste: karmic?
<flacoste> gary_poster: no, Jaunty
<gary_poster> flacoste: ...python2.4 bootstrap.py works fine on karmic for me.
<flacoste> gary_poster: still fails here
<flacoste> python2.4 gives the same error than python2.5
<flacoste> python-setuptools isn't installed
<flacoste> but was in the past
<flacoste> i'll install again and try agian
<flacoste> gary_poster: with python-setuptools installed, python2.5 works
<gary_poster> flacoste: setuptools is not installed for me
<flacoste> but you are on karmic on a new install
<gary_poster> flacoste: it may be that installing and uninstalling leaves something unpleasant around.  would you like me to try that?
<gary_poster> i.e., do you want me to investigate?
<flacoste> gary_poster: nah, i'm moving on
<gary_poster> ok
<flacoste> if it happens again, i'll investigate
<flacoste> gary_poster: lazr.youpkg still has
<flacoste> sys.path.insert(0, 'src')
<flacoste> from lazr.yourpkg import __version__
<flacoste> in it, is that correct?
<gary_poster> probably.  we've fixed everything else
<flacoste> gary_poster: ok, i thought we didn't want to do this import try from setup.py anymore
<flacoste> but since you've fixed buildout
<flacoste> maybe we don't care anymore
<gary_poster> well, ubuntu still doesn't like it
<gary_poster> so it is worth changing
<gary_poster> I'll get to it
<flacoste> gary_poster: what's the new thing to do? use a static version in setup.py?
<flacoste> and no __version__?
<gary_poster> see how it is done in lazr.restful: version.txt in package, setup.py loads the value into __version__ by reading the file, and __init__.py uses pkg_resources
<gary_poster> to load it into __version__
<gary_poster> flacoste: actually, note that the __init__.py still has some old cruft: the try:except is no longer necessary
<flacoste> ok, thanks
<barry> sinzui: ping
<gary_poster> salgado: ping
<salgado> hi gary_poster
<gary_poster> salgado: hi :-) .  I need to convert the logintoken pages to the new templates.  I'm trying to figure out how to duplicate that locally so I can get a visual "before and after" check to make sure I have converted everything OK.  Do you have an idea on how I might do that?
<kees> how do I turn off caching in python-launchpadlib ?
<salgado> gary_poster, I think the fastest way would be to create logintokens of all different kinds inside a 'make harness' session and for each of them load 'https://launchpad.dev/token/<token>' for each of them before and after you convert.  does that answer your question?
<gary_poster> salgado: I think so, yes, thanks!  I'll do what I see at the beginning of logintoken-pages.txt
<barry> rockstar: ping
<barry> intellectronica: ping
<barry> EdwinGrubbs: ping
<rockstar> barry, hi
<salgado> gary_poster, np
<EdwinGrubbs> barry: pong
<barry> rockstar, EdwinGrubbs : hi.  can you do a quick ui review for a somewhat redesigned ~/person/+editemails page?
<EdwinGrubbs> barry: do you have screenshots?
<barry> EdwinGrubbs: yes: http://people.canonical.com/~barry/editemails.png
<rockstar> barry, if you have screenshots, I can do it now, otherwise it'll have to be a bit.
<barry> rockstar: ^^
<barry> EdwinGrubbs, rockstar it's not perfect.  i wish i could put that Add button next to the input field, but that page is kind of a hack and it's not feasible given timeboxing
<barry> EdwinGrubbs, rockstar still, i think it's better and i get to close an old bug 180349 as a bonus
<mup> Bug #180349: mailing list subscriptions page should link to team <mailing-lists> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/180349>
<intellectronica> hi barry
<salgado> gary_poster, btw, I have a question for you.  we have some tests that generate a request and append objects into request.traversed_objects, but having the tests define that is far from ideal so I'm wondering if it'd be possible to pass just the URL into the request and feed it to the publisher so that traversed_objects gets updated appropriately.  is that possible?
<barry> intellectronica: hi. sorry to bother you.  was looking for a ui review, but rockstar and EdwinGrubbs ponged me first ;)
<thekorn> kees, I'm turning off the cache at runtime for one of my scripts, let me try to find how I'm doing it
<intellectronica> barry: you are always welcome to bother me if someone else picks up the work eventually ;)
<thekorn> kees, wow, it is as simple as    launchpad._browser._connection.cache = None
<barry> intellectronica: :)
<EdwinGrubbs> barry: it seems like the displayname of the team should also be linkified. Actually, shouldn't you use the tales fmt:link which will give it a nice icon?
<barry> EdwinGrubbs: good point.  i'll see if i can fix that
<EdwinGrubbs> barry: ui=me
<barry> EdwinGrubbs: thanks
<gary_poster> salgado: ...yes, that should probably be doable, though I haven't tried it.  I would first try a test request and then do what zope.publisher.publish.publish does (get the publication, process inputs, and so on through maybe the "afterTraversal" call.  You might need to get your own publication...
<salgado> gary_poster, ok, I'll give that a try
<gary_poster> cool
<kees> thekorn: okay, thanks
<barry> EdwinGrubbs, rockstar http://people.canonical.com/~barry/editemails2.png
<EdwinGrubbs> barry: looking good, Mr. Carter
<barry> EdwinGrubbs: :)  thanks!  rockstar?
<rockstar> barry, I agree that the add button should be next to the input field, but that's a problem with FormView, not you.  r=me
<barry> rockstar: thanks man
<sinzui> barry: I think  "but that page is kind of a hack". Is an understatement. The page is a hack We need to reinvent it for 4.0
<barry> sinzui: yeah ;)
<sinzui> barry, have you really solved bug 180349
<mup> Bug #180349: mailing list subscriptions page should link to team <mailing-lists> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/180349>
<barry> sinzui: did you see the screenshot?
<sinzui> I am
<sinzui> barry: how did you get the label linked?
<barry> sinzui: i hacked the view to give me the team and the widget, disabling the widget.label.  then i render the team/fmt:link in one column and the widget in the second column
<sinzui> interesting. I will have to study this
<barry> sinzui: for some reason, it was a lot easier to manage this time around.  it mean it kind of surprised me.
<sinzui> I think the work with the license widget taught you all the options.
<mwhudson> morning
<thumper> salgado: has your page_title fix landed?
<salgado> thumper, no
<thumper> salgado: ETA?
<thumper> salgado: I'm wanting to work on the breadcrumbs for branches
<thumper> salgado: but I don't want all the "correct" stuff
<thumper> oops
<thumper> I want the "correct" stuff to start with
<thumper> rather than land stuff, then be told it is wrong or overridden with something else
<salgado> thumper, the only thing that will be overridden is the text of the last breadcrumb when you're on a page which is not the default one for that context
<salgado> we're currently using the page's name (as defined in the zcml) and after my fix lands we'll use the page's title (either view.page_title or the entry in pagetitles.py)
<sinzui> salgado: I do not think it should support pagetitles since we want to remove that file in 10 days
<salgado> sinzui, we're removing that file and moving all the titles there as view attributes or what?
<sinzui> salgado: We want to remove the module. No 3.0 page should use it. We will know on day 1 of week 0 if someone cheated
<thumper> sinzui: +1 on not falling back to pagetitles.py
<sinzui> salgado: I don't think you need to change your code, but i would delete a test for that feature rather than fix it
<salgado> sinzui, that's just not practical.  have you seen how many pages still take their titles from pagetitles.py?
<sinzui> salgado: yes. Sometime people do this right thing when threated with violence
<mwhudson> wow, markup flamewar on launchpad-dev!
<sinzui> salgado: I think a lot of developers have not cleaned out the pagetitle that is not being used
<sinzui> mwhudson: this is just a prelude for when we build wikis for user. Most probably know mediawiki, not moin
<gary_poster> salgado: most of these token pages use context/@@main_template/master .  The conversion guidelines suggest main_side or main_only for these, but locationless seems more appropriate.  Do you agree?
 * sinzui thinks investment in a gui editor will alleviate the need to fight the markup war
<salgado> gary_poster, yes, they should be locationless
<gary_poster> salgado: cool thank you
<maxb> What is the purpose of the ~launchpad-hackers team?
<kfogel> gary_poster: hey, I've got matsubara's branch that ports lp-bug-ifier to launchpadlib.  Do you do anything history-preserving when you port stuff from lp-dev-utils to launchpadlib/contrib/, or do you just copy the script?  If the latter, maybe I can save you some time?
<kfogel> maxb: some hysterical raisins, and I can't remember exactly what now...
<gary_poster> kfogel: just copy.  yeah, thanks, I won't get to that today, and I have some other things ahead of that for tomorrow too, though I might get to it then.
<kfogel> gary_poster: launchpadlib is not PQM-governed anyway, right?  I.e., if I can just push this in myself, I will; otherwise, I'll make a branch of launchpadlib and leave it for you.
<gary_poster> kfogel: it is not governed by pqm.  I found out recently that the desired way to handle these is to "co" the branch, merge in the changes from your branch, and commit the merge with the appropriate "[r=foo] bar" message
<kfogel> gary_poster: hmmm.  doing "bzr branch launchpadlib foo; cd foo; cp .../lp-bug-ifier.py .; bzr add lp-bug-ifier.py; bzr ci -m '[r=notsureyet] bar'; bzr push lp:launchpadlib"    is not the way?
<gary_poster> kfogel: no
<kfogel> gary_poster: I confess I'm surprised they would even have different effects; what's worse, I remember having this exact discussion (perhaps with you?) last week, and yet I still am expecting those two have the same effect.
<kfogel> gary_poster: anyway, diogo is the one who ported it, and you're the one I'm discussing this with.  Should I put "[r=gary]" ?
<kimus> should I file a bug for the statistics module see: https://lists.launchpad.net/launchpad-users/msg05474.html or it's ok in ML only?
<kfogel> kimus: reading
<gary_poster> kfogel: not with me.  you are probably right that it would have the same effect--to bzr.  It does not have a review in there--unless you are the reviewer, which is quite possibly your intent (effectively you are reviewing Diogo's work).
<gary_poster> If you wanted someone else to be the reviewer you would need to push your branch publicly first to have it reviewed, and then the process I described would be the right way.
<kfogel> kimus: yes, please, and feel free to include as many specific examples of useful stats in the bug as you can think of.
<kfogel> kimus: if the bug could contain a link to the archive URL above, that'd be great; that way we can get from the bug to the thread.
<kimus> sure kfogel
<kfogel> gary_poster: well, I think I'm not officially a reviewer, so [r=kfogel] is probably never formally correct, though in this case I did review his change of course.
<kimus> kfogel: what model? launchpad it self?
<kfogel> gary_poster: or when you said "does not have a review in there" did you mean "does not have to have a review in there" ?
<kfogel> kimus: yes
<gary_poster> kfogel: no I meant "does not have a review step in there."  In this case, I'd just use yourself as a reviewer, under the circumstances.  Not letting you be a reviewer for this feels...wrong.
<kfogel> heh
<kfogel> gary_poster: not all changes in the launchpadlib logs have a reviewer at all.  Is the r= even necessary?  I'm going to show up as the committer already.
<mwhudson> thumper: standup?  in a few minutes would be ok, then i could eat the toast i just made :)
<thumper> ok
<kfogel> thumper: don't let him eat the toast -- he gets violent
<mwhudson> thumper: ok to which part?
<thumper> mwhudson: eat your toast, we can wait a few minutes
<mwhudson> ok
<gary_poster> not all changes have "[r=...]" because people such as myself were bad, bad committers.  Or, well, we didn't know the desired result.  This commit message should be a "[r=kfogel] (merged for matsubara) add another internal file newly ported to launchpadlib" or something like that, AIUI.
<kfogel> gary_poster: I'll JFDI.  If it's a mistake, this is the way to find out.  Thanks!
<gary_poster> kfogel: well, we don't have automation here.  the way to find out that you did something is wrong is for a colleague to inform you of that...
<kimus> kfogel: done: https://bugs.launchpad.net/launchpad/+bug/431011
<mup> Bug #431011: Launchpad statistics <statistics> <Launchpad itself:New> <https://launchpad.net/bugs/431011>
<kfogel> gary_poster: that's what I meant
<kfogel> kimus: thank you
<gary_poster> kfogel: ok.   what I meant was, I was trying to inform you before a mistake was made :-)  but if we're on the same page then cool, all in favor of jfdi
<kfogel> kimus: I changed the summary to be more accurate
<kfogel> gary_poster: AH, gotcha
<kimus> kfogel: fine :-)
<kfogel> gary_poster: I just tested his script -- it works perfectly.  Review enough for me!
<gary_poster> kfogel: +1
<mwhudson> thumper: ready now
 * rockstar is ready too
<thumper> rockstar: skype doesn't think so
<mwhudson> rockstar: you didn't pick up ?
<rockstar> mwhudson, thumper, skype sucks?
<mwhudson> rockstar: yes
<mwhudson> my skype doesn't think you're online, but we know what that's worth
<thumper> rockstar: you still aren't picking up :)
<rockstar> thumper, call now, sound sorted.
<bac> hi mwhudson -- i just launched an ec2test --headless and it took 66 minutes to get it running and let go.  has something changed...for the worse?
<mwhudson> bac: !!!
<rockstar> bac, I definitely didn't see that just not when I launched 2 ec2tests
<jml> hello
<mwhudson> bac: that's terrible, did you notice which steps were taking the time?
<bac> mwhudson: i've got another coming up that i'll double check
<rockstar> ...and I pulled pretty recently.
<mwhudson> bac: also what machine version did it say you were using?
<bac> mwhudson: didn't specify a machine.  i thought the default was changed to be XL
<mwhudson> bac: i meant "Using machine image version %d\n'"
<kfogel> jml: hi
<mwhudson> bac: it's one of the first things the script prints
 * bac scrolls bac
<bac> er, back
<jml> heh heh
<jml> kfogel, hello :)
<jml> kfogel, want to join skype?
<bac> mwhudson: this it?  Using machine image version 16
<bac> mwhudson: i don't see anything that identifies the machine.
<mwhudson> bac: yes, that's what it should say
<kfogel> jml: yup, getting the headphones now
<jml> kfogel, cheers.
<bac> i wish the output had timestamps
<kfogel> jml: skype just dumped core
<kfogel> jml: no kidding
<jml> kfogel, :(
<kfogel> jml: yup, did it again
<kfogel> jml: let me see if there's an update real quick
<jml> kfogel, ok
<mwhudson> bac: yeah, i'd like that too
<kfogel> jml:  on
<mrevell> Good ol' Skype just died on me
<jml> mrevell, :(
<kfogel> mrevell: I had to upgrade at skype.com
<mrevell> jml: I'm back.
<mrevell> kfogel: seems ok now
<kfogel> jml: did you drop?
<kfogel> jml: I think we should set this up via canonical conf calling...
<kfogel> do you have a code?
<jml> kfogel, no I don't.
<mrevell> I'm getting crazy amounts of static
<mrevell> I *lurve* Skype
<kfogel> jml: we could hijack kiko's, maybe
<kfogel> jml: (action item: get you a code)
<jml> kfogel, heh
<kfogel> jml: (not a joke!)
<thumper> kfogel: you have several outstanding approved branches
<thumper> kfogel: are you going to land them?
<kfogel> thumper: I do?
<jml> kfogel, you were dumping a bunch of noise onto the line
<kfogel> thumper: I wonder what they are; I didn't know I had anything outstanding.
<kfogel> thumper: will look after this call
<kfogel> jml: uh
<thumper> kfogel: check out the approved section in https://code.edge.launchpad.net/launchpad/+activereviews
<kfogel> thumper: thx
<kfogel> jml, mrevell: um.  let's hijack kiko's code, and then jml can get a code of his own later.  thoughts?
<jml> kfogel, ok, sure.
<kfogel> jml: okay, I'll dial in.  If I'm first, I'll set it up.
<jml> kfogel, privmsg details please
<kfogel> jml: will do, one sec
<barry> jml, thumper, mwhudson, rockstar wanna meet today?
<mwhudson> barry: guess so
<thumper> barry: yes
<barry> -> #launchpad-meeting in 2m
<thumper> rockstar: lets have a call after the reviewer meeting
<rockstar> thumper, I'll probably have to walk the dog, but after that, sure.
<thumper> rockstar: ok
 * rockstar is assuming reviewer meeting is now.
 * thumper really hates pagetests
<wgrant> 3.0 is a week away now, isn't it?
<mwhudson> wgrant: that's the plan i think
<wgrant> Eek.
<mwhudson> i guess a delay is possible...
<wgrant> It's still all very unpolished, there is a big unresolved root context issue, and there is no UI designer.
#launchpad-dev 2009-09-17
<thumper> wgrant: you noticed#
<thumper> ?
<wgrant> The middle one hasn't had any attention, AFAICT.
<wgrant> (try going to a distribution source package, distro series, distro arch series, or product series. Click on tabs. Be confused.)
<thumper> :(
<thumper> :((
<thumper> build failures
<rockstar> thumper, call?
<thumper> rockstar: yes sir
 * jml is back
<jml> wow, the template conversion summary is pretty exciting
<jml> lots of "almost dones"... who will be next
<jml> mwhudson, hello
<mwhudson> jml: hello
<jml> mwhudson, do you want to talk at all about the entrypoints stuff?
<mwhudson> jml: did i send my reply yet? :)
<mwhudson> seems not
<mwhudson> jml: i have a half written reply
<jml> mwhudson, oh cool.
<jml> mwhudson, well, if you'd like to talk, let me know.
<mwhudson> jml: will do at some point today i'm sure
<jml> mwhudson, ok
<barry> jml: are we in testfix?
<jml> barry, I don't know.
<jml> https://lpbuildbot.canonical.com/builders/lp/builds/135/steps/shell_7/logs/summary seems to indicate some sort of failure
<barry> jml: blarg.  let me look
<mwhudson> find -name xx-*.txt | xargs rm -f
<barry> mwhudson: rs=me
<mwhudson> barry: don't tempt me
<thumper> sinzui, barry: should breadcrumbs have icons like the bug one?
<barry> thumper: i think they can.  "should they" is a beuno question :)
<thumper> hmm...
<barry> mwhudson: where's the candy-like history erase button when you need it?
<barry> got some family stuff to do now.  if no one else attacks those failures in the meantime, i'll take a look in a few hours.  ping me if you do though so i don't step on your toes
<thumper> barry: I want to be able to explicity say "don't add this view name to the breadcrumbs", can I?
<thumper> jml: this could give us better defaults
<thumper> jml: if we default to not adding the page name
<thumper> jml: but allow people to add it in
 * mwhudson lunches
<jml> maxb, btw, what happened with the first test run was that Launchpad was in testfix mode, thus rejecting new patches.
<jml> thumper, "this" being... explicitly saying "don't add this view name to breadcrumbs"?
<thumper> jml: yes
<jml> cool.
<beuno> thumper, barry, they should not
<beuno> salgado will fix that
<thumper> beuno: by "that" I take it you mean breadcrumbs should not have icons?
<beuno> yes  :)
<rockstar> thumper, that diff size was misleading.  Lots of it was deletions, which I don't review.  :)
<thumper> rockstar: I said that :)
 * thumper needs fun and caffeine
<thumper> heh
<thumper> typo: s/fun/fud/
<thumper> although fun would also be good
<bac> jml, mwhudson: i have a testfix branch to submit
<mwhudson> bac: great!
<mwhudson> bac: do you want one of us to review it?
<mwhudson> (or rs it, more likely)
<bac> mwhudson: no.  just didn't want to interfere with work you may be doing.  i fix one test and revert a revision that caused lots of failures.
<bac> i will rs it
<bac> barry: ^^
<mwhudson> bac: thanks a lot
 * thumper turns BranchHierarchy.objects into a generator
<thumper> hmm
<thumper> debugging generators is harder
<poolie> thumper, jml, hi, i'm just going to put my 2.1 timeline mail into launchpad milestones
<poolie> (silly old me)
<poolie> and just thinking about aligning them with launchpad milestones
<poolie> i see you don't actually use milestones?
<poolie> ):
<poolie> i mean :)
<poolie> oh maybe they're on launchpad-project but that oopses
<poolie> well, i'll just add the ones i want and then we can talk about them
<poolie> if we want
<thumper> rockstar: ping
<thumper> poolie: we do, kinda
<poolie> btw https://edge.launchpad.net/launchpad-project/+milestones times out fairly persistently
<thumper> poolie: I think that is a known issue, but not entirely sure
<thumper> poolie: there was one that was doing *a lot* of bug tag queries
<wgrant> That was the project group milestone page.
<wgrant> Not the milestone listing.
<sinzui> thumper: No breadcrumbs should not have icons.
<rockstar> thumper, pong
<dobey> hmm
<bac> mwhudson: fwiw, my next ec2 submission took 7 minutes...
<mwhudson> bac: that's rather better
<mwhudson> bac: how long did the instance take to boot?
<bac> mwhudson: dunno, wasn't paying attention
<mwhudson> bac: it's in the output if you still have that
<mwhudson> after all the ........................................................ that are near the beginning
<bac> 4:12
<dobey> is there any way to get the branch specified in the Vcs-Bzr: tag in a source package, via the LP API?
<mwhudson> bac: cool
<wgrant> dobey: No.
<mwhudson> boot time + three minutes isn't too bad, i think
<wgrant> dobey: But...
<bac> mwhudson: no, much better than last.
<wgrant> dobey: You should be able to assume soon that eg. lp:ubuntu/hardy/dpkg is the canonical hardy dpkg branch.
<dobey> but that is not what i want :)
<wgrant> What do you want to do?
<dobey> i want to get the sour package branch for a particular source_package_publishing_history in the LP API
<wgrant> You can't rely on Vcs-Bzr to be reliable for that.
<dobey> well i can't rely on anything to be reliable for it at the moment
<dobey> because there's no API to get it via LP
<wgrant> LP doesn't have that information.
<wgrant> Nothing does.
<dobey> i just want to automate the tedium of doing releases
<thumper> rockstar: sorry, missed pong
<dobey> because it's taking me a lot more time than i would like to spend, doing them
<thumper> rockstar: got a minute?
<dobey> and it's going to get more so, once i have to start dealing with stable branches vs. trunk
<dobey> i also wish 'person' had methods to query for bugs
<dobey> as i don't see any way to do a query for 'all bugs assigned to me'
<thumper> dobey: it can be done, but it isn't trivial
<dobey> well, the web does it, so i'm sure it's doable. i just don't see how to do it, and don't really want to go searching through web ui code to figure out how :)
<wgrant> There's no API for it.
<wgrant> There's a bug about that.
<wgrant> It's just not trivial.
<rockstar> thumper, sure. Skype?
<thumper> yep
<rockstar> thumper, just call
<thumper> trying to type while pinentry keeps popping up is an arse
<jml> why are so few of the exposed methods and properties on Person actually visible on the API docs?
<wgrant> jml: The attributes all show up on Team.
<jml> :(
<mwhudson> grr my brain isn't working very well today
<jml> wgrant, that's unfortunate.
<wgrant> jml: It is. That's what you get for doing mildly hackish things, I suppose.
<sinzui> implementing Team in a Person is also unfortunate
<mwhudson> hmm
<mwhudson> lifeless: does txAWS use boto under the hood?
<lifeless> nope
<lifeless> boto free
<lifeless> cleaner api
<lifeless> twisted!
<lifeless> and a teeny gui :>
<mwhudson> lifeless: 2.4 compatible, i guess?
<lifeless> dunno :)
<jml> lifeless, bram says Twisted is confusing :\
<lifeless> jml: its coding standards sure are!
<jml> lifeless, heh heh
<jml> lifeless, now _that_ I agree with.
<mwhudson> lifeless: how does it talk to the web service part?  i thought it was some SOAP horror show
 * jml needs to hack up a Twisted version of pep8.py
<mwhudson> i guess i can find this stuff out myself...
<jml> mwhudson, are you thinking what I think you're thinking?
<mwhudson> jml: probably
<lifeless> mwhudson: twisted.http.client thingy + xml
<mwhudson> wee, no setup.py
<jml> mwhudson, excellent. :)
<mwhudson> that's going to make building an egg nice and easy
<lifeless> use packages
<lifeless> they are better than eggs
<mwhudson> lifeless: "hnnnnnnnnnnnnnnnnnnnngh"
<mwhudson> in other news, loggerhead is terrible
<mwhudson> graar so is paste
<jml> yes
<mwhudson> DEB [20090917-03:40:51.803] [47331369258224] paste.httpserver.ThreadPool: Added task (128 tasks queued)
<mwhudson> stop spawning threads, stupid software
<jml> mwhudson, btw, do you still want a call today? If so, can we arrange a time now?
<mwhudson> jml: i think it would be a good idea, yes
<mwhudson> jml: any time in the next say three hours works for me
<jml> mwhudson, ok. let's talk now. :)
<mwhudson> jml: not so "now" eh?
<jml> mwhudson, skype did something
<lifeless> I hate the default reactor
<thumper> \o/ landing last of the code page 3.0 fixes
<thumper> now for those breadcrumbs
<jml> thumper, wooot
 * jml away
<thumper> mwhudson: the bzr.dev builder is showing weirdness loading the git plugin
<mwhudson> thumper: i guess bzr.dev is already at api version 2.1 ?
<mwhudson> thumper: a run against the 2.0 branch would be more interesting right now i suppose
<thumper> hmm...
<thumper> this brings up a question
<thumper> for the next 6 months of bzr development, what version is launchpad going to run?
<thumper> 2.0
<thumper> or 2.1b?
<lifeless> 2.1b please
<mwhudson> thumper: yeah, i think we more-or-less have to follow the "beta" line
<thumper> rockstar: breadcrumbs are up
<thumper> hmm..
<rockstar> thumper, I see that.
<thumper> ta
<thumper> mwhudson: got any idea how to run "make check" properly for cscvs and the new bin/py stuff?
<mwhudson> thumper: does make check PYTHON=~/canonical/checkouts/trunk/bin/py work?
<thumper> mwhudson: it won't here because I don't have that path
<thumper> I'd hate to see that in the Makefile
<mwhudson> thumper: i was assuming you'd change to point to a real bin/py
<thumper> mwhudson: on the commandline?
<thumper> :)
<thumper> sorry
<thumper> misunderstanding
<mwhudson> (i'm not sure it would work either)
<thumper> got it using the right python
<thumper> which hopefully will bring in the right bzrlib
<thumper> mwhudson: I'm looking at the 'unicode' object has no attribute 'branchName'
<mwhudson> thumper: ah, cool
<thumper> *hurl*
<thumper> if branch.__class__ is not types.StringType:
<thumper>             branch = branch.branchName
 * thumper tries to remember the base_string thing
<mwhudson> thumper: kill it quick, before it breeds
<thumper> isinstance(x, basestring)
<thumper> mwhudson: this is in the cscvs branch
<thumper> I don't think I have that set up :(
 * thumper looks
<mwhudson> thumper: well i guess i'm glad it's not in launchpad
<thumper> mwhudson, rockstar: either of you got a few minutes for a trivail cscvs fix?
<mwhudson> thumper: yeah
<mwhudson> thumper: where is this obscenity?
<thumper> CVS/StorageLayer.py:537
<thumper> I'm checking for others
<thumper> just the one
<thumper> mwhudson: that should account for the three failing CVS test_worker import failures
 * thumper checks
<mwhudson> thumper: https://pastebin.canonical.com/22200/ ?
<thumper> mwhudson: that is exactly what I have, and it passes the three TestCVSImport failures with 2.0rc2, r=me
<mwhudson> thumper: ok, i'm running the cscvs tests here, but if they pass i'll land it
<thumper> cool
<thumper> I don't think you'll have any problems
<thumper> that line has to be more robust now :)
<thumper> mwhudson: I was very tempted to replace all the 8 space indents though
<thumper> mwhudson: I almost went blind!
<mwhudson> thumper: :-)
<mwhudson> welcome to hel^Wcscvs
<thumper> mwhudson: an rs=me for any fixing of the whitespace in cscvs :)
<mwhudson> thumper: you can't trick me that easily!
 * thumper tweaks the stacking tests to use format="2a"
<thumper> :)
<mwhudson> thumper: the cscvs branch is in pqm's queue now
<thumper> mwhudson: cool
<thumper> mwhudson: I'm looking at the TestBranchPuller failures now
<thumper> mwhudson: it seems pretty mechanical, removing format='1.6' from places
<mwhudson> thumper: ah right, we use "1.6" to mean "some format that supports stacking" a bit i guess
<thumper> yeah
<thumper> mwhudson: is that going to take ages to get through?
<mwhudson> thumper: don't know
<thumper> mwhudson: I have a fix for the rest
<thumper> v.trivial thankfully
<mwhudson> thumper: happy to hear that
<thumper> mwhudson: can you review?
 * thumper is pushing now
<mwhudson> thumper: sure
<thumper> ta
<thumper> mwhudson: proposed, email should be through shortly
<thumper> mwhudson: I'm running it through ec2 now
<thumper> mwhudson: I'm expecting the CVS failures, but the others should be fine
<mwhudson> thumper: cool
<thumper> mwhudson: review diff up
<thumper> mwhudson: I'm going to make dinner now
<mwhudson> thumper: ok
<thumper> mwhudson: I'll check on the ec2s later
<maxb> Argh
<maxb> The lazr.enum import problems on karmic are back
<jml> :(
<jml> I'm done for the day. G'night all.
<noodles775> Night jml
<adeuring> good morning
<stub> mwhudson: with loggerhead, is generating a revision graph cache CPU intensive?
<mrevell> Morning
<maxb> Who's dev-ing on karmic these days, I could use a fails-for-everyone-or-just-me confirmation
<maxb> See LaunchpadOnKarmic for tests which are failing these days for me even with python2.4
<wgrant> maxb: Both issues confirmed.
<maxb> thanks
<maxb> (and gah :-) )
<wgrant> Something like that.
<wgrant> Does buildbot use Hardy?
<maxb> On the plus side, as of last night, all of the interesting bits of my python2.5 branch have landed on devel
<wgrant> What remains? Just the s/2.4/2.5/?
<maxb> that, and an increased startup timeout for the test librarian which may or may not still be relevant
<wgrant> That zope.sendmail fix ended up upstream?
<maxb> Gary ran with that one and got it done :-)
<wgrant> Very good.
<thumper> losa: ping
<mthaddon> thumper: hi
<thumper> mthaddon: the pqm seems wedged, the csvcs merge of mwhudson hasn't seemed to progress for several hours
<thumper> mthaddon: is it the actual test run wedged, or just the ui?
<mthaddon> checking
<thumper> ta
<mthaddon> yeah, going to kill the job - see a few zombied processes
<mthaddon> thumper: I'm afraid he'll need to resubmit
<thumper> mthaddon: ok
<thumper> mwhudson: got that?
<stub> mwhudson: Do you know if generating the graph revision cache in loggerhead is cpu bound or io bound?
<thumper> night all
<bigjools> stub: any idea what would cause this simple query to take so long? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1355EC1268
<stub> bigjools: Something else must have had a lock on that row
<bigjools> yeah that was the only thing I could think of too, but I can't think what would
<stub> bigjools: I think it can also lock if there have been inserted rows not yet committed - until the commit happens, PostgreSQL can't tell if your update is going to cause unique constraint violations or not.
<bigjools>  good point
<stub> bigjools: Perhaps the trigger was another script hanging mid transaction?
<bigjools> no idea what would be updating stuff that Build references, unless ...
<bigjools> builder maintenance I bet
<bigjools> ok thanks stub
<stub> if rows have been updated in the builder table, that could block too since PG needs to validate the foreign key reference.
<bigjools> mmmm I get an error about diverged branches when rf-get is updating dulwich
<intellectronica> bigjools: did you try removing it and getting it fresh? maybe you've made some changes locally by accident?
<bigjools> intellectronica: definitely not made local changes!
<intellectronica> bigjools: anyway, i see that gavin just wrote about this to the list, so i guess you're not alone (although i just updated and didn't experience this)
<bigjools> I suspect someone uncommitted a revsion on LP
<bigjools> and those of us that had that revision are getting issues
<wgrant> bigjools: dulwich gets rebased sometimes.
<bigjools> I don't even know what it is :)
<wgrant> The Python git implementation.
<wgrant> Used by bzr-git.
<bigjools> ah
<BjornT> bigjools: it probably got replaced with another branch
<BjornT> bigjools: my local revno is 297, and lp:s one is at 413
<bigjools> yeah, when I did pull --overwrite a lot of stuff was deleted
<bigjools> fabulous rant by Cody about reST :D
<deryck> Morning, all.
<gmb> Morning deryck
<stub> bigjools: I got the same error doing an update the other day. I pull --overwrited my dunwich and things went fine after that.
<wgrant> henninge: From your new home page screenshot, it looks to me like there is no longer a way to get to the app homes.
<henninge> wgrant: you know what, I was just thinking about that ... ;-)
<henninge> seriously
<wgrant> henninge: Why should it be locationless?
<henninge> wgrant: hm
<henninge> wgrant: I went by Martins mock-up
<henninge> beuno' mock-up that is ...
<wgrant> Yeah.
<henninge> just trying to rattle his cage but I guess he is really not here ... ;)
<henninge> wgrant: maybe I'd put them in the list on the right, above the featured projects.
<henninge> or linkify from the list on the left for not logged-in users...
<wgrant> But that list is gone for logged-in users, isn't it?
<henninge> wgrant: yes, so it's either on the left or the right, depending on your logged-in state ...
<henninge> the right list is not visible for logged-out users
<wgrant> Ah, forgot that bit.
<henninge> normally I'd call this kind of inconsistency terrible, but usually people stay logged in once they have an account
<henninge> and very rarely use the hompage.
<wgrant> Right.
<henninge> at least, that is my expectation, don't have any figures on the logg-in-out behaviour of LP users ... ;-)
<gmb> beuno: Hi; sorry to interrupt your vacation and all, but do you have a moment to take a look at lp:~gmb/launchpad/bugtask-index-conversion ? It's - well, it's the bugtask-index redesign branch.
<flacoste> morning Launchpad!
<flacoste> Code, Translations are done!
<flacoste> Registry -> 2 to go, Bugs -> 3, Answers -> 3!!!
<flacoste> blueprints -> 19
<flacoste> we are almost there
<barry> flacoste: the 2 in registry are going to be "fun"
<flacoste> right, person-edit and person-index
<salgado> person-index is done!
<barry> salgado: you rock!
<danilo_> salgado, do expect some test failures in your breadcrumbs branch, translations team just landed a few page_title introducing branches
<salgado> danilo-afk, ok, thanks for the heads up
<leonardr> BjornT, i'm being asked to clear out all my outstanding branches, which includes https://code.edge.launchpad.net/~leonardr/launchpad/remove-edwin-code/+merge/7253
<leonardr> i never merged that because i thought you wanted to use it
<leonardr> is that still true?
<matsubara> Chex, gary_poster, rockstar, bigjools_, henninge-bbl, sinzui, intellectronica, Ursinha: LP production meeting in 40 min at #launchpad-meeting
<BjornT> leonardr: i don't need that branch to be merged. the important changes were lines 32-35 in the diff, and that change is already merged.
<intellectronica> matsubara: allenap is the new intellectronica
<leonardr> bjornt: ok, i'll just merge it on my own
<matsubara> intellectronica, thanks. I'll update the MeetingAgenda page
<intellectronica> matsubara: we're training him in the stanislavski method. he's still working on the accent. be easy on him ;)
<intellectronica> matsubara: thanks
 * allenap quickly looks up stanislavski so he can take part in the charade
<dobey> in the API, is project_group.all_milestones sorted at all?
<bac> hi sinzui
<sinzui> hi bac
<intellectronica> allenap: http://en.wikipedia.org/wiki/Stanislavski's_system
<allenap> intellectronica: I'm there :)
<bac> sinzui: so the idea with person+edit is all of those g*&^%d(&ed lozenges go away, leaving a nice, clean edit page.  in doing so, a bunch of tests will break.  that's it?
<matsubara> hehe
<sinzui> bac: That sums it up
<bac> sinzui: what about the 'other actions'? will they stay at the bottom?
<sinzui> bac: I want them removed, but clearly that is a lower priority
<bac> ok
<bac> salgado: i've merged in your person-three-o branch into my work.  please let me know if you update it
<gmb> What? How can devel be out of date compared to my local copy? Has someone been uncommitting?
<salgado> bac, will do
<leonardr> intellectronica, can we have a short conversation about lp/picker.js?
<intellectronica> leonardr: sure. skype?
<intellectronica> leonardr: maybe ask EdwinGrubbs to join too? he knows much more about it
<leonardr> sure, but your name is on the code that concerns me
<leonardr> basically i'm trying to merge https://code.edge.launchpad.net/~leonardr/launchpad/remove-edwin-code/+merge/7253
<leonardr> which has been unmerged for a long time
<leonardr> basically it stops the javascript web service client from requesting an XML rendition of a resource and then parsing the xml
<intellectronica> leonardr: right, and meanwhile i've inlined some hacks to parse the xhtml result into picker itself
<sinzui> EdwinGrubbs: coordinate with gary_poster. He has started some of the tempaltes. He know which ones need love.
<leonardr> intellectronica: so when you do Y.DOM.create(entry) and all the code after that, that's parsing the xhtml?
<intellectronica> leonardr: yeah, that's a nasty hack for parsing the result
<intellectronica> well, parsing the result and getting the dom structure for the embedded value
<gary_poster> Thanks sinzui.  Hi EdwinGrubbs :-) thanks for review.  Trying to DTRT for those templates now.  I'm going to make a pastebin for me to share the info I have.
<leonardr> intellectronica: ok, the point we want to get to is where save() sends picker_result.api_url to picker._resource_uri + '/' + attribute_name
<leonardr> basically we tell launchpad to modify that single field
<leonardr> and the xhtml response we get back will be that single field
<leonardr> no need to parse anything
<intellectronica> leonardr: awesome
<intellectronica> leonardr: we still need to DOM.create to be able to use the result in a page, but there's no need to do all the complicated field by field iteration. that's really great
<intellectronica> well, i suppose we can use innerHTML too, that may be more efficient
<leonardr> intellectronica: ok, how would you feel if i simply put my new code into place and let you make the change to picker.js?
<intellectronica> leonardr: this is not a very good time to have broken code in trunk. maybe try to land both changes together?
<EdwinGrubbs>  gary_poster: it sounded like sinzui was suggesting that you had unconverted templates that I could work on.
<leonardr> intellectronica: i was saying that on the assumption your code wouldn't break
<intellectronica> leonardr: ok, maybe i need to understand how the new way of patching and retrieving a single field works
<gary_poster> EdwinGrubbs: http://paste.ubuntu.com/272894/
<leonardr> you already have the hack in place locally, and BjornT said the relevant part of my branch was already landed
<gary_poster> EdwinGrubbs: So you could take over anything in lines 30-end.
<danilo-afk2> leonardr, intellectronica: I am seeing doc/launchpadlib.txt errors in buildbot, would you guys know something about it? https://lpbuildbot.canonical.com/builders/lp/builds/141/steps/shell_7/logs/summary
<leonardr> intellectronica, take a look at line 32-35 of https://code.edge.launchpad.net/~leonardr/launchpad/remove-edwin-code/+merge/7253
<intellectronica> leonardr: if it doesn't break then that's fine. my only worry was that i'll have to take care of a broken result now, because i don't really have much time. if it doesn't break and just requires a cleanup later on then i'm happy to take care of that
<gary_poster> deryck: could you look at http://paste.ubuntu.com/272894/ , lines 38-46?
<danilo-afk2> (just because you are discussing launchpadlib, no other reason to think you might know more :)
<gary_poster> deryck: those are pages in "launchpad" that Francis said are for bugs somehow
<EdwinGrubbs> gary_poster: can I put that in a wiki page, so I can mark which ones I've started on?
<leonardr> intellectronica: i feel that if it was going to break, it would be already broken
<gary_poster> EdwinGrubbs: absolutely, that would be much smarter
<leonardr> danilo-afk2: it looks like the server isn't accessible when that test runs?
<deryck> gary_poster, looking
<gary_poster> ty
<intellectronica> leonardr: how did you test this?
<leonardr> intellectronica: i haven't tested it yet. i'm just trying to figure out where all the pieces of code go
<intellectronica> has it really been merged? if yes and we don't have problems then i suppose you're right and it doesn't break
<deryck> gary_poster, yes, that is correct.  We'll handle those, plus the structural-subscriptions-manage one.
<danilo-afk2> leonardr, ok, so it's not a new change, but probably spurious, thanks
<deryck> gary_poster, I'm doing a branch now for the non-hwdb ones.
<gary_poster> deryck: awesome thank you
<deryck> np
<intellectronica> leonardr: well, that's easy to test. let's merge it and try looking at a bug page with the result
<leonardr> all right
<gary_poster> EdwinGrubbs: ^^^ what deryck said (I'll put it on the wiki page if you don't, once you tell me where it is)
<intellectronica> leonardr: does it merge cleanly?
<leonardr> intellectronica: no, that's why i brought you into the conversation. my branch has a hack to picker.js that conflicts with your hack
<intellectronica> hmmm ...
<leonardr> well, my branch has code to send PATCH to the individual field
<intellectronica> leonardr: oh right, so we'll need to change that too to get the effect
<leonardr> if i know how to test it, i can probably get this working
<leonardr> just load a bug page?
<leonardr> am i, for instance, changing the bug status?
<intellectronica> leonardr: load a bug page and try to change the assignee or milestone. if they work then your change is good. if not, give me a shout and i'll look at what's going on together with you
<intellectronica> if that's ok with you
<leonardr> ok
<leonardr> i'll get this damn thing out of my life once and for all
<intellectronica> :)
<EdwinGrubbs> deryck: for all the non-hwdb templates?
<deryck> EdwinGrubbs, I'm doing the two non-hwdb ones.  I think abel will do the hwdb.  But someone on bugs will do those as well.
<deryck> This is bug 431916 for me.
<mup> Bug #431916: Remove bugbranch-delete.pt and structural-subscriptions-manage.pt  from lib/canonical/launchpad <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/431916>
<gmb> sinzui: So, I'm working on the bugtask-index redesign, according to the mockup that intellectronica did.
<gmb> sinzui: It's gone pretty smoothly but for one problem: we want the bugtask table to stretch across the page above the sidebar.
<sinzui> gmb....
<gmb> If I use main_side, that doesn't work. If I use main_only I don't get the sidebar
<sinzui> your question is timely
<gmb> sinzui: (This is because squashing the bugtask table looks *horrible*, btw)
 * sinzui checks is code landed
<EdwinGrubbs> deryck, gary_poster: Can you mark which ones you are working on that are still in the unassigned list: https://dev.launchpad.net/VersionThreeDotO/UI/TemplateToDoList
 * gmb waits with bated breath
<leonardr> intellectronica: it works on its own, i'm going to try to port my change
<intellectronica> lovely
<deryck> EdwinGrubbs, will do.
<gary_poster> EdwinGrubbs: looks good for me.  thank you
<sinzui> gmb: in the next 30 minutes there will be a CSS class called full-page-width that will extend into the sidebar
<gmb> sinzui: Nice! So, how would I use that in this instance?
<sinzui> gmb: I used it on the porlets around the bug and spec listing tables to take the full page
<gmb> sinzui: Can you point me at an example?
<gmb> (Or is this in the code that's due to land?)
<sinzui> gmb: it does not work when placed on a table that has the listing class, I placed it on the parent
<deryck> oh happy fortuitous day, gmb! :)
<gmb> deryck: Let's not count our chickens :)
<sinzui> gmb: <div class="portlet full-page-width">
<gmb> Eenteresting.
<gmb> sinzui: Thanks. Can you point me at a branch I can merge?
<sinzui> gmb: lp:~sinzui/launchpad/milestone-design-oops
<sinzui> ^ Look at a firefox milestone
<gmb> sinzui: Thanks! I'll take a look now.
 * deryck never counts chickens.  neva eva.
<gmb> sinzui: Looks good! I'll try it out on my bugtask branch.
<gmb> sinzui: Ha. So, that solved part of the problem. The bugtask table now stretches across the page. However, the sidebar stayed where it was. Let me have a play with this and get back to you.
<sinzui> gmb: yes. That is because of the z-index. I think some trickery is need to push the side content below the table
 * sinzui thinks
<gmb> sinzui: Your thinking is welcome :)
<leonardr> intellectronica: the http requests are going through but i'm getting strange errors on the client side
<intellectronica> leonardr: what errors do you see?
<intellectronica> want me to look at a branch?
<leonardr> intellectronica: not yet, just letting you know
<leonardr> intellectronica: ok, got it
<leonardr> i'll push a branch and we can discuss
<leonardr> i'm trying to patch the bug when i shoudl be patching the bugtask
<leonardr> the question is how to handle that in a general way
<intellectronica> leonardr: i can't imagine why you'd be operating on a bug. i don't think you even have the identity url for it anywhere there
<intellectronica> but yeah, i'll prolly understand better looking at the branch
<leonardr> ok, let me get things straight
<beuno> gmb, can I see a screenshot instead?  :)
<gmb> beuno: Sure. https://devpad.canonical.com/~gbinns/ss.png
<gmb> beuno: I'm currently trying to get the bugtask table to stretch across the top of the page, but as sinzui noted above there needs to be some trickery done to get the sidebar to not sit over the top of it.
<leonardr> intellectronica: i'm pretty sure there's a bug in lazr.restful
<beuno> gmb, the breadcrumbs aren't underneath the title
<intellectronica> leonardr: what's that?
<beuno> the "reported by..." should be in the heading area
<gmb> beuno: Ah, that's probably because I forgot to sort the title out :)
<gmb> (tunnel vision)
<beuno> convert to question looks odd iconless
<gmb> beuno: Ok.
<gmb> beuno: Yeah
<gmb> I was wondering if we had an icon for that action.
<beuno> maybe they should all be iconless?  don't know
<beuno> we don't
<sinzui> gmb: I suspect creating a slot in base-layout.pt for content to appear before the side lost may be easier. I am still thinking about how to tell the content to position itself relative to the table
<beuno> gmb, did you look at the mockup we did en buenos aires for this?
<gmb> beuno: In the mockup, Tom used something like (>) as an icon. I think ti would look odd if they were all iconless, especially since every other page has icons.
<gmb> beuno: No, the one that Tom sent out in his RFC email.
<gmb> That might be the same one.  I dunno.
<leonardr> intellectronica: when you navigate into a field resource it navigates based on the name of the interface field
<gmb> sinzui: Right, I was thinking along the same lines (but trying to get away without it ;) ).
<gmb> sinzui: I'll give the extra slot a shot.
<beuno> gmb, so first converting, then desiging it?
<leonardr> so /firefox/+bug/15/assignee_link doesn't work, you have to do /firefox/+bug/15/assignee
<mup> Bug #15: PO file import errors should be more verbose <feature> <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/15>
<mup> Bug #15: PO file import errors should be more verbose <feature> <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/15>
<gmb> beuno: I'm not clear what you mean.
<beuno> gmb, as for the icon
<leonardr> *but*, when lazr.restful tries to set the value, it uses the externally-facing name of the field. so *that* has to be assignee_link
<leonardr> but there's no way to specify assignee_link, so you can't modify that field
<beuno> gmb, you could grab some gimp, and recreate the dupe icon but with the question icon in the back instead
<gmb> beuno: Yeah, that sounds like a plan.
<gmb> I'll see if I can fix the bugtask table first.
<beuno> gmb, sorry I can't help much right now  :)
<beuno> also
<beuno> what would be SUPER AMAZING
<gmb> beuno: No worries. Some guidance is a good, though.
<leonardr> i'm going to file a bug for this, and i'm going to send you a version of the branch that doesn't change picker.js
<leonardr> go ahead and use the hack for now
<beuno> is doing what the mokcup shows
<beuno> which is "Add bugtask" instead of "als affects" twice
<beuno> which nobody ever ever ever knows what to choose
<beuno> if you fix that confusion
<beuno> you become my instant hero
<gmb> beuno: Heh. I'll see what I can do, but I'll get the design bit done first.
<beuno> gmb, that, to me, would be the single most important change on that page
<beuno> collampsing all those 3 options into one
<beuno> deryck, ^
<beuno> and
<beuno> maybe moving the "me too" out of under there
 * deryck looks at scrollback
<gmb> beuno: Right. One crisis at a time, thoguh :)
<beuno> like in https://wiki.canonical.com/Launchpad/UI/Bugs/ThreeDotO?action=AttachFile&do=view&target=bug_page_30.jpg
<beuno> gmb, I'm taking advantage of my gf making tea and not seeing me work
<gmb> Heh.
<beuno> I will probably disappear suddenly in about 2 minutes
<beuno> so I'm squeezing as much as I can  :)
<sinzui> gmb: I think cproc is landing the registration slot where you can place the:
<sinzui>     Bug #15 reported by Foo Bae on 2007-12-18
<mup> Bug #15: PO file import errors should be more verbose <feature> <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/15>
<gmb> sinzui: Ah, cool.
<deryck> beuno, you want something from me?  Or just looking for consent for gmb to become your instant hero? :)
<beuno> deryck, just to keep you in the loop and try to get you on board
<deryck> beuno, gotcha.
<beuno> now
<deryck> beuno, I'm certainly on board with that, but I think we need to be realistic about what can be accomplished in a day.
<beuno> they've cought me
<beuno> bbl
<sinzui> gmb: did you try wrapping the entire side content in a div with style="z-index: 10"? we may need a float: left instruction added to the table to let the portlets know that they can wrap around it
<gmb> sinzui: Hmm, no. Let me try that...
<intellectronica> hey beuno, have you got a sec to look at my work in progress bugs index page redesign?
<intellectronica> damn, the gf won
<beuno> intellectronica, she went to the bathroom
<beuno> GO GO GO
<gmb> sinzui: No joy.
<intellectronica> beuno: https://devpad.canonical.com/~tom/bugs-homepage-redesign-screenshot.png
<leonardr> intellectronica: do you by any chance remember the formulae for running the windmill tests?
<leonardr> i am pushing my code to lp:~leonardr/launchpad/get-field-uri
<leonardr> take a look at the code (it's a subset of what's already been reviewed) and if the tests pass i'll land it
<sinzui> gmb: what was the effect, content pushed out? insane wrapping?
<gmb> sinzui: No change at all :)
<sinzui> hmm.
<intellectronica> leonardr: https://dev.launchpad.net/Windmill but there are no tests for the bugtasks table yet, if that's what you're looking for
<beuno> intellectronica, I like it
<intellectronica> leonardr: also, i don't know if that hasn't changed now that BjornT_ is working on making windmill work as part of the general test suite
<leonardr> intellectronica: thanks for link. i am just trying to run the tests i added to this branch
<beuno> I don't know if I like the format for "bug supervisor..." etc
<intellectronica> beuno: how can we improve on that?
<beuno> names will be long, oit will wrap, it doesn't look like it does in other places...
<intellectronica> i really want to keep these links in one place so that people don't have to fish for them all over the page
<intellectronica> would you suggest moving it out of the sidebar?
<beuno> I think so
<beuno> bug tracker as well
<beuno> and just leave the action
<beuno> you could have it in the main content
<beuno> on  the right
<beuno> top right
<beuno> where the serarch is
<beuno> search even
<beuno> damn
<beuno> cought again
<beuno> bbl, I'm on strike 2 now
<intellectronica> beuno: another option is to have the title of the fields on a separate line. that way wrapping will be less of a problem
<intellectronica> laters
<beuno> intellectronica, gmb, email is easier for me  :)
 * beuno -> gone
<intellectronica> beuno: gotcha
<sinzui> gmb: I have a cracked proposal. Move the table to the side portlets. You need to add a position: relative, then play with the left: or float properties to align the table to the left side.
<gmb> sinzui: I like it. Let me fetch my crack pipe and get hacking.
<deryck> intellectronica, the screenie looks nice, man.  You've done some nice work there.
<sinzui> gmb: you may still need a z-index: 10 on the side portlets to ensure they flow with the table
<intellectronica> deryck: cheers. b.t.w you don't see the cloud because there's no data, but that looks nice too. now wrestling with the search box
<gmb> sinzui: Understood
<deryck> intellectronica, gotcha.  I like the border around the search area.  It gives us room to improve later as we try to play with improved search/filing ideas that we batted around but don't have time for now/
<deryck> intellectronica, how does the "Hot Bugs" section get built?  Just latest or latest touched?  Or some actual calculation of "hot"?
<intellectronica> deryck: for now it's just latest touched. but i think it's worth keeping it vague so that we can change the query later to something more sophisticated. what do you think?
<deryck> intellectronica, yes, agreed.  vague now to release, better later.  good call.
<leonardr> intellectronica: my new tests pass, and my code doesn't break any existing tests. if you'll bless my new diff, i'll land that branch, and come back to the bug (which i will now file) when i come back from holiday next thursday
<leonardr> if you, like me, feel slightly uncomfortable with the idea of me landing something and then going away for a week, maybe you'd like to take over the branch?
<intellectronica> leonardr: i'm not sure i understand. what's the bug? is everything on the bug page still working?
<leonardr> intellectronica: i have not removed your hack
<leonardr> the bug prevents me from removing it
<intellectronica> leonardr: normally i'd love to, but i have heaps to finish, so i can't realistically promise to look at it until we're done with all our 3.0 work
<leonardr> intellectronica: ok, i'll probably land it when i get back
<intellectronica> leonardr: in that case, feel free to file a bug and assign to me for doing that later on
<leonardr> intellectronica: the bug is in lazr.restful, so i'll fix it, and then file a bug for you to get rid of the hack
<leonardr> that's probably what you meant
<intellectronica> yeah, that's what i meant
 * gmb <-- taking a break for food; this is frying my brain. Back in an hour or so
<mrevell> night all
<maxb> gary_poster: My lazr.enum import pains on karmic are back again. Just wondering if you have any immediate thoughts on the issue, or if I should dig into it myself this weekend.
<gary_poster> maxb: argh!  no
<gary_poster> maxb: can you give me a traceback or something?
 * maxb slices a testlog
<maxb> http://paste.ubuntu.com/272968/
<gary_poster> so, back, with a new and amusing new face.
<gary_poster> or something.
<maxb> and mysteriously localized to codehosting bits
<gary_poster> oh.  well, that's a clue at least.
<gary_poster> maxb: to state the probably obvious, the tests I have looked at so far look like they are calling out in one way or another, and the paths appear to not be set up correctly.
<gary_poster> Unfortunately, it's not obvious to me on a skim how these things are calling making subprocesses.
<gary_poster> In any case, on the bright side from my perspective, and maybe yours, this appears to me to be something funky having to do with our test set up, rather than some breakage in zc.buildout.
<EdwinGrubbs> sinzui: I can't find a zcml entry for rdf-index.pt. Do you know where it is used?
<salgado> EdwinGrubbs, /rdf, maybe?
<salgado> that's it, just confirmed on launchpad/configure.zcml
<EdwinGrubbs> salgado: oh, it's not in the zcml directory. Thanks.
<bac> sinzui: did you create a bug for the person-edit conversion?
<sinzui> bac: No
<sinzui> sorry
<bac> np
<bac> i'll do it
<sinzui> I told everyone you were working on it
<bac> i just need me a number
<bac> it was supposed to be a surprise
 * sinzui told everyone who seemed to care at least
<sinzui> bac: I am in a call, If you want me to review it, I expect to be available in an hour
<bac> sinzui: ok
<barry> Edwin-lunch: when you're back from lunch, ping
<mwhudson> good morning
<jtv> hi mwhudson
<mwhudson> jtv: should i be telling you to go to bed?
<jtv> mwhudson: in a moment, but first you could do wonders for my ability to sleep by helping me with a notfound-traversals failure.  :)
<jtv> This is the grown-up software engineer's way of asking you to read me a story.
<mwhudson> jtv: rm notfound-traversals.txt ?
<jtv> Tempting...
<jtv> Basically I seem to have managed to replace a 404 for a certain nonsensical URL with a 500.
<jtv> BFD to me, but what do I know...
<mwhudson> 500s are pretty bad, i'd say
<jtv> true
<jtv> here's what I did: I added a Navigation & Breadcrumb for Language, and now /+languages/xx/foos (where xx is a language code) no longer produces a 404.
<jtv> Instead, ForbiddenAttribute: __getitem__ on Language.
<mwhudson> jtv: is there a GetitemNavigation somewhere?
<jtv> Yup
<jtv> Ahhhh
<mwhudson> jtv: kill it before it breeds
<jtv> now the name begins to make sense
<jtv> What do I put there instead?
<mwhudson> um
<mwhudson> i think just a Navigation
<jtv> Just kill?
<jtv> Ah
<mwhudson> (assuming there is actual navigation to be done, i guess)
<mwhudson> jtv: oh, you added the navigation?
<jtv> yes, without understanding much about it
<salgado> jtv, if you wait till tomorrow you won't need to add this Navigation as bug 423898 will be fixed
<mup> Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects <Launchpad Foundations:In Progress by salgado> <https://launchpad.net/bugs/423898>
<jtv> salgado: would that give me the breadcrumbs I crave?
<jtv> (and hi btw :)
<salgado> jtv, yes
<jtv> ooh
<salgado> you still need the Breadcrumb adapter, but a Navigation is no longer needed
<jtv> salgado: nice!  Using plan Navigation solves it all for now, so I'll just add an XXX referring to that bug.
<salgado> jtv, ok
<jtv> mwhudson: see?  Now I'll sleep a whole lot better.  :)
<mwhudson> jtv: yeah, a happy result!
<jtv> thanks, guys
<thumper> booting the laptop
<thumper> call shortly
<mwhudson> thumper: laptop busy fscking?
<thumper> :(
<sinzui> EdwinGrubbs: this bug relates to rdf https://bugs.edge.launchpad.net/launchpad-registry/+bug/6405
<mup> Bug #6405: /rdf page doesn't provide access to RDF exports <registry> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/6405>
<EdwinGrubbs> sinzui: Should I even bother trying to convert this now, since it will have to be changed so much in the future?
<sinzui> EdwinGrubbs: The page will not render if it is not converted. Just do the minimum to convert it. We need to rethink DOAP
<thumper> losa, mwhudson: the cscvs merge seems stuck on db comments again
<EdwinGrubbs> sinzui: is the macro:page/applicationhome also to be replaced by the new templates?
<sinzui> EdwinGrubbs: yes
<sinzui> Locationless or main_only
<Chex> thumper: this is the pqm queue, correct?
<thumper> Chex: yes
<thumper> mthaddon: pqm wedged again same as last night
<thumper> :(
<sinzui> EdwinGrubbs: If application button do not make sense for the page (/rdf) use locactionless. main_only is the default
<mthaddon> thumper: ok, so something in the code is causing a problem - can someone look into that?
<thumper> mthaddon: the change is in the cscvs branch itself, so it seems very screwy
<thumper> mthaddon: it isn't the branch that is landing that is at fault
<mthaddon> thumper: ok, so what's wrong with cscvs?
<thumper> mthaddon: one line change blocking bzr 2 from landing
<mthaddon> thumper: I guess I'm just asking if we can make a change that will stop this happening again
<thumper> mthaddon: I don't know what is wrong...
<thumper> mthaddon: it shouldn't block there!
<thumper> it is "make schema"
<thumper> I have no idea...
<thumper> Aaarrrrgggg!!!!!!!!!!!!!!!!!
<kfogel> jml: hey
<kfogel> where o where is my jml
<kfogel> thumper: those approved branches of mine you noticed yesterday -- they were already merged, somehow Launchpad just didn't know about it.  I've marked their status as "merged" now, so they'll no longer show up in activereviews.
<jml> kfogel, hello
<kfogel> jml: hey there
<thumper> kfogel: ok, ta
<jml> kfogel, computer problems prevented me from arriving sooner.
<jml> I was forced to wait on an fsck.
<kfogel> jml: if by "computer problems" you mean "fleet of leather-clad bikers wielding live armadillos", then sure.
<kfogel> jml: you know you can hit Escape to stop that, I think?
<jml> kfogel, I believe it's koalas, this cycle
<jml> kfogel, ha ha ha
<wgrant> Ah.
<kfogel> jml: the escape thing wasn't a joke...
<wgrant> So that's why everyone is having problems, but nobody can work it out.
<jml> kfogel, it doesn't work
<wgrant> rocketfuel-get is broken for non-Canonicalites.
<kfogel> wgrant: !!??
<kfogel> jml: one second while we both jump on this thing wgrant just said
<jml> ok
<kfogel> wgrant: that counts as a P1.  What's the problem?
<wgrant> You know how ~3 people have been complaining that rocketfuel-setup fails when it complains about sourcecode/mailman's absence?
<wgrant> I just ran rocketfuel-get. It complained about shipit and didn't actually update any of the branches.
<jml> interesting.
<jml> wgrant, rf-get has changed recently
<wgrant> It has.
<wgrant> And it has no error handling.
 * thumper still doesn't use rf-get
<jml> wgrant, that surprises me
 * wgrant tries.
<sinzui> I know dulwich is broken. I used --overwrite to force the branch to update
<jml> wgrant, it has some error handling.
<kfogel> wgrant: looking at recent rf-get changes now...
<kfogel> oh frig, there's still no way to get the history of a file efficiently in bzr
<wgrant> bzr log?
<kfogel> wgrant: try it :-)
<sinzui> kfogel: I use gannotate to look though a file. I do not know how to get just the log of the commits that changed the file
<kfogel> wgrant: I did 'cd utilities; bzr log -v -n0 rocketfuel-get', although I'm not strictly sure the -v is necessary...
<mwhudson> kfogel: it's waaaay better in 2a format than it was before, at least...
<kfogel> ah, eliminating -v helps
<kfogel> a lot
<kfogel> mwhudson: YES
<kfogel> mwhudson: actually the culprit appears to be the -v really
<mwhudson> jml: please to be fixing devscripts.sourcecode to pull overwrite
<wgrant> A plain bzr log on that file takes just 5 seconds here.
<kfogel> I had thought that whatever work -v did was what bzr would have to do to extract logs for just that file anyway, but apparently not
<jml> mwhudson, yeah, I've already made a note to do so :)
<mwhudson> kfogel: log -v should be faster in 2a too...
<jml> mwhudson, although aiui, it's a matter of adding a parameter to one function call in one place.
<mwhudson> jml: yeah
<kfogel> mwhudson: it may be faster, it's just still rather slow
<mwhudson> jml: so i guess it doesn't actually demand you do it...
<kfogel> wgrant: http://paste.ubuntu.com/273138/
<mwhudson> jml: the last-touched principle & all that
<kfogel> wgrant: I'm sure you were at that rev already
<wgrant> Ahhh.
<wgrant> I see.
<wgrant> So.
<jml> mwhudson, oh sure, I'm happy to do it.
<jml> I just would have been happier if someone else had already done it :P
<kfogel> wgrant: looking at diff, one sec
<wgrant> kfogel: I have a fix.
<kfogel> wgrant: zing!
<wgrant> Just working out what the Right Way to report errors is, given that it might be an optional.
<kfogel> wgrant: ok.  Should jml and I start our call (that's what we backgrounded, but if you have questions we can wait..)
<wgrant> kfogel: Go ahead. Sorry for interrupting.
<kfogel> wgrant: m'gosh, sorry we broke rf-get!
<thumper> hmm... pqm seems to be advancing, but slowly
<thumper> Chex, mthaddon: any idea why pqm would take an hour to apply comments.sql?
<mwhudson> maybe postgres really wants to vacuum or something
<poolie> hi
<poolie> i think it used to be possible to change the status of a question, but the option seems to have gone away
<poolie> even on lpnet
<poolie> wtf
<wgrant> The permissions for that are very restrictive.
<poolie> it's a bazaar question
<poolie> maybe the permissions have been broken? do you know off hand who is allowed to edit them?
<poolie> oh
<poolie> actually it's not
<poolie> i don't know why i got it then
<mwhudson> kiko: build engineer tole?
<poolie> wgrant: ok, i remember, i've hit this before
<wgrant> poolie: It's in bazaar, but not bzr?
<poolie> i don't have permission to change the status but i do have permission to reassign the question and then i can change the status :)
<wgrant> Ah, yes.
<wgrant> Heh.
<poolie> i think someone else may have moved it before i got there
<EdwinGrubbs> BjornT: ping
<EdwinGrubbs> jml: ping
<jml> EdwinGrubbs, pong
<jml> EdwinGrubbs, wassup?
<EdwinGrubbs> jml: I don't understand the benefit of the /+storeblob page.
<jml> EdwinGrubbs, me neither. I didn't know we had one :)
<mwhudson> EdwinGrubbs: wgrant replied to you on #launchpad-reviews....
<kiko> mwhudson, heh
<thumper> hi kiko
<kiko> heya tim
<kiko> how are you?
#launchpad-dev 2009-09-18
<poolie> hi kiko
<thumper> mwhudson: got a few minutes to talk about code imports?
<wgrant> jml: Is there any point catching exceptions in the sprout/pull, or should I just do it around the open where the problems are actually going to occur?
<maxb> # cat /usr/share/pyshared/lazr.uri-1.0-nspkg.pth
<maxb> import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('lazr',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m = not ie and sys.modules.setdefault('lazr',new.module('lazr')); mp = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
<maxb> gary_poster: ^ uhm, yikes :-/
 * maxb glares spiky death at pycentral and namespace packages in general
<gary_poster> maxb: yeah, welcome to setuptools :-/
<gary_poster> I like namespace packages as an idea myself.  implementation leaves a bit to be desired, but bringing core features to a language without a language's consent sometimes does that IME
<maxb> "a bit"
<gary_poster> :-)
<ajmitch> maxb: so, that's not perl there, I take it? :)
<maxb> heh
<maxb> This is so screwed up. How on earth do you support namespace packages mixed between PYTHONPATH and the system dirs !?
<wgrant> Run. Away.
<mwhudson> thumper: ok
<maxb> Sadly that's not going to result in a running Launchpad
<mwhudson> the problem with setuptools is that people use it
<maxb> maxb@z61p:~$ python -c 'import sys; print sys.modules["lazr"]'
<maxb> <module 'lazr' (built-in)>
 * maxb boggles
<mwhudson> unlike other pje-projects, which people have been insprired by
<mwhudson> generally usefully
<jml> wgrant, sorry...
<gary_poster> maxb: I'm not really around--I need to do some 3.0 stuff, but otherwise not be here.  But our general goal has been to keep the system namespace packages at the very end of the pythonpath, so that we don't see them.
<gary_poster> PYTHONPATH might not be sufficient for that, if it tacks things at the end of the path--and that's what we use for running some scripts.
<gary_poster> Feel free to do more of course, but if you send me a note with what's calling the codehosting scripts--the mechanism, so I can duplicate it outside of the tests--I'll be happy to do the surgery.
<jml> wgrant, exceptions are going to occur in open & sprout/pull
<gary_poster> "happy" ;-)
<gary_poster> If our approach to bin/py (PYTHONPATH) is at fault, then we'll have to use a faux-interpreter, which will be fine, but will involve some Makefile surgery.
<jml> wgrant, so catch around both.
<gary_poster> (done)
<maxb> I will do some research, I guess
<gary_poster> maxb: Minimally, if you give me dupe instructions (which maybe are as simple as "install lazr.enum and run the failing tests") then I'll get around to it eventually.
<maxb> bin/py -c 'import lazr.uri; print lazr.enum'
<maxb> ^ dupe instructions
<maxb> oops
<maxb> I mean bin/py -c 'import lazr.enum'
<maxb> that's all :-)
<gary_poster> maxb: yup.  I think I had already set up my karmic to try to look like your installation in this regard.  ok, that's good enough.  thank you, I can go from there.
<maxb> bin/py -S -c 'import lazr.enum' works
<maxb> as does bin/py -S scripts/mirror-branch.py -h
<gary_poster> unsurprising that the import would work.  More surprising that the mirror-branch works, but I guess it doesn't need lxml and so on that we have in dist-packages
<maxb> lp doesn't use lxml anyway :-)
<mwhudson> screw it, early lunch, focus after hopefully...
<gary_poster> maxb: no?  I thought we did.  and there are some other bits that I think we need.
<wgrant> jml: But exceptions that occur after the open are probably real, even if it's an optional sourcedep.
<jml> wgrant, ummm... let me think about that for a bit (on a call still)
<wgrant> jml: OK, sorry.
<jml> wgrant, no problem at all.
<jml> ok.
<jml> I'm back.
<jml> wgrant, that's a good point. sadly, I don't actually know what the semantics of the 'optional' field in the config file actually are.
<wgrant> jml: Its intent and use is clear, however.
<jml> wgrant, you think?
<jml> wgrant, if it's optional (e.g. shipit), and we can open it, but something happens to prevent us pulling it, what should happen?
<jml> and why :)
<wgrant> I think it should die.
<wgrant> They are optional to prevent things dieing if the user has insufficient privileges.
<jml> hmm.
<jml> ok. fair enough.
<wgrant> If the open succeeds, the user has permission.
<wgrant> So any subsequent failure is real.
<jml> wgrant, so, are you preparing a patch for this, or shall I?
<wgrant> jml: It's sufficiently trivial that it would probably be less work for you to do it.
<jml> wgrant, heh, ok.
<thumper> mwhudson: proposal made for import branches
<wgrant> Just wrapping the Branch.open for new branches is sufficient, but the same should probably be done for the updating thing.
<jml> thumper, why are you disabling auto-upgrade?
<thumper> jml: because going from packs -> 2a takes a long! time
<thumper> jml: a more orderly upgrade would be good
<thumper> jml: especially with 2.5k imports
<jml> thumper, *nod*
<jml> thumper, do you have any plans for how to upgrade the imports to 2a?
<thumper> jml: nothing concrete yet
<thumper> jml: we have some ideas for the git imports
<thumper> jml: I'd like to get the upgrade job done properly
<thumper> jml: and then probably use that
<jml> thumper, that makes sense.
<thumper> jml: but no concrete plans
<jml> thumper, it'd be good to have some.
<thumper> jml: yes, it would
<thumper> jml: but my planning brain has been full with lp 3.0
<jml> since as long as they are out of date, we're making Bazaar look slower than it actually is.
<jml> thumper, understood! :)
 * jml afk
<jml> mwhudson, do I have to do anything wrt ec2-entrypoins?
<mwhudson> jml: no
<jml> mwhudson, thanks.
<mwhudson> jml: i am slaving away to get it ready for review
<jml> :)
<mwhudson> jml: will you be able to review it this afternoon?
<jml> mwhudson, quite possibly
<mwhudson> jml: excellent
<jml> away again
<jml> launchpad probably doesn't need five IRC channels.
<wgrant> jml: Are you counting an internal one, or am I missing one?
<jml> wgrant, an internal one, yes.
<wgrant> But aren't there lots of internal ones?
<jml> not that I know of.
<jml> mwhudson, can we import from svn that requires http auth?
<mwhudson> jml: yes, you have to get a losa to faff around on the slaves though
<wgrant> If only svn was less braindead and allowed one to specify credentials in the URL like... everything else.
<jml> I wish every whiteboard were a wall
<jml> or something
<mwhudson> jml: it's a strange repo too, it contains a zip file
<jml> hmm
<mwhudson> thumper: cscvs branch landed
<thumper> mwhudson: cool
<jml> thumper, can a product branch be linked to a product series for a different product?
<thumper> jml: it shouldn't be able to
<thumper> jml: I think we check when they try to link it
<thumper> jml: but if it is linked, then moved, I don't think we check
<jml> thumper, ahh, that'll explain it
<jml> (also, is there a bug for that?)
<thumper> don't think so
<jml> https://code.edge.launchpad.net/~vcs-imports/schooltool/main
<jml> I can't delete that branch because I'm not a project driver for obsolete-junk
<thumper> wgrant: around?
<thumper> wgrant: bug 407643
<mup> Bug #407643: CodeImportNewView confusing after form changes <Launchpad Bazaar Integration:In Progress by thumper> <https://launchpad.net/bugs/407643>
<rockstar> mwhudson, buying you a beer (or some single malt) is now on my todo list.  ec2test --headless is quick now.
<wgrant> thumper: Hi.
<thumper> wgrant: hey, take a look at my image attached to the bug
<thumper> wgrant: I'm getting that reviewed
 * wgrant looks.
<wgrant> thumper: Much better. Thanks.
<thumper> np
<thumper> BjornT: you up yet?
 * thumper thinks optimistically
<mwhudson> rockstar: :)
<mwhudson> jml: hi
<jml> mwhudson, hi
<mwhudson> jml: testing anything in ec2test is going to be hard because of python 2.4/2.5 fun-ness
<mwhudson> though, hah, testrunner doesn't import boto
<jml> mwhudson, it took me a while to parse that :)
<mwhudson> jml: sorry :)
<mwhudson> also bzr plugin path issues :(
<jml> mwhudson, so, what therefore shall we do?
<mwhudson> jml: land this branch sans tests?
<mwhudson> (i haven't actually written any yet)
<jml> mwhudson, I think that's fair enough.
 * thumper afk for a few minutes
<wgrant> ... Person.t_shirt_size? ahaha.
<stub> Where did you find that? I thought I managed to kill off that idea.
<wgrant> In some branch that I happened to come across.
<mwhudson> jml: you have mail
<jml> mwhudson, thanks.
<jml> mwhudson, I'm just going out to lunch. I'll review it when I get back.
<jml> I'll try to be quick
<mwhudson> jml: ok, thanks
<wgrant> Argh. There's no way from the outside to tell whether two LFAs with the same content actually have the same LFC, is there?
<jml> wgrant, LFA?
<mwhudson> librarianfilealias, i presume
<wgrant> Right. It will let me find all LFAs with a particular SHA1, but won't tell me which LFC they point to.
<wgrant> But I found the relevant code lurking deep in Soyuz, so no matter.
<wgrant> nascentupload is too big, confusing and scary.
<jml> yes.
<jml> I've made it smaller recently
<jml> and will probably make it smaller again soon.
<wgrant> Very good.
<jml> (if ever I get a moment to start working on my top priority tasks!)
<thumper> yay, bzr 2.0rc2 landed
<jml> yay
<rockstar> Man, I'm currently in the mood to replace all the code page tests with unittests.
<mwhudson> rockstar: possibly not on friday of week 3, but +1 in general
<rockstar> mwhudson, yes, this is a large reason why I'm not doing it.  However, working with the pagetests fills me with vigor that will hopefully last until the weekend.
<mwhudson> heh
<rockstar> Also, I will worship at the feet of anyone who will delete notfound-traversals.txt
<rockstar> Not just worship, but like, sacrifice people and everything.  You know, REAL worship.
<jml> mwhudson, I'm so glad you've done this ec2 command refactoring
<jml> mwhudson, not just because it makes ec2 better, but also it will make my future command-line apps easier to write :)
<mwhudson> jml: heh heh
<mwhudson> jml: bzrlib needs to change a bit to make them truly easy, i think
<jml> mwhudson, agreed.
<mwhudson> but i'm not sure i understand how the parts interact sufficiently yet to see precisely how
<jml> mwhudson, but at least I now have mental hooks into how to begin thinking about it :)
<mwhudson> otoh, it's 6pm on a friday, i don't understand anything very precisely now
<jml> heh :)
<jml> gosh I hate CHR
<jml> it makes me want to fix about a dozen bugs
<jml> which is partly the point of doing it
 * mwhudson EOWs
<jml> but I don't think I'll have any time between now & Christmas to do so :\
<mwhudson> jml: and then you realize how hard it is to make changes to launchpad
<jml> mwhudson, see you around
<mwhudson> jml: good luck with the move
<jml> mwhudson, I might change code import branches to be owned by their actual owners rather than vcs-imports, just to surprise you :P
<jml> mwhudson, thanks!
<mwhudson> jml: that would be awesome
<jml> mwhudson, although maybe deleting comments would make me more friends :)
<mwhudson> jml: deleting comments would make you friends in more ... authorized ... places, for sure
<jtv> connection blinking...  I need coffee.
<jtv> hi mwhudson, thanks for your help; I slept wonderfully
<mwhudson> jtv: hooray
<jtv> Does noone take things out of context anymore?
<wgrant> Sadly I read the earlier conversation, so could not help you.
<jtv> A sad day for puerile office humor
<henninge> Hi!
<henninge> Does anybody know how to display a projects logo?
<henninge> <img tal:attributes="src project/...
<henninge> ?
<henninge> Like the new template does on the top left
<wgrant> henninge: project/image:logo?
<wgrant> I think that should work.
 * henninge tries
<henninge> wgrant: does that give me the url or the full tag?
<wgrant> henninge: I presume the full tag, but I don't know.
 * wgrant checks the formatter.
<wgrant> The whole tag.
<henninge> yup, just found out, too.
<wgrant> If you want the URL, you might just have to use project/logo/fmt:url, I guess.
<henninge> Thanks!
<henninge> nope, that's what I tried first ...
<wgrant> I guess LFAs are special.
<henninge> looks beautiful ... ;-)
<wgrant> What are you doing with it?
 * jtv heads for lunch
<mrevell> Morning
<jml> good morning
 * jml is about to EOW
<jml> (last week in .au)
<mrevell> Man, are you nervous jml?
<jml> not yet.
<jml> I tend to get nervous at the last minute.
<bigjools> morning all
<wgrant> bigjools: I will reply to your ddeb email more thoroughly later, but did you really mean to suggest that ddebs shouldn't skip NEW?
<wgrant> That will make archive admins very sad.
<bigjools> wgrant: yes, of sorts, they should do what debs do, it will make it *much* easier
<wgrant> bigjools: If they're going to follow the corresponding deb, there's no point sending them through NEW.
<wgrant> Because they should always inherit the same override.
<bigjools> wgrant: I am assuming that they are always in step with the corresponding deb
<bigjools> yes, you won't *see* them in NEW, you just accept the deb
<wgrant> But should they be sufficient to send a binary upload into NEW?
<bigjools> not on their own
<bigjools> that decision should be based on the deb
<wgrant> Right.
<wgrant> So they should skip NEW.
<bigjools> depends how you look at it :)
<wgrant> Except not quite in the way they do now, perhaps.
<bigjools> yeah, that part's confusing
<bigjools> it would help if I knew more about how and when they are generated
<wgrant> I need to look at how overrides work in the queue.
<bigjools> I can help you with that, it's quite easy
<wgrant> I haven't really looked at the queue stuff all that much.
<bigjools> I have :(
<bigjools> the +queue page is the bane of my soyuz life
<wgrant> Heh.
<wgrant> What do you need to know about ddebs that would help?
<bigjools> from what you said, you implied that they can be NEW where the corresponding deb is not?
<wgrant> Basically, they're automatically generated for and will accompany binaries with compiled binaries.
<wgrant> So once all my glue is in place, and the switch is turned on...
<bigjools> this is as I expect, so far
<wgrant> The first build for each arch of each source that compiles things will produce NEW binaries.
<wgrant> This only happens the first time for each (source, arch) after the switch is flipped.
<wgrant> Or when a binary begins to contain compiled code.
<bigjools> but we'll not put them through NEW since their debs are not NEW
<wgrant> Right.
<bigjools> only when the DEB is new
<bigjools> err wrong caps :)
<wgrant> But without the ddeb-specific hacks, we'd have a hundred thousand builds in NEW because of the ddebs.
<wgrant> Hmm. Dinner.
 * wgrant departs for a little while.
<bigjools> wgrant: indeed
<bigjools> I need more caffeine
<henninge> How do I get the urls to the application homepages?
<henninge> https://bugs.launchapd.net/, bugs.edge.lp.net ...
<henninge> from tal, ideally
<henninge> maybe, this is too obvious ... ?
<intellectronica> henninge: just a guess, but can you pass the application object to canonical_url ?
<henninge> intellectronica: oh right, from python i could use canonical_url with rootsite and an empty url?
 * henninge tries
<intellectronica> henninge: i was more thinking of the top-level application object, but i'm really just guessing. let me know when you find out, i'm curious now
<henninge> intellectronica: right, I need an application object. I have that (its the root view after all)
<henninge> so it's context
<intellectronica> huh, of course :)
<henninge> bigjools: does soyuz have an application home page?
<bigjools> henninge: no, it's homeless
<bigjools> soyuz is a hobo
<henninge> sleeps under bridges ...
<bigjools> are you trolling?
<bigjools> ba. dum. tish.
<henninge> intellectronica: I've got this in the view now http://paste.ubuntu.com/273353/
<intellectronica> nice
<deryck> Morning, all.
<wgrant> Fancy new profile page.
<wgrant> Even fixes the edit form mess.
<jmux> Hi. I want to work on bug #188564 (Non-Ubuntu a.k.a. Debian PPAs). I already have some ideas about the implementation and I saw that there is already an (empty) blueprint registered with the bug. Where should I put my ideas (new page on dev.launchpad.net), so we can discuss my ideas, before I start an implementation?
<mup> Bug #188564: Build also packages for Debian in PPA's <feature> <ppa> <soyuz-core> <Soyuz:Triaged> <https://launchpad.net/bugs/188564>
<bigjools> jmux: hi
<wgrant> That's a hard one.
<jmux> Ok - just happens some more people think about it :-)
<wgrant> Although it already mostly works.
<bigjools> jmux: that would be great, somewhere under http://dev.launchpad.net/Soyuz/ and link to it from the blueprint
<jmux> bigjools: ok
<wgrant> jmux: I've got notes locally on the issues that I identified a few weeks ago.
<wgrant> But I imagine that there are further non-technical barriers to this, eg. buildd time, librarian disk, germanium disk, chroot administration time.
<jmux> wgrant: Can you send me your notes? I'm jmglogow in launchpad.
<wgrant> jmux: Sure.
<wgrant> jmux: Sent.
<gmb> intellectronica: In the new bug page, should we show "Report another bug" and "List all open bugs" with the other actions (mark dupe, convert to question, etc)?
<gmb> Or should we just get rid of them?
<intellectronica> gmb: we should definitely have the report another bug (see discussion on the ml). the question is whether to just include it in the involvement portlet style or as something less prominent
<gmb> intellectronica: I'll re-read that thread; must've missed that part of the discussion. (I wish that Google had invented "highlight the text relevant to my brain2)
<intellectronica> i think the 'list all open bugs' link is not necessary, though
<gmb> intellectronica: Agreed on both counts. I'll put the report a bug link in the portlet for now; we can always move it later.
<intellectronica> gmb: i'd say an action link like for the 'report another bug'. the involvement portlet is too prominent
<gmb> Hmm.
<gmb> intellectronica: Maybe we should just leave it at the foot of the page then.
<intellectronica> and it would be a bit weird because the context isn't the target, it's the bugtask
<gmb> Yeah.
<intellectronica> gmb: i really can't decide on that. ot1h putting it at the bottom kinda' makes sense because it communicates that you should read everything before filing another bug. otoh, part of the redesign is an attempt to move the actions back together so users don't have to search for them all over the page
<gmb> Right.
<intellectronica> maybe leaving both links at the bottom is the path of least resistance, though
<intellectronica> gawd, i'm not really helping, am i :-/
<gmb> intellectronica: It's Friday week 3. PoLR is my favourite route today.
<intellectronica> gmb: yeah, i agree
<gmb> intellectronica: Design is hard. This is why we employ Argentinians.
<gmb> (And mpt, but hey, that spoils the gag)
<gmb> Hah. Failure in tests: Just about everything under lp.bugs.stories. What a surprise.
<mpt> gmb, I could pretend to be Argentinian. I eat meat.
<gmb> mpt: You might need to talk faster and gesticulate more, but hey, this is IRC...
<mpt> \o_
<gmb> Hah.
<henninge> mrevell-lunch, noodles775: Can you please look at bug 431244, my last comment? I need some input UI-wise (and a review eventually) and content-wise (new blog posts!).
<mup> Bug #431244: Launchpad homepage needs conversion to 3.0 design. <story-ui-3> <Launchpad Foundations:In Progress by henninge> <https://launchpad.net/bugs/431244>
<henninge> I will be relocating now but will be back soon.
<noodles775> k
<henninge> thanks
<wgrant> Somebody might want to point henninge at bug #429247 when he returns.
<mup> Bug #429247: Locationless <h1>s block login/out widgets <story-ui-3> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/429247>
<wgrant> henninge: Bug #429247
<mup> Bug #429247: Locationless <h1>s block login/out widgets <story-ui-3> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/429247>
<henninge> wgrant: thanks!
<henninge> wgrant: now I am wondering if it should really be "low" ...
<wgrant> henninge: Not if the homepage is locationless, no.
<henninge> yup
<henninge> wgrant: I don't see another way to do the home page, at least not if I stick to Martin's design...
<henninge> mrevell, noodles775: I am back btw.
<henninge> ;-)
<wgrant> henninge: Right.
<flacoste> sinzui, barry, bac, salgado, EdwinGrubbs: Registry conversion is complete, awesome job!!!
<sinzui> flacoste: rockstar: what is the status of the final 3 answers pages?
<flacoste> sinzui: only rockstar knows and it's a little early for him yet
<rockstar> sinzui, it's approved to land, but tests keep failing.  I'm working on them now.
<sinzui> :(
<rockstar> sinzui, yea, tell me about it.
<sinzui> rockstar: how can you be on American East Coast Time and keep time with NZ?
<rockstar> sinzui, I sleep 40 minutes every few hours.
<rockstar> ...give or take.
<rockstar> (especially when I have a deadline)
<noodles775> henninge: yep, I'll be taking a look shortly (just had lunch-break) :)
<henninge> noodles775: fine
<rockstar> sinzui, ping
<sinzui> hi rockstar
<rockstar> sinzui, so my tests were all passing, but I apparently had conflicts, so I merged in trunk, and now my templates are throwing TraversalError in the MenuAPI on context.  Would you know what changed to do this?
<sinzui> yes
<sinzui> rockstar: There is python error in one of the links
<sinzui> rockstar: you can see the real error in a unittest, browser tests hide it
<rockstar> sinzui, okay, I'll take a gander.
<sinzui> rockstar: I had a bad experience a few months ago when I discovered I wrote a link the correct way (pass the name to canonical_url). and the link failed because the view was not registered for IProject.
<rockstar> sinzui, well, it was working before the merge.  If I revert, everything is fine, but then I have conflicts.
<sinzui> rockstar: The link was canonical_url(something) + '/+view-name'
<sinzui> rockstar: I have a simple test tool
 * sinzui looks for example
<rockstar> sinzui, usedfor = IBranch should make it work, right?
<sinzui> That is perfect
<sinzui> rockstar: You can check_menu to verify the links http://pastebin.ubuntu.com/273506/
<sinzui> rockstar: it instantiates the link and verifies there is a view for it. It will die when the link logic is bad of the view is not registered
<rockstar> Alright, I'll give it a whack.
<sinzui> rockstar: ^ I added this because I discovered that there were two bad links that were very old in that menu
<sinzui> bac: I just assigned bug 422334 to you. I do think it is trivial, but it may be easy do since person-index does it
<mup> Bug #422334: "Contact this team" link should be in the action menu <Launchpad Registry:Triaged by bac> <https://launchpad.net/bugs/422334>
<bac> ok
<sinzui> bac: Oh, person-index did it by not putting it in the action menu, we just put it in the side bar. that is much easier
<maxb> barry: Re your 14 failures and 2 errors on Karmic - I attribute 13 failures and 2 errors to the lazr import mess mentioned on LaunchpadOnKarmic - I added a rather crude workaround to that page this morning
<barry> maxb: cool.  i haven't looked into it in detail, but thanks for working on it
<maxb> I am hugely jealous of having a machine that can get through bin/test in 2 hours :-)
<barry> maxb: i earned it though.  the machine i had been using was painful, loud, hot, and unreliable. :)
<maxb> I ran it on an Aspire One netbook once. Took 9Â¼ hours :-)
<barry> ouch.  before this box, i had nothing newer than circa 2006 and my main dev box was a 3ghz p4.  otoh, i don't get as many naps now <wink>
 * gmb -> out BBIAB.
<EdwinGrubbs> sinzui: did I use the wrong milestone for bug 432516?
<mup> Bug #432516: Convert /rdf page to UI 3.0 <Launchpad Foundations:In Progress by edwin-grubbs> <https://launchpad.net/bugs/432516>
<sinzui> EdwinGrubbs: wrong project. the file is owned by launchpad-foundations
<EdwinGrubbs> sinzui: oh, that probably changed the milestone automatically, and I didn't notice anything else in the email.
<sinzui> yes, it does.
<rockstar> sinzui, if the context of a page is an IQuestionSet, and I register a menu with usedfor IQuestionSet, the view should be able to get to the menu, right?
<sinzui> rockstar: yes in a manner is speaking
<sinzui> rockstar: views and context can both have a menu, since you have both objects, you have two menus.
<sinzui> rockstar:  <context|view>/@@+global-action
<rockstar> sinzui, so I have a menu that works for the view when the context is ISearchableByQuestionOwner, but not when the context is IQuestionSet.
<rockstar> sinzui, this is an application menu.
<sinzui> so context/menu:answers will work. since they are not associated with a view, you need to ensure the menu is registered for both.
<sinzui> rockstar: I have done a lot of subclassing that modifies one or two lines like label, page_title, usefor to update everything to 3.0
<rockstar> sinzui, so, I seem to have fucked these menus up beyond recognition.  I'm feeling pretty frustrated.  Can we have a call?
<sinzui> yes
<sinzui> rockstar: I am ready
<EdwinGrubbs> jml: ping
<EdwinGrubbs> rockstar: ping
<rockstar> EdwinGrubbs, on the phone.
<EdwinGrubbs> deryck: ping
<flacoste> barry: did you land all of adeuring branches?
<deryck> EdwinGrubbs, pong
<barry> flacoste: i could only get the first one landed
<EdwinGrubbs> deryck: do you need help converting the hwdb pages on https://dev.launchpad.net/VersionThreeDotO/UI/TemplateToDoList since Abel is out?
<barry> flacoste: the others are still up for grabs
<flacoste> EdwinGrubbs: could you finish adeuring branches?
<EdwinGrubbs> flacoste: sure
<deryck> EdwinGrubbs, yes, please.
<rockstar> sinzui, I'm not entirely sure the question-listing and faq-listing are going to get done today.  The tests are making me realize they are bigger than I thought.
<rockstar> If PQM doesn't close until tomorrow, I may be able to get it done tonight.
<rockstar> flacoste, when is PQM closing?
<sinzui> rockstar: do what you can. I can help fix tests, change code, do reviews. I have a only a few tomorrow because I leave for a sprint
<rockstar> sinzui, I think I'm going to quit on this branch, and do a really minimal mechanical change, and then come back to this and do it proper.
<sinzui> rockstar: push the branch. I'll try to pick it up. I am going to assist salgado first
<rockstar> sinzui, the problem is that question-listings can by applied to LOTS of different Interfaces, and they all need different items in their menus.
<intellectronica> henninge: not that i'm any authority on this, but i think the new homepage is great. there's lots of stuff that can be improved, but as it is it's already a great improvement and i would be proud to have it as our 3.0 homepage
<henninge> intellectronica: thank you so much !
<flacoste> rockstar: i'm thinking of closing it on Sunday when spm starts
<rockstar> flacoste, okay.  That actually gives me a little breathing room.  I was thinking it'd close in about 7 hours, and so that means I have to be off to ec2 in 3.
<sinzui> salgado-lunch: how can I help you
<rockstar> sinzui, so, I changed the menus in answers, and for some reason, the titles of the pages all broke.  Would you happen to know why?
<sinzui> rockstar: I think titles broke when barry landed his branch on Saturday. Did you see the bug I reported about FAQs
<sinzui> rockstar: titles are the inverse of breadcrumbs, but I think there is something missing form the view (labels and or page_titles) because neither is being used. FAQs to not have a title or a heading
<mrevell> night all
<rockstar> sinzui, I did.
<sinzui> rockstar: I see. FAQ does not have a view. That is why is is screwed up. You may want to verify if everything you are working with has a view in configure.zcml
<rockstar> sinzui, the thing is, without my patch, the tests are fine, but with my patch, the tests aren't fine.
<sinzui> because all the page titles changed form sane to crack?
<sinzui> I see the FAQ is an easy fix
<EdwinGrubbs> sinzui: is the ISprintSpecification/+decide page even used now? It seems to be superseded by the ISprint/+settopics page that lets you decide on multiple ISprintSpecifications at once? I can't even figure out how to load +decide since there are no tests.
<rockstar> sinzui, yeah, it shouldn't be hard.  I'm talking about listings now though, not the bug you file (although I can probably fix that too)
<sinzui> EdwinGrubbs: I do not know the answer.
<sinzui> rockstar: I see that question-listing use LaunchpadView, not a subclass to define a page_title or label
<sinzui> rockstar: in 3.0 every page needs unique view.
<rockstar> sinzui, wait, what?
<rockstar> sinzui, maybe I should get on the phone with you again, if that's agreeable.
<sinzui> rockstar: For a page to be a full page (a page title) it must have a view to define that. I can see in my copy of RF that it does not:
<sinzui>   <browser:pages
<sinzui>     for="lp.answers.interfaces.question.IQuestion"
<sinzui>     class="canonical.launchpad.webapp.LaunchpadView"
<sinzui>     permission="zope.Public">
<sinzui>     <browser:page
<sinzui>       name="+listing-detailed"
<sinzui>       template="../templates/question-listing-detailed.pt" />
<rockstar> sinzui, question-listing-detailed isn't a full page though.
<rockstar> It's a fragment.
<sinzui> rockstar: ^ subclass LaunchpadView and give it a label (and maybe a page_title). barry says it needs a label, salgado-lunch says it needs a page_title. I decided the two can fight it out in a caged match next week
<sinzui> rockstar: okay, my misunderstanding
<sinzui> rockstar: when template and view is the issue
<rockstar> sinzui, this my diff that somehow breaks page titles : http://pastebin.ubuntu.com/273626/
 * barry prefers silly string and water balloons, but is up for anything
<sinzui> two men enter, one man leaves
<sinzui> rockstar: your diff does not show that you added SearchQuestionsView.page_title
<salgado> sinzui, until we have some time for the caged match I've changed the code to be happy with either a label or a page_title
<salgado> sinzui, and all the failing tests seem to be fixed, according to ec2
<sinzui> rockstar: in fact, I see it was only added to ManageAnswerContactView. I think all views in the browser modules need a label or a page_title
<rockstar> sinzui, lable and page_title are and/or?
<sinzui> salgado: You more than rock!
<sinzui> rockstar: try a label first and see what happens. I expect you to get something since barry guarantees a title form the breadcrumbs
<barry> rockstar: if you're getting breadcrumbs already, that will be used as the default title, but currently label is required
<rockstar> It looks like I just needed to move pageheading to be page_title.  We'll see what happens.
<sinzui> rockstar: Yes! that was what I was thinking when I created the page_title attribute. That is also why I wanted to do answers, I could cheat with a global find and replace
<rockstar> sinzui, :)  I still need a label though, right?  Can it be the same as the page_title?
<gary_poster> bigjools: is sources-list.pt (from the launchad list of templates) soyuz?  Or can we ignore it?
<gary_poster> deryck[lunch]: I'm still thinking that bugs will be doing the hwdb stuff from https://dev.launchpad.net/VersionThreeDotO/UI/TemplateToDoList
<gary_poster> is that right?
<sinzui> rockstar: given what salgado said about label/page_title I don't think it needs a label if the page is displaying the page_title in the  heading and title. If they are not displayed, I would make lable = page_title
<sinzui> rockstar: I think in 3.1.10, we will remove the heading-slot and page_title. We will just use label. The mater is being discussed
<EdwinGrubbs> salgado: I thought it was possible to override just the +foo part of the page_title?
<sinzui> EdwinGrubbs: do not think about that matter
<sinzui> EdwinGrubbs: we need to wait for salgado's branch to land before we can judge what needs to be changed. the +foo = view.label or view.page_title
<rockstar> sinzui, and failures like this are to be expected and changed? http://pastebin.ubuntu.com/273636/
<sinzui> rockstar: :( yes. that is the new page title rules that landed 6 days ago
<rockstar> sinzui, great, that's all I needed to know.  At least now I know they are supposed to break and be fixed, and it's not something I did unintentionally.
<sinzui> EdwinGrubbs: keep this in mind as you make changes. An ugly page title is easy to fix in the future. but every 2.0 page will have broken navigation. we need the pages converted now. No blueprint or launchapd page is worth more than 1 hour of hacking time
<deryck> gary_poster, I believe EdwinGrubbs was going to take care of the hwdb templates if he could.
<gary_poster> oh ok
<gary_poster> EdwinGrubbs: I'm working on low-priority templates--actually I will update the todo list--so I can do that instead if you are booked.
<EdwinGrubbs> gary_poster: I was going to try, but right now I'm working on Abel's branches that were already review but needed a few changes, so if you want to take them, go for it.
<gary_poster> EdwinGrubbs: ok.  I'll finish my current bits and then check in with you.  thanks
<barry> does anybody know what the hell ABE is and how to shut it off for all of launchpad.dev?
<gary_poster> barry: do you mean those log messages?
<gary_poster> starting with A and B and E and with dates and stuff?
<barry> gary_poster: it's a firefox thing and it stops me from hitting certain launchpad.dev urls, though it seems to be completely random about what it complains about
<barry> ABE = (apparently) application boundaries enforcer
<gary_poster> barry: oh, sorry, then no. :-/
<barry> gary_poster: ;)
<barry> ah.  it's a noscript thing
<gary_poster> noodles775 (redirected from asking bigjools): is sources-list.pt (from the launchad list of templates) soyuz?  Or can we ignore it?
 * sinzui takes specification-index
<bac> hi salgado
<salgado> hi bac
<bac> salgado: when i run 'bin/test -vvm lp.registry' now i get http://paste.ubuntu.com/273651 .  it was introduced by the branch you landed for jamal
<salgado> bac, are you sure?  the changes I reviewed didn't have anything related to that
 * salgado checks the diff from the revision email
<bac> salgado: i don't know what is happening.   the error does mention lp.registry.browser.test.test_person_view, which that branch introduced
<bac> salgado: i have isolated it to that revision - 9521
<maxb> LP looks a bit plain now the colour-coded applications aren't any more
<sinzui> maxb: your meeting the team leads in London at the end of the month aren't you?
<salgado> bac, that's weird; I submitted the branch through ec2, but it's possible it conflicts with something that landed while it was in ec2.  let me check
<maxb> Yes
<sinzui> maxb: I'll introduce you to beuno. You can talk colour with him
<bac> salgado: wait, i may have the wrong revision
<rockstar> barry, I still seem to be getting +faqs in my title, even though I have label and page_title defined.
<salgado> bac, looks like 9517 touched stuff related to ArchiveAdminView
<sinzui> rockstar: that is correct. the page titles are the inverse of breadcrumbs
<flacoste> gary_poster: do you know what would cause http://pastebin.ubuntu.com/273658/ ?
<rockstar> sinzui, so it saying +faqs is okay?
<sinzui> rockstar: salgado's recent work will use the page_title/label to replace the +faq
<bac> salgado: yeah, but if i revert to -r 9520 the failure happens.  -r 9519 does not have it
<rockstar> sinzui, okay, I'll leave that to him then.
<sinzui> rockstar: If he lands first, you need to update the test.
<bac> salgado: can you reproduce the problem?
<salgado> sinzui, rockstar, my branch is on PQM
<rockstar> sinzui, yes, it's a race.
<rockstar> salgado, dammit!  :)
<salgado> bac, let me try something slightly different
<gary_poster> flacoste: there could be a variety of reasons.  If you are not using our custom buildout, try using a clean, non-system Python.  That's the only way it is likely to work.
<rockstar> salgado, what's the url of your branch?  I'd like to merge it.
<bac> salgado: with the latest devel, if i 'rm lib/lp/registry/browser/tests/test_person_view.py' the warning goes away
<flacoste> gary_poster: what do you mean? that package is not installed in site-packages
<salgado> rockstar, bzr+ssh://bazaar.launchpad.net/~salgado/launchpad/breadcrumbs-for-leafs
<rockstar> salgado, ah yes, I reviewed that yesterday...
<flacoste> gary_poster: i think it's because their archive is screwed-up
<gary_poster> flacoste: I'd try a clean Python myself.  The other thing to do is look at the package you downloaded.  If the setup.py doesn't deliver what the egg promises, you'll get problems.
<flacoste> gary_poster: the tar file is gviz_api_py, untarring it leaves only a google-visualization-python directory
<gary_poster> huh
<flacoste> gary_poster: and the setup.py in that file has name="gviz_api.py"
<flacoste> do these google folks actually knows what they are doing?
<gary_poster> yeah, sounds broken
<gary_poster> :-)
<salgado> bac, do you have an ArchiveAdminView class in your lp/soyuz/browser/archive.py?
<bac> salgado: yes
<bac> salgado: can you reproduce it?
<flacoste> gary_poster: redoing a python sdist and using the resulting archive worked
<gary_poster> lol
<salgado> bac, './bin/test -vvt test_person_view' just passed here
<salgado> bac, should I do something else to reproduce it or is that how you're doing it?
<bac> salgado: bin/test -vvm lp.registry
<bac> salgado: i don't think test_person_view is the culprit, but it causes the problem to show up
<bac> salgado: but i'm anxious to see if it happens in your environment
<salgado> bac, reproduced
<bac> salgado: weird, no
<salgado> it makes absolutely no sense
<salgado> the name is defined in the module and the error is only triggered when we do -vvm lp.registry
<bac> yep
<bac> sinzui: you have any ideas?  ^^^
<sinzui> bac: No ideas
<bac> sinzui: drats.
<sinzui> bac: well I have ideas, but they are ideas from previous single test nonsense where a test does not cleanup or worse, a test expects the predessor to not cleanup, so when the test order changes, the test fails
<bac> sinzui: yeah, but this isn't a data issue.  it's an import failure
<bac> salgado: can you try something else, unrelated?  see if you can 'make iharness'
<sinzui> bac: oh does my branch that I pulled from review fix the issue? https://code.edge.launchpad.net/~sinzui/launchpad/import-person/+merge/12060
<sinzui> bac ^ I was triaging the bug and fixed it at the same time
<salgado> bac, I can't, but that's because of some windmill crap
<bac> salgado: yeah, i think bjornt's branch (r 9499) introduced it
<bac> sinzui: your branch does not help
<bac> salgado, sinzui: ArchiveAdminView is a red herring.  if i comment out the first line of c/l/browser/__init__.py it complains about lp.soyuz.browser.build.BuildContextMenu
<bac> by 'it', i mean bin/test -vvm lp.registry
<sinzui> bac: We is this really stopping you from working on templates. Can you run the test another way?
<bac> sinzui: no, the next change is ready to review.  i'll let it go...
<salgado> bac, if you move the import of PersonView into the method where it's used, the warning/error goes away
<bac> salgado: this problem smells of a lurking circular dependency or something similar
<bigjools> gary_poster: did you figure it out yet?  looking inside the file makes it obvious :)
<gary_poster> bigjools: no, I was moving on, plenty of other stuff to do ;-)  should I look?
<salgado> bac, agreed, and we'll probably see it often if we're correct
<bigjools> gary_poster: heh, no, I can tell you it's Code
<gary_poster> bigjools: oh ok thank you :-)
<bigjools> gary_poster: sourcepackagerelease-body-summary can be removed though
 * gary_poster tries to figure out what bigjools means.  it's not on conversions.html; not in sources-list.pt ...
<bigjools> gary_poster: sorry, sourcepackagerelease-body-summary.pt
<gary_poster> bigjools: oh ok.  yeah, not registered in any zcml...and not in pagetitles.pt.  So do you want me to just remove that template in one of my branches?  Happy to do it
<bigjools> gary_poster: removing dead files always gets rs=me :)
<gary_poster> I meant pagetitles.py
<gary_poster> ;-) ok cool
<Tonny> Hi
<Tonny> launchpad can install on a Debian Lenny ?
<Tonny> I suggested to use multiverse
<Tonny> Please enable the 'universe' component in /etc/apt/source.list'
<gary_poster> flacoste or EdwinGrubbs: I've gone through the "change or remove" files on https://dev.launchpad.net/VersionThreeDotO/UI/TemplateToDoList that are in my section of the page.  notification-test.pt was a pretty standard change, no problem.
<gary_poster> launchpad-addform and launchpad-editform are registered in widgets.zcml but are only used as macros.  The rest of them are not registered at all.
<gary_poster> Can I rm all the files that are not registered in zcml (the ones I don't mention specifically here)?
<gary_poster> If I don't rm them, I'll just make the simplest mechanical change to the html tag and move on I guess.  I'm doing that now.
<rockstar> salgado, when I merge your branch, my titles end up something like "FAQs for $displayname : Questions for Mozilla Firefox : Mozilla Firefox" Is that right?
<gary_poster> rockstar or abentley: l/c/l/templates/sources-list.pt is something from code (./lib/lp/code/browser/configure.zcml).  Could I ask one of you to look at it and do the conversion (and maybe move it to lp/code/templates if that makes sense)?
<salgado> rockstar, probably not
<rockstar> gary_poster, I'm pretty swamped right now, but abentley might be able to do it.
<gary_poster> ok thanks rockstar
<rockstar> salgado, do you have any suggestions for what I should do about it?
<salgado> rockstar, not really, but I'll come up with something
<rockstar> salgado, looking at it through the browser has the same issue.
<gary_poster> salgado: I asked something of flacoste and EdwinGrubbs above.  Do you think I could rm the files I talk about? (template-form.pt, message-add.pt, teamplate-page.pt, template-addform.pt, template-editform.pt, default-ediform.pt, all in l/c/l/templates)
<gary_poster> as I said above, they are not registered in zcml
<rockstar> salgado, when you say "I'll come up with something" does that mean "land what you have, and I'll make a fix"?
<EdwinGrubbs> gary_poster: sorry, I don't know.
<gary_poster> EdwinGrubbs: np, thank you for looking
<salgado> rockstar, if your branch is ready, yes.  otherwise you can wait for the fix
<salgado> gary_poster, looking
<gary_poster> salgado: thank you very much
<rockstar> salgado, actually, I think this might be my problem.  Hold on.
<salgado> rockstar, it's not.  the problem is that the code that generates titles doesn't know how to deal with zope.i18nmessageid.message.Message
<rockstar> salgado, ah, it's a replacement problem.
<rockstar> salgado, ah, okay.  I'll get my stuff reviewed and you can land your fix when you need.
<salgado> rockstar, do the breadcrumbs have the same problem on those pages?
<gary_poster> deryck: hwdb-fingerprint-submissions.pt is not registered in zcml anywhere.  Does that mean I can rm it?  Or would you prefer I just do the mechanical changes and move on, because of time?
<rockstar> salgado, nope, doesn't look like it.
<deryck> gary_poster, yeah, I don't think it can be removed.  It
<deryck> gary_poster, It's used in a view class somewhere, if memory of greping holds.
<deryck> gary_poster, this is why I was leaving it to abel because I couldn't really work out how to verify the changes looked ok.
<deryck> gary_poster, so change the macro so it qualifies, commit, and move on, I guess. :)
<salgado> gary_poster, yes, please kill them all!
<gary_poster> deryck: ah, gotcha.  FWIW, "find . -name '*.py' -exec grep -Hn 'person-hwdb-submissions.pt' {} \;" gives no results.  But I'll make the mechanical changes.  Thank you!
<gary_poster> salgado: woohoo!  thank you!
<salgado> gary_poster, no, thank you!
<gary_poster> :-)
<deryck> gary_poster, ok, I could be recalling incorrectly then.  I guess we could kill it and see if ec2test complains.
<gary_poster> deryck: ah, deryck, I was grepping for the wrong string.  It is actually used here: ./lib/canonical/launchpad/browser/hwdb.py:260 .  I'll make the mechanical change as you suggested and move on.  Thanks again.
<deryck> gary_poster, np
<deryck> gary_poster, thank you for doing those templates!
<gary_poster> :-) np
<deryck> kees, I'm taking a look at your branch now.
<bac> sinzui: the link to +mugshots has been removed from the team index page.  was that intentional?
<sinzui> no
<sinzui> I believe it should be in the same portlet that has the members link. Is it conditional by accident?
 * bac looking
<bac> sinzui: would that be TeamOverviewMenu?
<sinzui> It is missing from the menu?
<bac> sinzui: it is in TeamOverviewMenu with launchpad.View condiotional
<sinzui> bac: it is provides by TeamMenuMixin
<sinzui> bac: I bet that guard is on the link so that we do not get timeouts from bots
<bac> sinzui: same guard as the +members link
<bac> sinzui: the 'Show all members' is rendered in person-portlet-memberships.pt.  no mention of +mugshots there
<bac> or is it?
<sinzui> bac: team-portlet-membership is 1) missing +mugshots and 2) "Show all members" => "All members"
<sinzui> bac: do you have time to work on this?
<bac> sinzui: i do
<bac> sinzui: i don't understand your => comment
<sinzui> the link in he <h2> is not the correct language
<bac> sinzui: should it not get it as defined in the link?
<sinzui> bac: "show" is not to appear in those links. they are verbless
<bac> sinzui: right.  so shouldn't it be fixed in the menu and then used here?
<sinzui> no
<sinzui> the menu is correct because the link is used in many plackes. the portlet hack is is an exception that will probably be removed in 4.0
<bac> sinzui: http://people.canonical.com/~bac/team-index.png
<bac> sinzui: i suspect we want those stacked?
<sinzui> no
<bac> sinzui: then you like it as shown?
<sinzui> bac we do not encourage the heading link crack. Use the real link.
<sinzui> (i) Show member photos
<sinzui> ^ We commonly show menu in  <ul class="horizontal">
<sinzui> bac I would put the link above the Recently approved because I think the lists in this portlet are optional
<bac> sinzui: for both or just mugshots?
<sinzui> just mugshots. bac: this should look like portlets used on pillars. There is nothing special about this portlet
<sinzui> The portlet is missing a <h2> now that I look again at the picture. We can guess it is about members
<sinzui> This wacked
<sinzui> bac: look at https://edge.launchpad.net/~bac portlets need a <h2> with a .see-all hack in it. There is some information, then links to relataed pages or actions you can take
<sinzui> bac: this has some good examples too: https://edge.launchpad.net/launchpad-registry
<sinzui> ^ I think VIew fill history is wrong because the link text makes sense in the case
<rockstar> sinzui, there is supposed to be a slot to the right of the title for creation date, etc.  Does that exist?
<sinzui>  <tal:registering metal:fill-slot="registering">
<sinzui> rockstar: I just used it for the first time a moment ago
<sinzui> It works
<rockstar> sinzui, great, thanks.
<bac> sinzui: how's this? http://people.canonical.com/~bac/team-index.png
<bac> sinzui: i used the icon as defined in the link, not the (i)
<sinzui> r=me
<sinzui> bac: you are correct
<bac> sinzui: i'll land it with my contact team branch
<sinzui> fab
<sinzui> EdwinGrubbs: did you ever find the decline a blueprint part of sprint
<EdwinGrubbs> sinzui: I could not find the url for ISprintSpecification/+decide
<sinzui> EdwinGrubbs: I add a few specs to a sprint, and now I cannot remove them. I am glad this feature is well hidden
<EdwinGrubbs> gary_poster: I was going to start to work on sources-list.pt unless there is something else that is more important.
<gary_poster> EdwinGrubbs: thank that would be great.  I'm working on a MP now, which I will send your way, if you are willing.
<EdwinGrubbs> gary_poster: sure, I can review it
<gary_poster> thank you
<sinzui> EdwinGrubbs: Add /<sprint-name> to the end of the spec url (I assume after  you have add one or more sprints) eg
<sinzui> https://blueprints.launchpad.dev/firefox/+spec/canvas/futurista
<EdwinGrubbs> sinzui: ok, thanks
<sinzui> I wonder if I should add a link to it from the index
<kfogel> danilo-afk: you're landing patches as danilon {AT} babaroga, and it's screwing up our community-contributions.py script :-)
 * kfogel adjusts the script
<kees> deryck: cool; let me know if I can help at all
<deryck> kees, this isn't going to be able to land this cycle, sorry man.  There's some zcml weirdness with the permissions, and actually there will be a number of lines failing in the test now.
<deryck> kees, and I just don't have time to chase it all down today.  sorry.
<kees> deryck: ok, cool.  thanks for taking a look
<deryck> kees, no problem.  I can probably get it next week some time and land it soon as pqm opens the week after.
<deryck> gotta run.  later on, all.
<lamalex> Hi guys, the "getting the code" part of getting lp is broken
<lamalex> the file you bzr cat doesn't seem to exist
<lamalex> or the link format changed
<jamalta> lamalex: which step are you having an issue with?
<jamalta> nvm it is an issue
<lamalex> :) i mean i figured it out
<jamalta> ahh
<lamalex> but i figured you guys would like to know about it
<jamalta> yeah they probably do
<rockstar> sinzui, around?
<sinzui> I am
<rockstar> sinzui, so, I'm moving all the page_titles around, and there's one case that I can't see how it ever worked.
<rockstar> sinzui, if you go to answers.launchpad.dev and search there, it's trying to take the title from IQuestionSet.displayname which doesn't exist.
<sinzui> right
<rockstar> The logic hasn't changed, I just renamed from pageheading to page_title and removed the fallback from pagetitles.py
<rockstar> sinzui, since I can't see how this ever worked, I don't have many ideas on how to fix it.
<sinzui> It worked because the template was god. now it is not
<sinzui> rockstar: does the url have a special view?
<rockstar> sinzui, no, it's one that's reused for all search.
<sinzui> hmm
<rockstar> sinzui, I think I have a fix.
<rockstar> sinzui, how do I check that a class is of a certain interface?
<sinzui> IMYInterface.providedBy(self.context)
<wgrant> lamalex: Is rocketfuel-setup working for you? There's a bug at the moment where unless you're a Canonical employee it will probably not download all the stuff you need.
<wgrant> lamalex: If you run into that, I have a patch.
<wgrant> Which I must get merged soon!
<lamalex> wgrant: i think it's not working
<lamalex> the script finished running make schemas fails
<wgrant> lamalex: Run 'rocketfuel-get', and see what it says.
<lamalex> ... running but ..
<wgrant> Something about shipit?
<wgrant> If rocketfuel-get does give you a traceback, try applying http://pastebin.ubuntu.com/273832/.
<lamalex> wgrant: is this the trace you're expecting? http://paste2.org/p/429284
<wgrant> lamalex: Urgh. No.
<wgrant> That's much worse.
#launchpad-dev 2009-09-19
<lamalex> :\
<wgrant> I see why it happens, though.
<wgrant> lamalex: Do you have the log from the original run of rocketfuel-setup?
<lamalex> wgrant: where would it be
<wgrant> lamalex: In the terminal buffer.
<lamalex> wgrant: no, dont have anymore
<wgrant> lamalex: What does 'make' do?
<lamalex> it's running some scripts, i'll let you know how it terminates
<lamalex> wgrant: http://paste2.org/p/429291
<wgrant> lamalex: OK, that's what I would expect.
<wgrant> lamalex: Does rf-get work now?
<lamalex> just got the shipit error
<wgrant> lamalex: Great. Apply the patch and rerun rf-get.
<wgrant> I'll run rf-setup myself this morning and see exactly how it breaks.
<wgrant> At least we don't have a circular bootstrapping issue.
<lamalex> wgrant: that shipit error was with your patch
<wgrant> lamalex: But did the script continue to run?
<wgrant> Without the patch it should be fatal. With the patch it should continue.
<lamalex> but now make run fails :P
<lamalex> and is there a simple way to make the instance public so I can access it? it's on my vps..
<lamalex> ah, i see
<wgrant> make schema?
<wgrant> utilities/launchpad-database-setup?
<wgrant> https://dev.launchpad.net/Running/RemoteAccess
<lamalex> wgrant: yah just saw that last bit
<lamalex> hmm rocketfuel-setup seems to have not pulled in twisted?
<wgrant> rocketfuel-get should do that.
<wgrant> Do you still have the output of its last run?
<lamalex> http://paste2.org/p/429309
<lamalex> rocketfuel-get's last run?
<wgrant> Yes.
<wgrant> Oh.
<wgrant> I know.
<wgrant> utilities/link-external-sourcecode ../../lp-sourcedeps
<wgrant> That wouldn't have worked when rf-setup ran it, because rf-get failed.
<wgrant> (I'm currently running rf-setup locally to work out what's broken...)
<lamalex> lots :P
<lamalex> now it needs bzr loom which it didnt pull
<wgrant> rf-get should do that.
<wgrant> and link-external-sourcecode should link it in so LP can see it.
<lamalex> wgrant: think this is the issue? http://paste2.org/p/429313
<wgrant> lamalex: Yes. Looks like you killed rf-get in the middle at some point?
<lamalex> not afaik but possibly
<wgrant> lamalex: Just remove that subvertpy dir and rerun.
<lamalex> where's the subvertpy dir? in ../../lp-sourcedeps/sourcecode/subvertpy
<lamalex> ?
<wgrant> Yes.
<lamalex> merci
<wgrant> Alright, rf-setup running. Let's see what breaks.
<wgrant> (update-sourcecode - as used by rocketfuel-get - was rewritten earlier in the week, so its unsurprising that something is broken)
<wgrant> Is it working better now?
<lamalex> I /think/
<lamalex> rerunning make schema
 * lamalex crosses his fingers
<lamalex> woo!
<lamalex> thanks wgrant
<wgrant> lamalex: That was quick.
<wgrant> Does make run work now?
<lamalex> wgrant: yup! up and running
<wgrant> lamalex: Excellent.
<wgrant> Filing two bugs now.
<wgrant> lamalex: Bug #432830
<mup> Bug #432830: rocketfuel-setup does not work <Launchpad Foundations:New> <https://launchpad.net/bugs/432830>
<lamalex> wgrant: is it possible to set up registration emails for a different domain name?
<lamalex> hm why is superspace in here
<lamalex> nm
<lamalex> my terminal just hadn't refreshed
<wgrant> lamalex: What do you mean? All email is redirected to root@localhost, as you'd want for a dev setup.;
<lamalex> wgrant: ah, ok
<lamalex> wgrant: any info on what i need in terms of a keyserver for soyuz?
<wgrant> lamalex: I have full docs on setting up a local Soyuz setup. Let me check that they're up-to-date and upload them somewhere.
<lamalex> :) merci
<wgrant> lamalex: It used to be much harder, but I've patched bits and pieces so it's pretty easy now.
<wgrant> How much do you want to do?
 * lamalex isn't sure what the limits are.. I want to be able to push and build?
<wgrant> lamalex: http://williamgrant.id.au/f/1/2009/running-soyuz.html has the basics of a pretty awful dev setup. There are a few things there that are only necessary if you're running Karmic.
<lamalex> thanks
<wgrant> lamalex: When you get to the chroot building stage, it really is much easier to grab an Ubuntu one.
<wgrant> \
<wgrant> lamalex: Oh yeah, you might also have to change the NTP host in /etc/launchpad-buildd/default
<rockstar> \o/ Branch index redesign has landed.
<wgrant> rockstar: This I must see.
 * wgrant updates
<wgrant> sinzui: Do I want to file bugs on dodgy padding in the side portlets?
<sinzui> I think so.
<sinzui> wgrant: can you point me to a page to see an example?
<wgrant> sinzui: There's 0.3em too much padding at the bottom of the context actions portlet.
<wgrant> There's too much at the top of side portlets that start with an h2.
<sinzui> i see
<sinzui> There is also too much at the bottom of the side abr
<wgrant> So there is.
<sinzui> I could not get a simple even boarder when I played with it 2 days ago
<wgrant> I also think the dark grey of the side bar could also do with some decoration (eg. rounded corners?)
<sinzui> I'll set beuno on to that issue.
<wgrant> It would also be really nice to un-break the tabs/watermark for distroseries/distoarchseries/distributionsourcepackage/sourcepackage/productseries.
<wgrant> But I guess that's unlikely for 3.0 :(
<sinzui> that is a 4.0 goal
<wgrant> So it's just going to be utterly confusing until then?
<sinzui> There is a bug that we did not get to fix since the breadcrumb code landed late. I want to show karmic in the crumbs, not 9.10
<wgrant> That doesn't really help the crazy behaviour of the tabs on https://edge.launchpad.net/ubuntu/+source/dpkg
<wgrant> However, the 3.0 UI is a really really great improvement.
<wgrant> Particularly as the migration will actually be finished.
<sinzui> Well the UI will be consistent enough that the problems will be more obvious.
<sinzui> I there some non-sense in sidebars and heading that I don't think will be resolved until 3.10
<wgrant> I think it's a bad idea for 3.1.10 to be 6 weeks, but I guess you've no choice what with Karmic in the middle.
<wgrant> IMO a normal-length cycle to fix 3.0 quickly could be better.
<sinzui> Yes. We should have have an extra week in July/August but we had dates we had committed too at that time
<wgrant> Ah.
<sinzui> 6 weeks is tool long for a release. this UI was too long...
<wgrant> better than not getting it finished like 1.0 and 2.0.
<sinzui> but that is what happens when you do a mediocre job the previous year
<sinzui> :)
<wgrant> lamalex: Did you run into any issues/
<lamalex> wgrant: haven't tried yet. Went out for a bit. Will probably mess around more with it tomorrow, wondering now how to do a vcs import
<wgrant> lamalex: That's one thing I've not done, but I hear it's fairly easy.
<wgrant> lamalex: What are you wanting to do with it?
<lamalex> import a git repo
<lamalex> hm.. can't figure out what script to run to ge the import to actually happen
<wgrant> lamalex: cronscripts/code-import-dispatcher.py
<lamalex> ahh
<lamalex> thanks :)
<wgrant> Is it working?
<wgrant> I haven't locally used vcs-imports at all, and codehosting only minimally.
<lamalex> not sure, it looks like it ran, but it's not showing any revisions
<wgrant> Check the directory manually.
<lamalex> where's that
<wgrant> It won't show revisions in the web UI until you scan the branch.
<wgrant> No idea.
<wgrant> Well, it should be somewhere under /var/tmp
<lamalex> ah, so need to run another script to scan the branch?
<wgrant> Yes.
<wgrant> There's a make target for it..
 * wgrant hunts.
<wgrant> make sync_branches
<lamalex> hmm.. failed
<lamalex> supermirror-pull.py: error: Unhandled arguments ['upload']
<wgrant> Try just 'make scan_branches'?
<wgrant> Might not have to pull it.
<lamalex> hmm the vcs I added gives an error
<lamalex> 2009-09-19 06:08:22 INFO    OOPS-1358BS1: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://bazaar-internal.launchpad.dev/00/00/00/4d/.bzr/branch-format  (~vcs-imports/jolicloud-netbook-config/trunk)
<wgrant> No idea.
<lamalex> yah
<lamalex> got it, apache config failure
<wgrant> Damn, build failre.
<wgrant> +u
<lifeless> u+something
 * wgrant thwacks lifeless.
<lifeless> mmmm
<wgrant> The breadcrumbs and title on https://answers.edge.launchpad.net/ubuntu/karmic/+source/gnome-terminal/+addquestion make me sad.
<wgrant> The most specific title segment is buggy, and also contains all of the information in the rest of them.
<lifeless> I'm not a fan of breadcrumbs as a concept
<wgrant> I think they're a great idea, but not quite in the current implementation.
<elmo> restarted poppy on germanium
<wgrant> elmo: Thanks.
<wgrant> How easy is it for somebody to look up an OOPS that occurred at a particular URL?
<wgrant> (in particular I'm interested in the traceback for the OOPS caused by a POST to https://api.edge.launchpad.net/beta/ubuntu/+archive/test-rebuild-20090909 around 0740 UTC today.
<wgrant> Can I express conjunction in TALES without having to resort to python: ?
<bac> henninge: thanks for doing the testfix
<henninge> bac: np
<bac> henninge: it was nice to wake up seeing all of that red but finding you'd already got a fix in.
<henninge> bac: see, there *is* an advantage of us all living in differnt time zones ... ;-)
<bac> henninge: i feel bad for the dudes down under.  it seems they spend a lot of time cleaning up after us...
<henninge> bac: but from what I hear, they also have it nice and quiet. Just a few of them, always reviewing each other's branches, no long queues ... ;)
<wgrant> Hm, this is interesting.
<wgrant> I have a case where the root context of an object is incorrect.
<wgrant> It's a distribution archive. The object directly above it is a distribution.
<wgrant> Yet the root context is an IPerson.
<wgrant> I think this is because there's an adapter from IArchive to IPerson, which descends from IRootContext.
<wgrant> It seems pretty fragile.
<bac> mwhudson: ping
<mwhudson> bac: 1 am on a sunday, not likely
<bac> mwhudson: yeah, my tz math was off!
<wgrant> I don't see breadcrumb guidelines on the 3.0 conversion page
<wgrant> Some of them are pretty bad at the moment, eg:
<wgrant>    1.    Ubuntu
<wgrant>    2. âconkyâ package
<wgrant>    3. Questions for âconkyâ package in Ubuntu
<wgrant>    4. Ask a question about conky in ubuntu
<wgrant> I'd be happy to go around and fix them, if there were guidelines or a known-good example.
#launchpad-dev 2009-09-20
<jml> wgrant, I think there's only the various mailing list threads about them (all on launchpad-dev), and what's on the conversion page.
<lifeless> jml: fly well
<jml> lifeless, thanks.
<lifeless> mwhudson: you wouldn't happen to be around?
<maxb> Does anyone else find 'make check' sometimes aborting because branch-rewrite is holding open a db connection to launchpad_dev?
<maxb> Why does 'make check' care about the launchpad_dev DB anyway?
<gmb> wgrant: Your branch made it through EC2... should be hitting PQM soonish.
<rockstar> Has anyone done anything about the db_lp failure?
<intellectronica> rockstar: ??? looks green in buildbot
<maxb> "The Launchpad web service is currently in a limited beta, open to Launchpad's beta testers. " <--- this is now a lie, right?
<maxb> Hrm, https://help.launchpad.net/API is acl-ed to AdminGroup edits only
<intellectronica> maxb: i believe it is indeed a lie. if you don't mind filing a bug on the launchpad-documentation project that would be great. we can get it fixed tomorrow
<intellectronica> (sorry but i myself can't edit that page)
<mwhudson> failure on db_lp :(
<bac> hi mwhudson -- are you working on the db-lp failure?  if not i'll submit it.
<mwhudson> bac: yes
<mwhudson> bac: let me check it's landed
<bac> mwhudson: thanks.  at least it is a trivial fix.
<mwhudson> bac: yeah, it's fixed
<bac> mwhudson: do you know why paul landed that against db-devel and not devel?
<mwhudson> bac: indeed, and an integration failure, noone to blame except our processes :)
<mwhudson> bac: i do not, maybe it was the fact that week 4 landings are usually db-devel only
<bac> mwhudson: but that isn't until after PQM closes, i thought...
<bac> mwhudson: anyway, thanks for fixing it
<mwhudson> bac: only guessing
<bac> mwhudson: hey i have an ec2test question
<mwhudson> bac: i'm on the phone to tim, but ok if it's a quick one :)
<bac> mwhudson: i'll ask and you can answer at your leisure.
<mwhudson> bac: cool
<bac> mwhudson: i ran the 'aws management console' yesterday and saw i had three instances running that had been there for a couple of days.  :(  i recall having done a ctl-c to abort the start up of an ec2test or two.  could that have left them running?  is it a known problem?
<mwhudson> bac: yes, it could
<mwhudson> bac: i think it got more robust in my recent landing
<mwhudson> bac: there are probably always going to be races there though
<bac> mwhudson: cool.  i'll be more vigilant about following up.  so i pissed away $40 or so...
<thumper> https://code.edge.launchpad.net/~simono/ubuntu/karmic/powertop/fixes-bug-428254
<mwhudson> bac: compared to the buildbot AWS account noone will notice :)
<bac> true
<wgrant> gmb: Thanks.
* bac changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html
#launchpad-dev 2010-09-20
 * thumper has lost pyflakes
<lifeless> its nice when one index cuts 50% time off of things
<thumper> lifeless: like what?
<lifeless> thumper: https://bugs.edge.launchpad.net/malone/+bug/618396
<lifeless> it won't help with the count(*) blow-out which happens from time to time, but it will shift the whole page performance down bu 1.4seconds or so
<thumper> wallyworld: you are very quiet in your corner there
<thumper> wallyworld: how are things going?
<wallyworld> thumper: head down, tail up
<thumper> wallyworld: what are you looking at now?
<lifeless> his navel, by that description
<thumper> mwhudson: can I have a quick pre-impl with you about branch-distro?
<wallyworld> i've landed 3 branches of late and am finishing up the default reviewer test cases prior to doing a mp
<wallyworld> after that i was wanting to have a catch up
<mwhudson> thumper: ok, one sec
<thumper> wallyworld: sounds good
<thumper> wallyworld: I want to head to lunch after a quick chat to mwhudson
<thumper> it should be very quick :)
<wallyworld> thumper: ok, do you want to call me when you are free
<thumper> wallyworld: sure
<mwhudson> thumper: ok
<lifeless> hmm, thats 4 ec2 lands I have running at once.
<mwhudson> ah, helps if i launch skype
<thumper> wallyworld: I'll call you after lunch
<lifeless> Need moar to do
<wallyworld> thumper: ack
<lifeless> StevenK:
<lifeless> StevenK: ping
<lifeless> spm: also when you, oh, three minutes or so I need help QAing a patch on staging.
<lifeless> of course that need staging running
<spm> yes, one would tend to follow the other :-)
<lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342/comments/3 is what I'll need your help with
<lifeless> oh, also
<lifeless> 'garbo-daily' didn't run. Not that you need more queued items to look at :)
<spm> you guys get the logs for those too, fwiw. :-)
<lifeless> where?
<spm> sodium: locate 'garbo' | grep log | head ==> /x/launchpad.net-logs/scripts/loganberry/garbo-daily.log
<spm> bleh, still doing the session prod fail thing
<lifeless> $ less /x/launchpad.net-logs/scripts/loganberry/garbo-daily.log
<lifeless> /x/launchpad.net-logs/scripts/loganberry/garbo-daily.log: No such file or directory
<lifeless> ah, date suffixes
<spm> well locate is always older; yarp
<lifeless> it would  be very interesting to say 'no increased LOC outside of tests.'
<lifeless> I wonder if that would fly.
<mwhudson> aaaaaaaaaaaaaaargh
 * mwhudson is splitting up a doctest and man, sample data sucks
<mwhudson> as do hidden parameters
<lifeless> you have my sympathy
<lifeless> poolie: I'd just *love* it if you were to do some more on the UI for flags
<poolie> ah, this week i'm feeling you might be lucky
<lifeless> \o/
<lifeless> StevenK: Yo
<lifeless> edge was happy over the weekend
<lifeless> 38 Time Outs
<lifeless> possibly time to lower it again.
<lifeless> 112 /  236  CodeImportSchedulerApplication:CodeImportSchedulerAPI has reached #1
<lifeless> 104 /  218  BugTask:+index
<lifeless>       44 /   33  RootObject:+login
<lifeless>       40 /   56  DistributionSourcePackage:+filebug
<lifeless>       37 /   12  Distribution:+search
<jelmer> lifeless: hi
<poolie> hi jelmer
<lifeless> hi jelmer
<lifeless> jelmer: if you're actually around now, theres a soyuz patch blocking further migrations of bugfixes to production
<lifeless> jelmer: its what I was pinging about the other day
<lifeless> stub: hi
<lifeless> stub: can we talk indexes for a minute?
<jelmer> lifeless: Which patch is that?
<stub> lifeless: ok - gimme a minute to finish this coffee
<lifeless> jelmer: rev 11556
<lifeless> stub: take your time
<lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/bug-121363/+merge/35971 and https://code.edge.launchpad.net/~lifeless/launchpad/bug-618396/+merge/35970
<jelmer> lifeless: I'm seeing some similar errors to the OOPS one you fixed earlier. The OOPS ID in the job runner test that you fixed is off now.
<lifeless> jelmer: ECONTEXTFAIL
<jelmer> lifeless: sorry
<stub> y
<stub> o
<lifeless> jelmer: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt is the thing I look at for things to deploy.
<lifeless> stub: hey
<lifeless> stub: so I was looking at a timeout with bug searching and noticed that importance isn't indexed.
<lifeless> stub: there was a similar issue already reported with date_closed; I've used a slightly unusual index syntax to get the (foo desc, id) ordering working
<lifeless> stub: wondered if you're ok with this (and if so, can we add these indexes w/o downtime)
<lifeless> stub: spm added the importance one to staging for me for testing
<spm> yo stub
<lifeless> jelmer: so, some context and I can understand what you're talking about :)
<stub> So with PG 8.2 we would never use the index on importance. We might now if it is there. Did you test any example queries to see if they made use of the index on staging?
<lifeless> yes
<lifeless> 3500ms -> 1800ms
<lifeless> the key thing is the ordering of the second field
<stub> Ok. Adding both of those indexes makes sense, and we can create them live.
<lifeless> cool
<stub> We have a date_closed index - UNQUE (date_closed, id) WHERE status = 30
<lifeless> yes, it won't be used
<lifeless> oh, bah, I missed the unique and partial aspects
<lifeless> anyhow it needs to be '(date_closed, id desc nulls first)'
<lifeless> to be used.
<stub> The index would be used if you are limiting the search to FIXRELEASED bugs.
<jelmer> lifeless: sorry, looking at that revision now
<lifeless> stub: no, due to the query being "order by date_closed desc, id"
<lifeless> http://www.postgresql.org/docs/8.3/static/indexes-ordering.html
<stub> Right. So we should drop that index then I think.
<lifeless> jelmer: great, please do: if you can qa it as ok to deploy, or incomplete (can just remove the qa-* tags I think in that case), we can deploy more stuff
<stub> (the existing one that is less useful than the one we are creating)
<lifeless> stub: I can't see that UNIQUE status=30 index
<lifeless> stub: in launchpad_dev
<stub>     "bugtask__date_closed__id__idx" UNIQUE, btree (date_closed, id) WHERE status = 30
<lifeless>     "bugtask__date_closed__id__idx" btree (date_closed, id DESC)
<lifeless> stub: anyhow, my patch drops it
<lifeless> oh foo
<lifeless> I've applied my patch
<lifeless> anyhow, my patch drops that index and adds bugtask__date_closed__id__idx2 (does that first so there is no point without an index)
<lifeless> stub: should my new one also be partial?
<stub> I need to split it in two anyway if we want the indexes built live - dropping indexes has to wait until the next db update.
<lifeless> stub: interesting. I'm curious why it needs to wait ?
<stub> It needs to grab an exclusive lock on the table for a short period, and that will never happen on the live system.
<lifeless> ah, but adding doesn't ?
<stub> CREATE INDEX CONCURRENTLY - special syntax.
<lifeless> ok
<lifeless> what should I do to my patch.
<lifeless> a) make it partial?
<lifeless> b) make there be two patch files?
<stub> Can I see your patch as it stands?
<lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/bug-121363/+merge/35971
<lifeless> separate one for importance : https://code.edge.launchpad.net/~lifeless/launchpad/bug-618396/+merge/35970
<stub> I'm unsure on the partial thing - it will be smaller, which makes things using it faster. But we have to be sure that our test queries still make use of it (ie. for all queries we want to use it we have to specify STATUS=30 in the WHERE clause, and confirm PG is smart enough to realise this matches the index and it can be used - fine for simple queries, but want to test more complex stuff to make sure that info doesn't get lost).
<lifeless> about 50% of bugs are closed IIRC
<lifeless> so its not going to be masssively smaller - not even a single height difference in any decent sized btree
<jelmer> lifeless: I don't think I'll be able to get to it today (I'm on leave), perhaps StevenK is around to have a look?
<lifeless> jelmer: sure, I'll naggify him
<lifeless> jelmer: its sunday, of course you're on leave.
<lifeless> jelmer: whats the OOPS thing about
<jelmer> lifeless: I'm on leave this week as well (I'm in CA)
<lifeless> ah!
<lifeless> jelmer: have fun!
<jelmer> lifeless: I'm trying to land my final branches for the buildd master performance improvements, and jml and bigjools are sprinting on some incremental stuff for that this week
<jelmer> lifeless: but one final test (the one you fixed up some stuff in last week wrt OOPSes) is still failing. The OOPS ID the test is expecting is off by one.
<jelmer> lifeless: any idea what might be going wrong? It's definitely another test isolation issue.
<lifeless> what do you mean 'off by one'
<lifeless> pastebin the test perhaps, and the error
<lifeless> stub: so I think it shouldn't be partial
<stub> lifeless: yup
<lifeless> stub: ok, and you want two patch files ?
<stub> I'll just do the review with patch numbers
<lifeless> thanks
<thumper> wallyworld: if you are working in branch foo, and have devel at the same depth in the directory
<thumper> wallyworld: go `bzr merge --preview -d ../devel .`
<stub> lifeless: Is the bugtask.importance index being applied live too?
<lifeless> stub: please
<jelmer> lifeless: http://pastebin.ubuntu.com/496781/
<thumper> lifeless: oops 1723XMLP312 :((
<stub> I guess including id in the indexes is necessary now, as batch jobs can set date_closed in bulk. Previously id was only there to keep the test suite happy.
<thumper> # SQL time: 14 ms
<thumper> # Non-sql time: 34074 ms
<lifeless> stub: do we need the UNIQUE ?
<lifeless> jelmer: where is the test code?
<lifeless> jelmer: oh, I see, unmodified
<jelmer> lifeless: yes, the test is unmodified so it's a test isolation problem. I have (obviously) changed other parts of the tree.
<jelmer> The test doesn't fail when run by itself, only on ec2 as part of a full test run.
<lifeless> jelmer: and what do you mean by off by one ?
<stub> lifeless: It doesn't make any practical difference. In this case, I'd say not. But that is a pretty arbitrary call.
<jelmer> If you look at the last line, you'll see that the assertIn fails because the string that we look for has a slightly different OOPS ID
<lifeless> stub: ok, I was wondering if there was a practical issue here
<stub> lifeless: Maybe in some future version of PG
<thumper> lifeless: it is worth looking at oopses 1723XMLP307 1723XMLP308 1723XMLP309 1723XMLP310 as well
<jelmer> lifeless: OOPS-1721T6 vs OOPS-1721T7
<lifeless> \o/ next CP passed ec2 now to wait for bb
<wgrant> Up to where?
<lifeless> wgrant: the soyuz thing
<lifeless> StevenK: yo!
<mwhudson> talking of hidden parameters earlier
<mwhudson> now i'm reading a shell script
<mwhudson> :(
<wgrant> mwhudson: buildd?
<wgrant> Or something less sinister?
<lifeless> thumper: thats -special-
<thumper> lifeless: I'm going to talk to spm to see if we can see what else was going on at the time
<lifeless> gl
<lifeless> we've got a single-threaded appserver setup on the way
<mwhudson> wgrant: do you know what lexbuilder is?
<wgrant> mwhudson: A ha ha.
<wgrant> I have heard about it.
<mwhudson> i guess it
<mwhudson> i guess it's kinda like buildd, but based around live-helper, not sbuild
<lifeless> stub: can you give me a shout when those indices are up, I want to see how much of a difference it makes to the overall feeling
<poolie> heh, so part of the reason dkim is not working completely is a lack of DRP
<poolie> DRY
<lifeless> do repeat yourself?
<poolie> iow a higher level doesn't ask "is it authenticated" but "does it have a gpg signature"
<stub> lifeless: You are landing those branches?
<lifeless> stub: they are queued in https://pqm.launchpad.net/
<lifeless> jelmer: ok thats a reasonable clue
<lifeless> jelmer: for some reason the unique file namer is reusing an older OOPS id
<poolie> urk
<stub> lifeless: Land them now. There is no point me kicking of the index builds yet as they will block until the daily backup has completed (CREATE INDEX CONCURRENTLY has to wait on all existing transactions to complete at one point of the process)
<lifeless> probably a missing +1 somewhere.
<lifeless> stub: yes, they are landing ;)
<stub> And I'm typing slow
<lifeless> stub: there are three branches is in pqm is all
<lifeless> :>
<stub> lifeless: So unless you want me to kill the daily backup, we are waiting 5 hours.
<stub> (8 hours! Geez...)
<stub> (Death to BranchRevision!)
<lifeless> stub: it wouldn't worry me
<lifeless> stub: we have redundant copies of the data anyway; is that backup offsite?
<stub> I'm told the backups get copied somewhere, but I haven't seen the rsync scripts or know the final destination - that is IS magic.
<lifeless> spm: yo, mr IS.
<lifeless> ^
<stub> There is an antique RT trying to get confirmation on this, as I wanted to confirm that everything being backed up is what I think is being backed up (inspired by a call for disaster recovery a year or three ago)
<lifeless> heh, yes, I see that RT every time I go look at RFWTAD progress ;)
<lifeless> stub: would you be up for a learn-cassandra sprint early next year, in principle?
<lifeless> learn/evaluate that is
<poolie> i would be
<poolie> :)
<stub> lifeless: If the timing is good and it is in an exciting location ;)
<lifeless> poolie: I'll keep that in mind
<lifeless> stub: can you let me and statik know what timings are bad for you then ?>
<lifeless> stub: as for the location, nowhere is as exciting as bangkok
<lifeless> sorry.
<stub> lifeless: Any time is good really. Late march early april would be best for my visa purposes, but that is my problem really ;) Bangkok is fine! Come on over! But before April as that would be the preferred timing for the next lot of mass protests or coup.
<lifeless> stub: possibly jan - U1 want to really evaluate cassandra
<poolie> lifeless: just invite people til the centre of gravity converges on your prefered location :)
<stub> (They like to hold these events on long weekends so everyone can participate, and the Songran holiday is the longest weekend)
<poolie> if that's "dunedin" it may be difficult :)
<lifeless> their sharding story is not as nice as they'd like.
<lifeless> in all seriousness I'd be expecting e.g. florida or something
<stub> Dunedin is fine if there is skiing. Jan doubles up with the LP sprint in Dallas.
<poolie> i might try to poke dkim along a bit first, then do flags
<mwhudson> even in dunedin i don't think there will be much snow in january
<stub> Probably more than AU in high season though.
<lifeless> 0 > 0 == False
<ajmitch> yay for precedence?
<poolie> heh gotta love python
<poolie> i'm sure that seemed like a cute idea at the time
<poolie> 1 > 0 == False ====> True
<mwhudson> oh it's chaining, isn't it
<stub> If you aren't using brackets for clarity you deserve what you get.
<stub> Pitty the language doesn't enforce it.
<poolie> it's not just precedence
<poolie> the problem is that it transforms to
<poolie> (1 > 0) and (0 == False)
<mwhudson> http://python.net/~mwh/blog/nb.cgi/view/weblog/2006/05/15
<poolie> it seems like such a small win at a price of being inconsistent with everytihng else
<poolie> maybe not perl?
<poolie> mwhudson: because 'XXX', 'in' and 'progress' might later turn out to be defined?
<poolie> that's pretty cute
<poolie> oh wow
<mwhudson> poolie: well
<mwhudson> 'in' is a keyword
<stub> Taipei! It was all 'everyone should get to Taipei to see the amazing stuff being done there' and then we kept having sprints in N.America.
<mwhudson> but otherwise yeah
<mwhudson> it was a mistake of course, the - was meant to be #
<poolie> "a == 2 or fucked-up"
<lifeless> stub: ok, so in 6 hours I should ask agian ?
<stub> or 5 hours
<lifeless> stub: yeah, but you need time to add them :P
<stub> I might need to be reminded too ;)
<lifeless> ok, 8pm
<lifeless> StevenK: ping . Surely you're not _still_ asleep at 1pm
<spm> note to self. LPIA != PA-RISC. wgrant, that builder is now lpia (again)
<wgrant> spm: Which builder?
<wgrant> Ah, in the question.
<wgrant> Thanks.
<wgrant> Looks good.
<spm> oh. sorry, yes. rehinium or similar spelling
<lifeless> stub: 44 /   33  RootObject:+login - I think thats the OAuthNonce thing, 3rd highest oops count atm
<wgrant> is there a good reason for OAuthNonce to be in the DB, rather than memcache?
<stub> We actually make use of the transactional integrity it gives us for some edge cases
<stub> I had a branch that moved it to memcache, which is when I picked up on this.
<wgrant> Does a request retry try to perform the authentication again?
<stub> I don't know why +login is messing with OAuthNonce - oauth is a different authentication system to +login which is OpenId (I don't think they make use of the same views?)
<stub> wgrant: Yes - the whole request is tried again
<wgrant> Ah.
<StevenK> lifeless: No, I was afk. Hm?
<lifeless> StevenK: can you please qa rev 11556?
<StevenK> lifeless: Fix an OOPS when an archive admin uses the +queue page to
<StevenK>         accept uploads that close private bugs.?
<lifeless> StevenK: there are two linked bugs on that patch
<lifeless> both need to be qa'd
<lifeless> I'm told dogfood is involved.
<lifeless> wgrant reported them and can probably advise.
<lifeless> StevenK: if they aren't qa'd, its a team wide pipeline stall :- qa matters :P
<wgrant> I'm pretty sure that one of them isn't fixed, but it's easy enough to QA.
<lifeless> if its not fixed, but no worse, tag it qa-ok, set the status back to triaged.
<wgrant> If you can't work out details, give me a yell.
<lifeless> StevenK: the bugs are linked from the commit message.
<StevenK> Well, duh
<StevenK> lifeless: Can you give me a few minutes to actually get state rather than jumping and asking "Is it QA'd yet? How about now? Now?"
<lifeless> StevenK: Sure, I was simply meaning to give context for assessing priority.
<lifeless> I realise that qaing it may take time
<lifeless> StevenK: also, I forgot to tell you this last week; statik is ok with funding your hudson experiments on ec2.
<lifeless> StevenK: just expense it while its in the current ballpark; if it starts to really go up in $$$ let me know and we'll recheck.
<StevenK> lifeless: My EC2 usage is currently ~ $85US for the month
<lifeless> yes
<lifeless> the linode is dedicate to hudson too right ?
<StevenK> It is
<lifeless> so, 160 - long as it stays under 200 I'm sure statik will have no concerns; if its going to go over, ping me
<StevenK> To be completly honest, I think that's another 2 days of test running.
<lifeless> who do your expense claims get sent to ? bigjools or vlumper?
<StevenK> lifeless: Julian
<spiv> vlumper, our transylvanian code team lead?
<lifeless> spiv: virtual flacoste :P
<wgrant> He's still flumper to me.
<lifeless> mailed
<StevenK> wgrant: So, create an upload to dogfood that closes a private bug, and see if it goes bang when I accept it. If not, bug 564491 is qa-ok.
<wgrant> StevenK: not when you accept it -- it needs to be a non-admin.
<StevenK> I can fix that
<wgrant> True.
<StevenK> I think I've dropped my duck on dogfood
<lifeless> StevenK: the short story is : do not stress about the bill. Don't drain the bank account, but don't stress.
<lifeless> lol. 'dropped the duck'
<StevenK> wgrant: And for bug 566339, create an upload that uses a private e-mail address for Changed-By, same deal.
<wgrant> StevenK: I think 566339 is probably not fixed, but yes.
<lifeless> thank you guys
<StevenK> Yes, but I'd like to confirm it, so I can pull lifeless off my back and onto someone elses. :-P
<wgrant> Heh.
 * StevenK looks for a private bug
<poolie>     ZopeXMLConfigurationError: File "/home/mbp/launchpad/lp-branches/dkim/lib/canonical/launchpad/webapp/configure.zcml", line 204.4-209.10
<poolie>     ImportError: cannot import name SAFE_INSTRUCTIONS
<poolie> does that mean anything?
<mwhudson> poolie: run utilities/update-sourcecode
<wgrant> poolie: update-sourcecode
<poolie> thanks
<wgrant> Your bzr-builder is out of date.
<mwhudson> wgrant: is http://williamgrant.id.au/f/1/2009/soyuzness.html still vaguely current?
<wgrant> mwhudson: No.
<wgrant> There's a wiki page
<wgrant> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
<wgrant> It is an evolved version of the original.
<mwhudson> thanks
 * mwhudson is going to try to set up his beagle board xm as a local builder, sounds like a fun waste of time
<lifeless> also you may need to delete lib/mailman and run 'make
<lifeless> '
<wgrant> mwhudson: Are beagleboards ARMv7?
<mwhudson> yes
<wgrant> You'll need a bit of tweaking to get the buildd to work remotely.
<mwhudson> fairly sure, at least
<wgrant> But it isn't difficult.
<mwhudson> ok
<wgrant> (because they need librarian access)
<StevenK> Ah ha. I suspect the Lucid upgrade has broken dogfood.
<lifeless> <type 'exceptions.TypeError'>: cannot concatenate 'str' and 'NoneType' objects
<lifeless> yay buildbot. I hates you/
<StevenK> lifeless: I can't QA this on dogfood at least
<wgrant> What's up with it?
<StevenK> Exception-Value: could not access file "$libdir/plpython": No such file or direc
<StevenK> tory
<wgrant> Ah, awesome.
<StevenK> And staging is down
<wgrant> Easily fixed, at least.
<StevenK> lifeless: Dropped
<persia> mwhudson, Take care: performance is such on those that I don't even use raw sbuild, let alone anything else.
<lifeless> dropped ?
<persia> (although the XM might be faster)
<StevenK> lifeless: I can't QA those two bugs; dogfood is broken, and staging is down for a code update
<mwhudson> persia: it's just for testing, i'm not actually interested in building anything non-trivia;
<mwhudson> persia: the xm has 512 megs of ram at least
<lifeless> StevenK: wgrant seems to think that dogfood is easily fixed.
<wgrant> lifeless: By a sysadmin.
<StevenK> I thought it required at least a GSA
<lifeless> wgrant: here's one I prepared earlier.
<StevenK> Ah, see ... :-)
<wgrant> I didn't know LOSAs did DF
<lifeless> wgrant: its lp; we start there.
<StevenK> They don't
<lifeless> StevenK: why not?
<lifeless> anyhow, digression, if we need a sysadmin
<StevenK> Because we manage it, not them
<lifeless> StevenK: thats kindof a statement of the status, not a rationaile.
<lifeless> I so want buildbot to say 'transubstantiating', not just 'substantiating'
<StevenK> lifeless: Then please ask mthaddon or bigjools, obviously I can't recall correctly
<lifeless> I've pinged vanguard in is
<StevenK> lifeless: Hold on, I'm still checking
<lifeless> pjdc: may be easier to discuss here.
<pjdc> righto
<lifeless> pjdc: the upgrade to lucid has probably jiggled the pg plpython packages around
<wgrant> You probably need postgresql-plpython-8.3
<wgrant> Unless it's running 8.4 already.
<lifeless> also staging is just -down-, its been down all day AFAIR
<StevenK> It's running 8.4
<StevenK> lifeless: I'm not even sure if the database has made it one piece to be fair
<StevenK> \dT psql launchpad_dogfood does not tell a pretty story
<StevenK> Ah ha, dogfood is running both.
<StevenK> pjdc: Yes, please install postgresql-plpython-8.3 on mawson
<pjdc> StevenK: hmm, it doesn't seem to be available in lucid
<wgrant> It's not.
<wgrant> It's probably in the PPA.
<wgrant> Otherwise karmic.
<pjdc> it doesn't look like mawson had karmic or ppa sources before the upgrade
<wgrant> It wouldn't have. karmic has 8.3 natively, whereas lucid just has 8.4.
<pjdc> well, mawson went hardy -> lucid
<wgrant> Oh, it was hardy before. Right.
<wgrant> My point stands.
<pjdc> looks like it was a vanilla hardy version, so i guess let's see if that will install
<StevenK> We should probably transistion dogfood to 8.4, but that will take about two days. (Sadly, I'm not kidding)
<pjdc> StevenK: postgresql-plpython-8.3 is installed (as are its dependencies python2.5 and python2.5-minimal)
<poolie> ok it seems like dkim works but not for the case of mail to new@
<wgrant> It's not using 8.4 instead?
<StevenK> pjdc: Many thanks
<StevenK> wgrant: Like I said, it's running both, and psql is still talking to 8.3
<pjdc> StevenK: you're welcome!
<pjdc> StevenK: if you could ping a GSA when that can be removed again, that'd be super :)
<StevenK> pjdc: Was indeed already my plan -- I'll talk to Julian on our stand-up about moving mawson to 8.4
<pjdc> excellent
<thumper> ah poo
<thumper> what "special" things to I need to do to run tests on maverick?
<wgrant> Downgrade python-psycopg2 to Lucid's version.
<thumper> is it just the database library?
<wgrant> We need to work out how best to fix that.
<wgrant> Our code is sort of broken.
<thumper> wgrant: happen to remember the command to do that off the top of your head?
<thumper> that it is
<wgrant> thumper: wget http://launchpad.net/ubuntu/+archive/primary/+files/python-psycopg2_2.0.13-2ubuntu2_i386.deb
<wgrant> sudo dpkg -i python-psycopg2_2.0.13-2ubuntu2_i386.deb
<wgrant> Replace i386 with amd64 if you are one of them.
 * thumper is 64 bit
<thumper> wgrant: ta
<wgrant> (the problem is that we use strs when constructing some queries that want unicodes)
<wgrant> eg. lots of places do getUtility(IDistributionSet)['ubuntu'] or similar.
 * thumper nods
<wgrant> And the celebrity descriptors suffer the same problem.
<lifeless> wgrant: the db library is being stupid
<wgrant> lifeless: I'd say we are...
<lifeless> wgrant: python2.x is -not- suitable for strict u'' enforcement
<wgrant> Storm is strict about it.
<wgrant> As it should be.
<wgrant> psycopg2 is now too.
<lifeless> which is a bad idea to do without a new major release
<lifeless> I guarantee nearly every single nontrivial db app will be broken by this
<lifeless> I'm not denying the semantic clarity it brings
<lifeless> but hell
<lifeless> even simple things like traceback objects and Exception are not unicode safe in 2.x
<lifeless> I suspect we want to put a patch up to be SRU'd to make this sane again.
<lifeless> by sane I mean 'works with the status quo'
 * thumper frowns
<thumper> I've still got problems
<lifeless> spm: sorry to interrupt you, but lpbuildbot seems buggered for lp_prod
<lifeless> thumper: we know :P
<thumper> canonical.testing.layers.MemcachedLayer setup
<lifeless> thumper: oh sorry, you mean with maverick ?
<thumper> layer setup
<lifeless> backtrace?
<thumper> No such file or directory
<wgrant> What's it whining about?
<thumper> what a useful error
<wgrant> Do you still have memcached installed?
<thumper> no path given
 * thumper wonders
<wgrant> It's not left some stupid pid around like the librarian does?
<thumper> what is c?
<lifeless> poolie: cool
<lifeless> thumper: 299,792,458 metres per second
<poolie> i just filed three consecutive bugs
<persia> Depends where you are, really.  Might be a bit faster up a mountain, or a bit slower in a valley.
<poolie> it must be a quiet day
<poolie> really?
<spm> lifeless: le sigh. that's a full stab to recover I suspect... but trying master only.
<lifeless> persia: only if you're the smartest mathematician on the disc
<spm> cud cud cud cud
<persia> lifeless, I'm thinking atmospheric excitement influenced by current density vs. influence of turtles
<lifeless> persia: but do you have 4 stomachs ?
<thumper> wgrant: apparently memcached was uninstalled as I upgraded
 * persia is not nearly that capable a mathematician
<mwhudson> wgrant: where in https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally does bob the builder get created?
<wgrant> mwhudson: Sampledata.
<wgrant> Others, /builders/+new
<mwhudson> as n utilities/soyuz-sampledata-setup.py?
<wgrant> mwhudson: No, it's been in the sampledata since 2005.
<lifeless> spm: let me guess. You stabbed, but forgot the first aid kit.?
<mwhudson> ah, i'm not authorized
<wgrant> mwhudson: Are you bootstrapping from nothing?
<mwhudson> wgrant: sorry for the noise
<mwhudson> wgrant: no
<wgrant> That gets a bit messier.
<wgrant> So good.
<mwhudson> hah
<mwhudson> there doesn't seem to be an armel processor in the sample data?
<wgrant> There should be a family.
<wgrant> maybe not a processor.
<wgrant> Indeed not.
<spm> lifeless: more like didn't stabb enough
<mwhudson> wgrant: is there a ui for that?
<wgrant> mwhudson: No.
<wgrant> You can use the factory, or good old psql.
<wgrant> Then you need to add a DAS.
<wgrant> For that there is UI.
<wgrant> Not sure if it's linked, though -- DistroSeries:+addport, IIRC.
<spm> sigh. no. full stabb coming up.
<mwhudson> wgrant: thanks
<mwhudson> some impressive warnings on that page :)
<wgrant> Yes.
<wgrant> The ZCML also says to poke sabdfl before changing any of the values.
<poolie> lifeless: no rush, but you could comment some time on https://bugs.edge.launchpad.net/launchpad-foundations/+bug/643224 as to where the configuration ought to go
<lifeless> poolie: I did
<lifeless> poolie: or did you want a more detailed sketch ?
<lifeless> spm: I only ask because 502's
<lifeless> wgrant: you might want to patch that to instead mention roles.
<wgrant> lifeless: Hm?
<lifeless> 16:44 < wgrant> The ZCML also says to poke sabdfl before changing any of the values.
<lifeless> I'm pretty sure thats delegated now
<wgrant> Heh, probably.
<lifeless> spm: thanks
<spm> sigh. tho one slave is still being levels of stubborn.
<lifeless> spm: looks all yellow now
<lifeless> I really have to patch bb
<lifeless> http://en.wikipedia.org/wiki/Transubstantiation would be a much cooler message
<lifeless> nup, db_lp fail
<thumper> wallyworld: got those questions?
<wallyworld> thumper: skype?
<spm> lifeless: well. for varying values of "yellow"
<thumper> wallyworld: aye
<lifeless> StevenK: are you unblocked for qaing?
<mwhudson> wgrant: i uploaded something and ran process-upload -- and now nothing is happening
<mwhudson> wgrant: where should i be looking?
 * poolie loves makeSignedMessage(oh no actually not signed) :)
<poolie> oh even better that's the default :)
<wgrant> mwhudson: What did process-upload say?
<wgrant> Did you run it with -vvv?
<poolie> i realize it means "potentially signed message"
<wgrant> (-vv is OK too, but -vvv lets you see its emails, among other details)
<mwhudson> wgrant: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally doesn't say -vvv so no
<wgrant> mwhudson: Bah.
<wgrant> -vvv
<wgrant> It may have already moved it to rejected or failed.
<wgrant> Does root have mail?
<wgrant> Oh, it's Zopeless, so it probably won't actually send mail.
<wgrant> Sad.
 * mwhudson edits the wiki
<mwhudson> ah
<mwhudson> Unable to find hello_2.4.orig.tar.gz in upload or distribution.
<wgrant> debuild -S -sa
<mwhudson> i guess i need to force a full upload somehow
<poolie> i think -sa does that
<poolie> nb with bzr builddeb you need 'bzr builddeb -S -- -sa'
<poolie> iirc
<wgrant> That's right.
<mwhudson> http://launchpad.dev:58080/100/nHOxGYhrhsWKP0SXew1T6tEUh30.txt
<mwhudson> er
<wgrant> Yeah, not useful.
<mwhudson>  Cannot build any of the architectures requested: any
<wgrant> mwhudson: Do you have chroots?
<wgrant> Ah.
<mwhudson> i guess because i'm uploading to a ppa
<mwhudson> and the builders are both 'official'
<wgrant> If you only have an armel chroot, you'll need to mark it unrestricted, or whitelist the PPA.
<mwhudson> wgrant: how do i do that?
<lifeless> spm: Cannot rebuild database. There are 1 open connections.
<lifeless> spm: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/163/steps/shell_7/logs/stdio
<wgrant> mwhudson: Go to the PPA's +admin, and check the ARM box.
<mwhudson> i presume checking virtualized isn't the thing to do
<wgrant> Then try uploading again.
<lifeless> spm: please. apply. signals.
<wgrant> mwhudson: Ah, you'll need a virt builder if you want it to actually be dispatched, yes.
<wgrant> You also need to fill in the VM host with any string.
<mwhudson> wgrant: how does it know not to actually try to reset the builder?
<wgrant> mwhudson: Because the dev config sets it to a dummy command.
<mwhudson> wgrant: ah
<wgrant> On production it does some ssh magic that I'm not allowed to see yet.
<mwhudson> 2010-09-20 05:18:16 DEBUG   Created armel build of hello 2.4-3ubuntu2 in ubuntu lucid RELEASE [31] in PPA named test-ppa for Ppa-user (2505)
<wgrant> Excellent.
<mwhudson> i don't see where that build has gone though :(
<wgrant> What do buildd-manager logs say?
<wgrant> Probably not much.
<mwhudson> heh, the last entry in /var/tmp/buildd-manager/buildd-manager.log is from may
<wgrant> Not /var/tmp/development-builddmanager.log
<wgrant> ?
<wgrant> Or development-buildd-manager.log... I forget which.
<wgrant> It changed recently.
<mwhudson> ah hah
<lifeless> arrggggghhhh
<lifeless>   File "/srv/buildbot/slaves/launchpad/production-devel/build/orig_sourcecode/eggs/lazr.restful-0.13.0-py2.5.egg/lazr/restful/_resource.py", line 924
<lifeless>     except Exception as e:
<lifeless> spm: hi, how far along are we to 'all-lucid' ?
<mwhudson> wgrant: hm, nothing for a couple of hours
<mwhudson> i guess i'll try restarting it...
<wgrant> mwhudson: If it's still not helping, change its logging level from INFO to DEBUG.
<wgrant> Should be in lib/lp/buildmaster/manager.py
<mwhudson> wgrant: 2010-09-20 17:23:36+1200 [-] No build candidates available for builder.
<mwhudson> which is i guess not surprising as the queue seems to be empty
<poolie> lifeless: does launchpad have something like bzr's overrideAttr?
<mwhudson> _why_ the queue is empty though...
<poolie> to monkeypatch something for just one test?
<mwhudson> oh, i need to publish the source first?
<wgrant> mwhudson: Only if it's a private PPA.
<mwhudson> ok, not that
<lifeless> poolie: no, I'd love a feature that does that
<lifeless> poolie: you can use bzr testcases in lp, if you don't mind making your own factory
<wgrant> mwhudson: What's the build status?
<wgrant> Hit 'View build records' on the PPA.
<mwhudson> wgrant: hm, pending
<wgrant> Oh.
<wgrant> It's possible that the PPA is created non-virt.
<wgrant> Try un-virting the builder.
<mwhudson> hah, it's building
<mwhudson> well not really
<mwhudson> 2010-09-20 17:29:08+1200 [QueryWithTimeoutProtocol,client] <bob:http://10.0.0.46:8221/> response for "ensurepresent": [False, 'Error accessing Librarian: <urlopen error [Errno 111] Connection refused>']
 * mwhudson watches the build be dispatched over & over & over again
<wgrant> As expected.
<wgrant> There is failure counting in db-devel, IIRC.
<mwhudson> the development librarian only listens to the local interface?
<lifeless> uyes
<wgrant> I believe so.
<wgrant> I have done this in a year, though.
<wgrant> Er.
<wgrant> Haven't.
<mwhudson> i guess i can fix that, or get the slave to talk to this proxy i happen to have running
<mwhudson> graaaar
<wgrant> Welcome to Soyuz :)
<wgrant> I suppose I can just about validly say that now.
<lifeless> I want a rubber stamp for testfix on prod-devel
<lifeless> last.restful needed a 'Exception as e:' -> 'Exception, e:'
<mwhudson> lifeless: sounds ok
 * lifeless takes thumpers name in vain as its a fix to the previous +1
<mwhudson> ok, that's actually a little strange, it's the proxy not knowing about hostnames in /etc/hosts
<lifeless> what poxy?
<mwhudson> polipo
<mwhudson> ah, that's a config setting apparently
<mwhudson> it's building!
<mwhudson> well, unpacking the chroot
<wgrant> Go and have dinner.
<wgrant> And breakfast.
<mwhudson> :)
<spm> so buildbot seems to do a good job of firing off an instance; and then losing contact with it. hence db_lp in a questionable state
<mwhudson> took 5 minutes on the real builder: https://edge.launchpad.net/ubuntu/+source/hello/2.5-1/+build/1725699
<lifeless> add to that that the non lucid builders should be failing every time atm
<lifeless> because of lazr.restful 0.13.0
<mwhudson> and it failes
<mwhudson> http://archive.launchpad.dev/ubuntu/dists/lucid/main/binary-armel/Packages.gz
<wgrant> Ah, yes.
<mwhudson> W: Failed to fetch http://archive.launchpad.dev/ubuntu/dists/lucid/main/binary-armel/Packages.gz  504  Host archive.launchpad.dev lookup failed: Host not found
<mwhudson> rather
<mwhudson> i guess more /etc/hosts nargery?
<wgrant> So you need to fix the resolution, and also './scripts/publish-distro.py -C' to actually create the archive.
<lifeless> mwhudson: you might like squid
<mwhudson> wgrant: what should it resolve to?  same as launchpad.dev?
<wgrant> mwhudson: It just needs to make it into Apache.
<wgrant> So that should do.
<wgrant> I did add it to the stock Apache config, didn't I?
<mwhudson> wgrant: it's 403ing, joy
<mwhudson> which is a bit strange
<wgrant> It is.
<wgrant> What does Apache say about it?
<mwhudson> [Mon Sep 20 17:51:01 2010] [error] [client 10.0.0.1] client denied by server configuration: /var/tmp/archive/ubuntu/dists/lucid-updates/restricted/binary-armel/Packages.gz
<wgrant> Ah.
<wgrant> Right.
<mwhudson> which is a bit less surprising when you look at the config
<wgrant> Forgot that bit.
<wgrant> Yeah, I decided to be safe, I suppose.
<mwhudson> i certainly hope i don't take this laptop to a cafe and get a 10.x.x.x ip address for a while...
<wgrant> Oh, yeah, if you have lp-buildd installed you really want a firewall.
<mwhudson> well, that's on the arm board
<wgrant> True.
<lifeless> stub: ping on the backup :)
<lifeless> stub: <- optimist
<mwhudson> oh what the hell
<mwhudson> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/maverick/main/binary-armel/Packages.gz  404  Not Found
<mwhudson> well, /yes/ but ...
<stub> lifeless: Is still running
<persia> mwhudson, ports.u.c/ubuntu-ports/...
<mwhudson> persia: yes yes, but this is 7 layers in
<persia> ftp.internal is merged.
<lifeless> stub: thanks
<mwhudson> wgrant: any ideas?  is the /etc/sources.list from the chroot mangled somehow?
<wgrant> mwhudson: Ah. Check the external dependencies on the PPA's +admin.
<wgrant> They are set to archive.ubuntu.com by default, because the dev primary archive doesn't actually have any build-deps that packages might want.
<mwhudson> well, this is taking longer to fail at least
<wgrant> Is it installing build-deps yet?
<mwhudson> past that, it seems
<mwhudson> wgrant: this doesn't look very good http://people.canonical.com/~mwh/uhoh.png
<mwhudson> wgrant: for several reasons
<wgrant> mwhudson: Check the build and b-m logs.
<wgrant> Looks like it was GIVENBACK.
<mwhudson> i've retried the same build a few times
<mwhudson> the buildlog looks fine though
<wgrant> Oh, it was successful?
<wgrant> You may be running into jelmer's incomplete branch.
<wgrant> Try merging his IFORGETTHIS-popen-2 branch.
<mwhudson> well
<mwhudson> actually i think i'm going to go home
<mwhudson> but i'll try that tomorrow :-)
<wgrant> That could work.
<mwhudson> will it just keep on building in the current state?
<wgrant> I suspect so.
<wgrant> kill off b-m.
<mwhudson> yeah, looks like it
<mwhudson> anyway, close enough to success for one day
 * mwhudson eods
<wgrant> I should also head home.
<poolie> what if anyhting is the patch size limit?
<lifeless> the review policy asks for patches to be < 800 lines unless you negotiate with your reviewer
<lifeless> practically speaking, anything the review finds to awkward/complex/unclear will be pushed back on anyway.
<lifeless> personally I think the limit is bogus and should be tossed away, in favour of asking for single-intent, focused patches; which may be very large and mechanical, or small but subtle.
<persia> mechanical patches are generally exceedingly large by their very nature
<poolie> mm
<poolie> i think there's a fair overhead per landing
<poolie> which pushes people (or at least me) to do bigger ones
<lifeless> spm: substantiate failed
<spm> buildbot?
<spm> orsum it's effed and died on both ec2 images. sigh.
<StevenK> Can we switch to Hudson now?
<lifeless> StevenK: is it ready?
<lifeless> StevenK: also, how did you go with the qa?
<StevenK> QA is underway, still. :-/
<lifeless> StevenK: KK
<lifeless> StevenK: If there is someway I can help, lemme know.
<StevenK> lifeless: Hudson is blocked until we can figure out how to get it building from source in a way that IS are comfortable with.
<lifeless> StevenK: have you asked on the hudson list uet ?
<lifeless> StevenK: also, I don't see why that blocks it; because there are other things that aren't ready aren't there?
<StevenK> lifeless: No, but there is a Debian ITP open about it.
<poolie> ok, https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985 i think fixes a few of those things
<StevenK> lifeless: To be brutally honest, it seems like only you and me care, and I'm the only one doing things to it.
<lifeless> StevenK: personally, I wouldn't worry about the deb building aspect.
<lifeless> its the least of the issues.
<StevenK> lifeless: IS refuse to use the upstream .deb package
<lifeless> but, and I can't stress this enough, its *really important* to talk to upstream about these things.
<lifeless> StevenK: thats fine; we're not ready to deploy it yet are we?
<lifeless> StevenK: horses go in front of the carriage.
<spm> lifeless: unless you have a horseless carriage, in which case the horses are squished into the engine somehow. which may be behind the carriage.
<lifeless> StevenK: in terms of caring / doing; spm has expressed great passion to get rid of BB, so has maris.
<lifeless> spm: those are beetles.
<lifeless> spm: totally different things.
<spm> Lamborgini's!!!!
<StevenK> lifeless: James Page has commented on the Debian ITP bug, which already has upstream scribbling on it -- I was going to touch base with him
<spm> mainly as BB is an unreliable .... .... .... ... ....!
<lifeless> StevenK: why are you worring about the deployment side of it yet though
<StevenK> spm: And Ferraris, some Audis, every Porsche except one
<lifeless> frankly, I'd get everything else totally happy first.
<poolie> spm, thanks for your patient help, i could have done it without you
<poolie> but it would have been harder
<poolie> (might as well be honest :)
<spm> poolie: ha. np
<spm> but, you'll crush my feelings saying I'm not necessary to the process
<poolie> i think i should leave now before something goes wrong
<lifeless> spm: I think you need a larger weapon
<spm> oh yes. just dealing with a pri 90; then it's destressing time
<StevenK> NameError: name 'self' is not defined
<StevenK> Oh, for the love of ...
<lifeless> StevenK: thats on dogfood ?
 * jml waves hello
<lifeless> StevenK: or local, cause local would let my heart start beating again
<lifeless> hi jml
<StevenK> lifeless: No, completly different branch
<lifeless> whew
<StevenK> lifeless: Oh, sorry, I meant production
 * StevenK calls for an ambulance to lifeless' house
<lifeless> wow, either I really messed up OOPS reporting, or the CP this morning has actually helped a lot
<lifeless> https://devpad.canonical.com/~lpqateam/lpnet-oops.html#time-outs
<lifeless> also https://lpstats.canonical.com/graphs/OopsLpnetHourly/20100914/20100921/
<lifeless> https://lpbuildbot.canonical.com/one_box_per_builder - it is -completely- confuddled.
<StevenK> Oh bugger. ImportError: No module named cachedproperty
<StevenK> That *is* on dogfood
<StevenK> I'm blaming shipit, since that appears in the traceback
<StevenK> Looks like you can't use copy_field() when the field you want to copy is in the same class as you are
<lifeless> StevenK: your shipit is out of date
<lifeless> utilities/update-sourcedode
<StevenK> I should run that on dogfood?
<lifeless> I would
<lifeless> you need to make deps just the same as anywhere else
<StevenK> Bleh, it can't check out shipit
<lifeless> for prod/staging we run that on devpad (well, we use config-manager, but near enough)
<lifeless> could just remove sourcecode/shipit
<StevenK> lifeless: I don't like that idea
<lifeless> why?
<lifeless> is there a shipit.dogfood.launchpad.net ?
 * lifeless tires
<lifeless> no, there isn't
<lifeless> rename it to something else then - mv sourcecode/shipit{,.disabled}
<lifeless> shipit is optional in the tree - its closed source
<StevenK> lifeless: shipit disabled, thank you
<spm> lifeless: buildbot hit with a bigger hammer. thrice.
<lifeless> spm: thanks
<lifeless> lets see if it sticks
<lifeless> grah what does it take to get out of testfix these days
<lifeless> spm: bb is building, isn't that meant to take us out of testfix mode?
<spm> not sure tbh where the trigger is; at receipt of a fix; or when it fixes.
<lifeless> AIUI starting a build is the key
<lifeless> bbs, dinner time
<lifeless> 3.4seconds for 99% of all lp back at the 7th aug.
<lifeless> 3.95seconds for 99% of all lp yesterday
<lifeless> bah
<lifeless> 2.95
<StevenK> lifeless: IE, we've lost 0.5 seconds?
<lifeless> I think so
<lifeless> dunno how much noise there is in the usage patterns
<lifeless> interestingly the mean has moved up 0.06, but the variance has come down more than enough to compensate
<adeuring> good morning
<mrevell> Hello
<StevenK> allenap: Hi! Are you available for a call in about 10?
<wgrant> StevenK: Did you get anywhere with DF?
<allenap> StevenK: Would 20 be okay?
<allenap> StevenK: So, about 0900 UTC.
<StevenK> wgrant: Fighting horribly
<wgrant> Heh.
<StevenK> And giving up
<wgrant> That bad?
<lifeless> stub: backup finished?
<StevenK> wgrant: Well, Julian's turned up, and I have other things aside from work to be doing
<wgrant> Ah, right.
<wgrant> So it's not defeat.
<lifeless> bigjools: oh hai!
 * StevenK doesn't even have the motivation to insult wgrant, so I must be sick
<lifeless> :(
<lifeless> vitamin C time
<bigjools> hai
 * bigjools is sprinting with jml this week
<lifeless> cool
<wgrant> bigjools: Ready for the Twisted overdose?
<bigjools> in body yes, in mind no
<lifeless> hey, there is a patch - 11556 IIRC - that needs qaing on dogfood; its the blocking patch in the line for doing quicker deployments of a bunch of bugfixes.
<lifeless> StevenK was trying to qa it, but ran into some stuff.
<bigjools> ok
<bigjools> there's 2 that need DF QA
<StevenK> wgrant: He probably won't remember it if he drinks heavily enough
<jml> http://isometric.sixsided.org/strips/twisted_plutonium/
<wgrant> Is Twisted not itself sufficiently intoxicating?
<bigjools> StevenK: will you be able to do those QA things?
<StevenK> bigjools: Until when?
<bigjools> a question is not a valid response to a question
<StevenK> bigjools: Bug 564491 qa-ok
<_mup_> Bug #564491: Cannot accept package which closes inaccessible bug <boobytrap> <oops> <qa-ok> <queue-page> <ui> <Soyuz:Fix Committed by julian-edwards> <https://launchpad.net/bugs/564491>
<StevenK> bigjools: Do you think there is any point QA'ing 556339?
<bigjools> bug 556339
<_mup_> Bug #556339: systray.py crashed with SIGSEGV in vtable for QPaintDevice() <amd64> <apport-crash> <apport-failed-retrace> <lucid> <hplip (Ubuntu):Confirmed> <https://launchpad.net/bugs/556339>
<bigjools> Oo
<StevenK> Sorry, 566339
<StevenK> bug 566339
<_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <qa-needstesting> <Soyuz:Fix Committed by julian-edwards> <https://launchpad.net/bugs/566339>
<bigjools> StevenK: no, can you set it back to triaged please
<bigjools> and unlink the branch
<StevenK> Done
<bigjools> cheers - and the other one needs a couple of COPY archive builds
<bigjools> on a frozen series, which you then mark released
<wgrant> Is buildd-manager actually functional right now?
<wgrant> In devel, that is.
<StevenK> bigjools: Sorry, you've completly lost me
<bigjools> wgrant: why would it not be?
<wgrant> r11566
<wgrant> AFAICT it will break successful completion.
<bigjools> StevenK: the bug was that when a series gets released, any COPY archive builds in progress would cause b-m to oops
<lifeless> bigjools: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt is the report I'm looking at for deployments btw
<wgrant> Until the second part lands.
<bigjools> wgrant: jelmer said he was going to land everything on Friday, what do you think is missing?
<wgrant> I don't think part 2 has landed.
<bigjools> what's in part2?
<lifeless> jelmer hit trouble with OOPS
<lifeless> the same thing we had last week
<bigjools> FFS
<wgrant> buildd-manager no longer destroys the BQ, so the build will be reset as soon as the upload is queued.
<bigjools> https://code.edge.launchpad.net/~jelmer/launchpad/506256-remove-popen-2/+merge/35412
<bigjools> not merged :/
<wgrant> That's the one.
<wgrant> It has an odd test failure.
<bigjools> do you know how to fix it?
<bigjools> is it even related?
<lifeless> StevenK: \o/
<wgrant> I don't know how, no. It's a test isolation error of some sort.
<bigjools> lifeless: is it too late for me to push this on to you so I can get on with my sprint?
<wgrant> Nobody seems to know.
<lifeless> bigjools: the oops thing?
<bigjools> lifeless: well whatever is blocking jelmer's branch
<lifeless> bigjools: its 9pm, I doubt I'll make much traction on it tonight.
<bigjools> since it's also now blocking QA of a different branch
<lifeless> I spent most of a day staring at it last week.
<lifeless> and worked around it
<lifeless> I do however have a little more info now from jelmer, so I'll happily stare at it again.
<lifeless> bigjools: is wgrant right, that if we deployed r11556 we'd break things?
<bigjools> yes
<lifeless> ok, so it needs to be marked qa-bad
<bigjools> it was a 2-parter
<lifeless> with the specific revision. hang a sec and I'll dig it up
<bigjools> split up for review purposes, but he should have landed them together really
<lifeless> bigjools: 11556 was your patch
<allenap> StevenK: http://pastebin.ubuntu.com/496900/
<wgrant> 11566
<lifeless> wgrant: do you really mean 11556 ?
<lifeless> ah
<lifeless> 11566, coolio.
<wgrant> That's what I said, isn't it?
<wgrant> Yes.
<lifeless> its pretty far back to consider rollingback too. darn.
<StevenK> allenap: http://pastebin.ubuntu.com/496901/
<wgrant> lifeless: Howso?
<wgrant> That code isn't touched often.
<lifeless> wgrant: high chance of unrelated fallout from the same oops thing, I bet it would be bad
<bigjools> lifeless: there';s nothing wrong with 11556
<wgrant> Ah, right.
<lifeless> bigjools: ok cool; StevenK was qaing the two bugs - I see one is done.
<bigjools> lifeless: I thought you meant jelmer's rev
<lifeless> the other is pending?
<lifeless> bigjools: I was all confused; I'm synced up now.
<bigjools> lifeless: yeah one of them is going to get unlinked, the other is QA OK
 * bigjools is going to disconnect from IRC in 5 minutes so I can get some work done
<lifeless> bigjools: https://bugs.edge.launchpad.net/soyuz/+bug/566339 - the second bug on 11556 - isn't qa-ok yet.
<_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <qa-needstesting> <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/566339>
<bigjools> lifeless: that's the one that should be unlinked from the MP
<bigjools> it's not fixed, I should not have linked it
<lifeless> bigjools: ok, I'll just remove the qa tag from it
<bigjools> great
<lifeless> that might fix it
<bigjools> fix what?
<lifeless> if it doesn't, I'll qa-untestable it
<lifeless> the deploy script
<bigjools> ah that's in action now then
<lifeless> candidate-deploy-stuff
<lifeless> bigjools: the bits are all coming online yes; its output is linked above
 * bigjools is going to run tests locally on jelmer's unlanded branch and try and land it
<bigjools> if it still fucks up with this OOPS shit, I am punting to you :)
<lifeless> bigjools: it will
<bigjools> :/
<lifeless> bigjools: I'm looking at it now
<bigjools> ok
<bigjools> thanks then
<lifeless> save your time; I'll email you when I pass out from exhaustion with a brain dump
<bigjools> ok :)
<lifeless> not that I can land a fix
<lifeless> BB shat itself royally.
<lifeless> and we're in test fix for the next 2.5? hours
<bigjools> can we just kill BB now? :)
<lifeless> stub: the new index seems to work - https://lp-oops.canonical.com/oops.py/?oopsid=1724ED352 - 1.6 second query rather than the previous 3+
<jml> lifeless, I think testfix rules have changed such that submitting a testfix branch removes the testfix flag
<jml> lifeless, can we please have pre-merge testing back?
<lifeless> jml: +1
<lifeless> jml: I don't know what you mean by that, but the branches are all fine;
<bigjools> before we do that, we need a test suite that takes 5 minutes instead of 4 hours
<lifeless> its all fixed, just waiting for bb to figure that out.
<StevenK> bigjools: Patches welcome
 * bigjools wonders what the Aussie equivalent of a P45 is
<jml> bigjools, not true! pqm takes 20 minutes to process a branch, so we are by definition happy with a 20 minute processing time per branch.
<jml> bigjools, a slab of beer
<bigjools> jml: FSVO happy
<jml> yeah
<jml> the kind of happiness that you drink with ice
<lifeless> jml: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<jml> lifeless, what am I looking at?
<lifeless> 7 of the 60 are done, one under way, and I just closed 2 off as fix released.
<lifeless> jml: Progress
<jml> \o/
<lifeless> jelmer: ping
<jml> lifeless, he's on vacation
<jml> lifeless, in another tz
<lifeless> yes, but we was around not so long ago
<lifeless> this thing isn't what I was looking at
<lifeless> bigjools-afk: try this http://pastebin.com/fNKSwyTS
<lifeless> bigjools-afk: if I'm right it will work
 * bigjools-afk is not here
<lifeless> its 930 at night; I started at 6:30 - I'm not here either :P
<lifeless> bigjools-afk: takes a full test run to show the problem
<lifeless> I'll commit this and push it
<lifeless> stub: thanks for applying those indices
<henninge> jtv, danilos: Here is my current problem: http://paste.ubuntu.com/496907/
<henninge> The actual failure is at the end: pofile.currentCount()
<henninge> I added some output to see what's going on and I see four current messages but currentCount returns 3.
<henninge> what am I missing?
<jtv> henninge: is pofile an Ubuntu pofile or an upstream pofile?
<henninge> (its five, actually)
<henninge> jtv: let me look
<henninge> this is fromp poimport.txt btw
<henninge> jtv: upstream
<jtv> I'd expect to see 2 current messages there.
<henninge> jtv: so does the test. which ones?
<jtv> Actually, no, I don't see a reason why the last message shouldn't be current.  But it may have a (deliberate) validation error in the plural.
 * henninge checks
<jtv> Or maybe it's even supposed not to count as a current translation because it doesn't translate all forms.
<jtv> Plurals are nasty.
<henninge> jtv: no, the plurals are complete and correct
<henninge> jtv: ah!
<jtv> (BTW the code for getTranslationMessages has an oversized line)
<jtv> ?
<henninge> one of the potmsgsets is obsolete, I think
<jtv> I was wondering why you weren't filtering for thoseâ¦
<henninge> ;-)
<henninge> jtv: yes, balloon does not exist in the template that is being imported in the test.
<henninge> jtv: and we create obsolete POTMsgSets for unkown msgids in pofiles, right?
<jtv> I'm sure we do _somewhere_â¦
<lifeless> bigjools-afk: ok
<lifeless> bigjools-afk: https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994 - review this
<lifeless> merge it into jelmers branch, and then land both.
<lifeless> jelmer: ^ that should take care of it
<jtv> Can anyone tell me where this revision came from?  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/11369
<jtv> It seems to be related to bug 614404, but it's not in a branch linked to that bug.
<_mup_> Bug #614404: commit uses system user-id to generate revision-id even when committer id is supplied <Bazaar:Fix Released> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/614404>
<lifeless> jtv: bzr 2.2
<jtv> It was done _for_ bzr 2.2, but this is a Launchpad branch
<lifeless> which changes versions.cfg
<jtv> (which is breaking things in production for us atm)
<lifeless> that commit brings in bzr 2.2 via versions.cfg
<jtv> But it's not bzr that's breaking things; it's an undertested Launchpad change to accommodate the bzr upgrade.
<jtv> (Well, untested really)
<lifeless> I'm not sure what tests would be appropriate; its a fairly deep change in assumptions; how would you ensure that all possible cases are caught, in a reasonable time
<lifeless> anyhow
<jtv> Yes, that's the big question innit.
<jtv> Here's the problem I'm trying to fix:
<jtv> directbranchcommit now creates a bzr id based on the responsible person's preferred email address,
<jtv> but it doesn't check whether that person has a preferred email address.
<jtv> In our case, the person is often a team.
<lifeless> there's other code that does this.
<lifeless> Perhaps consolidating it all would be a good idea
<jtv> Very.
<lifeless> (for package branches, an email is needed and teams are often the person so a fallback is needed)
<jtv> So we want some kind of "get_bzr_id_for_person" function that falls back to something sensible.
<lifeless> no
<lifeless> get_email_for_person
<lifeless> used by
<lifeless> get_bzr_id_for_person
<lifeless> the thing for package branches is used in the .changes file
<lifeless> when building the recipe
<jtv> We already have "get email for person" functions.
<lifeless> well, just use whichever one is right :)
<jtv> I think the use case you mention is a different one than mine.
<lifeless> perhaps; I don't see why the logic would differ
<lifeless> both are dealing with:
<lifeless>  - need an email address
<jtv> In my case, I need a valid bzr user identity.  The sane fallback would probably be a celebrity.
<lifeless>  - have to handle teams
<lifeless>  - it will be publicly visible
<lifeless> jtv: thats what the recipe code does.
<lifeless> direct address; fallback to owner preferred; fallback to a well known fake address
<lifeless> fallbacks occur when not set or private-address.
<jtv> So that's not the same.
<lifeless> why can't it be
<lifeless> ?
<jtv> In our case, fallback to the owner would be misleading.
<jtv> In our case the bzr id is not so much for contact purposes as it is for attribution purposes.
<lifeless> I don't see that its any better or worse; perhaps I'm wrong about the other code.
<jtv> If we get too clever, we only make it harder to see that the change is authored by Launchpad.
<wgrant> (Recipes don't fall back to the owner -- the first attempt is the owner, right?)
<lifeless> its also for attribution in a .changes file
<lifeless> wgrant: recipe owners are teams sometimes
<lifeless> wgrant: I believe - maybe wrongly - that the team owner is the first fallback.
<lifeless> anyhow.
<lifeless> a) its late
<wgrant> Oh.
<wgrant> I don't think so, but possibly.
<lifeless> b) I don't see any difference in needs so far.
<wgrant> We need a solution to this.
<wgrant> There are two separate implementations at least.
<lifeless> c) the recipe code may be wrong, but lets not have two different implementations of the same basic use case.
<wgrant> And I can think of two or three other places that need it.
<lifeless> jtv: so if your needs are different, please at least minimally use the same function with a knob.
<jtv> lifeless: I'm not completely stupid, thank you!
<lifeless> lifeless: hah, sorry if something came out badly.
<lifeless> I'm really very tired.
<jtv> Maybe not a good time to discuss this thenâit's getting on here as well.
<jtv> (Of course we do need it fixed, but we can work it through with the American timezones)
<lifeless> jtv: I don't think you're at all stupid; I think perhaps I got the wrong end of the stick with what you were saying about different needs.
<lifeless> I'm sure you'll do something sane.
<jtv> lifeless: I understandâimagine a smiley face there.
<lifeless> :)
<henninge> jtv: filtered: http://paste.ubuntu.com/496919/
<jtv> These are the rabbit holes we stumble over when we're tired.
<jtv> henninge: and the "Foo %i" translation should not validate, so that shouldn't become current.
<lifeless> jtv: I don't know if you saw, but it looks like we've shaved 0.5 seconds off of the 99% threshold systemwide
<jtv> lifeless: !
<jtv> lifeless: stub's graphs are great for this
<lifeless> yup
<jtv> Seeing the change you've made there is really gratifying.
<jtv> testfix :(
<lifeless> jtv: small steps; and fortunately its not just me :)
<lifeless> I'm fortunate too having the leeway to focus my coding time on tis
<lifeless> this
<lifeless> tomorrow should see another CP with a bunch of stuff
<jtv> lifeless: got an interesting effect on the +templates pageâ¦ the biggest of those went down to about 2 seconds for the normal case, but it still takes >7s sometimes
<lifeless> jtv: have you captured a ++oops++ for one of the 7 second cases?
<jtv> Yes, but not much to seeâthere are no queries or blocking actions in the interesting part.
<lifeless> jtv: so its 'python time' ?
<jtv> My current sneaky suspicion is that maybe those templates are usually in storm cache, in which case the page renders in 2s (I could easily shave some more off that but can't justify it right now)
<lifeless> jtv: we nuke the storm cache at the end of each request.
<jtv> â¦but when they aren't, deserializing their header strings (kilobyte-order) can take time.
<lifeless> jtv: so in prod you won't see a change there.
<lifeless> therve has a  branch tuning that if you want to give it a spin
<jtv> Tuning it?  In what way?
<lifeless> getting rid of fat
<lifeless> I filed a bug talking about performance there - saw a page taking 16 seconds to deserialise stuff
<jtv> <whistle>
<lifeless> turns out that when a machine is very busy storm performance take s ahuge hit
<lifeless> partly its giving up the gil and grabbing it a whole heap
<jtv> The problem we feared.
<lifeless> and so it goes back on the runqueue each time when it calls into python code
<lifeless> thats -machine- load not -many-python-threads- per se.
<lifeless> so if the machine is at or beyond 100% cpu, even though the thread has a timeslice permitted, its back trying to grab it rather than going on immediately.
<lifeless> prod servers aren't run as hard as staging though
<lifeless> anyhow, there is an RT open to get some instances made single core
<lifeless> so we can evaluate that.
<jtv> What surprised me for the +templates page was the discrete nature of the delay: sometimes it's 2s, sometimes it's 7s, but there's nothing inbetween.
<lifeless> thats indeed very interesting.
<jtv> (Let me reiterate here my call for a performance experiment server)
<lifeless> I wonder what we can do to get a handle on it.
<wgrant> It's not because Ubuntu takes 7s and everything else takes 2s?
<lifeless> jtv: we can do experiments as needed; as I say there is a single-core one already in the pipeline.
<jtv> wgrant: no, I routinely get the Ubuntu page in 2s.
<jtv> But if you can think of something with more templatesâ¦  :)
<lifeless> jtv: so, one thing I'd do is look at the PPR and see if your feeling about it is real
<jtv> Maybe it's master/slave, or difference in privilees.
<jtv> *privileges
<lifeless> jtv: the ppr graph should show if its 2,7 or around-2, around-7 or whatever
<jtv> lifeless: that's where I spotted the difference.  Would be useful to get a bigger sample size though, yes.
<lifeless> jtv: if it is pretty clearly 2 peaks, then the ztrace log should let us figure out more data
<lifeless> jtv: such as master/slave and so on
 * jtv looks up ppr
<lifeless> Ursinha-afk: I can't see why ;
<lifeless> Revision 11556 can be deployed: qa-ok
<lifeless> Revision 11557 can not be deployed: not-ok
<lifeless> Ursinha-afk: we may need to make the more detailed output visible or something - the summary stuff is only useful if the detailed context above is shown too.
<lifeless> Ursinha-afk: (for developers). For folk saying 'time to doa deploy, the summary is sufficient, but I don't thinkt hey will mind seeing the rest.
<lifeless> Ursinha-afk: https://bugs.edge.launchpad.net/malone/+bug/497386 is qa-ok
<_mup_> Bug #497386: ScopedCollection:CollectionResource:#message-page-resource timeouts for bugs with many messages <api> <qa-ok> <timeout> <Launchpad Bugs:Fix Committed by lifeless> <https://launchpad.net/bugs/497386>
<lifeless> Ursinha-afk: also we may need a way to say 'this rev fixes bad-commit-12345' other than rollback; for the case when we decide to leave it in and fix it.
<gmb> Hooray for misspelt TestCases
<lifeless> gnight y'all
<jtv> henninge: how's that test doing now?
<henninge> jtv: I don't see updateTranslation doing that. It makes all messages current that don't have a translation conflict.
<jtv> henninge: it uses a helperâ¦ called validate_translation IIRC
<henninge> independent of validation errors.
<henninge> yes, it does
<jtv> henninge: I think it's this line in _makeTranslationMessageCurrent that does it:
<jtv>         if new_message.validation_status == TranslationValidationStatus.OK:
<henninge> jtv: the test is now failing on pofile.getPOTMsgSetWithErrors
<henninge> which does not find any such POTMsgSets (should find 1)
<jtv> henninge: in the recife code as it stands, getPOTMsgSetWithErrors is still hard-wired to look only for upstream-current messages.
<henninge> so what should I do? Fix the test?
<jtv> Well getPOTMsgSetWithErrors needs fixing, though I'm not sure that's the cause of the test failure.
<jtv> I think the other thing is that getPOTMsgSetWithErrors should find the message only if it did become current despite the validation error (which normally it shouldn't).
<jtv> henninge: does the test make the failed message current by manipulating the flags directly?  If so, see that it matches expectationsâgetPOTMsgSetWithErrors is wrongly hard-wired to is_current_upstream, the test is wrongly hard-wired to is_current_ubuntu.
<henninge> yes, in order to change that I will have to make the test use is_current_ubuntu
<deryck> Morning, all.
<persia> Good morning deryk.  I was advised you were the best person to ask for an opinion on 642637
<stub> Anyone recall what I can use to see if a script my test just ran emitted the expected OOPS reports?
<lifeless> in-process, self.oopses[-1]
<lifeless> ex-process getLastOopsReport
<lifeless> which is having a little quirky-moment just now, for reasons I haven't dug into.
 * lifeless really really is gone now.
<stub> ta
 * wgrant resets the "seconds since lifeless last left" timer.
<mars> wgrant, I think your IRC client does that for you ;)
<mars> well, the server /whois actually
<wgrant> True, true.
<persia> Trick is writing the script to distinguish time-since-last-activity from time-since-last-claim-to-depart
<maxb> No CHR today?
<allenap> bryceh: Hi, I'm looking into your email now. I'm on CHR today, I haven't done it for months, and it's still a complete pita :) Anyway, I'll try and get you an answer soon.
<jtv> ping abentley
<abentley> jtv, pong
<jtv> hi!  Did you see bug 643345?
<_mup_> Bug #643345: Failing branch exports <Launchpad Translations:In Progress by jtv> <https://launchpad.net/bugs/643345>
<jtv> The problem in a nutshell: bzr apparently needs an email address when DirectBranchCommit commits, but the user in question doesn't necessarily have a preferredemail.
<jtv> (And so our translations-to-branch export script breaks)
<abentley> jtv, no, I didn't see it, but I've seen other issues like it.
<jtv> It'd be good to have a single solution.
<jtv> We run into it with teams in particular.
<abentley> jtv, yeah.  It would be nice if everyone had email addresses.  It is 2010, after all.
<jtv> Which means that many use twitter for communication.
<jtv> I wonder if anyone thinks of us as old-fashioned for using email yet.
<jtv> But I digress.
<jtv> There are many things one _could_ do to find a valid email address in the case of a team, but I think ultimately they would be misleading.
<jtv> So my suggestion is: fall back to a celebrity.
<jtv> I don't know if that should be the same one every time, or whether we could have a global one.
<jtv> Ahem.  Those would be the same option.  Sorry.
<abentley> jtv, I don't know about this.  This is an address that people are using to create commits for the world to see.
<jtv> abentley: that's a good pointâthere may be other things worth trying in some or all of the cases.
<abentley> jtv, bzr users have complained about bzr silently generating an email address without them setting it.
<abentley> jtv, because they find out much later, and don't want to have to redo all their previous work just to get the right email address on their commits.
<jtv> abentley: in our use-case, the best fallback would be some celebrity that stands for "Launchpad committed this."
<jtv> I have no idea how suitable that would be for any or all of the other use-cases.
<abentley> jtv, are you sure that's what users want, not an opportunity to set the email address to the desired one?
<abentley> jtv, because in general, bzr users seem to want the latter.
<jtv> abentley: opportunity is always nice, but "you need to set an email address for this team before translations exports to branches will work" would be highly non-obvious.
<jtv> Not to mention the potential difficulty in conveying that point to someone without a preferred email address.  :)
<abentley> jtv, you mean a warning/error message with that text would not be clear?
<jtv> We could write a clear message, but it'd be yet another complication that's hard to foresee or justify through reasoning.
<jtv> (The preceding one being "you need to push to your branch," for which we also send out emails)
<jtv> Effectively we'd be letting go of Launchpad as a unified repository of identity: "Launchpad knows who you are but Launchpad Translations can't write to a Launchpad Code branch without your email address."
<jtv> abentley: I don't suppose we could generate a consistent non-email id along the lines of username@emailless-user.launchpad?
<abentley> jtv, we could certainly do that, but do users actually want that behaviour?  Our experience with bzr users suggests they do not.
<jtv> abentley: I can see that, but the solution after all is "make sure we have a valid email address for you."
<jtv> (Also, aren't there any hidden problems with exposing these email addresses publicly?)
<jtv> For our particular script, I think it'd be fine to have a single celebrity produce all commits.  Nice and recognizable.
<abentley> jtv, if we ask users to set an email address to be used as their public identity, I don't think exposing it is a problem at all.
<abentley> jtv, In my experience, using a fake email address is something users don't want.
<abentley> jtv, Do you have contradictory experience?
<jtv> abentley: I've seen some pretty hot-headed remarks about public email addresses, but I'm more interested in the question of "using a fake email address is something users don't want given what alternative?"
<jtv> If the answer is "if you don't like this, give us an email address to use," I don't think there's much ground for complaint there.
<jtv> grounds?
<jcsackett> does anyone know (or is there a place i can check) how long staging is likely to be updating for?
<jtv> Right now I'm not at all interested in the case where an email address for exactly the right Person (whether user or team) is available.
<abentley> jtv, the alternative is to error until users supply an address to use, even if the user-supplied address is fake.
<jtv> jcsackett: until it's fixed I guess.  It's been that way since my morning AFAIK.
<jtv> abentley: for what our script does, erroring out would be really unsettling.
<jcsackett> jtv: thanks.
<jtv> jcsackett: at the time I heard mention of fixing it, but haven't had time to look closer.
<abentley> jtv, the problem is that commits hang around for a long time.  IME, people would rather get it right at the start, and not have bogus identities on the first few commits.
<jcsackett> jtv: i'll check the lists &c, thanks. it's not a rush thing on my part, just curious when i can test something.
<jtv> abentley: I'm thinking in the case of our script, it'd be fine to fix that with a celebrityâI just need to pick or create one.  In more interactive use-cases, it'd be different.
<jtv> abentley: but I should point out that a preferred email address can disappear "spontaneously."
<abentley> I don't understand why you keep going back to your celebrity idea.  Do you think that your intuition trumps my experience?
<persia> Could one automatically assign every team an address that would match their mailing list address, and when it wasn't enabled, drop it to /dev/null ?
<persia> Users have addresses.
<jtv> abentley: no, that's just entirely about our specific use-case where picking a person probably isn't a very good idea in the first place.
<abentley> jtv, I don't think your use-case is as specific as you think it is.  It produces commits.  They live a long time.  People get emotional about the contents of commits.
<jtv> abentley: the thing is, the choice of person we have there right now is really a bit arbitrary.  It's a cron job doing the actual committing.
<jtv> abentley: the branch owner in that script serves as an approximation of whoever enabled the commits, but it picks the current branch owner which isn't necessarily the same person.
<jtv> abentley: now, _if_ our use-case is different in that sense, then there is no need to let it weigh down the general solution.
<abentley> jtv, it's being done on behalf of someone.  If the service didn't exist, some person would have to be committing to get the same result.
<abentley> jtv, the Code team doesn't have any use cases involving automated bzr commits.  We have use-cases involving email addresses for source packages, though.
<abentley> jtv, e.g. https://bugs.edge.launchpad.net/launchpad-code/+bug/620137
<_mup_> Bug #620137: allow choice of DEBEMAIL for recipes builds <recipe> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/620137>
<jtv> abentley: but in our case, who exactly is the commit done on behalf of?  The best answer I could give is "all the people who changed the translations."
<abentley> jtv, even for source packages generated automatically, even when the email address is valid, users want to specify the *particular* valid address.
<abentley> jtv, the commit is done on behalf of the person who enabled exports for that branch.
<abentley> jtv, or imports.  Whatever.
<jtv> Which is information we don't currently have available with full accuracy.
<jtv> In the problem cases we have now, for unrelated reasons, it's rather likely to be inaccurate.
<abentley> jtv, limitations of your current data model are not a good justification for planning future behaviour.
<jtv> abentley: no, but future behaviour that doesn't solve the problem _and_ requires an extension of the data model isn't very relevant to our problem.
<abentley> jtv, that's a tautology that can be shortened to "stuff that doesn't solve our problem doesn't solve our problem".
<jtv> abentley: if you want to leave out relevant conditions, sure.  But storing a different person doesn't solve the problem of not having an email address.  It merely increases the relevance of the email address if we have one.
<jtv> I would hope that it also increase the chances of having an email address, but it again leaves us with no very good course of action and a non-obvious failure mode when an email address goes away.
<abentley> jtv, I don't see how leaving out the conditions changes the truth of the expression.  future behaviour that doesn't solve the problem _and_ *does not* require and extension of the data model isn't very relevant to our problem.
<abentley> jtv, what about using the email address of the team owner when the team itself has no email address?
<abentley> jtv, for error messages, not for commits.
<jtv> abentley: when it comes to error messages we might as well notify an entire team.
<abentley> jtv, it would be nice, but we are talking about a situation where we don't have contact information for the team, right?
<abentley> jtv, I guess you mean contacting each team member individually?
<jtv> abentley: I thought you could email an entire team, as a collection of individuals with separate email addresses.  But no matter.  What I'm so unhappy about is having the extra error condition in the first place.
<abentley> jtv, I think that error condition is due to external requirements.  It's irreducible complexity.  But I think we can make it extremely rare.
<jtv> abentley: if we can do that, then great.
<jtv> How would we go about it for teams?
<abentley> jtv, I'm thinking for all Persons, we could have a "public email id" field.  And when someone's configuring imports for a branch, we can require that field to be filled out.
<abentley> We can then use the same email id for source package recipe builds.
<jtv> abentley: would it be a valid email address?
<abentley> jtv, no, it would not be required to be valid.
<jtv> (Just wondering if there are any abuse risks)
<abentley> jtv, it would be hard for that field to accidentally go away, so the error condition would only be hit if the user decided to clear it manually.
<jtv> abentley: what happens when a user transfers branch ownership?  Would we require the new owner to have a public email id?
<abentley> jtv, I don't know if it's possible to transfer branch ownership.
<jtv> It is.  But I see the point: if we store who initially set up the exports, that indicates which public email id to use.
<abentley> jtv, I guess depending on how we do it, transferring ownership could break imports.
<abentley> jtv, I'm not sure whether it makes sense to continue doing imports when transferring a branch.  That way, the branch gets contents that its owner never approved.
<abentley> jtv, we could also refuse to change ownership to an owner with no public email id.
<jtv> abentley: well forgetting admins for the moment, obviously the original branch owner makes the transfer.
<jtv> At that point, the original "license" to export to the branch has been given by someone who isn't necessarily an owner of the branch any more, but the new owner receives it with this restriction.
<abentley> jtv, right.  So now that the branch is owned by owner-new, should the imports configured by owner-old still apply?
<jtv> abentley: I think soâit's behaviour our users already use and expect, and it facilitates transfer to a team.
<jtv> If the old owner were to become thoroughly distrusted, I think there's worse problems than ongoing translation commits.
<jtv> Also, with the commits happening daily, there's little the new owner could do to become dependent on them not happening before they became obvious.
<abentley> jtv, true, although in the case of transfer to a team, owner-old is usually a member of owner-new, and so has the right to configure imports for owner-new.
<jtv> Yes.
<jtv> Of course keeping the email id of the original requester of the daily exports does mean that we could be committing in the name of a user that may have disappeared.
<abentley> jtv, My idea was actually that we would use the public email id of the current owner.
<jtv> OIC
<jtv> So then transfers are back on the table as an issue to be resolved.
<abentley> jtv, if the common case is that owner-old is a member of owner-new, perhaps we should let owner-old set the public email id of owner-new while transferring the branch.
<jtv> abentley: you mentioned the possibility of requiring a public email id when transferring a branchâ¦ that'd be necessary for what we do, but is it a reasonable thing to ask for other cases?
<abentley> jtv, if recipes could be transferred, I think it would be reasonable for that case.
<jtv> Then there's transition.  What to do about the existing cases?
<jtv> (Also, it'd be nice to have a better way of making "almost-candidates" clear in pickers: "you could almost transfer ownership to this person, _but_ there's no matching public email id yet")
<abentley> jtv, for Persons which currently have imports or source package recipe builds, we set the public email id to the value currently being used, and send a notification.
<jtv> abentley: I imagine we'd always fall back to a real publicly visible email address when no explicit email id has been set, but I'm thinking especially of the email-less cases.
<StevenK> allenap: And you were right, getUtility(IDistributionSet) is not what I want
<abentley> jtv, maybe I should have said "for Persons which currently have *working* imports or source package recipe builds..."
<jtv> abentley: I don't mean to be finicky about thatâjust asking what to do about the current problem cases.
<abentley> jtv, for the current problem cases, the "no public email id" case applies, and so we use that error handling.
<abentley> jtv, send it to the owner, as I suggested, or send it to each member of the team, as you suggested.
<jtv> abentley: that's a sizable number of people to bother.  :(
<abentley> jtv, this is why I suggested only bothering the owner.
<jtv> I see.
<jtv> This also means we have to go through a transition period where an owning team must expose a real email address.
<jtv> Not saying that's a dealbreaker, just worth addressing if we can.
<abentley> jtv, why would an owning team need to expose a real email address?  The public email id need not be real or valid.
<jtv> abentley: but we don't support those ids yet, or did I misunderstand?
<abentley> jtv, we don't.
<jam> hey guys, is it more appropriate to propose merges into "lp:launchpad" or "lp:launchpad/devel" the former being db-devel seemed less appropriate for non-db patches.
<jtv> But we do have production failures going on.
<abentley> jam, devel unless it has db patches or depends on new versions of scripts.
<abentley> jtv, okay, I figured that was pre-transition.
<abentley> jtv, what currently happens when we get these failures?
<jam> abentley: thanks, that's what I thought, but I'll note that the UI doesn't push you in that direction.
<jtv> abentley: all depends on perspective I guessâ¦ I was thinking of "from what we have now to the situation where we have public email ids"
<jtv> abentley: the exports to branches simply don't work, and we get oopses
<jtv> (or at least, logged failuresâthe oopses turned out not to be working for some reason)
<abentley> jam, it's because of the overloading of "development focus" for stacking.  db-devel is the best branch to stack on.
<abentley> jtv, so as an immediate fix, you could catch these errors and mail them to the team owner or the team members.
<abentley> jtv, I think that having public email ids is the right direction, but perhaps we should get other people involved in the discussion, like sinzui or lifeless or launchpad-dev.
<jtv> abentley: discussed with lifeless in the afternoon (about 9 hours ago I think), but got too late in the day for him to make it a reasonable demand.  Timezones make this hard.  I think as an interim measure I'll have to contact the affected teams and urge them to set an email address.  Howeverâ¦
<jtv> â¦I have one question about that: do teams get a preferredemail address in the same way that users do?
<jtv> I saw some code earlier that made me wonder.
<abentley> jtv, I don't know.
<jtv> I'm looking into it.
<jtv> abentley: humâPerson.setPreferredEmail starts out with "assert not self.is_team"
 * jtv digs for something more conclusive
<StevenK> allenap: Changes to db-add-derivedistroseries-api pushed, have a sneaky-peek when you have a chance.
<jtv> sinzui: are team email addresses maintained completely separately from user emails?  We have a situation where persons are expected to have a preferredemail, for teams that doesn't seem possible.
<sinzui> jtv, they are not separate because we keep people and team in the same table
<sinzui> teams have a contact address, users a preferred address, and we test for .is_team in teamowner in sql
<sinzui> jtv I have a branch that is dealing with a person/team email address corner-case right now. This is a real nuance.
<jtv> sinzui: thanks for clarifying thatâ¦ is there an easy way to get "preferred email or contact address"?
<sinzui> jtv: in python or sql?
<jtv> sinzui: python
<sinzui> no, this is a look before you leap issue
<jtv> sinzui: great thing to hear after the bus has already gone of the edge :)
 * sinzui cheats in SQL <person|team> -> EmailAddress (status = 4)
<sinzui> jtv, I have long wanted to separate users from teams.
<jtv> I've long said that users are the cause of by far most of our problems; anything you can take away from them is good.
<jtv> But seriously. :)
<sinzui> well, I have argued for a base class and table called agent, and then have three subclasses and tables for robot, user, and team
<jtv> sinzui: abentley and I had just figured out that we can fix our present production failures by asking teams to register preferred email addresses, but if they can't have preferred email addresses, we need to work on the code to accept contact addresses as well.
<sinzui> If we made everyone robots the users would not be an issue
<jtv> Four Terminator films and a TV seriesâit's been tried.  :(
<sinzui> except for when the rebel and turn themselves into users like all Cyclons do
<jtv> All of this has happened before, and all of it will happen again.
<sinzui> I bet the fans are reallying hoping for it to happen again
 * sinzui got bored with Caprica
 * jtv tried and failed to watch the pilot
<jtv> Unbearably bad.
<jtv> sinzui: what's the data model for team contact addresses?  Up to 1 validated address?  Pick any validated address?
<sinzui> jtv no :(
 * jtv hopes against reason that sinzui is merely disagreeing with his taste in TV series
<sinzui> jtv: 1 or 2 address. 1 contact address (status 4) and 1 mailing list address (status 3); or 1 contact address that is also the mailing list address (status 4). The magic is status 4, which is used to select the right one in the implementation
<jtv> sinzui: isn't status 3 OLD?
<sinzui> jtv: but since the address may be None, no contact address, but 1 mailing list address (status 3), in which case we lookup the members of the team and send to their addresses
<sinzui> oh, maybe, then I mean 2
<jtv> That's VALIDATED.
<sinzui> yep, that is what I mean
<jtv> ISTM 2 and 4 are the only usable states an email address can be in, and only 3 (VALIDATED) is applicable to teamsâ¦  So I guess that amounts to "up to 2 validated addresses, and a bit of complication for picking the right one."
<jtv> Waitâyou're saying a team _can_ have an email address with status PREFERRED.  Maybe it just doesn't get set as such through the normal channels, but ends up working the same otherwise?
<jtv> Of course if the address is then None, we're still, if I conjugate the Colonial correctly, fruck.
<jcsackett> sinzui: how would you feel about adding a usage_attribute to a view?
<jcsackett> i'm sort of reaching through some convolutions to access translations_usage for a product_series, and i think just having the views have their own usage_attribute mirroring whatever is the case on the context might be easier and cleaner.
<jcsackett> sorry, ProductSeries.
<jtv> jcsackett: in some narrow contexts I dig up a reference to the product-or-distribution, so I can inspect its official_rosetta attribute regardless of what it is.
<sinzui> jcsackett, yes it is convoluted because ProduceSeries is independent of Product. Any user can setup an automatic import for Ubuntu. henninge, jtv, and danilos can explain the separation and hopefully simplify the issue
<jtv> sinzui: how is ProductSeries independent of Product?
<sinzui> jtv: if the project choses unknown, external, (or even does not apply), a user can still setup an automatic import from the series
<jtv> sinzui: ah, the translations usage per se can change independently from the seriesâ¦
<jcsackett> sinzui, jtv: okay, so the translations_usage attribute (which is supplanting official_rosetta, jtv), ProductSeries mirrors Product by using the ProductSeries to Product adapter. i'm looking for an easy way to get at that for templates. are you suggesting that we actually need ProductSeries to have its own, entirely separate translations_usage attr?
<sinzui> jtv: I think the confusion is that there are many things that can be configured, project, series, and permissions. I think we should have once screen to manage permission and configuring/enable the service for the project. I think enabling series imports need to be clearly explained that is a separate issue on the project and series pages.
<jtv> Per-series translations usage as we have it now is an emergent property, derived primarily from the presence of (non-deactivated) templates.
<sinzui> jtv, jcsackett https://translations.edge.launchpad.net/gedit-class-browser is very confusing
<jtv> Yes, some very different things there: setup instructions; import queue; permissions model and translation group.  And no sign of branch synchronization, since that's a per-series setup.
<sinzui> How can the project have open permission if it does not use Lp? Why can I see an import queue if it does not use Lp (well, because the series can be setup). However, if the project sets not applicable, shouldn't the entire page go blank?
<jtv> sinzui: you typically want to provide templates and set permissions before you start using Rosetta.
<jtv> At that state, you may well need or want to see the import queue to see what's going on with your uploads.
<jtv> What's more confusing is that there are 4 access models, but only 2 make sense before you have a translation groupâand of course not enabling translation moots them all.
<jtv> Causality goes something like this:
<sinzui> jtv, so to choose "In Launchpad", the form should insist that I have imported something. The form could include permission widgets as subordinates of "In Launchpad".
<jtv> sinzui: I can't answer that without a better understanding of the implications of that setting.
<sinzui> jtv: how many projects say official translations, but have never imported a template?
<jtv> sinzui: I don't know; I don't see it mattering much.
<sinzui> jtv: sure it does. I am trying to locate where translations happen for an upstream project. the project claims it is Lp, but that is not true because they never complete setup
<jtv> sinzui: internally I don't think we ever thought of official_rosetta as providing that information, useful as it is.
<sinzui> jtv, jcsackett: I think we also have a sizable number of projects that say they user translations, but their code it not i18n enabled
<jtv> But looking at it now, would you believe, the majority of official_rosetta projects have no templates.
<sinzui> jtv: the bridging the gap goal is includes clearly stating where services/work is done: in lp, in an external service, and in this case, not applicable
<jcsackett> jtv: i can confirm that official_rosetta isn't in use much; the only place that seems to check it is products. distributions, projectgroups, and series (both distro and product) ignore it on the browser side.
<jtv> sinzui: in the case of translation, we also have edge cases like "translation is done in Launchpad for these few languages only."
<jtv> jcsackett: we also check it for external suggestions.
<jcsackett> jtv: ah yes; missed that.
<sinzui> jtv: jcsackett I just changed https://translations.edge.launchpad.net/gedit-class-browser to not applicable. the code is not i18n enabled. So I think I should not see the other portlets below the message that clearly states the project has nothing to translate
<jtv> (Actually the complexity there is set to move to SuggestivePOTemplate)
<sinzui> jtv: yeah, code has similar edge cases
<jtv> does that team have any good ways of incorporating those in the usage information?
<sinzui> jtv: jcsackett: I think I am reading that rosetta is implicitly enabled by the setup of templates for a series (code is enabled by a branch linked to a series). Should official_translations be enabled when that state is achieved? Does this mean the project owner cannot choose external or not applicable later?
<jcsackett> i could see translations_usage on series being a calculated property based on that condition; it does seem like this is less of a case of it following the setting on the related pillar.
<jcsackett> at least i assume: are we only talking productseries here, or product and distroseries--it seems similar concerns hold for both.
<jcsackett> jtv, sinzui^
<jtv> The permissions model certainly provides an additional "master switch" on the translationsâ¦  the only difference IIRC between "Closed" permissions and disabling translations is visibility.
<jtv> Everything we've done so far has been on the assumption that the considerations for productseries and packages on the one hand are separate from those for products and distributions on the other.
<jtv> It take some re-think to get my head around a different way of doing it; though it seems sensible to avoid duplication of the concerns.
<jtv> By the way, templates can be disabled.  This should be tantamount (give or take) to reversible deletion.
<jtv> Only POTemplates with the iscurrent flag set should be counted when it comes to determining whether their owning object uses Translations.
<jtv> jcsackett: for Products, it's quite possible that people set up a pilot, import translations (possibly even a lot of them), and finally decide not to use Launchpad.  So there, whether a project uses Launchpad is meaningful information (though it can only be the case if there are non-deactivated templates).  For productseries, I think having non-disabled templates is a sufficient condition to conclude that it uses Translations.
<jcsackett> jtv, sinzui: okay, so clearly the series needs its own attribute to determine this, rather than just piggybacking off the Product.
<jcsackett> which will also ease my initial question, b/c now all contexts hitting the template will have the attribute in question.
<jtv> jcsackett: actually that's something we already derive from the presence of templates (with iscurrent set)
<jcsackett> jtv: sure, but given the existence of something called "translations_usage" i would think we want that to tell something meaningful.
<jtv> jcsackett: yes, I'm talking purely of productseries there.
 * jcsackett nods.
<jcsackett> so, this still raises the question of consistency: i'm a product owner, and i turn off translations for my product. now i have a series of my product that is running independent of my product decision.
<jcsackett> i suppose in this instance its just a case of "go deactivate everything if you want this off."
<jtv> jcsackett: well, the "master usage switch" should override usage for the series.
<jcsackett> jtv: okay, i agree. that's what i was driving at (rather circuitously, i admit)
<jtv> jcsackett: it's late here, don't use long words.  :)
<jcsackett> jtv: sorry. :-)
<sinzui> jcsackett, jtv: I can expound on the question. Should I be able to deactivate the project if it has automatic import enabled?
<jtv> In fact, I'd like to wrap up my urgent issue with sinzui and call it a night!
<jtv> sinzui: you mean import of translations from a branch?
<sinzui> jtv: jcsackett: this was an excellent conversation. We really appreciate it
<sinzui> jtv: yes I do mean from a branch
 * jcsackett nods. it's helped clear up several things.
<jtv> sinzui: so far we have taken the position that you may need some time to set things up right before you open up translation
<jtv> (in fact you may set things up experimentally and then give it a miss)
<sinzui> jtv: yes, I think I am seeing that situation in projects
<sinzui> jtv: do you still need my help with email addresses?
<jtv> Imports in particular can take a while.  We can't just say "oh you have templates, you're open for translation" because it could take considerable time to import your existing translations, and you don't want to invite people to do redundant work on translations that you already have coming in anyway.
<jtv> sinzui: yes, I still need help with thatâfirst off: is that branch you have waiting in the wings one that would give us an easy way to get a "preferred email address for user or team" in the short term?
<jtv> If not: do you have a design in mind that the design for such a function should or could comply with?
 * sinzui was thinking of creating an IContactAddressSet adapter for person|team that works like a cast, and provides a set of address for the person, or team, or team members
<jtv> sinzui: isn't that going a bit overboard with the adapters?  It sounds like a job for an interface.
<sinzui> jtv ^ If person, get preferred, if contact address is not None, get contact address, else for member get email address
<jtv> sinzui: given what abentley-lunch said, it probably makes sense to have a separate function for what bzr needs, because we may end up falling back on a public email-shaped id that need not be an actual email address.
<sinzui> ah, I was missing context
<sinzui> jtv: so we want unique identity as a string, and is commonly an email address
<jtv> In the short term however we need a way for people to have "the" email address respected regardless of whether it's a team's or a person's.
<jtv> sinzui: you'd have to ask Code people for the details there; my immediate concern is something that definitely obtains a publicizable email address if one is available.
<sinzui> teams cannot hide addresses, so that the issue is teams without an address
<jtv> We can work around the current problem in the very short term by asking affected team owners to set up a contact address.  But the existing code only looks for preferred addresses.
<jtv> Yes, that's the issue.
<sinzui> does the address need to work
 * sinzui ponders xrds rules for id urls
<jtv> sinzui: possibly not, though obviously we want to draw a very clear line around ones that might not.
<sinzui> jtv: does this id need to look like an email address, can we use a url
<jtv> sinzui: talk to Code people :)
 * sinzui looks at membership code for sekret email addresses
<jtv> sinzui: buggerâITeamCreation seems to imply that we only allow contact addresses to be set upon team creation.
<sinzui> no, the team can add them at anytime
<sinzui> jtv: team use a different view than users
<jtv> ah
<sinzui> jtv: I am inclined to do think of the future with this issue: "launchpad engineering <1234@launchpad.net>" where the number is Person.id like we do for bugs and questions
<sinzui> jtv: I have not confirmed that address is available, but I can see there are no handlers looking for that address.
<jtv> sinzui: of course we'd like to avoid making up ids if we can; that's something that apparently has been done in the past and which the code people want to do away with.
<sinzui> jtv: we use ids because bugs move, and teams change their names
<jtv> sinzui: apparently people get really unhappy about made-up ids, and so the feeling among Code seems to be that it's better to error out.
<sinzui> I have a problem where it is not possible for the team owner to contact his team because of ridiculous rules involving the teams contact address and mailing list. I might be able to solve the issue with an address like that. It would only work for members of the team
<jtv> You mean the address would become functional?
<jtv> It sounds cool on the one hand, but suspiciously close to re-inventing mailing lists on the other.
<sinzui> jtv: I think we need a functional address, but the debate on it has driven me to tears
<jtv> sinzui: I can imagine it vividly
<sinzui> mailing lists are indeed the problem...a team can have a list, but no members are subscribed...if a tree falls in a forest, and there is not one to hear it, does it make a sound
 * sinzui believe all team members must get email from the list
<jtv> So far we were thinking: if we can at least give people, possibly as soon as tomorrow, some control over the effective preferredemail of their team, then we're in a position to require one.
<sinzui> jtv: I bet mailing lists would be successful if they were automatically on. all teams have them, and they just work!
 * jtv implemented a system like that onceâ¦ you got a wiki, a mailing list, an svn repository etc.  It was quite nice.
<sinzui> projects have series and code, teams have lists and messages
<sinzui> jtv: team-name@lists.launchpad.net is could be real for all teams, but that is a new feature
<jtv> sinzui: it looks as if actually, team.preferredemail should work as it would for user.preferredemail; they're just set in different ways, but setting a team's contact email should produce the effect we're after.
<cr3> the launchpad python style guide mentions that methods should be initialCamelCase, but how do I integrate that with frameworks expecting to callback methods which use_underscores in a clear way? is there somekind of comment or something I should mention so that people can know to expect one or the other naming convention?
<sinzui> yes, they have different rules about the number off addresses
<jtv> abentley-lunch: ^^ this is good newsâmeans we can ask teams to set contact addresses as an immediate workaround.  Need to verify though.
<jtv> cr3: our """See `IAnInterfaceThisClassImplements`.""" docstring convention.
<jtv> may help.
<jtv> cr3: if there's an interface or base class that declares the method that you're defining, mention it in the docstring in that way.
<jtv> If there's no such thing, another nice one (which also happens to fit with our guidelines completely) is:
<jtv> def doMyThing(self):
<jtv>     pass
<jtv> Â 
<jtv> my_thing = doMyThing
<cr3> jtv: both make sense, I'll try to limit myself to the first approach then and define the interface in an appropriate module, like someframework.py which would scope all those external expectations in a single location
<cr3> jtv: the second approach might be nice if I expect the method to be called from within the code base in addition to the framework expecting a certain naming convention. thanks!
<jtv> happy hacking
<EdwinGrubbs> abentley: ping
<abentley> EdwinGrubbs, pong
<EdwinGrubbs> abentley: I read your response to my email about a generic job queue. I'm not interested in creating an end-all-be-all solution. I just think we don't need a bunch of almost identical cronjobs. The registry is adding a couple of job tables, and it would be nice if anybody else adding a table could just re-use one cronjob.
<abentley> Edwin, that was a response to Julian Edwards' email, not yours.  My thoughts on having a single script were covered by thumper.
<EdwinGrubbs> abentley: I'm wondering if you have any thoughts on how a given class of jobs should opt-in to using a generic job queue. The interface could subclass from a GenericJobSource interface, or for more fine grained control, each implmentation could specify classProvides(GenericJobSource).
<EdwinGrubbs> abentley: so, in response to thumper, I would like to provide a round-tuit, since you only have square ones.
<abentley> EdwinGrubbs, I think that each job should have its own configuration, and should have its own crontab entry, with the particular configuration specified as a commandline parameter.
<abentley> EdwinGrubbs, the script itself can then be generic.
<abentley> EdwinGrubbs, one thing that's important to the LOSAs is that each task type have its own database ID.
<EdwinGrubbs> abentley: why do the LOSAs want each job type to have it's own db id? Stub only wanted each cron script to have its own database id.
<abentley> EdwinGrubbs, The losas want it so that they have better visibility into resource use problems.  stub only wanted each cron script to have its own database id because each cron script represented a task type.
<abentley> EdwinGrubbs, we haven't yet found a way to provide that visibility without database ids, and you say you don't want to do a huge change, so...
<EdwinGrubbs> abentley: having the generic cron script use a bunch of separate crontab entries for each task seems like it could lead to a dangerous number of parallel processes. Running them sequentially would help prevent that. A single cron process could switch db ids, and the config could just map job types to db ids.
<abentley> EdwinGrubbs, Running jobs sequentially would harm responsiveness, potentially quite significantly.
<abentley> EdwinGrubbs, I don't agree that the scale we're talking about could lead to a "dangerous" number of parallel processes.
<abentley> EdwinGrubbs, I agree that we could switch DB ids in the script if that seems like a good implementation choice.
<EdwinGrubbs> abentley: Even if paralell process won't overload the system, it will improve throughput if the parallel processes can run any job type, so I think I will go that route.
<abentley> EdwinGrubbs, in other words, provide the parallelism via the script, not by running several scripts at once?
<EdwinGrubbs> abentley: well, either the script could be threaded, or there could be multiple crontab entries for the same script, but the crontab entries wouldn't have an argument that limited that process to just one type of job.
<abentley> EdwinGrubbs, there will need to be limits on the types of jobs that run on a given machine.  CreateMergeProposalJobs must run on crowberry, for example.
<abentley> EdwinGrubbs, MergeProposalJobs are supposed to run on loganberry.  (They could also run on crowberry, but that would waste crowberry's resources.)
<EdwinGrubbs> abentley: I'm not planning on moving over existing job types. I'm just planning on providing a simple way for a developer to choose to have their job class run on the generic cron script.
<abentley> EdwinGrubbs, so when I choose to use that for my latest job type that can only run on loganberry, how will I do that?
<EdwinGrubbs> abentley: I wasn't aware of that feature requirement. However, instead of giving the generic cron script a job type argument, the config could specify which servers that a job type can run on, or there could be names for groups of jobs depending on what resources they need. A server's config would just have to specify which groups it can run based on which resources (e.g. external network access, or storage access) it provides.
<abentley> EdwinGrubbs, I will be happy if the new system provides control over which hosts the job runs on.
<abentley> EdwinGrubbs, I still don't think it's a good idea to run distinct job types sequentially, because they can have radically different performance characteristics.
<abentley> EdwinGrubbs, so if you introduce parallelism, I would suggest (at least) one thread/process per job type.
<abentley> EdwinGrubbs, you should also look at the TwistedJobRunner, because it has support for parallelism.
<EdwinGrubbs> abentley: how does someone add a crontab entry anyway? TwistedJobRunner would at least eliminate that step. My main goal is to make it possible to add job types with as little work as possible.
<abentley> EdwinGrubbs, add a request to https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
<lifeless> moin
<jelmer> lifeless: hi
<jelmer> lifeless: Thanks very much for that fix yesterday; I crashed shortly after our conversation on IRC.
<lifeless> no probs, did it work?
<lifeless> abentley: EdwinGrubbs: I agree that serialised jobs of different sorts is undesirable
<jelmer> lifeless: From what I've seen it did.
<lifeless> jelmer: great
 * jelmer disappears off to vacation
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Performance Tuesday | Week 2 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<cr3> leonardr: hi there, might you have a moment for advice on decorators for interface methods and attributes?
<leonardr> cr3, sure, but my latency may be very high
<cr3> leonardr: ditto :) so, the problem I'm trying to solve is that I have classes that are expected to have methods named with underscores by the framework but I'd like to adhere to the python style guide which uses camelCase instead.
<leonardr> cr3: you can use export_as to publish a named operation under a name different from the underlying python method name
<cr3> leonardr: I was thinking it might be cool to have interfaces define methods using camelCase and decorate the methods with something like @compatible_as("uses_undecores"), where the string would be the compatible method name which would be defined by the decorator in the class implementing the interface
<cr3> leonardr: could I use that even if I don't intend to export the method through lazr?
<leonardr> you can use it, but nothing will happen
<cr3> leonardr: in other words, does export_as simply create another alias for the name of the method in the class implementing the interface?
<leonardr> no, lazr.restful creates a _totally new_ adapter class
<EdwinGrubbs> losas: I have some non-urgent questions regarding the cronjob setup.
<leonardr> in which methods have different names
<cr3> leonardr: ah, so what would you think of @compatible_as("other_name") in this non-lazr context then? does this approach make sense?
<leonardr> cr3: can you sketch out the interface and its implementation as it would work without the camelCase?
<leonardr> i don't have a picture of what you have now
<abentley> thumper, how would you ensure that the comments, revisions and incremental diffs appeared in a particular order?
<cr3> leonardr: https://pastebin.canonical.com/37433/
<leonardr> cr3: you could get that to work by putting the annotation in the *implementation*
<cr3> leonardr: get_user = getUser
<leonardr> if you had it in the interface, you'd need to run grok or something on the interface to do something like "find all the registered implementations and add methods to them"
<leonardr> but if you put it in the implementation, you could just do this, with no annotator:
<leonardr> get_user = getUser
<leonardr> which i guess is what you just said
<cr3> leonardr: if so, jtv suggested that earlier, but I feel it's tucked away too much
<leonardr> cr3: tucked away just by virtue of being in the implementation?
<cr3> leonardr: that's a good way of putting it, I guess it's alright
<lifeless> gary_poster: hi
<gary_poster> lifeless, hi
<lifeless> would you like to catch up?
<leonardr> cr3: the problem is that the interface just puts constraints on any possible implementation
<leonardr> you can specify that any possible implementation must implement both get_user and getUser and that they must do the same thing, but you still have to actually do the work
<cr3> leonardr: well, @compatible_as would man that any implementation must implement getUser but would also have get_user defined for free
<cr3> s/man/mean/
<gary_poster> lifeless: Thank you.  I'll be stepping out in 15 min, and in another conversation now.  Would a very quick catch-up be useful, since the next time we can do so is a whole day away?
<cr3> leonardr: but, as you said earlier, that would imply something like grok would have to go modify each implementation. I feel that's somewhat cleaner than rely on each implementation having to remember to define get_user as well as getUser
<leonardr> cr3: problem is you can't do that in an interface. interfaces don't give you anything for free, they just specify the work that must be done
<lifeless> gary_poster: nothing urgent; was just going to chat over the zope conf stuff; architectural concerns for ajax; apologise for the
<lifeless> # of bugs I filed while you were gone...
<gary_poster> lifeless: heh, yeah that's a bit overwhelming.  At least I'm not at a lack of things to do ;-)
<lifeless> well still have some spikes in https://lpstats.canonical.com/graphs/OopsLpnetHourly/20100914/20100921/ I need to track down
<leonardr> cr3: well, that's certainly something grok can do
<leonardr> it might be a little simpler if you put the grok code in the implementation, though
<leonardr> @fill_in_methods(IAuth)
<leonardr> that way IAuth wouldn't have to find Auth. Auth already knows about IAuth
<lifeless> Ursinha: hiya
<leonardr> you could even have @fill_in_methods() call implements()
<leonardr> and use it instead of implements()
<cr3> leonardr: interesting, I'll definately consider that
<leonardr> cr3: what's the framework that wants you to use underscores?
<leonardr> django?
<cr3> leonardr: and oauth
<wallyworld> morning
<leonardr> cr3: consider calling it @implements_for_django or something
<leonardr> and then reference django as well in your interface annotations
<leonardr> @django_name('get_user')
<cr3> leonardr: I feel this is more generic though, since I've already encountered the problem with two frameworks in the very early stages of a project which has only had three commits so far :)
<leonardr> cr3: ok, well, make some reference to what is happening
<cr3> leonardr: also, I was thinking this could also be an intellectual exercise in an attempt to do things right... as long as it's not too long to implement either :)
<thumper> morning
<leonardr> that the interface being implemented incldes method renames that need to be added
<thumper> wallyworld: are you around for a standup now?
<cr3> leonardr: indeed
<wallyworld> yup
<lifeless> Ursinha: when you come back, I need a hand with the deployment script
<thumper> abentley, rockstar: one of you host?
 * rockstar realizes it's standup time!
<abentley> thumper, I will.
<gary_poster> lifeless: spikes: interesting.
<gary_poster> zope conf stuff: there's some small things of interest.
<gary_poster> I mentioned publicly that I wanted to switch to a WSGI front end, and then I would be interested in someone making a WSGI simple openid consumer plugin because I don't see why that can't be shared, and the existing implementation like repoze.who are complex and more flexible than we or many other projects would need.
<gary_poster> I got two discussions about the WSGI openid plugin within the hour, with one proposed implementation and a review request (from Martin von LÃ¶wis) the next day.  Perhaps I didn't clarify sufficiently that we weren't *immediately* ready :-)
<gary_poster> I mentioned the long poll idea, but it took a long time for people to see the point.  Chris McDonough proposed web3 on the web sig with a mechanism that would have let us do what we want but that was not the intent of the design, so no one responded when I said that it would be nice.  Maybe I didn't explain it well enough...it is awfully close to the use case of passing an iterable (which WSGI supports natively, 
<gary_poster> the difference is that the long poll approach needs you to be able to send headers once the deferreds have been processed.
<gary_poster> Anyway, I think I see how to do that.  The kind of collaboration we need is more on the WSGI or Twisted side.  I think we should just try it and see how it works, seeing if we can get Twisted people to help out.
<gary_poster> But now I have to run :-)
<lifeless> ciao
<rockstar> What. The. Hell. My system just shat itself back out to the login screen for no reason at all.
<lifeless> X crashed
<lifeless> or something similar.
<rockstar> lifeless, yeah, the screen went all white or something.
<lifeless> check your X log
<mtaylor> lifeless: wanna see something weird?
<mtaylor> lifeless: https://bugs.edge.launchpad.net/drizzle/+bugs?search=Search&field.assignee=mordred <--- there's my drizzle bugs...
<mtaylor> lifeless: now click on #622576, which is listed as High/Confirmed
<_mup_> Bug #622576: plugin status vars not working <Drizzle:Confirmed for mordred> <Drizzle dexter:Invalid by mordred> <Drizzle elliott:Invalid by mordred> <https://launchpad.net/bugs/622576>
<mtaylor> and then you see it's invalid in all of the places I can mark it invalid. :)
<lifeless> please file a bug
<lifeless> looks like a series / nomination / infestation bug
<lifeless> there are three tasks
<lifeless> one task is project wide
<lifeless> but its knobs are hidden
<jml> <corecode> % bzr branch lp:ubuntu/mdadm
<jml>  bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches.">')
<jml>  what am i doing wrong?
<jml> ^^^ thumper, from #ubuntu-devel
<thumper> it isn't linked most likely
<thumper> jml: https://code.edge.launchpad.net/ubuntu/+source/mdadm no branches
<jml> thumper, it's the wrong error for no branch
<thumper> jml: yes, there is a bug filed about bad errors
<jml> thumper, is it going to be fixed soon?
<thumper> jml: no one is looking at it right now
<jml> thumper, it was introduced by the recent private branches stuff right?
<thumper> yes
<thumper> as we pushed the checks deeper
<jml> thumper, since it's a regression introduced by a recent change, I reckon it would be a good idea to bump the bug up in the queue
<lifeless> hmm, time to tackle BugTask:+index methinks
<lifeless> Chex: thanks for CP
<Chex> lifeless: yes sure, your welcome
<mwhudson> is buildbot un****ed yet?
<lifeless> mwhudson: it was fine last night
<mwhudson> ok
<lifeless> mwhudson: yeterdays CP is live now
<mwhudson> lp and db_lp are offline, i see
<lifeless> now there is a buglet with the qatagger to identify
<lifeless> mwhudson: they are ec2 slaves
<mwhudson> my branch passed ec2 yesterday but didn't land because of testfix
<lifeless> mwhudson: so thats not in itself an issue
<mars> mwhudson, don't worry, the CI system is being a real pain right now, but I plan to work on it.
<lifeless> 'click clack'
<mwhudson> mars: \o/
<thumper> I have a general statement about our buildbot builders, lp and db_lp are failing a lot, if we don't care, we should remove them, if we do care we should fix them
<thumper> lifeless: what is it to be? ^^^
<wgrant> We can't really remove them until Hardy is gone.
<thumper> so... when are our appservers going lucid
<thumper> ?
<elmo> they are
<elmo> only the DB servers are hardy now
<thumper> really?
<thumper> awesome
<thumper> so... we can get rid of the hardy builders
<mars> elmo, just the DB?
<wgrant> That's convenient.
<mars> what thumper just said
<wgrant> As long as the Lucid builders aren't running 8.4.
<thumper> python 2.5 is dead, long live python 2.6
<elmo> thumper: https://wiki.canonical.com/InformationInfrastructure/OSA/Projects/LucidUpgrades
<thumper> elmo: thanks
<mars> whoohoo!  When did that get finished?
<wgrant> Are the Lucid builders using postgres 8.3 or 8.4?
<elmo> mars: last rollout was the last big push
<elmo> if someone knows their machine names, I can check
<mars> elmo, pilinut
<elmo> pilinut is 8.4
<wgrant> Because we probably still want the Hardy ones around if they're 8.4
<elmo> we could downgrade them to 8.3 on lucid
<mars> hmm
<deryck> lifeless, ping
<mars> so we develop on 8.4, EC2 runs 8.4, buildbot runs 8.3
<lifeless> deryck: hey
<deryck> hey
<lifeless> thumper: I wrote to the list
<deryck> lifeless, are you building CPs for every rev in stable now that gets qa-ok?
<lifeless> thumper: we care because it breaks production-devel->production-stable builds if python 2.6 only stuff gets in.
<lifeless> deryck: hell yeah
<deryck> awesome
<lifeless> deryck: but only full merges, not actual cherry picks
<lifeless> so for instance
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
<lifeless> Revision 11556 can be deployed: qa-ok
<lifeless> Revision 11557 can not be deployed: not-ok
<mars> elmo, wgrant, unfortunately I do not know enough to say that downgrading to 8.3 would cause much hardship for packaging, dependencies, etc.
<lifeless> I would do 11556, but not 11558 even if its 'ok', because 11557 isn't ok.
<mars> elmo, wgrant, stub would know though.  And he'll be online in a few hours
<lifeless> mars: thumper: no we can't get rid of the hardy builders
<lifeless> see my mail to the list where I already detailed this.
<deryck> lifeless, ok, cool.  And the upshot is we don't need to build CP merge requests ourselves any longer, right?
<thumper> lifeless: so we should fix them
<thumper> lifeless: because right now they aren't
<lifeless> thumper: yes
<lifeless> thumper: I totally agree
 * thumper cracks the whip
<elmo> mars: I think it's fine - we run sourcherry as lucid but with 8.4 + 8.3 installed and 8.3 is the primary
<elmo> mars: FWIW
<lifeless> we also need to make devel->stable promotion require *both*
<wgrant> mars: We ran 8.3 on Lucid for ages.
<wgrant> On every dev system.
<wgrant> And mawson is running it.
<lifeless> deryck: so, if you want something that is *after* a non-qa'd rev, you can do a few things:
<lifeless>  - help get that non-qa'd rev qa'd
<lifeless>  - do a manual cp around it
<lifeless> sometimes we'll have  abad rev, like 11566, where we need to wait for the fix to be ready as well and land a wide range of revs.
<lifeless> the goal is, obviously, to be doing 1 rev at a time.
<mwhudson> lifeless: i guess reverting the bad rev is also an option?
<mars> wgrant, yep.  I am worried about test coverage, and trying to get all systems running the same thing.  Dev is moving to 8.4.
<mars> or has moved for new setups
<wgrant> mars: Right, which is why I fear killing off lp and db_lp when they are the only 8.3 we have.
<wgrant> Besides production.
<lifeless> mwhudson: yes, in which case the revert is the 'fix' and we still need to land a wide range of revisions.
<mwhudson> lifeless: right
<lifeless> deryck: once mthaddon has the qastaging up and running
<lifeless> deryck: we can stop deploying to edge w/out qa
<lifeless> deryck: and this will become a bit simpler - we'll just deploy stable to edge + lpnet, rather than deploying production-stable, or something like that.
<wgrant> Revs without MPs make me sad.
<mwhudson> wgrant, lifeless: btw, do you know if the buildd-manager problem i had yesterday is fixed yet?
<deryck> lifeless, this is awesome.  I don't see an email outlining this is active now.  I see your "always deploy devel" email reminder, but that's it.  What subject is it?
<wgrant> mwhudson: It should be.
<wgrant> Not sure how.
<wgrant> But the branch landed overnight.
<mwhudson> heh
<mwhudson> i guess i can find out
<mwhudson> wgrant: it was buildd-manager only?  i don't need to reinstall launchpad-buildd?
<wgrant> No, it's a master-only change.
<mwhudson> cool
<wgrant> If you confirm that it no longer exhibits yesterday's problem, I'll update the docs with an extra step that's required to process the uploads.
<lifeless> deryck: well the overall RFWTAD process documents the end goal
<lifeless> deryck: I'm just following the existing process for deploying midcycle using the qa tools that have come live from that process to aid me
<lifeless> deryck: I'm waiting for mars and Ursinha to send their mail about the qatagger.
<lifeless> which was meant to happen last week.
 * lifeless eyeballs mars and Ursinha 
<deryck> lifeless, right, I totally get.  And I completely understand we're moving to this.... just meant that since you're patching everything as CPs now, our devs don't need to put single CPs together.  bdmurray just put one up, for example.
<mars> wgrant, I'm just looking up that thread that Robert mentioned.  Otherwise, I wonder why we don't run lucid 8.4 + lucid 8.3.  I would think it would be easier to maintain than lucid 8.4 + hardy 8.3.
<mwhudson> wgrant: ok
<mars> lifeless, on the list for today
<lifeless> deryck: well they do if they want it promptly: we're a week behind on what I'm doing because of (teething problems, things not being qa'd promptly)
<wgrant> mars: Do we know when 8.4 is happening?
<wgrant> Not until the next rollout?
 * mars shrugs
<lifeless> wgrant: it will be done rolling AIUI
<wgrant> Even the master?
<lifeless> wgrant: same slony version, different pg, replicate, switch master, continue.
<wgrant> That seems unlikely, but nice.
<wgrant> Ah, that works?
<wgrant> Handy.
<lifeless> AIUI, YMMV, AS
<lifeless> deryck: so, if something needs CPing - do it. If its near the number in https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt, consider helping that number move up
<lifeless> deryck: otherwise just CP as normal.
<lifeless> deryck: which is why I haven't sent a mail about this; its not a reliable service yet )
<lifeless> :)
<wgrant> Why is the Launchpad Credentials Manager going through the webapp with OAuth, rather than using a restricted API?
<wgrant> That seems unnecessarily fragile.
<lifeless> wgrant: its being backed out
<wgrant> Ah.
<mars> lifeless, so I read the thread.  Are you saying we need the hardy builders because the LP packages have to still install on the db machines, which are postgres 8.3 on hardy?
<lifeless> yes
<lifeless> otherwise we can't rollout
<lifeless> which would be ... bad
<wgrant> Why do the DB servers have LP code on them?
<lifeless> wgrant: security.py
<lifeless> wgrant: database/schema/patch*
<wgrant> Well, that *could* be run remotely.
<mwhudson> wgrant: gaarrr
<wgrant> mwhudson: Hm?
<lifeless> wgrant: more fragile in the event of network glitches etc.
<mwhudson> wgrant: i now have a build thats "Needs building  on Bob The Builder", but buildd-mananager isn't scanning that builder
<lifeless> wgrant: we choose not to, for now.
<deryck> lifeless, gotcha, thanks
<mwhudson> i started the manager before i started the librarian, so the attempt to dispatch the job failed hilariously
 * deryck is taking pics of kids in super suits while chatting :-)
<mwhudson> the builder is marked ok and idle though
<lifeless> wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/641338 - is that a root cause dup?
<_mup_> Bug #641338: Archive:EntryResource:syncSource timeouts <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/641338>
<mwhudson> i guess i can restart buildd-manager
<mars> lifeless, so if we have a near release window for the DB server updates, then we do not have to fix the lp and db_lp builders.
<wgrant> mwhudson: buildd-manager isn't scanning the builder, or just isn't dispatching?
<mwhudson> wgrant: isn't scanning
<mars> lifeless, if they are upgraded next week, then why go through the trouble?
<wgrant> mwhudson: Urgh.
<wgrant> Kill it and restart it.
<mwhudson> the attempt to dispatch really did blow up though
<mwhudson> three tracebacks!
<wgrant> lifeless: Probably not entirely.
<wgrant> lifeless: The copy checker is awfully slow.
<wgrant> Unnecessarily so.
<mwhudson> 2010-09-21 10:44:27+1200 [-] canonical.librarian.interfaces.UploadFailed: [localhost:58090]: [Errno 110] Connection timed out
<lifeless> mars: I can't asnwer that until I know how much trouble is needed.
<mwhudson> 2010-09-21 10:44:35+1200 [-] exceptions.AttributeError: 'BuilderSlave' object has no attribute 'clean'
<mwhudson>         exceptions.AttributeError: 'NoneType' object has no attribute 'specific_job'
<lifeless> mars: but its a pipeline stall for 8 hours (two runs) when it breaks.
<wgrant> mwhudson: WTF? BuilderSlave?
<lifeless> mars: and I've run into this every second day or so in the last work week
<wgrant> It should be a RecordingSlave!
<wgrant> JULIAN!
<mars> lifeless, yes, I understand, it sucks.
<mwhudson> yes, i think it's the failure counting stuff
<mwhudson> let me paste the whole misery
<mwhudson> bah
<mars> need to go afk, back later
<wgrant> mwhudson: You could try r11580
<mwhudson> now it's just failing
<lifeless> wgrant: are you working on that ?
<lifeless> wgrant: its perf tuesday ;)
<wgrant> 11581 has some buildd-master changes that I don't quite understand, so I can't trust that they're not this breakage.
<jml> did you guys see https://code.edge.launchpad.net/~jml/launchpad/buildd-deferred/+merge/36010 and https://code.edge.launchpad.net/~jml/launchpad/buildd-deferred-fo-sho/+merge/36037, btw?
<wgrant> lifeless: It's also I-have-far-too-many-projects week :(
<lifeless> mars: will Ursinha be back? or do you know about the qatagger deployment story?
<jml> (speaking of BuilderSlave)
<mwhudson> wgrant: http://pastebin.ubuntu.com/497319/
<wgrant> jml: That's the change to which I refer.
<wgrant> I'm currently trying to interpret the diff.
<lifeless> for line in lines:
<lifeless> ...
<wgrant> lifeless: Hm?
<mwhudson> and bah, it fails in almost the same way when i restart the buildd-manager
<lifeless> wgrant: a joke
<wgrant> Ah.
<jml> wgrant, my hunch is that it doesn't swap a BuilderSlave for a RecordingSlave anywhere
<wgrant> jml: It already didn't in some situations.
<wgrant> Which caused breakage. But it may no longer cause the same breakage, so I don't recognise it.
<jml> wgrant, I mean, the diff doesn't really change call sites
<jml> wgrant, if we're talking about buildd-deferred/+merge/36010
<jml> wgrant, the breakage is because of the shift away from magic getattr methods
<wgrant> mwhudson: Is the librarian running?
<mwhudson> wgrant: it wasn't then
<mwhudson> wgrant: but when i restart with it running, it fails in the same way, except without the first traceback
<jml> wgrant, BuilderSlave needs an explicit clean() method that forwards to the xmlrpc proxy
<wgrant> mwhudson: Pastebin pls.
<wgrant> Better tests pls.
<wgrant> The fact that buildd-manager has been completely broken in devel twice in the last week hints that we might possibly need better tests, I think.
<jml> wgrant, working on it.
<wgrant> Excellent.
<jml> wgrant, see the two diffs I pasted.
<lifeless> wgrant: presumably 2201  OOPS-1723N1442  Archive:+copy-packages is simillar ? (thats statement counts)
<mwhudson> wgrant: http://pastebin.ubuntu.com/497321/
<wgrant> It should be easier now that jelmer's branch has removed the Popen crap.
<wgrant> lifeless: Yes.
<jml> mwhudson, http://pastebin.ubuntu.com/497322/ this will address the clean() thing
<wgrant> Yeah, looks like it.
<mwhudson> wgrant, jml: it's possible that my playing around yesterday left the db in a strange state
<wgrant> Not sure about the specific_job thing, though.
<wgrant> That's a bug, even if your DB is borked.
<jml> mwhudson, soyuz ought to be more robust in the case of... yeah, what wgrant said
<wgrant> (which it is)
<wgrant> jml: Not Soyuz any more lalala.
<mwhudson> yeah
<jml> buildmaster
<jml> such a silly name. I'd of called it a chuzwazza
<mwhudson> ok, it's building now
<mwhudson> (with jml's patch)
<jml> I can add that patch with tests tomorrow, if you'd like
<mwhudson> it seems like it would be a good idea
#launchpad-dev 2010-09-21
<wgrant> mwhudson: Once the build finishes, buildd-manager should copy it into an upload directory and set the status to UPLOADING.
<mwhudson> i wonder how much faster the chroot would unpack on arm if it was gzipped not bzip2ed
<wgrant> We then need to run a separate script to upload it.
<mwhudson> ah right, this is the stuff that's changed recent
<mwhudson> ly
<wgrant> Like 8 hours ago, yes.
<wgrant> So I haven't run it yet.
 * wgrant fixes that.
<jml> speaking of changes
<jml> I'm now running a couple of ec2 runs with my new, improved ec2 error mail
<jml> email looks something like: http://paste.ubuntu.com/497325/
<mwhudson> wgrant: it's "Uploading build  on Bob The Builder" now
<mwhudson> (this looks like progress)
<wgrant> mwhudson: Excellent.
<wgrant> So, now you need to run...
<mwhudson> scripts/process-upload.py ?
<wgrant> ./scripts/process-upload.py --builds -C buildd -vvv /var/tmp/builddmaster
<wgrant> I think that should work.
 * mwhudson tries science
<mwhudson> wgrant: http://pastebin.ubuntu.com/497326/
<wgrant> mwhudson: I think it worked.
<mwhudson> not quite sure what the bottom two bits are about, probably from the fun i had yesterday
<wgrant> Except that there were two other uploads from the breakage yesterday.
<wgrant> Does the build have binaries listed now?
<mwhudson> wgrant: yes
<Ursinha> lifeless, hello
<mwhudson> process-accepted, publish-distro?
<wgrant> mwhudson: OK, so it's all working.
<wgrant> Right.
<Ursinha> lifeless, I'm in an oops tools minisprint with matsubara-afk
<mwhudson> wgrant: if you edit the page, you might want to scatter some -vv s around i think
<lifeless> Ursinha: hi
<wgrant> mwhudson: I might indeed.
<lifeless> Ursinha: I am blocked; I need a hand
<lifeless> Ursinha: I cannot diagnose why https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt shows 11557 as qa-notok
<mwhudson> although wow scripts/publish-distro.py --ppa -vv is noisy
<lifeless> Ursinha: I *thought* we had more output than that.
<wgrant> mwhudson: Most of it was still written on July 22nd last year, so it's not exactly as I'd do it now!
<lifeless> Ursinha: and I'm wondering where it goes so that I can see it.,
<mwhudson> wgrant: :)
<lifeless> Ursinha: (and the rest of the canonical staff should be able to look at it too)
<Ursinha> lifeless, take a look here: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<mwhudson> and yay, i can download a build
<wgrant> mwhudson: Is p-a happy?
<lifeless> Ursinha: that looks old
<mwhudson> wgrant: seems so
<lifeless> Ursinha: because 11555 is live on production
<Ursinha> lifeless, it's not final, just showing you what must be the report
<lifeless> Ursinha: let me try a different angle.
<lifeless> Ursinha: we *had a totally useable debug report*
<lifeless> Ursinha: what happened to it?
<Ursinha> lifeless, wait, I need context, reading devpad logs
<Ursinha> been in a totally different context the whole day
<lifeless> Ursinha: ok, lets start over.
<Ursinha> lifeless, just give me a moment
<jml> anyway, see you crazy cats later.
<lifeless> Ursinha: hi, I've been doing CP's to lpnet based on the qatagger output; and getting folk to QA stuff as needed for ut.
<lifeless> *it*
<lifeless> Ursinha: sure; /me hits the pause button
<Ursinha> thanks :)
<mwhudson> wgrant: it seems to have worked
<wgrant> mwhudson: Great.
<wgrant> mwhudson: Docs updated.
<wgrant> With the new process-upload invocation, and liberal application of -v.
<Ursinha> lifeless, when was 11555 deployed?
<Ursinha> lifeless, please, refresh the html report
<lifeless> Ursinha: this morning
<Ursinha> lifeless, always consider the txt report accurate
<Ursinha> the html one is experimental
<lifeless> Ursinha: so, I think we want to keep the txt report as it is too -  because its safe to show e.g. wgrant
<lifeless> Ursinha: whereas the html report can potentially report on security bugs
<Ursinha> lifeless, not sure what you mean; txt are for losas, html for developers
<lifeless> Ursinha: but the html still doesn't address my question
<Ursinha> roughly speaking
<lifeless> Ursinha: why is 11557 blocked?
<Ursinha> lifeless, I need to finish some tests and will put that in production, so we'll have both
<mwhudson> wgrant: thanks for the help
<lifeless> Ursinha: it wasn't mentioned by the commit message
<Ursinha> lifeless, linked to the branch
<lifeless> Ursinha: its an in-progress bug later on the branch
<Ursinha> the problem I told you reusing branches would cause
<lifeless> fair enough
<wgrant> mwhudson: np
<lifeless> there's a bug open to support this better though?
<Ursinha> because neither ec2 or bzr lp-land or the tagger support this use case
<Ursinha> lifeless, of course
<lifeless> Ursinha: coolio
<wgrant> librarian downloads are slow :(
<wgrant> I wonder why.
<lifeless> Ursinha: could you please tell the txt report to refresh ?
<mars> lifeless, the HTML report says bug 618375 has not been QA'd.  the 'qa-notok' status should really be 'qa-needstesting'.  However, the bug has no tags?
<_mup_> Bug #618375: BugTrackerSet:+index consistently slower than 10 seconds <qa-ok> <timeout> <Launchpad Bugs:Fix Committed by lifeless> <https://launchpad.net/bugs/618375>
<Ursinha> lifeless, bug 638468 for ec2 land, bug 640566
<_mup_> Bug #638468: ec2 land: do not include already fix-committed or fix-released bugs in commit message <new-merge-workflow> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/638468>
<lifeless> Ursinha: I recognise I'm shooting myself in the foot
<_mup_> Bug #640566: qa-tagger should not consider linked bugs to branches when bugs are already Fix Released <new-merge-workflow> <qa-tagger:Triaged by ursinha> <https://launchpad.net/bugs/640566>
<Ursinha> for qa-tagger
<lifeless> mars: it has no tags because its from later on; its further work.
<Ursinha> yes, hehe
<Ursinha> that's what reusing branches cause
<lifeless> Ursinha: the big reason to handle reused branches properly is developers shouldn't need to remember if they used the name before.
<Ursinha> but I'm working on a workaround
<lifeless> Ursinha: we should 'just work'
<lifeless> Ursinha: cool, and thanks.
<Ursinha> lifeless, that's fine, I'm just saying this case wasn't considered
<lifeless> yeah
<lifeless> Ursinha: theres another case I think we missed.
<lifeless> look at rev 11566
<Ursinha> and that's why such things are happening
<mwhudson> wgrant: what does
<lifeless> this was one part of a 2-part branch
<mwhudson> 2010-09-20 23:24:03 WARNING Upload was rejected:
<mwhudson> 2010-09-20 23:24:03 WARNING 	nominatedarchindep is not present in legal_archseries: armel
<mwhudson> mean?
<mwhudson> oh i think i know
<mwhudson> the upload contains _all packages and i only have a armel builder configured
<wgrant> What's nominatedarchindep set to?
<Ursinha> lifeless, let me see
<mwhudson> no idea
<mwhudson> it's on distroseries?
<wgrant> It should be on distroseries:+edit
<wgrant> Or maybe +admin.
<wgrant> Set it to armel.
<lifeless> Ursinha: so this is fixable by a rollback
<lifeless> Ursinha: -or- by doing a fix
<mwhudson> ah, wasn't the package i wanted to build anyway
<lifeless> Ursinha: so we need a matching thing like rollback=11566 fixes=11566
<lifeless> Ursinha: same logic for the tagger - can only deploy 11566 with the fix-for-11566, but humans would be confused by a rollback=11566
<lifeless> Ursinha: lastly, we also need to be able to annotate this things after the fact: commit messags are nice, but we make mistakes.
<Ursinha> lifeless, if we're reusing branches, I need to rely in commit messages
<lifeless> Ursinha: that seems orthogonal to me.
<Ursinha> for commit messages to be reliable, i.e. only contain valid in progress bugs, people all need to use ec2 land or bzr lp-land
<mwhudson> wgrant: +edit and +admin look basically the same (?) and neither have nominatearchindep
<Ursinha> lifeless, qa-tagger needs to consider something besides linked bugs to branches
<lifeless> Ursinha: perhaps. We're iterating here, I recognise that.
<lifeless> Ursinha: now that we have something working - and it is, cause we're deploying :P - we're finding out things that were not obvious up front
<Ursinha> yes :)
<Ursinha> that's nice
<Ursinha> I was expecting that
<lifeless> I've very excited and happy with what we've achieved so far.
<Ursinha> lifeless, me too
<Ursinha> lifeless, next step is to make html reliable and available, after that fix this problem of reused branches (that's messing with old bugs, argh)
<wgrant> mwhudson: Maybe you'll need to set it with SQL.
<mwhudson> wgrant: yeah, maybe
<lifeless> Ursinha: part of the issue there is the many week delay between landing and deploy, as that gap narrows it will be easier.
<wgrant> I'm boring and just use i386.
<mwhudson> it wasn't the package i wanted to build though, so i don't really care
<Ursinha> agreed
 * mwhudson is building pyton2.6 so he can compare build times with the official builders
<Ursinha> lifeless, what's the problem with 11566? that's an incremental qaable fix, right?
<lifeless> Ursinha: thanks for interrupting your sprint; I think I'm good now, I know hat to look for for more revs
<Ursinha> so the bug will be qa-needstesting
<Ursinha> lifeless, it's late now, 8h40PM
<Ursinha> I have to take matsubara-afk home :)
<lifeless> Ursinha: no, the branch is broken
<Ursinha> lifeless, is the bug qa-bad?
<lifeless> Ursinha: if its rolled out without its second half it will break.
<Ursinha> hm
<lifeless> I put bad-revision-11566 in the bug tags
<lifeless> Ursinha: 5 *6* 6 , not 5 *5* 6
<Ursinha> lifeless, I know
<lifeless> (I got confused between them yesterday :P)
<Ursinha> lifeless, so it shouldn't be committed without the second part? why only half of the fix was committed?
<Ursinha> lifeless, hehe
<Ursinha> I almost did now :P
<lifeless> Ursinha: it wasn't meant to be
<lifeless> Ursinha: it was reviewed in two parts, meant to be landed in one.
<lifeless> sorry bad-commit-11566
<Ursinha> lifeless, right, so we should tell developers to don't do that
<lifeless> hah
<Ursinha> first of all
<lifeless> yes, I agree its undesirable.
<Ursinha> lifeless, I can't make the script work without some assumptions :)
<Ursinha> or I'll spend 90% of the time trying to teach it how to workaround bad use of the process
<Ursinha> but I understand it has to be considered
<lifeless> agreed
<Ursinha> so you think using the same mechanism of rollback tag should work
<Ursinha> I agree
<Ursinha> that would be nice exercise of the script, btw
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
<lifeless> Ursinha: I'd really like to see the other output from the script
<lifeless> Ursinha: can you get it to go to the same file, or a different file?
<lifeless> you know the stuff where it says what revs it looked at as it goes and so on. I know its not pretty, but its very helpful.
<Ursinha> what's the other output? the html one?
<lifeless> Ursinha: no, there were debug messages
<Ursinha> ah
<Ursinha> AH
<Ursinha> I see
<Ursinha> you want the true log
<Ursinha> :)
<lifeless> yes!
<Ursinha> :)
<Ursinha> debug log, cool
<lifeless> wallyworld: thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/404131 needs QA
<_mup_> Bug #404131: tales linkify create broken links  <qa-needstesting> <trivial> <ui> <Launchpad Bazaar Integration:Fix Committed by wallyworld> <https://launchpad.net/bugs/404131>
<wallyworld> lifeless: ack
<Ursinha> lifeless, https://devpad.canonical.com/~lpqateam/qa_reports/qa-tagger-stable.log
<lifeless> Ursinha: \o/
<Ursinha> :)
<Ursinha> lifeless, should be there from now on
<lifeless> Ursinha: thank you!
<Ursinha> lifeless, my pleasure, sir :)
<lifeless> now when 404131 is qa'd we should have another big batch CP'ing today
<Ursinha> yay
<poolie> hi, happy performance tuesday!
<poolie> wallyworld: good question!
<poolie> istr there's a way i can run process-mail.py feeding it from a test mailbox
<poolie> to interactively test gpg/dkim stuff
<poolie> is that true?
<wgrant> lib/canonical/launchpad/doc/mailbox.txt
<poolie> thanks
<bdmurray> lifeless: I've received an ec2 failure regarding runJobHandleError and with a Fake exception.  Did you work on that last week or so?
<lifeless> bdmurray: I changed some code in that area
<lifeless> pastebin ?
<bdmurray> https://pastebin.canonical.com/37437/
<Ursinha> lifeless, hey
<Ursinha> lifeless, thought about one workaround for 11566
<Ursinha> lifeless, if we wait for the second branch to land, just leave it as qa-needstesting
<Ursinha> when the second branch lands, it will mention the same bug, and it will be QAable
<Ursinha> as soon as this bug gets then QAed ok, the first revision will be marked as ok to land
<Ursinha> voila
<lifeless> Ursinha: right, but we need to make sure that nothing lands without both.
<Ursinha> the bugs ensures that
<wgrant> Shouldn't the first branch just never land?
<Ursinha> *bug
<lifeless> Ursinha: how so ?
<Ursinha> wgrant, land in qa environment
<Ursinha> not production
<lifeless> bdmurray: try with https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994 merged in
<Ursinha> lifeless, the first and the second branches mention the same bug
<wgrant> If the first branch is going to break things, it should never even hit devel alone, probably.
<lifeless> Ursinha: yes, but a branch in the middle might be bad
<Ursinha> wgrant, but it's only known as breaking things because it's already in the qa instance
<Ursinha> lifeless, what do you mean?
<wgrant> Ursinha: In 11566's case it was known that it would break things.
<Ursinha> wgrant, so it shouldn't have landed in first place, but that happened and I don't know how to avoid that to happen again
<lifeless> Ursinha: 11566=X, 11567=Y,11568=Z
<lifeless> lets say that Z fixes X
<lifeless> if we use a bug, as you say, then X and Z can be qa-ok on the same bug
<lifeless> but Y may be qa-needstesting
<Ursinha> lifeless, that's fine, but the special case of 11566 it's not bad, just incomplete
<lifeless> if X is qa-ok then the rules say it can be deployed, but it can't, we have to deploy nothing, or X+Y+Z
<Ursinha> both are part of the same bug fix
<lifeless> Ursinha: its bad unless its complete.
<lifeless> Ursinha: because it will break the buildmaster.
<Ursinha> lifeless, but it will break anyway, because it will land in edge
<Ursinha> that's the QA instance
<lifeless> Ursinha: edge doesn't [yet] deploy to the buildmaster
<Ursinha> ah
<Ursinha> but that's not my point
<lifeless> for qastaging, it would break yes.
<Ursinha> that's the point
<lifeless> or whatever tom is going to call the domain.
<lifeless> as long as we do exercise soyuz there.
<Ursinha> thing I want to say is that's not bad, but qa-needstesting that cannot be tested without the second part
<Ursinha> or hm well
<Ursinha> that's bad because it landed in the first place, so it should be rolled back...
<lifeless> yes, but what if the rollback just contains the fix.
<Ursinha> lifeless, in this special case the fix is the other part, right?
<lifeless> from the deployment story its identical. X on its own = boom, X+Z together = ok.
<lifeless> Ursinha: yes.
<Ursinha> so keeping the branch qa-needstesting would block it from deployment, right?
<Ursinha> branch no, bug
<lifeless> as will bad-commit-xxxxxx
<Ursinha> but why use that
<lifeless> which I think is accurate.
<lifeless> because it is a bad commit, all commits are -meant- to keep trunk stable
<Ursinha> it's because it's not just a partial fix, but it's breaking stuff?
<lifeless> right
<Ursinha> I see
<lifeless> its not incremental
<lifeless> its damaged without its soul mate
<Ursinha> it's bad
<Ursinha> nothing much special about it, just bad
<Ursinha> break stuff, should not be there
<lifeless> I'm proposing a pqm commit messag elike fixcommit=12345 to handle roll-forward rathr than rollback
<lifeless> Ursinha: yes, it shouldn't have happened, but we need to deal when it does
<lifeless> the only difference fixcommit and rollback would have is:
<Ursinha> lifeless, I'm thinking out loud to check if I make sense
<lifeless> rollback tags in-progress again, fixcommit doesn't change the bug 'status' field.
<Ursinha> hm
<Ursinha> so we'd need to say that it not just is a rollback but a fix itself
<lifeless> yes
<wgrant> mwhudson: How's python2.6 going?
<mwhudson> wgrant: it seems to be running the tests
<wgrant> Aha.
<mwhudson> https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.6-5ubuntu1/+build/1961090 -> (took 3 hours, 35 minutes, 1.1 seconds)
<mwhudson> been going for close to 2 on my board, so a while yet, i expect
<wgrant> Hm, the xM looks rather nice.
<mwhudson> wgrant: o
<mwhudson> bah
<mwhudson> wgrant: i've been blogging about it! http://voices.canonical.com/michael.hudson/
<wgrant> I may have to acquire one. My previous ARM board is now acting as the home servery/routery thing, so I need something to experiment on.
<lifeless> anyone know the status of 'mentoring'
<mwhudson> lifeless: i think it's "kill code on sight", not 100% sure though
<wgrant> "Under trial withdrawal" is the official status.
<wgrant> Removed from the UI and condemned, but code not yet deleted.
<wgrant> Although the reference to it in the feature listing seems to have now been entirely removed.
<lifeless> and it causes extra queries.
<lifeless> le sigh
<lifeless> thumper: I think its better to do this via a garbo patch:
<lifeless>  - gets rid of the interrupt on spm
<lifeless>  - long term solution
<thumper> lifeless: yes, so you have said multiple times already
<lifeless>  - same basic code as we'd be cowboying, but tested
<thumper> and it will be
<lifeless> thumper: I've been thinking more about it
<lifeless> thumper: that was summary; nuff said.
<lifeless> oh, and man echannel too.
 * lifeless hides in shame
<spm> chuckles
 * thumper code dives
<lifeless> zomg
<lifeless> the celebrity code queries every time ...
<wgrant> I thought it cached IDs.
<wgrant> That's how you can get MutatedCelebrityErrors.
<lifeless> now when you do ).admin
<lifeless> or perhaps my test is just catching the cache loading
<lifeless> still
<lifeless> ECRY
<wgrant> It will have to load the object if it's not in the cache.
<wgrant> But I believe it's meant to cache the ID over transactions.
<Ursinha> lifeless, https://devpad.canonical.com/~lpqateam/qa_reports/logs/
<Ursinha> I've changed them all to a separate folder
<lifeless> thanks for letting me know
<wgrant> I wonder how badly LP breaks on pg 9.0.
<lifeless> mwhudson: LaunchBag is spectacularly ugly
<mwhudson> lifeless: yes
<lifeless> silly question
<lifeless> is it ok to have __init__ on SQLBase classes
<lifeless> or .. ah _init?
<Ursinha> I'm done for today
<Ursinha-zzz> lifeless, could you please file a bug for the fixes-xxxxx problem?
<lifeless> Ursinha-zzz: go sleep
<lifeless> :)
 * thumper goes offline briefly while IRC proxy goes to maverick
<lifeless> I'm making progress
<lifeless> viewing a single bug page with no subscribers is now down to 99 queries.
<lifeless> !
<poolie> from where?
<lifeless> 110 when I started this branch
<wgrant> lifeless: How many comments/tasks?
<lifeless> wgrant: 1/1
<wgrant> ..... ew.
<lifeless> wgrant: I took my view scaling test (14 queries), made it render...
<lifeless> and blinked.
<poolie> i was thinking this morning about the idea of giving sql planner logs back to the client
<poolie> and it occurred to me that giving them to the web app (to put in an oops) would be nice but isn't strictly necessary
<poolie> *if* it turns out that logging them is not noticeably expensive, perhaps we could log them all the time and just make them available on devpad
<lifeless> we have detailed logging off on the master due to load.
<poolie> it does show up?
<lifeless> Have I done the numbers myself ? no. Ask stub :P
<lifeless> I presume its turned off because someone measured.
<poolie> i believe you, i'm just curious
<poolie> just thought it would be nice to cut out the roundtrips to get this
<lifeless> anyhow, I'd expect query plan serialisation to be similar overhead: totally fine from time to time but significant if on all the time
<lifeless> poolie: personally, ignoring performance, I'd rather have it in the oops.
<lifeless> nicely interleaved with the queries.
<lifeless> rather than in a separate file i have to go read
<poolie> i agree
<poolie> i was just thinking it would be less work to record it to a log
<lifeless> have a look at requesttimeline
<lifeless> its nice
<lifeless> shove it in there, it turns up in the oops, bada boom bada bing
<poolie> where is it?
<lifeless> lp.services.timeline
<poolie> ok, thanks
<lifeless> hmm, we query the tags for the js fragment twice... sigh
<lifeless> no, something else
<poolie> wgrant: if you're free could you do a security-oriented review of https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
<lifeless> nah, he charges ;P
<poolie> lifeless: could you please land https://code.edge.launchpad.net/~mbp/launchpad/flags-webapp/+merge/32967 for me
<wgrant> Let's see.
<wgrant> +            canonicalise_line_endings(mail.signedContent), signature)
<wgrant> WTF
<wgrant> mixedCase attributes?
<wgrant> Must be old code.
<poolie> not my fault
<wgrant> I know.
<wgrant> Makes me cringe anyway :)
<poolie> what is the standard meant to be? underscored attributes, camelcase methods?
<wgrant> Right.
<wgrant> PEP-8 with a pinch of Zope.
<poolie> urk
<poolie> biab
<lifeless> is bugtask.distribution always set when bugtask.sourcepackagename is ?
<lifeless> hmm
<wgrant> I hope so.
<lifeless> actually
<lifeless> it never is
 * lifeless suspect official bug tag adaption mojo
<wgrant> Er.
<wgrant> What?
<wgrant> sourcepackagename on its own is useless.
<wgrant> distribution and distroseries should be mutually exclusive.
<wgrant> But sourcepackagename should always have one of those two, although it's not enforced by the DB.
<lifeless> it is
<lifeless> CONSTRAINT bugtask_assignment_checks
<wgrant> Ah, true.
<thumper> AssertionError: not equal:
<thumper> a = set([u'revision-id319180', u'revision-id319182', u'revision-id319184', u'revision-id319186', u'revision-id319188', u'revision-id319198', u'revision-id319196', u'revision-id319194', u'revision-id319192', u'revision-id319190'])
<thumper> b = set([u'revision-id319180', u'revision-id319182', u'revision-id319184', u'revision-id319186', u'revision-id319188', u'revision-id319198', u'revision-id319196', u'revision-id319194', u'revision-id319192', u'revision-id319190'])
<thumper> is it me or is that crackful?
<lifeless> are those actually strings or storm objects with pretty reprs?
<thumper> lifeless: good point
 * thumper double-checks
<wgrant> s/pretty/shocking/
<thumper> it says unicode
<wgrant> It's not assertIs?
<thumper> assertEqual
<wgrant> Bah.
<lifeless> wgrant: != - assertEqual in testtools prints out like that
<lifeless> thumper: yes, thats cracked.
<thumper> a == b in the python interpreter
<stub> So the repr is bogus
<mwhudson> woo python2.6 built on the beagle xm
<mwhudson> took 4 hours, 53 minutes, 23.1 seconds
<mwhudson> so a bit slower than the official buildd
<wgrant> So not too slow.
<mwhudson> not too shabby though
<mwhudson> given that you can buy xm's by the crate now
<wgrant> Is the buildd hardware publicly available yet?
<wgrant> mwhudson: They're actually on backorder pretty much everywhere.
<mwhudson> you mean, the details of what it is?
<wgrant> But yes.
<wgrant> No, the actual devices.
<wgrant> For a while the buildds were unreleased hardware.
<thumper> lifeless: http://pastebin.ubuntu.com/497480/
<thumper> lifeless: I'm in the pdb session
<mwhudson> wgrant: ok, well linaro has about 40 or something now
<mwhudson> maybe not that many
<mwhudson> but >10 anyway
<mwhudson> wgrant: eh, the buildds are some kind of fancy dev board i think, i'm not sure that it's ever going to be publicly available in the sense of being able to just pony up a credit card number and buy one
<mwhudson> icbw though
<mwhudson> thumper: wth!
<mwhudson> (Pdb) print list(expected) == list(observed)
<mwhudson> True
<mwhudson> (Pdb) expected == observed
<mwhudson> False
<mwhudson> thumper: types of the set classes?
<mwhudson> print type(expected) == type(observed)
<lifeless> one of these is not like the other
<wgrant> Maybe it's security proxied.
<wgrant> But that should normally be fine.
<wgrant> Unless set has some horrible optimisation.
 * wgrant throws Django's URL system into the "cruel joke" bin.
<mwhudson> if observed is proxied, i bet observed == expected would be true
<thumper> (Pdb) print type(expected) == type(observed)
<thumper> True
<wgrant> ...
<lifeless> print type(expected), type(observed)
<wgrant> Are they both actually sets?
<wgrant> That.
<mwhudson> ok
<mwhudson> starting to think weird ass bugs now
<thumper> fucking proxies
<mwhudson> ah
<wgrant> They're both proxied?
 * lifeless chalks another one up to 'lets remove the proxies'
<stub> That shouldn't mess with == :-/
<thumper> yes, both proxies
<thumper> stub: they are both proxied sets
<stub> Yes, but the wrappers are supposed to be transparent to pretty much everything (everything but 'is' / 'is not' IIRC)
<thumper> stub: probably the testtools implementation of assertEquals
<lifeless> rockstar: you forgot the link
<wgrant> No, == says they're not equal.
<wgrant> It's nothing to do with testtools.
<thumper> wgrant: good point
<wgrant>     def __eq__(self, other):
<wgrant>         if isinstance(other, BaseSet):
<wgrant>             return self._data == other._data
<wgrant>         else:
<wgrant>             return False
<wgrant> But surely the proxies are smarter than that.
<rockstar> lifeless, ?
<mwhudson> wgrant: return **False** !
<mwhudson> surely that should be NotImplemented
<mwhudson> unless comparison is different
<wgrant> Hm. Except that's sets.Set, which is not set.
<wgrant> Now, where is set...
<mwhudson> wgrant: Modules/setsmodule.c
<wgrant> Oh.
<rockstar> lifeless, ah, I see.
 * rockstar _should_ go to bed.
<wgrant> I was looking at setobject
<wgrant> mwhudson: I have no setsmodule.c
<mwhudson> oh right
<mwhudson> yes setobject
<mwhudson> sorry
<lifeless> grah
<lifeless> so, if I've added an attribute to the Interface
<lifeless> how do I specify access permissions for it ?
<thumper> lifeless: it depends
<lifeless> ForbiddenAttribute: ('official_tags', <Bug at 0xef872d0>)
<thumper> lifeless: on how the interface itself has the permissions set
<wgrant> mwhudson: Looks like it has the same bug as the Python one.
<lifeless> official_tags = Attribute("The official bug tags relevant to this bug.")
<wgrant> It does the type check and returns false, rather than NotImplemented like makes sense, and others seems to do.
<wgrant> lifeless: Bug doesn't use interfaces for security.
<wgrant> It lists the attributes in ZCML.
<lifeless> siiiiiiigh
<thumper> lifeless: lib/lp/bugs/configure.zcml line 574ish
<thumper> lifeless: also that file has lots of references to canonical.launchpad.database.*
<thumper> lifeless: which it shouldn't
<lifeless> thats so bong
<wgrant> sinzui: Why are maps dying?
 * thumper rings lifeless's bong
<thumper> wgrant: cost is one reason
<lifeless> wgrant: they want lots of money to serve on ssl
<thumper> wgrant: and they changed the api
<wgrant> Yay.
<lifeless> thumper: to be fair, thats orthogonal
<lifeless> the primary problem was our account expired.
<thumper> yeah, it is
<lifeless> ohhhh
<lifeless> TypeError: [] is not JSON serializable
<wgrant> Um.
 * lifeless is not sure if a practical joke is being played or not
<wgrant> What?
<lifeless> ooooh
<lifeless> I bet I know
<wgrant> Proxies?
<lifeless> the list is security proxied
<wgrant> Heh.
<lifeless> so the browser code which was doing a redundant sorted(list( <- and yes thats also self redundant
<lifeless> was hiding that
<wgrant> Is this still BugTask:+index?
<lifeless> yes
<lifeless> will save, about 40 queries on bug 1
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<lifeless> its got waay to many bugtasks.
<poolie> wgrant: any other comments on that patch?
<wgrant> poolie: That getUtility(ILaunchpadBag).to_user looks like a sed gone wrong.
<lifeless> yay, finally, squashed that one.
<mwhudson> lifeless: work on deleting a bug task next? :-)
<poolie> i could make it more testable by tearing apart the methods more
<lifeless> mwhudson: nah, I'm going to defeat this foul beast.
<poolie> but i anticipate an uncomfortable interval where the patch gets bigger but the tests don't get safer
<lifeless> of course, the patch is going to be a) ugly and b) insufficiently tested.
<lifeless> But
<wgrant> poolie: Apart from that it looks OK. But the code needs refactoring.
<lifeless> It has the only test I care about right now: query scaling :)
<poolie> ah you're right about the '.to_user' well spotted
<poolie> i think my next refactoring would be to separate "determine who this comes from and how strongly they're trusted" from "become that user"
<poolie> cleaner to test that way i think
<wgrant> poolie: That suggests a missing test.
<wgrant> Or you just didn't find it.
<poolie> it does, doesn't it
<wgrant> Hm.
<lifeless> is there a debug mode to tal?
<wgrant> I wonder if the LP favicon should be that of the current context.
<poolie> i didn't run everything but i ran 'bin/test mail' which you'd think would catch it
<lifeless> that is, to print the thing being evaluated?
<lifeless> or similar
<poolie> i think it is a missing test and i could add one
<poolie> and see if it would have trapped on that line
<lifeless> down to 88
<poolie> lifeless, wgrant, how about something like http://pastebin.ubuntu.com/497509/ as a test?
<lifeless> seems fine to me; lines 8,9 and 10 look like they will want to be reusable
<poolie> mm
<poolie> a lot of it should be
<wgrant> maxb: Is python-debian really still needed in the PPA? It's in sourcecode now.
<poolie> wgrant i'm pretty sure there was no test for mail to help@ but there is one now
<wgrant> poolie: Great.
<poolie> can you two help me decide whether to add more tests to this or just leave it?
<poolie> i don't want to break incoming mail but i also want to leave this and work on something else
<lifeless> poolie: how big is the change? is it flag controllable? that would make it easy to back out.
<poolie> it's https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
<lifeless> poolie: For refactoring I tend to remove all but one old-place test, and move them to the new place, and not try to add coverage
<poolie> it's not flag controllable atm and it's refactoring code that seems poorly tested at the moment
<poolie> thus my discomfort
<wgrant> It's also rather ancient code.
<lifeless> poolie: do you think it needs more tests?
<poolie> in general, yes, it does
<poolie> does it need me to add them right now? i hope not :)
<lifeless> poolie: to be comfortable landing this change I mean?
<poolie> i don't know
<poolie> i have a sinking feeling that to be able to test it more i'll have to change more stuff
<lifeless> so
<lifeless> stop
<lifeless> land it, qa on staging, rather than edge, done.
<poolie> in particular, to make it have less side effects
<poolie> fair enough
<poolie> staging receives mail, even thought it doesn't send it?
<poolie> and we can now see the mail logs from it, or we should be able to
<lifeless> it should be able to yes
<lifeless> if not, I'll RT that :P
<poolie> i replied to the rt asking for logs from staging too
<poolie> they don't seem to be visible atm
<lifeless> 84
<poolie> ok, so with that off the plate i'll look at a flags editor
<lifeless> \o/
<lifeless> you wanted a chat with wallyworld
<lifeless> I'm up for that nowish
<poolie> is he?
<poolie> <hold music>
<wallyworld> dah de dah dah de dah
<poolie> wallyworld, lifeless: mumble/skype/pots?
<wallyworld> skype is ok for me
<wallyworld> i don't have any specific agenda
<wallyworld> some of my random musings have already been aired in the mailing list
<lifeless> poolie: skype plox
<lifeless> 76
<lifeless> 74
<wgrant> It's a countdown!
<wgrant> But to what?
<lifeless> sob
<lifeless> return list(MilestoneVocabulary(self.context)) != []
<wgrant> Bwahah.
<wgrant> At least it is scoped.
<lifeless> guess how many milestones bug 1 has
<lifeless> ...
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<wgrant> Why's it doing that? To work out whether to display the milestone selector?
<lifeless> wgrant: yes
<wgrant> Yay.
<lifeless> browser/bugtask.py 3632
<bigjools> jeez, someone added 200 builds this morning
<lifeless> buildds?
<wgrant> jml: Are you going to get that BuilderSlave.clean thing merged?
<bigjools> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20100920/20100922/
<jml> doo-di-dee-dooo, doo-di-dee-do, doo-di-dee-dooo, doo-di-dee-do-do-di, doo-do-de-doo doo-de-de-do-do-do-do-dooo...
<jml> IT's THE FINAL COUNTDOWN!
<bigjools> THE FINAL SOL^WCOUNTDOWN
<adeuring> good morning
<jml> wgrant, yes, I'm going to do that next thing.
<wgrant> lifeless: My religion forbids me from opening a file that large.
<wgrant> jml: Great, thanks. Everything seems to work well with that fixed.
<bigjools> wgrant: bug 644059
<_mup_> Bug #644059: buildd upload processor explodes if source produced by binary build <Soyuz:New> <https://launchpad.net/bugs/644059>
<bigjools> can you write that in English? :)
<wgrant> bigjools: Description updated.
<bigjools> grassy ass
<wgrant> Heh.
<jml> wgrant, how did mwhudson trigger the bug in first place? it would be nice to have some kind of test for that.
<jml> as well as a direct one for clean.
<wgrant> jml: I triggered it too.
<wgrant> Let me check my logs.
<jml> no matter
<jml> bigjools has just given me a few pointers
<jml> mrevell, hello
<bigjools> wgrant: was it getting called from rescueBuilderIfLost ?
<wgrant> bigjools: No, updateBuild.
<bigjools> ok
<wgrant> Although rescueBuilderIfLost probably had the same issue.
<mrevell> Hello
<bigjools> yes
<bigjools> hey mrevell
<wgrant> We also sometimes get into a situation where a BuilderSlave is used during dispatch to.
<wgrant> NFI how.
<jml> if all goes well, that won't matter at the end of the week.
<wgrant> Indeed.
<wgrant> Although I wonder how much of a performance boost it will be.
<jml> I would like someone to review this please: https://code.edge.launchpad.net/~jml/launchpad/split-mail-and-summary/+merge/36111
<jml> wgrant, probably not much.
<jml> wgrant, the sanity boost is not to be sneezed at
<wgrant> That's true.
<jml> bigjools, you might be interested in this bug: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419685
<_mup_> Bug #419685: Buildbot sends emails that require no action <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419685>
<lifeless> sigh
<lifeless> the per row stuff here is still going to be terrible.
<jml> It's such a good branch.
<lifeless> jml: ask me how many queries viewing a trivial bug page with no subscribers, 2 product tasks takes.
<jml> lifeless, I've been wondering, ...
<lifeless> 110
<jml> lifeless, :(
<lifeless> jml: I got pissed off enough this morning
<lifeless> that I'm doing something about it
<lifeless> I'm down to 72
<jml> lifeless, woot!
<lifeless> 1 15 files changed, 157 insertions(+), 86 deletions(-)
<jml> !
<lifeless> jml: I may want a very pragmatic review for this :P
<jml> lifeless, ok. :)
<jml> lifeless, swap you.
<lifeless> sure, what up
<jml> https://code.edge.launchpad.net/~jml/launchpad/split-mail-and-summary/+merge/36111
<jml> better mail from ec2
<StevenK> \o/
<lifeless> done
<lifeless> 68
<jml> lifeless, thanks.
<jml> (also, wuuu)
<wgrant> lifeless: I suppose it also now scales better?
<bigjools> have you seen how many HTTP requests there are for a bug page with a cold browser cache?
<wgrant> What are they all?
<wgrant> I can't think of too many.
<bigjools> try it in .dev
<wgrant> .dev is special.
<wgrant> The JS isn't merged, is it?
<bigjools> ummm I dunno
<bigjools> anyway
 * bigjools -> sprint
<lifeless> wgrant: somewhat
<lifeless> wgrant: I haven't reached the last query yet.
<lifeless> it will still do 4 queries per nomination.
<wgrant> :(
<wgrant> lifeless: Was your mass-CP rolled out everywhere?
<wgrant> Even Soyuz?
<lifeless> checkwatches + appservers
<lifeless> not quite everywhere
<lifeless> AIUI
<lifeless> there was a singular CP done at the same time
<wgrant> Looks like it did make it to cocoplum anyway.
 * lifeless headdesks
<lifeless> SELECT COUNT(*) FROM Bug WHERE Bug.duplicateof = %s
<wgrant> Hmm?
<bigjools> ummm that's bad if you updated cocoplum
<wgrant> bigjools: Why?
<wgrant> The buildd-manager thing wasn't in the last batch.
<bigjools> if the b-m change made it there
<bigjools> ah ok
<bigjools> *phew*
<wgrant> And b-m is OK now, anyway.
<bigjools> well no, it needs a cronjob
<wgrant> Just needs the extra cron job set up before the next CP.
<wgrant> Right.
<lifeless> wgrant: we have a denormalised field to avoid that particular query
<lifeless> wgrant: ...
<wgrant> Hah, so we do.
<wgrant> It shouldn't be too slow, though.
<lifeless> wgrant: hah
<lifeless> wgrant: hah
<lifeless> wgrant: hah
<wgrant> Really?
<lifeless> count(*) is one of the slower operations you can do
<wgrant> No bug ever has more than a few hundred.
<wgrant> So there's not a huge number of rows to go through.
<lifeless> wgrant: right, but it still requires a index operation that is not significantly cheaper than select..
<wgrant> Yeah.
<lifeless> AND WE HAVE THE NUMBER RIGHT THERE.
<lifeless> (emphasis mine)
<lifeless> 66
<lifeless> wgrant: hey, guess how bug privacy duplicates interact
<wgrant> Badly?
<lifeless> well, and I'm just guess
<lifeless> ing
<lifeless> one query per private dupe
<lifeless> maybe 2
<wgrant> Only 1?
<wgrant> Yeah...
<lifeless> guess what happens when apport backlogs
<lifeless> <fun>
<jml> have those windmill failures been addressed?
<lifeless> not that I know of
<lifeless> mars says he's oging to look at bb soon
<lifeless> also \u/ for duplicate methods that do exactly the same thing
<lifeless> personIsDirectSubscriber == isSubscribed
<lifeless> 64
<jml> lifeless, hey, your fixture thing is an lp dep?
<lifeless> jml: yes
<jml> lifeless, ok. should we deprecate the lp.testing.fixtures business?
<lifeless> jml: its mostly moved over to context managers already; I moved fakelibrarian
<lifeless> there's one use remaining I think.
<jml> lifeless, looking at lp.testing.fixtures, it's not using ctxmgrs at all
<lifeless> I may be confused. ELate+BugTask:+index is consuming me
<lifeless> 63
<wgrant> 8 to go!
<jml> lifeless, fixtures... sourcedeps, package or eggs?
<jml> (cos it ain't working)
<lifeless> jml: its in the dist-cache
<jml> dist-cache
<lifeless> jml: versions.cfg etc
<lifeless> downloadcache/dists
<jml> ahh, thanks.
<lifeless> jml: works for me; check the fake librarian
<lifeless> you may have an old  branch?
<jml> lifeless, I don't see *anything* that imports 'fixtures'
<jml> lifeless, the branch is current as of Monday morning.
<lifeless> lib/lp/testing/fakelibrarian.py
<lifeless> line 22
<lifeless>  16 files changed, 197 insertions(+), 122 deletions(-)
<jml> lifeless, thanks. merging in latest stable gets it.
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/bugtask+index/+merge/36117
<lifeless> noodles775: ping
<noodles775> Hi lifeless
<lifeless> hiya
<lifeless> so you've got a branch called 'expose distro diff' or thereabouts
<noodles775> YEs
<lifeless> I wanted to check that you're happy for that to happen on lpnet, *now* (in principle)
<lifeless> and that you're not basing it on 'this release cycle'
<noodles775> erm, It's for db-devel?
<lifeless> noodles775: ah, I didn't see that :P
<noodles775> I mighht not have set it...
<lifeless> safe enough then (though personally I'd still use a flag, in case you find a bug at the last minute or post release and want to pull the feature)
<wgrant> Is the API flaggable?
<lifeless> should be
<lifeless> same request object IIRC
<lifeless> you can't change whats exported
<wgrant> True.
<noodles775> I've flagged the UI, but didn't see it as necessary to flag the API for it (since there will not be any data to access).
<lifeless> but you can control what it does
<lifeless> I would't stress about the API
<wgrant> I still don't see how the current derivation model can work.
<wgrant> But I guess we'll see.
<noodles775> wgrant: in what way?
<wgrant> noodles775: We need multiple parents.
<lifeless> jml: I got that branch exactly the right size it seems (800 lines)
<wgrant> Changing parent_series after initialisation will break a few things and seems a bit ew.
<noodles775> wgrant: ah, right. AFAIK multiple parents was discussed by bigjools-afk with others, but not included in the initial release. I don't know the details.
<lifeless> jml: its getting late, so I'd like to know if you're going to look now, or later.
<jml> lifeless, am looking now
<jml> lifeless, is MilestoneTarget.has_milestone a property?
<lifeless> yes
<jml> ta
<lifeless> if you mean has_milestones
<lifeless> its about a brazillion times faster than the vocab
<jml> lifeless, yeah.
<jml> lifeless, I've approved modulo some clarity/style tweaks.
<jml> lifeless, great patch. thanks.
<lifeless> thanks
<noodles775> Has anyone seen "psycopg2.ProgrammingError: server closed the connection unexpectedly" when running `make schema`? http://pastebin.ubuntu.com/497604/
<lifeless> jml: dumps(security_proxied_list) goes boom
<lifeless> jml: thats why the comment; I've expanded it.
<jml> lifeless, thanks.
<wgrant> noodles775: I haven't seen that. Does the postgres log say anything useful?
<lifeless> jml: also I mean 'tp' query - 'tp = ' is 4 lines up.
<noodles775> wgrant: yes - I should have checked there first. FATAL:  the database system is in recovery mode
<wgrant> Aha.
<jml> lifeless, heh. ok.
<lifeless> noodles775: nuke your db
<lifeless> noodles775: and start over; its the easiest way
<noodles775> k, thanks lifeless, wgrant
<lifeless> gmb: did you talk to the mozilla folk
<gmb> lifeless, Can you be more specific? I might have missed something whilst sifting through my mail pile yesterday
<gmb> lifeless, Ah
<gmb> https://bugs.edge.launchpad.net/malone/+bug/642418 you mean?
<_mup_> Bug #642418: Detect when remote Bugzilla bugs are duplicates and link to the duped-to bug instead <Launchpad Bugs:New> <https://launchpad.net/bugs/642418>
<gmb> lifeless, Exactly to whom should I be talking and what needs to be said?
<lifeless> $folk and $mozilla that are $concerned
<lifeless> I dunno
<gmb> lifeless, That's $unhelpful.
<lifeless> I just got told you knew all about this stuff :)
<lifeless> so I helpfully palmed the enquirers off with yourname and a glib assertion that you'd be helpful/
<gmb> Haha.
<lifeless> poolie: would appreciate any insight you have into https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342
<gmb> Helpful doesn't start until this afternoon.
<_mup_> Bug #634342: need a features 'scope' for page ids <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342>
<gmb> lifeless, I know the code, at least. Let me dig further into this. I'll add it to my todo list for today.
<deryck> Morning, all.
<lifeless> hmm, clearly I'm up too late.
<spiv> lifeless: yes
<lifeless> gary_poster: you're around now, I take it ?
<gary_poster> lifeless, yes on call but what are you doing up?!
<lifeless> well, I had a itsy bitsy morning
<lifeless> and then I got my teeth into BugTask:+index
<lifeless> still winding down from that ;)
<lifeless> gary_poster: when do you think you'll be off the call?
<gary_poster> 10 min?
<lifeless> hmmm, if you're up for a catch up post that, I might hang about a little more
<gary_poster> lifeless, you are crazy, but I am off the call and available for ~20 min.  mumble, irc, skype...?
<lifeless> like a fox
<gary_poster> :-)
<lifeless> lets say skype
<gary_poster> ok
<lifeless> rbtcollins
<wgrant> We really need to work out a better bug notification strategy.
<wgrant> Since my top timeout is probably mostly that :(
<deryck> wgrant, completely agree
<wgrant> I wonder if it's as easy as removing BugNotificationRecipient and calculating it when we send them.
<wgrant> Or if that will miss some things (like bugs being reassigned)
<deryck> I think it could be more complex than that, but it's an easy check to remove it and run tests to see what breaks.
<wgrant> Yeah, it's not that simple, sadly.
<wgrant> Since the recipients can change if the task target does, and the existing code will notify the old recipients as well.
<deryck> right
<deryck> we will have to deal with this notification overhead sooner rather than later, though.
<deryck> So someone from the bugs team will look at this in the short term.  if you don't beat us to it, wgrant. ;)
<wgrant> It makes kernel bugs just about impossible to file.
 * gmb lunches
<leonardr> sinzui, when you come in, i'm getting an incomprehensible error message when i ec2 my branch, but not when i run the test locally:
<leonardr> http://pastebin.ubuntu.com/497660/
<wgrant> Uhoh.
<wgrant> Not this again :(
<mars> wgrant, ?
<wgrant> It's the off-by-one OOPS ID thing.
<mars> is there a bug for it?
<wgrant> I forget.
<lifeless> try it with https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
<lifeless> gnight
<wgrant> Night lifeless.
<mars> I can't find a bug for it
<bigjools-afk> mmmm
<bigjools> jml just munched on two faggots for the first time and loved it
<StevenK> mars: Hey, did you get my e-mail?
<gmb> Ursinha, ping
<Ursinha> gmb, hi
<gmb> Ursinha, Howdy. So, I keep getting the "Please try again" page when I try to delete this bugwatch: https://bugs.edge.launchpad.net/bugs/642418/+watch/81562/+edit
<_mup_> Bug #642418: Detect when remote Bugzilla bugs are duplicates and link to the duped-to bug instead <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/642418>
<Ursinha> what my script did wrong
<Ursinha> :)
<Ursinha> ah
<gmb> Ursinha, I don't know why it's not getting an OOPS raised, but do you know where I might be able to look to see if one's been raised but isn't showing up in the UI?
<gmb> I'm kinda clutching at straws here, by the way :)
<Ursinha> gmb, all oopses are on devpad, let me take a look
<gmb> Ursinha, Thanks.
<gmb> R%^&QGÂ£YUEHIUDJHIUFHIWUE!!!!!
<gmb> You have *got* to be kidding me.
<gmb> We add the "bug watch foo has been deleted" notification before we delete the bugwatch.
<wgrant> What gets really amusing is when transaction retries come into play.
<wgrant> So you end up with lots and lots of notifications.
<gmb> wgrant, Indeed. As I just discovered.
 * gmb branches and fixes. That one's not hanging around.
<Ursinha> gmb, I can't find oopses on devpad
<Ursinha> they're synced every 10 minutes, so I guess should be there already
<Ursinha> but I can't find anything grepping them
<gmb> Ursinha, Thanks. I've found (possibly) a separate problem (see my rant above).
<Ursinha> hehe, np
<gmb> Ursinha, I'll grep later.
<rockstar> gmb, I need to reboot, but then I'd like to chat about the wizard widget.
<gmb> rockstar, Sure. thing.
<gmb> Er. Sure thing.
<gmb> rockstar, I'm ready whenever you are.
<nigelb> lifeless: I like the stump speech ;)
<mars> leonardr, you missed this fix for your EC2 issue: https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
<mars> StevenK, yes, I got it.  Have been working on other things, will get back to mainline build engineer work this week.
<leonardr> mars: is it landed?
<mars> leonardr, I don't think so.  Robert said to merge it into yours and then try again.
<leonardr> mars: i see
<bac> has anyone seen basic auth challenges popping up when running windmill, e.g. http://people.canonical.com/~bac/Screenshot-Authentication%20Required.png
<bac> they don't seem to interfere with the tests but are annoying
<mars> bac, yes, a known problem since the summer.  Did this just start now?
<bac> mars: yeah
<bac> mars: just ignore it?
<mars> bac, did you just upgrade to Maverick?
<bac> mars: last week, yes
<mars> bac, so it could be a problem with the test harness under Maverick, or it could be bug 609190
<_mup_> Bug #609190: Login problem in windmill test <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/609190>
<bac> mars: thanks
<mars> bac, try '$ bin/test lp.translations.windmill.tests.test_import_queue', see if that fails
<mars> if so, then it is systemic
<mars> if not, then it is an issue introduced by new code
<henninge> Which style is the right style for headings in doctest? I for get ..
<bac> mars the translations test did throw up a bunch of those auth windows but proceeded without error
<henninge> == Heading ==
<henninge> or
<henninge> Heading
<henninge> =======
<bac> henninge: latter
<henninge> cheers bac ;)
<bac> henninge: some do
<bac> ======
<bac> Heading
<bac> =========
<bac> which seems to be ok unless gmb is your reviewer.  :)
<henninge> :)
<bac> (but only for the first)
<henninge> I was about to ask that ...
<mars> bac, ok, noted.  I can check after I do the Maverick upgrade myself.  Was this a fresh system install?
<gmb> Oi!
<bac> mars: yes
<danilos> bigjools, hi, if I was to take on bug 644464, what would be the best approach?
<_mup_> Bug #644464: Template generation jobs are not aggregated <Launchpad Translations:Triaged> <https://launchpad.net/bugs/644464>
<mars> henninge, danilos, any idea what is up with the latest buildbot failure?  It died in  canonical.buildd.tests.test_translationtemplatesbuildmanager.TestTranslationTemplatesBuildManagerIteration.test_iterate_fail_GENERATE
<mars> henninge, danilos, https://lpbuildbot.canonical.com/builders/lucid_lp/builds/171/steps/shell_7/logs/summary
<danilos> mars, hum, no, let me take a look
<bigjools> danilos: you need to see if a job already exists for the same context; I don't know the best way of doing that for TTBJs
<mars> henninge, danilos, nevermind, misread.  It failed in "Error in test lp.buildmaster.tests.test_builder.TestSlave.test_clean", not the translations stuff.
<danilos> bigjools, well, I know that much :), I was asking more along the lines of where do you do that for other jobs in soyuz, and if it would be a good thing to do it at the same time?
<bigjools> danilos: for soyuz, we allow it, but we detect a more recent version and supersede the old build request instead of dispatching it
<bigjools> danilos: but I am worried that you had *so many* requests all queued up
<danilos> bigjools, well, we don't have a limit per project yet, but we probably could add that too
<bigjools> I think it's a good idea
<mars> bigjools, when you are finished talking to Danilo, buildbot died with 'Error in test lp.buildmaster.tests.test_builder.TestSlave.test_clean' - are you the right person to handle that?
<danilos> bigjools, anyway, dispatch time is probably the best time if we want to aim for minimum amount of repeated work
<bigjools> mars: jml is working on it right now
<bigjools> it's a test we added recently and then promptly broke
<mars> bigjools, thanks.  jml, could you please send a message to the list about it?
<jml> what.
<jml> mars, yes, of course
<mars> thank you
<bigjools> danilos: I would address it on both fronts
<danilos> bigjools, well, if I address it on one (considering we are always getting tip of the branch, I can put that limit at 2 which would avoid all the concurrency issues)
<danilos> bigjools, I don't see much need for addressing on the other... and vice versa
<danilos> bigjools, btw, what was the number of builds that we had scheduled?
<bigjools> danilos: ok, I'm no so familar with the dynamics of how and when you generate the jobs so I trust whatever you say
<danilos> bigjools, good :)
<danilos> bigjools, or not so good, but anyway :)
<bigjools> :)
<bigjools> danilos: I don't know how many were scheduled
<bigjools> but, one sec
<danilos> bigjools, I see we did at least 360 for software-center
<bigjools> !
<danilos> bigjools, in one day :(
<bigjools> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20100921/20100923/
<bigjools> ummm
<danilos> bigjools, it definitely sounds as if something was wrong elsewhere as well
<bigjools> I expect someone uploaded a bunch of stuff, somewhere
<danilos> bigjools, because that particular branch only had 9 commits on 21st (when it did 360 template build jobs)
<bigjools> danilos: that's.... special
<danilos> bigjools, yeah, so somewhere on the code side we generated a bunch of duplicated jobs needlessly
<danilos> bigjools, so, I'd like to investigate this a bit, and will end up limiting the number of entries in the table per project to 2 anyway, but would like to check out why is this happening in the first place
<danilos> bigjools, or perhaps we are retrying them for some reason? under what conditions does build-manager retry a build (just so I can check we are not causing it to do that)?
<bigjools> danilos: that's down to the behaviour class for templates
<bigjools> the b-m just picks the next item from the queue and dispatches it
<danilos> bigjools, ok, since we haven't implemented that, we should not worry about it
<danilos> bigjools, thanks, useful input, I'll go dive into code a bit
<bigjools> danilos: np
<bigjools> danilos: can you kill off all the unnecesary duplicated TTBJs in production?
<bigjools> and unnecessary, even
<danilos> abentley, btw, do you know of any way to check if branch-scanner has recently been detecting a single change more than once (I am looking at logs but I can't find current branch-scanner logs on devpad)
<danilos> abentley, never mind, it's scan-branches.log
<danilos> bigjools, sure, though it will take me a bit to rediscover all the tables that I need to purge from
<bigjools> danilos: see mawson:~/handy_sql/kill_a_build.sql for inspiration
<danilos> bigjools, thanks
<abentley> jtv, around?
<danilos> abentley, he should be long gone
<abentley> danilos, mostly, but I have seen him around in the past.  I'm having problems with the FakeLibrarian.
<bigjools> danilos: hi
<danilos> bigjools, hi :)
<danilos> abentley, yeah, he does sometimes stick for much, much longer, but we are also trying to get that habit out of him :)
<bigjools> there's a rather large problem with builder histories being absent since about 6 hours ago, did you guys  change anything for your history?
<danilos> bigjools, those changes only landed on devel a few days ago, are you talking about production?
<bigjools> yes
<danilos> bigjools, unless this was CPed in line with lifeless' new approach to rolling out stuff, then we haven't changed anything recently
<bigjools> danilos: that's what I am wondering
<bigjools> it seems remarkably coinciding
<bigjools> what time did it get rolled out
<bigjools> today
<danilos> bigjools, did it get rolled out?
<bigjools> I;'ve no idea, I only just started looking at this
<danilos> bigjools, this is the last one: https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/35965
<bigjools> danilos: what revno did the ttbj history land in?
<bigjools> and was it on db-devel or devel?
<danilos> bigjools, I am looking that up now
<danilos> bigjools, fwiw, it's still marked as qa-needstesting for us, so I doubt it was CPed
<danilos> bigjools, it's db-stable r9793
<danilos> bigjools, so, my guess is that it ain't that
<danilos> bigjools, it's neither listed as part of any of the CPs
 * bigjools scratches head
<danilos> bigjools, fwiw, I am struggling very much coming up with appropriate queries for the DB (I started using the new table jtv added and the query failed on production)
<danilos> bigjools, that, at least, confirms that the code was not rolled out, but also makes my head hurt
<bigjools> the new model is a total headache :/
<danilos> bigjools, two models are a bigger one when you rarely use either :)
<bigjools> aye
<mtaylor> spiv: you awake yet?
<mtaylor> or really any losa - there is a chance that there may be a memory issue on maverick ppa builders ... we're seeing a drizzle test failure there that we're not seeing on our builders, and looking at the output it looks very similar to a weird failure we had on a machine a month ago that was also due to bad memory
<mtaylor> I mean, it could also be a bug in our code - but I thought it might be worth someone looking at
<mtaylor> http://launchpadlibrarian.net/52012953/buildlog_ubuntu-maverick-i386.drizzle_2010.03.1347-1_FAILEDTOBUILD.txt.gz
<mtaylor> hrm - perhaps nevermind ... similar but different is occuring in multiple places ...
 * rockstar lunches
<mtaylor> quick followup - it is our bug, but for some reason it's only showing up on the launchpad ppa 32 builders and not our 32 build machines ... are you guys doing anything weird on your 32bit builders which would cause them to deal with memory differently? (asking to see if I can set up something similar to try to more easily reproduce)
<jml> mtaylor, there's an issue that we are investigating right now
<jml> mtaylor, but apparently that's a different problem
<mtaylor> cool
<bryceh> deryck[lunch], on 642418 is it LP or the bugzilla lp plugin that sets the See Also link?
<bigjools> mtaylor: the PPA builders are virtual, which might be something, I dunno
<bigjools> mtaylor: but it's best to check with lamont
<bryceh> deryck[lunch], lp:~bryceharrington/bugzilla-launchpad/no-dupe-link-update
 * lifeless stretches
<lifeless> nigelb: ?
<deryck> bryceh, not sure if it's the plugin or lp.  If it's the plugin, it may not be worth worrying too much about, since people will need to install new, and newer bugzillas won't be affected.
<bryceh> deryck, since it sounds like it's a bugzilla policy whether to update links on dupe bugs, the plugin seems like the "right" place to fix it
<bryceh> deryck, as that'd prevent the incorrect behavior regardless of who was using the api
<bryceh> deryck, but for our case at least, i think we can conditionalize calling the set_link() api on it being a dupe... I'm checking
<bryceh> (and it still leaves the more general issue of making us point to the proper bug, but I *think* that may be a more involved issue)
 * deryck is thinking....
<deryck> bryceh, so the plugin is already configurable about whether or not to update links on dupe bugs?
<bryceh> deryck, no
<bryceh> heh that would make it especially easy
<bigjools> lifeless!  I'm surprised you don't have some way of accessing IRC when you're sleeping
<bryceh> bigjools, isn't that called a telephone?
<bigjools> or is this your morning clone I am speaking to
<lifeless> bigjools: I plug an ethernet cable into my ear.
<jml> wifi drains too much power in sleep mode
<deryck> bryceh, ok, so I think we should do the right think on our end.
<deryck> bryceh, if it's just a simple conditional to be quiet on upstream closed bugs, that's enough.
<bryceh> deryck, yes, it looks like I can slot in a check in linkLaunchpadBug()
<deryck> bryceh, ok, excellent.
<jml> hello everyone
<bryceh> deryck, this will only prevent it from setting the bug link on the upstream bug though... are there other updates we want to prevent done to upstream dupes?
<jml> bigjools & I just finished busting up a bunch of doctests
<jml> but we need to land the change, and I think someone ought to give it a cursory review first
<nigelb> lifeless: I just said your stump speech http://bit.ly/9mTfdf looks awesome :)
<bigjools> it's death to .txt
<jml> who would like to review https://code.edge.launchpad.net/~jml/launchpad/buildd-slavescanner-bustage/+merge/36187, which is 1k+ lines of doctest-removing fun?
<lifeless> nigelb: ah right, I had no idea what you were referring to by 'stump speech'
<deryck> bryceh, perhaps you and gmb should do a pre-imp on this tomorrow before he EODs.  I'm not sure about other updates honestly.
<lifeless> nigelb: I'm glad you like it.
<nigelb> lifeless: the bzr team called it that
<jml> anyway, I'm off to the pub
<lifeless> nigelb: its ok, I was just confused ;)
<jml> whoever reviews that branch gets a complimentary compliment at the next Epic
<jml> maybe a beer too
<nigelb> lifeless: considering that it must be something like 5 for you, totally understandable
<lifeless> nigelb: 7 :P
<nigelb> lifeless: still way to early ;)
<deryck> bryceh, the only other updates we would do would be comments, if supported, right?
<bryceh> deryck, dunno
<bryceh> deryck, yes
<deryck> bryceh, I think so, but not 100% sure.  I can argue boths pros and cons here, so let's allow gmb the final say.
<bryceh>            # Only sync comments and backlink if the local bug isn't a
<bryceh>             # duplicate and the bug watch is associated with a bug task.
<bryceh>             # This helps us to avoid spamming both upstream and
<bryceh> 	    # ourselves.
<lifeless> ok, lets see how bad this bugtask index test breakage is
<bryceh> haha, we avoid updating if the bug is a dupe on *our* end, but not *their* end :-P
<deryck> heh
<deryck> right, so there's your answer.
<deryck> bryceh, if there's is a dupe, do nothing.
<bryceh> deryck, ok, so don't bother with fixing the plugin, just fix locally?
<deryck> bryceh, yes
<bryceh> ok easy enough
<lifeless> sigh, bug.getBugTask makes me sad.
<jam> lifeless: I seem to be getting spurious failures when asking people to ec2land branches for me. I'm not really sure who to ask for help
<jam> but I see you online :)
<lifeless> jam: hi, what sort of failures?
<jam> lifeless: I can send you the email if that would be easier
<jam> but 2 in soyuz
<lifeless> sure
<jam> one in buildmaster
<bigjools> good night all
<jam> lifeless: my change just updates the default location of 'codebrowse's config files after a clean 'make'
<jam> lifeless: to elaborate, when starting with a clean machine, the build instructions didn't create the 'codebrowse.launchpad.dev' directory but they *do* create a 'bazaar.launchpad.dev' directory, which is also what is configured elsewhere in the code. I honestly wouldn't expect any tests to fail from this, as it is a setup thing.
<jam> certainly it doesn't touch soyuz code
<lifeless> jam: do those tests pass locally ?
<lifeless> jam: note that ec2 doesn't do a full setup, it starts partially setup AIUI
<lifeless> jam: perhaps talk with mars
<jam> lifeless: well, the last code I submitted was a comment-only change, and it still failed the ec2land test suite (for one person, for the other person it passed)
<jam> as such, I don't have huge faith in ec2land...
<jam> though that time was a different test that failed
<lifeless> jam: will be a minute
<cr3> gary_poster: got a minute for a question about z3c.recipe.scripts? having problems importing lazr.restfulclient in /usr/lib/pymodules after importing the generated site.py file
<jam> bac: ^^
<bac> oh, great
<jam> so if the tests are already failing, it may be a particular version of devel that I merged, etc
<jam> I suppose I should have merged something 'stable' ?
<bac> jam: did you not start with the latest devel?
<bac> i mean the latest rev of devel
<jam> bac: I started the branch a while back, you asked me to update against devel so I did
<bac> jam: right.
<jam> I also may have started it as a db-devel branch, etc
<jam> I would have thought by now the two would have converged, though, and the diff was the tiny one I expected
<bac> jam: i started with a clean version of the latest devel and merged in your two-line change
<jam> and you still got the failure?
<bac> jam: and that is what i'm testing locally
<bac> jam your branch on LP is what ec2 tested
<jam> (missing shows that I am without about 48 devel patches)
<jam> bac: are you running the full suite? Or just the tests that failed?
<bac> jam: just the failed
<jam> good to know they fail in isolation :)
<jam> (I'm still trying to just get the test suite to run again, after updating to the latest lp/devel)
<bac> jam: ec2 had 4 failures.  devel locally has 1.
<bac> jam: will re-run your branch again and see what fails
<jam> bac: well one of the failures definitely looked to be an isolation issue, since it was checking for OOPS...6 and found OOPS...7
<bac> ok
<lifeless> ok
<lifeless> so this is the same uniquefileallocator thing
<lifeless> try with my branch?
<lifeless> I'm waiting for *anyone* to tell me it works/doesn't work
<lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
<jam> lifeless: what is the right way to update your branch? I tried "utilities/update-sourcecode" and now zc.buildout is failing at 'make' time
<bac> jam:  your branch has 1 failure locally, not the OOPS one
<gary_poster> cr3: do you have include-site-packages = true in your .cfg file?  That will be the default in 1.5.2 but false is default before then
<jam> bac: is it the same one that 'devel locally' has ?
<bac> lp.soyuz.tests.test_buildpackagejob.TestBuildPackageJobScore.test_score_unusual_component
<bac> jam:no.  devel has the OOPS failure.  your branch has ^^
<cr3> gary_poster: yes
<jam> bac: well having it fail 3-different ways doesn't make me very trusting
<bac> nope
<cr3> gary_poster: I'm kinda confused why import can't find restfulclient under /usr/lib/pymodules/python2.6 when that path is actually in sys.path
<lifeless> jam: you may need an apt-get update && apt-get upgrade in there
<gary_poster> cr3: can you give me instructions to dupe maybe?  want to help, but also have some other people to support right now
<cr3> gary_poster: it seems that if I introduce /usr/lib/pymodules/python2.6 in the buildout_paths, in site.py, before the zope.exceptions egg path, then I can import lazr.restfulclient
<jam> lifeless: did that, now I'm trying an update of the "download-cache" directory
<jam> (bzr update)
<gary_poster> not a good long-term solution cr3: setuptools won't work the right way like that
<jam> which did pull in a bunch of stuff
<cr3> gary_poster: I'll try to figure a way to easily dupe and get back to you
<gary_poster> thanks cr3
<cr3> gary_poster: zc.recipe.egg seems to order paths correctly though
<jam> I don't know why it didn't update with everything else...
<jam> at this point, I'm ready to turn to a voodoo doll
<gary_poster> cr3 what definition of correc?
<cr3> gary_poster: works :)
<gary_poster> fair enough, cr3.  does not work in other circumstances though.
<jam> lifeless: updating download-cache was enough to get 'make' to run
<cr3> gary_poster: ugh, so if I use both zc.recipe.egg and z3c.recipe.scripts, I don't work in all circumstances :)
<gary_poster> cr3: correct.  z3c.recipe.scripts is supposed to be your one-stop-shop.
<gary_poster> (the fact that it is not is a bug, obviously)
<gary_poster> zc.recipe.egg will not change
<cr3> gary_poster: I'll concentrate on porting my existing zc.recipe.egg stuff to z3c then
<gary_poster> cool, cr3.
<lifeless> don't you hate it when adding an assert makes things work ...
<mars> leonardr, still around?  Did you get a chance to try lifeless's OOPS patch?
<leonardr> mars: well, it's in ec2. i didn't get the problem locally
<lifeless> Ursinha: could we have a 'latest' or 'current' symlink for the oops report html file ?
<Ursinha> lifeless, it's always the deployment-stable one
<lifeless> different hting
<lifeless> like https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-oops-last-hour.txt
<lifeless> but for the day
<mars> jam, any luck?  Normally to update LP you can run 'rocketfuel-get; cd mybranch; bzr merge ../devel'
<lifeless> I thought there was one, but I can only find things for specific dates, not one I can put in by bookmarks.
<mars> leonardr, the branch with the patch is in EC2?  Or just the plain old branch?
<leonardr> the branch with the patch is in ec2
<mars> lifeless, ^
<jam> mars: well, things almost seem to work, but I still am trying to determine how to run a subset of the test suite based on failures from ec2
<jam> at least the test runner starts up and runs some tests and exits appropriately
<lifeless> leonardr: cool, thanks
<lifeless> jam: testr load < subunit-stream; testr run --failing
<mars> jam, ok, in the branch: testr init; (save log.gz from ec2 to disk); zcat foo.log.gz | testr load; testr failing
<Ursinha> ah
<bac> jam, lifeless: the failure i'm seeing is real and is going to put us in testfix mode very soon now.  https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/steps/shell_7/logs/stdio
<bac> search for test_score_unusual_component
<mars> \o/
<Ursinha> lifeless, I see what you want
<lifeless> Ursinha: for that one html would be nice :)
<lifeless> Ursinha: just needs to be a symlink to 2010-09-21.html, etc etc
<Ursinha> lifeless, I got it
<jam> bac: so ec2land doesn't pre-merge the target branch and run the tests on the result?
<lifeless> bac: was that landed without ec2land? do we know?
<bac> jam: yes it does
<mars> jam, ec2 land branches devel, then merges your branch, then runs the tests
<bac> lifeless: we have no way of knowing
<jam> ah, I was hoping so
<lifeless> jml: yo
<bac> since it is soyuz i'd say not
<bac> i should rephrase
<lifeless> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/ is about to die and you're in the blame list. Should we rollback your commits ?
<bac> bigjools does his testing locally.
<bac> lifeless: who was that directed to?
<lifeless> jml:
<mars> jam, it was written by bzr folk - pre-merge is not natural, but all of you have learned to The Right Way To Do It
<lifeless> mars: pre-merge?
<mars> lifeless, is that not what jam just called it?  "so ec2land doesn't pre-merge the target branch and run the tests on the result?"
<bac> lifeless: yes, it is certainly jml's r11586
<lifeless> mars: 'EPARSE' on your last
<lifeless> bac: land a backout of it
<lifeless> bac: if you would
<lifeless> and 11588 I guess, I'm assuming that that was an attempt to fix it that didn't
<bac> lifeless: so how would i do that?
<mars> bac, please use "ec2 land --rollback 11586", or 'bzr lp-land --rollback 11586'
<mars> bac, that way the QA flags will be correct
<bac> mars: you rock!
<lifeless> bac: bzr lp-land --rollback 11586
<lifeless> bac: bzr lp-land --rollback 11588
<lifeless> and then it should go its merry way
<lifeless> actually
<lifeless> mars: is that only commit message glue, or does it do the roll back merge too ?
<mars> bac, by the way, you have to acutally run 'bzr merge 11586..11585'
<lifeless> so, the full story then:
<lifeless> bzr branch devel testfix
<lifeless> in testfix
<mars> (this is all in the not-yet-seen-but-does-exist user guide)
<lifeless> bzr merge . -r 11586..11585
<lifeless> bzr merge . -r 11588..11587 --force
<lifeless> bzr commit -m "Rollback 11586 and 11588"
<lifeless> bzr lp-land --rollback 11586 --rollback 11588
<lifeless> mars: ^ sane?
<mars> lifeless, I hope so.  I don't know if the tagger or lp-land can take multiple --rollbacks
<bac> seems right to me, though i would've forgotten the .
<lifeless> mars: if it doesn't, it will need to ;)
<mars> if it doesn't, we can roll each back on it's own maybe?
<mars> bac, try it
<mars> test flight!
<bac> mars: trying
<bac> still generating me some wadl
 * mars hope's bac's branch doesn't end up in a smouldering crater
<mars> I can watch the tagger logs
<mars> ah, maybe not.  There is a 4? hour lead time on landings
<mars> puts is around 8:30 or 9pm here
<bac> mars: what plugin provides lp-land?  mine doesn't have --rollback
<mars> bac, bzr-pqm
<bac> mars: i need to install from lp:pqm?
<mars> bac, sorry, 'pqm' is the plugin, bzr-pqm is the ubuntu package
<bac> mars: is there a ppa?
<mars> bac, yes, it is in the LP ppa - what version do you have?
<mars> apt-cache policy bzr-pqm
<bac> ii  bzr-pqm                 1.4.0~bzr69-1           bzr plugin to submit an email to a Patch Queue Manager
<mars> out of date
<mars> 1.4.0~bzr73-0ubuntu1-launchpad1~lucid1
<mars> why, it needs a maverick build?
<bac> not.  on.  lucid.
<bac> no one should be on lucid
<bac> we all have to jump the broom together
<bac> or something like that
<bac> i think i confused roots with thelma and louise
<bac> mars would you mind trying the rollback since i'm crippled?
<mars> ok, having no series on the PPA page package list is a little annoying
<bac> jam, please ping me tomorrow and i'll try again
<mars> wasn't there supposed to be JavaScript on this page?
<mars> bac, ok, what is the branch, just devel?
<bac> mars: yes, devel.
<mars> bac, here is your problem: https://edge.launchpad.net/~launchpad/+archive/ppa?field.series_filter=maverick
<bac> trying to undo changes 1 and 3 from https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/
<mars> compare to: https://edge.launchpad.net/~launchpad/+archive/ppa?field.series_filter=lucid
<bac> yes, many fewer
<mars> some are legitimate, like python-debian
<mars> others are oversights
<mars> adding that to my TODO list
<mars> bac, running it now
<bac> is celso really still uploading PPAs for us?
<bac> re: geoip on maverick
<jam> bac: I'll say hi tomorrow, thanks for working with me on this
<bac> jam: sorry we had so much fail for what should've been easy
<jam> lifeless: so how in the 'testr' stuff do you run just the failing tests?
<jam> testr run looks like it runs everything
<lifeless> testr run --failing
<jam> ah, testr run --failing
<mars> bac, waiting for the MP to show up, I'll need you or lifeless to approve it to appease lp-land
<bac> mars: rs=me
<lifeless> rs=theworld
<bac> mars: oh, right, on the MP
<rockstar> Wow, Chromium consistently crashes X for me now.
<mars> rockstar, eeew
<rockstar> mars, what's worse is that it seems to happen whenever I'm REALLY focused on what I'm doing.
<mars> X crashes are not fun.  I've had my share of those.
<mars> yeah
<mars> at least an application freeze is humane.  An X crash is just brutal.
<jml> lifeless, hello. what's up?
<jam> lifeless: trying to run "testr run --failing" gives me: http://paste.ubuntu.com/497981
<jam> which seems like a test system infrastructure issue
<mars> bac, https://code.edge.launchpad.net/~mars/launchpad/rollback-11586-and-11588/+merge/36212
<wallyworld___> morning
<jml> jam, yeah. I've been meaning to chase down that bug.
<lifeless> jml: bb found a flaw in your branch
<lifeless> jml: we're backing it out
<jml> lifeless, :(
<jml> lifeless, can't I just fix it instead?
<jam> jml: well, it *does* take 4 hours to land the reversal
<lifeless> jml: it looks like you've tried once already; its an unknown amount of time before we find all the issues and we don't want to be in testfix for that long.
<jml> lifeless, wrong.
<mars> ok, trying lp-land
<jml> lifeless, different problem.
<mars> ...
<lifeless> mars: hang a sec
<mars> (nice timing)
<lifeless> jml: please expand;
<jml> lifeless, the first test fix was for a different failing test with a completely different problem: not having a clean() method on build
<lifeless> jml: [separately, meta] are you landing these things via ec2 land ?
<jml> lifeless, the failure you see now is due to a different problem due to a change to the API of a factory method
<jml> lifeless, no, I'm not.
<lifeless> jml: please do.
<jml> lifeless, I normally do.
<lifeless> jml: well, please do what you normally do.
<jml> lifeless, ok.
<lifeless> jml: not doing it has spent about 1/2 an hour of engineer time
<mars> x3
<lifeless> jml: how confident are you that there are no other issues behind this one
<bac> mars:done
<jml> lifeless, sure. I know how tedious it is to fix other people's broken builds.
<jml> lifeless, quite confident.
<lifeless> ok, I'm happy with 'fix it' - but if we head back into testfix from another issue in the same patch in 4 more hours, I'll roll it back and let you debug tomorrow, ok?
<jml> lifeless, +1
<mars> lifeless, jml, so if need be, we roll back both with https://code.edge.launchpad.net/~mars/launchpad/rollback-11586-and-11588/+merge/36212 ?
<mars> lifeless, or will you prepare a new patch?
<jml> mars, I'd rather you rollback only 11588
<lifeless> jml: landing without ec2 land is ok from time to time - you know me and pragmatism; I guess I'm saying that the work you're doing is stuff I wouldn't have attempted to land without full tests :)
<lifeless> mars: I'll leverage that one, if needed
<mars> lifeless, ok, I'll leave it to you and jml then
<lifeless> mars: thanks
<lifeless> mars: can you confirm that when bb *starts* a build pqm opens again ?
<bac> yeah, thanks mars
<bac> lifeless: that is true
<jml> lifeless, as I said, normally, I wouldn't either.
<mars> bac, the 'pqm opens again' is true?
<mars> I don't actually know
<bac> when bb starts on at [testfix] it optimistically takes us out of testfix mode
<lifeless> bac: thats a different question
<lifeless> bac: what I asked is 'starts a build' - thats 'receives a testfix commit'
<lifeless> bac: many testfixes are spurious
<jml> lifeless, waiting eight hours before I can meaningfully integrate is particularly trying at a sprint. :\
<lifeless> yeah
<bac> lifeless: what do you mean many testfixes are spurious?
<lifeless> bac: I mean our test suite is as flaky as 'Flake(tm)' chocolate
<bac> lifeless: i assumed you meant pqm was closed due to testfix mode
<lifeless> yes, thats what I mean
<bac> then bb won't start again until it receives a testfix, right?
<lifeless> a non trivial amount of the time just running the test suite again will work.
<lifeless> bac: no, you can press 'force build'
<mars> but that does not open PQM again
<bac> lifeless: so you are asking if forcing a build while in testfix mode opens pqm.  that i do not know
<lifeless> mars: it doesn't? Ok, can we make it do so?
<mars> lifeless, no idea.  That means the poller bit would have to know the difference between a forced build and a testfix build.  Would take some work.
<lifeless> mars: why would it need to know the difference?
<bac> mars: making it know the difference would argue that it currently would open pqm
<mars> yep, you are right.  I was thinking 'if you only want to open PQM when a build is forced, then you need to do some footwork'
<jml> lifeless, I object to your statement about our test suite being flaky. The tests themselves very, very rarely fail spuriously.
<mars> tunnel vision, not helpful, sorry
<lifeless> jml: layers fail to come up; windmill on the lp builder is almost always dying, we have hung librarian processes a lot of the time
<jml> lifeless, yes, but the tests themselves...
<jml> lifeless, everything else never works, sure.
<lifeless> jml: I referenced the 'test suite', which is the whole
<mars> lifeless, ?  I haven't seen any of those issues in a while.  Recently it has been the DB connections thing.  and XMLRPC code pulls fail.
<jml> :D
<lifeless> mars: yesterday.
<lifeless> mars: lp build, lp_db, go boom.
<lifeless> also
<lifeless> this is bad:
<cr3> gary_poster: it seems the problem might be related to bug #599332, now I'm getting: Error: Couldn't find a distribution for 'elementtree'. Still working on it...
<_mup_> Bug #599332: python-lazr.enum makes python-lazr.restfulclient no longer be visible <lazr.restfulclient (Ubuntu):Fix Released> <https://launchpad.net/bugs/599332>
<lifeless> Danger Zone.
<lifeless> enter makeBugTask.
<lifeless> 233525392 16
<lifeless> 233525392 16
<lifeless> 233525392 16
<lifeless> 234934992 16
<lifeless> enter makeBugTask.
<lifeless> 233525392 16
<lifeless> thats id(bug), bug.id
<lifeless> in one call to makeBugTask()
<lifeless> notice that we have two objects claiming to be the same bug, live at once.
<wallyworld___> thumper: standup?
<mars> lifeless, if you are wondering about the hardy builders, we haven't been maintaining them
<mars> yes, they blow up, because we aren't fixing the problems
<lifeless> mars: which demonstrates my point about flakiness ;)
<gary_poster> cr3: :-) I'm sorry.  If you can just give me dupe instructions, I'll swim in themorass for you
<lifeless> the lp test environment is not a 'fire and forget' one.
<lifeless> its forget, and you're on fire.
<gary_poster> cr3: IOW, I advise trying to keep from figuring out what's actually going on--but if you do, that's great
<cr3> gary_poster: heh, that's really nice but I'm trying to spare you too much distraction
<cr3> gary_poster: in that case, I'll try to push a branch which can reproduce the problem for you. one moment...
<gary_poster> cr3: great thanks.  You may have to give me apt package names that you have installed that you suspect are causing the problem.  It may also be lucid or maverick or something, so let me know what that is
<jml> one line diff: https://code.edge.launchpad.net/~jml/launchpad/fix-factory-change/+merge/36215
<mars> jml, if you are asking 'does this pass our code standards', then yes! r=mars.  If you are asking if you missed anything critical in this patch, well, I have no idea :)
<jml> mars, good enough for me.
<mars> jml, done
<jml> mars, ta.
<jml> landing now.
<lifeless> I'd really quite like to delete most of our coding standards I think.
<lifeless> they seem, the more code I read, to be a poor surrogate for what we say we care about
<mars> lifeless, to be honest, I mostly review for readability now - a Smalltalk-influenced ideal I believe we should strive towards
<mars> and all-around quality - more robust tests, using the right test type for the purpose and such
<lifeless> mars: things like lines ending on 78/79/80, (,) vs (, ), what case to use for function names seem largely content free
<mars> oh, and for codebase design improvements - "we have a helper for that", or "this would be great as a new helper"
<cr3> gary_poster: email sent
<lifeless> mars: thats sensible
<mars> lifeless, true, but standards are nice.  When one person codes to C, one to Java, and one to Smalltalk, things look... not as nice as they could be, to the other people
<mars> and in Python as a whole, I have seen all three
<gary_poster> cr3, ack, investigating
<mars> styles, that is
<lifeless> mars: if we're going to use a standard, we should use a standard.
<lifeless> mars: not make our own
<lifeless> mars: because we interoperate with the rest of the python world
<lifeless> mars: I would simply say 'be roughly PEP8, make it readable, thanks.'
<gary_poster> cr3: maybe I don't have privs to see?
<jml> PEP 8 (alternatively, bzrlib's or Google's Python standard)
<cr3> gary_poster: maybe I've been working too hard on this and I forgot to push that branch :)
<cr3> gary_poster: it's done now, sorry about that
<gary_poster> jml, lifeless, mars, changing coding standards in the middle of a codebase, particularly when you are talking about things that affect API, like camelcase versus underlines, doesn't seem like a great idea to me, but...eh, flyby :-) .
<jml> gary_poster, yeah, that's the other issue
<gary_poster> cr3: got it, thanks :-)
<jml> gary_poster, especially now that we've got an external API to preserve
<gary_poster> well, we can adjust that
<gary_poster> but still
<gary_poster> unless we have a magic "change everything at once"
<gary_poster> I'm -1
<gary_poster> Which is funny in a way
<gary_poster> But I need to move on :-)
<cr3> jml: I've I'm writing a brand spanking new API, is there anything I should consider from this conversation about coding style?
<jml> cr3, no.
<gary_poster> PEP 8 :-)
<lifeless> cr3: make it tasteful.
<lifeless> gary_poster: changing public apis has consequences, yes.
<cr3> lifeless: to me, it tastes just the same camelcase vs underlines
<cr3> lifeless: ... as long as it's consistent with the context
<lifeless> use whitespace then, to add flavour
 * cr3 adds salt (random bits) to taste
<gary_poster> don't give me that branch, cr3 ;-)
<gary_poster> cr3: maybe you haven't checked in things to download-cache?
<gary_poster> missing wsgi-interceptm for instance
<gary_poster> can work around
<jml> anyway, my yak stack is pretty deep with things that actually bug me about LP development. coding standard is well low.
<cr3> gary_poster: installed as package, I should add to setup.py
<gary_poster> cr3: ok.  got it as egg here
 * jml is hanging around until PQM says my branch has landed
<cr3> gary_poster: ./bin/test, are you getting the same error as me?
<poolie> hello all
<gary_poster> cr3, doing it a different way, but I think so :-)
<lifeless> poolie: hi
<poolie> hi lifeless
<lifeless> early for you? Anyhow I could use a hand
<lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342
<_mup_> Bug #634342: need a features 'scope' for page ids <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342>
<poolie> slightly early
<poolie> yes i saw
<poolie> i would presume from that output that it is getting the value for memcache in that scope
<poolie> unless you defined it at a lower prioirity than the default
<poolie> clearly there's room for better docs and tests there
<lifeless> there was only one rule defined in the db
<cr3> gary_poster: regarding wsgi.intercept, I'll probably be testing it differently once I get the bin/test script running
<gary_poster> cool
<lifeless> poolie: is 0 ultimate high or low pri ?
<poolie> i will file a bug
<rockstar> lifeless, https://code.edge.launchpad.net/~rockstar/launchpad/build-farm-job-constraint/+merge/36219
<rockstar> lifeless, I'd be interested in your opinion here.
<lifeless> rockstar: I need to pop out to the shops briefly, will look when I return
<poolie> it uses the rule that is relevant and has the numerically highest priority
<poolie> so 0 is ultimate middle :)
<poolie> you could go negative
<poolie> but i imagined we would use 0 for the defaults
<rockstar> lifeless, ack.
<poolie> hello gary_poster, rockstar
<gary_poster> hey poolie :-)
<rockstar> poolie, hi.
<jml> ~30 mins :(
<jml> g'night all.
<poolie> hi jml! sleep well
<poolie> lifeless: i'm trying to work out what the doc/usability bug should be
<leonardr> lifeless: fyi, after merging your branch my branch ran ec2 with no test failures, but for some reason the ec2 run failed anyway
<leonardr> Tests failed (exit code 1)
<leonardr> make: *** [check] Error 1
<poolie> well, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/644751
<_mup_> Bug #644751: should be easier to tell which flags are active <flags> <Launchpad Foundations:Confirmed for mbp> <https://launchpad.net/bugs/644751>
<poolie> feel free to add more
<mars> rockstar, poolie, since you are on the topic of feature scopes: the docs don't say how to install a scope or feature for just one test.  Did either of you have an idea about how it could be done?
<mars> rockstar, unping
<mars> lifeless, that last was meant for you
<poolie> i'm just replying to noodles's mail about exactly that
<mars> haven't looked today - on lp-dev?
<gary_poster> cr3: ah-ha!  You have encountered https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/621348 !
<_mup_> Bug #621348: .pth and .egg-info files in /usr/lib/pymodules/python2.6 are not being processed <python2.6 (Ubuntu):New> <python2.6 (Debian):Unknown> <https://launchpad.net/bugs/621348>
<gary_poster> congratulations! ;-)
<mars> poolie, ok.  The other thing I was wondering - why do I need a full database to fire up a feature?  Can we just do a simple dict-based controller for that?
<cr3> gary_poster: reading and scrutinizing for workaround :)
<gary_poster> cr3: :-) workaround I would suggest is to use the packaged eggs.  Would that work for you?
<mars> poolie, or some way to install a custom FeatureController that is just a dict :p.  Maybe a bit more with scopes if need be.
<gary_poster> sorry, "packaged eggs" was two mistakes in two words cr3
<gary_poster> I meant the .tgzs available from PyPI
<gary_poster> Or launchpad in this case
<poolie> mars istm that for most tests you shouldn't care about the rules and scopes
<cr3> gary_poster: packaged eggs just for lazr.restfulclient?
<poolie> you just want to say "with active_features([blah, blah, blah])"
<cr3> gary_poster: err, "tgz" just for lazr.restfulclient? :)
<gary_poster> :-) yeah.  is that acceptable cr3?  I'd actually recommend all the lazr things be from Python source packages (tgzs)
<gary_poster> you could do that probably pretty easily
<mars> poolie, "with active_features()" - is that documented?
<mars> poolie, because I have yet to see it
<cr3> gary_poster: I tried that earlier and got something about not being able to find distribution for elementtree, but that might've been because of the wsgi stuff. let me try again real quick
 * gary_poster needs to turn into pumpkin, cr3
<poolie> mars, that was science fiction
<poolie> i'm saying that's what the api should be
<mars> lol
<poolie> like a famous announcement from our ex-government telco "no email should have been lost during this upgrade"
<poolie> yeah, "shoudl"
<poolie> *should
<cr3> gary_poster: darn, I'll try me best then and try to get some rest even if it doesn't work :)
<cr3> Error: Couldn't find a distribution for 'elementtree'.
<cr3> crap, no clue where that's coming from
<gary_poster> cr3: ack.  Send me an email (and a branch!) and I'll look at it tomorrow morning
<gary_poster> let me try
<mars> poolie, so Michael's helper is a start.  It would be nice to break the database dependency, but that can be done later
<gary_poster> cr3, worked for me
<poolie> right
<poolie> i'll try to do that in my next slice on it
<poolie> got to do some bzr things today
<cr3> gary_poster: 1. added lazr.restfulclient-0.10.0 to download-cache; 2. added lazr.restfulclient to eggs under [buildout]; 3. make build?
<gary_poster> cr3: http://pastebin.ubuntu.com/498023/
<reed|work> bryceh: Why not just fix the link to go to the non-dupe bug?
<gary_poster> 8-9: hack to get packages
<reed|work> as in, go up the chain
<gary_poster> 4-15 also
<gary_poster> 14-15 I mean
<reed|work> bryceh: and update launchpad with the actual bug
<reed|work> rather than the dupe
<gary_poster> 23 says :don't get my dependencies from site-packages
<gary_poster> 31 is a convenience to get an interpreter to play around with
<gary_poster> 41-43 should mean that you can reinstate allow-picked-versions = false
<bryceh> reed|work, right that's how I'd *like* to fix it
<gary_poster> cr3: argh import still fails
<gary_poster> also, it didn't get packages; looking
<gary_poster> need to go RSN
<reed|work> bryceh: I was just reading your initial commit, which didn't seem like a very good fix ;)
<bryceh> reed|work, unfortunately launchpad appears to capture the fact that the watched bug has status DUPLICATE, but afaict does not record what the remote dupe bug was
<cr3> gary_poster: at least I'm reassured this is not a trivial problem :)
<reed|work> so, can that be fixed?
<gary_poster> cr3: well, the debian one isn't.  this is suposed to be
<reed|work> well
<bryceh> reed|work, aside from fixing a symptom rather than root cause why do you think it is a bad fix?
<poolie> john has a big, useful patch stalled
<poolie> r
<poolie> https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877
<reed|work> because launchpad won't be showing the *real* status of the upstream bug
<poolie> if i read it, will someone from the lp team join me?
<reed|work> which is what this is supposed to be providing
<reed|work> it will just be showing the status of some dupe bug that nobody upstream is looking at
<jml> poolie, I can try, but can't promise anything this week.
<bryceh> reed|work, I think you're jumping the gun a bit.  ;-)
<bryceh> reed|work, as I see it there are three possible ways to address the complaint
<bryceh> reed|work, two of the three are fairly trivial, and I did implementations of both of those
<bryceh> the third, making the bugwatch auto-update, is not as easy as it seems
<bryceh> because while we capture the fact that the upstream bug is marked RESOLVED DUPLICATE, we do not capture the identity of the bug it was duped against
<gary_poster> cr3: your builout doesn't actually install your software :-P :-)
<bryceh> in any case, I have emailed gmb for advice on how to do that third approach, and shown him the other two
<cr3> gary_poster: if I can't run the tests, it's a feature that it doesn't actually install :)
<gary_poster> lol
<bac> mars, gary_poster: lucid_lp builder failed with "Cannot rebuild database. There are 1 open connections."  is that fixable by a forced rebuild?
<reed|work> bryceh: where is the code that pulls from bugzilla?
<reed|work> like, pathwise or filewise
 * reed|work is pulling launchpad
<mars> bac, yes, force rebuild
<mars> bac, it could take a few tries to clear it
<bryceh> reed|work, recall the original complaint was that mozilla was feeling spammed by updates to dupe bugs; that complaint is easy to solve
<reed|work> sure
<bac> mars, gary_poster: thanks
<reed|work> people are also whining about launchpad touching old bugs
 * gary_poster just watched, and started to reply
<reed|work> that haven't had activity forever
<reed|work> but I care less about that
<bac> mars:  it just started and says "ETA of 2h 14m".  what is it smoking?
<bryceh> reed|work, well like I said that was probably just because we started tracking Importance now
<reed|work> bryceh: sure
<reed|work> https://bugzilla.mozilla.org/show_bug.cgi?id=597786
<reed|work> https://bugzilla.mozilla.org/show_bug.cgi?id=597902
<reed|work> see those two bugs
<mars> bac, I think that is close to normal now.  Might be the time from the last run?
<reed|work> those are complaints people have been having
<bryceh> reed|work, heh when my son whines we make a point not to give him what he's whining for so we don't reinforce the behavior ;-)
<mars> bac, there is a lot of overhead in there besides running the suite
<gary_poster> lol bryceh
<bac> bryceh: do you squirt him with water?
<reed|work> bryceh, that works, except when he's right.
<reed|work> ;)
<bryceh> bac, in the bathtub and he loves it ;-)
<bryceh> reed|work, anyway just stay tuned, I'm way ahead of you ;-)
 * bac just watched the big bang theory "positive reinforcement" episode...
<bryceh> bac, lol
<reed|work> bryceh, you saw the complaint about launchpad re-adding the link when people remove it, right?
<reed|work> especially if it's wrong
<bryceh> reed|work, no didn't see that
<reed|work> see the two bugs I linked above ;)
<bryceh> reed|work, but having just looked at the update code I know why - if the field is blank it updates it
<bryceh> reed|work, obvious workaround would be to just put garbage in the field and it won't update.  "NOTHING" would do it
<reed|work> wait, which field?
<reed|work> you can't put "NOTHING" in a see also field
<reed|work> in bugzilla
<bryceh> well, any value except blank would prevent launchpad from filling it in
<gary_poster> cr3: 21 minutes late, must go!  but this works.  http://pastebin.ubuntu.com/498032/ .  Builds a whole buncha buncha stuff.  Needs more cleanup.
<reed|work> yeah, can't put anything but urls, and specific URLs at that
<gary_poster> There are some similar probs in your cfg
<reed|work> so, that's not really a fix or workaround
<bryceh> reed|work, anyway, you'd need to raise this with deryck, I'm just hired gun here :-)
<gary_poster> That is, related to not actually building your package
<reed|work> sure
<gary_poster> Can look tomorrow cr3
<cr3> gary_poster: thanks, I'll catchup with you tomorrow!
<gary_poster> bye
<reed|work> deryck around, or is he gone for the day?
<bryceh> reed|work, sounds like there'd need to be some way to record "not bug such-and-such" that would clue launchpad in
<bryceh> reed|work, he's probably gone for the day
<reed|work> mmm
<reed|work> let me think how that could work
<rockstar> thumper, I'm going to go for walk.  I'll be back in a bit.
<lifeless> mars: what was for me ?
<lifeless> leonardr: was there any other data?
<mars> lifeless, leonardr's run of the patch
<lifeless> ohright
<mars> lifeless, oh, the other thing - the API suggesting.  Martin answered my question with artistic fiction - can't easily top that :)
<mkanat> gmb: Do you have a Mozilla Bugzilla account?
<mkanat> Looks like not.
<reed|work> yes, he's graham@canon
<mkanat> Ahh.
<reed|work> I cc'd him on the first bug
<reed|work> not the second one yet
<lifeless> poolie: so I'm still confused about the scopes bug thing; its not getting the value back.
<lifeless> mars: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/631884
<_mup_> Bug #631884: feature flags get out of sync easily <qa-untestable> <Launchpad Foundations:New for lifeless> <https://launchpad.net/bugs/631884>
<mars> lifeless, eh?
<wgrant> jtv: You should probably warn people that setting a contact address will break all their bugmail.
<lifeless> mars: something to be aware of if working up poolies sci fi
<mars> right.  I think noodles' patch covers that
<mars> lifeless, would the helpers go in lp.testing, lp.testing.features, or lp.features.testing ?
<mars> I need some help with the convention here
<mars> or on lp.testing.TestCase as a helper method
<lifeless> poolie: the memcache code still runs, so I think that the 'disabled' is not propogating correctly.
<mars> nah, that wouldn't work for views
<mars> lifeless, sorry to bug you with the questions, but you are the Test Engineering Ninja for this shift :)
<lifeless> lp.services.features.testing.py
<mars> great, thanks
<lifeless> lp/services/features/testing.py I mean, obviously ;)
<wgrant> jml: Yay, you're killing buildd-slavescanner.txt
<jml> wgrant: a letting.
<jml> wgrant: a little, I mean.
<jml> brain no longer connected to fingers. good night :)
<wgrant> Night.
#launchpad-dev 2010-09-22
<leonardr> lifeless: here's the entire run: http://pastebin.ubuntu.com/498063/
<lifeless> leonardr: uhm, its normally a .gz file for good reason ;)
<lifeless> leonardr: consider email in future?
 * leonardr hates email, but ok
<lifeless> 42000 line pastebins make me sad
<lifeless> leonardr: ah, is that why you're never on the lp-dev list ? )
<lifeless> leonardr: line 26213 of that pastebin
<lifeless> jml's testfix issue
<lifeless> AttributeError: 'NoneType' object has no attribute 'specific_job'
<lifeless> leonardr: you can find this easily by 'gunzip -c log | subunit-filter | subunit2pyunit'
<leonardr> lifeless: i see, it's an "error" not a "failure"
<lifeless> leonardr: (or testr load)
<leonardr> lifeless: for the record, you're right about email for such a long doc, the pastebin is a pain
<leonardr> i hadn't actually used it
<lifeless> I'm frankly impressed and a little terrified that it accepted it.
<leonardr> lifeless: jml's testfix issue == the one he's trying to address with buildd-deferred-fo-sho?
<lifeless> I guess
<lifeless> anyhow, not your branch, not my patch :)
<leonardr> lifeless: does that actually give me the option to land my branch, or is the line stopped?
<lifeless> leonardr: was that the only error in the output?
<lifeless> leonardr: if so, I'd land your branch, because we know that that error was from a different very unrelated patch
<leonardr> lifeless: i've got two identical-looking windmill errors as well
<leonardr> error: lp.registry.windmill.tests.test_add_bugtracker.TestAddBugTracker.test_adding_bugtracker_for_project [ multipart
<leonardr> Content-Type: text/plain;charset=utf8
<leonardr> garbage
<leonardr> 35
<leonardr> [<Thread(Thread-275, started daemon 47553913698064)>]0
<leonardr> ]
<leonardr> well, i guess pastebin would have been good for *that*
<lifeless> leonardr: I don't know enough to comment about them
<leonardr> lifeless: ok, i'll wait until tomorrow
<lifeless> leonardr: 5 lines isn't worth pastebin. personally I pastebin above ~10 lines and below thousands.
<mars> leonardr, should be ignored
<mars> by the test framework
<leonardr> mars: hey, you're still around
<mars> leonardr, for maybe 5 minutes
<leonardr> mars: ok, i'm going to land the branch without lifeless's branch merged, since his branch hasn't been reviewed
<lifeless> leonardr: it will fail
<mars> leonardr, sure.  I was just commenting about the windmill errors.  I actually fixed that specific bug a while ago (or thought I had)
<lifeless> leonardr: do not land it, you'll break bb
<leonardr> lifeless: ok, then i'll wait until your branch has been reviewed and landed, and then i'll land this branch
<lifeless> it was reviewed
<leonardr> lifeless: i see, the status wasn't changed
<lifeless> leonardr: besides which, if you needed it reviewed, its a) tiny and b) you're allowed to do reviews too.
<leonardr> lifeless: ok, i am in a position to land both your branch and my branch. will *that* break bb (because of the bug jml is trying to fix)?
<lifeless> leonardr: no, because your branch + my branch + devel only failed on what jml is fixing.
<lifeless> s/no/very low probability/
<leonardr> ok, i'm going to do that
<wgrant> spm: Are you sure there's only one LP person? There may be another one with an email address matching one of the SSO accounts.
<spm> wgrant: 4 emails. 3 in the old; 1 in the new.
<wgrant> There's a known bug there.
<wgrant> spm: And the primary addresses for both SSO accounts are associated to the one Person?
<spm> the two openid's both are in the same LP account; so if there's a new account; not sure how to find it.
<spm> are associated to the one Person <== to the one LP account, yes.
<wgrant> The OpenID identifiers sadly don't matter -- they will follow whichever Person the email addreess is associated with.
<wgrant> Hmm.
 * poolie is back
<poolie> lifeless: do you want a hand with the flags stuff at all?
<lifeless> poolie: that would be lovely
<lifeless> poolie: if you do 'make run' and visit bugs.launchpad.dev/bugs/1
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<poolie> ok, let me answer this roadmap mail then i'll see what i can make of it
<poolie> snort
<lifeless> poolie: then look at the source, you should see the memcache flag evaluated
<lifeless> if you do ++oops++ on that and look at the oops, you can see memcache calls are made.
<lifeless> poolie: setting the rule in the db as I put in the bug, the scope is found, the flag still evaluates to None, and memcache calls are still made.
<lifeless> poolie: its likely shallow, but I've been elbow deep in this bugtask perf patch.
<poolie> k
<rockstar> ec2 keeps failing my branch on tests that aren't failing locally and look to have absolutely nothing to do with my changes.
<rockstar> I'm half tempted to just send it to PQM and see if it breaks there.
<lifeless> rockstar: details?
<rockstar> lifeless, what details do you want?  The actual tests that failed?
<lifeless> yes
<lifeless> wgrant: https://code.edge.launchpad.net/~rockstar/launchpad/build-farm-job-constraint/+merge/36219
<lifeless> wgrant: how does that fit in the with the build farm refactoring stuff
<rockstar> lifeless, that part better not get refactored.  It just got refactored.
<rockstar> lifeless, here's one: lp.soyuz.tests.test_buildpackagejob.TestBuildPackageJobScore.test_score_unusual_component
<lifeless> rockstar: heh, yes. but wgrant has stared closely at this stuff a lot ;)
<lifeless> rockstar: was it a missing/None attribute error?
<lifeless> rockstar: if so, jml is meant to have fixed it
<rockstar> lifeless, uh, how was he meant to have fixed it?
<lifeless> he had a branch
<rockstar> lifeless, basically, abentley noticed when doing the refactoring the PackageBuild that the interface and the branch didn't agree.
<lifeless> him and bigjools landed some brokenstuff
<lifeless> rockstar: ECONTEXT: The test failure
<rockstar> lifeless, oh, maybe, except for that it failed the same tests yesterday.
<lifeless> rockstar: paste the error?
<rockstar> lifeless, http://pastebin.ubuntu.com/498129/
<lifeless> yes, thats jml/bigjools and jml was landing a patch
<lifeless> https://lpbuildbot.canonical.com/waterfall
<lifeless> rockstar: rev 11589 looks like it should fix it
<lifeless> rockstar: so if you ec2 land it should work now
<wgrant> rockstar: When did it get refactored?
<rockstar> wgrant, the PackageBuild stuff?  July.
<wgrant> rockstar: Oh, that's just the first part of the refactoring.
<wgrant> That part is staying, but the table you just fixed is being removed.
<wgrant> Now that Translations has done their bit.
<rockstar> wgrant, *groan*
<rockstar> wgrant, as long as someone BESIDES code takes care of it.
<wgrant> I believe that is the plan.
<rockstar> This moving target thing is really hard when you're trying to finish a feature.
<wgrant> Well, this wouldn't have been a problem if it had been designed properly in the first place :)
<wgrant> But it's nearly there now.
<wgrant> We have all the necessary tables.
<wgrant> So now we just have to move stuff off the old classes and delete their tables.
<wgrant> In summary: BuildFarmJob, PackageBuild etc. are staying.
<wgrant> BuildQueue, SourcePackageRecipeBuildJob, BuildPackageJob, TranslationTemplatesBuildJob are being destroyed.
<jtv> wgrant: setting a contact email will break bug mail!?
<wgrant> jtv: It will send bugmail to the list.
<jtv> wgrant: you mean the contact address?
<wgrant> jtv: that.
<jtv> grrrr
<jtv> what a wonderful situation we just got dumped in
<wgrant> What forced the change?
<wgrant> Didn't you previously use a celebrity?
<jtv> The change was one we were entirely unaware of, so I'm only now learning the details.
<jtv> Apparently bzr needs a user id for every committer.
<jtv> And apparently those ids used to be made up somehow (I don't know the details).
<jtv> It was decided somewhere that this was wrong, and so the Launchpad code had to pass an email address when committing.
<wgrant> isn't the author still the celebrity, though?
<wgrant> Why can't it be the committer for now too?
<jtv> No.  These commits default to the branch owner.
<jtv> There's a bug in that change such that if the branch owner doesn't have a preferredemail, boom.
<wgrant> Hm, I thought they were "Launchpad Code Hosting" or something like that.
<jtv> We've been _wanting_ to make this commits in the name of a celebrity for a long time, just like you say.
<wgrant> But it was like that when it was first implemented...
<wgrant> I even filed a bug.
<wgrant> Bug #407266
<_mup_> Bug #407266: Translations branch committer needs a better email address <code-integration> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/407266>
<jtv> Ahhh
<jtv> wgrant: thanks, that's a missing piece of the puzzle.
<jtv> We would have liked to have a proper, recognizable celebrity for this.
<jtv> And this bug report must have been the reason we wanted that.
<wgrant> The thing is, it was previously a celebrity. A bad one, but still a celebrity.
<wgrant> I don't remember a commit when that changed.
<jtv> But evidently the Code code moved in a different direction without our knowledge.
<wgrant> Yeah, maybe.
<wgrant> Oh.
<wgrant> I bet that was the default whoami.
<lifeless> yes
<jtv> Yes.
<lifeless> it was the default whoami;
<jtv> We left it uninitialized.
<jtv> Then apparently it got changed to default to branch.owner.
<lifeless> I proposed using the same logic Code uses to do changes files for recipe builds.
<wgrant> I didn't consider that the gecos would be something like that.
<wgrant> So thought it must have been in the code somewhere.
<wgrant> jtv: can't you refactor it so you can pass in an arbitrary name and email?
<wgrant> And do the celebrity thing.
<jtv> wgrant: arbitrary?  I don't like arbitrary.
<wgrant> Since that's more correct.
<wgrant> And it will work.
<jtv> There's no need to refactorâwe can pass in a user identitiy.
<wgrant> Without creating a real DB celebrity?
<jtv> AFAIK there's no such thing as a "real DB celebrity."  The celebrities exist as a collection of items in the python code.
<jtv> The items themselves are regular user identities, teams, language objects, etc. etc. etc.
<spiv> Oh nice, codebrowse OOPSes are viewable finally: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1713CB6
<wgrant> Right.
<mwhudson> spiv: hurrah
<thumper> mwhudson: hey
<thumper> mwhudson: congrats on the house
<thumper> mwhudson: my branch-distro change has been reviewed by gmb, but I was wondering if you could cast your eye over it too?
<mwhudson> thumper: thanks
<wgrant> Insurers defeated?
<thumper> https://code.edge.launchpad.net/~thumper/launchpad/branch-distro-avoid-scan/+merge/36103
<mwhudson> thumper: i think it looked fine, i'll have another quick look
<mwhudson> wgrant: yeah
<thumper> mwhudson: thanks
<wgrant> Well done.
<thumper> mwhudson: also, how do we QA this?
<thumper> mwhudson: should we copy a bucket load of branches to staging?
<mwhudson> thumper: hmm, yes, i guess you can run a query to delete 90% of the seriesbranch links for maverick on staging
<mwhudson> thumper: the branch looks fine
<thumper> cool
<thumper> thanks
<mwhudson> thumper: then get the ids of the branches that are still official, get a losa to copy the those branches to staging (they have a script for this)
<mwhudson> then run the script on staging
 * thumper nods
<mwhudson> think that should work fine
<jtv> wgrant: one thing is clearâif someone hadn't changed the default from a celebrity to branch.owner, then this other bug wouldn't have bit us.  It's infuriating.  A combination of changes that we were unaware of.
<jtv> And there wasn't even a Code bug for this that I could find.
<wgrant> jtv: It didn't really change from a celebrity.
<wgrant> bzr started requiring explicit whoami.
<wgrant> So Code started setting it, overriding the default.
<wgrant> Which happened to look like a celebrity.
<wgrant> (I'm afraid that I filed the bug which caused bzr to require whoami)
<jtv> wgrant: well, a "special user"âwhich is pretty close to being a formal celebrity
<wgrant> Bug #549310
<_mup_> Bug #549310: bzr should not try to guess username but require setting it with whoami <easy> <Bazaar:Fix Released by parthm> <https://launchpad.net/bugs/549310>
<jtv> Easy indeed.
<wgrant> Heh.
<jtv> wgrant: thanks for digging this stuff upâwe're only at the receiving end of this and don't have much of a grasp of the work that went into making it broken.
<jtv> So to speak.
<wgrant> jtv: This is the problem with having a thoroughly partitioned team, I suppose.
<jtv> wgrant: that's definitely part of it, but we're not supposed to be this thoroughly partitioned.
<jtv> In this case, ironically, the bzr and code teams worked together to fix the problems but communication between launchpad teams broke down.
<jtv> phone call
<spiv> lifeless: I see in your latest performance mail you used "@" rather than "at".  That's what I call dedication!
<lifeless> spiv: hah, was a marathon dive. I was a tad tired.
<poolie> hello jtv
<jtv> hi poolie
<poolie> jtv i'm so glad we got to hang out briefly in .nl, i feel like i know you much better
<jtv> poolie: likewise
<lifeless> poolie: did you have any luck with flags<->memcache?
<poolie> haven't got to it yet sorry
<poolie> should soon
<lifeless> no worries
<lifeless> interested not panicing
 * thumper takes kids swimming
<thumper> will be around later
<poolie> zarro mail! i'll look at memcached now
<poolie> lifeless: was that in devel? or db-devel?
<lifeless> devel
<poolie> k
<lifeless> or db-devel, either will do
<lifeless> but I've been landing this stuff on devel
 * poolie runs it up
<poolie> could someone please sponsor landing of https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173
<StevenK> poolie: I sure can, let me branch that
<poolie> thanks
<lifeless> poolie: sorry blah I've been meaning to do it
<lifeless> grah
<lifeless> ForbiddenAttribute: ('_getOfficialTagClause', <SourcePackage <Distribution 'Debian' (debian)> <DistroSeries u'woody'> <SourcePackageName 'mozilla-firefox'>>)
<poolie> np, there's also https://code.edge.launchpad.net/~mbp/launchpad/flags-webapp/+merge/32967
<poolie> which is only doc changes and could arguably land without ec2
<lifeless> garh I hate interfafces
<lifeless> too dan opaque
<poolie> hm i wish i'd added the ui to see the flag rules :)
<poolie> lifeless: so istm that you're getting back None because there are no flag rules defined on production
<lifeless> poolie: we added one to staging to teset
<poolie> i don't see any there either
<lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342/comments/3
<_mup_> Bug #634342: need a features 'scope' for page ids <flags> <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342>
<poolie> unless maybe it's gone now?
<lifeless> deleted it afterwards
<lifeless> see that comment, it has the sql that tom ran for me
<poolie> ok, i'll test it locally
<poolie> lifeless: ok, the sql was wrong
<poolie> should have been 'pageid:BugTask:+index'
<poolie> however, it is a bug that it's possible for you to so easily get it wrong
<lifeless> garh
<lifeless> and i wrote that code n all
<poolie> np
<poolie> silent fail is a poor policy
<lifeless> well
<poolie> i think we probably want to give warnings in the edit/view gui
<poolie> not per page request
<lifeless> yes, if we had one :P
<poolie> soon/next
<poolie> might go out for fresh air first
<poolie> also we need standardization
<poolie> you use 'disabled', soyuz uses 'off'
<poolie> this will become chaotic
<lifeless> I think some constants would be nice
<lifeless> or enums
<lifeless> I think we can survive with different values as long as its self documenting in some fashion
<poolie> right, maybe something like a registry
<poolie> i want something lightweight and that allows the db to be slightly out of sync with the code, without laying too mny traps
<lifeless> yeah
<lifeless> being out of sync is normal for this design :)
<poolie> ok back to the gui now
<StevenK> poolie: That MP I'm going to land is targeted to db-devel, did you want it tossed at devel?
<poolie> i don't know!
<poolie> where should it go
<poolie> :)
<lifeless> is it safe to deploy now?
<StevenK> poolie: There's a simple rule for it. devel unless you touch the database
<StevenK> lifeless: It only changes the test infrastructure
<poolie> which one are we talking about, flags-webapp, or mbp-trivial?
<lifeless> devel
<StevenK> The latter
<poolie> ok, mbp-trivial
<poolie> in that case both are safe for devel
<StevenK> I'm just fighting with my own branches as well
<poolie> i was just thinking about adding a machine readable plain text view of the flags
<poolie> this is probably less useful than a human usable editor
<poolie> it might be an ok baby step towards it?
<lifeless> its a good start
<lifeless> secure it to duck + launchpad devs
<lifeless> and we're able to start seeing whats up
<poolie> yeah, that's a good policy question
<poolie> the settings should be private?
<poolie> i'm torn
<poolie> in a sense, since the code is open, it shouldn't matter
<poolie> otoh if we're dealing with a crisis, perhaps it is better to have it public
<poolie> s//better not to
<lifeless> I think users should see the settings that apply to them, in principle.
<lifeless> Thats quite different from seeing all the settings.
<lifeless> as an example
<lifeless> if we have a private team
<lifeless> which represents a customer
<lifeless> and we want to give them a longer timeout
<lifeless> google shouldn't index the fact they are a customer ;)
<poolie> good example
<poolie> wfm too
<persia> Probably best to have most policy private: for the same reasons, probably best to push most of that to admin-adjustable configuration rather than code.
<lifeless> persia: thats what we're doing
<poolie> that's the whole point:)
<persia> Indeed, just adding justification to the choice to make it private :)  Please continue with your excellent work.
<poolie> lifeless: and write access should be only ducks?
<poolie> that would be ~admin?
<StevenK> ~admins
<poolie> right
<lifeless> poolie: yes
<lifeless> person.isAdmin
<lifeless> or something like that
<mtaylor> https://code.edge.launchpad.net/~mordred/+recipe/trunk-nightlies
<mtaylor> that page crashes chromium for me
<mtaylor> fwiw
<StevenK> poolie: Your branch fails to merge against devel with a conflict
<StevenK> poolie: Er, your mpb-trivial branch, that is
<poolie> thanks, i'll update it
<poolie> StevenK: i'm pushing an updated mbp-trivial now
<poolie> StevenK: pushed
<StevenK> poolie: Thanks, throwing at ec2 now
<poolie> thanks and just to be sure, you mean ~launchpad-dev?
<poolie> i guess even non-canonical staff in there will be quite trusted
<lifeless> ~launchpad
<lifeless> thats canonical only
<lifeless> and is the one i meant
<poolie> glad i asked
<poolie> is it tasteful to test access control by checking the test browser raises an exception?
<lifeless> not really :)
<stub> Anyone else get the feeling they have lost responses from ec2 recently?
<thumper> wallyworld__: around?
<wallyworld__> thumper: yes
<thumper> wallyworld__: ETOOMANYUNDERSCORES :)
<thumper> wallyworld__: skype?
<wallyworld__> ack
<poolie> lifeless: uh, thanks, so what would be a tasteful way?
<lifeless> generally:
<lifeless>  - security is on model objets (permits API exposure)
<lifeless>  - check from a unittest in the databasefunctionallayer that you cannot access the model objects
<lifeless>    other than as the user types you care about
<lifeless> you may want to have two sets of model objects that talk to the same db or something? I'm not 100% sure here.
<poolie> i'll look around a bit more
<adeuring> good morning
<lifeless> poolie: rephrasing: I think that getFeatureFlag is safe and narrow and anyone can use it; the deeper APIs shouldn't be exposed over the model etc to anyone but launchpad & admins.
<poolie> hm, interesting
<poolie> so i was imagining i would change the permission in the browser config
<poolie> but perhaps it should be at a different level?
<lifeless> yeah
<lifeless> all security is meant to be at the model layer
<lifeless> (because the API uses the model directly)
<lifeless> this may be a mistake, but its not something I've thought deeply about yet.
<jml> hello
<poolie> hello jml!
<jml> poolie, hi :)
<jml> poolie, did I see you mention that dkim is working?
<lifeless> jml: https://bugs.edge.launchpad.net/launchpad-registry/+bug/644977
<_mup_> Bug #644977: ProjectMilestone is inconsistent, confusing ui, can we just delete it? <Launchpad Registry:New> <https://launchpad.net/bugs/644977>
<poolie> lifeless, this is interesting, because it naively seems to mean that code running as me is allowed to read and summarize data that i'm not allowed to read myself
<lifeless> jml: the things you find trying to improve performance
<poolie> perhaps this is not surprising if we define "model" in the right way
<poolie> jml, it's already working for mail other than creating new bugs
<jml> poolie, ahh, nice.
<poolie> also, i'm happy that our devops practice got a bit better, in that i can now see the log output myself rather than nagging a losa
<jml> poolie, +1
<bigjools> good morning all
<jml> poolie, we've got a lot of room for improvement in that area
<lifeless> poolie: perhaps. zope security can be very granular and capable
<poolie> if someone reviews/sponsors https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985 for me then it will work for mail creating new bugs too
<jml> poolie, lifeless may have mentioned once or twice that he has an interest in increasing transparency :)
<poolie> i'm mildly amused that adding debug log messages caused on "omg what's happening?" moment :)
<spm> jml: you've become a master of understatement lately?
<poolie> 'cos of them being mailed by default
<jml> spm, heh :)
<jml> poolie, I'll take a look at your branch now
<poolie> lifeless: so i need separate interfaces for "read feature flag rules" and "write them?"
<jml> poolie, should I still also look at jam's lp-serve branch?
<poolie> jml, i am a babe in the woods so please review thoroughly
<lifeless> poolie: no, one interface
<poolie> jml, jml's branch is pretty big but getting some review would be great
<mrevell> Hello
<poolie> it's a bit smaller than it looks because it's based off db-devel or something
<lifeless> poolie: configure.zcml can specify what access (e.g. Launchpad.Edit) is needed for what attributes
<lifeless> poolie: and you write a small policy adapter to say how e.g. Launchpad.Edit is determined for a given Model object.
<poolie> can you point out a likely good example of doing this?
<jml> poolie, look in lp/code/configure.zcml for IBranch, and in c.l.security for AccessBranch...
<lifeless> ^
<poolie> ah i should have known that one would be elegant :)
<lifeless> bigjools: hey
<lifeless> wgrant: around?
<bigjools> lifeless: good day
<lifeless> hey bigjools
<lifeless> so, your pet performance problem
<lifeless> how reliable is the code?
<bigjools> I don't have any pets, just problems
<bigjools> which one? :)
<jml> poolie, well, it's not exactly elegant, but it'll be a little easier to follow since you are probably very familiar with branch access.
<lifeless> like, if I start madly shuffling am I likely to run into zomg moments?
<bigjools> lifeless: which performance problem?  I have many.
<lifeless> ArchiveResource:Entry:sync or whatever it was
<bigjools> ah the package copier
<lifeless> like, if I were to do a spike to it like my soon-to-land BugTask:+index spike
<lifeless> am I heading into a disaster, or just a moderate risk
<bigjools> lifeless: it's an extremely sensitive area and I am not convinced that the test coverage is good.  But it needs love.
<bigjools> if the package copier doesn't do its job it has the potential to break the publisher
<lifeless> ok, no hack n slash spike then/.
<bigjools> but please don't let me put you off :)
<bigjools> yeah you can't throw test hacks at it
<lifeless> oh, I wasn't suggesting tests ;)
<lifeless> just Refactoring. With a Capital R.
<bigjools> lifeless: also I'd like to try and CP jelmer's b-m changes
<bigjools> it may solve a metric asshat load of problems
<lifeless> cool
<bigjools> but I need a real quick way of backing it out in case of issues
<lifeless> so, I suggest: put together a CP branch with just *that* in it, for Monday.
<lifeless> I'll Cp up to 11565 tomorrow
<lifeless> when you deploy, if there is aproblem the losas can rollback to the revision before with a single command.
<lifeless> the time-to-restore would be about 30 minutes
<bigjools> it needs a cron job too
<lifeless> trivial to turn that on/off.
<lifeless> how does that sound spm ?
<mthaddon> he's EOD-ed
<lifeless> ah
<lifeless> mthaddon: how does that sound to you?
<mthaddon> but it sounds somewhat cowboy to me - that we're thinking of CP-ing something we're not sure about
<lifeless> mthaddon: its been QA'd AIUI.
<lifeless> mthaddon: but its soyuz, we often have problems post major rollout with the builddmaster anyway.
<bigjools> the problem is that we don't have a test build farm with 60 builders.  We can *never* be sure about the buildd-manager.
<bigjools> we can be confident, but not sure
<lifeless> mthaddon: it makes sense to me to do a single change, with a single simple rollback rather than bundling it in with the massess in 3 weeks time
<bigjools> +1
<lifeless> mthaddon: lower risk, shorter recovery.
<mthaddon> and more losa time :) I'm just whining, don't mind me...
<lifeless> mthaddon: yeah, I appreciate that.
<lifeless> mthaddon: and that you're flat chat.
<lifeless> mthaddon: this particular CP we're discussing is significant because it may make a lot better use ofa ll the builders
<lifeless> mthaddon: which will reduce 'are were there yet' questions to you.
<lifeless> :)
<mthaddon> yep, I think I've seen chat about this one
<lifeless> bigjools: ok, so rc=me for that when you put the cp branch together just ping me
<bigjools> ok ta
<lifeless> bigjools: if you get it fully organised friday
<lifeless> then on monday, once stevenk starts, I'll ask spm to do it, so it can be running with data when you start.
<bigjools> well
<bigjools> hang on, OTP
<lifeless> sure; or it can wait for you, i don't mind :)
<lifeless> my main point is that we should not do it before the weekend ;P
<StevenK> Yes, if we do it on Friday, it WILL break on Sunday
<stub> Anyone know where all those rubbish ZCML load DEBUG log messages are coming from on script startup? They should be DEBUG2 or lower.
<lifeless> sorry, no idea - I haven't seen them.
<lifeless> jml: I have fixed up the expected test fallout
<jml> lifeless, which expected test fallout?
<lifeless> from my bugtask:+index
<lifeless> mainly little things
<jml> ahh.
<lifeless> http://bazaar.launchpad.net/~lifeless/launchpad/bugtask+index/revision/11587 if you want to eyeball it
<StevenK> wgrant: Did you end up playing with LP on 9.0?
<bigjools> ok lifeless I am off TP.   I will prepare a CP ready for Monday.  I'd like to be around when it's rolled out though.  We also need extra logs synced etc, so it will be a little complicated.
<jml> lifeless, looking now
<lifeless> bigjools: ok; document it all on LPS as normal :)
<jml> lifeless, "        # The view caches, to see see different scenarios, a refresh is needed." Two "sees"...
<jml> lifeless, also, why the change to @property syntax in model/milestone.py?
<lifeless> jml: see the change in lib/lp/registry/model/projectgroup.py
<jml> lifeless, oh right. ugh.
<jml> lifeless, presumably the vocabularies is the same
<lifeless> jml: yes, I can add an XXX there, but one is really enough I think
<jml> agreed.
<lifeless> anyone wondering will find it pretty quickly.
<jml> lifeless, I was just thinking... "you know you're abusing your fancy component architecture when..."
<lifeless> jml: when you're using it ? :)
<jml> lifeless, har har.
<lifeless> jml: so was that revision ok?
<lifeless> poolie: your lep update
<lifeless> I think you had a public<->private typo
<jml> lifeless, yeah.
<jml> lifeless, I think it uncovers a fair amount of tech debt
<jml> lifeless, but what can you do?
<lifeless> jml: apply flamethrowers?
<lifeless> halt()ing time I think
<stub> jtv: Do you know what test_main_leaves_oops_handling_alone in test_translations_import.py is actually trying to test?
<jtv> stub: nope
<jml> lifeless, do you have a list of cronjobs that we are actually running in production?
<jml> lifeless, or know how I'd find one?
<lifeless> jml: its a losa question atm
<jml> lifeless, ok, thanks.
<lifeless> jml: I'd like to get this more managed and accessible by devs but it hasn't hit the top of my 'most leverage' list yet.
<jml> lifeless, understood.
<lifeless> mthaddon: thanks for progressing the new librarian stuff; I'm excited to see it getting close.
<jml> lifeless, glad it's on your list, and agree re priority.
<lifeless> gnight
<mthaddon> o/
<wgrant> StevenK: No. I might over the weekend.
<wgrant> bigjools: I'm reasonably confident in the latest b-m changes.
<wgrant> My main fear is that it might be too slow.
<wgrant> And we'll get a backlog of uploads.
<bigjools> wgrant: that's good, and bad
<bigjools> but I doubt we'll get a backlog
<wgrant> I guess it's a whole lot faster due to the lack of initZopeless.
<wgrant> So it should be OK.
<bigjools> if we do, it doesn't matter
<bigjools> they'll get processed eventually
<wgrant> lifeless: You rang?
<bigjools> we can keep an eye on it and figure out a way to throttle the b-m back if that happens
<wgrant> I guess it can be no worse than it is now... not that that's saying much.
<noodles775> l
<gmb> Anyone know how I get testrepository to just give me a list of the failing tests rather than all the output?
<jml> gmb, if you're using trunk, testr failing --list
<jml> gmb, if you aren't, headbutt lifeless until he does a release
<jml> gmb, or...
<jml> gmb, testr failing --subunit | subunit-ls
<gmb> jml, I guess I'm not using the trunk. Thanks.
 * gmb adds "headbutt lifeless" to his todo list.
<jml> gmb, I only added the support recently.
<jml> still pending is my patch to make 'testr load' display output incrementally
<gmb> Fair enough.
<jml> bigjools,
<jml> bigjools, https://code.edge.launchpad.net/~jml/launchpad/buildd-deferred-fo-sho/+merge/36188
<deryck> Morning, all.
<jml> bigjools, https://code.edge.launchpad.net/~jml/launchpad/buildd-slavescanner-bustage/+merge/36187 is being tested in ec2 as we speak
<jml> bigjools, http://paste.ubuntu.com/498394/
<jml> noodles775, have you disabled test_runAll_mails_oopses on devel?
<noodles775> jml: no, I landed the testfix on db-devel only.
<jml> noodles775, I see.
<jml> noodles775, the failure is affecting my branches that are targeted at devel
<noodles775> jml: can you reproduce it locally? or just on ec2 test?
<jml> noodles775, I'll try to now.
<noodles775> if it's just on ec2, and its your only failure, why not merge the testfix rev and land your brach?
<noodles775> OK.
<jml> noodles775, yeah, I might do that.
<jml> noodles775, still don't know if it's my only failure, only kicked off the test run three hours ago.
<wgrant> Bug 645127 is awkward.
<_mup_> Bug #645127: Release files list wrong architectures for maverick <Soyuz:New> <https://launchpad.net/bugs/645127>
<jml> bigjools & I are just out for a couple of hours for lunch & errands.
<bigjools> we are
<noodles775> jml: See lifeless' comment on bug 644984 too... might be worth checking whether your ec2 run included that rev.
<_mup_> Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984>
<noodles775> Enjoy :)
<gmb> Dear lib/lp/bugs/stories: Die in a fire. No love, Graham.
<wgrant> Erm.
<wgrant> https://edge.launchpad.net/ubuntu/+source/firefox/3.6.10+build1+nobinonly-0ubuntu3/+build/1970234
<wgrant> Failed, but without a log or anything.
<wgrant> What?
<wgrant> Maybe failure counting.
<stub> gmb: Can you think of anything in the checkwatches stuff that might be resetting the Python logging system?
<gmb> stub, Not off the top of my head. Can you give me more context on the problem?
<stub> I'm reworking logging for all the LaunchpadCronscripts and checkwatches isn't playing nice.
<stub> I see a debugger in my future
<gmb> stub, Checkwatches uses the default LaunchpadCronscript logging stuff as far as I know.
<stub> Yer, I can't see why things are misbehaving either.
<stub> Maybe tomorrow with a fresh head
<bac> hi jam.  i just merged new devel with your branch and all of the previously failing tests pass locally.
<bac> jam: if you could merge devel and push your branch back to LP i will send it directly to PQM
<bigjools> wgrant: the b-m was restarted at that time, I've retried it
<wgrant> bigjools: Thanks.
<wgrant> Was killing my scripts.
<bigjools> heh
<wgrant> Why would it have ended up in that state, though?
<bigjools> NFI
<wgrant> A little concerning.
<bigjools> yes
<bigjools> but I'm not going to look into it since that aspect will be changing soon
<wgrant> True.
<mars> noodles775, ping re: your feature flags branch
<noodles775> mars: yup? Which one?
<mars> noodles775, either of them :)
<mars> noodles775, I was talking with Martin last night about a test helper for adding features
<mars> I was looking at adding something to a new lp.features.testing module
<mars> noodles775, do you already have code to do this, and if so, have the branches landed?
<jam> bac: will do, though pqm merges into devel, right?
<jam> (seems a bit spurious to merge devel to merge into devel)
<noodles775> mars: I emailed the dev list with the code I'm using to create the flag in my test... but lifeless also replied pointing out that the memcached test is a better one to base it on.
<bac> jam; you're right
<mars> noodles775, ok, then I'll copy the memcache test for my own helper.  Are you landing your work today?
<bac> jam: i usually do it anyway just to ensure there are no conflicts
<bac> jam: but i've proven that locally
<jam> yeah, I just tested it, no conflicts
<jam> still want me to push that up?
<noodles775> mars: the example that I pasted in the email is already landed on db-devel, but I was going to update it in another branch... but I'll wait until your helper is there.
<noodles775> (my example was from lp.registry.browser.tests.test_series_views
<noodles775> )
<mars> noodles775, alright, that sounds good to me.  I'll let you know and reply to the list thread once it is coded.
<noodles775> Great, thanks mars
<mars> noodles775, did you file a bug for the buildbot test failure XXX this morning?
<mars> leonardr, did your branch with lifeless patch land?
<leonardr> mars, it didn't land last night because i screwed up the commit message
<leonardr> let's see if it's landed now
<jml> mars, yes, he did. It's https://bugs.edge.launchpad.net/launchpad-foundations/+bug/644984
<_mup_> Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984>
<mars> thanks jml.  Trying to coordinate the fix for this.  leonardr has something landing that may do the trick.
<leonardr> mars: i'm still in pqm
<mars> out of curiosity, how long has it been there?
<mars> leonardr, ^ ?
<leonardr> mars, less than 30 minutes, i'd say
<mars> ah, ok, np then
<jml> mars, PQM is taking about 30 mins per branch
<noodles775> mars: yep, bug 644984
<_mup_> Bug #644984: test_runAll_mails_oopses fails sometimes <Launchpad Foundations:New> <https://launchpad.net/bugs/644984>
<mars> jml, yeah, that is why I was asking :/
<jml> mars, you should make it take less time
<jml> mars, that would be rad
<mars> lol
<bac> hi matsubara, you were the last to upload the PPA for bzr-pqm to the launchpad PPA.  would it be easy for you to push the new version up for maverick?
<matsubara> bac, I copied from the lucid archive to the maverick one. let's see if that will work. in case it doesn't, I'll try to build it again for maverick
<bac> matsubara: as usual, you rock!
<cr3> gary_poster: about what you said yesterday that z3c.recipe.scripts should be my one stop shop, or something along those lines, I should replace zc.recipe.egg with z3c but what about zc.recipe.testrunner? should I also try to just use z3c.recipe.scripts unless I have a really good reason?
<gary_poster> cr3: I meant in comparison with zc.recipe.egg.  zc.recipe.testrunner has also been updated, so it's good to use
<gary_poster> cr3: I saw your email, but I kind of want to get to other tasks first.  Lemme review now since you are hear to see if I have any flyby comments...
<cr3> gary_poster: ok, I started playing with it and I noticed a buch of repetitive lines in the array assigned to sys.path[0:0]
<cr3> gary_poster: when you're ready, no rush. at least I have a pretty good grasp of the problem now, so I can workaround to continue working and wait a bit for a real solution
<gary_poster> ok great news cr3.  But rereading now...
<gary_poster> cr3: in regards to your patch, that code comes directly from your local site.py--which is at least a tiny bit odd TBH, because a clean Python generally does not ship with pkg_resources.  Is this maverick?
<cr3> gary_poster: lucid
<gary_poster> me too.  Py 2.6?
<cr3> gary_poster: yep
<gary_poster> weirrrd.
<abentley> gary_poster, have you ever dealt with itertools.groupby and security proxies?  It uses a custom iterator, so I had to return a redundant generator expression.
<abentley> gary_poster, patch line 303: https://code.edge.launchpad.net/~abentley/launchpad/incremental-diff-driveby/+merge/36156
<cr3> gary_poster: I'm starting to lean towards including pymodules within site.addsitepackages, but I'm not particularly comfortable with that
<gary_poster> cr3: as a workaround, whatever, I guess.  as anything that lasts longer than a week, "augh" and "horrible" come to mind. :-)
<cr3> gary_poster: what's making me particularly uncomfortable about all the *.recipe.* scripts is that they don't seem to behave the same, so if a script is built with zc.recipe.testrunner, it might run just fine, but another script built with z3c.recipe.scripts, might not run at all :(
<gary_poster> cr3: they are built the same (they delegate in fact), so the difference is almost certainly configuration.  As I said yesterday, your config was broken, and I only fixed a bit of it.
<cr3> gary_poster: I'll give the configuration a makeover then :)
<gary_poster> abentley: I have not.  why don't you want the custom iterator security proxied?  (__iter__ is supposed to be always allowed, I think)
<abentley> gary_poster, __iter__ was not allowed.
<jml> gary_poster, hello. I have a question that is co-incidentally related to abentley's question.
<gary_poster> abentley: can I put you in the queue or do you need this now?
<jml> gary_poster, I would like to return Deferreds from things that are wrapped in the security proxy
<abentley> gary_poster, I want the custom iterator to have the same behaviour as the generator expression does.
<abentley> gary_poster, you can queue it.
<gary_poster> jml, I repeat the same question I gave abentley.  My stack is pretty deep right now, and I'd like to move to a queue instead :-)
<gary_poster> thanks abentley
<jml> but of course, when you try to use those Deferreds, you guess... ForbiddenAttribute: ('addErrback', <Deferred at 0xd4cef80  current result: ('BuildStatus.Building', 'OkSlave BUILDING')>)
<jml> gary_poster, sure. I'll puzzle it out myself for the nonce.
<gary_poster> I'll try to get back to you guys in just a few
<bac> hi mrevell
<mrevell> hey bac
<dobey> on a bug when i "Target to release" and select multiple series for a project, how do i know which series a bug_task is for, when looking at the tasks on a bug in the API?
<bac> hi mrevell, i need your wise cousel on some wording changes
<bac> it was "3 active reviews or unmerged proposals".  i found that to be a mouthful, cluttery, and it broke my portal.
<bac> mrevell: i'd like to just say "3 active reviews"
<jml> bigjools, http://paste.ubuntu.com/498561/
<gary_poster> OK, abentley.  If you look for _iteratorChecker in eggs/zope.security-3.7.1-py2.6-linux-x86_64.egg/zope/security/checker.py you'll see what default iterator security checkers are provided to let iteration through.
<gary_poster> You can provide your own for whatever builtins also--don't do it thoughtlessly, because it does have security implications, of course, but I think your example is perfectly fine--in lib/lp_sitecustomize.py for now.  You'll see something similar there already for bzr bits.
<gary_poster> If, as I understand, the problem you are having is with a Python builtin, that should actually go in zope.security eventually.  If you would file a bug in https://bugs.edge.launchpad.net/zope.security I would appreciate it.
<gary_poster> now moving on to jml...
<jml> gary_poster, done :)
<jml> gary_poster, well, sort of.
<jml> gary_poster, but I'd love to hear your opinion.
<jml> gary_poster, as I see it, there are two approaches: defining Deferred in our zcml as a class with allowed attributes, or doing something directly with checkers in lp_sitecustomize.py
<jml> bigjools, ^^
<jml> (which, incidentally, I only just learned about)
<jml> gary_poster, is either preferable to the other, really?
<gary_poster> jml, for the original intended use case of the security system, I think we would need to think hard about whether things like addErrback and other mutation-y things should be allowed generically.  In our case/usage, I think the clear answer is "yes."  Therefore, I'd register something allowing access to the whole deferred API.  My mechanism preference is ZCML because the deferred is not a builtin and not an oddba
<gary_poster> "look, just allow all the bzr branch classes hierarchically please".
<gary_poster> So, just for consistency, doing it in zcml is preferred IMO
<jml> gary_poster, ok, thanks.
<gary_poster> np
<jml> gary_poster, fwiw, addCallback and addErrback are essentially necessary to actually use a returned Deferred object.
<gary_poster> can't you look at the result without them?
<gary_poster> the current result
<jml> gary_poster, only if it has fired.
<gary_poster> ah, of course
<jml> better is asynchronous when you are everything.
<tyarusso> Okay, has *anyone* managed to get a production Launchpad instance up and running from the available code, including identity provider?  I can't for the life of me get it all working from the READMEs...close, but no cigar.
<jml> bigjools, can you pls approve this here: https://code.edge.launchpad.net/~jml/launchpad/recipebuilder-expect-deferred/+merge/36336
<dobey> hrmm, should i poke someone in particular re: bugs api?
<rockstar> dobey, any one of the following: deryck, gmb, allenap, adeuring, bryceh, or bdmurray.
 * rockstar is feeling all nostalgic at the PQM queue.
<dobey> heh
<deryck> I was about to break for lunch.  Maybe gmb or adeuring can help with the question.
<deryck> but what was the question dobey?
<dobey> on a bug when i "Target to release" and select multiple series for a project, how do i know which series a bug_task is for, when looking at the tasks on a bug in the API?
<dobey> deryck: ^^ that :)
<deryck> dobey, so how do you get from bugtask-->series via the API?
<deryck> is that the question?
<dobey> yeah. if there's a bug which affects multiple series of a project, the bug magic in tarmac doesn't work right, and i'm trying to fix it, but i don't see an obvious way to get the series id for the bug task
<deryck> dobey, it's not exported, I don't think.  Looking to confirm....
<bdmurray> at least with Ubuntu I believe it appears in the bug target name
<bdmurray> but you have to parse the string which is rather lame
<dobey> bdmurray: like "ubuntu/lucid"?
<deryck> yeah, it's definitely not exported.
<bdmurray> task: upower (Ubuntu Maverick)
<bdmurray> dobey: ^
<dobey> well that's the display name
<dobey> hrmm
<dobey> ok it looks like bug_task.bug_target_name has the information, but i have to parse it a bit and do some magic
<bdmurray> yes, that's what I was saying
<dobey> thanks
<dobey> i suppose i should file a bug against malone to expose it properly, too
<deryck> dobey, yes, please.  Though I'm curious for such an obvious thing why it was never exported before.
<deryck> maybe just oversight
<dobey> could be
<jam> bac: \o/ it landed :)
<jam> quick question to anyone, when does db-devel and devel get synchronized?
<jml> jam: db-stable is merged into devel post-release
<jml> jam: stable is merged into db-devel as soon as there's a change to stable.
<dobey> ok, another question. how do i get the series for a merge proposal or branch, from the API? :)
<jml> jam: https://dev.launchpad.net/Trunk
<dobey> oh, probably have to parse branch.name perhaps? or the target bzr_identity?
<jml> dobey, not all branches have a series
<dobey> jml: yes, but for the ones that do?
<dobey> any branch of a branch that has a series, has a series, right? :)
<jml> no
<dobey> ok. well for the proposals/branches that do have a series, how do i get the series id from the API for that proposal/branch?
<jam> jml: in all fairness, I don't see where on that page it says when db-stable is merged into devel
<jml> jam: oh, I think there's another page somewhere
<jml> jam: sorry, I had meant to say "Here's where you can learn more", rather than "Here's where you should have checked"
<jam> it seems to describe the forward links (devel => stable => db-devel => db-stable)
<jml> jam: multi-tasking.
<jml> https://dev.launchpad.net/Trunk/Glue
<jam> which I think I did know, but was good to refresh
<jml> maybe that mentions a thing.
<jam> nope
<jml> got wiki edit?
<jam> I believe so, I'll put a quick bit in the "Where's trunk" blurb
<jml> thanks.
<jam> I don't think I have a good way of updating the graphs :)
<jam> jml: thanks for the info, page updated
<dobey> so i guess the answer is that it's impossible to get a series from a branch or proposal? :(
<jml> dobey, I don't know, sorry.
<bac> hey jam, in the future be sure to have a conversation with your reviewer about landing the branch.  i think i just assumed you could do it.  thanks again for the fix.
<jml> dobey, if I were trying to figure it out, I'd look in the Launchpad codebase to figure out how bzr_identity works
<jml> dobey, remember also that a branch can be linked to many series.
<lifeless> wgrant: I did
<dobey> ugh
<dobey> well that's no good
<lifeless> sinzui: hey, in a bit I'd like to talk about 'project group milestones'
<lifeless> sinzui: are you popping out early or anything?
<sinzui> lifeless, no I will be unavailable for about 30 minutes in 1h to get children.  We might extend project group milestones to include getting milestone assignees in a single query :)
<m4n1sh> which version of oauth does LP use?
<m4n1sh> 1.0?
<jam> anyone know why 'bin/run' in my working tree is adding lp-branches/devel/lib to the path rather than adding ./lib to the path?
<jam> ok, that is just my fault running in the wrong directory.
 * jam hides
<abentley> gary_poster, thanks, I was able to solve it with your tips.  Filed as bug #645469
<_mup_> Bug #645469: No checking policy for itertools.groupby <zope.security:New> <https://launchpad.net/bugs/645469>
<mars> bac, ping
<bac> hi mars
<rockstar> Playing music with flash and doing `make schema` is a surefire way to crash X for me now.  Happens every time.
<mars> rockstar, you may want to hunt a bug # down for that.  Or you could ask Bryce - he knows a bit about the topic ;)
<rockstar> mars, yeah, these bugs only crop up when I have things to do, so I only notice them then.
<rockstar> abentley, got a quick second to chat?
<abentley> rockstar, sure.
<lifeless> sinzui: hi
<lifeless> sinzui: could we perhaps do voice?
<lifeless> sinzui: ah, you're still out, mea culpa :P I shall ping again later
<lifeless> gary_poster: I forgot one thing :)
<lifeless> gary_poster: chameleon - have a look at jtv's landing last week-or-so for distroseries:+templates
<lifeless> gary_poster: 7000 rows or something crazy - from db and rendered in 2 seconds.
<lifeless> gary_poster: by avoiding canonical_url, and tales
<mars> lifeless, do you have a moment to informally review some code for the features test helper I created?
<lifeless> sure
<mars> lifeless, http://pastebin.ubuntu.com/498725/, lines 91 and 92 are the meat of it
<lifeless> scope seems unneeded
<mars> wasn't sure
<lifeless> its an orthogonal concern, it should be an orthogonal helper.
<mars> ok
<lifeless> it will confuse and mislead people I think
<lifeless> the only code that is permitted to be concerned with scopes is the scope code itself
<gary_poster> lifeless: cool
<lifeless> all code being controlled by features has to be scope-ignorant
<mars> fixed
<lifeless> mars: you don't need to add them to the database you know, you can just use a in memory feature controller
<jcsackett> does anyone know why calling fmt:link on a sourcepackage (e.g. replace=" structure sourcepackage/fmt:link") would seem to only provide an actual link if you're logged in as admin on launchpad.dev?
<lifeless> but thats not really important either way.
<mars> lifeless, yes, but for the first round I was just going to do this.  But I agree in-memory would be much nicer.
<mars> that is one advantage of the per_thread thing I guess
<lifeless> that looks good
<lifeless> mars: no, the per_thread thing is a workaround for us not having a consistently available 'context' throughout the system.
<lifeless> mars: thanks for doing this ;)
<lifeless> don't forget the 'from __future__ import with_statement' though
<lifeless> we're still not python 2.6.
<mars> lifeless, np.  This only works for unit tests now.  The API doesn't lend itself to setting and unsetting on views or doctests, again because of the per_thread thing.
<mars> good poing
<mars> point
<Ursinha> sinzui, hi
<lifeless> mars: if you use a Fixture (from fixtures import Fixture), then in a doctest you can do 'fixture = FeatureFixture('foo'='123'); fixture.setUp()' .... 'fixture.cleanUp()'
<Ursinha> sinzui, about bug 540890, I'm not sure which oopses you want to have removed
<_mup_> Bug #540890: exclude robot posts from reports <OOPS Tools:Triaged> <https://launchpad.net/bugs/540890>
<mars> lifeless, an in-memory controller would be nicer for that actually.  MockFlagsController.set_flag()
<lifeless> I should add a contextmgr->fixture adapter to fixtures
<mars> lifeless, ah!  I was wondering about that
<mars> the fixtures bit
<lifeless> and fixtures are context managers, so can also use with
<lifeless> mars: one small thing
<mars> ok
<lifeless> rather than {dict of flags}
<lifeless> hmmm
<mars> foo(key=value) ?
<lifeless> never mind, the apis aren't close enough
<lifeless> yeah, but key can have . in it.
<mars> yep
<mars> or ':'
<lifeless> might be able to do something with **kwargs magic, but its a little freaky.
<mars> as you want to do with page IDs
<lifeless> so lets not.
<sinzui> Ursinha, The spam oopses in bugs (tcquery) and rdf oopses are caused by bots. We seem to have decided not to fix the spam inject attacks
<lifeless> gary_poster: yeah, its cool; thought that it might be a nice reference point for how to make a page fly.
<gary_poster> cool
<Ursinha> sinzui, do we have useful caused-by-robots oopses?
<matsubara> sinzui, crazy idea, how about removing all robot triggered oopses from the reports?
<sinzui> I am not sure.
<lifeless> Ursinha: yes, if they follow a local link
<lifeless> matsubara: I'm not entirely keen on that.
<sinzui> Ursinha, the attacks have no referer
<matsubara> hmm
<lifeless> sinzui: the spam injection stuff is on my radar.
<mars> matsubara, think of it as free fuzz-testing for our site!
<lifeless> sinzui: but I'm focusing on performance first
<matsubara> ok, sounds like a good criteria then, all robots with no referrer shouldn't appear in the reports
<sinzui> We fixed registry and answer spam vectors last December
<lifeless> matsubara: anything without a referrer shouldn't appear.
<lifeless> matsubara: for 404's.
<matsubara> that way we keep the benefit of free fuzz-testing and ignore robots triggering oopses we don't care about
<sinzui> Blueprints is also attacked once or twice a month
<matsubara> lifeless, that's one of the fixes we've been working on
<lifeless> matsubara: hang a second; are we talking 404s or all oopses.
<lifeless> matsubara: because its *only* 404's that I'm talking about. Other oops are important to see.
<matsubara> actually Ursinha just uploaded the branch with that fix
<lifeless> I'm confused; could we start over?
<matsubara> lifeless, any oopses triggered by a bot with no referrer header
<lifeless> matsubara: I think thats too broad.
<lifeless> matsubara: I would be happy with 'any NotFound with no referrer header'.
<lifeless> matsubara: I don't think it matters whether its a bot or a human, do you? made up urls that don't exist are not interesting from a QA perspective.
<matsubara> lifeless, filtering only NotFounds wouldn't help sinzui's use case as reported on https://bugs.edge.launchpad.net/oops-tools/+bug/540890
<_mup_> Bug #540890: exclude robot posts from reports <OOPS Tools:Triaged> <https://launchpad.net/bugs/540890>
<lifeless> looking
<lifeless> matsubara: thats true, but the other exceptions are important. I disagree about us not fixing them.
<lifeless> matsubara: we have many things we haven't fixed yet; those are definitely on the list-to-fix as far as I'm concerned.
<sinzui> lifeless, matsubara. I would be equally happy with all the search vectors patched. I get tired of reading the monthly super barrage of attacks to all locations
<lifeless> sinzui: getting rid of the 404's with no referrer will help, though it will leave the attacks in place. We will get to them.
<jam> losa ping, I have some questions about deploying a new service as part of launchpad, and I want to make sure I've worked out what you guys need, etc.
<mbarnett> jam:  sure.  hit me, and if i don't think i can give you a complete answer, i might ask you to email us so that everyone gets a chance to chime in.
<jam> mbarnett: so I have this merge-proposal up: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877
<jam> which adds a new service as part of the "bzr+ssh" chain
<jam> basically, it is something that can fork itself to provide better connection times
<jam> rather than execing a new python process
<mbarnett> right
<jam> mbarnett: as such, it will be running on the same machine that runs the Conch server now (I believe that is crowberry)
<lifeless> matsubara: sinzui: Unless there is a strong argument for why we will never have a successful attack via robots triggering exceptions, I really feel we should only filter NotFounds.
<matsubara> lifeless, well, it's not that we're not going to fix, it's just that we won't list those specific oopses in the reports. I think one of the ideas is to make the reports more useful to the devels, and having thousands of oopses in the reports that are affecting a bunch of misbehaving bots shouldn't be a priority
<mbarnett> jam: it is
<jam> since it is a running service, it seems like something the losas need to know about, so I need to get documentation put somewhere
<jam> I don't really know where that would be
<jam> also, we'd like to work out a way to stage its deployment
<sinzui> lifeless, I reported the bug on flacoste's behalf, as I said, I fixed the apps I have domain over
<jam> namely, once this code lands, we would want to activate it on staging
<jam> (via a lazr.conf setting)
<jam> and then eventually roll that flag out to production
<sinzui> lifeless, the attaches started in Nov 2009
<mbarnett> jam: yeah, we will need to know a few things.. a) how to monitor it to ensure it is functioning as intended b) expected performance characteristics (how to measure if it is succeeding and c) resource profile (what additional load it is expected to put on the server and and d) how do we make it not fork us to death  :)
<lifeless> I feel uncomfortable that the injection vectors are not totally fixed.
<lifeless> I feel terrified at the idea of having that grow or change and not seeing it.
<jam> mbarnett: well, should this be in documented form, or is irc chat sufficient :)
<lifeless> I think that the exceptions should just be fixed, we shouldn't route around it : it is a bug, it is important.
<jam> a) I did add support for making a 'hello' request on its socket
<lifeless> NotFound w/no referred isn't a bug, and it isn't important (because we handled it successfully)
<jam> I can have it report whatever information you would like
<mbarnett> jam: that is an interesting question.  I think it would be worth it to have it in a place other than scrollback.  either email or a wiki page.
<jam> which might be a good thing to integrate into the existing service reporting stuff (what is the name of it?)
<jam> (Acorn or something like that?)
<lifeless> sinzui: would it be ok for 'ProductSeries.milestones' to return the Product milestones too ?
<gary_poster> EdwinGrubbs: hi. :-) does your OOPS format work address bug 635254, directly or indirectly?
<_mup_> Bug #635254: oops request timeline should be richer <oops-tools> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/635254>
<jam> d) It will be logging to a file, and where should that file be located, and we want to make sure it gets sync'd to devpad like other log files
<sinzui> lifeless, I do not think so, I can move a product series to a different product to move the milestones... and I have no intention of moving other milestones
<jam> b) the service itself should be responsive within <1s I would expect, since it does very little before forking and handling the rest there.
<lifeless> sinzui: ah. Then how about I add a 'vocabulary_milestones' to the milestone contract
<sinzui> looks like the prescription spammer's mailer just hit the openjdk list
<jam> however, I don't have a great idea about 'load'. I can say we usually have 20+ concurrent ssh connections, but I don't know the number of new connections/second
<lifeless> sinzui: the vocab is doing too many queries; its one of the causes of slow
<sinzui> yes, then optimising that would be a very good idea
<jam> mbarnett: as an example, one graph right now: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/ this should change that graph to be much lower
<mbarnett> jam: heh
<jam> (times locally show 2.5s to connect, dropping to 0.5s which seems 95% ssh overhead)
<EdwinGrubbs> gary_poster: although I have been thinking about the different formats we will want for individual fields, my work mainly involves making it easier to separate different multiline fields.
<gary_poster> EdwinGrubbs: so it's fair to say that your work will make these distinctions possible, even though that's not the primary focus of your work?  If so, would it be ok to assign the bug to you?  (If not, of course, I won't :-) )
<mars> lifeless, when you spoke of using a fixture for the feature flags, did you mean lp.testing.fixtures ?
<mars> lp.testing.fixture
<lifeless> mars: no, 'fixtures'.
<mars> lifeless, hmm, bin/py says we don't have that module
<lifeless> mars: then you have an old branch
<mars> or goofed-up dependencies
<lifeless> indeed
<EdwinGrubbs> gary_poster: I don't think I will be allowed to work on it after I get my current branch landed. It's take surpisingly long as it is.
<gary_poster> mars, have you communicated our shared confusion about feature flags, and do you now have knowledge that you can share with me at a later date? :-)
<jam> c) resource profile => should actually decrease versus what we do today
<EdwinGrubbs> s/take/taken/
<gary_poster> EdwinGrubbs: ack, fair enough.  Thank you.
<mars> gary_poster, yep, and I am writing the test helpers now so everything becomes easier
<jam> the service itself should have low resources, <= 1 bzr serve process
<jam> and it should save some load by forking rather than starting up a new process
 * gary_poster cheers in mars' direction
<lifeless> matsubara: sinzui: on the oopses; if I haven't convinced you about the non-404's, can you perhaps mail the list so we can have a broad discussion.
<jam> and having that process do all the IO of importing lots of python code
<lifeless> I have to run out for a bit. I will be back soon.
<jam> also, it does log the rusage() of its subprocesses, which might be good to hook into some sort of report, since it may help us figure out bzr+ssh overhead issues
<mbarnett> jam: would you mind capturing what we chatted about in here in an email, and appending your operational questions (where to log to, etc..) and shooting that over?  I think this is a significant enough change (since it affects everyone using codehosting) that it would be good to have this conversation in a more explicitly inclusive way...
<jam> mbarnett: also, "email us" who is us and what is your email address :)
<mars> gary_poster, I am having some trouble picking up the 'fixtures' package in the eggs directory.  I have run 'make clean && make', but it still will not find the module.  It is not in sys.path according to bin/py.  Do you have moment to help debug this problem?
<gary_poster> mars, sure.  where's a branch?
<mars> gary_poster, devel
<gary_poster> oh?
<gary_poster> ok
<mars> gary_poster, actually
<mars> wait a sec...
<lifeless> k, back
<mars> gary_poster, argh, it is something with the setup.  This is in a lightweight checkout I have of devel.  lp-branches/devel knows about the module.  lp-branches/dev (my checkout) does not.
<mars> stale .pyc files maybe?
<gary_poster> mars, ? Don't know enough about what you are talking about.  Do I need to care, or not? :-)
<mars> I thought 'make clean' killed those
<gary_poster> doesn't look like it
<mars> ok!  That is a likely candidate then
<bdmurray> should getting ReturnToReferrerMixin to work require much effort?
<gary_poster> but getting the pyc files out of whack involves having to do odd things like touching the pyc files, or changing the py file *really* fast
<gary_poster> after it has been compiled
<mars> gary_poster, ?  Why not make the clean target nuke them all with 'find -iname *pyc -delete' ?
<gary_poster> mars, you could I guess, only in lib, but Python is really supposed to handle that for you
<mars> ah, wait
<mars> make clean does kill them
<lifeless> mars: try
<lifeless> mars: a) check that versions.cfg lists it
 * gary_poster repopens makefile
<lifeless> mars: run bin/buildout
<mars> lifeless, heh, I thought you were advocating for empirical evidence: 'try running "make clean" and see what happens :)
<lifeless> heh
<mars> gary_poster, line 343 does it
<gary_poster> mars yes it does, sorry.  I was looking for pyc in Makefile but it is -name '*.py[co]'
<mars> lifeless, so it is in the versions.cfg list - that means the code would not build if it could not find it
<mars> ... this goes to a bad place - something wrong with z3c.recipe.scripts ? :(
<lifeless> mars: now, run 'bin/buildout' no options.
<gary_poster> mars, lifeless, versions.cfg only has to do with specifying versions
<gary_poster> it has nothing to do with choosing software
<lifeless> gary_poster: ok
<gary_poster> that is done in setup.py
<lifeless> gary_poster: thanks
<gary_poster> versions.cfg is separate because it needs to handle dependencies as well
<gary_poster> as well as recipes
<gary_poster> and anything else buildout happens to tickle
<lifeless> mars: I found that after running bin/buildout it works, when I first added it
<thumper> gary_poster: want to have a quick catch up call?
<gary_poster> sure thumper
<gary_poster> ready any time
<mars> lifeless, gary_poster, and now it works!  On the third try! ARGH.
<mars> lifeless, gary_poster, thank you for the help
<cr3> gary_poster: fyi, all is well with my buildout now
<lifeless> thumper: so, how do you want to do this?
<wallyworld_> morning
<lifeless> what fantastic thing should I do today
<mars> cut the test suite runtime in half?
<lifeless> hmm
<lifeless> I wonder if I could do that
<mars> lifeless, btw, here is the code as a FeatureFixture: http://pastebin.ubuntu.com/498766/
<lifeless> mars: thats a bit unidiomatic
<mwhudson> lifeless: no downtime rollouts for cronscripts
<lifeless> one sec and I'll give you an alternative
<mars> lifeless, have an idiomatic example?  I assume you mean the addCleanup bit
<lifeless> mars: http://pastebin.ubuntu.com/498773/
<lifeless> mars: basically all the closures are unneeded
<lifeless> mwhudson: that would be lovely.
<mars> yep, as I thought
<mars> oh neat, pulling it inside the loop like that
<mars> if the loop blows up, then the cleanup still happens too
<lifeless> well, if cleanUp gets called, but yes.
<lifeless> its closer to being correct :)
<lifeless> jml: where did we leave our parallel testing spike for lp
<jml> lifeless, lp:~jml/launchpad/dirty-parry is the closest I've got
<lifeless> I'm thinking of this as a strategy:
<lifeless>  - teach testrepository to run partitioned copies
<jml> lifeless, but I've massively screwed with our ec2 tools since then
<lifeless>  - start working up parallel-safe layers, from db up - incrementally more capable.
<jml> lifeless, parallel-safe == more than once on the same machine?
<lifeless> yes
<jml> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/107371
<_mup_> Bug #107371: Make the test suite able to be run in parallel on a single machine <build-infrastructure> <feature> <test-system> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/107371>
<jml> lifeless, I think that is a win independent of testr improvements.
<lifeless> I agree.
<lifeless> however it will be easier to get a feel for the thing if I can run a single partitioned run :)
<jml> fair enough.
<lifeless> jml: I think I know why some tests don't run properly via testr after ec2
<jml> lifeless, why?
<lifeless> stories have a test id that a) is mangled - the path thing we talked about , but b) doesn't represent a runnable test.
<jml> It's because you haven't reviewed my incremental failure branch, isn't it?
<thumper> lifeless: we have the UDD meeting shortly
<thumper> lifeless: but after that we can skype to talk through the xmlrpc issue
<lifeless> UDD meeting?
<thumper> lifeless: have you not been told?
<thumper> lifeless: you should be there I think
<thumper> lifeless: on #ubuntu-meeting IIRC
<wgrant> Can someone check buildd-manager logs to see what happened to https://edge.launchpad.net/ubuntu/+source/firefox/3.6.10+build1+nobinonly-0ubuntu3/+build/1970234? The state it's in is not one that can actually occur, and it be breaking my scripts.
<wgrant> (plus it's not really awesome to have broken builds, since release is in two weeks)
<lifeless> losa ping ^ where are these logs?
<mwhudson> wgrant: surely it's ok for such an unimportant package!
 * mwhudson runs away
<lifeless> on ppc
<wgrant> lifeless: They're on devpad, from cesium.
<lifeless> wgrant: after this meeting, yes.
<wgrant> lifeless: Thanks.
<mwhudson> wgrant: failed to build but with no log?
<lifeless> wgrant: perhaps its the new das disable flag?
<mwhudson> hilariously it looks like devpad has faceplanted
<james_w> shouldn't affect powerpc?
<wgrant> mwhudson: No log, or builder, or times.
<lifeless> I thought ppc wasn't supported
<lifeless> clearly I'm wrong
<wgrant> It's not *supported*.
<wgrant> But it is there.
<wgrant> It is the only remaining community port.
<mbarnett> what he said.
<james_w> wgrant: maybe a repeated failure in dispatch?
<james_w> I guess that's why you are asking for the logs...I'll shut up
<lifeless> mbarnett: thanks
<mwhudson> that code isn't deployed yet though is it?
<mbarnett> :)
<wgrant> mwhudson: It was in 10.09.
<mwhudson> ok
<wgrant> lifeless: Do we have per-pageID timeouts on edge yet?
<lifeless> no, matsubara's branch hasn't landed
<bdmurray> should getting ReturnToReferrerMixin to work require much effort?
<wgrant> :(
<lifeless> james_w: when that 401 happens, does it perhaps take a long time to answer?
<james_w> lifeless: no idea
<lifeless> have you filed a bug ?
<james_w> I've not seen it in interactive use
<james_w> no
<lifeless> could you?
<james_w> -foundations?
<james_w> lifeless: oh, I missed the response body at the top
#launchpad-dev 2010-09-23
<lifeless> james_w: ah
<lifeless> james_w: does it give you a hint of some sort?
<lifeless> james_w: yes, -foundations
<james_w> lifeless: well, it says the nonce was used before
<lifeless> yes
<lifeless> I don't know if that indicates a bug in your code, in launchpadlib, or in the lp code.
<james_w> my code?!?
<james_w> never!
<lifeless> its quite possibly lp itself
<lifeless> one user with many api clients at once isn't a common occurence today
<wgrant> That shouldn't cause nonce reuse...
<lifeless> without checking the implementation, who knows.
<james_w> wgrant: do you know how the nonces are generated and stored?
<lifeless> OAuthNonce table
<wgrant> LP stores them in the OAuthNonce table.
<wgrant> Yeah.
<wgrant> I wonder who generates them.
<lifeless> second highest oops yesterday I think
<james_w> are they an 8 bit number and stored forever, or are we talking heat death of the universe before this should happen?
<lifeless> not quite, bit lower:
<lifeless> 8 /  112  RootObject:+login
<lifeless> oauthnonce__access_token__request_timestamp__nonce__key" UNIQUE, btree (access_token, request_timestamp, nonce)
<lifeless> the nonce itself isn't constrained to be unique.
<wgrant> Right, the timestamp has to match.
<wgrant> So a collision is less likely.
<james_w> wgrant: python-oauth by the look of it
<james_w> nonces/timestamps are only SHOULD IIRC ;-)
<wgrant> def generate_nonce(length=8): """Generate pseudorandom number.""" return ''.join([str(random.randint(0, 9)) for i in range(length)])
<wgrant> Yeah.
<james_w> 10^8 space per second?
<wgrant> Looks like it.
<james_w> I think this is the error you get if you don't re-sign on redirect, but I don't know why these requests would have been redirected
<wgrant> What are the requests?
<james_w> this one was sp.getBranch(pocket="Something")
<mwhudson> if you take n samples randomly from N options, you have about 1 - math.exp(-n*(n-1)/2.0*N) chance of getting a collision
<wgrant> Hmm.
<james_w> 1 - math.exp(-n*(n-1)/(2.0*N)) ?
<mwhudson> um
<james_w> or 1 - math.exp((-n*(n-1))/(2.0*N))
<mwhudson> james_w: well those last two are the same, right?  but they're both better than what i said, indeed
<thumper> lifeless: I think having our chat after lunch would be best for limiting the disruptions
<james_w> yeah
<james_w> bug 645640
<_mup_> Bug #645640: API gives 401 errors on occasion <Launchpad Foundations:New> <https://launchpad.net/bugs/645640>
<lifeless> sure
<mwhudson> i did this math for http://bugs.python.org/issue6598 fwiw :)
<mwhudson> how many nonces do we generate in a second?
<james_w> mwhudson: I don't know, but 100-1000 probably
<james_w> assuming they are per-access-token too
<james_w> in this case I got three 401 in 2 minutes, so I don't think it's a collision
<lifeless> RootObject:+login 204961
<lifeless> 2-3
<mwhudson> james_w: yes, that seems pretty unlikely
<lifeless> unless its per-request
<james_w> lifeless: my comment on reliability was more about tuning than large changes, so while I agree that using Launchpad's facilities makes sense, that is a fair amount of work, and doesn't buy us much in the fine-tuning department.
<lifeless> james_w: fair enough; my main goal is to get the system 'owned' by someone with it as part of their work portfolio
<james_w> lifeless: so I was thinking of things such as better heuristics for transient failures, better automatic categorisation of problems, automated linking to bugs
<lifeless> james_w: you do great, but its hardly your primary thing
<james_w> lifeless: and I'm certainly down with that
<wgrant> lifeless: What does +login have to do with OAuth?
<lifeless> james_w: OOPS-1725D1955
<lifeless> grah the pageid on that is sad
<james_w> won't load for me
<poolie> james_w: if you only need readonly access you could be anonymous
<poolie> and avoid the issues
<lifeless> james_w: https://lp-oops.canonical.com/oops.py/?oopsid=1725D1955 works for me
<james_w> poolie: this is read-write on occaision
<lifeless> poolie: anonymous may not be what you think it is ;)
<james_w> lifeless: does now
<lifeless> poolie: I'm fairly sure it allocates a token on the fly
<lifeless> poolie: which is gross in some ways
<poolie> lifeless: i think (imbw) it's only inside the app server, not in http
<james_w> that's probably me
<poolie> i agree it is a bit gross
<lifeless> poolie: its in the appserver, but thats where this problem may be too :)
<james_w> OAuthAccessToken.sourcepackagename?
<lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/645651 about the oops itself
<_mup_> Bug #645651: pageids on nonce failures are a bit bogus <Launchpad Foundations:New> <https://launchpad.net/bugs/645651>
<lifeless> james_w: no idea why thats there
<james_w> ah, because they can be restricted in scope
<poolie> lifeless: i think i'll keep pushing on flags today
<lifeless> poolie: \o/
<poolie> i meant to give it a one or two day timeslice but it feels like there's a fair momentum/inertia effect
<poolie> iow launchpad is heavy :)
<lifeless> yes
<lifeless> I wouldn't stress about doing it the right way though.
<poolie> oh btw
<lifeless> Like, practicality of purity.
<poolie> if i change my mind about naming something, i can just change it, right?
<lifeless> james_w: 755156 API requests a day.
<poolie> there are no internal api stability rules other than that the whole thing must pass it's tests
<lifeless> poolie: yes you can but its desirable, if folk are building on something, that they be able to CP it to production.
<poolie> (i don't mean gratuituously; i realize it may break outstanding branches etc)
<poolie> right
<lifeless> poolie: so do consider leaving a forwarder behind.
<poolie> sure
<lifeless> you odn't have to
<poolie> some of the naming about features vs flags etc is a bit inconsistent
<lifeless> yeah
<poolie> that's one nice thing compared to bzrlib
<poolie> so as of yesterday i have a working readonly anonymous view of the rules
<lifeless> james_w: so, 100 per second or so
<poolie> i was wondering about proposing that in parallel with adding access control
<poolie> just to be stepwise
<poolie> and because there's probably nothing privacy critical  at the moment
<lifeless> poolie: separate review, sure, but I wouldn't land it solo
<poolie> k
<wgrant> james_w: Scope restriction doesn't actually work, unfortunately.
<wgrant> It would be really nice if it did.
<wgrant> What with the rather damaging APIs that are around now...
<wgrant> Like, say, syncSource into the primary archive.
<lifeless> james_w: oauthnonce ||      79.96 tuples/sec
<mwhudson> wgrant: did you get those buildd-manager logs you were after?
<wgrant> mwhudson: I didn't.
<mwhudson> wgrant: can you tell me what to look for?
<wgrant> mwhudson: a startBuild(http://<one of adare and ross>.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3
<wgrant> I think.
<wgrant> I may have the buildd bit wrong.
<wgrant> But it will mention adare or ross in there somewhere.
<mwhudson> wgrant: any idea when?
<wgrant> date_first_dispatched
<wgrant> 2010-09-22 07:48:40.575908+00:00
<mwhudson> ah, there we go
<mwhudson> mwh@devpad:/srv/launchpad.net-logs/production/cesium$ grep startBuild.*adare buildd-manager.log | grep firefox
<mwhudson> 2010-09-22 07:48:40+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
<mwhudson> 2010-09-22 07:53:13+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
<mwhudson> 2010-09-22 07:55:09+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
<mwhudson> 2010-09-22 13:46:15+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
<wgrant> What happens immediately after the first startBuild?
<wgrant> (the 13:46 one is from when Julian retried it last night -- we presumed it was transient)
<mwhudson> looks normal
<wgrant> I wonder why it's retried 5 minutes later, then.
<mwhudson> http://pastebin.ubuntu.com/498821/
<mwhudson> 2010-09-22 07:52:19+0000 [-] <adare:http://adare.buildd:8221/> communication failed (User timeout caused connection failure.)
<mwhudson> 2010-09-22 07:52:19+0000 [-] <adare:http://adare.buildd:8221/> failure (None)
<wgrant> Gah.
<wgrant> Non-virt builders *do not do that*.
<wgrant> Ah. And I bet that retrying the build didn't reset the failure count.
<wgrant> So it was immediately killed the next time.
<mwhudson> actually
<mwhudson> http://pastebin.ubuntu.com/498823/
<mwhudson> that dispatching line at the bottom is normal?
<wgrant> I believe so.
<mwhudson> ah haha
<mwhudson> wgrant: http://pastebin.ubuntu.com/498826/
<wgrant> That's more like it.
 * thumper goes to find lunc
<thumper> lunch that is
<wgrant> However, that wasn't terminal, since the builder and job failure counts are the same.
<mwhudson> adare seems to be timing out quite a lot
<wgrant> Hmm.
<mwhudson> not like every build
<mwhudson> wgrant: http://people.canonical.com/~mwh/ppc-buildd-fail.txt
<wgrant> mwhudson: Are builders from other archs so bad?
<mwhudson> wgrant: hard to say, it's pretty bad though
<mwhudson> wgrant: yuck: http://pastebin.ubuntu.com/498830/
<mwhudson> (adare and ross are the worst though)
<mwhudson> wgrant: ppa builders, for contrast: http://pastebin.ubuntu.com/498831/
<wgrant> Hm, quite a difference.
<mwhudson> still seems like a whole lotta time out for one day's log
<wgrant> adare looks reasonably dead now :/
<wgrant> And ross just started building something that has been attempted a couple of times befor.e
<wgrant> I wonder what's going on.
<poolie> hi wgrant, mwhudson
<poolie> StevenK: what happened to https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173 ?
<wgrant> Morning poolie.
<poolie> wow, lp certainly has a big backlog of approved non-landed mps
<wgrant> They're mostly/all from people with PQM privs, though.
<wgrant> Hm. Half are more than a week old.
<thumper> lifeless: ping
<lifeless> thumper: sec
<thumper> np
<lifeless> thumper: skype?
<thumper> lifeless: just a few secs
<thumper> lifeless: yep
<thumper> https://lp-oops.canonical.com/oops.py/?oopsid=1723XMLP310
<wgrant> OOPS-1727EA92
<wgrant> That same filename works fine as an attachment on launchpad.dev
<wgrant> But not on edge.
<wgrant> (yes, yes, I do name files strangely to try to break LP)
<lifeless> \o/ bugtask:+index landed.
 * lifeless dances the happy happy dance.
<wgrant> lifeless: What did you get it down to?
<lifeless> wgrant: what I posted to the list
<lifeless> wgrant: just had various test fallout to fix - things I had missed subtlties of
<wgrant> Ah, right.
<wgrant> Yep.
<wgrant> lifeless: At what stage did the OOPS I referenced about occur?
<wgrant> The initial traversal, or some librarian trickery?
<lifeless> please wait, your enquiry is important to us
<lifeless> do doo doo, do do do-doo
<lifeless> I bet sodium has been exposed to water again
<wgrant> Heh.
<wgrant> Sounds like it needs replacing.
<lifeless> its been replaced.
<wgrant> ...
<lifeless> the problem is possibly the fs
<wgrant> Well then.
<lifeless> or similar
<lifeless> it does not like that oops
<lifeless> will try again ... later
<wgrant> k
<wgrant> Thanks for trying.
<lifeless> thumper: mwhudson: I need your rubber stamps, again.
<mwhudson> lifeless: otp
<wgrant> lifeless: Where to now? 11565?
<lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/36406 when you get a chance; just code-ok :)
<lifeless> wgrant: yes
<wgrant> Excellent.
<lifeless> spm: if you're not flat chat, could you drop http://pastebin.com/DZcgFsA1 onto staging as a cowboy? want to see if its going to blow up tonight so I can start on it now, if needed.
<spm> sure, gimme a bit tho, chasing logs for beuno atm
<lifeless> ta
<lifeless> evil: http://samy.pl/evercookie/
<mwhudson> for some reason i feel like viewing that url with netcat
<jcsackett> lifeless: you ain't kidding. that's horrid.
 * jcsackett ponders.
<jcsackett> i believe i heard about that as being by the same person who came up with the twitter xss hack.
<lifeless> security is damn hard :)
<jcsackett> ain't that the truth.
<jcsackett> at least this evercookie is open; someone can develop a plugin to kill it.
<mars> jcsackett, is that the cookie that uses the HTML5 database to store itself?
<jcsackett> mars: yeah. and uses png cookies, and every other storage mechanism.
<mars> heh, nasty
<jcsackett> link was posted above by lifeless; it's a pretty freaky thing. though tech wise, it *is* sort of impressive.
<mars> yeah, I'm not clicking that link.  I stopped clicking when the 'Gmail contacts stealing' example page was published
<mars> although I suppose I could use a Chrome incognito browser to look at it
<wgrant> Unless it uses Flash cookies too.
<mars> :/
<mars> double yuck
<benji> the png cookies are especially beautiful
<wgrant> Indeed.
<wgrant> The Web really needs to just die.
<mars> ah, here it is, the recent debacle around ad agencies starting to use these nasty techniques: http://arstechnica.com/apple/news/2010/09/rldguid-tracking-cookies-in-safari-database-form.ars
<lifeless> mwhudson: so, can has stamp ?
<lifeless> thumper: ping
<thumper> lifeless: yus?
<lifeless> please rc stsamp https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/36406
<mwhudson> lifeless: still otp
<lifeless> mwhudson: sorry, thought you weren't from the netcat comment. It doesn't actually a review, only a 'review'.
<lifeless> mars: perhaps you could ?
<mars> looking
<mars> lifeless, does the report give you that output right now?  Or did you construct it yourself?
<lifeless> mars: myself from the report
<mars> lifeless, what am I supposed to do with this?  rubber-stamp it?
<lifeless> mars: yes, its just so that ec2land will work
<mars> ok
<mars> lifeless, done
<lifeless> thanks!
<mars> lifeless, we can add that data to the text report later as well.  I already publish most of that info in the HTML report.
<lifeless> mars: it shouldn't go in the txt report
<mwhudson> storing cookies in etags is an impressively evil idea
<lifeless> what we should do though is start showing more info about the other commits
<mars> if only we could figure out how to make the vaccines for these internet diseases spread as quickly as the infections themselves! :)
<mars> it would make an awesome doctoral thesis topic
<lifeless> spm: taptap :)
<spm> still busy :-)
<lifeless> you might want to grab the pastebin before it times out ;)
 * beuno starts talking more loudly than lifeless 
<lifeless> beuno: you could do these things during your workday :P
<beuno> lifeless, I remember the days when I could...
<beuno> they where great and people didn't yell at me during a movie
<spm> lifeless: if you'd put your paste into a WEBSCALE pastebin, like, eg sqlite backed, timeout wuolnd't be a problem. that is all.
<mwhudson> :-)
<mars> lifeless, poolie, here is the new feature flags fixture in action: http://pastebin.ubuntu.com/498904/
<poolie> mars, sweet!
<poolie> is that already in devel?
<beuno> jdEC2
<mars> poolie, not yet, the branch is here: lp:~mars/launchpad/add-profiling-feature-flag
<poolie> also, i guess in non doctest code you'd use self.useFixture(FeatureFixture...)
<mars> needs landing polish
<beuno> irssi FAIL
<beuno> hi everyone!
<mars> poolie, yes, and it is very nice.  with statements also work.
<poolie> hello beuno; i just got a survey from LAN the other day saying "where would you like to go in South America" and I thought of you :)
<beuno> poolie, I would love to repeat our mini-sprint
<beuno> or just skip the sprints and do all meals!
<poolie> heh
<poolie> i wish code branches easily showed you the submit diff, even before the mp exists
<wgrant> I think everything should just have a WIP MP.
<lifeless> fileabug
<poolie> mars, so how flags work out for you?
<poolie> wgrant, that'd be another way to do it
<poolie> lifeless: i'm pretty sure there is already one
<poolie> mars i think we need more systematic naming of flags
<poolie> i don't want to sound bureaucratic here but i just think it will help when we get more of them
<mars> poolie, I think they will work well.  It will be nice to turn the request_profiling feature on and off from the UI and also control access by scope
<poolie> maybe yours should be something like webapp.profiling.enabled
<mars> poolie, yes, I pondered 'services.profiling'
<mars> or that
<poolie> or services.profile.enabled
<poolie> exactly
<poolie> matching the python module name is good, i think
<lifeless> ugh
<mars> what does FF do?
<lifeless> we have many terrible python names
<poolie> FF?
<mars> foo.bar.enabled: True ?
<mars> firefox
<lifeless> so I wouldn't match them.
<lifeless> if theres a good name, use it.
<mars> I thought about how it would look in a  UI
<lifeless> but often a flag will be interpreted in many modules.
<mars> Feature: request_profiling - ON
<poolie> so for instance
<poolie> i think 'memcache' is a poor name
<poolie> unless it really is going to turn all of memcache on and off
<lifeless> it turns all of memcache on and off
<poolie> if it's controlling memcache tal stuff more specifically, we should say that
<poolie> or vice versa
<mars> yes, that makes sense
<lifeless> poolie: it turns it on and off for all uses we have of memcache atm.
<lifeless> tal and API
<mars> yes, that too
<mars> so the current use makes sense
<mars> but if you ever get anything more fine-grained, then maybe some naming could make the flag's function more obvious
<lifeless> tight
<lifeless> bah
<lifeless> right
<poolie> mars that branch looks nice
<poolie> thanks
<mars> ok, my vision is starting to get blurry - time to sign off.  I'll land the FeatureFixture tomorrow.
<mars> Good night!
<poolie> you can cc me to the review if you like
<mars> poolie, ok, will do
<poolie> one thing, can you mention this in the servicres.features doc string?
<mars> ok
<lifeless> spm: so..
 * spm should kick lifeless from the U1 channel.... :-P
<spm> gimme 10, just doccoing what we did and taknig a bio break
<lifeless> kk
<mwhudson> here's something to try if you want to cry:
<mwhudson> host 'sdasd asdas' ns4.vpweb.com
<mwhudson> (this is the other kind of evil to what lifeless posted earlier)
<lifeless>     Hard / Soft  Page ID
<lifeless>      122 /  338  BugTask:+index
<lifeless>       91 /  212  CodeImportSchedulerApplication:CodeImportSchedulerAPI
<lifeless>       48 /   13  Distribution:+search
<lifeless>       45 /   25  DistributionSourcePackage:+filebug
<lifeless>       18 /   85  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       13 /   47  Milestone:+index
<lifeless>       13 /   40  Distribution:+bugs
<lifeless>       10 /   11  POFile:+translate
<lifeless>        9 /    8  Person:+translations
<lifeless>        8 /   18  DistroSeries:+queue
<wgrant> lifeless: Is that daily lpnet?
<lifeless> yes
<wgrant> Not bad.
<spm> lifeless: patched and restarting ....
<spm> fwiw. '10' in sysadmin speak is typucally out by a factor of 3 when dealing with actual time. fwiw.
<lifeless> so you're || close to being a black hole?
<poolie> StevenK: hi?
<StevenK> poolie: Hi. You didn't get a mail from ec2?
<poolie> nup
<poolie> did you?
<StevenK> I certainly did, the tests failed
<StevenK> Interesting, the exact same tests failed for my branch that I submitted at roughly the same time :-(
<stub> We are in test fix. Is the    lp.poppy.tests.test_poppy.TestPoppy.test_full_source_upload(sftp) test being looked at?
<stub> LayerIsolationError: Test left new live threads: [<paramiko.Transport at 0x147abe50L (cipher aes128-cbc, 128 bits) (active; 0 open channel(s))>]  <-- suprious?
<stub> spurious even?
<lifeless> wgrant: bug 1 in the ubuntu context - 179 queries
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<poolie> bug 1 is such a good example of why we should add task deletion :)
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<mwhudson> and why _mup_ should have rate limiting
<wgrant> lifeless: I recall it being roughly three times that...
<wgrant> Not bad.
<lifeless> wgrant: 179 to the point it times out ... :P
<thumper> lifeless: got a minute?
<lifeless> sure
<wgrant> Ah.
 * mwhudson goes home
<wallyworld_> thumper: ping?
<thumper> wallyworld_: otp
<wallyworld_> thumper: np. just wanted to touch base. later.
<poolie> stub:  if we're still in testfix should that be in the topic?
<stub> Dunno. I just forced the builds (the other one crapped out due to bzr checkout issues too)
<lifeless> stub: hey
<lifeless> stub: bug messages and bugactivity
<lifeless> stub: can you see any reason not to link activity to bugmessage, thus permitting a single range query to get only actions that will be shown ?
<wgrant> Most activities are now done by AJAX, so don't have an explicit or obvious message.
<stub> Have to be careful not to lose activity if a message is hidden. Other than that, that seems fine.
<stub> expect wgrant is right and you will end up needing fake messages
<wgrant> Oh good, Debian is trying to reimplement PPAs.
<spm> what on earth for?
<wgrant> Well, Launchpad is evil, see.
<spm> oh. of course. silly me.
<lifeless> stub: huh
<lifeless> left out
<lifeless> wgrant: well, and we don't support sid or other debian releases
<lifeless> stub: we have lots of activity without messages: every web action, for instance.
<wgrant> lifeless: No, but it's surely easier for them to alter the code and run their own cut-down instance than it is to write their own.
<lifeless> wgrant: oh sure
<lifeless> someone should point that out
<lifeless> stub: patch # for this ?
<stub> eg?
<stub> eh?
<lifeless> ALTER TABLE BugActivity ADD COLUMN bugmessage integer;
<stub> What are we doing this for btw? Why do we want to show activity associated with a particular message?
<lifeless> other way around
<lifeless> consider what bug index pages render
<lifeless> like https://bugs.edge.launchpad.net/launchpad-registry/+bug/237315
<_mup_> Bug #237315: search for -FOO alone causes a timeout and might be better as a substring search <infrastructure> <search> <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/237315>
<lifeless> we render a sequence of messages and actions interleaved
<lifeless> when there are too many messages we render the first and last 40
<lifeless> and only the activities that occur between or around those activities
<lifeless> stub: But the page *loads* all the activities and *all* the messages (and all the mesagechunks) every time.
<stub> And timestamps don't do that efficiently?
<lifeless> stub: perhaps; certainly we don't do partial loads of stuff
<lifeless> stub: I'll hold off on the patch
<poolie> i want to write a browser test with an admin logged in; it seems a bit hard
<poolie> just doing 'with logged_in_user' doesn't seem to make new browsers behave as that user
<stub> It seems we are interested in the activity in particular time ranges, not activity linked to particular messages.
<poolie> i guess the answer is, test the view, not through testbrowser?
<lifeless> poolie: getUserBrowser(user=person)
<lifeless> poolie: and make person with password='test'
<poolie> even when i give it an existing member of the admin team, i get an 'unauthorized' error
<poolie> yet i can log in to lp.dev as an admin user and see that page
<poolie> hm, the spr tests seem to do this
<lifeless> poolie: its the password
<lifeless> getUserBrowser falls back to anon
<poolie> ! ok
<lifeless> thus my advice -  new user with password='test', add it to admins.
<poolie> ok, i'll try that
<poolie> https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415 is the readonly feature rules view, btw
<lifeless> cool
<poolie> i'm glad you told me about the password; that could have taken a lot of difgging
<poolie> woo
<poolie> lifeless: so like this http://pastebin.ubuntu.com/498976/ ?
<lifeless> poolie: its in my second (I think) perf tuesday mail - it took me a lot of digging :)
<lifeless> poolie: yes
<poolie> ok, so i think that code may be not-unreasonable to land as it is
<poolie> >> # XXX jamesh 2005-11-22: Temporary fix, which Steve should undo
<poolie> mm :)
<spiv> poolie: hmm, 2005 XXX, great vintage that.  Lots of character, with crufty notes.
<poolie> :)
<poolie> drinking well now, with great long term potential
<spiv> Recommend cellaring: in a dark, deep hole.
<poolie> 15% bong by volume
<spiv> Haha
<poolie> lifeless, i'm thinking of adding a helper that just does
<lifeless> bong.light()
<lifeless>  ?
<poolie> if not getFeature(x): raise FeatureDisabled
<poolie> a little like the requireFeature() thing in bzr tests
<lifeless> if you want; I don't see a use for it: tal doesn't have exception flow control AFAIK
<poolie> i was thinking of putting it in view code when a thing is totally disabled
<poolie> the page can just fail
<poolie> for instance, i was recursively wondering if the rules view should use this
<lifeless> I don't really understand this; it seems a big departure from the previous model
<poolie> oh?
<lifeless> previously you have been building a very flexible schemaless thing
<lifeless> this seems to imply that unset or set to '' == the error condition
<lifeless> which is the reverse of what has previously been advocated
<poolie> ah, i'm not saying this will be for all uses
<poolie> just for the particular case of wholesale disabling a feature, that should cause an entire view to become unavailable
<poolie> even if people have handcrafted the url to it
<lifeless> mmmm
<poolie> this won't help if you just want to disable or change some controls on a page that should otherwise keep working
<lifeless> I think a helper might be useful
<lifeless> but you'd want to raise a 404 in traversal
<lifeless> we wouldn't want an exception, nor oops reports of it, would we?
<poolie> i don't know
<poolie> istm you _might_ want to count them, but as a different category from other things
<poolie> a bit like 404s being a special type of oops
<lifeless> well, you could add that in
<poolie> if lots of people are hitting this it should raise a question mark
<poolie> if you did indeed mean to turn it off then it's ok
<lifeless> it could be useful, though I don't think we've got any mandatory-hidden uses yet
<lifeless> personally I'd file it under yagni
<lifeless> no objection to it being added, but I wouldn't want a deliberate action to noise-up the already noisy oops reports.
<adeuring> good morning
<wgrant> Hm, so zack isn't actually entirely averse to the idea of using an LP instance.
<mrevell> Mornin'
<jml> mrevell, hello
<jml> lifeless, https://lpbuildbot.canonical.com/builders/prod_lp/builds/110/steps/compile/logs/stdio
<lifeless> jml: sigh fuckity.
<lifeless> jml: rc rs from you to fix?
<jml> lifeless, what's the fix?
<lifeless>  ) as e: -> ), e:
<lifeless> jml: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/645860
<_mup_> Bug #645860:  buildbot is letting production breaking changes through <Launchpad Foundations:New> <https://launchpad.net/bugs/645860>
<lifeless> jml: ping; Can I send the fix in.
<lifeless> jml: I'm taking your name in vain.
<stub> Gah. So the loggers are all hierarchical, with messages bubbling up. All hierarchical except for the filters which have to be explicitly attached to the logger emitting the messages rather than at a higher point in the tree.
<lifeless> python logging sucks
<jml> lifeless, thanks :)
<jml> lifeless, thanks.
<lifeless> wgrant: https://code.launchpad.net/~leonardr/launchpad/rename-grant-permissions/+merge/36363 may make you run screaming
<wgrant> lifeless: It did.
<wgrant> Where is all this discussion happening?
<wgrant> It seems to keep changing.
<wgrant> With no public rationale.
<lifeless> wgrant: I haven't seen any discussion.
<wgrant> And that is mildly concerning, considering how fucked everyone will be if it's wrong!
<lifeless> So I can't answre that.
<lifeless> Apparently leonardr hates email :)
<jml> oh right. that reminds me.
<lifeless> wgrant: brakes applied.
<lifeless> jml: do you know about this desktop oauth changing thingy stuff?
<jml> no.
<wgrant> lifeless: I think you probably meant "Needs Information"
<wgrant> But thanks.
<lifeless> jml: it seems to be getting discussed, changed with the wind and so forth with no public discussion, yet its a very delicate bit of work.
<lifeless> wgrant: no, I mean it needs fixing.
<jml> lifeless, yes.
<lifeless> wgrant: the fix may be conceptual :)
<jml> lifeless, my last point of reference was the email I sent to the list, for which I am still waiting on leonardr for a reply.
<wgrant> After seeing that MP a few hours ago, I sort of gave up and decided I'd object at the end once the whole thing was finalised, since it kept changing and nobody seemed sure of what was going on.
<wgrant> But objecting now is good too if others agree.
<lifeless> wgrant: objecting to the process is fine; as is pointing out problems as they come along
<wgrant> lifeless: Well, except that it's not really my place. So I will only really complain when somebody is about to break everything.
<jml> lifeless, I'm also concerned: I think good desktop integration is extremely important to Ubuntu + Launchpad.
<wgrant> jml: It certainly is.
<lifeless> wgrant: its all our places
<wgrant> But it needs to be done properly.
<jml> wgrant, exactly.
<lifeless> jml: I think its important too; I will grab leonardr and gary tomorrow but perhaps you would like to do so earlier.
<wgrant> And it's more likely to be done properly if more people know and can analyse what's going on.
<lifeless> minimally we need ubuntu-security, ubuntu-desktop, launchpad-security [I guess I'll wear that hat, for now] involved.
<jml> lifeless, I've emailed gary asking for a follow-up on his comments yesterday. I'm not going to be able do much else this week.
<lifeless> jml: gotcha
 * jml back to sprint
<lifeless> jml: gary's comments?
<jml> lifeless, at the team lead meeting.
<lifeless> and sigh, there's a dubious patch landed in launchpadlib too
<lifeless> I wonder how to help folk realise when something is high risk vs ordinary in terms of change, folk that it should be socialised with, etc.
<jml> lifeless, partly it's a numbers game
<lifeless> jml: I think its also partly a cultural thing
<lifeless> jml: I nagging feeling I am having is that lp reviews are kind of like makeup.
<lifeless> I'm positive that the team want to make it work well
<lifeless> we need to figure out with them how to do so; and /if possible/ draw their attention to the sorts of design things that need widespread input
<allenap> gmb: Judging from your Twitter stream, it seems like you've been having similar problems to me all week. My branches have cooked more than a few roast dinners with the heat generated from their futile ec2 runs.
<gmb> allenap, Yeah. Different tests keep breaking; can't get them to break locally so I guess I'm pulling in bad code from devel or something. Or maybe it's the Moon.
<lifeless> jml: wgrant: for your interest; there was discussion about some of the mechanics, but not the direction or reasoning in #launchpad-foundations
<jml> lifeless, which IRC network is that on?
<lifeless> freenode
<jml> huh.
 * wgrant didn't know that channel existed.
<jml> me neither.
<jml> allenap: devel's had quite a few bad landings.
<wgrant> Unlogged channels :(
<lifeless> gmb: what error ?
<allenap> jml: Okay, that makes me feel better :)
<jml> allenap: or maybe it's had only a small number, but it takes a long time to notice them and fix them in such a way that ec2 test will include the fixes.
<jml> Perhaps ec2 test should run against stable by default.
<gmb> lifeless, Er... I'd tell you but I don't know how to get the info out of testrepository.
<gmb> Since it's in an old run
<gmb> and the most recent one didn't fail.
<allenap> jml: That's a really good idea.
<lifeless> gmb: subunit-filter < .testrepository/$ID | subunit2pyunit
<gmb> lifeless, Ta.
<jml> allenap: see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419689
<_mup_> Bug #419689: Test failures in devel break ec2test runs <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419689>
<gmb> lifeless, It was a Windmill test: lp.code.windmill.tests.test_branchmergeproposal_review.TestReviewCommenting.test_merge_proposal_reviewing
<lifeless> gmb: or for sex; tribunal .testrepository/$ID
<lifeless> gmb: windmill errors are nearly always noise AFAICT - they show up when something else is wrong and go away when it isn't.
<wgrant> Running against stable would make it easier for devel to break in the first place.
<lifeless> gmb: from ec2 I mean.
<lifeless> gmb: I've never had a windmill test pass locally.
<lifeless> gmb: I just ignore them completely.
<gmb> lifeless, Heh. This one did, oddly. Anyway, we'll see what happens with this ec2 run.
<lifeless> good luck luke, may the force be with you
<gmb> :)
<lifeless> adeuring: regarding the librarian OOPS ID change
<lifeless> adeuring: could we just delete that template altogether ?
<lifeless> adeuring: and stop special casing it?
<adeuring> lifeless: yeah, I wondered too if we really needed it. but...
<adeuring> there might be one reason:
<lifeless> adeuring: if you'd like to delete it, +1 from me :)
<adeuring> lifeless: well, these errors involve another machine, the librarian server, so they can occur due to reasons like hardware failures, network problems etc
<lifeless> adeuring: so do all our requests.
<lifeless> adeuring: (the database server is another machine ...)
<adeuring> well, yes, but there one more machine involved that usually
<lifeless> true, but its not a unique thing
<lifeless> its just more of the same
<lifeless> global searches use google
<lifeless> gpg key checking uses the keyserver
<adeuring> hrmm, yeah... ok, I delete it. Though I'll be missing the "feng shui in the server room" message ;)
<lifeless> cool!
<adeuring> lifeless: what's the "timeline" for the token based access to the librarin?
<lifeless> adeuring: mthaddon has the keys now, so it should be up for QA soon.
<adeuring> cool
<adeuring> I am still bothered by lines 148..150 in l/c/l/browser/librarain.py, where we return a 503 error without doing any logging, but if we get rid of that code soon anyway, there is no need to touch it now
<lifeless> \o/
<wgrant> That's why I didn't fix it.
<wgrant> Does anyone know why launchpad-dependencies depends on ubuntu-keyring?
<lifeless> it will be the same thing
<lifeless> at a guess.
<lifeless> launchpadlib had a patch land today to use gnome-keyring
<wgrant> ubuntu-keyring is the Ubuntu archive keys.
<lifeless> oh blah, of course.
<lifeless> uhm, dunno.
<adeuring> lifeless: want to review this branch: https://code.edge.launchpad.net/~adeuring/launchpad/no-feng-shui-in-the-server-room/+merge/36427 ?
<deryck> Morning, all.
<deryck> The level of failures from ec2 and buildbot lately is driving me insane.
<deryck> ec2/land should become ec2/land-if-you-are-lucky
<jml> deryck, tbh, it feels this bad for me all the time
<deryck> maybe I've just been more productive lately, and I'm only now reaching jml levels to notice it. :)
<jml> perhaps. :)
<deryck> adeuring, hi.  I noticed you started on bug 594247.  Can we consider the librarian OOPS issues fixed now?  At least, all we can do for now?
<_mup_> Bug #594247: searchTasks with structural_subscriber times out regularly <dhrb> <overlyprecise> <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/594247>
<adeuring> deryck: yes. it is still unclear to me why I could not find as many OOPS reports as I would have expected, but looking longer at this without a better clue is pointless.
<adeuring> and if we have a similar situation again, we should either see the OOPS number or we should get another error due to a missing OOPS ID
<deryck> adeuring, ok, cool.  I agree.  For some reason, I thought there was another bug open on this.
<gmb> Hooray for throwing things at EC2 until they stick.
<mars> gmb, ?
<gmb> mars, Windmill failed in EC2, didn't fail locally; I resubmitted.
<mars> gmb, an intermittent failure?
<mars> could you send me the log?
<gmb> mars, Sent.
<mars> thanks
<dobey> hrmm, on bugs for projects, is it not possible to target a bug only to a release other than trunk? i notice that if i target to trunk, it changes to say "status tracked in trunk", but if I only target the bug task to a different series, then it still has the normal bug task, as well as the series task
<cr3> can someone help me understand the difference in testing between layers and fixtures?
<sinzui> bac: I think you can say this is fixed on edge now: https://bugs.edge.launchpad.net/launchpad-registry/+bug/252889
<_mup_> Bug #252889: Project attributes should be altered from a link next to assertions about them <Launchpad Registry:Triaged> <https://launchpad.net/bugs/252889>
<mars> cr3, layers are from the Zope world.  Each layer has it's own setup and teardown, and that is run once before all the tests in that layer are run, and tearDown after.  A fixture, on the other hand, is set up and torn down for each test that makes use of it.
<mars> cr3, our layers are in a hierarchy, so to write a pagetest you must also set up a full librarian service, a full database, a full component registry - they are not composed easily.  Fixtures can be easily composed: you only .useFixture() what you need.
<bac> sinzui: i'll have a look
<sinzui> bac: I think that since you removed the block on the progress bar, the links to configure an app are on the page. I think we will be ready to remove the "Uses launchpad for" chunk next week
<cr3> mars: all clear now, thanks!
<sinzui> benji, can you point me to a file or test that shows how to export an error over the api?
<benji> sinzui: sure, one sec
<benji> sinzui: lib/lp/registry/model/product.py:456
<sinzui> thank
<sinzui> s
<benji> np
<wgrant> Erm.
<wgrant> There are two methods now?
<wgrant> What happened to annotating exception classes with webservice_error?
<benji> wgrant: this mechanism is for individual exceptions (not classes); for example if you're going to raise a KeyError because some key passed in was not found
<wgrant> Hmmmm.
<cr3> when defining a database schema, there's sometimes not a meaningful difference between a cell containing none or empty string (''). so, what's the preferred approach to keeping the schema and application layer code sane?
<cr3> hm, I'll also as in #postgresql, I've been wondering for a while what are the implications to consider
<cr3> s/as/ask/
<cr3> I should have a look at the launchpad schema and see if there's ever a situation where a text or varchar column can be null...
<cr3> on an unrelated note, is there an unwritten rule about when to use which quotes, ' or "?
<mars> gary_poster, should lib/canonical/launchpad/doc/profiling.txt be moved to lp.services.profile/doc?  Or is there a better location?
<gary_poster> mars, I decided not to make that change for my own branch--that was where it was when I found it.  But yes, before I knew that file existed, I was putting documentation in lp/services...
<gary_poster> So if your branch is small enough to include the move, and you want to, go for it AFAI am concerned.
<mars> ok, thanks
<gary_poster> np
<lifeless> morning
<deryck> morning, lifeless.  Care to review a small branch for me?
<lifeless> sure
<deryck> lifeless, thanks!  https://code.edge.launchpad.net/~deryck/launchpad/fewer-milestone-queries-bugtask-index/+merge/36458
<deryck> lifeless, I don't think this will make significant difference yet, but still think it's worth doing.
<lifeless> every bit helps
<lifeless> did you see that activites is 2.5 seconds alone, for bug 1
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<deryck> lifeless, I didn't.  But I knew from your bug mail that activities and comments were the next big two.
<deryck> rockstar, hi.  Is the yui in lazr-js the latest?  If I try to bug fix in this, will my deploying this to lp be delayed by yui version upgrade on lp?
<rockstar> deryck, the yui in lazr-js is indeed the newest.  The only real thing blocking the update of lazr-js is the thing I raised on the mailing list last week (python dependencies)
<deryck> rockstar, ok, so build issues not library compatibility?
<rockstar> deryck, yeah.
<deryck> ok, thanks
<lifeless> deryck: approved; coupla tiny tweaks you can make if you feel like it
<rockstar> deryck, in the first branch I tried it on, I needed to rename all yui- classes to yui3-, but that's it (as I remember)
<deryck> lifeless, great, thanks!
<deryck> rockstar, gmb has to get the widget in lp very soon.  And I'd like to see this bug fix I'm about to put up in lp, too.
<deryck> wizard widget, rather
<rockstar> deryck, yeah, I saw he just landed it.  I will be working on this tonight in fact.
<deryck> ah, cool.
<rockstar> deryck, I also have a hard dependency on a new yui.
<deryck> ah, ok, so this should move forward then. ;)
<rockstar> deryck, ideally, we aren't tied to lazr-js to upgrade yui.  Unfortunately, I don't think that will happen.
<deryck> rockstar, there isn't a YUI wrapper around substring search is there?  i.e. prettier than foo.indexOf('some string') > -1 ?
<rockstar> deryck, no, but feel free to write one.  I think it'd be beneficial to all.
<deryck> ok, I could do that.  Not sure I'll do it today to be honest.
<deryck> The lazr-js build step makes me feel less inclined to be opportunistic like this.
<rockstar> abentley, what you do know about BranchWithSortKeys view?
<abentley> rockstar, Sorry, no idea.
<rockstar> abentley, from the comments, it appears to be a hack for when we used SQLObject, and was intended to be removed when we switched to Storm.
<rockstar> abentley, I'm going to delete it and see what blows up.
<rockstar> (It's blocking my merge queue db patch currently)
<dobey> deryck: is it impossible to target a bug to only affect a series other than trunk?
<deryck> dobey, I believe the series has to be the active development branch.
<deryck> or development focus, I think we call it.
<dobey> deryck: so there has to always be a bug target for the development focus, even if it doesn't actually affect it?
<abentley> lifeless, have you come to any conclusions about that security stuff?
<cr3> lifeless: hi there, I'd appreciate your advice on writing unit tests: should helper methods like makePerson which do not strictly related to unit testing be defined in a factory, whereas other methods like assertFoo which relate more to unit testing be defined in a TestCase derived class?
<deryck> dobey, sorry, I don't follow what you mean there.  The idea is that you can only nominate bugs for an active series.  Not saying this is ideal, but that's the way it is currently.
<lifeless> abentley: no sorry; I've been mainly head down on just performance the last week
<lifeless> abentley: I'll revisit the mail in detail today
<abentley> lifeless, cool.
<dobey> deryck: i mean, if i click "Target to release" and select only series other than trunk (or i guess the development focus, as it seems), i would expect it to only be tracked in those series
<lifeless> cr3: http://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ http://rbtcollins.wordpress.com/2010/09/18/maintainable-pyunit-test-suites-fixtures/
<lifeless> cr3: (that is, things like factory are great, putting helpers on subclasses of TestCase isn't great)
<lifeless> cr3: but the urls are much less pithy
<cr3> lifeless: thanks!
<dobey> deryck: is that not currently possible?
<dobey> deryck: or should i find a bug to point you at, which shows the issue i'm trying to find a solution to?
<deryck> dobey, sorry, I think I'm confused and thinking of another constraint.  If you click "target to release" and you select any series on that page, it should only be linked to that series.
<deryck> dobey, and yes, showing the issue might help me understand better
<deryck> fwiw, I was thinking of the conjoined master condition where a conjoined bugtask is created when the series is the development focus.
<dobey> deryck: https://bugs.edge.launchpad.net/ubuntuone-client/+bug/645519
<_mup_> Bug #645519: DBus delete_share doesn't work for shares made by the user to others <foundations+> <u1-maverick> <Ubuntu One Client:In Progress by verterok> <Ubuntu One Client stable-1-4:In Progress by verterok> <ubuntuone-client (Ubuntu):Confirmed for ubuntuone-ops+> <https://launchpad.net/bugs/645519>
<dobey> deryck: see how it shows status for both the project and stable-1-4? if i target to 'trunk' also, then it will show 'tracked in Trunk' instead of status there. but if i don't target to trunk, it will always show status like that
<deryck> dobey, ok, so I was thinking of the right thing.  That's a conjoined bug task, where the status is only tracked in the series, not the main project bug task.  The series has to be the development focus to get that joined bug task.
<dobey> deryck: ok, so there's no way to do what i want, basically?
<deryck> dobey, if what you want is to have the status only tracked in the series for any series you target to, then no.
<deryck> I'm not sure of the historical reasons why this choice was made, but I do think there is a bug asking for conjoined tasks on any series.
<dobey> hrmm, i'm having trouble finding such bug filed against malone
<dobey> should i file a new bug?
<deryck> dobey, sure, file a new one, and I'll dupe if I find one.
<deryck> dobey, I doubt we'll work on this, though.  Not anytime soon.  But having a bug to track it would be nice.
<dobey> :(
<deryck> Sorry.  Just too much needs doing to even get to that.
<lifeless> I suspect we need to gather the 'rules' for the current implementation and go back to ground zero :)
<deryck> heh
<lifeless> eventually
<deryck> yeah, that's partly why I say we won't work on it, too.  It's a largish design decision that I don't want to revisit with everything else we're active on.
<lifeless> completely agreed
<deryck> rockstar, I've got a lovely 4 line lazr-js branch.  Care to review it?
<dobey> https://bugs.edge.launchpad.net/malone/+bug/646277
<_mup_> Bug #646277: Targetting to series should result in conjoined bug task <Launchpad Bugs:New> <https://launchpad.net/bugs/646277>
<deryck> I don't find a dupe either.  And I searched mpt's reported bugs. :-)
<lifeless> hah
<dobey> heh
<dobey> now to figure why bzrlib is deciding to lie to me in the form of an Exception
<deryck> rockstar, you still around?
<rockstar> deryck, yup.
<rockstar> (On the phone)
<deryck> ah
<deryck> rockstar, I'm EOD'ing soon.  You care to review lazr-js offline for me?  https://code.edge.launchpad.net/~deryck/lazr-js/stop-all-those-null-choice-edit-icons/+merge/36494
<rockstar> deryck, sure.
<deryck> thanks.
<deryck> rockstar, if you make me write a test, I will.  But in this case, I think it's really silly.
<rockstar> lifeless, around?
<lifeless> hi
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<jml> ra ra ra
<jml> still hacking in worcestershire
<lifeless> garh, more 2.6 I missed
<lifeless> jml: I'm going to use your name again :)
<jml> lifeless, only if you review my incremental failure patch in testr.
<jml> lifeless, https://code.edge.launchpad.net/~jml/testrepository/show-failures-incrementally-613152/+merge/31765
<lifeless> jml: I can leave prod broken if you'd prefer ;)
<lifeless> jml: its on my list, I'm keen to have it.
<rockstar> jml, do you know anything about BranchWithSortKeys.  It seems to pre-date my time on Launchpad.
<jml> lifeless, cool. rs=jml
<jml> hah
<jml> rockstar, thumper knows all about it.
<jml> rockstar, I never really understood the need for it.
<rockstar> jml, dammit. thumper is unavailable today.
<jml> rockstar, it seemed to be some crappy performance hack afaict.
<jml> rockstar, a cunning trick.
<rockstar> jml, yeah, the comments indicate that it could go away when we moved to Storm.
 * rockstar remembers us moving to storm a very long time ago.
<lifeless> rockstar: hi?
<jml> rockstar, I can search my mail for clues
 * bigjools waves
<rockstar> lifeless, so, I pinged you, but I'm not sure you're the best to help.
<rockstar> lifeless, basically, I dropped a pile of columns from the DB, but I can't generate newsampledata because the old sampledata is now all screwed...
<rockstar> ...and I REA-HE-LLY don't want to edit current.sql by hand if I don't have to.
<lifeless> rockstar: ok, so the easiest way is probably: rebuild with db-stable's schema., apply your patch, and output the sampledata
<rockstar> lifeless, ah, 'tis a good idea.
<jml> rockstar, seen https://bugs.launchpad.net/bugs/154016 ?
<rockstar> jml, I get a nice fancy 403 there...
<jml> rockstar, looks like mwhudson also knows about it.
<jml> me too!
<jml> lifeless, do you have duck privs?
<rockstar> jml, yeah, he was the next person I was going to harass.
<rockstar> jml, basically, I've decided I'm going to kill it and see what breaks.
<rockstar> ...Although that might make lifeless cry.
<jml> rockstar, I've found a patch of his from 2007-10-16
<rockstar> jml, holy crap. Data mining FTW!
<jml> rockstar, lifeless (and I, for that matter) generally approve of trying stuff
<rockstar> jml, yeah, but if it really ends up killing performance, lifeless will hit a child.
<jml> rockstar, kiwi kids are tough. it's a rugby thing.
<thumper> rockstar: it had to do with sql object not allowing sorting by columns that weren't returned
<thumper> rockstar: yes Storm can and it should be fixed
 * thumper isn't here
<rockstar> thumper, okay.  I'm killing the view.
<thumper> rockstar: good
<rockstar> (The merge queue patch fights with it)
<mars> lifeless, something to make your life a bit easier: a branch that checks for Python 2.5 compatibility when you run 'make lint': https://code.edge.launchpad.net/~mars/launchpad/add-py25-lint
<lifeless> mars: tie it into make check to bb will enforce it and I'll be happy ;)
<mars> lifeless, there is also a merge proposal for it.  I think it is floating around somewhere in the Launchpad system ether.  I'm sure it will show up somewhere.
<lifeless> s/to/so/
<mars> there it is: https://code.edge.launchpad.net/~mars/launchpad/add-py25-lint/+merge/36502
<lifeless> mars: oh, I see
<lifeless> mars: we don't have py2.5 on the lucod builders do we?
<mars> I don't believe so
<rockstar> Oh crap.  Did we generate sampledata on pgsql 8.3 again?
<wallyworld> morning
<rockstar> Wow.  Skype crapped itself at the end of that call.
<mwhudson> has anyone tried local codebrowse recently?
#launchpad-dev 2010-09-24
<poolie_> whos' the on-call reviewer? does that concept still exist?
<lifeless> thumper: http://nosql.mypopescu.com/post/619181345/nosql-graph-database-matrix
<lifeless> poolie_: it does, check #launchpad-reviews or the wiki page
<poolie_> it's '-'
<poolie_> ok
<mwhudson> poolie_: that concept exists, but not really in this timezone
<lifeless> poolie_: that means noone is on.
<mwhudson> poolie_: i can probably take a look for you
<lifeless> mwhudson: lp in pypy would be intereseting
<lifeless> mwhudson: so would lp in jython
<mwhudson> lifeless: right away, you need psycopg2
<poolie_> thanks mwh
<mwhudson> i'm not sure what else we have in the way of mandatory c extension modules
<poolie_> mwhudson, could you sponsor landing https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173
<mwhudson> poolie_: i think you meant to propose against devel, not db-devel?
<poolie_> yes
<poolie_> i don't know why db-devel is the defalut
<poolie_> (well, i do; i think it's a bad default though)
<poolie_> i guess i can re-propose it?
<mwhudson> that's probably easiest
<poolie_> ok https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
<rockstar> wallyworld, I've made myself available for you this evening in case you get stuck, although you may have plenty of people around.
<poolie_> hello rockstar
<mwhudson> poolie_: ta
<rockstar> poolie, hi
<wallyworld> rockstar: thanks for the kind offer. i don't think i'll need you. feel free to have a glass or three of good wine without any guilt :-)
<mwhudson> that would not be the guilt you are looking for, i suspect
<rockstar> Hello quotes page...
<mwhudson> poolie: i don't mean to be a pain, but i'm not sure that comment you're adding makes sense, has it lost its first line or something?
<mwhudson> make is blowing up for me
<mwhudson> IOError: [Errno 2] No such file or directory: 'lazr-js/build/choiceedit/assets/skins/sam/choiceedit-skin.css'
<rockstar> mwhudson, is this in launchpad or lazr-js?
<mwhudson> rockstar: launchpad
<rockstar> mwhudson, shite.
<mwhudson> rockstar: ah
<mwhudson> $ ls -l lazr-js/build/choiceedit/assets/skins/sam/
<mwhudson> total 8
<mwhudson> -rw-r--r-- 1 mwh mwh 871 2010-09-24 11:20 choiceedit.css
<mwhudson> lrwxrwxrwx 1 mwh mwh 101 2010-02-26 13:42 choiceedit-skin.css -> ../../../../../../eggs/lazr_js-0.9.2-py2.5.egg/lazrjs/choiceedit/assets/skins/sam/choiceedit-skin.css
<rockstar> mwhudson, yeah, this is stuff I'm going to attack tonight.
<mwhudson> rockstar: i just thought "you know, why don't i delete all these py2.5 eggs"
<rockstar> mwhudson, hahaha.
<rockstar> mwhudson, I HATE HATE HATE that we have to eggify javascript.
<mwhudson> so this is one of those, we use make, kinda sorta problems
<mwhudson> rockstar: yeah, i know
<wgrant> mwhudson: Local codebrowse worked for me last week.
<wgrant> But I haven't tried it since.
<mwhudson> wgrant: ok cool
 * rockstar relocates
<mars> mwhudson, what exactly is a 'we use make' sorta problem?
<mwhudson> mars: make traditionally tracks dependencies
<mwhudson> so if you edit foo.c, foo.o gets rebuild and the foo binary gets relinked
<mwhudson> mars: but if you edit versions.cfg and run make, we don't get that kind of effect
<mwhudson> well maybe in that precise case we do, but in general we don't
<mars> ah, yes.  foo.js gets lint, minified, concatenated, etc.
<mars> yes, that makes sense, especially since most projects treat JavaScript as a compiled language now
<lifeless> we could use make properly if we wanted
<mwhudson> let's use automake!!1!
<mars> as for make versus bin/buildout - that is something I haven't managed to figure out - both have advantages and drawbacks
<mwhudson> (not really)
<lifeless> mwhudson: I said properly.
<mwhudson> one of the things i always liked about the cpython dev community: the appropriate amount of disdain for automake and libtool
<mars> lifeless, the problem with Make is that we did use it, but it is a rather special language, and I gather not everyone knows how to use it well
<poolie> mwhudson: i'll look
<mars> lifeless, so our use of Make was not great
<poolie> mwhudson: i have an autographed copy of the autotools goat book saying "I hope you never use this book -- Ben"
<mwhudson> :-)
<poolie> mwhudson: it's not cropped, it's just not a complete punctuated sentence
<poolie> which jml told me the other day is the lp style
<poolie> i can fix that
<mwhudson> poolie: thanks
<mwhudson> poolie: i'm not sure being a grammar nazi to the extent lp does is wise, but i do actually find that comment a bit hard to interpret
<poolie>     166     while open_readers:
<poolie>     167         # select() blocks for a long time and can easily fail with EINTR
<poolie>     168         # <https://bugs.launchpad.net/launchpad/+bug/615740>.  Really we
<poolie>     169         # should have EINTR protection across the whole script (other syscalls
<poolie>     170         # might be interrupted) but this is the longest and most likely to
<poolie>     171         # hit, and doing it perfectly in python has proved to be quite hard in
<_mup_> Bug #615740: test_on_merge.py doesn't handle eintr <Launchpad Foundations:In Progress by mbp> <https://launchpad.net/bugs/615740>
<poolie>     172         # bzr. -- mbp 20100924
<poolie> is that clearer?
<mwhudson> poolie: yes, that's much nicer, thanks
<poolie> when you start insisting on passive voice i'll worry :)
<mwhudson> poolie: i think i just wanted a subject for "blocks" really
<poolie> 'lego'
<poolie> anything else?
<lifeless> how busy is staging db right now ?
<wgrant> Hm.
<wgrant> Debian just started running apt-ftparchive in parallel.
<wgrant> That's actually not a bad idea.
<rockstar> bzr is MUCH slower when I run `make schema` at the same time.
<mars> rockstar, check your loadavg
<rockstar> mars, I'm being a bit facetious.  EVERYTHING is much slower when running `make schema`
<mars> :)
<rockstar> I just wanted to rag on the bzr team for not being fast enough.
<lifeless> :(
<rockstar> lifeless, :)
<poolie> rockstar: you could iorenice psql
<lifeless>     Hard / Soft  Page ID
<lifeless>      129 /  224  CodeImportSchedulerApplication:CodeImportSchedulerAPI
<lifeless>      108 /   19  DistributionSourcePackage:+filebug
<lifeless>      107 /  319  BugTask:+index
<lifeless>       58 /   13  Distribution:+search
<lifeless>       18 /   15  Archive:+copy-packages
<lifeless>       16 /   44  Milestone:+index
<lifeless>       16 /    9  DistroSeries:+queue
<lifeless>       13 /    5  Person:+bugs
<lifeless>       11 /  103  RootObject:+login
<lifeless>       11 /   29  Archive:+packages
<rockstar> poolie, ah! iorenice is quite cool.
<rockstar> For creating new database models, do we still want to use SQLBase?
<rockstar> lifeless, ^^ I seem to recall some discussion about performance issues with the sqlobject compatibility layer.
<wgrant> All my new stuff has descended from Storm.
<rockstar> wgrant, yeah, that's what I was wondering.
<lifeless> we need a base class
<lifeless> anything using just storm is buggy
<wgrant> Even if you're not using cachedproperty?
<rockstar> lifeless, ELACKOFCLEARANSWER
<lifeless> because it doesn't do IPropertyCacheManager(self).clear() on __storm_invalidate__
<lifeless> rockstar: so, I guess I'm saying 'use SQLBase' or 'add a base class we can use with no gunk, and a storm invalidate hook'.
<lifeless> it would be nicer still to tell storm to have a global invalidate hook, I guess
<rockstar> lifeless, is there an example of a storm invalidate hook somewhere?  I guess I have no idea what that entails.
<mars> lifeless, how ofter are you running manual rollouts of revs that have passed QA?
<mars> 'ofter' - there's a new word
<poolie> "works well with otters"
<rockstar> mars, lifeless, the test suite seems to be running faster on ec2.  If you did that, THANK YOU.  If you didn't, say you did.
<wgrant> mars: Why are the QA reports private?
<wgrant> They aren't for production-stable, so it seems unnecessary.
<mars> wgrant, they don't have a good public home yet - we want to set up lp-qa.canonical.com as a public place to publish them
<wgrant> Aha.
 * stub wonders where last night's ec2 test run ended up
<poolie> mwhudson: can you help me understand the failure from mbp-trivial?
<poolie> is it spurious?
<mwhudson> poolie: hadn't seen it, one sec
<poolie> maybe i should keep a count of how many spurious rejections i get? my guess is around 50% of attempted landings
 * mwhudson stares at offlineimap
<mwhudson> i wonder what it's doing
<poolie> i pasted the summary on https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
<mwhudson> poolie: what a helpful failure mode!
<poolie> yeah, there are some nasty cases in subunit where it falls in to "lost connection" like here
<mwhudson> poolie: i have no reason at all to think that this is anything other than spurious
<mwhudson> poolie: i can just shove it back in again if you'd like?
<poolie> i guess so :(
<poolie> thanks
<mwhudson> doing so
<mwhudson> having stuff like this officially being Someone Else's Problem is one of the nicest things about no longer being an official launchpad developer
<mwhudson> :/
<poolie> yeah
<poolie> i'm especially grateful for you doing it when you don't really have to
<poolie> there's no more information in the subunit stream afaics
<poolie> lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/646563 from your comments about testbrowser yesterday
<_mup_> Bug #646563: want a way to make a TestBrowser logged in as a particular user <testing> <Launchpad Foundations:New> <https://launchpad.net/bugs/646563>
<wgrant> mwhudson: Ahem.
<wgrant> Something is wrong with Launchpad, then? :P
<mwhudson> wgrant: probably
<mwhudson> wgrant: but launchpad at least has the moral position of being large
<wgrant> But yes, I don't get that Django thing.
<wgrant> It's stupid.
<mwhudson> are you criticizing the runserver thing or the whole project? :)
<wgrant> The fact that it doesn't serve static media.
<wgrant> And its URL system is painfully awful.
<wgrant> But apart from that it's not bad.
<mwhudson> i think a global settings module is an idea that deserved to be strangled at birth
<wgrant> Yes.
<wgrant> And its mandatory app structure is inconvenient.
<wgrant> I'm struggling with that at the moment.
<poolie> if i want to make the feature-rules page visible to only developers, what would be a tasteful way to do that?
<poolie> add permission launchpad.Developer and then register an adaptor for it?
<wgrant> Hmm.
<wgrant> Difficult.
<wgrant> Do you have a FeatureFlagSet sort of thing?
<poolie> and, to be tasteful, does ~launchpad need to become a celebrity?
<poolie> what sort of thing do you mean?
<wgrant> ~launchpad should already be a celebrity
<wgrant> Well, what does this view live on?
<wgrant> ILaunchpadRoot, or something else?
<poolie> ILaunchpadRoot
<poolie> i'm open to moving it
<wgrant> You could for now reuse ILaunchpadRoot's launchpad.Edit
<wgrant> It's ~admins + ~registry
<poolie> ah yes, so it is
<wgrant> It's currently used for managing featured projects.
<poolie> ok
<wgrant> And is roughtly ~launchpad + ~canonical-bazaar + a few others.
<poolie> brilliant
<poolie> so it would be launchpad.Edit on the readonly mode
<poolie> and launchpad.Admin on the edit mode
<poolie> s/mode/form
<wgrant> It's a bit of an abuse.
<wgrant> Probably.
<poolie> wgrant: works for me, thanks
<maxb> wgrant: On the offchance you're still around, do you know who needs to be poked about builds that bounce between buildds whilst only pretending to start?
<wgrant> maxb: It needs a LOSA to fix, but the first step is to get someone with log access...
<wgrant> noodles775: Can you see what's going on?
<wgrant> It's been failing like this a bit lately.
<noodles775> wgrant, maxb: sure, I'll check the logs - maxb do you have a specific build I can look for?
<maxb> noodles775: bzr/proposed PPA, bzr 2.2.1-0~bazaar1~{karmic,jaunty,maverick}1
<noodles775> wgrant: do you know the background to the issue (what has been the cause for other builds doing this lately?) - I've been a bit out of the loop.
<wgrant> noodles775: I don't know, sorry.
<wgrant> adare and ross are known to be problematic, but that doesn't explain PPA builds.
<noodles775> Thanks.
<noodles775> losa: Hi! is devpad down? I can't ssh to access logs.
<spm> yup. probably because yout logged into it noodles775,  you should know by know it's senistive!!!!!
<StevenK>   File "/home/steven/launchpad/lp-branches/ids-limit-packagesets/lib/lp/testing/__init__.py", line 78, in <module>
<wgrant> devpad seems to have been rather unwell lately.
<StevenK>     import fixtures
<wgrant> StevenK: make
<StevenK> Why does this keep turning up?
<wgrant> A new egg was added a few days ago.
<noodles775> spm: ;)
 * StevenK blames lifeless 
<wgrant> That's right.
<spm> wgrant: indeed it is. I think everything in the h/w has been replaced and it still smashes.
<wgrant> spm: Is crowberry at least happy again now?
<spm> not sure. I know stuff was done overnight to make things happier.
<noodles775> wgrant, maxb: the most recent build of that package that I can see was dispatched to americium without an issue, but then the next entry for that buildd is: 2010-09-24 07:00:49+0000 [-] <americium:http://americium.ppa:8221/> communication failed (User timeout caused connection failure.)
<wgrant> Yay.
<maxb> "User timeout" ?
<noodles775> losa: it looks like the last build that finished on americium was 3 hours ago: https://edge.launchpad.net/builders/americium/+history
<noodles775> Do you have instructions for resetting the buildd, or is it something only lamont does?
<spm> depends on how wedged they are
<noodles775> It's still trying to build new items.
<spm> noodles775: but supposedly it started on a new bzr build 8 mins ago?
<spm> or is that the problem? starts but barfs?
<maxb> ALSO, the PPA publisher hasn't published something that was accepted 88 minutes ago
<noodles775> Yeah, it seems to be.
<spm> ahh that sounds like the fun we noticed yesterday
<spm> noodles775: can you ensure bigjools knows about the repeat of the fun with find/xargs?
<jtv> jelmer: did you Q/A your branch for bug 128259?  The bug is still marked qa-needstesting.
<_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
<noodles775> jtv: jelmer is not available this week.
<noodles775> spm: sure, is there a bug we can collect info on?
 * noodles775 looks
<jtv> noodles775: arghâ¦ afaict that branch is probably keeping >200 revisions from being deployed, including a pressing one I'm trying to get in.
<spm> noodles775: unsure. he knows what it is tho. i think he emailed the dev list as well
<noodles775> spm: great.
<spm> basically publishing/cron.daily-ppa is locking and blocking the publishing for 2+ hours
<spm> we don't actually know HOW long for, as we kill it before it finishes.
<jtv> noodles775: of course there's more branches waiting for q/a, but I think if we could get this one out of the way it'd make a big difference.
<spm> maxb: that should happen "RSN" for values of 'soon'
<noodles775> jtv: k - let bigjools know, he'll organise QA for it I'm sure (I can't do it right now).
<jtv> noodles775: will do, thanks
<wgrant> jtv: Last I heard the plan was to QA that, get it individually CP'd on Monday (so we can roll back easily if necessary), then resume normal mass-CPing once we're confident it works.
<wgrant> Since it's a big, risky change.
<maxb> spm: thanks
<maxb> titanium hasn't built anything for four days
<jtv> wgrant: I seeâ¦  maybe lifeless will make an exception and still let me cherrypick my fix then.
<jtv> (There's a few other branches less far behind that are also blocking mine.  I'm Q/A'ing one of them now.)
<maxb> charichuelo nothing for 22 hours
<maxb> an awful lot of other buildds claim to not have built anything in 3 hours
<noodles775> maxb: yeah, I'm just creating a bug listing all the builders showing that same error... I'll ping you when it's done in case you've more to add.
<adeuring> good morning
<noodles775> wgrant, maxb, spm: bug 646635 - but checking the histories now looks like communication has been restored between the buildds and the buildmaster?
<_mup_> Bug #646635: communication failed - user timeout caused connection failure <Launchpad Auto Build System:New> <https://launchpad.net/bugs/646635>
 * wgrant blames Nafallo sleepwalking through the DC and tripping over cables.
<noodles775> heh
<wgrant> It does look fairly happy now.
<wgrant> Hopefully on Monday the latency will disappear, and problems will be a lot more obvious.
<mrevell> Good morning
<jtv> hi mrevell!
<lifeless> wgrant: my bugtask:+index is on on prod, if you're interested.
<lifeless> 370 queries for bug/1 still
<lifeless> jtv: normal process for cp's applies if the cp isn't listed in https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
<lifeless> bbiab
<wgrant> ,lifeless It was 600, so that's not too bad.
<jml> Greetings Earthlings
 * noodles775 wonders what the air is like today in "the hut"
<wgrant> Heh.
<jml> relatively clear.
<jml> updateBuild gets called 12 times over the course of 600 lines of doctest.
<poolie> hello jml
 * jtv wonders if he falls under "earthlings"
<jtv> hi jml
<wgrant> jml: Please destroy buildd-slavescanner.txt :)
<jtv> lifeless: the one I want to deploy (codehosting only) is 11599.
<jml> wgrant, that's basically happening slowly.
<wgrant> It's soooo big :(
<jml> the problem for me is that I'm not sure whether it's testing the builder itself or binary package build behaviour
<jml> probably both. :(
<wgrant> Well, they were one and the same.
<wgrant> So it's both.
<noodles775> I'd assume both - when we factored out the separate behaivours I didn't take the time to do more than ensure the current doctests still passed.
<jml> yeah. that sounds right.
<wgrant> We destroyed bits of it.
<wgrant> But there was so much of it there.
<jml> yeah.
<jml> in our work here we're getting a little bit closer to separating out the tests into the two layers
<maxb> noodles775: shipova just ejected my build, it's now starting again on thorium
<jml> there's probably still more that could be done to make the separation of concerns clearer for both for tests and for the interfaces themselves
<wgrant> jml: Even just splitting it into unit tests would be a huge step forward.
<noodles775> maxb: I'll check the log and confirm whether it's the same and updated the bug. Thanks.
<wgrant> So you don't move one test out, and find that something breaks 1000 LINES later.
<jml> well also, perhaps it will make the intents of the tests clearer
<maxb> noodles775: for the record, that build on shipova had most definitely started. It had been running for an hour, and was displaying build log output
<jml> that's the biggest problem here
<bigjools> we've already murdered a couple of doctests
<wgrant> jml: Right, but making the intet of tests clearer is easier if you can actually change them.
<bigjools> it felt good
<jml> :D
<wgrant> Which is much easier when the doctest isn't 3000 lines.
<wgrant> Or was that archive.txt? I forget
<bigjools> there are problems in the air today
<jml> buildd-slavescanner is now ~800 lines
<noodles775> maxb: so you build on shipova looks like something went wrong with the builder itself (or it was manually set to not-ok) - 2010-09-24 08:30:53+0000 [-] shipova was made unavailable, resetting attached job
 * noodles775 checks for thorium
<bigjools> a load of builders went to Enablement not that long ago
<noodles775> bigjools, maxb: that would certainly fit with the fact that shipova is no longer listed.
<bigjools> they have the ability to pull builders out of the pool at any time
<bigjools> the build has to be re-dispatched elsewhere
<jtv> Why does this show devel 11566 as the oldest undeployable revision?  AFAICT r11399 hasn't gone through Q/A yet (though at least one branch for the same bug has)
<jtv> Damn, lost the bug now.  Maybe I got it all wrong.
<lifeless> jtv: so, 11566 is jelmers half-landed branch
<lifeless> jtv: julian is cping it monday
<lifeless> jtv: your thing you can cp with the normal process; what I'm doing is doing stuff thta passes under the *new process* which is less exception orientated: I'm finding the glitches so we don't have a panic when we start doing more of it.
<jtv> lifeless: I guess this is also going to reduce a lot of the risk of conflicts and false conflicts with cp candidatesâ¦  I actually based my branch on devel instead of productiond-devel.
<lifeless> jtv: it will help, as long as we don't let it fall behind :)
<jtv> quite :)
<stub> jml: Seen anything like this? http://paste.ubuntu.com/499557/
<jml> stub, what in particular?
<stub> It exploded and it is very unclear why
<jml> stub, oh, I see it's a make run
<jml> stub,
<stub> its ec2 land output
<jml> stub, I've seen errors like "Usage: test [options]" before. That means zope.testrunner has become confused and isn't spawning child processes properly.
<stub> I've tried to submit the branch a few times - same failure each time.
<jml> hmm.
<jml> stub, what happens when you try locally?
<stub> I just did test_layers locally - fine.
<stub> I'll try ./test_on_merge.py -vv "--subunit -vvv"
<jml> stub, may I see the full subunit output?
<jml> stub, I'd be surprised if it's an issue with ec2 test per se.
<jtv> Is there any way to figure out if the branch scanner on staging is invoking my ITipChanged handler?
<stub> http://paste.ubuntu.com/499560/
<jml> looks like it fails fast, at least.
<jml> stub, when I try to test your branch locally, I get the same crash with or without subunit
<stub> Sorry, distracted. Yes. Fails here too with test_on_merge
<jml> stub, I tried "./bin/test -vvv" and "./bin/test -vvv --subunit" fwiw.
<deryck> Morning, all.
<jtv> good night & good weekend, everyone
<gmb> So... now that I've put some code in lazr-js - woot, etc. - how on earth do I get my local copy in my LP branches to use that code?
<jml> gmb: versions.cfg; ./bin/buildout; see doc/buildout.txt
<gmb> jml, Ta.
<deryck> gmb, oh but wait ;)
<gmb> Oh bother.
<deryck> gmb, you'll have to coordinate with rockstar.  He's updated yui in the latest release and there are some blockers to deploying a new lazr-js.
<gmb> *facepalm*
<deryck> yup
<deryck> I've got a fix about to land in lazr-js, too.
<gmb> deryck, Okay. I'll hang fire.
<deryck> gmb, so I would suggest work on the lp stuff you need to support the widget, and I'll coordinate with rockstar on getting this landed ASAP.
<gmb> deryck, Right. Will do.
<deryck> gmb, great, thanks.
<gmb> deryck, Shall I mark the integration card for the Wizard blocked?
<deryck> gmb, yes, indeed.
<gmb> RIghto
<deryck> gmb, and once you get stuff in lp you want to play with in the widget, you can symlink to your lazr-js build from lp tree, I think.
<deryck> just to keep working
<gmb> Cool. Will do.
<deryck> gmb, regarding bug 575911 and a bugwatch referenced in a bug message with no imported comments.... is this something we're doing when setting up bug watches from links in comments?
<_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/575911>
<gmb> deryck, Aaaaah, this is the other half of my problem with the deletion of bug watches. Thanks; I was just trying to debug that.
<gmb> deryck, Yes, it's caused by us being too strict about what counts as deletable.
<deryck> cool, glad my question helped your thinking then.
<gmb> Don't know why it doesn't OOPS, but that blows my theory about mangling the response before the OOPS machinery gets to it away.
<gmb> deryck, Amusingly, I triaged it. I appear to have no memory of this.
<deryck> heh
<deryck> Too many bugs.
<deryck> I appreciate you helping triage malone's bugs, though, gmb.
<gmb> deryck, Natch. I think it's an easy bug to fix for a Friday afternoon. I'll look into it and if it's as simple as I think, I'll fix it today.
<deryck> good deal
 * deryck steps away for a few minutes to dress the waking baby and hand her off to grandparents
<gmb> deryck, Ah!
<gmb> Oh, no.
<gmb> Wait.
<gmb> Damn.
<gmb> Clever thought was not clever.
<gmb> Never mind.
<gmb> deryck, So, I think the thing that causes the problem is an easy fix, but we'll have to do some data cleanup to make the currently non-deletable watches deletable.
<gmb> I'll update the bug once I'm sure, but I'll fix the initial problem now since it's quick and easy.
<deryck> gmb, sounds good.
<cr3> gary_poster: hey dude, I hope your stack is better now :)
<gmb> adeuring, Were you able to solve your OOPS-not-being-raised error?
<adeuring> gmb: not really. But spooted another missing OOPS report
<adeuring> s/spooted/spotted/
<gmb> adeuring, Are you getting the Please Try Again page?
<gmb> (instead of an oops)
<salgado> sinzui, I'm getting http://paste.ubuntu.com/499723/ when make running.  any idea what's wrong?
<gmb> I'm asking because that's what happens when you try to delete a bug watch https://bugs.edge.launchpad.net/malone/+bug/575911, and the error being raised there is an IntegrityError. Don't know if that helps you any.
<_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
<adeuring> gmb: the problem appeared in connection with the speical Librarian error message ("feng shui in the server room")
<adeuring> that page does not mention an OOPS ID
<sinzui> salgado, I have seen that on a dirty shutdown. I kill all procs, then rm /var/tmp/*.pid
<adeuring> but an OOPS _should_ have been raised. problem was that I found IIRC one OOPS report where I would have exected 10 or 20
<sinzui> salgado, the mailman pid could be from weeks ago if you have not use run all in a while
<salgado> sinzui, right, that made it possible to run, but I was wondering about the "ImportError: No module named mailman.monkeypatches.defaults" error
<salgado> that one persists
<sinzui> salgado, sorry, I see another error. is your trunk up to date. I moved moneypatches to lp/services/mailman a few days ago
<salgado> yeah, I just ran rf-get
<salgado> sinzui, looks like lib/mailman/Mailman/mm_cfg.py wasn't updated?
<sinzui> salgado, I think that is generated
<gmb> adeuring, That is indeed "special." Where "Special" translates as "Nutzlos."
<adeuring> gmb: exactly ;)
<sinzui> salgado, regardless, I have a new pristine branch and will try now
<salgado> oh, indeed it is auto-generated.  I'll try removing it
<sinzui> salgado, I have from lp.services.mailman.monkeypatches.defaults import *
<salgado> can't seem to get it to be generated again, now that I've removed it
 * sinzui thinks
<sinzui> salgado, make compile should call buildmailman,py
<sinzui> salgado, make clean will purge the whole mailman dir
<salgado> yeah, but that's called by make run
<salgado> I was trying to avoid a make clean because it takes too long to rebuild after that.  I'll live without that file for now and once it causes problems I'll rebuild
<salgado> thanks sinzui
<sinzui> np
<salgado> jcsackett, do you have some sample URLs for the pages you've changed in unknown-translations-service-643545-0?
<jcsackett> salgado: yes, i've posted links in the MP
<jcsackett> salgado: my last comment on it is a list of links and what's on them.
<salgado> jcsackett, oh, as comments, I see them now.  was looking at the description
<jcsackett> salgado: ah, yeah. sorry about that.
<salgado> no worries.  thanks for adding the demo data to exercise the changes. :)
<jcsackett> salgado: thanks for the suggestion of doing that in your last review. :-)
<gmb> Ursinha, matsubara: Do either of you have any idea why the OOPS machinery wouldn't catch an IntegrityError raised by BugWatch.destroySelf()?
<matsubara> gmb, don't know. how do you know it's raising an IntegrityError and no oopses is being generated?
<gmb> matsubara, I'm reproducing it locally and instead of an OOPS page I get a ProxyError.
<gmb> matsubara, I can talk you through reproducing it if that helkps.
<gmb> (Also, nothing is showing up in my /var/lperr directory)
<matsubara> gmb, I can try to reproduce locally
<gmb> matsubara, Okay. I'll paste some instructions for you, hang on...
<matsubara> thanks
<gmb> matsubara, This is https://bugs.edge.launchpad.net/malone/+bug/575911, FTR.
<_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
<gmb> matsubara, http://pastebin.ubuntu.com/499735/
<sinzui> mars, retarget questions, not assign them. https://answers.edge.launchpad.net/launchpad/+question/126444 need to be in launchpad-registry so that all answer contacts are notified
<mars> sinzui, garh, sorry
<mars> done
<matsubara> gmb, looks like it's failing before the oops code have a chance to log it. line 568 in webapp/publication.py. not sure why though
<matsubara> gary_poster, can you help gmb diagnose why an IntegrityError is not being logged correctly as an oops report?
<gary_poster> on call will ping
<gmb> matsubara, gary_poster: Thanks.
<rockstar> deryck, have you landed your patch I reviewed yesterday yet?
<deryck> rockstar, yup.  Just did an hour or so ago.
<rockstar> deryck, good.  I'm wrangling lazr-js and our launchpad build system as we speak.
<deryck> awesome!
<bdmurray> as zope's test browser doesn't correctly set the referrer how can I test "ReturnToReferrerMixin" in a story?
<gary_poster> bdmurray: have you already surveyed similar tests?  I don't remember if the answer is there, but I remember confronting it. :-/
<gary_poster> gmb, ok looking now...
<bdmurray> gary_poster: yes, I didn't find anything obvious
<gary_poster> gmb, ok so the only way to get a traceback is to dupe, eh?  Trying.
<gary_poster> bdmurray: did you find the tests dealing with REFERER, and they used another mechanism, or you didn't find pertinent tests?
<bdmurray> gary_poster: All the clicking of Cancel tests I could find didn't seem to use ReturnToReferrer in the view
<gary_poster> bdmurray: lemme do a grep; I probably can't help easily, but I'll give it a quick whirl...
<gary_poster> bdmurray: see if lib/canonical/launchpad/pagetests/standalone/xx-offsite-form-post.txt helps
<bdmurray> gary_poster: looks like it will thanks
<gary_poster> cool, np
<bigjools> gary_poster: do you know of a context manager (or similar) that does the same as the @write_transaction decorator?
<gmb> gary_poster, Yes (sorry, was OTP)
<gmb> gary_poster, I don't know why that IntegrityError isn't becoming an OOPS.
<gmb> I know why the error is happening, and I'm fixing that, but I think it's worth making sure that this not-oopsing issue doesn't happen elsewhere, too.
<gary_poster> bigjools: no, I don't think we have one.  If you look at the write_transaction impl in lib/canonical/librarian/db.py, you can see how to manage it manually.  a context manager might be nice.
<gary_poster> gmb: understood and agreed
<bigjools> gary_poster: yeah I am going to move it out of that location, it causes circular imports :(
<gary_poster> ah :-/
<bigjools> (I need it in a database class)
<gary_poster> gotcha
<bigjools> I'll maybe write a context manager sometime
<gary_poster> it would be reasonable to put in the transaction library
<gary_poster> as would a CM
<bigjools> maybe in the next century when I get some free time
<gary_poster> :-)
<bigjools> gary_poster: I am looking at putting it in lp/services/database/__init__.py
<gary_poster> sounds very reasonable bigjools
<bigjools> ok thanks gary_poster
<gary_poster> np
<gary_poster> gmb, I don't see how to do step 2 in http://pastebin.ubuntu.com/499735/
<gmb> gary_poster, Expand the top bug task using the little expander thing on the left hand side
<gmb> (Old school, this)
<gary_poster> ah@
<gary_poster> !
<gary_poster> got it thanks
<gmb> gary_poster, And yes, "None, the report is updated manually" is listed twice. It's age-old, that bug.
<gary_poster> ah ok, so it doesn't matter which one
<gmb> gary_poster, Nope. I just use the first one.
<gary_poster> cool
<gary_poster> ok yay, duped
<gary_poster> gmb, the reason is that the error happens within the transaction commit, which is outside of the application code.  This is a bug, though not one that will be solved soon, because it will involve replacing or changing the core Zope publication library (I'd like to replace, but as you might expect, that's not a small project).
<gary_poster> I don't think we have a bug for this particular instance of OOPS tools not catching things.  Would you be up for creating one, or shall I?
<gmb> gary_poster, Can you do it please? I'm desperately trying to to switch context in the middle of a ZCML horrorshow.
<gmb> trying *not
<gary_poster> gmb, will do.
<gmb> gary_poster, Thanks.
<gary_poster> np
<EdwinGrubbs> abentley: ping
<abentley> EdwinGrubbs, pong
<EdwinGrubbs> abentley: hi, I've finally wrapped my head around the TwistedJobRunner, so I wanted to discuss with you the two possible ways I see to have it run multiple different job types in parallel.
<cr3> in launchpad tests, should Fake classes for testing purposes be located in the tests themselves, like in test_foo.py, or under a testing directory? does it depend on whether the Fake class can be reused across more than one test module?
<abentley> EdwinGrubbs, okay.  Did you want to do this on IRC or voice-to-voice?
<jml> cr3, pretty much.
<jml> cr3, also you should look for test doubles that already exist before writing your own.
<EdwinGrubbs> abentley: mumble might be easier.
<cr3> what about Fake implementations for interfaces, so that getUtility(IFoo) returns the Fake implementation in a testing context, I haven't noticed Fake utilities registered in ftesting.zcml
<EdwinGrubbs> abentley: I added the ampoule channel to mumble. Can you join that?
<salgado> sinzui, deryck[lunch], have you seen that the heading text is broken on https://bugs.edge.launchpad.net/launchpad?
<sinzui> salgado, I do not see that
<deryck[lunch]> me either
<salgado> the "There are currently no open bugs filed against Launchpad itself."?
<salgado> might be a chromium isssue
<sinzui> that is true
<sinzui> salgado, the bugs were retargeted to the app
 * deryck fires up chromium
<deryck> ah ha
<salgado> it works on epiphany
 * sinzui is using chromium
<deryck> thought this was fixed already.  Must have regressed.
<salgado> sinzui, I mean that the sentence is broken here; the first two works show up beside the search form
<salgado> and the rest below it
<salgado> s/works/words
<salgado> deryck, you see that too?
<sinzui> epiphany and chromuim look identical to me. I see the search box, and below it I see a bold statement and below that I see a link a report a bug link
<deryck> salgado, yes, I see it.  Sorry on call now.
<salgado> sinzui, are you on chromium 7.0.531.0 (nightly build)?
<deryck> salgado, I'll reopen the bug about float issues in chromium.
<salgado> deryck, cool, thanks
<deryck> np
<abentley> gary-lunch, I have some questions about how view configuration works when there are multiple potential matches.
<mars> sinzui, jinx!
<sinzui> ha
<gary_poster> abentley: having another conversation/pursuing bug, but can follow along here too probably
<abentley> gary_poster, We have shared code for "comments", where comments can actually be bug comments, code review comments, revisions, package diffs, and I'm adding incremental diffs to the list.
<abentley> gary_poster, There's a "default" comment header that I don't want incremental diffs to use.  But it's being used anyway.
<gary_poster> how is it registered, and how is the one you want registered?  Alternatively...
<abentley> gary_poster, here are the configurations: http://pastebin.ubuntu.com/499890/
<gary_poster> the order of preference for a multi-adapter like a view is to try to match the first element (context in this case) as much as possible, and then go to the second (request).  For eact item, interfaces directly declared on the instance have precedence, after which interfaces declared on the class, in __iro__ order for each interface and standard Python base class resolution order for the bases
<gary_poster> looking
<gary_poster> abentley: my guess is that class effectively resolves so that lp.services.comments.interfaces.conversation.IComment comes before lp.code.browser.branchmergeproposal.IIncrementalDiffComment
<abentley> gary_poster, I will examine that.  It could be that it's declared to implement ICodeReviewComment directly, I guess.
<abentley> s/ICodeReviewComment/ICommeng/
<gary_poster> k
<abentley> gary_poster, thanks.  That looks like it solved it.
<gary_poster> great, abentley
<cr3> heh, just came across this comment from 2005: if steveIsFixingThis :)
<rockstar> gary_poster, if I make a library available in PyPI, do I need to worry about putting an egg into lp-sourcecode-whatever?
<gary_poster> yes, but very easy: comment out "install-from-cache = true" from buildout.cfg, specify version in versions.cfg, and run buildout.  Then it will be in lp-sourcecode-whatever
<gary_poster> (then uncomment)
<rockstar> gary_poster, so then I have to commit the egg in lp-sourcecode-whatever?
<gary_poster> rockstar: yes (or if you want to test it on ec2 first there's a flag for that)
<rockstar> gary_poster, hm.  I fail to see the benefit in putting it on PyPI then.
<gary_poster> sharing?
<gary_poster> open source?
<gary_poster> collaboration in the Python community? :-D
<rockstar> gary_poster, yeah, I'm not sure that these tools would be of use to anyone else.
<gary_poster> then there is no benefit.
<rockstar> gary_poster, at least in this case, I'm probably going to eggify locally first, and then worry about PyPI later.
<gary_poster> cool
<rockstar> (I'm sure we can make the tools effective enough to be of value to others)
<gary_poster> good.
<gary_poster> bye all.  back Wed.
<EdwinGrubbs> abentley: did you get a chance to look at my email?
<abentley> EdwinGrubbs, I started, but got distracted.  Lemme look again.
<mwhudson> poolie: that branch landed the second time :/
<abentley> EdwinGrubbs, yeah, that's the basic idea.
<EdwinGrubbs> abentley: ok, I'll try to get that into review by Monday.
<abentley> EdwinGrubbs, Be careful of lock files.  It would be easy to have each forked process prevent the others from running.
<EdwinGrubbs> abentley: good point
<abentley> EdwinGrubbs, if you make queued-job-runner a commandline argument, it becomes easy to configure different JobSources for different machines.
<abentley> EdwinGrubbs, I might do if getattr(section, 'runner_class', 'JobRunner') == 'JobRunner'.
<rockstar> Since when does Launchpad INCORPORATE GAME MECHANICS?
 * rockstar goes to a corner to sob.
<abentley> EdwinGrubbs, oh, and I think you want to _exit() if pid == 0 after script.lock_and_run
<abentley> rockstar, stand-up?
<EdwinGrubbs> abentley: yes, there are plenty of bugs in it still.
<rockstar> abentley, absolutely.
<rockstar> abentley, hm, I seem to have forgotten my skype headset.  Lemme see if it would be cheap to POTS call you.
<abentley> rockstar, I can SkypeOUT you.
<rockstar> abentley, yeah, but then you have to pay for my absentmindedness.
<abentley> rockstar, yeah but so little I don't really care.
<rockstar> abentley, if it's alright, then sure.
<abentley> rockstar, there's also Truephone, which is a lot like Skype, but supports Android.  We could try that next time you forget your headset.
<rockstar> abentley, oh yeah.  That would be good.
<rockstar> abentley, I try to come down and cowork on Fridays. Otherwise, I start having long philosophical conversations with my dog.
<abentley> rockstar, :-)
<poolie> thanks mwh
<mwhudson> poolie: actually i didn't land
<mwhudson> poolie: because of testfix
<poolie> oh ok, but we know it passed
<poolie> so lp-land will send mail direct to pqm, assuming that you have already run the tests on ec2 or locally?
<mwhudson> poolie: yeah, i think lp-land is the tool for this job
#launchpad-dev 2010-09-25
<poolie> rockstar: ? i'm intrigued
#launchpad-dev 2010-09-26
<lifeless> moin
<mwhudson> lifeless: it's monday morning and there's nothing from you on https://code.edge.launchpad.net/launchpad/+activereviews! what's going on?
<mwhudson> heh, live-build git trunk got completely rebased it seems
<mwhudson> and i got 358 emails about it
<lifeless> mwhudson: I'm working on the librarian test infrastructure
<lifeless> lp:~lifeless/launchpad/test
<lifeless> I was going to propose it once I've got a bit deeper down the rabbit hole.
<lifeless> then I ran out of disk in my vm.
<lifeless> :P
<mwhudson> fair enough
<mwhudson> ouch
<lifeless> also Civ V was released on friday.
<mwhudson> :)
<lifeless> the FooSetup().tearDown() style scares me shitless
<lifeless> just soo much implied global state.
<lifeless> me no likey
<mwhudson> all that stuff is super old i think
<mwhudson> e.g. the database stuff
<lifeless> did I show you the zope.testing.functional helper?
<lifeless> grep for 'self.__dict__.update' in your eggs
<lifeless> or was it self.__dict__ =
<lifeless> I can't remember.
<thumper> mwhudson: the number of emails there completely sucks
<thumper> morning people
<lifeless>  
<lifeless> hi thumper
<lifeless> \o/
<lifeless> Could not communicate with subprocess
<lifeless> **********************************************************************
<lifeless> Exception KeyboardInterrupt in <module 'threading' from '/usr/lib/python2.6/threading.pyc'> ignored
<thumper> ?
<lifeless> just mutting about the guts of our test environment
<lifeless> keyboardinterrupt being raised in a thread is highly suspicious
<thumper> email backlog cleared out
<lifeless> mars: around?
<wallyworld> morning
<thumper> wallyworld: morning
<wallyworld> thumper: well, not a good morning so far. bloody teenage kids, who needs them :-(
<thumper> heh
<thumper> I have some kids fighting here too
<wgrant> wallyworld: Oi!
<wallyworld> hi wgrant
<wgrant> Morning.
<wallyworld> thumper: yeah, but it gets way worse when they are 16 and think they are king of the castle
<mwhudson> https://code.edge.launchpad.net/~mwhudson/+junk/test/+linkblueprint is an amusing page
<thumper> mwhudson: not so much
<thumper> wallyworld: skype?
<mwhudson> thumper: it's not linked to, at least
<wallyworld> you must be psychic - i was just about to ask the same thing
<thumper> mwhudson: well that's something
<thumper> wallyworld: yes, I am psychic
<thumper> wallyworld: yes, I know what you are thinking
<thumper> wallyworld: and no, you don't want to type that
<wallyworld> "that"
#launchpad-dev 2011-09-19
<lifeless> any reason we can't run it right after ?
<wgrant> It'd run into the 0902 run, so that wouldn't happen.
<lifeless> wgrant: can has review?
<wgrant> lifeless: Sorry, missed that. Will look in a sec.
<wgrant> Just fixing test failures from yesterday's largish branch series.
<wgrant> lifeless: Could you do the sort of query that jtv asked for https://code.launchpad.net/~jtv/launchpad/bug-613823/+merge/75773?
<wgrant> lifeless: The approver is cronned on staging.
<lifeless> wgrant: hmm ?
<wgrant> lifeless: There are QA instructions in that MP.
<wgrant> I don't have staging DB access.
<lifeless> sorry to be a nuisance, but can you translate to sql ?
<wgrant> SELECT * FROM translationimportqueueentry WHERE error_output IS NOT NULL AND status = 5 ORDER BY date_status_changed DESC LIMIT 10;
<lifeless> 0
<wgrant> That's upsetting. I guess I will check it with hloeung later.
<wgrant> lifeless: Does oops-timeline really only lose us two lines of code?
<lifeless> wgrant: yes, but it saves duplication for other folk glueing them together
<wgrant> Two lines of duplication?
<lifeless> about 10
<wgrant> stsly?
<lifeless> duplication has never been about size of code though
<wgrant> srsly?
<wgrant> lifeless: Do our consumers cope with the s/db_statements/timeline/?
<mwhudson> https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc/+merge/75673 if anyone is bored...
<lifeless> wgrant: oops-tools is a version locked buildout project.
<lifeless> wgrant: it uses datedir-repo which this change doesn't affect, because its not a labelled key in the rfc822 format
<lifeless> wgrant: that said, I have a branch for it which updates-and-corrects
<lifeless> wgrant: that also needs a review :) - code.launchpad.net/~lifeless/oops-tools/timeline/+merge/75941
<lifeless> mwhudson: ping
<mwhudson> lifeless: hello
<lifeless> want to talk (you know, by airwaves) about branch access?
<mwhudson> ah sure
<mwhudson> lifeless: mumble/skype/pots
<mwhudson> ?
<lifeless> the second door
<poolie> mwhudson, just a random idea
<poolie> is it cleaner to pass a dict that can contain a username and possibly other stuff?
<poolie> i don't know if that will be easier to evolve or not
<mwhudson> poolie: what would the values in the dictionary be?
<lifeless> objects!
<poolie> username='mbp' client_ip='1.2.3.4'
<poolie> etc
<mwhudson> ah
<poolie> bzr_version='2.4.4'
<mwhudson> lifeless: haha, this is xmlrpc
<poolie> #quotes
<wgrant> lifeless: Ahh, so it doesn't actually make a difference in the serialised format?
<lifeless> right
<lifeless> wgrant: were you going to review the oops-tools one too ?
<wgrant> lifeless: Done.
<StevenK> Oh look, pocketlint deals with JS.
<StevenK> If only I knew that on Friday.
<nigelb> heh
<nigelb> What happened on Friday?
<nigelb> Also, I thought pocketlint dealing with JS was one of its biggest advantages.
<StevenK> I was dealing with the same JS branch, but I had broken the JS badly so Firefox didn't love me and refused to render the page
<nigelb> Ouch.
<nigelb> Didn't firebug help?
<StevenK> No, it just told me I had a syntax error on line 68,000 something
<StevenK> Which wasn't very handy
<nigelb> Yeah.
<nigelb> I like how firebug throws a weird bug when you make a mistake in JSON.
<nigelb> I spent about 20 minutes for that, until I discovered jsonlint helps.
<nigelb> StevenK: But if you click on the error it should take you to that line, letting you debug it.
<nigelb> Not like that's easy either.
<StevenK> Anyway, pocketlint has solved my issue.
<nigelb> :)
<nigelb> I hope noone stabs me for the number of revisions I've made undeployable.
<wgrant> You've only made 13 undeployable, which is probably the least I've seen from non-APAC breakage.
<wgrant> I get stabby when it gets above 50.
<nigelb> non-APAC?
<StevenK> APAC is Asia-Pacific
<wgrant> US/EU breakage often gets nasty.
<nigelb> "technically" I live in APAC
<wgrant> Well, yeah.
<wgrant> Just!
<lifeless> easily
<lifeless> asia goes -way- west
<wgrant> Shh.
<nigelb> Middle east is west of me.
<nigelb> So, i'm not "just" Asia :P
<lifeless> isn't it to the bosphorus?
<nigelb> Yeah
<lifeless> beautiful river
<nigelb> lifeless: At some point I need to pick your brain further re:js-oopsd
<nigelb> But at a later point when I'm not sleep deprived!
<wgrant> reprocess-hwdb-submissions is doing well for itself.
<wgrant> 90272 None: None
<lifeless> nigelb: ok
<wallyworld___> lifeless: can you tell me the code that gets invoked when serving loggerhead pages like to http://bazaar.launchpad.net/~johndoe/project/files
<wgrant> wallyworld___: You're trying to add the privacy overlay thing?
<wallyworld___> yes
<wgrant> Run away.
<wgrant> We have no loggerhead customisation story these days :/
 * wallyworld___ starts running
<wgrant> Which means we have to copy the LP-specific template and JS into the loggerhead tree. And have it there polluting everyone's installations.
<wgrant> Even though it's only relevant to us.
<wgrant> And our theme.
<wallyworld> yuck
<nigelb> Can't fork it?
<wgrant> Forking it is not a good option.
<nigelb> Like have a branch with launchpad changes, and keep merging trunk into it.
<wgrant> We should have an alternate theme.
<wgrant> Well.
<wgrant> Really we should use LH as a service.
<lifeless> erm
<wgrant> And import it into the LP UI.
<lifeless> right
<mwhudson> if request is a ILaunchpadRequest, what is request.principal?
<wgrant> But that may happen in three decades.
<lifeless> the ideal thing is to make LH a background service.
<wgrant> Until then we need something better.
<wgrant> mwhudson: *probably* an IAccount.
<lifeless> in the mean time, we a) maintain loggerhead, b) deploy trunk.
<wgrant> mwhudson: Or it may have an adapter to IAccount.
<nigelb> AH
<lifeless> Guest73189: your nick is bust :)
<Guest73189> yeah :-(
<Guest73189> keeps happening
<nigelb> So logggerhead won't actually show files form a private branch?
<wgrant> nigelb: It does.
<wgrant> nigelb: It just doesn't say that it's private.
<nigelb> AHH.
<mwhudson> wgrant: ah, it's a ILaunchpadPrincipal
<nigelb> Stupid question - Isn't loggerhead already a service?
<mwhudson> (well, if it's not unauthenticated)
<wgrant> mwhudson: Does that handle stuff like IWeaklyAuthenticatedPrincipal?
<wgrant> (which should really be INotActuallyAuthenticatedAtAllPrincipalButSomePeopleApparentlyCannotHandleEmailSigningBecauseTheyLikeToUseGmail, but that's a bit long)
<nigelb> heh
<mwhudson> wgrant: basically
<mwhudson> i have a request
<mwhudson> i want a person, or None
<nigelb> I remember doing this elsewhere.
<lifeless> nigelb: it is but it displays a web UI of its own
<lifeless> nigelb: using different templates, middleware, and web stack.
<lifeless> nigelb: its not a *backend* service that the LP web app can consume
<nigelb> AHH.
<lifeless> nigelb: its just a sibling website that happens to be themed the same way
<nigelb> That means loggerhead should first expose such a service in trunk and then we need to grab that and use that?
<lifeless> it has a bit of such a service
<lifeless> it needs more
<lifeless> and it needs to be -much- faster
<nigelb> Agree on that one.
<lifeless> its fast-path is tolerable but its slow path needs to be two orders of magnitude faster
<lifeless> interesting  https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920
<mwhudson> (fwiw, i think IPerson(request.principal, None) is what i want)
<StevenK> wallyworld__: Can I force an overlay to the top?
<wallyworld__> StevenK: you mean so that it always stays on top?
<StevenK> wallyworld__: Give me a tick, preparing screenshots
<wallyworld__> ok
<StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popup.png
 * wallyworld__ looks
<StevenK> wallyworld__: That's the "before" shot -- it's a private bug and I've clicked the "subscribed to all notifications" link for the popup
<wallyworld__> and the confirm overlay appears beneath?
<StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popunder.png
<nigelb> Needs z-index magic :-)
<wallyworld__> StevenK: overlays have a zIndex propety
 * wgrant invokes mpt.
<wallyworld__> StevenK: default is 0
<StevenK> Oh no, I've angered wgrant.
<wgrant> Nested overlays... this doesn't seem right.
<wallyworld__> StevenK: http://yuilibrary.com/yui/docs/overlay/
<StevenK> wallyworld__: Higher is on top, or lower is?
<wallyworld__> StevenK: ummmm. higher i *think*
<nigelb> Higher.
 * nigelb helpfully links to http://www.w3schools.com/cssref/playit.asp?filename=playcss_z-index&preval=2
<wallyworld__> StevenK: sort of agree with wgrant though. i'd like to see the click in the "remove" link result in the confirmation exapnding out below the link via an animation
<wgrant> Right.
<wallyworld__> sort of like for the stuff i did for confirming bug assignees
<wgrant> The dialog mutate by expanding, or using a second step.
<wgrant> s/mutate/should mutate/
<StevenK> You two suck, or something.
<wgrant> Dialogs are bad the best of times.
<wallyworld__> you've been peeking in my window again haven't you
<nigelb> Actually, I'll agree with them as well.
 * wallyworld__ needs to close the curtains
<StevenK> s/two/three/
<nigelb> So, StevenK wasted 2 days of JS hacking only to be mpt'd :P
<StevenK> Not really
<StevenK> Since there are two callsites
<wgrant> I always expect a few days of hacking on a new technology to have to be thrown out at least a couple of times.
<wgrant> And while feature squads seem to like introducing tech debt and terrible UI, I think we should try to do this at least vaguely properly.
<nigelb> what's tech debt? I see that used in tags.
<wgrant> Launchpad.
<nigelb> Heh.
<wgrant> Launchpad is mostly tech debt.
<wgrant> http://c2.com/cgi/wiki?TechnicalDebt
<lifeless> wgrant: I've seen worse.
<wgrant> lifeless: Huh?
<wgrant> Where?
<wgrant> COBOL doesn't count.
<nigelb> Ah.
<wallyworld__> wgrant: minestar
<lifeless> wgrant: Micropay
<wgrant> OK, software that isn't meant to be enterprisey?
<lifeless> wgrant: .... unlike LP ?
<wallyworld__> wgrant: win32 api :-)
<nigelb> Isn't LP the enterprisey codehosting website? ;-)
<wgrant> LP isn't meant to be enterprisey, I don't think. It is, but I don't think it was meant to be.
<lifeless> wgrant: and yeah, a few things do come to mind that rival LP for 'wants refactoring soooo bad'
<nigelb> It may not be meant to be enterprisey, but some of the best features are enterprisey.
<nigelb> (lp)
<lifeless> wgrant: see rule #1: all software sucks.
<wgrant> lifeless: We just have no way to make it not suck.
<wgrant> Because nobody wants to reduce tech debt.
<nigelb> Delete more code. That's code that's guaranteed to not suck :-)
<wgrant> Maintenance squads can't fix it, and feature squads won't.
<wgrant> => we are fucked
<wgrant> :)
<StevenK> Everything will be better when we have no criticals.
<StevenK> OH WAIT
<wgrant> Hahahahahahahhaa
<nigelb> Bwahaha
<StevenK> I could not help myself ...
<wgrant> Speaking of which,.
<nigelb> 390 bugs with tech-debt :/
<wgrant> nigelb: And that's mostly just the really bad stuff.
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: -| Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated
<StevenK> Bleh, still 260.
<StevenK> We are going *backward*
<nigelb> wgrant: Some seem to be not very had.
<nigelb> *hard
<wgrant> nigelb: Some aren't, no.
<wgrant> nigelb: And even the big stuff is not hard.
<wgrant> I spent a few hours yesterday and very nearly disposed of Zopeless.
<StevenK> wgrant: How did that turn out?
<wgrant> StevenK: Some test failures in the last branch in the series.
<wgrant> Which removes ZTM's commit/abort/begin methods, and initZopeless' return value.
<wgrant> Leaving ZTM to be moved into DBConfig in the next branch.
<wgrant> Still have to strip out Zopeless mail somehow.
<wgrant> But it's all pretty well detangled now.
<lifeless> great
<wgrant> initZopeless' callsites are limited to core base classes and buildd-manager.
<wgrant> Which means we can finally untangle the damned dbuser handling.
<wgrant> Which is roughly quadruplicated at the moment.
<mwhudson> poolie: is there a reason that there are scopes team:foo but server.edge?
<wgrant> And it also means the Zopeless layers can die, which simplifies things a bit.
<mwhudson> i.e. ':' vs '.'
<poolie> mwhudson, i don't think there's any really good reason
<poolie> you could look at it as 'server_edge=True' vs 'server=edge
<lifeless> o/ 90K hwdb exceptions
<wgrant> Yup, the reprocessing seems to be going well...
<lifeless> 181 AttributeError: 'LaunchpadTimeoutError' object has no attribute '__traceback__' looks suspect
<wgrant> lifeless: I pointed that out last week, yeah. The attempted reraising is bad.
<wgrant> __traceback__ was added in 2.7, wasn't it?
<lifeless> wgrant: did you file a bug ?
<wgrant> Maybe even 3.x.
<wgrant> No.
<lifeless> wgrant: or reopen it ?
<wgrant> I had three production breakages.
<lifeless> I'm not criticising
<lifeless> I'm asking so I don't duplicate work.
<wgrant> You should have been :P
<wgrant> I haven't, no.
<wgrant> Well, really I wanted to see if anyone else would pick it up.
<lifeless> IIRC benji worked on it ?
<wgrant> I think that's right.
<wgrant> lifeless: So, for science, I'd like to leave it a couple of days and see if a maintenance squad notices.
<lifeless> well
<lifeless> I've mailed benji
<wgrant> :(
<StevenK> SUCCESS!
<StevenK> My confirmationoverlay works for +subscriptions
<StevenK> wallyworld__: *prod*
<wallyworld__> StevenK: ouch!~
<wallyworld__> StevenK: excellent
<wallyworld__> StevenK: you are now a yui expert :-)
<nigelb> Trapped! :P
<wallyworld__> and i'll assign all the js bugs to you!
<StevenK> wallyworld__: Suggestions about how to break up the form_content in http://pastebin.ubuntu.com/692723/ ?
 * wallyworld__ looks
<nigelb> wgrant: Deploying today?
<wallyworld__> StevenK: you can use a join
<wallyworld__> give me a sec and i'll find an example
<wgrant> nigelb: Funny you should ask.
<wgrant> 13:09:58 < wgrant> hloeung: We need to do a nodowntime rollout today so we can turn gina on.
<wgrant> nigelb: So, you weren't quite perfectly timed, but 'tis acceptable.
<nigelb> wgrant: Almost immediately? :-)
<nigelb> what channel was that? Canonical IRC?
<wgrant> Maybe. Some preparation to do, and we are down to one LOSA this week.
<StevenK> nigelb: Yes, a private one.
<wgrant> Yeah, that was #launchpad-ops on the Canonical network.
<lifeless> mwhudson: don't you hate all the boilerplate glue to say 'this code at that endpoint' ?
<mwhudson> lifeless: YES
<nigelb> StevenK: ah, I have an example of join somewhere I think.
<mwhudson> i used a bit less boilerplate than some though
<wallyworld__> StevenK: search for join('') or join("") in js
<wallyworld__> there's quite a few places
<mwhudson> some endpoints have the xml-rpc methods in a view on the application endpoint object
<wallyworld__> StevenK: you can use string concat if it's only 2-3 lines.
<mwhudson> i just put the methods on the application endpoint object
<nigelb> StevenK: ['foo', 'bar'].join('')
<wallyworld__> but any longer, a join is recommended
<nigelb> where foo and bar are 50 to 70 chars each.
<nigelb> wgrant: I'm technically a jQuery person more, but YUI is quite neat :-)
<nigelb> err
<nigelb> wallyworld__: ^
<wallyworld__> nigelb: ?
<nigelb> wallyworld__: I played around a lot with it for that bug title fix. Its different, but now I think in a better way.
<wallyworld__> nigelb: oh, you mean you like yui. it's not too bad actually. i think it's 2nd most popular framework behind jQuery
<StevenK> wallyworld__, nigelb: Fixed, thanks.
<nigelb> StevenK: \m/
<StevenK> I think I need to revert bug_subscription_portlet changes while I work out how to expand it
<StevenK> Perhaps I'll do the changes in two branches
<lifeless> mwhudson: I've done a review
<lifeless> mwhudson: its probably a bit opaque. Two key things - please don't duplicate code (team: magic string handling), and a bit fuzzier one that you may want to ping me on
<mwhudson> lifeless: you have?  i don't see a review
<lifeless> mwhudson: process-incoming.py
<mwhudson> ah
<mwhudson> lifeless: did you see my response to poolie's comments?
<StevenK> wallyworld__: I'll grab you after lunch on how to test this thing?
<wallyworld__> StevenK: ok
<nigelb> YUI tests! Fun! :-)
<StevenK> wallyworld__: No promises on where I'll grab you
<lifeless> yes, I think dict for scopes was confusing (because scopes are containers), but coming from the same place I am
<StevenK> :-P
<wallyworld__> oh, one can only hope
<lifeless> mwhudson: docs are in docstrings.
<mwhudson> lifeless: were you under the impression that i know what you're talking about?
<lifeless> mwhudson: yes!
<lifeless> mwhudson: poolie pointed you at docs, you found an empty file.
<mwhudson> well, i still don't know what needs to be _updated_
<lifeless> mwhudson: I believe they are in module docstrings instead
<mwhudson> all the code i added has docstrings
<lifeless> yes, but nothing points at your code; thats the point I think.
<mwhudson> ah oik
<lifeless> __init__.py
<mwhudson> lifeless: were you reviewing the originally proposed version, or r13974 ?
<lifeless> mwhudson: the mailed out version
<mwhudson> lifeless: ok, look again please
<lifeless> much better
<lifeless> mwhudson: back to you :)
<mwhudson> lifeless: lol, guess what my working copy looks like
<mwhudson> default_scopes = (DefaultScope(),)
<lifeless> mwhudson: :)
<mwhudson> lifeless: back to you (hopefully not much more of this)
<lifeless> mwhudson: your example is missing a :
<lifeless> 'codehosting.use_forking_server', ['user:' + user_name])
<lifeless> ->
<lifeless> 'codehosting.use_forking_server', ['user:' + user_name]):
<mwhudson> ah
<mwhudson> ok
<mwhudson> lifeless: thanks
<mwhudson> i wonder if i can still land code ...
<lifeless> should be able to
<lifeless> have I put you in the emeritus team yet ?
<mwhudson> don't think so
<lifeless> want me to?
<mwhudson> lifeless: are you aware of a bug report about this?
<lifeless> about what?
<lifeless> oh
<lifeless> uhm
<lifeless> there may be one
<mwhudson> lifeless: what impact does being the emeritus team have?
<mwhudson> ok, i'll search
<lifeless> you'll get review mail which we don't [yet] have a good offswitch for
<lifeless> you get bugcontrol privs, and push privs to ~canonical-launchpad-branches
<lifeless> mwhudson: ah you are in it
<mwhudson> oh ok
<lifeless> https://launchpad.net/~canonical-launchpad-emeritus
<mwhudson> i don't get review mail...
<StevenK> No PQM access?
<mwhudson> (which i am happy with, before you do anything about that :p)
<lifeless> mwhudson: its not fully setup up :)
<lifeless> mwhudson: the intent is to get you review privs, which currently implies mail.
<lifeless> mwhudson: [sorry]
<mwhudson> lifeless: i appear to be able to approve merge proposals
<mwhudson> i am still in ~launchpad mind
<lifeless> mwhudson: ah, well then :P
<lifeless> mwhudson: its moot till you leave that
<mwhudson> ok
<lifeless> StevenK: yes, if pqm is integrated with LP (which it was till the code decided their old automation design was wrong)
<StevenK> lifeless: Right, so the intent is that canonical-launchpad-emeritus members continue to have PQM?
<lifeless> StevenK: the intent is that emeritus devs lose nothing if they are still @ canonical, and lose write-to-deployed-branches only, if they are not.
<lifeless> e.g. be as close to an open source project as we can with our current constraints
<StevenK> wallyworld__: *grab*
<StevenK> wallyworld__: Let me just get some tea
<wallyworld__> StevenK: oooh. a little hiher
 * StevenK goes to scrub his hands with solvol and steel wool
<wallyworld__> StevenK: so you got your tea?
<StevenK> wallyworld__: Indeed. Ready when you are.
<wallyworld__> StevenK: ok, so you want to write a yui test for your confirmation overlay functionality?
<StevenK> wallyworld__: Yup. I'm on mumble if that makes it simpler.
<wallyworld__> StevenK: ok. i'll just grab my headset. one of the kids has nicked it
<StevenK> Hah
<wgrant> Ah, finally.
<wgrant> ~jans has added their OpenPGP key.
<wgrant> They've uploaded 18 packages this morning.
<wgrant> Over several hours.
<wgrant> Causes lots of process-upload cronspam :(
<StevenK> Hah
<wgrant> But maybe it will stop now.
<nigelb> wgrant: Don't you have filters for that sort of thing?
<wgrant> nigelb: That's one of the few user errors that still generates emails.
<wgrant> nigelb: I tried to fix it one day, but then found terrible security holes and never visited that code again.
<wgrant> Ah, I see that sinzui had a productive anti-tech-debt Sunday as well.
<nigelb> :)
<StevenK> wgrant: Oh?
<wgrant> StevenK: You might recall I was talking about pagetitles last week on the call.
<wgrant> StevenK: sinzui deleted much of it.
<StevenK> Neat
<mwhudson> wgrant: can you talk to sinzui about blueprints next?
<wgrant> Heh
<StevenK> Haha
<nigelb> Just delete the folder?
<nigelb> I can do that. :P
<StevenK> mwhudson: You want blueprints deleted?
<wgrant> Damn, ZTM will probably fall tomorrow. Then I'll need to find another target for my wrath :(
<StevenK> wgrant: lib/canonical
<wgrant> StevenK: canonical.lp no longer exists in devel... will that do?
<nigelb> WHAT
<nigelb> !!
<wgrant> canonical.lp, not canonical.launchpad :(
<nigelb> Ah!
<mwhudson> wgrant: actually, talk to him about ILaunchBag
<nigelb> I did wonder if I patched something in canonical.launchpad only for you to delete it.
<wgrant> mwhudson: I've tried to rip out bits of that myself, but it's not easy :(
<wgrant> ZTM was pretty easy, just very involved and tedious.
<StevenK> ILaunchBag needs to die
<nigelb> Wait ILaunch*Bag*?
<nigelb> I first read it as Bug and I was WTF.
<wgrant> It's like a global variable, except more subtly hidden.
<mwhudson> wgrant: s/getUtility(ILaunchBag).user/IPerson(get_current_browser_request(), None)/ should do a bunch of it
<mwhudson> but you might get a million tests to fix
<wgrant> mwhudson: Also doesn't catch non-browser users.
<wgrant> eg. the email interface uses LaunchBag in places.
<wgrant> Because why not.
<mwhudson> ah, this relates to that other bug
<mwhudson> scripts don't do participations rite
<wgrant> Scripts do a lot of things not right.
<wgrant> I need to talk to Zope people about zope.app.testing.functional.FunctionalTestSetup, too.
<wgrant> Or maybe just replace FunctionalLayer with ZopelessLayer and see what blows up.
<mwhudson> https://bugs.launchpad.net/launchpad/+bug/623199
<_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
<wgrant> Ah
 * mwhudson evaporates
 * wgrant gets the condensor.
<StevenK> wallyworld__: How can I determine what to put in Y.one() for the overlay?
<wallyworld__> StevenK: Y.one('#id') where id is the overlay id if you know it
<wallyworld__> StevenK: or Y.one('.yui3-overlay-xxxx') where xxx is the class
<StevenK> Yes, my question is how to determine the overlay id, since I don't
<wallyworld__> StevenK: you can set the id. give me a minute to check
<wallyworld__> StevenK: you have a content_box which you create -eg Y.Node.create("<div #id='foo'></div>")
<wallyworld__> StevenK: then you can create the overlay, telling it to use this content_box
<wallyworld__> see picker_patcher.js around line 54
<wallyworld__> this creates an Activator but the concept is the same I think
<StevenK>         var co = Y.one('.yui3-overlay-confirmationoverlay');
<StevenK>         Y.Assert.isNull(co);
<StevenK> wallyworld__: ^
<wallyworld__> StevenK: are you saying the asset fails? or passes?
<StevenK> I'm not saying either yet, I'm saying that the code I have at the moment.
<wallyworld__> or that's what you are proposing
<wallyworld__> ?
<wallyworld__> ah. that will work if there's only one confirmation overlay
<wallyworld__> otherwise you will need to set the content box
<wallyworld__> in the initialisation params
<wallyworld__> of the overlay
<StevenK> If the subscription js is creating two confirmation overlays, that is news to me
<wallyworld__> StevenK: i mean on the page. so long as the node used as the root for .one() is correctly set it will work
<wallyworld__> ie use can use Y.one() which is for the whole page or
<wallyworld__> node.one() which just looks at children of the node
<StevenK> No failures
<StevenK> Let me break it
<StevenK> wallyworld__: So I get failures, but none about my code
<wallyworld__> StevenK: what sort of failures?
<StevenK> http://pastebin.ubuntu.com/692789/
 * wallyworld__ looks
<wallyworld__> StevenK: the test invokes test_unsubscribe_with_warning_action which clicks the link and looks at the mocked io values
<wallyworld__> StevenK: so with the confirmation dialog there, it doesn't get to do the expected io
<StevenK> wallyworld__: Right, so that's fine that it fails -- but test_on_unsubscribe_updates_info doesn't fail
<wallyworld__> but since your test is failing, it may be that the Y.one(.xxxx) is wrong
<StevenK> My test is failing to fail
<wallyworld__> i would use firebug to inspect the css class used
<wallyworld__> for the confirmation overlay
<StevenK> class="pretty-overlay-window yui3-widget yui3-overlay yui3-pretty-overlay yui3-lazr-formoverlay yui3-lp-app-confirmationoverlay yui3-widget-positioned yui3-widget-stacked"
<StevenK> That bit?
<wallyworld__> yep, use 'yui3-lp-app-confirmationoverlay'
<StevenK> With no dot?
<wallyworld__> sorry, with a dot
<wallyworld__> StevenK: to be pedantic, you could use Y.one('.yui3-overlay .yui3-lp-app-confirmationoverlay')
<wallyworld__> which will require both classes to be present
<wallyworld__> but try the simple case first
<StevenK> wallyworld__: Which still doesn't fail how I want
<wallyworld__> StevenK: how does it fail now?
<StevenK> wallyworld__: The same way
<StevenK> Which means Y.Assert.isNull(co) is true
<wallyworld__> StevenK: and you are sure the overlay is always being created
<StevenK> wallyworld__: Well, I'd like to debug this somehow, but I have NFI how
<wallyworld__> StevenK: you open the html harness in chrome and use firebug
<wallyworld__> or firefox
<wallyworld__> but for yui tests, chrome seems to work better
<wallyworld__> run the tests one to load the scripts, then switch to the test_xxxx.js script and set a breakpoint
<wallyworld__> and hit refresh
<poolie> o/ wallyworld__
<wallyworld__> hi poolie
<wallyworld__> StevenK: i may have mislead you. to test for both classes, you use Y.one('.foo.bar') <- without the space, slip of the fingers
<wallyworld__> poolie: how can i help?
<poolie> just saying hi
<wallyworld__> poolie: just checking, just in case :-)
<jtv> hi mrevell!
<mrevell> Morning!
<jtv> mrevell: we just rolled out a small but hopefully helpful Translations change that may be worth announcing.
<jtv> Any suggestions for how/where I ought to do that?  I haven't kept track.
<mrevell> jtv, I'd always favour a blog post. We can then reference that elsewhere.
<lifeless> wgrant: closing in on u1; up for 2 tiny reviews in the same theme ?
<mrevell> Top notch, btw.
<jtv> thanks mrevell
<rvba> wgrant: Hi, if you haven't (re-)reviewed my branch yet, I'll split the changes like you suggest.
<wgrant> rvba: That would be great -- as it stands it's pretty impractical to see what's what, as I'm sure you've found.
<wgrant> lifeless: Possibly. Links?
<lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
<rvba> wgrant: Indeed. I'll do that this morning.
<lifeless> wgrant: ^
<poolie> wallyworld__, hey thanks for grabbing bug 696954, that has bothered me in the past
<_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
<wallyworld__> poolie: np. it's on the disclosure todo list :-)
<poolie> hm
<poolie> kinda seems like some scope creep there
<poolie> but i'm happy it's getting done
<poolie> i think there may be dupes or near dupes of it
<poolie> no need to find them now i guess
<wallyworld__> poolie: disclosure covers who has access to information just as much as who doesn't
<wallyworld__> i'll try and see that any dupes are linked to this bug
<lifeless> wallyworld__: you'll need to be very careful about query changes - lots of room for foot-gun on performance in this area; OTOH brad snuck some of it in already before the re-org, so we may be lucky.
<wallyworld__> lifeless: the accepted pattern seems to be union of sub queries. i've put up a mp this afternoon along those lines and was going to do something similar here
<lifeless> wallyworld__: its not so much a matter of patern, as bug queries being right on the cliff face of timeouts
<lifeless> wallyworld__: so adding more work to them has a high probability of pushing them over the cliff
<poolie> wallyworld__, so it's kind of a beer conversation but it kind of seems like tackling every bug kinda related to the feature may cause features to run long and starvation of other areas
<lifeless> wallyworld__: -> need to make it as much faster as the extra work you are asking it to do.
<poolie> but i am really happy to see this one fixed
<lifeless> wallyworld__: I'd allow several days for dealing with performance impacts alone
<poolie> wallyworld__, oh the one i filed was bug 746887
<_mup_> Bug #746887: private bugs get stuck invisible to developers <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/746887 >
<poolie> which is a direct dupe of yours, i'd say
<poolie> but now duped against bug 696973
<_mup_> Bug #696973: There are no roles that can see all private artifacts in (public or private) projects <disclosure> <projects> <teams> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696973 >
<wallyworld__> lifeless: recently, bug task assignee was added to the allowed viewers of private bugs. i've taken the same approach for https://code.launchpad.net/~wallyworld/launchpad/pillar-owners-private-bug-visibility-702429/+merge/75961 i can give you some sql to run on staging if you want
<wallyworld__> poolie: i'll see if yours is a dup and link it
<lifeless> wallyworld__: its not that simple :) - you'll find you need to look at prod (because its in the grey area), and compare bug search timeout counts before/after you go live, and see if there is a regression, and if so toggle it off.
<wallyworld__> lifeless: actually, i can optimise it a bit - only do the sql depending on which pillar is not none
<wallyworld__> lifeless: ok. i'll make the optimisation before i land. and gather some stats as you suggest
<lifeless> wallyworld__: how? (We have queries that cover all pillars - site wide bug queries)
<lifeless> wallyworld__: one big thing you can do to make this safer is feature-flag the new query.
<lifeless> easy to do, big rewards, I mean.
<wallyworld__> lifeless: yes ok. optimisation not feasible as you say. but i will do a ff
<wallyworld__> actually, i could do the project roles work as per 969793 behind the same ff perhaps
<lifeless> bug 969793
<lifeless> no mup?
<wallyworld__> um, 696954
<wallyworld__> sorry
<wallyworld__> wrong bug
<lifeless> bug 696954
<_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
<lifeless> wallyworld__: cool; if you need specific stuff tested, yes I'd be happy to help.
<lifeless> wallyworld__: we can only get pretty gross results from staging as I mentioned though :( - clearly good and clearly bad, but its poor on 'maybe'
<wallyworld__> lifeless: thanks. i guess i'll need you if it all blows up on prod and we have to turn off the ff :-)
<lifeless> wallyworld__: trivial queries will always be fine. You'll have trouble, if you do, on: project queries (e.g. launchpad-project), and Ubuntu queries, and site-wide queries.
<wallyworld__> lifeless: well fingers crossed. if you are interested, https://pastebin.canonical.com/52955/ the unions after bug task assignee are the new ones
<adeuring> good morning
<rvba> wgrant: I know you're busy right now and this is not urgent at all, but I've refactored the branch: the first one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769 and the second one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy-2/+merge/74958
<bigjools> lifeless: are you around in about 20 minutes to talk about python-oops?
<lifeless> I think so
<bigjools> thanks, just need to do my team call
<lifeless> wgrant: sorry to be a nag, was that yes or no to the reviews?
<wgrant> lifeless: Sorry, unexpectedly busy. I can look tomorrow (I'm OCR), but I guess you want to toss them at someone else.
<lifeless> I'm nearly EOD too, I may just nab you in the morn
<lifeless> I need to finish the storm component before it all becomes relevant.
<lifeless> thats nearly done
<bigjools> lifeless: hi
<bigjools> skype?
<lifeless> sure
<cjwatson> ok, what the heck does https://launchpad.net/ubuntu/+source/clang/2.9-11ubuntu1/+build/2792745 mean
<cjwatson> "Currently building" "Finished 7 hours ago (took 18 hours, 12 minutes, 50.6 seconds)"
<cjwatson> definitely still going, still getting build output
<bigjools> it's a bug
<thumper> cjwatson: confused
<thumper> hi bigjools
 * bigjools looks up the bug
<bigjools> yo thumper
<wgrant> cjwatson: Yeah, came upon that earlier... it finished on celbalrai, but then $something happened and it was redispatched. I haven't seen that happen for 18 months...
<wgrant> cjwatson: It is building now, and should upload as normal in ~22 hours, at which time it will look sensible again,.
<bigjools> I think it's part of bug 717969
<_mup_> Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <Launchpad itself:Triaged> < https://launchpad.net/bugs/717969 >
<cjwatson> ah, ok, I wouldn't have been able to find that bug :)
<wgrant> That's a possibility, yes.
<wgrant> It's not a case of that bug that we've seen before, but it is a similar sort of thing.
<bigjools> the bug title needs to change
<bigjools> might it have been to do with the FDT?
<wgrant> bigjools: No, this was hours ago.
<wgrant> The initial issue was 6 or 7 hours ago.
<cjwatson> should I add a screenshot or something to that bug?  The evidence will go away in the near future
<bigjools> ok
<wgrant> cjwatson: That would probably be useful. Also useful is the API representation of the build: add /api/devel to the start of the path to get that.
<cjwatson> OK
<bigjools> lifeless: ok ready when you are, can't see you on skype
<lifeless> I'm rbtcollins
 * bigjools blind dials
<danilos> lifeless, hi, where's the code for ppr pages? I assume it process launchpad appserver log files, right?
<danilos> s/process/processes/
<mpt> StevenK, whatever it was I did, I apologize
<lifeless> danilos: ztrace files yes
<lifeless> danilos: its in the lp tree
<danilos> lifeless, oh right, thanks
<danilos> lifeless, btw, how would you feel if we add the request duration to the apache log files as well?
<lifeless> danilos: no particular opinion; I thought apache log format had that anyeway
<danilos> lifeless, it doesn't, unfortunately, common format only lists request *end* time afaict
<danilos> lifeless, ok, I'll bring it up with LOSAs since this may affect our log processing scripts as well
<danilos> and actually it's the time request was received, some stale reference for my previous claim :)
<mpt> StevenK, fwiw, I can't see what's in the "Unsubscribe" overlay on that screenshot, but it looks reasonably probable that fixing bug 795180 would make it unnecessary.
<StevenK> mpt: I'm fixing a seperate bug -- if a user is unsubscribing themselves from a private bug, they should be warned.
<mpt> StevenK, oh, then I'll have to agree with wgrant then. :-) That warning could be indented under the one of those three commands that deprives you of access.
<StevenK> mpt: I've already been convinced. I just need more JS knowledge.
<mpt> k
<wgrant> Ah, good, so I invoked mpt correctly, and shall not incur too much of his wrath.
<jtv> stub: I wonder if garbo should report how many iterations and âitemsâ a job got through before being killed.  Nice to know if we're making progress, and whether a job is still needed.
<stub> jtv: Sounds useful. Would need to be in DBLoopTuner but that is fine.
<jtv> Yeah.
<wgrant> stub: Can we abolish database/schema/pending?
<matsubara> danilos, hey there, the script that loads oops into the oops-tools database caught up during the weekend and those SMS oopses should now be available for viewing
<stub> wgrant: Replacing it with what?
<wgrant> stub: Well, it seems to have been used roughly twice in the last two years.
<stub> wgrant: I guess it can go - nothing in there at the moment that is useful
<wgrant> It should at least be emptied out.
<wgrant> Nothing in there is useful now, and I don't really think there's much of a case to put stuff in there.
<stub> wgrant: yer. Will need to find somewhere for templates etc. for data migration type scripts. That is going to happen more and more with fastdowntime.
<wgrant> That's true.
<lifeless> jamesh: https://code.launchpad.net/~lifeless/storm/wsgi closes the loop
<wgrant> Nothing in there deserves to stay, but I'm not sure if the directory itself should...
<danilos> matsubara, cool, thanks
<matsubara> danilos, you're welcome
<wgrant> rvba: I think those two branches look fine.
<wgrant> rvba: It's hard to say for sure, but the test changes look pretty sane.
<rvba> wgrant: Okay.  Thanks for looking at it again.
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated
<wgrant> stub: Do you recall why our store names include the config section name? We never change it outside tests...
<wgrant> I guess it may have been a WHUI attempt to permit usage of multiple concurrent configs.
 * wgrant deletes it to see what breaks.
<wgrant> Ah, of course. It's the only way to get the section name into LaunchpadDatabase.
<wgrant> Unless I just fix it to always use canonical.config.dbconfig...
<wgrant> Which it already does, because the other case is WHUI.
<jtv> hey benjiâI've got a gigantic lint branch up for review.  Not expecting anyone to read it in full, but since I don't see how it could be Q/A'ed, I'd prefer not to make it self-reviewed as well.
<benji> jtv: sure, I'll take a look
<jtv> thanks
<wgrant> cjwatson: There are some complexities to exporting changeOverride, sadly.
<wgrant> cjwatson: Permissions are one difficult bit.
<wgrant> Another is getting the same source+binaries behaviour.
<cjwatson> I looked at permissions and that part looked OK; launchpad.Edit permissions on SPPH/BPPH already look sane
<cjwatson> i.e. basically archive owner with a few warts
<stub> wgrant: I suspect the code you are looking at was assembled (I won't say 'designed') before canonical.config.dbconfig existed.
<adeuring> bigjools, wgrant: I want to create a set of BinaryPackageBuilds for all possible values of BuildStatus. When I then create a +builds view, the resultset of the view is sometimes empty: http://paste.ubuntu.com/693006/ I get empty results set for the statuses built, building, pending. Any suggestions?
<cjwatson> wgrant: and surely the source+binaries behaviour could be handled by the caller?
<cjwatson> I would've thought lib/lp/soyuz/scripts/changeoverride.py could basically be transmogrified into an API script
<wgrant> cjwatson: Probably, yes, assuming the relevant methods on SPPH are exposed.
<wgrant> SPPH.getPublishedBinaries or whatever it is.
<wgrant> cjwatson: The API's SPPH.requestDeletion does source+binary implicitly, but that makes less sense for overrides, as they may differ.
<cjwatson> requestDeletion's implicit behavior is annoying; it's too constrained to implement lp-remove-package.py over the API
<cjwatson> we need to do things like deleting individual NBS binaries, deleting only a source package when its binaries have been taken over by another package, ...
<wgrant> stub: Possibly. Since nothing seems to use LaunchpadDatabase or a DBPolicy with anything other than the current section, I'm hoping this ec2 run will succeed. Then I can move ZTM's remaining user handling crap into DBConfig, and it can finally die.
<wgrant> cjwatson: Indeed.
<wgrant> cjwatson: I forget if we expose BPPH.requestDeletion.
<cjwatson> and yes, only being able to overrides for everything in a source package at once would be so limiting as to be useless
<wgrant> cjwatson: But do you ever want to delete a source without deleting binaries from that source?
<cjwatson> *do overrides
<cjwatson> wgrant: only if those binaries have been taken over by some other source.  I'm never sure whether LP will notice that correctly on removal
<benji> did the +activereviews page change?  The organization looks different -- and less useful :(
<cjwatson> lp-remove-package normally does seem to, admittedly
<wgrant> cjwatson: We identify BPPHs for BPRs that were built from a build for the SPR that's being deleted.
<cjwatson> the other use case for deleting binaries is when they fail to build (even if they aren't actually NBS) and we don't want to ship unsupportable stuff
<wgrant> cjwatson: Names aren't used at all.
<cjwatson> OK, that would be safe
<wgrant> Yeah, deleting binaries I can understand, and is easily supportable.
<wgrant> Deleting sources without their binaries would require slightly more creative API construction.
<cjwatson> I can see why you might not want to expose API methods that produce orphaned BPRs
<wgrant> Exactly.
<benji> oh! it's because it doesn't know who I am, I need to log in
<jtv> benji: those are two independent statements, there should be no comma, between, them, how are you, I am fine?
<benji> jtv: this is true; my IRC copy editor is on vacation today so you'll have to deal with small imperfections
<deryck> Morning, all.
<jtv> benji: I see.  Now compare your case to deryck's, who seems to be verbless at the moment.
<jtv> Hi deryck.  :)
<deryck> hi
<benji> jtv: I guess he accidentally a word.
<deryck> Not sure I get the verbless comment. ;)
<jtv> deryck: I was being a pedantic prick with benji, and when he made up a semi-plausible excuse, I started using you as a bad example instead.  :)
<jtv> The âverblessâ refers to the absence of verbs in âmorning, all.â
<deryck> ah
<cjwatson> Ah, that invented Victorian grammar. :-)
<deryck> Arguments about language on the Internet always end well. ;)
<cjwatson> I'll just cite http://languagelog.ldc.upenn.edu/nll/?p=3338 and leave it at that :-)
<deryck> heh
<deryck> abentley, hi.  we're back to mumble this week.
<jml> cjwatson: I stopped reading Language Log ages ago when it went through a period of being a blog about how badly the BBC do science reporting. I'd forgotten how good it can be.
<jcsackett> sinzui: available to mumble?
<sinzui> yes.
<jcsackett> excellent.
<abentley> deryck: chat?
<deryck> abentley, sure.  let me grab coffee and then meet you in mumble.
<abentley> deryck: cool.
<lifeless> sinzui: morning.
<sinzui> hi lifeless
<lifeless> sinzui: did you see the rollback of subscription-changes-on-toggling-private-flag-in-bugs ?
<sinzui> I did.
<lifeless> sinzui: there is some confusion about whether a) wallyworld was confused or b) I was confused about the design
<sinzui> I told wallyworld that OEM has direct subscriptions removed so I thought he did the right thing
<lifeless> sinzui: I promised him I would touch base with you directly to clear things up
<lifeless> sinzui: do you mean they do the following with the old code: a) make private; b) remove the resulting direct subscriptions ?
<sinzui> We can cut that feature and land the structural subscription part only. OEM can report a bug if they believe the behaviour is still broken
<sinzui> lifeless, OEM removes anyone they do not know to be associated with their projects
<sinzui> It has nothing to do with direct/indirect. It is simply a matter of disclosing info
<lifeless> sure, but the indirect-become-direct behaviour is a part of the story
<lifeless> in that it requires an explicit act to become a subscriber without that
<lifeless> [for a non-project-person]
<lifeless> sinzui: anyhow, the result of ditching -all- direct subscribers is that we can't have symmetrical code as we designed : we would have to special case according to increasing or decreasing sensitivity
<sinzui> Sure, but disclosing private/secure information costs millions, and users who cannot see who is subscribed (api/email) are trusting Lp to do the right thing
<lifeless> agreed on the result of a mistake, but we're talking about the case of taking a bug that was open, private, which clearly means that the info in it was public at one point.
<lifeless> such super sensitive things should be created private to start with, so there is no chance of disclosure, and the transition code becomes irrelevant
<sinzui> But the subsequent private conversation was never public
<sinzui> This case might better be solved by bug linking
<lifeless> the transition code flow we discussed was designed for dealing with private-security becomes private-non-security, and vice verca.
<lifeless> yes, I think a private discussion about a bug reported by a person outside the project should be done with a lnked private bug
<lifeless> is there an option to say 'bugs on this project cannot be filed open' ?
<sinzui> As I wrote to wallyworld, we will only deal with structural subscriptions (remove the direct changes) so that the common case works as users expect (and Lp claims to do)
<lifeless> ok
<lifeless> I think I know what that means, and will look over someones shoulder when v2 of it goes up :)
<lifeless> to make sure I understand, so I have a clue and don't trigger a late rollback :)
<sinzui> lifeless,  was also cut the unsubscribe-security-contact-bug-supervisor rule when a bug because public/non-security because there was disagreement. I just want to land what we agree solves most of the problem
<lifeless> sinzui: oh, thats surprising.
<lifeless> sinzui: I agree on landing the uncontentious bits
<lifeless> sinzui: but am also curious what the disagreement was
<sinzui> wgrant believed the security contact may want to follow the conversation after the issue was made non-security, or even choose to re-secure it if it is decided the change was a mistake
<lifeless> btw, I have a sneaking suspicion we might be able to address some performance issues if we materialize subscriptions (like we do teamparticipation). IMBVW
<sinzui> wgrant, is planing for that :)
<lifeless> sinzui: (re-securing - a test that they receive the 'it is now public' notification would cover that (and be a solid expectation too))
<lifeless> sinzui: following-the-conversation : tough. :)
<lifeless> sinzui: they can subscribe when they get the notification that says 'xyz is now public and you are no longer subscribed'
<bigjools> lifeless: 1. wth are you still doing awake, and 2. any objections to me throwing the management rabbit  plugins in the LP PPA?
<sinzui> lifeless,  yes, ensuring notification may be the correct way to handle this.
<lifeless> bigjools: 1. Cynthia. 2. No objections.
<bigjools> copy!
<lifeless> bigjools: btw, I think one of the bugs confused you
<bigjools> quite possibly
<bigjools> write better descriptions then :)
<lifeless> bigjools: the ..139 bug is about snarfing issues from *rabbit*, not longpoll
<lifeless> the ...136 bug is about issues from longpoll.
<bigjools> I realised that much
<lifeless> so how is 136 a pre-req for 139 ?
<bigjools> did I get them the wrong way around?
<lifeless> they are unrelated
<bigjools> hmm
<lifeless> two separate services, both need tell-us-what-went-wrong integration of some sort, to avoid a human going and looking at log files.
<bigjools> yer right, I'm confused. My bad.
<lifeless> no worries :)
<bigjools> the management interface is quite neat BTW
<lifeless> cool
<bigjools> I am poking messages through and the web page updates almost instantaneously :)
<lifeless> james_w: https://launchpad.net/testr_recipe is a 404
<lifeless> james_w: the url is on your pypi page
<bigjools> looks interesting that
<james_w> well where did that go then?
<james_w> I wonder if I ever actually registered it
<james_w> ah https://launchpad.net/testr-recipe
<stub> lifeless: https://code.launchpad.net/~wallyworld/launchpad/branch-privacy-trigger/+merge/75189 might interest, as it is a DB patch that should land with code changes (the tests for the trigger behaviour)
<gmb> jtv: Could you take a look at https://answers.launchpad.net/launchpad/+question/171451 for me? I don't know the answer.
<gmb> this one, also: https://answers.launchpad.net/launchpad/+question/171450
<bigjools> where do I set the default reviewer for a project?
<bigjools> well, trunk branch
<bigjools> nm found it eventually
<sinzui> jcsackett, do you have a moment to discuss http://pastebin.ubuntu.com/693202/ on mumble?
<jcsackett> sure.
<timrc> off hand is there an easy way to get get a bug object via a .getBugByURL()-like API call :)?
<sinzui> timrc, the lp object has a top-level bug collection. You only need the id from the URL
<sinzui> lp.bugs[284141] will get bug #284141 regardless without need of knowing the projects it affects
<_mup_> Bug #284141: PPA upload permissions should be decoupled from its team membership. <lp-soyuz> <ppa> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/284141 >
<timrc> sinzui, okay that can work
<timrc> sinzui, thanks
<nigelb> jtv: Hey, do you know why your MP (the one linked on your blog post) turns up with an empty diff?
<nigelb> s/your/Launchpad
<nigelb> That's probably going to be confusing for everyone who clicks through :)
<nigelb> sinzui: Heh, after much fun with regressions, I finally fixed the bug title feature :-)
<nigelb> s/fun/fail/g works as well.
<sinzui> nigelb, I saw. Thank you for following up
<nigelb> sinzui: Embarassing mistakes. But learned YUI testing well now :-)
<sinzui> nigelb, You have nothing to be embarrassed about. Now wrongly closing 10,00 bugs in production does cause some embarrassment.
<nigelb> ...wow
<flacoste> nigelb: yes, now 4 years since that event, but sinzui is still talking about it :-)
<sinzui> I was traumatised
<sinzui> When I am described as "legendary", I think "what? Who knows me?", then I remember the 10,000 bugs.
<nigelb> haha
<nigelb> sinzui: I was traumatised with nightmares of wgrant stabbing me for making a bunch of revs undeployable :P
<sinzui> nigelb, :)
<nigelb> sinzui: I think someone new has more "fame" now with the accidental auto-sync that happened this cycle :P
<sinzui> :)
<lifeless> flacoste: hi; will be with you soon
<flacoste> lifeless: no worries, working on the QBR stuff
<lifeless> james_w: ah, should be simple to fix the pypi ref then :)
<james_w> lifeless, already done
<lifeless> james_w: I wanted to look at the code to see if you setup a run --parallel config
<lifeless> james_w: but IIUC you use the .testr.conf in the tree, so thats still manual ?
<james_w> it also has code to generate .testr.conf
<lifeless> cool!
<lifeless> does it setup a parallel conf or the older run-without-knowing style?
<james_w> it's old
<lifeless> if you have a look at testtools .testr.conf, or even testrepositories itself, you can see the changes quite easily.
<lifeless> should I file a bug ?
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 260 - 0:[########*** stack smashing detected ***: ./lp terminated
<james_w> lifeless, go ahead
<jelmer> 'morning lifeless
<nigelb> morning... wait a minute.
<nigelb> jelmer: aren't you somewhere in Europe? :)
<jelmer> lifeless: you approved one of my bzr-search branches and spoke the ever legendary word "doit", but you own lp:bzr-search; is there any chance you can merge it for me or change ownership to ~bzr/~bzr-search?
<lifeless> jelmer: no I don't :)
<jelmer> lifeless: :-) thanks
<jelmer> nigelb: Yeah :-) I think it's evening for both of us, right?
<nigelb> I've passed the point where I can call it evening ;)
<nigelb> I still haven't slept so I'll claim evening :P
<poolie> sleep well, nigel
<poolie> and sleep enough
<nigelb> :)
<nigelb> Thanks poolie!
* lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 260 - 0:[########*** stack smashing detected ***: kees pinged
<lifeless> wgrant: reviews plox
* wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 256 - 0:[########*** stack smashing detected ***: kees pinged
<lifeless> wgrant: https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
<wgrant> lifeless: Sorry, on a call right now.
<lifeless> kk
#launchpad-dev 2011-09-20
<wgrant> lifeless: Hmm.
<wgrant> lifeless: Why 'timeline.timeline' instead of 'timeline'?
<wgrant> I have to say that I really question the utility of a 155 line diff to deduplicate a single line of code.
<wgrant> The python-oops-wsgi diff could be argued to be sensible. But I don't think python-timeline's is.
<lifeless> wgrant: PEP 3333
<lifeless> wgrant: environ variables are namespaced
<wgrant> But even python-oops-wsgi's diff is probably better handled by passing a dict of stuff to preserve from the environment.
<lifeless> so, which package do you think should define the location of the timeline in a wsgi stack ?
<lifeless> An implied aspect is that we should export a symbolic variable with the value 'timeline.timeline'
<wgrant> Does it need to be fixed?
<wgrant> What's going to use it?
<lifeless> wgrant: storm and other things that want to log events in a wsgi world
<lifeless> wgrant: e.g. https://code.launchpad.net/~lifeless/storm/wsgi/+merge/76009
<wgrant> Erm
<wgrant> We have DNS breakage.
<wgrant> LibrarianServerError: <urlopen error [Errno -2] Name or service not known><br />
<lifeless> wgrant: note that this knows nothing about oopses
<wgrant> Just got an OOPS for that page.
<lifeless> -win-
<lifeless> (sarcasm)
<wgrant> And I forget to grab the OOPS ID.
 * wgrant greps.
<lifeless> was that a librarian fail or a find-librarian fail ?
<wgrant> I think find-librarian,.
<wgrant> Two OOPS so far today with that error, both from soybean.
<lifeless> I've asked in is
<lifeless> there was a dns reload
<wgrant> Ah
<lifeless> anyhow
<lifeless> back to our regularly scheduled program
<lifeless> its about loose coupling
<lifeless> connecting storm to timeline in a wsgi environment is one step
<lifeless> connecting timeline to oopses in a wsgi environment is another
<wgrant> Just got another one.
<lifeless> thus a change to storm, to timeline, and to oops-wsgi
<wgrant> AQ4
<wgrant> Are they still reloading DNS?
<lifeless> james_w: I'm trying to use testr_recipe, but it says 'installing test.. cannot find distribution for test' (where test is the part in the buildout.cfg
<lifeless> wgrant: ok, now where were we.
<wgrant> lifeless: Having storm.wsgi.make_app be time-line specific seems odd.
<wgrant> I'm all for factoring out common code sensibly, but I really don't think the python-oops-wsgi and python-timeline changes are examples of that. They save three lines of code, all of which are trivial and two of which could be reduced to one with a more generic python-oops-wsgi solution.
<lifeless> wgrant: you'll need to spell out what you mean, because I don't see it
<wgrant> lifeless: Which bit?
<lifeless> more generic python-oops-wsgi solution.
<wgrant> The oops_wsgi change would probably be better as a general facility to specify values from the environ to put in the context.
<lifeless> I can do that
<wgrant> eg. pass in a {'timeline.timeline': 'timeline'} dict or so.
<lifeless> I don't see it eliminating the needed for the other changes
<lifeless> I'd also like to have it do that particular one by default, as a sane-default
<wgrant> So, to tie the bits together I need to import a module and have a special-case in oops_wsgi, or I can specify a tiny dict and construct a timeline myself.
<wgrant> Which takes roughly 1.5 lines.
<lifeless> I am rather allergic to copy and paste of undifferentiated code
<lifeless> when there is really local policy, its fine. This isn't one of those times
<wgrant> This code is actually going to be shorter.
<wgrant> The other one just happens to be entirely symbols.
<lifeless> per PEP3333
<lifeless> the timeline module is what gets to use timeline.*
<lifeless> if we call it oops.timeline or oops.context['timeline'] then oops-wsgi could set it
<lifeless> if we call it storm.timeline, storm could set it
<lifeless> anything else is asking for trouble, and all those other names are (hopefully obviously) undesirable
<wgrant> I don't think any of those need to set it.
<wgrant> The only glue code that is useful here is the stuff in storm.wsgi.
<lifeless> which would be totally the wrong place to create the timeline object
<lifeless> as its used for more than just storm lookups
<wgrant> Sure, I don't think you should create it there.
<wgrant> I think the app should do it.
<wgrant> Pass the name into Storm.
<wgrant> And ask oops-wsgi to map it into the report.
<lifeless> that would force configuration onto everything that wants to talk to a timeline
<lifeless> I think thats undesirable
<wgrant> That's possibly true.
<lifeless> I'm happy to make oops-wsgi more configurable
<lifeless> but it would be a mistake to do that and then say 'now everyone has to use that'
<wgrant> But we also have a 155 line diff to add one line (41 characters) of very trivial.
<wgrant> very trivial code.
<lifeless> shrug
<wgrant> I think *that* is probably undesirable.
<lifeless> the major cost - writing and testing it - is sunk
<wgrant> This smells, and I don't have enough WSGI experience to say if it is sane. I'm afraid I can't sensibly approve this myself.
<wgrant> This is an interface that other projects are going to use, so I am going to be more cautious than I would be for an internal LP interface.
<lifeless> sure
<lifeless> this is what jamesh and I agreed on
<lifeless> I don't agree that it smells
<lifeless> separate but related
<lifeless> oops-tools has code to infer request duration
<lifeless> by examining the last item in a timeline
<lifeless> I think it might be sane for Timeline() to have a 0 duration initial action
<lifeless> to seed things
<lifeless> but Timeline can't tell when its finished with, so it needs to be told [exact details for doing this could vary]
<lifeless> man, really want yield from
<wgrant> That didn't make it into 3.2, did it?
<lifeless> I don't think so
<wgrant> :(
<lifeless> it would make some of these wsgi wrappers better and faster
<wgrant> Indeed, accepted for 3.3.
<lifeless> such as the next change to the timeline one which I'm about to self review
<lifeless> wgrant: other than the structural thing which you've abstained on
<lifeless> wgrant: were there code quality comments; I have one noted from the discussion - why doesn't oops-wsgi let the map be done arbitrarily
<lifeless> wgrant: which I will execute on as I'm in the area
<wgrant> lifeless: It all looks fine, apart from the workaround for lack of 'yield from', which I believe is pretty standard anyway.
<lifeless> yah
<lifeless> thanks
<lifeless> do you want to see the generalisation before I land (I plan to supply a default mapping dict which folk can use as a template, and a mapping param which None means 'use the default dict'
<wgrant> That sounds fine. I'm about to wander out for a few hours, so won't be around much.
<wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/no-config-names-in-store-names/+merge/76135? Simple code changes, potentially non-simple consequences, but the test suite is fine with it.
<lifeless> what about the impact on session query filtering ?
<wgrant> The store name there is just 'session'
<wgrant> Always has been.
<wgrant> I don't think it even uses LaunchpadDatabase.
<wgrant> Yeah, see PGSessionBase in canonical.launchpad.webapp.pgsession
<lifeless> ok
<wgrant> Thanks.
<jtv> nigelb: noticed that tooâ¦ no idea; frankly I don't know why other MPs don't get empty diffs once they're merged.
<jtv> wgrant: looks like gina's done with sid.
<jtv> Syncing logs to see what happened to squeeze.
<jtv> Oh come on oneiric, please don't do thisâ¦ I need to shut down _somehow_ so I can carry this laptop to the office.
<wgrant> sudo pm-suspend ftw
<lifeless> jtv: sudo pkill e*
<lifeless> ?
<jtv> lifeless: why e*?
<lifeless> erlang, can't remember the process name
<lifeless> has been known to cause 'issues'
<wgrant> beam.smp? :)
<lifeless> yeah :P
<lifeless> there are two though
<lifeless> beam and a broken
<wgrant> epmd?
<lifeless> broker
<lifeless> yes
<wgrant> Yay, I remember erlang crap properly.
<jtv> In my case: can't move mouse pointer, and can't log into text console because it keeps typing /////////////
<jtv> (Actually my GUI session has been doing that as well, but _there_ at least it stopped)
<jtv> And since suspend/hibernate don't work, I need to shut down.  But since the shutdown option doesn't work, what I normally do is log out and then switch to a text console to shut down.
<jtv> I think I'll take a bug-filing day this week.
<jtv> Well, the pkill didn't work.  :(
<jtv> Why is epmd running as rabbitmq even after I stopped rabbitmq?
<jtv> And why was it still there after the pkill?
<jtv> I killed it by pid, but no change.  :(
<lifeless> anything in dmesg?
<jtv> A lot of screensaver segfaults
<jtv> Complaints about the CD that's in my drive, I think.
<jtv> forcedeth, which sounds like a cover band.
<jtv> Complaints about unknown SCO packets on hci0.
<jtv> Sorry no, about SCO packages for an unknown connection handle.
<jtv> âapm: BIOS not foundâ is probably not as exciting as it sounds.
<StevenK> You're on a MacBook which uses EFI
<jtv> Not as exciting as it sounds.
<jtv> I'll try the pm-suspend then I guess.
<lifeless> win 19978  OOPS-2088HWDB303  None
<StevenK> wallyworld_: *prod*
<wallyworld_> StevenK: hello
<StevenK> wallyworld_: var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
<StevenK> That still results in co being null
<wallyworld_> no work?
<wallyworld_> maybe try removing one of the css class selectors
<wallyworld_> just to see what happens
<StevenK> Can I see all CSS classes at that point int time?
<wallyworld_> yes, node.getClass()
<wallyworld_> but i thought you looked using firebug
<wallyworld_> to see what the classes were
<StevenK> I meant in the test itself
<wallyworld_> oh, ok, yes that will give you the classes
<wallyworld_> once you have the node
<wallyworld_> wgrant: wrt the conversation about only removing subscribers for bugs associated with projects with private_bugs=true - it is acceptable to simply look at the default_bugtask to get the project (if any) whose 'private_bugs' may be true/false?
<StevenK> wallyworld_: Yes, but I'm having trouble getting the node!
<wallyworld_> StevenK: yes. so you probably are best to loosen the selection constraint on css class
<wallyworld_> to try and get a node that matches
<wallyworld_> you can also use Y.all() and iterate over the node list
<wallyworld_> so if you make the constraint .yui3-overlay you can see what overlays there are
<StevenK> Y.all('.yui3-overlay'); ?
<wallyworld_> yes, i think so
<wallyworld_> so long as yui3-overlay is correct in terms of a css class that they have
<mwhudson> I couldn't get Y.one('.class-one.class-two') to work the other day
<mwhudson> could it be some kind of bug?
<wallyworld_> mwhudson: perhaps. i think we are running a rc version of yui 3.4. maybe time to look at upgrading
<StevenK> That was silly
<StevenK> alert(i) gives me an alert box for each attribute of the node
<mwhudson> doh
<wallyworld_> StevenK: no i lie. we are running 3.3
<wallyworld_> but 3.4 is now out i think
<wallyworld_> StevenK: Y.log is your friend
<StevenK> AH
 * mwhudson asks in #yui, though i expect everyone is asleep
<StevenK> Y.all('.yiu3-overlay') has a _nodes property that is [ ]
<wallyworld_> StevenK: that implies there are no matching nodes
<wallyworld_> since Y.all returns a NodeList afaik
<mwhudson> StevenK: don't look behind the curtain
<StevenK> Clearly
<mwhudson> StevenK: .size() == 0 is a better check :)
<mwhudson> (and as for gratuitous differences between Array and NodeList...)
<StevenK> Ah ha
<StevenK> That function never gets called with "unsubscribe"
<StevenK> wallyworld_: Does Y.log() hit stdout/stderr when running under bin/test?
<StevenK> mwhudson: My JS knowledge is ... heavily fragmented and mostly missing.
<wallyworld_> StevenK: not sure but doubt it. it goes to the console in the browser when you run the test via loading the html page
<wallyworld_> i find that the best way to debug
<mwhudson> StevenK: mine is heavily fractured but i'm gradually filling in the gaps :)
<wallyworld_> since i can also use break points, watches etc etc
<StevenK> wallyworld_: Running it via the browser it keeps complaining that "Y.lp.app.confirmationoverlay" is undefined.
<wallyworld_> StevenK: that explains a lot
<wallyworld_> StevenK: you need to include the module in the html harness
<StevenK> Oh, at the bottom of the test js?
<wallyworld_> sort of near where the other imports are done nearish the top i thin
<wallyworld_> thinkl
<StevenK> Oh, in the HTML itself
<wallyworld_> yes
<wallyworld_> see the <!-- Come required dependencies -->
<wallyworld_> comment
<wallyworld_> Some, not Come
<wallyworld_> can't type
<StevenK> Which doesn't appear in that HTML
<wallyworld_> StevenK: bin/test tends to hide a lot of errors and just reports failure for whatever reason
<wallyworld_> see test_personpicker.html for an example
<wallyworld_> bin/test is good for once stuff is debugged and working
<wallyworld_> but to see setup errors etc, use the browser and firebug
<StevenK> Expected: null (object)
<StevenK> Actual: DIV#yui_3_3_0_2_13164951130961890 yui_3_3_0_2_13164951130961894 (object)
<StevenK> SUCCESS
<wallyworld_> StevenK: excellent!
<wallyworld_> StevenK: now you can try the "proper" css class selector
<StevenK> That is with the proper CSS class selector
<wallyworld_> even better
<StevenK> var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
<wallyworld_> at least now you know you test fails and you can write the code to fix it
<StevenK> Does that strike you as 'proper' ?
<wallyworld_> well, so long as it is specific enough to select the confirmation overlay you are trying to get at
<wallyworld_> and not find any others
<StevenK> wallyworld_: I'm now un-breaking the JS itself to only show the overlay on private bugs
<wallyworld_> sounds good
<StevenK> And then if the test passes, I can start writing my own
<wallyworld_> yep
 * wallyworld_ has to go and pick up car from getting new tyres fitted
<StevenK> >1 day for 3 lines of JS and 2 lines of HTML
<StevenK>  /wrists
<wallyworld_> StevenK: at least you know how to do it quicker now :-)
<wallyworld_> all the things to look out for
<wallyworld_> StevenK: what doesn't kill you makes you stronger :-)
<nigelb> Except those that make you want to die.
<nigelb> ;)
<nigelb> Why does the MP have "Empty diff" ocassionally?
<nigelb> I saw it for one of MPs and the other day with one of jtv's MPs.
<StevenK> Can I grab hold of a button in JS by using Y.one() ?
<huwshimi> StevenK: Does the button have an ID?
<StevenK> It does not
<StevenK> <button class="lazr-pos lazr-btn ok-btn" type="submit">OK</button>
<StevenK> It has a surrounding div (<div class="yui3-lazr-formoverlay-actions">), which I guess I can grab with var div = Y.one('.yui3-lazr-formoverlay-actions');
<wallyworld_> StevenK: you can grab a button using attribute matching also eg "button.ok-btn[type='submit']" or something like that
<adeuring> good morning
<nigelb> Good Morning adeuring & mrevell
<mrevell> yo
<wgrant> stub: Hmm, so it turns out that all but two of the storm_cache and storm_cache_size directives in the configs are unused.
<stub> wgrant: Just the appserver overriding?
<stub> wgrant: We currently have a huge value for the appserver because it hasn't been instrumented and are scared of reducing the size.
<stub> wgrant: And are scared of using high values in scripts to stop memory ballooning.
<wgrant> stub: Well, that's what I thought, but it's a little bit simpler than that.
<stub> Its busted and only works in rare cases?
<wgrant> The 'launchpad' section is used for everything, except for the librarian (which uses 'librarian').
<stub> \o/
<wgrant> launchpad is 10000 on production, 100 on dev.
<wgrant> Someone somewhere along the line stopped calling setConfigSection in production code, except for the 'launchpad' default in lib/canonical/config/__init__.py, and one other case in librarian.tac.
<wgrant> librarian seems to really only care about overriding the dbuser and isolation_level.
<wgrant> Which, conveniently, is what everybody else cares about overriding too.
<stub> Do we currently have any script memory hogs?
<wgrant> Apart from nasty gina and process-death-row worstcases recently, not really.
<wgrant> That I know of.
<stub> dbuser and isolation_level should really be hardcoded anyway, isolation because things break if you change the config and dbuser because we never make use of the fact we can change the config.
<wgrant> Yeah, apart from in tests.
<wgrant> ... and formerly in buildd-manager, but that was fixed a year ago.
<wgrant> So, I'm probably removing config section support, merging launchpad's settings into the main database section, changing librarian.tac to override directly. And due to the fix I landed this morning, that means that dbconfig.override() is pretty much a direct replacement for initZopeless, and ZTM can finally BURN.;
<wgrant> And this stuff that has been a shim for 4 years can finally die :/
<wgrant> Uhoh.
<wgrant> canonical.lp won't die.
<wgrant> It somehow got revived today.
 * wgrant blames jtv.
<jtv> whuwhuwhu?
<wgrant> message: [r=benji][no-qa] Fix lots of lint in recently-changed files.
<wgrant> added: lib/canonical/lp/
<wgrant> :(
 * wgrant remurders.
<jtv> Please do.
<wgrant> Bah.
<wgrant> Looks like I need to keep respecting config.launchpad.dbuser, as it's what all the appserver configs use.
<poolie> jtv, i think you mean "symptom, search internet, selfdiagnosis, treatment, conspiracy theories"
<jtv> poolie: I am _not_ taking you to any more coffee shops.
<poolie> haha :)
<bigjools> lifeless: how's the python-oops-twisted thingamujig?
<lifeless> bigjools: good news and bad news
<lifeless> bigjools: the good news is I figured out what all the tech debt meant
<lifeless> bigjools: the bad news is that the new project isn't done yet, because of the good news
<lifeless> bigjools: pretty close though, just tests to write now
<bigjools> lifeless: well, thanks, you've saved me a bunch of work so it's all good AFAIAC: )
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 256 - 0:[########*** stack smashing detected ***: kees pinged
<poolie> jelmer, hey that's a really interesting point about the code ui
<jelmer> poolie: thanks; I think it's one of those things that are hard to notice once you've gotten used to the existing UI.
<poolie> yeah
<poolie> i was actually talking to huw about this the other day
<poolie> because we did a little on it at the o'rally and it's been idle since then
<poolie> i would love to see it reactivate
<jelmer> Once the last code-import<->mirror integration branch lands, I'd really like to kill the "Register a branch" button.
<poolie> i think it's one of those topics that can hurt user experience a lot, but that won't clearly come up in bug reports or user requests
<poolie> s//hurt or help
<jelmer> yeah
* StevenK changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 256 - 0:[#########]:256
<lifeless> bigjools: turns out our current twisted integration can silently block the librarian etc
<lifeless> bigjools: we're calling blocking apis without deferToThread
<bigjools> lifeless: awesome
<lifeless> I will be fixing one of the two cases
<bigjools> what scenarios?
<lifeless> oops creation writes files to disk
<lifeless> and can trigger a re-read of the directory
<lifeless> but the key bit is we thunk logObserver to python logging
<lifeless> and thats documented in the twisted docs as 'can block'
<lifeless> we should be doing deferToThread
<lifeless> and then doing the may-block stuff in a thread
<lifeless> this just became blindingly obvious when I started asking 'how to extract this nicely'
<lifeless> for bonus points we have two distinct twisted integrations atm
<stub> I normally don't mind the spider, but it should get off my damn screen!
<lifeless> roughly equally used.
<lifeless> I'm not going to try and fix that, but I'm going to bless one - the one I extract :)
<bigjools> lifeless: well at least you spotted it
<jml> lifeless: which is the blocking API being called?
<stub> We need to append pending log messages to a list, and deferToThread something that logs them in the correct order.
<jml> Logging a message doesn't normally need to be treated as a blocking operation.
<lifeless> jml: PythonLoggingObserver
<lifeless> jml: it does, and this is documented in the twisted docs as well as the logging docs.
<jml> lifeless: where?
<lifeless> jml: on the web page :) - sorry, past EOD and got stuff to do
<jml> that's lame
<jml> but I understand.
<lifeless> the twisted.log api docs specifically
<lifeless> wherever they are
<stub> Oddities I foresee are log messages being spit out in the wrong order, timestamps being slightly off, and bound variables and stacks being mutated as the callsite proceeds and before the log message is generated.
<jml> lifeless: thanks
<lifeless> stub: failures already materialise the backtrace IIRC
<jml> they do.
<lifeless> stub: the rest are already happening because we're in a reactor environment
<stub> cool. timestamps will be within precision.
<stub> just thinking of why it is blocking in the first place :-)
<lifeless> its blocking because the python 'logging' module has a great big lock in the middle
<lifeless> (and because file IO and directory listing can block too)
<jtv> bigjools: do we have any way to watch the debian domination on production?
<bigjools> jtv: the log file?
<jtv> I mean the effects of.
<jtv> Seeing whether the resulting status of Debian makes sense.
<bigjools> jtv: yeah, find a package that's dead in Debian but not in LP's import
<bigjools> also see the count of packages in +missingpackages
<jtv> Oh, we derive Ubuntu from Debian in production now?
<bigjools> have done for a while!
<bigjools> see oneiroc
<bigjools> oneiric, even
<bigjools> that's how this bug was noticed IIRC
<jtv> Ooh nice little beta bar
<jtv> Mind you, this is transitional domination so it shouldn't mark dead packages as deleted yet; it'll keep the last release alive for permanent domination to deal with.
<jtv> Also, gina's still dealing with squeeze.  :/
<bigjools> did it do sid yet?
<jtv> No, don't think so.
<bigjools> if not, take a note of the number of packages now
<bigjools> compare after
<jtv> Good one.  We also did that on dogfood.
<jtv> Packages and statuses, I think.
 * jtv cooks up some SQL
<bigjools> jtv: you can just look at the package counts in the UI
<jtv> The ones that need linking?
<bigjools> [11:07:42] <bigjools> also see the count of packages in +missingpackages
<jtv> That includes the DSD machinery as wellâ¦ since I'm not expecting any package deletions, I'll want to watch the DB as well.
<jtv> gmb: clearly, you're not bitter but just a tad disappointed in my review style?
<gmb> jtv: No, I've just formed an emotional attachment to the branch because I've been working on it for a week and a half.
<gmb> ]
<gmb> It's been a royal pain in my backside.
<gmb> jtv: One of your in depth reviews is always appreciated, unless the reviewee is feeling particularly lazy.
<jtv> Says the self-proclaimed Lazy Reviewer.  :)
<jtv> We ought to form a duo Ã  la Laurel & Hardy.
<gmb> :)
<jtv> Hippie & Nazi, Reviewersâ¢
<gmb> Yeah, I can see that going down a storm :)
<bigjools> lifeless: I need to do a txlongpoll test fixture - any opinion on whether that should be a separate project?
<jtv> gmb: compared to what I got away with last week, it ain't so bad.
<lifeless> bigjools: I'm torn
<lifeless> bigjools: on the one hand it should clearly be reusable, so not part of LP
<bigjools> lifeless: we could not decide either :) It'll add more dependencies of course
<lifeless> on the other hand if its part of txlongpoll it ties the client language to the server implementation, and implies that a client that can use the fixture could get at the server innards - thats undesirable
<lifeless> on the gripping hand adding a new project has some cognitive overhead
<lifeless> I think we should try separate-project: we can always massively consolidate later
<bigjools> I was erring that way
<jtv> gmb: your change to initialize() puzzles me.  Why assign a variable you're not going to use?  Are you trying to force evaluation of a property?
<gmb> jtv: Yes; activity_and_comments is a cachedproperty. If it's not loaded at initalize() time you end up with recursion problems in tests (not in actual usage though). I can drop the variable assignment; it just looked odd to me without it.
<gmb> jtv: I'm going to go and grab some lunch; feel free to stick any questions in the MP and I'll reply on my return.
<jtv> Aye-aye.
<danilos> flacoste, lifeless: we can't triage bugs for launchpad-results (like https://bugs.launchpad.net/launchpad-results/+bug/854635), meaning that it's not really our duty, yet it's part of launchpad-project and we can't drive untriaged bugs count to zero: what shall we do about it?
<_mup_> Bug #854635: unit model names have leading/trailing spaces <Launchpad Results:New> < https://launchpad.net/bugs/854635 >
<danilos> bigjools, the following bug seems to be simple to fix (missing DB user), yet pretty critical: bug 854449. Do you think we should treat it as an incident and start working on it asap?
<_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
<bigjools> danilos: yes
<bigjools> danilos: I suspect fallout from recent db user renamings
<bigjools> danilos: also it needs a script monitor
<danilos> bigjools, right, thanks, I'd appreciate it if you (as someone with more authority on the subject) adds a note to the bug itself, and I'll ensure we get started on it soon
<danilos> soon == today
<bigjools> ok :)
<wgrant> danilos: It is a pretty trivial puppet task.
<wgrant> An RT and a LOSA-poke may be in order.
<danilos> wgrant, I can guess it is for someone who knows all about the script
<wgrant> Hm? It's not got much to do with the script :)
<danilos> wgrant, (eg. what DB user it should use)
<wgrant> if __name__ == '__main__':
<wgrant>     script = GenerateContentsFiles(
<wgrant>         "generate-contents", dbuser='generate_contents_files')
<wgrant> Problem solved :)
<danilos> wgrant, I'd appreciate if you add that to the bug as well, since I am doing my CHR rotation right now
<wgrant> Done.
<danilos> thanks
<wgrant> bigjools: You might recall that I removed txlongpoll a while back.
<wgrant> bigjools: lifeless forbids its inclusion in our setup.py.
<bigjools> FFS
<wgrant> For it is to be a microservice.
<bigjools> we need it for make run
<bigjools> that is all
<bigjools> I don;t know how else to set it up
<stub> Is there an RT for Bug #854449  yet?
<_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
<wgrant> bigjools: Neither do I.
<lifeless> danilos: -results is in a bit of limbo; we should either have it meet our governance rules or remove it from being part of 'launchpad-project'.
<lifeless> danilos: chat to flacoste when he's up, and/or cr3 about which route
<lifeless> danilos: cr3 wants to have it properly integrated as a microservice etc
<lifeless> danilos: so, I think the right thing is getting it under our regular rules for bug supervisor etc
<danilos> lifeless, right, thanks for updating me on it
<lifeless> wgrant: bigjools: you use a buildout recipe
<lifeless> wgrant: that gets it executable with a bin/txlongpoll entry point, but not importable
<wgrant> This is going to get very ugly.
<wgrant> But maybe.
<lifeless> wgrant: bigjools: my use-gpgfixtures branch on lp has/had an example of doing that for the new keyserver.
<lifeless> which flacoste gave me.
<wgrant> We'll need a separate buildout target for each dep.
<bigjools> lifeless: there is no bin/txlongpoll entry point
<bigjools> it's a TAP
<lifeless> so, you need the egg unpacked (buildout can do that), and you need a script (the fixture) that knows how to run the tap
<lifeless> no ?
<lifeless> just txlongpoll itself doesn't end up on our PYTHONPATH
<bigjools> can you explain your aversion to setup.py changes?
<wgrant> Ah, that's right. You'll need to use buildout to create a second twistd.
<wgrant> That has the egg.
<lifeless> I love setup.py changes
<bigjools> in this context :)
<lifeless> https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Background_reasoning
<bigjools> I'm not sure that answers the question
<lifeless> thats the background reasoning
<bigjools> I'm not really au fait with buildout so this is a learning exercise
<lifeless> for why I want the microservices to not be importable
<bigjools> happy to be guided on this
<lifeless> wgrant: yes, buildout a z3c.recipe.script that has the additional egg, probably a defaults=... and tada
<gmb> jtv: I hadn't noticed the conflicts with devel; have pushed a fix.
<jtv> gmb: thanks.  I'mâ¦ collating notes.
<gmb> ok
<lifeless> bigjools: basically I want an ironclad avoidance of the sort of back-door dealing with API's we've had in LP with in-process stuff
<bigjools> ok
<lifeless> bigjools: so that folk can *confidently* work to the interface, not the implementation
<lifeless> this has several corollaries:
<bigjools> I'm still unsure what setup.py has to do with that
<lifeless>  - there will be some form of split-outs that we can't do, because we don't know how to write an interface that is fast+ etc etc etc
<bigjools> I perfectly understand the rationale, just not the "how" :)
<lifeless> oh
<lifeless> so when you add something to setup.py, buildout adds the resulting egg to the PYTHONPATH
<lifeless> it does this transitively.
<bigjools> and a simple buildout recipe does not?
<lifeless> if you have setup.py reference package A
<lifeless> and A references B
<lifeless> B will be in the PYTHONPATH setup by bin/py
<lifeless> bigjools: the 'scripts' recipe can specify its own additional things
<bigjools> how are we going to make a fixture figure out how it can run the TAP then?
<jtv> gmb: done.  Frankly it was the name of the branch that attracted my attention in the first place.
<lifeless> bigjools: thinking
<lifeless> bigjools: got it
<lifeless> bigjools: the fixture needs to know the command line to run the thing
<gmb> jtv: Heh, thanks.
<bigjools> yes, but it also needs to know where the twistd binary and plugin lives to do that
<lifeless> bigjools: this doesn't mean importing, it just needs to know that 'bin/twistd-longpoll' will run a twistd invocation that can import longpoll, and it needs the tap file
<lifeless> bigjools: yes, this will mean buildout.cfg stuff (sorry to be handwavy, nearly 1am etc)
<bigjools> ok, thoroughly confused here :)
<lifeless> wgrant: are you less confused?
<bigjools> maybe someone who knows buildout better can do this
<gmb> jtv: Once again, your review has me saying "Wait, what?" I never knew about zip() (or knew and have forgotten). I shall go and learn about it forthwith.
<jtv> gmb: good sport
<lifeless> def sudo_make_me_a_fixture(twistd='bin/twistd-longpoll', tap='bin/longpoll.tap'):
<lifeless>     return LongPollFixture(twistd=twistd, tap=tap)
<lifeless> ^ thats the thunk code to inject the custom twistd script and tap location
<lifeless> the other bit is teaching buildout to create the tap and twistd-longpoll
<wgrant> bigjools: See txlongpoll's buildout.cfg.
<wgrant> The 'interpreter' section there does sort of what we want.
<wgrant> Except we probably want to use a script target directly, without an interpreter, if possible.
<bigjools> lifeless: how would it know where bin lives in your example?
<lifeless> bigjools: in LP it will always be bin/twistd-longpoll
<bigjools> even if we have a script that encapsulates the invocation
<bigjools> ah, so you want it in LP's bin
<lifeless> thats what buildout is for
<lifeless> its responsible for making that file
<lifeless> this is what flacoste showed me: http://bazaar.launchpad.net/~lifeless/launchpad/usegpgfixtures/revision/13758
<bigjools> twistd is not entirely flexible in how it looks for TAPs is it ...
<lifeless> wgrant: ^
<wgrant> bigjools: Not at all. So we'll need a second twistd that has basically just txlongpoll in its path.
<bigjools> right, we have something in the txlongpoll buildout.cfg that builds itself
<wgrant> Ahh, z3c.recipe.scripts, handy.
<wgrant> Although that still generates an interpreter.
<lifeless> wgrant: it didn't
<lifeless> I don't know why the line is needed ;)
<bigjools> what does that code put in bin/ ?
<bigjools> s/code/config/
<lifeless> it creates bin/gpgfixtures
<lifeless> which has the buildout glue to set pythonpath etc
<bigjools> not in my dev area it doesn't :)
<lifeless> and ends up running gpgfixtures.keyserver.main(argv)
<lifeless> bigjools: what do you mean ?
<bigjools> there is no bin/gpgfixtures when I build latest trunk
<lifeless> of course
<lifeless> thats in a branch
<bigjools> unlanded?
<bigjools> ok
<lifeless> its demonstrating what you need to achieve, for a different but similar case
<bigjools> insomuch as I understand roughly what one of those lines is doing :)
<lifeless> right
<lifeless> this is why I pointed wgrant at it
<lifeless> he has more overlap with you
<lifeless> I'm dead :)
<bigjools> FSVO overlap :)_
<wgrant> Well, we actually both have zero overlap.
<wgrant> But yes.
<bigjools> yeah, you were up at crazy o'clock
<bigjools> thanks for the advice so far lifeless, rest well
<wgrant> Night lifeless.
<bigjools> wgrant: ok so we might be able to get away with the one in txlongpoll, the only issue is what to do with the TAP directory abomination
<wgrant> bigjools: What about it?
<wgrant> That's all in the egg.
<bigjools> wgrant: yes, but it needs to end up in $CWD
<wgrant> Nope.
<bigjools> otherwise twistd doesn't find it
<wgrant> It's in twisted/plugins/blah
<bigjools> is there a way of telling twistd where it is then?
<wgrant> Just try that buildout rul.e
<wgrant> Should work fine.l
<wgrant> I can type, see.
<bigjools> you miss my point I think
<wgrant> twistd looks in twisted.plugins
<wgrant> The plugin is in twisted.plugins in the egg.
<bigjools> where "twisted" is in $CWD
<wgrant> No.
<bigjools> ah
<wgrant> In pythonpath.
<bigjools> ah
 * bigjools experiments
<wgrant> The egg is all set up. It works fine.
<wgrant> If you add it to setup.py and rerun buildout, you'll see it listed when you run bin/twistd
<wgrant> So we just need to make a *second* twistd, that only has txlongpoll.
<bigjools> we do?
<wgrant> Since our normal twistd uses the deps from setup.py
<bigjools> ah right
<wgrant> It's for running LP stuff.
<bigjools> how do you rename the generated script name?
<bigjools> ah never mind
<deryck> Morning, everyone.
<jtv> hi deryck
<bigjools> morning deryck
<bigjools> wgrant: know what's up here? "Error: Picked: Twisted = 11.0.0"
<wgrant> bigjools: Possibly because you're using include_site_packages.
<bigjools> ok let's try false
<bigjools> nope
<bigjools> I have no idea what that error even means
<bigjools> I'd not know it was an error if it were not preceded with "Error" ...
<bigjools> ah think I found it
<bigjools> and no
<deryck> abentley, adeuring -- can we standup at 20 after?  I have another call at the bottom of the hour today.
<adeuring> deryck: sure
<abentley> deryck: sure
<deryck> great, thanks guys.
<flacoste> bigjools: i'm hopping on call with deryck
<flacoste> bigjools: but I could help you with that buildout after it, you could also grab gary_poster or benji to help out in the mean time
<gary_poster> bigjools: you need to set versions.cfg to specify Twisted = 11.0.0
<wgrant> jelmer: Did you intend to bump the bzr-git revision when you regenerated sourcedeps.cache?
<jelmer> wgrant: argh, sorry. That should have been in the original commit.
<wgrant> Ah, sure.
<danilos> flacoste, hi, do you have any suggestions on what we should do with launchpad-results (it's part of launchpad-project, but we don't have privileges to triage bugs)? lifeless believes we should make it match lp-project standards for bug supervision
<mrevell> Hey deryck or gary_poster, do you think you could spare someone to finish implementing Huw's 503 page? (https://code.launchpad.net/~huwshimi/launchpad/503-error-844631) Huw tells me he has taken it as far as he can.
 * gary_poster looking, mrevell
<gary_poster> mrevell, sure, I can put it in our (pretty short) backlog.  bonus points if you mark the bug escalated or critical :-P but not necessary
<mrevell> Thanks gary_poster! We consider Launchpad to be a stakeholder, so perhaps I could escalate it. It's producing an OOPs, which we want to continue logging, but I suppose that makes it critical. I'll mark it critical and ask lifeless' forgiveness if need be :)
<gary_poster> mrevell :-) ok cool
<wgrant> mrevell, gary_poster: It's fastdowntime-related and an OOPS, so it can be critical. Doesn't need escalation :)
<mrevell> superb
<gary_poster> wgrant, cool :-)
<bigjools> gary_poster: hello!
<bigjools> my buildout saviour
<gary_poster> hey bigjools
<gary_poster> heh
<bigjools> gary_poster: what I am doing is adding a script recipe to generate a "microservice"
<bigjools> versions.cfg already has Twisted = 11.0.0
<gary_poster> bigjools, script recipe from what
<gary_poster> this is in Launchpad
<gary_poster> 's setup.py I assume
<bigjools> not in setup, I am taking the txlongpoll egg and writing some buildout config to try and make it generate me a script
<bigjools> lifeless has banned changing setup.py for external scripts
<bigjools> which is fair enough
<gary_poster> bigjools, ok.  Oh, interesting.  (I don't think I'm breaking that in my current branch..._
<gary_poster> )
<gary_poster> bigjools, my memory is a bit fuzzy on all this, but I bet if I look at it I'll have an idea.  Do you have a branch for me?
<bigjools> I'll paste you my change, one sec
<bigjools> gary_poster: http://pastebin.ubuntu.com/693799/
<bigjools> gary_poster: argh
<bigjools> sorry hang on
<bigjools> gary_poster: http://pastebin.ubuntu.com/693800/
<bigjools> the first one is the whole file, that's just the diff
<gary_poster> bigjools, An error with "Picked" is definitely complaining about "You didn't tell me which version to use, so I had to guess, and you told me to complain, so I'm complaining".  So the question is, why isn't versions.cfg good enough
<gary_poster> ok
<bigjools> gary_poster: oh I wonder if it doesn't like the txlongpoll egg then
<bigjools> since that's the part that requires twisted
<gary_poster> um
<gary_poster> maybe.  I wouldn't have guessed so.
<gary_poster> lemme try applying this.  1 sec
<bigjools> you'll need to update your eggs
<bigjools> well, dists
<gary_poster> k
<gary_poster> bigjools, I see "Error: Picked: txlongpoll = 0.2".  Fixing versions.cfg for that...
<bigjools> gary_poster: weird, I don't see that
<gary_poster> bigjools, ok now duped Twisted problem.  Looking more...
<bigjools> gary_poster: ah right sorry, I had already applied the change to versions.cfg and didn't tell you :)
<gary_poster> :-) cool
<rvba> gmb: Could you mentor a review of mine? (the branch it self is from allenap)
<gary_poster> bigjools: txlongpoll says it depends on twisted not Twisted.  The name is Twisted, and everything else spells it as such.  Apparently this confuses setuptools and/or buildout code.  You can verify by editing eggs/txlongpoll-0.2-py2.6.egg/EGG-INFO/requires.txt to have Twisted, not twisted.  Then build will complete successfully.  I suggest changing setup.py in txlongpoll and rolling a new release.
<bigjools> argh
<bigjools> I thought it might be something like that
<bigjools> thanks gary_poster
<gary_poster> welcome bigjools
<bigjools> I can't do enough releases
<gary_poster> :-)
<flacoste> danilos: i agree with lifeless
<danilos> flacoste, cool, so what do we do about it? ask cr3 to fix it all for us? :)
<cr3> danilos: oh oh, what's this I hear about work?
<flacoste> danilos: or ask a losa  if cr3 isn't responsive enough :-)
<cr3> flacoste: good assumption! it would indeed make sense to have danilos on /ignore
<gmb> rvba: Sorry, was otp. Certainly, I'd be happy to.
<rvba> gmb: Thanks, here you go: https://code.launchpad.net/~allenap/launchpad/longpoll-storm-events/+merge/76215
<gmb> rvba: Okay, I'll take a look shortly.
<cr3> flacoste: seriously though, is this about builders, hardwaredb, results tracker or something else? I'm not seeing an obvious thread by scrolling above
<flacoste> cr3: it's about the bug supervisor for launchpad-results
<benji> gmb: if you get a minute to look at a simple lazr.restful branch, I'd appreciate it: https://code.launchpad.net/~benji/lazr.restful/bug-854695/+merge/76230
<cr3> aha! I see now, bugs in launchpad-results. where can I familiarize myself with lp-project standards for bug supervision, I'm all for following that too
<gmb> benji: I'll add it to my list.
<benji> thanks
<cr3> flacoste: someone did ask me to triage them more quickly before, which I've been doing so far.
<flacoste> cr3: we'd like to change the bug supervisor so that the lp team can triage the bugs
<cr3> flacoste: I suspect that "critical" might appear as a big red light on your radar though
<flacoste> also
<cr3> flacoste: if you change the bug supervisor to launchpad itself and I'm not a member of launchpad engineers, won't that case problems for me?
<cr3> s/case/cause/
<flacoste> cr3: we should create a new team and make ~launchpad part of it
<cr3> flacoste: we've got ~launchpad-results, could we use that?
<cr3> flacoste: I changed bug supervisor of launchpad-results to ~launchpad-results so, if you add that team to ~launchpad, we should be good to go
<sinzui> gmb, do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-official-branches-0/+merge/76128
<flacoste> cr3: we want to add ~launchpad to ~launchpad-results
<gmb> sinzui: I'll add it to my queue. Shouldn't be a problem.
<cr3> flacoste: done
<flacoste> cr3: thanks
<danilos> cr3, thanks from me as well (if I am still not on your /ignore list :)
<danilos> cr3, and I hope you won't be bothered with lp-devs mistriaging bugs for launchpad-results from now on, because that's what we do :)
<adeuring> gmb: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-9/+merge/76241?
<gmb> adeuring: There's a couple of branches in the queue in front of you, but I'll try to get to it.
<adeuring> gmb: ok, thanks
<cr3> danilos: bugs for launchpad-results are on my super sonic radar, so I'd like to see you try mistriaging bugs :)
<bigjools> flacoste: your guess was right about the clashing twisted paths
<flacoste> bigjools: do we need to use a plugins? can't we use a regular tac file?
<bigjools> flacoste: we can't
<bigjools> tacs don't let you pass command line args
<bigjools> flacoste: ah I may be talking cobblers
<bigjools> it does find it but there's an import error that twisted was masking
<bigjools> hence ignoring the plugin
<bigjools> gary_poster: I have an extra directory in txlongpoll that also needs to be in the egg. How do I make that happen?
<gmb> sinzui: r=me with grammatical nitpicks
<sinzui> thank you
<nigelb> sinzui: Heh, re: the mailing list thread - Of course, you're the expert in mass bug status changes :P (j/k)
<sinzui> nigelb, indeed. This script is actually from my 18 month effort to make sense of Lp's bugs
<nigelb> sinzui: Its interesting how LP bugs are all Critical, High, or Low.
<nigelb> I liked what stub suggested
<nigelb> Critical should be reserved for things that need overnight/weekend fixing.
<sinzui> There are only three states. LP engineers like to bend Lp rules while telling other projects not to do it
<nigelb> sinzui: Which turns out to be - "Now!", "Some time in the next 6 months", "not any time soon"
<sinzui> nigelb, The three states are: do now (move to the top of the schedule), do next (schedule), do whenever (wait for an opportunity when fixing another bug)
<nigelb> sinzui: ah! that makes sense, yes.
<nigelb> I tend to pick bugs from the last queue since those are the most unloved.
<sinzui> nigelb, right. The performance-bugs-critical experiment failed because we could not distinguish between operational-critical bugs. maintenance squads work on critical (yet tagged work), feature squads work on high(yet tagged work)
<nigelb> Ah.
<bigjools> sinzui: case in point being the fact that poppy is still not fixed
<nigelb> I was curious how feature squads picked work
<bigjools> it's down to the lead, who is the project manager for that feature
<sinzui> We tag bugs to be part of a feature. We mark the required ones as high, and the optional ones as low.
<sinzui> nigelb, oh, and we mark those that happen to be oopes/regressions/timeouts as critical to remind our selves they really need to be fixed
<nigelb> ah
<nigelb> so, that explains the tags that I've seen
<nigelb> and somewhere in betweeen the escalated bugs also come into play. I'm guessing those go to maintenance queue.
<sinzui> nigelb, I would like to user words that help developers and users know what is going to happen when the bug's importance is set. maybe essential, expected, optional
<nigelb> sinzui: Actually, it would be awesome if teams had the ability to Change bug statuses.
<nigelb> Like, a project says, we will rename Critical to -> X, High -> Y, Low -> Z. We won't use the others.
<nigelb> s/teams/projects
<bigjools> flacoste: do you know how to get a non-python file in an egg?
<sinzui> nigelb, I put some thought to that. We already map external importance to Lp importance. We could support a project mapping that permits qualification of the importance. There could be three mapping to low, one meaning  a feature request, a bug in the rules, a rare oops that users can recover from
<nigelb> sinzui: But those can be done with status + tags. I like having fewer statuses than more.
<sinzui> nigelb, me too. I never suggested we support that level of customisation. project owners sometimes ask for it, but that undermines inter-project collaboration
<sinzui> User just want meaningful labels.
<gary_poster> bigjools, /me lunching, but just saw your question.  The sarcastic solution is to use subversion, since setuptools has automatic support for that and only that.  The real solution is to use MANIFEST.in.  This is an underdocumented Python thingy.  Lemme see if I can find you the docs...
<bigjools> gary_poster: ok thanks.  It's an xml file that the project needs to load at runtime :(
<gary_poster> bigjools, ack.  So, the docs are http://docs.python.org/distutils/sourcedist.html and in particular http://docs.python.org/distutils/sourcedist.html#manifest-template .  A number of ye olde lazr.* packages have them, for .txt files and so on.  Here's an example: http://bazaar.launchpad.net/~lazr-developers/lazr.restful/trunk/view/head:/MANIFEST.in
<bigjools> gary_poster: you rock, thanks
<gary_poster> welcome
<bigjools> gary_poster: ah so does it override the packages= on the setup() ?
<nigelb> sinzui: Agreed (sorry, connection is being flaky today)
<gmb> adeuring: I'm not going to be able to get through your branch before my EoD. Might be worth asking the next OCR, which is... StevenK, if I'm not mistaken.
<adeuring> gmb: sure, no problem.
<gmb> Thanks.
* gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
<sinzui> jcsackett, do you have time to mumble
<gary_poster> bigjools, sorry, had wandered away again.  AFAIK, it is different.  It describes what files locally in this directory tree should be included.  I don't think you can tell python files specified in packages= to take a hike, but then I've never tried.  Maybe it does override.  I've always done both.
<bigjools> gary_poster: yeah I have it working nicely now, thanks
<gary_poster> awesome
<jcsackett> sinzui: i can mumble now--i was grabbing lunch when you pinged me. does now work for you?
<sinzui> jcsackett, too late. I have a meeting with flacoste in 0 seconds
<sinzui> Can we talk in about an hour?
<jcsackett> sinzui: certainly.
<flacoste> sinzui: skype time?
<sinzui> flacoste, I am ready
<cr3> is there a difference between the verb "new" and "create" in the launchpad api? is one preferred over the other in some circumstances?
<flacoste> cr3: no. there isn't, fixing this inconsistency would be nice
<sinzui> hi jcsackett. Do you have time to mumble?
<jcsackett> sinzui: sure, just a moment.
<jelmer> abentley: I'm pretty sure bug 854654 is a dupe
<_mup_> Bug #854654: Cyrylic nicknames in ADC are not allowed <FlexHub:Confirmed> < https://launchpad.net/bugs/854654 >
<jelmer> ehm, bug 854964
<abentley> jelmer: I couldn't find another bug like it.
<_mup_> Bug #854964: 2a format permits fetching tree-reference entries <2a> <nested-trees> <Bazaar:New> < https://launchpad.net/bugs/854964 >
<jelmer> I recall filing one in the past, but can't find it now either..
<abentley> jelmer: anyhow, it damages the prospects of converting the subtree branches to 2a, because we don't know what might be in their history.
<abentley> jelmer: even though lp:~ebbe/+junk/game is the only one that could not be pulled into a 2a branch.
<lifeless> sinzui: your summary of medium bugs includes low bugs
<lifeless> sinzui: is it stale?
<sinzui> lifeless, I think I need to recheck the rules. I expected duplicates from multiple bug tasks, but not actual errors
 * sinzui rechecks the script
<lifeless> sinzui: I just invalidated the bug about email processing not being tested enough
<lifeless> as a not-useful-bug
<lifeless> but
<lifeless> it was low
<lifeless> and in your list of mediums :)
<lifeless> you made it low yourself not long ago
<sinzui> ha, I tend to do that when I view a Medium bug. My new report will be done in a few minutes.
<lifeless> it was bug 30138
<_mup_> Bug #30138: Notifications generated by the email interface should be properly tested <email> <lp-bugs> <story-better-notification-sending> <test-system> <Launchpad itself:Invalid> < https://launchpad.net/bugs/30138 >
<sinzui> ah, I am not getting open-only bugs. So much for the default search rules.
<lifeless> sinzui: you are
<lifeless> sinzui: I *closed* it when I saw it in the list.
<sinzui> :)
<lifeless> sinzui: my concern is that it was *low* since '2011-08-26'
<lifeless> so your list must be a month old or something
<lifeless> (a month old | buggy)
<lifeless> if its a month old its fine. If its buggy its not :)
<sinzui> While the script pre-exists, the list was made this morning. I wonder if I have cached bugs
<timrc> anyway to get at ppa creation date from the web service api?
<lifeless> then there was something significantly wonky
<timrc> does not look like it from my cursory check :/
<lifeless> sinzui: I see 967 medium bugs
<lifeless> sinzui: ah, thats lp; lp-project: 1068
<sinzui> yes, I am searching lp-project
<lifeless> sinzui: I think we can just close many of these
<lifeless> e.g. https://bugs.launchpad.net/launchpad/+bug/3454
<_mup_> Bug #3454: Should have a UI for assigning multiple tasks to a milestone <lp-bugs> <milestone-management> <Launchpad itself:Triaged> < https://launchpad.net/bugs/3454 >
<sinzui> Well I think that of many low bugs. as well
<lifeless> its obviously a work item in planned work, rather than a defect report describing a users issue / limitation the user encountered.
<lifeless> I will do a table scan of these.
<sinzui> I remind myself that if a user provided a patch, I would accept it
 * lifeless opens 100 tabs
<lifeless> okok, 75
<nigelb> ...
<nigelb> lifeless: Aren't you supposed to be away today?
<sinzui> lifeless, the feature aspect of the bug is an interesting point considering that many of the bugs are reported by us as an idea that seamed relevant 3 years ago
<lifeless> sinzui: I agree
<lifeless> sinzui: but I think for most things we have no shortage of ideas on how to improve; they don't generally have value like a report of how something affected a user.
<lifeless> sinzui: I won't be cavalier
<lifeless> sinzui: if you want to take the second page of a web search for medium bugs in -project, default sort order; we could triage 10% of the total in about 10 minutes.
<lifeless> nigelb: yes, but thats never stopped me.
<sinzui> jml said something similar. I wish I could remember the exact phrasing of his witticism.
<nigelb> lifeless: Good point. I was planning to pick your brains tomorrow morning.If you will be around later today, I might just do that :)
<lifeless> nigelb: Think of it as priorities: today my priority is my family. But I may do somework. On work days my priority is work, but I may look after my family.
<nigelb> lifeless: Well said :)
<sinzui> lifeless, the difference in my numbers and lp-projects numbers is that I not subscribed to all private bugs :)
<lifeless> sinzui: sure, but how did that low bug get in the list ?
<sinzui> lifeless, I cannot explain. My revised report only shows mediums: http://pastebin.ubuntu.com/694004/
<sinzui> lifeless, sorry. I ran against qastaging!
 * sinzui runs against lpnet
<lifeless> sinzui: haha :)
<lifeless> do we support debtags yet ?
<lifeless> no :)
<lifeless> bug 4730 - does the publisher have a --dry-run ?
<_mup_> Bug #4730: Publisher tool option to only change the database, not the archive <lp-soyuz> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/4730 >
<lifeless> hah
<sinzui> jcsackett, r=me
<jcsackett> sinzui: hurray!
<jcsackett> sinzui: any chance this can wait a bit too land? i'd like to take some time to debug my ec2 issues and having a branch to send out would be nice. :-)
<jcsackett> s/too land/to land/
<sinzui> land as you you wish
<lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/34343
<_mup_> Bug #34343: Shouldn't allow task or blueprint reassignment to an upstream that doesn't use Launchpad <lp-blueprints> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34343 >
<lifeless> sinzui: did we perhaps fix-by-driveby that ?
<sinzui> hmm
<sinzui> lifeless, I do not think so. I reported that bugs has the same error last month
<lifeless> ah, so there is a dupe out there ? :)
<sinzui> lifeless, this they are not since we need three vocabs, each to represent valid spectarget, bugtarget, and questiontarget
<sinzui> The current fields only require an active target
<lifeless> ahhh! - you know that librarian bug
<lifeless> waaaay old dup
<lifeless> https://bugs.launchpad.net/launchpad/+bug/34758
<_mup_> Bug #34758: librarian will set type to text/html though it should be text/plain <infrastructure> <librarian> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34758 >
<lifeless> ah no its not
<sinzui> I do not think it is either.
<lifeless> do we have a formatter for libraryfilealias ?
<lifeless> nearly done
<lifeless> \o/
<lifeless> 10% done
<lifeless> I hope I didn't overwhelm anyone's mail queue :)
<sinzui> wallyworld_, wgrant, StevenK. I will be 15 minutes late to the standup
<wallyworld_> sinzui: ok
<lifeless> james_w: hi
#launchpad-dev 2011-09-21
<poolie> flacoste, hi?
<flacoste> hi poolie
<huwshimi> Does anyone know if the little bug icon on the left hand side of bug listings has any more meaning than just showing the importance of the bug?
<wgrant> huwshimi: It's just the importance.
<huwshimi> wgrant: Makes sense. I guess it was just a historical thing
<wgrant> huwshimi: Now you've lost me.
<huwshimi> wgrant: Oh I just mean, it didn't seem to have any more meaning than showing the importance, which is duplication of the importance column and so was probably still there because it has always been there.
<wgrant> I find it's pretty handy to be able to see the importance while scanning down the first few words of the summary.
<wgrant> But it predates the coloured importance column.
<wgrant> In fact, it dates back to the days of separate severity/priority columns.
<huwshimi> wgrant: That's good to know, thanks
<wallyworld_> thumper: hey, i found out the hard way that we allow branch stacking to form a loop
<wallyworld_> well, there are tests which do it anyways
<wallyworld_> surely that's not something we would expect to have occur in real life?
<lifeless> bzr doesn't support it
<lifeless> but, it can happen
<lifeless> so we need to handle it gracefully
<mwhudson> you can create such branches with vfs level access if nothing else, so it would be bad if the db melted in this situation
<wallyworld_> yeah, i've rolled back a trigger i added to db-devel and will rework it to handle this
<poolie> hi huwshimi
<huwshimi> poolie: Hey
<poolie> huwshimi, jelmer is keen to look at the branch pages too some time
<huwshimi> poolie: Ok great. I think what might happen is that it might end up being a feature level project sometime. It's just cropped up a few times recently that we need to clean up some of our basic features
<lifeless> poolie: hundreds? no, 75 :)
<StevenK> Now on revision 13999.
<StevenK> Someone land something!
<wgrant> I have an MP up.
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/overridable-dbconfig/+merge/76316
<wgrant> It's even already tested.
<wgrant> Actually, the db-stable merge will be r14000 :)
<wgrant> hloeung gets it :(
<nigelb> Did we reach 14000?
<wgrant> nigelb: Yep.
<wgrant> [Branch ~launchpad-pqm/launchpad/devel] Rev 14000: Merging db-stable at revno 10994
<nigelb> awwww
<nigelb> Dammit
<nigelb> wgrant:
<nigelb> Err
<nigelb> Do you know if the app servers all of the same rev now?
<wgrant> nigelb: codehosting, librarian, mailman, ftpmaster and ppa are all behind a bit.
<wgrant> codehosting and mailman are being upgraded now.
<wgrant> librarian, ftpmaster, ppa are a bit more of a challenge.
<nigelb> wgrant: I'm thinking in terms of my db patch
<wgrant> So was I :)
<nigelb> HA
<nigelb> I'm not sure which service that falls into though.
<wgrant> All of them.
<wgrant> That particular patch affects *every* service.
<nigelb> WIN.
<wgrant> So we need at least 13932 everywhere.
<wgrant> http://paste.ubuntu.com/694210/ was the status 20 minutes ago.
<wgrant> 13996 is the rev that's deploying now.
<wgrant> You can see the first host had it 20 minutes ago.
<nigelb> AH, nice!
<wgrant> (mizuho == librarian, forster == mailman, cocoplum == ftpmaster, germanium == ppa, crowberry == codehosting)
<nigelb> How many squads are there? Teal, Yellow, Orange, Red, and any more?
<wgrant> That's all.
<wgrant> Teal was formed by the merge of Blue and Green.
<wgrant> After members of Blue departed.
<nigelb> Blue departed?
<wgrant> Green started small, and a couple of members of Blue left, so it was decided to merge Blue and Green into a single squad.
<nigelb> ah
<james_w> lifeless, hi
<nigelb> He's supposed to be away, but he was around earlier.
<wgrant> james_w: He's not meant to be here on Wednesdays at the moment.
<james_w> wgrant, then he shouldn't ping me :-)
<wgrant> And, in a manner rather unlike his usual, he indeed is sometimes not here on Wednesdays.
<nigelb> heh
<nigelb> He was around in the morning
<nigelb> "Think of it as priorities: today my priority is my family. But I may do somework. On work days my priority is work, but I may look after my family."
<StevenK> I thought since there were two codehostings, they could go into NDT
<wgrant> StevenK: They can be updated without downtime, but it requires handholding.
<wgrant> And takes more than an hour.
<wgrant> so they're not in the usual nodowntime set.
<wgrant> They must be explicitly requested.
<wgrant> I documented this on LPS last week :)
<StevenK> And forster is just ... odd
<mrevell> Hallo
<lifeless> ola
<rvba> Morning mrevell.
<adeuring> good morning
<poolie> danilos, hi, if i put up a patch that just turned off those mails (maybe by a flag) would anyone actually complain?
<poolie> re bug 855150
<_mup_> Bug #855150: excessive translation import template mails (also poor phrasing) <mail> <spam> <translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/855150 >
<danilos> poolie, well, many would be happy (especially ubuntu packagers), but some would be worried that their files have not been imported with such a change
<poolie> the worry would come from us suddenly stopping (that could be handled by an announcement) or because they do count on getting them
<danilos> poolie, fwiw, I'd say just go for it, but make sure not to silence the emails when there are errors: i.e. silence only the "no problems" emails
<poolie> yeah
<poolie> i think one of the other bugs says the "errors" mail goes to the wrong people
<danilos> poolie, from us suddenly stopping (iow, they have learned to expect them)
<poolie> but that's perhaps at least not as common
<danilos> poolie, I think that one might be wrong, the error goes to the committer, which is the right person, the fact that it doesn't say that is a different bug, but hey... :)
<poolie> hm
<poolie> the person who last committed?
<poolie> they may not know or care about translation though
<danilos> poolie, well, since LP is able to generate templates from a tree, they may have broken it even if they don't care about it (eg. introduced problematic _() marking or something)
<poolie> oh totally
<poolie> very likely
<poolie> but, i suspect an error mail from launchpad will not get them to fix it
<poolie> they will need a more personal mail from a person within their project who does know/care about gettext
<danilos> poolie, well, we did talk about having a 'translation driver' for a project long time ago, we just never did it, but as I said, this particular area is very badly structured and would need a lot of improvements
<danilos> poolie, import queue core mechanics are very (and I mean *very*, circa 2005) code that we never had time to properly clean up, but only stacked things on top
<danilos> very _old_
<poolie> mrevell, +1 on the unexplained oops being awful, fwiw
<wgrant> That has my full support as well.
<jtv> cjwatson: quick note while otp: sid's been converted to transitional debian domination, and all active debian publications are now Published, not Pending, without exception.  Conversions should complete in a few hours, and then we'll land permanent debian domination.  The permanent form will finally delete all packages that Debian has deleted.
<jtv> cjwatson: the transitional form's dealing nicely with withdrawn package versions & failed builds.
<cjwatson> jtv: OK, that should make life simpler for us.  Thanks.
<jtv> cjwatson: note that we've already seen 2 cases of Debian regressing to an earlier version; in those cases, the latest-but-deleted Debian version will also become Deleted in LP.
<cjwatson> uh
<cjwatson> do you have specific examples?  the Debian archive is set up to never go backwards in versions, like ours
<cjwatson> I'm not aware of any historical incidences of that rule being violated
<jtv> We found 1 instance of this in sidâ¦ wgrant, what was that package in sid where the latest-published version was no longer in the latest Sources list?
<wgrant> cjwatson: One was in experimental, where it was deleted and then reappeared with a lower version. I didn't find that entirely unexpected.
<wgrant> The sid case was similar, but rather unexpected.
 * wgrant finds the links.
<wgrant> But in both cases they were removed some time before the lower version appeared.
<wgrant> http://packages.qa.debian.org/t/tcc.html is the experimental case
<wgrant> http://packages.qa.debian.org/i/ixp4xx-microcode.html the very odd, but plausible, unstable one.
<wgrant> 2.4-3 was skipped during a maintainer change, then uploaded 2 years late, or something.
<wgrant> After it had been removed.
<wgrant> One of the strangest occurences I've seen.
<wgrant> Also, it was uploaded with armel binaries.
<wgrant> Ah, it's probably an armel-specific package, I guess.
<wgrant> Yes.
<cjwatson> Wow, that's weird.
<wgrant> Yes.
<wgrant> The reappearance is weird enough.
<wgrant> The version and content of the changelog is... unbelievable.
<wgrant> But it apparently happened.
<cjwatson> We should've reported that to Debian, really
<wgrant> Well, we only discovered it like 2 hours ago.
<cjwatson> I'm not seeing the experimental case
<jtv> I guess this means it's in the pool but not really publishedâso kind of unnoticed garbage?
<cjwatson> it seems to have reappeared with the *same* version
<wgrant> cjwatson: + vs ~
<cjwatson> (and same changelog)
<wgrant> cjwatson: Took me a while to notice.
<cjwatson> oh yes
<wgrant> jtv: It is published.
<cjwatson> "ROM; Wrong version number"
<cjwatson> sigh
<wgrant> Heh.
<wgrant> I didn't know they did that...
<cjwatson> ftpmaster should've told the maintainer to take a hike
<wgrant> Yes.
<wgrant> Although it *is* experimental, I guess...
<cjwatson> I know they'd refuse to do that in unstable
<wgrant> I would have thought they'd refuse it in experimental too, so you never know.
<wgrant> What fun may lie ahead.
<cjwatson> mm
<cjwatson> the ixp4xx-microcode case looks like joeyh being unaware of the later versions
<wgrant> Indeed.
<wgrant> But I wonder how.
<cjwatson> and dak having forgotten about it so it didn't reject
<wgrant> Unless -4 and -5 didn't have binaries.
<wgrant> Ah, it was removed for not building any binaries.
<wgrant> That is interesting.
<wgrant> Ahhh.
<wgrant> -4 and -5 had *arm* binaries only, it seems.
<wgrant> So I guess when arm was dropped it ran out of binaries and got removed...
<wgrant> Anyway, those two seem to be the only cases of that happening since we started importing Debian.
<wgrant> cjwatson: ixp4xx-microcode is probably harmless, since the only binaries for the bad versions are for arm, which is long dead... do we want to tell Joey or someone about it anyway?
<cjwatson> Might not hurt; it should perhaps be bumped to 2.4-6 anyway
<cjwatson> Would anyone object to me taking bug 804252?  It looks relatively trivial but I think it would eliminate a reasonably common source of user-visible error; I currently have http://paste.ubuntu.com/694372/ and am about to run it through tests
<_mup_> Bug #804252: Please support InRelease files <Launchpad itself:Triaged> < https://launchpad.net/bugs/804252 >
<wgrant> cjwatson: Is apt safe these days?
<wgrant> I haven't looked at it recently.
<wgrant> And last time I did it didn't come out too well.
<wgrant> It's also slightly non-trivial to support it for primary and !primary.
<wgrant> As primary signing is still done by a non-native post-publication shell script.
<wgrant> Everything else (mm, maybe not partner) is done using different, native code.
<cjwatson> apt's broken validation was fixed a while back
<cjwatson> oh yes, I didn't notice cronscripts/publishing/distro-parts/ubuntu/publish-distro.d/10-sign-releases
<cjwatson> validation> assuming you mean bug 784473
<_mup_> Bug #784473: Treats partial InRelease signature as verifying the entire file <apt (Ubuntu):Fix Released> <apt (Ubuntu Natty):Fix Released> <apt (Ubuntu Oneiric):Fix Released> < https://launchpad.net/bugs/784473 >
<cjwatson> http://paste.ubuntu.com/694375/ should deal with the shell script case
<cjwatson> although it doesn't look like there are applicable test?
<cjwatson> *tests
<wgrant> That's very probably not tested, right.
<cjwatson> Is there anything else I should be looking at regarding apt?  Since this is deployed in Debian I'd be surprised if it actually failed hard or anything
<wgrant> cjwatson: It didn't fail hard, it was just trivially exploitable, and I'm not entirely confident with having our archive keys doing inline signatures until someone actually audits apt slightly.
<wgrant> But maybe.
<cjwatson> I thought that's what Marc had done in that bug report above
<cjwatson> I can follow up with him if you'd like and find out what security's confidence level is
<cjwatson> Given that we had a report of Release/Release.gpg skew just this morning, I'd like to do something about this, though
<wgrant> Sorry, missed half of the conversation here.
<wgrant> Yeah, it's probably safe, but I am somewhat wary of inline signatures given that just about nobody seems to implement them properly :/
<wgrant> Your diff is probably fine, though.
<cjwatson> I'll mail the security team and see what they think
<benji> I'm having an ec2 land issue that I wondered if anyone else had seen (jtv has had some ec2 land issues lately, but looking back at his messages they don't seem related): ec2: ERROR: You must have an ssh agent running with keys installed that will allow the script to access Launchpad and get your branch.
<benji> I'm not aware of any changes to my setup that would have precipitated the error.
<bigjools> I get that all the time in KDE
<bigjools> ssh-add before you start ec2
<sinzui> jcsackett, ping
<jcsackett> sinzui: hello.
<sinzui> jcsackett, do you need an enchantment to land your branch
<jcsackett> sinzui: it looks like it. same error, nothing has gotten around it.
 * jcsackett is incredibly frustrated with ec2 and his environ.
<sinzui> jcsackett, I will land it now. matsubarawill want to test this today
 * jcsackett nods
<jcsackett> thanks, sinzui.
<sinzui> jcsackett, do you have a few minutes to mumble about what we do next?
<jcsackett> sinzui: sure, just a moment.
* abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 256 - 0:[#########]:256
<rvba> abentley: Hi, would you please mentor a review of mine?  Gavin is my mentor and I'm reviewing one of Gavin's branch ;)
<abentley> rvba: sure.
<rvba> abentley: Thanks: https://code.launchpad.net/~allenap/launchpad/longpoll-merge-diff-event/+merge/76407
<abentley> rvba: as someone with domain knowledge (I wrote the original code), I'd ask whether this is the right place for this.  This not catching every time BMP.preview_diff is updated, only every time a Job updates it.
<abentley> rvba: I don't know that any code duplication is required.  Anything that would be duplicated can be moved into a function called by both tests.
<rvba> abentley: Very good point.
<rvba> abentley: Right.
<abentley> allenap: What do you think about emitting an event every time BMP.preview_diff is updated, instead of every time a UpdatePreviewDiffJob updates it?
<rvba> abentley: So I guess your advice would be to hook up the event generation directly in lib/lp/code/model/branchmergeproposal.py?
<abentley> rvba: I'd certainly look into that.
<allenap> abentley: Sounds good to me. I have spotted one problem...
<allenap> BranchMergeProposal already relies on ObjectModifiedEvents being sent out at particular times.
<allenap> The merge_proposal_modified subscription handler for example, which sends email.
<allenap> So emitting extra events is going to create more mail.
<allenap> I may have to create a PreviewDiffUpdated event.
<abentley> allenap: A PreviewDifffUpdated event that derives from OjbectModifiedEvent, but is blacklisted from generating email?
<allenap> abentley: I think it would probably not inherit from ObjectModifiedEvent.
<allenap> Just from IObjectEvent.
<abentley> allenap: Since it does represent a modification of an object, and since ObjectModifiedEvent is our standard way of communicating that, I'd be inclined to make it inherit from it at least.
<rvba> allenap: If a ObjectModifiedEvent is already emitted ... doesn't it mean that we already have what we want?
<abentley> allenap: but can't you just change the mail handler to skip preview-diff-only events?
<allenap> Alternatively I could just do lp.app.longpoll.emit(bmp) instead of zope.event stuff.
<allenap> rvba: They're only emitted by browser code, not the job code.
<rvba> allenap: ah ok.
<allenap> abentley: Yeah, that's probably the most elegant way to do it.
<abentley> allenap: I have been trying to find a "pre-change" hook for Storm columns, but so far, no dice.
<allenap> abentley: There's storm_validator (?) to abuse ;)
<abentley> allenap: Storm also has its own events, but they're not meant for API clients to use.
<allenap> abentley: I could subclass Storms column/property and override __set__ and __delete__.
<abentley> allenap: there's this thing I've seen a few times where there's a read-only property and a private version of the property, and a public setter.  That might be the best way to go.
<allenap> abentley: Hehe :)
<abentley> What's funny?
<allenap> abentley: That's the pattern used in Job.status/_status, the one I tried to replace with a storm_validator a while back.
<allenap> I thought you were alluding to that.
<abentley> allenap: I was, but I'd forgotten you made the change.
<abentley> allenap: ISTM that Int accepts variable_kwargs, which will let you specify an event system, which will have 'emit' invoked on it when the value changes.
<allenap> abentley: Ah, interesting! Thanks.
<jcsackett> jam: are you around/have a few moments?
<cr3> flacoste: heads up, I just created a mailing list for ~launchpad-results to which we added ~launchpad yesterday so you will probably not want the ~launchpad folks to get emails from thatlist
<flacoste> cr3: they won't receive mail from the list unless they subscribe to it
<flacoste> cr3: so everything should be fine
<cr3> flacoste: excellent, thanks!
<jcsackett> sinzui: up for another quick round of mumbling?
<sinzui> yes
 * gary_poster tries to remember who was on the soyuz team, to try to ask someone if https://bugs.launchpad.net/launchpad/+bug/855479 is reasonable or not...bigjools not here. StevenK and wgrant hopefully sleeping.  Celso Somewhere Else. ...am I forgetting someone?
<_mup_> Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 >
<gary_poster> or maybe that's codehosting, in which case we are significantly more without knowledgable resources...
<gary_poster> abentley-lunch...if you have a moment, am I right that this is about what Paul was working on right before he left for U1?  If so, do you know if this is a reasonable bug, or if it's user error? It looks reasonable, but I really don't know.  I can try asking Paul if you are not sure.
<gary_poster> https://bugs.launchpad.net/launchpad/+bug/855479
<_mup_> Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 >
<flacoste> gary_poster: jelmer can probably have an informed opinion too
<flacoste> gary_poster: jelmer was on the soyuz team for more than a year
<gary_poster> flacoste, ok cool, thanks
<flacoste> it might be a problem with bzr-builder which he maintains with the bzr team
<gary_poster> jelmer, if you are around, the question is just this.  Do you know if this is a reasonable bug, or if it's user error? It looks reasonable, but I really don't know.  https://bugs.launchpad.net/launchpad/+bug/855479
<_mup_> Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 >
<abentley-lunch> gary_poster: I don't think he was working on that specifically, but yes, the code team was working on recipes when he left.
<gary_poster> abentley-lunch, ok cool.  Do you have any ideas on this?
<abentley-lunch> gary_poster: it would definitely be a bzr-builder issue.
<gary_poster> ok.  Since you don't say the bug is broken, I'll assume it is real, and triage it high and move on.
<gary_poster> thanks abentley-lunch
<abentley-lunch> gary_poster: Well, it looks like bzr-builder already accomodates specifying the distribution.
<abentley-lunch> gary_poster: so presumably it's a matter of supplying that flag.
<gary_poster> abentley-lunch, oh ok.  On https://code.launchpad.net/~diwic/+recipe/alsa-hda-daily it looks like he is correctly specifying what he wants (Maverick and Natty).  Is this something he should have done differently, or something we need to expose, or...?
<james_w> http://paste.ubuntu.com/694633/
<abentley-lunch> gary_poster: I don't think it's something we need to expose.  We have the data, we just need to use it.
<gary_poster> james_w, that's the likely fix?
<gary_poster> abentley-lunch, ok I think I've got it, thanks
<james_w> gary_poster, yep
<gary_poster> thanks james_w, cool
<gary_poster> abentley, we have no tests for that machinery AFAICT.  Am I right, am I missing something, or do you not know?  Given that, I'm tempted to apply the patch James gave, and ask for a review from someone who claims to be an expert (you? bigjools?)
<abentley> gary_poster: we have no automatic tests.  We should not be cavalier about that.  Breaking the buildd would have serious consequences.
<gary_poster> abentley, agreed, but do we have any protection mechanism other than "ask the expert"?
<abentley> gary_poster: There are tests we can run manually, i.e. test_buildd_recipe
<abentley> gary_poster: That will require a local soyuz: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
<gary_poster> abentley: test_buildd_recipe: ah, I see.  good.  So...if we changed 'maverick' to 'natty' in that file maybe it would trigger the broken behavior?  local soyuz: cool, though I'm not really comfortable with my background knowledge.  I'll make notes in the bug for now.
<abentley> gary_poster: It depends on the existing changelog contents, but yes.
<gary_poster> cool, great
<gary_poster> thank you abentley
<abentley> gary_poster: you're welcome.
<bac> c
<lifeless> incoming
<lifeless> nigelb: what did you want to ask me ?
<lifeless> sinzui: is bug 46385 part of disclosure ?
<_mup_> Bug #46385: Malone should prohibit filing bugs on obsolete packages <lp-bugs> <motu> <Launchpad itself:Triaged> < https://launchpad.net/bugs/46385 >
<lifeless> sinzui: I think its a dup of some of your vocab stuff
<sinzui> lifeless, I think that is fixed
<lifeless> thanks
<sinzui> I know I cannot report a bug against a package that was in dapper, but not in oneiric
<sinzui> I tested this recently
<james_w> OOPS-2090STAGING85
<james_w> no bot :-(
<james_w> is it worth my time waiting for that oops to show up on lp-oops?
<james_w> https://lp-oops.canonical.com/?oopsid=2090STAGING85
<james_w> any clues
<james_w> it's a new one on me
<james_w> oh
<james_w> it's saying "you must be authenticated to do this"
<james_w> 500 seems wrong there
<mwhudson> whuh?
<mwhudson> looks like you can _almost_ subscribe people to blueprints without being logged in?
<mwhudson> presumably the model check is usually done in the view
<mwhudson> er
<mwhudson> s/model/permission/
<mwhudson> yeah, subscribe is in ISpecificationPublic
<mwhudson> i guess there needs to be ISpecificationAnyPerson too?
<mwhudson> oops, i see i managed to break feature flags
<benji> mwhudson: at the moment a virtual ISpecificationAnyPerson is "created" in lib/lp/blueprints/configure.zcml on lines 176-179 by naming attributes
<mwhudson> benji: ah ok
<benji> if you have an attribute or two to add, putting them there would be reasonable; moving linkBug and unlinkBug to a real ISpecificationAnyPerson would be reasonable too
<mwhudson> so i guess subscribe just needs to move out of ISpecificationPublic then
<benji> it looks that way to me
<benji> in fact, there are several mutators there that look suspicious
* abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
<mwhudson> https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/+merge/76493 anyone?
<lifeless> wgrant: when you arrive - would like input on bug 87012
<_mup_> Bug #87012: Cannot start developing next ubuntu release before the prior one is released <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/87012 >
<lifeless> mwhudson: is the old code rolled back ?
<mwhudson> lifeless: yes
<lifeless> so why is your branch linked to the rollback bug ?
<mwhudson> lifeless: because i don't know the correct process i guess
<lifeless> ok
<lifeless> so reopen your bug
<lifeless> the rollback bug was fixed when curtis rolled it back (and will be released when that deploys)
<mwhudson> ah ok
<lifeless> in http://bazaar.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/revision/14013
<lifeless> line 130 of the scopes.py diff.
<lifeless> why?
<lifeless> oh
<lifeless> nvm
<sinzui> jcsackett, in approved you branch to remove the flags, *but* I do not want it landed until next week.
<jcsackett> sinzui: works for me.
<jcsackett> sinzui: not like i can land right now anyway. :-P
<sinzui> I cannot use qastaging for my official source package branch because of ssl errors
<sinzui> I have a api script ready for staging when it gets the right revisions
<mwhudson> lifeless: thanks
<lifeless> wgrant: ping
<lifeless> wgrant: could also use a comment on bug 69755
<_mup_> Bug #69755: Gina shouldn't use the maintainer for the sourcepackagerelease owner <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/69755 >
<StevenK> huwshimi: Prod.
<huwshimi> StevenK: Hey
<StevenK> huwshimi: O hai Mr UI person. Could you please glance at bug 690570, along with my MP for it: https://code.launchpad.net/~stevenk/launchpad/include-ppa-url/+merge/76499 , and tell me what you think of my proposed solution?
<_mup_> Bug #690570: Include URL to Private PPA in Private PPA activation email <disclosure> <lp-soyuz> <p3a> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/690570 >
<huwshimi> StevenK: Sure
<wgrant> lifeless: My analysis has always matched what you've written there, but I have never verified that enough to actually Invalid the bug.
#launchpad-dev 2011-09-22
<huwshimi> StevenK: Sorry, I'm just trying to look at a couple of things. What appears on the recipient_subscriptions_url and ppa_url pages? I can see from the test what those urls translate to, I would just like to see an example of those pages.
<huwshimi> StevenK: I'm mostly trying to see the difference between those pages
<lifeless> wgrant: so...
<wgrant> lifeless: It's now Invalid. There are other bugs for the build notification issues.
<wgrant> lifeless: (which should have been a critical part of DDs, but nobody in the squad thought about it)
<huwshimi> StevenK: Ah actually I figured it out.
<lifeless> wgrant: can you confirm my comment on bug 47353
<_mup_> Bug #47353: give-back-loop detection would be desireable <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/47353 >
<huwshimi> StevenK: I know you haven't touched this, but shouldn't the  'recipient_subscriptions_url' link to be to: https://launchpad.net/~huwshimi/+archivesubscriptions/(id)/+index instead of the generic list of *all* the archives (I assume we can be smart enough to do that)?
<lifeless> sinzui: I believe bug 50894 should be fix released
<_mup_> Bug #50894: Can't change the distribution for a distro package bug report <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/50894 >
<lifeless> sinzui: and have you seen bug 52656 in the context of disclosure?
<_mup_> Bug #52656: Reports that bug contacts have been subscribed when they haven't <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/52656 >
<lifeless> sinzui: also! bug 52915 - wallyworld_'s work should fix-release that, no ?
<_mup_> Bug #52915: Reassigning a private bug to a different product doesn't notify either the new product maintainer or security contact <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/52915 >
<lifeless> sinzui: perhaps not, but close to it. Or something.
<wallyworld_> lifeless: i don't think it will but i can add it to my todo list
<lifeless> wallyworld_: I'd check with sinzui but it seems awfully close to 'easy' now.
<wallyworld_> +1 yes
<lifeless> wgrant:  is bug 54773 still relevant?
<_mup_> Bug #54773: Dry run on process-accepted isn't always dry <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/54773 >
<wgrant> s/process-accepted/Soyuz/ s/always/often/
<lifeless> and hah - isn't bug 55030 a dupe ?
<_mup_> Bug #55030: Binary domination removes arch-all binaries too soon <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/55030 >
<lifeless> (sorry to be dragging you into this, but these bugs are sparse on symptoms)
<wgrant> lifeless: 55030 would be the original, I assume...
<wgrant> But I think there is a modern dupe which has been escalated.
<wgrant> Right.
<lifeless> and bug 55520
<_mup_> Bug #55520: Extend the package-driven approach to Domination & JudgeSupersed <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/55520 >
<lifeless> a work item with no context. \o/
<wgrant> I *think* that refers to the pushing of lots of publishing code into SPPH.publish.
<wgrant> But that bug has long been a mystery.
<lifeless> bug 55521 is even more useful
<_mup_> Bug #55521: Benchmark DeathRow procedure <lp-soyuz> <soyuz-publish> <Launchpad itself:Invalid> < https://launchpad.net/bugs/55521 >
<wgrant> Yeah, because we know how fast it is. "not"
<wgrant> lifeless: Hmm, I'm pretty sure there's an RT for that bug you said there was an RT for.
<wgrant> https://rt.admin.canonical.com/Ticket/Display.html?id=43780
<lifeless> wgrant: echan :P
<lifeless> oh good
<lifeless> I just failed at search
<lifeless> wgrant: is 60190 fixed ?
<wgrant> Bug #60190
<_mup_> Bug #60190: Misleading email when uploads are UNAPPROVED <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/60190 >
<wgrant> I think it is fixed.
<wgrant> I'm pretty sure modern emails say "Waiting for approval" in the subject.
<lifeless> sinzui: would like your thoughts on bug 56650, i fyou are still around.
<_mup_> Bug #56650: Restrictions on milestone editing should be dropped <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/56650 >
 * StevenK waits for buildout
 * StevenK looks for a private bug on qas
<StevenK> wgrant: Do you happen to have one handy?
<lifeless> wgrant: so, bug 54773 - is --dry-run wanted for soyuz?
<_mup_> Bug #54773: Dry run on process-accepted isn't always dry <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/54773 >
<lifeless> wgrant: or was it all yagni ?
<lifeless> wgrant: and did I ask you about bug 47353 ?
<_mup_> Bug #47353: give-back-loop detection would be desireable <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/47353 >
<wgrant> StevenK: Bug #1234 should be private still.
<_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
<wgrant> lifeless: Most of our scripts have a dry-run option, but a lot of them don't work.
<wgrant> lifeless: I don't know what we want to do with them.
<wgrant> I commented on 47353 an hour ago.
<lifeless> ah thanks
<StevenK> Oh, ouch
<StevenK> It *isn't* a timeout
<StevenK> ProgrammingError: column branch.transitively_private does not exist<br /> LINE 1: ...agename, Branch.stacked_on, Branch.target_suffix, Branch.tra...<br /> ^<br /> <br />
<StevenK> WALLYWORLD!!
<StevenK> wallyworld_: ^
<wallyworld_> StevenK: context?
<lifeless> qastaging hasn't had the column added
<lifeless> not wallyworlds fault
<wallyworld_> lifeless: i was told that db patch had been rolled out?
<lifeless> process failure with fastdowntime; it should have been applied to qastaging too
<wgrant> Hah.
<wallyworld_> or at least i thought it was
<wgrant> I just independently asked for that in #-ops.
<wgrant> Seeing just such an OOPS myself.
<mwhudson> lifeless: so i can rollback or i can fix the new problem
<lifeless> mwhudson: rollback
<mwhudson> lifeless: is there a command line for that?
<wgrant> It's not landed yet, is it?
<lifeless> bzr merge -r x..before:x; bzr commit; bzr push; bzr lp-land --rollback x
<mwhudson> it might still be in ec2 actually
<wgrant> I see the rollback in 14011
<wgrant> And nothing since.
<lifeless> mwhudson: kill the instance
<wgrant> Kill the instance.
<mwhudson> ok done
<mwhudson> hooray for a slow test suite
<wgrant> Oh, bah, I was looking at the wrong rollback. We can't deploy for a while.
<lifeless> blame the software why don't you
<lifeless> see
<wgrant> Because the rollback was landed 5 hours after I asked :/
<lifeless> 'hooray that ec2 is so slow'
<lifeless> is what I would say
<wgrant> wallyworld_: We need to roll back your garbo job, too.
<wgrant> wallyworld_: We can't deploy that until the triggers are in place.
<wallyworld_> wgrant: why?
<wallyworld_> wgrant: the garbo job doesn't need the triggers
<wgrant> wallyworld_: Because the job only touches branches where transitively_private is NULL, right?
<wallyworld_> yes
<wgrant> And the trigger isn't there to keep transitively_private consistent once it is set.
<wallyworld_> yes
<wgrant> So the job is going to be setting stuff which then gets out of date.
<wgrant> And is never corrected.
<wallyworld_> yes, i think that's the case sadly
<wgrant> Can you revert it, please?
<lifeless> there is an alternative
<wallyworld_> or we could get the triggers deployed
<poolie> hi all
<wallyworld_> which is what i was counting on
<lifeless> set the transitive field to null when updating private
<wgrant> wallyworld_: We can't do that until friday night.
<lifeless> wallyworld_: its /never/ safe to land code with a db dependency in devel before that dependency is in production.
<lifeless> wallyworld_: it needs to be a hard rule, because the timelines for deploys are so radically different
<wallyworld_> lifeless: it wasn't intentional. i had a few branches on the go and got mixed up about the order
<lifeless> wallyworld_: no worries
<StevenK> nigelb has been hitting that, he wants to drop a column, but we haven't deployed the code that stops using it everywhere.
<lifeless> wallyworld_: I'm trying to be really clear about how this stuff hangs together, at the risk of telling folk to suck eggs.
<lifeless> StevenK: reverse case, but yes.
<wgrant> Damn, buildbot is still only half-way through.
<lifeless> StevenK: this is why finishing RFWTAD is so important
<wallyworld_> lifeless: i know the rules, it was a scheduling mistake
<lifeless> wallyworld_: cool :)
<lifeless> wallyworld_: like I said, just erroring on clarity atm cause its so new for everyone
<wgrant> wallyworld_: So, you're reverting that in the next hour or so?
<wallyworld_> yes
<wallyworld_> wgrant: should i mark as qa bad first?
<wgrant> qa-bad bad-commit-XXX
<wgrant> Land with --rollback=XXX
<wgrant> And lp-land, don't ec2 land.
<wallyworld_> where xxx is the rev nr?
<wgrant> Yep.
<wallyworld_> what happened with qas and the column?
<StevenK> But that is seperate from what is blocking my QA, right?
<wallyworld_> i thought the patch to add the column had been deployed everywhere?
<StevenK> Waiting on a LOSA/completion.
<wgrant> StevenK: It's the same rev, but qastaging needed the patch anyway.
<wgrant> wallyworld_: qastaging doesn't automatically do DB upgrades.
<StevenK> TBH, I think that needs fixing
<wgrant> wallyworld_: Mostly to catch stuff landing on devel with DB patches that aren't on prod.
<wallyworld_> sure, but it thought a downtime would do it
<wgrant> wallyworld_: But it also made me notice your rev.
<wgrant> wallyworld_: downtime does the minimal possible.
<StevenK> I'm sick of qas having a DB that is months behind
<wgrant> wallyworld_: Which is applying a patch to production.
<wallyworld_> it's no good on prod if it's not on qas :-(
<wgrant> wallyworld_: We should probably apply to qastaging immediately afterwards, but the timing is terrible and the last couple of downtimes have been.. chaotic.
<wallyworld_> sure. we need to fix the process cause folks will land devel code that will break qas
<wallyworld_> if qas != prod
<wgrant> Well.
<wgrant> OTOH if we leave it manual, it means that lifeless and I are more likely to notice revs like this one.
<wgrant> StevenK: DB restores and upgrades are largely unrelated, FWIW.
<wgrant> Anyway, I am wandering off for a while.
<wgrant> wallyworld_: Please land that revert ASAP.
<wallyworld_> sure, have to save some work first
<wgrant> Confused...
<wgrant> Oh, IDE people.
<wgrant> lol
<wgrant> :)
<mwhudson> wgrant, lifeless: can you be paranoid over https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/+merge/76493 once more?
<wallyworld_> no, not ide.
<wallyworld_> i use a single sandbox that i bzr switch between
<wallyworld_> no ide required to do a rollback
<wallyworld_> at least i can debug without editing source code :-P
<wgrant> mwhudson: That's not landing again until it's been aggressively tried locally, but it looks more sensible now. And is even tested. Thanks.
<mwhudson> wgrant: it was tested before
<wgrant> Ah, that was one of the tests you inverted the order of?
<wgrant> I only noticed the TeamScope ones.
<mwhudson> just with the controller constructed and the request set up in the wrong order
<wgrant> But that's the only scope I knew was broken, so maybe I wasn't looking for the others.
<wgrant> Ah
<mwhudson> wgrant: do you know of any tricks for testing feature rules locally?
<poolie> mwhudson, locally in what sense?
<mwhudson> other than grep for a feature flag check in a template and try to make it happen
<poolie> on lp.dev interactively?
<mwhudson> poolie: yes, lp.dev
<lifeless> mwhudson: visit /+feature-rules
<poolie> and look at the comment at the bottom of all html pages
<mwhudson> poolie: ah cool
<lifeless> mwhudson: better
<lifeless> mwhudson: thanks!
<mwhudson> wgrant: well, i've done positive and negative tests for pageid: and team: scopes
<mwhudson> obviously default still works
<mwhudson> and i'm not sure server scope really makes sense in lp.dev?
<mwhudson> i guess i can change the config to make it look like edge
<lifeless> server.beta IIRC
<lifeless> or something
<poolie> .dev i think
<mwhudson> lifeless: ah you seem to be right
<mwhudson> yeah .beta
<poolie> we could add a /+feature-test form that lets you evaluate random stuff
<StevenK> wgrant: bug 1234 on qas is public
<_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
<poolie> lifeless, do you want to talk about our qbr some time
<lifeless> sure
<nigelb> lifeless: Hey! Sorry, about the late reply. I was trying to understand errorlog.py the other day and I was stuck a bit.
<lifeless> no worries
<lifeless> I have to pop out for a few, if yo uwant to chat in ~20 I'd be delighted to do so
<nigelb> Cool!
<lifeless> wgrant: any comment on bug 117557 ?
<_mup_> Bug #117557: Nascent Upload code doesn't check properly for bad distroseries <lp-soyuz> <soyuz-upload> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/117557 >
<nigelb> I'll grab coffee by then and boot into the right computer.
<wgrant> lifeless: "aaaaaaaa"
<wgrant> lifeless: NascentUpload is pretty bloody awful.
<wgrant> lifeless: Probably still valid.
<StevenK> wgrant: qa-ok
<wgrant> StevenK: Thanks, but it's sorta irrelevant now :/
<StevenK> Indeed :-(
<lifeless> nigelb: okies
<nigelb> lifeless: gimme 2 mins. My laptop with launchpad is booting :)
<lifeless>   still? wow...
<nigelb> Well, I made coffee in between, etc
<lifeless> :P
<lifeless> YHBT HAND HTH
<jtv> wgrant: permanent gina domination looks good on dogfoodâ¦ deleted a frightening number of sid packages, but the remaining number matches the number I see in Sources.gz.
<wgrant> jtv: Yep, saw that on the bug. Excellent news.
<jtv> Unfortunately there's a qa-bad in the way.
<wgrant> jtv: Less excellent news, however, is that it still seems to be running very slowly on production... and script-monitor isn't alerting about it.
<wgrant> 3 qa-bads, actually.
<wgrant> Just two of them are already deployed.
<jtv> wgrant: 3!?  I only see 1 qa-needstesting & 1 qa-bad.
<wgrant> jtv: Like I say two of them are already deployed. There are three rollbacks that need to come through buildbot and qastaging before we can deploy :/
<jtv> We'll have to see whether the slow runs are really a concern after (1) the transitional code is gone and (2) the initial deletions have been done.
<wgrant> Yeah.
<wgrant> I'm more worried that we're not getting alerts about it.
<lifeless> its doing shorter transactionw now right ?
<jtv> Muchly.
<lifeless> cool
<jtv> wgrant: I had to leave before we could discuss my p-d-r suggestion yesterday.  Is it correct that the main worry is hidden long-standing dependencies on ancient librarian files?
<wgrant> jtv: No, that was the first p-d-r issue. This one is probably pool files.
<jtv> The reaper deletes those as well?
<lifeless> huwshimi: do you think bug 126684 is still relevant ?
<_mup_> Bug #126684: Style sheet is overly complex <css> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/126684 >
<nigelb> lifeless: okay, coffee by my side, and work computer turned off.
<nigelb> In other news, a colleague deleted a library from production server because "it was not being used"
<nigelb> I had to put out a fire today morning for that one :)
<lifeless> win
<nigelb> totally!
<nigelb> Okay, couple of things - 1) What all information do I log?
<lifeless> everything you can get except the session cookie
<lifeless> errorlog.py is mostly irrelevant to you btw
<lifeless> s/mostly/entirely/
<nigelb> Oh.
<nigelb> Gah.
<nigelb> I'll get error message, URL, line number as get parameters into js-oopsd
<nigelb> I suppose I can also get a timestamp based on when I get the request
<nigelb> lifeless: 1) More embarassingly, I don't see where in errorlog.py the oops is actually written to file.
<nigelb> I'm guessing that's the bit I can take away from launchpad's oops handling
<lifeless> nigelb: sorry
<lifeless> EBABY
<lifeless> nigelb: all the oops stuff is in python-oops, python-oops-wsgi, python-oops-datedir-repo etc
<nigelb> ah
<nigelb> I could just be using those libs..
<lifeless> s/could/will be/
<nigelb> Right. :)
<lifeless> for instance, http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/view/head:/gpgverify/main.py#L87
<lifeless> parses and configures a datedir repo
<lifeless> then runs the app (a web.py thing, I suggest using wsgiref - it will be cleaner)
<lifeless> see the various project README's and pydocs for more info
<lifeless> what you need will be:
<lifeless> one repo
<lifeless> two configs - one for received js oopses, one for oopses from your wsgi app itself
<lifeless> oops_wsgi wrapped around your app for the latter
<lifeless> and explicit use of the former for the ks oopses
<nigelb> *js
<lifeless> that thing
<nigelb> okay, so I need to read up on python-oops-wsgi and python-oops-datedir-repo
<lifeless> and python-oops :P
<lifeless> remind me tomorrow and I'll put a full project skeleton, and a sketch, together fo ryou
<nigelb> aren't these projects by Canonical/Launchpad?
<lifeless> so you can focus on the interesting stuff
<nigelb> okay!
<lifeless> nigelb: they are, recently extracted from the LP code base
<nigelb> Yeah, I thought so )
<nigelb> :)
<nigelb> wallyworld_: Hey, around?
<wallyworld_> nigelb: yep
<nigelb> wallyworld_: The other day we were talking about overriding default styles for certain forms for the +editemails form that was fixing
<wallyworld_> we were
<nigelb> Do you have an example to point me at?
<wallyworld_> just a sec
<nigelb> I want to get those small bugs of my list :)
<wallyworld_> nigelb: lp/code/templates/branch-macros.pt
<wallyworld_> but only if it is truly a one-off
<wallyworld_> it really should be in styles-3-0.css
<nigelb> Hrm, I could put it in styles--3.0.css
<wallyworld_> nigelb: and i'd check with huwshimi since he is looking at this sort of stuff and trying to fix what we've done badly in the past
<nigelb> Add an ID, grab it in css. override.
<nigelb> Cool, okay.
<wallyworld_> nigelb: so, in other words, we've done certain things in the past with respect to css but it may not be the right way now
<nigelb> heh, I'll talk to him.
<wallyworld_> cool. thanks
<wallyworld_> best to try and avoid creating more tec hdebt :-)
<nigelb> especially when I'm trying to fix tech debt :P
<wallyworld_> lol
<wallyworld_> nigelb: it may be that what was done in branch-macros.pt is ok, but better to ask
<wallyworld_> just to be sure
<nigelb> Personally, I dislike CSS going anywhere other than style.css most of the time.
<nigelb> <-- fan of semantic web
<wallyworld_> yep
<jtv> wgrant: the reaper deletes pool files as well then?
<wgrant> jtv: That is the entire purpose of the reaper.
<jtv> wgrant: and so the great fear is that we might reap files there that we shouldn't?
<wgrant> Yes.
<jtv> I gag at the thought, but perhaps we could have a look at atimes to see if we might get lucky with the number of files that we need to worry about?
<jtv> If we have atimes, of course.
<wgrant> No.
<jtv> No we don't have atimes, or no we can't look at them?
<wgrant> You are aware that there are some hundreds of Ubuntu mirrors, right? :)
<jtv> Ah those.
<jtv> And we can't sample atimes from those?
<jtv> Or do the files get read in the mirroring process?
<jtv> Won't help with internal access, but could eliminate one source of problems?
<jtv> I don't suppose we could stop files that we think can be reaped from being mirrored?
<micahg> wgrant: re bug 137448, I seem to have the option to change everything
<_mup_> Bug #137448: New UI is confusing and counter inuitive for changing affected package <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/137448 >
<wgrant> micahg: You can't change the package or distribution inline -- you have to know to open the expander.
<wgrant> micahg: It used to be that clicking on the package name opened the expander.
<wgrant> Same with status/importance.
<wgrant> Before AJAX.
<micahg> ah, right
<wgrant> But now you can click on status/importance to change them inline, so nobody knows about the expander.
<huwshimi> wallyworld_: Hey
<wallyworld_> huwshimi: yello. was going to ping you later :-)
<huwshimi> wallyworld_: Would you like to wait?
<huwshimi> wallyworld_: Or is now ok?
<wallyworld_> huwshimi: is it ok if i ping you in an hour or so? i'm just finishing a branch
<huwshimi> wallyworld_: Of course! I'm in no hurry
<wallyworld_> huwshimi: thanks. how's the bub?
<jtv> wgrant: how soon do we need the question about the safety of pool-reaping resolved?
<wgrant> undef
<huwshimi> wallyworld_: Doing great. Started smiling on the weekend!
<nigelb> Hey, what are the branch portlets which show statistics? I can't find any.
<wallyworld_> huwshimi: we all laugh at you :-P
<huwshimi> wallyworld_: It's true
<StevenK> wallyworld_: Wah! There are multiple pretty-overlays on a bug page!
<nigelb> what the....
<nigelb> I can now hide comments?
<wallyworld_> StevenK: yes! hence the advice in the mp to do stuff relative to a specific content box or by id :-P
<wgrant> nigelb: No, that's a display bug to do with memcached.
 * StevenK hides nigelb's last comment
<wgrant> WIll be fixed in a few hours.
<nigelb> wgrant: AH
<nigelb> StevenK: lol
<nigelb> Can someone help me with bug 656941
<_mup_> Bug #656941: Portlets on branch list pages disclose information on private branches <lp-code> <privacy> <Launchpad itself:Fix Released by nigelbabu> < https://launchpad.net/bugs/656941 >
<nigelb> I can't reproduce the bug.
<StevenK> wallyworld_: It's fine for +subscriptions, but there are like four for a bug page
<nigelb> Wait. Fix Released.
<wallyworld_> it's fine until someone adds another one :-)
<StevenK> id="yui_3_3_0_1_13166655391282262"
<StevenK> Handy.
<StevenK> wallyworld_: ^ ?
<wallyworld_> StevenK: that's a defualt generated one. you need to tie the overlay to a specific content box or look for it relative to another dom element
<StevenK> Can I pass an id to the constructer?
<wallyworld_> StevenK: for our widgets, we tend to create content box divs with an id named after the property
<wallyworld_> StevenK: see picker_patcher
<wallyworld_> the contentBox is passed in from memory
<wallyworld_> we construct the content box with the id we pass in
<wallyworld_> i could be a bit off on the details
<StevenK> http://pastebin.ubuntu.com/694948/
<StevenK> Those are the first elements of <body>
<wallyworld_> what are those overlays used for?
<wallyworld_> whicu ui elements?
<StevenK> A bunch of them are for bug task editing
<StevenK> The first one is the one I want, but how the frack do you *tell* that :-)
<wallyworld_> they may be tied to an Activator
<wallyworld_> are the overlays shown when the user clocks on a link, or a little sprite?
<StevenK> Yes
<wallyworld_> what's the js module?
<StevenK> bug_subscription_portlet
<wallyworld_> StevenK: it looks like a single overlay is created when the user clicks on a link, and then destoyed after the ajax call. so those other ones must be from elsewhere
<wallyworld_> what's the html inside one of them?
<StevenK> Obviously
<StevenK> The first three all start with a div with class content_box_container
<wallyworld_> i take it you just want to grab the overlay created by the bug sub portlet and ignore these other ones?
<StevenK> Right
<wallyworld_> and the overlay comes up centred on the page i think?
<wallyworld_> which means it is not bound to a node,which means we can't get at it that way\
<wallyworld_> StevenK: one way is to add a css class to the overlay node after it is created eg "bug-subscription-overlay" and do a Y.one('.bug-subscription-overlay')
<wallyworld_> that may be the easiest at the moment
<wallyworld_> StevenK: or you could even set the id of the node but i'm not sure if that's kosher
<wallyworld_> .me needs coffee
<poolie> hi wallyworld_
<poolie> could you finish off https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 some time?
<wallyworld_> poolie: hi. stupid oneiric killed my net connection. :-(
<poolie> i had a bit of trouble with that a while ago
<wallyworld_> poolie: the ball is in lifeless's court
<wallyworld_> he needs to +1 it
<wallyworld_> but then he went and had a kid :-)
<wallyworld_> i'll remind him again
<poolie> why does he need to +1 it?
<wallyworld_> poolie: cause i don't feel i have enough knowledge in that area to be sure it's all ok to land
<wallyworld_> i'm happy to land it once it's said to be ok
<poolie> well, i think your last comment is reasonable:
<poolie> > Given the number of eyeballs that have already seen this mp, it looks ok to me apart from some small lint issues. I can fix those and then land this mp.
<poolie> so..?
<poolie> i think we should at least let xaav know what's happening
<poolie> and ideally actually finish it
<poolie> would it help if i rereview it or get one of my guys to?
<wallyworld_> poolie: i just want to be 100% sure given all the back and forth that has happened on the mp
<wallyworld_> poolie: anyone who feels they have enough knowledge to say it's good is fine by me
<wallyworld_> i agree that it should be finished, it's taken way too long :-(
<poolie> well
 * wallyworld_ sighs. unity is very naughty today. just crashed again :-(
<poolie> so let's make a plan
<wallyworld_> ok
<poolie> i don't want to block on robert in particular, because obviously he has very little spare time
<poolie> and he has read it, and he hasn't specifically asked to get a rereview afaik
<wallyworld_> i don't think so either. i'm scared about anything to do with exporting/publishing, and it's had a lot of iterations, is all
<wallyworld_> greater potential for breakage therefore
<poolie> how about if i ask john to read it; he's touched this
<wallyworld_> sure. if he can +1 it, i'll land it tomorrow :-)
<poolie> and then perhaps you could do the lint fixes and run it up in lp.dev and see if it obviously breaks?
<wallyworld_> ok
<poolie> and if that works, could you shepard landing and deploying it?
<wallyworld_> of course
<wallyworld_> huwshimi: can we mumble tomorrow morning? i've been hamstrung by software issues  for a bit this arvo :-(
<huwshimi> wallyworld_: Of course.
<wallyworld_> thanks. i'll ping you after our standup, around 9:30ish
<wallyworld_> huwshimi: so you've seen the managing disclosure mockups?
<huwshimi> wallyworld_: No I haven't actually
<wallyworld_> huwshimi: ok. i'll email them. they're some screenshots done in balsamic
<huwshimi> wallyworld_: OK thanks
<wallyworld_> and we need to provide some interactive proof of concepts
<lifeless> huwshimi: do you think bug 126684 is still relevant ?
<_mup_> Bug #126684: Style sheet is overly complex <css> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/126684 >
<huwshimi> lifeless: I'll take a look, might need a few minutes to investigate.
<lifeless> no worries
<lifeless> its an old css bug
<lifeless> I figure its very relevant to some of your recently noted things
<huwshimi> lifeless: The css classes it mentions at the start don't exist any more, there are now only three XXXs (which seem to have decent comments), I'm not sure what the conflicting columns is about, !important is still used 9 times (but I don't know if they are required), I'm not sure about the IE6 rules and most of the styles at the end of the stylesheet are there because of refactoring (with comments). sinzui has done some
<huwshimi> pretty large refactoring since this bug was reported.
<huwshimi> lifeless: My hunch is that the bug report is no longer useful as it is. If someone has the ability to figure out if the remaining issue are still valid they would probably be better as individual bug reports
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugs: 256 - 0:[#########]:256
<adeuring> good morning
<jtv> wgrant: an irony just struck me.  ow!
<jtv> In future, if a superseded source package in Release still has binary publications active, don't we just want to keep the source package active for the release's lifetime?  New domination would let us do that.
<stub> bigjools, wgrant: Is process-death-row.py fragile or interruptable from a fastdowntime deploy point of view?
<wgrant> stub: Interruptible.
<stub> wgrant: Is buildd-retry-depwait fragile?
<wgrant> stub: No.
<wgrant> buildd-manager and publish-ftpmaster and publish-distro are about it.
<wgrant> Mm, process-upload too, but we disable that before and it doesn't run for long, so it's never come up.
<stub> wgrant: My next question was process-accepted :-)
<wgrant> Mmm. Not really. It's not ideal if it's interrupted, but it's safe unless that happens while it's half-way through publishing a custom upload that is then rejected by an archive admin before the next run.
<stub> wgrant: That unless makes it sound fragile (shut it down before a fastdowntime db update)
<wgrant> stub: Yes, but it's so incredibly unlikely. But it's normally quick and we haven't run into it before, so you can probably add it to the fragile list and nobody will ever notice.
<wgrant> So if you're doing a mass dbuser change, might as well do that one too.
<wgrant> (I'd almost prefer we accept the minute fallout from an interrupted run, rather than have it disrupt a fastdowntime, but it's unlikely to do either...)
<stub> I'm doing them. Just flagging the necessary ones in the fragile list at the same time. I added process_accepted with a comment explaining it is fast and likely to not need shutting down.
<wgrant> Ah, great. Thanks.
<stub> wgrant: We could improve this with cronscripts.ini or losas pushing out crontab updates before the deploy, but that is out of the scope I'm looking at. But the idea solution (per Bug #845407 metabug) is of course to not need to do that at all.
<_mup_> Bug #845407: soyuz is not fast-downtime friendly <canonical-losa-lp> <fastdowntime> <Launchpad itself:Triaged> < https://launchpad.net/bugs/845407 >
<wgrant> stub: Indeed.
<wgrant> stub: But transactionality when dealing with a filesystem tree that's exposed to Apache is non-trivial, probably requiring model change.
<stub> We just need two-phase commit with PostgreSQL and the archive on the filesystem. trivial.
<wgrant> Yep.
<wgrant> Well, we could do it on Windows.
<wgrant> But yeah.
<stub> We could generate a filesystem on demand from a transactional backend like PostgreSQL...
<stub> If we used fuse to mount it, we wouldn't even need to reengineer that much..
<wgrant> Diskless archives are meant to do that.
<wgrant> But, well, they've been planned for 5 years.
<lifeless> wgrant: can't do it on windows
<lifeless> wgrant: the needed apis are not exposed.
<lifeless> wgrant: ceph of btrfs however..
<wgrant> lifeless: Hm? TxF works fine, even with MSDTC.
<bigjools> lifeless: hows the python-oops-twisted coming along?
<wgrant> Only supported on >= Vista, though, so maybe after your time.
<lifeless> wgrant: ah yea
<wgrant> (TxF == Transactional NTFS)
<stub> So we deploy on Vista. I think the licences are going cheap at the moment.
<lifeless> wgrant: it doesn't talk about the consistency model
<lifeless> wgrant: I could well believe atomic commits but inconsistent reads
<wgrant> Possibly, but that's fine for process-accepted :P
<lifeless> it == wikipedia
<lifeless> oh process accepted? it can do the bzr thing easily
<lifeless> ah it does - nice - 'An application can use TxF to preserve the integrity of data on disk caused by unexpected error conditions and help resolve concurrent file-system user scenarios by isolating your changes from others while the changes are being made.'
<stub> Could bazaar be used to maintain all the generated files? We don't need to put the whole archive in a tree as moving files in and deleting them can be done atomically, but the generated stuff could be done and committed to a branch elsewhere and then pulled into the live tree served by Apache.
<stub> I guess we wouldn't need bazaar for that - just symlinks and rsync
<lifeless> right
<lifeless> or a directory pivot
<bigjools> lifeless: hows the python-oops-twisted coming along?
<lifeless> bigjools: I didn't get anything done today :(
<lifeless> bigjools: but I expect to wrap it up tomorrow
<bigjools> lifeless: you're 300% late on your estimate :)
<lifeless> I am
<bigjools> can I help with anything?
<lifeless> nah
<lifeless> well, you could, but the handoff would probably be ~= to doing it myself
<lifeless> so i don't think its useful
<bigjools> ok I'll just keep nagging
<lifeless> fair enough too
<bigjools> :)
<stub> rvba: https://code.launchpad.net/~stub/launchpad/distinct-db-users/+merge/76535 is a simple one
<rvba> stub: Okay.
<adeuring> rvba, allenap: fancy another review? https://code.launchpad.net/~adeuring/launchpad/bug-739052-10/+merge/76540
<rvba> adeuring: Sure, I'll add it to my queue.
<adeuring> rvba: thanks!
<cjwatson> wgrant,stub: indeed I'm not sure we've ever manually rejected a custom upload, FWIW
<wallyworld_> wgrant: dumb question for you
<wgrant> wallyworld_: Sure.
<wallyworld_> what's wrong with bzr push lp://staging/~wallyworld/+junk/foo  --stacked-on lp://staging/lp-production-configs
<wallyworld_> 'InvalidURL', 'Invalid url supplied to transport: "bzr+ssh://bazaar.staging.launchpad.net/+branch/lp-production-configs": no supported schemes
<wgrant> wallyworld_: --stacked-on initially didn't work for LP. I'm not sure if it does now.
<wgrant> Also, staging probably doesn't have data in lp:lp-production-configs.
<wallyworld_> wgrant: i want to test the trigger to maintain the transitivel_private column, so would like to create a branch stacked on a private one
<wallyworld_> or at least be able to manipulate the privacy status of a branch
<wgrant> wallyworld_: You probably need to ask a LOSA to help you with that tomorrow.
<wallyworld_> ok. sad that we can't test such things ourselves :-(
<wgrant> In a post-Disclosure world we may be able to.
<wallyworld_> hope so
<wallyworld_> it will be quite easy to test if i get someone just run run a bit of sql actually
<wgrant> True.
<wgrant> wallyworld_: Still around?
<jtv> jcsackett: are you Q/A'ing your expander branch?
<jcsackett> jtv: sure; hadn't gotten notice that it had been tagged qa-needstesting.
<jtv> jcsackett: then you know now.  :)  I'm asking because it's one of 2 blockers for something that's getting a bit urgent.
<jcsackett> jtv: no worries; taking a look now.
<jtv> Thanks.
<jcsackett> jtv: mine is qa-ok. good luck hunting down the other blocker. :-)
<jtv> Thanks jcsackett!
<jtv> The other, interestingly, is your reviewer sinzui.  Any idea where he is?
<jcsackett> jtv: it's a bit before the start of the work day here. i imagine he is doing the wake up breakfast dealing with kids thing?
<jtv> I suppose.  Thanks.
<jcsackett> you only got me b/c i was reading the news on my pc when you pinged. :-P
<jtv> I was waiting to pounce.
<jtv> Any twisted experts here?  I'm looking at some suspicous code of this shape:
<jtv> d1 = make_deferred()
<jtv>   d.addCallback(f1)
<jtv> Correction:
<jtv> d = make_deferred()
<jtv> d.addCallback(f1)
<jtv> d.addCallback(f2)
<jtv> And f1 seems to create its own deferred and add callbacks to it.
<jtv> But I don't see anything that would guarantee that f1's own deferred will complete before f2 is called.
<jml> jtv: does f1 retun its deferred?
<jml> return, rather.
<jml> jtv: because if it does, then that Deferred has to fire & have its callback chain complete before f2 is called
<jtv> It does not return its deferred, afaics.
<jml> jtv: if it doesn't, then there is no guarantee whatsoever. Well, unless f1 is using Deferreds in an explicitly synchronous way, which is rare but not unheard of.
<jml> e.g.
<jtv> (I'm simplifying greatly; it's pretty complicated in reality so there's also the risk of getting the call tree wrong)
<jml> def f1(x):
<jml>   d = defer.succeed(x * 2)
<jml>  d.addCallback(this_gets_called_immediately)
<jml>  return d
<jml> (pardon the IRC indentation)
<jml> jtv: as a general rule, if a function gets a Deferred, it ought to return a Deferred.
<jml> jtv: if you want, I can take a quick look at the real code.
<jtv> What kind of âbarrierâ should I look for in the code?  What could be in there to ensure that the nested Deferred completes before the outer one moves on to its own next callback?
<jtv> I don't think the real code lends itself to a quick look, but I just posted an overview on bug 717969.
<_mup_> Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/717969 >
<jtv> It's about one page of call tree, and I haven't figured out a good way of representing the data chain in there yet.
<jtv> I may do that separately.
<jtv> I added a /!\ marker where the nested Deferred seems to be created.
<jtv> I'm not entirely sure it is yet; all I know about that so far is that a proxy has its callRemote called.
<jml> jtv: I don't understand the question. Return the Deferred?
<jml> jtv: otherwise, there's no way of ensuring
 * jml frowns
<jml> the buildmanager really, really needs to have the db stuff separated out so it can be called in deferToThread and so transaction boundaries are crystal clear.
<jml> jtv: working up the stack now.
<wgrant> Ahh, didn't see it being discussed over here.
<jtv> jml: can't judge the first part of that statement but agree with the clarity bit.  Do we even have anything to guarantee, really guarantee, that we're not interleaving unrelated bits of job management in one transaction?
<jml> jtv: not that I saw. other than that historically people have been urged to be careful with changing the locations of commit()
<jtv> wgrant: why were you afraid?  We're too far apart for immediate physical harm, and plenty of time before the next meeting to get a restraining order.
<jtv> jml: be careful where you put those deck chairsâ¦ hey look at that pretty iceberg!
<jtv> I've been staring at this for too long.  I'm getting silly.
<jml> jtv: OK.
<jml> jtv: so, everything from BuilderSlave.status up is returning any Deferred it creates.
<jtv> I believe so, yes.
<jtv> I'm not sure where _that_ Deferred comes from exactly.
<jml> t.web.xmlrpc
<jml> jtv: so, you can rely on that deferred to fire before any call site proceeds to its next callback
<jtv> How does that follow?
<jml> jtv: http://twistedmatrix.com/documents/current/core/howto/defer.html
<jtv> Read that oneâ¦ which bit?
<jml> http://twistedmatrix.com/documents/current/core/howto/defer.html#auto12
<jml> "If you need one Deferred to wait on another, all you need to do is return a Deferred from a method added to addCallbacks. Specifically, if you return Deferred B from a method added to Deferred A using A.addCallbacks, Deferred A's processing chain will stop until Deferred B's .callback() method is called; at that point, the next callback in A will be passed the result of the last callback in Deferred B's processing chain at the time."
<jtv> Ahh
<jml> or see my comments at 12:37-38 UTC
<jtv> That makes more sense now, thanks.
<jml> basically, without that behaviour, we might as well be passing around callback functions.
<jtv> Ah, my backtrace wasn't extensive enough to cover the place where the nested deferred ended up being returned.
<jtv> It's somewhat hidden in a place that creates yet a third deferred.
<jtv> Which it returns, instead of the original.  Hang on.
<jtv> Shouldn't matter, I think.
<jtv> jml: very glad to have your help, by the way.
<jml> np
<jtv> I did find one place (close to where things have been known to go wonky) where a callback returns None.
<jml> jtv: where's that?
<jtv> buildfarmjobbehavior.py, line 108.
<jtv> It's one of those âshould never happenâ cases.
<jml> jtv: even so, it won't matter
<jml> jtv: callbacks can return normal values as well as Deferreds
<jml> jtv: and that code path doesn't do any async operations
<jml> jtv: so no ordering problems.
<jtv> This is mind-bending stuff.  :)
<jml> jtv: yeah, but once you've bent it, it all makes sense.
<jtv> This is what I fear the most.
<jtv> jml: timing and implementation aside, is it a valid abstraction to think of returning a Deferred from a callback as a tail callââfinish all this work before you consider me doneâ?
<jml> jtv: umm. I guess so. I tend to think of any Deferred returned from any function (callback or no) as a thing that will fire when it's completely done.
<jtv> jml: but presumably merely returning a Deferred from a regular function has no special powers?  It may seem a pedantic point but since I'm trying to hunt down a mysterious bug, I can't really assume that everything has been done by safe rules.
<jtv> If a non-callback returned a Deferred that wasn't being kept anywhere, I suppose it would trigger âwhenever.â
<jml> jtv: it has no powers, right. Essentially, when one is returned in a callback, addCallbacks is called on it.
 * jtv frowns
<jtv> Not on whatever Deferred was being executed in the call site?
<jml> jtv: so yeah, if a non-callback returned a Deferred, and nothing was addCallback or addErrbacked to it, then it would trigger whenever (assuming the Python process hung around long enough)
<jtv> In this case it probably wouldâ¦ I'm not particularly expecting this, but it's another thing to watch out for.
<jml> jtv: I can never remember which way around.
<jtv> I wish I had some drawing paper handy.
<jml> but it's pretty logical. might help you to play around with a couple of trivial cases.
<jtv> In a way it's all just tree traversals.
<jml> jtv: I've got to go do pair programming now. Good luck.
<jtv> Thanks for your help!
<jml> also, this might help: http://mumak.net/stuff/twisted-intro.html
<jtv> Ack
<abentley> adeuring: http://code.mumak.net/2011/08/launchpadlib-helper.html
<rvba> jcsackett: Hi ... are you reviewing today?
<jcsackett> rvba: yes! thanks for the reminder. i am somewhat off my scehdule today. :-)
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett, rvba* (allenap) | Critical bugs: 256 - 0:[#########]:256
<jcsackett> and oh god; there's an 822 line diff and an 1888 one in the queue. :-P
<jcsackett> rvba: i suppose you might be interested in me taking a look at your branch, eh?
<rvba> jcsackett: I'm just asking because I've a branch up for review if you're up for it.
<rvba> hehe
<jcsackett> rvba: i'm assigning it to me now.
<rvba> Great, thanks.
<rvba> jcsackett: The 1888 branch seems to be targeting someone specific to review it.
<rvba> jcsackett: I'm working on Ian's branch. 1355 lines ... but it's a re-implementation of a work that has been reverted.
<jcsackett> rvba: ah, thanks for pointing that out.
<jcsackett> we have had some very large diffs of late, it seems.
<rvba> Indeed.
<rvba> sinzui: Hi ... any idea why the diff is still the same even with the prerequisite branch?
<sinzui> rvba, not really
<sinzui> rvba, It may be caused by the fact that the first branch was backed out
<rvba> I've tried to mess around with "-r ancestor:..." and other bzr magic commands but no luck.
<wgrant> If the first branch is merged already, it's not useful as a prereq.
<wgrant> I believe it merges the prereq into the target, then merges the proposed branch into that, and takes a diff.
<wgrant> Rather than diffing from prereq to proposed.
<jtv> oh, hi sinzui!  Is your rollback good for deployment?
<sinzui> yes
<sinzui> oh, sorry, I must have missed the qa-ok on that. I did check it more than an hour ago
<sinzui> fixed
<jtv> Thanks.
<jtv> We've got a green Q/A board; I requested a nodowntime rollout.
<jtv> And now I truly must leave.
<jcsackett> ciao, jtv.
<jtv> nn!
<gary_poster> jcsackett or rvba, https://code.launchpad.net/~gary/launchpad/bug856048/+merge/76597 could use a review
<gary_poster> please :-)
<rvba> gary_poster: Let me check the size of this first ;)
<rvba> gary_poster: Nah, just kidding, I'll do it when I'm done with my current review.
<gary_poster> rvba :-P Yeah that last one was a doozy.  This one is pretty short and sweet.  Thanks!
<jcsackett> rvba: sorry it took me so long, but i have comments up on your MP.
<rvba> jcsackett: Okay, let me have a look at your comments.
<rvba> jcsackett: replied.
 * deryck goes offline for lunch, back in an hour
<jcsackett> rvba: dig, thanks. i replied to your reply, but the gist is r=me. :-)
<rvba> jcsackett: thanks.
<jcsackett> rvba: thanks for your patience.
<rvba> np
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 256 - 0:[#########]:256
<sinzui> jcsackett, do you have time to mumble?
<jcsackett> sinzui: sure.
<lifeless> morning
<nigelb> Good morning lifeless
<abentley> lifeless: morning!
<nigelb> This should be my cue to sleep.
<lifeless> abentley: hi:) nigelb: yes
<nigelb> heh
<abentley> lifeless: do you know of any tech that for getting logging out of a subprocess in Python?  Basically, I'm thinking of serializing the logs, writing them to a pipe, deserializing them.  But I can't believe it hasn't already been done.
<lifeless> hmm
<lifeless> not offhand. I'm curious what the use case is - testing?
<lifeless> I mean, isn't stderr often a pipe in a subprocess?
<abentley> lifeless: Use case is the twisted job runner.
<abentley> lifeless: I can get stderr out, but I'd rather not-- stderr has a bunch of things I don't want to know about.
<abentley> lifeless: and Ideally, I'd control the verbosity of the logging in the parent process.
<lifeless> theres a quirk to be aware of there
<lifeless> our twisted integration generates oopses when a twisted error is logged (not the python logging module - the twisted.python.log module
<abentley> lifeless: that sounds like what we do when a normal error is logged.
<lifeless> it is
<abentley> lifeless: So the thing is that we don't want to generate the oops twice?
<lifeless> but intercepting normal error logging and preventing the oops in the subprocess won't intercept the twisted support (which I'm just rewriting now)
<lifeless> there are two things
<lifeless> a) we need a unique OOPS prefix, or else multiple concurrent subprocesses will overwrite each others oopses
<lifeless> b) we wouldn't want to log the OOPS twice
<lifeless> (and c) - we want the backtrace from inside the subprocess)
<abentley> a) not a concern for this use case.
<lifeless> abentley: theres no concurrency?
<lifeless> abentley: or each job already sets a unique prefix?
<abentley> lifeless: There's no concurrent subprocesses-- one parent, one child.
<lifeless> abentley: do the parent and child have differing prefixes?
<abentley> lifeless: probably not.
<lifeless> so, thats something to be aware of, datedir-repo is really poor at handling this situation
<lifeless> I want to move us off of that very soon
<lifeless> but for now...
<abentley> lifeless: but the parent waits for the child to complete, so it's unlikely to oops concurrently with the child.
<lifeless> if the parent receives log entries
<lifeless> and were to generate oopses on warning-or-above for those entries
<lifeless> abentley: ah, just picked up on the wording
<lifeless> abentley: datedir-repo is not unsafe for 'concurrent oopses' its unsafe for 'overlapping processes which both oops once or more'
<lifeless> abentley: it caches the next id to use, then writes new oopses without checking for collisions, monotonically incrementing ids
<lifeless> abentley: so if the child oopses once, and the parent oopses after the child finishes, the childs oops will be trashed
<abentley> lifeless: okay.  We can give it a unique oops prefix.
<lifeless> abentley: if the parent oopses once, starts the child, the child oopses, then the parent oopses after the child finishes - same effect, but the child wouldn't have overridden the parents first oops.
<lifeless> abentley: thanks. Its a great wart on the oops code, and its caused lots of contortions like this.
<abentley> lifeless: I don't think my current work makes that situation worse, though.
<abentley> lifeless: if you're working on the oops code, pretty please, with a cherry on top, can I get the oops ID back if I generate an oops?
<lifeless> abentley: yes, the new api totally does that
<abentley> lifeless: thanks.
<lifeless> abentley: if you're using the ErrorReportingUtility its a little more constrained. Let me see
<lifeless> raising() returns the oops dict
<lifeless> so
<lifeless> report = errorutility.raising(..)
<lifeless> if report: oopsid = report.get('id')
<abentley> Cool.
<lifeless> the errorreportingutility is very web-stack centric, I'd like to let other things stop using it - most/all of the plumbing is in place to permit that, but we need to make non request-based get_request_timeline() support
<lifeless> have a look a tthe current raising() method in lib/canonical/launchpad/webapp/errorlog.py - that may make it a little clearer
<abentley> lifeless: anyhow, back to my original question.  Is there a better way to do what I'm trying to do here?
<lifeless> I would - oops in the child, serialise-and-deserialise things to log to the parent, and have some way to log errors in the parent without oopsing.
<abentley> lifeless: I don't want to oops in the child.
<lifeless> I don't think there is a better way to ship the logs across
<lifeless> abentley: one of the things the oops grabs is the backtrace
<lifeless> abentley: is the child plain ol python or also twisted?
<abentley> lifeless: I just want the calling process to know that a user error ocurred.
<abentley> lifeless: But it's not an indication of a programming error.
<abentley> lifeless: and so the backtrace isn't important, either.
<lifeless> how do you tell them apart?
<lifeless> I'm sorry if I'm dragging this offtopic
<lifeless> I don't mean to
<abentley> lifeless: if an exceptions's class is listed on JobSubclass.user_errors, it's considered a user error.
<abentley> lifeless: But I'd really like *all* logging to come across, not just errors.
<lifeless> sure
<abentley> right now, the twisted job runner is a bit of a black hole.
<lifeless> if it were easy to have the child create oopses for non user-errors, would you be happy with it writing the oopses ?
<lifeless> that would alleviate my concern about the backtrace *when* it matters
<lifeless> we can still ship all the logs across
<abentley> lifeless: I already have the child creating oopses for non user-errors.
<lifeless> ok, great.
<lifeless> btw you might like to look at errorlog.py's _oops_config.filters - thats an extension point for stopping oopses
<lifeless>  </tangent>
<lifeless> I can only think of three basic ways this can be done: - an API in the client you can query, writing to a pipe the parent watches, or writing to some known-location the parent can read-back from (e.g. a regular file on disk)
<lifeless> I think using a pipe is totally fine
<abentley> lifeless: It seems like such an obvious solution that I'm surprised I can't find an implementation anywhere.
<lifeless> abentley: I suspect most people just log to a file
<lifeless> abentley: and/or stderr, and watch that. Full introspection of whats being logged (which a pipe may allow) is rather heavier than most people need
<lifeless> abentley: I agree that its an obvious implementation for the question 'how do I get all the log entries into a parent process'
<abentley> lifeless: I guess the desire to do parent-side filtering and handling is what's pulling me that way.
<lifeless> abentley: yes. I don't understand that desire, but I'm assuming its got good reasons :)
<abentley> lifeless: At minimum, I want the same verbosity to be used for parent and child logs.
<lifeless> for clarity - I don't mean to imply its unreasonable or anything, we simply haven't chatted about it.
<abentley> lifeless: It also seems to make testing easier.
<lifeless> in the soyuz area we have a similar thing
<lifeless> there is a process that runs N child processes
<lifeless> currently its not passing -q / -v down to them, so the verbosities are different
<lifeless> so +1 on the same verbosities
<lifeless> abentley: what does it do for testing?
<abentley> lifeless: Usually when I test that something gets logged, I do it through the python logging mechanism with TestCase.expectedLog
<lifeless> ok, I can see that helping; OTOH if you're looking from output from a child process when testing the parent code, you are testing 2 layers at once - perhaps it would be better to be testing them seperately?
<lifeless> the only downside I can see to using a pipe and serialising the logs is that it will have tighter coupling than passing command line parameters around and watching stderr / a file on disk
<abentley> lifeless: I want to test the integration.  I want to prove that logs propagate from child to parent.
<lifeless> abentley: isn't that partly  circular? You want logs to propogate because you need the same verbosity + its easier to test, and you're testing that its easier to test?
<abentley> lifeless: no, it's not circular.  I could test that logs propagate from child to parent if they were logged normally to a pipe instead of serialized.  It would just be a matter of getting access to the data that comes across that pipe.
<lifeless> abentley: so there is another reason to pass logs across, other than what we've already discussed?
<abentley> I want all the logs related to a job run to end up in the same place.
<lifeless> ok!
<lifeless> given that I'd be inclined to just write to a pipe
<lifeless> and tell the child verbosity via our standard options
<lifeless> but serialising will work too. The reason I would just write to a pipe is that I think its easier than managing a protocol
<abentley> lifeless: the subprocess is launched via Ampoule, so we can't use the standard way of specifying verbosity, but I don't think it'll be terribly hard.
 * jcsackett hates his development environment today.
<jcsackett> anyone know how to get rid of the "You may supply --create-prefix to create all leading parent directories." messages on local codehosting pushes?
<jcsackett> i've had to rebuild my lp stuff and seem to have broken that, and recall wgrant helping me fix it *months* ago.
<lifeless> incoming
<jcsackett> lifeless: ? is that related to your earlier convo above, or to me? or some other, third thing? :-P
<lifeless> jcsackett: medium bug triage ;)
<jcsackett> lifeless: oh. i see.
 * jcsackett modifies bug mail filters.
<jcsackett> :-P
<lifeless> mwhudson: where is bug 123880 at ?
<_mup_> Bug #123880: Codebrowse needs a custom 502 error page <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/123880 >
<abentley> mwhudson: Do you know if there's a way in Twisted to forward logging from a subprocess to the parent process?
<mwhudson> lifeless: no idea, sounds more like a losa task than anything to me?
<lifeless> sinzui: help on bug 125545 please :)
<_mup_> Bug #125545: Language variants should know their parent language <lp-foundations> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/125545 >
<lifeless> mwhudson: it may even be done...
<mwhudson> abentley: i'm not sure what that would mean
<mwhudson> lifeless: yeah, i think the 502 page for codebrowse is fine currently
<mwhudson> lifeless: so just close it i reckon
<sinzui> lifeless, we do filtering in python instead of the db because we do not know that en_US is a child of en
<sinzui> I marked it low
<lifeless> thanks
<abentley> mwhudson: A suprocess calls log.err, and the effect is as though log.err was called in the parent process.  Presumably by serializing the log messages to a pipe or socket.
<mwhudson> abentley: ah, i'm not aware of anything like that, no
<abentley> mwhudson: Cool, thanks.
<mwhudson> abentley: i notice twisted has a syslog observer http://twistedmatrix.com/documents/10.1.0/api/twisted.python.syslog.html which would be a bit similar to the subprocess side of that i guess
<lifeless> we use that already (via the oops observer, which I'm redoing :P)
<sinzui> jcsackett, could you review https://code.launchpad.net/~sinzui/launchpad/valid-targets-0/+merge/76658 if you have time
<jcsackett> sinzui: i certainly can.
<mwhudson> ah cool
<jcsackett> sinzui: r=me.
<sinzui> thank you
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
<lifeless> wgrant: bug 137448 - really? I thought you fixed that?
<_mup_> Bug #137448: New UI is confusing and counter inuitive for changing affected package <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/137448 >
<lifeless> poolie: if you're still hacking on lp email, bug 138592 would be the bomb to fix
<_mup_> Bug #138592: Bug notifications have personal To: header but aren't personal <email> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138592 >
<lifeless> whats the oldest version of ie we support ?
<StevenK> I hope 7, but I suspect 6.
<lifeless> grah
<lifeless> yeah
<lifeless> I wiped that from mmy mind
<StevenK> Global use of IE6 is hovering around 9%.
<StevenK> IE8 is 30% or so.
<StevenK> Whoa. Firefox *2*. 0.16%
<wallyworld_> huwshimi: you free now for a chat?
* wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 256 - 0:[#########]:256
<jelmer> lifeless: are you going through *all* launchpad bugs, or a specific category?
<huwshimi> wallyworld_: Do you mind if we talk in 10 min?
<lifeless> jelmer: medium
<wallyworld_> huwshimi: sure, ping me when you are ready
<huwshimi> wallyworld_: Thanks
<lifeless> jelmer: there is a discussion about possible downgrading high->medium and critical->high. *if* that happens we don't want to 1000 untriaged bugs to the high bucket
<lifeless> jelmer: there was some talk about a batch move, but I did a sample 75, and many were irrelevant/fixed/dupes or genuinely high; so I suggested we just treat them as untriaged and triage them.
<lifeless> jelmer: I'm doing 75 a day
<jelmer> lifeless: ah, makes sense
#launchpad-dev 2011-09-23
<wgrant> lifeless: re. bug #137448: I fixed the model to permit full retargeting, and added support for that to the legacy, non-AJAX UI.
<_mup_> Bug #137448: New UI is confusing and counter inuitive for changing affected package <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/137448 >
<lifeless> wgrant: bug 163244 needs you to pick *A* flaw in it ;)
<_mup_> Bug #163244: CVE list needs some triaging features <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/163244 >
<lifeless> wgrant: so 137448 is fix released ?
<lifeless> wgrant: or you mean 'not fixed because the ajax ui isn't fixed'
<wgrant> lifeless: I thought that it was referring to the AJAX UI, but I think that bug might predate AJAX. I suspect the specific change the bug complains about is in fact the introduction of a link to the target in the task row, rather than just in the expander where it was initially.
<wgrant> lifeless: However, until packages can be reassigned by AJAX and the expander is removed, I think the bug is probably still valid.
<lifeless> wgrant: yup, I get that
<lifeless> thanks
<huwshimi> wallyworld_: Ready whenever you are
<wallyworld_> huwshimi: ok. mumble?
<huwshimi> wallyworld_: sure
<lifeless> wgrant: get spec by mail ..
<lifeless> (the email fail)
<wgrant> Yeah, but that's not the main issue here.
<wgrant> I've only seen that error once.
<lifeless> oh, I see dkim ?
<lifeless> is it casting str to unicode?
<wgrant> I can see a particular DKIM log message missing from process-mail.log each time we get that cronspam.
<lifeless> done for today, down to 679 medium bugs
<wgrant> 2011-09-22 18:51:13 INFO    Attempting DKIM authentication of message id=<db6701cc7969$046cade0$718d875f@BOOTHRpy> from=<BOOTHRpy@ffni.com> sender=None
<wgrant> That one.
<wgrant> I suspect the crash is in from/sender.
<wgrant> Can we upgrade to Python 3 yet?
<lifeless> anytime
<lifeless> if it works
<wgrant> Hmm, do I want to %r or try to unicodeify them...
<wgrant>     log.info(
<wgrant>         'Attempting DKIM authentication of message id=%s from=%s sender=%s'
<wgrant>         % (signed_message['Message-ID'],
<wgrant>             signed_message['From'],
<wgrant>             signed_message['Sender']))
<wgrant> That's what we're doing now.
 * wallyworld_ goes out for lunch
<lifeless> wgrant: looks like one of those is unicode then
<wgrant> Traceback (most recent call last):
<wgrant>   File "/usr/lib/python2.6/logging/__init__.py", line 791, in emit
<wgrant>     stream.write(fs % msg.encode("UTF-8"))
<wgrant> UnicodeDecodeError: 'ascii' codec can't decode byte 0x98 in position 120: ordinal not in range(128)
<wgrant> lifeless: It's a decode error on encode.
<wgrant> Doesn't that mean it's trying to encode a str?
<lifeless> implicit conversions
<lifeless> 'foo %s' % u'bar' -> u'foo bar'
<wgrant> Fair point, missed the % bit.
<wgrant> Focused on the encode.
<wgrant> Anyway, -> maintenance peeps
<lifeless> the log message ends up being unicode because its % (...)
<lifeless> or, ah
<lifeless> it may be a str that is utf8, but 'fs' isn't ascii decodable
<lifeless> so fs % msg-as-unicode blows up
<lifeless> need to see the values to know
<lifeless> blah, my turn to miss stuff :)
<lifeless> anyhow, yes we need to fix
<wgrant> wallyworld_: Could you review <https://code.launchpad.net/~wgrant/launchpad/moar-fragile/+merge/76666>? About as trivial as they get.
<lifeless> wgrant: why don't you self review it ?
<wgrant> I didn't really want to self-review a change like that, but might as well.
<lifeless> why not?
<wgrant> It has the potential to do bad things to fastdowntime unless I know what I'm doing.
<wgrant> This stuff is already fragile enough :)
<lifeless> you're adding one name
<lifeless> I can't imagine a reviewer at the code style level having anything to contribute
<lifeless> you're either right, or wrong ;)
<wgrant> I didn't want a style review :)
<lifeless> wgrant: less use of imperatives in bug reports!
<wgrant> lifeless: Fair point.
<wgrant> wallyworld_: How goes QA for your trigger?
<wallyworld_> wgrant: i'll ping stub when he is available. easier that way
<wallyworld_> wgrant: sorry i missed your review. i was having an early lunch with a friend
<lifeless> what do you need done?
<wallyworld_> lifeless: i need to run some sql to update branch.private = true for say launchpad, and then check on of the branches stacked on lp to see that transitively_private is true
<wallyworld_> plus say, once lp is private, unstack a branch and see that transitively_private is false
<lifeless> so, future ref, use a losa
<lifeless> 24h coverage, which stub cannot supply.
<wallyworld_> sure. i thought in this case it would be easier sonce he was familiar with the tirgger etc
<wallyworld_> less hand holding required
<lifeless> a little yes, but it adds latency, and we're kindof latency sensitive once things are in trunk
<wallyworld_> this is in db-devel
<lifeless> yees
<lifeless> thats a trunk
<lifeless> as is devel
<wallyworld_> doh
<lifeless> s/trunk/thing/ we deploy from
<wallyworld_> for some reason i only think of devel as the "real" trunk
<lifeless> when you're not dealing with the schema thats a pragmatic view
<lifeless> but with fastdowntime in the mix, db-devel has the ability to deploy as often as nodowntime has been deploying (but not as often as nodowntime /can/ deploy
<wallyworld_> yes, 95% of the time it's just devel but you are right about db-devel
<wallyworld_> lifeless: i need to catch when a model object property is changed. is the correct pattern in our architecture to make it a r/o property and introduce a setter, marked as @mutator_for(xxx) in the web services interface. the setter would publish an ObjectModifiedEvent which there would be a listener for
<wgrant> There are several different ways to do it.
<wgrant> What exactly are you trying to achieve?
<StevenK> Can anyone reproduce a overlay appearing at the top of a bug page on up-to-date devel? make run and then https://bugs.launchpad.dev/redfish/+bug/15
<_mup_> Bug #15: PO file import errors should be more verbose <feature> <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/15 >
<wallyworld_> i need to know when a bug supervisor or security contact has changed on a project
<wallyworld_> i need the old and the new values
<wallyworld_> StevenK: give me a sec and i'll do it
<wgrant> wallyworld_: You're going to attempt to do a mass subscription/unsubscription?
<wallyworld_> wgrant: no. if a new bug supervisor is added to a project, they need to be auto subscribed if the project is related to any private bug tasks etc
<wgrant> That sounds like a "yes" to me.
<wgrant> And a very bad idea.
<wgrant> Really slow, and attempting to perform sensible disclosure on top of legacy disclosure.
<wgrant> s/perform/implement/
<wallyworld_> i've been assigned a bug to do this work
<wallyworld_> well, there's a 5 digit but and one i assigned myself which is related which curtis agreed to this morning
<wallyworld_> s/but/bug
<wgrant> And I will happily revert any attempt to do that, because it will time out.
<wallyworld_> that's very prsumptuous
<wgrant> It's really not, unfortunately :/
<wgrant> We can do this once we have project observers.
<wgrant> But updating a couple of hundred thousand bug subscriptions in-request is not cheap.
<wallyworld_> this is only for private bugs
<wallyworld_> surely there's not 100000's of private bugs
<wallyworld_> StevenK: what am i looking for?
<StevenK> wallyworld_: http://people.canonical.com/~stevenk/overlay.png
<wallyworld_> StevenK: don't see that
<StevenK> That is upsetting.
<StevenK> Then WTF is causing it for me.
<wallyworld_> try make jsbuild? is your js up to date
<StevenK> That is from a clean devel
<wallyworld_> hmmm. i just pulled the latest devel tip myself and did make clean run
<wallyworld_> is it just on the bug index page?
<StevenK> Hm, no.
<wgrant>  product | distribution | count
<wgrant> ---------+--------------+-------
<wgrant>          |            1 | 29441
<wgrant>     1694 |              |  3598
<wgrant>     9514 |              |  3196
<wgrant>     2982 |              |  1868
<wgrant>     8892 |              |  1607
<wgrant>    10294 |              |  1241
<StevenK> Many private bugs
<StevenK> Shows up on any bug page and https://launchpad.dev/~landscape-developers
<wgrant> StevenK: I don't see it either.
<StevenK> :-(
<wgrant> Whatever Firefox Oneiric has this week.
<StevenK> Then why do I? :-(
<wallyworld_> i'm runnign latest ff beta and don't see it
<StevenK> Perhaps Firebug is confounding me
<StevenK> Where's the option for halting on errors?
<wgrant> StevenK: Tried Chromium?
<wallyworld_> StevenK: can't remember
<wallyworld_> wgrant: i assume distro number 1 is ubuntu?
<StevenK> Yes, Distribution 1 is Ubuntu
<StevenK> wgrant: No. Don't really plan on, either. :-P
<wallyworld_> so i could do it as a cron task. don't think we have a proper jobs infrastructure with persistent state etc yet?
<wgrant> wallyworld_: Why don't we do this in a few months when we have non-legacy disclosure, with observer roles?
<wgrant> wallyworld_: Adding a job is not lightweight enough that we should just throw it away in a few months.
<wallyworld_> observers will probably work for this, yes
<wallyworld_> or we can make sure it works
<wgrant> It's meant to do *exactly* this sort of thing.
<wgrant> Quickly, too.
<wgrant> Without having to write-lock thousands of rows.
<wallyworld_> so we would have to have some sort of denormalisation built into the model
<wgrant> Oh?
<wgrant> Bug supervisor will no longer imply visibility, just like it no longer implies notification.
<wgrant> The default will probably still be supervisor == visibility == notification, but like with structural subscriptions that will just be a default.
<wallyworld_> oh ok. i would expect that as a bug supervisor i would have visibility, however it's done
<wgrant> That doesn't work for Ubuntu.
<wallyworld_> because?
<wgrant> We have many non-Canonical people in the bug supervisor role, but we have coredumps and stuff that should not be visible to them.
<wgrant> (I won't mention security bugs, because sinzui seems to be convinced that they should remain a special case)
<wallyworld_> ok. seems like we are saying to someone to do a role, but not necessarily ggiving them all the info they might need ti make decisions?
<wallyworld_> or have i misunderstood?
<wgrant> The bug supervisor role's primary purpose is to confer access to the restricted statuses, and the ability to set bug importance.
<wgrant> It was hijacked to be the default subscriber back when default-private-bugs were introduced, because it was convenient.
<wgrant> And that has functioned reasonably well for a few years.
<wallyworld_> what does "confer access to the restricted statuses" mean?
<wgrant> Allow setting and unsetting of Won't Fix and Triaged, and unsetting of Fix Released.
<wallyworld_> ok. but the info need to fix the bug, once triaged and assigned to someone, might remain invisible to the supervisor?
<wgrant> They don't know that that bug exists.
<wgrant> Unless they are also defined as an observer.
<wallyworld_> how can they set bug status if they don't know it exists?
<wgrant> that will be a sensible default for most projects, but it cannot be a universal rule.
<wgrant> They can't.
<wallyworld_> but didn;t you just say that's what the supervisor does?
<wgrant> They can set status and importance on the bugs they can see, yes.
<wgrant> They obviously can't do it to the bugs they can't see.
<wallyworld_> so there's no point making someone a bug supervisor of a bug they can't see
<wallyworld_> and yet the rules now are that bug supervisors are subscribed to private bugs
<wallyworld_> automatically
<wgrant> They are subscribed to private bugs when they are created in a default-private-bugs project.
<wgrant> Which is a tiny subset of projects.
<wallyworld_> sure
<wgrant> And an inflexibility on which we already have bugs filed.
<wallyworld_> so with upcoming disclosure work, this will all change?
<wgrant> Right. The bug supervisor will probably return to its original purpose, no longer implicitly providing visibility by default in some projects.
<wgrant> There's a separate observer list for that purpose.
<wallyworld_> makes sense. thanks for the explanation
<wgrant> So, while it would be nice to do the subscriber transition on bug supervisor change in the current model, it's probably impractical to do now, and is trivially done in a much simpler way once we have the new privacy model up and running.
<wallyworld_> sure
<lifeless> guys
<wgrant> Uhoh.
<lifeless> if we're doing any sort of mass-change, it should be backend driven, and use short (<=2 secs) transactions
<wgrant> Yes.
<lifeless> for bug supervisors
<lifeless> question - is the intent that bug supervisors will be observers?
<wgrant> I hope not.
<wgrant> If there is, the intent is incorrect.
<lifeless> because I expect most projects will want the bug supervisor to see all private non-sec bugs, as they will want the project security team to see all private sec bugs
<lifeless> !cite, I know.
<wgrant> That is the most common situation that I envisage.
<lifeless> How do we intend to help folk achieve that ?
<wgrant> I believe the current proposal, which I vehemently disagree with, is to continue special-casing security.
<wgrant> Observers won't be able to see bugs with the security flag set.
<wgrant> (I haven't heard this confirmed for a couple of months, but it's the last thing I heard)
<lifeless> observers not seeing security is correct
<lifeless> but
<wgrant> sure.
<lifeless> perhaps we need types of observers, or something.
<wgrant> But I don't think it should be a special case.
<wgrant> Yes!
<wgrant> But it was argued that that is too complicated or something.
<lifeless> it veers close to generic acls
<lifeless> but not too close, I think.
<wgrant> To me the most obvious solution is to specify a privacy policy on each bug, sort of like what branches have now except explicit and not crippled.
<wgrant> Most projects would have two.
<wgrant> Private and Security, I guess.
<wgrant> Two I can think of for Ubuntu are Apport and Security.
<lifeless> right, this harks back to the prague, or was it texas, discussion
<wgrant> They probably wouldn't have Private.
<wgrant> sinzui has basically vetoed this, I believe.
<wgrant> But I don't think we can not have it.
<lifeless> where shared-namespace projects would have multiple policies.
<lifeless> the big ui issues I see are clearly communicating the impact of choosing such a policy for a bug.
<lifeless> implementation wise I think it would be easy and execute fast
<wgrant> Exactly.
<wgrant> We don't even have to expose it by default.
<wgrant> Security could be a UI special case, if we want to keep it just how it is now.
<wgrant> Until we smooth things out and open up the general UI.
<wgrant> But the key is that the backend is general, just as fast as a security flag.
<wgrant> And it lets us handle Ubuntu very well.
<wallyworld_> what are some examples of shared namespace projects?
<wgrant> Where the security special case does not, at all.
<lifeless> wallyworld_: storm
<lifeless> wallyworld_: but more seriously, they are in an awkard halfway house at the moment
<lifeless> I think we should -either- ditch them and say that projects are single-owner (e.g. if a private entity wants to work on some other public project, they can't do so in private: they need a separate private project which forks the other)
<lifeless> or we need to do a lot of remedial work
<wallyworld_> dumb question - what about storm makes it shared namespace?
<lifeless> it has multiple different branch privacy policies
<lifeless> when I push a branch there, you cannot see it.
<lifeless> if you push a branch there, I can see it.
<lifeless> this is an example of how it works, not how it should be :)
<wallyworld_> i didn't realise that
<lifeless> theres some enterprise integration branches hardware-qa folk have written
<lifeless> not yet opened
<wallyworld_> lifeless: so what sets your branches private - an attribute on your IPerson instance?
<lifeless> I'm in the hardware-certification team
<wallyworld_> ok. and that's a private team?
<lifeless> that team matches one of the policies, and wins for whatever reason.
<lifeless> the team doesn't have to be private for this to happen
<lifeless> (it may be in this case, I genuinely don't know)
<wallyworld_> but it's policy based per project
<lifeless> yes
<wallyworld_> right
<wallyworld_> lifeless: so how do people get to do code reviews on your storm mp's if your branches are private?
<wallyworld_> i guess only certain people can
<lifeless> they need to be in the hardware-certification team
<lifeless> its like a whole other project, sharing the namespace
<lifeless> own rules, own policies
<wallyworld_> sounds blah
<lifeless> but its not a complete separation
<lifeless> like series are shared
<lifeless> so stacking is shared
<lifeless> wallyworld_: well, the intent is for things where multiple organisations want to do independent private work, for them to do that.
<lifeless> wallyworld_: it also is intended to support things like unity where we have private branches for a while which get opened when hardware vendors ship the final product and we are allowed to open source the code
<lifeless> I'm neither justifying nor critiqing this
<lifeless> just trying to explain why, what it is, and its current status
<lifeless> in the former folk want partitions
<wallyworld_> lifeless: sure, and i appreciate the insights
<lifeless> in the latter folk want public-private partitioning and then free-for-all behind the partition
<lifeless> oem are unique in doing this multiple times with multiple partitions, and they don't use shared namespaces, instead they run N projects (and want us to link things cross-project)
<lifeless> arguably these things are equivalent, but choosing one approach and really polishing it probably makes a lot of sense
<wgrant> There are also non-commercial instances of this sort of thing.
<wgrant> eg. Ubuntu has really private apport bugs, sort of private apport bugs, and security bugs.
<wallyworld_> i'm all for making *one* nicely polished process that can be tuned to fit the required use cases
<lifeless> thats closely related yes. I wouldn't call it a shared namespace as such
 * wallyworld_ sighs. another compiz crash :-(
<wgrant> lifeless: Exactly: it's not shared-namespace, but it is an example of the security special case not working.
 * wallyworld_ reboots
<lifeless> jamesh: hi; I don't suppose you've had a chance to try glueing oops and u1 together again ?
<jamesh> lifeless: sadly not.
<lifeless> no worries
<lifeless> btw, I have a native twisted oops config, if that is useful
<lifeless> should be publishing the code today
<jamesh> the python-oops bug I filed came from my chasing down a bug in the wrong direction because of similarly named exceptions
<lifeless> yeah
<lifeless> it makes total sense
<lifeless> we did similar to testtools output
<jamesh> Python's DB-API encourages lots of similarly named exceptions, including one called "Error"
<lifeless> \o/
<lifeless> bbiab
<jamesh> the spec could really have benefited from a stdlib module for all the adapters to build on top of
<rsalveti> sorry asking here, wasn't able to find at launchpad, but is there a bug already on the code import about the ability to only import trunk when importing a git tree?
<rsalveti> would like to also be able to import a git branch
<rsalveti> I know it's probably because of a limitation of bzr-git or similar, but would like to also see a bug for that at launchpad
<rsalveti> guess jelmer should know this :-)
<rsalveti> https://answers.launchpad.net/bzr-git/+question/171522
<rsalveti> cool, seems the support is already at bzr-git trunk
<wgrant> rsalveti: You can actually import them in LP now.
<wgrant> rsalveti: Since a week or two ago.
<wgrant> It's not documented or obvious yet, however.
<rsalveti> wgrant: oh, ok, any special syntax?
<wgrant> eg. https://code.launchpad.net/~wgrant/mochiweb/R12B
<wgrant> Add ,branch=whatever to the end of the URL.
<rsalveti> wgrant: oh, awesome :-)
<rsalveti> I love you guys, launchpad rocks
<wgrant> There'll hopefully be some UI for it soon, but at least it's possible now :)
<rsalveti> just when I needed \o/
<rsalveti> we'll be doing CI and daily builds of the linaro components
<rsalveti> and they are mostly tracked using git
<wgrant> Excellent.
<rsalveti> wgrant: thanks
<nigelb> lifeless: Hey! You asked me to ping you today for a project skeleton and sketch, etc :-)
<nigelb> wgrant: So now, everything that touches db need to have the pre-requisite branches deployed everywhere before landing?
<wgrant> nigelb: Sadly not yet. mizuho, cocoplum and germanium still need fixing. mizuho is having other work done to it on probably Monday, which means we should be able to upgrade it then.
<wgrant> (it's awkward because it's not HA yet, so we can't safely restart it while LP is up)
<wgrant> The work on Monday should make it HA.
<nigelb> \o/
<wgrant> It was meant to be done last night, but, er, things did not go smoothly.
<nigelb> heh
<nigelb> Oh well, time to head to work. Laters.
<lifeless> nigelb: I did
<lifeless> nigelb: uhm, give me half an hour or so
<StevenK> wallyworld: Wow, no underscore.
<wgrant> Heh
<wallyworld> yeah, it ran away
<StevenK> wallyworld: No green animated awesomeness for that branch.
<wallyworld> ?
<StevenK> wallyworld: But I will hit you up on Monday about it.
<wallyworld> you mean the latest bug confirmation work
<StevenK> confirming unsubscribe on private bugs, yes.
<wallyworld> cool
 * wallyworld hates debugging @^@$@%$^ doc tests :-(
<rvba> Morning.
<wallyworld> g'day
<rvba> Hey, how's it hanging wallyworld? ;)
<wallyworld> rvba: shit. ec2 gave me the finger and now I've got to find an error in a doc test :-(
 * rvba hates doc tests too.
 * wgrant stabs Storm.
<wallyworld> what did Storm do to you?
<wgrant> It's generating UPDATE queries with = NULL instead of IS NULL.
<wallyworld> wgrant: it also does that for =/is True
<rvba> wgrant: I've got a question for you: I have four dependent branches: A -> B -> C -> D; a certain wgrant reverted the whole thing (and he was right) ...
<wgrant> Hmmm, I guess I can't exactly use a nullable field in a Storm primary key anyway.
<rvba> Now I've created C': A -> B -> C'
<rvba> But when I try to land it, it gets merged with devel which has A and B reverted so ec2 gives me the finger (like wallyworld says ;))
<wgrant> rvba: What we normally do in that case is create a branch to revert the revert (bzr merge -r$(revert)..$(revert-1) .), then develop the fix on top of that.
<rvba> I could simply merge devel, recreate A' (similar to A) and B' (similar to B) but maybe there is a better way to do this?
<wgrant> Or you could probably merge C' onto the branch with the reverted revert.
<wgrant> That would probably work.
<rvba> If IÂ could avoid having to create new MP for thing that have been approved already it would be nice ...
<rvba> things* even
<rvba> wgrant: I think that since all the changes from A, B, C and D have been reverted all at once, I can't revert the revert properly...
<wgrant> rvba: Ah. In that case, cherrypick the A and B merges from devel back on top of your branch.
<rvba> wgrant: Okay, I'll do that, thanks for your help...
<wgrant> That'll hopefully work. I haven't had cause to partially unrevert a multi-branch reversion before :/
<wgrant> If it doesn't, I will poke further.
<rvba> Seems all the changes where committed as one commit in devel.
<wgrant> Ah, of course, so they were.
<rvba> I tried to cherry pick from my branch (as opposed to devel) but something seems to be wrong with that ...
<wgrant> That'll probably go wrong if you merged devel into your branch during its development.
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
<rvba> I did merge devel during its development.
<rvba> Let see if I can create a simple patch from the dev branch and apply it manually to the new branch then.
<wgrant> Indeed, you could do a diff -rancestor:../devel to get the patch.
<rvba> I've done a patch using cherry picking (i.e. specifying the revisions) but this seems to work.
<lifeless> wgrant: what evil are you working on?
<wgrant> lifeless: PillarObserver (currently just for optimising display and revocation of legacy restricted disclosure, but in the future it will probably be used to grant non-legacy observer privs, I guess)
<lifeless> how does it optimise the legacy stuff?
<wgrant> lifeless: My current theory is that access to private artifacts will depend on holding either full Observer privileges, or Restricted Observer and a subscription.
<wgrant> We need to be able to efficiently show who has access to private artifacts on a project.
<wgrant> And revoke that access.
<lifeless> sure
<lifeless> I humbly suggest that you want a fact table here
<lifeless> rather than doing it in your online processing table
<lifeless> we can talk on monday if that doesn't make sense
<wgrant> My online processing table?
<lifeless> the live table where you change things
<lifeless> the one optimised for letting users search bugs etc
<lifeless> -> the one that actually grants access
<wgrant> I have a table PillarObserver(pillar, person, permission), which subscribing someone to a bug currently adds a RESTRICTED permission to, if it doesn't already exist.
<wgrant> It's not flattened, so you do have to join against TP, but that seems to be fast enoguh.
<lifeless> wgrant: you've shoved real world data sizes into it ?
<lifeless> joining against TP should be fine
<wgrant> Attempted to, but it's really hard to say what is a representative DB.
<wgrant> Right, that's what I thought.
<wgrant> It should be a small enough set of useful rows that the join should work fine.
<wgrant> Unless someone is in 100000 teams.;
<wgrant> In which case we might be in trouble.
<lifeless> Now, IIRC there was a requirement to show the artificats flk have access to
<wgrant> Yes.
<lifeless> 2K is the largest in-team set at the moment.
<wgrant> I plan to initially use bugsummary to display counts, possibly even on the listing.
<wgrant> Then once we drill down list subscriptions.
<lifeless> that might be shiny
<wgrant> We should really check bugsummary's consistency at some point.
<lifeless> I keep meaning to file a bug saying that its either confusing output, or wrong - oem let me know its off by 25% in some pages
<lifeless> which is -way- more than my simulations predicted
<wgrant> OEM is a bit pathological in a lot of cases, though.
<lifeless> disclosure will help a lot
<wgrant> Yeah.
<lifeless> wgrant: I've seen odd numbers myself, I just can't remember where
<wgrant> We can hopefully mostly summarise on privacy policy.
<wgrant> WIth only exception subscriptions throwing everything off.
<wgrant> And private projects should have very few of them.
<wgrant> I've tried various different strategies here, and I think this approach is going to be the simplest, most efficient and most future-proof.
<lifeless> will there be a blacklist facility ?
<wgrant> Others probably won't outlast legacy disclosure without a complete redesign, and/or run into what wallyworld was trying to do earlier.
<wgrant> ie. an explicit DENY?
<lifeless> e.g. 'foo has restricted, but thats wrong, reject them -> leads to them not being addable again'
<lifeless> at least not implicitly via subscriptions
<wgrant> So, at present I'm emulating legacy disclosure. Subscribing someone to a bug adds a Restricted permission if they don't already have at least that. I imagine in future that will probably not implicitly happen, or projects will be able to reject subscriptions who don't have a permission explicitly added.
<wgrant> We can't sensibly enable the revocation functionality until we've worked out how the new artificat visibility UI will work, but I don't want to design a legacy disclosure viewing model that won't be future-proof.
<lifeless> sure
<lifeless> will po be part of bug queries ?
<mrevell> Hi!
<wgrant> lifeless: Yes.
<wgrant> lifeless: I initially tried to avoid that.
<wgrant> lifeless: But then realised that it will have to be in future anyway.
<wgrant> lifeless: For full observer roles.
<wgrant> It should be quick enough to join through that and TP that it won't be too slow. I have tried on reasonably large datasets, but who know how it will perform in the wild.
<wgrant> FF FTW.
<adeuring> fgood morning
* leguin.freenode.net changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 256 - 0:[#########]:256
<StevenK> Dear Freenode, stop sucking.
<rvba> StevenK: Hi ... and congrats on the JS branch! ;)
<lifeless> nigelb: doing your thing in 5
<StevenK> rvba: Thanks, couldn't have done without you. :-)
<rvba> StevenK: Np ;)
<bigjools> morning all
<nigelb> lifeless: \o/
<lifeless> bigjools: http://pypi.python.org/pypi/oops_twisted
<nigelb> I'm at work, so my response times are horrible :|
<bigjools> lifeless: yay
<lifeless> bigjools: I'm just adding its tarball to the download cache for you
<nigelb> Morning bigjools!
<bigjools> lifeless: no Launchpad download? *cough*
<bigjools> lifeless: anyway that's awesome, thanks
<bigjools> hello nigelb
<lifeless> bigjools: it should be straight forward to use
<bigjools> lifeless: yeah we talked about that already, sounds great
<stub> bigjools: So does the db permissions approach I'm taking in https://code.launchpad.net/~stub/launchpad/distinct-db-users/+merge/76535 , or do you still think it will be painful and things will break?
 * bigjools looks
<stub> security.cfg bits, where I'm just declaring the distinct db users as aliases of a more powerful group
<bigjools> stub: I think it's fine. ideally we'd have role groups, but I guess that would be painful to do now
<bigjools> I already did the same trick for packagecopyjob
<stub> bigjools: I expect if someone can think of a good name we just rename 'fiera', 'uploader', 'queued' etc. to start with and stick with them as the roles.
<bigjools> well I was thinking more granular
<bigjools> because queued, for example, closes bugs
<stub> bigjools: Yes, but that takes time as you say :-)
<bigjools> yes :)
<nigelb> lifeless: were you able to do that thing for me? :)
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 256 - 0:[#########]:256
<lifeless> nigelb: download cache upload just finished
<lifeless> bigjools: committed to the cache for you
<bigjools> lifeless: ta
<bigjools> lifeless: why did you call it oops_twisted on pypi?
<lifeless> thats the package
<lifeless> import oops_twisted
<wgrant> stub: Is it deliberate that LP defaults to serializable isolation, while things that call initZopeless default to read committed?
<bigjools> yes, but we have python-oops
<lifeless> bigjools: http://pypi.python.org/pypi/oops
<bigjools> ok
<stub> wgrant: yes
<wgrant> stub: Some scripts don't call initZopeless, so they end up serializable :(
<stub> wgrant: need to fix that. hang - on phone
<bigjools> lifeless: I am writing tests for my txlongpollfixture and my buildout test runner doesn't have the path to the executable but the interpreter does, any idea how I can fix it?
<bigjools> so Popen("bin/txlongpoll") works inside bin/py, but not in a test
<lifeless> whats cwd in the test ?
<bigjools> it gets changed to the tempdir
<bigjools> on the Popen call
<bigjools> but removing it makes no difference
<lifeless> so . isn't in your PATH, you'll need to use the abspath to the executable
<bigjools> lifeless: how does that work when I am using an egg?
<bigjools> I don't know where it is
<bigjools> only buildout does
<lifeless> erm, I'm not sure offhand
<lifeless> sorry, ELOCAL
<stub> wgrant: Can you point me at a script that doesn't call initZopeless?
<stub> I thought this was all handled in the LaunchpadScript base class
<stub> And everything was supposed to use that (or LaunchpadCronScript)
<wgrant> stub: All LaunchpadScripts do it, yeah. But some stuff isn't a LaunchpadScript.
<wgrant> eg. I ported a dozen scripts to LaunchpadScript on Sunday, because most of them called initZopeless directly.
<wgrant> But I also ran into a couple that I can't remember right now, that call execute_zcml_for_scripts but not initZopeless.
<wgrant> poppy-sftp seems to be the only thing left.
<wgrant> There are some others, but they are short-lived and rarely run on prod.
<wgrant> stub: I think it's somewhat unfortunate that ISOLATION_LEVEL_DEFAULT isn't actually the default any more, though.
<wgrant> Perhaps now that just about everything uses LaunchpadScript it will be less bad.
<stub> wgrant: The reason for using read committed over serializable is that if you use serializable you will randomly get serialization exceptions and are expected to deal with them.
<bigjools> for my sanity, if I add a new dependency in launchpad-developer-dependencies it's not going to affect  buildbot is it?
<stub> wgrant: So a foot gun, but scripts only hurt themselves.
<wgrant> bigjools: It won't automatically, but it will when somebody next tries to update them.
<wgrant> bigjools: Same with ec2.
<wgrant> stub: Right.
<wgrant> stub: I'm just strategising around saner script DB config APIs.
<bigjools> wgrant: why is pdr showing script warnings this morning?
<wgrant> bigjools: was killed for fastdowntime.
<bigjools> how long is it taking to run now?
<wgrant> 1.5 hours still.
<bigjools> :/
<bigjools> 8 mins to 1.5h is not goo
<bigjools> d
<wgrant> Indeed not, but we now have everything close enough to fixed that I think we know everything that is wrong.
<wgrant> jelmer: What have you done to https://code.launchpad.net/~jelmer/wireshark/svn?
<wgrant> jelmer: It seems rather impressively broken.
<bigjools> wgrant: can you review: https://code.launchpad.net/~julian-edwards/meta-lp-deps/add-rabbit-management/+merge/76710
<wgrant> bigjools: This needs some thought.
<wgrant> bigjools: It will make LP uninstallable on oneiric.
<wgrant> And launchpad-messagequeue-dependencies uninstallable in the DC.
<bigjools> the latter easily fixed
<bigjools> why the former?
<bigjools> (this is a losa request BTW)
<wgrant> Because oneiric has rabbitmq-server 2.5.0
<wgrant> So rabbitmq-management 2.3.1 won't install.
<bigjools> hmm
<bigjools> this is why I asked you to review this :)
<stub> So given we should all have switched to Oneiric per policy...
<bigjools> wgrant: I am at a loss. I think the only way forward is to package the 2.5.0 plugin but ....
<jtv> wgrant: are we also quite quite sure that nothing and nobody will mark an SPPH as Deleted after Gina is done importing the package but before its domination run?
<wgrant> jtv: Nobody is meant to have privileges to do that. And even if they do, what's the worst that happens? It gets dominated 6 hours late.
<jtv> wgrant: unless the number of versions increases to offset the decrease in Published publications.
<wgrant> bigjools: I think so too. Which is why I was saying a week or so ago that the way forward is 2.5.0 or possibly even 2.6.0.
<bigjools> wgrant: yes, and I agreed with you, but then I found out what a total bitch it is to package that stuff
<bigjools> oneiric is getting 2.6.0
<wgrant> It's actually really simple!
 * wgrant calls StevenK in for backup.
<bigjools> wgrant: well you said it wasn;t :)
<wgrant> bigjools: For a packager it is simple :)
<bigjools> plugins requiring the parent's Makefile
<bigjools> odd version requirements
<wgrant> Sure, there are a couple of messy bits, but those are already solved.
<bigjools> FSVO solved :)
<bigjools> but it'll do
<bigjools> so can I invoke the Antipodean Packaging Brigade?
<wgrant> Damn, you're not Soyuz any more, so I can't say you should finally learn packaging :(
<bigjools> you can still say that
<bigjools> it's not like I don;t want to
<bigjools> but $TIME .... :/
<bigjools> and I don't want to block this
<wgrant> Bah.
<wgrant> I'll see what I can do on Monday.
<wgrant> If the upgrades are trivial enough, it should only take an hour or two.
<wgrant> If they're not, I'll have to see.
<bigjools> we could ask someone in distro, if they are already packaging 2.6.0
<wgrant> That may also be a good option.
<bigjools> they had a FFe for it
<wgrant> Late!
 * nigelb waves
<wgrant> Evening nigelb.
<nigelb> Lazy Friday evening :)
<bigjools> packaged by Marc Cluet it seems
<wgrant> Sigh, their rabbitmq-erlang-client packaging is still stupid.
<wgrant> It installs both the extracted files and the archive containing all of them.
<StevenK> wgrant: Grab me on Monday and I'll do part of it too
<bigjools> thanks guys
<nigelb> bigjools: Starting work on longpoll? :)
<wgrant> Upstream provides reasonable 2.6.0 packages, so it's just a matter of updating the plugin infrastructure and getting the versions to match.
<bigjools> nigelb: a while ago
<bigjools> wgrant: oh, they've done packages?
<nigelb> bigjools: Can't wait to see it in production :-)
<bigjools> nigelb: we're also moving to a slightly different deployment model, so it's been a bit trickier than usual
<wgrant> bigjools: They provide a rabbitmq-server package which appears to be based on Debian's, or vice-versa.
<bigjools> but nothing for the management plugin?
<nigelb> Oh, how different is the deployment going to be now?
<wgrant> No.
<bigjools> balls
<bigjools> nigelb: SOA-based
<wgrant> Their deployment story for plugins is to download the .ez from the website and drop it in the system dirs.
<nigelb> Ah. Right.
<bigjools> lots of small microservices
<jelmer> wgrant: it's a bzr code import
<bigjools> which will be *awesome* when we can start splitting up LP itself
<nigelb> I'm writing one of those services :P
<wgrant> jelmer: Ah.
<jtv> wgrant: wanna review?  https://code.launchpad.net/~jtv/launchpad/bug-857155/+merge/76715
<wgrant> jtv: Looks good. Should we perhaps take this opportunity do some logging during domination?
<wgrant> jtv: We presently log two lines per published package; another one per package being dominated would be useful and only 50% larger :)
<jtv> wgrant: if you like.  I'm also preparing a post-branch with additional improvements (bulk-loading and a renaming), but logging could go into the original.
<wgrant> It should be a single line, so why not :)
<jtv> Well it's not _that_ easy.  The place where I'd most like to log this doesn't know the package name.
<wgrant> :(
<wgrant> Depends where you want it, I guess.
<jtv> wgrant: I've added some debug and debug2 logging: debug will give you the name and stats for a package being dominated; debug2 also says which packages it skips *and* what it does to each publication.  Pushing.
<jtv> In the follow-up branch I'll change the name of that domination method (because they no longer have to be âremovedâ versions) and add bulk-loading of the sprs.
<wgrant> jtv: That sounds like a good option.
<jtv> If you _really_ want, you'll be follow each step of the algorithm.
<bigjools> dogfood is going down for 2-3 days for DB refresh
<wgrant> Hm, that is awkward.
<jtv> Hmm maybe I should request a Q/A run of my branch on staging now.
<wgrant> Right when we need to QA gina!
<wgrant> But yeah.
<bigjools> staging FTW
<jtv> We knew dogfood would go down, and postponing it would just give us more grief next week.
<jtv> Yup.
<wgrant> We'll need to cowboy the config and get a partial archive onto there.
<wgrant> But we should try it.
 * jtv toys with idea of running old & new versions on staging & qastaging respectively, just so he can compare results
<bigjools> we need to shift onto staging more
<jtv> Och aye, we can't run gina's import there.
<wgrant> That debug2 logging looks marvellous.
<wgrant> Approvalised.
<jtv> Thanks.
<jtv> stub defined some extra debug levels, including âBLATHERâ
<bigjools> launchpad_dogfood=# drop database launchpad_dogfood;
<bigjools> muahahha
<wgrant> Will it let you do that with active connections?
<bigjools> what active connections.... :D
<wgrant> 21:58:26 < bigjools> launchpad_dogfood=# drop database launchpad_dogfood;
<nigelb> bigjools: You need to work on that evil laugh :D
<lifeless> bah, bad oops_wsgi 0.0.4 tarball.
<bigjools> it's only semi-evil
<lifeless> silly setuptools manifest handling
<bigjools> you'd think that typing a ticket number into the twisted trac search, with only "tickets" selected, would find the exact ticket first.  But oh no.
<lifeless> jamesh: oops-wsgi had a bad tarball - stale MANIFEST, I've done a 0.0.5 to fix.
<lifeless> nigelb: ok
<nigelb> lifeless: "free-er"? :)
<lifeless> lp:js-oopsd is populated
<nigelb> lifeless: Thanks! Looking now
<lifeless> no tests, and nothing useful captured, but it should be within reach rather than being from a standing-stat for you
<nigelb> wow
<lifeless> there is some science fiction in the README etc, so read carefully - you'll need to fill those bits out :)
<nigelb> lifeless: Thanks, that's awesome. You just did all the bits I had no clue (buildout, etc), and I there's boilerplate wsgiref code \o/
<lifeless> to experiment
<lifeless> run it with
<lifeless> bin/py -m js_oopsd.main
<lifeless> and use your browser to visit the url it prints
<nigelb> okay@
<lifeless> then look for a directory like 2011-09-24
<nigelb> s/@/!
<lifeless> in that will be OOPSes
<lifeless> one for each request your browser made
<nigelb> cool!
<lifeless> so you can see its -very- shallow :)
<bigjools> lifeless: so, oops logging added to longpoll already.  Nice and easy!
<lifeless> bigjools: worth the wait ?
<bigjools> lifeless: of course
<lifeless> :P
<bigjools> :)
<lifeless> ok, time for bed
<lifeless> gnight all
<nigelb> g'nite lifeless
<bigjools> lifeless: so one more question!
<lifeless> heh, nick of time!
<bigjools> lifeless: if I add more log observers will it affect any of this?
<bigjools> or vice-versa
<bigjools> since Twisted bug 638 got fixed I can add a proper rotatable log file now
<lifeless> twisted dispatches all log items to all log observers
<_mup_> Bug #638: Incorrect link in the bug's task listing <lp-bugs> <Launchpad itself:Fix Released by bradb> < https://launchpad.net/bugs/638 >
<bigjools> poifect
<bigjools> ta
<lifeless> bigjools: however
<bigjools> you may sleep now
<lifeless> bigjools: I suggest using the OOPSObserver fallback parameter
<lifeless> to point at the rotatable log file observer, rather than having it as a direct observer.
<bigjools> right
<lifeless> this will mean you get the oops ids logged to the log file, rather than having the tracebacks in that file and no oops id
<lifeless> ta-ra
<bigjools> right
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 256 - 0:[#########]:256
<bac> hi adeuring, looks mighty quiet here
<adeuring> morning bac, yes, is very quiet today
<StevenK> Are you two hunting MPs?
<stub> jtv: I can't take credit for BLATHER - that is brought over from Zope2 to Zope3. I just downgrade its integer value :)
<jtv> Reviewer wanted, while I go off and have weekend!  https://code.launchpad.net/~jtv/launchpad/post-857155/+merge/76733
<nigelb> heh
<nigelb> not very tempting offer :P
<jtv> Why not?
<adeuring> morning deryck:, could you please run this query on staging: https://pastebin.canonical.com/53295/ ?
<deryck> adeuring, sure.
<adeuring> thanks!
<deryck> adeuring, https://pastebin.canonical.com/53296/ (run twice to see with/without cache)
<adeuring> deryck: cool, thanks!
<deryck> np!
<mrevell> Hey deryck, do you have time for a ten minute call this afternoon?
<deryck> mrevell, sure.  you want to calendar a time that works for you?
<adeuring> deryck: just to be a bore sur, could also try this one: https://pastebin.canonical.com/53297/ (should be sloooow)
<deryck> adeuring, sure
<mrevell> deryck, thanks, will do
<deryck> adeuring, https://pastebin.canonical.com/53298/
<adeuring> deryck: thanks!
<deryck> np!
<deryck> adeuring, abentley -- coming. just running a couple minutes behind, sorry.
<deryck> adeuring, abentley -- https://answers.launchpad.net/launchpad/+question/172089
<deryck> adeuring, hey.  see recent mails from me about that question, where I cc'ed you.
<bigjools> MP diffs are slow today
<adeuring> deryck: ack
<deryck> adeuring, if it ends up being a timeout bug, or something that needs coding to fix ;)  we should pull it back to the next laneâ¦.
<deryck> adeuring, and let whoever gets free first deal with it.  since there's the other escalated bug already in next.
<adeuring> ok
<flacoste> gary_poster: you are not really fixing bug 724609, right?
<_mup_> Bug #724609: Rewrite lp.client tests using yuitest <build-infrastructure> <qa-ok> <Launchpad itself:In Progress by gary> < https://launchpad.net/bugs/724609 >
<gary_poster> flacoste, I was intending to soonish, yes, as an example of using the new YUI XHR tests.
<bigjools> gary_poster: hello, I have another buildout question for you if you have 5 minutes?
<mrevell> deryck, Skype or Mumble?
<gary_poster> In fact, I was about to include that in my announcement flacoste, so if that's bad somehow lemme know. :-)
<flacoste> gary_poster: cool, but it's not fixed yet (as qa-ok makes me believe)
<flacoste> gary_poster: or did you just rewrite the tests already
<deryck> mrevell, let's mumble.  give me 2 minutes.
<mrevell> k
<gary_poster> flacoste, I have to say qa-ok for incremental steps.  I landed with --incr because the branch introduced the infrastructure needed to write the test, but then when you do that you still have to assert that you have qa'd your incremental changes (I thought I used --no-qa actually, but that's a separate issue)
<flacoste> gary_poster: ok, makes sense
<flacoste> gary_poster: and i'm very happy that you are fixing this bug!
<gary_poster> flacoste, cool :-)
<gary_poster> bigjools, sure
<bigjools> gary_poster: thanks you might be my saviour again.
<gary_poster> :-)
<bigjools> gary_poster: I have a txlongpoll egg, which build the txlongpoll server. I have another egg, txlongpollfixture which depends on the former
<bigjools> gary_poster: I am struggling to work out how the fixture can find the executable that the first egg builds, so it can run it up
<deryck> mrevell, orange 1 o 1 when ready
<gary_poster> bigjools, ah fun.  Mm, if I understand you, you may have to use setuptools APIs to do that the "right" way.  The "wrong" way might be easy: it might be in the egg, in EGG-INFO/bin.  Another alternative is to have the fixture call the code that the executable "fronts," if that works for you.
<bigjools> gary_poster: we discussed the wrong way earlier, it could get messy depending on what else builds it I think. I'm not sure I understand the 3rd alternative there though, can you expand?
<bigjools> (bearing in mind we need to Popen the executable)
<gary_poster> bigjools, typically you create executables by simply pointing setup.py at a function and saying "make a bin for this function and call it ${whatever}."  What you can do then in this case is set up your module to be run as __main__ (IIRC) and run "${executable} -m txlongpoll.module_with_your_executable ...options..."
<gary_poster> if they are equivalent that you are good to go
<bigjools> gary_poster: have you got an example of that?
<gary_poster> bigjools, :-) I am looking for the pertinent docs, 1 sec
<jcsackett> is anyone else regularly getting rabbitmq timeouts when trying to run launchpad.dev?
<bigjools> gary_poster: is this the entry_points thing I can see in LP's setup.py?
<gary_poster> bigjools, that's how you typically make an executable, yes.  So, in txlongpoll's setup.py, you would define a binary there.  If it were installed via something like setuptools in a virtualenv or real Python, the bin would be created.
<gary_poster> Then for code that uses it as a library, you would define the same entry_points thing in our setup.py or in our buildout.cfg.  That entry point would also be run in the associated module's def __main__ (http://docs.python.org/using/cmdline.html#cmdoption-unittest-discover-m) so that code like your fixture would not have to find (or even have!) the binary, just run {executable} -m {module} {any other arguments that you
<bigjools> gary_poster: it's not a library
<bigjools> it's a standalone daemon
<bigjools> I already have it building from from a buildout recipe
<gary_poster> bigjools, ok, but the code can still be imported, right?
<bigjools> not easily
<bigjools> it's twisted
<gary_poster> bigjools, ohhhh, so they don't play the normal Python games?
<gary_poster> :-(
<bigjools> not in the slightest
<gary_poster> ah :-(
<gary_poster> um
<bigjools> you have to put a plugin in a special place
<bigjools> then run twisted with the right args
<bigjools> we'll have this same problem when we eventually make the librarian a SOA part
<gary_poster> bigjools, well, then setuptools may not help you either.  what's an example of the command you want to run?
<bigjools> gary_poster: https://bazaar.launchpad.net/~julian-edwards/txlongpollfixture/FIRST/view/head:/txlongpollfixture/server.py
<bigjools> gary_poster: see the _start() method
<bigjools> line 73 onwards
<bigjools> if we could get the bin directory in the PATH then we're golden
<bigjools> or even the egg directory
<gary_poster> bigjools (I have a call in 20, fwiw.  can return to this afterwards.)
<gary_poster> actually about 15 now
<bigjools> gary_poster: np, thanks
<gary_poster> I'm going to go look at how you are creating bin/txlongpoll...
<bigjools> script recipe
<gary_poster> OK so txlongpoll=twisted.scripts.twistd:run , which is identical to the twistd in setup.py except it has its own custom path that includes the txlongpoll egg.  So...it really is an arbitrary binary from the perspective of other code.  It could be running a different Python version even.
<gary_poster> bigjools, I don't see an opportunity for magic snarfing here.  If you don't want to tie txlongpollfixture to the LP build (and I would understand not wanting to), you need to make this something that is configured--for instance, the fixture requires you to inform it where the binary is.
<gary_poster> Once you do that, you can have Launchpad either hardcode the binary name/location in the test fixture initialization, or do buildout tricks.  I'd be inclined to do the former, relying on config's ability to easily get you LP's root, and then hardcoding 'bin' and 'txlongpoll'.
<bigjools> gary_poster: yeah, I was considering just ensuring that the person using the fixture has the executable in $PATH
<bigjools> yeah, hardcoding bin/txlongpoll was the original plan, I figured that buildout might set the path. I was wrong :)
<StevenK> What's wrong with figuring out your current path with os.path.abspath(os.path.dirname(__file__)) ?
<bigjools> because it's not necessarily always in the same relative place to the executable
<bigjools> it depends how the egg was built
<bigjools> the dependent egg I should say
<bigjools> but I might be wrong, I had discarded this way earlier, maybe it was too hasty
<gary_poster> bigjools, eh, there's a million ways for that kind of config. :-) but yeah, I'm afraid it does need to be config, AFAIK.  buildout can tell you what has been generated, particularly while it is generating it, but since this is really buildout generating a separate binary with a separate context (that could even be in another language as far as the main LP code is concerned)
<bigjools> indeed
<bigjools> StevenK: actually thinking about it that definitely won't work because the bin/ directory can move around
<bigjools> gary_poster: ok I will set the PATH in my fixture's tests so at least they work, then whoever uses the fixture needs to set the path as well
<bigjools> thanks for looking
<gary_poster> bigjools, does the txlongpollfixture depend on txlongpoll, and does/will LP depend on txlongpollfixture?
<bigjools> gary_poster: yes, exactly that (will)
<gary_poster> bigjools, in that case, all the nice separation you've done in buildout is a bit for naught
<bigjools> gary_poster: blame lifeless!
<gary_poster> because LP will still have txlongpoll as a dependency
<bigjools> well it was to prevent txlongpoll having a dep on the test fixtures
<gary_poster> Does the fixture really need txlongpoll as a dependency?
<bigjools> and this is only for the dev environment
<bigjools> in prod we'll run it differently
<gary_poster> ...
<bigjools> prod doesn't need the fixture
<gary_poster> yeah, I understand that part.
<gary_poster> So...
<adeuring> deryck: to be a bit more sure, could you try this query: http://paste.ubuntu.com/695674/ ?
<gary_poster> This is maybe a discussion for another forum, but just to see if I understand
<deryck> adeuring, sure.
<gary_poster> bigjools, txlongpollfixture is needed to test txlongpoll within itself *and* needed for LP to test txlongpoll?
<gary_poster> I mean, test the use of txlongpoll?
<gary_poster> What I'm getting at is this:
<bigjools> gary_poster: txlongpollfixture is not needed to test txlongpoll; it's just a way of starting it for other tests and for "make run"
<gary_poster> bigjools, got it.  So, actually, it never imports txlongpoll, right?
<bigjools> nope
<bigjools> just starts the twistd daemon up
<gary_poster> bigjools, but it has a Python egg dependency on txlongpoll even though it never imports it?
<bigjools> yeah that does sound wrong :)
<bigjools> I did it for convenience so that the egg gets built
<gary_poster> bigjools, yeah, so I suggest breaking that dependency
<bigjools> ok
<bigjools> although
<gary_poster> because that's what we will need for other similar microfixtures, particularly those not written in Python
<gary_poster> microservices I mean
<bigjools> that will make it harder to make the txlongpollfixture tests to work
<gary_poster> bigjools, maybe make it a test dependency?  That should be easy with or without buildout
<bigjools> we need a general solution for PATH with microservices
<bigjools> ah yes, I can do a test dep
<gary_poster> bigjools, you don't really mean PATH you mean bin, right?
<gary_poster> I mean, PATH is one mechanism for communicating bin
<gary_poster> the location of the bin
<bigjools> I mean a way for these services to get started without knowing where they live
<gary_poster> yeah
<bigjools> otherwise the local .dev will be a nightmare
<bigjools> we just want to be able to type make run and have it start stuff
<gary_poster> that has to be configuration IMO, but we can certainly make that configuration easy some how
<bigjools> we could put bin in the path
<gary_poster> bigjools, yeah, sure, my point is simply that you are framing the problem in terms of your current solution, AFAICT.  no big deal.  I need to have my call :-)
<bigjools> gary_poster: I guess I am, yeah
<bigjools> enjoy, thanks for the help
<gary_poster> welcome bigjools
<deryck> adeuring, taking a bit, sorry.  but I'm getting the results now.
<adeuring> deryck: np
<sinzui> jcsackett, I might loose power in a few minutes. The rain is torrential.
<jcsackett> sinzui: i am sorry to hear that, do you want to chat now in case you can't later, and we'll just accept the risk of sudden disconnect?
<sinzui> sure
<rsalveti> bigjools: hey, any news when we'll be able to create the ubuntu-leb derived distro?
<rsalveti> at production
<bigjools> rsalveti: you can do it now, I was holding off telling you because there's no Apache set up yet to make the archive available
<rsalveti> bigjools: well, guess we can create it now and set up apache later
<bigjools> there's an RT for it
<rsalveti> not critical yet but I'd like to get it going
<adeuring> bac: fancy a a review of an MP with a short diff? https://code.launchpad.net/~adeuring/launchpad/bug-739052-11/+merge/76772
<bac> adeuring: surely
<bac> adeuring: nice, r=bac
<mrevell> Night all
<nigelb> gary_poster: YUI XHR tests sound neat :-)
<bigjools> hey bac, can I poke a review your way please?
<bac> bigjools: shirley
<bigjools> bac: https://code.launchpad.net/~julian-edwards/txlongpollfixture/FIRST/+merge/76777
<bac> bigjools: i was about to grab a late lunch, though.  you in a hurry?
<bigjools> it's a new standalong project
<bigjools> bac: no it can wait, I will be eating dinner shortly
<bigjools> bac: I will be back on later
<bac> ok
<bigjools> cheers
<gary_poster> thanks nigelb :-)
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Critical bugs: 256 - 0:[#########]:256
<sinzui> bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/valid-targets-1/+merge/76781
<bac> sinzui: i do and will when i'm done with julian's
 * deryck goes offline for lunch
<bac> sinzui: i accidentally approved your MP without comment.  i'm updating it now.
<sinzui> cool, I saw the approve without a comment and thought that was odd
<bac> sinzui: hah, and i mispelled 'typo'
<sinzui> I can tell you were thinking of me
<bac> :)
<sinzui> I will fix the comment once I am certain I know what I meant.
<nigelb> sinzui: Hey, do you have a few minutes? I'd like to hear your take on bug 5283
<_mup_> Bug #5283: "Home page" vs. "Description" is misleading <easy> <lp-registry> <tech-debt> <ui> <Launchpad itself:Triaged by nigelbabu> < https://launchpad.net/bugs/5283 >
<sinzui> I do
<sinzui> I think I did a report in the past to see what would happen is we merged fields
<nigelb> sinzui: what was the eventual decision back then?
<sinzui> nigelb, We really want to remove .homepage
<nigelb> the whole field?
<sinzui> nigelb, for 2 years we have presented .homepage_content as the leading text to teamdescription
 * nigelb opens up psql
<sinzui> We want to update the db to concatenate the two fields
<sinzui> We want to rename teamdescription to description
<nigelb> Db patch \m/
<sinzui> so there is one field name description in Person for both teams and users
<nigelb> that makes sense
<nigelb> so, do you want me to talk to stub and lifeless to get started on a db patch for this.
<sinzui> The fixing the edit forms and templates is easy, but I think timing is difficult
<nigelb> I would first do the rename
<nigelb> and then land it and deploy
<sinzui> nigelb, I think there are three db tasks and one code task  to ensure no interuption to users
<nigelb> yeah
<sinzui> 1. create a description field in the schema
<sinzui> 2. garbo job to to fill it from homepage_content + \n + team description
<nigelb> what's a garbo job?
<sinzui> 3. update the index pages and forms to use the new field (do not show the old fields if the description is not empty).
<sinzui> 4. remove the old columns when the garbo job is complete
<sinzui> 5. remove the old field from the models and templates
<sinzui> nigelb, a garbo job is a db process used to clean up data while th production system is running
<nigelb> ah, I've read that somewhere
<sinzui> nigelb, while we call it garbo, we often co-opt it to populate new data
<sinzui> nigelb, there are more than 1,000,000 users and team. I expect the job needs a few days to complete
<nigelb> okay
<nigelb> I'll paste the list you just mentioned into the bug and start working :)
<sinzui> Please do.
<nigelb> Could give me a patch ID please?
<nigelb> s/ID/number
<sinzui> nigelb, only stub can give an id. When I write patches I end mine in a very high number
<sinzui> nigelb, use patch-2208-97-0.sql for development
<nigelb> The process says any launchpad team member can
<nigelb> I will, however, poke stub on Monday
<sinzui> oh, that's right, let me check the wiki page to claim a number
<sinzui> and I should not have recommend -0. this will be an incremental for the fast rollout
<nigelb> Yeah :)
<lifeless> norming
<sinzui> nigelb, i am getting the branch now. I will also get you real numbers for affected teams and person from staging afterwards
<nigelb> cool!
<nigelb> lifeless: Good morning! I see you still need caffeine :-)
<lifeless> I very rarely drink caffeine ;) - that was a deliberate switch
<sinzui> nigelb, 2208-90-1 is your number to add the column
<nigelb> lifeless: ha
<muffinresearch> Hi, I seem to have trouble entering text into some of the edit boxes on merge proposals in chrome in the last couple of days. This is chrome 14.0.835.186. When it doesn't work I can't type anything only pasting text works.
<matsubara> sinzui, https://bugs.launchpad.net/launchpad/+bug/857697 oops in the affiliation code for the person picker
<_mup_> Bug #857697: AttributeError: 'NoneType' object has no attribute 'owner'  get affiliation in person picker <disclosure> <oops> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/857697 >
<matsubara> I just triggered the oops in the bug report so that one is not available yet on oops-tools. the other one I added as an example can be seen there
<sinzui> thanks matsubara
<matsubara> np
<cr3> benji: hi there, might you have a moment for some lazr.restful assistance?
<benji> cr3: sure, what's up?
<cr3> benji: so, I'm getting this error when getting a collection of system objects: There isn't enough context to get URL information. This is probably due to a bug in setting up location information.
<cr3> benji: the problem is with the processor attribute of each system object which probably doesn't have a url information by defining the __parent__ and __url_path__ attributes
<cr3> benji: however, I don't know how to define the __parent__ attribute because a processor object doesn't know its system container. in fact, it's the other way around, system has a foreign key to the processor
<cr3> benji: ideally, I'd like the url for a processor to be /system/<id>/processor, not sure how to pull it off though
<benji> cr3: is this a Django app?
<cr3> benji: yep
<benji> cr3: if __parent__ isn't known statically, then you'll have to make it a property that looks it up
<cr3> benji: so, I wonder if System should inherit from TraverseWithGet, do something to the request object, so that Processor.__parent__ can then know the context
 * benji looks up TraverseWithGet
<benji> cr3: I don't see how that will help.
<cr3> benji: I just tried it, it doesn't help indeed :)
<benji> :)
<cr3> benji: not sure how a processor can know it's system container at runtime though
<benji> cr3: now, you could use something like TraverseWithGet that wraps the traversed object in a LocationProxy
<benji> LocationProxy is for objects that don't know their __parent__ or __name__, but someone else does and can wrap the object in a proxy that passes through all requests except for those two attributes
<benji> of course, you may need a DjangoLocationProxy because Django doesn't like __name__ as an attribute name
<cr3> benji: I think I've rolled my own to look something like: class SystemProcessor: delegates(IProcessor, context="processor"); def __init__(self, system, processor)...
<cr3> benji: however, whether I create something like a DjangoLocationProxy (good call about __name__, by the way!) or roll my own, I'm not sure how to apply that to the System class. For now, I have class System: processor = Reference(processor_id, Processor.id), ie I'm conveniently using Storm to reference the processor
<cr3> benji: instead, I believe I'd have to change that to class System: def _getProcessor(self): processor = Store.of(self).get(Processor, self.processor_id); return SystemProcessor(self, processor); processor = property(_getProcessor)
<benji> cr3: that's where you'd use something like TraverseWithGet, you have to hook some part of the traversal so that when you have both the system and processor "in hand" you can create your wrapper and tell it about it's __parent__ and __name__ (er, __url_path__)
<cr3> ... which seems like a lot of noise to do something apparently simple :(
<benji> cr3: that would work too, and it is a bit noisy
<cr3> benji: I'm not sure where I'd have both the system and processor "in hand" though, I'll try hooking here and there to figure it out and then fallback to making noise :)
<nigelb> I have a confusion with a db patch.
<benji> cr3: good luck
<cr3> benji: thanks man!
<nigelb> I'm comparing the diff of current.sql and newsampledata.sql. I see a new column transitively private :|
<nigelb> Is that supposed to happen?
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256
<bac> nigelb: you'll see new items unrelated to your change if previous branches added things to the db but did not generate new sampledata
<bac> nigelb: you can verify that it isn't your change but generating sampledata in a fresh branch from devel
<bac> you'll probably see the same additions
<nigelb> ah
<nigelb> so, I should probably mention this in my MP for stub I guess.
 * nigelb looks for culprits
<nigelb> bac: Thanks!
<bac> nigelb: np.
<wallyworld_> jcsackett: you still there?
<jcsackett> for some definition of "there". :-P what's up?
<wallyworld_> jcsackett: just to let you know, i had a chat to huw about the managing disclosure mockups
<wallyworld_> were are looking to use some static html with js hacked in and hosted on people.canonical.com
<jcsackett> wallyworld_: sounds good to me.
<wallyworld_> cool. i may on monday muck around with it a bit
<wallyworld_> we can chat about it a bit more next week, just wanted to keep you in the loop
<jcsackett> wallyworld_: is huw providing the static and we hack in the js, or is that part not yet figured?
<wallyworld_> jcsackett: he is still ramping up on what we need to do - i ran him through the functionality etc. i was going to do the html myself initially
<jcsackett> wallyworld_: dig.
<jcsackett> and now, i must attend to starting dinner. thanks for keeping me up to date. :-)
<wallyworld_> np. have a good weekend
#launchpad-dev 2011-09-24
<SpamapS> how often does staging get refreshed data from production?
<lifeless> weekly
<wgrant> SpamapS, lifeless: Approximately... but it's been probably 5 weeks now, and may well not happen this week either.
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 261 - 0:[#########]:256
#launchpad-dev 2011-09-25
<wallyworld_> wgrant: can you point me at the doco that covers the pop3/imap settings to pull mail from the qas mailbox?
<wgrant> wallyworld_: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox
<wallyworld_> wgrant: thanks
#launchpad-dev 2012-09-17
<StevenK> wgrant: Does @export_read_operation\n@operation_for_version('1.0') actually make sense? Since it seems it isn't exported for any of the versions
<wgrant> StevenK: The order matters. But I forget which way it should be
<wgrant> Why wouldn't it make sense?
 * StevenK has switched to exported(), rather than the above on the interface
<StevenK> Which seems to export it for 1.0 and beta, even though I say as_of='1.0'
<StevenK> Oh, hah. It's exported for 1.0 and devel, but not beta.
<StevenK> wgrant: I'm not sure how to tell lazr.restful to keep its grubby mits off devel. Do you think I should bother?
<wgrant> StevenK: What are you doing?
<wgrant> security_contact?
<StevenK> wgrant: Yeah
<wgrant> StevenK: Why's that an operation? Isn't it an attribute?
<StevenK> wgrant: I've now made it an attribute
<StevenK> wgrant: But using exported(TextLine(...), as_of='1.0') has it exported for both 1.0 and devel.
<wgrant> StevenK: Right, that's as_of
<StevenK> wgrant: Oh, is there a different argument I should be using?
<wgrant> ie. from
<wgrant> Try exported(TextLine(...), ('beta', None), ('1.0', None))
<wgrant> I think that will do what you want
<wgrant> (None means to use the default name; you can use a string instead to override it)
<StevenK> You think beta and 1.0? Rather than just 1.0?
<StevenK> wgrant: It doesn't love ('1.0', None) or (('1.0', None),)  :-(
<StevenK> Huh, it seems it wants None to be a dict instead
<StevenK> And using ('1.0', {}) has it exported for devel, beta and 1.0.
<wgrant>     :param versioned_annotations: A list of (version, param) 2-tuples,
<wgrant>         with more recent web service versions earlier in the list and older
<wgrant>         versions later in the list. The 'param' objects can either be a
<wgrant>         string name for the field in the given version (None means to
<wgrant>         use the field's internal name), or a dictionary.
<wgrant> So I had them the wrong way around, maybe.
<wgrant> I guess it's possible that just renames, rather than unexporting
<wgrant> Might have to check the source
<StevenK> [('1.0', None)] gives ValueError: need more than 1 value to unpack on the line for version, annotations in reversed(versioned_annotations):
<wgrant> StevenK: It's *versioned_annotations
<StevenK> Ah, so ('1.0', None) gives TypeError: 'NoneType' object is not iterable
<StevenK> ('1.0
<StevenK> Bleh
<StevenK> ('1.0', [None]) == ValueError: Unrecognized annotation for version "1.0": "None"
<StevenK> wgrant: Why does bugtasksearch raise ValueError everywhere? :-(
<StevenK> Surely this isn't good for the API
<wgrant> I didn't write it, just moved it. But ValueError probably maps to 400 Bad Request anyway
<StevenK>     self.assertEqual(400, response.status)
<StevenK> MismatchError: 400 != 500
<wgrant> :(
<StevenK> BugSearchError or something?
<StevenK> wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/proper-error-when-searchtasks-orderby/+merge/124609
<wgrant> StevenK: s/BugSearchError/InvalidSearchParameters/, perhaps?
<wgrant> BugSearchError is possibly the worst exception name ever
<StevenK> Fair point
<StevenK> wgrant: http://pastebin.ubuntu.com/1210554/
<wgrant> StevenK: Sounds sensible.
<adeuring> good morning
<StevenK> wgrant: Diff updated
<StevenK> wgrant: No +1 for me?
<wgrant> StevenK: You can't put that new test in an existing class?
<StevenK> wgrant: test_searchtasks_webservice.py is horrible
<wgrant> As it adding a new test class that is three times as long as the test :)
<StevenK> Like any good test class
<StevenK> wgrant: http://pastebin.ubuntu.com/1210571/
<StevenK> rick_h__: I don't like the idea of json_dump_information_types in registry/enums. But if it has to stay, you could uppercase it. You should also use 'in PRIVATE_INFORMATION_TYPES' rather than 'not in PUBLIC_INFORMATION_TYPES'
<stub> Is there a standard unix command that works like cat but can be set to accept input at a low baud rate?
<maxb> pv --rate-limit ?
<stub> I'll check it out, not installed by default
<StevenK> stub: pv - Shell pipeline element to meter data passing through
<rick_h__> StevenK: yea, open to location suggestions. I had it in app/utilities, jcsackett suggested either registry/utilities or left in enums.
<rick_h__> StevenK: and the whole method should be upper like a constant? not following that. Is there another method I can see as an example?
<StevenK> rick_h__: If it's a function, it's not an enum and doesn't belong there.
<rick_h__> StevenK: right, it's a function. I'll look at going with jcsackett's other suggestion and add a utilities.py in registry to stick it in then.
<StevenK> rick_h__: utils.py, services, librarian, and archive{publisher,uploader} use that already
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji- | Firefighting: - | Critical bugs: â
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: â
<rick_h__> benji: a small branch for your look when you get a sec please https://code.launchpad.net/~rharding/launchpad/move_into_utils/+merge/124678
<benji> rick_h__: sure
<deryck> rick_h__, I'm looking at the test timeout now.  Will let you know if I turn up something.  Or if I turn up nothing.
<rick_h__> deryck: ty
<sinzui> rick_h_, I removed the registry mailman doc tests, all 4000 lines. I will not break the build because of them again
<rick_h__> sinzui: hah, <3 hearing of dying doctests
<jcsackett> sinzui: did you send out my bugtracker branch to land? i see it's been set to merged, but i don't have any info about it and i didn't send it out.
<sinzui> I did
<jcsackett> sinzui: ok, thanks.
<sinzui> qastaging's db needs updating to qa work
<sinzui> deryck, I just confirmed your bugtraker fix is good
<deryck> sinzui, my bugtracker?
<sinzui> sorry deryck, I meant to type jcsackett, I just confirmed your bugtraker fix is good
<deryck> ack, np
<jcsackett> sinzui: dig, thanks.
<sinzui> jcsackett, do you have time to hangout to discuss criticals
<jcsackett> sinzui: i do.
<deryck> rick_h__, trying one more thing to see here, but if that bears no fruit, as the other things I've tried haven't, I at least have some suggestions.
<rick_h__> deryck: ok, thakns for the heads up
<jcsackett> sinzui: bug 629258 was where i saw it.
<_mup_> Bug #629258: Battery life estimation never comes around <apport-bug> <apport-collected> <i386> <maverick> <metabug> <natty> <patch> <DeviceKit-Power:Fix Released> <gnome-power:Invalid> <One Hundred Paper Cuts:Invalid> <System76:Fix Released> <Release Notes for Ubuntu:Fix Released> <Upower:Fix Released> <upower (Ubuntu):Fix Released> <upower (Ubuntu Maverick):Won't Fix> < https://launchpad.net/bugs/629258 >
<sinzui> jcsackett, https://bugs.launchpad.net/launchpad/+bug/393922
<_mup_> Bug #393922: Links to +edit and +appoint on a translation group are always visible <403> <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/393922 >
<deryck> yay, we're ready for deploy once the deployment report updates.
 * rick_h__ ducks
<cjohnston> sinzui: ping
<sinzui> hi cjohnston
<cjohnston> sinzui: I'm not quite sure what it is that sets the subscriber in my branch.. I see what the comment says, but I don't know what to remove.
<sinzui> Undo the launchpad.Admin changes because they have no-effect
<cjohnston> ok
<sinzui> The methods deal with editing, so launchpad.Edit is correct.
<sinzui> your text revision is fine
<cjohnston> sinzui: lifeless made the suggestion to make it to where only certain people could mark people essential, that way it still does the same thing with Summit that it used to do, just without the spam
<sinzui> cjohnston, per lifeless's comment, do we really needed essential if the summit site does not use it
<sinzui> jcsackett, well to do that, you would need to rewrite the python method in security.py
<cjohnston> was that for me?
<sinzui> cjohnston, yes, sorry
<sinzui> cjohnston, who should be permitted to state attendance is essential?
<cjohnston> So make it to where the drafter, approver, assignee and ~uds-organizers (or whatever team it is that is the meeting driver)
<sinzui> cjohnston, so Ubuntu's drivers cannot set this?
<cjohnston> I'm not against that, but I don't have a way to define that ubuntu-drivers can for UDS, and ~team-y can for Conference Y without using the team that is the meeting driver
<sinzui> cjohnston, and what of the series release manager?
<cjohnston> I'm fine with that as well, it just has to be able to scale across other groups that use summit... as in it can't be hard coded
<sinzui> I think you just want to remove the rule that lets the subscribe claim to be essential
<sinzui>     user.inTeam(self.obj.person) or
<sinzui> The method other says the project drivers, the series drivers and the spec roles can say who is essential
<cjohnston> ok, so essentially everyone that we already talked about
<sinzui> yes. I think the problem is that non-core developers were presuming they could be essential.
<sinzui> I think this change also works for all other projects.
<cjohnston> ok
<sinzui> cjohnston, test will fail with this change because very few use a driver or assignee to subscribe
<cjohnston> so then tests need to be changed too is what your saying?
<sinzui> cjohnston, I think you need to login as a different user to fix these tests:
<sinzui>   lib/lp/blueprints/doc/sprint-meeting-export.txt
<sinzui>   lib/lp/blueprints/stories/standalone/subscribing.txt
<cjohnston> I don't understand 'login as a different user'
<sinzui> cjohnston, the tests are not logged in as a driver or as a user in the specification's role when  setting essential,
<sinzui> per what we said above, the subscriber cannot set himself to be essential, so those tests will fail.
<sinzui> Either the test logs in as a different user, or the user used in the test must be made a driver or maybe the specification assignee
<cjohnston> I may be misunderstanding, but any user should be able to be set as essential, only some users can set people as essential... so I don't see why the user must be made a driver/assignee... atleast in sprint-meeting-export.txt it doesn't seem to be testing marking essential, only exporting it.
<cjohnston> ok.. i see line 41 in the subscribing.txt
<sinzui> cjohnston, you don't need a permission change then
<sinzui> you just want to change the text
<sinzui> the current tests say any user can mark themselves as essential
<cjohnston> right.. I see that now.. I don't want any user to be able to mark themselves essential.. i want certain users to be able to mark anyone essential
<sinzui> then remove the line I suggested from EditSpecificationSubscription, then change the tests to show that a only a special person can set the flag
<cjohnston> I did.. I just have to figure out how to rewrite the tests :-(
<sinzui> okay
<sinzui> cjohnston, Sample Person (~name12) is the maintainer of firefox so is an effective driver change
<sinzui> >>> browser.addHeader('Authorization', 'Basic carlos@canonical.com:test')
<sinzui> >>> browser.addHeader('Authorization', 'Basic test@canonical.com:test')
<sinzui> in subscribing.txt
<cjohnston> line 28?
<sinzui> yes
<cjohnston> ok
<sinzui> cjohnston, I see lots of failures
<sinzui> my suggestions are not enough
<sinzui> cjohnston, This diff shows the changes you can make to make the test pass. Carlos is subscribed, but non-essential. there is a essential is tested later in this same test using the right user: http://pastebin.ubuntu.com/1211548/
<sinzui> cjohnston, I think my change and your change combined is good enough to land
<cjohnston> ok.. cool.. thanks.. I'll apply it and push it up.
<sinzui> I will approve the Mp when you ping me cjohnston
<sinzui> I will land it too
<cjohnston> thanks
<cjohnston> sinzui: is that leaving the line 28 authorization as carlos?
<sinzui> cjohnston, yes
<cjohnston> ok
<cjohnston> sinzui: https://code.launchpad.net/~chrisjohnston/launchpad/part-essential/+merge/124559
<sinzui> cjohnston, change the permission back to launchpad.Edit because the community is still eidting
<sinzui> admin if for celebrity teams only
<cjohnston> sinzui: done
<cjohnston> thanks sinzui.. when do you think it may land?
<sinzui> 4 hours + 12 to clear buildbot We might release it tomorrow
<sinzui> cjohnston, is there a bug for this branch?
<cjohnston> sinzui: no, would you like one?
<sinzui> The has to be one...Lp will not accept the landing command
<cjohnston> ok
<cjohnston> sinzui: bug #1052130
<_mup_> Bug #1052130: Make assigning participation essential limited to certain groups of users <lp-blueprints> <Launchpad itself:In Progress by chrisjohnston> < https://launchpad.net/bugs/1052130 >
<sinzui> landing has started
<cjohnston> thanks
<cjohnston> sinzui: I have no idea what the failure email means, outside of that it failed
<sinzui> cjohnston, I don't think your branch is related to this.
<cjohnston> ok
<lifeless> flacoste: morning
<flacoste> morning lifeless
<flacoste> lifeless: not too early for a catch-up?
<lifeless> flacoste: woke anyway, and then realised DNS for my domains is cactus and no mail for the last 10 hours anyway... not a good look.
<lifeless> So, digging into that, no chance of going back to sleep.
<flacoste> lifeless: ok, we can catch up later in the week anyway
<lifeless> flacoste: let me get this ns snafu un snafu'd
<lifeless> so e.g. I can get Janes reply to mail from me :)
<lifeless> and then I'm happy to catch up
<lifeless> ok, mail flowing again.
<lifeless> Grah, hates such things.
<lifeless> flacoste: hi
<flacoste> hi lifeless
<lifeless> can you hear me
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<cjohnston> sinzui: ping
<sinzui> hi cjohnston
<cjohnston> I think I may have figured out why it's failing
<cjohnston> There seems to be one ( on line 655 of security.py, one ) on 656, and one ) on 657..
<cjohnston> I'm not seeing a second open (
<sinzui> run make lint
<sinzui> it will report such errors.
<cjohnston> lint is giving me an error about pocketlint not found.. hmm
<sinzui> cjohnston, push up a fix and if it makes sense I will land it
<sinzui> sudo apt-get install python-pocket-lint
<sinzui> It checks python, css html and javascript
<cjohnston> installing ty
<cjohnston> look at that, it passes now :-)
<cjohnston> sinzui: https://code.launchpad.net/~chrisjohnston/launchpad/part-essential/+merge/124559
<sinzui> fabulouso splendido.
<sinzui> off it goes
<cjohnston> :-)
#launchpad-dev 2012-09-18
<StevenK> wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-bfj-on-branch-delete/+merge/124828
<wallyworld__> StevenK: any reason not to update the cascade?
<wallyworld__> so everything is in one spot
<StevenK> wallyworld__: BFJ deals with far more than just TTBs
<wallyworld__> seems ok to me but i have limited bfj foo
<wallyworld__> StevenK: are there orphaned db records that need to be removed also?
<wallyworld__> from previous deletes?
<StevenK> There are.
<wallyworld__> i guess i bit of sql would do
<StevenK> Yeah, just reaching for mawson
<wallyworld__> r=me anyway
<StevenK> And trying to work out just how evil this query will be, since we need to pull in SourcePackageRecipeBuild, BinaryPackageBuild and TranslationTemplatesBuild
<wallyworld__> sounds just peachy
<StevenK> SELECT id FROM buildfarmjob WHERE id NOT IN (SELECT build_farm_job FROM packagebuild UNION SELECT build_farm_job FROM translationtemplatesbuild); is pretty close, but it will take a few eons on prod
<StevenK> :-(
<StevenK> All 3 columns are indexed and it's horribly slow
<StevenK> I think the UNION is not helping in the slightest
<StevenK> Ah, two Seq Scans. Thanks, postgres
<wgrant> StevenK: No, it's pretty easy
<wgrant> StevenK: Just query for BFJs of the TTBJ type that have no TTB
<wgrant> StevenK: Given the potentially very large number of BFJs that could be returned, it may be best to query the IDs directly.
<wgrant> store.find((BuildFarmJob.id,), ...)
<StevenK> wgrant: I tried (BuildFarmJob.id,), but I was not loved
<wgrant> That's not very helpful
<StevenK> I've not tossed it at ec2 yet, let me see
<wgrant> Also, I'm not a huge fan of that test. I'd prefer that the existing TTB deletion test be extended to check that the BFJs are gon
<wgrant> Checking that nothing shows up on +history is very indirect and likely to incorrectly pass for a multitude of other reasons.
<StevenK> I made sure it broke before I fixed it
<wgrant> Sure, but it could also pass because the builder doesn't show the build for some reason
<wgrant> It's not what you really want to test
<wgrant> It's about the most indirect integration test you could ever think of
<wgrant> There must be an existing test that TTBs are deleted, so just extend that to check that the BFJs are gone too
<wgrant> And delete your other new test.
<wgrant> This is an example of our terrible doctest style, except with unit tests instead.
<wgrant> "unit" tests
<wgrant> launchpad_dogfood=# SELECT COUNT(*) FROM (SELECT id FROM buildfarmjob WHERE job_type = 4 EXCEPT SELECT build_farm_job FROM translationtemplatesbuild) AS donotcare;
<wgrant>  count
<wgrant> -------
<wgrant>    303
<wgrant> (1 row)
<StevenK> What was the timing on that?
<wgrant> Slightly under 2s
<StevenK> So select that into a temp table and then DELETE FROM buildfarmjob WHERE id IN tempfoobar; ?
<wgrant> Temp table? Surely you jest.
<wgrant> launchpad_dogfood=# DELETE FROM buildfarmjob WHERE id IN (SELECT id FROM buildfarmjob WHERE job_type = 4 EXCEPT SELECT build_farm_job FROM translationtemplatesbuild);
<wgrant> DELETE 303
<wgrant> Time: 3874.078 ms
<wgrant> There'll be more on prod
<wgrant> But prod is also not running off 1rpm disks
<StevenK> Hahaha
<StevenK> Bleh, list(store.find((BuildFarmJob.id,), ...) is giving me a list of 1-tuples
<wgrant> StevenK: Yeah, you'll need to map it through attrgetter
 * wgrant wanders out to lunch for a while
<wgrant> Hm
<wgrant> http://paste.ubuntu.com/1212288/
<wgrant> postgres' optimiser makes me sad
<StevenK> wgrant: attrgetter doesn't work for tuples
<wgrant> It won't optimise "BugTaskFlat.bug IN (foo) OR BugTaskFlat.bug IN (bar)" down to "BugTaskFlat.bug IN (foo UNION ALL bar)"
<wgrant> StevenK: I meant itemgetter of course.
<StevenK> Maybe we should then
<StevenK> wgrant: http://pastebin.ubuntu.com/1212297/
<wgrant> StevenK: I guess a list comprehension is actually probably nicer in this case, since we don't need to use DRS
<wgrant> But the test changes look good
<wgrant> Although assertEqual(0, bfjs.count()) or assertContentEqual([], bfjs) is nicer than listifying.
<StevenK> wgrant: http://pastebin.ubuntu.com/1212299/ then
<wgrant> StevenK: Sounds good
<StevenK> wgrant: So, how do I QA my merge fix :-(
<wgrant> StevenK: I believe I outlined in the bug exactly how it happened
<wgrant> StevenK: Or perhaps I outlined on IRC and someone quoted in the bug
<wgrant> I don't quite remember
<StevenK> wgrant: You did, indeed
<StevenK> wgrant: I don't quite want to delete the only account I have on qas :-)
<wgrant> Ah
<wgrant> I have a few test SSO accounts
<StevenK> wgrant: So, wrong question. I'd like to QA it, but I have one Person and I'd rather they weren't deleted.
<StevenK> wallyworld__: Does your MP about er MPs need reviewing?
<wallyworld__> StevenK: wtf not
<wallyworld__> thanks
<wallyworld__> bigjools forced me to do it
<StevenK> I'd rather the commit message wasn't included at all if it isn't set.
<wallyworld__> yeah, but i didn't want to introduce a different template
<bigjools> shut up gollum
<StevenK> Keep %(commit_message)s in the template, and have it expand to '' if the commit message is blank
<StevenK> bigjools: Why gollum?
<wallyworld__> there would still be the header
<wallyworld__> *precious*
<bigjools> StevenK: separated at birth
<bigjools> *score*
<StevenK> wallyworld__: Remove the header, and include 'Commit message:\n' in commit_message if proposal.commit_message
<wallyworld__> thought you would say that :-)
<wallyworld__> ok, will do. i was thinking that it may be good to see that they didn't specify a comment explicitly
<StevenK> wallyworld__: You may need to test to make sure there isn't \n\n\n in the mail
<StevenK> I'm unclear how bad the templating is, it's a been a while since I've touched it
<wallyworld__> maybe. i'll see what other tests are there for similar things
<StevenK> wallyworld__: There's a mail template when you subscribe someone to a P3A, I think that does similar tricks
<wgrant> Soyuz upload notifications use that extensively too
<StevenK> wallyworld__ doesn't like touching Soyuz :-P
<wallyworld__> if i get drunk enough i might
<StevenK> wgrant: Can haz account or are you sorting one out?
<wgrant> StevenK: It may be useful for you to invest in one or two spare SSO accounts
<StevenK> wgrant: I thought you enjoyed being the only LP engineer that has more than one?
<wgrant> Heh
<wgrant> wallyworld__: Parts of the IPerson launchpad.LimitedView adapter permit access if the user can see the team itself or any of its super teams, while others require that it be the team itself. Do you recall it was done like that?
<wgrant> It doesn't seem particularly valuable to preserve, but I'm not sure if I'm missing a reason it's done both ways.
<wallyworld__> wgrant: i can't recall any reason for that, or even if it were considered. it may have been an accidental inconsistency
<wgrant> k
<wallyworld__> StevenK: diff updated
<StevenK> wgrant: Your URL for bug 1019218 doesn't reproduce on qas, which is a little sad.
<_mup_> Bug #1019218: InconsistentBuildFarmJobError: Could not find all the related specific jobs at Builder:+history <buildfarm> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1019218 >
<wgrant> StevenK: The branch probably hasn't been deleted yet.
<wgrant> StevenK: You can probably see the actual branch listed there
<wgrant> I don't know which branch it was
<wgrant>  Translation template build for lp://qastaging/guvcview
<wgrant> I think
<StevenK> That branch exists on prod too
<wgrant> StevenK: The creation dates and unique_names are suspiciously different
<StevenK> Heh, right
<StevenK> I don't really care about which orphaned BFJ it is
<wallyworld__> wgrant: i'm confused about the comments mentioning private_bugs and deactivating proprietary projects - i didn't change those bits at all from what was already there
<wgrant> Oh, I missed that the private_bugs bit was already there
<wgrant> But I was aware of the existing deactivation
<wallyworld__> the bug report didn't seem to imply a new enum was required
<wgrant> It's not clear it still makes sense to deactivate, but it mihgt.
<wallyworld__> it just said to ensure stuff couldn't be abused
<wgrant> We need to ensure stuff can't be abused
<wgrant> But we also need to not be reckless.
<wgrant> And changing the default to public is reckless :)
<wallyworld__> how so? it's just he default?
<wgrant> The plan that sinzui and I discussed on the call two weeks ago is to add a new sharing policy that allows nothing
<wallyworld__> existing stuff remains private
<wgrant> How is it not reckless?
<wgrant> My project expires, but I don't notice
<wgrant> I push up my proprietary code
<wallyworld__> why, you get an email?
<wgrant> Now my code is public :(
<wallyworld__> several emails in fact
<wgrant> I'm not the project owner
<wallyworld__> the owner should take responsibility for their own projects. but anyway, it's moot i guess
<wgrant> Silently opening up access is really really really not a good policy
<wallyworld__> it's not silent
<wgrant> I guess it's not truly silent
<wgrant> But it's still really not good
<wallyworld__> well, no pay, no privacy seems fair
<wgrant> Sure
<wallyworld__> can't expect something for nothing
<wgrant> Bu no pay, we'll make all your code public, is not fair
<wallyworld__> but it's not "all your code"
<wallyworld__> it's code pushed *after* you  have lost the right for privacy
<wgrant> But I don't know that I've lost that right
<wgrant> Or I have forgotten
<wallyworld__> for new stuff, yes because you owe money
<wgrant> Launchpad needs to make mistakes difficult and explicit
<wgrant> Not make them itself
<wallyworld__> and get get plenty of warning, or the owner does
<wallyworld__> cutting off a feature when payment expires is not making a mistake
<wallyworld__> so this forbidden type should disallow creation of all new private bugs and branches?
<wgrant> All new bugs and branches
<wallyworld__> public too?
<wallyworld__> really?
<wgrant> It's not just cutting off a feature: it's opting you into a new feature without asking
<wgrant> Well
<wgrant> For branches it's the same thingf
<wgrant> You can't create branches with a non-default information type
<wgrant> For bugs it's less clear
<wallyworld__> it's not without asking - try not paying your electricity bil and see how you get on
<wgrant> If I don't pay my electricity bill then the company doesn't come and throw all my stuff out onto the street.
<wallyworld__> and neither do we, why do you keep claiming that?
<wallyworld__> exisiting private stuff stays private
<wgrant> And then I push my code and it becomes public
<wallyworld__> as expected
<wgrant> Why is it expected?
<wallyworld__> no pay = no more electricity, np pay = no more privacy
<wallyworld__> totally expected. don't pay for something, don't get the service
<wgrant> The former is temporary and fixable, the latter is not
<wallyworld__> and lots of emails about it before hand
<StevenK> wallyworld__: We all agreed that what wgrant is saying is the right approach
<StevenK> It was covered on a call about two weeks ago, I think
<wallyworld__> hmmm. ok. clearly i forgot
<wallyworld__> i don't agree but that's just my opinion
<wallyworld__> i was mainly reacting to the assertion that *all* your stuff get's throen out onto the street so to speak
<StevenK> wallyworld__: I'm not sure if you were on the call, but at least myself, wgrant and sinzui agreed it was the right approach.
<wallyworld__> sure, np
<wallyworld__> i guess we have to protect people from themselves. sad but true
<wgrant> wallyworld__: Well, a freshly pushed branch probably contains all of your history.
<wgrant> So it is all your stuff.
<wgrant> Effectively.
<StevenK> wgrant: So, 1.0 API for security_contact? Please?
<wallyworld__> even if it is stacked?
<wgrant> If the project uses stacking then it's a bit different
<wgrant> But sadly lots of our commercial projects don't.
<wgrant> (because they have lots of codebases living in a single project. which we don't really support, but they do anyway)
<wgrant> But not supporting something and being reckless with security are unfortunately different.
<adeuring> good morning
<czajkowski> morning
<benji> rick_h__: I didn't get to  https://code.launchpad.net/~rharding/launchpad/move_into_utils/+merge/124678 until late yesterday and it was "Work in progress".  Is that right?
<rick_h__> benji: yes, it gained some scope
<rick_h__> benji: so yea, I ping'd you to ignore it. Sorry for the trouble
<benji> no worries
<rick_h__> sinzui: ping, trying to figure out a conflict here with doc/message-holds.txt? I don't see it blown away in your doctest purge
<sinzui> rick_h_it was
<rick_h__> sinzui: ok, then I'll just remove it locally/resolve. It wasn't listed in http://bazaar.launchpad.net/~sinzui/launchpad/angy-mob-burns-doctests/changes so trying to make sure I resolve this right
<sinzui> rick_h_, I see it in the act in trunk: http://pastebin.ubuntu.com/1212860/
<rick_h__> sinzui: ok cool
* rick_h__ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: â
<rick_h__> sinzui: another ping, reviewing https://code.launchpad.net/~sinzui/launchpad/delete-packaging-link/+merge/124809 and not understanding the adding of the karma bits in the test file. Was it required for some reason?
<sinzui> rick_h_karma will make the user non-probationary...a user with experience
<sinzui> I think that needs a comment
<rick_h__> sinzui: ah, that makes total sense. Thanks
<sinzui> rick_h_I keep forgetting you review on Tuesdays. I have it in my head this day is empty
<sinzui> I took 3 reviews this morning thinking that
<rick_h__> sinzui: yea, that's ok. You pushed me. I wanted to try to get one branch into ec2 before reviews this morning so trying to out race you :P
<abentley> rick_h_: as of 3.5.1, Y.Array.forEach is part of yui-base.  Tempted to retain it because forEach is the official ECMAScript spelling: http://ecma-international.org/ecma-262/5.1/#sec-15.4.4.18
<rick_h__> abentley: ok, then yea including array-extras will allow that to work
<allenap> gary_poster, yellow squad: Do you have a moment to help with lxc? lxc-start-ephemeral is hanging all the time, even with a freshly created base container. Have you encountered this?
<gary_poster> hi allenap.  we are sprinting this week, so we ideally are focusing here.  hallyn on #ubuntu-server has been very helpful for us in the past.  I'm looking myself.  hazmat suggests lxc-start may be the problem.  The first thing I can think of is to make sure that you can start the base container.  Have you confirmed that?
<gary_poster> allenap, another idea is to actually modify the script (it is just a shell script) to have set -x at the top, to show you what command is hanging
<allenap> gary_poster: Tip top, thanks for that advice. Looks like lxc-net was broken/not running. I have yet to discover why. Have a good sprint!
<gary_poster> thanks allenap :-)
<adeuring> rick_h_: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/specifications-sharing-service/+merge/124978 ?
<rick_h__> adeuring: sure thing
<adeuring> thanks!
<rick_h__> adeuring: #96 says +    @operation_returns_collection_of(IBranch)
<rick_h__> but this is specifications right?
<adeuring> rick_h_: argh, of course, I'll change it
<rick_h__> adeuring: same with the docstring that mentions branches please
<adeuring> sure
<abentley> sinzui: I'm confused, because I see there's an accesspolicy.person column, but you say "They do not have any form of access policy".
<rick_h__> adeuring: r=me after the s/branch/specification and a wonder if we should have a bug/XXX for coming back to it later or not.
<adeuring> rick_h_thanks, change already done. Regarding the XXX, I think we should at first see how slow the query will relly be.
<sinzui> abentley, it is incomplete.
<abentley> sinzui: Ah, okay.
<rick_h__> adeuring: ok, cool. Wanted to bring it up.
<sinzui> abentley, we do not know how exactly to manage who may know of the team, or see extra information about it :(. We know archive subscriptions grant limited view, but how would I say all canonical staff may know about our private tech team?
<abentley> sinzui: ISTM that an AcccessArtifactGrant would be the way to go.
<sinzui> I think there was some confusion about requirements too. wgrant does not think the issue can be solved until private projects are in beta, but most private teams are not associated with projects...I don't see the connection
<sinzui> abentley, I think we might need to do that (mirror the project schema). bug 1014580 is ultimately caused by private team in places that we know implicitly allow users to know about the team, but Lp has no means to verify that
<_mup_> Bug #1014580: MixedVisibility error in ProductSet:+all and Product:+index pages <oops> <private-projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1014580 >
<tumbleweed> do I need to request a review of lp:~stefanor/launchpad/edit-packagesets? or will an on call reviewer get to it at some point?
<rick_h__> tumbleweed: so I was peeking at it but it's way out of my wheel house
<rick_h__> tumbleweed: so I am going to wait until wgrant and SteveK get up and ask them to look
<tumbleweed> thanks
<jcsackett> rick_h__: can you take a look at https://code.launchpad.net/~jcsackett/launchpad/too-many-findAP-methods/+merge/125011
<rick_h__> jcsackett: will do
<rick_h__> jcsackett: r=me
<rick_h__> yay for killing cruft
<jcsackett> rick_h__: thanks.
<rick_h__> deryck: yay! productjs branch passed ec2 tests! Thanks again for helping figure that crap out
<deryck> rick_h__, np!  Glad it worked.
* rick_h__ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<abentley> deryck: Any chance you could review https://code.launchpad.net/~abentley/launchpad/spec-creation-js/+merge/125038 ?
<deryck> abentley, sure.
<flacoste> lifeless: ever stumbled upon http://www.12factor.net ?
<lifeless> yes
<flacoste> a lot of these principles seems to be dead on for a SOA architecture
<lifeless> elliot linked it in G+
<lifeless> I think its pretty good
<flacoste> should we link it from the Services page?
<lifeless> flacoste: yeah, might be good
<abentley> deryck: On Kanban, is "Blueprint specs should honour sharing policy" the same as "Use sharing policy default for creating specs"?
<deryck> abentley, yeah, they are.  sorry if I duped that.
<abentley> deryck: np, just wanted confirmation before deleting.
<abentley> deryck: I think someone also pointed out that blueprints were accepting information_types that violated the sharing policy, e.g. PUBLIC for a PROPRIETARY product.
<deryck> abentley, ah, ok. via the API?
<abentley> deryck: No, via the UI.
<deryck> abentley, is there a bug?
<deryck> abentley, also, I still don't have a diff on that MP.  something up there?
<abentley> deryck: I can't remember whether I saw it on a bug report.
<deryck> abentley, ok, I'll make a note and check into it.
<deryck> that surprises me a bit actually.
<deryck> lifeless, hi there.  do you have strong opinions about the visibility vs information_type thread?  Or are you happy for sinzui and us to chat it out?
<lifeless> you and sinzui should come to consensus
<deryck> awesome, thanks.
<lifeless> if you need a tie break, I will be happy to do so.
<abentley> deryck: it timed out: https://oops.canonical.com/?oopsid=OOPS-469a5d735141f9e84163c03ce55e9d4d
<sinzui> deryck, I am satisfied with the discussion. I think your argument are right
<abentley> deryck: I tried triggering a new scan.  No results so far.
<deryck> thanks, sinzui.  I appreciate you weighing in on it and discussing it with me and abentley.
<deryck> abentley, I can't see the ooops yet due to two-factor auth issues, but I had a branch like that last week.  had to push to a new branch on lp and re-MP.
<abentley> deryck: Here is the diff: http://pastebin.ubuntu.com/1213706/
<deryck> abentley, thanks.
<deryck> abentley, I'll review this evening unless you're really wanting to get it landing here shortly.
<abentley> deryck: That's cool.
<deryck> abentley, thanks.  I have smoked chicken to order soonish here. ;)
<rick_h__> wgrant: StevenK ping when you get get in. I left a review about packagesets I didn't feel I knew enough to go over well and respond to his edge case concerns. Can one of you take that please?
<rick_h__> and with that...time to run!
<deryck> later on everyone....
<czajkowski> later gator
<wgrant> rick_h__: Sure
<rick_h__> thanks wgrant
#launchpad-dev 2012-09-19
<wgrant> StevenK: So, how far through the lazr.restful source have you been?
<StevenK> wgrant: I've stared at exported() for a while and it still makes little sense
<wgrant> StevenK: It adds annotations. But you need to look at what interprets those annotations
<StevenK> wgrant: What does the interpreting?
<wgrant> StevenK: Yes
<StevenK> wgrant: While talking with lifeless I've been combing lazr.restful and still coming up with no dice
<wgrant> I'll look shortly
 * StevenK finds another bug
<StevenK> Dear AAPT, please DIAF
<StevenK> Maybe my IPv4 connectivity out of Australia will work now
<StevenK> wgrant: Are you going to request a deploy of oops-tools?
<wgrant> StevenK: I need to talk to lifeless about how we deploy/release/whatever oops*
<lifeless> hi
<lifeless> you just ask bebops to do it
<lifeless> there isn't a wiki page yet.
<lifeless> Perhaps there should be
<wgrant> lifeless: We need to release to PyPI first, or do they deploy from branches?
<wgrant> lifeless: ^^
<lifeless> they deploy from  branches, but please release to PyPI
<lifeless> we should split oops-tools like we did auditor
<lifeless> would make that better
<wgrant> Split?
<wgrant> Also, I think only you have PyPI privileges
<wgrant> I'm not even sure I have an account
<lifeless> wgrant: also I have some oops-tools stuff pending
<lifeless> adding query capturing
<lifeless> wgrant: split into django site and django app, and make the site internal only
<wgrant> lifeless: Ah, right
<StevenK> BLEH, bug 1020439 leads straight back into lazr.restful
<_mup_> Bug #1020439: AttributeError: 'NoneType' object has no attribute 'items'  in +preview-diff <code-review> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1020439 >
<lifeless> james_w: hi
<lifeless> wgrant: get thyself a pypi user id
<lifeless> wgrant: I've added stevenk for now
<lifeless> wgrant: pypi thinks there is a wgrant btw, if its not you say so asap :)
<wgrant> lifeless: Ah, that is me indeed.
<wgrant> I see that I own oops-tools now
<wgrant> Thanks
<lifeless> give me a few hours to kick the tires on this query capturing
<wgrant> Sure
<wgrant> I'll be very happy when you get that done :)
<wgrant> lifeless: I also need oops_datedir_repo
<StevenK> wgrant: So, your choice, help with security_contact, or peer at OOPS-e8d958307abcc91627fcb35e08fff15e :-)
<wgrant> StevenK: My only two options involve obscure lazr.restful? You are a cruel man.
<wgrant> StevenK: What have you uncovered so far?
<lifeless> wgrant: whats pending there ?
<wgrant> lifeless: The same fix
<StevenK> wgrant: For either? That I don't understand lazr.restful much :-(
<lifeless> wgrant: gimme a hint
<lifeless> wgrant: 0.0.18 is published on pypi already, and there is nothing else committed to trunk for datedir-repo
<lifeless> btw, I realised you can meaningfully salt anonymiseip
<lifeless> Its now in my todo list to add a salt option
<wgrant> Ah, good :)
<wgrant> Um, I approved the datedir-repo MP, maybe tarmac hasn't noticed
<wgrant> Or there is no tarmac
<lifeless> there is no tarmac
<wgrant> python-oops-tools has one, so I thought there might be for datedir-repo
<lifeless> the README notes this, the trunk branch URL tells you as well
<lifeless> the owner of the branch is launchpad-pqm for tarmaced things
<wgrant> Yes, but I didn't bother to check since oops-tools worked :)
<lifeless> hah
<lifeless> ok
<lifeless> I see
<lifeless> this is the prune SNAFU
<wgrant> Right
<lifeless> so, do the dance to do a 0.0.19 release of datedir-repo
<lifeless> no need to wait for me, and look at the commits in the log for 0.0.18 and the rev after it to see how its done.
<lifeless> For bonus points, write a damn tool to do releases.
<wgrant> Heh
<lifeless> then you'll want to do another patch to oops-tools
<wgrant> To upgrade versions.cfg, right
<lifeless> to bump the datedir-repo version
<lifeless> wgrant: https://code.launchpad.net/~lifeless/python-oops-tools/timeline/+merge/125086
<lifeless> wgrant: out for  abit
<wgrant> lifeless: k
<wgrant> lifeless: Your MP seems to lack a dep on timeline_django in setup.py
<james_w> hi lifeless
<wgrant> StevenK: So, those two lazr.restful issues
<wgrant> StevenK: I know not much more about lazr.restful than you do
<StevenK> wgrant: Heh, handy
 * StevenK has moved onto bug 827244 for the moment
<_mup_> Bug #827244: bug_filters related to teams are said "mutable" when they're not <api> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/827244 >
<StevenK> wgrant: I'd go back to using as_of='1.0' except I'm stubborn and don't want security_contact in devel
<lifeless> wgrant: django_timeline you mean ?
<wgrant> lifeless: No, timeline_django
<lifeless> oh erm
 * wallyworld_ had fun watching bigjools and lifeless have a public belching competition at lunch. real classy
<lifeless> wgrant: thanks
<lifeless> wgrant: we thought so
<lifeless> bah
<lifeless> wallyworld_: ^
<StevenK> Hahaha
<StevenK> wgrant: Are you handing QA for r15973?
<wgrant> StevenK: You're 38 seconds late
<StevenK> Oh, sorry, I was looking at doing the QA for r15972
<wgrant> A good idea
<wgrant> StevenK: Hm
<wgrant> StevenK: For security_contact, did you try adding a version annotation of ('devel', dict(exported=False))?
<wgrant> With QA done I'm poking around the source
<wgrant> And that looks plausible
<lifeless> wgrant: so, I think we'll definitely find it captures stuff it shouldn't from the openid auth module for django
<lifeless> wgrant: i'm not sure where to start for neutering that
<wgrant> lifeless: Indeed.
<StevenK> wgrant: I did not
<wgrant> lifeless: Personally I think capturing parameters is generally pretty insane.
<lifeless> wgrant: yes, because no one ever does manual SQL.
<StevenK> wgrant: So you think "('devel', dict(exported=False)), as_of='1.0'" ?
<wgrant> StevenK: I forget if you can replace as_of itself with a version annotation, but yes, that should work
<wgrant> lifeless: If they do that in Django apps then I will be sad.
<StevenK> wgrant: Ah ha!
<wgrant> StevenK: Are you still QAing that essential sub thing?
<wgrant> Looks pretty trivial
<wgrant> then we can deploy
<wgrant> And private teams can be less slow
<StevenK> wgrant: Trying to work out how, sadly
<StevenK> I can still tick essential for ubuntu blueprints
<lifeless> wgrant: so, should we land it, find out the issue, file a bug and comment out the hook ?
<StevenK> So I'm trying to work out what the catch is
<wgrant> lifeless: I'd comment out the middleware addit
<wgrant> ion
<lifeless> wgrant: and then have ops uncomment it ?
<wgrant> I don't know :)
<lifeless> wgrant: so the middle ware isn't what captures the data
<wgrant> Safety on capturing SQL statements is an unresolved issue.
<wgrant> True
<lifeless> wgrant: its the timeline hooks that does it.
<lifeless> which is what I was suggesting commenting out to disable
<wgrant> timeline_django.filters.install_hooks?
<lifeless> timeline_oops
<StevenK> wgrant: Right, I don't get it.
<lifeless> the one you listed does sanitisation for the stock django bits.
<wgrant> StevenK: The subscriber can no longer tweak the flag
<wgrant> StevenK: Or isn't meant to be able to
<StevenK> wgrant: I can set it when I subscribe
<wgrant> StevenK: what about afterwards?
<lifeless> james_w: please be doing a release of timeline_django :)
<wgrant> lifeless: Which bit is it that logs SQL to the timeline, then?
<StevenK> wgrant: If I hit Update subscription I get 'Not allowed here'
<wgrant> timeline_django_setup?
<StevenK> Which is just awesome
<wgrant> StevenK: Right, so that's hideous but the logical effect of the revision
<wgrant> StevenK: Even if you don't change the flag?
<lifeless> wgrant: the middleware
<wgrant> The revision's commit message also doesn't match its content
<StevenK> wgrant: I can't even see the page to change the flag
<wgrant> 13:59:21 < lifeless> wgrant: so the middle ware isn't what captures the data
<lifeless> wgrant: I'm saying disable the entire timeline when there is an issue
<lifeless> wgrant: the timeline isn't in the oops by default
<StevenK> wgrant: I also can't unsubscribe myself from the blueprint
<lifeless> wgrant: middle ware -> hooks into django and adds to timeline; timeline hooks hook timeline into the oops
<wgrant> Oh, disable the timeline from being included in the OOPS, I see
<wgrant> StevenK: rofl
<wgrant> StevenK: Revert revert revert
<wgrant> And I can't deploy my private team fix :(
<wgrant> lifeless: Right, makes sense now
<StevenK> wgrant: Sorry
<lifeless> wgrant: so, plush one on my mp ?
<wgrant> lifeless: Do we want an I_ACKNOWLEDGE_THAT_I_AM_TERRIBLY_MISGUIDED flag in settings.py to enable it, perhaps?
<wgrant> lifeless: Don't we want it disabled in trunk?
<wgrant> That MP still has it enabled.
<james_w> lifeless, the only change is your debugging aid?
<lifeless> james_w: yes, which would be very useful for oops.c.c
<james_w> lifeless, you can't debug the issue locally?
<lifeless> wgrant: thats right, its safe enough for folk not running custom auth crazy
<lifeless> james_w: nope, can't.
<james_w> lifeless, you had a reproducer though?
<lifeless> james_w: can't reproduce now
<lifeless> james_w: driving me batty
<james_w> ok
<james_w> not tonight
<james_w> maybe not tomorrow
<wgrant> lifeless: Is it?
<wgrant> lifeless: But our auth crazy is at the Apache level anyway
<lifeless> wgrant: is it ? I don't think it is.
<wgrant> Oh, you mean the /admin thing, yeah
<wgrant> Maybe
<lifeless> james_w: cool, let someone here know - purple or me - and we'll bump the dep in oops tools at that point.
<james_w> lifeless, poke me tomorrow or the next day if I haven't
<james_w> we're in a bit of a crunch
<lifeless> ok
<wgrant> lifeless: btw, this version-locked madness is madness
<StevenK> wgrant: Revert landed as r15980
<wgrant> StevenK: Thanks
<StevenK> wgrant: Shall we deploy up to r15971?
<wgrant> We have little choice
<wgrant> StevenK: Did the security_contact thing work?
<StevenK> wgrant: It worked so well I put it up for review. https://code.launchpad.net/~stevenk/launchpad/export-security_contact-for-1.0/+merge/125092
<wgrant> I got an email right as you said that
<wgrant> lifeless: I have a tested datedir-repo sdist -- can I have upload privs now?
<wgrant> StevenK: This doesn't sound like it will fix the proejct creation script
<wgrant> StevenK: As it's RO
<wgrant> Right?
<lifeless> wgrant: done
<StevenK> I have no idea about the project creation script, the bug only talked about exporting it
<wgrant> lifeless: Thanks
<wgrant> StevenK: The bug description mentions it
<lifeless> wgrant: so.. +1?
<StevenK> wgrant: Sure, but it doesn't say that it has to be settable
<wgrant> lifeless: k
<wgrant> done
<wgrant> StevenK: A project creation script presumably wants to set it
<wgrant> lifeless: How do I add a new release on PyPI?
<StevenK> wgrant: Let's leave it for now, I'll bring it up on the call
<wgrant> I try to add a new file, but it lists the 0.0.18 tar.gz, so I'm not sure if it's adding a new release or not
<wgrant> I'm also slightly nauseous from uploading to a totally insecure distribution mechanism
<lifeless> wgrant: so, you make the release by doing
<lifeless> setup.py sdist upload -s
<lifeless> wgrant: gpg signed, ~= totally insecure
<wgrant> OK, all the clients are totally insecure :)
<wgrant> Now how do I auth...
<lifeless>  cat .pypirc
<lifeless> [server-login]
<lifeless> username:lifeless
<lifeless> password:
<wgrant> Oh cool
<wgrant> It defaults to basic auth over unencrypted HTTP
<lifeless> yup
<wgrant> And I bet if asked to do HTTPS it doesn't actually check the cert
<lifeless> patches...
<wgrant> Yeah, no cert verification
<wgrant> Ah
<wgrant> Not that it really matters
<wgrant> Since you can change your password through the web UI with just a cookie
<StevenK> Yeah, security is for other frameworks
<wgrant> I think it's uploaded
<wgrant> I might need to go outside to breathe before I refresh the page, though
<wgrant> The hash even matches
<ajmitch> wgrant: or just take a drink every time there's some security thing that annoys you. pretty soon you won't care at all :)
<StevenK> Hahaa
<wgrant> They're not security things that annoy me, they're security things that are objectively wrong :)
<StevenK> ajmitch: And after using LP for 15 minutes, wgrant gets admitted to hospital for alcohol poisioning
<wgrant> LP is merely less than ideal
<wgrant> Other things are trainwrecks :)
<StevenK> Oh damn, I looked at a branch page wrong during initial scan
<lifeless> bigjools: http://www.xtranormal.com/watch/7023615/watch_movie <- kick this one off next.
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/mute-when-not-allowed/+merge/125094
<StevenK> wgrant: I think bug 869351 and bug 1036882 are dupes. Possibly bug 816617 too
<_mup_> Bug #869351: UnknownRecipientError on +editstatus page when setting assignee, milestone, status, and commenting <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/869351 >
<_mup_> Bug #1036882: UnknownRecipientError OOPS updating series specific tasks <bugs> <email> <oops> <subscribers> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1036882 >
<_mup_> Bug #816617: UnknownRecipientError raised sending mail notification to bug subscriber <mail> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/816617 >
<wgrant> StevenK: I believe they are probably dupes, yeah, but I didn't get around to digging farn enough into them on Monday to tell for sure
<wgrant> Hmk
<wgrant> I thought I duped 1036882 against 869351 on monday
<wgrant> But apparently not
<wgrant> Ah, and the OOPSes from the older two are gone
<StevenK> Yeah
<StevenK> Of course
<wgrant> I think my diagnosis in 1036882 can reasonably apply to the other two
 * wgrant dupes
<StevenK> I was about to, but sure
<wgrant> Ah right
<StevenK> wgrant: Your diagnosis of "I'm not sure why there was no reason." ? :-)
<wgrant> I duped 925791
<wgrant> So there were 3 duplicates
<wallyworld_> StevenK: can you put the team name in the error message and maybe word it like the message just below in the code?
<wgrant> Also, does LP prefer "can not" or "cannot"?
<wgrant> I suspect the latter
<wallyworld_> +1
<wgrant> wgrant@lamuella:~/launchpad/lp-branches/devel$ bzr grep '\bcan not\b' | wc -l
<wgrant> 77
<wgrant> I think we have a clear winner
<wgrant> wgrant@lamuella:~/launchpad/lp-branches/devel$ bzr grep '\bcannot\b' | wc -l
<wgrant> 1298
<StevenK> I wish bzr grep supported -c
<wgrant> Don't make me go full UNIX on you
<StevenK> wallyworld_: http://pastebin.ubuntu.com/1214202/
<lifeless> wgrant: so, you're doing the oops-tools repo dep upgrade?
<lifeless> wgrant: or do you want me to ?
<wallyworld_> StevenK: thanks, s/muted, team/muted because team
<StevenK> wallyworld_: http://pastebin.ubuntu.com/1214207/
<wgrant> lifeless: I guess some of the other deps need upgrading too
<wallyworld_> r=me, thanks
<wgrant> lifeless: Since datedir-repo is at 0.0.15...
<lifeless> maybe
<lifeless> you'll get conflicts if they are incompatible
<lifeless> or something
<lifeless> jam: whats your pypi id ?
<jam> lifeless: jameinel
<lifeless> jam: I'd like to apply http://paste.ubuntu.com/1214228/ to bzr-pqm and do a release on pypi.
<jam> lifeless: do we actually require launchpadlib? I thought it was a nicety, but for people who might use it on Windows it brings in a huge dependency set.
<jam> Otherwise +1
<lifeless> jam: it selftest fails w/out it.
<lifeless> jam: I don't recall if it fails to load at all w/out it.
<jam> I know I used 'bzr pqm-submit' without it for a long time
<jtv> wgrant: having some problems with âbzr bdâ on maasâ¦ are you familiar with it?
<jam> but certainly the lp- versions of the pqm commands probably require it
<jam> (lpland, etc)
<wgrant> jtv: Only vaguely.
<wgrant> jtv: I gather you have some people who know bzr pretty well now, so they probably know it better than I
<wgrant> But I can help if you need
<jam> anyway, I won't block it, and people using bzr-pqm likely have launchpadlib around, there aren't many outside of lp people using pqm anyway.
<StevenK> wgrant: I also do not get why ... (re: bug 1036882)
<_mup_> Bug #1036882: UnknownRecipientError OOPS updating series specific tasks <bugs> <email> <oops> <subscribers> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1036882 >
<jam> lifeless: are you asking me to apply the patches, or you need pypi access, or just a review?
<wgrant> StevenK: Have you been able to reproduce it locally?
<lifeless> jam: I could move it to extras,  but I'm not sure there is a good way to say 'bring it in for this command' other than splitting the package.
<StevenK> wgrant: No, I've been reading the code
<lifeless> jam: eyeball review, since I plan to commit, push, sdist upload register etc all at aonce.
<jtv> wgrant: fwiw Julian is stumped.  :)  A patch fails to apply, and I get the impression it should.  I suspect the fact that one of the paths has a double â.origâ in it.
<lifeless> jam: so, say '+1' now,a nd then you can forget about it :)
<jam> lifeless: so I'm hesitant about launchpadlib, but I understand and I can live with it for your +1
<StevenK> wgrant: All of the subscriber (as in zope subscriber) and the recipient fetching code
<lifeless> jam: they can't currently pip install it anyhow, as its not on pypi at all :)
<wgrant> StevenK: Have you set up the scenario described in the bug locally?
<jtv> wgrant: the â---â file is maas-0.1+bzr702+dfsg.orig.orig/contrib/maas_local_settings.py
<lifeless> jam: which this will at least solve; can fine tune later :>
<lifeless> jam: thanks
<StevenK> wgrant: No, that's my next step
<StevenK> wgrant: So, create a bugtask and milestone, create a structural subscriber for the milestone and +editstatus?
<wgrant> StevenK: Something like that. Possibly with a target change, or assignee change, or something like that
<wgrant> The full circumstances should be described in the bug
<StevenK> I was going to add those in, yes.
<lifeless> jam: and there - http://pypi.python.org/pypi/bzr-pqm
<lifeless> done
<jam> lifeless: looks good
<jam> thanks for doing the work
<jam> this is part of 'get rid of sourcecode' ?
<jam> launchpad guys, I get initial emails when someone submits a MP to lp:maas, however, I do not get comments on all MPs. I think I subscribed to the branch, is there a config I'm missing to get the followup emails?
<lifeless> jam: its part 'get rid of inventory'
<lifeless> jam: and part 'make it easier to get rid of sourcecode'
<jam> lifeless: 'inventory' being things that aren't properly released yet?
<lifeless> jam: we either need to switch to e.g. pip (something that doesn't use separate egg dirs per thing), or we need to teach bzrlib how to load plugins from eggs.
<lifeless> jam: yup
<lifeless> jam: 'fix committed' status
<lifeless> jam: I mailed the list about the issue
<jam> lifeless: 'pip install -Z' doesn't build a .zip/.egg file, I believe. Can't you set the 'not zip safe' flag somewhere in setup.py?
<lifeless> jam: EPARSE
<lifeless> jam: pip doesn't use egg directories at all, it installs into site-packages.
<jam> lifeless: sorry, "easy_install -Z" then. The thing that creates eggs can do it by just updating .pth and then putting the files expanded on disk.
<lifeless> ok, gotta run, taxi here.
<jam> I used to have to do that for paramiko
<jam> because otherwise py2exe couldn't bundle it.
<jam> lifeless: catch you later.
<jtv> wgrant: this âbzr bdâ problem with maas is really bugging us.  A patch fails to apply to a missing file, except the missing file seems to be in the branch as before.
<jtv> An invocation of âdh get-orig-sourceâ seems to be part of the problem.  There seems to be no such command in dh.
<StevenK> I strongly doubt it's dh
<StevenK> dh is a debhelper wrapper
<wgrant> Are you perhaps trying to use get-orig-source in a package that doesn't support get-orig-source?
<wgrant> bzr bd is after my time, anyway
<jtv> How would I tell whether the package supported it?  There is a target of that name in debian/rules though.
<wgrant> That is roughly the definition of supporting it.
<StevenK> wgrant: http://pastebin.ubuntu.com/1214252/ and no failure :-(
<wgrant> Not sure why it would be trying to call into dh
<bigjools> the problem is when quilt is applying the patches
<bigjools> beyind that I dunno
<jtv> It doesn't find the file it's supposed to be patching.  To be honest, I can't find it either.  It's in the .orig tarball, but I don't see it unpacked anywhere.
<StevenK> Is it deleted by the .diff.gz applying?
<wgrant> maas hopefully doesn't have a diff.gz
<StevenK> Or an .orig then
<StevenK> It's just .tar.gz for native
<jtv> How would I check these things?  I see no files with any of those names in the packaging branch, fwiw.
<wgrant> StevenK: I was alluding to the fact it is probably 3.0 (quilt), which cannot delete files from the orig.tar.gz
<StevenK> Ah, I've been ignoring 3.0 (quilt) for being a crime against humanity
<StevenK> wgrant: Ah ha, my save against BugTask:+editstatus doesn't hit the zope subscriber stuff
<jtv> Well the file that's being patched is still in the .orig.tar.gz.
<jtv> wgrant: I guess it's normal that, after the failed build, the build-area directory contains the .orig.tar.gz and the packaging branch, but not the contents of the .orig.tar.gz in unpacked form?
<wgrant> jtv: I'm really not sure, sorry
<jtv> Any idea who might know, that's available at this hour?
<StevenK> wgrant: Hm, I thought passing form=foo to create_initialized_view() would call the save_action
<wgrant> StevenK: Perhaps your action name is bad
<wgrant> StevenK: Does the form appear to submit?
<wgrant> jtv: Perhaps former bzr people may know
<StevenK> Ah ha, view.errors
<jtv> wgrant: thanks, I think I'll be able to dig some up soon!
<StevenK> wgrant: The form submits, zope subscriber stuff fires, no error
<wgrant> StevenK: Have you tried manually setting up the scenario on launchpad.dev?
<wgrant> You could just have a bad test
<StevenK> wgrant: http://pastebin.ubuntu.com/1214277/
<wgrant> StevenK: I can't always solve all your problems just by looking at a test of a strange view, sadly
<wgrant> StevenK: Try it in a browser
<StevenK> wgrant: I am doing so
<StevenK> Trying to remember how to add a series task
<wgrant> Target
<StevenK> Don't I have to nominate? It's been so long since I've had to do stuff like this.
<wgrant> Not if you're the driver
<StevenK> Which I'm not
<StevenK> Let me fix that
<StevenK> wgrant: No OOPS
<wgrant> You won't even see the link if you're not one of maintainer/driver/bugsupervisor
<wgrant> Hmm
<StevenK> I have a product, which I'm driving, a series, a milestone and a structsub for a random on the milestone
<wgrant> StevenK: Do you have an appropriate event filter?
<wgrant> StevenK: The problematic subscription on production was open/close only
<StevenK> That isn't the default?
<wgrant> StevenK: Not through the API, probably.
<wgrant> Or through the method you called in the test
<StevenK> Right, I'll check the filter
<StevenK> Hm, how do I even express that as a filter? :-(
<wgrant> StevenK: It's one of the root settings for the subscription
<wgrant> StevenK: So it's not shown as a filter in the web UI
<wgrant> It's one of the initial radio buttons
<lifeless> jam: so yes, sourcecode/
<StevenK> Right, structsub edited
<lifeless> jam: I can look into the zip unsafe flag if needed, but whats unsafe about bzr-pqm? Is it that 'bzr cannot load it from a zip' ?
<jam> lifeless: right
<jam> some other tool doesn't work properly with zip
<jam> I think it also is needed for things that create extension modules.
<jam> but I just defaulted to using it because py2exe doesn't work with eggs either.
<StevenK> wgrant: Also no OOPS
<wgrant> StevenK: :(
<lifeless> jam: http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt
<lifeless> ``zip-safe`` and ``not-zip-safe``
<lifeless> ...
<lifeless> ---------------------------------
<lifeless> If neither file is present at installation time, EasyInstall defaults
<lifeless> to assuming that the project should be unzipped.  (Command-line options
<lifeless> jam: it will still be unpacked to a .egg directory
<lifeless> jam: which won't let bzr import it
<jam> lifeless: if easy_install updates the .pth appropriately, I think it still works.
<lifeless> jam: nope
<jam> I'm not sure about path issues and easy_install, though. It gets a bit confusing with namespaces.
<lifeless> jam: because we scan for plugins ourselves.
<lifeless> jam: we need a custom path aware - including egg/pth - plugin loader, or we need to use pip for launchpad
<jam> ah sure. I wonder if we could play games with bzrlib.plugin.__path__
<jam> or play games with BZR_PLUGIN_PATH
<lifeless> syncing that with PYTHONPATH via heuristics makes me shudder
<lifeless> jam: bzrlib.plugins.__path__ is set when set_plugins_path is called
<lifeless> from get_standard_plugins_path
<lifeless> and we nuke the default path entirely.
<jam> lifeless: and tbh I'm not really sure how sys.path interacts with bzrlib.plugin.__path__ and all that stuff. Namespaces were supposed to help with this, but it was never something we tried to do for bzr itself.
<jam> btw, I didn't see an email about it
<jam> or maybe it was in a thread I missed?
<lifeless> haven't sent one
<lifeless> I side tracked slightly onto that from reviewing bugs.l.n/~lifeless/?status=FIXCOMMITTED
<jam> (9:55:23 AM) lifeless: jam: I mailed the list about the issue
<jam> hence my confusion
<jam> but np
<wgrant> StevenK: Reproduces easily for me
<wgrant> UnknownRecipientError: <Person at 0xf853a4c no-priv (No Privileges Person)><br />
<StevenK> wgrant: Holy crap
<StevenK> wgrant: Nice work
<lifeless> jam: about the fixcommitted issue :)
<lifeless> jam: a week or so back
<wgrant> StevenK: From a fresh dev DB, I created a new milestone hoary-updates. As no-priv I subscribed to it with default settings. Then, as name16 I went to https://bugs.launchpad.dev/ubuntu/hoary/+bug/2/+editstatus, set In Progress/High/name16/hoary-updates with a comment, then saved
<lifeless> jam: apologies for adding confusion
<wgrant> StevenK: Not sure how many of those details are actually necessary. I was just duplicating the changes from the OOPS before trying to minimise the test case
<StevenK> wgrant: Ooooh, I've been doing it against products, not distros. That is probably very related ...
<wgrant> StevenK: Potentially
<lifeless> stub1: hi, around ?
<stub1> lifeless: yup
<StevenK> wgrant: Are you going to keep digging, or shall I take your notes and dig in tomorrow?
<lifeless> stub1: time for a brief catchup?
<stub1> lifeless: ok. I'll find my mike
<adeuring> good morning
<lifeless> adeuring: o/
<adeuring> hi lifeless!
<wgrant> StevenK: Ahaa
<wgrant> StevenK: It's the combination of milestoning and assigning to Me
<lifeless> allenap: bug 847889 needs a release done.
<_mup_> Bug #847889: RabbitServerResources.tearDown is never called <rabbitfixture:Fix Committed by allenap> < https://launchpad.net/bugs/847889 >
<lifeless> allenap: as you did the work, care to do the release too ?
<wgrant> StevenK: that should let you fix the test
<wgrant> StevenK: It probably works on products too
<wgrant> StevenK: That's like two lines of diff -- can you try that now?
<StevenK> wgrant: Hmm. No failure for me :-(
<wgrant> StevenK: It doesn't actually have to be assigning Me, it can be any user
<wgrant> But I suspect what's happening is that it's doing the assignee change first
<wgrant> Which causes the recipients to be calculated
<wgrant> And cached
<wgrant> Then the milestone is changed, and it adds a new recipient
<wgrant> But something's still cached
<wgrant> So the recipient has no reason
<StevenK> wgrant: I'm adding a series task, and then passing in form data with the milestone and assignee, and I don't get an OOPS
<wgrant> StevenK: Can you pastebin the latest test?
<StevenK> wgrant: http://pastebin.ubuntu.com/1214353/
<wgrant> StevenK: That's quite possibly erroring because there are mandatory fields missing
<StevenK> wgrant: view.errors == []
<wgrant> StevenK: Reproduced on a fresh product with no series task and just setting assignee+milestone. But the subscription needs to be open/close only
<lifeless> -> plane
<mpt> sinzui, why did you tag bug 1052364 as "private-projects"?
<_mup_> Bug #1052364: Blueprint icons aren't as distinct as they could be <lp-blueprints> <private-projects> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1052364 >
<czajkowski> mpt: there is work going on with them atm possibly
<wgrant> It's unrelated
 * wgrant untags
<wgrant> He did that in a batch of other taggings
<StevenK> wgrant: Ah ha, so now the question remains of how to do that in a test.
<StevenK> wgrant: I thought open/close was LIFECYCLE?
<wgrant> StevenK: I think so
<wgrant> But don't quite me on that unless you check the code first
<StevenK> wgrant: If so, no error for me
<wgrant> StevenK: In the test or web UI?
<StevenK> The test
<wgrant> Give me your latest version and I'll fix it
<wgrant> Now I have a minimal case
<StevenK> I swear I'm close. :-(
<StevenK> wgrant: http://pastebin.ubuntu.com/1214400/
<wgrant> StevenK: Kill off the series
<wgrant> No need for that
<wgrant> Otherwise that looks pretty reasonable...
<StevenK> wgrant: Done, but no evil traceback. I didn't think I needed to call render() or anything?
<cjohnston> sinzui: ping
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: â
<sinzui> hi cjohnston
<cjohnston> hey there.. did you see the comment about the participation essential stuff breaking unsubscribing/editing subscription?
<sinzui> No
<cjohnston> https://bugs.launchpad.net/launchpad/+bug/1052130
<_mup_> Bug #1052130: Make assigning participation essential limited to certain groups of users <bad-commit-15972> <lp-blueprints> <qa-bad> <Launchpad itself:Fix Committed by chrisjohnston> < https://launchpad.net/bugs/1052130 >
<sinzui> cjohnston, The branch will need to be rolled back. Another branch is needs that extends your branch and fixes the javascript
<sinzui> I think there are two uses of the permission, but the zcml shows only one.
<sinzui> cjohnston, We want to restore the launchapd.edit method so users can edit their subscriptions. We want the essential flag to be launchpad.Drive
<sinzui> or we consider removing essential from Launchpad
<cr3> launchpadlib doesn't seem to be ported to python3 yet, any plans?
<sinzui> no. barry abandoned it I think because the deps chain was hard
<sinzui> I think there is some bad mojo in the gnome key/auth code that is ancient python
<cjohnston> sinzui: I don't know what the response will be about removing it from LP.. personally, I'm not against it, though I really don't have time/ability to do the work since it needs to be done asap
<sinzui> cjohnston, essential is used by many non-ubuntu projects. http://pastebin.ubuntu.com/1214916/
<sinzui> I will revert the branch now
<czajkowski> wow
<cjohnston> well, all of the LPC stuff is Summit too... so that could be considered mine for a lack of a better term.. I am curious though (and this is why I sent the email asking) what they use it for
<sinzui> great
<cjohnston> but the only feedback I got was that it is for Summit... there really isn't anything else (unless a group specifically has a use for) that it's used for
<cjohnston> i.e. it doesn't really do anything in LP other than change the icon color
<sinzui> cjohnston, StevenK already landed a branch to revert the change
<cjohnston> ok
<cjohnston> sinzui: so does this mean we can't even remove it since others are using it?
<cjohnston> I mean, if you look at the 'help text' its pretty clear as to what it's for
<sinzui> We would need to ask if they really need it.
<sinzui> regardless, a branch to remove it has to change the javascript that was broken by your branch
<cjohnston> So what it the best approach then for now to get my point across? go back to the text change?
<sinzui> yes
<cjohnston> then lifeless is going to leave me his comment again ;-) heh
<sinzui> That is also true for Non-ubuntu brojects
<abentley> rick_h_: I'm trying to make the change you wanted: http://pastebin.ubuntu.com/1215019/ But it says "yui: NOT loaded: function (Y) {
<abentley>     var tests = Y.namespace("lp.blueprints.addspec.test");" which looks wrong: http://pastebin.ubuntu.com/1215023/
<rick_h_> abentley: looking
<rick_h_> abentley: sorry, missed that you hadn't created a module in the test file. Was more change than I originally thought. https://pastebin.canonical.com/74807/
<rick_h_> abentley: and the comment in the requires array breaks the meta.js parser for the combo loader so moved it up.
<rick_h_> I've got a branch that uses an ast vs regex to parse into convoy, but never got the ok on it.
<abentley> rick_h_: So this patch is meant as an alternative to my patch?
<rick_h_> abentley: yes, sorry I had pulled your branch down earlier to prep for my rename of registry/app stuff
<rick_h_> abentley: so this is a patch against what you had pushed up for review this morning
<abentley> rick_h_: Okay, thanks.
<rick_h_> abentley: np, thanks for looking at the update
<abentley> rick_h_: Are you landing move_into_utils right now?
<rick_h_> abentley: no, I've marked your branch as a pre-req and I'm waiting on your branch first
<abentley> rick_h_: Okay, I'm going ahead then.
<rick_h_> abentley: cool, thanks
<jcsackett> sinzui: you available to chat a bit?
<sinzui> I am
 * sinzui looks for headphones
 * jcsackett fires up g+
<jcsackett> sinzui: hangout sent, whenever you're ready.
<jcsackett> sinzui: bug 612387
<_mup_> Bug #612387: Breadcrumb from PersonProduct active reviews page gives 404 <404> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/612387 >
<sinzui> jcsackett, https://bugs.launchpad.net/gdp/packaging
<sinzui> https://bugs.launchpad.net/launchpad/+bug/573779
<_mup_> Bug #573779: Site header does not accurately represent section <breadcrumbs> <lp-web> <Launchpad itself:Triaged> < https://launchpad.net/bugs/573779 >
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<abentley> deryck: Please tell me this isn't doing what I think it's doing: http://pastebin.ubuntu.com/1215660/
<deryck> abentley, sorry, I had stepped away, looking now....
<abentley> deryck: It's more of an, "oh, god, blueprints are ugly" statement than a real question.
<deryck> abentley, yeah, it's kind of off code.
<deryck> odd, I meant
<abentley> deryck: Yeah.  Not generally a good idea to re-implement SELECT  :-)
<deryck> ha!  yeah.
<deryck> in a python loop no less. :)
<jcsackett> sinzui: standup?
<sinzui> jcsackett, sorry, will be there in a few minutes
#launchpad-dev 2012-09-20
<lifeless> wgrant: I'll do oops-tools if you haven't
<wgrant> lifeless: I haven't
<StevenK> wgrant: So, what's going on is the bugtask subscriber stuff is poking in the event and getting a set of new_subscribers and passes that into add_bug_change_notifications. The BugTaskAssignee case is pawing through that list and removing the assignee -- which assumes that everyone listed in new_subscribers is already in recipients. The structsub's owner isn't, so bang.
<wgrant> Yep
<bigjools> Bug 1017293 \o/
<_mup_> Bug #1017293: Commit message is not shown on the initial merge proposal email <code-review> <email> <qa-ok> <Launchpad itself:Fix Released by wallyworld> < https://launchpad.net/bugs/1017293 >
<wallyworld_> bigjools: i accept credit card or prefer cash
<bigjools> wallyworld_: coffee?
<StevenK> wgrant: So new_subscribers isn't used anywhere else, and that's why it's only an impact for LIFECYCLE -- otherwise they get a reason
<wallyworld_> ok, that will do
<StevenK> wallyworld_: Act now, and bigjools might throw in his twins
<wallyworld_> and a set of steak knives
 * StevenK prepares a shallow grave for Tim Shaw
<bigjools> twinings only do tea
<StevenK> wgrant: Given we're only interested in the assignee, I'm tempted to catch the exception here and 'continue'
<wgrant> StevenK: I'm not sure that's valid.
<StevenK> wgrant: Why? This function does nothing else with new_subscribers and assumes that all of them are already in recipients
<wgrant> StevenK: Can you point me at the problematic code?
<StevenK> wgrant: lib/lp/bugs/subscribers/bug.py. Function is line 139 the block I'm talking about is line 160
<StevenK> wgrant: new_subscribers is passed in from subscribers/bugtask.py and is the difference of event.object.bug_subscribers and event.object_before_modification.bug_subscribers
<StevenK> In the usual case, it's only going to be the assignee or the empty set
<wgrant> Oh no
<wgrant> Not this function :(
<StevenK> wgrant: Hahaha
<wallyworld_> wgrant: thanks for looking at my branch, not sure i 100% agree with the project group reversions. the pg filebug page will list the reason why projects cannot have bugs filed, forbidden is but one reason so the mp sticks to the current conventions in that area
<wgrant> wallyworld_: Well, doesn't it only check default_product now?
<wgrant> Blocking it early is also far less necessary now that we just redirect to Product:+filebug
<wgrant> And this is an exceptional misconfiguration situation
<wgrant> So I'm not sure adding the extra confusing UI text to the existing situation improves things.
<wgrant> It'll be very clear when they get redirected to Product:+filebug
<wallyworld_> i think so, but what it does it display a message for each product saying eg "not malone" and i've added a new message "forbidden" to go with that
<wallyworld_> reverting those bits would make the code simpler for sure
<wgrant> It would make the code and UI simpler
<wallyworld_> the ui is already not simple
<wallyworld_> it already lists each product with reasons
<wgrant> And I'm pretty sure the ProjectGroup contextAllowsNewBugs is buggy
<wgrant> Does it?
<wallyworld_> yes
<wgrant> The text you've changed seems to only be shown when no projects are selectable.
<wallyworld_> yes
<wgrant> So it doesn't list each product
<wgrant> 245	There are no projects registered for <span
<wgrant> 246	tal:replace="context/displayname">project displayname</span>
<wgrant> 247	- that use Launchpad to track bugs.
<wgrant> 248	+ that either use Launchpad to track bugs or allow new bugs to be filed.
<wallyworld_> it does, i tested it
<wgrant> 256	- but none of them use Launchpad as their bug tracker.
<wgrant> 257	+ but either none of them use Launchpad as their bug tracker or none
<wgrant> 258	+ allow new bugs to be filed.
<wgrant> 272	There is 1 project registered as part of
<wgrant> 273	<tal:project replace="context/displayname" /> but it
<wgrant> 274	- does not use Launchpad as its bug tracker.
<wgrant> 275	+ does not use Launchpad as its bug tracker or does not allow new
<wgrant> 276	+ bugs to be filed.
<wallyworld_> yes, that's the summary message at the top
<wallyworld_> and then each product is listed
<wallyworld_> with the reason
<wgrant> https://launchpad.net/launchpad-project/+filebug
<wgrant> There's just a <select>
<wallyworld_> but that's not relvant here since launchpad-projects has products with alow new bugs
<wallyworld_> on a .dev system, update firefox to forbidden and then goto mozilla+filebug
<wgrant> Oh, that's all wrapped in !contextUsesMalone
<wgrant> How odd
<wgrant> I think we can just delete that
 * wgrant checks the DB
<wgrant> Heh
<wgrant> What a buggy little-known page
<wgrant> https://launchpad.net/mercurial/+filebug
<wgrant> it has a persistent notification and accidentally nested bullets somehow
<wgrant> (and it's not linked from anywhere)
<wallyworld_> that's why i took the approach i did - to be consistent with what was there
<wgrant> So I would suggest we delete most of the complexity from that block
<wgrant> It's not worth it
<wgrant> The page is unlinked and already buggy
<StevenK> wgrant: So, "not this function" and no other discussion? :-(
<wgrant> StevenK: I was reviewing wallyworld's branch and that function is horrible :)
<wallyworld_> wgrant: it may be buggy but this branch is already large. i think it best to be consistent with what's there and do any tidy up in another branch
<wgrant> wallyworld_: If you fix the contextAllowsNewBugs bug, can your new text on ProjectGroup:+filebug ever be true?
<wallyworld_> i do think it's reasonable that it doesn;t allow you to enter all this info, and then say "ha ha, no you can't really file a bug here"
<lifeless> does it get hits?
<wgrant> wallyworld_: "all this info" is a project and bug title.
<wgrant> wallyworld_: The description etc. is after the redirect
<wallyworld_> sure, but still, it allows you to proceed when you can't
<wgrant> wallyworld_: Your contextAllowsNewBugs is buggy because it will block the page if the default project, not all projects, happen to be forbidden
<wallyworld_> i was following the pattern used for contextUsesMalone
<wgrant> Unless you do a very complex fix for that, I don't think the added text on ProjectGroup:+filebug can be true
<wallyworld_> which will do the same thing
<wgrant> wallyworld_: contextUsesMalone works because default_product is the first product in the project group that uses malone
<wgrant> So if it's present, there's a project that uses malone
<wallyworld_> ok, it's easy to change ales new bugs to see if one of the projects allows bugs
<wgrant> It's easy but completely not worth it.
<wallyworld_> i don't agree
<wgrant> This is an exceptional situation where the worst that can happen is you enter a bug summary and get told "lol no"
<wgrant> It's not worth the extra code on this little-used view
<wgrant> And tests
<wallyworld_> the view isn't inlinked
<wallyworld_> unlinked
<wallyworld_> it's linked from the project group page
<wgrant> The complex product listing bit is unlinked today
<wgrant> https://launchpad.net/ggi
<wgrant> spot the link
<wallyworld_> you get the view if you +filebug on a project group
<wgrant> wallyworld_: how do you get there if no projects use malone?
<wgrant> The link is not shown in that case
<wgrant> The page needs to tell you "lol no" if you URL hack, but it doesn't need dozens of lines of complex template logic to be pretty
<wallyworld_> i didn't check the tal - is the link wrapped in a condition?
<wgrant> wallyworld_: The +filebug link is only shown if bug_tracking_usage == LAUNCHPAD, and a project group's bug_tracking_usage == LAUNCHPAD iff at least one of its projects does.
<wgrant> So the link is only shown iff contextUsesMalone is true
<wallyworld_> so it seems that view is only there if people url hack
<wgrant> So the !contextUsesMalone case is unimportant
<wgrant> (there's 105 lines of template for it, despite it being unimportant except for URL hackers)
<wgrant> That's 20% of the entire template dedicated to a case that's unlinked.
<wgrant> Delete :)
<wallyworld_> but people may have bookmarks etc, so we should stil ldisplay somwething nice
<StevenK> I think wgrant and I agree that 'Not found' is something nice for this case
<wallyworld_> what? really?
<wallyworld_> with forbidden, the view will not be unlinked anymore either
<wgrant> It's not "Not found"
<StevenK> It isn't?
<wgrant> It's "No projects in this project group use Launchpad for bug tracking."
<wgrant> Or thereabouts
<wallyworld_> so you could click on +filebug, and you should see a page which says, sorry, xxx project does not accept new bugs
<wgrant> In roughly 3 lines of template
<wgrant> Without any logic
<wgrant> wallyworld_: Well, in the exceptional, rare, and usually temporary case of subscription expiration (which usually warrants immediate notification of and action by the project owner), you'll be able to see the +filebug link, click it, select the product, enter a summary, and then be told that your project is in a perilous state
<wallyworld_> for the addition of a few lines of tal
<wgrant> For the deletion of 100 lines of TAL
<wallyworld_> the tal that's there does seem reasonable though for the !uses malone case
<wallyworld_> since people may have the page bookmarked
<wallyworld_> and the page suggests where they might go instead
<wallyworld_> so if one believes we should scrap that nicety, then yes delete the tal, if not then adding the extra few lines for this new case is reasonable
<wgrant> wallyworld_: ProjectGroup:+filebug is hit a total of ~200 times a month
<wgrant> That's already tiny
<wgrant> The fraction of people with bookmarks to +filebug on project groups with no projects that use LP is going to be even tinier
<wallyworld_> hmmmm
<wgrant> (and that 200 hits includes search engines and such)
<StevenK> I was under the impression it was a whole template.
<StevenK> If it's part of one, kill, kill, kill
<wallyworld_> there's a bunch of macros
<StevenK> Excellent, even more things to kill
<wallyworld_> i can look to kill, but i really dislike unilaterally removing functionality with the stroke of a pen
<wallyworld_> without understanding the impact to users
<wallyworld_> but 200 hits a month seems small
<StevenK> With the press of a key even? :-)
<wallyworld_> yeah, that too
<StevenK> wgrant: http://pastebin.ubuntu.com/1216037/
<StevenK> wgrant: Do you disagree with the verbose comment I've added as well as my fix?
<wgrant> wallyworld_: Right, we shouldn't just rip out functionality, but the bit we're removing is unlinked, unlikely to be bookmarked, and the whole page is only viewed a few times a day.
<wgrant> It's an excellent candidate for just being deleted
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-cause-unknownrecipienterror/+merge/125397
<StevenK> wallyworld_, wgrant: No review? :-(
<wallyworld_> StevenK: sorry, was having coffee with bigjools
 * StevenK rings the blood bank
<wallyworld_> StevenK: "due to level or so" does quite make sense to me
<wallyworld_> when you are not otp
<wallyworld_> the comment also says "we are only interested in dropping the assignee out" and yet we then proceed to drop anyone else not in the recipients list, so it's a little confusing as written perhaps
<StevenK> wallyworld_: Yes, exactly. If they aren't in the recipients list, they aren't the assignee and they aren't going to be mailed and can be ignored.
<StevenK> wallyworld_: Due to level or so -- the people in new_subscribers might be BugNotificationLevel.LIFECYCLE -- if we aren't closing the bug, they won't get mailed anyway, but they may leak into new_subscribers.
<wallyworld_> the recipients list contains other people besides assignee so saying that not being in the recipients list equates to not being the assignee doesn't quite addd up for me
<wallyworld_> maybe you could reword the lvel bit to work into the comment somthing along the lines of what you posted just above?
<StevenK> wallyworld_: Do you want to get back onto mumble? Words are obviously failing me.
<wallyworld_> ok
 * wgrant tries to fix translation search timeouts
<StevenK> wgrant: Are you fixing it by removing rosetta?
<wgrant> Hopefully not
<lifeless> hah, cute
<StevenK> wallyworld_: http://pastebin.ubuntu.com/1216114/
<lifeless> wgrant: did you add the new -repo tarball to the download cache?
<wgrant> lifeless: No, I felt I'd pushed my luck enough by uploading to PyPI. But I can if you want.
<lifeless> nope can does
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/catch-incomingemailerror/+merge/125416
<wallyworld_> StevenK: could you monkey patch a test? i guess as you say, it's a trivial change
<StevenK> wallyworld_: I've been looking at the end to end tests, and I don't think so, as I said.
<wallyworld_> np
<wallyworld_> r=me
<lifeless> wgrant: can you coordinate getting oops-tools deployed ?
<lifeless> wgrant: release is done, dependency bumped etc
<wgrant> lifeless: That's just a matter of poking ops, right?
<lifeless> yes
<lifeless> and helping if there should be fallout / conflicts etc.
<lifeless> You'll find their local diff instructive.
<lifeless> I need to go help lynne now is all, or I'd do this.
<wgrant> Well, I know I want to clobber at least one bit of the local diff
<StevenK> wallyworld_: Still here?
<lifeless> wgrant: how did the deploy go ?
<wgrant> lifeless: I was going to wait until we had ops that weren't alone and near the end of their shift
<stub1> So I'm just about finished with the new deployment updates, and I'm now thinking most of it is useless.
<wgrant> stub1: Oh?
<stub1> Because streaming replication will automatically cancel transactions that conflict with WAL that needs replaying
<stub1> So we disable access to the master, killing master connections, and apply the patches. That gets replayed on the slaves and if that transaction happens to conflict with what slave transactions are trying to do, they get cancelled.
<stub1> There is a timeout for how long they are given, which is how long lag is allowed to get.
<wgrant> Hmmm, that's a reasonable point. Have you tried it locally?
<stub> Not yet, just clicked
<stub> By default, that timeout is 30 seconds. Should be easy enough to test by locking a table on the slave.
<stub> bah... can't lock on a slave :)
<wgrant> Well
<wgrant> Select from a table on the slave
<wgrant> Drop a column on the master
<wgrant> See what happens
<wgrant> My local replication setup has mysteriously evaporated...
<stub> Yeah, just need to ensure that select keeps running for longer than the timeout, plus time for my fat fingers.
<wgrant> stub: Well, not necessarily
<wgrant> stub: As long as it's one transaction it should be fine
<wgrant> Where "fine" means "cancelled"
<stub> nah, that would require repeatable read
<wgrant> Since it's not legal to have a subsequent SELECT * in a REPEATABLE READ transaction return fewer columns...
<wgrant> Right
<stub> no serializable on the slaves
<wgrant> But you can get REPEATABLE READ on a slave
<wgrant> Just not SSI SERIALIZABLE, since that requires feedback
<stub> yeah, that should work
<stub> Silly new isolation  levels confusing me :(
<wallyworld_> StevenK: yes
<stub> Yup: FATAL:  terminating connection due to conflict with recovery
<stub> Just need to make sure Storm handles that one :)
<stub> It will need to in any case
<wgrant> That's handy, if it kills the connection rather than aborting the transaction
<StevenK> wallyworld_: I thought we showed OOPS for AJAX timeouts via JS?
<stub> Yeah, except when the connection being killed is my backups ;)
<stub> the connection is killed
<wallyworld_> StevenK: we should do so long as the client js is correctly constructed
<stub> should have clicked earlier with that problem staring me in the face
<StevenK> wallyworld_: Ah ha, so could you look at https://bugs.launchpad.net/launchpad/+bug/925937 ?
<_mup_> Bug #925937: Does this bug affect you: Timeout error popup <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/925937 >
<wgrant> stub: Yeah
<wgrant> stub: There's probably a gotcha here
 * wallyworld_ looks
<wgrant> stub: But it seems like it should work...
<lifeless> so pending schema changes won't cause locks on the slaves?
<StevenK> wallyworld_: I don't want you to fix it, mind you, just figure out why we don't get the OOPS so we can fix that first.
<wgrant> lifeless: They won't cause locks. They'll cause massacres.
<stub> wgrant: Only if they improve the feedback the slaves are able to give the master in future pg releases
<lifeless> which we want to avoid
 * wallyworld_ nods
<stub> At the moment, the slave only sends back enough information to stop vacuum cleaning up records that might still be in use. And even that seems busted at the moment.
<lifeless> stub: so what happens to *new* transactions after the schema change is in the WAL
<lifeless> stub: but not yet applied.
<wgrant> stub: Still, we need the disable/enable stuff to kill off the master connections when we want HA clients to fall back to the slaves
<stub> So the slave has no choice but to either lag, or cancel transactions
<stub> It does both, allowing lag up to the configurable max then cancels connections.
<stub> wgrant: Yes
<wallyworld_> StevenK: from memory, the js for that affects me widget predates work to standardise js error handling, so it should just be a bit of a tweak to make it behave properly
<wgrant> stub: So most of the work is still completely relevant.
<stub> lifeless: All transactions before the WAL is applied are the same
<lifeless> stub: so, it sounds to me like your wrk is very valuable
<lifeless> stub: because the goal was 0 interrupted reads
<stub> wgrant: half of it is. But I've written the whole thing :)
<StevenK> wallyworld_: Right, okay. I'll grab you tomorrow to look it over.
<wallyworld_> StevenK: basically, an ErrorHandler needs to be constructed and used in conjunction with the io call
<wallyworld_> ok
<adeuring> good morning
<wgrant> lifeless: I thought the goal was 0 read interruptions, not 0 interrupted reads.
<StevenK> wallyworld_: Oh, right. That should be pretty easy, then.
<wgrant> lifeless: They're somewhat different
<wallyworld_> StevenK: my statements above are made without looking at the code, just an educated guess
<StevenK> wallyworld_: Sure.
<stub> It means we don't need to disable replication, so less work recovering from a failed upgrade and less things to put us in OMG ring the dba mode.
<wallyworld_> but yes, should be easy
<wgrant> stub: We do need to disable replication if we want to let transactions on the slaves finish.
<wgrant> But I don't think we do
<StevenK> wallyworld_: So my two step plan is to instrument the call so we can actually get an OOPS and then see WTF is going on.
<wallyworld_> yes, good idea
<stub> wgrant: That involves switching pgbouncer to transactional mode
<lifeless> wgrant: the goal is that the new PPA infrastructure be reliable.
<stub> I don't think we have that option, at least on the master, because we are making use of temporary tables
<wgrant> lifeless: That means 0 read interruptions, not 0 interrupted reads
<wgrant> lifeless: We can interrupt reads as long as they can be immediately retried.
<lifeless> ok
<lifeless> I'll let you and stub get back into it :)
<stub> With pgbouncer running in session mode, there is no way to say 'let the connections finish the current transaction, then terminate them'. We would have to add that. I'm not sure if it is possible.
<wgrant> Yeah, that's a good point
<wgrant> Well
<wgrant> The webapp is easy
<wgrant> Once replication is paused lag will increase
<stub> And since faster is better, I think terminating and letting them retry is just fine. These services need to handle network outages, and that is exactly what the update looks like to them
<wgrant> And the webapp will run away from the slave after the last transaction
<wgrant> Right, exactly.
<wgrant> I don't think we need to preserve the transactions.
<wgrant> But we can if we need to
<stub> Haha... most of my work really is unnecessary.
<wgrant> Oh?
<stub> We could run a second pgbouncer in transaction mode. Set all the slave connections to use that.
<stub> Then we run the existing script which shuts down the master pgbouncer
<wgrant> We could
<wgrant> though there's a pull request for per-DB pool_mode
<stub> Yeah, the new approach is nicer and doesn't require sudo loving.
<wgrant> And it's faster
<stub> And I certainly want per-DB pool_mode
<wgrant> And it's also less sickening :)
<stub> Hey, at least I used sudo rather than kill -9 ;)
<wgrant> True, true.
<wgrant> Ah
<wgrant> Slaves don't like it much when there's a recovery.done rsynced from the master alongside their recovery.conf :)
<wgrant> stub: Do you know how the killing works internally?
<wgrant> I guess the RO transactions take the usual minimal locks
<lifeless> i imagine the wal segment
<wgrant> And then recovery checks locks as it goes, killing anything that might conflict
<lifeless> lists the relations that locks are needed on
<lifeless> perhaps implicitly
<wgrant> Right.
<wgrant> I think I have fixed translation searching
<wgrant> Yay
<wgrant> Although one of the new indices is 5GB, which probably pushes sourcherry over the limit
<wgrant> So there goes that idea
<lifeless> if its needed, its needed
<wgrant> Yeah, but if it pushes sourcherry over the edge than I can't do it tomorrow :)
<StevenK> wgrant: It's just an index or a query fix as well?
<wgrant> Both
<stub> wgrant: I think that after you set wal_level=hot_standby, the WAL files include enough information to block or cancel transactions using resources that might change, so lock information at a minimum.
<wgrant> stub: Right, it would make sense if that was the difference between archive and hot_standby
<stub> wgrant: And the RO transactions will take the usual minimal locks so this actually works
<wgrant> Right, exactly
<stub> And because then the hot standbys are using the same well tested code path :)
<stub> wgrant: We still have 170GB free I think. It might set of alerts, but it should fit.
<stub> But given that partition is already at 91%... I suspect the alerts have already been adjusted.
<wgrant> Last I heard there was ~100GB
<wgrant> Ah
<wgrant> So some space has been freed
<stub> Maybe fewer backups at the moment :)
<wgrant> This'll consume about 22GB all up
<wgrant> Heh
<wgrant> True
<wgrant> (about 5.5GB of new indices per instance)
<stub> right
<stub> 2012-09-20 08:28:57 INFO    Outage complete. 0:00:00.913263
<stub> That is local
<wgrant> stub: Have you tried disabling security.py and comments.sql?
<wgrant> That should get it down below 500ms
<wgrant> Unless something's going wrong
<wgrant> No, I'm never satisfied :)
<stub> When do we reset permissions then?
<wgrant> We do it then, just with a faster version of security.py
<stub> We currently only grant permissions live, we don't revoke them live
 * stub tries to recall why that is
<wgrant> I think the only thing we really need to do during the outage is relation ownership changes.
<wgrant> And we avoid revoking during nodowntimes because security.py is run before the code is deployed
<wgrant> I don't believe revocations take any notable locks, but table ownership changes need something hideous
<wgrant> It used to be ACCESS EXCLUSIVE; not sure if that remains true in 91.
<wgrant> 9.1
<stub> Oh, we need to grant permissions in the same transaction as we create new objects
<stub> Which this simplified ignore-the-slave methodology doesn't cope with, but can with a little refactoring.
<wgrant> Ah, you mean we might replicate new objects that require new permissions before we replicate the permissions? Indeed, that's a potential issue
<wgrant> Well, s/potential/real/
<stub> Yeah, window is so tiny we could pretend it doesn't exist... but it is there.
<stub> I need to share the transaction between upgrade.py and security.py, committing at the end.
<wgrant> I think security.py should sensibly run entirely within a transaction now that we've removed cluster mode
<stub> It does I believe
<stub> It makes the failure mode nicer too, all the updates applied or they didn't. Currently we might get schema updates but no permission changes if things explode.
<wgrant> Right
<wgrant> Although that's only an issue in a couple of situations
<wgrant> SECURITY INVOKER functions, Person foreign keys, LFA foreign keys.
<wgrant> I think
<wgrant> But it could still be an issue if we're really unlucky :)
<wgrant> OK
<wgrant> Now this is odd
<wgrant> stub: Ahem
<wgrant> stub: Locks replicate
<wgrant> stub: We still need to disable access
<wgrant> stub: On the master, set a table owner in a transaction
<wgrant> Don't commit
<wgrant> On the slave a couple of seconds later, try to select from that table
<wgrant> It will hang
<wgrant> abort the master transaction, the slave will unhang half a second later
<stub> wgrant: Unless I disable replication
<wgrant> stub: But we still have to kill everybody off before we restart replication if we don't want them to hang
<wgrant> stub: eg. I'm just starting my transaction, and replication unpauses... person's owner changes, and I try to select from it a couple of milliseconds later
<wgrant> Now I time out waiting for the lock
<wgrant> Because some other transaction on the slave was holding person, and recovery was waiting for it
<stub> If you are waiting for the lock, you will get it until replication propagates and you are kicked off.
<wgrant> But I won't be kicked off immediately
<stub> No, it is a little nicer than that.
 * stub wonders what is nicer
<stub> Sucks I have to disable replication in any case
<wgrant> Hey, it's nice and easy and less unreliable this time
<wgrant> Much nicer than the slony days
<stub> Yeah, it is still an improvement
<stub> Just wondering if I should disable slave access for a while in any case.
<stub> I think we can get away with not doing it, and I think it is nicer on the clients, but I'd rather be sure.
<wgrant> I think we have to disable slave access, or we'll run into the same locking issues as normal
<wgrant> It'll automatically undeadlock after 30s, though
<wgrant> Hmm
<wgrant> Thinking
<stub> So real transactions are being run while the WAL is being replayed. I guess if the WAL replay grabs a lock before a slave db connection does, then the slave db connection blocks until the update transaction has finished being replayed.
<stub> If vice versa, the WAL replay blocks until it timesout. And that WAL replay potentially might have locks open.
<stub> I'm not sure if that is reality, but if that seems logical it is enough to go back to disabling replication and slave db connections
<wgrant> Ah
<wgrant> I think it depends on whether all the locks are taken atomically
<wgrant> But they won't be
<wgrant> So it's not safe
<stub> My confusion is because I don't know how transactional WAL replay is.
<stub> yer
<stub> sod it, I'll take the safe route
<stub> code is already there in any case :)
<wgrant> Yeah, we need to do the planned full slave disablement dance to be safe
<wgrant> Yeah
<wgrant> I didn't realise it replicated locks like that
<wgrant> I guess it probably only needs to replicate ACCESS EXCLUSIVEs, since all the slave txns are RO
<wgrant> Yeah, only access exclusives are logged in hot_standby
<wgrant> stub: Ah
<wgrant> stub: It gets messier
<wgrant> Only idle sessions get killed
<wgrant> If there's a query executing, the query gets cancelled and the transaction aborted
<wgrant> But the session survives
<wgrant> So yeah, I think we really want to do the full disable and kill dance
<stub> Because of Storm our code won't care if the session is killed or just the transaction, but yeah.
<stub> oh.. might have that wrong
<wgrant> It will care
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: â
<deryck> looks like maybe rick_h_ was dropped from our stand-up, which is why it was listed as updated.
<deryck> I really do think that was Zoe and Siri and not me. ;)
<rick_h_> I've been kicked out by Siri?!
<rick_h_> come on, just because I don't love the apples :P
<deryck> rick_h_, I replied on email, but I may have misunderstood you -- did you not remember we were on an old webkit, or is it that you still find it hard to believe this name resolution could be the problem?
<deryck> I think you and allenap probably have the same WTF lobe going off. ;)
<rick_h_> deryck: yea, I replied with the test results
<rick_h_> deryck: once that lands it'll help perhaps.
<rick_h_> deryck: I still have a wtf since there were maybe 10 lookups in that diff that was changed
<rick_h_> and in my test I'm counting to 1M and such
<rick_h_> but the effect is demonstrated
<deryck> rick_h_, right, but sinzui confirmed the webkit on ec2 test is 20x slower than post-lucid.
<rick_h_> deryck: I know we're on older webkit, but just the time diff between a namespace lookup 10 times seems it wouldn't be but a handful of ms, but that's what I've not verified
<rick_h_> right
<rick_h_> still, let's say it's a full ms slower per nesting, and we removed 10 cases that were two levels too deep. That saved up 20ms
<rick_h_> and if that was triggering a timeout it still wtf lobes me
<rick_h_> deryck: but yea, always known there was a hit and the jsperf charts in my email show it in IE and FF, looks like Chrome optimizes it away automatically
<rick_h_> and older machines will show it for sure
<deryck> chrome is the best for this, indeed.
<rick_h_> I'm past it, it was a red flag I got namespace happy
<deryck> and without profiling, it's all speculation how much the actual hit is in lucid webkit.
<rick_h_> so pita to debug, still kind of wtf...but moving on atm
<deryck> yeah, I didn't think you were dwelling on it.
<cjohnston> Trying my wording change again until we can get it sorted out to make more substantial changes to participation essential. :-) https://code.launchpad.net/~chrisjohnston/launchpad/part-essential-2/+merge/125501
<sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/incomplete-api/+merge/125515
<jcsackett> sinzui: sure. :-)
<jcsackett> sinzui: looking now.
<jcsackett> sinzui: looks good, r=me.
<sinzui> thanks jcsackett
<jcsackett> and curse your 3000 LoC credit. :-P
<sinzui> jcsackett, you can remove the portlet that suggest Ubuntu packages on project pages: https://launchpad.net/kran
<sinzui> jcsackett, The feature is ineffective now because we have matched the existing project to packages. The top 1,200 packages that need upstream linking require a project to be registered.
<jcsackett> sinzui: ah, cool.
<sinzui> So removing this portlet + view + tests will get you a few 1000 lines
<jcsackett> sinzui: ah, sounds like a plan.
<cjohnston> sinzui: I created a new MP for just the text change.. how do we go about starting the proccess of further investigating the usage of participation essential?
<sinzui> jcsackett, there is a counterpart to this portlet on package pages, it will remain because that is how we get the expedited project registration
 * sinzui looks
<sinzui> cjohnston, I will land you branch
<cjohnston> ty
<deryck> jcsackett, hi.  I have a branch for review if you have the time.
<jcsackett> deryck: sure.
<deryck> jcsackett, thanks!  https://code.launchpad.net/~deryck/launchpad/honor-default-for-spec-sharing-policy-1052521/+merge/125039
<jcsackett> deryck: r=me.
<deryck> jcsackett, awesome, thanks
<sinzui> wgrant, StevenK, wallyworld_, jcsackett, I am summoned to visit the local institution that claims to be preparing my daughter for a place in society. I cannot make our meeting. I will send an email with what I did.
<wallyworld_> ok, have fun :-)
<wallyworld_> i may be a few minutes late myself
<czajkowski> cjwatson: nice mail to -devl found it easier to rea than the blog post
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<cjwatson> czajkowski: thanks
<czajkowski> cjwatson: why is the reason for the fedora patches being inclued?
<cjwatson> czajkowski: either those patches or the moral equivalent are likely to be necessary to avoid our key being revoked
<czajkowski> ahh so theyve done some of the leg work already ?
<cjwatson> And there's no point reinventing the wheel for the sake of it
<cjwatson> Yes
<czajkowski> gotcha
<czajkowski> thanks
<cjwatson> They aren't particularly long
<StevenK> wgrant: Can you create a structsub on https://qastaging.launchpad.net/auditorfixture/+milestone/milestone-foo ?
<StevenK> wgrant: Of open/close, etc ...
<StevenK> cjwatson: I'm guessing r15988 is hard to QA on mawson?
<wgrant> StevenK: Done
<StevenK> And no OOPS. Excellent.
 * StevenK ponders marking r15990 as qa-untestable
<StevenK> wallyworld_: Can you peer at lib/lp/bugs/javascript/bugtask_index.js ? The affects me too stuff is in there, and it looks like there already is an error handler?
<wallyworld_> sure
<wallyworld_> StevenK: so remind me the problem - did the error message that was displayed not contain the oops id? was it a timeout error?
<StevenK> wallyworld_: It was a timeout error with no OOPS id, right
<wallyworld_> StevenK: the error handler does not show the oops id for timeouts
<wallyworld_> only for other errors
<lifeless> wgrant: did you deploy oops ?
<wallyworld_>                 if (o.status === 503) {
<wallyworld_>                     self.showError(
<wallyworld_>                         'Timeout error, please try again in a few minutes.');
<wallyworld_>                 // If it was a server error...
<wallyworld_>                 } else if (o.status >= 500) {
<wallyworld_>                     var server_error =
<wallyworld_>                         'Server error, please contact an administrator.';
<wgrant> lifeless: Argh, no, sorry
<wallyworld_>                     var oops_id = self.get_oops_id(o);
<wallyworld_> StevenK: perhaps it should show the oops id for timeouts
<StevenK> wallyworld_: Is that the error handler for affects me too, or the generic one?
<wallyworld_> StevenK: generic one in client.js
<wallyworld_> affectsmetoo uses it
<StevenK> Oh yah, the OOPS id turns up in AJAX events
<StevenK> Hahahahaha
<StevenK> OOPSes in the body link to oops.canonical.com
<StevenK> OOPSes in the AJAX log link to pad.lv, which redirects to lp-oops.canonical.com
<StevenK> lifeless: ^
<wallyworld_> yes, oops id is in ajax response
<StevenK> Except I can't find the OOPS
<lifeless> they should link to oops.canonical.com then :)
<lifeless> StevenK: ^
<StevenK> lifeless: Obviously :-)
<StevenK> Hmm, the URL is in our config. Pity I don't think you can fetch that in JS
<StevenK> lifeless: I also can't find the OOPS that the ajax log showed
<StevenK> wallyworld_: https://code.launchpad.net/~stevenk/launchpad/ajax-oops-link/+merge/125609
<wallyworld_> StevenK: r=me, good that this is at least correct even if it's hardcoded
#launchpad-dev 2012-09-21
<wallyworld_> wgrant: i thought unclosed <br>tags were valid html5?
<sinzui> no
<wgrant> wallyworld_: They're valid HTML5, but not valid XHTML
<wgrant> And we are a polyglot
<wgrant> Because people parse us with XML parsers
<wgrant> Because SGML is awful, and HTML5 is only mildly better
<sinzui> we will not permit them because we cannot check our own work...and we do not know what the browser will do
<wallyworld_> ok, i'll lp-land a quick fix, didn't see the mp comment before i landed
<wgrant> Formally we treat our markup as an HTML5/XHTML polyglot, and I've fixed most historical issues that prevent parsing as either.
<sinzui> I patch pocket-lint a few months back because it chocked on html5 with html4 entities
<wallyworld_> sinzui: if you're stil lawake, i'd love a quick chat about 1052639
<sinzui> they are the same of course, but old tools do not know that
<sinzui> wallyworld_, okay
<wallyworld_> sinzui: just need to reboot - mumble hates me
<wallyworld_> wgrant: i just created a branch to fix those couple of <br> tags i left in and doing a search finds lots more. i'll fix those while i'm there
<wallyworld_> well, a few anyway
<wallyworld_> many are in comments
<james_w> lifeless, is there a way to refer to the root context in handlebars?
<james_w> I'm looking for a way to do conditional logic based in a partial not on the thing being rendered, but the context in which it is being rendered
<wgrant> wallyworld_: I know there are some in structsub JS
<wgrant> But what others?
<wgrant> Ah, there's one on an edit form
<james_w> and I might be any number of layers deep, and don't want to duplicate that config at all layers
<wgrant> wallyworld_: Beware about fixing the ones in JS
<lifeless> james_w: I don't think so. I mean, we could add / vs ../
<wgrant> wallyworld_: Some of our UI relies on the markup being misparsed
<wallyworld_> wgrant: yes, they are mainly js ones
<wallyworld_> ok, will leave alone then
<lifeless> james_w: I'm not sure its a good idea though, as the compiler is pretty unaware of how deep it is today.
<wgrant> wallyworld_: eg. the structsub thing relied on accidental empty table cells due to invalid markup
<wgrant> Fixing the <br> there might change the nesting
<james_w> lifeless, yeah, it feels wrong, I'm just struggling to find a solution that doesn't multiply data
<james_w> {{#with foo=bar}} would work
<james_w> as would {{>partial foo=bar}}
<lifeless> james_w: passing it down in userspace, as it were?
<lifeless> james_w: that seems like a solid approach to me
<james_w> lifeless, those aren't supported syntaxes currently?
<lifeless> so, remember that ../ is template nesting, not context nesting
<lifeless> james_w: does that help ?
<james_w> lifeless, what do you mean?
<lifeless> you aren't an arbitrary depth down
<lifeless> james_w: anyhow, handlebars does support keyword parameters
<james_w> http://paste.ubuntu.com/1217974/
<lifeless> hmmm, No OOPS Tools Production OOPSes found for 2012-09-20 <- not sure I believe that.
<wgrant> lifeless: Wasn't it upgraded just after midnight?
<lifeless> could be
<lifeless> james_w: so, I'm suggesting
<lifeless> james_w: http://paste.ubuntu.com/1217979/
<lifeless> I don't know if that will work OOTB
<lifeless> but it may
<james_w> it doesn't
<lifeless> you tried ?
<james_w> yeah
<james_w> let me get the error
<james_w> pybars/frompymeta.py in moduleFromSource
<james_w>         code = compile(source, filename, "exec")
<james_w> non-keyword arg after keyword arg (pymeta_grammar__render__195.py, line 8)
<lifeless> ok
<lifeless> so, there is a protocol for calling helpers with kw arguments
<lifeless> it makes sense to me that a template called with extra kw arguments would shove them in the context
<lifeless> I suggest either getting handlebars.js or making it require an option to enable or something
<lifeless> so we don't go spuriously incompatible indefinitely.
<lifeless> james_w: if you think its a sensible approach
 * lifeless grabs a drink before fixing https://bugs.launchpad.net/python-timeline-django/+bug/1050852
<_mup_> Bug #1050852: Error in action handling <python-timeline-django:New> < https://launchpad.net/bugs/1050852 >
<james_w> lifeless, ok
<james_w> lifeless, I won't do that now as I'm just trying things out, but if the experiment is a success then I'll still do it if I haven't found a better way to address this
<lifeless> kk
<wgrant> StevenK: What do you think of the restriction that non-virtual main archives can't be arch-restricted?
<wgrant> That is:
<wgrant>         if self.is_main and not self.require_virtualized:
<wgrant>             return getUtility(IProcessorFamilySet).getRestricted()
<wgrant> It seems like a pretty pointless special case
<wgrant> So I'm going to give Ubuntu primary/partner all restricted archs and remove it, unless you can think of a reason not to
<StevenK> main archives being purpose PRIMARY and PARTNER?
<wgrant> And DEBUG, but yes
<StevenK> Right
<StevenK> Sounds like a good plan
<StevenK> Remove PARTNER while you're at it
<wgrant> Heh
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-897999/+merge/125640
<StevenK> wgrant: I was about to comment on your crimes against indenting when I realised it was code you were deleting.
<StevenK> wgrant: r=me
<adeuring> good morning
<cjwatson> StevenK: totally QAable on mawson - it just got trumped by secure boot stuff yesterday
<cjwatson> StevenK: I'll do it this morning
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: â
<czajkowski> jelmer: can this be closed https://answers.launchpad.net/launchpad/+question/206501
<cjwatson> wow, that rules file is insane
<cjwatson> I'll follow up
<czajkowski> cjwatson: thank you
<cjwatson> wgrant: Do you have any remaining concerns about https://code.launchpad.net/~cjwatson/launchpad/remove-queue-tool/+merge/114464, once process-accepted-bugs-job is deployed and the associated ops work done?  I'm just merging in current devel now
<cjwatson> Because, -1956
<wgrant> cjwatson: Well, we should probably live through a bit of freeze first. It's very likely that the bugs thing will be sufficient to get rid of all the timeouts, but we're pretty screwed if it doesn't.
<cjwatson> Yeah - fortunately we have a freeze now
<wgrant> Right :)
<cjwatson> And if we have this deployed and enabled on say Monday, we'll have that freeze period plus the flush at the end
<cjwatson> Which I think will be enough
<wgrant> Indeed
<vila> hi guys, I found a socks_proxy=socks://lpdev.local:8110/ in my env, any idea where it's coming from ?
<vila> as in: I setup an lpdev instance long ago, but this line is nowhere to be seen in my .bashrc/.profile
<vila> I discover it recently as it breaks a badly isolated test in another project
<wgrant> vila: That's not a standard Launchpad thing.
<wgrant> vila: No tool I know of uses lpdev.local
<wgrant> Or socks_proxy
<vila> wgrant: there was a wiki page mentioning socks at some point (I can't find it anymore), the .local is from avahi and comes from me. But I don't remember ever putting that in any .rc file :-/
<vila> (and all the significant ones are under version control anyway)
<vila> wgrant: note that (from memory) the wiki page was referring to some FF setting, not an env var... but since I *never* used socks myself...
<cr3> hi folks, I'd like to have a project and team deleted from launchpad. should I ask a question to launchpad (itself)?
<czajkowski> cr3: yes plase
<cr3> czajkowski: cheers!
<czajkowski> cr3: need the list deleted so just waiting on that to happen
<cr3> czajkowski: thanks, no rush
<cr3> czajkowski: this is mostly about keeping Launchpad tidy :)
* adeuring changed the topic of #launchpad-dev to:  http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<sinzui> jcsackett, how goes to demolition of the suggest ubuntu packages portlet?
<jcsackett> sinzui: slowly, though not because of the task itself. i have had a rocky-ish day so far in terms of other things needing doing.
<sinzui> I keep getting locked out of my computer bug the screen-lock
<jcsackett> sinzui: that sounds like a pain.
<sinzui> I just disabled it so I can talk without needing to kill procs or reboot
<jcsackett> sinzui: dig.
<sinzui> jcsackett, did you see Bug #105376 ? There is a db column that can be removed too I think
<_mup_> Bug #105376: Kubuntu 7.04beta Alt. CD install not create a new user. <debian-installer (Ubuntu):Fix Released by brian-murray> < https://launchpad.net/bugs/105376 >
<sinzui> jcsackett, did you see Bug #1053765 ? There is a db column that can be removed too I think
<_mup_> Bug #1053765: Suggest ubuntu packages portlet has nothing to do <package-link> <projects> <tech-debt> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/1053765 >
<sinzui> I missed a digit
<jcsackett> sinzui: i didn't see that bug. thanks.
<jcsackett> ah, i see you updated my card as well.
<jcsackett> sinzui: do we want to obliterate the portlet, period? or just the part that's trying to encourage linking if not known?
<sinzui> just the suggestions
<jcsackett> ok; that's what i was assuming, but i realized it could be meant to remove all of it.
<sinzui> we still want to show the 5 most recent packages built from the project's releases
<jcsackett> sinzui: dig.
<wallyworld_> sinzui: hi, with that new getSHaredProducts branch, i did not return distros because of the lazr restful issues with heterogeneous results. i was thinking about a separate api for distros
<wallyworld_> also, there are some comments in the bug about teams vs users
<wallyworld_> the idea is that user is removed from teams first, so we only need the api to check for direct shring for the user
<wallyworld_> ah hang on, you are talking about teams for maintainer and driver
<wallyworld_> i do need to fix this then
<wallyworld_> and you also want commercial admins to get back all results, not just admins
#launchpad-dev 2012-09-22
<lifeless> ahha
<lifeless> https://oops.canonical.com/static-reports/OOPSTOOLS-PROD-2012-09-21.html
<lifeless> nice that there were two soft time outs, but 0 shown in the details section
#launchpad-dev 2012-09-23
<lifeless> james_w: +  var template = CompilerContext.compile("{{#goodbye cruel='CRUEL' times=12}}world{{/goodbye}}");
<lifeless> james_w: is what handlebars.js supports
<lifeless> james_w: I *thought* I supported that for pybars, extending it to support passing context refs should be doable
<cjwatson> Hmm.  I'm pretty sure my latest branch will break derived distro creation, but no test failures ...
 * cjwatson will have to write something there to check
<lifeless> wgrant: / StevenK: Your thoughts solicted on https://launchpad.net/~yavdr/+archive/main/+sourcepub/2680975/+listing-archive-extra
<lifeless> '
<lifeless>     diff from 304.43-0yavdr0~precise to 295.75-0yavdr1~precise (139.1 MiB)
<lifeless> '
<lifeless> downgrades? wtf?
<lifeless> see #launchpad...
<czajkowski> ello
<StevenK> wallyworld_: You have two revs of QA, and then we can deploy.
<wallyworld_> yes, doing them as we speak
<lifeless> wgrant: around ?
<wgrant> lifeless: Hi
<wgrant> lifeless: What's the issue with those builds? They're trying to upload an older version.
<lifeless> wgrant: yes, but LP seems to have let them...
<wgrant> lifeless: Right, so it sounds like they deleted the source but not the binaries
<wgrant> Which probably means they deleted the source before the binaries were published
<wgrant> In that 5 minute window
<lifeless> so, see #launchpad; are they wedged?
<wgrant> They should be able to redelete the old source
<wgrant> Which will hopefully take the binaries with it this time
#launchpad-dev 2013-09-16
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/add-new-processor-api/+merge/185697
<StevenK> stub: https://code.launchpad.net/~stevenk/launchpad/db-add-processor/+merge/185700 when you have a tick
<stub> StevenK: Surprised we didn't need that earlier.
<stub> StevenK: You don't want to add default value and NOT NULL Processor.restricted? It is only 11 rows... Similarly the other new columns - largest table contains 550 rows.
<StevenK> stub: NOT NULL will be added in -1
<StevenK> stub: The plan is to populate them shortly after that patch is rolled out
<wgrant> You can do the NOT NULL for processor if you want, since the app doesn't create them
<wgrant> But not for builder
<StevenK> We don't touch builder
<wgrant> Oh right, builder already has processor
<StevenK> Yeah, it's DAS and ArchiveArch
<wgrant> But DAS.processor has the same thing
<wgrant> And ArchiveArch
<wgrant> If you make them NOT NULL initially the test suite will go boom
<StevenK> Yes, which is why the -1 DB patch sets them as NOT NULL
#launchpad-dev 2013-09-17
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bm-buildercache/+merge/185968
<StevenK> wgrant: http://pastebin.ubuntu.com/6117968/
<wgrant> StevenK: headerspan still confuses me, not least because person !== null surely makes more sense.
<wgrant> headerspan seems to look completely different depending on whether it's a draft or not.
<wgrant> Perhaps construct it independently in those two cases.
<wgrant> But otherwise it's looking much more sane.
<StevenK> wgrant: http://pastebin.ubuntu.com/6117982/
<wgrant> +    var headerspan = null;
<wgrant> Also consider headerspan = Y.Node.create('<span>Comment by <a></a> on <span></span></span>')
<wgrant> Roughly as readable as a template, without the overhead of using an actual template engine.
<StevenK> wgrant: Then we don't need the extra span
<StevenK> wgrant: I wasn't sure how JS was about if (...) {\n var blah; } else { var blah; }
<StevenK> Oh, we do need the span, so we can use .set(), right
<wgrant> StevenK: They should both end up in function scope.
<wgrant> I don't think ECMAScript has block scope.
<StevenK>       81: 'headerspan' is already defined.
<StevenK>       84: 'headerspan' used out of scope.
<StevenK>       87: 'headerspan' used out of scope.
<StevenK> From that lovely thing, make lint
<wgrant> Bah
<wgrant> OK, var headerspan;
<wgrant> But uninitialised > null;
<wgrant> So
<wgrant> Now this code is in a form that I can vaguely understand what it does!
<StevenK> wgrant: http://pastebin.ubuntu.com/6117991/
<wgrant> StevenK: Why do you insert before the next row, rather than after the matching row?
<StevenK> wgrant: To handle multiple comments on one row
<StevenK> So they're shown in order
<wgrant> Would it make more sense to have a comment container row that then just has a sequence of comment divs for that line within it?
<StevenK> Hmmm, do I really want to rewrite this again? :-)
<wgrant> Won't the IDs conflict if there are multiple comments on a single line?
<StevenK> No, we only set ids for draft comments now
<wgrant> Ah
<StevenK> Because they are only rows we are going to want to find again
<StevenK> Published comments are displayed, but are static
 * StevenK sighs
<StevenK> if (draft === true) { .... if (draft === true) { ... } }
<StevenK> wgrant: r=me
<wgrant> Thanks
<RoelV> is there a way to upload files quickly to launchpad bug reports without using http? ftp maybe?
<cjwatson> HTTP is a better file transfer protocol than FTP anyway ...
<RoelV> yes but launchpad easily fails on it
<RoelV> very easily sometimes
<RoelV> and there is no recovery eother
<cjwatson> You'd probably do better to quote an OOPS ID or something
<cjwatson> It's possible to attach files using the API; it's still over HTTPS, but a somewhat different path from the web UI
<RoelV> cjwatson, how does it work exactly? command line driven?
<cjwatson> https://help.launchpad.net/API/launchpadlib
<cjwatson> However, like I say, if you're hitting an OOPS you should quote it before wasting time on different methods
<RoelV> cjwatson, ok thanks. Next OOPS I get I'll try and come back
<cjwatson> Ursinha: How's bug 1201485 going?  Just wanted to make sure that we'd have it in time for use before release
<_mup_> Bug #1201485: Need to import translations for the unity daily builds <langpack-o-matic:Triaged> <Launchpad itself:In Progress by ursinha> <Ubuntu Translations:Triaged> <https://launchpad.net/bugs/1201485>
<Ursinha> cjwatson, I'm writing the final tests, should put it for review today
<cjwatson> Brilliant :-)
<Ursinha> :)
<cjwatson> seb128 will be your friend
#launchpad-dev 2013-09-18
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/use-new-processor/+merge/186228
<wgrant> StevenK: k
<StevenK> wgrant: Thanks, it'll land after 49-0 hits devel.
<wgrant> Yes
<StevenK> wgrant: Microservices?
<Ursinha> wgrant, cjwatson, https://code.launchpad.net/~ursinha/launchpad/bug-1201485/+merge/186305
#launchpad-dev 2013-09-19
<StevenK> stub: https://code.launchpad.net/~stevenk/launchpad/db-no-not-null-pf/+merge/186461
<StevenK> stub: And sorry for the sampledata diff being fracking enormous
 * stub looks
<stub> I never review sample data changes, so don't put them there just on my account ;)
<stub> Hmm.... if I rename the sample data files zz_sampledata.sql, will they always be at the end of the diff?
<StevenK> Not sure about that
<stub> r=stub
<stub> I would need to rename the directory
<stub> meh.... can't be arsed
#launchpad-dev 2013-09-20
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/testfix-for-not-null-processor/+merge/186712
<StevenK> wgrant: My plan is to land that against devel with [testfix], but then I need to get it from devel/stable into db-devel somehow
<wgrant> StevenK: You'll probably need to merge it manually into db-devel
<wgrant> AFterwards
<wgrant> https://code.launchpad.net/~wgrant/launchpad/bfjb-no-interactor/+merge/186477
<StevenK> wgrant: BFJB will soon die, or BI will?
<wgrant> StevenK: BI
<StevenK> You only just added it
<wgrant> Yes :)
<StevenK> Has your plan changed, then?
<wgrant> It was intended as an intermediate step while I ripped the slave stuff out of Builder.
<StevenK> Right
<wgrant> It let me thread through an object with the builder, slave, behavior as state, rather than having to thread through those as separate arguments to places that needed them.
<StevenK> wgrant: r=me
<wgrant> I shall land it once you've fixed the world.
<StevenK> Right
<StevenK> I wonder if I can construct a PQM message to just merge stable into db-devel
<wgrant> StevenK: Sure, --public-location
<wgrant> That's how I do the db-stable -> devel merge
<StevenK> Bah
<StevenK> ERROR: lp.buildmaster.tests.test_interactor.TestSlave.test_abort
<wgrant> StevenK: Ensure that your python-launchpad-buildd is up to date
<StevenK> wgrant: That's from buildbot
<wgrant> Ah
<StevenK> Force it?
<wgrant> I'd say so
<StevenK> wgrant: bzr pqm-submit --public-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel -m '[testfix][r=stevenk][no-qa] Manually merge devel r16769.'
<wgrant> StevenK: Right, from a devel branch.
<StevenK> Yeah
<StevenK> Given test_abort was the only failure, I'm happy enough for db-devel to build while devel is again.
<StevenK> wgrant: The world is fixed, but you'll probably have to wait for the poller. We'll deploy up to your branch on Monday, populate the new columns, and then FDT 49-1 on Monday night.
<SteveA> good morning from London. Can anyone tell me where I can get an SVG of the official Launchpad.net logo ?
<cjwatson> SteveA: Could be extracted from lp:launchpad lib/canonical/launchpad/images/src/launchpad-gem.svg, I think
<SteveA> thanks colin, I'll take a look :-)
<cjwatson> http://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/canonical/launchpad/images/src/launchpad-gem.svg   in case a direct link is useful
<SteveA> cjwatson: awesome, that's exactly what I was looking for. Thank you!
<cjwatson> you're welcome, hope things are going well :-)
<SteveA> better than ever. I'm living in London now, so if there's an opportunity to go for a $beverage, I'm up for it
<cjwatson> I may or may not be down around release week (17 Oct), not sure yet
<SteveA> I'm around early that week, in Nice France towards the end
 * smartboyhw is grateful that http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/870 passed, phew
<smartboyhw> wgrant, how do I push to a branch I set up in Launchpad QA Staging instance?
<cjwatson> smartboyhw: Do you need to?  To QA this, you should just need to check that the UI looks right.
<smartboyhw> cjwatson, I don't know where to find that sort of branch?:P
<cjwatson> start from https://qastaging.launchpad.net/~, go to Code, find a branch you've pushed before
<smartboyhw> cjwatson, yes
<cjwatson> Oh, sorry, needs an empty branch
<smartboyhw> But I thought the QA specifies that it needs an empty branch
<smartboyhw> Anyhow, found one!
<cjwatson> Yeah, I was just going to say that it so happens I have one
<cjwatson> https://code.qastaging.launchpad.net/~cjwatson/language-selector/check-all => "bzr push --use-existing-dir lp://qastaging/~cjwatson/language-selector/check-all" for me
<cjwatson> (which incidentally is probably also the pattern for pushing that kind of branch)
<cjwatson> Anyway, qa-ok
<smartboyhw> cjwatson, qa-oked
<cjwatson> Great, thanks for your work
 * smartboyhw might fix trivial bugs for LP in the future
<cjwatson> I expect it'll be deployed next week
<smartboyhw> More
<smartboyhw> :)
#launchpad-dev 2015-09-14
<cjwatson> apt by-hash is going to need at least https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798919 fixing before we can use it
<cjwatson> I believe I have all the LP changes done for InRelease, but I need to get some internal mirroring etc. fixes landed first.
<cjwatson> (All proposed, so I'll bug a webop once I catch one)
<wgrant> Can we actually deploy mirror fixes atm?
<wgrant> There was that RT that Adam said might have been progressed or something.
<cjwatson> Is this https://rt.admin.canonical.com/Ticket/Display.html?id=83847 ?
<cjwatson> Ha, I think I missed the existence of that charm
<cjwatson> Is canonical-magic-mirror not being used any more?
<wgrant> magic-mirror is used for the split
<wgrant> But we also need to verify that the charm syncs InRelease last.
<wgrant> As it wasn't doing with Translations-* until that ticket.
<cjwatson> Right
<wgrant> The charm doesn't do any weird stuff like magic-mirror, just the two-stage sync.
<wgrant> cjwatson: Did you look into Tarmac git support in any depth?
<wgrant> I don't intend to excise bzrlib's command processing etc. at this stage.
<cjwatson> wgrant: Only to the extent of satisfying myself that it isn't hard and doing some extra API exports for it
<cjwatson> zyga said he was working on it, but I think we should time out on that soon.
<cjwatson> I wonder where https://pastebin.canonical.com/139395/ comes from
<cjwatson> There are similar files in puppet, but not ports-sync.
<wgrant> cjwatson: I also intend to add BugBMP tomorrow.
<wgrant> Initially populated by BugBranches being added, but also manageable explicitly.
<wgrant> Eventually the diff generator should ask turnip to regexp the new commits to link bugs.
<wgrant> I think that's the only reasonable approach for git, do you agree?
<wgrant> cjwatson: Hm, I didn't realise ports-sync was different.
<wgrant> cjwatson: It may be manually maintained; there are few ports mirrors.
<cjwatson> BugBMP etc.> Agreed.
<cjwatson> wgrant: Yeah, appears to be (see #is)
<wgrant> Sorry, busy collecting popcorn and reading too many channels.
<wgrant> Haven't caught up.
 * cjwatson checks whether cdimage's two-stage sync handles InRelease and finds he did that in 2011
<wgrant> Heh
<wgrant> That's an easy one, then.
<cjwatson> Also I checked that I couldn't reproduce anything like the original apt InRelease security problems with precise and trusty
<cjwatson> (Indeed, precise just has InRelease disabled with a big hammer)
<wgrant> Oh, I didn't realise it was disabled.
<wgrant> Since Debian was using it by that point.
<wgrant> Maybe it was disabled while the sensible gpgv usage was fixed.
<cjwatson> I guess our apt was a while out of sync.
<cjwatson> Right.
<wgrant> Rather than trying to parse it out manually.
<cjwatson> In trusty, if you try tricks like appending an InRelease file, then it ignores the unsigned portions of the file
<cjwatson> Which feels a bit odd, but not exploitably so
<wgrant> That sounds like it's doing the right thing.
<wgrant> It is a little odd, and there is an argument to be made for failing on non-whitespace outside the sig, but it doesn't really worry me.
<wgrant> I don't remember how I found it the first time, but I'll have a poke around the code too this week.
<cjwatson> Yeah.  Thanks.
<cjwatson> On apt by-hash, I think we probably can in fact do most of it without the bug above being fixed, just not the Acquire-By-Hash flag in Release.
<wgrant> Yep
<wgrant> The fallback is rather unpleasant, but we have little choice for at least a couple of years.
<cjwatson> It'll need an apt-ftparchive backport (or we could do it in LP directly, but I don't think it's worth it).  Fortunately a small one.
<wgrant> Oh, I didn't realise a-f had support.
<wgrant> How does it handle GC?
<cjwatson> Keeps three by default.
<wgrant> I'd be doing it in LP.
<wgrant> Because we need to do it for NMAF anyway.
<cjwatson> True.
<wgrant> It's not dissimilar from the Release code which we already reimplement.
<cjwatson> I think we want finer-grained control than a-f offers; it only lets you control the count.
<wgrant> We currently let a-f write directly to dists, but that's only because it's convenient.
<cjwatson> (APT::FTPArchive::By-Hash-Keep)
<wgrant> It would be entirely reasonable to have it write to a temporary directory, then we grab the files and do whatever we want with them.
<wgrant> I prefer to keep our dependency on a-f to a minimum.
<cjwatson> Yeah, I guess so.
<lifeless> cjwatson: since you're hacking on email notifications
<lifeless> cjwatson: there is one bug (I don't have it to hand) that would make me so so so super happy
<lifeless> cjwatson: which is that LP always sends mail to *me* even if I'm only indirectly subscribed
<lifeless> cjwatson: which breaks GMail 'mute'
<wgrant> lifeless: Just bugmail?
<wgrant> There's a bug about that, let me find it.
<lifeless> wgrant: bugmail is ~99% of my LP mail
<lifeless> wgrant: so even if its not *just*.
<lifeless> would still be happy happy joy joy schnaaaake time.
<lifeless> Night all.
<wgrant> lifeless: Oh sure, just checking there were no other cases.
<wgrant> If we fix one source and you still whine, that's not good :)
<wgrant> https://bugs.launchpad.net/launchpad/+bug/138592
<mup> Bug #138592: Bug notifications have personal To: header but aren't personal <email> <lp-bugs> <notifications> <Launchpad itself:Triaged> <https://launchpad.net/bugs/138592>
<cjwatson> lifeless: Mm, that wouldn't be too hard, I guess.  Some code review stuff already does something kind of similar (well, it actually does a weird thing where it tries to work out which of the people the notification's being sent to that you're allowed to know about, but I see even less justification for that for bugs than for code)
<cjwatson> Code at least includes the MP address
<rpadovani> hey all :-) There is a way to login to local installation with a non-admin user?
<cjwatson> rpadovani: Use utilities/make-lp-user
<rpadovani> ty!
<cjwatson> (You'll want to start a local keyserver first, probably - utilities/start-dev-soyuz.sh is overkill for that but works)
<cjwatson> wgrant: Answers should behave the same way, I think.
<wgrant> Hm, indeed.
<rpadovani> cjwatson, o/ I found a very trivial bug to fix, so I wrote the one line change needed, but I'm a bit confused about how writing the related test. To don't bother you right now, I wrote all in the description of the MR - when you have some spare time, could you please take a look? Thanks so much :-)
<rpadovani> https://code.launchpad.net/~rpadovani/launchpad/unhide-comments/+merge/270950
<cjwatson> rpadovani: You'll want to add an optional comment_owner argument that's passed to makeBugComment as owner=, like TestBugHideCommentControls.getContext just below.  Then extend TestMessageVisibilityMixin with a test saying that the comment owner can see the comment.
<rpadovani> cjwatson, okay, thanks, I try
<rpadovani> well, I pushed the test, but lp doesn't want to update my branch information. Time to study I think, I'll take a look later
<cjwatson> rpadovani: I'll keep rescanning it until it works.
<rpadovani> thanks
<cjwatson> rpadovani: In fact, it's there now.
<rpadovani> oh, great
<rpadovani> hi cjwatson, thanks for your time :-) I have a couple of questions about your review: you wrote hidden comments need admin style - is that the one with gray background? If yes, it's already present, without having to edit BugComment.show_for_admin
<rpadovani> Another question: how stories are supposed to work? I write what is expected and then write some code that should demonstrate that?
<cjwatson> rpadovani: Oh, right, the implementation of show_for_admin is different from how I remember.
<cjwatson> rpadovani: Stories *are* tests.
<cjwatson> The indented stuff is run.
<cjwatson> https://docs.python.org/2/library/doctest.html
<rpadovani> oooh, I see! How much things I have to learn, thanks :-)
<cjwatson> (They are mostly very irritating and we prefer not to write more of them, but it's OK to extend existing ones a little bit if there isn't an immediate alternative.  Rewriting as unit tests is usually better.)
<cjwatson> rpadovani: I think a pagetest (== .../stories/...) addition is a good idea here even if you don't need to change show_for_admin.
<rpadovani> ok, great, I add it, thanks
<mapreri> JOOI (and OT): do you think you'll be able to move to py3 in only 5 years?
<cjwatson> mapreri: Heh, hopefully.  Every so often we shave off another bit of the problem.
<mapreri> looks like lot of pain from an outsider pov
<mapreri> good luck :)
<cjwatson> After we move off buildout, we'll be able to upgrade to a current ZTK, and then it might actually be possible to see how terrible the situation is.
<cjwatson> Right now it's only possible to attack in the abstract, which isn't very rewarding.
<cjwatson> Also, we're still mostly deploying on 12.04, and Python 3.2 wasn't a brilliant porting target.
<mapreri> ic
<cjwatson> Why do you ask?
<rpadovani> sorry to bother again, how could I run the story test? Using python -m doctest -v lib/lp/bugs/stories/bugs/xx-bug-hidden-comments.txt doesn't work
<mapreri> cjwatson: just curiosity (sometimes i really act like a kid, with my curiosity) :)
<cjwatson> rpadovani: bin/test -vvct lib/lp/bugs/stories/bugs/xx-bug-hidden-comments.txt
<cjwatson> (or a regex that matches that)
<rpadovani> thanks
<cjwatson> mapreri: OK, just wondering about the choice of five years
<mapreri> cjwatson: py2 is doomed for EOL around 2020, you know...
<cjwatson> Oh right
<cjwatson> It's not a timeframe I've been worrying about much
<cjwatson> Too many closer ones :)
<mapreri> eheh
<cjwatson> I did go through recently and get rid of most of our use of class advice, which was a multi-thousand line patch needed for py3
<cjwatson> So we're not ignoring it :)
<mapreri> nice :)
<rpadovani> cjwatson, how can I use user_browser.open() to log in with a different user? My edits broke test in xx-bug-hidden-comments.txt at line 40 because now the comment is visible - to test if a ordinary user doesn't see the hidden comment, I need to change user - how? (or, what can I read to understand the solution?)
<cjwatson> rpadovani: You'll need to get hold of a different browser instance that's authenticated as a different user.  The pagetests often rely on the sample data shipped with Launchpad, so the easiest way is probably something like   >>> test_browser = setupBrowser(auth="Basic test@canonical.com:test")
<cjwatson> Then you'll want to test that the comment appears for the non-admin user that posted the comment (with basically the same set of tests we perform for admin users), and doesn't appear for a different non-admin user.
<rpadovani> okay, thanks
<cjwatson> lib/lp/testing/pages.py is the file that sets up things like user_browser
<rpadovani> cjwatson, I pushed new stories - thanks for your suggestions, I hope to become more independent with time ;-)
<mapreri> rpadovani: maybe assign yourself the bug?
<cjwatson> mapreri: not required
<cjwatson> (I mean, neater perhaps, but the QA bot is about to do so anyway)
<cjwatson> rpadovani: LGTM, thanks, landing
<mapreri> goody bot
<rpadovani> cjwatson, thanks, I'll take a look to another bug then - usually I assign bugs to myself only when I'm sure I know how to fix them, to don't block any other user that wants to fix it
<cjwatson> Reasonable.
<blr> morning
<cjwatson> rpadovani: Have you looked at your buildbot test failures?
<cjwatson> rpadovani: Some are spurious, but the failure in lib/lp/bugs/stories/bugs/xx-bug-hidden-comments.txt is real, which is weird because I thought you said you'd run that.
<wgrant> Morning.
<cjwatson> rpadovani: Ah, you need to fix BugTaskNavigation.traverse_comments too
 * cjwatson assumes rpadovani has gone to bed, so fixes locally and runs the bugs tests
<wgrant> cjwatson: Nothing appeared anomalous DB-wise overnight?
<cjwatson> wgrant: Nothing I saw, no.
<wgrant> Lovely.
<wgrant> So my plan for BugBMP is that in the bzr case it will be tied exactly to BugBranch while the MP is open.
<wgrant> Which is slightly messy, but preserves the existing behaviour and hopefully makes things relatively unconfusing.
<cjwatson> Yeah, I was wondering how you were going to make that not weird ...
<wgrant> We can probably remove the UI to link a branch directly later on, and need to change bug notifications.
<wgrant> I'm very open to suggestions if you have any...
<cjwatson> So you'd be able to edit BugBMP, but in the bzr case it would push it through to BugBranch?
<wgrant> But I think BugBMP is the only approach that makes sense, so we have to make it usable somehow.
<wgrant> Right.
<wgrant> Or maybe it only resyncs when the preview diff is updated.
<cjwatson> Yeah, none of my half-thoughts about how to do it on GitRef directly have made any kind of sense.
<wgrant> Hmm.
<cjwatson> If it only resyncs when the preview diff is updated, then editing BugBMP is difficult.
<wgrant> True.
<cjwatson> I don't think that makes sense.  After all, today, if you link a branch to a bug then that's reflected immediately in the BMP.
<cjwatson> Without updating a diff.
<wgrant> Yeah.
<wgrant> Well.
<wgrant> No, maybe not.
<wgrant> If we remove the BugBranch UI...
<wgrant> Then you can only link by pushing a new rev, which will update the diff, or by clicking the link on the BMP directly, or by using the BugBranch API.
<cjwatson> That would also make it impossible to see bzr branches that fix bugs unless they've had MPs proposed.
<cjwatson> Which, granted, won't work in the git case.
<cjwatson> (Although it does work on GitHub ...)
<wgrant> Indeed.
<cjwatson> We could do a BugGitRepository with very weak links.
<wgrant> I don't know how GitHub decides what is relevant.
<cjwatson> I'm not sure how pulling from one branch to another would work.  It would have to be tied into merge detection somehow.
<cjwatson> Otherwise everything is attached to everything.
<wgrant> Maybe it's only the first time each rev appears.
<wgrant> Right, exactly.
<wgrant> The LP logic for that is very weird.
<cjwatson> And there are certainly some branches with implausible numbers of bug links as a result.
<wgrant> I did at one point know why trunks sometimes got bugs linked.
<cjwatson> It might be worth some effort working out GH's logic.
<wgrant> I can't remember now, though.
<cjwatson> First time each rev appears doesn't seem a terrible start, but then what if you rename the branch
<wgrant> Yup, exactly.
<wgrant> Will poke GitHub.
<cjwatson> Well, we can fairly cheaply work out which branches are ancestors of which other ones in a repository
<cjwatson> That's near enough how our merge detection works
<wgrant> Yep, but what happens if you have two trunks?
<cjwatson> So it could just be any links from branches that aren't merged
<cjwatson> Doesn't matter whether they're trunks or not
<wgrant> What does "that aren't merged" mean, if not merged into trunk?
<cjwatson> The interesting commits are the ones that are unique to a branch
<cjwatson> Now, the trick is handling the case where a branch is merged into a trunk and then deleted
<cjwatson> Couple of possible approaches to that
<wgrant> Or where I push a branch, then push a superset of the same branch to a different name because the first name was wrong.
<cjwatson> One promising one might be to have merge detection remember that everything older than the mergepoint is uninteresting for commit scans
<cjwatson> Maybe
<cjwatson> It's hard to tell the difference between your case and the case of the creation of a new trunk.  Whatever a trunk is.
<wgrant> Exactly :)
<cjwatson> (Anything that relies on us knowing what a trunk is is probably wrong ...)
<cjwatson> Seems like a thing worth trying out on GH, anyway.
<wgrant> Yep, will do.
<wgrant> cjwatson: Are you still looking at that testfix?
<cjwatson> Yes
<cjwatson> Nearly done, just trying to get the blasted thing to scan before pushing the fix rev
<wgrant> Hah
<wgrant> Thanks.
<cjwatson> lp.bugs passes now though
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-unhide-comments/+merge/271043
<wgrant> Hmm.
<wgrant> I'm not actually sure I like randoms being able to unhide their comments, but I guess until we have a way to fix mistakes it's awkward.
<wgrant> So it'll do.
<cjwatson> Yeah, it's not unproblematic.  But I guess that in cases of serious abuse we'd suspend accounts anyway.
<wgrant> Right, but it is open to other more subtle abuse.
<cjwatson> And they can always repost, it's not like it really helps much to not let them unhide
<wgrant> Making parts of the conversation disappear and then reappear when it's convenient.
<wgrant> cjwatson: Did you prefer LaunchBag over self.request deliberately?
<cjwatson> I didn't know that API well; I noticed that self.request was =None in Navigation's constructor, and found ILaunchBag used elsewhere
<wgrant> Ah, OK, sounds reasonable.
<cjwatson> Maybe comment hiding/unhiding should go in the activity log.
<wgrant> No.
<wgrant> Spam is a thing.
<wgrant> We should fix the hiding silliness to be admin-only eventually.
<wgrant> Feel like fixing the rest of that traversal check while you're there?
<wgrant> It's moderately annoying for us, and it's the next line...
<cjwatson> Sorry, I'm nearly asleep.  What's the problem with it?
<cjwatson> Oh, it doesn't allow registry does it
<wgrant> Right, it should probably use Bug.userCanSetcommentVisiblity
<wgrant> +i
<cjwatson> So should get_visible_comments, then
<wgrant> Ah, get_visible_comments doesn't allow project-privileged users, it seems.
<wgrant> Which is arguably correct from a spam perspective.
<wgrant> But awkwardly inconsistent.
<cjwatson> So they can hide spam, but can't see that they've done it?
<wgrant> Apparently.
<wgrant> cjwatson: Ah, so GitHub doesn't actually track this.
<wgrant> cjwatson: The PR page doesn't directly list the issues, only by linkifying them in commit messages.
<wgrant> And the issue page tells you that a bug was closed by merging into the default branch, or that it was referenced in a commit (not a branch)
<wgrant> Of course in Git you don't need to know the branch, just the repo, and it's always the same repo.
<wgrant> Well, on GitHub it's always the same repo.
<cjwatson> Ah, right, the commit link has no ref context
 * wgrant tries a cross-repo reference.
<wgrant> We can't be quite so simple, as we have multiple repos.
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-unhide-comments/+merge/271043 brushed up slightly
<wgrant> It seems to only show the first time it saw each commit.
<wgrant> If I reference wgrant/test#5 in a commit in wgrant/test2, the issue shows that.
<wgrant> But subsequently pushing that same commit to wgrant/test doesn't show anything, unless it causes the issue to be closed.
<wgrant> cjwatson: Thanks, looks good.
<cjwatson> Thanks, landing.
<wgrant> Hmmmmmm.
<wgrant> Trying to think how this should work.
<wgrant> I guess it's not so bad if we don't link from the repo to the fixed bugs.
<wgrant> The list on a bug will not grow large, just the list on the repo.
#launchpad-dev 2015-09-15
<cjwatson> Yeah, I don't think the list on the repo is that useful.
<wgrant> (the repo -> bug link already exists if you go through the commit history, anyway)
<cjwatson> And for refs, it can be linkified from recent commit messages.
<cjwatson> Usually.
<cjwatson> Once we have a convention I imagine we could even hack our cgit to support it.
<wgrant> Right, exactly.
<cjwatson> Were we just going to apply the LP: regex for changelogs?
<wgrant> So I guess we grow a BugGitRepository which is unique (commit_sha1, bug)
<wgrant> I hadn't really thought about that yet.
<wgrant> My main goal was to get it possible to have Git MPs with bugs, which is the main blocker for us.
<wgrant> Whether manually linked or otherwise.
<cjwatson> I wonder what tarmac would do with this.
<wgrant> The MP bug harvesting is then actually separate from BugGitRepository.
<wgrant> What do you mean?
<cjwatson> It currently expects to be able to do ... oh, it's actually fetching the bug list from bzrlib directly
<wgrant> Because the MP should grab any bugs referenced from commits that it involves, rather than looking at BugGitRepository at all.
<wgrant> Oh, is it?
<cjwatson>                     rev = self.bzr_branch.repository.get_revision(rev_info[0])
<cjwatson>                     for bug in rev.iter_bugs():
<wgrant> Huh, I didn't expect that.
<cjwatson> An exotic approach.
<wgrant> I guess that makes sense given the LP list isn't always reliable.
<cjwatson> Maybe they didn't trust LP, indeed.
<wgrant> But I do occasionally forget to --fixes and link manually on LP, which would break in that world.
<cjwatson> Anyway, if a sensible thing were exposed on BMP's API, that would be better.
<wgrant> Perhaps that is fine, though.
<cjwatson> Which is easier than coming up with a sensible thing for a branch.
<cjwatson> Since there's an implied stop point.
<wgrant> I'm weighing up whether to continue to allow manual linking at all.
<wgrant> For MPs, at least.
<wgrant> But that would mean we'd need automatic linking before this would be useful at all.
<wgrant> Which means bikeshedding the commit message format.
<cjwatson> Yeah, I assumed we'd bikeshedded this eight years ago and would just use that :)
<cjwatson> Or at least have it as a valid option, so that package repositories can be sensible.
<cjwatson> Anyway, I must sleep, happy to debate further in the morning.
<wgrant> If by sensible you mean wrong, then indeed :)
<wgrant> Well, I guess if we don't autoclose then it's OK.
<wgrant> If it preserves current LP behaviour then it'd be fine.
<wgrant> But GitHub instacloses on merge.
<wgrant> Night.
<cjwatson> Yeah, I meant reference not autoclose
<wgrant> cjwatson: Oh, IPersonRoles really doesn't enjoy being given None. Will fix.
<cjwatson> wgrant: Bah.  Thanks.
<cjwatson> I didn't run the full bugs test suite after that. :-(
<wgrant> Quis testfix ipsos testfix, etc.
<cjwatson> rpadovani: Will you be able to do QA on your change?  That is, trying things out on qastaging and making sure they behave sensibly
<rpadovani> cjwatson, sure thing, I start right now :-)
<rpadovani> cjwatson, so, I tested it here: https://bugs.qastaging.launchpad.net/launchpad/+bug/1391394 with my account and a private browser session, and works as expected. What's next? Should I create screenshots?
<mup> Bug #1391394: Unable to unhide my comment <comments> <confusing-ui> <hide> <qa-needstesting> <trivial> <ui> <unhide> <Launchpad itself:Fix Committed by rpadovani> <https://launchpad.net/bugs/1391394>
<mapreri> remove qa-needstesting and putting qa-ok, i'd say  (/me's just trying a guess)
<cjwatson> rpadovani: that should be fine, so you can do as mapreri says.  https://dev.launchpad.net/PolicyAndProcess/QAProcess?highlight=%28qa-ok%29
<cjwatson> rpadovani: no need for screenshots
<rpadovani> ... I need to read more the wiki
<rpadovani> ty
<mapreri> "qa-rcfixed: when a bug is fixed in RC mode." cjwatson ?
<mapreri> the only meaning i'm aware of RC is "Release Critical", guess this is different? ;)
<mapreri> (or release candidate)
<cjwatson> that may be obsolete, it predates me
<mapreri> nice
#launchpad-dev 2015-09-16
<wgrant> Perhaps it is time to bite the bullet and have a generic artifact cross-reference table without strong foreign keys.
<wgrant> Referential integrity doesn't really buy us much for BugBranch, SpecificationBranch, SpecificationBug
<jtv> wgrant: I wrote a weakly-linked table once...  TranslatableTemplate or something.  Probably gone now, but it was really useful at the time.
<jtv> Sometimes with relational databases, painful as it may be, you just have to admit that it's... relational.
<jtv> And hi.  :)
<wgrant> jtv: Hi!
<wgrant> There's SuggestivePOTemplate, but I don't recall TranslatableTemplate.
<jtv> (Ahem.  Obviously I didn't write a weakly-linked table "once" â I mean I had one in Launchpad once.))
<wgrant> Heh
<jtv> Dammit, internets, you can deliver my messages within the hour, can't you?
<jtv> wgrant: yes, that's the one!
<jtv> It eliminated a subquery of a few dozen ms that was repeated in many queries per translation page, but maintaining referential integrity would have defeated the purpose.
<jtv> (Actually I've had this long-standing suspicion that those big PO template headers that were only used in one place were unnecessarily slowing down the POTemplate table, but that's another story)
<wgrant> Yeah, we had that problem with SourcePackageRelease.copyright
<wgrant> I hacked it to only load when that specific field is requested on the the one page that uses it, saving megabytes of database transfers on hot pages.
<jtv> Not to mention decoding...
<jtv> I used to want a Django lazy-loading field type for this.  But then I got greedier: if we could remove these long strings from the tables altogether, it would increase data density.
<jtv> Could matter to lots and lots of joins.
<wgrant> Indeed, though I suspect most of these would be TOASTed so not affect density much.
<jtv> (Even when you're using an index, postgres still needs to look at the actual table to check tuple liveness.)
<jtv> True, if they're out in separate storage, that'll help.
<jtv> I don't know how the TOASTing works in terms of table representation; POTemplate is so hot for joins that even just dropping a 4-byte field may help.
<wgrant> cjwatson: Do you think https://bugs.launchpad.net/launchpad/+bug/1170301 is still a problem? Now that everything actually gets closed by copies, Launchpad-Bugs-Fixed may not actually be used in any normal case any more.
<mup> Bug #1170301: It would be nice to have bugs-autoclosing working for intermediate revisions non accepted to the archive but included in a new upload <bugs> <packages> <soyuz-core> <soyuz-upload> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1170301>
<wgrant> jtv: Large values are stored as references to tuples in a separate TOAST relation in a separate file on disk.
<wgrant> This doesn't help LP as much as it could, as we almost always get all fields.
<wgrant> But it does mean we're not inflating large dead rows just to check whether they're dead.
<cjwatson> wgrant: Seb filed that bug six months after we switched to proposed-migration and everything being closed by copies ...
<cjwatson> So not sure I'm convinced by that argument
<wgrant> Hm, indeed.
<wgrant> Perhaps the ancestry calculation is just dodgy.
<cjwatson> Yeah, I've had my suspicions about that before
<jtv> wgrant: I just looked it up...  the default TOAST threshold seems to be 2KB, and I suspect most PO headers would hit the "sour spot" just below that.
<jtv> In which case, massive potential for moving them out-of-line.  :)
<jtv> Set only on import, read only on export.
<cjwatson> wgrant: Thanks for reviewing https://code.launchpad.net/~cjwatson/launchpad/livefsbuild-version/+merge/271193, but did you notice that it relies on https://code.launchpad.net/~cjwatson/launchpad/db-livefsbuild-version/+merge/271171 ?
<wgrant> cjwatson: I reviewed that one, but I guess my request on livefsbuild-version only made it through because closing db-livefsbuild-version got me down to four tabs...
<wgrant> fixing
<wgrant> cjwatson: Any thoughts on the cross-artifact link table proliferation?
<cjwatson> wgrant: Limited to only two non-null reference columns?  That would make it easier to decide what to do on deletion (e.g. no bug/specification/branch all linked together and then you have to decide what to do if the branch is deleted)
<cjwatson> db-livefsbuild-version> thanks
<wgrant> cjwatson: Or ditch the dozens-of-columns approach and not bother with FKs.
<cjwatson> what would the table contain then?
<wgrant> Just store a type and an ID for each end.
<cjwatson> hm, yeah, I guess there's no reason to believe that would have perf problems
<cjwatson> seems reasonable ...
<wgrant> None whatsoever.
<cjwatson> better density too
<wgrant> I guess it'd also have a JSON metadata column too, where we'd store eg. the git repo hint.
<cjwatson> in that case it would be a commit sha-1 rather than an id
<cjwatson> no obvious id for the link-to-commit case (unless you use the repo hint as the id, but that complicates what to do on deletion)
<wgrant> (plus this makes the way toward splitting clearer)
<wgrant> Right.
<wgrant> Some kind of identifier
<wgrant> Not a specifically integral ID.
<wgrant> Just needs to be some bijective mapping.
<cjwatson> maybe having an id column at least available would be quicker for searching in the cases where we have one
<cjwatson> id integer, identifier json, check (null_count(id, identifier) == 1) or some such
<wgrant> Maybe.
<wgrant> A string is only slightly longer, and conversion isn't too verbose or slow.
<wgrant> I considered using URLs, but that raises issues with staging that I can't be bothered working out this week.
<wgrant> (this could then be generalised to other services, which could even maybe register callbacks to describe the status of the referenced external artifact to be displayed on the internal artifact's LP page)
<wgrant> But using simple internal identifiers is a good first step.
<cjwatson> Yeah, ids could have service names attached for splitting
<cjwatson> I like this plan
<wgrant> That was easier than I expected.
<cjwatson> Are there any cases where inhibiting deletion is more than an inconvenience?
<wgrant> Not in the tables I'm considering right now.
<wgrant> I think that this solution should be restricted to those where it shouldn't be inhibited.
<cjwatson> Deleting active MPs, but presumably you aren't looking at that
<cjwatson> Yeah
<wgrant> Right, no.
<wgrant> Recipes are a murky case.
<cjwatson> Especially if you're thinking of it being a cross-service thing
<wgrant> There's a good argument that recipes should be text, and use cross-references for backlinks from branches.
<wgrant> Due to the fact they can be created by anyone and block deletion of any referenced branch.
<wgrant> But certainly not an immediate target :)
<cjwatson> Right, I think the path for recipes is to make it possible to detach branches from them after which they become unbuildable but still exist.
<cjwatson> If I get a few solid days to make progress on git recipes then that might be a sensible thing to attempt as part of it.
<wgrant> Indeed.
<cjwatson> <cjwatson@niejwein ~/src/canonical/git-build-recipe/git-build-recipe (master)>$ git diff --cached --shortstat
<cjwatson>  10 files changed, 4050 insertions(+)
<cjwatson> one of these days
<wgrant> Impressive.
<cjwatson> I had an otherwise unused train trip
<blr> morning
<rpadovani> cjwatson, hey :-) I'm a bit confused about the relation between template files and python files. I'm trying to fix #185328, so I understood that +publishinghistory of a package is in soyuz, I found distributionsourcepackage-publishinghistory.pt, and the table I'm lookin for is generated by
<rpadovani> <tal:block repeat="publishing publications/currentBatch"
<rpadovani>                     replace="structure publishing/@@+listing-summary">
<mup> Bug #185328: Publishing history has only distribution series codenames, not version numbers <lp-soyuz> <trivial> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/185328>
<rpadovani> I tried to grep a bit these things, but I really don't understand where I'm supposed to look
<rpadovani> early in the file there is tal:define="publications view/batchnav, so I suppose I have to find this view
<rpadovani> but what is it?
<cjwatson> rpadovani: I'm not sure what I think about that bug in general, would probably take some playing around.  But as to your specific question, template files are evaluated according to http://pythonic.zoomquiet.io/data/20050615194557/index.html; in general the "context" is model code (i.e. corresponding roughly to a database object) and the "view" is browser code (i.e. the part of the presentation layer that isn't just HTML templating).  ...
<cjwatson> ... To find which view is associated with a given template, look for the template in lib/lp/*/browser/configure.zcml - in this case it's in soyuz, and it turns out that the same template may be applied to either lp.soyuz.browser.distributionsourcepackagerelease.DistributionSourcePackageReleasePublishingHistoryView or lp.registry.browser.distributionsourcepackage.DistributionSourcePackagePublishingHistoryView
<cjwatson> rpadovani: the +listing-summary page is also defined in lib/lp/soyuz/browser/configure.zcml, and in this case it's going to be for a SourcePackagePublishingHistory, so that will end up in sourcepackagepublishinghistory-listing-summary.pt
<cjwatson> rpadovani: and then that goes off into @@publishinghistory-macros and you get to repeat the process again :)
#launchpad-dev 2015-09-17
<rpadovani> cjwatson, okay, thanks for the explanation :-)
<wgrant> cjwatson: When you're around, can we discuss your snap browser branches?
<cjwatson> wgrant: Sure
<wgrant> cjwatson: The listing branch has an awful lot of tentacles.
<wgrant> What was the motivation behind IHasSnaps?
<wgrant> The IBranchCollection/IGitCollection getSnaps methods are a little neater than the alternative, but I'm not sure IHasSnaps is worth its weight.
<cjwatson> Hm, so originally it was partly because I was going to use it for SnapAddView
<cjwatson> But then I ended up attaching those to Branch/GitRef directly
<cjwatson> And originally I had a bit more per-implementer logic there
<wgrant> Using it to attach views might be justifiable.
<wgrant> But those tend to be slightly customised anyway.
<cjwatson> So it can possibly go away now
<wgrant> https://code.launchpad.net/~wgrant/launchpad/snap-listings <- here's one I prepared earlier
<cjwatson> The invention of SnapSet.findByContext was fairly late in the development of that branch
<wgrant> Ah, that'd do it.
<wgrant> I also don't really like the IBranchCollection and IGitCollection tentacles, but they're far more contained so if it's not easy to give a method on SnapSet a BranchCollection or GitCollection then they're not unreasonable.
<wgrant> (I realise this is a standard that code hasn't previously been held to, but I'd prefer the situation not continue to get worse)
<wgrant> Browser tentacles are somewhat unavoidable, but they're at least not inflating the overhuge classes.
<cjwatson> The main problem with moving the *Collection bits out is that they need to use _getBranchSelect etc.
<wgrant> Right.
<wgrant> It may be okaaaay to make that publicer.
<wgrant> It's certainly no less gross than putting Snappy bits on the Code collections.
<wgrant> Then you can use it as a subselect in SnapSet.
<wgrant> Er
<wgrant> No more gross.
<wgrant> It's going to be unfortunately slow either way.
<wgrant> I guess it may remain quick if the number of snap packages doesn't increase beyond a few thousand.
<cjwatson> wgrant: Your branch causes lp.snappy.browser.tests.test_snaplisting.TestSnapListing.test_branch_links_to_snaps to fail, because DecoratedBranch isn't a thing that can be passed to SnapSet.findByContext; since there's no longer an interface in use here, lazr.delegates doesn't fix it up for us.  What's the least bad way to fix this?  Maybe make lp.snappy.browser.hassnaps explicitly check for Decoratedbranch?
<cjwatson> *DecoratedBranch
<cjwatson> That's relatively foul, but all the alternatives I can think of are much worse
<wgrant> cjwatson: Oh, I'd forgotten decoratedbranch was a thing.
<wgrant> Hmm, uglyu.
<wgrant> We should really abolish DecoratedBranch at some point, but unwrapping in snappy isn't entirely gross.
<wgrant> Except that DecoratedBranch exists only in browser.
<cjwatson> I don't quite get why it isn't just eager loading.
<cjwatson> And cachedproperties.
<wgrant> Because cachedproperties in the model weren't a thing then.
<cjwatson> Oh right, that.
<wgrant> It's easy enough to abolish now.
<cjwatson> It's only in browser, indeed, so I can't unwrap it in SnapSet.findByContext.
<cjwatson> But could possibly unwrap it in lp.snappy.browser.hassnaps.
<wgrant> Ah yes, indeed.
<wgrant> That'll do for now.
<cjwatson> I've pulled your branch and fixed that up.  I'll work on the *Collection bits next, and then merge into snap-add-view and make sure everything still works there.
<wgrant> Thanks. Other than that it looks sensible.
<wgrant> One day we will be free of ridiculous circular imports.
<cjwatson> wgrant: Hm, would it be OK to use collection.getBranches().get_plain_result_set()._get_select() in SnapSet?  That's all _getBranchSelect does, so it'd save exporting a new interface method
<cjwatson> Though maybe that also means it's fairly harmless to export.
<wgrant> cjwatson: I'm not sure you even need _get_select.
<wgrant> I think you can do .is_in(resultset)
<wgrant> No leading underscores sounds like an invitation to me.
<cjwatson> Can you do .is_in(DecoratedResultSet) though?
<wgrant> I doubt it.
<wgrant> But get_plain_result_set() is not private.
<cjwatson> If is_in is given something that's not an Expr, it list()ifies it first.
<cjwatson> So it might work, but will not be quick.
<wgrant> Ah, damn.
<wgrant> _get_select it is, then.
<wgrant> It even makes it obvious that it's a bit icky.
<cjwatson> Maybe I should just export _getBranchSelect rather than writing it out again, though.
<wgrant> Fair.
 * cjwatson gets more coffee rather than dithering.
<cjwatson> Do you have an opinion on the practice of exporting interface methods with leading underscore as an "ok, you don't have to remove the sec proxy, but it's still icky" indicator?
<cjwatson> I guess we have a few of those ...
<wgrant> It is evil, but luckily there is sed.
<wgrant> In fact that method's only referenced in that file.
<wgrant> Mm
<wgrant> I guess the ickiness indicator is valuable.
<wgrant> So I'm not fussed either way.
<cjwatson>  6 files changed, 19 insertions(+), 111 deletions(-)
<cjwatson> (disentangling from {Branch,Git}Collection
<cjwatson> )
<wgrant> but how
<cjwatson> just the disentanglement commit, not the whole thing :)
<wgrant> yeah, still surprisingly productive.
<cjwatson> wgrant: All done and pushed, both snap-listings and snap-add-view
<wgrant> Huh.
<wgrant> It ended up nearly 500 lines shorter!
<wgrant> Thanks.
<cjwatson> Spotting that get{Branch,Repository}Ids were already exported and are nearly the same thing helped.
<wgrant> ahh.
<wgrant> Are the three related snap templates identical?
<cjwatson> Almost.  Let me see if I can unify/macro them
<cjwatson> I wonder if the snap templates should live in lib/lp/snappy/ ?
<wgrant> That would indeed make sense, if they can be unified.
<cjwatson> There's precedent for e.g. stuff in code defining pages for registry objects.
<wgrant> True.
<wgrant> But better if we can unify them :)
<cjwatson> Though that might be a bit too odd since *-index are still going to have to link to them.
<wgrant> Is that odder than the template in Code referencing weird mixins from Snappy?
<cjwatson> wgrant: Pushed, what do you think?  I haven't addressed your review comments yet, that's next
<wgrant> cjwatson: Looks good.
<wgrant> Code's running out of Snappy tentacles.
<cjwatson> All this magic dependency injection, I feel like a Java programmer
<wgrant> Hm, it doesn't seem to terrible to me.
<wgrant> too
<cjwatson> I didn't *actually* say it was terrible :-)
<cjwatson> wgrant: "There won't always be matching GitRefs, so this preloading won't always find everything."  but if they don't exist we don't need to preload them
<wgrant> cjwatson: But if the preloading is useful, then whatever it is useful to will make queries for the refs that aren't in the cache.
<cjwatson> Ah, yes.  Maybe Snap.git_ref should be a cachedproperty so that I can fill it in here.
<cjwatson> Actually I suspect that bit of preloading isn't doing anything right now.
<wgrant> Yep.
<cjwatson> I'll pull that out and sort it out in a later branch.
<blr> morning
<wgrant> Morning blr.
<blr> hey wgrant
#launchpad-dev 2015-09-18
<wgrant> cjwatson: Can you merge up snap-add-view?
<cjwatson> Oh, right, that actually needs a not entirely trivial merge due to the ZPT macrology
<wgrant> Yup
<wgrant> Not hugely difficult, fortunately.
<cjwatson> Would you be inclined to use a slot or a variable for the create_snap link there?
<cjwatson> Since gitrepository isn't going to get it
<wgrant> I think that makes sense as a variable.
<wgrant> If it works.
<wgrant> I always have to look up exactly how macros work.
<wgrant> Normally I just cargo-cult...
<cjwatson> Yeah
<cjwatson> I can't find the order of evaluation of tal:define vs. metal:use-macro defined anywhere
<cjwatson> Oh, or I could just include the link if context_menu/create_snap exists, no need for a variable
<wgrant> Did you having a a single generic add view, with the link from Code just populating the source field?
<wgrant> I'm happy either way.
<wgrant> Bah, edit lag
<wgrant> s/having a a/consider having a/
<cjwatson> That's what I have, right?
<wgrant> You have a single view class, but it acts as a view on the source object.
<wgrant> Rather than the branches linking into the snappy hierarchy, there is this single parasite.
<wgrant> Well, I guess also the listing views, and they're more awkward to move.
<wgrant> So carry on.
<cjwatson> I did originally have something like /+snaps/+new, but thought it was simpler to use the context rather than passing variables around
<cjwatson> I can try again if you think it might be worthwhile
<wgrant> Not much point while +snaps is adjacent.
<wgrant> Right, so I think I have reasonably good xref ports locally, though I may need to create fake BugTags for search performance
<wgrant> (QuestionBug, BugBranch, SpecificationBug, SpecificationBranch abolished)
<cjwatson> Nice
<cjwatson> wgrant: snap-add-view pushed
<wgrant> Thanks, looking.
<wgrant> Hm, if I do fake tags then I can kill BugCve too.
<cjwatson> I guess create_snap could go in HasSnapsMenuMixin, maybe?  Would need logic to exclude GitRepository until I make +new-snap smarter
<wgrant> GitRepositoryNavigationMenu could just set create_snap to None
<cjwatson> ContextMenu but yeah
<wgrant> Er that
<wgrant> I don't remember the difference.
<cjwatson> Yeah, OK, let's do that
<wgrant> Also I think it's "snappy Ubuntu Core", though I might be out of date.
<wgrant> The ubuntu.com page sneakily only uses it at the start of a sentence.
<wgrant> Ah no, "Try snappy Ubuntu Core"
<cjwatson> I'll ask #snappy-internal
<wgrant> A critical issue, I know.
<wgrant> And snapcraft seems consistently lowercase.
<cjwatson> Nobody has any taste, but oh well.
<wgrant> Heh, quite.
<cjwatson> (Actually, I'm OK with snapcraft if it's being treated as a Unix utility.)
<wgrant> Not as distasteful but unavoidable as BuildableDistroSeries, fortunately.
<wgrant> The snapcraft docs use "Snapcraft" at the start of a sentence, and snapcraft both monospaced and not.
<wgrant> So even the non-command version should be lowercase.
<wgrant> cjwatson: Do you deliberately exclude SUPPORTED series?
<wgrant> Like, say, trusty.
<wgrant> Or rather lts+1, I guess
<wgrant> Since trusty is too old.
<wgrant> lgtm otherwise
<cjwatson> wgrant: so that's confusing because this is not the observed behaviour
<cjwatson> trusty is SUPPORTED in my dev instance, but appears in +new-snap
<cjwatson> And I cloned-and-hacked that from +new-recipe
<wgrant> I don't believe you.
<wgrant> But you have a good point.
<cjwatson> I don't believe me either
<cjwatson> And yet
<wgrant> Maybe BuildableDistroSeries is even dodgier than I suspected.
<cjwatson> Doesn't seem to be ...
 * cjwatson pdbs
<wgrant> Hm, no.
<wgrant> It is exactly as dodgy as I remembered.
<cjwatson> Oh, but this doesn't make any sense here
<cjwatson> Er
<wgrant> Oh
<wgrant> initial_series
<cjwatson> It's only picking one
<wgrant> derp
<wgrant> er, initial_values
<cjwatson> But it ought to include FROZEN
<wgrant> quite.
<cjwatson> Or just use currentseries or something
<wgrant> Indeed...
<wgrant> It could easily accidentally pick RTM there.
<cjwatson> Should I just use the ubuntu celebrity?
<wgrant> I don't know if fireworks will occur if it's not actually in the vocab, and it will likely break tests.
<wgrant> Being as bad as recipes isn't a great bar, but it's not terrible.
<cjwatson> Let's at least include FROZEN and an XXX comment
<wgrant> Yep
<wgrant> Oh
<wgrant> I guess fixing the snap case without fixing recipes wouldn't break tests, would it.
<wgrant> But FROZEN is probably Good Enough.
<cjwatson> BuildableDistroSeries also uses the ubuntu celebrity, which should be enough to guarantee that it's in the vocab
<wgrant> Oh
<wgrant> I thought it used the distros of all PPAs you could upload to.
<cjwatson> Plus ubuntu
<wgrant> It lists 14.09 for me.
<cjwatson> And currentseries is always going to be active
<wgrant> Ahh
<wgrant> Yep
<cjwatson> wgrant: brutal hack in place: http://bazaar.launchpad.net/~cjwatson/launchpad/snap-add-view/revision/17748
<wgrant> cjwatson: As long as you feel bad about it. r=me.
<cjwatson> Oh I do :P
<cjwatson> But at least it's in a very very domain-specific place ...
<cjwatson> Thanks.  Making good progress on a basic requestBuilds UI, which is the last significant piece of UI for this.
<wgrant> Do you know what it looks like yet?
<cjwatson> For now it'll just be a basic form with archive, architectures, pocket.
<cjwatson> Which is crap but workable.
<cjwatson> The only tricky bit is the archive selection.
<wgrant> Pocket!?
<wgrant> But I guess it's necessary here until we have something better.
<cjwatson> I'm adding a widget to let you choose primary archive or a PPA.
<wgrant> Hopefully searching PPAs
<wgrant> Rather than showing a <select> of four hundred.
<wgrant> Being added to Online Services teams was the worst thing that ever happened to me.
<cjwatson> That's the intention
<cjwatson> Haven't tested what my current code actually does yet :P
<cjwatson> Pocket is nearly the worst piece of terminology in Launchpad.
<wgrant> It's one of my earliest memories of Launchpad.
<wgrant> Trying to work out what on earth the text on SP:+index meant.
<wgrant> It survives to this day, and makes a bit less sense.
<cjwatson> I remember Daniel swearing a lot after being told to introduce it ...
<cjwatson> Since it involved rewriting a good chunk of the Soyuz code he had at that point
<wgrant> Oh, I didn't realise it wasn't there from the start.
<wgrant> It's rather more seemless history-wise than the introduction of archives.
<cjwatson> It may have been before much was committed.
<cjwatson> I think this was still in the phase where about 20% of Soyuz was being written in my house, and before the mega-landing on devel
<wgrant> Heh
<wgrant> Better than good old r4274
<wgrant> ("Personal Package Archives")
<wgrant> cjwatson: Do you have any planned UI filling after requestBuild?
<cjwatson> Not at present
<cjwatson> Do you have requests?
<wgrant> Not until I can do them through the web UI.
<cjwatson> Not sure I understand
<wgrant> The last piece of UI you're working on is for making requests, and then you asked if I had more requests.
<wgrant> It's a terrible pun, you seen.
<wgrant> But no, I don't know of any big remaining gaps.
<cjwatson> Sigh.  Must be Friday
<cjwatson> wgrant: http://people.canonical.com/~cjwatson/tmp/snap-request-builds.png corresponds to https://code.launchpad.net/~cjwatson/launchpad/snap-requestBuild-ui/+merge/271650.  It's, er, basic, but works.
<wgrant> cjwatson: It is very weird asking for pocket without series, but such is life.
<cjwatson> I wonder if that's really a model issue.
<cjwatson> I was thinking of it like livefs, where sometimes you want to do just one build against -proposed.
<cjwatson> But maybe that's wrong.
<wgrant> I wonder if snaps aren't actually series-specific.
<cjwatson> Arguably not, since they aren't unique by series.  Though this request-builds form would be even worse if you had to pick the series every time too ...
<wgrant> Right, but recipes have sensible defaults there
<wgrant> Or rather they have a set of daily build series that are ignored for manual requests for some reason.
<cjwatson> I don't think people generally want to build snaps based on more than one series of code.
<cjwatson> And they probably don't want to flip-flop around or have to pick it every time.
<wgrant> Right, they don't want to have to pick every time.
<wgrant> But think about eg. charms
<cjwatson> So I think, while a snap isn't series-specific as such, it makes sense to store that persistently.
<wgrant> Oh certainly.
<wgrant> A snap probably has a set of series.
<wgrant> Now how do pockets fit in...
<cjwatson> And IMO the bug here is really that default pockets and architectures aren't stored on the snap too.
<wgrant> Yeah
<cjwatson> It's definitely weird to be choosing that in separate places
<wgrant> Maybe it has a set of suites and a set of processors.
<cjwatson> (Well, SnapArch exists, and I'm not using it right now.  Probably should be.)
<wgrant> Iteration!
<cjwatson> SnapArch also has no UI
<cjwatson> So a slight set of improvements would be (a) give SnapArch some UI, (b) move pocket to Snap, (c) drop pocket from request-builds UI, (d) default architectures in request-builds UI to Snap.processors
<cjwatson> I don't think a set of suites makes sense.  You're building the snap *from* the suite, not *for* the suite, and it's building a static blob of everything from there.  Why would you want more than one?
<wgrant> Is it truly everything?
<wgrant> Surely we don't include libc in the snap.
<cjwatson> True, and I suppose we don't really know the long-term snappy support model yet
<wgrant> Right, exactly.
<cjwatson> I'll at least do (d), that's fairly obviously correct
<cjwatson> (done)
<cjwatson> Recipes don't let you set the pocket in the UI at all, and daily builds always use RELEASE.  Which must be fun if you actually need something from -updates.
<wgrant> Not quite
<wgrant> They use Release in the PPA
<cjwatson> Oh true
<wgrant> And then the PPA's dependencies for primary.
<cjwatson> Do we have anything else that models a set of suites?  Maybe it would be better to treat the pocket like ArchiveDependency does.
<wgrant> You can't build directly into primary.
<wgrant> Right, that may be more reasonable.
<cjwatson> That is, you choose the same pocket for all suites.
<cjwatson> er series
#launchpad-dev 2015-09-20
<blr> morning
#launchpad-dev 2016-09-21
<xnox> is it normal that https://launchpad.net/api/1.0/mvo/+archive/ppa returns
<xnox> Object: <lp.systemhomes.WebServiceApplication object at 0x8f96310>, name: u'mvo'
<xnox> instead of json?
<wgrant> xnox: Yes
<wgrant> xnox: You're missing a ~
<wgrant> mvo is many things, but a project is not one of them.
<xnox> yes!
<xnox> thank you.
<wgrant> xnox: software-properties-common, or something else?
<xnox> aha
<xnox> fixing a bunch of stuff
<xnox> like you know, actually showing the keys from /etc/apt/trusted.gpg.d instead of pretending "you only use google chrome key and nothing else"
<wgrant> I'
<wgrant> m sure gpg2 will break that somehow spectacularly.
<xnox> =)
<xnox> wgrant, ah, things did change. previously that broken url would fail to return anything and/or return http error code and/or set an exception and now it returns the Object thing.
<xnox> anyway, i'll catch the json exception and return PPAException as the code expects. sorted.
<wgrant> xnox: That's an HTTP 404, and has been for about 9 years :)
<wgrant> That's the normal text of an API 404
 * xnox ponders do i really want to debug pycurl, or should i just kill the python2 codepath
<wgrant> Poor Python 2 :(
<xnox> yeah, 404.
#launchpad-dev 2016-09-22
<timrc> wgrant: Long time no speak :) I've observed strange behavior with "apt-cache show"... I was hoping you could set me straight :)
<wgrant> timrc: Hi! It's been a while. What's the issue?
<timrc> wgrant: This one is weird.  Ansible has a module called 'apt_repository' and this module will create a sources file in /etc/apt/sources.list.d if it doesn't already exist and give it a file mode.  This file mode _weirdly_ defaults to 420 (root user readable, root group writeable)
<wgrant> That sounds like a very special module.
<timrc> If you were to "apt-cache show some-package" as a non-root user, apt-cache show wouldn't find anything.
<timrc> The reason _seems_ to be that it scans /etc/apt/sources.list.d and if it can _open_ the file, it will use it when scanning /var/lib/apt/lists
<timrc> But in my case the user executing "apt-cache show" can read the /var/lib/apt/lists location.
<timrc> So I could literally grep for the package I'm interested in /var/lib/apt/lists but I could not discover it using "apt-cache show"
<wgrant> timrc: That's normal. /etc/apt/sources.list and co are all meant to be world-readable.
<wgrant> There are separate files for creds if need be.
<timrc> Okay so the assumption is that you're not using weird modes on /etc/apt/sources.list
<timrc> Though wouldn't it be better to just do the c++ equivalent of "ls -1 /etc/apt/sources.list" and use that to compose your search space?
<timrc> Oh wait scratch that, it needs the url to reconstruct the cache file name.
<timrc> wgrant: Thanks =)
<wgrant> timrc: Right, it could approximate that by just looking at every file in /var/lib/apt/lists, but there can be other properties in sources.list (eg. disabling signature verification) that mean it can't really do that.
<timrc> Wow... so the person who wrote this module had the right idea.  This is a real bug... the default mode is 0644, but he does int('0644', 8) which turns it into 420 and then I guess does a chmod 420 on the file.
<wgrant> Heh
<wgrant> That'd do it.
<timrc> I just thought he was smoking pot.
#launchpad-dev 2016-09-25
<rebel> hi, I'm trying to get a slightly modified version of an existing package into daily builds. basically I just have to do some sed replacements on the latest Makefile and rules file of the original package. I'm a bit lost in documentation and options, if someone can point me towards the "right" way I'd much appreciate it.
