#launchpad-dev 2010-01-11
<jml> abentley, https://code.edge.launchpad.net/~jml/launchpad/use-testtools/+merge/16711
<abentley> thumper: https://code.edge.launchpad.net/~jml/launchpad/use-testtools/+merge/16711
<thumper> jml: ping
<jml> thumper, pong
<al-maisan> rockstar: please see bug #505725
<mup> Bug #505725: Replicate the processor/virtualized properties in the BuildQueue table <buildfarm> <Soyuz:Triaged by al-maisan> <https://launchpad.net/bugs/505725>
<jml> jtv, noodles775: https://code.edge.launchpad.net/~jml/launchpad/behavior-refactor/+merge/17127 -- mid-implementation
<mrevell> Howdy
<jml> mrevell, hi
<jml> mrevell, did I get my timing wrong?
<mrevell> jml, Timing?
<mrevell> jml, Oh, sorry, I misread your nick as jtv.
 * mrevell checks glasses
<deryck> Morning, all.
<henninge> salgado: ping
<salgado> hi henninge
<henninge> Hi salgado! :)
<henninge> salgado: I may need to add a package to launchpad-dependencies. Can tell me or give me a hint about how to do that?
<salgado> henninge, https://help.launchpad.net/Packaging/PPA
<salgado> no, not that one
<henninge> salgado: right,  I was talking about an existing package that I need for some new code.
<henninge> The package is intltool, btw.
<salgado> henninge, https://dev.launchpad.net/LaunchpadPpa
<salgado> henninge, does that help?
<henninge> salgado: still reading but that looks like it's what I need.
<henninge> thanks
<salgado> once you're done updating meta-lp-deps you'll need https://help.launchpad.net/Packaging/PPA to upload a package to ~launchpad's ppa
<henninge> salgado: hm, I am surprised it would be so much work. I am not talking about a package that I created or wrote.
<henninge> salgado: I just need another package from the standard Ubuntu repository.
<salgado> henninge, it's only a few commands to get that done
<arnaud_> hey everybody
<mars> hi arnaud_
<beuno> EdwinGrubbs, sinzui, adding a member on staging looks super slick
<sinzui> bac: did you start bug 491320?
<mup> Bug #491320: Unnecessary spaces and lines in new team member approval page <trivial> <ui> <Launchpad Registry:Triaged by bac> <https://launchpad.net/bugs/491320>
<bac> sinzui: i have not
<sinzui> bac: okay.
<kfogel> adeuring, deryck: bbiab w/ +patches view bug
<deryck> kfogel, excellent.  thanks.
<adeuring> kfogel: cool
<kfogel> deryck, adeuring: please read https://bugs.edge.launchpad.net/malone/+bug/506018 and give me your comments.
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:New for kfogel> <https://launchpad.net/bugs/506018>
 * deryck looks
 * adeuring looks too
<deryck> kfogel, yes, looks good to me.  Seems complete.
<deryck> kfogel, I triaged accordingly -- it would be "high" since this is a high priority story for us this month.
<kfogel> deryck: sounds good
 * kfogel waits for adeuring to say he's absorbed it
<deryck> kfogel, also, not a big deal, but we wouldn't assign to 10.01 now, even though we're all very confident this will land this month.
<kfogel> deryck: ah, *nod*
<deryck> kfogel, we would wait until it nears review state.  but don't un-milestone it now -- we don't want to create confusion.
<adeuring> kfogel, deryck: looks good to me too
 * deryck recognizes this is at odds with how LP development has always worked, but the bugs team is trying a new approach
<kfogel> deryck: what part is at odds?
<kfogel> adeuring: I'm going to show to Bryce and Jorge now (would like to keep them in the loop as much as possible).  Sound good to you?
<adeuring> kfogel: sure!
<deryck> kfogel, historically the milestone has been either a backlog queue or a promise to deliver the listed bugs by the milestone release.
<deryck> kfogel, so we're now using it as a list of what will actually make release
<kfogel> deryck: ah, okay.  I don't think it matters much; Lean Training said "you're going to write the code you write" and I agree :-).
<deryck> kfogel, I agree completely too.
<kfogel> adeuring: I edited the description field in response to a comment from jcastro, but after I clicked the green checkmark to submit my edit, it just spins forever with the red background.  Is this a known problem?
<adeuring> kfogel: haven't noticed this before...
<kfogel> adeuring, deryck: fascinating.  I can't update the bug's description, because of a... bug in updating descriptions, at least with my Firefox 3.5.7 on Karmic+updates.  https://pastebin.canonical.com/26408/ has the new desc text.
<deryck> kfogel, odd.  Do you get an error of any kind?
<adeuring> kfogel: Just copied&pasted your new version and changed the description.
<kfogel> adeuring: thanks.
<kfogel> deryck: no, just spins forever.  I'm searching/filing a bug on it now.
<deryck> kfogel, did you reload the page?  Perhaps the description was changed, but the UI not updated?
<kfogel> deryck: I tried a reload while it was spinning, last time, and my edit had not taken.  (But good question: I will remember to include that in the bug report.)
<mrevell> night all
 * deryck has to bail for food before a call later...
<kfogel> adeuring: you might want to add your browser info to follow up to my comment here: https://bugs.edge.launchpad.net/malone/+bug/443217/comments/7
<mup> Bug #443217: Changing a bug's affected project or description doesn't ever finish <bug-page> <javascript> <ui> <lazr.restful:New for intellectronica> <Launchpad Bugs:Triaged by intellectronica> <https://launchpad.net/bugs/443217>
<deryck> kfogel-lunch, jusy fyi... when you see the red border on a failed AJax interaction, that's a server error of some sort, usually.  Next time, use Firebug and get the error info that failed to display to the web page.
<jml> bigjools, http://wikitravel.org/en/Wellington#Eat
<jml> thumper, ^
<beuno> sinzui, replied to the package linking email
<beuno> sorry it took me a while
<beuno> let me know if it's clear
<beuno> also, does this plan involve making the series column nullable?
<beuno> as in, stop this crazyness of linking series to series be mandatory?
<sinzui> beuno: No and I have said that every time because we want to link to the development series, and we allways know that
<mwhudson> jml, bigjools, thumper: boulcott st bistro or hummingbird would be nice :-)
<sinzui> beuno: we do not have a model problem, we have a UI problem
<sinzui> beuno: what ask for the user to select the development series when we know it?
<beuno> sinzui, works for me, as long as you can click through without knowing about serieseses
<wgrant> sinzui: Surely it's better to just link to the project than to lie?
<wgrant> Linking to the development series is normally a lie, when you in fact want to link to just the project but cannot.
<beuno> yes, I tend to agree
<beuno> we will be inventing data
<beuno> still, defaulting to something is already a big step forward  :)
<sinzui> wgrant: beuno: we have a separate problem for next month to ensure the development series is correct. because it can change, behind the Ubuntu contributors back, the upstream project needs more help to get this fixed.
<sinzui> wgrant: the user is still requested to select a series, we will except the project if the user does not provide a series
<sinzui> beuno: wgrant: the user experience is bad because we designed for the rare cases where there are many upstream series. We need to handle cases like python in a different manner.
<mwhudson> down to 8 import policy violations, i see
<bigjools> gary_poster: around?
<bigjools> bug 505657
<gary_poster> bigjools: hi, yes
<mup> Bug #505657: tachandler.py imports from launchpad <Launchpad Foundations:New> <https://launchpad.net/bugs/505657>
<bigjools> gary_poster: hi there.  We have a problem with that bug --^ :(
<gary_poster> bigjools: ok, looking
<bigjools> it's kinda urgent is it's going to block lamont from rolling out buildd changes
<kfogel> intellectronica: got time for a few questions?
<gary_poster> bigjools:  ok, got urgency, but trying to understand problem still.  staring at bug more...
<gary_poster> bigjools, I'm afraid I don't have enough context to understand.  Want to try Skype?
<bigjools> gary_poster: I'm not particularly familiar with it either, just a sec, I'll talk to people here
<gary_poster> bigjools: ack
<bigjools> gary_poster: looks like the memcache stuff did something to tachandler
<bigjools> gary_poster: see stub's commit 10064 on devel
<gary_poster> bigjools: ok, looking
<bigjools> tachandler now imports from lp stuff, which is not ideal for our buildds which don't have LP installed :)
<gary_poster> bigjools: ok, so either we need to revert just the tachandler file (it looks like stub was just trying to consolidate code) or...is there someplace that tachandler *can* import from that is shared with LP?
<bigjools> gary_poster: I don't think there is :(
<bigjools> well, lib/canonical/buildd
<gary_poster> bigjools: OK, then I think we just need to revert the file, and keep the rest of stub's changes
<gary_poster> bigjools: are you all in a position to do that, or do you need one of us to do that?
<bigjools> gary_poster: we can do it if you review it?
<gary_poster> bigjools: +1
<bigjools> cool, thanks gary
<gary_poster> np
<gary_poster> bigjools: Beyond the simple revert of the file, the only additional request is a comment saying why we don't import the helper functions, so we don't do this again. :-)
<bigjools> I was thinking the same as you typed that :)
<gary_poster> heh cool
<sinzui> combine-css fails in rocketfule. I cannot identify which of the 100 CSS files is the cause of the failure. And I cannot run dev to work on my own branch.
<wgrant> sinzui: Tried 'make clean'? rockstar had that problem this morning.
<rockstar> sinzui, yes, make clean.
<rockstar> Then make again.
<sinzui> wgrant: rockstar: Thanks. That fixed the issue
<beuno> danilos, ping
<beuno> danilos, do you remember where the "error" message sprite breaks in translations?
<beuno> flacoste, do you?  the bug I have assigned is 405476, but that one's too generic
 * sinzui thinks how to make the error appear
<al-maisan> rockstar: https://bugs.edge.launchpad.net/soyuz/+bug/506142
<mup> Bug #506142: JobStatus should have a "SUSPENDED" member <buildfarm> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/506142>
<sinzui> beuno: I tried to remove the summary from a ProductSeries and got a small error. It is not dramatic, but you will see two icons in the z-index under the bug icon
<beuno> sinzui, will try  that, thanks
<flacoste> beuno: https://translations.edge.launchpad.net/ubuntu/karmic/+source/apturl/+pots/apturl/av/+translate
<flacoste> beuno: Bugs 405476, 389737, 487142
<beuno> perfect
<beuno> I can work with that
<beuno> thanls
<intellectronica> kfogel: sure
<sinzui> beuno: the markup is <p class="error message">text</p> no inside markup! I may have discovered a different but related problem
<kfogel> intellectronica: oh, hey.  I'm working on bug #506018, and burrowing my way through much documentation for the first time.  If you have time for a phone call, that might be fastest.
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/506018>
<jml> mwhudson, my use-testtools branch is now blocked on fixing the upcalls in the signon code
<intellectronica> kfogel: i can do a phone call, but i need 10m first so that you don't have to hear me chewing :)
<kfogel> intellectronica: heh, that's fine
<mwhudson> jml: :(
<mwhudson> jml: i guess i can land my build-testtools in the mean time; that should get the bzr buildbot running a bit better at least
<jml> mwhudson, yeah, I think so.
<intellectronica> kfogel: ready when you are. skype?
<kfogel> intellectronica: my skype may or may not be broken.  let's try it, but watch here in case you can't hear me.
<intellectronica> kfogel: np. if not i can call you on skype creds
<kfogel> intellectronica: what's your skype name?
<intellectronica> kfogel: tom.berger
<jml> noodles775, would you like to review https://code.edge.launchpad.net/~jml/launchpad/behavior-refactor/+merge/17127
<kfogel> intellectronica: ringing and ringing
<kfogel> intellectronica: do you hear it ringing for you?
<noodles775> jml, sure
<kfogel> intellectronica: huhn
<kfogel> can you hear me?
<kfogel> intellectronica: did you pick up?
<intellectronica> kfogel: nope
<kfogel> intellectronica: ok, sigh
<jml> wgrant, oi
<intellectronica> kfogel: i did pick up but i can't hear anything. could my setup. let me check
<jml> wgrant, where's the branch you're working on?
<jml> wgrant, I'd like to merge it in to the what we're doing
<jml> bigjools, I'm talking about hacking on soyuz, what are you talking about? :P
<kfogel> intellectronica: +1 (773) 351-1729?  Let me get that headset on though.
<kfogel> intellectronica: ?  are you having Net troubles?
<wgrant> jml: What are you wanting to do buildd-wise?
<jml> wgrant, mostly just to make sure I'm not blundering all over your work.
<intellectronica> kfogel: so it seems :-/
<kfogel> intellectronica: whups
<wgrant> jml: lp:~wgrant/launchpad/lp-buildd-generalisation, but you'll need to unbreak tachandler yourself if you want to run it.
<jml> wgrant, ok. thanks.
<intellectronica> kfogel: sorry, i'm trying to work out what's the problem. if i can't, do you have an affordable way to call my phone?
<kfogel> intellectronica: hmrmrm.  I have some skype credit; whether skype works for me is another question, but I can try.
<kfogel> intellectronica: privmsg me your number.  in the meantime, I'll do a skype test call just to see.
<intellectronica> kfogel: nevermind, got it working, i think, let's give it a try
<kfogel> intellectronica: https://bugs.edge.launchpad.net/malone/+bug/506018
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/506018>
<kfogel> intellectronica: https://pastebin.canonical.com/26421/
<gary_poster> bigjools, wgrant: branch approved.  Thank you.
<kfogel> intellectronica: we're fading
<bigjools> gary_poster: cheers
<kfogel> intellectronica: can you hear me?
<wgrant> gary_poster: Thanks.
<kfogel> intellectronica: http://www2.bryceharrington.org:8080/X/Reports/patches.html
<kfogel> intellectronica: this is in lib/lp/bugs/model/bugtarget.py ?
<thumper> gary_poster: do you know about copy_field?
<thumper> I have a feeling it isn't quite doing what I want
<gary_poster> thumper: I don't think I do.  I'll look at it if you like
<thumper> hmm..
<thumper> fields have implicit names somewhere don't they?
<gary_poster> you mean, they know what they were called in the interface?  if so, yes
<thumper> gary_poster: I mean what the widget names become
<thumper> fields.xxx
<gary_poster> ah, yes, they do
<thumper> hmm
<thumper> I have branch_name = copy_field(IBranch['name'])
<gary_poster> I'm pretty sure you can affect those names
<thumper> and I want the widget and field to be called 'branch_name' not 'name'
<gary_poster> thumper, will look at zope.formlib, one sec.  I think that's the pertinent bit.  Where is copy_field defined?
<thumper> lazr.restfull
<thumper> s/ll/l/
<gary_poster> a ok
<thumper> .interfaces
<gary_poster> thumper: try ``copy_field(IBranch['name'], __name__='branch_name')``
<thumper> gary_poster: I was just about to try that :)
<gary_poster> :-)
<thumper> works :)
<thumper> ta
<kfogel> intellectronica: still on?
<kfogel> intellectronica: can hear me?
<al-maisan> rockstar: https://bugs.edge.launchpad.net/soyuz/+bug/497520
<mup> Bug #497520: Disabled archives should automatically have their waiting builds removed <buildfarm> <ppa> <soyuz-build> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/497520>
<lifeless> barry: ping
<barry> lifeless: pong
<lifeless> barry: you've climbed around inside distutils right
<barry> a bit ;)
<lifeless> I have two questions for you
<lifeless> what does bzr integration actually do
<lifeless> and
<lifeless> how can I get 'setup.py sdist upload' to set the description field on the new release that that creates?
<lifeless> barry: ^
<barry> lifeless: sorry, multitasking ;)
<barry> the setuptools_bzr really just allows lazy package authors to not have to write a MANIFEST.in
<lifeless> barry: au naturale
<barry> it essentially queries bzr to find out what files are under vc and automatically adds them to the manifest
<lifeless> barry: ah, its setuptools only? not distutils?
<barry> i think it's distutils too, but distutils only supports svn out of the box
<barry> lifeless: in truth though, it's much more trouble than its worth, so i don't plan on continuing to support it
<barry> lifeless: and our lp packages don't use it any more
<barry> the trouble isn't so much bzr, but distutils :/
<kfogel> intellectronica: you're in UK right?
<intellectronica> kfogel: yup
<barry> as for your second question, setting the 'description' and 'long_description' in your setup.py should do the trick.  does it not?
<jml> mwhudson, what's the correct type for sourcepackagerecipe.manifest
<jml> sprbuild.manifest
<jml> rather.
<mwhudson> jml: in the zope.schema sense?
<jml> mwhudson, indeed.
<mwhudson> jml: probably just Attribute
<kfogel> intellectronica: let's pick this up tomorrow then; I'm startig pretty early anyway, and I think it would be useful for me to do some poking around on my own now.
<jml> mwhudson, ok.
<intellectronica> kfogel: cool
<kfogel> intellectronica: a lot of the dev wiki documentation makes a lot more sense now -- thank you for your help.
<mwhudson> jml: for api purposes we'll want to expose a text representation i guess
<mwhudson> jml: requires bzr-builder changes tho
<lifeless> barry: which one ends up in the rest field in pypi
<intellectronica> np. zope is a beast, but you'll get it in no time
<barry> lifeless: otp
<lifeless> otp?
<mwhudson> on the phone
<mwhudson> i expect
<EdwinGrubbs> sinzui: ping
<mwhudson> (not the erlang standard library thing)
<sinzui> Hi EdwinGrubbs
<lifeless> ah yes
<EdwinGrubbs> sinzui: can you think of any reason that the Reply-To header set in notify_team_join() should actually be the proposed member's email address as opposed to the reviewer who is actually proposing them?
<sinzui> EdwinGrubbs: yes. "invite" in the ui is admin -> user, but "propose" in the ui is user -> team
<sinzui> EdwinGrubbs: So the user performing the action should be the reply to.
<EdwinGrubbs> sinzui: I guess I should just remove the security proxy here when someone besides an LP admin or the user themself tries to propose someone as a member through launchpadlib.
 * sinzui thinks
<sinzui> EdwinGrubbs: I think that is fair. If the user wants to join the team he must be willing to share his address. We do not how ever want someone to be able to craft a script to propose joining a team to learn another user's email address. In the contact-this-user feature the email address is shown to the other user. If the other user has a hidden email address, he must chose carefully about the consequences of his reply.
<sinzui> EdwinGrubbs: I think joining a team is a lot like contact-this-team, so I this the rules of disclosure should be the same.
<sinzui> EdwinGrubbs: We do use removeSecurityProxy() when send contact-this-user emails.
<EdwinGrubbs> sinzui: oh, no, it could be used like that in launchpadlib, since it is not the user calling team.join(), it's a team admin calling team.addMember(status=PROPOSED) which normally doesn't happen ever.
<sinzui> indeed that sounds wrong because the invite is in the wrong state. Proposed means the admin must approve, and surely he would since he just proposed it.
<EdwinGrubbs> sinzui: I think I will have to talk to the user some more to figure out why they are doing that.
<sinzui> "invite" is for an admin to contact another team to ask their approval to be added. I favour allowing admins to invite users so that the user can accept rather then discover someone claims they wanted to join the team
<al-maisan> rockstar: lp:~al-maisan/launchpad/disabled-builds-497520
#launchpad-dev 2010-01-12
<al-maisan> rockstar: http://pastebin.ubuntu.com/355257/ (the UPDATE query)
<lifeless> barry: off the phone?
<barry> lifeless: yep.  had dinner too :)
<lifeless> so
<lifeless> 09:48 < lifeless> barry: which one ends up in the rest field in pypi
<barry> lifeless: what is "the rest field"?
<lifeless> there is a field called description which takes ReST
<lifeless> and makes the pypi page pretty - e.g. if you look at http://pypi.python.org/pypi/testresources
<barry> wouldn't that be long_description?
<lifeless> I don't know... thus my asking ;)
<barry> lifeless: i think so
<lifeless> I'll try long_description on my next upload.
<barry> lifeless: also, do you know about packages.python.org?
<lifeless> no, never heard of it
<barry> lifeless: http://packages.python.org/munepy/
<lifeless> pretty
<barry> lifeless: you upload a zip file with an index.html.  nice for uploading a full sphinx documentation tree
<lifeless> oh cute
<lifeless> can setup.py do that too?
<lifeless> or better yet, is there an API for doing all this without setup.py ?
<barry> lifeless: if you go to a package you admin, and click on the pkg_edit link, you'll see an upload form.  not sure if it can be uploaded from setup.py
<barry> lifeless: that i'm not sure about
<lifeless> whats the right place to find out (about setup.py for starters)
<barry> lifeless: disutils-sig probably
<barry> lifeless: oh also...
<barry> http://docs.python.org/distutils/index.html
<lifeless> heh
<lifeless> I've been reading that
<lifeless> but it seems to leave a lot out
<barry> lifeless: other than that, it's all magic :)
<barry> distutils-sig then probably
<lifeless> thanks
<barry> np.  will probably be mostly offline for the rest of the evening.  have a good one!
<jml> mwhudson, have you added a makeRecipe to the factory?
<mwhudson> jml: no
<al-maisan> rockstar: http://pastebin.ubuntu.com/355298/
<jml> mwhudson, ok if I move makeBuilderRecipe?
<mwhudson> jml: go for it
<jml> mwhudson, thanks.
<al-maisan> rockstar: ./lib/lp/soyuz/tests/test_archive.py
<al-maisan> jtv: here you go: http://pastebin.ubuntu.com/355304/
<jtv> al-maisan: thanks!
<jml> thumper, https://code.edge.launchpad.net/~thumper/launchpad/active-branch-counts/+merge/7440
<jml> wgrant, we should get https://code.edge.launchpad.net/~wgrant/launchpad/bpr-ddeb_package-db/+merge/14008 sorted out this week
<mwhudson> stub: hello
<mwhudson> stub: can you review https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-db-schema/+merge/16268 again please?
<stub> yo
<mwhudson> ideally after i've pushed the most recent revision...
<stub> mwhudson: With comments in comments.sql so this makes more sense to a layperson?
<mwhudson> stub: oh right
<mwhudson> wow, comments.sql is SO FAR from alphabetical right now
<jamesh> run it throught sort?
<mwhudson> sadly i don't think that would quite work
<stub> mwhudson: SourcePackageRecipeDataInstruction.recipe_data should be NOT NULL?
<mwhudson> stub: certainly, yes
<stub> Oh... jono mentioned already.
 * stub waits for latest diff
<mwhudson> stub: diff is up to date now
<mwhudson> stub: jml was actually meaning something else :)
<jml> noodles775, actually, I think the build behaviour classes should rightly live in lp.SOMETHING.adapters
<jml> where something is probably soyuz.
<bigjools> buildmaster?
<jml> yeah, maybe that too
<jml> or in the adapters module of their respective apps
<jml> binarypackage in soyuz, recipe in code etc.
<noodles775> sounds good.
<jml> anyway, that's later.
<jml> (we should have a "where do things go" kind of document too)
<jml> ((and code to enforce it))
<jml> (((and fix all the broken stuff too)))
<mwhudson> stub: is stuff like date_last_modified considered sufficiently obvious to not need an entry in comments.sql?
<stub> mwhudson: Generally, yeah. If the comment just repeats the column name there isn't much point.
<mwhudson> ok
<jml> noodles775, you guys aren't working on an interface for the BuildSourcePackageFromRecipeJob table, are you?
<noodles775> jml, Nope.
<jml> noodles775, thanks.
<al-maisan> rockstar, jtv : the XXX bug is #506255
<mup> Bug #506255: Refactor BuildQueue unit tests <buildfarm> <Soyuz:Triaged> <https://launchpad.net/bugs/506255>
 * thumper EODs
<bigjools> Schwarzenegger fan?
<jtv> jamesh: got a nice little pickle with Storm... care to do some puzzling?
<jamesh> sure
<jtv> thanks.  I've got a class that is not orm-backed, but one of its base classes is.
<jtv> or actually, one of its base classes _delegates_ to a class that is.
<jamesh> that sounds a bit weird ...
<jtv> branchjob hierarchy.
<jtv> now, some generic code elsewhere goes "what class do you need?  Okay, I'll build a Storm query on that class."
<jtv> And when it tries that for my class, things go "boom, there's no __storm_table__ here"
<jtv> Changing that generic code could be a bit painful
<jamesh> maybe you shouldn't use this class with the generic code then?
<jtv> Replacing this class would also be painful.
<mwhudson> i am bored of waiting for make schema
<jtv> It'd be perfect if Storm were able somehow to deal with the delegation.
<jamesh> mwhudson: you should delete some sample data then
<jamesh>  iirc, that was one of the big time sinks
<mwhudson> security.py seems to be the longest part
<jtv> delete some tables
<mwhudson> i think it's the usual "we have too many tables"
<jamesh> jtv: I'm not exactly certain what you're trying to do with this class, so it is difficult to say.
<jamesh> mwhudson: ah.  I seem to recall thinking that could be optimised somewhat
<jamesh> perform multiple grants in a single statement
<jamesh> jtv: can you point me at the code in question?
<jtv> jamesh: it's still in ec2...  the weird construct with the delegation is imposed by existing interfaces though; see lib/lp/code/model/branchjob.py
<jtv> There's BranchJob (implementing IBranchJob), with its specialized child classes that are all based on BranchJobDerived.
<jtv> BranchJobDerived delegates IBranchJob to BranchJob.
<jamesh> jtv: and what code are you passing these instances to?
<jtv> jamesh: in lib/lp/soyuz/model/buildqueue.py you'll find a property specific_job.
<jtv> That tries to query the class.
<jtv> But for my case of course, the wrong class.
<jtv> (It ends up there by registration of a utility in zcml)
<jamesh> jtv: my suggestion would be to not do what you're doing then.
<jtv> jamesh: yes, maybe the way out is to de-generalize the query and move it into the utility.
 * mwhudson fights with implicit flushes trying to write half constructed objects to the database
<jtv> mwhudson: if that's a non-storm class: storm is a bit less eager to add objects to the store
<jamesh> jtv: or try to use adaption
<mwhudson> jtv: it's all storm
<mwhudson> it adds it to the store as soon as you link it to another database object
<mwhudson> i wonder if there's a way around that
<jtv> jamesh: I don't think adaptation would help here.  :(
<jamesh> jtv: could you adapt (IJob, BuildFarmJobType) to IBuildFarmJob?
<mwhudson> jamesh: can you help with this ?
<jamesh> basically make the work done by BuildQueue.specific_job the responsibility of an adater?
<jamesh> mwhudson: reorder how you set things in the constructor?
<mwhudson> jamesh: sadly building related objects requires queries
<mwhudson> i can probably fight my way to something
<jtv> jamesh: where BuildFarmJobType is the enumeration?  Or my own BuildFarmJob derivative?
<jamesh> mwhudson: alternatively, do the queries before setting properties on the new object, so you don't implicitly add it to the store
<jamesh> then it can't be implicitly flushed out
<mwhudson> jamesh: yes, that's what i have to do i think
<jamesh> jtv: I don't know this bit of the code well enough to answer that.
<mwhudson> it's all a bit circular though
<jtv> jamesh: I think I'll work in the direction of an extra utility interface method tomorrow
<jamesh> jtv: alternatively, make the specific_job_classes code look up interfaces rather than utilities, then try to adapt the job to that interface
<jamesh> rather than doing multi-adaption
<jtv> jamesh: that sounds nice... still means extra zcml for each class of course
<jtv> particularly annoying is that the specific_job_classes keeps track of the model classes, not the interfaces
<jamesh> anyway.  It is the soyuz code that looks crazier than the codehosting bits
<jamesh> so I guess things haven't changed too much in Launchpad
<jtv> (and some of these model classes may not need their own interfaces)
<jamesh> if you do want to go with adaption, garry or flacoste would be good people to talk to
<jamesh> (although they do live on the wrong side of the planet)
<jtv> jamesh: I guess tomorrow morning we'll be able to talk to folks on the West Pole
 * jamesh curses the sticking keys on his keyboard
<wgrant> Oh, goody, buildStatus_OK is completely untested.
<mrevell> morning
<arnaud__> hi all
<mwhudson> stub: can you look at https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-db-schema/+merge/16268 one more time?
 * stub looks
<kfogel> adeuring: quick question
<adeuring> kfogel: yes?
<kfogel> adeuring: I had some good help from intellectronica last night; he suggested that putting this functionality (for bug #506018) into HasBugs is the right way to go.  I'm in lib/lp/bugs/browser/bugtarget.py -- should I add a "BugTargetPatchesView" or should this be called just "PatchesView"?
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/506018>
<kfogel> I.e., not sure when to say "BugTarget" and when not, due to slightly fuzzy relationship between BugTarget and HasBugs in my mind.
<adeuring> kfogel: without looking into HasBugs, I'd say that BugTargetPatchesView is, let's say, too "narrow". We'll need that view for teams too, and teams are not bug targets, but IIRC implement HasBugs
<adeuring> kfogel: so, the simple "PatchesView" looks more reasonable
<kfogel> adeuring: but implementing the view in browser/bugtarget.py is still the right place, or should it be bug.py or some other file?
<kfogel> adeuring: (oh, btw, how about "BugsPatchesView"?  Seems wrong not to have "Bugs" in there, somehow.)
<adeuring> kfogel: hmmm. Since most other "relevant" stuff is in BugTarget, I think we should keep the new class there.
<kfogel> adeuring: thanks.
<adeuring> kfogel: yeah! that's a good name, i think
<kfogel> adeuring: using that then
<kfogel> adeuring: should it subclass either BugTargetBugsView or BugTaskSearchListingView?  (Soon I'll just post a patch with lots of questions :-) ).
<adeuring> kfogel: good question.... lets me look...
<adeuring> I'd opt for BugTaskSearchListingView. I think we can simply call its search() method with "canned parameters" in the new class
<kfogel> adeuring: hmm.  okay, thanks.  Remember that a single bug may have multiple patches attached -- i.e., our list lists by patches, not bugs, so conceivable the same bug may appear multiple times.  That'll be okay with BugTaskSearchListingView?  (you can see it on Bryce's example page, actually: http://www2.bryceharrington.org:8080/X/Reports/patches.html)
<adeuring> kfogel: good point....
<adeuring> kfogel: but even if we need to rebuild the query, we can make more use from helper mthods in BugTaskSearchListingView, I think
<kfogel> adeuring: ok
<kfogel> adeuring: I'm creating templates/bugtarget-patches.pt right now.  I'm basing it off bugtarget-bugs.pt, and removing things like, e.g., the sidebar.  Who is the "Bob Johnson" hardcoded intothat file?
<kfogel> adeuring: (or if there's some better template file to start from, let me know)
<adeuring> kfogel: never heard about that guy ;) Just a place holder that's replaced by real supervior's name
<kfogel> hunh  okay :-)
<adeuring> kfogel: no, i think it'f fine to use that template
<leonardr> bac, did you ever resolve the problem you were having with the lplib cache? i remember you saying that you'd made a change to your local launchpadlib
<leonardr> and i can't duplicate your transcripts
<kfogel> deryck: quick question: in the patch-in-progress at https://pastebin.canonical.com/26445/, search for "###".  See my question there -- what's the right type for this list (or for the objects in the list, or is this the wrong way to go about it?)
<kfogel> gmb: you might be able to answer above question I directed at deryck
<deryck> kfogel, I'm honestly not sure.  That's a zope thing for the field type for dealing with individual patches in the list...
<deryck> kfogel, and I don't know what type patches might be.  Perhaps intellectronica can help, if gmb isn't available.
<kfogel> deryck: np.  It's not crucial yet, just will be soon.  I'll ask others when I get to that point.
<kfogel> deryck: they're attachments, but formally what to call that, I'm not sure.  I'll bet intellectronica knows, or knows how to find out.
 * intellectronica reads back
<deryck> kfogel, perhaps looks at "attachments" in lib.lp.bugs.interfaces.bug
<intellectronica> kfogel: it's an IBugAttachment
<kfogel> intellectronica, deryck: thanks!
<deryck> there you go :-)  he's so quick
<kfogel> IIntellectronicaWin
<deryck> heh
<kfogel> hah
<kfogel> make run:
<kfogel>     ZopeXMLConfigurationError: File "/home/kfogel/private/work/canonical/lp/lp-branches/506018-patch-report/lib/lp/services/openid/configure.zcml", line 11.4
<kfogel>     SyntaxError: invalid syntax (bugtarget.py, line 68)
<kfogel> make: *** [run] Error 1
<kfogel> thanks, Zope.  now to find which of the three files I have open named "bugtarget.py" that is... :-)
<kfogel> interfaces
<kfogel> intellectronica: a bit of debugging help: this is my current patch: https://pastebin.canonical.com/26448/.  When I do 'make run', launchpad.dev runs, but if I visit (say) https://launchpad.dev/~name12/+patches, I get the no-such-page "Lost something?" error page
<kfogel> I think I'm still missing a piece :-).
<kfogel> intellectronica: also, I can visit https://launchpad.dev/projects, but visting any actual project page gets an OOPS error.  Is this expected in a dev instance?  I thought there was sample data in the db.
<kfogel> deryck: TZ implies you may be the only one around to answer the above questions I directed at intellectronica :-).
<intellectronica> kfogel: because you're looking for it on a person and not a has-bugs
<kfogel> intellectronica: I thought a person was a has-bugs too??
<kfogel> they're not?
<intellectronica> kfogel: oh, maybe it is? what happens if you try this of a project?
<kfogel> intellectronica: (see above about trying to do it via a particular project)
<intellectronica> kfogel: so the oops must be something you introduced. what is the error?
<kfogel> intellectronica: let me get it, hold on
<kfogel> intellectronica: it certainly looks like something I introduced; see very end of this traceback https://pastebin.canonical.com/26450/
<deryck> intellectronica, kfogel -- is browser/configure.zcml right for what karl wants?  Shouldn't this be for IHasBugs and not IBugTarget?
<kfogel> intellectronica: wait, let me do that properly on ubuntu's pastebin
<intellectronica> kfogel: right, that's because all_bugtasks is a property and not a method. remember we talked about properties and how they're methods but they masquerade as attributes?
<kfogel> deryck, intellectronica: http://paste.ubuntu.com/355633/ (just to be conducting things properly -- it's the same paste)
<intellectronica> kfogel: remove the () and you should be good
<kfogel> intellectronica: yes!  thanks
<kfogel> intellectronica: on attachments too (no "()" )
<intellectronica> kfogel: yes
<kfogel> deryck, intellectronica: oh, duh.  okay, a person is not a has-bugs because you don't file a bug *against* a person.  A person may be subscribed to, or be assigned to, or be the reporter of, a bug, but that's different from being an entity that can actually *have* a bug, as in have a bug reported against it.
<kfogel> Is that a fair summary?
<intellectronica> kfogel: sort of. do you need this to work for a person?
<intellectronica> we can maybe make a person implement IHasBugs fully if necessary. don't remember what's involved
<kfogel> intellectronica: mmmm, at some point probably yes, that would be the user-friendly thing to do.  But it's not the most important thing right now, so let's not worry about it.
<intellectronica> kfogel: cool. does it work for other IHasBugs implementations like IProduct?
<kfogel> intellectronica, deryck: w00t!  thank you: http://www.red-bean.com/kfogel/hello-world.png
<kfogel> intellectronica: see above
<intellectronica> :)
<intellectronica> kfogel: hint for the next step. try <table><tr tal:repeat="patch context/patches"><td tal:content="patch/title"></tr></table>
<bac> leonardr: no, the problem is not resolved.  the transcript i sent you is based on the egg as used in launchpad.
<bac> leonardr: are you using the launchpad version or another?
<leonardr> bac: i'm doing exactly what you're doing
<bac> leonardr: that's really weird.  if i get time i can try it on another machine
<leonardr> bac: sounds like the best option
<bac> leonardr: yep.  i'll let you know what i discover
<kfogel> intellectronica: thx
<kfogel> intellectronica: I just discovered I don't have to restart if I edit the .pt file.  I think I'm in heaven.
<bac> leonardr: in a new VM i did the same experiment and got the same results as seen in http://pastebin.ubuntu.com/352999/
<leonardr> bac: the best advice i can give is to put in some debug points and see how the bad cache dir gets built
<thumper> morning
<kfogel> thumper: morning
<EdwinGrubbs> bac: I found out why the merge page was raising an Unauthorized exception, when the other pages with the person picker were not. PersonAccountToMergeVocabulary uses getUtility(IPersonSet) instead of just using the Person db objects like the other vocabs.
<bac> EdwinGrubbs: ah, interesting
<deryck> Later on, everyone...
<kfogel> deryck: l8r
<kfogel> intellectronica: I'm trying to understand this (which I just wrote, based on something you said earlier) in bugtarget-patches.pt:
<kfogel> <table><tr tal:repeat="patch context/patches"><td tal:content="patch/title">Hello, world!</td></tr></table>
<mwhudson> morning
<kfogel> intellectronica: what do these repeat and content attributes do, exactly?
<kfogel> intellectronica: I'm guessing that the first says to make as many <tr>...</tr> elements as there are patches, somehow;
<kfogel> and the second says what <td>...</td> elements to put in each tr.
<kfogel> But the values of those attributes are a bit mysterious to me.
<kfogel> mwhudson: morning!
 * mwhudson finds Person.visibilityConsistencyWarning, is scared
<EdwinGrubbs> sinzui: ping
<mars> beuno, ping, do you have a list of key, most used Launchpad pages by type?  BugtaskIndex, CodeHome, etc. etc.?
<mars> PPA would be in there somewhere...
<beuno> mars, I don't handy, but I did some grepping through logs with a script that I think flacoste built
<beuno> that may of been a year ago  :)
<mars> yeah, I remember you can derive the page type from the appserver log output, but I was hoping someone had already done so for me.
<beuno> mars, there is a script that does that
<beuno> I fixed it when I picked it up
 * beuno looks for it
<beuno> mars, I *think* it was lp-access-log-analyzer.py
<beuno> yes it is
<sinzui> hi EdwinGrubbs
<wgrant> abentley: lp:~wgrant/launchpad/lp-buildd-sourcepackagerecipe-support
<wgrant> abentley: See the XXXs in lib/canonical/buildd/sourcepackagerecipe.py
<mars> beuno, I can't find it.  Is it in trunk/?
<abentley> wgrant: Thanks.
<mars> beuno, ah! in lp-dev-utils/
<beuno> mars, it's in lp-dev-utils
<beuno> which I though had been merged into trunk?
<mars> last revno on lp-dev-utils/trunk is Jan 6th, so it is still active I assume
<bac> leonardr: i used the latest version of lplib (still set at 1.5.4 but newer than the released 1.5.4) and the problem goes away
<leonardr> bac: so you have the problem with the version packaged with launchpad but not with the version in versio ncontrol?
<bac> leonardr: yes, that is correct
<bac> leonardr: so when 1.5.5 is released and lp uses it the issue will be resolved
<mars> beuno, just wondering, do you have the list of most-visited projects and/or pages from a year ago?  That list may still be valid.
<beuno> mars, I don't. awstats may give you some of that information
<leonardr> ok, let me try to find the difference bewtween those versions
<mars> beuno, ok, thanks
<leonardr> bac: i think there may have been a bug having to do with the cache dir and the launchpadlib dir being switched in some method call
<leonardr> bac: i'll do a new release of launchpadlib tomorrow
<beuno> leonardr, you may have some insight on this:  https://pastebin.canonical.com/26435/
<leonardr> beuno: well, the file name's too long...
<leonardr> i designed launchpadlib before i knew ext4 was going to impose lengths on filenames
<leonardr> i don't know what to do about it (in this case or in general)
<wgrant> eCryptFS makes it much worse, too :(
<beuno> I am of course, using both
<leonardr> i can change launchpadlib to hash the string and use that as the filename
<leonardr> that will fix the length problem but will make it extremely difficult to examine the cache
<mars> beuno, ok, maybe some good guesses are in order.  The Bzr project homepage is one.  What else?
<mars> Some closed/fix-released Bug Index page would be good.
<beuno> mars, what is it you're trying to find out?
<mars> The launchpad.net homepage is good.
<mars> beuno, I've coded a library, pyslow, that automates YSlow stats collection.  I am looking for pages to start collecting with.
<mars> code.launchpad.net/bzr might also be good.  code.launchpad.net/launchpad is a bit too large to be representative.
<beuno> mars, a bug page
<kfogel> wgrant: got time for some debugging help?
<beuno> a popular bug
<beuno> mars, something other than bug 1  :)
<mars> beuno, yep, but a closed bug.  Otherwise new comments may cause stats drift.
<mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:In Progress by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Confirmed for shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubun
<beuno> mars, right
<beuno> mars, another one is a translations overview page
<mars> ah!
<mars> good idea
<mars> and PersonIndex, of course
<beuno> mars, a branch index, and a merge proposal page
<mars> ok, both good ideas
<mars> beuno, is the translations overview just translations.lp.net/someproject ?  Or is it underneath that?
<mars> beuno, the PPA index page would be good as well
<kfogel> mars, beuno, or anyone: http://paste.ubuntu.com/355726/ is the result of visiting bugs.launchpad.dev/redfish (a test project) running the code in https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report.  I'm sure the traceback has something to do with my changes, but can't see what.  Any ideas?
<bac> leonardr: hey that's great
<beuno> mars, https://translations.edge.launchpad.net/ubuntu/karmic/+lang/es
<leonardr> i might as well try to do something about the file length while i'm at it
<beuno> danilos, btw, that page looks very squished ^^
<mars> leonardr, ^ any idea what kfogel is seeing?
<mars> leonardr, something to do with the webservice going into his page's LP.client.cache
<kfogel> mars: really?
 * kfogel looks
<kfogel> mars, leonardr: note that if you visit the bugs page for a project that has no bugs (e.g., https://bugs.launchpad.dev/lies) everything works fine.
<wgrant> kfogel: Bit busy sprinting at the moment, sorry.
<kfogel> wgrant: np, thanks for letting me know
<leonardr> mars, kfogel: launchpad is putting a json representation of your test project into LP.client.cache['context'], but it's failing--probably an error is happening when generating the json representation
<leonardr> if you try to get that test project through the web service, you'll probably get a better error message.
<kfogel> leonardr: thanks
<kfogel> leonardr: I understand conceptually what you're suggesting, but have not actually done it in a long time.  Is it visiting a URL like api.launchpad.dev/something?
<mars> kfogel, https://api.launchpad.dev/beta/some-project
<mars> should work
<mars> use curl or wget
<mars> or the browser
<kfogel> mars: I tried it in my browser and got http://paste.ubuntu.com/355730/
<mars> kfogel, argh, my bad.  Try: https://launchpad.dev/api/beta/some-project
<kfogel> mars: aaaah
<kfogel> one sec
<kfogel> mars, leonardr: TERRIFICALLY HELPFUL error from that, thank you!  That is one trick I'm going to remember.  http://paste.ubuntu.com/355734/
<kfogel> (and yes, it was my code)
<mars> kfogel, maybe add it to http://dev.launchpad.net/Debugging ?
<mars> since that is a nasty information-hiding error you uncovered there
<kfogel> mars: I am :-)
<EdwinGrubbs> sinzui: should a new unit test for vocabularies go in lp.app or lp.coop or just in canonical.launchpad.tests?
<kfogel> mars: even better would be to make the web ui error as informative as the web services error...
<sinzui> EdwinGrubbs: which vocab is it testing?
<EdwinGrubbs> sinzui: all of them
<sinzui> lp.services maybe
<EdwinGrubbs> ok, cool
<sinzui> EdwinGrubbs: We do not want to add the canonical. and I think lp.app is specific to integration code.
<sinzui> EdwinGrubbs: If you have doubts, place it in lp.app
<EdwinGrubbs> sinzui: all it's doing is checking whether the vocabs are security wrapped, which is sorta integration but not between apps
<kfogel> mars: https://dev.launchpad.net/Debugging#Getting%20Better%20Tracebacks
<sinzui> EdwinGrubbs: I think services is the best place
<mars> kfogel, maybe put it at the bottom, call it "Tracing obscure TAL template errors for mangled webservice objects", and link to your pastebins?
<mars> kfogel, my concern is that "Getting Better Tracebacks" is actually a bit vague, whereas you solved a very specific problem (and helpfully posted evidence to help us help you)
<kfogel> mars: so I wasn't sure how long Ubuntu pastes live.  (the site doesn't say) are they forever?
<kfogel> mars: and, does your advice only apply to TAL template errors of that sort, and not to nasty tracebacks in general?
<kfogel> mars: (note that when I encountered it, I didn't know that it fell into that category, and I'm not sure any other newbie would.  so we want the widest category of traceback for which the advice still holds...)
<sinzui> flacoste: root-index.pt still has:
<sinzui>     <li tal:condition="context/required:launchpad.Admin">
<mars> kfogel, I would say your case was pretty specific: writing a new template, looks OK, load it, BOOM
<sinzui> flacoste: sorry I meant to paste that into #launchpad-reviews
<flacoste> sinzui: that's fine
<flacoste> sinzui: i'll fix it
<mars> kfogel, leonardr and I knew it was a webservice problem right away, because of the specific template line that went bad.  The advice of checking the webservice was pretty specific.  However, I do not know if other TAL errors mask problems with model objects in a similar way.
<kfogel> mars: help me figure out the right title here.  I fear that anyone who knows enough to know that their error is a "TAL template error for a mangled webservice object" is less likely to be in need of this debugging advice...
<mars> hmm, true
<mars> well, it was specifically an error with a new TAL template, and the error was (and presumably will always be): LocationError: (<lazr.restful.tales.WebLayerAPI object at 0xd932ccc>, 'json')<br />
<kfogel> mars: and the web services advice wouldn't necessarily hold under other circumstances?
<mars> kfogel, that I do not know.  I can't think of any other circumstances besides "my new code broke the model, my page spat out this weird webservices error"
<kfogel> mars: *nod*
<kfogel> flacoste: do you know how long pastes at paste.ubuntu.com live?  I.e., can we refer to them from permanent pages in the wiki?
<flacoste> kfogel: i don't
<kfogel> flacoste: np
<kfogel> mars: https://dev.launchpad.net/Debugging#Understanding%20TAL%20template%20tracebacks%20for%20mangled%20webservice%20objects
<kfogel> mars: not happy with the title, but not sure what else to call it
<mars> kfogel, "Tracing past "LocationError: 'json'" in TAL templates" ?
<kfogel> mars: I want to get the word "traceback" in there, since that's what someone will be looking at when they go looking for this advice.
<mars> kfogel, up to you.  I find tracebacks to be implicit with any meantion of a "TAL Error".  The two are entwined, forever seared into memory.
<kfogel> mars: I don't think that will be the case for many people :-).
<kfogel> mars: https://dev.launchpad.net/Debugging#Getting%20past%20%22LocationError:%20%27json%27%22%20in%20TAL%20template%20tracebacks
<kfogel> mars: good enough for newbies now, more or less
<thumper> bzr-hg imports working in dev branch, up for review \o/
<poolie> nice one
<bigjools> hi poolie, how's it going
<poolie> good thanks, how are you?
<bigjools> poolie: enjoying the sprint!
<poolie> i'm free to talk any time this week
<poolie> though right this moment is not quite so good
<bigjools> ditto
<bigjools> maybe this afternoon?
<barry> sinzui: do you really want me to approve joining gdp-developers to haibunku?
<sinzui> barry: no. I forgot you get staging email
<sinzui> but...
<barry> sinzui: no worries, i had a feeling that was it
<sinzui> I think you are the prefect person to verify a invitation to join a super secret team
 * barry loves secrets
<sinzui> bac: ping
<barry> sinzui: i'm about to catch some dinner, but will be back in a bit
<sinzui> okay, you'll see the invite in a few minutes
<sinzui> barry: you should receive an invite on behalf of haibunku for https://staging.launchpad.net/~private-ufos If you can see and accept the invitation, you will be the first person I know of to allow a public team to be a member of a private team.
<sinzui> losa ping
<barry> sinzui: hasn't shown up yet
<sinzui> hmm
<barry> oh wait, staging
<sinzui> Yes, and I see two?
<sinzui> oh, flacoste is also an admin
<barry> as do i
<barry> right
<barry> accepted!
<sinzui> you saw the page?
<sinzui> wow this is big. I wonder what the effort is to allow a private team be a member of a private team?
<sinzui> thank you very much barry
<barry> sinzui: np, and yep, it's way cool.  gotta run.
<jml> jtv, https://code.edge.launchpad.net/~jml/launchpad/behavior-refactor
#launchpad-dev 2010-01-13
<cody-somerville> Ugh, there appears to be a pretty serious bug with the launchpad import system. I just created a new import and it made me the owner instead of the vcs import team.
<cody-somerville> Is it safe to make the vcs import team the owner?
 * cody-somerville will ask for forgiveness later.
<cody-somerville> ugh, I did it mid-import too
 * cody-somerville hopes for the best.
<lifeless> cody-somerville: why would you want the vcs import team to be the owner?
<lifeless> cody-somerville: its your import
<lifeless> jml: ^
<cody-somerville> me being a member of vcs-imports aside, I don't want to accidentally push to my import which I imagine would cause problems the next time the importer runs and tries to import new revisions
<jml> cody-somerville, you can't, I don't think. It ought to be r/o
<cody-somerville> which is why I thought the branches were owned by vcs-imports
<cody-somerville> Is there another mechanism now that makes them r/o?
<wgrant> They're import branches, not hosted branches. They're Special.
<cody-somerville> The UI should reflect that.
<mwhudson> cody-somerville: they've always been read-only for reasons other than team membership
<thumper> cody-somerville: does the UI not reflect that?
<thumper> cody-somerville: I'm pretty sure it says it is updated by the code import service
<cody-somerville> I'm not the only person to be confused by this change.
<cody-somerville> I believe james_w mentioned this the other day as well
<cody-somerville> I thought it was only "r/o" cause of the team who owned it
<mwhudson> rockstar: https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-model-code/+merge/16272
<al-maisan>  Bug #506617
<mup> Bug #506617: make Builder._findBuildCandidate() operate across all build farm job types <buildfarm> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/506617>
<al-maisan> jtv: http://pastebin.ubuntu.com/355856/
<jml> lifeless, do you have access to pqm.launchpad.net any more?
<lifeless> no
<lifeless> I mean
<lifeless> I can see the web page
<lifeless> :P
<jml> lifeless, right. I meant special access.
* jml changed the topic of #launchpad-dev to: PQM in testfix, not sure why | Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<mwhudson> jml: pjdc has access
<mwhudson> but will require handholding
<jml> mwhudson, it would be the blind leading the blind with me
<jml> mwhudson, who'd know what they were doing?
<mwhudson> i guess i know a bit
<lifeless> its documentef
<mwhudson> i wrote the documentation!
<lifeless> some of it:)
<jml> the bits with apostrophes :P
<mwhudson> i wrote it for the crummy launchpad specific stuff that's currently falling on its arse
<lifeless> :)
<jamesh> now that you've got lots of users, do you really need the test suite any more?
<jamesh> surely with many eyes, all the bugs will be shallow
<stub> My wadl explodeth
<mwhudson> stub: make clean
<mwhudson> then try again
<stub> Done
<stub> And failed again
<mwhudson> hm
<stub> File "/home/stub/lp/replication/lib/lp/code/model/branchjob.py", line 134, in BranchJobType
<stub> File "/home/stub/lp/lp-sourcedeps/eggs/lazr.enum-1.1.2-py2.5.egg/lazr/enum/_enum.py", line 100, in docstring_to_title_descr
<stub>     assert not lines[num+1].strip()
<mwhudson> stub: i just submitted my schema patch to pqm with a further change
<mwhudson> stub: to whit, this: http://pastebin.ubuntu.com/355888/
<mwhudson> stub: i hope this is ok :-)
<stub> mwhudson: No problems there
<jml> \o/
<mwhudson> stub: great
<stub> I think rockstar's landing broke db-devel. My launchpad/devel is building fine, my db-devel is failing unable to build wadl, that is the only landed patch on that branch since the last db-devel buildbot build and he touched branchjob with is similar to the area in the wadl generation that explodes.
<stub> And reverting that patch fixes things
<rockstar> stub, it went through ec2 just fine.
<stub> It hasn't yet
<rockstar> stub, no, I mean I sent it through ec2
<stub> Oh... not buildbot
<stub> hmm
<stub> Anyone else reproduce this locally?
<rockstar> stub, trying now.
<rockstar> I just did a make clean and a make.
<stub> On your branch, or your branch merged with latest db-devel?
<stub> Your patch might be victimized by some other update, like a lazr changes.
<rockstar> stub, oh noes, it's broken here now too.
<stub> version.cfg changed recently - probably passes with old dependencies but fails with current.
<rockstar> stub, I think I know what this is.
<stub> The assert above seems to suggest a docstring not conforming to some standard, but neglects to produce a meaningful error message.
<rockstar> stub, yes, it's not conforming to the Enum standard.
<rockstar> stub, I've got a fix.  It's just whitespace.  Can I have your rs, or should I pastebin?
<stub> rs
<rockstar> stub, thanks, sending fix now.
<rockstar> stub, fix is off to pqm
<wgrant> noodles775: Only that one failure, it looks like. Thanks for running it.
<noodles775> wgrant, yeah! Great work!
 * wgrant works out where that logger is coming from.
<noodles775> G'night.
<mrevell> Mornin' all
<flacoste> morning launchpadders
<mars> morning flacoste
<sinzui> bac: call me when you are ready for our meeting.
<bac> sinzui: ok
<salgado> beuno-lunch, any chance you could help me figure out why the text is not centered (bug 506581) in the OOPS page?
<mup> Bug #506581: oops template page is out of center <ui> <Launchpad Foundations:New for salgado> <https://launchpad.net/bugs/506581>
<beuno> salgado,
<beuno> sure
<beuno> salgado, it seems to be related to the CSS combining
<beuno> trying to pinpoint the style to blame
<salgado> beuno, I was confused because everything there seems to have a "text-align: center" (according to firebug, at least)
<beuno> salgado, yeah, it claims that body hast text-align: center
<beuno> salgado, it's coming from /* lazr/build/yui/cssgrids/grids.css */
<beuno> body{text-align:center;margin-left:auto;margin-right:auto}
<beuno> so, it's a matter of order
<beuno> I'm also pretty sure that the oops page didn't load that CSS before at all
<salgado> that's correct
<beuno> salgado, so we can either override it in that template specificall (a hack) or port it to one of the new master templates
<beuno> one that uses the yui-* CSS clases
<salgado> I'll try porting it then
<salgado> but it doesn't use any
<salgado> it's a standalone template
<beuno> salgado, you could add the CSS clases manually then
<salgado> beuno, what classes are needed?
<salgado> yui-u and yui-g?
<beuno> salgado, I don't remember them by heart, but use on the main div the same class used on the one-column layout template
<beuno> sinzui, do you remember them?
<sinzui> yui-u and yui-g as stated, and there are yui-t4 and yui-d0 setup in base-layout
<salgado> sinzui, beuno, but do I need yui-u and yui-g on a page which has only one section with a few paragraphs of text?
<beuno> salgado, I think not
<sinzui> salgado: certainly not
<sinzui> salgado: those are only needed to create columns
<intellectronica> beuno, allenap: sent my notes and mockups on the ui changes we want to do for making bug syncing more reliable. your comments etc
<allenap> intellectronica: Cool!
<beuno> intellectronica, wooo, will look
<salgado> sinzui, any idea what classes I need to use on the oops template to make it looks nice again? (https://bugs.edge.launchpad.net/launchpad-foundations/+bug/506581)  that page now includes cssgrids.css (from yui), so it looks awful
<mup> Bug #506581: oops template page is out of center <ui> <Launchpad Foundations:New for salgado> <https://launchpad.net/bugs/506581>
<sinzui> salgado: know, but I suspect that yui-reset is the culprit. I'll make an opps and see the markup
<salgado> sinzui, https://translations.edge.launchpad.net/ubuntu/hardy/+source/gnome-control-center/+imports?field.filter_status=all&field.filter_extension=potaaaa
<salgado> (an oops)
<sinzui> salgado: interesting becase https://edge.launchpad.net/~buy-viagra-online-q looks fine and the markup is similar. I think this may be an easy fix
 * salgado sees yui-main and yui-b divs there
<sinzui> salgado: we might be able to add a rule to the locationless but i see that this is not using base-layout. I think you can hardcode a text-align: left in the oops template or add structure that is left-aligned
<salgado> sinzui, I placed a <div class="yui-d0"> around the main content there, which seems to have fixed the text alignment
<sinzui> okay
<salgado> sinzui, beuno, thanks a lot for the help!
<rockstar> morning
<rockstar> Has anyone looked at the build failures?
<sinzui> rockstar: I suspected that the failures were in the layer, not the specific tests
<sinzui> rockstar: I think those tests are wrongly reported to have left the layer dirty
<rockstar> sinzui, it looks like two of them might be, but the code import stuff is probably a valid failure.  I won't see thumper for another two hours or so though.
<rockstar> sinzui, yes, I think so.
<rockstar> (thumper was working on the code import stuff yesterday)
<beuno> mars, flacoste, EdwinGrubbs, what do you guys think about makign sprites horizontal instead of vertical?
<mars> beuno, is there a reason why they are traditionally vertical?
<EdwinGrubbs> beuno: do you mean combining them horizontally in the giant consolidated image?
<beuno> EdwinGrubbs, yes, so they don't show up with multiple lines
<EdwinGrubbs> beuno: does that mean that you will need to space them out 1920 pixels for users who maximize their windows?
<beuno> mars, the only reason I made the vertical is because images get loaded from top to bottom
<beuno> EdwinGrubbs, well, I can't think of any scenario where we would push it horizontally like we do vertically, so I don't think we'd need a crazy amount of spacing at all
<deryck> beuno, ping
<beuno> deryck, hi
<mars> beuno, IIRC GIFs compress best vertically, thus GIF sprites should be vertical.  However, I can not find anything that says PNGs have the same limitation.
<beuno> mars, so that would be a good measure, make sure it's not significantly bigger
<beuno> in size
<kfogel> intellectronica: still online?  question about mapping back from an attachment -> bug -> bugtask (which I'm not sure is possible, so I may have to rearrange data flow here)
<kfogel> deryck: if you have a sec, I'd hit you with the same question I just asked intellectronica above
<deryck> you want to get to the bugtask from the attachment?
<deryck> kfogel, ^^
<kfogel> deryck: right, and I'm not sure that's possible (since you can't convert a many-to-one mapping back to one of the many, if you know what I mean).
<kfogel> Am I unduly pessimistic?
<kfogel> deryck: the core code in model/bugtarget.py is:
<kfogel>     @property
<kfogel>     def patches(self):
<kfogel>         """See `IHasBugs`."""
<kfogel>         lst = []
<kfogel>         for bugtask in self.all_bugtasks:
<kfogel>             for attachment in bugtask.bug.attachments:
<kfogel>                 if attachment.type == BugAttachmentType.PATCH:
<kfogel>                     lst.append(attachment)
<kfogel>         return lst
<kfogel> So I'm using the bugtasks to get to the attachments, but the information about which bugtask it was is thrown away.
<kfogel> (I mean, there are solutions; I just want to know if I'm analyzing correctly.)
<deryck> kfogel, what is patches a method of?  what is "self" in other words?
<kfogel> deryck: HasBugsBase
<kfogel> deryck: and http://paste.ubuntu.com/356183/ has in-progress bugtarget-patches.pt I'm working on, when I realized the problem (i.e., that I couldn't necessarily get "status" or "importance" from a bug, I had to get it from a bugtask)
<deryck> kfogel, ah, ok, I see what you are wanting to do.  Yeah, there is no way to get back from patch to bugtask.
<deryck> kfogel, I think it would be better to use searchTasks and get tasks with patches, and operate on those tasks.
<kfogel> deryck: cool, I'll go in that direction.  I'm actually kind of pleased, at least, to discover that what I thought was the problem *is* in fact the problem.  That's not always the case!
<kfogel> deryck: (note that searchTasks doesn't seem to offer that, but that's okay, the code I pasted in-channel above can easily get a list of tasks with patch attachments; in fact, it already does, all I have to do is not throw the information away.)
<kfogel> oh, nm, there's a has_patch=foo on searchTasks
<deryck> kfogel, you can't use searchTasks with has_patch?
<kfogel> deryck: see my "oh, nm" above
<deryck> ah, sorry :-)
 * deryck only looks at the red in xchat
<kfogel> deryck: how much longer you on for?  (So I can time likely-to-produce-questions activities vs other stuff.)
<deryck> my EOD is top of the hour coming up.  But I can hang around some after that.
<deryck> kfogel, ^^
<kfogel> deryck: *nod* thx
<deryck> kfogel, np
<kfogel> deryck: so where I can find a reference of all the tal: macros available?  I've just been cutting and pasting from other .pt files, making educated guesses, so far.
<deryck> kfogel, I just cut-n-paste and guess myself ;)
<kfogel> deryck: thought that might be the universal answer, np :-)
<deryck> kfogel, I don't think we have a reference, and all the zope refs on tal on I find are pretty basic
<kfogel> ok
<kfogel> deryck: easy one for you: in this excerpt from the .pt file (http://paste.ubuntu.com/356188/) what's the Official Right Way to convert the bug ID to a link?  I'm betting that just handcoding an "<a href=..." is not how the cool kids do it.
<kfogel> (I know it will need to be tweaked later, when we use a task instead of a patch, but that's okay)
<deryck> kfogel, grep for fmt:link
<kfogel> deryck: thx
<beuno> intellectronica, still around?
<beuno> deryck, maybe you can help. In Tom's mockup of a remote bug, would that be a bug that was imported from another bugtracker, and is read-only in LP?
<beuno> where can I see one today?
<deryck> beuno, haven't looked closely at what Tom sent... let me look.
<intellectronica> beuno: just got back. the mockup is of a new page for a bugwatch. that is, launchpad's representation of a remote bug
<beuno> intellectronica, cool, deryck filled me in, thanks. I'm replying to your email. Great work  :)
<intellectronica> beuno: it doesn't carry any interesting data regarding the bug itself, but we'd like to have it so that users can help more with monitoring checkwatches
<intellectronica> cool
<beuno> intellectronica, and any change to the bug page itself?
<beuno> just the icon, right?
<intellectronica> beuno: just to the representation of a bugwatch (basically, the icon). haven't mocked that up, though
<intellectronica> beuno: what do you think about making it link to the new bugwatch page, instead of to the remote bug directly. i'm unsure about it myself. ot1h it will be annoying to some users, otoh i really want to make people pay attention to bug syncing. i'm really looking for a better idea, actually
<beuno> intellectronica, I thought about it
<beuno> I think it's not the best  thing to do
<beuno> it will dectract from the usefuleness of it, no?
<beuno> I am thinking, however, on how to best link to the new page
<beuno> intellectronica, what if
<beuno> *if* it failed
<beuno> we should a link to the bugwatch page next to it?  "() gnome-bugs #32241 (edit bugwatch)"
<mup> Bug #32241: Distro release source package release page is empty <Soyuz:Fix Released> <https://launchpad.net/bugs/32241>
<intellectronica> yes, that's another option. but being inconsistent about where you link to is also quite annoying
<intellectronica> oh right, that's a nice option i didn't think about
<beuno> intellectronica, edit icon?
<intellectronica> it will be a bit hard to cram it into the bugtasks table, but maybe a pencill icon?
<beuno> :)
<intellectronica> synchronicity
<beuno> it would be a slightly different page than you may expect, but it could be a good compromise
<beuno> not super sure that would be enough to entice people into fixing it
<intellectronica> then the only problem that's left is, how do you get to the bugwatch page if it's not broken?
<beuno> we could leave the edit icon there always
<intellectronica> well, there's not much that people can do to fix it other than letting us know
<beuno> true
<beuno> but
<beuno> there's the tip of a thread there
<intellectronica> the problem is, in the context of the bugtask row, edit means 'edit this cell'
<beuno> how about being controversial
<beuno> and linking to filing a question?  :)
<intellectronica> yeah, that's definitely something we can do. next to the broken sync line
<beuno> intellectronica, I think it's shaping up nicely
<beuno> I'll reply to the email with other nitpicks as well
<intellectronica> beuno: cool. i still want to add a graph like the ones deryck just added too
<beuno> intellectronica, I always get excited about tracking progress
<intellectronica> beuno: oh yeah? what does it say about you? ;)
 * intellectronica hides
<beuno> intellectronica, that I'm a good fit for a company like Canonical!  :p
<jml> thumper, buildbot compile failed
<thumper> jml: I don't grok that
<jml> thumper, buildbot was building five minutes ago. it's not any more, because the compile step failed.
<thumper> jml: on db-devel?
<jml> thumper, yeah, db_lp
<thumper> jml: make fails due to soyuz code move
<thumper> I am fixing
<jml> thumper, ahh, ok.
<jml> thumper, man, those sounds must get annoying
<jml> thumper, really
<jml> thumper, really
<jml> thumper, really
<jml> thumper, annoying
<wgrant> bigjools: Does it really?
<jtv> al-maisan:
<jtv> https://code.edge.launchpad.net/~jtv/launchpad/bug-500110/+merge/17272https://code.edge.launchpad.net/~jtv/launchpad/bug-500110/+merge/17272
<jml> jelmer, SourcePackageRecipeBuildJob
<jml> thumper, tell me where the branch is, and I'll review it.
<thumper> jml: it's a coming
 * mwhudson wants to know too, so i can test my branch again...
<wgrant> jtv: https://code.edge.launchpad.net/~wgrant/launchpad/lp-buildd-generalisation
<cody-somerville> wgrant, Whats that? :)
<cody-somerville> wgrant, it looks interesting
<mwhudson> ec2 land can feel like throwing a dart at a dartboard and hoping the dartboard is still there in four hours
<jml> mwhudson, hahaha
<bac> mwhudson: i like your analogy but i think it is more ephemeral, like playing whack-a-mole and hoping the mole pops up in four hours just before you swing.
<mwhudson> bac: :)
#launchpad-dev 2010-01-14
<adiroiban> Hi! If a template is used in more views, should I define an interface for the template?
<jml> adiroiban, an interface for the template?
<jml> adiroiban, I'm not sure what that means.
<adiroiban> all views using that template, to implement a common interface
<adiroiban> right now we have potemplate-index.pt, potemplate-chart.pt, distroseries-langchart.pt and serieslanguage-index.pt
<adiroiban> they are for different object, but the statistic tables is similar
<adiroiban> I was thinking those templates chould be changed to include a macro for that table
<jml> sorry, I zoned out...
<jml> umm...
<jml> thumper, ^^^
<thumper> if the view is the same on all the pages, then yes, register against an interface
<thumper> if it is similar but not the same, then use macros
<adiroiban> they are similar and I start using macros, but I was wandering if we should have an interface for that macro
<adiroiban> you can always read the macro code and see how it is accessing the view
<adiroiban> but I was just wondering if there is a convention for describing a macro.
<adiroiban> thanks!
<thumper> I have my own conventions for macros
<thumper> but I don't think there are documented and agreed upon conventions for LP devs
<jml> thumper, fight!
<bigjools> wgrant: Thou spleeny shard-borne bugbear!
<mwhudson> jml: http://uncyclopedia.wikia.com/wiki/Daily_Mail
<mwhudson> landing branches throught pqm takes fricking ages
<magcius> Question time: if I work on Code Hosting for Git branches over the next two weeks, will it ever get landed?
<magcius> Because I only want to try and attempt if it will be worthwhile.
<magcius> So basically: will Canonical consider other VCSs for Launchpad, because I have an amazing idea that I really want to see integrated, and I'd be glad to work on it, only if it would go somewhere.
<magcius> Basically: tool-agnostic code hosting. Check out any branch in either Git or Bazaar and work on appropriately.
<thumper> magcius: what are you actually proposing?
<magcius> thumper, what do you mean?
<thumper> magcius: you say you want to integrate git, but how are you proposing doing this?
<thumper> magcius: did you see jml's comment above?
<magcius> thumper, which one?
<magcius> <jml> magcius, we aren't opposed to having git support, but we'd want it to work in such a way so that you could use bzr or git for any project on Launchpad, regardless of what it's actually hosted in.
<magcius> That one?
<thumper> yes
<magcius> That was basically my idea.
<magcius> Basically, implement a git daemon that accepts pushes.
<thumper> how about log, diff, info et al
<magcius> thumper, what do you mean?
<thumper> I guess the real answer right now is no.
<thumper> not at this stage
<thumper> I'm not saying we wouldn't consider it later
<thumper> but right now we have too much else on
<magcius> thumper, okay.
<magcius> thumper, the real work would be in converting the object database from bzr to git, right?
<thumper> what object database?
<thumper> we use postgresql
<magcius> err
<magcius> I'm thinking too much in terms of git.
<magcius> I thought Keybuk told me that git and bzr were a lot closer in their storage model, but I guess that's not true.
<james_w> semantically close, but the details of what is stored differs, e.g. bzr doesn't store full file modes, and git stores less commit metadata
<james_w> so a lossless mapping is difficult, if not impossible.
<magcius> james_w, hm, okay.
<rockstar> magcius, out of curiosity, what is your favorite thing about Launchpad that you'd be so committed to getting Git support in.
<magcius> rockstar, the fact that it could be a central place to do everything.
<magcius> rockstar, as an advantage, Launchpad has the best bug reporting I've seen
<rockstar> magcius, yes, but there are many competing code hosting solutions out there that you could use.
<rockstar> magcius, awesome.  That's helpful to know.
<magcius> rockstar, to be brutally honest, I'd be content with some way for the Branches thing to link to my GitHub repo.
<rockstar> magcius, you can say that code is not stored on Launchpad.
<magcius> rockstar, my users were getting confused. Because I had forked a project already on Launchpad, they were like "huh? Where's the source?"
<magcius> rockstar, I could provide an alternate bzr branch, but that's quite useless when it gets lost among the multitude of branches already there.
<rockstar> magcius, I think that's a realistic option in the short term.  Launchpad already has the concept of "remote branches."  Maybe that can be extended to point to git branches as well as bzr branches.
<rockstar> magcius, but you lose a lot of the niceties that Launchpad provides.
<magcius> rockstar, I would also like it if I could fork a project so that I could fix bugs in my project's branch, and still get new bug reports from the old project.
<rockstar> You're using the term "fork" in the git sense of the word, correct?
<magcius> rockstar, because one bug request of "fixed in this branch" that won't ever get integrated into the official one because it's a design decision is disappointing.
<magcius> rockstar, basically, I forked notify-osd because I wanted to fix some things that were marked as wontfix.
<rockstar> magcius, well, to be truthful, as a user, if I wanted the same changes, I probably still wouldn't use your changes because I don't want to have to deal with two different VCSes.
<magcius> rockstar, I initially added a branch and marked the bugs as "fixed in my branch", but Marco reverted that status to "wontfix"
<magcius> rockstar, I initially hosted them with bzr, but when I started using git for my own projects I hosted it there too.
<thumper> magcius: why not have a vcs-import of your git branch?
<thumper> magcius: that'll stay in sync
<magcius> thumper, because I'd like native support for Git. I have free time and I need a project to work on.
<thumper> magcius: native git support will not happen in the short term for launchpad
<thumper> full stop
<rockstar> magcius, I have some projects here you cane have.  :)
<magcius> thumper, two questions: what time frame does "short term" mean, and why?
<rockstar> magcius, probably at least the next year == short term
<magcius> Alright.
<rockstar> magcius, the why is because I could stop working on features now, and have at least a year's worth of work in bugs.  :)
<magcius> When is the release date for "4.0"
<magcius> rockstar, alright.
<magcius> rockstar, I guess I should start smaller. I'd gladly fix the bugs.
<magcius> james_w, I was trying to find some good documentation on the formats and the object model, but I couldn't find any.
<thumper> magcius: awesome
<thumper> bugs.launchpad.net/launchpad-project
<rockstar> magcius, I'm sure bzr-git could use your help.
<magcius> rockstar, alright.
<rockstar> magcius, ignore thumper, he's a super crazy.
<magcius> rockstar, are you a Launchpad dev or a bzr dev?
 * thumper sups his coffee
<rockstar> magcius, Launchpad dev, but I (as well as thumper) work on integrating bzr into Launchpad.
<magcius> eek
<magcius> rockstar, is Loggerhead a Canonical project?
<bigjools> thumper the oompahloompah
<thumper> oompahloompah?
<thumper> I'm not that short
<jml> magcius, kind of.
<thumper> loggerhead is open source
<jml> magcius, it wasn't started by Canonical
<rockstar> magcius, loggerhead didn't start at Canonical, but we loves it.
<jml> magcius, and we use in for Launchpad, so we patch it a lot.
<magcius> Well.. bzr didn't start at Canonical either :P
<thumper> well, yeah it did
<jml> magcius, well, what do you mean by "Canonical project"?
<magcius> jml, is it funded by Canonical? Worked on by Canonical employees?
<rockstar> magcius, I think you could provide some real help on bzr-git: https://bugs.edge.launchpad.net/bzr-git
<jml> magcius, as I said, we patch it a lot.
<rockstar> magcius, no, but some of those who work on it are Canonical employees as well.
<magcius> rockstar, alright.
<magcius> rockstar, make Loggerhead easier to use. Every time I try to use it it's a cludge.
<rockstar> magcius, yes, we're working on it.
<magcius> rockstar, make it have the Launchpad masthead with a branch breadcrumb
<magcius> I guess I need a good overview on how bzr works internally, which I can't find online. All the documentation I can find is about bzrlib, which I don't care about.
<rockstar> magcius, yeah, like I said, year's worth of bugs if we stopped getting features. :)
<thumper> magcius: rockstar is somewhat busy on other tasks right now
<magcius> Sorry if that sounded like a demand.
<rockstar> magcius, bzrlib is how bzr works internally
<magcius> rockstar, well, what's the object format?
<thumper> magcius: the best way to get bzr internals is to ask on #bzr
<rockstar> magcius, if appeal to thumper's emotions, maybe he'll make me work on Loggerhead.
<magcius> thumper, okay. Is there a bzr-dev
<rockstar> I doubt it though.  The Grinch's heart is bigger.
<magcius> err
<rockstar> :)
<magcius> #bzr-dev
<thumper> magcius: no, they are all on #bzr
<magcius> okay
<jelmer> thumper: I've updated the Branch destructor web API call branch again
<thumper> jelmer: ok
<jelmer> thumper: but something else seems to be wrong with the diff now
<jelmer> I was just looking - there's a lot of other changes, but I've only merged lp:launchpad
<thumper> hmm...
<stub> jelmer: lp:launchpad is lp:~launchpad-pqm/launchpad/db-devel
<jelmer> stub: Ah, that explains it - thanks
<jml> gah, my use-testtools branch _just_ missed the buildbot boat
<jml> now I won't get it on stable for 8.5 hrs.
<lifeless> jml: grats
<lifeless> [on getting it in at all]
<jml> lifeless, thanks, although I don't count a branch as landed until it hits stable.
<lifeless> jml: tribunal needs an update for testtools - it doesn't upcall in setUp :P
<jml> oops.
 * jml adds a todo
<stub> jml: Perhaps we should have multiple builds running instead of just one.
<stub> jml: We could have 4 slaves that kick off a build of trunk once per hour if there are revisions landed that are not already being tested by another buildbot.
<jml> stub, that's a good idea
<stub> I think if you wanted to guarantee 15 mins max before a buildbot starts testing your patch and had a 4 hour test suite we would need 16 potential slaves configured
 * jml notes that PQM takes 15 mins to do its thing
<jml> back from nzpug?
* jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<wgrant> jml: We've been back for a while (it finished more than 1.5 hours ago)
<wgrant> jml: But most were out for a while after that.
<mwhudson> evening
<jelmer> 'lo
<jml> wgrant, I see.
<bigjools> ha straight on the laptops I see
<james_w> what else?
<jml> engaging conversation, a stroll on the waterfront, a round of whist by the fire...
<bigjools> or something by the fire
<mwhudson> jml: i can tell you haven't been outside for a while
<mwhudson> it's raining now
<jml> mwhudson, heh heh
<jml> http://paste.ubuntu.com/356445/ -- what's going on here?
<mwhudson> i guess you have to edit the prepare script?
<mwhudson> jml: btw, if you want to look at https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-model-code/+merge/16272 and suggest stuff about filenames and so on, feel free
<jml> mwhudson, edit it how?
<jml> mwhudson, I'll take a look
<mwhudson> ta
<jml> mwhudson, I think that all of it could be just as easily in lp/code/ as lp/soyuz.
<mwhudson> yes i guess
<jml> mwhudson, I'm not sure which is better.
<wgrant> Also, there's that one thing which is in a file that is named strangely.
<wgrant> recipebuilder.py
<mwhudson> jml: it's a fascist conspiracy that file paths are linear
<jml> mwhudson, indeed.
<mwhudson> wgrant: that's not in my branch, at least :-)
<wgrant> mwhudson: Ah, OK.
<jml> leonardr, http://paste.ubuntu.com/356445/ is what happens when I try to run 'prepare' in lazr.yourpkg
<james_w> jml: do you have any lazr packages elsewhere in sys.path?
<jml> james_w, quite probably.
<jml> jamesh, sorry.
<jml> gror
 * jml confused
<jamesh> hmm?
<leonardr> jml: i think you're supposed to branch it as 'lazr.yourpkg' and then run 'prepare' to change it everywhere
<jml> jamesh, sorry, I got your nick confused w/ james_w as sort of a double-misunderstanding
<jml> leonardr, that also doesn't work
<jml> leonardr, http://paste.ubuntu.com/356450/
<leonardr> jml: ok, i'll try it
<jml> leonardr, thanks.
<leonardr> jml: ok, you don't have to branch it as lazr.yourpkg
<leonardr> but you do have to run bootstrap.py and then bin/buildout
<leonardr> then you can run bin/py prepare.py lazr.importguardian
<jml> leonardr, thanks.
<jml> leonardr, were there docs in the package that I was missing?
<leonardr> jml: not really, you're just supposed to know how to run lazr.* scripts from https://dev.launchpad.net/HackingLazrLibraries
<jml> leonardr, ahh ok.
<leonardr> jml: but yourpkg is kind of a special case, it's not obvious that you have to run buildout on a package you're not going to use
<leonardr> if you wanted to add some more specific docs to README i'd r= that
<jml> leonardr, thanks.
<mrevell> Morning
<jml> mrevell, hi
<mrevell> hey there jml
<jml> leonardr, even after bootstrap & ./bin/buildout, I still get the same error
<leonardr> jml: just to check, are you using bin/py?
<jml> leonardr, yes.
<leonardr> hmm
<leonardr> i got it to work
<jml> leonardr, this is in the lazr.importguardian branch. trying in lazr.yourpkg now.
<jml> I wonder if there's a correlation between liking buildout and being close to the US east coast (where the internet lives)
<jml> nope. :(
<leonardr> ok, let's try it again
<leonardr> jml: yes, i'm getting an error now in buildout. you too?
<leonardr> i think there is a catch-22 here
<wgrant> james_w/abentley: Hm, I see that the slave returns a file named 'changes'.
<wgrant> why isn't it the full name?
<jml> leonardr, http://paste.ubuntu.com/356466/
<jml> leonardr, that's what the first buildout run gives me
<wgrant> I could hack around that, but it would be preferable to have the full name returned.
<leonardr> jml: do you have a global cache? you might like buildout better if you set one up
<leonardr> that's also in HackingLazrLibraries
<james_w> wgrant: oh, I noticed that, but I thought it was intended
<james_w> we can probably fix it
<wgrant> james_w: I can't see where it is actually done on the slave side.
<abentley> wgrant: That's what's done for a binary build.
<jml> leonardr, ahh, that's a useful tip. thanks.
<leonardr> jml: and are you sure those errors are fatal? is there a bin/py in your directory?
<jml> leonardr, they aren't fatal. there is a bin/py
<wgrant> abentley: Oh, yuck. I guess I'll check how process-upload handles that, then. Best not to change the slave.
<jml> running again...
<james_w> psycopg2.OperationalError: FATAL:  Ident authentication failed for user "launchpad" <- any clues?
<wgrant> james_w: You've run launchpad-database-setup?
<james_w> this is the first time I'm running LP outside a chroot
<james_w> yep
<jml> leonardr, http://pastebin.ubuntu.com/356471/ is what I end up with in ./bin/py
<jml> leonardr, I also have lazr packages installed on my system from Ubuntu.
<jml> leonardr, should I be using virtualenv?
<leonardr> jml: i'm not sure. i eventually had to compile a whole separate version of python. if you run into problems or are already good at virtualenv, i'd recommend it
<wgrant> abentley: That's only done for a binary build as of your r10153.
<wgrant> abentley: Previously it used the real name.
<wgrant> Now I suspect it is broken.
<abentley> wgrant: Okay, I'll have a look at it tomorrow.
<wgrant> abentley: Thanks.
<jml> leonardr, I'm not :(
<jml> leonardr, the HackingLazrLibraries page says there are issues that are being looked into -- is there a relevant bug number?
<james_w> 275	+        self._slave.waitingfiles['changes'] should be self._slave.waitingfiles['
<jml> "At this time, a non-system Python, or a virtualenv executable that does not include site-packages, is highly recommended, and may be required. We are working to remove this limitation."
<james_w> self._slave.waitingfiles[os.path.basename(path)] I mean
<leonardr> jml: i don't know about this part, sorry
<jml> leonardr, ok, thanks.
<wgrant> james_w: Yeah, that's what I've just hacked in.
<wgrant> james_w: If one of you can commit that to your branch, 'twould be good.
<leonardr> jml: you might ask gary or (for some reason i associate him with this) bac
<jml> leonardr, is there a lazr mailing list?
<leonardr> jml: yeeees?
<leonardr> https://edge.launchpad.net/~lazr-users
<jml> leonardr, thanks.
 * jml is off
<jml> g'night all.
<wgrant> Oooh.
<wgrant> Collection works.
<james_w> yay
<wgrant> I have a lot of local changes to bash SourcePackageRecipeBuild into its interface, but it works.
<mwhudson> wgrant: woo
<wgrant> mwhudson: Took a bit of work, but I successfully (and automatically) went from the SourcePackageRecipeBuild that you told me how to create to a binary package, with not too many gross hacks.
 * wgrant decides to sleep.
<mwhudson> wgrant: very cool
 * mwhudson should sleep too
<mwhudson> (and mthaddon has built buildbot two of the ec2 images already, hurrah!)
<wgrant> So we can land stuff tomorrow?
<deryck> Morning, all.
<kfogel> adeuring: what does the "structure" keyword in, e.g., <a tal:replace="structure patch/bug/fmt:link" /> mean?  It solved a huge problem for me (my output links are correct now, instead of looking like quoted HTML), but I'm not sure what magic did this...
<adeuring> kfogel: it prevents escaping of '<' and '>'
<adeuring> ...in the text that is inserted
<kfogel> adeuring: aaaah, "structure" as in "interpret this as the 'structure' of an HTML page instead of as content" ?
<adeuring> kfogel: yes
<kfogel> adeuring: interesting.  Very useful; not the keyword I would have chosen, but then I guess it's hard to think of words that will be intuitive under all circumstances.  Anyway, thank you.  Big light bulb for me :-).
<adeuring> kfogel: welcome :) The general idea is: Use "structure" only for trusted data; any user provided text must not be rendered this way.
<kfogel> adeuring: *nod*  thanks.  In this case, it's expanding our own bug link, so it's safe (though users can set the titles of bugs... I presume we already filter that in the bug tracker itself?)
<adeuring> kfogel: well, the title is considered as text, so it should not be rendered with the "strurcture" keyword. That's even necessary, otherwise writing a title like "1<2 returns False" would be a bit cumbersome
<kfogel> adeuring: one sec, let me show you diff and screenshot
<adeuring> kfogel: and sure, using "structure" to render a link is absolutely fine -- that's the indended usage
<adeuring> kfogel: escaping the title is in this case the job of the fmt.link renderer
<adeuring> s/fmt.link/fmt:link/
<kfogel> adeuring: http://paste.ubuntu.com/356555/
<kfogel> adeuring: so that's a correct use of structure?
<adeuring> kfogel: yes
<kfogel> adeuring: thanks
<adeuring> kfogel: welcome :)
<mars> morning flacoste!
<flacoste> morning mars!
<kfogel> adeuring, deryck, intellectronica: what free software tools do you like for making mockups?  I can just use inkscape or gimp or whatever; I'm just doing a rough sketch for Bryce right now, and wondered if you had any tools you love.
<deryck> kfogel, with image-based mockups I use gimp.  I use balsamiq (not free) for free-from, sketch-type mockups.
<adeuring> kfogel: pencil, paper, scanner and Sane?
<kfogel> adeuring: :-) could work
<adeuring> kfogel: problem is though that only Sane is free in this setup...
<intellectronica> kfogel: inkscape is quite good for sketching. if you're willing to compromise on freedom balsamiq is very good and we have a group license for it (given by balsamiq gratis to free software projects)
<kfogel> adeuring: they're all libre.  in fact, I think I libre-ated some of my pencils from the Software Freedom Law Center a few weeks ago.  Don't tell.
<kfogel> intellectronica: I don't have a moral opposition to using non-free software, I just hate spending time acquiring skills in something that can be taken away at any time, if you know what I mean -- seems like a poor investment usually.
<adeuring> kfogel: ;) And you can take paper from your recycling bin. Would also be free in some sense...
<intellectronica> kfogel: yes, it's a fine balance. and even balsamiq is not free of problems. it's built on adobe air, which doesn't work very well on linux (shortcut keys don't function) and there's absolutely nothing you can do about it
<mars> intellectronica, "shortcut keys don't function" - really?  All of them?  They've all worked for me so far.
<intellectronica> mars: oh really? maybe something is borked about my installations (more than one, both in jaunty and karmic) but ctrl-c, ctrl-v, ctrl-x don't work, which is a pain in the ----
<mars> kfogel, you can export balsamiq mockups as .png for sharing, and their interface makes it very easy and streamlined to do so (easy to use UI from a UI design product company - go figure)
<mars> intellectronica, those keys work fine for me here - GNOME on Karmic
<intellectronica> hmmmm ... not that i have the time or patience to try fixing that now, but at least there's hope! :)
<mars> kfogel, if you go for Balsamiq and are running a 64bit OS, I have some simple instructions for getting AIR running.
<kfogel> mars: thanks
<matsubara> Chex, gary_poster, rockstar, daniloff, sinzui, allenap: meeting in 1 min @ #launchpad-meeting
<matsubara> henninge, can you cover for danilo?
<EdwinGrubbs> sinzui: what does the SourcePackageRelease.component column mean?
<sinzui> EdwinGrubbs: main, universe, multiverse
<sinzui> EdwinGrubbs: Main is of course the packages most often used by Ubuntu users
<EdwinGrubbs> sinzui: shouldn't you limit which bugs you count by the date they were created? If a package is obsolete it should be significantly less important.
<sinzui> EdwinGrubbs: are any obsolete packages in the listing? I was assuming that they way they are joined they are current (latest release)
<EdwinGrubbs> sinzui: I don't know enough about those tables to say. Even if they are not to-be-removed from Ubuntu, they may be less important because a new piece of software is much better.
<sinzui> EdwinGrubbs: I suppose `spph.supersededby is not NULL` would ensure the that the package is current
<sinzui> EdwinGrubbs: when a package is removed from a distroseries, the spr is removed, which is what causes the message in the sp +index that the package is not in the series
<sinzui> EdwinGrubbs: I think the status of published means it is current so a constraint like `spph.status = 2` will work
<EdwinGrubbs> sinzui: what is the most important thing that will happen after these items are linked? Build a new binary package in Ubuntu or in a PPA?
<sinzui> EdwinGrubbs: ppa are not used in buildin ubuntu.
<sinzui> EdwinGrubbs: The most important thing is to then ensure the branch, bugtracker, and translations are setup so that bugs are forwarded, translations synced, and tip is included in the daily builds
<EdwinGrubbs> sinzui: it just seems odd that nagios-plugins would be ranked higher than sun-java6 and postfix.
<sinzui> sun-java is not in main.
 * sinzui looks for popcon data
<EdwinGrubbs> sinzui: it seems that buggier apps will get prioritized over those with a lot of bug heat for a few bugs.
<sinzui> EdwinGrubbs: yes. I do not want to write queries that will kill the page (just like i did in November)
<sinzui> EdwinGrubbs: nagios-plugins are pretty popular
<sinzui> EdwinGrubbs: I am not sure heat in needed to this prioritisation to be successful.
<EdwinGrubbs> sinzui: the heat was just an idea, but I don't think it's that important. I do think that a component package with zero bugs and zero translations shouldn't win out over a non-component package with bugs or translations.
<sinzui> EdwinGrubbs: yes, I saw that. the main rule was that last thing I added.
<EdwinGrubbs> sinzui: otherwise, I think the heuristics are good. It would probably make it easier to update the query if you put it in a subquery so that you could use "ORDER BY score DESC"
<sinzui> EdwinGrubbs: instead of counting the bugs, I could sum the bug.hotness, but the default is 0 so I need to verify 1 is the effective value since there is always on subscriber
<sinzui> EdwinGrubbs: great idea, I'll try that
<sinzui> EdwinGrubbs: r=me for the API branch. I have one suggestion in my review.
<EdwinGrubbs> thanks
<sinzui> EdwinGrubbs:  the two packaging queries use spph.status IN (1, 2) which means the package is pending or published. There are no deleted or obsolete packages in the listing
<sinzui> EdwinGrubbs: Switching to sum(hotness) instead count(bugtask.id) creates an interesting change in the top 15 (I used LIMIT): http://pastebin.ubuntu.com/356690/
<mrevell> night
<mwhudson> morning
<wgrant> Morning.
<EdwinGrubbs> sinzui: that is interesting. maybe, it should be (hotness/10)+count so that desktop apps don't have such an advantage over libraries.
<sinzui> EdwinGrubbs: I'll try that. I have already changed main component to 1000 and increased the po_message core by a multiple of 5
<beuno> mwhudson, hey. When's the LH patch going to be tested?   I'm anxious to see if a 20 line patch fixes everything  :)
<mwhudson> beuno: it should automagically hit production "at some point"
<beuno> we should really stop using voodoo to deploy launchpad
<mwhudson> looks like it's rolled out at 22:30 utc
<mwhudson> so ~3 hrs
 * beuno crosses fingers
<beuno> kfogel, another alternative to show the patch-er
<beuno> is to show the one with most karma
<beuno> (most active in LP)
<kfogel> beuno: interesting idea!
<kfogel> beuno: I'm a little worried about karma becoming a positive feedback loop; but, we could at least show karma when we show a user at all.
<thumper> morning
<kfogel> intellectronica: ayt?
<al-maisan> wgrant: Could you please take a look at comment #2 in https://bugs.edge.launchpad.net/soyuz/+bug/507323
<mup> Bug #507323: Candidate job selection logic needs to observe the 'virtualized' setting <buildfarm> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/507323>
<kfogel> deryck: got time for a quick call about code design?
<kfogel> (not vital, just would help; I can stumble through the underbrush on my own too)
<kfogel> beuno: have you seen the "mockups" in bug #506018?
<mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/506018>
<beuno> kfogel, I have. I've been spying on the thread
<beuno> the "..." may not be the most obvious and clickable thing  :)
<kfogel> beuno: yeah.  Maybe the words "(most recent)" next to the patch age?  (and the words would not be a link)
<kfogel> sometimes one can try to do too much with icons!
<beuno> kfogel, I think I'd just not link it
<beuno> and
<beuno> I've also been thinking about this number
<kfogel> beuno: the patch age?
<beuno> instead of days/weeks/months
<beuno> yes
<kfogel> we need to indicate units
<kfogel> right now I'm assuming it's days
<kfogel> user may not know that though
<beuno> right, I'd add that explicetely
<kfogel> agreed
<beuno> maybe for multiple patches
<beuno> you could do:  61 days (2)
<kfogel> should the patch age itself be a link to anything?  I'm beginning to think not.  It should just provide the hover-over popup.
<kfogel> beuno: that'd be confusing, though -- is it saying there are 2 patches that have been there for 61 days?
<beuno> I think that unless you take them directly to the patch or something, no link
<kfogel> that's not the case
<beuno> it would sort of imply that
<kfogel> well, going directly to the patch, hmmmm... that's an idea.  We provide a snippet of it in the popup, then they can click directly to it to investigate more.
<beuno> not sure it's terrible
<kfogel> how about "61 days (youngest)" ?
<beuno> well, how important is it to know that the other ones are older?
<kfogel> It's somewhat useful to know there are other patches there, but it may not be worth the UI clutter.
<kfogel> Bryce seems to think not hugely important.
<kfogel> We can just leave it out for now.
<kfogel> We're going to talk to an upstream dev too (jorge is finding) so we can ask him.
<kfogel> But for now I'll code assuming we just show the youngest and that's that.
<beuno> I think it's good to know there are more patches, but not super necessary to know that the "other ones" are older
<beuno> adding the number between brackets is not super correct, but helpful enough  :)
<kfogel> beuno: true, though that will always be the case
<beuno> and don't show it if there's just one  :)
<kfogel> umrmph
<kfogel> I am afraid that number is going to be confusing.  let's see what bryce & upstream dev say
<beuno> sure
<beuno> kfogel, I'd also link the packages to their bug listings
<beuno> and, of course, importance/status with the colors
<kfogel> beuno: IOW, to the same place the bug number & summary link to?
<beuno> kfogel, no, the bug will take you to that bug, this will take you to the list of open bugs for that package, or hot bugs, your call
<kfogel> what do you mean by "important/status with the colors"
<beuno> as a way to go to that package
<beuno> kfogel, colors, https://bugs.edge.launchpad.net/bzr
<beuno> confirmed red, fixed greed, etc
<kfogel> beuno: oh, of course.  Bryce's page isn't already doing that with the colors?
 * kfogel looks
<kfogel> heh, it's not
<kfogel> But I assumed it was, no worries.
<beuno> cool
<beuno> I'll continue to spy, and try and raise things before it hits UI review
<beuno> kfogel, it rocks that you're doing this
<kfogel> beuno: I'm loving it, but WHEW it is really drinking from the firehose.  This isn't just a minor bugfix :-).  I'm learning a lot about launchpad plumbing.
<jml> :D
<jml> launchpad needs more plumbers
<beuno> kfogel, you should try something with blueprints  :)
<kfogel> beuno: or maybe I should just slam this steel door on my toes?
<beuno> kfogel, good, you got the picture
<kfogel> jml: want to discuss a code-design question with me?  Nothing better to do?
<jml> kfogel, "better" is an open question. I do have stuff that's more urgent, sadly.
<kfogel> jml: thought that might be the case, no worries.
<beuno> sinzui, is karma updated only once a day?
 * kfogel discovers http://www.owlfish.com/software/simpleTAL/tal-guide.html, weeps with joy
<thumper> beuno: if that
<beuno> ok, once-a-day graph should do then
<sinzui> beuno: karma is once a day, and revision karma only when the script completes
<beuno> sinzui, thanks
<sinzui> kfogel: yes, that is the same page I bookmarked when I started hacking on launchpad.
<jtv> al-maisan: https://bugs.edge.launchpad.net/rosetta/+bug/507678
<mup> Bug #507678: Retrieve TranslationTemplatesBuildJob results <Launchpad Translations:New> <https://launchpad.net/bugs/507678>
<al-maisan> jtv: thanking you :)
<jtv> al-maisan: no, you!
<kfogel> sinzui: in one of our .pt files, I'm still not clear on where the "context" comes from in something like this: <tr tal:repeat="patch context/patches">
<kfogel> sinzui: I mean, it's working, I just don't understand all the magic.  Can you summarize what the "context" is?
<sinzui> context is the context of the view, and if the template is used by many views, the context could be several objects that implement a common intergface
<sinzui> kfogel the View that does the work for the template is __init__ ed with the context object and the request. The context was passed to the view by the published (in th case of the main view seen in the url), or by another template using object/@@/a-view
<sinzui> kfogel: I think the context in your specific case is BugMessage because the model object has a patches attribute
<kfogel> sinzui: HasBugsBase (the patches attr is new in my branch), but thank you -- I think I get the idea.  I was unclear on how context was magically what I needed it to be :-).
<sinzui> kfogel: context and view are the common objects we work with in templates. What is very confusing is there is a CONTEXTS that is something very different. there are a few templates that use it. Try to ignore it if you can
<kfogel> sinzui: school of hard knocks: I just learned you can't use a "-" in the NAME portion of a tal:define="NAME EXPRESSION".  Now *that* was unexpected.
<sinzui> I think we have all done that. You have graduated
<kfogel> sinzui: stumbled across it early in a lucky guess; I wouldn't call myself bitter.  Yet.
<sinzui> kfogel: When you work with CSS3 or YUI, you learn you cannot use "_" or "." in a css class name, but many of our templates are doing that, so you need to fix the class to use it in JS.
<kfogel> whoa
<kfogel> sinzui: thanks for the heads-up!
<BjornT> sinzui, kfogel: you can select by class containing dots in yui. you just have to use attribute selectors (like '[class="some.name"]'
<sinzui> BjornT: right, and that is something you learn the hardway
<kfogel> BjornT: *nod*  I'll remember at least to ask you when I encounter that :-).
#launchpad-dev 2010-01-15
<kfogel> sinzui: any way to get launchpad to re-evaluate a .py file without restarting?  I'd save a lot of time as I make little edits to, say, lib/lp/bugs/model/bugtarget.py.
<kfogel> BjornT: .pt --> HTML formatting question: I've got <td class="importanceUndecided">Undecided</td> in my output, but the Undecided is still not showing up in any particular color.  Is there something more I need to do?
<kfogel> BjornT: never mind; trick is use tal:attributes="class string:importance${task/importance/name}" instead of tal:attributes="class string:importance${task/importance/title}"
<kfogel> (And why would I think BjornT is actually awake right now anyway?)
<jml> kfogel, because he's in NZ :)
<kfogel> jml: zing!
<kfogel> jml: Do I win the Company-Wide Awareness Award for this month yet?
<jml> maybe.
<mwhudson> bzr's setUp -> set_up for Server is breaking launchpad
<kfogel> jml: What do you mean, someone else already got it this month?  Why wasn't I told??
<mwhudson> 176 times so far
<jml> kfogel, :D
<jml> mwhudson, I told poolie so :)
<mwhudson> yeah, i grumbled about it a bit when it landed
<mwhudson> pretty boring change though luckily
<poolie> hello jml, mwhudson
<poolie> sorry
<mwhudson> not a big deal
<mwhudson> bug 404693
<mup> Bug #404693: PPA ssh reset trigger can hang the buildd-manager indefinitely <buildd-manager> <soyuz-build> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/404693>
<poolie> mwhudson: by way of compensation, i'll do https://bugs.edge.launchpad.net/bzr/+bug/507710 if you like it
<mup> Bug #507710: want bzrlib.initialize() to do all typical setup <api> <Bazaar:Confirmed for mbp> <https://launchpad.net/bugs/507710>
<al-maisan> about:blank
<al-maisan> jtv: https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation
<wgrant> jtv: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
<al-maisan> jtv: I am about to add the logic collecting the buildd slave results to `TranslationTemplatesBuildBehavior` .. is that OK?
<jelmer> jml: can you merge lp:~jelmer/launchpad/builder-behavior again?
<jelmer> jml: Sorry, seems I forgot to push a rev
<lifeless> what are the zope singletons/global thingies called again ?
<lifeless> ah.. remembered. Utilities
<lifeless> jml: launchpad still thinkgs you're in sydney
<lifeless> loggerhead fail http://bazaar.launchpad.net/~jelmer/launchpad/subunit-formatter/revision/10160
<mrevell> Morning
<deryck> Morning, all.
<jml> lifeless, I don't care.
<sinzui> adiroiban: ping
<adiroiban> sinzui: hi
<sinzui> adiroiban: what is blocking the landing of your branch to fix bug 496352
<mup> Bug #496352: Refactor DistroSeriesStatus to SeriesStatus <Launchpad Registry:In Progress by adiroiban> <https://launchpad.net/bugs/496352>
<adiroiban> sinzui: I asked gmb to do a test and land it
<sinzui> today?
<adiroiban> sinzui: no
<adiroiban> about 4 days ago
<sinzui> I think your branch fixes some circular imports. Do you mind if I try to land it?
<adiroiban> sinzui: nope
<sinzui> thanks
<adiroiban> but you must merge with devel before
<sinzui> okay
<adiroiban> and check if the merged changes
<adiroiban> contains DistroSeriesStatus
<adiroiban> and then do a full test again
<sinzui> I'll do that
<bac> sinzui:  i've been trying to figure out what i changed that made download file deletion by a proj admin break.  turns out it is broken in devel.  :(
<lifeless>  jml :P
<mrevell> have a good weekend all
<sinzui> bac: excellent. Do you think it can be fixed in your branch? Should it be a separate branch?
<bac> sinzui: i think a separate branch
<bac> sinzui: unless you want me to continue chasing it
<dobey> hi all
<dobey> does the Prerequisite branch field on merge proposals work well for declaring that a branch in another project needs to land there, before this branch can land? or does it only work for other branches being merged to the same place?
<salgado> dobey, the latter
<dobey> salgado: that's what i thought. ah well. :)
<dobey> salgado: if i filed a bug to request cross-project dependencies in merge proposals, how many years would it take to get implemented do you think? :)
<salgado> dobey, no idea, but maybe abentley can answer that
<abentley> dobey: You mean, proposing a branch for merging with a prerequisite branch from a different project?
<dobey> abentley: yeah. like if i add new API to a more general library project, and in my other project that uses that library, i also make a branch that uses the new API, i don't want the latter sitting around without a proposal waiting for the former to land, but i would like some way to let reviewers know that it can't be reviewed without the other branch
<dobey> without explicitly saying so in a comment, but something that can be checked via LP REST API and such
<sinzui> bac: I think the +download delete file bug is because that view is heavily cached. I can see that the deleted rules are building the cache before as it runs. the cache should be built after the process.
<bac> sinzui: yeah, i know the caching is the problem.  just haven't figured out the details yet
<sinzui> bac:I updated bug 508085 with the call chain problem I see
<mup> Bug #508085: Deleting files from +download still displays the deleted file <Launchpad Registry:Triaged> <https://launchpad.net/bugs/508085>
<bac> thanks sinzui
<abentley> dobey: I can't predict how long it will take to be implemented if you file it, but I can predict how long it will take to be implemented if you don't file it :-).
<dobey> abentley: sure, i was just being facetious, because i know you guys have a neverending queue :)
<abentley> dobey: Maybe the best way to express it in our model would be a dependency on a bug.  (There may be no merge proposal in the other project yet)
<dobey> abentley: bug dependencies is another thing i definitely want to see, yeah
<abentley> dobey: I actually a meant that the merge proposal would have a dependency on a bug.  I'd also like to see bug dependencies, but that's not something the Code team can do.
<dobey> right
<dobey> bug dependency might be weird/confusing though, given how bugs work in lp
<dobey> as they can "affect" multiple projects/distros
<cody-somerville> Bug dependencies would be so awesome.
<cody-somerville> dobey, Not sure I see how. That feature is intended to indicate a single bug affects multiple projects and/or distributions (the latter probably being the motivation for the feature). Why do you think bug dependencies would be weird/confusing?
<dobey> cody-somerville: if a bug affects multiple projects, how do i clearly know which fix my branch will depend on? ie, it probably affects both the project i depend on, and the project i'm developing, if i'm writing branches for both projects at the same time. so it would be weird to say that this branch fixes bug X, but also depends on a fix in bug X. in LP there's no clear way to distinguish what project is relevant for which the bug affects
<cody-somerville> haha, forget I said anything. I got excited there and thought we were talking about dependency between bugs.
<dobey> between bugs is probably clearer, but i could definitely see some confusion due to the multiple project/distro affects bits :)
#launchpad-dev 2010-01-17
 * mwhudson_ just caught sight of abentley's hair
<abentley> mwhudson: My hair isn't that special at the moment.
<mwhudson> abentley: i know, but it's still quite distinctive :-)
<thumper> mwhudson, jml: meeting in the foyer of the west plaza at 1pm
#launchpad-dev 2011-01-10
<thumper> how warm / cold is it in Dallas?
<thumper> should I pack warm clothing?
<jelmer> thumper: I'd recommend a winter coat
<jelmer> It's 2 or 3 degrees (Celcius) at the moment I think
<thumper> crap
<thumper> jelmer: I take it the hotel is warm enough?
<wgrant> thumper: It's going to vary.
<wgrant> thumper: It looks like 16-17 early next week.
<wgrant> But 1 tomorrow.
<wgrant> And 4 later next week.
<thumper> hmm...
<wgrant> You'll need to take roughly everything.
<jelmer> thumper: the hotel is nicely warm. At least they don't have the airco on "freeze" mode like in some places.
<thumper> wgrant: when are you heading out?
<wgrant> thumper: Sunday.
<wgrant> You?
<thumper> same
<lavid> hello! i'm trying to fix https://bugs.launchpad.net/bzr-hg/+bug/518510 (since it's blocking something else i'm working on) and i'm trying to get my launchpad instance to import a mercurial repository so i can reproduce the bug locally. i don't think that functionality works on dev instances of launchpad. does anyone have any tips on either: how to better debug this issue or how to get my dev instance of launchpad to also support runn
<_mup_> Bug #518510: assertionerror in _find_most_recent_ancestor  <Bazaar Hg Plugin:Triaged> < https://launchpad.net/bugs/518510 >
<wgrant> lavid: You shouldn't need to run a local Launchpad instance to test that.
<jml> huwshimi: hello & welcome!
<lavid> wgrant: fair enough. i guess i was hoping to get a better idea as to what's happening further up the stack trace. how'd you recommend tackling this?
<jelmer> lavid: install bzr-hg as a plugin in bzr
<jelmer> lavid: then try to clone a mercurial branch and doign incremental pulls into it
<wgrant> I am trying to provide a precise recipe, but my machine is being objectionable.
<jelmer> One of the key things to the bug appears to be that it only happens on incremental pulls that import new revisions.
<lavid> jelmer: cool. thanks. any tips for running the bzr-hg plugin via eclipse or some other visual debugger?
<jelmer> lavid: Setting BZR_PDB=1 will open a pdb interactive debugger for you when an exception occurs in bzr
<jelmer> I don't have any experience with Python in Eclipse, sorry
<poolie> hi jelmer, wgrant
<lavid> jelmer: ooh, tasty! thank you!
<jelmer> 'evening poolie
<wgrant> Morning poolie.
<wgrant> Or evening, I guess.
<jml> see you all in a bit.
 * jml is off for stuff.
<thumper> oh FSF
<thumper> FFS
<thumper> make build dying on OSError: [Errno 4] Interrupted system call
<thumper> still
<wgrant> thumper: Didn't it work on Friday? :/
<thumper> wgrant: it did
<thumper> wgrant: so it seems to be temperamental
<wgrant> thumper: Yay.
<wgrant> thumper: It wasn't a parallel make?
<thumper> I don't think so
<wgrant> thumper: Does it die on the .join()?
<thumper> wgrant: no, times out
<thumper> wgrant: actually, yes
<thumper> File "./utilities/create-lp-wadl-and-apidoc.py", line 86, in main
<thumper> sorry, didn't look enough up the stack
<thumper> wgrant: any idea how to get around the make problem?
<thumper> I can't make run
<thumper> :(
<thumper> which makes it hard for me to test this thing
<wgrant> thumper: You could hack it to not use multiprocessing. Or use multiprocessing, but serially.
<wgrant> It is tempting to debug, except for the whole POSIX signal fuckedness.
 * thumper loses the will to fix it on a Monday afternoon and calls it a day
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       63 /  293  BugTask:+index
<lifeless>       36 / 4408  Archive:+index
<lifeless>       21 /  294  Distribution:+bugs
<lifeless>       13 /  112  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       12 /  177  POFile:+translate
<lifeless>       12 /    0  ProjectGroup:+milestones
<lifeless>        8 /   12  NullBugTask:+index
<lifeless>        7 /  201  Question:+index
<lifeless>        6 /   13  Branch:+index
<lifeless>        5 /    4  Cve:+index
<wgrant> Does anyone happen to know why Storm would be doing lots of 'SELECT 1 FROM foo WHERE foo.id=bar' in a test after invalidating the store?
<wgrant> It doesn't seem to do that in production.
<adeuring> good morning
<al-maisan> Good morning !
<bigjools> benji: good morning
<benji> morning, julius maximus
<bigjools> heh, never been called that before
<bigjools> I'm still struggling to get my dev environment fixed :(
<bigjools> I downgraded launchpadlib to 1.6.5 (which is the last version I had an egg for)
<bigjools> and the librarian won't start up in tests still, I  get loads of "No handlers could be found for logger "librarian""
<benji> hmm, that doesn't sound related to launchpadlib; I can't imagine why it'd be screwing with the librarian's logger
<bigjools> me neither
<jcsackett> benji: can you do qa for bug 686690?
<_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings <desktop-integration> <qa-needstesting> <regression> <launchpadlib :Fix Committed by benji> < https://launchpad.net/bugs/686690 >
<leonardr> jcsackett: martin has confirmed the behavior, so i think we are ok
<jcsackett> leonardr: ok, so i can mark that as qa-ok then?
<leonardr> jcsackett: i'm about to upgrade launchpadlib in launchpad again. let's mark it qa-ok after i test that
<jcsackett> leonardr: sounds good. thanks.
<jcsackett> gmb: can you do qa for bug 686690?
<_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings <desktop-integration> <qa-needstesting> <regression> <launchpadlib :Fix Committed by leonardr> < https://launchpad.net/bugs/686690 >
<jcsackett> sorry, gmb, bad copy paste. i meant bug 683672
<_mup_> Bug #683672: Bug description in verbose footer should be indented by 2 spaces <lp-bugs> <qa-needstesting> <story-better-bug-notification> <trivial> <Launchpad itself:Fix Committed by gmb> < https://launchpad.net/bugs/683672 >
<gmb> jcsackett: I will be doing so shortly; just waiting for deryck to get up-and-running with the staging mailbox.
<jcsackett> gmb: cool, thanks.
<bigjools> benji: at what point is the keyring doing stuff it should not at import time?  When it loads the backend, or something else?
<bigjools> I made a keyringrc.cfg to force an alternative backend and it still goes bang
<benji> bigjools: it's certainly doing backend selection at import time, but it may well be doing other things; did your bang look related to the SIGCHLD stealing or something else?
<bigjools> benji: yeah, same EINTR stuff
<benji> let me look at the keyring code and see where it's doing that registration
<bigjools> I forced anUncryptedFileKeyring backend
<bigjools> benji: I'm just trying to hack anything in to get me unblocked :(
<benji> bigjools: hmm, I don't see anywhere that it explicitly registers a SIGCHLD handler; wait, didn't you say you downgraded to a pre-keyring launchpadlib?  if so, keyring shouldn't ever be imported
<bigjools> benji: I've gone back to the latest lplib since the other once had that logger problem
<bigjools> well, the librarian problem
<benji> ah, ok
<bigjools> the sigchld is registered somewhere in PyQt4
<benji> I figured. :(
<bigjools> according to my strace anyway
<bigjools> it's all so frustrating :/
<benji> bigjools: I think you can hack your launchpadlib to never import the keyring module (just comment out the import) and your LP will work (some tests will fail)
<bigjools> ok, never thought of the obvious :)
<bigjools> benji: ok, that reduces me back to the No handlers could be found for logger "librarian"
<bigjools> maybe if I bang my head up the wall a bit more....!
<lifeless> gary_poster: around?
<mwhudson> who is release manager this time?
<mwhudson> i ought to know this
<gary_poster> lifeless: I am
<gary_poster> mwhudson: jcsackett
<lifeless> jc I thought
<mwhudson> gary_poster: thanks
<lifeless> gary_poster: hi; thanks for fast tracking the oops prefix updates
<gary_poster> lifeless: hi, np.
<mwhudson> jcsackett: which revno is being released today?
<lifeless> gary_poster: I'm wondering when that goes live (and if it will mean that the oops reports mailed to the list change accordingly)
<mwhudson> ah, db-stable 10119
<gary_poster> lifeless, the intent is today, and yes.
<lifeless> mwhudson: huh no
<lifeless> we deploy from stable
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<lifeless> mwhudson: rev 12177
<lifeless> mwhudson: and we're blocked on rev 12167
<lifeless> jcsackett: ^
<mwhudson> ah cool
<mwhudson> well, not the being blocked part
<mwhudson> but that means the fix i care about (and just qa-ed) is going to be released
<jcsackett> mwhudson: we're deploying on the 12th, not the 10th. did i say the 10th in an email?
<mwhudson> errr
<mwhudson> no,
 * jcsackett has written a lot of emails lately, very well could have goofed.
<mwhudson> can i blame jetlag?
<mwhudson> :-)
<jcsackett> mwhudson: yes you can. :-)
<lifeless> jcsackett: we ar edeploying from stable, right ?
<lifeless> gary_poster: sweet, thanks.
<gary_poster> np
<jcsackett> lifeless: correct.
<lifeless> jcsackett: great, my heart can start beating again
<jcsackett> we need to deploy at least through r12177 on stable.
<jcsackett> 10119 was the db revision we qa-ed and merged on friday, lifeless.
<lifeless> jcsackett: thanks
<jcsackett> np.
<bigjools> gary_poster: can you spare me a moment please?  I've worked around the keyring problem for now, but still have a problem with the librarian in tests :(   http://pastebin.ubuntu.com/552492/
<gary_poster> benji, leonardr, can either of you help bigjools ?
<benji> gary_poster: I can take a look; not done much with the librarian yet though
<lifeless> bigjools: thats weird
<gary_poster> benji: ack.  Lemme check in with the other pending pings and I'll see what needs to be handled
<bigjools> benji: I would have asked you but you were busy fixing the keyring :)
<lifeless> bigjools: when did this start?
<bigjools> lifeless: once I worked around the keyring problems just now
<lifeless> also I hate python logging, I truely do
<bigjools> I've not had a working dev environment since Thursday last week
<lifeless> 2011-01-10 20:30:34+0530 [-] No handlers could be found for logger "librarian"
<benji> bigjools: it's nice to be loved
<bigjools> lifeless: I share your hate
<lifeless> -not- a sane failur emode
<lifeless> bigjools: do you have a /var/tmp/fatsam.test/librarian.pid ?
<bigjools> lifeless: ignore that, it's a relic of the earlier failure
<lifeless> ok
<bigjools> I delete fatsam each run
<lifeless> ok
<lifeless> so its leaving the pid file when it fails to start? Could you file a bug on that - we should fix that too
 * bigjools tries again
<bigjools> didn't we discuss that some time ago and it was hard to fix for some reason?
<bigjools> ARGHHHHH
<bigjools> it's working now
<lifeless> dunno; the code is a lot cleaner than it was it should be fixable.
<bigjools> there was a librarian left running
<lifeless> deleting old ones on start is problematic; dealing with a failed start is simpler
<bigjools> thought I'd killed it
<lifeless> however it sounds like it was behaving correctly ;)
<bigjools> define correctly :)
<lifeless> not connecting you to an existing librarian on the statically defined port
<lifeless> however the diagnostics are terrible - please do file a bug that it didn't manage to tell you
<bigjools> roger
<gary_poster> bigjools, benji, sorry, I misunderstood thought the librarian thing was a webservice/keyring thing
<gary_poster> but so anyway, that's "resolved" enough for benji to get back to what he was doing before, bigjools
<gary_poster> ?
<lifeless> it might have been :)
<bigjools> gary_poster: in all fairness, it might have been!  I had no idea what was up.
<gary_poster> heh
<bigjools> gary_poster: yes, thanks, I've commented out the keyring import for now
<bigjools> lifeless: to confirm, what did you expect it to do that it was not doing?  Telling you about an existing librarian, or something else?
<gary_poster> bigjools: ack, and that solved it, or...something solved and you are moving on?
<bigjools> gary_poster: "worked around" would be the right phrase :)  benji is fixing the keyring code to not do stuff when it's imported
<lifeless> hi flacoste
<gary_poster> bigjools: lol, ack, right.  thanks
<bigjools> gary_poster: I'm gonna have to do some work now it's fixed.  Darn.
<gary_poster> bigjools: lol, sorry :-)
<bigjools> :)
<flacoste> hi lifeless
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 3 | PQM in RC for devel | RM: jcsackett | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<bigjools> sinzui: around?
<sinzui> bigjools: yes
<bigjools> sinzui: when you have a moment, it's not urgent, but I'd appreciate your feedback on the mockups for the new +addseries page and its new +initseries, see https://dev.launchpad.net/LEP/DerivativeDistributions#Mockups
<sinzui> bigjools: thanks
<bigjools> sinzui: thank *you*
<jcsackett> benji: are bugs 651852 and 669701 qa-able?
<benji> jcsackett: looking
<jcsackett> thanks.
<lifeless>  /win 70
<benji> jcsackett: both are; 651852 is now marked qa-ok, but 669701 will have to be QAed by someone that has write permission for feature flag rules, a LOSA perhaps
<jcsackett> benji: dig.
<jcsackett> thanks.
<lifeless>  /win 70
<lifeless> bah
<lifeless> wgrant: *all* oops/timeout are 'high'
<lifeless> wgrant: per ZeroOopsPolicy
<gmb> jcsackett: Bug 683672 is now qa-ok.
<_mup_> Bug #683672: Bug description in verbose footer should be indented by 2 spaces <lp-bugs> <qa-ok> <story-better-bug-notification> <trivial> <Launchpad itself:Fix Committed by gmb> < https://launchpad.net/bugs/683672 >
<jcsackett> gmb: thanks!
<flacoste> lifeless: we have a problem, project can only be part of one project group
<flacoste> which means that lazr projects cannot be part of both lazr and launchpad
<flacoste> we could make them all part of launchpad
<flacoste> maybe except lazr-js
<flacoste> and even then
<lifeless> flacoste: ah, yes we should fix that ;)
<flacoste> lifeless: i'm moving all of them to launchpad, leaving a URL to the other lazr project
<flacoste> anything lazr is vapourware
<flacoste> so not really worth separating out
<lifeless> flacoste: ah
<lifeless> flacoste: I fear that if we don't have a brain-dead-simple way of querying all the bugs that lp interrupt squads should care about, that ones outside the default-set will get starved
<flacoste> lifeless: i agree
<flacoste> that's why i'm moving all the projects which we maintain to launchpad-project
<lifeless> \o/
<flacoste> except storm
<lifeless> which we don't maintain :)
<flacoste> right
<flacoste> and when it affects us
<flacoste> we usually have a bugtask on launchpad for it
<flacoste> lifeless: all done
<lifeless> gaaarh
<lifeless> the list of projects is cached I guess
<bigjools> flacoste: what about launchpad-buildd?
<flacoste> lifeless: it is
<lifeless> :(
<flacoste> bigjools: already there i think
 * lifeless embugginates
<lifeless> 'launchpad auto build system'
<bigjools> flacoste: well generally I mean, it wasn't folded into launchpad like the others, do we intend to keep it separate?
<bigjools> (given the bug about splitting out the code from the tree)
<flacoste> bigjools: being part of Launchpad project is orthogonal to having a separate tree
<flacoste> bigjools: wait a moment
<flacoste> a) yes, it should be a separate project
<flacoste> b) it should be part of the launchpad-project so that its bugs are part of the overall bugs we need to fix
<flacoste> list
<bigjools> ok
<flacoste> c) we should move it out in a separate code tree
<bigjools> sounds reasonable to me
<flacoste> like lazr.restful or wadllib
 * flacoste goes to lunch
<lifeless> flacoste: so, I can bug triage now
<lifeless> ?
<flacoste> lifeless: yep
<sinzui> matsubara: Ursinha: I am looking a bug 687465. The code thinks it is reporting oopses, but I never see them in oops reports. Can you confirm that production mailman is generating oopses and we rsync them
<_mup_> Bug #687465: add oops reporting to the xmlrpc queue runner <lp-registry> <mailing-lists> <Launchpad itself:Triaged> < https://launchpad.net/bugs/687465 >
<matsubara> sinzui, /me looks
<matsubara> sinzui, which machine does production mailman runs one?
<sinzui> matsubara: I do not know. Chex do you know ^
<Chex> matsubara: forster
<matsubara> sinzui, there's a /srv/launchpad.net-logs/scripts/forster/mailman-xmlrpc dir in devpad and the last oops dir there is 2009-10-06. I'm trying to find a newer mailman-xmlrpc dir in devpad
<matsubara> Chex, thanks
<matsubara> sinzui, ./staging/asuka/mailman-xmlrpc
<matsubara> ./scripts/forster/mailman-xmlrpc
<matsubara> ./qastaging/asuka/mailman-xmlrpc
<matsubara> those are the dirs where I'd expect mailman oopses to show up
<matsubara> and by mailman oopses I mean those with MMX prefix
<matsubara> or QSMMX for qastaging nad SMMX for staging
<sinzui> matsubara: I think the product config says the oopses start with a c
<sinzui> matsubara: as I noted in the bug, I found bugs in the database there were never in the daily reports
<pcjc2> sinzui?
<matsubara> sinzui, the reason OOPS-1795C1521 doesn't appear in the report (https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2010-11-30.html#informational-only-errors) is because it's hidden amongst the 2858 error of the same kind. the report just show a sample of 10
<matsubara> it's very likely OOPS-1795D3104 doesn't show up for the same reason
<sinzui> :(
<pcjc2> hi Sinzui, I've provided updated information on the my LP bugs you triaged earlier
<sinzui> matsubara: what can we do to ensure mailman oopses are not information-only-errors
<sinzui> pcjc2: I dedupped the bug
<sinzui> well I undid regardless of that word I just mad up
<sinzui> made
 * sinzui gives up
<pcjc2> cool - was a little frustrating to see them closed down so quickly given a LP dev had asked me to file them
<matsubara> sinzui, why do you think OOPS-1795C1521 is a mailman oops?
<pcjc2> Is the canonical-identity-provider code available to take a poke at?
<pcjc2> or is that a closed-source part of LP?
<sinzui> matsubara: the TB: Module lp.registry.xmlrpc.mailinglist, line 200, in getMembershipInformation
<matsubara> sinzui, OOPS-1795C1521 has no traceback information and is the informational only oops
<sinzui> matsubara: since mailman is an antonymous system, most of its issues will appear  related to MailingListAPIView
<matsubara> sinzui, OOPS-1795D3104 is not an informational only oops
<sinzui> https://lp-oops.canonical.com/oops.py/?oopsid=1795D3104
<sinzui> has a tb
<matsubara> yep, and that one is not informational only
 * pcjc2 found the identity-provider branch
<sinzui> matsubara: as for https://lp-oops.canonical.com/oops.py/?oopsid=1795D3104, Chex saw it in mailman's log we know the runner reported it
<sinzui> matsubara: I have the death trail of Mailman's failure in November. There are a lot of oopses it reported hours before it's death http://pastebin.ubuntu.com/552570/
<matsubara> sinzui, OOPS-1795D3104 is a timeout. it didn't show up in the report because there were a total of 218 unique timeouts on that day and only 15 showed up in the report https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-2010-11-30.html#time-outs
<sinzui> matsubara: okay. We may need to think about that because mailman thinks it is being DoSed
<matsubara> sinzui, so the runner tried to get_subscriptions but LP was timing out on that call and recording each oops correctly
<pcjc2> I'm trying to login to the staging server, but it won't auth with the API provider
<pcjc2> Sorry - OpenID provider...
<pcjc2> Does the staging server sync the user database for production regularly? The user I'm trying to use is for a robot, and I created the account only a couple of days ago
<sinzui> matsubara: since we are getting the oopses. I will change mailman to send the 503 and 504 information as oopses so we see mailmans conclusion that life has no meaning and kills itself
<sinzui> pcjc2: I do not have an answer. SSO is not launchpad and we do not control it. Canonical's ISD group does and they can set Lp staging to use their staging version of SSO. We do not know the state of their DB
<pcjc2> ok I hadn't appreciated the division there
<sinzui> pcjc2: try qastaging. The DB is many weeks old, but it does using production SSO (login.ubuntu.com)
<pcjc2> is that LP database ok to screw with arbitrarily?
<pcjc2> (I'm writing a robot, and don't want to mess things up where I shouldn't!)
<sinzui> pcjc2: as long as there is a login.launchpad.net, no one will know there that they have two separate systems
<sinzui> pcjc2: you can do what ever you need. The DB will be restored in a week or two
<pcjc2> Is there a political divide?
<StevenK> Awww, mwhudson's cloak changed :-(
<pcjc2> ok - will create some bugs against our project and play with them
<mwhudson> only 8 months later or whatever
<matsubara> sinzui, sounds sensible. at least that way we'll see those reported as XMLP kind of oopses, right?
<lifeless> pcjc2: there are different teams
<pcjc2> ValueError: qastaging is not a valid URL or an alias for any Launchpad server
<lifeless> pcjc2: we see eye to eye but we (effectively) cannot change stuff in that code
<sinzui> pcjc2: No. We do not want to be in the OpenID biz. Users want more from it than we do. So gave it to Ubuntu. We want to allow users to login using any OpenID service. The problem is that setting up a domain that looks like launchpad, bug does not work like Launchpad was a mistake
<pcjc2> credentials.get_request_token(web_root="qastaging") <-- is there a URL I can use there instead?
<pcjc2> sinzui: I'm glad you want to let logins from any OpenID service
<pcjc2> We just migrated our bugs and stuff to LP, and some of our users wanted to use existing OpenID logins etc..
<sinzui> pcjc2: I use launchpadlib.launchpad.Launchpad.login_with('testing', 'https://api.qastaging.launchpad.net/')
<pcjc2> needed to drop the "api." for the credentials.get_request_token(web_root="https://qastaging.launchpad.net"). but it worked
<pcjc2> Thanks
 * pcjc2 does find the distinction between loging on to LP and loging on at login.launchpad.net a little amusing
<pcjc2> but it seems less strange to me as I know vaguely how it works ;)
<pcjc2> I wish LP had an option to let me masquerade as another user
<pcjc2> (my robot), rather than forcing me to log off all the way
<pcjc2> https://launchpad.net/~gpleda-launchpad-robot
<pcjc2> Would also be nice to have somewhere that I (or the developer team) "own" that user account
<sinzui> There is a very old bug suggesting that we provide I way to become another user or change privileges temporarily. I do not think we plan to work on it any time soon.
<pcjc2> sounds like many of the feature requests for our project.. nice idea.. no time ;)
<pcjc2> (or other priorities)
<pcjc2> Is there a schedule for when DB updates to staging / qastaging get made?
<pcjc2> OOPS-1836QS24
<pcjc2> Can someone check that for me?
<pcjc2> Getting a HTTP Error 404: Not Found for bug.bug_tasks on this bug:
<pcjc2> https://bugs.staging.launchpad.net/geda/+bug/693991
<_mup_> Bug #693991: compiz crashed with SIGSEGV in nux::IOpenGLSurface::UnlockRect() <amd64> <apport-crash> <apport-failed-retrace> <decorations> <gnome> <metacity> <natty> <window> <compiz (Ubuntu):New> < https://launchpad.net/bugs/693991 >
<jcsackett> is there an easy way to run ec2 tests with a different version of dependencies? say if i'm working on changes to a lazr lib? i can't find anything in the wiki.
<lifeless> pcjc2: hasn't mirrored yet
<lifeless> jcsackett: edit your versions.cfg
<lifeless> and setup.py
<lifeless> ec2 test is meant to propogate that
<jcsackett> lifeless: i may be (read: probably am) wrong, but it looks like that requires existing version numbers. is there a way to use something that only exists as a branch i'm working on?
<jcsackett> i see my earlier question wasn't clear. my apologies.
<lifeless> jcsackett: once you've added it to the download cache, its fine
<jcsackett> lifeless: ah! so i add the tarball or what have you to that, and ec2 pulls info from there? i didn't realize. that's cool.
<lifeless> its documented on ze wiki I think
<lifeless> you add the tarball, bzr add, bzr commit
<pcjc2> OOPS-1836QS42  ?
<lifeless> pcjc2: also won't have syncted yet :)
<jcsackett> lifeless: dig. thanks!
<pcjc2> what is the timeframe?
<lifeless> pcjc2: generally 15 minutes IIRC
<pcjc2> gah, I'm being a tool...
<pcjc2> I filed the bug on staging, not qastaging
<mwhudson> wgrant: are you awake yet?
<lifeless> pcjc2: hmm, so
<lifeless> oops 1836QS24
<lifeless> how did you generate that oops ?
<pcjc2> from the API, accessing a non-existant bug
<lifeless> hmm
<lifeless> shouldn't OOPS
<pcjc2> Here is a real one which is annoying me: 1836O1543
<lifeless> what was the API call you made ?
<pcjc2> OOPS-1836O1543 (this was jut now, so need to wait a bit) It is a bug search timing out
<lifeless> sure
<lifeless> so, QS24
<lifeless> what does the code look like that triggered it ?
<jml> lifeless: hello. where are you?
<lifeless> B
<pcjc2> >>> from launchpadlib.launchpad import Launchpad
<pcjc2> >>> from launchpadlib.credentials import Credentials
<pcjc2> >>> credentials = Credentials.load_from_path ("commit_robot_qastaging.credentials")
<pcjc2> >>> launchpad = Launchpad(credentials, service_root="https://api.qastaging.launchpad.net")
<pcjc2> >>> bug=launchpad.bugs[123456789]
<pcjc2> >>> print bug
<lifeless> linaro room
<pcjc2> In the response, there was: x-lazr-oopsid: OOPS-1836QS46
<lifeless> yeah
<jml> lifeless: do you want to grind more on persistence layer stuff?
<lifeless> sure
<pcjc2> The search oops I'm hitting is via the normal web interface - was looking to find all open bugs in the project with no tags
<lifeless> jml: can yo ucome here first ?
<lifeless> pcjc2: yeah, hang on
<lifeless> pcjc2: need to wait for it to sync
<jml> lifeless: sure.
<jml> lifeless: omw
<lifeless> pcjc2: O1543 is still pending rsync
<jml> lifeless: which linaro room?
<lifeless> ballroom B
<jml> lifeless: I'll try again.
<lifeless> back right
<lifeless> right of main desk
<jml> huwshimi: hello
<huwshimi> jml: Morning
<jml> huwshimi: how'd it go yesterday?
<lifeless> pcjc2: ok
<lifeless> pcjc2: slow sql
<huwshimi> jml: Good thanks. Just getting Launchpad set up locally
<lifeless> pcjc2: what did you search for ?
<jml> huwshimi: all set up w/ wiki access?
<huwshimi> jml: Yup
<wgrant> mwhudson: Hi.
<wgrant> lifeless: It's only a soft timeout so far.
<lifeless> wgrant: ah; well it can be real anytime you like :>
<mwhudson> wgrant: hi, i wanted to ask you about openid identifier/account merge crazyness
<mwhudson> wgrant: but we found mbarnett instead
<lifeless> pcjc2: https://bugs.launchpad.net/launchpad/+bug/701250
<_mup_> Bug #701250: Product:+bugs timeout with search  <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/701250 >
<wgrant> mwhudson: It should all be pretty much fixed soon, after the next SSO deployment.
<mbarnett> woot
<wgrant> But who knows when that will be.
<lifeless> matsubara-afk: \o/ codebrowse oopses are visible
<pcjc2> lifeless: 17 seconds is a long SQL query...
<pcjc2> Bad DB index?
<sinzui> pcjc2: Most long queries are because the there to too much data being collected, most of which will not be used
<pcjc2> in terms of row count, or data join'd from other tables?
<sinzui> data in other tables and columns. Bug queries are undermined by the ORM in a way
<flacoste> hi huwshimi! welcome aboard!
<lifeless> pcjc2: indeed
<lifeless> pcjc2: we need to debug this a little against staging
<pcjc2> we? as in me you and me?
<flacoste> huwshimi: subscription to canonical-launchpad approved
<jml> huwshimi: btw, give us a holler if there are issues with getting a dev env set up
<huwshimi> jml: Thank you. It's taking a while to pull everything down, but it is working.
<StevenK> *Another* Sydney-sider?
<wgrant> Too many.
<StevenK> Oh, so clearly I need to move to Melbourne?
<wgrant> Yes.
<wgrant> Or follow the others' lead, and move to another country!
<mwhudson> i guess QLD is not looking such a good option currently
<StevenK> Queensland has other problems.
<StevenK> Such as being full of Queenslanders.
<jml> StevenK: now now.
<huwshimi> flacoste: Thanks you! Sorry only just noticed your message.
<mkanat> What does it take to get ~/launchpad-pqm/loggerhead to be set up on qastaging as codebrowse, and then pushed to production?
<mkanat> ~launchpad-pqm/ that is.
<mkanat> Okay, I guess I need to update sourcedeps first.
<mkanat> Do I propose merges against edge and then those go into stable...?
<StevenK> mkanat: No, propose merges against lp:launchpad, which is the right place
<mkanat> Okay.
<lifeless> there is no edge
<mkanat> lifeless: There's lp:launchpad/edge
<jml> lifeless: hello
<lifeless> let me just delete that
<mkanat> lifeless: Okay.
#launchpad-dev 2011-01-11
<timrc> I'm working on an app that authenticates users with lp/openid and I'd like to use their team memberships for context.  I must be missing something because using OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO = True in conjunction w/ https://login.launchpad.net/ does not seem to do anything
<timrc> Oh, and one important detail, I'm using django and the django-openid-auth library
<lifeless> timrc: I think you need to be whitelisted to query that via openid
<lifeless> to prevent harvesting; IMBW
<timrc> lifeless: thanks! do you know who I would talk too?
<lifeless> timrc: anyhow, separately, don't use login.launchpad.net - login.ubuntu.com *is* login.launchpad.net
<lifeless> https://forms.canonical.com/lp-login-support/
<timrc> lifeless: right, thanks and thanks again
<lifeless> from the bottom of https://login.launchpad.net/
<lifeless> bach
<lifeless> https://login.ubuntu.com/
<lifeless> https://forms.canonical.com/sso-support/ <- that one
<timrc> lifeless: great, thank you
<lifeless> jml: around?
<pcjc2> lifeless - that SQL query
<pcjc2> I wrote it out indented, was slightly perturbed to see lack of brackets between OR and AND clauses in the bug status selection portion
<pcjc2> might be correct, but the operator ordering isn't totally clear
<pcjc2> actually, on second reading, probably OK - I must avoid adding too many () for the sake of not having to remember operator ordering!
<pcjc2> I trust the postgreql engine is smart enough not to execute the Auth lookup part of the query in the case where Bug.private = FALSE
<pcjc2>          EXISTS (SELECT BugSubscription.bug FROM BugSubscription, TeamParticipation
<pcjc2>                         WHERE TeamParticipation.person = 882987 AND
<pcjc2>                               BugSubscription.person = TeamParticipation.team AND
<pcjc2>                               BugSubscription.bug = Bug.id)
<pcjc2> could take a while if executed for every bug it has to consider in the list
<lifeless> thats a correlated subquery yes
<pcjc2> I used to speak SQL at one point (A-Level computing) ;)
<pcjc2> but not so much any more - its mostly read-only
<pcjc2> I'm trying to run it on my local instance (although doesn't have such a big DB ;))
<lifeless> hey if you've reformattted it to work
<lifeless> paste that to me in pastebin or something
<pcjc2> not reformatted, just entered in psql
<pcjc2> reindented it so I could read it
<pcjc2> doesn't get any hits on my DB - so I suspect I didn't munge the product IDs properly to reflect my local instance
<pcjc2> BugTask.bug NOT IN (SELECT bug FROM BugTag) AND
<pcjc2> what about having NOT EXISTS (SELECT bug from BugTag where bug = Bug.id)
<pcjc2> so you don't search the entire tag list for every bug in the DB for every bug we query?
<pcjc2> or perhaps "BugTask.bug NOT IN (SELECT bug FROM BugTag WHERE bug = Bug.id)"
<lifeless> pcjc2: there were \\n in the thing I pasted
<lifeless> if you can paste me something ready to run
<lifeless> then I can do something interesting
<pcjc2> ok - will try
<pcjc2> I deleted the \\n and indented differenly, but never mind
<pcjc2> LP ought to grow a "no wrap" mode for some comments IMO
<pcjc2> http://ubuntu.pastebin.com/DVg1NzYm
<pcjc2> try that
<pcjc2> Just adds a "WHERE bug = Bug.id" to the tag sub-query
<pcjc2> I'm curious what bit of code translates the tag query the user enters into that SQL though - other than the missing WHERE clause, it looks pretty efficient
<pcjc2> (of course.. I'm not certain that adding the WHERE clause will help - it should in theory be able to do just as good a search without it, since it is filtered by that afterwards)
<thumper> lifeless: hi
<thumper> lifeless: do we have regex string matchers yet?
<thumper> lifeless: just wondering if someone else has written them yet
<lifeless> thumper: in testtools trunk I think
<thumper> :(
<pcjc2> lifeless: are you able to run that SQL on the same DB as a real server? (If not, we need different owner IDs and product Ids)
<pcjc2> Since the query is ~instant on my machine it probably needs testing on a large DB to reproduce the huge exec time
<pcjc2> if that helps (not that I probably need to point you at this ;)), the SQL in question comes from lib/lp/bugs/model/bugtask.py ~ line 1369
<pcjc2> Sorry, line 1422
<pcjc2>             exclude_clause = "SELECT bug FROM BugTag"
<lifeless> ok, 0.3 seconds
<lifeless> hmm
<lifeless> we don't have your data in prod yet
<lifeless> hang on
<pcjc2> and 17 when executed before?
<spm> lifeless: https://pastebin.canonical.com/41738/
<spm> 2nd run https://pastebin.canonical.com/41739/
<pcjc2> s[is this related to what I'm looking at?
<lifeless> spm: thanks; what does it return without the explain analyse - whats the found count ?
<pcjc2> spm: ... (^___)
<lifeless> pcjc2: yes, its your query analyzed
<pcjc2> don't have privs to look at that
<spm> o rows
<lifeless> ok, thats very interesting
<spm> that'd be 0. not o.
<lifeless> pcjc2: did you add  braces perhaps ?
<pcjc2> That comes from the fact it was a stupid query for our bug-set
<pcjc2> ALL the bugs are tagged with something to determine which sourceforge tracker they came from
<lifeless> pcjc2: does it still oops if you try via the web UI ?
<pcjc2> I only realised this when I tried to run it locally
 * pcjc2 checks
<pcjc2> Yes, it does
<pcjc2> (ErrorÂ ID:Â OOPS-1837O107)
<pcjc2> Any chance I can see those pastebin postings?
<lifeless> ah yes
<lifeless> http://pastebin.com/732mWULr
<pcjc2> most of the parts look like they were never executed
<pcjc2> Is that on the production database?
<lifeless> yes
<pcjc2> so the same thing the OOPs said took 17 seconds, executed in 0.369ms ??
<lifeless> unless there was a transcription error
<pcjc2> doesn't show me in the dump what product IDs were used
<lifeless> flacoste: I've removed the 'edge' series to avoid confusing folk
<lifeless> spm: again please - http://pastebin.com/raw.php?i=3S3RKCSY
<lifeless> spm: two by explain analyze and one for the result itself
<lifeless> pcjc2: that will be an hour or so
<pcjc2> execution time, or just fitting the job in?
<lifeless> getting an spm timeslice
<pcjc2> spm is a LOSA ?
<lifeless> yes
<pcjc2> just for scale - what sort of size data-centre is all this running on?
<lifeless> data centres
<wgrant> The DB servers are amusing.
<lifeless> pcjc2: primary db server is 16 cores, 128GB of ram, db is ~250GB on disk
<lifeless> pcjc2: we have 2 active replicas with 8 cores eachm same ram, same db size on disk
<pcjc2> I assumed some kind of DB cluster
<pcjc2> so queries are load-balanced between all 3?
<lifeless> appservers direct read only queries to replicas when possible
<lifeless> writes go to the primary
<pcjc2> was just about to ask that
<pcjc2> does it gaurantee in-order processing?
<lifeless> no
<pcjc2> so if you get a write to the primary, followed by a read at some point later (from the same app?), the write is going to be replicated and affect the read?
<lifeless> we so, uhm 4million page hits a day
<lifeless> if we serialised we'd be dead in the water
<wgrant> pcjc2: The DB is determined largely by the request type.
<lifeless> a write to the primary and then a read from a slave may read the old data
<wgrant> pcjc2: POSTs go to the master, most GETs to the slave.
<wgrant> pcjc2: So within a request it should be consistent.
<wgrant> Across requests, possibly not.
<pcjc2> cool - this is computing on a scale larger than I ever knew before (writing MS Access databases ;))
<pcjc2> lifeless: that first analyze execute you posted the results for..
<pcjc2> was that the SQL query which LP executed, the one from the OOPS, or the modified one?
<lifeless> all the one you gave me
 * pcjc2 checks i didn't screw it up
<lifeless> I've regenerated - its the new one I'm asking spm to run
<pcjc2> I screwed it up...
<pcjc2> The one I pasted you had product IDs replaced as I was running it on my local DB
<lifeless> I suspected it might
<pcjc2> I saw the IDs ok in the new one you asked to execute
<pcjc2> how does security work here - I presume at some level, it is because the LOSAs know who you are and won't ask them to execute a DROP *;
<pcjc2> And presumably they scan the SQL and keep an eye for any nasty side-effects possible?
<lifeless> its because a) they know who I am and b) they will read the sql
<lifeless> I'm authed to freenode, etc.
<pcjc2> I recall hearing the LOSAs don't like executing SQL much
<pcjc2> (Or certainly - not tested and approved SQL)
<lifeless> thats nuanced
<lifeless> mutating sql we require a bug describing how we can avoid ever running the sql again
<lifeless> read only sql we only do as part of diagnosing faults
<lifeless> and every such request is an interrupt which reduces project work
<lifeless> so its moderately important to us not to interrupt them casually
<pcjc2> so if there was some manual fixup required which could be done in a few SQL statements.. someone would have to file a bug and decide if LP needed to grow internal support for that feature etc..
<lifeless> pcjc2: yes
<lifeless> pcjc2: and we'd have an incident report
<lifeless> our schema is extremely complexx
<pcjc2> noted ;)
<lifeless> the chance of screwing something up on even simple sql is nontrivial
<pcjc2> I've been reading bits of it for amusements sake
<pcjc2> When I run ANALYSE EXECUTE here I get      ->  Index Scan using bugtag__bug__idx on bugtag  (cost=0.00..8.27 rows=1 width=4) (actual time=0.003..0.003 rows=1 loops=267) for the tag lookup
<lifeless> that will be affected by the stats which affect th eplanner
<lifeless> also
<lifeless> I wouldn't obsess on the tag component
<lifeless> we need data
<pcjc2> trye
<pcjc2> But without the SELECT, there is rows=33445 loops=1
<pcjc2> So I'm guessing that it will show a difference in the query you analyse too
<pcjc2> Is spm going to run ANALYSE EXECUTE  on the original SQL LP emitted?
<pcjc2> I'm going to have to call it a night - 2AM here - will read the bug report tomorrow to see if there was any development
<pcjc2> (Please leave a comment if there is marked difference in analysis results with the tag part changed)
<pcjc2> Btw.. in case you didn't hear it enough - Launchpad is AWESOME
<lifeless> thanks :)
<pcjc2> Moving from Sourceforge to LP with our bugs has TOTALLY reinvigorated our two projects
<pcjc2> Contributors are coming out of the woodwork with patches, participating in review, reworking their patches
<pcjc2> On SF, patches went to die
<lifeless> thats awesome
<pcjc2> We had to shut our -dev email list down to open membership due to Signal to noise ratio problems
<pcjc2> LP bug comments have proved to be the -dev list we never had. Active, constructive discussion of the item in hand - far less OT
<pcjc2> (And this is still only a couple of days into  our migration and triage effort!)
<pcjc2> I know SF is not a great shining example to compare against, but I've had several positive comments from users who far prefer LP as well now they've tried it
<lifeless> I wonder if we have a page for quotes ;)
<thumper> lifeless: I've got a question if you've got a minute
<pcjc2> Feel free to quote me if you  want
<pcjc2> Really -> bed now, night!
<LPCIBot> Project devel build (348): STILL FAILING in 3 hr 26 min: https://hudson.wedontsleep.org/job/devel/348/
<lifeless> thumper: sure
<thumper> lifeless: it is about the +build urls
<thumper> lifeless: that bigjools replied to on launchpad-dev
<thumper> lifeless: he mentions three points, but only one (IMO) is valid
<thumper> lifeless: is it worth fighting or just add redirects?
<lifeless> whats the thread subject?
<thumper> Url change for binary package builds
<LPCIBot> Project db-devel build (262): STILL FAILING in 3 hr 28 min: https://hudson.wedontsleep.org/job/db-devel/262/
<thumper> lifeless: are you reading or busy?
<lifeless> thumper: its dinner/drinks time, so multiplexing
<thumper> :)
<lifeless> which one is valid ?
<thumper> that people may keep ids around
<thumper> my change altered ALL binary builds
<thumper> not just ppa ones
<thumper> so that is one of the three out
<thumper> the second point I disagree with
<lifeless> the api stability argument may matter if the build objects were exported in '1.0
<lifeless> '
<thumper> I talked with flacoste about it and he doesn't think it is an issue
<thumper> he seemed to think that the url wasn't a big issue...
<lifeless> I think we need to decide if our apis are stable or not
<lifeless> changing the url space for existing 1.0 exported things is a big deal IMO
<thumper> lifeless: in order to get this fixed probably best to just add redirects yes?
<thumper> this is an oops issue for us
<lifeless> I think it probably is best overall, yes.
<thumper> ok
<lifeless> it is more work
 * thumper gets on it
<thumper> it is
<thumper> the work is complete as is
<thumper> so yes, more work
<lifeless> OTOH the work makes the transition smoother during the deploy
 * thumper shrugs
<thumper> I'll get it done
<lifeless> cool
<lifeless> thumper: hey, do you think you could land mkanat's loggerhead version bump?
<thumper> lifeless: where is it?
<lifeless> thumper: https://code.launchpad.net/~mkanat/launchpad/lp-loggerhead-update/+merge/45787
<thumper> lifeless: yep
<lifeless> awesome, thanks!
<thumper> gah
<thumper> can't lp-land it
<thumper> as I don't have that branch
<thumper> isn't there a setting to say "land that one"
<lifeless> if there isn't, there should be a bug asking for that
<lifeless> I'd be happy for such a bug to be triaged 'high'
<thumper> lifeless: which plugin?
<lifeless> lp-submit I think
<lifeless> perhaps pqm-submit
<thumper> lifeless: it is in the pqm plugin
<thumper> lifeless: is devel open?
<thumper> lifeless: topic says no
<lifeless> oh
<lifeless> hmm
<lifeless> we should be able to open again as soon as we're qa'd up past the db merge.
<lifeless> I guess that isn't in the process docs yet or something, or perhaps we aren't qa'd to that point yet.
<lifeless> spm: hi
<spm> lifeless: ho!
<lifeless> spm: did you see my analyze request ?
<spm> oh no. sorry. doing now.
<lifeless> spm: new post - http://pastebin.com/raw.php?i=5HBhT6R4
<spm> ugh. 15+ seconds on getting the explain analyse
<lifeless> yes, thats why we're asking for it ;)
<lifeless> data isn't in staging yet
<spm> ew. https://pastebin.canonical.com/41741/ 1 minute just for the analyse.
<lifeless> spm: 2 plox, + the actual result
<spm> yah. 2nd runing now.
<lifeless> . wireless . at . hotels .. sucks
<spm>  count
<spm> -------
<spm>      9
<spm> (1 row)
<spm> lifeless: ^^
<lifeless> ???????
<lifeless> what was the second analyze?
<spm> I didn't paste that? oops. one sec.
<lifeless> note that I can see
<spm> https://pastebin.canonical.com/41742/
<spm> no I didn't meant to add it to the results above
<spm> didn't <comma> meant to...
<lifeless> around for a little?
<lifeless> spm: can you try
<lifeless> http://pastebin.com/LcA17msn
<spm> lifeless: https://pastebin.canonical.com/41743/ I like that version better
<lifeless> thanks spm
<lifeless> me too
<wgrant> Wow, KDE is stupid.
<lifeless> ...
<wgrant> I installed python-kde4 last night to try to debug the SIGCHLD thing.
<wgrant> I just logged out and back in, and now the test suite causes a KWallet prompt followed by a segfault.
<lifeless> \o/
<StevenK> Clearly, KDE is for people who want a broken Launchpad.
<wgrant> It's probably not Launchpad's fault that there's a segfault.
<wgrant> That is entirely down to KDE :)
<wgrant> spm: Hi.
<spm> wgrant: yo!
<lifeless> yoyo
<wgrant> spm: Could you please run http://paste.ubuntu.com/552687/ on prod?
<spm>  architecturetag | count
<spm> -----------------+-------
<spm>  ia64            |  1982
<spm>  sparc           |  1983
<spm> (2 rows)
<spm> wgrant: ^^
<wgrant> Damn.
<wgrant> OK, thanks :(
<StevenK> wgrant: pitti is having lots of fun with your VGA cable
<wgrant> StevenK: Oh?
<wgrant> spm: http://paste.ubuntu.com/552689/, if you could.
<StevenK> wgrant: Martin's laptop with Natty, 52" TV in the hotel room, do you need a calculator?
<wgrant> StevenK: Ah, of course, making Unity crash even more spectacularly than usual!
<StevenK> wgrant: Sadly, it didn't crash once.
<spm> wgrant: https://pastebin.canonical.com/41744/
<wgrant> StevenK: It doesn't do anything *but* crash on my desktop.
<wgrant> spm: aaaaaaaaaaaaaaaaa
<spm> heh
<StevenK> wgrant: Can has bug with a backtrace?
<lifeless> wgrant: is bug 78845 still true?
<_mup_> Bug #78845: publication process should allow per-release holds <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/78845 >
<wgrant> StevenK: Possibly.
<wgrant> StevenK: It's a bit hard.
<wgrant> Because fglrx is awful.
<wgrant> And likes to hang once Unity crashes.
<StevenK> Oh, ye gods.
<lifeless> well there is your bug
<wgrant> Although even vanilla Compiz crashes sometimes now.
<wgrant> It was stable in maverick :(
<wgrant> lifeless: I don't think that's ever been true.
<wgrant> And it's even less true now that security uploads don't go through the queue.
<StevenK> I suspect you're on your own, masochist
<wgrant> spm: https://pastebin.canonical.com/41745 :(
<spm> wgrant: https://pastebin.canonical.com/41746/
 * spm is an SQL bot
<StevenK> Today, you are.
<wgrant> spm: Thanks.
 * wgrant goes off to cry in the Soyuz corner.
 * StevenK cries at test_hasbuildrecords.py
<StevenK> Yes, let's use broken sampledata that's been changed by use of removeSecurityProxy() and THEN push it through code. Ja. That would be fun.
<wgrant> Oh, they're not actually in the primary archive.
<wgrant> Phew.
 * StevenK grumbles at sourcepackage.py
<StevenK> # End of duplication (see XXX cprov 2006-09-25 above).
<StevenK> What XXX by cprov?!
<wgrant> StevenK: IIRC the original XXX is in one of the duplicates.
<wgrant> But not the other.
<StevenK> Must. Resist. Throwing. Laptop.
<wgrant> It's a ThinkPad, it'll survive.
<StevenK> If it's closed.
<wgrant> True.
<spm> so close it, throw, then re-open?
<StevenK> Hah
 * StevenK rings Chubb first ...
<StevenK> (Pdb) print self.builds[0].build_farm_job.date_finished
<StevenK> None
<StevenK> Ah ha. Hello, smoking gun.
 * wgrant pushes delayed copies off a cliff.
<wgrant> spm: http://paste.ubuntu.com/552703/ <- last one, but there'll be about 4000 rows returned.
<spm> do you need all 4k?
<wgrant> Ideally.
<wgrant> We have at least three variations of the bad data... I'm not sure how many more there are.
<StevenK> spm: Only give him 3,999. He'll never know ...
<spm> StevenK: you are kidding right? this is *wgrant* we're talking about.
<StevenK> Bwahaha
<spm> amusingly, it's 3969 rows
<spm> well, lines of output.
<wgrant> I was expected 3965 rows of data.
<wgrant> Which is one off.
<wgrant> Odd.
<spm> wgrant: https://devpad.canonical.com/~spm/wgrant.out
<spm> (3965 rows)
<wgrant> spm: Thanks.
<wgrant> Sounds like it's a good time to visit Brisbane.
<wgrant> brb
<wgrant> Is there a reason we don't have a PropertyCache-based memoization decorator yet?
<adeuring> good morning
<al-maisan> Good morning adeuring !
<adeuring> Hi al-maisan!
<al-maisan> how are things!
<adeuring> sad to see you leaving
<al-maisan> s/!/?/
<al-maisan> adeuring: das ist der Lauf der Dinge :)
<adeuring> althings are fine here. Looking forward to the epic
<al-maisan> nice :) when and where is the epic taking place?
<bigjools> morning
<jcsackett> leonardr: what's the qa status of bug 686690? is it qa-able?
<_mup_> Bug #686690: 1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings <desktop-integration> <qa-needstesting> <regression> <launchpadlib :Fix Committed by leonardr> < https://launchpad.net/bugs/686690 >
<leonardr> jcsackett: yeah, it's qaed, let me just make sure the new version made it into launchpad
<jcsackett> leonardr: ok. thanks.
<leonardr> jcsackett: yeah, looks good
<jcsackett> leonardr: excellent. that's the last bug blocking the deploy-stable queue.
<jcsackett> thanks, leonardr.
<leonardr> np
<flacoste> jcsackett: do we have revision number?
<jcsackett> flacoste: unless someone contacts me with something that needs RC and landing by midday today, r12177.
<flacoste> jcsackett: how about doing a nodowntime today of 12176?
<jcsackett> flacoste: i'm comfortable with that.
<flacoste> jcsackett: can you make it happen?
<mwhudson> we can't do nodowntime to codehosting yet can we?
<jcsackett> mwhudson: i don't know. flacoste? ^^
<jcsackett> i thought we could nodowntime anything that didn't require db changes, but i could be quite wrong.
<flacoste> mwhudson: we can't no
<mwhudson> ah well
<flacoste> mwhudson: codehosting isn't part of nodowntime yet, we have a RT in progress to fix that though
<mwhudson> cool
<flacoste> jcsackett: soyuz FTP services, librarian and codehosting are not part of the nodowntime set
<flacoste> because deploying there actually causes downtime to the services
<bigjools> I had an idea about ftp services
<flacoste> we have RTs to fix codehosting and librarian
<bigjools> and ftp :)
<flacoste> soyuz FTP services will require some engineering
<flacoste> bigjools: i thought ftp was more than a RT?
<bigjools> flacoste: given that we never, ever change the ftp code, I filed an RT to have 2 deployment trees, one for FTP and one for everything else
<jcsackett> flacoste: let me scan the deployment queue again then and make sure we don't have anything that couldn't be nodowntime then--i haven't been reviewing the queue with that in mind.
<bigjools> then we can roll out to germanium's "everything else" tree as part of the nodowntime set
<lifeless> jcsackett: most things
<flacoste> bigjools: that would be a nice incremental improvement!
<lifeless> bigjools: we can do an active-passive mode for ftp / sftp
<bigjools> flacoste: rt 43238 if you want to poke
<lifeless> bigjools: wgrant seems to think its harder than that though, and was going to speak to you about it
<bigjools> lifeless: I think it will be hard too
<bigjools> since we can't interrupt in-progress uploads
<lifeless> sure
<lifeless> same constraint we have on appservers
<bigjools> so needs a bit of engineering - my 2-tree solution is much nicer I think
<lifeless> I think its a good short term fix, I don't think its a good long term fix because we want to eliminate skew
<bigjools> the only problem after that is worrying about a SPOF
<bigjools> skew?
<jcsackett> lifeless: most things?
<bigjools> there is no skew
<bigjools> the ftp code never ever changes
<lifeless> the losas monitor deployed versions
<lifeless> if we have two deploys on a machine
<lifeless> they will get warnings if one is not running the current deployed version
<sinzui> I didn't see an announcement of a rollout last week or this week, but I see we did one
<bigjools> lifeless: Tom was happy to do this when I asked him
<bigjools> I am sure they can cope
<lifeless> bigjools: I'm happy for it too, short term.
<lifeless> I don't think its a sensible long term arrangement
<mthaddon> lifeless: not exactly - that holds true for groups of servers (lpnet servers, for instance) but not across all services
<bigjools> why?
<bigjools> I'm not wedded to the idea if there's something better, but you need to explain :)
<lifeless> because it adds a nonobvious surprise waiting to be a pain in the future - especially if we very rarely change it
<lifeless> (its the rarely changed things which hurt most, because the knowledge gets lost)
<mthaddon> bigjools: I'm assuming the long term idea is make sure those services are deployable in a no-downtime-load-balanced way so we can deploy to them without affecting customers
<bigjools> can you expand on what the nonobvious surprise is?
<mthaddon> the amount of code that changes during a monthly rollout
<bigjools> mthaddon: yes, but that will need extensive code changes to make it work
<lifeless> the nonobvious surprise would be having a lp tree that isn't deployed to
<bigjools> lifeless: not true, it would be deployed once a month
<mthaddon> bigjools: actually, I think it needs as much infrastructure changes (haproxy, etc.)
<bigjools> mthaddon: not quite, see above about not interrupting in-progress sessions
<lifeless> bigjools: thats a constraint we have on the web appservers too
<mthaddon> bigjools: we'd have a way of monitoring haproxy to ensure we only stop services when there are no active sessions (as we are planning to do for the appservers)
<bigjools> yes, so we'd need to change some code, like I said :)
<lifeless> thats fine
<lifeless> short term vs long term
<mthaddon> bigjools: and we'd have a mechanism to be able to say "pretend you're down to haproxy so it doesn't send new connections to you, but don't actually stop doing anything yet"
<bigjools> mthaddon: ah, if you can do it all in the haproxy then that's a different matter
<lifeless> bigjools: the ftp thing is zope's ftp service right ?
<bigjools> yes, but I want it to die horribly
<bigjools> and replace it with twisted
<lifeless> bigjools: all it needs is a <small> http site that starts giving 500's after SIGUSR2 is received
<mthaddon> bigjools: yeah, about 80% of it is done in haproxy - just need a mechanism to be able to fool haproxy into thinking it's down when it's not (but when you want it to be shortly)
<bigjools> we have sftp in twisted, adding ftp will be easy
<lifeless> sure
<lifeless> either way
<bigjools> then the zope shit can die
<lifeless> my point is - doing what you've proposed is a great short term hack
<lifeless> but longer term - the goal is one rev of lp everywhere, on every deploy
<bigjools> if that's the goal, cool
<bigjools> bear in mind though that you'll struggle to do any of this on cocoplum
<lifeless> and yeah we have to write code and elinminate SPOF's and so forth
<lifeless> one step at a time :)
<bigjools> since we can't interrupt the current publishing cycle easily
<bigjools> well, we can, but it's nasty
<bigjools> we need cocoplum and germanium *2 to eliminate SPOFs :)
<lifeless> or to put their storage on the SAN
<bigjools> that's part of it
<lifeless> then we can have a cluster of boxes to do the processing logic
 * lifeless handwaves furiously
<bigjools> ha
<lifeless> seriously: I know this is a fiendish scale problem
<bigjools> we'd need to re-engineer a load of soyuz stuff to make in multi-processable
<bigjools> s/in/it/
<lifeless> and there are model issues where we can wedge stuff if something is uploaded twice
<lifeless> and so forth
<bigjools> yeah, not impossible, just hard
<lifeless> I'm advocating a calm one step at a time, interleaved with feature work and bug fixes
<lifeless> the benefits of getting this all done are substantial
<bigjools> I certainly won't argue with that
<lifeless> at the moment we're in a sort of phase 1: get to the point where we can upgrade all our code without user visible impact
<lifeless> that gets rid of a bunch of software level spofs
<lifeless> doesn't do scaling
<lifeless> doesn't do hardware spofs
<lifeless> doesn't do datacentre-redundancy etc
<bigjools> I'm very concerned about the scaling when we need to host derived distros
<lifeless> I'd be delighted to talk about current bottlenecks and see if we can come up with a minimal way to add pluggable capacity
<bigjools> we can chop probably 90% of the database load the b-m generates if we use MQs
<bigjools> I'll run you through it next week if you like
<lifeless> cool
<sinzui> Googles index is mutating. My search for "prescription" in Launchpad yielded 105 matches. I expected 8. I saw only 40. A minute later I searched an there was only 4 matches
<jml> lifeless: yo
<jml> lifeless: I wish to speak with you.
<danilos> anyone has any suggestion on how to debug a "ShortListTooBigError: Hard limit of 1000 exceeded." API-prefetching problem on a non-API using page? i.e. how would I figure out what attribute is getting serialized?
<danilos> oh, how stupid of me, SQL log tells me all I need to know
<lifeless> jcsackett: looks like we can unfreeze trunk
<lifeless> jcsackett: given that we're qa'd up through 12177
<jcsackett> lifeless: yes. on the list of todos i'm working down right now.
* jcsackett changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 4 | PQM is open | RM: jcsackett | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<sinzui> danilos: jcsackett, you coordinate your work. you may be doing duplicate work or bugs
<sinzui> only one of you should use do_not_snapshot on the specifications attr for product and distribution
<jcsackett> danilos: what bug are you looking at? i'm looking at bug 696913
<_mup_> Bug #696913: Product:+edit or +configure-* error 'Cannot update project details: shortlist exceeded 1000' <oops> <projects> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/696913 >
<danilos> jcsackett, oh, I just filed a new one because I've seen it in translations
<danilos> jcsackett, I am only fixing valid_specifications, I haven't hit the milestones yet, but I am sure I would when I tried this fix out
<sinzui> danilos: and lifeless filed one for blueprints. I think there may only be one bug.
<danilos> sinzui, right, it looks like it is, it's a simple doNotSnapshot missing, or a more complex "do-not-snapshot-by-default" bug
<jcsackett> sinzui, danilos: it's the IHasSpecificationsMixin; none of its collections are doNotSnapshot-ed, and it's included in Product, so anything with products can hit this.
<danilos> sinzui, jcsackett: I am marking bug 701529 as duplicate of that
<_mup_> Bug #701529: OOPS on Distribution:+configure-translations <oops> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/701529 >
<danilos> jcsackett, I have a branch which fixes it for valid_specifications (including a test that lives in registry, though ideally we'd have a IHasSpecifications test)
<sinzui> jcsackett: sprint maybe
<danilos> jcsackett, https://code.launchpad.net/~danilo/launchpad/bug-701529
<jcsackett> sinzui: you mean leave this to the sprint to discuss solution?
<sinzui> jcsackett: also projectgroup. We can test that by trying to edit the description of launchpad-project
<jcsackett> sinzui: oh, sprint, the model.
 * jcsackett is all out of whack today.
<sinzui> jcsackett: I think the problem interface is mixed into ISprint
<jcsackett> sinzui: yeah. IHasSpecifications is used in several places.
<danilos> jcsackett, sinzui: since I am in Dallas, I would be very happy to hand this over to you guys, but the branch I have is already landable imo, so if you want I can land at least that bit
<sinzui> danilos: thanks.
<jcsackett> danilos: sure, get it landed and i'll deal with any conflict in my branch when it hits.
<danilos> jcsackett, I guess it's not going to fix the problem even for translations, so I might just leave it to you :)
<jcsackett> danilos: sounds fine. i think i'll have mine ready to land by my EOD.
<jcsackett> i was trying something fancy earlier, and it goofed, so i'm going for the less fancy more functional fix.
<bac> hi benji
<benji> hey bac
<bac> benji: i created an egg for lplib 1.9.3 but am now getting other errors using ec2
<bac> benji: http://pastebin.ubuntu.com/552890/
<benji> bac: hmm, that surprises me; looking into it more
<benji> bac: I bet you're running this over an SSH session.
<bac> benji: i am.  as i always do.  :)
<bac> benji: i can try on the machine to see if i can get past the auth step
<StevenK> bac: If it isn't obvious, I'm in Dallas, so please ping me for the US reviewers meeting this week, and not the er, other one.
<benji> bac: I bet it'll work.  I'm looking for a better fix while you try that.
<bac> benji: it did
<danilos> jcsackett, so, the branch I have does fix the problem for IDistribution:+configure-translations page (tried it out by cowboying to staging)
<jcsackett> danilos: cool. if you want to land it, i don't think we'll have a merge conflict down the road. my branch tackles the same bit, plus some other collection fields and milestone stuff.
<benji> bac: you should be able to get GNOME keyring to work over ssh by running export `dbus-launch`
<danilos> jcsackett, right, I don't want to land it if you are creating a nicer lib/lp/blueprints test, so I'd let you be the judge: https://code.launchpad.net/~danilo/launchpad/bug-701529/+merge/45886
<danilos> jcsackett, if you by any accident feel an urge to approve that, I'll land it, but if you've got a better solution (I don't doubt you do :), I'll just scrap it
<jcsackett> danilos: i am adding blueprints tests, but i don't think they prohibit your landing that--two extra fields on that test aren't a testing performance issue, imo.
<jcsackett> danilos: if you would rather abandon it though and enjoy Dallas, i don't think you have to land it.
<danilos> jcsackett, it's more of a "localization issue": you break non-blueprint tests by changing blueprints, which is something I hate
<danilos> jcsackett, so, I'll scrap it (it'd still be hard to enjoy Dallas :)
<jcsackett> danilos: heheh. dig.
<timrc> bigjools: Is there a proposed Round 2 of testing for https://dev.launchpad.net/LEP/DerivativeDistributions -- I'd be interested in participating
<bigjools> timrc: nothing planned, but if you have any comments I'll gladly take them
<timrc> bigjools: is there something demoable regarding this feature?
<bigjools> timrc: no, we're a long way off
<timrc> bigjools: I'm generally interested as an OEM stakeholder
<bac> benji-lunch: that worked, thanks
<jml> sinzui: ping
<sinzui> hi jml
<jml> sinzui: hi
<jml> sinzui: I'm just looking at https://lpstats.canonical.com/graphs/People/
<jml> sinzui: it looks broken.
<sinzui> Look like someone switching Lp to use Ubuntu's SSO
<jml> sinzui: ahh, ok.
<jml> sinzui: so I should pretty much ignore the "invalid" bit?
<jml> sinzui: I'm trying to get a sense of number of users.
<sinzui> I do not know really.
<sinzui> but I think we need to broaded the range to ensure shipit nonsense is not mixed in too
<sinzui> okay shipit is not a factor
<sinzui> I wonder if this is looking a password. Lp does not use them, so I expect them to be null
<jml> sinzui: also, do you know how https://lpstats.canonical.com/graphs/ProductsFlaggedOfficial/ is calculated? is it up to date wrt your recent changes?
<sinzui> Yes, it is correct
<sinzui> note the dips as we transitioned to the new rules
<sinzui> jml: I looked at the people when I saw it hit a million. I think the number is legitimate!
<jml> sinzui: that's pretty exciting :)
<sinzui> I had a small anxiety attack at the time. Is there really that many in the communities, or do we have users who registered to do one single task
<sinzui> jml: have you ever looked at how many users get karma every week
<jml> sinzui: requently
<jml> frequently, rather.
<jml> sinzui: https://lpstats.canonical.com/graphs/KarmaBreakdownGlobalWeek/
<sinzui> I have this nagging feeling we have a large silent failure in Lp
<jml> sinzui: https://lpstats.canonical.com/graphs/KarmaBreakdownGlobalWeek/20070701/20110112/
<jml> sinzui: how do you mean?
<sinzui> less than 1% of registered users are active
<jml> sinzui: yeah.
<jml> sinzui: I think the number goes up a fair bit if you consider activity over a span longer than a week
<sinzui> that is a bogus number because some people work on monthly and yearly scales
<jml> sinzui: *nod*. it's about 20k per month
<sinzui> sorry, message interpolated badly. My 1% remark is bogus
<jml> sinzui: tell me more about your hypothesized large silent failure
<sinzui> jml I can never find the graph branch. I am suspect we need to remove password from or account from the report to fix the numbers
<jml> sinzui: bzr+ssh://bazaar.launchpad.net/~canonical-losas/tuolumne-lp-configs/trunk/
<sinzui> thanks
<jml> sinzui: it would also be nice to graph the number of projects that use *any* component officially
<sinzui> jml: I suspect many users try Lp, then silently leave. Some maybe to report a bug, some to report a project.
<jml> sinzui: yeah. I believe that.
<lifeless> oh yeah
<lifeless> did you guys see pcjc2's comments about launchpad last night?
<mwhudson> about how it had suddenly made his project awesome?
<sinzui> jml: I am talking with mrevell and gary next week about reintroducing the Lp setup profile workflow. We lost it going to Ubuntu SSO and I think it needs to be re-imagined to introduce Lp to users
<mwhudson> or something
<lifeless> mwhudson: yes
<jml> lifeless: I didn't.
<lifeless> 14:57 < pcjc2> Btw.. in case you didn't hear it enough - Launchpad is AWESOME
<lifeless> 14:57 < lifeless> thanks :)
<lifeless> 14:58 < pcjc2> Moving from Sourceforge to LP with our bugs has TOTALLY reinvigorated our two projects
<jml> rockin'
<lifeless> 14:58 < pcjc2> Contributors are coming out of the woodwork with patches, participating in review, reworking their patches
<lifeless> 14:58 < pcjc2> On SF, patches went to die
<lifeless> 14:58 < lifeless> thats awesome
<lifeless> 14:58 < pcjc2> We had to shut our -dev email list down to open membership due to Signal to noise ratio problems
<lifeless> 14:59 < pcjc2> LP bug comments have proved to be the -dev list we never had. Active, constructive discussion of the item in hand - far less OT
<lifeless> 14:59 < pcjc2> (And this is still only a couple of days into  our migration and triage effort!)
<poolie> excellent
<lifeless> 15:00 < pcjc2> I know SF is not a great shining example to compare against, but I've had several positive comments from users who far prefer LP as well now they've tried it
<lifeless> 15:01 < lifeless> I wonder if we have a page for quotes ;)
<poolie> you should post it to the blog
<lifeless> 15:08 < thumper> lifeless: I've got a question if you've got a minute
<lifeless> 15:10 < pcjc2> Feel free to quote me if you  want
<jml> that's awesome
<poolie> tagged 'feedback'
<jml> I will quotethat
<jml> lifeless: and yes we do have a page for that sort of thing.
<poolie> http://www.google.com.au/search?q=launchpad+testimonials none are us
<jml> yes.
<jml> I'll get my SEO team on to that
<StevenK> Should we put that on help.lp.net ?
<StevenK> Since, er, dev doesn't seem the right place
<poolie> mm, i really think the blog is better
<poolie> it's not user help information
<poolie> or only for developers
<poolie> or perhaps somewhere like +tour, but less dusty
<StevenK> TBH, I personally feel blogs aren't static, but ...
<StevenK> The bikeshed should be purple, clearly. :-P
<poolie> "on this day, pcjc2 said..."
<poolie> it's a moment in time
<poolie> you can tag them to find what was said
<jml> internally, https://wiki.canonical.com/Launchpad/Testimonials
<lifeless> 'in the past, our users have said...'
<poolie> but yeah, it's a bit bikesheddy
<lifeless> it's a story about how we are perceived :P
<StevenK> I don't think testimonials are a moment in time ... they should be current
 * lifeless doesn't care
<sinzui> lifeless: about Lp admins should not have nomination rights, is this because they own a team?
<lifeless> sinzui: I was going off the data in the bug
<lifeless> sinzui: owning a team would speak to the owner/operator split we were discussing the other month
<poolie> oh, this is the person filing all these bugs recently
<lifeless> sinzui: but I don't know if thats the case here
<sinzui> lifeless: exactly my thinking. I have noted that it is challenging in Lp to learn what team I own since I am not always a member
<poolie> really, wow
<lifeless> sinzui: you might like to note that this may be 'they own' rather than 'they are admins' but that we need more data to diagnose.
<lifeless> sinzui: or I can if you like, but I have about 60 bug tabs open and that one closed already
<lifeless> StevenK: yo
<lifeless> bug 261971
<_mup_> Bug #261971: Add debconf preseed for architecture tag <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/261971 >
<sinzui> lifeless: I will look into it.
<lifeless> sweet, thanks
<StevenK> lifeless: Uh?
<lifeless> StevenK: is that still needed? crack? done?
<StevenK> It's crack cut with arsenic, and lpia is dead, please kill it.
<StevenK> lamont may disagree
<StevenK> lifeless: I've pinged lamont, lesse ...
<lifeless> so have I
<StevenK> Haha. We pinged in different channels, for hilarity
<lifeless> where did you ping?
<lifeless> StevenK: surely bug 277550 is a dupe of some master 'does not support alternate dependencies' thing ?
<_mup_> Bug #277550: binary package status page does not display alternate dependencies <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/277550 >
<StevenK> We do support alternative dependencis
<StevenK> It's a bug in the model
<lifeless> I don't follow
<lifeless> do we have duplicate code?
<StevenK> lifeless: I'm trying to fix something, so I'm trying hard to not context switch
<lifeless> ok
<StevenK> lifeless: wgrant would be the best person to ask about that bug
<lifeless> thnaks
<jml> lifeless: a while ago you asked me for a public graph of the number of bugs tagged oops & timeout
<jml> lifeless: I haven't done that yet.
<jml> lifeless: do you still want it?
<lifeless> would be nice. regression too
<jml> ok.
<jml> I'll try, but I won't be hurt if someone else does it before I do.
<timrc> offhand, launchpad supports arbitrary length tags?
<timrc> the limit would just be a hard limit (e.g. db space)
<jml> flacoste: hi
<jml> flacoste: actually, off to lunch, emailed instead.
<lifeless> mwhudson: bug 613806
<_mup_> Bug #613806: SSH server should forward OOPS code to bzr client <codehosting-ssh> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/613806 >
<lifeless> mwhudson: IIRC another identical to that was filed recently;
<lifeless> is that right?
<lifeless> sinzui: there are now no untriaged bugs
<sinzui> \o/
<lifeless> well
<lifeless> none triaged + importance unknown
<lifeless> you may find it entertaining that some bloke 'Curtis' made a lot of them triaged (from confirmed) without setting an importance
<sinzui> I investigated one oh your bugs in November, I need to find the related bugs to explain what has to change to close the bug
<sinzui> I suck
<lifeless> :P
<sinzui> ajax takes too long to wait for a response
<lifeless> sinzui: whats the sso bug tracker ?
<sinzui> lifeless: do you mean project? canonical-identity-provider
<lifeless> thanks
<lifeless> we still have 176 'new / incomplete' bugs
<sinzui> We cannot set bug expiration until we fix the snapshot/shortlist bug
<lifeless> I suspect many shouldn't expire
<lifeless> kindof
<lifeless> e.g. bug 484712
<_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/484712 >
<lifeless> is just gmb being slack on answering :)
<sinzui> oh good. I thought he just had a junk filter on my bug comment
<lifeless> he may, but I'm sure its not personal :)
<sinzui> I mark all bug mail from ~/sinzui as junk. It would not surprise me if everyone did
<sinzui> lifeless: the next cleanup should be all non-released bugs targeted to a past release. It irks me to see a bug I want fixed that says it is in progress and targeted to a milestone from two years afo
<lifeless> flacoste: is deryck around atm ?
<flacoste> lifeless: he's out today
<flacoste> lifeless: we'll be back with us tomorrow
<lifeless> wgrant: hey
<jml> is there an automated way of finding out, say, what the owner of a distribution can do?
<lifeless> other than try it?
<jml> that's not automatic.
<mwhudson> jml: i think roughly speaking no
<jml> I think I've figured out how I could write something that would be close.
<mwhudson> you can look zcml that has launchpad.Edit on distribution contexts
<mwhudson> i think that's fairly close
<jml> I was thinking of going through security.py class by class
<thumper> sinzui: ping?
<sinzui> hi thumper
<thumper> sinzui: I have a branch that needs a quick UI review
<thumper> sinzui: I have a pic even
<jml> filling out https://wiki.ubuntu.com/LaunchpadPermissions fwiw
<thumper> sinzui: https://code.launchpad.net/~thumper/launchpad/show-recipe-upload-issue/+merge/45804
<sinzui> I saw. I asked my two mentees to look
<sinzui> salgado was not about. mrevell did not reply.
<sinzui> thumper: r=me, I will update the MP
<thumper> sinzui: ta
<jml> of course, there's stacks of code that has 'check_permission(obj, "launchpad.Edit")' manually
<jml> huwshimi: hi
<huwshimi> jml: Hello
<jml> huwshimi: how's things?
<leonardr> james_w, we would like to take another shot at including a more recent version of launchpadlib in natty. do you have time to talk about this?
<huwshimi> jml: Good thanks. I'm all set up and managed to work on a couple of bugs yesterday
<james_w> leonardr, would Monday work?
<jml> huwshimi: sweet.
<jml> huwshimi: so you're able to run up a local instance and what not?
<leonardr> james_w: i'll be at a sprint on monday, so it would have to be after hours
<huwshimi> jml: Yeah, all good.
<james_w> leonardr, as will I :-)
<leonardr> james_w: we won't be at the same sprint, will we??
<james_w> leonardr, I'm attending 2.5 days of the megathunderdome
<leonardr> all right, we'll talk then
<thumper> wgrant: you there?
<thumper> I cleaned out my eggs directory to get buildout to regenerate them (and clean out old versions)
<thumper> now the test runner complains about a lot of missing modules
<thumper> ImportError: No module named conch.interfaces
<thumper> ImportError: No module named conch.checkers
<thumper> ImportError: cannot import name BadRequest (from lazr.restfulclient.errors)
<thumper> ImportError: cannot import name ClientError (from lazr.restfulclient.errors)
<thumper> hmm...
<thumper> I've not merged devel
<thumper> lets try that
<lifeless> bigjools: hi
<lifeless> bigjools: or is that a false image of you?
 * bigjools is not really here
<lifeless> bigjools: ah.
<lifeless> bigjools: I was considering suggesting wgrant look at bug 641338 today
<_mup_> Bug #641338: Archive:EntryResource:syncSource timeouts <lp-soyuz> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/641338 >
<bigjools> he's busy with other stuff
<lifeless> I think it can be improved fairly easily
<lifeless> ok
<lifeless> thanks
<bigjools> but when he's done those, sure
<bigjools> it's the same underlying problem as the copy package page
<bigjools> aka the copy checker
<wgrant> lifeless: I've been sorting out the whole copier mess this week.
<wgrant> lifeless: The code is pretty shit. And the tests are worse.
<wgrant> I do have a slight performance improvement, though.
<lifeless> \o/
<wgrant> And cutting another few hundred queries of it is easy once I detangle a few things.
<wgrant> But I keep running into more bugs :/
<wgrant> And then finding more broken data caused by them :/
<lifeless> \o/
<bigjools> wgrant: at some point we need to refactor the whole copy checking thing with the upload processor
<thumper> yay, merge devel, and rebuild fixed testing errors
<wgrant> bigjools: Yes, I was whinging to bigjools about bits of that last night.
<wgrant> Er.
<wgrant> You are bigjools.
<wgrant> I am asleep.
<bigjools> do I need to throw coffee at you?
<thumper> bigjools: hi
<bigjools> thumper!
<thumper> bigjools: FYI, went with +buildjob and redirects
<thumper> bigjools: all done now
<bigjools> thumper: fantastic.  sorry I had to piss on your bonfire and all that
<StevenK> Haha
<thumper> bigjools: ah well
<thumper> you can buy me lotsa alcohol next week to make up for it :)
<bigjools> thumper: I know what it's like to have a branch ready to land and then someone points out a problem :)
<bigjools> thumper: I am always up for alcohol
<sinzui> bigjools: bac and I where wondering if these people really should have primary archives: http://pastebin.ubuntu.com/552994/
<bigjools> sinzui: !!!!
<sinzui> ^ bigjools, these people are the missing people from team.participants. a logic bug excludes them because they have primary arhives
<bigjools> how the ...
<bigjools> I think we need to find out how they got like that
<bigjools> sinzui: that's a serious bug
<sinzui> look at the ids, these are super old
<bigjools> maybe
<sinzui> well the first half are and I was looking for them in a list of members
<bigjools> sinzui: well indeed, the last 2 are recent
<bigjools> I suspect the others are badly migrated data
<sinzui> And they moonlight as Launchpad gods
<bigjools> feel free to fix those
<bigjools> wgrant can give you an eyeball
<wgrant> It's not *that* insane.
<wgrant> bigjools: Do you know how much a distro likes being without a primary archive?
<wgrant> I don't think much will care.
<wgrant> It's not at all surprising that they're there, though.
<wgrant> Creating a distribution creates a primary archive.
<sinzui> That explains only three people in the list
<sinzui> select archive.id, archive.purpose, archive.name, person.name from archive join person on archive.owner = person.id where purpose = 1 and person.teamowner is null;
<wgrant> sinzui: Why?
<wgrant> sinzui: The owner can be customised at creation-time.
<bigjools> hmmm had not thought about the distros
<sinzui> Only kiko + losas could create distros
<bigjools> easy to double check if they're attached ti one
<wgrant> bigjools: They are.
<sinzui> I do not think kiko can do it anymore
<wgrant> I actually was looking at old archives last night, as it happens.
<sinzui> Chex made a distro a few weeks ago. That accounts for his archive
<bigjools> makes sense
<wgrant> sinzui: The owner has to be specified when creating a distro.
<wgrant> sinzui: So anyone can own the archive.
<wgrant> And I recognise a few other names there.
<wgrant> Like joejaxx.
<sinzui> Even though the distro cannot use the archive, and most registered are not debian based
<sinzui> we suck
<wgrant> sinzui: Sure. We should nuke all primary archives except 1 and 3.
<wgrant> Once I check that the code is OK with it.
<wgrant> And we should also fix the code to stop creating them.
<wgrant> Because that's pointless...
<wgrant> sinzui: Oh, that is a nice bug.
<wgrant> I guess it works properly if you move the PPA restriction into the subselect?
<jml> oh hey
<sinzui> I think so
<jml> we were talking about distro roles today
<jml> and I was reminded that bug nomination has a duplicated-but-different set of logic for checking if someone can upload a package.
<wgrant> Yeah.
<wgrant> I looked at refactoring that, but it is not as trivial as your method makes it look.
<jml> I got a vague sense of difficult-ness when looking at it today
<jml> wgrant: what are the issues?
<wgrant> jml: It has been a year. I don't quite recall, sorry.
<jml> fair enough :)
<wgrant> Let me look again.
<wgrant> But twice now I've gone to try to refactor it, then remembered the problem I encountered the previous time.
<jml> heh
<wgrant> It doesn't really jump out to me at the moment. But the BugNomination code will still have to work out the component and stuff itself.
<wgrant> And it's not obvious what to do about pockets.
<wgrant> sinzui: It looks like there are two places it might crash if we remove the primary archives: the queue view (which shouldn't be used anyway, and isn't linked), and the bug nomination stuff might as well.
 * wgrant tests on DF.
<sinzui> bugger
<sinzui> bug nomination code is so damn crifty
<sinzui> crufty
<wgrant> You clearly haven't seen Soyuz.
<sinzui> I have. But I was trying to write a bug nomination test last month and discovered that factory setups do not work because the code ignored the env. It uses launchbag
<mwhudson> is there any good reason (other than amount of work) that the launchbag can't be killed?
<wgrant> Yup.
<jml> wgrant: I think it might be OK to change the behaviour of the bug nomination code
<wgrant> mwhudson: It's pretty hard.
<jml> not sure though
<wgrant> mwhudson: Since vocabs use it.
<jml> wgrant: but my suspicion is that even if it doesn't do the same check now, it ought to be.
<mwhudson> wgrant: what for?
<mwhudson> current user should be got from the interaction
<wgrant> mwhudson: Bug nominations, for one thing!
<mwhudson> wgrant: hee
<wgrant> mwhudson: The nominatable series vocab checks launchbag for the distribution or product to look at.
<sinzui> I am all for removing launchbag. I favour completing the apocalypse first
<thumper> +1
<wgrant> sinzui: But the apocalypse is being reversed...
<sinzui> It took 4 years to remove general view
<sinzui> wgrant how so
<wgrant> sinzui: We split the codebase by app 18 months ago.
<wgrant> But a month ago we merged the app-split bugs.
<jml> different things
<jml> it's still one code base
<sinzui> wgrant: not the same
<jml> the apocalypse is about making it easier to navigate in the best way we could think of at the time
<jml> still makes sense to complete
<sinzui> the issue is about defining contracts and responsibilities in the code
<jml> btw
<jml> I also had a bit of a chat w/ cjwatson today about NewReleaseCycleProcess
<jml> remind me to talk about that next week
<jml> also, some people here might be interested in https://wiki.ubuntu.com/LaunchpadPermissions
<sinzui> jml: I sent a revised brain dump of my understanding to mrevell recently. I advised that each team lead look at the list because every time I think I have a definitive list, someone cites some obscure location in the code that provides another permission
<jml> sinzui: that's the advantage of having a shared, editable document :)
<sinzui> I also advised we ask reviewers to ask developers to update documentation when a permission is changed
<jml> sinzui: that's pretty hard to do
<sinzui> eg. bug nomination rules changed a few moths ago, and now we are getting Ubuntu questions about it
<sinzui> The document cited in this question cannot be changed by me: https://answers.launchpad.net/launchpad/+question/140509
<jml> sinzui: that's unfortunate, but it's no reason not to keep *a* document up to date
<sinzui> I agree. Collective code in the case requires a collective document
<jml> sinzui: also, the Ubuntu guys need to be able to figure out how to run their project. :)
 * spm asks jml how much he's prepared to pay to not get widely quoted on that one ;-)
<jml> spm: I will not be beholden to blackmailers.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (349): FIXED in 4 hr 48 min: https://hudson.wedontsleep.org/job/devel/349/
#launchpad-dev 2011-01-12
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (263): FIXED in 4 hr 47 min: https://hudson.wedontsleep.org/job/db-devel/263/
<huwshimi> Hi. I need someone to review a fix for bug #367877 if anyone is available.
<_mup_> Bug #367877: Tabbing between links does not highlight them <confusing-ui> <css> <lp-web> <Launchpad itself:Triaged> <kde4libs (Ubuntu):Invalid> < https://launchpad.net/bugs/367877 >
<jml> anyone doing Launchpad development in natty?
<wgrant> jml: Yes.
<jelmer> jml: yep
<wgrant> jml: It mostly works.
<wgrant> There are a couple of easy ways to make it work a little more, too.
<wgrant> But it
<wgrant> 's not perfect.
<jml> cool. ec2 land just errored on me.
<wgrant> Sure that's not the launchpadlib issue?
<jml> it is a launchpadlib issue. not sure about "the"
<wgrant> A NameError?
<jml> yeah
<jml> NameError: global name 'AuthorizeRequestTokenWithBrowser' is not defined
<wgrant> The.
<jelmer> same here
<jml> bugger.
<wgrant> Well, 'The' as in the original.
<wgrant> Pull devel.
<wgrant> Is fixed.
<wgrant> That doesn't mean it will work, though.
<jml> sweet.
<jml> well, baby steps.
<wgrant> Because the new launchpadlib has some... other issues.
<wgrant> You'll need to remake once you pull.
<jml> :(
<wgrant> But if your system is untainted by KDE you should be OK.
<jml> I have a lot of Qt stuff installed.
<jml> I guess the worse that can happen is that it fails.
<jml> beautiful
<jml> it oopsed
<jml> AttributeError: 'NoneType' object has no attribute 'is_reviewed'<br />
<jml> huwshimi: what's the MP url?
<wgrant> jml: Traceback?
<wgrant> That sounds almost like a celebrity issue.
<jml> wgrant: http://paste.ubuntu.com/553026/
<wgrant> Oh.
<wgrant> That is_reviewed.
<huwshimi> jml: Sorry, what's a MP?
<wgrant> Which test? There are some odd natty failures like that.
<jml> huwshimi: a merge proposal
<jml> huwshimi: after you've created a branch, you should create a merge proposal, which is a place to discuss the patch and the changes. there's a link on the branch page.
<jml> wgrant: uhh, there's no test involved.
<jml> wgrant: that was when I authorized my laptop
<wgrant> jml: Well, that is awesome.
<jml> wgrant: yeah, I'm going to file a bug.
<wgrant> jml: You might want to talk to relevant people first.
<wgrant> launchpadlib in LP hasn't really worked for a week or so now.
<wgrant> It may be known.
<huwshimi> jml: Yeah, I haven't created one yet... I didn't have a reviewer, but I can create it without filling that in if it helps.
<jml> wgrant: hmm.
<wgrant> I haven't seen that particular error before.
<jml> huwshimi: yeah. do that. there's a default reviewer which is the whole LP team
<jml> or the canonical part of it anyway
<huwshimi> jml: OK thanks.
<jml> wgrant: it's easy enough to mark bugs as invalid
<jml> wgrant: it also appeared to actually authorize
<huwshimi> jml: Target branch should just be lp:launchpad right?
<jml> huwshimi: yep
<jml> hmm
<wgrant> jml: Do any of your Product Strategies happen to include making Soyuz less broken, or deleting it or something?
<jml> wgrant: yes. derivative distributions.
<wgrant> They just stack more brokenness on the perilously stacked brokenness.
<jml> wgrant: that's an implementation approach
<jml> wgrant: an alternative approach is to use it as an opportunity to clean stuff before you add new things
<jml> which is entirely cromulent
<wgrant> jml: But there is no time :(
<jml> sod that
<jml> it's not true
<jml> there's no deadline
<wgrant> Perhaps this will change on Monday :)
<jml> and doing some cleanup will make the dev go faster
<wgrant> Long-term, sure.
<jml> even in the shorter term
<wgrant> But it's clear that nobody in Soyuz has ever though about long-term before :)
<huwshimi> jml: Here is the MP: https://code.launchpad.net/~huwshimi/launchpad/highlight-links-367877/+merge/45947
<wgrant> The rest of LP, I don't know.
<jml> if you're working on a feature for three or so months with even two or three people, that's long enough to make cleanup worthwhile
<jml> and it's not like Soyuz is going away
<wgrant> :(
<jml> I'm not saying that it should be made perfect before we add anything, but there's always time to do things right.
<jml> sinzui: you've done a lot of stuff w/ our CSS before, interested in reviewing huwshimi's change? https://code.launchpad.net/~huwshimi/launchpad/highlight-links-367877/+merge/45947
<jml> huwshimi: oh, I forgot about #launchpad-reviews
<jml> huwshimi: that's another place to ask for reviews
<huwshimi> jml: ok should I head over there and ask now then?
<jml> huwshimi: although I personally prefer here, because I'm not sure what a dev channel is for other than discussing code changes :)
<jml> huwshimi: sure.
<wgrant> jml: How goes the rally?
<jml> wgrant: pretty well.
<jml> wgrant: it's not as talk-y as UDS, so less of me doing the listening part of my job, but it's still good to be here.
<thumper> jml: I don't suppose you can see bigjools
<huwshimi> jml: When asking for a review is the MP the most important bit of information to provide?
<jml> thumper: not from here. I think he's in the UK.
<jml> huwshimi: yeah.
<thumper> huwshimi: as long as the MP has a decent description
<wgrant> thumper: bigjools is asleep.
<thumper> wgrant: ah
<thumper> ok
<wgrant> thumper: What's up?
<thumper> wgrant: I was going to get him to look at my changes for the builds' urls
<thumper> wgrant: I implemented his suggestion
<thumper> so it seems only fair that he reviews it :)
 * thumper goes to add him on the MP
<jml> thumper: while you're here, can I interest you in reviewing huwshimi's branch?
<thumper> the css one above?
<wgrant> thumper: Ah, right.
 * jml really needs to go get food
<jml> thumper: yeah.
<wgrant> thumper: He disappeared about an hour ago.
<thumper> I'm not a ui reviewer
<huwshimi> thumper: OK thanks
<jml> thumper: does that still matter?
<thumper> for UI stuff?
<thumper> perhaps not
 * jml doesn't know
<lifeless> wgrant: cleanup++
<jml> thumper: if there's no UI reviewer in asiapac, and we're going to block UI branches on UI reviewers, then I guess I have a new problem to solve :)
<lifeless> I would like to unblock that
<jml> crisistunity!
 * thumper recommends one or two aussies do it
<wgrant> There are lots of us now!
 * jml reviews
<wgrant> lifeless: The problem is that there is so much cleanup that needs doing, and a lot of it isn't a drive-by sort of thing. :(
<jml> huwshimi: did you make some whitespace changes?
<jml> huwshimi: anyway, it's good to land as far as I'm concerned.
<jml> huwshimi: I've got to head, but if you need help figuring out how to land it, I'm sure either your fellow Aussie colleagues or our fine friends across the Tasman will be able to help.
<huwshimi> jml: No I just noticed those in the diff too. The strange thing is the CSS is not indented in those files.
<huwshimi> jml: Thanks, have a good night
<jml> will do.
 * jml out
<huwshimi> Hi. Is anyone around who can explain how I land a branch for Launchpad? I have an approved MP.
<wgrant> huwshimi: Because the test suite takes so long, we normally run it on Amazon EC2. See https://dev.launchpad.net/EC2Test for setup and usage details.
<wgrant> huwshimi: ec2test automatically lands the branch when it's done.
<wgrant> Although you might not have PQM access yet.
<wgrant> Do you know if you do?
<huwshimi> wgrant: Thanks. I don't know.
<spm> he does not
<lifeless> there is / was a starter document that explained what you need to do to get that
<lifeless> oh hai
<spm> lifeless: while you're here - how does the qastaging DB get updated? is that a manual only thing? or is it wrapped up in a place I've not yet looked?
<lifeless> spm: should happen when staging is updated
<spm> ahh. I assumed it wasn't. ta.
<wgrant> Note that the last full staging restore failed, so it's been a while.
<lifeless> spm: original concept was - copy over, restore to one, run patches, restore to other.
<lifeless> spm: as to what scripts etc - I have -no- idea, no visibility at all.
<spm> https://code.edge.launchpad.net/~canonical-losas/lp-staging-scripts/trunk
<spm> be ware. eyeballs may explode.
<lifeless> spm: s/edge.// in your history, plox.
<lifeless> spm: also, when doth that redirect kick in?
<spm> yeah. just old urls in quick search :-)
<spm> I was hoping to get it done yesterday, but dragged awy. likewise today. :-/
 * lifeless offers superglue for the fingers
<lifeless> spm: bug 457026
<_mup_> Bug #457026: bzrsyncd on loganberry using unnecessary amounts of /tmp space <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/457026 >
<lifeless> is that still happening?
<wgrant> StevenK: The WTFery may be continuing. http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ shows that the .debs are gone, but some of the .udebs remain. p-d-r logs say they were removed, and it finished before the mirroring started... can you check if pool/main/l/linux/acpi-modules-2.6.24-28-386-di_2.6.24-28.83_i386.udeb is still on cocoplum?
<spm> lifeless: yes
<lifeless> spm: even though we've removed the mirrored area?
<spm> lifeless: ? isn't the mirrored area on crowberry?
<lifeless> we got rid of having a mirrored area
<lifeless> oh right
<lifeless> I gets it
<spm> https://pastebin.canonical.com/41796/
<spm> just an extract. not the full thing.
<lifeless> bumped to high
<spm> ta
<lifeless> flacoste: hi
<lifeless> flacoste: if you're still around, who wrote trac-launchpad-migrator ?
<wgrant> Wasn't it Fluendo?
<lifeless> gmb
<lifeless> https://code.launchpad.net/~launchpad/trac-launchpad-migrator/trunk
<wgrant> The VCS history isn't reliable.
<wgrant> It wasn't originally in that branch.
<wgrant> Although the copyright headers could be useful.
 * wgrant checks.
<wgrant> http://bazaar.launchpad.net/~launchpad/trac-launchpad-migrator/trunk/annotate/head:/migrate.py
<wgrant> Fluendo.
<lifeless> ah
<lifeless> thanks
<lifeless> wgrant: perhaps you have an opinion on https://bugs.launchpad.net/trac-launchpad-migrator/+bug/461669, since you seem to know some history
<_mup_> Bug #461669: Attachments are looked for in the wrong directory <trac-launchpad-migrator:Triaged> < https://launchpad.net/bugs/461669 >
<lifeless> jelmer: ^
<huwshimi> wgrant: Just setting up ec2test and at this part https://dev.launchpad.net/EC2Test#setup it talks about setting up my own developer account etc. I assume that's all relevant to me?
<wgrant> lifeless: I think that might require some Trac knowledge, and I haven't admin'd a Trac instance in like 5 years. I'm probably not the best person to ask.
<wgrant> huwshimi: Yeah.
<wgrant> huwshimi: You need an AWS account.
<huwshimi> wgrant: Thanks
<lifeless> wgrant: can you expand on whats up in bug 438336 ?
<_mup_> Bug #438336: Packages still show up on builders page after they are done <lp-soyuz> <soyuz-build> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/438336 >
<wgrant> lifeless: Bug #438336
<_mup_> Bug #438336: Packages still show up on builders page after they are done <lp-soyuz> <soyuz-build> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/438336 >
<lifeless> thanks
<lifeless> spm: in bug 431235 - we're now running HA loggerhead, do you know if its single-source-tree or not ?
<_mup_> Bug #431235: Allow us to run multiple loggerhead instances from the same codetree <canonical-losa-lp> <launchpad-loggerhead:New> < https://launchpad.net/bugs/431235 >
<spm> separate tree
<spm> trees
<maxb> I can't see bug 431235 :-/
<_mup_> Bug #431235: Allow us to run concurrent loggerhead instances from the same codetree <canonical-losa-lp> <launchpad-loggerhead:Triaged> < https://launchpad.net/bugs/431235 >
<maxb> probably because it's bugtask is targetted to a deactivated project
 * cody-somerville hugs lifeless 
<lifeless> maxb: fixed
<lifeless> maxb: and the 5 other ones similarly
<lifeless> cody-somerville: thanks?
<cody-somerville> lifeless, You're welcome. :-)
<lifeless> james_w: bug 395200
<_mup_> Bug #395200: Allow linking a package upload to a bzr revision <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/395200 >
<lifeless> jml: ping
<lifeless> spm: hi
<spm> yo
<lifeless> spm: can you please change the maintainer of https://launchpad.net/qa-tagger to be ~launchpad ?
<spm> lifeless: done
<lifeless> thanks
<lifeless> matsubara-afk: https://bugs.launchpad.net/oops-tools/+bug/701762
<_mup_> Bug #701762: "No Production OOPSes found for 2011-01-11. " <OOPS Tools:New> < https://launchpad.net/bugs/701762 >
<lifeless> .
<lifeless> spm: is bug 660854 still present?
<_mup_> Bug #660854: importds are spamming log messages <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/660854 >
<lifeless> that was in the early days of the new logging stuff, it may be good now? /me hopes
<poolie> is bug 556132 now available for testing on staging or qastaging?
<_mup_> Bug #556132: bzr: ERROR: paramiko.SSHException:  Key-exchange timed out; consistent after sending 1GB data <lp-code> <paramiko> <qa-ok> <Bazaar:Invalid> <Launchpad itself:Fix Committed by mwhudson> <Twisted:Fix Released> < https://launchpad.net/bugs/556132 >
<lifeless> you can check by looking at the MP to see what rev in devel it got, and at the revno on the qastaging pages
<wgrant> lifeless: Hi.
<lifeless> hi
<wgrant> lifeless: I need a memoization decorator. Do we have one that I'm missing, or should I create a PropertyCache-based one?
<lifeless> what for
<wgrant> lifeless: Archive.getComponentsForSeries.
<lifeless> and how is that different to just @cachedproperty
<wgrant> @cachedproperty doesn't do arguments.
<lifeless> ah
<lifeless> you could fix that
<wgrant> It turns a method into a property, though.
<lifeless> true that
<lifeless> refactor and reuse
<wgrant> That was my plan.
<lifeless> no, I don't think we have a canned one
<wgrant> Thanks.
<wgrant> Seems odd.
<lifeless> and we'd want cache clearing so using PC is appropriate
<wgrant> But I guess performance wasn't much of a concern until recently.
<wgrant> Yep.
<lifeless> we have a list-memoiser and odd bespoke bits like that
<lifeless> wgrant: I'm curious why you need to memoise gCFS
<lifeless> but am too tired and buggered to understand the answer today.
<wgrant> lifeless: We want to do a component check during copies.
<wgrant> To make sure we're not creating invalid publications.
<lifeless> sure
<lifeless> I've found previously that making the whole thing more set based is generally a bigger win than caching at points
<wgrant> Possibly, yes.
<lifeless> see e.g. the stuff I did to Archive:+index
<wgrant> But it's not clear how best to encapsulate this in a set-based approach.
<lifeless> I encourage you to examine the changes I did there for inspiration
<wgrant> Set-based would be nice.
<wgrant> But it requires a restructure of the publisher and copiers.
<wgrant> All the way up.
<wgrant> Mmm, I suppose I could see how just setifying the lower parts works.
<wgrant> It's not going to be great, though :/
<lifeless> wgrant: well thats how we get set based in the entire stack
<lifeless> wgrant: one little bit, then add more, then more etc
<lifeless> wgrant: otherwise the *best* we can achieve is that we only do one just-in-time lookup per left-hand object
<lifeless> wgrant: which frankly still sucks
<huwshimi> wgrant: Before you were saying about needing PQM access. Any ideas about how to get it? I couldn't find anything (also apologies for all the hassling).
<wgrant> lifeless: You have convinced me to rework most of it :(
<wgrant> huwshimi: "all the"? You exaggerate.
<wgrant> huwshimi: But as for PQM access, an RT ticket to the Launchpad queue should do it.
<wgrant> Let me find the email address...
<huwshimi> wgrant: Thanks mate :)
<wgrant> huwshimi: A signed email to launchpad@rt.canonical.com  with your public OpenPGP key attached.
<wgrant> And then possibly a couple of pokes thrown in spm's direction to expedite processing :P
<lifeless> don't forget to use the magic words
<huwshimi> wgrant: Ah well I've already sent one of them... I guess on to the poking.
<huwshimi> Oh actually I haven't sent one to that address
<wgrant> Just ask to be added to the LP PQM keyring.
<lifeless> and config file
<lifeless> it should be all documented on rocketfuel setup in the internal wiki
<lifeless> poolie: https://bugs.launchpad.net/launchpad/+bug/701186
<spm> yeah. use the magic word. I don't do nuffin without the magic word.
<lifeless> jml: please refine the importance on https://bugs.launchpad.net/launchpad/+bug/695606
<_mup_> Bug #695606: recipes shouldn't build if a build was triggered by hand for the set PPA and nothing has changed <Launchpad itself:New> < https://launchpad.net/bugs/695606 >
<spm> <lifeless> spm: is bug 660854 still present? <== yes
<_mup_> Bug #660854: importds are spamming log messages <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/660854 >
<spm> ugh. we're not compressing/rotating the spew log that's collecting those.
<lifeless> sinzui: hi
<lifeless> actually
<lifeless> yeah sinzui - https://bugs.launchpad.net/launchpad/+bug/697364 - maybe you have a hunch ?
<_mup_> Bug #697364: pop up diff display (e.g. in bug pages) of merge proposal exceeds entire window and is not scrollable (css brain damage) <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697364 >
<wgrant> lifeless: Timing suggests the YUI upgrade.
<lifeless> Would not suprise me
<wgrant> I think the tag autocompleter glitch is also that.
<wgrant> But it may just be a Chromium dev build thing.
<lifeless> the bug above I can reproduce
<lifeless> tag autcompleter on mav chrome is -fine-
<lifeless> spm: please change the maintainer on https://launchpad.net/lp-qa-tools too
<spm> done
<lifeless> thanks!
<lifeless> maxb: is bug 663195 common ?
<_mup_> Bug #663195: CVS import fails for b2evolution project: cscvs.cmds.totla.ValidationFailed: directories differ <Launchpad CSCVS:Triaged> < https://launchpad.net/bugs/663195 >
<lifeless> \o/ no NEW bugs
<lifeless> bah, 2 NEW bugs.
<lifeless> nearly-no.
<maxb> lifeless: no idea, I'm afraid - generally I try to avoid looking at cscvs :-)
<lifeless> :)
 * huwshimi is done for the day
<adeuring> good morning
<matsubara> lifeless, thanks. I'll look into it
<gmb> deryck: Do you have a second to run a query on staging for me?
<deryck> gmb, definitely
<gmb> deryck: https://pastebin.canonical.com/41807/, please. I'm trying to get to the bottom of bug 700490
<_mup_> Bug #700490: Incorrect email address presented when merging accounts <Launchpad itself:Incomplete> < https://launchpad.net/bugs/700490 >
<deryck> gmb, no results.
<gmb> deryck: Probably the staging db was too out of date. Okay, thanks.
<deryck> gmb, np.  sorry it wasn't much help.
<gmb> deryck: Out of interest, can you just try https://pastebin.canonical.com/41808/.
<deryck> sure
<deryck> gmb, 3278 rows.  Would you like to see them?
<gmb> deryck: Sure.
<deryck> gmb, https://pastebin.canonical.com/41809/
<gmb> deryck: Ta
<deryck> np
<henninge> jtv: what's up with your system/connection?
<jtv> Something with the wireless router, I think.
<bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell
<bac> : meeting ping
<jtv> ack thx
<adeuring> thanks
<gary_poster> thanks
<mrevell> me
<mrevell> heh
<jml> hmm
<jml> the ec2 land run I submitted last night passed, but did not submit to PQM
<jml> mrevell: good morning :)
<mrevell> Hey there jml
<bigjools> jml: pqm is borked, I'm discussing it with mthaddon
<bigjools> you might be able to help, it's failing when importing testtools
<jml> bigjools: oh, that sucks. but that doesn't explain why ec2 land didn't even *try* to send to PQM
<bigjools> oh, seems awfully coincident, are you sure?
<jml> oh, no, my bad.
<jml> SUBMITTED TO PQM:
<jml> [r=jml][ui=none][no-qa] Upgrade to testtools 0.9.8 final
<jml> however, that might be even more co-incident.
<bigjools> haq
<jml> bigjools: where are the details of the current PQM issue
<bigjools> jml: https://pastebin.canonical.com/41803/
<lifeless> needs losa intervention
<mthaddon> lifeless: of what kind? I installed python-testtools (why is it suddenly needed?) and then we got a subunit import error
<lifeless> mthaddon: will need subunit as well
<lifeless> mthaddon: spm upgraded the pqm version on prase last week
<mthaddon> lifeless: but we've had successful submissions since then, no?
<mthaddon> lifeless: python-subunit ?
<lifeless> mthaddon: I wouldn't expect so
<mthaddon> lifeless: logs suggest we had one about 12 hours ago, but anyway... I can install python-subunit
<sinzui> rockstar: make me an admin so that I can add new members https://launchpad.net/~launchpad-ui-reviewers/+members
<mthaddon> lifeless, bigjools: ok, python-subunit installed - bigjools, can you try a resubmit?
<lifeless> mthaddon: thanks
<bigjools> ok
<bigjools> iz sent
<lifeless> flacoste: we're triaged https://bugs.launchpad.net/launchpad-project/+bugs?search=Search&field.status=New !
<lifeless> flacoste: should I update the bug triage wiki page per my proposal ?
<flacoste> lifeless: thanks a lot!
<lifeless> flacoste: or do you want to wait for the epic? It didn't seem to be as hot a topic as you thought it might be
<flacoste> lifeless: yeah, i was surprised by that
<lifeless> deryck: would love your input on bug 120357
<_mup_> Bug #120357: Improve the accept/decline/nochange column on +nominations <lp-bugs> <Launchpad itself:New> < https://launchpad.net/bugs/120357 >
<flacoste> i wonder if it's because people are in agreement
<flacoste> lifeless: but do update it, we can always refine it later
<lifeless> kk
<deryck> lifeless, ok, I'll take a look.
<lifeless> deryck: thanks!
<mars> bac, so this is what you were talking about for the Thunderdome? http://www.theweathernetwork.com/your_weather/details/620/2190343/4/ustx0327/plpcities/
<mars> bac, oops, that was posted in March! nevermind
<bac> mars: i'm sure you'll not even think it is chilly
<mars> According to the Weather Network the forecast is 19F with 9F after windchill - that is not fun for a sweater
<mars> I didn't know you even had weather like that so far south
 * gary_poster knew someone who (my wife reports, as roommate) used to open the bathroom window in January after a shower, living in Rochester NY.  She was from Minnesota.  *She* wouldn't think it was chilly.
<jcsackett> mars: it's a shorter winter, but it's still a nasty one in dallas. dallas is in the more northern, wetter part of texas.
<sinzui> mars: Some of us believe the planners of the platform assumed Texas is always hot
<mars> lol
<mars> sinzui, it appears I am guilty of such as well
 * sinzui was hoping for Cancun.
<flacoste> sinzui: you need to bribe marianna
<sinzui> she can come
<flacoste> for next year
<flacoste> oh, she's there all right
<lifeless> flacoste: NZ! :)
<flacoste> lifeless: getting 300 people to NZ isn't very cost effective :-/
<lifeless> flacoste: depends on hotel rates surely ;P
<sinzui> Hawaii (big island) is nice
<deryck> lifeless, so that bug is still relevant.  quite an ugly page and set of controls.
<deryck> lifeless, you just want an ack from me, or some other ideas, or something else?
<lifeless> deryck: if you could triage it (following the shiny new https://dev.launchpad.net/BugTriage) that would be awesome
<deryck> lifeless, ah, ok.  sure.
<lifeless> deryck: I didn't know enough to assess it
<deryck> gotchas
<lifeless> gmb: hey
<gmb> lifeless: Hi.
<lifeless> gmb: curtis and I have pinged for your input in a few bugs recently
<lifeless> I'm wondering if you could make some time to help us out
<gmb> lifeless: I've only seen yours today, to which I've responded (and I'm trying to write a test for it).
<gmb> lifeless: Which other ones did you need input on?
<lifeless> flacoste: will you do the defn-of-critical -> defn-of-incident stuff ?
<lifeless> gmb: I will have a squiz through the incomplete bugs to find them for you
<gmb> lifeless: Thanks. I'll check that my mail filters haven't been swallowing things they shouldn't whilst you look.
<lifeless> gmb: it may be the grey filter
<sinzui> gmb: you responded to the bug about @users.sourceforge.net. Since I confirmed the address does not exist in staging, we do not know how this could happen
<leonardr> james_w, quick question
<leonardr> as you know, we'd like to put launchpadlib 1.9.2 into natty
<leonardr> 1.9.2 depends on python-keyring 0.5
<gmb> sinzui: Yeah, I've no clue. I do wonder if we've not got an entirely accurate story here, but I so far haven't been able to reproduce it by mucking about locally.
<leonardr> the current version is 0.2. it's a debian package, and debian is frozen right now
<benji> (leonardr: actually it'd be best if it were launchpadlib 1.9.3 and keyring 0.5.1, but that's just a detail)
<leonardr> if we got python-keyring 0.5 into debian experimental, would we then be able to get it imported into ubuntu?
<flacoste> lifeless: sure, i can do that
<gmb> sinzui, lifeless: Just found the message about bug 257940. My filters obviously didn't deem it important enough to bother me with ;)
<_mup_> Bug #257940: Bug description doesn't get checked for remote bug links <bridging-the-gap> <bugwatch> <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/257940 >
<lifeless> gary_poster: have you seen anything like bug 696134 ?
<_mup_> Bug #696134: python-lazr.delegates causes 'No module named restfulclient.errors' from apport-bug <lucid> <Apport:New> <lazr.delegates:Incomplete> <lazr.delegates (Ubuntu):New> < https://launchpad.net/bugs/696134 >
<sinzui> gmb: I mark all bug mail generated by myself as waste. I don't blame you.
<flacoste> lifeless: should we work on a query to upgrade all timeout/oops/regression bugs to 'Critical'?
<gmb> sinzui, lifeless: I need to step out for a bit to collect my wife from work; ping me with any more bug IDs that I might have missed and I'll take a look when I get back.
<lifeless> flacoste: I was just going to JFDI it
<lifeless> flacoste: act as a mini-audit at the same time
<flacoste> lifeless: fine by me
<lifeless> gmb: have a look at the 'incomplete' list
<gmb> lifeless: Okay, will do.
<lifeless> gmb: its ~ 60 bugs and worth an eyeball
<gmb> lifeless: Sounds like a good way to end my day.
<gmb> Anyway; bbiaw.
 * gmb -> exeunt in pursuit of a redhead.
<lifeless> ooo
<gary_poster> lifeless, I haven't seen that before, and don't have an immediate idea after looking at the logs for that and the related bug.
<gary_poster> if it truly is lazr.restfulclient.errors with the problem, and not merely lazr.restfulclient, then that might indicate a packaging problem (not including __init__.py, say; otherwise, if it is a problem with lazr.restfulclient, it might be another namespace-packages-are-fragile bug.
<gary_poster> both of those are just random guesses though
<lifeless> Ursinha: do my comments in bug 701966 make sense to you ?
<_mup_> Bug #701966: None: None OOPS with various scripts <oops> <Launchpad itself:Invalid> < https://launchpad.net/bugs/701966 >
<Ursinha> whoa, let me see
<lifeless> Ursinha: also, I've just mailed the list saying that the new triage rules are in effect - we can all triage when filing bugs now
<Ursinha> right, ok, makes sense
<james_w> leonardr, that would be one way. We could go directly to Ubuntu as well.
<james_w> leonardr, I just realised that we should talk to barry about this, as he maintains the launchpadlib packages in Debian now
<james_w> leonardr, I can find him later to discuss it if you like
<leonardr> james_w, that would be great
 * leonardr also needs to talk to barry for an unrelated reason
<Ursinha> lifeless, I'm not triaging while I'm filing because I don't know the severity of the oopses or if they're false alarms. I'm filing bugs for all oopses I found and asking people about them, trying not to lose track of the oopses in a first moment
<lifeless> Ursinha: per zero-oops-policy they are critical
<james_w> lifeless, I'm going to discuss having estimation on blueprints as well with mounir later, so don't worry about it in the LEP for now
<lifeless> flacoste: I've updated z-o-p for squads, could you check I got it as you would have put it?
<lifeless> james_w: ok
<lifeless> james_w: thanks for letting me know
<flacoste> lifeless: z-o-p?
<lifeless> flacoste: zero oops policy
<lifeless> https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy
<flacoste> yeah, just got that
<flacoste> lifeless: fine, i brought back the respecting the w-i-p limit note, but worded it for the new context
<lifeless> flacoste: cool thanks
<lifeless> flacoste: I wasn't sure how to put it, appreciate you doing htat
<flacoste> lifeless: i'll make the relevant updates to the Kanban itself, since Critical bugs aren't 'Expedite' class-of-service anymore
<lifeless> cool
<lifeless> Thanks
<lifeless> I think I have a TODO of writing up done-is-when-deployed
<lifeless> that we were waiting for something to unblock/do. Do you remember what that was?
<gary_poster> lifeless: could you please take a look at my last comment in https://bugs.launchpad.net/lazr.restfulclient/+bug/380504 and add your suggestion/clarification as appropriate?  No rush, and if you'd prefer an email just ask.
<_mup_> Bug #380504: Handle HTTP Error 502: Bad Gateway automatically <canonical-losa-lp> <lp-foundations> <Launchpad itself:Invalid> <lazr.restfulclient:Fix Released by leonardr> < https://launchpad.net/bugs/380504 >
 * gary_poster should have searched for HAProxy in LP bugs
<gary_poster> doing that now
<gary_poster> lifeless: nm
<lifeless> gary_poster: I hope my reply is helpful
<gary_poster> lifeless: thanks.  So, actually...
<gary_poster> https://bugs.launchpad.net/launchpad/+bug/636713
<_mup_> Bug #636713: during sustained overload situation replies are truncated in production <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/636713 >
<gary_poster> which is similar
<gary_poster> and bug 640065
<_mup_> Bug #640065: appserver deployment must not interrupt live requests <lp-foundations> <rfwtad> <Launchpad itself:Triaged> < https://launchpad.net/bugs/640065 >
<lifeless> yeah
<lifeless> the 065 one is the one I split out
<gary_poster> but neither of those describe/explain the symptoms in that bug--daily 502s
<gary_poster> the HAproxy hypothesis might explain that
<gary_poster> you object to another bug?
 * gary_poster needs to get on another call but will be back
<lifeless> gary_poster: I'm fine with another bug; personally I think its the rollouts still : interrupted live requests show up as 502's
<gary_poster> daily 502s back before continuous deployment though?
<gary_poster> ok, will file
<lifeless> yes
<gary_poster> thanks
<lifeless> on *edge*
<gary_poster> no,
<gary_poster> bryce reports on prod
<lifeless> ah
<lifeless> actually yes
<lifeless> we do log rotation daily
<lifeless> IIRC that involves a stop-start sequence
<lifeless> lets talk when you're not also on a call
<jml> "Installing Twisted 10.2.0-4395fix Caused installation of a distribution: Twisted 10.2.0 with a different version."
<jml> What am I doing wrong?
<lifeless> the setup.py version does not match the one lp's setup.py/versions.cfg expects
<lifeless> same issue we had with testtools snapshots
<jml> mwhudson: did you have to change something in the Twisted tarball for the 4395 fix, other than applying the patch
<jml> mwhudson: because I can't see an obvious version change
<lifeless> gary_poster: ah, its sigusr2; now I need to read up on what that does.
<gary_poster> does not restart pretty sure
<mwhudson> jml: i hacked the setup.py :/
<gary_poster> theres a distribute or setuptools approach to that; can download after call if desired
<gary_poster> lifeless, also I believe bryce reported that times were not consistent
<lifeless> gary_poster: ok, given those two things we definitely need to keep looking
<gary_poster> cool, will file bug after call
<lifeless> gary_poster: we have been overcapacity routinely - its yet another reason I want to get the single threaded appserver stuff done
<gary_poster> ack, yeah
<lifeless> gary_poster: is bug 438802 perhaps fix released in lazr.restful ?
<_mup_> Bug #438802: UnicodeDecodeError changing 'Assigned to' field when summary contains non-ascii <lp-bugs> <oops> <post-3-ui-cleanup> <ui> <Launchpad itself:Fix Released by intellectronica> <lazr.restful:Fix Committed by intellectronica> < https://launchpad.net/bugs/438802 >
<gary_poster> lifeless: yes, changes, thanks
<gary_poster> changed
<lifeless> poolie: bug 585126 - if we could reduce memory on that that would be very helpful
<_mup_> Bug #585126: sendbranchmail with lp:~vcs-imports/linux/trunk is eating memory <canonical-losa-lp> <lp-code> <oops> <Bazaar:Confirmed> <Launchpad itself:Triaged by thumper> < https://launchpad.net/bugs/585126 >
<lifeless> gary_poster: what about bug 488762
<_mup_> Bug #488762: SnapShot OOPS editing team with 13000 members <lp-foundations> <lp-registry> <oops> <Launchpad itself:Invalid by bac> <lazr.lifecycle:Fix Committed by bac> < https://launchpad.net/bugs/488762 >
<gary_poster> released, changed, lifeless
<lifeless> thanks
<lifeless> bigjools: what machine does bug 694004 need to be deployed to ?
<_mup_> Bug #694004: PPA Apache log parser needs to exclude error logs <lp-soyuz> <oops> <qa-ok> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/694004 >
<StevenK> lifeless: germanium
<lifeless> thanks
<StevenK> PPA == germanium always
<poolie> lifeless, heh I read that as <Launchpad eating itself:...>
<lifeless> \o/
<jml> mwhudson: ok, thanks.
<mwhudson> jml: are you upgrading to 10.2?
<jml> mwhudson: indeed.
<mwhudson> jml: \o/
<mwhudson> jml: sorry for making your life more difficult
<jml> mwhudson: that's ok. :)
<bigjools> lifeless: sorry missed your msg, but I see it was answered
<lifeless> bigjools: de nada
<StevenK> I'm helpful. Sometimes.
<bigjools> lifeless: the lack of nodowntime for germanium prevented that fix going out quicker :/
<lifeless> bigjools: yeah
<bigjools> my oopses are swamped until it's landed
<bigjools> anyway I have to go, g'night all
<lifeless> bigjools: I think we're < 24 hours away now, but it should be simple: mail mrevell to get a downtime slot, and request a deploy to match
<bigjools> lifeless: it was hardly worth it with the release coming up otherwise I would have
<bigjools> anyway.... gone
<lifeless> ciao!
<StevenK> lifeless: So, are you available for an idea?
<lifeless> yes
<StevenK> lifeless: Which room are you in?
<lifeless> hallway
<StevenK> Which floor?
<lifeless> 3
<StevenK> Okay
<lifeless> gary_poster: were you aware of bug 416268 ?
<_mup_> Bug #416268: application server core dump <canonical-losa-lp> <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/416268 >
<gary_poster> lifeless: had seen.  did not repeat.
<lifeless> righto, oops + timeout + regressions rescored to critical
<StevenK> Yes, you amused kees
<lifeless> pcjc2: hi
<lifeless> pcjc2: are you interested in doing a patch for that tag issue?
<lifeless> pcjc2: also, have we grabbed a contributor agreement from you ?
<jml> poolie: https://dev.launchpad.net/LEP/WebservicePerformance ; https://dev.launchpad.net/LEP/WebservicePerformance/ClientSyntax ; https://dev.launchpad.net/Foundations/Webservice/ProposalQnA
<leonardr> sinzui, i need some xslt help
<sinzui> hi
<leonardr> i'm trying to modify this expression:
<leonardr>  <xsl:for-each select="key('id', 'service-root-json')/wadl:param/wadl:link">
<leonardr> (this is in wadl-to-refhtml.xsl in case you didn't guess)
<leonardr> that select is getting an object i want to leave out. my two questions are 1) how do i avoid processing it or change the select to say "only get links with property x"
<leonardr> and 2) how do i implement a check for property x in xslt
 * sinzui thinks
 * sinzui still thinking
<pcjc2> @ lifeless - yes I'll do the patch, and I've already signed the contrib agreement
<sinzui> leonardr I see we have an xsl:if and xsl:choose constructs in some of these uses. Which use or object are your trying to avoid
<leonardr> sinzui: i'd like to avoid param/link tags unless param['name'] ends with '_collection_link'
<sinzui> leonardr: okay, that helps
<sinzui> damn
<sinzui> leonardr: I just lost my history. please repeat the path and the rule to exlude :(
<leonardr> sinzui: sure
<leonardr> <xsl:for-each select="key('id', 'service-root-json')/wadl:param/wadl:link">
<leonardr> i want to include only those where the wadl:param tag has a name attribute ending in '_collection_link'
<sinzui> thanks
<sinzui> leonardr: are we using sn EXSLT enabled engine?
<leonardr> sinzui: i'll check. i think we are using xsltproc
<leonardr> sinzui: if push comes to shove we can explicitly exclude a single item
<sinzui> yes we are thanks.
 * sinzui thinks more
<sinzui> leonardr: we have several examples in foreach that use xsl:if or xsl:choose to exclude output. But I do not see how to exclude by a fragment of an attribute name
<sinzui> leonardr: we might do this if the attr's content is easy to test. I do not think collection links (urls) look different from entry objects though
<leonardr> sinzui: the urls themselves don't look different, no
<jml> gmb: may I join ~malone-alpha?
<jcsackett> leonardr, can i get you to take a quick look at a branch with an eye towards seeing if it breaks API compatability?
<leonardr> jcsackett, sure
<jcsackett> thanks, leonardr: https://code.launchpad.net/~jcsackett/launchpad/shortlist-696913
<thumper> lifeless: oops 1837REPORTIFSEEN381
<StevenK> What prefix is that for?
<gmb> jml: I think it can be arranged, yes.
<leonardr> jcsackett: when an entry is changed, we take a snapshot before making the change, and send the snapshot along with the new object in an ObjectModifiedEvent
<thumper> StevenK: something that shouldn't be running I think
<leonardr> so that anyone who cares about the change can see what changed
<leonardr> afaik that's the only place where lazr.restful uses snapshots
<thumper> StevenK: I saw lifeless update the oops prefixes in a config branch at the end of last week
<leonardr> and you can't change a collection field
<leonardr> so unless i'm missing something, this should not change the behavior of the web service
<jcsackett> leonardr: that's what i thought. a review on that branch raised the question though, and i wasn't sure. thanks.
<gmb> jml: Done
<lifeless> StevenK: see the production launchpad-lazr.conf for an answer
<flacoste> jml: why did you remove the link to the bug tags from the LEP template?%
<sinzui> leonardr: jcsackett: I am thinking something like this, yet valid: <xsl:for-each
<sinzui>   select="key('id', 'service-root-json')/wadl:Param/wadl:link[
<sinzui>     contains(local-name(@*), '_collection_link']">
<lifeless> flacoste: there were two links
<leonardr> sinzui: ok, why is that invalid?
<sinzui> leonardr: local-name() can return the name of an attr
<flacoste> lifeless: i see, the 'On Launchpad' bit
<sinzui> leonardr: I do not think I can pass a node-set to local-name()
<leonardr> sinzui: as a possible punt, can you give me a syntax for excluding wadl:link[not contains(resource_type, 'person')]?
<lifeless> jml: https://dev.launchpad.net/LEP/EffortEstimation
<sinzui> leonardr: I see local-name does except a node-set
<sinzui> it might be valid
<leonardr> ok, let me try it
<lifeless> james_w: ^
<leonardr> sinzui: that filters out every single top-level object
<sinzui> :(
<jml> gmb: thanks
<jml> gmb: btw, maybe make it a moderated team?
<gmb> jml: I just clicked save as you pinged me.
<gmb> Great minds
<gmb> (and mine)
<gmb> Occasionally think alike
<jcsackett> leonardr, sinzui: are we using xslt 1.0 or 2.0?
<leonardr> jcsackett: the stylesheet says 1.0
<jcsackett> damn. 2.0 gives us fn:ends-with.
<jcsackett> which seemed perfect.
<leonardr> the problem is less ends-with and more identifying the part of the tag that needs to be filtered
<pcjc2> lifeless?
<jcsackett> leonardr: right, but if you can assert name() ended with _collection_link, that would be your filter expression, wouldn't it?
<leonardr> jcsackett: you mean something like this?
<leonardr>  /wadl:param[endswith(@name, "_collection_link")]/wadl:link?
<leonardr> would that work?
<jcsackett> if we had xslt 2.0 available--i don't think we do. but i think maybe substring could work?
<jcsackett> wald:param[substring(name(), string-length(name()) - 15) = '_collection_link'] ?
<jcsackett> leonardr ^
<jcsackett> farfetched, but maybe?
<leonardr> my question is whether we can stuff a conditional in the middle of the select
<leonardr> i'll try it
<sinzui> jcsackett: leonardr: can either of you fix this syntax to ensure we call contains for every attribute [@*/contains(local-name(), '_collection_link']
<leonardr> sinzui: i need to see the whole expression in context. what is that being applied to? the wadl:link?
* jml changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 4 | PQM is open | RM: jcsackett | firefighting: build is broken | Get the code: https:/â/âdev.launchpad.net/âGetting
<jml> hey
<sinzui> key('id', 'service-root-json')/wadl:Param/wadl:link[@*/contains(local-name(), '_collection_link']
<jml> the build is broken, could someone please fix it? I'm not available right now
<StevenK> jml: In devel? Lookerating
<jml> StevenK: thanks.
<lifeless> pcjc2: hi
<lifeless> pcjc2: sorry, lots of interrupts here, was just talking SANs
<leonardr> sinzui: no idea. do you know why this doesn't select anything?
<pcjc2> hi - just coding up the patch for tags
<lifeless> pcjc2: cool
<leonardr> select="key('id', 'service-root-json')/wadl:param[contains(@resource_type, '_collection_link')]/wadl:link
<leonardr> can i just not put the filter there?
<pcjc2> I'm not sure what value the "DISTINCT" buys us if the EXISTS cause doesn't shortcut the query
<pcjc2> Does DISTINCT shortcut the lookup? It would seem that it couldn't know to do that - or does it infer that from the WHERE clause?
<pcjc2> Might seem to me that the * and -* clauses could be shortcut by LIMIT ing the return of the SELECT statement to at most one row
<lifeless> pcjc2: it does
<pcjc2> I've added similar speed-ups to the other tag searches too
<thumper> sinzui: ping
<lifeless> pcjc2: the DISTINCT means that if there are 1000 tags on that bug, the subquery only returns one row
<sinzui> leonardr: I read that to mean select all param elements that have a resource_type attribute that contains '_collection_link'
<lifeless> pcjc2: we've got concrete data for this
<lifeless> pcjc2: the precise change I proposed makes the query take 7ms
<lifeless> pcjc2: basically, pgsql is weird :)
<pcjc2> as compared to the case where it was only "SELECT ... WHERE BugTag.bug = Bug.id"
<leonardr> sinzui: ah, the name is wrong. it should be name, not resource_type
<pcjc2> As you noted in the bug, the EXIST function should have far more power to short-circuit row lookups
<lifeless> well, we've had other more complex cases
<pcjc2> I would have presumed DISTINCT had to process every row, as well as remove duplicates
<lifeless> it seems to be sensible
<sinzui> leonardr: you many need local-name() to avoid namespace issues
<lifeless> I can ask a losa to test with/without, but as distinct works well enough I propose just doing it :)
<pcjc2> It just looked odd to have it in the clauses for the -* lookups, but not for other tags
<leonardr> sinzui: /wadl:param[contains(@name, '_collection_link')]/wadl:link selects the param whose @name is "me_link". what should i do with local-name?
<pcjc2> (They will be distinct anyway, assuming duplicated tags are not allowed)
<pcjc2> I've put " SELECT DISTINCT TRUE FROM BugTag WHERE BugTag.bug=Bug.id"
<pcjc2> Since we don't care about the data returned from the table
<sinzui> leonardr: sorry. I thought you were referring to the function name(). you are correct to use @name
<pcjc2> The clauses are combined along the lines of "(EXISTS (%s) %s NOT EXISTS (%s))" % (include_clause, combine_with, exclude_clause)
<sinzui> leonardr: or name for an element named name
<lifeless> pcjc2: the ids aren't
<leonardr> sinzui: do you know why that expression would select a param with name="me_link"?
<pcjc2> Bug IDs aren't.. but then we are querying tags for a particular bug here, right?
<lifeless> mbarnett: are you online again ?
<mbarnett> lifeless: i am back,
<pcjc2> how is the test-coverage for tag searches?
<lifeless> up for profiling a query on prod? (data for it isn't on staging yet)
<mbarnett> lifeless: sure.
<lifeless> gimme a minute to whip it up
<mbarnett> lifeless: give me the competing bits
<mbarnett> kk
<jcsackett> sinzui: leonardr: i've got to run for a few. sorry i've been no help.
<sinzui> leonardr: I do not think you need local-name since the '_collection_link' is in an attr value
<pcjc2> gah - the test-suite tests based in expected SQL generation, not results
<leonardr> sinzui: ok. my problem is that i have a seemingly comprehensible expression that doesn't filter anything out
<sinzui> leonardr: Is this a sample of wadl:link elements that you want to match http://pastebin.ubuntu.com/553336/
<leonardr> sinzui: yes, exactly
<sinzui> :( I just wrote a select for that and then saw it was identical to what you just said did not work
<sinzui> leonardr: this does not work? <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
<sinzui>     contains(@name, '_collection_link']/wadl:link">
<leonardr> sinzui: maybe the expression shows up again later in the document, and it must be changed there as well
<leonardr> yeah, i think that's it
<sinzui> yes 2 times
<LPCIBot> Project devel build (351): FAILURE in 4 hr 48 min: https://hudson.wedontsleep.org/job/devel/351/
<lifeless> mbarnett: http://pastebin.com/KmzJ7YpL
<lifeless> bah
<leonardr> sinzui: ok, there's another place where it's slightly different
<huwshimi> Morning everyone
<jml> hey huwshimi
<leonardr> <xsl:variable name="top_level_collections" select="key('id', 'service-root-json')//@resource_type[substring-after(., '#') = $id]" />
<lifeless> mbarnett: http://pastebin.com/raw.php?i=kcwvmWqb
<lifeless> mbarnett: should be able to just run that
<lifeless> in psql
<leonardr> i changed that to:
<leonardr> select="key('id', 'service-root-json')/wadl:param[contains(@name, '_collection_link')]/wadl:link/@resource_type[substring-after(., '#') = $id]"
<mbarnett> lifeless: thanks, was trying to sort out the "#"s that the original was introducing
<leonardr> but either that had no effect, or i'm missing something else
<lifeless> mbarnett: I had a brain fart
<sinzui> leonardr: maybe <xsl:variable name="top_level_collections"
<sinzui>   select="key('id', 'service-root-json')/wadl:param[
<sinzui>     contains(@name, '_collection_link']//@resource_type[
<sinzui>     substring-after(., '#') = $id]" />
<leonardr> did you just add a slash?
<leonardr> you removed wadl:link
<leonardr> that doesn't help me
<sinzui> leonardr: you want the wadl:link element
<sinzui> ?
<leonardr> no, i don't care
<leonardr> but getting rid of it doesn't change what happens
<leonardr> 'person' does not show up in the list of reosurce types, presumably because it was found in top_level_Collections
<jml> huwshimi: how'd it go landing that branch?
<huwshimi> jml: Getting there, but ran into an issue. Still trying to sort it out
<mbarnett> lifeless: the results with no # of results all returned 33: http://pastebin.ubuntu.com/553340/
<sinzui> leonardr <xsl:variable name="top_level_collections"
<sinzui>   select="key('id', 'service-root-json')/wadl:param[
<sinzui>     contains(@name, '_collection_link']/wadl:link[
<sinzui>     substring-after(@resource_type, '#') = $id]" />
<jml> huwshimi: what's the issue?
<sinzui> leonardr: is person also effected by the dual nature of team?
<huwshimi> jml: The land script was having issues. Just about to try again and see
<lifeless> mbarnett: the explain analyzes seem to be missing ;)
<leonardr> sinzui: no, i eliminated that possibility pretty early
<leonardr> in the wadl, person and team are two different but largely duplicated tags
<mbarnett> lifeless: bah
<lifeless> pcjc2: select true, no distinct, appears to be the fastest result we got
<lifeless> pcjc2: can't tell if thats algorithmic or load (because the analyzes are awol :P)
<lifeless> mbarnett: no worries
<pcjc2> so drop the DISTINCT from the SQL - cool, that makes things more consistent
<lifeless> mbarnett: my intent was that you could just capture stdout and not need to fiddle with copy n paste
<pcjc2> The test-suite here is not very nice / good
<jml> huwshimi: btw, paste.ubuntu.com and paste.canonical.com are good places to dump error messages to share with others
<pcjc2> the test-suite is based on the expected SQL for a given tag query, not expected _results_ for a given ....
<huwshimi> jml: ok thanks.
<leonardr> sinzui: i don't think this expression is the problem. if i flip the conditional on $top_level_collections, i don't get person--i get nothing
<leonardr> i guess that doesn't prove what i was saying
<lifeless> pcjc2: heh; a bit ugly, but in some ways reasponable
<pcjc2> doesn't let me verify my new SQL produces valid results though
<pcjc2> definately drop "DISTINCT" ?
<lifeless> yes
<huwshimi> jml: I feel like I'm probably doing something dumb, but this is what I get: https://pastebin.canonical.com/41843/
<lifeless> huwshimi: btw if its not confidential, pastebin.ubuntu.com is better than .canonical.com
<lifeless> lets more folk help
<jml> huwshimi: you need to update your download-cache and rebuild
<huwshimi> lifeless: Oh right, thanks.
<jml> bzr up download-cache; make compile
<jml> huwshimi: it was a bug in our dev tree that has since been fixed.
<huwshimi> jml: Ok, thanks
<mbarnett> lifeless: http://pastebin.ubuntu.com/553345/ might help more
<lifeless> thanks
<lifeless> pcjc2: theres only 1ms in it in the plan, but yeah drop the distinct
<lifeless> thanks
<gmb> gary_poster: Around?
<sinzui> leonardr: I have assumed for a long time that the person collection/entry is broken by the flawed implementation of team.
<gary_poster> gmb, hi, yes
<sinzui> leonardr: is people_collection_link the item that is missin?
 * gary_poster still wants to set up a call with gmb before Thunderdome
<gmb> gary_poster: Hi. I was just wondered if you still wanted to have our long-delayed catch up call before Thunderdome. It would seem I suddenly have tomorrow and Friday as normal work days as the result of a travel snafu.
<gary_poster> though days are few
<gmb> Hah
<leonardr> sinzui: it may be, but that has nothing to do with this problem--this problem is caused by the fact that we have a link to a person at the top-level, and the xslt assumes there are only collections at the top-level
<leonardr> no, #person is the item that's missing in my hacked file
<leonardr> in the file as is, #person is created but it's not properly fleshed out and it's treated as a collection
<gmb> gary_poster: I can do any time tomorrow or Friday.
<gmb> (and I can be TZ flexible too, if that helps)
<gary_poster> gmb :-) awesome.  Lemme go look at a calendar, and remind myself what my TZ offset is...
<gary_poster> (-5 I think, but I never trust my memory of it)
<gmb> gary_poster: If you're in EST you're -5.
<gmb> (Hurrah for all those days of having to do conference calls with the Lexington office)
<sinzui> leonardr: okay, I found it. it does not have a @name. I think I can propose a solution
<gary_poster> heh.  that's it, then.  go, go memory.  Wait, I didn't mean for you to leave...
<gmb> :)
 * leonardr awaits
<gary_poster> gmb: tomorrow at 1600 UTC ?
<sinzui> leonardr: the me_link is unique in th xml, so
<sinzui> <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
<sinzui>     contains(@name, '_collection_link') or @path="$['me_link']"]/wadl:link">
<gmb> gary_poster: Works for me. Send me an invite and I'll ack presently.
<gary_poster> awesome will do.  thank you!
<gmb> np
 * gmb realises it's way past EOD, disconnects for the sake of his sanity
<sinzui> leonardr: well the quotes need fixing, but the trick is to use OR
<sinzui> leonardr: <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
<sinzui>     contains(@name, '_collection_link') or contains(@path, 'me_link')]/wadl:link">
* mbarnett changed the topic of #launchpad-dev to: **Launchpad down/read-only from 23:00 - 00:30 UTC for a code update** Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 4 | PQM is open | RM: jcsackett | firefighting: build is broken | Get the code: https:/â/âdev.launchpad.net/âGetting
<leonardr> sinzui: my problem is that me_link is being counted as a top-level collection and i don't want it to be
<jml> huwshimi: maybe try running ./bin/buildout if 'make compile' doesn't work?
<leonardr> that seems to guarantee it will be counted as one
<sinzui> oh
<sinzui> so we neet a not() condition on it? I would have thought that was unneeded since it does not have @name
<huwshimi> jml: That didn't fix it either
<leonardr> sinzui: i have no idea why it's not working as is, and i've fried my brain looking at it
<jml> huwshimi: still getting the same error?
<jml> oh
<jml> silly me
<jml> huwshimi: you'll need to merge in the latest devel
<huwshimi> jml: ok I'll try that
<micahg> hi lifeless
<lifeless> hi
<sinzui> leonardr: so this does not work: http://pastebin.ubuntu.com/553356/
<leonardr> sinzui: that works
<jml> mwhudson: fwiw, Launchpad tests fail w/ Twisted 10.2
<leonardr> i can stop me_link from being considered in the big list of <h2>top-level objects</h2>
<micahg> lifeless: so regarding bug 702031, this affects developers applying for upload rights in that it makes it harder to find their contributions, don't know if that should increase the priority, but didn't know if that needs another tag
<_mup_> Bug #702031: Packages pocket copied from a Security PPA to the archive should appear in +uploaded-packages <soyuz-security> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702031 >
<leonardr> but when it comes to generating the entry tags
<mwhudson> jml: !
<mwhudson> jml: which?
<leonardr> we check each one to make sure it's not in some list of "top-level objects" generated some other way
<jml> mwhudson: http://paste.ubuntu.com/553358/
<leonardr> and although 'me_link' doesn't seem to show up in that list, 'person' is not being considered an entry for some reason
<thumper> I HATE database identifiers in doctest results
<mwhudson> jml: at least they're faintly plausible tests to fail
<lifeless> micahg: I'm inclined to leave it low; but you can raise it through the stakeholder process (once Ubuntu decides on a representative)
<mwhudson> jml: is the problem clear from the traceback?
<StevenK> thumper: Agreed, rargh!
<micahg> lifeless: ok, are there other tags for tracking stakeholder bugs?
<mwhudson> (i also like the way lp.archiveuploader.tests.test_uploadprocessor.TestBuildUploadProcessor.testBinaryPackageBuild_fail both fails and errors)
<StevenK> mwhudson: On buildbot or hudson?
<lifeless> micahg: ones that we've accepted get a tag, but not simply ones that stakeholders care about AFAIK
<jml> mwhudson: they seem librarian related
<StevenK> Or twisted related
<mwhudson> jml: ok
<jml> mwhudson: the errors are obscured a bit by the librarian logs
<lifeless> whats up with this:
<micahg> lifeless: ok, thanks, will keep an eye on the stakeholder stuff
<lifeless> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
<lifeless> Using filter: min
<jml> mwhudson: when is poolie going to start working on tribunal full time
<mwhudson> jml: deprecation warnings on startup?
<jml> mwhudson: ooh, there's a thought.
<mwhudson> jml: what the what?
<spiv> lifeless: jam saw that yesterday
<StevenK> lifeless: I think that's an out of date jsbuild?
<poolie> ooh that'd be nice
<poolie> for a change
<jml> mwhudson: it would make it easier to read these errors
<mwhudson> jml: 'make start_librarian' or whatever i guess?
<jml> mwhudson: yeah, looking into it.
<spiv> lifeless: (but I think he hacked around it rather than digging into why)
<jml> mwhudson: actually, I might gate-crash your room. too much talk here for this kind of work.
<mwhudson> jml: are we going to make tachandler less vomitous at some point?
<mwhudson> jml: it's quiet here
<mwhudson> (cause there's a linaro meeting happening somewhere else)
<spiv> mwhudson: ReadyService is a thing of beauty :P
<lifeless> spiv: he 'rm -rf'
<lifeless> its lean now
<lifeless> I cleaned it up
<sinzui> leonardr: okay I think I understand now. Maybe you should stop working on this today. clear you mind. I will look at this my my tree and see if I come to a solution
<leonardr> sinzui: thanks a lot
<mwhudson> spiv: i guess you could say that
<lifeless>   File "/home/robertc/launchpad/lp-sourcedeps/eggs/lazr_js-1.5DEV_r191-py2.6.egg/lazr/js/build.py", line 74, in needs_update
<lifeless>     if os.stat(src_file).st_mtime > target_mtime:
<lifeless> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
<lifeless> Using filter: min
<lifeless> any more suggestions ?
<huwshimi> jml: Have gotten past that error now. Thanks!
<mwhudson> lifeless: rm -rf something i think
<lifeless> nope
<lifeless> jam deleted his whole tree
<mwhudson> oh
<lifeless> check utilities/yui-deps.py
<lifeless> and die a little
<jam> mwhudson, lifeless: technically I used "bzr clean-tree --detritus --ignored --unknown", but yeah, pretty much
<jam> the code that does os.stat() should check that the file already exists
<jam> or handle the ENOENT
<lifeless> its a dep listing
<lifeless> its just buuuugy
<mwhudson> joy
<jam> if the file doesn't exist, I think it is safe to say it isn't new enough :)
<lifeless> mwhudson: you looked ? :)
<mwhudson> lifeless: no
<mwhudson> i believe you though
<lifeless> :)
<lifeless> bug 702160
<_mup_> Bug #702160: utilities/yui-deps.py manually lists dependencies <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702160 >
<pcjc2> Lifeless, a cursory search suggests this "problem" exists for CVEs and possibly other things
<lifeless> pcjc2: you may find existing bugs in https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<pcjc2> "BugTask.bug IN (SELECT DISTINCT bug FROM BugCve)" rather than "EXISTS SELECT TRUE FROM BugCve WHERE BugCve.bug = BugTask.bug"
<lifeless> pcjc2: I can well  believe this
<pcjc2> ok, I'll see what I can get through
<lifeless> pcjc2: I suggest doing fixes for them in separate branches
<lifeless> fits better with our qa process
<pcjc2> I'm a little nervous that there isn't a test-suite test which tests functioanlity based on real queries though
<pcjc2> I'll have to be sure I test it properly here
<lifeless> pcjc2: most of our stuff is tested end to end (and thats a problem in various ways) - there are tests and tests though.
<lifeless> what specific tests are you looking at ?
<pcjc2> (I don't think I've got the spare time to re-write such an extensive bunch of tests)
<pcjc2> class TestBugTaskTagSearchClauses(TestCase):
<pcjc2> Tests emission of "correct" SQL, not whether the SQL produces the correct result or not
<pcjc2> so when I change the query in model/bugtask.py
<pcjc2> I have to change the expected SQL in the test results
<lifeless> yes, this is testing what is queried for
<lifeless> there are other tests :)
<pcjc2> and this doesn't help me verify I've not broken anything
<pcjc2> ah - fair enough
<pcjc2> I had wondered if it would be more efficient to phrase the tag search as a single SELECT
<pcjc2> and combine the logic in the WHERE statements - rather than doing boolean operations on various separate SELECT statements with a single WHERE clause each
<pcjc2> Anyway - this is probably just bike-shedding - 7ms vs. 17secs seems "good enough" for the case I originally reported ;)
<lifeless> pgsql traverses the btree separately per id anyhow
<lifeless> so I don't think its a significant issue
<pcjc2> stupid question - any idea of which tests to run?
<lifeless> :!find . -name "*bug*search*"
<lifeless> suggests
<pcjc2> thanks
<lifeless> bugtask-search-views.txt bugtask-searches /xx-bugs-advanced-search-upstream-status.txt bugtask-search.txt
<lifeless> ./lib/lp/bugs/tests/test_bugtask_search.py
<pcjc2> KeyError: 'STORM_CEXTENSIONS'
<pcjc2> grr bin/test not working here - what did I break... (checks)
<lifeless> pcjc2: run 'make'
<pcjc2> Error: Couldn't find a distribution for 'Twisted==10.1.0-4395fix'.
<pcjc2> some rocketfuel command I need to call?
<jml> uhhh
<thumper> pcjc2: update the download cache?
<jml> do you have a download-cache
<jml> is it up to date
<pcjc2> not sure.. -> probably not
<lifeless> who knows about the yui build stuff?
<jml> I don't :)
<jml> hmm. hmm. hmm.
<jml> the librarian log seems to accumulate during a test run
<jml> I guess that makes sense, because it's the same librarian.
<jml> but it makes the log in the details less useful for longer runs
<lifeless> jml: yes
<lifeless> jml: it would be nice for the fixture to note the file length and only copy new stuff
<lifeless> jml: but! we need to fix the 1MB-and-it-rotates thing first
 * pcjc2 tries make clean.. otherwise not working still
<lifeless> pcjc2: you nede to run 'bzr update' in the download-cache directory
<pcjc2> I tried bzr pull
<pcjc2> Tree is up to date at revision 227 of branch bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-source-dependencies
<lifeless> if you have the default setup, its bzr update
<pcjc2> error is in bin/compile_templates
<pcjc2> will pastebin
 * pcjc2 fixes error in his patch ;)
<pcjc2> The download-cache update did help though, but the make error was my fault
<pcjc2> is there an approved coding style for line-continuations?
<pcjc2>             include_clause = \
<pcjc2>                 "SELECT TRUE FROM BugTag WHERE BugTag.bug=Bug.id"
<pcjc2> Is that ok?
<lifeless> dev.launchpad.net/PythonStyleGuide
<lifeless> uhm
<lifeless> that looks like it will fit on one line in 78 charsa
<lifeless> if it won't
<lifeless> include_clause = (
<lifeless>     "SELECT ...")
<lifeless> is our preference
<bac> pcjc2: as lifeless points out, we prefer the style he quotes.  continuing a line by using \ is not used.
<lifeless> bac: not used would be an exaggeration :)
<bac> lifeless: really?  i don't recall seeing it.
<lifeless> it's around
<lifeless> personally I think we shouldn't specify stuff like this
<bac> lifeless: luckily we have a forum coming up for you to express that opinion.  :)
<lifeless> bac: bigger fish to fry
<pcjc2> thanks
<pcjc2> I can't seem to make it run some tests
<pcjc2> ./lib/lp/bugs/stories/bugtask-searches/xx-searching-by-tags.txt
<pcjc2> ./bin/test -t xx-searching-by-tags.tx
<wgrant> pcjc2: doctests are a bit odd. Try just asking for xx-searching-by-tags.txt, not the full path.
<pcjc2> thanks
<pcjc2> some tests fail with bug heat changes - even after "make schema"
<lifeless> interesting
<pcjc2> tests are _slow_
<lifeless> yes!
<lifeless> flacoste: hi
<jml> pcjc2: lifeless has a plan to make it all better.
 * pcjc2 wishes you guys used git instead of bzr - that would be nicer
<pcjc2> probably mostly because I'm quite familiar with git, but not so with bzr
<lifeless> pcjc2: how would it be nicer?
<pcjc2> I'd love to see LP support code-review and branches with git as well as you do for bzr
<pcjc2> we use git for our project - so supporting git workflows would be really handy
<pcjc2> I was wondering if it would be accepted should I volunteer to work on it
<lifeless> mmm
<pcjc2> but have been told (here IIRC), that it would not likely be wanted, even it it was coded
<lifeless> theres a bunch of concerns around it
<lifeless> we'd like to make users of git happy
<pcjc2> any written down?
<lifeless> how that looks is a whole other question
<lifeless> on the technical side I wouldn't want a parallel infrastructure for git & bzr throughout the system
<pcjc2> no - need some SCM abstraction
<lifeless> jml: can speak to the social and product constraints
<lifeless> pcjc2: we have one - bzrlib :)
<pcjc2> bzr and git backends
<lifeless> pcjc2: no, I'm serious - bzrlib *is* a SCM abstraction
<pcjc2> ok
 * pcjc2 wishes he had an index, and "git stash" whilst working on branches in bzr
<lifeless> it can talk natively to git, svn, hg, bzr
<lifeless> bzr shelve
<lifeless> bzr unshelve
<pcjc2> thanks - I knew it was probably me not being familiar enough with bzr
<pcjc2> I think the problem is I'm so used to git's internal model - and I don't "get" bzr's - I'll make an effort to look it up some time
<jcsackett> pcjc2: bzr shelve/unshelve has some really nice features. i've come to prefer it to git stash.
<lifeless> gary_poster: is it intentional that WebservicePerformance isn't linked on LEP ?
<gary_poster> I think so, lifeless; lemme review
<gary_poster> lifeless: yeah, it is, we were building it.  That said, putting it in the Drafting section probably wouldn't hurt anything.  Would you like me to do so?
<lifeless> that would be cool
<poolie> did someone tweet it's back up?
<poolie> gary_poster, i did that
<poolie> gary_poster, it looks nice
<poolie> i will add some comments
<gary_poster> poolie, thank you.  it's not internally consistent yet, but appreciated
<gary_poster> night all
<poolie> gary_poster, it would be interesting to look at the super-slow hottest100 measurement script
<poolie> and see what the code would look like, and what round-trips it would do,
<poolie> under this new approach
<jml> StevenK: hi
<jml> StevenK: how's it going with those test failures?
<StevenK> Workus Interruptus
<jml> StevenK: I ask, because the recent branch to control IBuild.date_finished only from within buildmanager introduces new test failures
<StevenK> Being in the kernel room has been not good for interrupts
<poolie> mm
<poolie> needing to get up and go to the bar all the time
<james_w> to examine in 15 minutes: OOPS-1838H5865
<jml> StevenK: should I attempt to fix it instead?
<james_w> (going to https://code.launchpad.net/~salgado/linaro-image-tools/config-class/+merge/46048)
<jml> hmm.
<pcjc2> grr... bugtask test fails comparing two notionally identical strings on prefixed as unicode (u"..."), one not ("...")
<lifeless> doctests are painful
<jml> hmm
<lifeless> jml: they are
<pcjc2> wasn't a doctest, was lib/lp/bugs/model/tests/test_bugtask.py
<lifeless> hmm
<lifeless> what line
<pcjc2> lost the scrollback in the terminal, so waiting for another test run
<pcjc2> SQL was (EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'bob'))
<pcjc2> will need to bzr shelve and re-check prior to my changes as a next step I think
<lifeless> pcjc2: what line in the test file
<jml> for rolling back a revision, I can just do it and email the list.
<jml> right?
<lifeless> jml: if you mean commit a new revision reverting the changes with rollback=xxxx, yes
<pcjc2> line won't match yours, as I've edited the test
<lifeless> jml: you don't even need to email the list if you won't want to
<jml> lifeless: ahh ok.
<jml> lifeless: is there a doc so I can get this right?
<lifeless> jml: if you mean uncommit, noooooooo dooooooinnnnnggggg it
<jml> (or better yet, tool support?)
<jml> lifeless: I don't mean uncommit.
<pcjc2> def test_mixed_tags_all(self): ~= Line 455
<lifeless> jml: https://dev.launchpad.net/MergeWorkflow
<lifeless> https://dev.launchpad.net/QAProcessContinuousRollouts
<StevenK> jml: Sorry, interrupted again. Please do.
<jml> StevenK: ta.
#launchpad-dev 2011-01-13
<pcjc2> http://pastebin.com/22DZ5hNS
<lifeless> pcjc2: so that uses __eq__
<lifeless> it will match u'' == ''
<lifeless> the string is different
<lifeless> to whit:
<lifeless> >>> a="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'bob'))"
<lifeless> >>> b="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'bob'))"
<lifeless> >>> a==b
<lifeless> False
<lifeless> note the 'bug.id' vs 'Bug.id'
 * pcjc2 explodes
<pcjc2> I pasted both strings in my texteditor and did a search to compare
<pcjc2> and it highlighted both
 * pcjc2 goes back to using a REAL editor like gvim ... screw gedit
<pcjc2> sorry for the noise
<lifeless> no probs!
 * pcjc2 feels stupid
<lifeless> its not the most helpful assertion
<pcjc2> Should I be matching WHERE BugTag.bug = Bug.id
<pcjc2> OR WHERE BugTag.bug = BugTask.bug  ??
<pcjc2> Either should work, but the old query was BugTask.bug IN
<lifeless> depends what we want to correlate on
<lifeless> Bug.id is a smaller set than BugTask.bug
<lifeless> 1 bug to many bugtasks
<jml> looks like we'll need a losa to fix the build. we'll have to wait until the release is done.
<lifeless> fooding downstairs
* mbarnett changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 4 | PQM is open | RM: jcsackett | firefighting: build is broken | Get the code: https:/â/âdev.launchpad.net/âGetting
<jml> wgrant: btw, I've landed a rollback for r12181. I guess another thing to do would have been to delete the date_finished assertions in test_uploadprocessor, but I was a bit rushed at the time and not fully certain.
<wgrant> jml: Were there test failures?
<jml> wgrant: yeah. sorry to bring bad news.
<mwhudson> jml, crusher of hope
<mwhudson> thwarter of desire
<wgrant> jml: *sigh*
<wgrant> Self-reviewed *and* untested.
<jml> yeah. it's a pain, and worse for being easily avoidable.
<jml> I want to upgrade Twisted, so I need a working devel in order to do a sane ec2 test run.
<jml> anyway, I guess that can be the work of tomorrow
<jml> I'm signing off
<wgrant> Night.
<jml> g'night all
<wgrant> Thanks for reverting that.
<jml> np.
<LPCIBot> Project devel build (352): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/352/
<LPCIBot> * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=664828] Fixed timeout when deactivating a
<LPCIBot> member of a team.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Upgrade to testtools 0.9.8 final
<pcjc2> lifeless: Patch is available for the tags issue, but haven't done any testing on it locally (other than proving test-suite now runs for the handful of test you identified)
<pcjc2> https://code.launchpad.net/~pcjc2/launchpad/fix-tag-search-bug-501945/+merge/46075
<pcjc2> lifeless: When PQM runs the test-suite,... does it use that opportunity to benchmark Launchpad?
<pcjc2> It occurred to me that one could take a snapshot of a fairly large testing database, grab a load of "typical" queries from a day in the life of Launchpad.. and make some kind of performance metric for code-changes
<pcjc2> Would probably have to be read only queries unless there was a way to roll-back a big DB snapshot after testing
<lifeless> no
<lifeless> in fact for lp we don't run the test suite in pqm; we do that in a CI tool (currently buildbot) post-landing
<lifeless> the live db (which you need for perf evaluation) is 250GB
<pcjc2> thought it would be a problem ;)
<pcjc2> My HDD is only 500GB
<lifeless> yeah
<pcjc2> I guess perf could be made from a set of read-only queries on the live DB
<lifeless> it won't fit on my laptop, thats for sure
<pcjc2> but data changes of course - so hard to remain consistent.
<lifeless> yeah
<lifeless> we have comprehensive performance data anyhow
<pcjc2> Perhaps that doesn't matter though... bad perf is bad perf, caused by increased DB size, or whatever
<pcjc2> Ok - that is good
<lifeless> we trace all requests and generate page render times, broken down by page, url, what have you
<pcjc2> Was just wondering if changes like the bug tags one would get noticed
<lifeless> well, that bug will be closed
<lifeless> we'll have some less backend data
<lifeless> howevewr
<lifeless> I suspect its < 10 pages a day hitting that bug (perhaps much less)
<lifeless> and we have 4000000 page renders a day
<pcjc2> https://devpad.canonical.com/openid/+login
<pcjc2> Authorization is required to accessÂ https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-timeout-candidates.html
<lifeless> yup, internal only atm
<pcjc2> shame
<lifeless> we're going to get a sanitised extract
<lifeless> but we have confidential project names of our customers exposed in the raw report
<pcjc2> Btw.. were the concerns about git (as regards possible integration with LP) documented somewhere?
<lifeless> I suspect not
<lifeless> I mean
<lifeless> we do mirror git into LP
<lifeless> and I think it would be fairly sane to publish bzr branches into git automatically
<lifeless> I'm not at all sure about speaking git for writes
<pcjc2> (that has confused some people in our project already)
<lifeless> on purely technical limits
<lifeless> let alone the room for confusion
<pcjc2> we already have git repositories in various places, so something distributed would be nice to support
<pcjc2> It doesn't really matter to us that launchpad mirrors through bzr in order to get at things like translations etc..
<pcjc2> But it would be nice if we could hide that fact as an "admin only" detail, rather than have users think we use bzr
<pcjc2> I should file a feature request for adding more comments on the "code" page of a project. We'd love to add some notes to https://code.launchpad.net/geda
<lifeless> please do
<poolie> that would be nice
<pcjc2> I'm going to bed shortly - I'll try and find time tomorrow to have a think about a) how our lives could be made less confusing w.r.t code on LP, and b) What wishlist we might have for git integration
<pcjc2> I do love the ease with which you can push personal branches to launchpad with bzr
<pcjc2> The code review workflow is lovely too. I wish we had the same for git
<lifeless> what keeps you on git ?
<pcjc2> it was not _that_ long ago that we moved to it, and we find it serves almost all our needs
<lifeless> what I mean is
<lifeless> if you like everything else about lp
<lifeless> and you want to avoid confusing your users
<pcjc2> The one area it could be better is that some users used to CVS / SVN just don't know how to "cvs up" with git
<lifeless> one option is to migrate to bzr
<pcjc2> that is of course an option ;)
<lifeless> (where you can bzr up :P)
<pcjc2> indeed
<lifeless> I'm totally cool with you staying on git, of course
<lifeless> just curious about how you perceive it all
<pcjc2> I'd bet that bzr can do almost all of what we want, but it is one more thing to learn. I expect to learn it in due course though.
<pcjc2> I find git more polished and pleasing to use than bzr though
<pcjc2> faster - more obvious what is going on under the hood. Nice paged output with colours by default ;) (No doubt all options I've yet to find in bzr)
<pcjc2> With bzr, I still get the uneasy feeling that I don't know where my data is
<pcjc2> With git, I know where the data is (when unpacked), where the reflogs are, where to find the internals of stgit, how to manually fixup most problems one might encounter
<pcjc2> (Thank-you very much ext4 + OS crash for the 0-length files in the repository's store)
<lifeless> heh
<lifeless> yeah, ext4 is not happy making
<pcjc2> using it now, but its habit of truncating files is not nice
<pcjc2> I recall there was a technical reason for the decision, but it is a shame they had to make it
<lifeless> it doesn't actually truncate
<lifeless> rather it saves the directory before saving the file inode
<lifeless> pcjc2: there are technical *arguments*... calling it a reason is a stretch in the opinion of quite a few people :)
<pcjc2> irritating behaviour whatever the cause. I recalled it was something to do with ensuring consistency
<lifeless> its all about performance
<lifeless> delayed allocatio
<lifeless> n
<pcjc2> http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
<lifeless> and yes
<lifeless> one of the problems is the black and white way the problem is framed
<lifeless> most apps *don't* care about 'on disk', but they do care about 'ordered in this way'
<lifeless> its better for battery life to care about the second point
<pcjc2> ignore the negative comments abut Ubuntu in that blog post
<poolie> bzr should probably just fsync files (or whatever exactly is needed) on ext4 bydefault
<pcjc2> It was a git repository I got corrupted, but I imagine both might benefit from fsync around critical changes
<pcjc2> goodnight
<wgrant> Storm is too lazy :(
<thumper> wgrant: in what way?
<wgrant> thumper: Applying @cachedproperty to a method that returns a resultset does nothing.
<thumper> heh
 * thumper EODs
 * huwshimi is heading off
<wgrant> I'm guessing there are no reviewers around?
<wgrant> thumper: ?
<LPCIBot> Project devel build (353): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/353/
<LPCIBot> Launchpad Patch Queue Manager: [r=benji][ui=none][bug=701613] update keyring to 0.5.1
<LPCIBot> Project devel build (354): STILL FAILING in 2 min 33 sec: https://hudson.wedontsleep.org/job/devel/354/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=702170][no-qa] Fix yui deps to list the
<LPCIBot> current yui files.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][no-qa] Adds more logging to the request_daily_build
<LPCIBot> script.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=sinzui][bug=700864] Show a warning to the user if the
<LPCIBot> daily build won't happen due to PPA upload permission problems.
<LPCIBot> * Launchpad Patch Queue Manager: [rs=jml][ui=none][rollback=12181] Rollback r12181,
<LPCIBot> which introduced test failures.
<adeuring> good morning
<wgrant> jtv: Morning.
<jtv> wgrant: morningâ¦ orâ¦ late afternoon?
<wgrant> jtv: One of those.
<wgrant> Or others.
<wgrant> jtv: Bug 702228
<wgrant> rosetta-export-queue is broken.
<jtv> Arrr
<wgrant> _mup_: bug 1234
<wgrant> :(
<wgrant> bad _mup_
<jtv> I guess I didn't make the display of current backlog on the export page prominent enough.
<wgrant> jtv: It is hanging on one export.
<jtv> Firefox, too.
<wgrant> natty firefox, IIRC.
<wgrant> Yeah.
<jtv> Do we know though that this isn't a stale lock file after the rollout?
<wgrant> jtv: It was processing firefox before the rollout.
<wgrant> And is processing firefox again after the rollout.
<jtv> Looks to me as if the bug report may be completely unrelated to what we're actually seeing.
<jtv> The backlog is 16 hours.
<wgrant> 2011-01-13 07:16:16 DEBUG   Exporting objects for ÐÐ°Ð½Ð¸Ð»Ð¾ Ð¨ÐµÐ³Ð°Ð½, related to template firefox in Ubuntu Natty package "firefox"
<wgrant> It did it again an hour ago.
<wgrant> This is an ongoing problem.
<jtv> But one unrelated to the complaint of "it don't work for 2 day," which is more likely to be an email problem or something.
<wgrant> Ah, true.
<jtv> What has me curious is why the backlog is listed as about 16 hours, when rollout was scheduled about 10 hours ago.
<jtv> Surely we didn't stop the script 6 hours prior to rollout?
<jtv> It's possible that this is unrelated to rollout, but given how close to rollout it happened, one would suspect a connection.
<wgrant> jtv: Indeed.
<wgrant> jtv: Except that rollout prep didn't start for another 4 hours, AFAICT.
<jtv> Right.  It actually seems to have happened just before rollout.  Not 2 days before, not immediately after.
<jtv> Which also means that we didn't cause this in db-devel.
<adeuring> stub: could you have a look at this schema patch: http://paste.ubuntu.com/553532/ ?
<adeuring> stub: this breaks "make schema" when the test DBs are populated
<stub> adeuring: How does it break? It might be you need to use $$ quoting instead of single quotes for the function body, and the function should go in trusted.sql.
<adeuring> stub: IntegrityError: new row for relation "message" violates check constraint "message__must_have_chunks"
<stub> I wouldn't add this constraint anyway, as it is only checked at insert time
<adeuring> stub: my main point: do you think the patch itself is reasonable? If not there is not need to dive into the samledata iusse ;)
<stub> Sounds like some of our messages in sampledata don't have chunks.
<adeuring> stub: exactly
<adeuring> and this causes several headaches
<stub> Don't add the constraint would be my preference.
<adeuring> we don't know why this happens, so I thought that postgres could guard it
<stub> Constraints are good to provide guarantees, but in this case it cannot provide a guarantee
<adeuring> stub: well, the contraint will cause exepctions
<stub> If we want to guarantee this, a trigger is a better option
<adeuring> if we'll get these empty messages again
<adeuring> stub: how would you use a trigger here?
<stub> We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message.
<adeuring> stub: ok, makes sense.
<stub> (16:53:48) stub: We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message.
<stub> (16:54:51) stub: I guess it is pretty much the same as the CHECK constraint
<stub> (16:56:19) stub: 'SELECT TRUE FROM MessageChunk WHERE message=$1 LIMIT 1' reads nicer to me and I think more likely to get a nice plan.
<stub> (16:58:38) stub: adeuring: Have you looked at the contents of Message.raw for these empty messages?
<stub> 17:00
<stub> (17:02:21) stub: adeuring: IIRC it is actually valid to have a Message with no MessageChunks - eg. an email that is just headers and no body. I don't see any use for these though even if they are technically valid so don't mind guarding against them if we need to.
<stub> (17:09:05) stub: adeuring: https://launchpadlibrarian.net/42717149/UYhI9QHAcptcDE1jt64zhivlP6.msg is the last one in the system, which looks like an email imported from debbugs
<stub> (17:09:42) stub: adeuring: And it is an email with no body - just headers
<adeuring> stub: ah, that's interesting. Seems that i need to check again what to do with empty messages
<adeuring> stub: strictly speaking, tis mail is _not_ empty: There are four empty lines after the headers, so a body content of '\n\n\n'
<adeuring> so that mail _should_ have a MessageChunk record
<stub> adeuring: So check out or email_to_message helper - we are likely deliberately stripping leading and trailing whitespace.
<adeuring> stub: right
<jtv> stub: it's a bit awkward to slap a SlaveOnlyDatabasePolicy around just the right parts of the export procedureâ¦ would a SlaveDatabasePolicy around the whole thing be as valid?  AFAIK we never ask for the master unless we really need the master.
<jtv> If that leaves cursor() on the master, I could just eliminate the call.
<LPCIBot> Project devel build (355): STILL FAILING in 4 hr 47 min: https://hudson.wedontsleep.org/job/devel/355/
<deryck> Morning, all.
<gmb> deryck: I think it'd be a good idea to make you an admin on ~malone-alpha so that you can approve new members. Any objections?
<gmb> deryck: Also, do you have the slightest clue what's going on here: https://bugs.launchpad.net/launchpad/+bug/702022/+attachment/1792482/+files/out-2.ogv
<_mup_> Bug #702022: Once a project is modified you can no longer modify the status <Launchpad itself:Incomplete> < https://launchpad.net/bugs/702022 >
<bigjools> can someone remind me where our QA tagging guide lives please?
<bigjools> ah nm
<deryck> gmb: sure, make me an admin.  looking at the other now.
<gmb> Ta]
<stub> jtv: Sounds fine
<deryck> gmb: yeah, I've seen that before, but don't recall exactly the work around.  it's something to do with renaming projects and permissions after that.
<gmb> deryck: Damn. Maybe sinzui, oracle of Registry, will know more.
<deryck> gmb: it's something to do with because the "-old" team is inactive.
<gmb> Ah.
<gmb> deryck: So, if they reactivate that the problem might go away?
<deryck> gmb: indeed, it might
<gmb> I'll update the bug.
<wgrant> deryck, gmb: The top task is a deactivated project.
<wgrant> Nothing to do with a team.
<wgrant> I thought we hid those or something.
<gmb> wgrant: Yeah, I s/team/project/'d before updating the bug.
<wgrant> Ah, great.
<gmb> deryck, wgrant: I reactivated the -old project too, to speed things along. Hurrah for limited admin permissions.
<wgrant> Heh.
<gmb> allenap: ISTR you looked into why archived debian bugs weren't synced correctly... Did you ever get anywhere with that?
<gmb> I ask because of https://bugs.launchpad.net/launchpad/+bug/702332.
<_mup_> Bug #702332: debbugs #605391 not able to correctly update information <Launchpad itself:New> < https://launchpad.net/bugs/702332 >
<allenap> gmb: I started investigating with mthaddon... it might have been a problem with the archive not syncing properly.
<gmb> allenap: Yeah; I came to the conclusion that because old archived stuff only sticks around for so long, we might not have a copy of it.
<allenap> gmb: I think that archived debbugs get moved into a separate database. Do you remember the bug that triggered http://twitter.com/grahambinns/status/18060932747886592?
<allenap> We should/are syncing both, but perhaps there is a problem.
<gmb> Hah, no.
<gmb> allenap: Yeah, I thought we were syncing both, and I seem to have got the idea that stuff gets deleted from the archive, too, which is clearly nonsense.
<gmb> (Having just re-read the same page that gave me that idea I can now see that I was just getting fuddled)
<leonardr> sinzui, thanks a lot for that sample. i'm sooo close to having something working
<leonardr> the only problem now is that the top-level collections are showing up twice: once as collections and once as entries
<leonardr> they're not being filtered out properly
<leonardr> my diff: http://pastebin.ubuntu.com/553622/
<leonardr> i think i probably just converted the last bit incorrectly
<sinzui> leonardr: are they twice in the toc or twice in the content
<leonardr> sinzui: both. that makes me think i didn't look carefully at the last two "if test"s
<leonardr> give me a minute
<leonardr> sinzui: i think this is the problem. $master_top_level_collections isn't a list of ids, it's a list of tags
<leonardr> so $master_top_level_collections[contains(., $id)] always fails
<leonardr> does that make any sense?
<leonardr> i took out this code because it didn't seem to do anything:
<leonardr>             <xsl:variable name="top_level_collections"
<leonardr>                 select="$master-top-level-objects" />
<sinzui> leonardr: id does make sense. We can either revise the master code to work with the master set to get ids from the tags, or we define a id version of the variable
<leonardr> sinzui: let's define another variable since it's used twice
<leonardr> what does it look like?
<jml> mrevell: hi
<mrevell> jml, Hi
<jml> mrevell: am stuck in a plenary atm
<jml> mrevell: do you want to have a call today?
<mrevell> jml, I'll be seeing you all day every day next week, so I'm happy to skip it. :)
<jml> mrevell: ok, cool. :)
<jml> wuuuuu Dallas!
<mrevell> hehe, you've been there so long now I bet you're picking up the accent.
<jml> not quite
<jml> I do have pick-up truck envy though
<jml> I want a pick-up truck so big that it's not legal to drive it within signatories of the Geneva convention
<mrevell> haha
<sinzui> leonardr: maybe this?
<sinzui> http://pastebin.ubuntu.com/553629/
<lifeless> so, how do I upgrade my ui ?
<lifeless> I pulled in dists
<lifeless> ran bin/buildout
 * jml tries upgrading Twisted
<StevenK> jml: Didn't we just do that?
<jml> StevenK: we upgraded for 10.1, and then we applied a recent patch from trunk to fix a particular bug
<StevenK> jml: Or was that just discussing 10.2, but not doing it
<jml> StevenK: but 10.2 was released toward the end of last year, so it's time for an upgrade
<lifeless> wgrant: still awake?
<jml> StevenK: I tried upgrading to 10.2 yesterday, but got blocked on test failures introduced into the build by other branches.
<StevenK> lifeless: It's 0217, so I seriously doubt it
<lifeless> StevenK: there is always hope
<lifeless> so, how do I upgrade my yui ?
<bigjools> lifeless: would you have any idea why Storm would throw an IndexError when I call is_empty on a ResultSet?
<bigjools> hmmm actually it's the stuff in ftests/pgsql.py
<lifeless> bigjools: not offhand
<bigjools> lifeless: http://pastebin.ubuntu.com/553640/
<bigjools> I think I'll be filing a bug
<leonardr> sinzui: i don't understand this error from the code you just sent me
<leonardr> XPath error : Invalid type
<leonardr> xmlXPathCompiledEval: 1 objects left on the stack.
<leonardr> clearly there's something wrong with the substring-after call, but i don't see it
<sinzui> I do not understand it either. I will re-read what I wrote
<leonardr> sinzui: if it helps, i get the same error replacing the xpath expression with a random string
<leonardr> select="substring-after('foo', '#')"
<sinzui> leonardr: okay. I reproduced the error.
<sinzui> leonardr: looks like the problem is not in the new variable bug in how we use it.
<leonardr> ok
<leonardr> not($master_top_level_collection_ids[contains(., $id)]) is wrong?
<flacoste> allenap, benji, Edwin-afk: can you QA your bugs, I'd like to make a nodowntime release later today
<allenap> Sure.
<benji> flacoste: will do
<flacoste> thx
<EdwinGrubbs> working on it
<sinzui> leonardr: I suspect we are getting a null string. Maybe we have an item in the xml where there is not string after #
<leonardr> sinzui: there is a param with an empty wadl:link
<leonardr> resource_type_link in the top-level
<sinzui> okay I will look into that
<bigjools> benji: keyring problems all seem sorted for me, thanks!
<benji> yay
<leonardr> sinzui: i'm going to move this stylesheet to launchpad while i'm at it. do you have an opinion where in the tree it should go?
<sinzui> leonardr: I am not sure. I would think lib/lp/services/api if we intend to migrate api generation code to a single location
<LPCIBot> Project devel build (356): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/devel/356/
<LPCIBot> Launchpad Patch Queue Manager: [r=benji,
<LPCIBot> edwin-grubbs][ui=none][bug=620868] Allow the viewing and editing of
<LPCIBot> recipes with invalid recipe text.
<sinzui> leonardr: I was mistaken that I could use substring-after to create create a node set. We are not getting the correct type back. I will make an alternate suggestions
<lifeless> gmb: hi
<lifeless> gmb: why is bug 380362 wontfix? - found it chasing a newly reporting 'bug not found' error in debbugs
<_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. <lp-bugs> <Launchpad itself:Won't Fix by gmb> < https://launchpad.net/bugs/380362 >
<LPCIBot> Project db-devel build (264): FAILURE in 4 hr 46 min: https://hudson.wedontsleep.org/job/db-devel/264/
<gmb> lifeless: Because of some confusion a while back. allenap and I think there might be a problem syncing archived bug reports. I'll re-open the bug now.
<lifeless> gmb: bug 702332
<_mup_> Bug #702332: debbugs bug watch not updating an archived debbug (#605391) <bugwatch> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702332 >
<lifeless> gmb: may be a dupe
<james_w> hi lifeless, where are you hanging out today?
<lifeless> bzr room atm
<gmb> lifeless: It is a dupe. allenap and I were discussing it just today, actually, but I hadn't got round to finding this bug and duping the new one. Will do it now, thanks.
<sinzui> leonardr: I think this solves the issue: http://pastebin.ubuntu.com/553663/
 * leonardr shall check
<leonardr> sinzui: looking good
<sinzui> fab
<sinzui> leonardr: jcsackett is reviewing today and he knows xslt. Is there a chance you can get your branch into review?
<jcsackett> jcsackett *sort of* knows xslt. :-P
<leonardr> sinzui: yes, i just need a minute to do a diff of the stylesheet. i'm moving it into launchpad so the whole thing willl show up in the diff
<jml> sinzui: is utilities/migrater still needed in trunk?
<jcsackett> jml: i think that will still be useful for as long as there are things to move from /canonical to /lp, yes?
<jml> jcsackett: I guess. I'm just mildly inconvenienced when file-ownership.txt shows up in my greps.
<jml> so it's no big deal
<jcsackett> jml: if you're grepping across the launchpad tree, you might look at utilities/migrater/find.py
<jml> jcsackett: you're going to have to work harder than that to get me to abandon bzr grep.
<sinzui> jml: I regenerate my own each time. file-ownership is vestigial
<jcsackett> jml: fair. wasn't trying to get you to abandon. i just find it a useful tool. :-)
<lifeless> flacoste: hi
<lifeless> flacoste: there are something like 10/15 rt's in the lp/bzr queue with pri 0 which AIUI means 'unset' - I'm wondering if you could drive that to 0? [on the same basis we drive NEW to zero]
<jml> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
<jml> just got that on 'make schema'
<jml> anyone know what's up with that?
<mwhudson> jml: lifeless filed a bug about that
 * jml looks
<jml> ahh. rm -rf lazr-js/build
<jml> can someone please run "./bin/test -cvvt distribution-mirror.txt" for me?
<jml> I wonder if this is a natty thing.
<lifeless> jml: doing a make schema
<lifeless> then I'll try for thee
<jml> lifeless: thanks
<flacoste> lifeless: i can do that yes
<jml> also
<jml> my current working hypothesis is that Python is broken in natty
 * jml gets on to that
<lifeless> 2.6 or 2.7 :p
<jml> 2.7
<jml> but I think it's actually bzr being broken in Python 2.7, which is more plausible
<lifeless> the test failed for me
<lifeless> /home/robertc/launchpad/lp-branches/working/lib/canonical/librarian/testing/server.py:120: DeprecationWarning: Attempt to start Tachandler with an existing instance (21693) running in /var/tmp/fatsam.test/librarian.pid.
<lifeless>     +     url = librarian.remoteAddFile(
<lifeless>     + AttributeError: 'thread._local' object has no attribute 'interaction'
<lifeless>     + ERROR   Error while sending mail from bounces@canonical.com to david.allouche@canonical.com.
<lifeless>     + Traceback (most recent call last):
<lifeless>     +   File "/home/robertc/launchpad/lp-sourcedeps/eggs/zope.sendmail-3.7.1-py2.6.egg/zope/sendmail/queue.py", line 261, in run
<lifeless>     +     raise error, msg
<lifeless>     + error: [Errno 111] Connection refused
<jml> hmm
<jml> I get completely different failures
<jml> but!
<jml> the stack traces show that it's using python 2.7
<jml> which means that buildout is somehow using system standard python rather than a hard-coded python 2.6
<jml> gary-lunch: does that sound plausible? ^
 * gary_poster has a call noe, jml...um
<jml> gary_poster: don't worry. I'll keep poking around.
<gary_poster> ok thanks, will ping
<gary_poster> jml, yes, that's what our Makefile does.  It was because of Hardy/Lucid transition.  Can specify 2.6 now
<jml> gary_poster: just set PYTHON to python2.6 in the Makefile?
<gary_poster> jml, prob
<jml> ok
<jml> will give it a try
<jml> gary_poster: thanks.
<jml> yeah. that does it.
<pcjc2> Lifeless, did you get a chance to review my patch? Would like to see it on staging so I can QA the changes
<flacoste> thumper: if you could QA the two bugs you landed, i'd like to do a nodowntime release later today
<lifeless> pcjc2: hi
<lifeless> pcjc2: been flat out; best way to get it reviewed is to pop into #launchpad-reviews and ask for a reviewer
<lifeless> it looked ok to me to the extent I had looked at it
<pcjc2> ok, - will do, sorry for assigning you directly
<lifeless> no worries
<lifeless> I'm happy to look at it
<pcjc2> that might have slowed progress if other potential reviewers ignored it as a result
<pcjc2> I'll ask in #launchpad-reviews
<thumper> flacoste: done
<flacoste> thumper, thx
<thumper> morning
<maxb> Does anyone know if the fact launchpad is supporting jaunty PPAs long after the jaunty EOL is a deliberate choice? It was not so for intrepid
<lifeless> maxb: accident I think
<bryceh_> StevenK, https://code.launchpad.net/~bryce/launchpad/lp-617698-forwarding
<jml> lifeless: is there a fixture for the librarian that I can use instead of the layer?
<jml> hmm.
<jml> found it.
<pcjc2> Hi Bryceh_, you working on LP as well as Ubuntu-X now?
<jml> (or should I actually use the layer)
<lifeless> jml: the answer is probably 'you should use th elayer'
<lifeless> jml: what are you doing ?
<jml> moving some tests out of doctests
<mwhudson> destroying cute kittens with the power of is mind
<StevenK> lp:~stevenk/launchpad/lp-617698-forwarding
<jml> I can use the layer without much hassle, I just thought I might try something.
<lifeless> jml: so the layer has dependencies
<lifeless> jml: its more appropriate for what you're doing
<LPCIBot> Project devel build (357): STILL FAILING in 4 hr 24 min: https://hudson.wedontsleep.org/job/devel/357/
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=699820] Ensure that
<LPCIBot> buildfarmjob.date_finished is only set by the buildd-manager
<LPCIBot> and not the upload processor so that we can accurately see the
<LPCIBot> overhead that the upload processor incurs.
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=702192] determineArchitecturesToBuild
<LPCIBot> no longer fails when nominatedarchindep is not supported by the
<LPCIBot> archive.
<LPCIBot> Project db-devel build (265): STILL FAILING in 4 hr 22 min: https://hudson.wedontsleep.org/job/db-devel/265/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12190
<LPCIBot> included.
<lifeless> abentley: hi, if you're around, could you comment on the expected behaviour in bug 702524 ?
<_mup_> Bug #702524: Merged branches keep 'Development' status when their merge proposal is marked as 'Merged' <Launchpad itself:New> < https://launchpad.net/bugs/702524 >
<abentley> lifeless, the expected behaviour is that the branch scanner will detect merges.
<lifeless> abentley: and change the branch state from 'development' to 'merged' ?
<lifeless> abentley: its clearly detecting the merge, or the merge proposal wouldn't be changed to 'merged'
<abentley> lifeless, per-branch detection of "merged" isn't tied to whether there is a merged merge proposal, and I believe it pre-dates merge proposals.
<abentley> lifeless, I believe it depends on whether the branch has been merged into the development focus, but I'll have to check.
<lifeless> abentley: if you could check that would be awesome; I mean - it seems like a reasonable request that this mark the branch as merged, but if there is a reason we don't, we can say so.
<abentley> lifeless, we only mark a merge if it's a merge into the development focus, OR if there's a merge proposal and it's a merge into a series branch.
<abentley> lifeless, thumper may have a better idea of the reasoning behind this.
<lifeless> thanks
<lifeless> hmm, thumper should be around anytime now ;)
<abentley> lifeless, he's around.  We just had a chat.
<abentley> lifeless, he's just on a call right now.
<lifeless> thanks!
<lifeless> jml: https://lpstats.canonical.com/graphs/KarmaActivityUpstreamsUbuntuWeek/20100114/20110114/
<pcjc2> gah - internal only
<jml> lifeless: yes?
<lifeless> jml: poking around at our popularity via various proxies
<jml> lifeless: oh, right. are you working on my talk for next week? :P
<lifeless> I don't know... are you working on mine?
<lifeless> jml: is there an 'active in the last month' ?
<jml> lifeless: yes.
<jml> lifeless: it's in the same area
<lifeless> jml: I'd like to see how much churn/low frequency use there is
<jml> lifeless: https://lpstats.canonical.com/graphs/KarmaActivePeople/
<jml> lifeless: the data starts at ~2007-07-01
<jml> lifeless: I find it useful to look at the whole of it when consulting those graphs
<jml> lifeless: the Ubuntu release cycles become more obvious
<lifeless> yeah
<lifeless> the troughs are near identical
<lifeless> pcjc2: sorry :)
<micahg> lifeless: regarding edge URLs, granted the redirect will send people to the right place, but shouldn't the code be fixed not to send out e-mails with it?
<lifeless> micahg: the code sends out emails based on the url they hit
<micahg> lifeless: ah, so the user posting the comment was on edge
<lifeless> micahg: 'fixing' it would be special casing edge as a domain to ignore even if running on edge
<lifeless> which is just the sort of thing I want to be cleaning up, not adding :)
<lifeless> micahg: yes, I very much expect they were
<micahg> ah, ok, sorry, I thought the URL was because of me and not the person using LP
<micahg> I confirmed this, I have some e-mails with non-edge URLs
<micahg> sorry for the noise
<lifeless> no worries
<huwshimi> Morning all
<mwhudson> hello huwshimi
<StevenK> huwshimi: Morning! When do you fly out?
<huwshimi> StevenK: In two days (Sunday Sydney time arrive Sunday Dallas time).
<StevenK> huwshimi: Yes, I also live in Sydney, so I had that fun last weekend.
<huwshimi> StevenK: Oh great. Will be nice to meet some fellow Sydney siders
<StevenK> huwshimi: It's awesome we have to fly for 20-ish hours to meet each other
<huwshimi> StevenK: Haha, only a little more than on a train to meet here though.
<huwshimi> Hey, is anyone able to review a CSS bug fix (bug #684911: https://code.launchpad.net/~huwshimi/launchpad/broken-calendar-684911/+merge/46208)?
<_mup_> Bug #684911: calendar overlay widget style broken after lazr-js 191 upgrade <javascript> <lazr-js-upgrade> <lp-web> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684911 >
<thumper> huwshimi: ask sinzui in #launchpad-reviews :)
<huwshimi> thumper: Ok thanks.
#launchpad-dev 2011-01-14
<jml> sinzui is probably offline now
<jml> btw
<jml> we're getting a whole bunch of script failed to run errors
<pcjc2> lifeless: Please hold that MP, it is broken
<lifeless> pcjc2: ec2 should bounce it
<lifeless> how is it bust?
<pcjc2> I moved the EXISTS() into the clause generator, but stupidly put it _inside_ the clasuse which is UNION'd when you have more than one tag queried
<lifeless> whee
<pcjc2> So I moved the EXISTS outside the join, but now have to return "None" for the no-tags passed case
<pcjc2> seems like a plan
<pcjc2> that's why I shouldn't code when tired
 * pcjc2 aims clue-bat at own head
<pcjc2> I _thought_ I had run the tests
<lifeless> pcjc2: have you pushed?
<pcjc2> yes
 * pcjc2 hopes this time it is not completely broken
<pcjc2> will be worth giving it another quick review though.. as it has changed a little
<pcjc2> Only bugtask.py has changed since the last push
<pcjc2> I guess real LP developers have lots of irons in the fire at once.. for all the pause-time running tests etc..
<pcjc2> high throughput, high latency
<lifeless> a bit yeah
<lifeless> pcjc2: kicked it off
<pcjc2> Thanks
<pcjc2> EC2 is a cloud server instance?
<lifeless> amazon ec2
<pcjc2> ok - had no idea you used Amazon servers
<pcjc2> is that just for testing?
<lifeless> =yes
<lifeless> ok, its away
<LPCIBot> Project db-devel build (266): STILL FAILING in 4 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/266/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12191
<LPCIBot> included.
<LPCIBot> * Launchpad Patch Queue Manager: [r=abel,
<LPCIBot> stub][ui=none][bug=276488] Add a nameblacklist admin field that
<LPCIBot> exempty the assigned team from the restriction.
<LPCIBot> Project devel build (358): STILL FAILING in 4 hr 28 min: https://hudson.wedontsleep.org/job/devel/358/
<LPCIBot> * Launchpad Patch Queue Manager: [r=benji,
<LPCIBot> edwin-grubbs][ui=none][bug=696913] Adds doNotSnapshot to fields
<LPCIBot> involved in OOPSes with ShortlistTooBigErrors.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Upgrade the version of Twisted that Launchpad
<LPCIBot> uses from 10.1 to 10.2, preserving the patch for Twisted bug 4395.
<_mup_> Bug #4395: wings3d: merge new debian version <wings3d (Ubuntu):Fix Released> < https://launchpad.net/bugs/4395 >
<wgrant> Hmm, those two errors look gmpy-related.
<jelmer> wgrant: which ones?
<wgrant> jelmer: Hudson's. entitlement.txt and looptuner.txt
<wgrant> I don't know why gmpy would be installed there, though.
<lifeless> for codehosting ssh exchange performance
<wgrant> Uhoh.
<lifeless> wgrant: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/
<wgrant> lifeless: OK, I see your point, but test failures.
<lifeless> wgrant: agreed
<lifeless> wgrant: not sure whats up there
<lifeless> wgrant: given it had to go through bb etc
<wgrant> lifeless: I bet buildbot doesn't have python-gmpy installed.
<wgrant> I can reproduce locally once I install it.
<lifeless> perhaps it wasn't added to the deps?
<lifeless> or $something
<wgrant> It wasn't, AFAICT.
<wgrant> Hmm.
<wgrant> Why does codehosting send me the URL to the MP twice?
<wgrant> In MP emails, that is.
<wgrant> For more details, see:
<wgrant> https://code.launchpad.net/~wgrant/launchpad/rebuilds-without-nai/+merge/46070
<wgrant> -- https://code.launchpad.net/~wgrant/launchpad/rebuilds-without-nai/+merge/46070 You are the owner of lp:~wgrant/launchpad/rebuilds-without-nai.
<thumper> lifeless: that drop is pretty awesome
<wgrant> I'd go a bit further than that.
<wgrant> Although that could be because qastaging's bzr is broken.
<lifeless> is it?
<wgrant> bzr: ERROR: Server sent an unexpected error: ('error', 'No module named bzrdir')
<poolie> oops
<lifeless> heh!
<lifeless> jam: ^
 * thumper chuckles
<wgrant> Is qastaging running the forking lp-serve thing?
<lifeless> yes
<jam> wgrant: well, the graph is doing "hello" which does work on qastaging
<jam> "echo hello | ssh bazaar.qastaging.launchpad.net bzr serve --inet --directory=/ --allow-writes"
<jam> however, there is, indeed, something broken
<jam> lifeless: is there a place where qastaging log files will be copied, such that I can get a look at them?
<jam> knowing who is asking for bzrdir and not finding it would be helpful
<wgrant> tellurium's codehosting-access.log is a couple of months out of date on carob :(
<wgrant> I wonder if the qastaging stuff doesn't sync yet.
<jam> the log file is at /srv/bazaar.qastaging.launchpad.net/qastaging-logs/codehosting/bzr-lp-forking-service.log
<jam> or possibly another one
<wgrant> Nothing like that on carob.
<wgrant> spm: ^^ are qastaging codehosting logs not syncing?
<pcjc2> goodnight
<lifeless> jam: devpad
<jam> wgrant: well, I did check again that running the service locally works, and I can push through local codehosting
<jam> lifeless: looking at /srv/launchpad.net-logs/qastaging doesn't have much
<wgrant> Hmm, odd.
<jam> wgrant: yeah
<lifeless> check with losas in -ops
<wgrant> jam: There is some stuff under /srv/launchpad.net-logs/staging/tellurium/codehosting.
<lifeless> ah, you are
<jam> lifeless: no response yet
<wgrant> But nothing from qastaging, and nothing since November.
<wgrant> So it may have all broken when qastaging was introduced.
<wgrant>    811.51s  OOPS-1839REPORTIFSEEN1172  None
<wgrant> Yay
<lifeless> wgrant: that means something running as 'production'
<wgrant> lifeless: I know. I was just surprised to see it being used for something that takes >10 minutes.
<wgrant> I thought it would be mostly tiny things that nobody has looked at for 5 years.
<lifeless> wgrant: right, so the question is do we want to bless doing this, or move them to another config
<wgrant> lifeless: Kill them.
<wgrant> I need to do a similar thing to cesium.
<wgrant> It uses the ftpmaster config :(
<lifeless> wgrant: if you're looking at this stuff, I'd love it if you file some bugs
<lifeless> (Or JFDI)
<wgrant> lifeless: Or we could adopt your OOPS naming strategy.
<wgrant> And then we can delete most of the configs.
<spm> <wgrant> spm: ^^ are qastaging codehosting logs not syncing? <== no. never been setup to
<wgrant> spm: :(
<lifeless> wgrant: I want to do that
<lifeless> spm: please do?!
<spm> yeah, am atm. needs rotatin' as well
<spm> fwiw, have I ever mention just how much I despise the default twistd logging?
<spm> log rotation*
<wgrant> Why does Australia fail at summer?
<wgrant> Now we are flooding too :(
 * spm tries not too feel smug at 650m above sea level
<lifeless> spm: thanks
 * wgrant throws a few buckets of water at spm.
<spm> ta, but we've had enough rain lately. thanks tho! ;-)
<wgrant> :(
<spm> still overcast today. yeck.
<wgrant> The weather today is pretty nice.
<wgrant> Except that the ground is so saturated that parts of my floor appear to be exuding water.
<wgrant> The humidity is <90%, though, which is a pleasant change.
<spm> heh, we all start dying from excessive humidity when it gets above 25%
<spm> the yak shaving on tellurium continues. just about in tears of laughter here.....
<wgrant> I see we have a directory, but no content. It does sound fun.
<spm> I was being excessively optimistic creating the directory, I feel
<spm> the yak, be shavÃ©d.
<wgrant> Indeed, thanks.
<wgrant> jam: There are logs now.
<wgrant> /srv/launchpad.net-logs/staging/tellurium/qastaging-codehosting/codehosting/bzr-lp-forking-service.log
<spiv> Hmm, did devpad's ssh host key change relatively recently?
<elmo> spiv: if by relatively recently you mean months ago, yes
<wgrant> It changed from sodium to carob at some point over a month ago.
<spiv> elmo: months ago is entirely possible.
<spiv> Thanks.
<LPCIBot> Project db-devel build (267): STILL FAILING in 4 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/267/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12192
<LPCIBot> included.
<LPCIBot> Project devel build (359): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/devel/359/
<LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Always use Python 2.6.
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][no-qa] Use the uploader db user for
<LPCIBot> ppa-add-missing-builds.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=697685] Adds validation to
<LPCIBot> RequestPeopleMergeView so that persons with PPAs cannot be merged.
 * huwshimi is off
<wgrant> huwshimi: See you in Dallas.
<huwshimi> wgrant: Yeah will do :)
<spm> have safe flights guys!
<lifeless> wgrant: when are you coming?
<maxb> hmm
<maxb> We need a way for the code import scheduler to not dispatch multiple jobs for the same svn repository to the same machine simultaneousl
<maxb> y
<spm> not sure if there's a bug for that; but that's been an operational issue for us before. so +1.
<maxb> Because for noteable one-repo-many-projects repositories (like Apache), we now can't start any new code imports, because they take so long to initialize the first time, another job comes along, and kills the long running one with a sqlite error
<wgrant> lifeless: I depart at midday on Sunday.
<maxb> Of course, this requires figuring out what it means to "be from the same repository"
<spm> yes :-)
<wgrant> lifeless: Arriving DFW at 15:10
<maxb> for which svn has a perfectly good UUID, but I can't think how to get it available in the DB/appservers
<wgrant> maxb: Particularly when it is the initial imports that often fail :(
<maxb> I suppose one possibility would be to cheat... add external whole-job locking by uuid to bzr-svn, such that it's any new jobs which fail, rather than new jobs killing jobs which have been running for hours
<wgrant> I can't think of much beyond making the import take a UUID-based lock.
<wgrant> Right.
<wgrant> Preferably making the subsequent jobs not really fail at all.
<maxb> Possibly adding a new "Skipped" job status, such.... snap :-)
<wgrant> But just rejecting them softly, not contributing to failure counts.
<jelmer> maxb: I think it'd be more worthwhile to spend time on the new cache format /or/ switch to tdb.
<maxb> We are of one mind :-)
<maxb> jelmer: My personal experiences with tdb are that it sucks badly once the cache gets into the gigabyte range
<maxb> Also the operational pain of needing to rebuild the cache for all code imports makes me weep
<jelmer> maxb: It's supposed to scale pretty well even in that regard
<jelmer> maxb: It's worked fine for larger branches for me in the past
<jelmer> maxb: are you on NFS?
<maxb> jelmer: it, uh, doesn't :-)
<maxb> I've gone back from tdb to sqlite for performance
<jelmer> maxb: Have you reproduced that recently?
<maxb> even though it triples the size of the file
<maxb> No NFS, just plain local disk
<maxb> I wouldn't say *recently*. On the other hand, I've not noticed any tdb updates in Ubuntu in a while
<jelmer> maxb: e.g. the bucket sizes are different these days
<spm> isn't tdb a tridge/samba thing? ergo perfect already?
<jelmer> spm: it's a tridge/rusty thing :-)
<spm> near enough... ;-)
<jelmer> there's a new format on the way with some improvements, but I'd be really surprised if the current performance is worse than sqlite
<maxb> jelmer: hmm. So, you think that might solve the problem of performance sucking unless the entire file was in kernel cache?
<jelmer> maxb: that depends entirely on the access patterns of the user
<maxb> access pattern: fetching svn rev info for ~1000 new revs
<jelmer> that shouldn't require having the entire db in the kernel cache in the current format either
 * jelmer gets some sleep
<al-maisan> good idea :)
 * maxb curses at private code imports causing the code import list pages to oops
<adeuring> good morning
<wgrant> mrevell: I'd like some advice on the PPA creation and edit UI, if you're free.
<mrevell> wgrant, I can be, although my day's pretty full. Is it something we could talk about next week? Perhaps with huwshimi.
<wgrant> mrevell: Sure.
<mrevell> Thanks. I'll make a note to ask you about it.
<wgrant> Thanks.
<LPCIBot> Project db-devel build (268): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/db-devel/268/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12193,
<LPCIBot> 12194, 12195, 12196 included.
<LPCIBot> Project devel build (360): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/devel/360/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=501945] Improve SQL efficiency when
<LPCIBot> searching for bugs by tag (Pre-filter by Bug.id)
<LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
<LPCIBot> Edwin][ui=none][bug=183372] Add a heartbeat to Mailman's xmlrpc log.
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][no-qa] Update loggerhead to get important bug
<LPCIBot> fixes and performance improvements.
<gmb> Is anyone else finding pushing branches to LP to be really slow or is it just my connection?
<deryck> Morning, all.
<pcjc2> hi
<allenap> mrevell: For the blueprints stats, did you want numbers per project (in the top 50), or just a total?
<mrevell> allenap, Per project, if that's okay, purlease
<allenap> mrevell: It is totally okay.
<mrevell> I have to state that I wasn't on lunch that long ... I just dived back into work without checking my IRC nick.
<pcjc2> Is the code for the Launchpad QA Bot available somewhere?
<mkanat> Looks like bazaar.qastaging.launchpad.net redirects infinitely, so I can't test loggerhead on qastaging.
<lifeless> pcjc2: Its not open sourced yet; it is planned to be
<pcjc2> ok - just I was writing something similar for git commits, and wondered if I could steal some ideas, that was all
<pcjc2> Design is going to be Git HOOK -> sqlite database with a "work queue" -> gpleda.org robot -> LP
<pcjc2> The database in the middle is to absorb any grief which might happen if LP is down when commits come in
<pcjc2> Possibly not an issue for the QA bot
<mkanat> pcjc2: I'd be surprised if there isn't already such a system for git.
<pcjc2> I wouldn't know where to look for it..
<mkanat> pcjc2: #git would know.
<pcjc2> I'm also writing (going to write) a small patch to our gitweb instance to look for the same "Closes-bug: lp-12345" syntax we intend to use, and link to LP
<pcjc2> lifeless: When will that merged bug tag code hit staging?
<pcjc2> (Or has it done so already - bug is tagged qa-needstesting)
<lifeless> qastaging.launchpad.net has it already
<lifeless> I was just going to do a few searches and see how it looks
<pcjc2> ok- I was testing on staging
<pcjc2> inkscape fails on staging
<lifeless> staging is where things with db schema patches, and some specific services are qa'd
<pcjc2> damn - also fails on qastaging
<lifeless> qastaging is where things that can be continuously deployed are tested
<lifeless> works for me
<lifeless> I did a search on launchpad for tag -*
<lifeless> ok
<lifeless> copied the search to production
<pcjc2> works now
<lifeless> fail
<lifeless> you can hit cold cache effects
<pcjc2> I had a search URL from staging, changed to "qastaging"
<lifeless> staging has 64GB or ram or something small like that
<pcjc2> so cold cache -> timeout?
<lifeless> db size is 250GB
<pcjc2> ok, but there is some improvement on qastaging
<pcjc2> one can at least perform the query
<lifeless> at this stage in our performance overhaul we generally are happy if it works a second time
<pcjc2> I'm amazed that on inkscape, out of 2805 open bugs, there are only 288 without tags
<pcjc2> This was the kind of query I originally wanted to do on our bugs (but I realised afterwards that we imported everything with _some_ tag, so it doesn't help so much)
<pcjc2> Is there a better place than a bug report to file feature requests / design ideas?
<pcjc2> Two ideas in my head right now...
<pcjc2> Advanced search link (from inside an existing advanced search) should keep the current search terms selected
<lifeless> facet based search
<lifeless> strongly desired, very sure its already a bug
<pcjc2> It would be nice to do a search, then work through all those bugs - with an added "Next" "Previous" (whatever) nagivation overlayered on the bug page
<pcjc2> So one could find all bugs with no tags (for example), then click through them one by one tagging them
<pcjc2> without having to go back to the original search
<lifeless> a bit like gmail? :) I don't recall seeing a bug for that, but that could be nice
<pcjc2> I've not used gmail in ages, so couldn't comment
<pcjc2> I was just thinking ... "what am I trying to do.." and "how could it be easier?"
<pcjc2> Rather than features for the sake of features
<gmb> pcjc2: Are you thinking about multiple bug editing here?
<gmb> That's something we've wanted for donkey's ages.
<pcjc2> yes and no.. edit one at once, but page through them
<gmb> Ah, I see.
<pcjc2> bonus points for letting a project save particular search queries they work with often
<pcjc2> find all bugs tagged "fruit"
<gmb> That would be nice. I can definitely see myself using that.
<pcjc2> I don't know how it would be done technically
<pcjc2> Perhaps one could add "next bug" and "previous bug" links to every bug page
<pcjc2> and then allow a concept of an active filter / search which reduces your view of bugs
<pcjc2> would need to think of a UI to specify / show the collection context
<pcjc2> IE.. am I looking at the "next bug" assigned to me?
<pcjc2> in the project?
<pcjc2> In the search results?
<allenap> mrevell: How do you want the results ordered? By the number of specifications for each project, or the project name?
<gmb> pcjc2: If you could look at a bug in the context of a specific group of bugs it could make sense. e.g.:
<gmb> bugs.lp.n/~gmb/launchpad/+assignedbugs/12345
<gmb> Though the URL construction logic could be a bit torturous.
<gmb> (I think that's how Gmail does it, but I'm not sure).
<pcjc2> lots of possibilities once you start wanting to do it for arbitrary searches
<pcjc2> I think we should support saving searches as a resource
<pcjc2> either against a project, or person / team
<gmb> pcjc2: It's on our to-do list.
<gmb> Or at least our want-to-do list
<gmb> kiko called it "Bug Bags" in 2008, I remember that much.
<gmb> Mainly because he told me roughly what that meant and I had to explain it to a lot of people.
<gmb> Actually, I think Bug Bags were arbitrary groupings of bugs to which you could add new ones if you wished. A bit like tags but personal to the user.
<wgrant> I think they were ordered, too.
<wgrant> But I don't think we heard anything about them after UDS Jaunty...
<pcjc2> Also - is it me, or is LP missing a "related bugs" feature
<pcjc2> where something is not quite a duplicate.. but may be relevant
<gmb> wgrant: They're a kiko feature: Kind of ephemeral until lifeless decides to do it.
<wgrant> Heh.
<gmb> pcjc2: YES.
<LPCIBot> Project db-devel build (269): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/db-devel/269/
<gmb> A thousand times yes.
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12197
<LPCIBot> included.
<StevenK> Rargh
<pcjc2> And possibly "blocks bug" / "blocked by bug" relationship between 2x or more bugs
<mrevell> allenap, I don't think I mind.
<mrevell> allenap, number of specs I s'ppose
<pcjc2> quote 'the "bug bag" functionality that will come with LP 3.0'
<pcjc2> From https://wiki.edubuntu.org/UDSJaunty/Report/QA
<gmb> pcjc2: Bug relationships are my number one thing-to-do.
<pcjc2> awesome - then I won't feel the need to file a feature request about that
<pcjc2> I'm considering the "bug bag" / bug collection idea though.. (currently looking for docs on the old bug bag idea)
<gmb> I really hope that that feature will get assigned to my new squad when its time comes.
<pcjc2> what is your squad?
<wgrant> mrevell, allenap: https://pastebin.canonical.com/41512/ is the top 50 project blueprint totals, if that's what you're after. mpt asked for it a couple of weeks back.
<gmb> (Flacoste, lifeless: Take note, I will cry like a man-baby if we don't get that one).
<gmb> pcjc2: The yellow squad. I'm told that we're not going to be the yellow squad for very long, though :)
<pcjc2> (Or is it just - when the dev cycle rolls around to your turn for feature development in that area again?)
<gmb> pcjc2: Well, we're reorganising, so that's the general plan.
<gmb> Basically, you have N squads, N-2 of which are assigned to feature work. The other 2 deal with bugs on a day-to-day basis.
<pcjc2> I read the posts about it, sounds like a good plan
<gmb> Once a feature's complete, the feature squad becomes a Triage / bugfix squad and one of the existing squads becomes a feature squad.
<gmb> pcjc2: The new structure takes effect next week when we sprint in Dallas.
<allenap> wgrant: I'm getting some more fiddly stats than that, but thanks anyway :)
<wgrant> Ah, OK.
<bigjools> wgrant: go. to. sleep.
<pcjc2> Not to be ungrateful, but search ought to be more AJAXy
<LPCIBot> Project devel build (361): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/devel/361/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=701947][no-qa] Cull a load of unnecessary
<LPCIBot> .count()s in favour of less-expensive SQL.
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=sinzui][bug=702694] Tweak the text on the
<LPCIBot> +daily-builds page.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=680733] Fix the recipe view's builds so
<LPCIBot> broken builds don't get stuck at the top of the list.
<gmb> pcjc2: Again, a thousand times yes.
<lifeless> hmm, I need to people with PPAs to qa bug 697685
<_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts <merge-deactivate> <ppas> <qa-needstesting> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/697685 >
<wgrant> bigjools: I was just resending an ec2 instance that failed because of a conflict
<wgrant> !
<bigjools> is that the conflict I warned you about? :)
<wgrant> Yes.
<wgrant> Shh.
<pcjc2> gmb: Does this get you something: http://onecall.farnell.com/jsp/search/browse.jsp?N=411+500003+1000224&Ntk=gensearch_001&Ntt=100uF+25V&Ntx=mode+matchallpartial
<flacoste> gmb: noted
<pcjc2> Might be tied to my session though
<flacoste> gmb: why won't you the yellow ones for long?
<gmb> flacoste: I think there's a general sense that we want to be the Gold Squad ;)
<gmb> (Or something)
<gmb> I jest.
<flacoste> lol
<flacoste> yellow gold
<flacoste> not to be confused with yyykon gold
<flacoste> yukon gold
<bigjools> I need something better than Red, I shall be asking my team next week
<flacoste> bigjools: as you as you are not the Reds
<bigjools> I cannot possibly be associated with red :)
<bigjools> flacoste: the google spreadsheet says Red
<pcjc2> gmb: That is a nice example of ajax search (even if the results are manually updated). The only missing feature is the ability to exclude based upon a given field
<pcjc2> IE. "Not 25V DC"
<pcjc2> Combine that search functionality, the ability to negate the filters.. and a means to save a given query.. we would have awesome
<allenap> bigjools: Come on, red is good :)
<gmb> pcjc2: That's a reasonable example. I think we'd want to aim for a slightly slicker UI, but it would be a good first step.
<bigjools> allenap: I don't want to be Red Ed
<StevenK> Hahaha
<pcjc2> It is usable - I agree you want slicker
 * StevenK keep that in mind for next week
<allenap> bigjools: Glitter then.
<bigjools> allenap: lol
<bigjools> that would be gary's team....
<gmb> OI.
<allenap> Of course!
<gary_poster> :-)
<pcjc2> Silly ideas in abundance here.. what about reverse AJAX for pushing updates to bugs whilst one has the page open?
<pcjc2> Often I find I'm working on bugs with other developers, and we have to keep hitting refresh
<lifeless> bigjools: any idea how to qa http://launchpad.net/bugs/680733 ?
<_mup_> Bug #680733: broken recipe build gets stuck at top of "5 latest builds" list on recipe page, forever <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/680733 >
<StevenK> If the Launchpad squards are going to named like that, there will be a beating next week
<gary_poster> I was thinking Gold Lame, per gmb.  Or maybe Yellow Bellies (Americanism for cowards).
<bigjools> lifeless: checking
<bigjools> StevenK: maybe something that alliterates with the squad leader's name then
<bigjools> Gary's Gang, for example
<gary_poster> heh
 * gary_poster tries to recall the names of the two gangs in West Side Story...
<gary_poster> Jets and...
<gary_poster> ah, yes, Sharks
<jcsackett> lifeless: don't worry about bug 697685. i just qa'ed. thanks for getting my other bug, btw. :-)
<_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts <merge-deactivate> <ppas> <qa-ok> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/697685 >
<lifeless> jcsackett: sweet, thanks
<bigjools> lifeless: no... :/
<bigjools> lifeless: the URL is invalid on qastaging... ummm
<lifeless> anyone know of a team with recipes on qastaging ?
<bigjools> https://code.qastaging.launchpad.net/~bzr/ is repeatedly timing out
<lifeless> yeah, its high on the ppr but not a timeout on prod atm
<lifeless> well we're clear to 12201
<lifeless> be nice to get 12201 and 12202 in the deploy
<flacoste> bac: did you start the wiki page for the review discussion of next week?
<lifeless> pcjc2: your fix should be live in ~ 20 minutes
<pcjc2> exciting stuff
<spiv> StevenK: I hear you're looking at a pow/gmpy doctest failure?
<StevenK> Yes
<StevenK> I think we have it
<spiv> StevenK: different repr() for values returned from pow(...) ?
<lifeless> spiv: loop tuner showing different perturbations
<spiv> lifeless: ah, pow(float(some_int), ...) returning an integer rather than a float?
<lifeless> returns an mpz
<spiv> Right
<lifeless> that in one case we have
<lifeless> class.int_colum = pow(9,10)
<lifeless> so that generates a TypeError
<spiv> *nod*
<spiv> I'd be happy to add eyeballs to reviewing a fix, if anyone wants.
<lifeless> we're just using math.pow in the lp suite
<spiv> Sounds reasonable.
<lifeless> spiv: possibly the conch pow hack should not cast floats
<lifeless> e.g. only int -> mpz
<lifeless> and float -> mpq
<spiv> lifeless: yeah, possibly.  Or PyCrypto should be changed to automatically use gmpy when it is availabe
<spiv> Then Conch wouldn't need to override the builtin pow.
<lifeless> spiv: actually, does it cast float -> mpz? cause that would be -wrong-
<spiv> lifeless: that's ok, because floats are wrong by definition ;)
<lifeless> float -> mpf is better
 * spiv looks
<spiv> lifeless: it unconditionally casts to mpz :(
<lifeless> spiv: now this, if you care to fix, would be good
<lifeless> I guess it means looking at pycrypto to see if it actually uses longs or floats
<spiv> crypto?  With floats?
<lifeless> python coders
<spiv> heh.
<spiv> Point taken.
<StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/gmpy-fix/+merge/46278
<lifeless> pcjc2: its live
<lifeless> Ursinha-nom: hi; I wonder if you could include a little more context in bugs like https://bugs.launchpad.net/bzr/+bug/702914 - I've updated it
<_mup_> Bug #702914: AttributeError OOPS in codebrowse <codebrowse> <oops> <Bazaar:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702914 >
<spiv> lifeless, StevenK: I've filed http://twistedmatrix.com/trac/ticket/4803
<lifeless> Ursinha-nom: also oops are critical + triaged status
<lifeless> spiv: thanks
<spiv> And will make a patch
<lifeless> spiv: awesome
<lifeless> Ursinha-nom: the goal being that folk without access to the oops db should be able to make some sense of the bug ( unless its got prvate data of course)
<lifeless> StevenK: I filed bug 702933
<_mup_> Bug #702933: IntColumn raises TypeError on assignment of an mpz <Storm:New> < https://launchpad.net/bugs/702933 >
<lifeless> StevenK: as we have no cases in core code I'm not going to do a patch just yet
<lifeless> sinzui: rt 43392 may interest you -
<lifeless> I think I captured enough data, but perhaps more needs to be said (on it?)
<sinzui> I cannot access the rt system
<lifeless> ah
<lifeless> natty?
<sinzui> Is this about nagio + mailman
<lifeless> yes
<sinzui> lifeless, no. I do not have working credentials for rt
<Ursinha-nom> lifeless, I would include more context if I have it :)
<lifeless> Ursinha-nom: just copy more of the backtrace :)
<lifeless> Ursinha-nom: the url from the oops report
<Ursinha-nom> lifeless, the oops becomes a link
<Ursinha-nom> ah, ok
<Ursinha-nom> got it
<lifeless> Ursinha-nom: yes, but e.g. mkanat (who does loggerhead things) cannot see the raw oops, so we need to decide whats safe and expose it
<lifeless> ditto adi roban for translations patches
<lifeless> wgrant until we hired him
<Ursinha-nom> lifeless, sure, I can do that :)
<lifeless> thank you!
<lifeless> pcjc2: were you going to look at a CVE issue too?
<lifeless> sinzui: bug 162510 - IIRC some job has been created for that?
<_mup_> Bug #162510: Person:+delete timeouts : Person merging needs to be done asynchronously <canonical-losa-lp> <chr> <feature> <lp-registry> <merge-deactivate> <tech-debt> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/162510 >
<sinzui> lifeless no. We have a table and a generic job that could be adapted to do the work
<sinzui> lifeless, http://launchpad.leankitkanban.com/Boards/Show/12749744
<sinzui> ^ it is in the back log to do, maybe in two weeks
<sinzui> lifeless is the mailman log change really fix released? The code is in production?
<lifeless> pretty sure
<lifeless> we did a nodowntime deploy
<pcjc2> @lifeless: RE: CVE issue, didn't find a time-out which matched, but can file a bug for updating the code to be more efficient, like the tags one is
<lifeless> jml: how important in the scheme of things is the rosetta translation statistics being up to date?
<jml> lifeless: I don't know.
<lifeless> jml: we don't run the daily stats effectively at the moment because its too sensitive to cluster replication lag
<lifeless> danilo feels that having stats up to date is a critical thing
<lifeless> I think that I don't know and its a product owner question :)
<lifeless> the technical work is fairly shallow, FWIW
<jml> lifeless: I'll talk w/ danilos
<danilos> jml, ok
<jml> now's not a great time
<danilos> jml, ok
<pcjc2> Anyone else seeing this bug..
<pcjc2> Go to a bug, edit its tags. (Have a pop-up auto-complete box appear)
<pcjc2> After completing tag editing, the auto-complete layer stays visible
<pcjc2> Does not happen if you cancel editing, only if you confirm it
<lifeless> bug in chromium support
<lifeless> its filed
<pcjc2> Its not chrome i'm using.. epiphany, which is webkit
<lifeless> so is chrome
<lifeless> so its a webkit thing
<pcjc2> ok, didn't know that.
<lifeless> hmm, I was sure it was filed
<bigjools> I've seen that happen in FF as well
<pcjc2> Just wondered if it was a new bug, as I'd not seen it before now
<lifeless> gary-lunch: is bug 381617 fix released in lazr-js ?
<_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
<bigjools> I forgot how to re-create it
<pcjc2> I'm tempted to feature-request a tag search which can "?sf-bugs -*"
<lifeless> in english ?
<pcjc2> as in I want to find bugs which have no tags - other than not caring whether they have the sf-bugs tag or not
<pcjc2> I don't think that is achievable with the current queries, although I might be wrong there
<pcjc2> or -!sf-bugs
<lifeless> no tags other than sf-bugs
<pcjc2> indeed
<pcjc2> although our query might be "find bugs which have no tags aside from sf-bugs, sf-patches, sf-feature-requesets..."
<lifeless> sure
<lifeless> uhm
<pcjc2> Still - there is the API which can help with that
<lifeless> feel free to file it
<lifeless> search isn't currently in the main bits being overhauled, but a patch to do it would be gladly reviewed
<pcjc2> I suspect it could well be rolled up if / when search is overhauled
<pcjc2> gmb sounded keen to make it nicer
<pcjc2> Its a difficult problem - we are effectively trying to present the user with an efficient way to convey what might be quite a complex SQL query
<pcjc2> And harder if we wanted to go further, and allow regexp matches against tag names
<jml> pcjc2: there are examples of similar interfaces in trac, rememberthemilk and gmail
<pcjc2> Can the DB do a regexp match, or do you have to pull a list of all tags for the given search scope and then filter down to get a list of bugs?
<jml> pcjc2: lots of us are very keen to make search nicer. I suspect a motivated volunteer would find help easily :)
<pcjc2> I don't think I've got the time to dedicate to it at the moment - other priorities
<pcjc2> I would love to do it, but there would be a learning steep curve involved
<pcjc2> I can't take on any more unpaid mega-tasks at the moment though
 * jml understands
<jml> but I still don't regret fishing :)
<pcjc2> No - I'd be very tempted if circumstances were different
<pcjc2> If you edit tags and specify something wrong (lets say, use an illegal character, such as "," between tags, the page basically gets stuck
<pcjc2> with no way to cancel or re-edit the tags
<pcjc2> Is that related to the existing filed tags bug?
<lifeless> I think you should file that
<pcjc2> will do
<gary_poster> lifeless: I have no idea.  I was on the periphery of lazr-js.  mars, when you return, please update bug 381617 as fix-released, assuming it was.
<_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
<lifeless> gary_poster: thanks
<gary_poster> np
<lifeless> mars: 07:26 < gary_poster> lifeless: I have no idea.  I was on the periphery of lazr-js.  mars, when you return, please update bug 381617 as fix-released, assuming it was.
<_mup_> Bug #381617: Inline tags autocomplete displays in the wrong location <javascript> <lp-bugs> <ui> <Launchpad itself:Fix Released by mars> <LAZR Javascript Library:Fix Committed by mars> < https://launchpad.net/bugs/381617 >
<gary_poster> :-)
<mars> gary_poster, lifeless, will do
<gary_poster> thank you
<mars> done
<mars> gary_poster, did I miss anything else?  Was fighting an Intel GPU crash
<gary_poster> thanks mars.  not that I know of
<mars> thanks
<gary_poster> I hope you won :-)
<mars> nope!  Had to do a hard reboot.
<gary_poster> :-/
<mars> The X201 does not like you using the 'Display Switch' button after docked, and then you undocking.  Crashes the GPU, cascades to crashing the shutdown syslog daemon (preventing shutdown)
<mars> Still an awesome laptop though
<StevenK> mars: I got an X201 as well :-)
<mars> StevenK, excellent choice! :)
<mars> I have it as my primary system now, using a dock and my 24" monitor and speakers
<mars> Best of both worlds: more powerful than my previous desktop, same screen size, and ultra-portable in a flash
<mars> (except for that GPU bug)
<LPCIBot> Project db-devel build (270): STILL FAILING in 4 hr 27 min: https://hudson.wedontsleep.org/job/db-devel/270/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12198,
<LPCIBot> 12199, 12200, 12201, 12202 included.
<LPCIBot> Project devel build (362): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/362/
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=656823] Correct the description of a bug
<LPCIBot> subscription filter that has no conditions. A filter without
<LPCIBot> conditions actually allows all mail through,
<LPCIBot> not no mail through as previously claimed.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=656823] UI to delete bug subscription
<LPCIBot> filters.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=656823] UI for creating new bug
<LPCIBot> subscription filters.
<LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson,
<LPCIBot> stevenk][ui=none][bug=697255] Fix the source package recipe build
<LPCIBot> title for deleted recipes.
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards, mwhudson,
<LPCIBot> stevenk][ui=none][bug=692814] Make recipe builds live under the
<LPCIBot> archive, not the recipe.
<lifeless> flacoste: two ideas for graphs
<lifeless> the 99% time, weekly report rather than daily, for a smoother trend line
<lifeless> and a non-api 99% time (Which I'm filing a bug on now)
<flacoste> lifeless: a moving weekly average?
<lifeless> flacoste: that would be interesting too
<flacoste> yeah, i thought of that one
<flacoste> because otherwise, we'd have only one point per week
<lifeless> lastly I'd love to have a | marker when we deploy and a || for db deploys
<lifeless> gmb: we need to talk features & API
<lifeless> gmb: I'm not sure it makes a great deal of sense to expose arbitrary flag queries on the api
<lifeless> gmb: for performance and sanity reasons
<Ursinha> I'm constantly getting connection timed out when trying to push a branch to launchpad... is that just me?
<lifeless> I sure hope su
<lifeless> what does it say?
<lifeless> https://lpstats.canonical.com/graphs/CodehostingPerformance/ is interesting
<lifeless> https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ seems ok
<lifeless> Ursinha: what does bzr say ?
<Ursinha> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
<Ursinha> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Ursinha> that happened yesterday as well, and worked without me doing nothing but trying
<Ursinha> lifeless, ^
<StevenK> sinzui: I can get Neil's attention here to help you with Unity over IRC if you wish.
<sinzui> I think I just need to wait for all the parts to build and mirrors updated. I just got a few items built in the last 3 hours
<sinzui> I think I am waiting on unity or compiz parts to arrive
<lifeless> mbarnett: ^
<lifeless> Ursinha: whats your ip address?
<lifeless> so we can look that up in the access log
<lifeless> mbarnett: can you look in the twistd.log and access.log for codehosting
<mbarnett> sorry, was answering on the other channel
<mbarnett> codehosting-access.log.1:2011-01-13 18:44:48,676 INFO [83012064] IPv4Address(TCP, '201.82.195.142', 57421) connected.
<mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,345 INFO [83012064] ursinha logged in.
<mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,434 INFO [87931288] failed to authenticate.
<mbarnett> left out:
<mbarnett> codehosting-access.log.1-2011-01-13 18:44:50,434 INFO [87931288] disconnected.
 * StevenK attempts to subvert bzr sufficently
 * jelmer hands StevenK subvertpy
<StevenK> Good, because using sftp manually isn't working
<jelmer> :-(
<pcjc2> lifeless: That bug you wanted me to file is Bug #703061
<_mup_> Bug #703061: Tags edit with syntax error makes further tag editing impossible <lp-bugs> <ui> <Launchpad itself:New> < https://launchpad.net/bugs/703061 >
<StevenK> Right, still no diff :-(
<gary_poster> lifeless, I want to move an old card off of the Foundations board as one of the last acts there: finishing ++profile++ so you can use it on staging.
<gary_poster> You wanted that done with a feature flag, I believe.  I have one guess as to why, but I'd rather be sure.  Why?
<gary_poster> If I were doing it without further input, I'd make a flag named something like "can-profile-on-staging" (meaning staging and qastaging) and then team:launchpad would have it set to True, with the possibility of opening it to others if desired.  Does that satisfy your needs, or do you have another requirement?
<deryck> Until Dallas then!  Have a nice weekend everyone.
<jml> gary_poster: lifeless is on a call right now. will be off soon.
<gary_poster> jml ack, thanks
<lifeless> gary_poster: I think just a flag control for the 'enabled' status
<lifeless> gary_poster: no need to tie it to staging specifically
<gary_poster> lifeless: that seems like an unnecessary risk to me
<gary_poster> lifeless: unless there's a compelling use case that supercedes the risk, of course
<lifeless> gary: hi
<gary_poster> hey
<lifeless> gary_poster: uhm, so I think code simplicity and clarity is important here
<lifeless> gary_poster: we don't label the config section 'profiling for developers'
<gary_poster> don't get the connection yet
<lifeless> gary_poster: if I was doing it, I would have the flag be (IIRC) profiling.enabled
<lifeless> the rule using team:launchpad, and only put it on on staging
<lifeless> gary_poster: there isn't a specific use case saying we must have it available on e.g. production
<lifeless> gary_poster: otoh if you're doing, you should do something that feels right to you.
<lifeless> gary_poster: one thing I will suggest is that the flag should -replace- one of the config settings
<gary_poster> lifeless, how do we put it only on staging?  can we do that only in one-offs?
<lifeless> the overall enabled one, I think.
<gary_poster> or can we do it once and have it stick?
<gary_poster> (which I would think is the desirable behavior)
<lifeless> gary_poster: I'd put it in a tiny post-restore hook
<lifeless> gary_poster: in the staging and qastaging restore scripts
<gary_poster> that spreads the configuration and behavior out more than I like.  This does feel like it is a matter of taste.  This isn't the way I'd do it, but I can do as you describe.
<lifeless> gary_poster: I have an alternative
<lifeless> but its more code
<lifeless> if feature flags scopes had an and operator
<lifeless> we could do
<gary_poster> I get you
<lifeless> server:staging and in_team:launchpad
<gary_poster> That's a lot of work for something that is not a requirement
<lifeless> if we put that on production, it would propogate to qastaging and staging
<gary_poster> Well, "a lot" may or may not be true
<gary_poster> but certainly more than is needed
<lifeless> gary_poster: the main thing for me is that the rule shouldn't refer to the server instance *in code* - thats config which should be in the rules.
<lifeless> otherwise we can't use it on e.g. dogfood, or developer machines, quite as easily
<lifeless> gary_poster: does that make sense?
<lifeless> brb fooding
<gary_poster> We disagree there--we have configuration abstractions for stuff like this--but I'm just going to follow your plan...essentially because you are TA, and I don't feel strongly enough about this to go further.  :-)
<gary_poster> I was intending developer machines to always have this behavior, irresepctive of the flag.
<gary_poster> But I'll proceed as described.
<lifeless> gary_poster: ah, interesting. But - thanks.
<lifeless> jam: https://launchpadlibrarian.net/1573330/emblem8.png
<jelmer> StevenK: I've fixed the bzr bug that was affecting you
<StevenK> \o/
<jelmer> StevenK: did the diff appear yet ?
 * StevenK worked around it
<lifeless> poolie: https://bugs.launchpad.net/launchpad/+bug/297398/comments/4
<_mup_> Bug #297398: support password/passphrase authentication for bazaar <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297398 >
<lifeless> jml: https://bugs.launchpad.net/launchpad/+bug/297398
<_mup_> Bug #297398: support password/passphrase authentication for bazaar <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297398 >
<lifeless> wgrant: does 363916 need to be private?
<StevenK> lifeless: You know, it's Saturday in .au, right?
<lifeless> StevenK: and?
<StevenK> lifeless: And no fair asking about work stuff on the weekend?
<lifeless> StevenK: he doesn't have to answer
<lifeless> StevenK: its not like I'm stalking in an unrelated channel; if he wants to sign off, he can.
<lifeless> I suspect, like I, his interest in Launchpad extends beyond a simple definition of work hours
 * StevenK decides that arguing is less fun when he is tired
<lifeless> StevenK: I don't think arguing is ever fun, FWIW.
<StevenK> No, trolling is much better, right?
<wgrant> lifeless: Probably not.
<lifeless> mars: do you know of an upstream bug for 664105
<lifeless> bug 644105
<_mup_> Bug #644105: remove basic auth (and passwords) - neither are used outside of the test suite <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/644105 >
<lifeless> that is, the windmill hostname crossing limitation
<LPCIBot> Project db-devel build (271): STILL FAILING in 4 hr 33 min: https://hudson.wedontsleep.org/job/db-devel/271/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12203,
<LPCIBot> 12204 included.
<LPCIBot> Project devel build (363): STILL FAILING in 4 hr 31 min: https://hudson.wedontsleep.org/job/devel/363/
<LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][bug=699719][incr] The code that sets up event
<LPCIBot> handlers for the bugtask:+index portlets has been moved into a
<LPCIBot> function so that we can better manage its behaviour using
<LPCIBot> feature flags.
<LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=701387] Drop unused
<LPCIBot> Archive.arm_builds_allowed.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb, leonardr][ui=none][bug=620458,
<LPCIBot> 629804] use LaunchpadWebServiceCaller to check the HTTP response in
<LPCIBot> test_user_access_to_private_bug_attachment()
<LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=matthew.revell][bug=676495] No oopses when rescoring
<LPCIBot> non-queued recipe builds.
<LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=607958] do not join unneeded target tables
<LPCIBot> in BugTaskSet.findExpirableBugTasks()
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=702260] Directly deleted library files no
<LPCIBot> longer cause the PackageDiff processor to crash.
<wgrant> sinzui: FWIW, I have similar natty issues.
<sinzui> \o/
<wgrant> sinzui: I can fix it by manually running metacity and then killing gnome-panel from a TTY.
<sinzui> ah
<StevenK> LPCIBot: Shush. I better have fixed you this devel build.
<wgrant> sinzui: Which video driver?
<sinzui> I reinstalled docky to give me a sense of status and what is running
<sinzui> I am using nvidia 173...
<lifeless> sinzui: hey
<lifeless> bug 697492 - I've made a few tweaks to it; I'm wondering if the fix is shallow or not
<_mup_> Bug #697492: user account suspension wants 'user password' reset too <canonical-losa-lp> <merge-deactivate> <tech-debt> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697492 >
<lifeless> specifically to just not /ask/ for a new password if an lp admin is suspending a user.
<sinzui> Well I am not sure an admin should be suspending users since the admin cannot undo the damage
<wgrant> sinzui: Can't they?
<sinzui> no
<wgrant> Even ~registry can suspend users...
<wgrant> Does suspending unset the preferredemail?
<sinzui> our code to restore an the email address and and password is never in the execution path since we switched to SSO
<wgrant> :(
<sinzui> Our code is happy to set the accept SSO authentication, set them as a principle with a know profile, then abandoning the poor user
<wgrant> lifeless: Could we hack around that Windmill issue by leaving a test-only basic auth path with a hardcoded password?
<sinzui> I cannot remember the bug that is tracking that. Gary may remember
<sinzui> I keep talking about the madness that no user should ever be set as the principle for a profile without an email address, but getting that fixed is very difficult
<wgrant> sinzui: Do we have a list of things that need to be fixed to make the authentication experience not suck?
<wgrant> StevenK: You've fixed the pow() issues?
<sinzui> gary has a very long wiki page describing the work that needs to be done
<StevenK> Yes
 * sinzui looks
<wgrant> sinzui: Does the cover the suspension issues?
<wgrant> StevenK: Yay.
<StevenK> wgrant: s/pow/math.pow/ since gmpy sucks
<wgrant> Hah.
<sinzui> wgrant, Yes. I wont let him forget
<sinzui> it
<sinzui> wgrant, https://dev.launchpad.net/LEP/OpenIdRoadmap
<wgrant> sinzui: Does the first step require any code?
<sinzui> lifeless, the immediate fix for the losa is to remove the password field from all forms. That is trivial and prevent admins from thinking they are changing passwords
<sinzui> wgrant, the first step of what
<wgrant> The first step of that roadmap: divorcing ShipIt. I mean, ideally ISD would spend two days rewriting it in Django. But since it appears they won't, it should probably just have a fork of LP and its database.
<sinzui> wgrant, I am not sure how fast ISD is progressing on that issue
<wgrant> It's such a trivial app :(
<sinzui> wgrant, an I perplexed about the rules for provisioning a lp profile. I do not know what is hard about checking if it is in a usable state
<wgrant> sinzui: Which rules?
<wgrant> In "thoughts?"?
<sinzui> Those in webapp authentication somewhere
<sinzui> wgrant I was thinking of servicing part of the issue for myself by giving ~registry the power to see suspended users, and updating that form to restore the user email address when the status is set active
<wgrant> sinzui: It seems to me that using the presence of preferredemail as an indicator of account status is unreasonably crackful.
<sinzui> possibly. Updating all Lp will take some work I think
<wgrant> Sure.
<sinzui> An I believe account is going away, so I do not know where status will live if it does
<wgrant> It'll need to live on person, but DEATH TO ACCOUNT.
#launchpad-dev 2011-01-15
<lifeless> wgrant: I want to cleanup the authentication logic in webapp
<sinzui> We did not and do not have a problem using email address to check validity. Our problem is that there are competing and conflicting rules. I am happy to have just one
<lifeless> \o/
<wgrant> lifeless: The hack should only be a couple of lines :/
<lifeless> closing 5-digit bugs is fun.
<wgrant> sinzui: Using the email address to check validity is in conflict with being able to sensibly suspend and unsuspend users.
<wgrant> It also doesn't make sense.
<sinzui> not so. We put the address in  state to ensure it cannot be reused
<wgrant> It should remain attached to the person, sure.
<sinzui> It also need to be flagged as bad so if it is transferred to someone else, it cannot be used
 * wgrant files a bug about that stupid SSO email.
<lifeless> wgrant: when do you arrive?
<lifeless> wgrant: how did you go setifying stuff?
<wgrant> lifeless: I leave in a few minutes over 24 hours.
<wgrant> Arrive... let's see.
<wgrant> 15:10 Sunday
<lifeless> cool
<LPCIBot> Project db-devel build (272): STILL FAILING in 4 hr 29 min: https://hudson.wedontsleep.org/job/db-devel/272/
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12209,
<LPCIBot> 12210, 12211, 12212, 12213, 12214 included.
<LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12205,
<LPCIBot> 12206, 12207, 12208 included.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (364): FIXED in 4 hr 28 min: https://hudson.wedontsleep.org/job/devel/364/
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=5927] Allow bugtask assignees to see private
<LPCIBot> bugs.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Use math.pow() since conch + gmpy means
<LPCIBot> __builtin__.pow() is splatted over.
<LPCIBot> * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=611217] Ignore POFiles for obsolete POTemplates
<LPCIBot> during upload approval.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
<LPCIBot> lifeless][ui=none][bug=702228] Avoid long-running master transactions
<LPCIBot> during translations export.
<wgrant> Yay.
<lifeless> k
<mtaylor> lifeless: ola
<mtaylor> lifeless: are you in the US now for the launchpad sprint thing?
<lifeless> yes
<mtaylor> cool.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (273): FIXED in 4 hr 27 min: https://hudson.wedontsleep.org/job/db-devel/273/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12215,
<LPCIBot> 12216, 12217, 12218 included.
<lifeless> jml: fyi - bug 703202
<_mup_> Bug #703202: Recipes: failed to build after altering series branch <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/703202 >
<lifeless> mtaylor: so are you coming around to hack on blueprints? :)
<lifeless> :grep '\.dependencies' lib/lp/soyuz -r
<wgrant> lifeless: What about them?
<lifeless> wgrant: StevenK asked to look at some sqlobject -> storm conversions
<lifeless> wgrant: and so we're looking at what uses Archive.dependencies right now, to evaluate impact of a change, and evaluate what sort of changes is best
<wgrant> Ah.
<lifeless> e.g.
<wgrant> We really need to finish that transition :/
<wgrant> It's sort of been nearly four years.
<lifeless> this is a property; its used as bool(foo)
<lifeless> storm doesn't cache the result; sqlobject does
<lifeless> but there aren't any repeated uses
<wgrant> s/bool(foo)/foo.is_empty()/, and I'm not sure caching is much of a concern for that field, really.
<wgrant> Right.
<lifeless> wgrant: this is about teaching the issues & process
<lifeless> wgrant: not the outcome
<StevenK> Archive dependencies tend to be fairly static, which is nice.
<wgrant> Anyway, I should probably finish locking up and stuff.
<lifeless> yeah
<lifeless> see you 'soon'
<StevenK> Haha
<lifeless> http://pastebin.com/XCrf1D60
#launchpad-dev 2011-01-16
<maxb> Hmm. I'm seeing connection timed out errors on apache.org imports. Wonder if we've been firewalled :-/
<lifeless> possibly
<jelmer> maxb: we were earlier
<jelmer> maxb: I thought that had been removed
<jelmer> maxb: please don't re-enable any old cscvs imports of apache.org branches
<maxb> jelmer: I know, and didn't. But there was a bzr-svn one behaving atypically (lp:subversion)
<jelmer> maxb: the bzr-svn file properties were copied over when the svn repository was migrated to the apache svn
<maxb> ouch
<maxb> I have made apologies to #asfinfra, unblocking is in progress
<lifeless> maxb: hi
<lifeless> maxb: what did we do?
<maxb> I tried to reenable the lp:subversion import over the weekend whilst suspending all the other apache.org ones to avoid them killing each other with sqlite errors
<maxb> According to jelmer there's something broken in the bzr-svn metadata that go copied into the ASF repo when Subversion joined the ASF, leading to bzr-svn to go nuts
<lifeless> oh
<lifeless> shame
<jelmer> maxb: I didn't realize it made bzr-svn go nuts
<jelmer> maxb: It should just cause an exception, that's all
<lifeless> StevenK: hi
<lifeless> StevenK: I've edited^Wfixed your bug from yesterday
<maxb> jelmer: I think what happens is that it sees a revid it doesn't know about, and then proceeds to inefficiently populate its revid-map-cache by sequentially doing a revproplist on every revnum
<jelmer> urgh
<maxb> the situation is exacerbated by the revid-map-cache population not being resumable, and sometimes not even being committed to sqlite even when complete, owing to a commit_conditionally() which really ought to be a commit()
<jelmer> maxb: can you file a bug about that?
<maxb> will do
<jelmer> maxb: thanks :-)
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      377 / 2484  Distribution:EntryResource:searchTasks
<lifeless>       76 /  227  Distribution:+bugs
<lifeless>       66 /  165  BugTask:+index
<lifeless>       30 / 3585  Archive:+index
<lifeless>        9 /    7  ProjectGroup:+milestones
<lifeless>        9 /    2  Product:+filebug-show-similar
<lifeless>        7 /  118  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        7 /   13  NullBugTask:+index
<lifeless>        7 /    0  Distribution:+builds
<lifeless>        6 /    7  Product:+translations
<StevenK> lifeless: Patches welcome
<lifeless> indeed!
<lifeless> StevenK: any idea how we'd qa Bug 680733 ?
<_mup_> Bug #680733: broken recipe build gets stuck at top of "5 latest builds" list on recipe page, forever <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by thumper> < https://launchpad.net/bugs/680733 >
<jelmer> maxb: also, thanks for handling those apache imports!
<StevenK> lifeless: I have no idea about recipes
<lifeless> StevenK: ok
<StevenK> I was expecting "No time like the present to learn"
<lifeless> StevenK: I'd love it if you're interested in learning
<lifeless> but it is sunday
<StevenK> Which is a concept you're unfamilar with, so why do you recognise it in other people?
<lifeless> I recognise many alien things
<StevenK> I don't believe that
<poolie> heh
#launchpad-dev 2012-01-09
<lifeless> mwhudson: you're not here are you?
<mwhudson> lifeless: no
<nigelb> LOL
<nigelb> oh right. Now I get what "here" means.
<mwhudson> :)
<nigelb> Wait a minute, why is lifeless awake. Isn't it late in Budapest.
<mwhudson> jetlag i imagine
<nigelb> oh the joy
<nigelb> Sigh. The week I decide to close up my unfinished bugs, epic happens :)
<nigelb> I guess I can procastinate to next week.
<lifeless> mwhudson: it is great to see some loggerhead patches from you
<nigelb> Morning lifeless
<lifeless> 'lo nigelb
<wgrant> lifeless: Bug #756499
<_mup_> Bug #756499: cgroup-bin breaks suspend to RAM <libcgroup (Ubuntu):Confirmed> < https://launchpad.net/bugs/756499 >
<lifeless> wgrant: win, thanks.
<Daviey> anyone near bigjools?
<StevenK> Slightly. We're in a presentation.
<Daviey> ah, thanks
<wgrant> Daviey: He's on irc.c.c, but can't connect to freenode
<StevenK> Oh, the sprint thing again?
<wgrant> Yeah
<wgrant> Someone didn't tell freenode :(
<StevenK> Last time it turned out that we did, twice, but they didn't listen.
<StevenK> So don't assume.
<wgrant> Heh
<StevenK> wgrant: I wonder if lib/canonical/{,launchpad}/__init__.py can now die.
<wgrant> StevenK: No
<wgrant> StevenK: Some things import it to get the icing etc. paths.
<wgrant> Using __file__
<StevenK> That's a little disgusting, but okay.
<wgrant> Yes.
<cjwatson> bigjools: I started API-based autosyncs over the weekend!
<cjwatson> with Archive.copyPackages
<bigjools> cjwatson: I heard, that's awesome
<cjwatson> Debian import freeze is today, so in the nick of time
<StevenK> cjwatson: \o/
<bigjools> cjwatson: I am hoping that copyPackage can be used for all the things you guys currently get timeouts for on the UI or with syncPackage
<cjwatson> so thank you muchly for all that
<bigjools> as per pitti's email
<bigjools> I am very happy that someone is using the code we worked on for nearly a year :)
<cjwatson> bigjools: so am I, though during bug 912867 I did run into a timeout at one point - it was in the middle of a load of other stuff though so I don't know how common it would be
<cjwatson> I'm hoping not much
<cjwatson> bigjools: I have a couple more client things to do but I should be able to submit a branch killing sync-source.py once I've ditched our last dependencies on it
<bigjools> nice
<Laney> Talking about copying (yay), I have nearly finished fixing #912247. Is adding a new column to SPPH a good way to do that?
<cjwatson> our sync-stuff-based-on-bug-requests process still has "ssh to cocoplum and run sync-source.py" in it
 * Laney eyes the bot
<cjwatson> but not fundamentally hard to fix now
<StevenK> bug 912247
 * StevenK pokes _mup_ in the eye.
<cjwatson> bigjools: I'd buy you a drink this week but I'm not in Budapest :-/
<bigjools> cheap place to buy one too :)
<wgrant> cjwatson: !
<cjwatson> ! to which? :-)
<wgrant> cjwatson: Your abscence.
<cjwatson> wgrant: my wife's coming up on 35 weeks pregnant, let's put it that way ...
<wgrant> Heh
<bigjools> kiss goodbye to your life as you know it
<cjwatson> we already have two ...
<cjwatson> (so I already have no life)
<bigjools> glutton for punishment? :)
<wgrant> Oh, I thought you only had one.
<cjwatson> one mine, one stepson
<wgrant> Ahh
<Laney> If adding a column is right, then AFAICS I need a database revision ID thingy
<wgrant> Laney: Yes. This is for SPPH.signer?
<Laney> I called it sponsor, but yeah
<wgrant> Good :)
<Laney> Should I need to edit SQL anywhere to get it saved or does the ORM handle that?
<StevenK> You need to write a DB patch
<Laney> I have got a schema patch
<Laney> but haven't written any explicit code to insert the new value
<wgrant> 2209-02-0 is your patch ID
<StevenK> Once that lands you can edit the model and interface
<Laney> ty
<cjwatson> lands> and is rolled out in an FDT
<StevenK> Well, you can work on the changes before that point, but it can't be landed itself until the FDT is done./
 * cjwatson nods
<Laney> Why does https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Sample_data say "We have deprecated sample data. That means that you should never add to the sample data."?
<Laney> (and then go on to describe how to change the sample data in great detail)
<cjwatson> bigjools: hmm
<cjwatson> bigjools: that autosync seems to have synced stuff from experimental :-(
<cjwatson> e.g. libcdio
<cjwatson> "latest version available" evidently doesn't include "actually in the source distroseries you asked for" ...
<cjwatson> oh, boggle, Archive.copyPackages doesn't actually take a source distroseries!
<cjwatson> no bloody wonder then
<bigjools> cjwatson: yeah, I thought you'd have remembered that from the special sync last year :)
 * bigjools in a meeting
<cjwatson> bit too long ago I'm afraid :-/
<cjwatson> I guess I'll work on a branch for that
<StevenK> rick_h__: http://paste.ubuntu.com/798092/
<rick_h__> http://pad.ubuntu.com/VyfPUoW5Cy is the pad for hte YUI project to work on
<cjwatson> bigjools: just a matter of adding an optional from_series parameter and adding tests for it, I think?
<rick_h__> http://pad.ubuntu.com/VyfPUoW5Cy is the pad
<bigjools> cjwatson: should be
<cjwatson> last year's sync was accidentally overwriting Ubuntu changes, I think
<StevenK> wallyworld_: https://code.launchpad.net/~stevenk/launchpad/step-one-mochi/+merge/87921
 * Laney gets impatient at the test suite
<cjwatson> Laney: you probably don't need to run the whole thing?
<Laney> I thought not, but the wiki seems to say that you do
<Laney> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Making_a_database_patch #15
<cjwatson> oh, db patch
<Laney> yessir
<cjwatson> well, it'll be run in ec2, but you might not want to go round that loop too many times
<StevenK> You don't need the test suite for just a db patch
<StevenK> Make sure 'make schema' works
<Laney> oh :P
<nigelb> Laney: \o/ \o/
<nigelb> StevenK: the last time you said that, my patch broke all triggers :D
<nigelb> (which is when that step was added I think)
<jml> nigelb: hi
<jml> nigelb: have you been watching the cricket?
<nigelb> jml: no, StevenK was goading me the other day
<jml> nigelb: in which case I'll refrain
<nigelb> heh
<nigelb> To be fair, the entire of last week I was sprinting for work on a beach :D
<nigelb> 0-2 :(
<jml> nigelb: tbh, have been disappointed that Tendulkar hasn't got a century yet.
<nigelb> He's been at 99 for so long that its depressing.
<Laney> https://code.launchpad.net/~laney/launchpad/spph-sponsor/+merge/87929 if someone wants to look and tell me what I've missed
<StevenK> Laney: You need to request reviews from lifeless and stub with a type of 'db'
<Laney> ah
<Laney> I did actually read that somewhere but forgot.
<StevenK> Laney: I'd prefer all keywords in your patch are all caps
<StevenK> WHERE sponsor is not Null; for example
<Laney> OK, I copied it from the patch which added creator but I can fix that
<Laney> bah, you have to enter the review type before selecting from the people picker
<nigelb> heh, bitten before :D
<StevenK> deryck: https://code.launchpad.net/~stevenk/launchpad/remove-translations-js/+merge/87933
<nigelb> I missed the 'js' in the link that thought StevenK went ahead and deleted translations :P
<nigelb> s/that/and/
<StevenK> I wish
<Laney> hrm, am I supposed to keep my own copyright in changed files? I was just looking at the CLA 2.1 (a): "You retain ownership of the Copyright in Your Contributionâ¦"
<StevenK> deryck: https://code.launchpad.net/~stevenk/launchpad/bpph-supersede/+merge/87875
<rick_h__> StevenK: http://yuilibrary.com/yui/docs/calendar/
<cjwatson> I know it's thunderdome week, but would anyone have time to review https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942 for me?
<lifeless> flacoste: btw http://webnumbr.com/launchpad-critical-bugs
<Laney> at this point I'm just seeing how long make check takes to run :-)
<wgrant> Laney: 4-6 hours depending on machine :)
<Laney> it appears to be doing doctests now
<wgrant> They're interspersed.
<Laney> oh :(
<cjwatson> Can anyone help me find out why Archive.copyPackage of qemu-kvm from lucid-proposed to lucid-updates is failing?  Might the answer be in appserver logs?
<wgrant> cjwatson: I don't think that's logged anywhere.
<wgrant> cjwatson: If you got a 200 back it won't be in appserver logs.
<wgrant> I think it only logs somewhere if there's an associated DSD.
<wgrant> Yeah
<wgrant> PlainPackageCopyJob.reportFailure
<wgrant> calls findMatchingDSDs, and adds a comment to each.
<cjwatson> Which won't be the case for lucid-proposed -> lucid-updates, right?
<wgrant> Right.
<cjwatson> So I'm screwed
<cjwatson> back to syncSource for now ...
<wgrant> Yup :)
<cjwatson> oh, I see
<cjwatson> actually, no I don't.  check_copy_permissions calls checkUpload, but that does seem to permit uploads to post-release pockets
<cjwatson> http://dogfood.launchpadlibrarian.net/80686770/5sZU7fHhxW0GbsX6UUORq5sEnM9.txt sigh, dogfood is just hopelessly nadgered isn't it
<cjwatson> (trying to see if this branch has any hope of working on something Ubuntu-scale)
<StevenK> I'm not sure how dogfood's librarian works, aside from ... badly.
<cjwatson> ideally it might forward things to the real librarian or something when it doesn't have them, but I realise that's probably a pipe dream
<cjwatson> I think the same thing would make it impossible to run a hypothetical publisher that used C_writeIndexes on mawson
<ayan> using the launchpad api, how does one get a list of series associated with a distribution?  essentially, this: https://launchpad.net/ubuntu/+series
<maxb> ayan: lp.distributions['ubuntu'].series
#launchpad-dev 2012-01-10
<cjwatson> wgrant: Is https://launchpad.net/ubuntu/+source/python-htmltmpl/1.22-10/+build/221077 a consistency error?  That is still the published version of python-htmltmpl in precise; it should not have been deleted
<cjwatson> (Noticed while trying to make my germinate-from-db branch work on dogfood.)
 * mwhudson drops a pin
 * nigelb catches the pin
<nigelb> ...after about 1 hour
<nigelb> spm: In other words, all the bits everyone wants to kill with fire (re: soyuz)
<nigelb> :D
<spm> heh
<spm> no comment
<nigelb> haha
<spm> nigelb: you are truly the master of understatement. 1st it was kill with fire; and now "complicated". /me bows in awe
<nigelb> spm: hey, I'll be nice to people who don't know about it ;)
<spm> :-D
<wgrant> cjwatson: It's a bit more sinister than that, I'm afraid.
<wgrant> cjwatson: It's impossible to natively publish some archives, even on proudction.
<wgrant> cjwatson: Because the files have been inappropriately deleted from the DB.
<wgrant> (this also makes it somewhat challenging to republish the primary archive, even non-natively.
<wgrant> cjwatson: And I guess that python-htmltmpl is an example of that.
<wgrant> I had a list at one point.
<uncle_ian> bigjools: o/
<bigjools> uncle_ian: GTFO
<rick_h__> awesome!
<uncle_ian> huwshimi: o/
<huwshimi> uncle_ian: Morning :)
<cjwatson> wgrant: I wonder what we should do about that.  I could upload rebuilds of affected packages to precise, which would make it irrelevant eventually, but ...
<cjwatson> (and it would be ultimately better to stuff the relevant files back into the db so that everything's consistent)
<wgrant> cjwatson: I have a script to identify them and reincarnate them from the pool.
<cjwatson> I would love it if that were run.  Is it blocked on anything?
<wgrant> As would I, but I need to convince bigjools to let me run it.
<cjwatson> wgrant: Lucky you're in the same building, then. :-)
<wgrant> cjwatson: But MaaS has stolen him :(
<cjwatson> arse
<wgrant> But I will track him down eventually.
<wgrant> http://bazaar.launchpad.net/~wgrant/launchpad/binary-necromancy/revision/13902 has the scipt
<cjwatson> well, I guess I'm not convinced that germinate-from-db will actually be viable anyway; the similar work in the publisher only has to compete with apt-ftparchive on performance, but germinate-from-db has to compete with apt reading Packages/Sources off disk
<wgrant> Probably fairly bitrotten
<wgrant> Yeah
<cjwatson> it's mind-numbingly slow on dogfood, and I can't really tell whether that's just dogfood or not
<cjwatson> I suppose I could try finishing the work to native-publish Ubuntu and then time that, but I have other things to do this year :)
<jcsackett> wgrant: https://github.com/mardambey/postoffice
<deryck> StevenK, rick_h__ https://one.ubuntu.com/combo/4931/?js/one-yui-meta-min.js&js/yui/yui/yui-min.js&js/loader/loader-min.js
<rick_h__> deryck: if you get a sec, diff is uploading: https://code.launchpad.net/~rharding/launchpad/replace_foldables/+merge/87924
<Laney> https://code.launchpad.net/~laney/launchpad/spph-sponsor/+merge/87929 got approved: can somebody land it?
<ayan> maxb: thank you!  that was exactly what i was looking for.
<nigelb> Laney: Yay!
<Laney> nigelb: only the first step :P
<nigelb> Once it lands, I'll show you the scoreboard where we cmpete with wgrant :P
<nigelb> *compete
<ayan> maxb: how did you find that information?  that still isn't obvious to me after reading the api documentation.
<cjwatson> ayan: does https://help.launchpad.net/API/Examples help?  it doesn't have that literal example.
<cjwatson> ayan: (which bit isn't obvious?)
<cjwatson> ayan: I guess you need to know that a foo_collection_link attribute in apidoc means that there's a corresponding foo object synthesised by launchpadlib corresponding to the collection
<cjwatson> ayan: you can sort of deduce that by comparing https://help.launchpad.net/API/launchpadlib#Collections with the apidoc; maxb may well have just known it off the top of his head though since it's a fairly common initial step in a launchpadlib script
<maxb> I looked it up using launchpadlib's introspection facilities
<maxb> I use a custom lpshell script (http://paste.ubuntu.com/799258/) including a custom describe(x) function (http://paste.ubuntu.com/799260/) which prettyprints the lp_attributes/entries/collections/operations attributes
<rick_h__> deryck: http://pad.ubuntu.com/VyfPUoW5Cy
<lifeless> gmb: I don't see the tags in the current streams LP emits
<lifeless> I was looking to check this thing I said I would...
<gmb> lifeless, They're there. Pipe it through grep and look for zope:layer and you should see them.
<lifeless> garh
<lifeless> gmb: right, I see them, testr is dropping them somehow.
<lifeless> gmb: headdesk headdesk headdesk
<gmb> Yeah.
<lifeless> gmb: this is why you are not seeing the tags I suspect. Digging
<gmb> Thanks.
<jml> I'm guessing https://bugs.launchpad.net/subunit/+bug/816690
<jml> (which apparently I've filed twice)
<_mup_> Bug #816690: TestProtocolClient doesn't support tags <subunit:Triaged> < https://launchpad.net/bugs/816690 >
<jml> https://bugs.launchpad.net/subunit/+bug/518016 is the other one
<_mup_> Bug #518016: No public API for tagging on TestProtocolClient <subunit:Triaged> < https://launchpad.net/bugs/518016 >
<gmb> jml, Yes, I'm looking at 518016 now...
<jml> I'd mark as a dupe, but my net connection is so poor I can't load the page.
<gmb> I'll do it.
<jml> gmb: ta.
<lifeless> mm
<gmb> jml, lifeless: So, IIUC the tags are in the subunit output from zope, but then testr eats them, right?
<lifeless> ProtocolTestCase perhaps
<lifeless> jml: ThreadsafeForwardingResult drops tags
<gary_poster> http://lxc.teegra.net/
<jml> lifeless: ah.
<cr3> what kind of permissions does a project maintainer have?
<bac> cr3: the maintainer can administer the project and do everything required except for those things that require LP admin.  do you have a specific question?
<cr3> bac: "everything required" is a bit vague, does he have special permissions for bugs and blueprints that others might not have for example?
<bac> yes
<cr3> bac: ok, I'll compare the list of options available for a project where I'm maintainer to one where I'm not. it should be rather obvious
<ayan> So... I'd like to programmatically nominate a bug for a series.  Does it only make sense to nominate a bug_task?  Can someone point me to documenation that explains the relationship between bugs, possibly bug_tasks, and series nomination?
<cjwatson> ayan: You nominate bugs, not bug_tasks.  You can tell this because only bug has the addNomination method.  https://launchpad.net/+apidoc/1.0.html#bug
<cjwatson> (It might be nice to nominate bug_tasks, but you can see this same thing in the UI; if you nominate a bug with tasks on multiple source packages, it gets nominations for all of them in one go and if you don't want some of them you have to mark them Invalid.)
<rick_h__> anyone up for reviewing some JS? https://code.launchpad.net/~rharding/launchpad/replace_foldables/+merge/87924
<wgrant> lifeless: Where is gpgverifyd?
<wgrant> s/Where //
<lifeless> wgrant: bzr+ssh://bazaar.launchpad.net/~lifeless/%2Bjunk/gpgverify/
<wgrant> lifeless: Ah!
<lifeless> jml: and threadsafeforwardingresult appears to not implement time()
<jml> lifeless: right.
<lifeless> doesn't need to implement it now I look, but it does have a bug (filed)
<jml> lifeless: couldn't tell you off the top of my head
<wgrant> bigjools: So, I think we should deploy buildd-manager at 9am tomorrow
<wgrant> bigjools: And see if it breaks again :)
<bigjools> wgrant: I'd quite like it QAd first
<wgrant> That was so effective the last two times... :)
<StevenK> bigjools: So instead of doing project work, wgrant and I have to spend hours doing so instead?
<bigjools> don't be so melodromatic
<StevenK> But buildd-manager QA is easily several houres.
<StevenK> s/houres/hours/
<bigjools> not at all
<bigjools> I said to jtv that we need one of each type of build pushed through
<bigjools> s/jtv/allenap/
<bigjools> then I would be happy if they all worked without triggering the r/o database code
<StevenK> Sure, and if we do that, then we're not checking everything and we may as well deploy it and roll it back
<bigjools> we're checking the basics
<StevenK> Quick QA of buildd-manager is effectively pointless.
<bigjools> are you insane?
<StevenK> With a change of this magnatude, *and* it's been rolled back at least twice.
<bigjools> I will pop to your room and explain
<rick_h__> wallyworld: https://code.launchpad.net/~rharding/launchpad/replace_foldables/+merge/87924
<rick_h__> wallyworld: http://yuilibrary.com/yui/docs/event/#event-whitelist
<rick_h__> http://yuilibrary.com/yui/docs/api/classes/Event.html#method_getListeners
#launchpad-dev 2012-01-11
<lifeless> jelmer: bug 755241 still needs a little polish I think
<_mup_> Bug #755241: subunit-filter ability to change fail to xfail based on external list <subunit:In Progress by jelmer> < https://launchpad.net/bugs/755241 >
<rick_h__> StevenK: lp:~rharding/launchpad/use-convoy is my branch with some small changes
<StevenK> wgrant_: loloptus
<wgrant_> Nah
<wgrant_> I think my terrible ARM server at home has died this time.
<wgrant_> gary_poster: sudo mount -t overlayfs -o upperdir=foo,lowerdir=bar none baz
<StevenK> overlayfs *and* LXC? What Could Possibly Go Wrong
<lifeless> wgrant_: AIEEEEEEEEEEEEEEEEEEEEEEE
<wgrant_> well, aufs is dead, so we need to use overlayfs instead on precise
<lifeless> I believe it got put back into precise :)
<lifeless> anyhoo
<lifeless> we can all upgrade to precise easily enough :)
<wgrant_> lifeless: Colin said otherwise
<wgrant_> And it works in Oneiric
<wgrant_> And we can use aufs on old series.
<lifeless> ah good, ok
<lifeless> wgrant_: hmm, I saw chatter go by in #ubuntu-kernel couple days back
<wgrant_> It was killed and revived back in Lucid, but AFAIK it's really gone now.
<lifeless> wgrant_: '06:11 #ubuntu-kernel: < apw> tgardner, that is our desire, we are starting to see some problems, which i want to look at at rally, seems pbuilder won't work for instance which is a bit of a problem
<lifeless> '
<jtv> wgrant_: grar, nasty traceback.  Looks very much as if the pending change was a holdover from either a previous scan cycle or a different builder whose work got interleaved with the failing one.
<wgrant_> jtv: Hm. It's possible that concordia was doing stuff, but I don't think so. The full log is at carob:/srv/launchpad.net-logs/staging/buildmaster/buildd-manager.log or so
<jtv> Or waitâ¦ builder.Build..?
<jtv> Sorry: builder.updateBuild
<jtv> Calls the build behavior's updateBuild.
<wgrant_> Yes, that's where the problem is most likely to be.
<jtv> wgrant_: yup, one of the status handlers again, I suspect.
<StevenK> Melbourne
<jtv> wgrant_: Builder.failBuilder
<jtv> wgrant_: in _handleStatus_BUILDERFAIL
<jtv> lp.buildmaster.model.packagebuild.PackageBuildDerived._handleStatus_BUILDERFAIL needs a read/write database policy.
<wgrant_> Aha
<wgrant_> But wasn't this PACKAGEFAIL?
<jtv> wgrant_: dunno â haven't looked at the log yet.  The traceback doesn't say.
<wgrant_> Look at the first line of the paste.
<wgrant_> 2012-01-11 08:41:19+0000 [QueryProtocol,client] Templates generation job blah-5194310 for lp://staging/checkbox finished with status PACKAGEFAIL.
<jtv> Ah.  Any chance that that might be exactly because the status update was preempted by this failure?
<rick_h__> StevenK: https://pastebin.canonical.com/57967/
<mhall119> who can I talk to about https://bugs.launchpad.net/launchpad/+bug/188564 ?
<_mup_> Bug #188564: Build also packages for Debian in PPA's <feature> <lp-soyuz> <ppa> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188564 >
<deryck> mhall119, what sort of talking to are you looking for?
<deryck> uncle_ian, lp:~deryck/launchpad/remove-unused-getContentArea
<mhall119> deryck: I'd like to get an update on how far the conversation has gone about giving resources to this, and if any decisions have been made
<deryck> mhall119, so see mrevell or flacoste
<mhall119> deryck: thanks
<deryck> mhall119, np!
<nigelb> So, I was thinking of doing a hacking on LP sesion at the next ubuntu developer week, can anyone co-host the session with me? :)
 * mhall119 hides
<lifeless> nigelb: depending on the timing, sure
<nigelb> \o/
<nigelb> lifeless: Pick one that works for you from https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable. I'll adjust my schedule around :)
<lifeless> 2100UTC on tuesday is probably good
<nigelb> 0230, not bad.
<nigelb> I'll book that
<nigelb> I'm guessing we need at least 1 hour?
<lifeless> depends on what you want to show folk
<lifeless> nigelb: 0230 isn't bad?!?!?!?!?!?!?!??!
<nigelb> I can stay awake that long :)
<nigelb> 0400 on the other hand...
<nigelb> Would setting up local instance of launchpad and hcaking on a small bug be too hard?
<lifeless> well, we can set up a VM the ycan download
<StevenK> Depends. You may have to fix it to document how long it takes.
<lifeless> it would take an hour to bootstrap a dev environment from scratch
<nigelb> boo
<nigelb> how about we announce that we expect people to already have their environments setup? (yeah, that's hard as well)
<lifeless> yeah
<lifeless> we should
<lifeless> but we should also make that easay
<nigelb> is it harder than it used to be?
<lifeless> no harder, no
<nigelb> I only had trouble with hanving enough bandwidth to download everything rf wanted to download ;)
<lifeless> jml: you are confusing me. And I want to talk to you about ui result objects. Can has voice?
<jml> lifeless: not *right* now. in 1hr15 though.
<mhall119> hey lifeless , would you be able to give me any insights into how far the discussions went on https://bugs.launchpad.net/launchpad/+bug/188564 ?
<_mup_> Bug #188564: Build also packages for Debian in PPA's <feature> <lp-soyuz> <ppa> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188564 >
<lifeless> mhall119: I don't think they have gone anywhere
<lifeless> jml: ping me.
<mhall119> lifeless: it sounds like it's not technically difficult, just resource expensive, am I reading that right?
<lifeless> there are technical things too, like having a debian archive to build against and publishing the results properly
 * cjwatson wonders why lp-remove-package.py bothers taking a lock
<cjwatson> Oh well, I guess it'll be moot once that's moved to the API ...
<jam> I just got some failures trying to push to bazaar.launchpad.net: "ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<jam> ssh_exchange_identification: Connection closed by remote host"
<jam> It is working right now, though. But I'm wondering if we are having capacity issues
<wgrant> rvba: Does the PPA notifications thing really delete the PCJ?
<StevenK> rick_h__: activateConstrainBugExpiration mochi death is live on qas.
<lifeless> jml: yo
<mwhudson> "Delete MochiKit.js since it's no longer used" \o/
<StevenK> Oh yes
<StevenK> We can't kill YUI 2 yet, sadly.
<mwhudson> is that going to happen this week?
<StevenK> Unlikely. The YUI 3 Calendar widget didn't appear until 3.4, and we're still on 3.3.
<mwhudson> ah right
<StevenK> And switching to 3.4 using our current system is *painful* since they reorganised the entire bloody tree.
<mwhudson> argl
<mwhudson> so not difficult, but massively tedious and has to be done in one bit hit?
<mwhudson> *big
<StevenK> We're looking at being clever and using a combo loader.
<mwhudson> ah, that can translate old to new locations?
<StevenK> So the class names didn't change, just their locations. This is the YUI combo loader, just not Yahoo's own.
<mwhudson> right
<StevenK> And let's face it. Our JS is a right mess.
<StevenK> We combine all of our JS files in a particular order, and then add YUI onto the end and then minify the entire lot.
<StevenK> It is utterly disgusting.
<timrc> not sure you can see this, https://bugs.launchpad.net/cloudberry because it's private but the results which should be showing all bugs for this project are not matching up with the statistics in the sidebar...  for example there are 3 results returned, but the side bar says there are 9 open bugs...
<timrc> am I missing something?
<timrc> clicking on the "9 open bugs" link takes me https://bugs.launchpad.net/cloudberry/+bugs which is still displaying only 3 bugs
<mwhudson> timrc: i think that's sort of expected, but i can't remember why
<mwhudson> timrc: ah, found the mail
<mwhudson> timrc: it's because you probably have multiple paths to visibility on those bugs
<mwhudson> i.e. directly subscribed and also in a team that is subscribed
<mwhudson> timrc: https://lists.launchpad.net/launchpad-dev/msg06914.html
#launchpad-dev 2012-01-12
<timrc> mwhudson, belated thx :)
<rick_h__> jcsackett: http://blog.pault.ag/post/15698933492/json-vim-love
<rick_h__> wallyworld_: https://code.launchpad.net/~rharding/launchpad/fix_lp.js/+merge/88316
<wgrant> bigjools: Is the copy notification stuff really meant to delete the job from the DB?
<bigjools> wgrant: YES
<wgrant> k
<rick_h__> deryck: https://pastebin.canonical.com/58012/
<huwshimi> deryck: If you have a minute I wouldn't having a quick chat about some ideas to fix one part of the title widths
<deryck> huwshimi, ok, in a bit.  just fixing qa issue.
<wallyworld_> huwshimi: deryck is with uncle ian, FO
<huwshimi> deryck: No problems. Whenever you have a minute
<huwshimi> wallyworld_: :(
<wallyworld_> huwshimi: just messing with you
<huwshimi> wallyworld_: :)
<StevenK> rick_h__: https://launchpad.dev/gnome-terminal/+milestone/foo/+edit
<rick_h__> StevenK: http://yuiblog.com/sandbox/yui/3.2.0pr1/examples/yui/yui-loader-ext.html
<huwshimi> deryck: Not sure if you want to review this before I land it: https://code.launchpad.net/~huwshimi/launchpad/bug-listing-two-line/+merge/88350
<deryck> huwshimi, yeah, I'll look quickly.
<huwshimi> deryck: Cheers mate
<deryck> huwshimi, r=me, but please use ec2 to land.
<huwshimi> deryck: No problems. Thanks
<lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/915267
<_mup_> Bug #915267: bug heat flames are expensive to calculate <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/915267 >
<lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/915269
<_mup_> Bug #915269: bug heat aging compromises search performance <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/915269 >
<cjwatson> I know it's thunderdome week, but would anyone have time to review https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942, please?  I'd like to minimise any further havoc caused by accidents with that method
<jml> is there a way in the UI to see all source packages in a PPA?
<jml> never mind
<timrc> any plans for making ppas buildable with derived distributions?
<mwhudson> gasp, lifeless is not on the channel
<spm> mwhudson: by implication of the photo that lynne put up that poolie took; lifeless has been asleep all week.
<mwhudson> i haven't seen that one
<lifeless> timrc: its not currently on the roadmap, but it was something we know we need to consider
<lifeless> timrc: OEM shouldn't need it though, they can use derived distros directly
<timrc> lifeless, we have packages that  build in ppas and my understanding is that they point to the latest ubuntu archives?
<lifeless> timrc: they do
<timrc> lifeless, so either we would need to be able to configure those archives or we would need to be able to upload packages to derived distros
<lifeless> the latter is the point really... how else would a derived distro get any content?
<timrc> lifeless, I wasn't aware that we could upload to derived distros
<lifeless> think of them as ppas on steroids
<timrc> it's still problematic for existing projects
<timrc> implies a migration would be necessary *nervous laughter*
<lifeless> why would an existing project need to build against a derived distro?
<timrc> i still like the idea of being able to tell a PPA what archives to build against
<timrc> well the real goal here is to introduce some sort of Ubuntu snapshotting capability using LP
<timrc> right now we achieve this with reprepro and it's less than ideal
<timrc> anyway, I need to go pick up my daughter from day care, bbl
#launchpad-dev 2012-01-13
<jelmer> mwhudson: hi
<StevenK> wgrant: Have you seen the failure in buildbot?
<wgrant> StevenK: Landed a testfix a few minutes ago
<wgrant> A 2000 line testfix, but still a testfix.
<StevenK> wgrant: Holy crap, yeah, I was just reading the diff
<bigjools> cjwatson_: "New procedure for performing syncs" .... \o/
<cjwatson_> bigjools: \o/
<bigjools> cjwatson: so freaking happy to see that, I can tell you
<cjwatson> bigjools: https://code.launchpad.net/~cjwatson/launchpad/remove-sync-source/+merge/88190
<bigjools> cjwatson: confident? :)
<cjwatson> Yep :-)
<cjwatson> Our tools use syncpackage in response to manual syncs now, and even if that fails, we can always upload stuff manually
<cjwatson> (But as that MP said it'd be good to add the from_series parameter to copyPackages first, as in the MP it links to)
<wgrant> cjwatson: What about non-Debian origins?
<wgrant> Although I don't know how long it's been since they were used.
<cjwatson> wgrant: Years.
<cjwatson> I really don't care about those.  We can use syncpackage on the .dsc for all I care.
<cjwatson> Those were there because Mark asked Daniel to make the Ubuntu archive an effective superset of everything on apt-get.org back in about 2005.
<cjwatson> (Holbach)
<cjwatson> And much of the stuff synced then hasn't been touched since.
<Ursinha> is there a way of knowing when a blueprint was last changed in launchpad?
<Ursinha> using the api or the blueprint page or...
<Ursinha> wgrant, you, that knows everything :P
<wgrant> Ursinha: That data's not stored :(
<Ursinha> wgrant, are you kidding me, right?
<wgrant> Bleuprint is a little old and terrible :)
<wgrant> There are only 5 dates
<wgrant> date_created, date_goal_proposed, date_goal_decided, date_completed, date_started
<Ursinha> wgrant, how hard would it be to add another one?
<wgrant> Pretty eas.
<Ursinha> hard, feasible, whatever
<Ursinha> cool
<wgrant> +y
<Ursinha> wgrant, I give you ten pounds if you do that :P
<StevenK> Ten pounds of what?
<Ursinha> lol
<Ursinha> british pounds
<Ursinha> but you can't do anything with that
<Ursinha> do you drink coffee? I can send you a pound of that :P
<Ursinha> seriously, pardon my french, but we are pretty fucked without that information
<Ursinha> that and desirable what changed... I assume we don't have that as well, do we?
<Ursinha> wgrant, ^
<wgrant> Sorry, talking with people here right now.
<StevenK> Ursinha: So, updating blueprint for date_last_changed or so -- easy. Logging what was changed as well -- hard.
<Ursinha> mmkay
<Ursinha> StevenK, what about data_changed and who_changed?
<StevenK> Ursinha: That is fairly easy.
<Ursinha> s/data/date/
<StevenK> Ursinha: Yeah, I figured.
<Ursinha> StevenK, :)
<Ursinha> StevenK, I'd love you forever if you do that...
<StevenK> Haha
<Ursinha> and bring brazilian coffee to you every time we meet
<Ursinha> like, forever
<StevenK> But I don't drink coffee ...
<bigjools> I'll do it! :)
<Ursinha> lol
<Ursinha> okay, whoever does that will get brazilian coffee for life
<Ursinha> I'm serious
<bigjools> a bottle of cachaca too?
<Ursinha> bigjools, that can be done haha
<Ursinha> seriously... can any of you do that?
<Ursinha> as it seems to be easy
<bigjools> I'd knock up an email with your requirements and send it to the dev list, see if anyone can pick it up
<bigjools> my team is mega busy with maas
<Ursinha> StevenK, what do you mean by fairly easy
<StevenK> Ursinha: I'm happy to explain it to you how to do it if you come and find me
<Ursinha> :)
<Ursinha> StevenK, let me put it another way, how long would you take to do it? :)
<Ursinha> (but yes, I'll find you, are you busy right now?)
<StevenK> Ursinha: I can talk for a few minutes.
<Ursinha> StevenK, where are you?
<StevenK> Ursinha: I'm in the LP room
<rick_h__> deryck: lp:~rharding/launchpad/use-convoy
<wallyworld_> wgrant: i upgraded to precise and there's a couple of issues - can you help me when convenient?
<wgrant> wallyworld_: Sure. Are you behind me?
<wgrant> Ah
<wgrant> Yes.
<nigelb> lol.
<nigelb> New heights of laziness :)
<deryck> rick_h__, StevenK lp:~deryck/launchpad/feature-flags-convoy
<wgrant> wallyworld_: launchpad-developer-dependencies is available for precise now
<wallyworld_> wgrant: thanks :-)
<deryck> rick_h__, StevenK -- lp:~deryck/launchpad/yui-version-flag
<deryck> rick_h__, StevenK -- js.combo_loader.enabled	default	1	on
<Ursinha> StevenK, do you think you could give me a five minutes help later today? :)
<StevenK> Ursinha: Sure. When is good for you?
<Ursinha> StevenK, are you busy right now?
<StevenK> Ursinha: I would welcome a hug and an interruption.
<Ursinha> lol
<Ursinha> okay
<nigelb> haha
<StevenK> Ursinha: After some hilarity with gnome-keyring, your branch is playing in ec2.
<Ursinha> StevenK, yay :)
<Ursinha> thank you very much :)
<StevenK> Ursinha: You're welcome. :-)
<wallyworld> StevenK: merge lp:~wallyworld/launchpad/more-comboloader-featureflag
<lifeless> wgrant: http://blog.mocality.co.ke/2012/01/13/google-what-were-you-thinking/
<poolie> pad.lv is offline due to some DNS problem-
<SpamapS> How might I use launchpadlib to find out the dev focus of a distribution object?
<Laney> current_series
<SpamapS> Laney: thanks. :)
<Laney> no problemo senor
<StevenK> deryck: https://code.launchpad.net/~stevenk/launchpad/fix-broken-js/+merge/88526
<deryck> StevenK, rick_h__  -- lp:~deryck/launchpad/better-yui-tarball
#launchpad-dev 2012-01-14
<nigelb> lifeless: around?
<lifeless> hi
<lifeless> nigelb: ^
<nigelb> lifeless: where do I start looking for bug 713873?
<_mup_> Bug #713873: (in API) Person.logo_link is hard to use and performs poorly <easy> <Launchpad itself:Triaged> <LoCo Team Portal:Triaged> < https://launchpad.net/bugs/713873 >
<nigelb> I'm deep in registry and can't find out where the api bits come in
<lifeless> ah!
<lifeless> so, start with launchpadlib + the debugging thing so you can see the requests (HTTPLIB2_DEBUG=1 or something)
<lifeless> then follow your nose
<nigelb> heh, ok
<lifeless> (sorry)
<lifeless> I will look once I'm down at breakfast, for more hinty things
<nigelb> no problem :)
<nigelb> when do you get on a plane?
<lifeless> leave hotel in 2h
<lifeless> 4h till boarding
<lifeless> -> foodness
<lifeless> olÃ¡
 * jelmer waves to lifeless 
 * nigelb waves to jelmer and lifeless 
<jelmer> hey nigelb
<nigelb> jelmer: I hear you fixed the problems with udd and quilt.
<jelmer> well, s/the/some/
<jelmer> merging should be a lot less troublesome now
<nigelb> heh, while I don't do much packaging, I remember headdesking with quilt.
<nigelb> A lot of people are going to be very grateful :)
<jelmer> but it's still a set of quilt patches in the end - not a loom
<jelmer> in the end we should be converting back end forth between quilts and looms, but that's going to be a lot harder
<nigelb> yeah, there's somethin to be said of mixing a patch management system with version control on top of it.
<nigelb> But that's a different argument for another day :)
<jelmer> yeah, indeed
<wgrant> Evening wallyworld_.
<wgrant> Fancy seeing you here.
<wallyworld_> wgrant: yello
<wallyworld_> bit quiet in here - everyone except us is flying :-(
<wgrant> Yeah
<wallyworld_> i just sent an sms to bigjools, he may come onto irc to laughtat us
<wgrant> Excellent
<wgrant> Aha
<wgrant> Evening bigjools.
<bigjools> hahaha
<wgrant> fu
<bigjools> who texted me?
<wgrant> That would be telling.
<bigjools> 12 hours!
<bigjools> lmao
<wallyworld_> bigjools: it was me who texted
<wgrant> Yeah
<wgrant> We leave here at 6am.
<bigjools> wgrant: ah! I don't have your num in my phone
<bigjools> wtf not
<wallyworld_> bigjools: what number did the text appear from? i used my voip phone provider's web interface to send it
<bigjools> pmed
<bigjools> I told you LHR is shit
<wgrant> Heh
<wallyworld_> bigjools: so any cricket on? after a week away. you can't get knocked up twice :-P
<bigjools> just choked laughing
<wallyworld_> hah!
<bigjools> really
<wallyworld_> quick, heimlich manoevure
<bigjools> hindlick
<wallyworld_> bigjools: i have to wait an extra 12 hours to batter up
<bigjools> so stuck in the T3 lounge all night?
<wallyworld_> bigjools: nope, a hotel
<wallyworld_> park inn
<wgrant> With wifi and power but no luggage.
<bigjools> how sweet
<wallyworld_> we got dinner and breakfast, and 10 quid for phone calls
<wgrant> So not so bad.
<bigjools> but no clean clothes
<bigjools> muahaha :)
<wallyworld_> well, i'm not the one who has to site next to me for 20 hrs on a plane
 * wallyworld_ goes to spend some of the 10 quid phoning home
<bigjools> wallyworld_: sit or shite?
<wallyworld_> hah, "sit"
<wallyworld_> can't type
<bigjools> what's the delay for?
<wallyworld_> pooli'es fault
<wallyworld_> a baggage cart crashed into an a380
<wgrant> A baggage truck crashed into poolie's A380
<wgrant> I assume they used our A380 to run poolie's flight.
<wallyworld_> and so he stole "our" a380
<wgrant> And now have to wait for QF31 to arrive tomorrow for us.
<nigelb> what happened?
<wallyworld_> see ^^^^^^
<nigelb> poolie was talking about a baggage truck hitting his airline
<wgrant> Yeah
<wallyworld_> nigelb: been watching the cricket? hasn't it been great?
<nigelb> thank you for rubbing it in :P
<wallyworld_> :-P
<nigelb> wow, eventful.
<nigelb> evening bigjools
<nigelb> So, who feels like hand-holding me through a bug? :D
<wallyworld_> nigelb: otp atm
<nigelb> ah, ok
<bigjools> evening nigelb
<nigelb> I'm still arguing whether to consider it evening or morning.
<nigelb> It looks like I won't sleep tonight.
<nigelb> (yay crazy sleep cycle)
 * bigjools is not entirely sure, I just know I am tired
<bigjools> but I do have Toblerone
<nigelb> WIN
<nigelb> Toblerone solves all ills.
<wallyworld_> bigjools: at least you are in your own bed tonight
<bigjools> wallyworld_: WIN
<nigelb> Look at the bright side, you have a bed to sleep.
<wallyworld_> bigjools: TWINS :-P
<bigjools> wallyworld_: and I'll be in bed with three others
<wallyworld_> bigjools: wtf? you lukcy bugger
<nigelb> lol
<bigjools> admittedly 2 of them are under age
<nigelb> where do I see the code for the api bits of lp?
<wallyworld_> bigjools: you'll go to jail for that
<wgrant> nigelb: The API is the model.
<bigjools> wallyworld_: and get sent to a convict colony?
<wallyworld_> yep :-)
<wgrant> nigelb: The interface (IPerson in this case) defines what's exported and how.
<wgrant> nigelb: And they all point to attributes/methods on Person itself.
<nigelb> ok
<nigelb> so dig into IPerson?
<bigjools> nigelb: don't work, watch the cricket.
<bigjools> oh sorry, working will be less depressing
<nigelb> and cry?
<nigelb> right.
<nigelb> My eyes are Iperson.HasTears objects
<wgrant> bigjools: You're an Australian for cricket purposes now?
<wgrant> Or only when it's convenient?
<nigelb> Until the ashes.
<nigelb> Or whenever England isn't playing Australia ;)
<bigjools> wgrant: wash out your mouth.  everyone likes to see the Indians beaten at cricket
<nigelb> haha
<nigelb> How does the devel, 1.0, and beta things for api work? Is that dealt with in the interface?
<wgrant> nigelb: Yeah
<nigelb> bah, I don't understand this.
<nigelb> wgrant: where should I be looking to make the change? the interface code?
<nigelb> I sort of think I see the bits
<nigelb> but I'm not sure what I need to be doing.
 * nigelb digs deeper
<bigjools> nigelb: what are you doing?
<nigelb> bigjools: trying to figure out whatto do for bug 713873
<_mup_> Bug #713873: (in API) Person.logo_link is hard to use and performs poorly <easy> <Launchpad itself:Triaged> <LoCo Team Portal:Triaged> < https://launchpad.net/bugs/713873 >
<bigjools> nigelb: easy
<nigelb> I question that.
<bigjools> :)
<bigjools> adding backward compatibilty is the hard bit
<nigelb> but isn't changing that in devel fine?
<bigjools> but can I implore that you add a method not a new property
<bigjools> it is
<nigelb> can I add a property?
<bigjools> would prefer not
<nigelb> okay
<bigjools> because it adds an extra lookup for every Person
<nigelb> ah. method makes it lazy.
<bigjools> wtf is logo_link defined
<nigelb> I've been asking that question since morning.
<nigelb> I see logo defined and mugshot defined.
<bigjools> yeah that's right
<bigjools> lazr.restful adds the _link
<nigelb> ah
<nigelb> *headdesk*
<bigjools> it's exported as a LogoImageUpload
<bigjools> I'd add a method to return the URL
<nigelb> A method to IPerson?
<bigjools> yes
<nigelb> Hrm, IPersonLimitedView I guess.
<bigjools> for example there's a changesFileUrl() on publications
#launchpad-dev 2012-01-15
<cr3> in the Launchpad code, do you guys search/replace the copyright dates across the board on the new year or only when modifying files?
<jelmer> 'evening
<StevenK> jelmer: O hai
<jelmer> StevenK: did you make it safely back to .au, or are you still waiting for a plane somewhere?
<StevenK> jelmer: I got home about 25 minutes ago.
<mwhudson> StevenK: good luck staying awake for the next 12 hours or so!
<StevenK> Yes, well ..
<StevenK> I think I managed about 4 hours sleep
<nigelb> StevenK: Did you also manage to get delayed?
#launchpad-dev 2013-01-07
<mwhudson> wgrant: is this the form of replication that lp uses? http://www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION
<wgrant> mwhudson: Yes
<wgrant> It works excellently, though it's somewhat arcane at times
<mwhudson> it's postgres, i think that last bit is implied
<wgrant> And it's not meant to be possible to demote the master to a slave without rebuilding, but we do it anyway with a bit of evil.
<wgrant> Hopefully it'll be a bit better in 9.3, but it works very well once you work it out
<wgrant> A tonne less annoying than slony
<mwhudson> wgrant: can you restore a slave from a backup that's say about 24 hours old and have it catch up from the master?
<wgrant> mwhudson: Um, sort of.
<wgrant> It can't be a pg_dump backup
<wgrant> It has to be a backup of the raw data files
<mwhudson> ah
<wgrant> And you have to have WAL retention set high enough
<mwhudson> yeah, that last bit was the thing that was starting to scare me a little
<mwhudson> well not scare me
<mwhudson> intimidate me with the prospect of reading a lot more documentation
<wgrant> Once we have enough disk space around we're planning on moving away from pg_dump backups
<wgrant> Just rsync the data dir to a backup volume, and keep WAL for weeks
<wgrant> Lets you easily bring on a new replica, plus gives you arbitrary PITR for DR.
<mwhudson> hmm
<mwhudson> hmm
<wgrant> For a less insane DB it's probably worth doing both from the start
<mwhudson> the reason I'm wondering about this is that i want to move pg off a server temporarily while we upgrade
<mwhudson> so maybe i don't need replication at all (a little downtime is ok)
<wgrant> Yeah, probably better to take the few minutes of downtime in that case
<mwhudson> we could just rsync the data dir from one server to the backup
<wgrant> If you have an existing replication setup then sure
<mwhudson> stop the db, rsync again, bring up the backup
<mwhudson> upgrade the original server
<mwhudson> stop the back up pg, rsync back to the original server and start things up again
<wgrant> Or just have the service down for the 5 minutes that it takes to upgrade the original server?
<mwhudson> wgrant: i mean os upgrade
<wgrant> So do I :)
<mwhudson> not expecting that to take 5 minutes
<mwhudson> hm
<wgrant> This isn't Windows or a pandaboard or a desktop, so it should usually be pretty fast, but I guess it depends
<mwhudson> I guess i'm a bit paranoid
<wgrant> That's always good, but sometimes not justified depending on the particular service
<StevenK> wgrant: Does https://code.launchpad.net/~stevenk/launchpad/destroy-pylint-comments/+merge/142053 frighten you?
<wgrant> StevenK: Naturally
<StevenK> wgrant: Is that code for 'self-review that, damn it' ?
<wgrant> No
<wgrant> Nearly done
<wgrant> StevenK: Done
<StevenK> wgrant: Can you glance at the changes in r16406 for that branch to see if I missed something?
<wgrant> StevenK: Can you just read through the new revision diffs and remove the many comments that are now obsolete?
<StevenK> I already did that before commiting, I'm wondering if I missed something
<StevenK> r16406 only changed 36 files
<wgrant>  # A zope interface doesn't have self as a parameter for its methods.
<wgrant> - # pylint: disable-msg=E0211
<wgrant>  # This class should know about the private _window attribute.
<wgrant> - # pylint: disable-msg=W0212
<wgrant>  # We are deliberately not calling PullerWorkerProtocol.__init__:
<wgrant> - # pylint: disable-msg=W0231
<wgrant>  # We know we are not using dirnames.
<wgrant> - # pylint: disable-msg=W0612
<wgrant>  # The super constructor is a no-op.
<wgrant> - # pylint: disable-msg=W0231
<wgrant> - # pylint thinks this raises None, which is clearly not
<wgrant> - # possible. That's why this test disables pylint message
<wgrant> # E0702.
<StevenK> wgrant: So it seems getUtility(IPackageDiffSet).getDiffsToReleases(sprs, preload_for_display=True) preloads the LFAs and LFCs, but the page goes ahead and queries again anyway. Surely it should be cached since it's just a key lookup?
<wgrant> StevenK: Right, you'll need to work out why they're not
<StevenK> Hmm, looks like the LFA ids are not the ids from the packagediff query
 * StevenK peers closer
<StevenK> (Pdb) lfa.filename
<StevenK> u'filename-100051'
 * StevenK facepalms
<wgrant> Hmmmm?
<StevenK> I'm poking around in the DB for that id, so I can work out what it is
<StevenK> It isn't a SPRF, BPF or a PackageDiff
<wgrant> Ah
<wgrant> Check the traceback on the query?
<StevenK> The test isn't giving a traceback
<wgrant> If it's a query count test then the statement collector will have tracebacks
<StevenK> AH HA
<StevenK> It's the files from the PUCs
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bfj-mixin/+merge/142055
<StevenK> 170+class TestBuildFarmJobBase:
<StevenK> And then you call super() ?
<wgrant> I didn't write that, but yes, it's fine to call super() in a class with no superclasses
<wgrant> Because of multiple inheritance, there still may be classes further up the MRO
<wgrant> Otherwise if I inherit from (TestBuildFarmJobBase, TestCaseWithFactory) it might not go all the way up
<StevenK> 417# The url of the upload log file is determined by the PackageBuild.
<StevenK> That comment is sort of wrong now, no?
<wgrant> The tests are all very strange now
<wgrant> I just needed them to pass
<wgrant> They'll obviously need to be significantly reworked over the next couple of days when PackageBuild and BuildFarmJob cease to exist :)
<StevenK> Yeah
<StevenK> Niggle dropped, since you'll need to revisit the tests, r=me
<wgrant> Thanks
<wgrant> StevenK: Why's the invalidate in getDiffTo?
<StevenK> Because that creates a PackageDiff?
<wgrant> No
<wgrant> That's a selectOneBy
<wgrant> You might mean requestDiffTo
<StevenK> Yeah, I've just shifted it
<wgrant> Great
<StevenK> Any other issues?
<wgrant> Doesn't look like it
<wgrant> Does it work?
<wgrant> Have you tested the query count on DF?
<StevenK> I've seen appreciable drops in the query count from the tests
<StevenK> I can cowboy it onto DF
<wgrant> Right, but it's worth a cowboy to see that you've actually caught everything
<StevenK> wgrant: +queue ==  At least 56 queries/external actions issued in 0.99 seconds
<wgrant> StevenK: Checked various Done pages?
<StevenK> Just loading Done
<StevenK> Which timed out
<StevenK> At least 66 queries/external actions issued in 12.24 seconds
<wgrant> What are the extra 10?
<StevenK> Reload gets us to 3.26
<StevenK> wgrant: Checking the query log without JS?
<StevenK> You evil man
<wgrant> Because Firefox and Chromium have become stupid, you might need to select the entire page content and View Selection Source
<wgrant> Because View Source seems to reload the page without cookies
<StevenK> Ugh
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/minimise-bfj-interfaces/+merge/142058
<bigjools> wtf does view source even reload the page ...
<wgrant> It's possible that IPackageBuildDB will need build_farm_job_id, but I don't think so
<wgrant> bigjools: Probably because LP sets no-cache, and browsers are retarded
<wgrant> Although do we actually set no-cache nowadays...
<StevenK> Items in the NEW queue have no SPRs and so a portition of the preloading is skipped?
<wgrant> They have SPRs
<wgrant> But no SPPHs
<wgrant> But +queue shouldn't care about SPPHs except for detecting newness
<StevenK> Ah ha
<StevenK> No binaries for source in NEW
<StevenK> wgrant: http://pastebin.ubuntu.com/1505886/ is a diff between the queries
<StevenK> Between the query logs, even
<wgrant> Well
<wgrant> Obvious one is sections
<wgrant> Are you failing to preload binary sections, perhaps?
<StevenK> I don't grab bprs at all, so likely
 * StevenK shovels more coal into mawson
<wgrant> While you're waiting for it to run 'bzr st' you can review my branch :)
<StevenK> I have
<wgrant> Oh, so you have
<wgrant> StevenK: Hideous!?
<StevenK> Right, NEW is now 58, and DONE is 62.
<wgrant> We only have IBuildFarmJob, IBuildFarmJobOld and IBuildFarmJobDB
<wgrant> I don't know WHAT you are talking about
<wgrant> What did you change?
<StevenK> load_referencing(BPR) and load Section for sprs + bprs
<StevenK> wgrant: I can diff the query logs again if you wish
<wgrant> Aha
<wgrant> Are you sure the BPRs weren't already loaded somewhere?
<wgrant> It already preloads the BPFs
<wgrant> Possibly directly
<wgrant> It may be worth replacing that prejoin
<StevenK> That's inside the browser code, I can rip that out if you wish
<StevenK> But it's a bit disgusting and it links into CPU
<StevenK> So I'm hoping I can leave it alone
<StevenK> Or I could just preload the BPR sections in the browser code
<wgrant> Well, SQLObject prejoins are thoroughly deprecated anyway, so it'd be nice to eliminate it if it's easy
<wgrant> And I suspect it would be cleaner given all the other preloading you're doing now
<StevenK> It's calling into IBinaryPackageFileSet.getByPackageUploadIDs
<wgrant> Oh god why
<wgrant> It may be worth eliminating that method
<wgrant> Rather than double-querying the BPrs
<wgrant> (Since that obviously joins through them, though it might not actually grab them)
<StevenK> browser/queue is the only callsite
<StevenK> And some hideous doctest
<wgrant> Kill
<wgrant> Crush
<wgrant> Destroy
<StevenK> WITH FIRE
<StevenK> wgrant: Haha, IBinaryPackageFileSet and ISourcePackageReleaseFileSet only have stuff used by that page
<StevenK> So I can delete the whole interface and model classes
 * wgrant loses
<wgrant> Excellent
<StevenK> NEW = 65 and DONE = 72
<wgrant> StevenK: Nice easy one if you're still around: https://code.launchpad.net/~wgrant/launchpad/no-+buildjob-redirect/+merge/142066
<StevenK> wgrant: Was distracted by Orks in SM, but r=me
<wgrant> Thanks
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: benji | Firefighting: - | Critical bugs: <150
<czajkowski> mgz: best place to send someone intersted in bzr community disucssions?
<mgz> czajkowski: the mailing list?
<czajkowski> mgz: ah yes what is the sign up page for that
<czajkowski> it's not n the signature of the list
<mgz> it's on lists.ubuntu.com
<mgz> linked from the main page
<czajkowski> ah
<czajkowski> cheers
<dobey> anyone have any idea what might cause the dailydeb issues happening in https://launchpadlibrarian.net/127602321/buildlog.txt.gz ? running dailydeb locally works fine (save for my needed to use debupstream instead of debversion, otherwise it fails immediately on that)
<dobey> #launchpad seems dead, so asking here
<czajkowski> abentley: allenap gary_poster ^^^
<abentley> czajkowski: Sorry, don't know.
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <150
<gary_poster> czajkowski, I have no idea I'm afraid.
<hloeung> morning
<czajkowski> hloeung: ello
#launchpad-dev 2013-01-08
<StevenK> wgrant: Ah ha. The five queries come from package_upload_source_dict[source_file.sourcepackagerelease.id].packageupload.id
<StevenK> Trying to key SPRF to upload id
<wgrant> Ah
<wgrant> To get changesfiles?
<StevenK> No, that is fed into CPU so it can populate the objects
<wgrant> Ah
<StevenK> Which it builds by using IPackageUploadSet.getSourceBySourcePackageReleaseIDs()
 * StevenK breaks DistroSeries:+queue :-(
<wgrant> What did you do to it?
<StevenK> I changed one part of it to no longer use IPackageUploadSet.getSourceBySourcePackageReleaseIDs(), and too make use of PUS only, and now the next method called is looking up SPRF.sourcepackagerelease.id and raising a KeyError when it isn't in the dict.
<StevenK> It just wants a mapping of PU id to a list of SPRFs
<StevenK> So I might just rewrite it to not be dreadful
<StevenK> wgrant: 62 == NEW, 66 == DONE
<StevenK> 3 of those are going to be PackageDiff
<wgrant> Great.
<StevenK> wgrant: I've shifted https://code.launchpad.net/~stevenk/launchpad/moar-preload-distroseries-queue-redux/+merge/142056 back to Needs Review, but it's currently cowboyed onto DF.
<StevenK> wgrant: Can haz review, if you're undistracted?
<wgrant> Soon :)
<StevenK> wgrant: Shall I pick up bug 1095982 and make AAGs work for lp.View?
<_mup_> Bug #1095982: Person.getAffiliatedPillars doesn't filter out inaccessible private projects <403> <easy> <private-projects> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1095982 >
<wgrant> StevenK: Maybe, or work out why LimitedView wasn't sufficient to render the link
<wgrant> StevenK: You can probably grep for the OOPSes
<StevenK> wgrant: Well, an AAG should allow it, by rights
<wgrant> StevenK: An AAG should certainly allow LimitedView, and I think it should allow View, but the private projects implementation assumes that an AAG does not give View
<wgrant> But I think LimitedView should have been enough to render that page
<wgrant> Unauthorized: (<Product at 0x1585a650>, 'displayname', 'launchpad.LimitedView')
<wgrant> https://oops.canonical.com/oops.py/?oopsid=OOPS-c2e7d50102a3b7d7aca70d699226ebee
<StevenK> Clearly not. displayname should remain under View
<wgrant> Should it?
<wgrant> I wonder how BugTask:+index works
<wgrant> Maybe the task table shows title rather than displayname
<StevenK> Likely, just thinking about it
<StevenK> wgrant: IProduct.userCanView() uses ISharingService.checkPillarAccess
<StevenK> wgrant: And checkPillarAccess only checks APGs
<wgrant> StevenK: Doesn't the LimitedView adapter do something different?
<StevenK> It checks userHasGrantsOnPillar
<wgrant> Right
<wgrant> That's what I suspected
<StevenK> wgrant: So I'm not sure how to tackle this
<wgrant> StevenK: How does BugTask:+index render?
<wgrant> I assume it uses Product.title rather than Product.displayname
<wgrant> Which must mean that title is LimitedView
<wgrant> Oh
<wgrant> But displayname is LimitedView too, from that exception
<wgrant> StevenK: Perhaps userHasGrantsOnPillar doesn't respect team participations
<StevenK> That calls IAccessPolicyGrantFlatSource.findArtifactsByGrantee(), which doesn't check TeamParticipation.
<wgrant> tsk
<StevenK> LimitedView for an AAG, and View for an APG just sounds wrong
<StevenK> wgrant: The only that I can see that uses TeamParticipation under APGF is _populateIndirectGranteePermissions
<wgrant> StevenK: I don't think AAG == LimitedView && APG == View is feasible to implement fully, but there's nothing fundamentally wrong with the idea and it's what is mostly implemented today
<wgrant> So we would do well to preserve it for now
<wgrant> StevenK: _getSharedPillars uses TP and APGF
<StevenK> wgrant: Well, it isn't what happens for bugs and branches
<wgrant> StevenK: Sure, but bugs and branches don't have subordinate objects that can have their own grants
<wgrant> The idea is that a grant on a bug gives you access to just that bug, not all details about the product
<StevenK> *cough* stacked branches
<wgrant> While a grant on the product gives you access to all
<StevenK> :-)
<wgrant> Stacked branches are not subordinate
<StevenK> Yes, I was mostly trolling badly.
<StevenK> It probably feels wrong due to bugs and branches acting differently.
<StevenK> _getSharedPillars uses TP and APGF for the owner, but not the grantee
<wgrant> So it does
<wgrant> It's not quite clear why it checks owner or driver at all
<wgrant> Oh
<wgrant> Right
<wgrant> The owner/driver check is to verify that the current user is allowed to see that the grant exists
<wgrant> getSharedProducts lists all direct grants for the *given person* to a product that the *user* owns or drives
<wgrant> checkPillarAccess is the privilege checking implementation
<StevenK> So from what I can see, there is no mtheod that looks for an AAG while respecting TP.
<wgrant> You'll want something similar to that, except on APGF
<wgrant> Sure
<wgrant> getVisibleArtifacts is probably the only thing that uses AAG+TP
<wgrant> (though it shouldn't; all artifacts should have it denormed)
<StevenK> Specification
<wgrant> Hmm?
<wgrant> What about it?
<StevenK> It isn't denormed
<wgrant> Sure
<wgrant> Hence "should"
<StevenK> Right
<StevenK> Can haz review now?
<wgrant> Am looking
<wgrant> Is long
<StevenK> You're not stuck with 3G tethering
<wgrant> source_dict is one of the most useless methods ever, and its name is wrong
<wgrant> Can it be inlined?
<StevenK> Sure.
<StevenK> It is leftovers, effectively
<wgrant> Oh
<wgrant> I can use a selection of Storm "validators" to do my evil
<wgrant> Though I shall probably never be forgiven
<StevenK> OMG, you wouldn't dare
 * StevenK stabs buildbot and it's poller
<StevenK> stub: Are you going to QA r16409 today?
 * stub wonders if it is untestable
<stub> I guess if we can retrieve stuff from the Librarian, it is qa-ok
<adeuring> good morning
<stub> StevenK: qa-ok'd
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban | Firefighting: - | Critical bugs: <150
<benji> gary_poster: yep, that is a bug in the backend; I was just trying to figure out where to file that and whether or not I should dig into it
<benji> pfft
 * dobey wonders who to bug about bzr dailydeb having issues only on launchpad :-/
<lifeless> dobey: what do you mean?
<dobey> lifeless: https://launchpadlibrarian.net/127602321/buildlog.txt.gz
<dobey> lifeless: this seems to only happen on lp. the recipe for that build works fine locally, it's just a simple recipe to reubild lp:ubuntu/ubuntuone-client on older versions of ubuntu that we (u1) still need to support.
<lifeless> dobey: that looks like a pristine-tar failure
<lifeless> dobey: there is no exception thrown from bzr routines, so presumably the tags etc were all recreatable
<dobey> yes, but why would it fail only on launchpadk, and not locally? how am i supposed to debug it further?
<lifeless> dobey: clean quantal chroot should let you reproduce it
<lifeless> but I presume you tried that and couldn't ?
<dobey> i've tried dailydeb on quantal and on raring; though not in an empty chroot
<dobey> brb
<dobey> back
#launchpad-dev 2013-01-09
<StevenK> wgrant: http://pastebin.ubuntu.com/1511514/
<wgrant> StevenK: No
<wgrant> APGF.findArtifactsByGrantee is expected by other callsites to only return direct grants
<wgrant> You might want a checkFooAccess or similar method
<wgrant> eg. checkPillarAccess performs access checks on an entire pillar
<wgrant> You don't care about the presence or absence of grants; you care about access of some kind
 * StevenK continues to work out how to grant an AAG to a team on a product in a test.
<wgrant> StevenK: Subscribe a team to a bug on that product
<StevenK> Hm, it was working, but I think the query was wrong.
<StevenK> Now I've fixed the query and it breaks :-(
<StevenK> wgrant: That adds an AA for the bug, but I can't see anything related to the product.
<wgrant> StevenK: Confused
<wgrant> What are you expecting to see?
<StevenK> Ah, I need to match via AP for the product policy?
<wgrant> A bug does not have a single product, so an AA cannot link to a product
<wgrant> Your query probably wants to involve AAG, AA, APA, AP, TP
<wgrant> Note that AAG, AA, and APA are merged into APGF records with non-NULL APGF.artifact
<StevenK> So far I'm using APGF
<StevenK> And TP
<wgrant> How're you using them?
<StevenK> wgrant: http://pastebin.ubuntu.com/1511746/
<wgrant> +            AccessPolicyGrantFlat.abstract_artifact_id == pillar.id,
<wgrant> WAT
<StevenK> wgrant: Right, pulling out the APs using APS.findByPillar and linking that way works great.
<wgrant> One could alternatively do that directly in the query
<StevenK> Right, switched to that
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/product-limitedview-with-team-aag/+merge/142441
<wgrant> StevenK: The method needs renaming, and you'll want to look for other callsites
<StevenK> There are none.
<wgrant> The convention is that "has grants" refers to a direct grant, not through TP
<StevenK> userIsAbleToAcknowledgeExistanceOfPillar
 * StevenK prepares to get murdered
<wgrant> That's not even the right subject/object, so yes, murder
<StevenK> It is only called from the LimitedView adapter. checkArtifactAccess doesn't work either
<wgrant> Potentially checkPillarArtifactAccess
<wgrant> Or PillarAnyArtifact
<wgrant> Or something like that
<StevenK> I don't mind checkPillarArtifactAccess, so let's do that
<wgrant> Or a new flag on checkPillarAccess
<wgrant> Potentially
<StevenK> wgrant: http://pastebin.ubuntu.com/1511809/
<wgrant> Sounds more reasonable
<StevenK> wgrant: The diff is updated.
<wgrant> StevenK: r=me
<StevenK> wgrant: So, e-mail, or did you want to discuss that on the call tomorrow?
<wgrant> Might as well discuss it on the call
<wgrant> Given it's getting toward EOD
<StevenK> I might bugger off to the doctors, then. I'll be back on $LATER to deal with the mailman deployment.
<wgrant> Thanks
<jtv> Got a weird problem here: somebody logs into lp, but somehow after going through the oauth dance he's always logged in under some different, newer, similarly-named account.
<wgrant> OAuth or OpenID?
<jtv> SSO confirms his correct login name and email address, but once he's redirected to launchpad, it shows him as logged into the other account.
<wgrant> also, details :)
<jtv> Oh, no idea actually which it is.
<jtv> Hang on, I'll fetch you some details!
<jtv> Username: tahoar
<jtv> After logging in, he suddenly found he was tahoar-z
<jtv> He renamed that account to tahoar2.
<wgrant> He has at least two SSO accounts
<wgrant> Has he tried logging in with the other one?
<jtv> Looks like â although I don't think he created that new one.
<wgrant> He did
<wgrant> Well, or someone else with his email address did
<wgrant> But probably him
<jtv> Are you looking at the original email address used for the account, or the currently configured email address?  Because he did change it  recently.
<wgrant> Get him to log in with the original SSO account to get into ~tahoar, then merge at https://launchpad.net/people/+requestmerge?field.dupe_person=tahoar2
<jtv> That's what he tried, but he can't log in as tahoar.
<jtv> Because when he does that, LP insists that he's tahoar2.
<wgrant> There are two distinct SSO accounts, because I can see that each LP account has a different OpenID identifier
<jtv> But somehow they get conflated.
<jtv> FWIW Ubuntu One does say he's logged in as tahoar.  But lp disagrees.
<wgrant> Ubuntu One will probably have its own concept of username
<wgrant> Has he tried logging into SSO with both of his email addresses?
<wgrant> precisiontranslationtools.com and yahoo.com
<jtv> He may have â but I don't think he'd know the password for tahoar2.
<wgrant> Also note that U1 uses login.ubuntu.com while LP uses login.launchpad.net, so he may be logged in as a different user on each
<wgrant> There's no "password for tahoar2" -- SSO doesn't have a concept of username
<jtv> Ah
<wgrant> It's all about email addresses
<wgrant> He clearly *does* know the password for the SSO account that LP knows as tahoar2, because he's logged into it
<jtv> No, he logs in as tahoar, not as tahoar2.
<wgrant> 16:54:52 < jtv> After logging in, he suddenly found he was tahoar-z
<wgrant> 16:54:58 < jtv> He renamed that account to tahoar2.
<jtv> But he used the password for his own account.
<wgrant> But he has two accounts :)
<wgrant> Each with its own email address and password
<jtv> Ignoring for the moment the question of how he got two accounts, how can logging into one of them get him into the other instead?
<wgrant> It can't
<wgrant> He's logging into the wrong one
<jtv> Yes, but why?  It's not him doing that.
<wgrant> He's not logging into SSO as tahoar, simply because that's a username and SSO doesn't know what a username is
<wgrant> He's logging into SSO as tahoar@somedomain
<jtv> He uses his gmail address for logging in.
<wgrant> Not tahoar
<jtv> Now, as I understand, the gmail account is _not_ associated with that weird extra account.
<wgrant> But it clearly is!
<jtv> Then it shouldn't be.
<jtv> It was associated with his gmail address at one point, but it isn't any longer.
<wgrant> Ah, I see that in the last couple of months he's changed the email address on the *LP* account ~tahoar2 from gmail.com to yahoo.com
<wgrant> But presumably the SSO account linked to ~tahoar2 still has gmail.com
<jtv> Yes, he's been trying to get back to his own account.
<jtv> Yes, looks like.
<wgrant> Then he should log in with his old account's email address
<wgrant> precisiontranslationtools.com
<jtv> Hang on, I'll call him.
<wgrant> SSO and LP can't magically detect that two accounts are owned by the same person; if you log in as the wrong account you'll get the wrong account, regardless of what you actually want.
<jtv> He's trying that now.  Looks like that precisiontranslationtools address fell by the wayside at some point.
<wgrant> Right
<wgrant> Once he's in, point him at that merge link I gave about
<wgrant> s/about/above/
<wgrant> Once the LP accounts are merged, either SSO account will work
<jtv> I think he has the merging link...  He just couldn't get into the right account for the merge!
<jtv> Apparently there are things that get deleted rather than moved over when you merge accounts.
<StevenK> Very few
<jtv> It was something specific that he didn't want to lose though.
<jtv> I forget what.
<wgrant> jtv: Nothing gets deleted from that account that will be kept
<wgrant> And presumably there's nothing of value on tahoar2
<wgrant> (it is only a few months old and has no karma entries whatsoever)
<jtv> He got into his original account!  But the weird thing is, he created the tahoar account and it had the gmail address as its main address.  Then the new tahoar-z (now tahoar2) account got created with that same gmail address, and the gmail address disappeared from his original account.
<wgrant> Are you sure?
<wgrant> There was no gmail address on ~tahoar last May, and in September the new account was created
<jtv> Well I'm getting it from him but that's the part he's sure about.
<wgrant> So unless it was in those four months or removed before May, it was never there
<jtv> He may well have moved it to his gmail account at a later stage.  Did the tahoar-z account get created automatically?
<wgrant> jtv: It depends what you mean by "automatically"
<jtv> By one of our various background jobs.
<wgrant> It was created automatically by LP when someone tried to log in when an SSO OpenID identifier and email address that were not linked to a Launchpad account. That's the normal way that a newly registered user logs into LP
<wgrant> So no, it wasn't autocreated when a background job saw the email address on an imported object
<wgrant> A separate SSO account was created by the user, and then that account was used to log into LP
<jtv> Could there have been some kind of replication-lag issue?  Changing the email address and then attempting to log in with it before things were ready?
<wgrant> No
<wgrant> There are two SSO accounts, and they must be created very explicitly
<wgrant> When an unknown OpenID identifier (ie. SSO account) is used to log into Launchpad, we also check to see if there's a Launchpad user with the email address in the SSO response. If there is one, we link the OpenID identifier to that existing account
<wgrant> Which means that at the time of first login the gmail address was not known to Launchpad
<jtv> Will it be safe for him to  remove the gmail address from the tahoar2 account at this stage and add it to the tahoar account?
<jtv> Or would it be best just to merge from there?
<wgrant> Merge to get rid of the excess account. It will transfer the addresses
<wgrant> The gmail address is presently on the gmail.com *SSO* account, which is linked to the tahoar2 aka. yahoo.com *LP* account
<wgrant> I don't believe the gmail.com address is on any LP account today, just SSO
<jtv> Massively confusing.
<wgrant> Certainly
<wgrant> Which is why that anyone with multiple accounts very probably wants to merge them as the first step
<jtv> Well in this case, the second account was never wanted in the first place.
<wgrant> Which is why we should merge it
<wgrant> It is the easiest and least confusing means of disposal
<jtv> Will it produce a situation where the 2 SSO accounts map to 1 Launchpad account?
<wgrant> Yes
<wgrant> So it may be advisable to also request that the SSO admins merge the two SSO accounts
<jtv> RT?
<wgrant> But having two SSO accounts is not problematic unless interacting with some particular external systems
<wgrant> https://forms.canonical.com/lp-login-support/
<jtv> That's taking ages to load...
<jtv> Ah, there it is.
<jtv> Thanks.
<wgrant> Well
<wgrant> It probably involves SalesForce
<wgrant> It would have to be slow :)
<jtv> Hmm... it links to a separate SSO report form.  Wouldn't he want that one?
<wgrant> It doesn't really matter for this issue
<wgrant> They are support forms for the same service, just with a different theme
<wgrant> They go to the same people
<jtv> Ah.
<adeuring> good morning
* frankban_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <150
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <140
<StevenK> wgrant: Is there a private project on qas we can borrow for this QA?
<wgrant> StevenK: It takes like 10s to create a new one
<StevenK> Hmmm, isn't there supposed to be a checkbox about it?
<wgrant> StevenK: There's an Information Type picker on the final step
<StevenK> I'm on part 2, with a Complete Registration, and I can't see an information type picker
<wgrant> Who are you logged in as?
<StevenK> Oh, I see it
<StevenK> Between Driver and Homepage URL
<StevenK> Now for a team to subscribe to the bug
#launchpad-dev 2013-01-10
<StevenK> wgrant: https://bugs.qastaging.launchpad.net/prop-auditorclient/+bug/939660 with a Proprietary project, and soyuz-team subscribed to the bug.
<_mup_> Bug #939660: globally-installed GIMP python plugins are not accessible <amd64> <apport-bug> <oneiric> <running-unity> <The Gimp:New> <gimp-plugin-registry (Ubuntu):New> < https://launchpad.net/bugs/939660 >
<wgrant> StevenK: It'll need to be some other team, or I'll need to steal the project from you
<wgrant> Since I'm a commercial admin
<wgrant> Actually
<wgrant> You can test this yourself
<wgrant> StevenK: https://qastaging.launchpad.net/~stevenk
<wgrant> Hmm
<wgrant> Might need to be a team, actually
<wgrant> StevenK: Can you see https://qastaging.launchpad.net/~soyuz-team, with the project listed?
<StevenK> Yes
<wgrant> StevenK: How about now?
<StevenK> wgrant: I can see the page, but the project disappeared
<wgrant> StevenK: And now?
<wgrant> (I've just added a team grant)
<StevenK> wgrant: The project is back
<wgrant> Sounds qa-ok, then
<wgrant> Oh
<wgrant> No, that was an APG, oops
<StevenK> Haha
<wgrant> And now?
<StevenK> wgrant: The page loads and the project is there.
<wgrant> Great
<wgrant> That's an AAG
<StevenK> I shall mark the bug as qa-ok, then
<wgrant> Sounds good
<StevenK> wgrant: We want to link the identifier in the case that there is an known email, but the identifer is not known about?
<wgrant> StevenK: Right. If the identifier is known then the identifier wins, otherwise we fall back to the email address and link the identifier for the future.
<wgrant> Currently if the identifier is known and the email is unknown, we add the email address. But we want to stop doing that.
<StevenK> wgrant: http://pastebin.ubuntu.com/1515303/ Am I on the right track?
<wgrant> StevenK: We want to at most warn if the accounts differ -- certainly not crash
<wgrant> And we don't even attempt to add the address if it's missing
<wgrant> Again, we would at most warn about it
<StevenK> wgrant: Right, I wasn't certain how to warn. Add an exception like TeamEmailAddressError?
<wgrant> That sounds like an error, not a warning.
<wgrant> We don't have to do a warning initially. Just ignore it for now.
<wgrant> It also looks like you removed the account creation bit
<StevenK> Yes, since that calls createPersonAndEmail
<StevenK> Note that paste is WIP, I've not even looked at tests.
<wgrant> createPersonAndEmail is one of the places that must obviously continue to create addresses
<wgrant> https://bugs.launchpad.net/canonical-identity-provider/+bug/556680/comments/5
<_mup_> Bug #556680: attempting to create a new account with an existing team email address at login.ubuntu.com oopses <isd-logging-sprint> <lp-foundations> <openid> <Canonical SSO provider:Confirmed> <Canonical ISD QA:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/556680 >
<wgrant> That's the sort of algorithm we want.
<StevenK> So I want to resurrect that code, it's sane?
<wgrant> But now I must go out for an hour
<wgrant> Yes
<wgrant> StevenK: How goes?
<StevenK> wgrant: http://pastebin.ubuntu.com/1515579/
<wgrant> +            create_email_token = False
<wgrant> why does that still exist?
<StevenK> wgrant: Because I don't want to assert for personless account twice
<wgrant> StevenK: But don't you only ever need to create an address if you end up calling createPersonAndEmail?
<wgrant> Remember that we no longer want to create missing addresses
<wgrant> That method only adds an address if the entire person is new
<StevenK> wgrant: create_email_token will call into getUtility(ILoginTokenSet).new(), which requires the person, and at the point I set create_email_token, I only have the account
<wgrant> StevenK: But why are you ever calling that method?
<wgrant> In what situation do you need to create an email address for an existing person?
<StevenK> wgrant: Where the OpenID identifier exists, but the address does not.
<wgrant> StevenK: We are making this change precisely so that that no longer happens
<wgrant> That's the entire point of this branch :)
<StevenK> * If the OpenID identifier has a person, and the e-mail address isn't known,
<StevenK> create a LoginToken, and no e-mail address, and then when the LoginToken is
<StevenK> consumed, we create the e-mail address as VALIDATED.
<StevenK> From my notes I made on the call
<wgrant> Ah
<wgrant> That bit was a misunderstanding, clearly
<wgrant> If the email address isn't known, we do nothing, except maybe eventually warn
<wgrant> That's the entire point of the change
<StevenK> I'm not sure how to warn :-(
<StevenK> We can't toss exceptions
<wgrant> "eventually"
<wgrant> So do nothing
<wgrant> Sure
<wgrant> An exception from a login method is not a warning :)
<wgrant> How do we normally present non-fatal warnings?
<StevenK> Using addNotification
<wgrant> Precisely.
<wgrant> (well, addWarningNotification)
<StevenK> Right, which means returning a 3-tuple and ugh
<wgrant> That's why I said eventually
<wgrant> Get it working first
<wgrant> Maybe even land it
<wgrant> Then work out how to do warnings
<wgrant> The key thing for now is to stop the destructive rampage
<StevenK> Working through test failures
<StevenK>   File "/home/steven/launchpad/lp-branches/openid-identifier-is-the-new-black/lib/lp/registry/tests/test_personset.py", line 818, in testNewEmailAddress
<StevenK>     self.assertIs(True, updated)
<StevenK> Well, about that ... :-)
<StevenK> MismatchError: True is not False
<StevenK> I guess that test is now bong with this change?
<wgrant> It certainly sounds like it's testing a piece of functionality that we're deliberately removing, so removing the test sounds sensible
<StevenK> And testMovedEmailAddress -- like you say, the whole point is to stop doing that
<wgrant> Not quite
<wgrant> The case it gives there is still valid
<wgrant> But our behaviour is different
<wgrant> The test name and result are no longer correct, but the scenario must continue to be tested
<StevenK> wgrant: This test pulls an account by using store.find(), I guess I need another DB query to find it's person?
<wgrant> its
<wgrant> You can adapt an Account to IPerson
<StevenK> wgrant: The only thing I'm tripping over is testNoAccount. It forces self.email.account and self.person.account to None and then calls into getOrCreateByOpenIDIdentifier()
<wgrant> StevenK: Is that a problem?
<StevenK> wgrant: Well, the test fails due to the assert in getOrCreateByOpenIDIdentifier()
<wgrant> Which assert?
<StevenK>             person = IPerson(account, None)
<StevenK>             assert person is not None, ('Received a personless account.')
<wgrant> Ah
<wgrant> So if you just blank out person.account without deleting the account then you'll end up with a personless account, which is illegal.
<wgrant> That same assertion was there before
<wgrant> Why did it work?
<StevenK> -                    # The Email Address does not exist in the database,
<StevenK> -                    # but the OpenId Identifier does. Create the Email
<StevenK> -                    # Address and link it to the person.
<StevenK> It was in that block
<wgrant> So, that test is crap
<wgrant> It creates an illegal state which happened to work before
<StevenK> Haha
<wgrant> Adjust it to remove the account, or at least remove its OpenID identifier
<StevenK> Destroy?
<StevenK> Aw
<wgrant> Oh, but it uses its own identifier?
<wgrant> Then how does it find the old account at all?
<StevenK> Now?
<wgrant> When it fails
<StevenK> Running the test under pdb so I can see what's what.
<wgrant> (note that self.email.account = None is effectively a no-op; the column hasn't existed for 12 months so that just creates a new unused attribute, but I clearly didn't catch all the callsites)
<StevenK> Hah
<StevenK> Right, so the case is OpenID == None, and email == <address>
<StevenK> And email.person.account is None
<wgrant> Right
<wgrant> So it should create an account
<wgrant> How does it end up with a personless one?
<StevenK> I think the error is misleading
<wgrant> Is the account itself None?
<StevenK> It should assert "Could not find Person from account" or something
<wgrant> No
<StevenK> (Pdb) p email.person
<StevenK> <Person at 0x10133110 acc2436244 (Displayname)>
<wgrant> If an account doesn't have a person, it's personless
<StevenK> (Pdb) p email.person.account
<StevenK> None
<wgrant> The error is correct
<wgrant> Sure
<wgrant> But what is "account" in "person = IPerson(account, None)"?
<StevenK> account will be set to email.person.account
<wgrant> In the latest diff I have, you've removed the account creation code
<StevenK> In this case
<wgrant> So account may be None
<StevenK> So None
<wgrant> Right
<wgrant> There's your problem
<StevenK> wgrant: http://pastebin.ubuntu.com/1515737/
<wgrant> Right
<wgrant> Note the suspiciously deleted AccountSet.new, with no replacement
<StevenK> Right, now resurrected
<wgrant> (an accountless person is probably inactive, so it's covered by the "if person is not active" block in my pseudocode)
<wgrant> In fact, I think an accountless person must be inactive
 * wgrant checks
<wgrant> Well
<wgrant> yes
<wgrant> They have to be
<wgrant> Since activeness is defined by account.status :)
<StevenK> Haha
<StevenK> Now I get IntegrityError: null value in column "account" violates not-null constraint
<wgrant> launchpad_dogfood=# SELECT COUNT(*) FROM person WHERE teamowner IS NULL AND account IS NULL AND EXISTS (SELECT 1 FROM emailaddress WHERE status = 4 AND person = person.id);
<wgrant>  count
<wgrant> -------
<wgrant>      0
<wgrant> (1 row)
<wgrant> StevenK: That sounds like it's talking about OpenIDIdentifier.account?
<StevenK> Ah, yeah. I can't create the account that late.
<wgrant> Note also that my pseudocode assumes that account has ceased to exist, so it might need some adjustment
<wgrant> I had planned to destroy Account by last March, but that didn't eventuate
<wgrant> Due to SSO
<StevenK> Right, and OpenIDIdentifier.account is NOT NULL, so that is fine
<StevenK> Bleh, stop erroring, I create a account
<StevenK> And it should be added to the store by IAccountSet.new, so I'm not sure why that assert trips
<StevenK> Bleh, the account isn't added to the store in IAccountSet.new
<StevenK> wgrant: Right, I have the test_personset tests passing
<wgrant> Great
<StevenK> That's ... comforting. No logintoken failures, even though I removed 70 lines of code.
<wgrant> Wasn't most of that from the browser code, though?
<wgrant> It's probably in the OpenPGP validation workflow tests
<StevenK> +14/-97 including browser code
<StevenK> Hmm, bin/test -vvt openpgp has no love
<wgrant> They'll be named gpg, I suspect
<StevenK> Yeah, -t gpg running now
<StevenK> lib/lp/registry/stories/gpg-coc/xx-gpg-coc.txt is the failure
<StevenK> wgrant: http://pastebin.ubuntu.com/1515800/
<wgrant> StevenK: Why don't you use AccountSet.new/
<wgrant> Also, now that we don't attempt to move email addresses around the team ownership check can be just before the person creation bit
<StevenK> wgrant: The comment before explains it:
<StevenK>                         # IAccountSet.new() creates an OpenIdIdentifier, which
<StevenK>                         # we do below.
<wgrant> StevenK: It's an optional argument
<StevenK> Oh, I misread it as 'is None'
<wgrant> So yeah, I'd move the team address check into the same place it is in my pseudocode
<wgrant> That is, the 'if email is not None' becomes 'if email is not None and not email.person.is_team'
<wgrant> And then a new elif after that which rejects login if the address is team-owned
<StevenK> Yes, just wrote that
<wgrant> Also, we might as well make that whole thing identifier-driven
<wgrant> So the 'if identifier is not None' bit goes away
<StevenK> Hm?
<StevenK> Not sure I understand what you mean
<wgrant> I was a little unclear
<wgrant> But basically I don't think the 'account' local var is valuable
<wgrant> person = IPerson(account, None) should be
<wgrant> person = IPerson(identifier.account, None)
<wgrant> That is, before then you just ensure that identifier is set properly
<wgrant> If identifier is not None then you don't have to do anything
<wgrant> If identifier *is* None, then you have to go through the email address check
<wgrant> So all the email stuff can be inside an 'if identifier is None' block
<wgrant> To make it clearer that the identifier completely wins if it exists.
<StevenK> Just running tests, and I can post a new diff
<StevenK> wgrant: http://pastebin.ubuntu.com/1515818/
<wgrant> StevenK: I reworked it to hopefully be a bit clearer. What do you think? http://pastebin.ubuntu.com/1515824/
<StevenK> Looks good
<wgrant> (this method has a hilarious history of bugs and misreadings, so I think we should make this rewrite as understandable as we can)
<StevenK> wgrant: So, looks good enough to propose, or we should go further?
<wgrant> http://pastebin.ubuntu.com/1515841/
<wgrant> Now it's much more understandable, I think
<wgrant> So propose away :)
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/openid-identifier-is-the-new-black/+merge/142641
<wgrant> StevenK: In testEmailAddressAccountAndOpenIDAccountAreDifferent can you check that the email account is unchanged?
<StevenK> wgrant: http://pastebin.ubuntu.com/1515904/
<wgrant> StevenK: Sounds reasonable.
<StevenK> It even passes
<StevenK> wgrant: Any other issues?
<wgrant> Nope
<StevenK> Hmm, can we actually QA this without going insane?
<wgrant> To some extent
<wgrant> I'll do it, because I have lots of accounts that I'm not too afraid of breaking
<wgrant> And I know all too well how to break this :)
<StevenK>  16415. By Steve Kowalik 2 minutes ago
<StevenK>     Assert the e-mail account is unmolested in testEmailAddressAccountAndOpenIDAccountAreDifferent.
<StevenK> Dear lp-land, why is the private bug in the commit message, but the public one isn't?
<wgrant> Because I unlinked the public one, because it doesn't fix it
<wgrant> :)
<StevenK> Thanks for the lack of warning :-P
<wgrant> I try
<StevenK> wgrant: Warning if the accounts are different will fix it?
<wgrant> StevenK: That bug sort of encompasses the weaknesses in our workflow that I identify in my rather large comment
<wgrant> It includes more than just email conflicts.
<StevenK> Right.
<StevenK> So this branch fixes *part* of it
<wgrant> Um
<wgrant> Sort of
<wgrant> Not reallty
 * StevenK glares at the test failure
<StevenK> wgrant: Hmmm
<StevenK> wgrant: I think the test fails because we only croak if there is no OpenID identifier
<StevenK> We pass one, get an account, login_called is True, test goes bang
<wgrant> StevenK: Right, the test probably assumes that we won't allow login with a team address at all, whereas we've now relaxed that to just failing the account creation case
<wgrant> Adjust the test to use a new OpenID identifier
<StevenK> I've been trying to work out where we even pass in the identifier
<wgrant> StevenK: _createViewWithResponse gets it from the provided account
<StevenK> Passing None as the account is probably a silly idea?
<wgrant> Well, it won't work
<StevenK> Indeed, it doesn't
<wgrant> You'll need to alter _createViewWithResponse to alternatively take an identifier string
<StevenK> And that's the first argument to FakeOpenIDResponse?
<wgrant>         openid_response = FakeOpenIDResponse(
<wgrant>             ITestOpenIDPersistentIdentity(account).openid_identity_url,
<wgrant>             status=response_status, message=response_msg,
<wgrant>             email=email, full_name='Foo User')
<wgrant> It would certainly seem to be
<StevenK> wgrant: http://pastebin.ubuntu.com/1516114/
<StevenK> I'll land it when I get home
<wgrant> StevenK: Right
<adeuring> good morning
#launchpad-dev 2013-01-11
<StevenK> wgrant: Did you want a review, or you're still fighting tests?
<StevenK> (Like I am.)
<wgrant> I'm fighting a branch scan timeout
<StevenK> Glad to hear it's not just me.
<StevenK> Er, I mean, that's terrible.
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1098170/+merge/142816
<StevenK> wgrant: Looks good, r=me
<wgrant> Thanks
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-count-distribution-ppas/+merge/142818
<wgrant> StevenK: r=me
<StevenK> wgrant: Oh, so IDistribution.getAllPPAs().is_empty() is fine?
<wgrant> StevenK: If it works, why wouldn't it be?
<StevenK> wgrant: It works, I'm concerned it's going to perform terribly.
<wgrant> is_empty() is very different from count() == 0
<wgrant> Because is_empty will stop as soon as it finds a row
<wgrant> So an index on archive(distribution, purpose) will have it satisfied in microseconds
<StevenK>     "archive__distribution__purpose__key" UNIQUE, btree (distribution, purpose) WHERE purpose = ANY (ARRAY[1, 4])
<wgrant> Note that that's not actually useful
<StevenK> That index, or the property?
<wgrant> The index
<wgrant> It's partial over (PRIMARY, PARTNER)
<wgrant> You may want to create a new index
<StevenK> Mmmm
<wgrant> But this will be strictly faster than what was there before, and trivially fast for Ubuntu
<wgrant> For other distros it will be slower
<wgrant> (simply because for ubuntu/+ppas it has to find any one row matching distribution=1 AND purpose=2, for which it has to search at most 67 rows, because there's only 66 archive rows that *aren't* Ubuntu PPAs)
<wgrant> StevenK: Oh
<wgrant> I missed something in that review :(
<StevenK> Oh?
<StevenK> Hah, test failure
<StevenK> assertContentEqual ?
<wgrant> Oh, I only sorted one end
<wgrant> Oops
<wgrant> StevenK: But the thing I missed was that you ended your commit message in a preposition.
<StevenK> wgrant: The description, rather than the commit text?
<lifeless> assertThat(... MatchesSetwise) might be your friend
<wgrant> lifeless: assertContentEqual is shorthand for that
<lifeless> wgrant: then sorting shouldn't be needed
<lifeless> wgrant: isn't it shorthand for MatchesListwise ?
<wgrant> Yes, but I didn't use assertContentEqual :)
<wgrant> Because I copied it from another test
<wgrant>     def assertContentEqual(self, iter1, iter2):
<wgrant>         """Assert that 'iter1' has the same content as 'iter2'."""
<wgrant>         self.assertThat(iter1, MatchesSetwise(*(map(Equals, iter2))))
<StevenK> Bad wgrant, no cookie.
<lifeless> wgrant: well then :)
<StevenK> wgrant: Are you landing a testfix, or shall I?
<wgrant> I am
<wgrant> StevenK: No +queue timeouts yesterday
<wgrant> And only three soft
<wgrant> The remaining slow queries are because of partner and the COUNT(*), but they're only 700-900ms each
<bigjools> nice
<StevenK> More problems solved by the destruction of PARTNER
<wgrant> All problems are solved by the destruction of PARTNER
 * StevenK stabs this branch, gives up and casts a wide net for anything that wants IEmailAddressSet.
<StevenK> Or I just call into traceback from IEmailAddressSet.new and toss a ValueError if the call trace doesn't contain LoginToken
<StevenK> wgrant: So, due to ripping it out of getOrCreateOpenIDIdentifier, it looks like the person browser code only create a LoginToken
<StevenK> The LoginToken code will cope if the EmailAddress exists or doesn't.
<wgrant> Hmm
<wgrant> StevenK: Ah, so it does
<StevenK> Which would explain why I couldn't find it.
<StevenK> wgrant: So I can put up this +10/-17 branch, but it's all tidy-up
<wgrant> Oh
<wgrant> Person.unvalidatedemails is actually calculated from the logintokens
<wgrant> Intriguing
<wgrant> So you're right, it's already all good
<wgrant> StevenK: Might as well put it up
<StevenK> And I can't see any errant calls to IEmailAddressSet.new, either
<StevenK> wgrant: So two bits of QA and we should deploy?
<wgrant> I'm testing the OpenID thing atm
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/random-logintoken-cleanup/+merge/142827
<wgrant> StevenK: That looks like an ideal candidate for a self review
<StevenK> Pfft
<StevenK> wgrant: Did you not close bugs from the NDT?
<StevenK> wgrant: And do we want to find the '' OpenID identifier in the DB and shoot it?
<wgrant> Ah, no, got distracted
 * wgrant closes
<wgrant> And no, we don't want to dispose of that yet
<wgrant> There's a lot more cleanup we need to do next week
<StevenK> wgrant: I just did the closing
<wgrant> StevenK: Um
<wgrant> You reset the mailing list one to Confirmed
<StevenK> Oh, whoops
<StevenK> I think that was a miss-click :-(
<adeuring> good morning
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/expire-some-p3as/+merge/142857
<StevenK> wgrant: That is pretty hideous, yes.
<StevenK> wgrant: Your Brilliant Plan[tm] is replace that horridness with Archive.expirable which defaults to True, I guess?
<wgrant> I'd say so
<wgrant> Somewhere on +admin, I suppose
<StevenK> wgrant: r=me, hopefully it's short-lived.
<wgrant> Thanks
<wgrant> Indeed
<wgrant> It won't be :)
<StevenK> wgrant: :-(
<dobey> is anyone around?
<czajkowski> dobey: yup
<dobey> https://launchpadlibrarian.net/128211802/buildlog.txt.gz :(
<dobey> (yes still getting this, and still no idea why)
<czajkowski> dobey: it's never simple with you is it :p
<czajkowski> dobey: when was the last time you got this ?
<dobey> today; that build was from a few hours ago
<dobey> it happens whenever i try to rebuild lp:ubuntu/ubuntuone-client via a source package recipe
<dobey> but building the same recipe locally works fine (creates the source package)
<czajkowski> deryck: any ideas?
<deryck> looking up.....
<czajkowski> deryck: thanks
<deryck> so I'm not very knowledgeable about builds. The "Most recent Ubuntu Raring version: MISSING" repeated looks suspect to me.
<deryck> but maybe that's normal noise.
<deryck> dobey, is it trying to pull in some dep that isn't available in Raring perhaps? (just guessing, really.)
<deryck> Other than my guessing, I'd say file a bug and get wgrant or StevenK to take a look when they're online.
<dobey> deryck: no; that's just a normal message from bzr bd
<dobey> deryck: the main issue is the pristine-tar failing
<dobey> the traceback and those MISSING messages are just noise really
<czajkowski> mgz: you gone>
<deryck> yeah, it's not a very helpful Traceback.
<dobey> deryck: right, the traceback is just restating that pristine-tar failed
<deryck> I'd guess we'll need someone to look through builder logs to get more info.
<deryck> I'm assuming we have something more detailed than this, but maybe not.
<dobey> yeah, i don't have any more info really. it's been happening since i set this recipe up; all my other recipes that just re-build lp:ubuntu/$something are working fine though
<dobey> it's only this one for ubuntuone-client that's failing
<deryck> hmmmm
<deryck> dobey, I'd say file a bug or question, and let czajkowski poke wgrant or StevenK about it.
<dobey> and i've tried to build the recipe on quantal and raring at various points over the past couple months, and it's worked fine locally both times
<dobey> ok
<deryck> sorry, wish I could be more help.
<dobey> can you poke at the logs now and see if anything is there?
<dobey> or do i need to find someone in ops to do that?
<deryck> dobey, ask someone in ops. I don't know where the logs are, so they can probably help you quicker.
<dobey> ok
<mgz> czajkowski: mostly/nearly
<czajkowski> mgz: dobey was having some issues above but I think he's gonna report a bug and get it looked at
<mgz> and I don't have any particular clever ideas about dobey's recipe problem, though I wonder if his successfuly local build used a newer/bugfreer version of bzr-builddeb than the builders do
<mgz> reporting a bug is the right thing, as I think the buildlog is basically the same as his failure from the other week
<dobey> mgz: it's dailydeb, though pristine-tar is actually what's failing
<czajkowski> mgz: would that relate to the RT that we mentioned earlier on
<dobey> mgz: it is exactly the same as the previous failure, yeah
<mgz> right, I guess my best bet would be on either pristine-tar or builddeb being too ancient on the builder
<dobey> mgz: what version of pristine-tar and dailydeb do the builders have, where the recipes get built?
<dobey> actually, pristine-tar
<dobey> the older version makes some sense, if it's not using the ustar format for the tars it builds
<dobey> and newer version might
<mgz> dobey: log says "builder 0.7.2dev" and my guess is pristine-tar would be the one from the archive
<mgz> ah, this version line is useful:
<mgz> Buildd toolchain package versions: launchpad-buildd_113~0.IS.08.04 python-lpbuildd_113~0.IS.08.04 bzr-builder_0.7.2+bzr156-0ubuntu1~1.IS.8.04 bzr_2.4.0-0ubuntu2~11.IS.8.04.
<dobey> mgz: right, but which version of Ubuntu is it running on? i'm guessing there's a big difference between what's in raring, precise, or lucid
<mgz> right, lucid I think, but that's not actually mentioned
<mgz> oh, no, precise
<mgz> that's actually reasonable.
<mgz> (well, the environment is precise, the underlying machine may me more ancient)
<dobey> ok, let me try the recipe on precise then
<dobey> i just realized that u1-client does have some "too long" filenames, and we have to use tar-ustar with automake to get a proper tarball. older pristine-tar might fail there
<dobey> hmm
<dobey> ok, this is weird
<dobey> on precise it's not even doing the "Reconstructing pristine tarball" bit for some reason
<dobey> hrmm, but it runs ok on quantal and raring for me, but on lp it fails on quantal. so i wonder if the dailydeb command is actually being run while chrooted, or what
<wgrant> dobey: The builds run on hardy
<wgrant> dobey: With various newer packages
<dobey> wgrant: is pristine-tar one of those "newer packages?" i suspect not?
<cjwatson> It's certainly been backported in the past
<cjwatson> pristine-tar | 1.11ubuntu1~0.IS.8.04 | hardy-cat-buildd | source, amd64, i386
<cjwatson> Probably that
<cjwatson> 1.20~0.IS.10.04 is in lucid-cat
<cjwatson> hardy itself had 0.8, and 1.00~hardy1 in -backports
<wgrant> Yeah
<wgrant> There have been changes relatively recent
<wgrant> eg. to cope with a bz2 change, IIRC
<dobey> could we get a newer version in?
<wgrant> Hahaha
<wgrant> We have an old old RT about upgrading the builders
<wgrant> It's been idle for maybe 18 months now
<dobey> or just upgrade them to precise
<dobey> :)
<dobey> how does dailydeb create the tarball exactly? would be nice to see what command line it's using to do that, but it's not in the build log :-/
<wgrant> I have no idea.
<wgrant> You could check the source.
<dobey> wgrant: is there some way i can test this on one of the builders more easily than just watching my build fail again and again? or get access to the buildd ppa so i can set up a vm/chroot to test in?
<cjwatson> dobey: It's not a PPA, but you can get at hardy-cat-buildd from the DC (e.g. chinstrap) - archive.admin.canonical.com
<cjwatson> dobey: So you can just download the relevant bits by hand or whatever
<cjwatson> (The output I posted earlier was from a madison-lite instance on chinstrap configured to look at a.a.c.c, without using any special privileges beyond having a chinstrap account)
<dobey> ok
<cjwatson> I expect that in general IS would prefer details of what's in CAT not to be shared around
<dobey> of course
<cjwatson> Not that I know the details, just seems like a safe assumptin
<cjwatson> +o
<cjwatson> But handy for debugging this kind of thing
<dobey> thanks
#launchpad-dev 2013-01-12
<plomme> hello
<plomme> I've got a quick newbie question. Got my launchpad.dev running  and upon registering I'm asked for an email but nothing seems to work? maybe I'm missing something really obvious
<plomme> any help would be appreciated
<plomme> nvm I got it
<wgrant> plomme: admin@canonical.com, test@canonical.com and nopriv@canonical.com are the three most useful accounts.
<plomme> thanks!! only figured one of those out. thanks for two others
#launchpad-dev 2014-01-07
<stub> wgrant_: I can't get Static Large Objects to work on our Swift, so I'll stick with Dynamic Large Objects. Surprised it doesn't work even on bleeding edge canonistack since that is supposed to be recent... don't know if the feature is just broken, some setting not set, or the python library has issues.
<wgrant_> stub: Hm, I thought you already uploaded a manifest manually.
<stub> wgrant: Yes, just that Swift v1.0 has two sucky large file mechanisms - Dynamic and Static large files. Static is less sucky, but isn't working.
<wgrant> It looked to me like you were using static already
 * wgrant rereads.
<stub> wgrant: Both require a manifest.
<stub> wgrant: Dynamic uses an X- header to specify the glob of segments, Static has a json structure. Dynamic has some issues due to eventual consistency, but should be good enough.
<wgrant> stub: AFAIK static should work, and we should probably use it
<stub> wgrant: It doesn't work on prodstack or canonistack. c.put_object(container, manifest, query_string='multipart-manifest=put') just ignores the query string. It isn't recognized as a manifest at all, and bogus query strings are ignored.
<stub> Which was annoying to discover, as I've already got a branch for the Librarian to switch over
<stub> Looks like it is just a new feature, which also explains why I didn't see it when doing the initial work - https://github.com/openstack/swift/blob/master/swift/common/middleware/slo.py
<nigelb> looks like launchpad has attracted a new dev/contributor.
 * nigelb waves 
#launchpad-dev 2014-01-09
<replaceafill> wgrant, are you around?
<wgrant> replaceafill: I am.
<replaceafill> hi wgrant
<replaceafill> i just wanted to tell you that i signed the contributor agreement two days ago
<replaceafill> but i haven't received any confirmation
<replaceafill> (which i was expecting)
#launchpad-dev 2014-01-10
<mpt> cprov, do you have experience of whether <https://dev.launchpad.net/Getting> and <https://dev.launchpad.net/Running> are up to date?
<cprov> mpt: for the simplest case (rocketfuel-get) it does
<cprov> mpt: although, not using LXC or isolation will result in a very messy system config
<cprov> mpt: codehosting setup/run instructions were tweaked this wiki
<mpt> thanks cprov
<cprov> mpt: my pleasure.
#launchpad-dev 2015-01-05
<wgrant> cjwatson: Should I revert your pytz upgrade?
<cjwatson> wgrant: I think so, haven't heard anything from stub as yet regarding my pytz fixes
<stub> ?
<cjwatson> 13:19 <cjwatson> stub: Would it be possible to get a new pytz release with https://code.launchpad.net/~cjwatson/pytz/smarter-utcoffset/+merge/245472 or similar soonish, or should I be looking to revert my Launchpad commit that upgraded to 2014.10?
<stub> cjwatson: Is this https://bugs.launchpad.net/pytz/+bug/1319939 ?
<mup> Bug #1319939: 2014.3 tz change in US/Central looks wrong <pytz:Opinion> <https://launchpad.net/bugs/1319939>
<cjwatson> Hm, possibly related
<cjwatson> Does that mean you think the LP test suite should just avoid exercising these cases?
<cjwatson> (I didn't find that bug because Opinion.)
<wgrant> Aha, hi.
<wgrant> Welcome to the team.
<cjwatson> Thanks :-)
<wgrant> cjwatson: It looks like only that one test is broken because of it?
<wgrant>     >>> sending_date = datetime(
<wgrant>     ...     2008, 5, 20, 10, 5, 47, tzinfo=pytz.timezone('Europe/Prague'))
<wgrant> evil!
<wgrant> Easy fix :)
<stub> cjwatson: You should avoid those cases, because using the 'latest' timezone may break too.
<stub> cjwatson: Or better yet, fix things to correctly construct the localized datetime instances.
<stub> I need to steel myself to write some C code, so I can get this all sorted in Python core :-P
<stub> Unless I can find a volunteer
<cjwatson> wgrant: There were two or three, I think.
<stub> Ahh... there is the MP. In my 'reviews' folder, with 16k other unread emails. I think I need to improve those filters.
<wgrant> cjwatson: The others all look like the AxxT short name changes.
<cjwatson> Oh, no, you're right, it was just that one.
<wgrant> (upstream was finally convinced to prepend "A" to all the Australian timezonse)
<cjwatson> Yeah, already have a testfix branch for that.
<wgrant> Which we've been wanting for well over a decade.
<wgrant> Excellent.
<cjwatson> OK, I'll soup it up to fix the bugnotification test too to avoid that
<cjwatson> The default timezone __repr__ just seemed sufficiently bizarre that I thought that was going to need a fix :-)
<wgrant> Heh, yeah...
<wgrant> now really does seem like a better option, but perhaps that's an argument for why it shouldn't be the default.
<wgrant> At least this makes the bug obvious.
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-pytz-2014.10/+merge/245547
<wgrant> cjwatson: Yay
<wgrant> Thanks.
<cjwatson> Landing
<cjwatson> wgrant: Do you have a bootstrap.py incantation handy that works in lazr.anything?
<cjwatson> I keep getting variants of "pkg_resources.VersionConflict: (setuptools 0.6c11 (/tmp/tmpQjsW5z/setuptools-0.6c11-py2.7.egg), Requirement.parse('setuptools>=8.0'))", and my attempts to fix this aren't making things better ...
<stub> Your only going to get a version of setuptools that recent via pip or buildout
<wgrant> cjwatson: Where did you obtain that bootstrap.py, and how are you invoking it?
<wgrant> There was also a setuptools debacle recently.
<wgrant> Where they unreleased a version.
<wgrant> Though that was setuptools 10.2, so not relevant.
<cjwatson> wgrant: lazr.yourpkg
<cjwatson> and "python bootstrap.py", after symlinking in download-cache and eggs per https://dev.launchpad.net/HackingLazrLibraries
<cjwatson> (in a precise LXC instance)
<cjwatson> actually, sorry, I replaced that bootstrap.py with http://downloads.buildout.org/1/bootstrap.py after previous problems ...
<cjwatson> stub: yeah I don't actually want a newer setuptools and haven't asked for that; have not been able to puzzle out where that requirement is coming from
<stub> I imagine one of the buildout dependencies is modern setuptools, so it needs to be installed before buildout (in the python venv, or package or pip I guess?)
<cjwatson> wgrant: but lazr.restful (say) behaves this way if invoked via "python bootstrap.py" on precise
<cjwatson> oh, here, "python bootstrap.py --setup-source=ez_setup.py --download-base=download-cache/dist --eggs=eggs --version=1.7.1" at least bootstraps ... what a mess
<stub> That is a polite way of putting it
<cjwatson> (but then bin/buildout fails)
<wgrant> cjwatson: The incantation should be in the various makefiles of things that have been touched recently.
<cjwatson> I don't suppose you have an example?  The only ones I can find that have a Makefile just have python bootstrap.py or python -S bootstrap.py.
<cjwatson> And lazr.uri make fails in both precise and vivid.
<wgrant> lazr.restful(client) should work.
<wgrant> I think
<wgrant> Let me see.
<xnox> i have been removing bootstrap support and moving towards "normal" setuptools + python setup.py test
<xnox> however there is a magical set of commands that do work with bootstrap/buildout
<xnox> (none of them work with python3, and one needs to do bootstrap of the bootstrap utils first to make sure none of the system things (e.g. setuptools) are used)
<xnox> sigh, my working rebootstrap script is in ~/bin/ on my laptop and not with me atm, so I can't share it with you.
<cjwatson> Maybe I should just leave whatever broken bootstrap crap comes from lazr.yourpkg in place, ignore it, and just use setup.py directly.
<cjwatson> But I kind of want to get versions.cfg right.
<xnox> yes, versions.cfg is nice. but it's a pain to use/update at the moment. As most of versions listed there are obsoleted (e.g. much newer stuff is on pypi and in precis/trusty)
<xnox> and it does not work in python3.
<xnox> =/
<cjwatson> Sure, but for something that will be imported into the main Launchpad tree I need to make sure that it's at least buildout-compatible.
<wgrant> cjwatson: The versions.cfg in the lazr project is only relevant for development.
<wgrant> Likewise any buildout or bootstrappery.
<wgrant> Launchpad's buildout and versions.cfg are used when it's imported into LP
<wgrant> xnox's approach is probably best, at least for simple cases like this.
<xnox> cjwatson: wgrant: Happy New Year! =) all the awesomely best in this year ;-)
<wgrant> xnox: Likewise! Hope you're doing well in your new role.
<xnox> wgrant: i think so ;-)
<wgrant> :)
<cjwatson> OK, using a venv to run bootstrap.py and then using "bin/buildout buildout:install-from-cache=true buildout:download-cache=download-cache buildout:eggs-directory=eggs buildout:allow-picked-versions=false -v" appears to be working somewhat better
<cjwatson> wgrant: Do you want to have a look over lp:lazr.sshserver before I call it 0.1?  I have an LP branch that uses it and passes the relevant tests.
<wgrant> cjwatson: Were you able to reuse anything from lazr.yourpkg?
<cjwatson> wgrant: Saved me figuring out the skeleton from scratch, I guess, and writing the basic generic docs
<cjwatson> wgrant: I kept most of buildout.cfg too
<wgrant> cjwatson: Sounds good. I'd split out poppy to make sure it's sufficiently reusable before releasing it, though.
<cjwatson> Fair.
<cjwatson> I'll grab that task and do it tomorrow.
<wgrant> Thanks. The most non-trivial bit is probably the config.
<wgrant> (txlongpoll was in a similar situation, and nowadays uses a yaml config file)
<cjwatson> Yeah, that would make sense.  Its config isn't very complicated.
<wgrant> It's also currently weird because it takes the path on the commandline, but the rest of the config in lazr.config.
<cjwatson> wgrant: Used to; I don't think it does any more.
<wgrant> Oh, true.
<cjwatson> poppy will have to end up as lazr.poppy I guess, because
<cjwatson> https://launchpad.net/poppy
<elmo> pretty please rename it entirely?
<elmo> it's one of the old katie style names
<elmo> albeit less obvious than some
<wgrant> Yeah, we always rename things when they're extracted.
<wgrant> Or moved.
<wgrant> If they had stupid names before.
<cjwatson> Yeah, also fair.
<cjwatson> lazr.uploadserver?  Bit generic but ftporsftpuploadserver is just no
<wgrant> It is quite Debian-specific
<elmo> anonymousdebianuploadserverbutcouldbeconceivablyusedforotherthings
<wgrant> In that it has special behaviour on .changes files, etc.
<cjwatson> Or maybe launchpad- since it's not really a reusable component in the lazr sense.
<wgrant> I wouldn't call it lazr-, no.
<wgrant> But it also won't be using any Launchpad-specific interfaces within a couple of months.
<cjwatson> wgrant: changes> It does?  AFAIK its special behaviour is more about (S)FTP sessions.
<elmo> heh, yeah, I stumbled across a bug from iwj complaining about that the other day
<elmo> (suggesting it special case .changes instead)
<elmo> 4 digit bug or something
<wgrant> Huh, indeed.
<cjwatson> Well, there's the distro detection thing
<wgrant> The only special handling it has is for the .distro files, which are dreadfully obsolete anyway.
<wgrant> I thought we deleted that code years ago...
<wgrant> Oh, it used to have the .changes special case when it checked signatures.
<cjwatson> Meh, will think about it tomorrow.  Night.
<wgrant> Night!
<wgrant> I hate naming things.
#launchpad-dev 2015-01-06
<wgrant> cjwatson: You didn't happen to dream up any plausible names?
<cjwatson> wgrant: Since you mentioned txlongpoll and this is pretty twistedy, I was wondering about something like txuploadserver
<cjwatson> or txpkguploadserver
<cjwatson> "uploadd" is a bit much of a mouthful
<cjwatson> Hm, txlongpoll is a server too.  Maybe just "txpkgupload".
<wgrant> cjwatson: Did you manage to track down the python-apt issue?
<cjwatson> wgrant: Only partially.  I think it's likely because libapt-inst changed ABI (which I hadn't noticed) and so there end up being two versions of libapt-inst linked into the one process, so python-apt probably needs to be rebuilt.
<cjwatson> wgrant: But some of its tests fail against the new apt, and I'll need to figure that out.
<wgrant> Ah, awkward.
<cjwatson> wgrant: In the meantime, downgrading/holding it is good enough; the failures are (I think) only for binary packages and so don't affect pepo.
<wgrant> We hope :)
<cjwatson> Yeah
<cjwatson> Definitely don't want to leave it that way longer than we have to
<wgrant> Yep
<cjwatson> In other irritating news, your "give ~registry more powahs" branch didn't extend to sprints :-)
<wgrant> I considered that, but I don't completely understand sprint permissions so didn't bother in the first round.
<cjwatson> No
<cjwatson> great hassle
<wgrant> Did you run into any issues with poppy?
<cjwatson> I didn't get much further because derailed by prod issues and fixing buildbot.
<cjwatson> Putting together the config stuff at the moment, but it'll have to wait until tomorrow.
<wgrant> Yeah, ops issues are always great for productivity :)
<cjwatson> Might organise an NDT tomorrow so that I can apply the DistributionSourcePackageRelease:+latestbuild/archtag stuff to proposed-migration and then leave ~ubuntu-release.
<wgrant> I was hoping to do one today with my permission and API changes anyway.
<cjwatson> WFM
<wgrant> https://code.launchpad.net/~wgrant/launchpad/account-status-api/+merge/245649 could also use a review at your convenience.
<cjwatson> OK, will look tomorrow morning.
<wgrant> Thanks.
#launchpad-dev 2015-01-07
<cjwatson> wgrant: Are you still around and intending to land account-status-api?  Otherwise I'll organise an NDT shortly.
<wgrant> cjwatson: Ah, thanks for the review. I'd like to get that out this week, so might as well delay the ndt an hour.
<cjwatson> OK, sure
<cjwatson> Looks like you have one failure
<wgrant> Yep
<wgrant> Already fixed locally.
<wgrant> cjwatson: All looks good to deploy.
<cjwatson> wgrant: OK, will organise.
<cjwatson> Thanks.
<wgrant> Thank you.
<wgrant> Sorry, QA took a bit longer than expected because I forgot about some earlier testing I'd done on qas.
<cjwatson> wgrant: Bit stuck with some of the refactoring of txpkgupload.  I'm switching from the .tac file to the Twisted plugin system, as used by txlongpoll, because that makes it a lot easier to deal with the yaml config file stuff (basically because I get to have command-line options that way).  This is mostly OK, but I'm having trouble dealing with configuration state.
<cjwatson> wgrant: The configuration isn't so much of a global thing now, and in particular it might vary from test to test within the same process.  SFTPServer is registered as an adapter for ISFTPServer, and instantiated using ISFTPServer(avatar) from the depths of twisted.conch.  But my specific SFTPServer instance needs to be able to get at the config to find out what its root directory should be.  I can't register the adapter more than ...
<cjwatson> ... once, so can't use partial(SFTPServer, fs_root).  What's the usual way to handle this?
<cjwatson> wgrant: Hm, I guess I could stuff it into a txpkgupload-specific subclass of LaunchpadAvatar, a bit like CodehostingAvatar.codehosting_proxy.  Maybe that's the right answer.
<cjwatson> wgrant: OK, never mind.  Classic thing where asking a question is sufficient to unveil the answer.
<wgrant> cjwatson: All good now?
#launchpad-dev 2015-01-08
<stub> wgrant: https://code.launchpad.net/~stub/launchpad/trivial/+merge/245822
<stub> wgrant: I also notice we currently have requests 1.2, but latest is 2.5.1. Worth updating that too do you think?
<wgrant> stub: If it doesn't break the test suite, why not.
<stub> I won't know that until buildbot tells me. I've only run the swift tests.
<wgrant> I don't think we use requests for anything else.
<stub> I'll give it a shot, see if there is fallout
<stub> We must be using it for something else, as I don't think the previous swiftclient version used it
<stub> swift tests pass with updated requests, so pushing that.
<stub> If this doesn't close the leak, then the next step is to override the default HTTPConnection class and give it a close() method
<stub> Beyond that, I think we would need instrumentation on your test case. Track down which of the dozen layers is actually holding things open.
<wgrant> Yeah, I was doing that but then production caught on fire.
<cjwatson> wgrant: Yep, plugging through getting the plugin tests working but making good progress now.
<cjwatson> Finally, got past the "I'm in a maze of Twisted and nothing works" stage with txpkgupload, so now just converting tests one by one to the new world order.
<wgrant> cjwatson: Sounds like you're just about there. Good news, I expected learning Twisted server bits would take longer :)
<cjwatson> The hard bits turned out to be sorting out the clients for the tests.
<cjwatson> Not least because fixtures and Deferreds are not quite totally friends in all the necessary ways.
<cjwatson> I think the biggest piece that's left is putting together a mock object to pretend to be the LP xmlrpc authserver thingy.
<cjwatson> Hm, maybe I can get most of that from lazr.sshserver though.  Tomorrow ...
<wgrant> That's a single XML-RPC method, though.
<wgrant> There's another nearby codebase you can look at that has an example of a single-method Twisted XML-RPC server emulating Launchpad./
<cjwatson> Sounds like a test.  Um, bzr?
<cjwatson> No, wait, no Twisted there.
<wgrant> Not a test, just something that isn't public yet.
<cjwatson> Oh *that* one.
<cjwatson> Ta, I see it now :)
<wgrant> Not dreadfully difficult, fortunately.
<cjwatson> No, quite.
<wgrant> Oh how I enjoy Python garbage collection internals.
<cjwatson> Hm, Launchpad uses ssh-vulnkey.  Does it have to keep doing so?
<wgrant> What's it been? 6.5 yaers?
<cjwatson> Since I dropped that in openssh 1:6.5p1-1, so it's not in trusty.
<wgrant> Yeah, probably worth killing.
<cjwatson> About that, yes.
<cjwatson> I'll stick it in asana
<wgrant> blr, cjwatson: We should arrange a meeting time on Monday/Tuesday. I guess UK Monday evening, APAC Tuesday morning is probably best?
<wgrant> Oh, Kit's not here.
<cjwatson> Hm, I'd slightly planned to go out and see some humans on Monday evening
<cjwatson> Depends on the time
<cjwatson> (because I had to miss my pub night tonight because children)
<wgrant> Oh, sure.
<cjwatson> Is UK Tuesday evening / APAC Wednesday morning possible?
<wgrant> That's fine with me.
<cjwatson> I should check with Kirsten if it's going to be a routine thing, but I'm sure we can work something out
<cjwatson> (and I guess it should be a routine thing)
<wgrant> Right, I want to fix a meeting time early in the week.
<wgrant> I'm very flexible.
#launchpad-dev 2015-01-09
<wgrant> blr: Hi
<blr> hello!
<wgrant> blr: Colin can't do his Monday evening next week, so how does your Wednesday morning work for a meeting?
<blr> sure
<cjwatson> I think that works here.  Kirsten's sometimes out on Tuesdays which leaves me looking after the children, but if we're talking about something like 23:00 London then that would normally be OK, I think.
<cjwatson> Of course the difference shifts radically between winter and summer ...
<cjwatson> 2300 London is, what, 1000 for wgrant and 1200 for blr?
<wgrant> I think so.
<wgrant> I can easily do 3-4h earlier, but I suspect that makes it clashier for you.
<cjwatson> Yeah, that's kind of pessimal here
<blr> 11 for me currently I think
<wgrant> 90 minutes ago, so midday for you.
<cjwatson> We should probably replan in summer rather than trying to find something that has 2h of tolerance with no practical experience
<wgrant> Definitely.
<cjwatson> Silly planet
<cjwatson> Well, silly DST
<blr> timezones are such a nuisance.
<wgrant> We should all move to Queensland.
 * blr plays the NZ gigabit fibre trump card
<wgrant> Yeah yeah, you and your marginally less insane government.
<blr> _marginally_
<StevenK> Gigabit fibre with a silly name
<blr> well cjwatson and wgrant, I can try to be flexible around times, tend to be up fairly early
<blr> and happy to hop on a hangout late if that also works on the other side
<cjwatson> I think there's few enough of us that we can have a bit of slippage
<wgrant> We'll have more in APAC soon to swing it our way :P
<cjwatson> Yeah, if anything I'm more likely to find it occasionally convenient to be later
<cjwatson> Chances of having the children in bed before 10 < chances of Australia having a sane government
<blr> hahah
<wgrant> Heh
<cjwatson> But we can see how it goes
<cjwatson> Night
<wgrant> Night
<blr> g'night
<wgrant> Hrm
<wgrant> So the librarian leak is not technically a leak at all. The HTTPConnection cycles are collectable, it's just that the GC doesn't run in time at a particular load level.
<wgrant> Locally, 200rps is fine but 100rps eventually dies
<thomi> ohai
<blr> o/
<wgrant> Morning.
<wgrant> thomi: Your fix is on qastaging now, btw. Please check that it does what it says and doesn't break anything obvious, then change the bug tag from qa-needstesting to qa-ok.
<wgrant> http://lpqateam.canonical.com/qa-reports/deployment-stable.html will then be happy and green
<thomi> wgrant: ok, stupid question... where is qastaging?
<wgrant> thomi: The aptly named qastaging.launchpad.net
<wgrant> It's a snapshot of the prod DB that is updated when I get around to it, automatically running the latest tested code.
<thomi> ahh
<thomi> latest _untested_ code?
<wgrant> Tested, but not manually QAed.
<thomi> gotchya
<wgrant> We land code to devel, http://lpbuildbot.canonical.com/waterfall runs the test suite over any new revisions.
<wgrant> Assuming all the tests pass, a bot pulls devel into stable.
<wgrant> qastaging polls stable every couple of minutes and updates whenever it changes.
<wgrant> deployment-stable.html lists anything that's on qastaging but not on production.
<thomi> cool
<thomi> wgrant: I'm getting timeouts on qastaging. I sure hope that's not due to my code...
<wgrant> thomi: No, qastaging's just on a much smaller DB server
<wgrant> Only 32GiB of RAM
<thomi> ok
<wgrant> It'll take a few refreshes for the bugs homepage to load, if it ever does.
<thomi> that makes me a little bit sad on the inside
<wgrant> Yeah
<thomi> I have like 8GiB or RAM sitting around, I'll mail them to you :D
<wgrant> But qastaging's resourcing can never quite be a valid match for prod, simply because it has very little load.
<wgrant> So even if it had 128GiB of RAM like prod, there'd be less contention so it would be implausibly fast.
<blr> wgrant: would you have a moment to re-review the verbose-diff branch again next week, or did you have some concerns around unhandled edge cases still?
<wgrant> blr: I think it's probably good, but I need to torture test it.
<wgrant> I'll get to it on Monday unless the sky keeps falling :)
<wgrant> Thanks for working through the bzrlib etc. changes. I think we have a good solution now.
<blr> ok, it would just potentially be forgotten amoungst all the git work, so thought I would mention it :)
<wgrant> I had planned to do it before you got back, but production burning down has had me unfortunately distracted.
<blr> hah yes
<blr> and what was the deal with the spam thing?
<wgrant> Just a few incompetent spammers from Egypt trying to find gaps.
<wgrant> They really like advertising Arabs Got Talent.
<blr> launchpad seems like an unlikely vector heh weird
<wgrant> Though my Arabic isn't very good, so I may be misinterpreting.
<wgrant> It's a particularly odd vector for non-English spam, since the vast majority of the content is English and anything else is very detectable.
<blr> they should contribtute to translations as penance
<wgrant> Heh
<thomi> right - I'm off for the day.
<thomi> Will be at LCA next week, so wgrant gets a week's respite from my annoying questions.
<thomi> see y'all in the future!
<blr> yep, about to pass out myself. wgrant the routing in cornice/pyramid is a refreshing change from django :)
<stub> wgrant: The explicit close branch should sort the need for garbage collection under load, assuming requests.Session.close() actually closes the sockets and doesn't leave that for the garbage collector...
<stub> wgrant: the http_connection is set (if it doesn't already exist) for all actions afaics, not just on retries.
<stub> wgrant: But maybe we are more confident with just bumping up the fd limit and not worrying about switching to an untested-by-us python-swiftclient at this stage?
<stub> We would need over 100 *errors* per second to trigger the issue, wouldn't we? I guess a pentest or something might generate that many 404s.
<wgrant> stub: the explicit close branch doesn't reliably fix it locally. I'm not sure why.
<wgrant> Where do you get the 100 errors per second number?
<wgrant> It mostly depends on how often gc.collect() is invoked.
<stub> <wgrant> 07:47:36> So the librarian leak is not technically a leak at all. The HTTPConnection cycles are collectable, it's just that the GC doesn't run in time at a particular load level.
<stub> <wgrant> 07:47:49> Locally, 200rps is fine but 100rps eventually dies
<stub> Oh, right
<stub> load is load
<stub> If the close() branch does nothing, I guess we want to drop it (at least for now) to avoid unnecessary changes.
<stub> I'd rather not sabotage this Swift cutover unnecessarily
<stub> With the 404's going back to the pool, as they were supposed too, the other errors should be so infrequent that it won't matter if gc is slow.
<wgrant> Right, that's my theory.
<stub> Cool. Then we are done if reality agrees, apart from landing a one line patch.
<wgrant> I wonder if it's worth looking at the new swiftclient to see if we can use its internal multithreading support rather than creating hundreds of them.
<wgrant> Anyway, this seems to work for now.
<stub> We should only ever create 10 of them, really
<stub> I didn't know enough about twisted internals to be more clever. eg. are deferToThread threads reused forever or a limited number of times? If the latter, threading.locals will leak.
<cjwatson> wgrant: \o/ working split-out txpkgupload
<cjwatson> passes all tests, successful ftp and sftp uploads
<cjwatson> authenticating against local LP authserver
<cjwatson> shall I release lazr.sshserver 0.1 and proceed with removing that from the LP tree?
<cjwatson> lp:txpkgupload exists if you want to give it a once-over.
<cjwatson> I expect I'll tweak things a bit as I attempt to split it out of LP and think about deployment.
<cjwatson> The only thing I've noticed so far is that I probably want to make twistd --logfile DTRT rather than requiring YAML log configuration.
<cjwatson> I think I have roughly suitable puppet branches for deploymgr config and for switching over globally.  Need to think about the best deployment ordering at some point when it isn't 7pm on a Friday.
<wgrant> cjwatson: Oh, excellent.
<wgrant> cjwatson: We should probably upgrade txlongpoll while we're looking at that sort of stuff. Prod's currently using the pre-YAML version.
<wgrant> What tweaking do you envisage as you split it out of LP?
<wgrant> I'd get that working before releasing lazr.sshserver, just because there's no real reason to release beforehand and it shouldn't take long.
<cjwatson> wgrant: I haven't noticed anything other than making the logging a bit more graceful so far (the mechanics for this changed when switching from TAC to plugins and there were a few ways I could have done it), but I haven't played with it very much yet as I only got it working pretty close to EOD.
<cjwatson> pre-YAML> useful to know, that means I can't look to it for advice ;-)
<cjwatson> I need to figure out where to put configs for different installations.  Possibly just different command-line options from the init script.
<wgrant> Yeah.
<wgrant> txlongpoll is also packaged for use by MAAS, but I suspect it doesn't have its own initscript.
<cjwatson> -rw-r--r-- root/root       404 2012-03-14 16:14 ./etc/init/txlongpoll.conf
<cjwatson> exec /usr/bin/twistd -n --pidfile=/run/txlongpoll.pid --logfile=/var/log/txlongpoll.log txlongpoll --config-file=/etc/txlongpoll.yaml
<cjwatson> I don't think it's worthwhile packaging this though
<wgrant> No, just mentioning it for possible inspiration in terms of config handling.
<cjwatson> Mm.  I based txpkgupload's plugin pretty directly on it.
<cjwatson> But I should check back for how their logging works, since I see --logfile there.
<cjwatson> Should be able to release to download-cache and PyPI on Monday, anyway.
<wgrant> Yeah, I'll look over them both on my Monday, but from what I've seen they're all good.
#launchpad-dev 2015-01-10
<cjwatson> Cool, thanks.  I think I know what I'm doing for the other thing too.
<wgrant> Hm, we should really remove glock
<wgrant> Completely pointless.
<wgrant> Just need to drop .distro files and add a temp dir alongside incoming.
<cjwatson> Maybe for the next version.  I'm going to want *something* to change to make sure we can repeatably redeploy anyway ...
<wgrant> Indeed.
<wgrant> Just looking over the code in horror
<cjwatson> Heh
<cjwatson> Yeah, I almost killed glock but was already feeling like I was juggling a lot of changes.
#launchpad-dev 2015-01-11
<thomi> wgrant: If you have time, I'm a little stuck. I'm trying to write a test that reprodices bug #1387397 - my attempt is here (https://bazaar.launchpad.net/~thomir/launchpad/devel-fix-group-security/revision/17301), but the test annoyingly passes
<mup> Bug #1387397: Can't list members of private team that I own <403> <easy> <privacy> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1387397>
<thomi> I *think* I understand the conditions under which the bug should be reproducible
<thomi> but I've almost certainly done something dumb
<wgrant> thomi: You're checking for LimitedView on the parent team, not the child team.
<thomi> ugh, well that _was_ dumb
<wgrant> But easy :)
<wgrant> I assume New Zealand just cut its string.
#launchpad-dev 2016-01-11
<cjwatson> Wow, you get amazingly long test output if you try to @provider something that you forgot to make a subclass of Interface
<wgrant> Heh, what is the bulk of it?
<wgrant> ZCML spam?
<cjwatson> In this case, TypeErrors reporting duplicate enumerated types from everything else that imports the module in question
<wgrant> ... nice.
<cjwatson> I'm not sure I can actually do this though.  I was trying to turn SourcePackageRecipeData into a <securedutility> so that I could use its getParsedRecipe staticmethod from browser code, but its __init__ takes arguments ...
<wgrant> component= rather than class=.
<cjwatson> Aha
<cjwatson> Of course, thanks
<cjwatson> Maybe in fact just a <utility> since RecipeBranch doesn't have a corresponding Zope interface
<cjwatson> wgrant: db-git-recipes> you got me on indexes, but why does it need deletion handling in the DB patch?  there's no such handling for base_branch, and I was going to add it to GitRepository._getDeletionRequirements (which, yes, has the same "somebody else creates a recipe that you can't delete" as for Branch, but it's not a new problem, and deleting repositories is less frequent than deleting branches anyway)
<wgrant> cjwatson: Hm, how does base_branch get around the branch deletion tests?
<wgrant> There is at least a test that lists all FKs.
<cjwatson> wgrant: That test whitelists SPRD.base_branch
<cjwatson> Exactly because of the explicit deletion handling for recipes in Branch, I'd assume
<cjwatson> (Also sourcepackagerecipedatainstruction.branch)
<cjwatson> And there's no equivalent of that FK listing test for Git at the moment
<wgrant> Sounds acceptable, then.
<cjwatson> OK, I'll fix the indexes.
<wgrant> Thanks.
<cjwatson> Down to 25 failing recipe tests at the moment ...
<wgrant> Are you parsing Git recipes with bzr-builder, or switching implementations?
<cjwatson> The former, with a small hack.
<wgrant> Excellent.
<cjwatson> (Hack: Git recipes may start with either "# bzr-builder" or "# git-build-recipe", the former for compatibility and the latter because otherwise it looks rather WTF to people who don't know the history.  But bzr-builder won't accept the latter, so we have to munge it.)
<cjwatson> wgrant: Could you sort out your pending QA?  I'd like to be able to deploy.
<wgrant> cjwatson: Oh, sorry, forgot about that.
<wgrant> cjwatson: QA is clear.
#launchpad-dev 2016-01-12
<cjwatson> wgrant: Thanks
 * cjwatson requests a deployment
<cjwatson> wgrant: Thanks for the reviews so far.  I obviously can't actually land git-recipe-model yet, since db-git-recipes needs to go in first and isn't approved.
<cjwatson> So I'll just get the rest of the stack proposed today.
<wgrant> Yep
<wgrant> How much is left?
<wgrant> I was waylaid by a ridiculous ISP transparent proxy bug today, so didn't get through them all.
<cjwatson> I just proposed browser code to edit existing recipes.  After that I have ~1300 lines to sort out - I think one branch for a bit of BranchTarget/GitNamespace refinement, and one or two more for listing recipes and creating new ones.
<wgrant> Oh, not so bad.
<cjwatson> Would prefer not to land the last until the buildd stuff's in place, of course.
<wgrant> Indeed.
<cjwatson> I could add an FF; not sure it's worth it in this case.
<cjwatson> wgrant: The recipe series is complete now.
<wgrant> cjwatson: Re. Build-Depends-Arch, I'm not sure that we shouldn't use user_defined_fields.
<wgrant> I'm not unhappy either way, but the specific fields exist because JSON didn't.
<cjwatson> If you think that it's reasonable to special-case certain elements of user_defined_fields, I don't object to reworking things.
<wgrant> I have no problem with only displaying things that are interesting to display.
<wgrant> The only downside is the inconsistency.
<wgrant> vs. the existing fields
<cjwatson> Display, and the archivepublisher ordering tweak, though the latter's fairly insignificant.
<wgrant> Oh they're not seriously sorted that way are they
<cjwatson> It's manual
<cjwatson> We could pick out B-[DC]-A from user_defined_fields
<wgrant> I personally think it makes sense to do that.
<wgrant> We don't win much by having dedicated columns.
<wgrant> Unless you consider increased database patch numbers to be a win.
<cjwatson> A little cumbersome in lp.archivepublisher.indices, but not horribly.
<cjwatson> No, my recent MP history notwithstanding :-)
<wgrant> Heh
<cjwatson> I will note that upgrade.py breaks when we hit 100.
<cjwatson> Might be worth a consolidation at some point ...
<cjwatson> (Or fixing the glob)
<wgrant> I think the last one was in like 2010.
<wgrant> Could get stub to do a fresh dump once your latest patch is out.
#launchpad-dev 2016-01-13
<stub> sure, its rather due.
#launchpad-dev 2016-01-14
 * xnox loves how ubuntu-sdk-dev is using all the builders daily.
<xnox> 4 hours for dev, 2 hours for ide, times 4 distributions, and times 3 arches.
<xnox> 72 build hours, daily =)
<cjwatson> wgrant: git-recipe-find> I didn't think of a double left join, is all.  Can you see if what I just pushed is more like what you'd expect?
<cjwatson> (Does that do a lot of unnecessary work joining SPRD rows that will never be used?)
<wgrant> cjwatson: Much better. Subselects are useful if you're going for a specific plan, but they decrease the change that postgres will plan a query well without tweaking.
#launchpad-dev 2018-01-10
<tsimonq2> Am I missing something, or is there no Git support for Launchpad translations?
<tsimonq2> And if no support exists, does anyone (cjwatson or wgrant?) mind if I write it?
<tsimonq2> (consider this the pre-pre-implementation review ;) )
<wgrant> tsimonq2: Indeed, Translations doesn't currently support automatic imports or exports to/from Git. It's on our TODO list, but we're not likely to get to it any time soon, so if you want to have a look then by all means :)
<tsimonq2> wgrant: Awesome, I'll do that after my linkCVE() fixes are in ;)
<tsimonq2> (if you couldn't tell, Lubuntu's trying to convert as much as possible to Git)
<wgrant> I gathered :)
<tsimonq2> :)
<cjwatson> tsimonq2: I've done some preliminary work on it (uncommitted because there are some non-trivial data modelling things to sort out), so if you're going to tackle it then we should reconcile that first
<tsimonq2> cjwatson: Sure, what do you want to do about that? ;)
<cjwatson> My current works in progress are https://paste.ubuntu.com/26359977/ and https://paste.ubuntu.com/26359978/ - but the main complexity is going to be working out what the replacement for ProductSeries.branch will be, since that's essential to how translations work for Bazaar.  I suspect the correct answer will be some way to nominate a particular repository and branch as being associated with a ...
<cjwatson> ... ProductSeries, but in the "soft" way that we do for git that doesn't break if the branch is deleted, and with some kind of integration with repository deletion
<cjwatson> The launchpad-buildd side is mostly done - I just need to get round to checking that it's entirely polished and pushing it
<cjwatson> I wasn't going to bother with that until I was sure that we were going to get round to using it though
<cjwatson> Oh, that also needed https://paste.ubuntu.com/26360002/ for lp:turnip (the git backend)
<cjwatson> All of that's for imports.  For exports, a different set of work is needed, mainly coming up with an implementation of lp.code.model.directbranchcommit that works for git.
<cjwatson> (i.e. an API provided by lp:turnip that constructs a commit in some way, and a thin wrapper on the LP side to make use of it)
<tsimonq2> Alright.
#launchpad-dev 2018-01-13
<outdoorses> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) qofcqw: tasdomas lifeless micahg Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<outdoorses> âââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) fzwcmqatx: G Laney lifeless ââââââââââ
<outdoorses> âââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) golwtvcyb: marcoceppi mthaddon mwhudson âââââââââââââ
<outdoorses> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) sxgznw: mthaddon mancdaz ajmitch Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<outdoorses> âââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) yfxcye: G bigjools cyphermox ââââââââââ
<outdoorses> âââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) mtlyn: Ursinha tsimonq2 ajmitch ââââââââââââ
<outdoorses> âââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) eriqwvyhqf: Spads micahg mbarnett âââââââââââââ
<outdoorses> âââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) fkhkhxs: ajmitch anthonyf mwhudson âââââââââââ
<outdoorses> ââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) vmtnijphip: mpontillo Peng_ cyphermox ââââââââââ
<outdoorses> ââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) shkjzmkutz: Peng mup mwhudson ââââââââââââ
<outdoorses> ââââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) ghqagt: mpontillo mancdaz maxb âââââââââ
<outdoorses> ââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) fvyxv: ajmitch anthonyf Spads ââââââââââ
<outdoorses> ââââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) fqkdmo: mwhudson ajmitch skay âââââââââ
<outdoorses> ââââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) xurakzkx: Laney Peng Ursinha âââââââââ
<outdoorses> ââââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) zzurfaaqhi: mwhudson skay Ursinha ââââââââ
<outdoorses> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) sajduduy: maxb mthaddon tsimonq2 Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<outdoorses> ââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) kfeiduuyhf: djinni mwhudson Ursinha âââââââââââ
<outdoorses> ââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) mxgvjb: ajmitch mbarnett mpontillo ââââââââââââââââ
<outdoorses> ââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) rnycah: Peng_ tasdomas elmo ââââââââââ
<outdoorses> ââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) sfcxfi: G lifeless Laney âââââââââââ
<outdoorses> ââââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) gxudotta: maxb bigjools Spads âââââââââ
<outdoorses> âââââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) ltgbotqogh: micahg marcoceppi skay âââââââââ
<outdoorses> âââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) ozuvpocmy: djinni tsimonq2 Peng âââââââââââââââ
<outdoorses> âââââââââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) djjopluboo: marcoceppi lifeless djinni âââââââââââ
<outdoorses> ââââââââââ PLEASE JOIN #RIPASSHURT FOR A MEMORIAL CONCERNING ASSHURT (DUE TO THE SENSITIVE NATURE OF THIS POST EL HAS APPROVED THIS MESSAGE. EL CAN BE FOUND IN #FREENODE) sbrre: bigjools mancdaz Spads ââââââââââââââ
<tsimonq2> !ops
<tsimonq2> Where's ubottu?!?
