[08:28] <adeuring> good morning
[08:28] <wgrant> Morning adeuring.
[08:28] <adeuring> hi wgrant!
[08:29]  * wgrant prepares a few post-exam branches.
[08:33] <gmb> Right. Big pot of Java, time to resolve some conflicts.
[08:34] <wgrant> gmb: Is that the branch from... before the open-sourcing?
[08:35] <gmb> wgrant: You know, I can't remember when I started this fricking thing. Possibly. Async dupefinder.
[08:35] <gmb> It's one of those "everyone thought it was less important than I did" branches.
[08:35] <wgrant> gmb: Yeah, that's the one that has been on +activereviews since the start.
[08:35] <gmb> Hahaha.
[08:36] <wgrant> But if you fix it, Ubuntu will drown in bugs even more :(
[08:36] <gmb> wgrant: Well, I actually think I'm going to just junk it and start over. The conflicts are pretty huge and they're mostly to do with the template redesign. I can cherrypick the javascript out of the original branch
[08:37] <gmb> wgrant: Nah, we'll just disable it for Ubuntu so that the interface keeps timing out all the time.
[08:37] <gmb> Fuck, the branch doesn't even *build*.
[08:37] <gmb> Man alive.
[08:37] <wgrant> gmb: Awesome.
[08:38] <gmb> Right, I'm gonna delete me some branches.
[08:38] <wgrant> adeuring: Can you please ec2test & land those two branches of mine?
[08:39] <adeuring> wgrant: thanks for the reminder! will do it right now
[08:39] <wgrant> adeuring: Thanks.
[08:47] <gmb> Oh for AJAX filtering in bug searches.
[08:49]  * maxb has a small change for the pygettextpo makefile: https://code.edge.launchpad.net/~maxb/pygettextpo/makefile-fix-version/+merge/14256
[09:09] <wgrant> bigjools: Do you want to do a quick review of https://code.edge.launchpad.net/~wgrant/launchpad/sourcepackageformat-to-sourcepackagetype/+merge/14581?
[09:09]  * wgrant is splitting the super-branch.
[09:09] <bigjools> sure
[09:10] <gmb> Can we take TAL out and shoot it, please?
[09:10] <gmb> It's harshing my mellow.
[09:11] <bigjools> twisting your melons
[09:11] <bigjools> wgrant: if only all reviews were as easy
[09:11] <gmb> bigjools: This melon is for display purpose only.
[09:12] <bigjools> gmb: slightly scratched?
[09:12] <gmb> 'Chafed' is the word.
[09:13] <mrevell> Morning troops.
[09:13] <bigjools> eyup mrevell
[09:13] <bigjools> wgrant: I'll land that for you
[09:15] <wgrant> bigjools: Thanks.
[09:19] <wgrant> gmb: How many branches did you get through before son-of-bride-of- or whatever it is?
[09:19] <gmb> wgrant: 3. I should have made more of an effort to split them up, really, but there were certain very large changes that were pretty much atomic.
[09:41] <bigjools> wgrant: did you see https://bugs.edge.launchpad.net/soyuz/+bug/478691 ... jeez
[09:42] <mup> Bug #478691: empty ppa builders should allow more builds from a single ppa <Soyuz:New> <https://launchpad.net/bugs/478691>
[09:45] <wgrant> bigjools: I did say that would happen.
[09:45] <wgrant> bigjools: The current algorithm sucks. It just sucks less than the old one for non-daily PPAs.
[09:45] <wgrant> I do not know how to make it better :(
[09:45] <bigjools> me neither
[09:46] <bigjools> other than adding more builders
[09:46] <wgrant> Conserving some fraction of builders for expected short builds seems like it could work OK. But it needs a lot of careful thought.
[09:50] <wgrant> We need to start discriminating against either daily PPAs or long builds. I cannot see a way around it.
[09:50] <bigjools> we could auto-lower the priority for anything with a high build ETA
[09:51] <wgrant> That doesn't help much.
[09:51] <wgrant> It just means that the rest of the queue has to clear for 5 seconds, and the daily builds will immediately monopolise every builder for three hours.
[09:51] <bigjools> who said anything about removing the current fix?
[09:51] <bigjools> it seems we have 2 situations
[09:52] <wgrant> The current fix is annoying.
[09:52] <bigjools> either the long-build PPA owners complain, or everyone else complains
[09:52] <bigjools> either way there's a lot of complaining
[09:52] <bigjools> the current fix annoys the fewest people
[09:53] <wgrant> I will also complain when I upload a few several-minute builds and it takes a couple of hours to build.
[09:53] <wgrant> While 45 builders sit idle.
[09:54] <gmb> Wow, bugspam from adeuring1!
[09:55] <adeuring1> gmb: yeah, time tp update some bug statuses ;)
[09:55] <gmb> adeuring1: Oh, sod, you're right. I'd forgotten.
[09:55] <bigjools> wgrant: have you seen that happen?
[09:55] <wgrant> bigjools: I haven't watched that closely, but I'm 99% sure it has.
[09:56]  * gmb does the same thing
[09:56] <wgrant> bigjools: Why wouldn't it have? It's a very common case.
[09:56] <wgrant> Upload a few new versions to each series.
[09:57] <wgrant> In most cases (at least in my TZ) that will not put any significant load on the build farm for very long at all.
[09:57] <bigjools> wgrant: ok - so the only thing I can think of to make this better is to allow the extra build to start if there's an empty queue
[09:57] <wgrant> bigjools: But then that will cause daily builds to monopolise again.
[09:58] <wgrant> We need to actively discriminate against either daily build PPAs or long builds simply on the attribute of being daily build PPAs or long builds.
[09:58] <bigjools> wgrant: the daily builds need more than one builder to complete within 24 hours it seems
[09:58] <wgrant> bigjools: They do.
[09:59] <bigjools> rock -> me <- hard place
[09:59] <wgrant> bigjools: The current restriction is too restrictive for even daily builds.
[09:59] <wgrant> But there needs to be *some* restriction.
[09:59] <wgrant> Just a slightly smarter one.
[09:59] <bigjools> so bump to 2 builders from 1?
[09:59] <wgrant> ETOOSTATIC
[10:00] <bigjools> or allow all builders as before unless we know it's a long build
[10:00] <wgrant> Not all, I don't think.
[10:00] <wgrant> But some large fraction.
[10:00] <wgrant> And a much smaller fraction if they are going to be long.
[10:00] <wgrant> But that still has a problem if there are lots of daily PPAs.
[10:00] <bigjools> hmmm
[10:01] <bigjools> we need more builders
[10:01] <wgrant> So some fraction needs to be reserved for un-long builds.
[10:01] <wgrant> al-maisan_'s quit message is very relevant.
[10:01] <bigjools> so is my away message :/
[10:01]  * wgrant doesn't know that one.
[10:02] <wgrant> Ah.
[10:02] <wgrant> I see.
[10:02] <bigjools>  /away
[10:02] <bigjools> fail
[10:03] <wgrant> Describes this situation rather well.
[10:04] <wgrant> Somebody needs to think and draw up lots of cases.
[10:09] <al-maisan> wgrant: I was reading up on this topic a bit and the only paper that seemed even remotely pertinent was: http://www.springerlink.com/content/t4t2643046427702/
[10:10] <al-maisan> wgrant: you may have free access to it since you're still a university student
[10:10] <wgrant> al-maisan: Let me see if I can get it through the uni library proxy.
[10:10]  * al-maisan was appalled about the lack of any grammar proof-reading in this article
[10:16] <wgrant> Doesn't look like I have access to that, sadly.
[10:59] <wgrant> bigjools: Bug #476036 probably wants to be worked on with some priority.
[10:59] <mup> Bug #476036: sbuild needs to run dpkg-source inside the chroot <Launchpad Auto Build System:New> <https://launchpad.net/bugs/476036>
[10:59] <bigjools> wgrant: yeah
[10:59] <bigjools> I'll poke lamont
[11:16] <bigjools> wgrant: http://pastebin.ubuntu.com/313996/
[11:16] <bigjools> brb, need caffeine
[11:17] <wgrant> bigjools: That looks like it should only fix the opposite situation :(
[11:17] <wgrant> Although.. hm.
[11:23] <bigjools> I've not looked at it in detail - it was to fix the upload problem
[13:27] <leonardr> i upgraded to karmic and now i'm getting the infamous "no module named psycopg2" error when running launchpad tests. does anyone know the solution (and is there a troubleshooting page on the wiki for this kind of thing)?
[13:28] <leonardr> i can import psycopg2 from a normal python shell but not from the bin/py shell
[13:34] <mars> leonardr, the upgrade kills the launchpad-developer-dependencies package, and the LP ppas - did you re-enable them?
[13:35] <leonardr> mars: thanks, argh
[13:35] <leonardr> that's my least favorite feature of ubuntu--it gets me every time
[13:37] <mars> heh, same here.  I wish we could fix the Software Sources dialog so it doesn't just say 'disabled by upgrade': 'and exactly which PPA was disabled, anyway?'
[13:38] <bigjools> it got me too, that one
[13:38] <mars> hehe
[14:02] <leonardr> mars: i'm not getting "ImportError: libgettextpo.so.0: cannot open shared object file: No such file or directory"
[14:02] <leonardr> s/not/now/
[14:03] <leonardr> looks like i might be missing a zope package...
[14:03] <leonardr> but perhaps that package ought to be put in sourcecode/
[14:04] <sinzui> leonardr: I think that is pygttext in sourcecode.
[14:04] <leonardr> hmm
[14:04] <leonardr> ok, i guess the problem is that it's looking for .so.0 and only .so is in that directory?
[14:05] <sinzui> leonardr: I think that is sourcecode/pygettextpo
[14:06] <sinzui> We don't hack on pygettextpo or old_xmlplus (dtdparser) I wonder what needs to happen to make them eggs
[14:06] <leonardr> adding a symlink doesn't help
[14:06] <leonardr> i wonder who's looking for .so.0?
[14:07] <leonardr> gary, maybe you have a clue
[14:07] <leonardr> i'm trying to get launchpad working again after karmic upgrade
[14:08] <gary_poster> ok
[14:08] <leonardr> when i run 'import gettext' from bin/py or try to run the tests, i get this error:
[14:08] <leonardr> ImportError: libgettextpo.so.0: cannot open shared object file: No such file or directory
[14:08] <leonardr> sinzui said it might be looking in sourcecode/pygettextpo
[14:09] <sinzui> leonardr: I did, but I see 'import gettext' as something else :(
[14:09] <leonardr> sinzui: i gave the symlink the wrong name. giving it the right name makes it work.
[14:10] <stub> leonardr: Shot in the dark, but try removing all the 'build' directories under sourcecode. make clean and friends doesn't seem to clean sourcecode properly which I found out this weekend (trying to use a rsynced tree build on 64bit on a 32bit machine)
[14:10] <sinzui> leonardr: gettext somes with python
[14:12] <mars> stub, yeah, there was a mailing list thread about that IIRC.  "make clean doesn't follow the GNU Makefile conventions"
[14:12] <gary_poster> leonardr: I don't know.  What happens when you try ``$ locate libgettextpo.so``
[14:12] <gary_poster> ?
[14:14] <mars> stub, ideally we would have 'make distclean', which would do as you say: kill everything, as if it were a fresh checkout of trunk/.
[14:14] <stub> Do you mean like realclean should be doing?
[14:15] <mars> I think so.  In GNU terms, distclean == realclean
[14:15] <mars> we just grab a new copy of the branch, but the tradition is to run 'make distclean' before 'make dist'
[14:30]  * maxb finds "bzr clean-tree --unknown --ignored --detritus --force" to be rather useful
[14:31] <maxb> gary_poster: Hi. ftr, ztk-2.5 passed everything (barring the broken c-i-p needing test) after a merge of 3.1.10 final
[14:33] <gary_poster> maxb: awesome!  (and I regard the broken CIP as a burning issue for this week, so hopefully that will be squashed)
[14:33] <gary_poster> broken CIP-needing-test I should say
[14:51] <gmb> Hell, tracking down these 'o is null' errors in YUI is a pain.
[14:51] <bigjools> wgrant: still up?
[15:13] <gary_poster> maxb: also ftr, per your question this weekend about wanting to see a discussion I had had about packaging, foundations is moving their more focussed channel to freenode: #lp-foundations .  I documented it on https://dev.launchpad.net/Help .
[15:14] <maxb> gary_poster: I have a feeling freenode would prefer you kept to a single project identifier - i.e. don't be both #launchpad and #lp
[15:15] <gary_poster> maxb: hm, ok, so #launchpad-foundations you mean?
[15:15] <maxb> yes
[15:15] <gary_poster> alright
[15:15] <Ursinha> hey danilos
[15:15] <danilos> Ursinha, hey hey
[15:16] <Ursinha> I see one of those TraversalErrors on Saturday, in translations, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1407F2349
[15:16] <Ursinha> danilos, is this supposed to happen?
[15:16] <danilos> Ursinha, well, yes :)
[15:17] <danilos> Ursinha, look at https://bugs.launchpad.net/rosetta/+bug/462891/comments/11, this is now in translations-export.pt, and there are a number of other cases where it can happen (either on translations pages or on the other pages listed there)
[15:17] <mup> Bug #462891: user.preferredemail shouldn't be None <oops> <qa-ok> <Launchpad Foundations:New> <Launchpad Translations:Fix Released by danilo> <https://launchpad.net/bugs/462891>
[15:18] <danilos> Ursinha, it can also happen somewhere else in code, so it's probably best to fix this in preferredemail property, but I'd like foundations team to take care of that
[15:18] <danilos> Ursinha, we've just worked around the most common one
[15:18] <Ursinha> danilos, I understand
[15:18] <danilos> Ursinha, my other branch attached to the bug fixes it in the property, but I don't know how to test it
[15:32] <sinzui> danilos: ping
[15:32] <danilos> sinzui, hi
[15:33] <sinzui> danilos: I am looking at https://edge.launchpad.net/ubuntu/lucid/+packaging. I want to know what has to happen to make these packages linked. When I look at one, It appears to be linked: https://edge.launchpad.net/ubuntu/lucid/+source/gnome-termina
[15:34] <sinzui> danilos: Is there something else that must happen to satisfy translations?
[15:35] <danilos> sinzui, it'd be nice for those links to automatically propagate over series, or even better, to be shared among them
[15:36] <danilos> sinzui, for example, https://edge.launchpad.net/ubuntu/lucid/+source/gnome-terminal/+packaging shows links but there's no karmic or lucid in there
[15:36] <sinzui> danilos: I see the auto-linking bug. I scheduled it for this release. I am not sure what is missing since the example is linked to a  series (though I know it should be master, not main)
[15:36] <danilos> sinzui, and it'd be PITA to ask people to manually enter them with every ubuntu release
[15:36] <danilos> sinzui, right, I'll let you worry about solving that problem then
[15:37] <danilos> sinzui, the other thing that translations need is a nice way to guide people from an ubuntu source package to register a project and automatically link it to that source package in all relevant ubuntu releases
[15:37] <sinzui> danilos: So you thinking is that while the linked series is carried forward, the packaging link is not created
[15:38] <danilos> sinzui, yeah
[15:39] <sinzui> danilos: bac and I discussed this briefly. I think that is good for this series, but preventing regressions (like the missing links) is more important. If I can fix these this release, we know the remaining work is to lower the barrier to setup a mirrored project
[15:40] <danilos> sinzui, ideally though, we'd have an option of just linking a product and (distribution, sourcepackagename) apart from the existing links ( (distroseries, sourcepackagename) <-> productseries)
[15:40] <danilos> sinzui, right, that's about it then
[15:40] <sinzui> danilos: I have seen that bug about just product.
[15:41] <danilos> sinzui, as I said, the above are just my thoughts on what'd be nice, but I don't want to try to impose my solution to the problem :) you are free to fix existing system if you think that's better and/or easier
[15:42] <sinzui> I'll collection my notes this week and send the to you and the others to comment on.
[15:42] <danilos> sinzui, excellent, sounds good! thanks for looking into it
[16:26] <leonardr> gary, stub: reopening the pygettextpo drama...
[16:26] <leonardr> i followed stub's suggestion and removed the build directories, then did make clean and make
[16:26] <leonardr> now there's no longer any gettextpo.so in sourcecode/pygettextpo, and i don't know how to build one
[16:27] <gary_poster> leonardr: looking
[16:27] <gary_poster> leonardr: rocketfuel-get might do the right thing
[16:27] <gary_poster> but looking
[16:28] <gary_poster> I don't have a .so there either
[16:28] <gary_poster> oh yes I do
[16:30] <gary_poster> leonardr: I'm trying to dupe
[16:31] <leonardr> gary: ok, rocketfuel-getting
[16:31] <gary_poster> leonardr: skeptical of myself.  feel free, but probably won't help is my new new new opinion
[16:31] <leonardr> i agree
[16:40] <gary_poster> leonardr: not helpful news, but I removed build from pygettextpo, did a make clean and then a make and got gettextpo.so back.
[16:42] <gary_poster> leonardr: maybe do ``make clean`` and then ``make SHHH=`` and pastebin the output for me?
[17:06] <gary_poster> kfogel: hi.  I forget, are you off today or Fri?  Would like to ask you for permission to proceed with trying to get ~launchpad-committers to happen, per email from maxb this weekend.  Maybe need permission from flacoste; he has not weighed in yet.
[17:06] <leonardr_> gary: i don't know how much of my rambling you saw earlier, but here's the result of make (with an error)
[17:06] <leonardr_> https://pastebin.canonical.com/24523/
[17:06] <gary_poster> leonardr_: I didn't see anything.  Looking
[17:06]  * leonardr_ hopes internet is back for good
[17:07]  * maxb mumbles about private pastebins
[17:07] <kfogel> gary_poster: (on phone, or about to be, but will look as soon as off.  it's just a standup call)
[17:07] <kfogel> maxb: :-)
[17:08]  * gary_poster helps leonardr_ and maxb : http://paste.ubuntu.com/314235/ :-)
[17:09] <maxb> leonardr_: Can you try running 'make PYTHON=python2.4 PYTHON_VERSION=2.4' in sourcecode/pygettextpo/ ?
[17:10] <leonardr_> sure
[17:10] <maxb> leonardr_: And also, do you somehow not have python2.4-dev installed? Nor launchpad-developer-dependencies ?
[17:10] <leonardr_> argh, it looks like 2.4-dev was removed in the karmic upgrade
[17:10] <maxb> Well, yeah, that'll break things :-)
[17:10] <gary_poster> heh
[17:10] <gary_poster> thanks maxb
[17:11] <gary_poster> leonardr_: check launchpad-dependencues too
[17:11] <gary_poster> that should have required python2.4-dev
[17:12] <gary_poster> IIRC
[17:12] <maxb> I think lp-dev-deps depends on the other two
[17:12] <gary_poster> maxb: ah ok
[17:12] <gary_poster> maxb: do you have an opinion about the python2.5-dev thing you raised on the weekend, and to which I replied briefly?
[17:13] <gary_poster> That is, do you think I should include python2.5 versions of all of the python2.4 things?
[17:13] <gary_poster> I'll go to flacoste if you are not sure.  He is the keeper of this key.
[17:14] <maxb> Theoretically, if we want a working python 2.4 and python 2.5 launchpad environment, we should include them,
[17:15] <gary_poster> That's what I figured
[17:15] <maxb> Practically, however, I don't think any packages that support python2.4 but don't support python2.5 will exist
[17:15] <maxb> So really it's only a matter of theoretical correctness, not actual breakage
[17:16] <maxb> Oh, and on the subject of policy w.r.t the bzr branches - policy? what policy? :-)
[17:16] <maxb> Basically "bzr push what you dput"
[17:16] <gary_poster> OK.  Maybe I'll stick with the current change, and then when we go to Py 2.5 with the codebase, switch all the 2.4 bits to 2.5, at which point it sounds like we will be theoretically correct also.
[17:17] <maxb> Agreed.
[17:17] <gary_poster> Cool.
[17:17] <gary_poster> policy: heh, fair enough.  Perhaps I was thinking more of instructions
[17:17] <gary_poster> That is, do I check out the branch, and then that's the same as if I had gotten a source deb?
[17:17] <maxb> You are right, it would be good to lay down some advisory instructions, rather than assuming that everyone's "common sense" is aligned
[17:17] <gary_poster> heh
[17:18] <maxb> gary_poster: That's the intent.
[17:18] <gary_poster> maxb: ok, cool.  I'll make a stab at an initial wiki doc for more knowledgable people to correct.  After lunch. :-) Thanks much.
[17:18] <maxb> We probably ought to specify the appropriate cmdline to invoke dpkg-buildpackage too - it's a bit pointless uploading a copy of the branch in the source package (which 0.55 has)
[17:19] <gary_poster> ah, yes, that sounds like something I would never have thought of
[17:19] <gary_poster> ok running away for a bit
[17:35] <Ursinha> rockstar, hi
[17:36] <Ursinha> rockstar, I'm chr this week and checking all the pending vcr-imports
[17:36] <Ursinha> rockstar, I see one that the repo url is valid, but it has no files in it, yet, maybe
[17:36] <Ursinha> rockstar, should I approve it or is it going to bork somehow?
[17:55] <leonardr_> gary: i'm having another, even stranger problem
[17:56] <leonardr_> i'm trying to set up a launchpadlib branch, and it's using lazr.restfulclient 0.9.3 even though setup.py specifies >=0.9.9
[17:56] <leonardr_> do you know what could cause that to happen?
[17:56] <leonardr_> i'm going to remove my old lazr.restfulclient eggs but it's annoying
[17:56] <gary_poster> leonardr_: so, this is not in launchpad, but in a branch.  Yes, I know what would cause that.
[17:56] <gary_poster> 1 sec
[17:57] <leonardr_> np
[17:59] <leonardr_> this is rich, i don't even have a 0.9.3 egg
[17:59] <gary_poster> leonardr_: the explanation of what is going on is long and annoying.  I'll describe at some point, but for now summarize that you will need to do one of these: (1) remove *all* lazr debs; (2) use the zc.buildout version that launchpad uses; or (3) use a non-system Python.  I recommend 3, and that is what I do for the non LP work.
[18:00] <leonardr_> ah, the deb is to blame
[18:01] <leonardr_> i see. now that apport uses launchpadlib, my previous strategy (1) is no longer tenable
[18:01] <leonardr_> gary, can you run me through (3)?
[18:04] <gary_poster> leonardr_: download a Python from Python.org.  Install with a --prefix that puts it somewhere in your home dir.  I then add it to a ~/bin (using names like 24python 25python and 25python) and set my PATH to include ~/bin.  use that Python for bootstrap. Done
[18:04] <gary_poster> (there are many variants; that's just what I do)
[18:04] <leonardr_> all right
[18:09] <mrevell> Night colleagues
[18:13]  * maxb wishes for a time machine to go back and stop the concept of a lazr.* namespace being invented
[18:16] <leonardr_> gary: --prefix is a configure argument, right? i'm getting through configure and make but python setup.py is failing me
[18:17] <gary_poster> leonardr_: yes, configure.  don't use python's setup.py.  do ``./configure --prefix=...`` then ``make`` then ``make install``
[18:18] <leonardr_> aha, make install, thanks
[18:21] <leonardr_> ok, that's working, but i need to install some dev packages like lib-devreadline to make this environment nicer
[18:31] <leonardr_> gary: i'm investigating this now, but maybe you know. what dev package do i need to install to compile a version of python that speaks https?
[18:32]  * leonardr_ trying libssl-dev
[18:33] <gary_poster> leonardr: that's what I was going to recommend, yes
[18:33] <gary_poster> I have it installed
[18:34] <kfogel> gary_poster: back
[18:34] <gary_poster> kfogel: cool
[18:34] <kfogel> gary_poster: sorry, remind me of context.  the ~launchpad-committers team will be for [?]
[18:36] <gary_poster> kfogel: everyone who can commit to LP.  Therefore, LP Canonical employees plus people like maxb, wgrant, and so on.  Use cases are primarily for making a place for branches that everyone can access who should be able to access.
[18:36] <gary_poster> there was some discussion of other uses
[18:37] <maxb> kfogel: e.g. I'd quite like write access to the meta-lp-deps branches, and I'd like a place to move the branches currently owned by the launchpad-dev open team to.
[18:37] <kfogel> gary_poster: hunh.  I remember being in favor of this, but I can't remember why now.  Everyone has r/o access to all branches, except security branches.  Would this new list have access to sec branches too?
[18:37] <kfogel> gary_poster: or is this about write access?
[18:38] <maxb> This is about community write access
[18:38] <gary_poster> kfogel: write access, for branches not managed by pqm
[18:38] <kfogel> gary_poster: if about write access, is the idea that any branch to which both a canonical dev and a community dev can read, they can also both write?
[18:38] <gary_poster> kfogel: not necessarily because of PQM
[18:38] <gary_poster> but in some cases
[18:38] <kfogel> gary_poster: so, I thought our goal was for community devs to be able to merge via PQM the way we do.  Is that not the case?
[18:38] <gary_poster> kfogel: that is the case but we do not have all branches managed by PQM
[18:39] <gary_poster> kfogel: cases include lazr.*, launchpad-dependencies branches, and the Python 2.5 sprint work
[18:39] <kfogel> gary_poster: but I mean, that's the main use case right?  That is, community devs being able to submit to PQM for stable, db-stable, devel, db-devel ?
[18:39] <maxb> It is a shame that ~launchpad-dev is already taken as a name - ~launchpad-committers is a bit of a long name to type in branch urls
[18:39] <kfogel> maxb: yeah
[18:40] <maxb> kfogel: PQM submission is less of an issue in the short term, I think, because there's always a Canonical reviewer that we can nag to land branches for us
[18:40] <gary_poster> kfogel: that would be a great eventual usage, and yes, that would be more important once it happened, and maybe having the group around would facilitate that change.  But that's not why I'm talking about this right now
[18:41] <kfogel> gary_poster: so this is for other, non-PQM-managed branches right now...
[18:41] <kfogel> gary_poster:  I'm getting kind of an edgy feeling about this.  Let me explain:
[18:41] <leonardr> gary: ok, hopefully the last one. in my launchpadlib branch built with my custom python, i can now import all of the modules mentioned in setup.py -- except, for some reason, lazr.uri. any ideas?
[18:42] <kfogel> We have a bunch of branches.  Some (previously mentioned) are managed by PQM.  Others are: lazr.*, launchpad-dependencies branches, and the Python sprint branches, and probably others to come.
[18:42] <gary_poster> maxb, kfogel: yeah, agree about name, though I don't care a heck of a lot TBH.  The name could be changed mechanically, I suspect.  Not sure what the ramifications would be, and how easy it would be to work around them.
[18:42] <gary_poster> leonardr: probably not a dependency?
[18:42] <kfogel> gary_poster: will it always be the case that if we want developer jrandom to have write access to one of those branches, we'd want him to have write access to all of them?
[18:42] <maxb> gary_poster: I was more thinking about mere finger-work typing "bzr foo lp:~launchpad-committers/...."
[18:42] <kfogel> gary_poster: i.e., is membership in the team a statement of "we trust this person's intentions and competence"?
[18:43] <leonardr> gary, aren't the dependencies what's listed in setup.py? i don't have a separate versions.cfg for this
[18:43] <kfogel> gary_poster: I'm not saying that's bad, just trying to make sure we agree what we're doing.
[18:43] <gary_poster> leonardr: yes
[18:43] <gary_poster> kfogel: your questions are harder :-)
[18:43] <leonardr> so yeah, lazr.uri is mentioned in setup.py as a dependency but is not importable
[18:44] <gary_poster> leonardr: ok give me a branch and I'll look at it
[18:44] <kfogel> gary_poster: I think now is the time to ask them, since we're apparently creating One Team To Rule Them All :-).
[18:44] <kfogel> gary_poster: but yeah, answer leonard first, it's no problem
[18:44] <leonardr> gary: it's a branch off of lp:launchpadlib. it's got to be some problem with my setup
[18:44] <gary_poster> kfogel: my inclination is JFDI.  Here's my argument.
[18:44] <leonardr> i can import the system lazr.uri (from the deb) using the system python
[18:47] <maxb> kfogel: Well, there's a bunch of branches currently owned by ~launchpad, for which some means of arranging for community write access would be nice :-)  These branches, afaik, are (1) meta-lp-deps, (2) sourcecode deps, (3) adhoc collaborative launchpad branches (e.g. python 2.5).  If there's a sensible granularity of access, maybe those should be split up.
[18:47] <gary_poster> kfogel: right now, we only accept someone as a contributor if they have shown competence in some way (do we have some kind of champion process or something?), *and* are willing to sign a contributors agreement.  In all cases, including Canonical employees, that's pretty much what we have.  If we need something fine grained, maybe we can add it later.  But I contend that social pressures, and the fact that someone can always 
[18:47] <gary_poster> a group, will likely be sufficient here, as they have been in other open-source cases (the zope.org repos come to mind: you get a blanket permission there; same with plone; probably same with other projects
[18:47] <gary_poster> may have been truncated.  tail:
[18:47] <gary_poster> But I contend that social pressures, and the fact that someone can always be removed from a group, will likely be sufficient here, as they have been in other open-source cases (the zope.org repos come to mind: you get a blanket permission there; same with plone; probably same with other projects
[18:48] <gary_poster> and, may I add:
[18:48] <gary_poster> )
[18:48] <gary_poster> and "." even
[18:48] <gary_poster> ok leonardr trying
[18:48] <kfogel> gary_poster: I completely agree with you so far.  Some of your text got elided.
 and, may I add:
 )
 and "." even
[18:49] <gary_poster> sorry, that was me trying to be funny :-/
[18:49] <kfogel> gary_poster: oh, heh
[18:49] <leonardr> gary: if i set an impossible version for lazr.uri in setup.py i do get an error
[18:49] <gary_poster> so, done
[18:49] <kfogel> gary_poster: so, +1 here, I'd just say make sure to spell this out when proposing to Francis that this new team have write access in whatever places we're initially proposing it will.
[18:50] <gary_poster> kfogel: ok, will do.  thank you
[18:50] <kfogel> gary_poster: thank _you_!
[18:50] <kfogel> high time
[18:50] <maxb> Does the tip of sourcecode branches get sucked into rollouts automatically? If so, I guess I see why they might need to not be opened to community committers.
[18:50] <kfogel> maxb: I don't know.
[18:51] <gary_poster> maxb: not for production.  for edge and such, yes
[18:51] <gary_poster> leonardr: what version of py did you use?
[18:52] <maxb> Another access question is the ~launchpad PPA. It's working quite well with me emailing sync requests, but I wouldn't say no to direct upload access if there was a way, and people were happy to give it to me
[18:52] <leonardr> gary: 2.6.4
[18:52] <gary_poster> leonardr: ok
[18:52] <gary_poster> maxb: eh...I'll add that to the email I guess, but I'm in favor of one step at a time :-)
[18:53] <leonardr> gary: i see references to .buildout/eggs/lazr.restfulclient (etc) in sys.path, but not lazr.uri
[18:53] <maxb> Sure... just trying to assemble all possible uses for a community write-access team
[18:53] <gary_poster> cool
[18:54] <gary_poster> leonardr: bah, I wonder if this is a setuptools c11 problem }:-(
[18:59] <leonardr> gary, what's a c11?
[18:59] <leonardr> at this point i'm tempted to remove apport packages and all other things that use launchpadlib to restore solution (1)
[18:59] <gary_poster> the newest version that phil eby released after much annoyance in the distutils list that is not worth recounting.
[19:00] <leonardr> ah
[19:00] <gary_poster> leonardr: sorry, as usual I'm trying to multitask--while waiting for one process to finish I look at another.  My build is in the middle of bin/buildout
[19:01] <leonardr> gary: np
[19:04] <leonardr> gary: fyi, rick spencer is not going to work on the gtk launchpad credential client until after uds
[19:05] <gary_poster> leonardr: urg. :-( ok
[19:05] <lfaraone> gary_poster: ping.
[19:05] <gary_poster> leonardr: I was able to import lazr.uri just fine.
[19:05] <gary_poster> lfaraone: hello
[19:07] <gary_poster> leonardr: uh.  are there any helpful error messages you can share?
[19:07] <lfaraone> gary_poster: What additional information would you need, re branded domains.
[19:08] <lfaraone> gary_poster: I talked to kfogel and kiko about it about a week ago in #launchpad.
[19:10] <leonardr> gary: unfortunately not. it just doesn't show up in sys.path
[19:10] <gary_poster> lfaraone: Hi.  The information I need is internal.  The point of the email I sent was largely to let you know that we were not ignoring you.
[19:10] <leonardr> i'll look through the output of buildout
[19:10] <lfaraone> gary_poster: ah, okay. (I was wondering... :)
[19:10] <gary_poster> :-)
[19:11] <lfaraone> gary_poster: let us know if you need anything.
[19:11] <gary_poster> lfaraone: will do, thank you, and sorry for not being clear :-)
[19:12] <lfaraone> gary_poster: on an entirely unrelated note, our codehosting system is git via gitorious. if some of us were to submit the patches, could we enable launchpad to work with gitorious as it does with the native bzr codehosting?
[19:13] <leonardr> gary: i get an "Unbuilt egg for ClientCookie [unknown version]" warning, but that's probably not relevant
[19:16] <lfaraone> (like linking branches, etc)
[19:18] <gary_poster> lfaraone: that's entirely out of my area, sorry.  I know we are interested in improving our git support, but the approach is something that the strategy team is working out with the bzr team and codehosting team.  I'm just a foundations guy, helping out because your initial question touched on my area. :-)  I will be happy to raise the question on launchpad-dev on your behalf if you'd like (though you can do the same).
[19:19] <lfaraone> gary_poster: well, on the other hand, I don't want to ask for too many things, at the risk of becoming a nusiance.
[19:19] <gary_poster> leonardr: hm...are you sure you used the home-installed Python?  That ClientCookie thing is something that typically comes from a messed up site-packages
[19:20] <gary_poster> lfaraone: I dunno, if you don't ask, you don't get.  :-)  you can at least maybe get an idea of the plans, and see if they match your goals
[19:22] <lfaraone> gary_poster: understood.
[19:24] <leonardr> gary: do i need to use home-installed python for everything, or just bootstrap? i've been using it for bootstrap
[19:24] <leonardr> yeah, bootstrap writes the right #! lines, so it shuold be fine
[19:25] <leonardr> gary: however, you're right that it is looking in /usr/lib/python2.6/dist-packages for the ClientCookie
[19:25] <gary_poster> leonardr: just bootstrap, and then bin/buildout without a Python invocation
[19:25] <leonardr> yeah, that's what i did
[19:26] <gary_poster> leonardr: grr.  never seen that.  something is wrong in set up, and no idea what it is.  leonardr, what happens if you start up that self-installed version of Python and look at sys.path?
[19:26] <gary_poster> does it include site-packages?
[19:31] <leonardr> gary:
[19:31] <leonardr> >>> [x for x in sys.path if 'site' in x]
[19:31] <leonardr> ['/home/leonardr/bin/python/lib/python2.6/site-packages']
[19:31] <leonardr> so, yes
[19:32] <gary_poster> leonardr: yeah, sorry wasn't clear
[19:32] <gary_poster> that's your local site-packages
[19:32] <gary_poster> which is presumably empty
[19:32] <leonardr> ok. is there a site packages in my personal install?
[19:32] <leonardr> did i configure incorrectly maybe?
[19:34] <gary_poster> leonardr: is this using a launchpadlib that had previously used a system python?
[19:34] <gary_poster> IOW, you are reusing a checkout
[19:34] <gary_poster> ?
[19:35] <gary_poster> trying to duplicate that way
[19:36] <gary_poster> heh that didn't get very far
[19:36] <gary_poster> but leonardr, if you think that's possible, try a fresh checkout.
[19:37] <gary_poster> leonardr: if I am right that this is the bug, then you probably could just remove bin and .installed.cfg and rerun bin/buildout.
[19:37] <leonardr> that's a promising line of inquiry
[19:38] <gary_poster> but I'd try the fresh checkout to be sure
[19:38] <leonardr> yeah, trying that
[19:52] <gary_poster> leonardr: that means that you have zope.proxy build with the system python
[19:52] <gary_poster> you have to delete the egg and rerun buildout
[19:52] <leonardr> ok, should i maybe delete all my cached eggs?
[19:53] <gary_poster> leonardr: sure.  The ones with C extensions are the only ones affected, but that certainly covers the bases.
[19:53] <leonardr> gary: oops mystery solved: https://bugs.edge.launchpad.net/lazr.restful/+bug/474522
[19:53] <mup> Bug #474522: TypeError when lazr.restful tries to unmarshall URI <api> <oops> <Launchpad Foundations:Triaged by leonardr> <lazr.restful:New> <https://launchpad.net/bugs/474522>
[19:59] <leonardr> gary: i hope this is not a portent of things to come: after deleting the eggs, bin/buildout is now reaching for the deb version of wadllib
[20:00] <gary_poster> leonardr: OOPS error: good catch.  deb version: that's insane.  this is in the clean checkout version, you are sure?
[20:01] <leonardr> gary: yeah. i specified version 1.1.4 of wadllib and then it downloaded the egg
[20:01] <gary_poster> leonardr: it downloaded the egg, and then somehow started using site-packages version?
[20:02] <leonardr> gary: no, here's what happened
[20:02] <leonardr> originally i ran with an unmodified setup.py
[20:02] <leonardr> it complained: "lazr.restfulclient wants 1.1.4 of wadllib, and i have 1.1.2"
[20:03] <leonardr> 1.1.2 being the deb packaged version
[20:03] <leonardr> i changed setup.py to require 1.1.4 explicitly, and it downloaded 1.1.4
[20:03] <leonardr> gary: and now, once again, i can't import lazr.uri from my shell
[20:04] <leonardr> /usr/lib/python2.6/dist-packages is in my sys.path
[20:05] <leonardr> as before, there are many ~/.buildout/eggs/lazr.* references in sys.path but lazr.uri is not among them
[20:05] <gary_poster> I'm really very suspicious that you are using a system Python sometime.  Maybe check your history?  I know the pertinent code, and that's the only way I can think of this happening.
[20:05] <leonardr> yeah, i'm inclined to agree
[20:05] <leonardr> it's possible that i ruined this branch by slipping up and using a system python after the initial setup
[20:05] <leonardr> in that case i should probably alias 'python' to my python
[20:06] <gary_poster> for excitement, try rm-ing the bin directory and .installed.cfg
[20:06] <gary_poster> and then rerun bootstrap and bin/buildout
[20:06] <gary_poster> and see if that makes things better
[20:06] <gary_poster> without having to do a fresh checkout
[20:07] <leonardr> ok
[20:13] <leonardr> gary: no effect. and i checked .installed.cfg before deleting it and 'executable' was correct
[20:14] <leonardr> but, now i have a checkout that works and one that doesn't
[20:14] <leonardr> i'll diff them and see what's different
[20:14] <gary_poster> leonardr: ok
[20:14] <gary_poster> probably messy :-/
[20:16] <leonardr> gary: the only difference is that my non-working checkout seems to have a garbled setuptools name:
[20:16] <leonardr> __buildout_signature__ = z3c.recipe.tag-0.3.0-py2.6.egg zc.recipe.egg-1.2.2-py2.6.egg zc.buildout-1.4.2-py2.6.egg setuptools-h8seYOqeLdvVn0YIl04xMQ== zc.buildout-1.4.2-py2.6.egg
[20:16] <leonardr> and the non-working version doesn't define installed_develop_eggs
[20:17] <gary_poster> weird
[20:18] <leonardr> gary: do you need to use your system python when testing launchpad too?
[20:19] <gary_poster> leonardr: we go to great lengths, for better or worse, to use the system python when testing/developing launchpad
[20:19] <leonardr> ok, i'm about to find out if it works
[20:38] <kfogel> lfaraone: ping
[20:50] <kfogel> Is database/schema/launchpad-2207-00-0.sql the "most recent master schema" for Launchpad?
[20:50]  * gary_poster doesn't know :-/
[20:50] <kfogel> (Background: I'm trying to get stats on number/percentage of failing code imports for CVS, same for SVN, same for git.)
[20:50] <kfogel> gary_poster: s'okay.
[20:51] <kfogel> flacoste: ^^
[20:51] <kfogel> flacoste: (my db question above)
[20:57] <kfogel> wgrant: ping
[21:08] <flacoste> kfogel: whatever is in the tree is the most recent
[21:09] <kfogel> flacoste: I'm asking a more basic question -- I don't know which filename I want.
[21:09] <flacoste> kfogel: what do you want?
[21:09] <kfogel> flacoste: I'm looking for a master description of our schema.  Though it's not incredibly urgent, as I am using psql cmds to find it out anyway.
[21:10] <kfogel> flacoste: overall background (my goal) is in this mail from jml: https://lists.canonical.com/mailman/private/canonical-bazaar/2009-October/004732.html
[21:11] <flacoste> kfogel: there is no master schema file, you get the schema in use by starting with that file and then applying all the patches
[21:12] <kfogel> flacoste: ah, okay.  thanks.
[21:12] <dobey> leonardr: ola :)
[21:12] <flacoste> kfogel: i always use psql when building that sort of query, or you can use another GUI tool (no particular recommendation here)
[21:12] <kfogel> flacoste: psql is exactly what I'm doing, yeah.
[21:13] <leonardr> dobey: ok
[21:13] <dobey> leonardr: so i take it i should pull some bzr branch to look at some code?
[21:13] <leonardr> to start with, check out lp:launchpadlib
[21:14] <leonardr> i've created a class that encapsulates the process of asking the end-user for their username, password, and desired access level, then sending that information to launchpad to authorize a request token
[21:14] <leonardr> independant of any particular user interface
[21:14] <dobey> ok
[21:14] <leonardr> and i've written two user interfaces: a scriptable one that i use for testing, and a console-based one that reads data from sys.stdin
[21:15] <dobey> so it's pretty much designed around how the oauth stuff in launchpad currently works?
[21:15] <leonardr> yes, it's very dependant on the specifics of launchpad, and i filed a number of bugs to make launchpad's behavior more predictable
[21:15] <leonardr> basically we are pretending to be the user's web browser and the user's brain looking at the launchpad web page
[21:16] <dobey> right
[21:17] <leonardr> the most important code is in src/launchpadlib/credentials.py, the RequestTokenAuthorizationEngine class
[21:17] <leonardr> the code that tests it is in trusted-client.txt
[21:17] <leonardr> and the test for the full workflow (where you pass in a RTAE for a specific UI type into Launchpad.login_with()) is in introduction.txt
[21:17] <leonardr> here's how the RTAE works
[21:18] <leonardr> there are a number of hook methods called at various points in the process
[21:18] <leonardr> startup(), input_username(), user_refused_to_authorize(), etc
[21:18] <leonardr> at each step the UI is supposed to display something to the user and/or accept input
[21:18] <leonardr> most of these methods take a 'suggested message' as an argument
[21:19] <leonardr> oh, i actually wrote three of these classes--i took the existing behavior that opens the user's web browser and asks them to hit enter, and implemented it as an RTAE
[21:19] <dobey> right. hrmm
[21:20] <dobey> i think for ubuntu one we're wanting to registering/subscribing as well, without opening a browser
[21:20] <leonardr> aaaargh
[21:21] <dobey> could this be extended to handle that, or does it sort of handle that all in the background and just open the browser, and we'd need to write something else new to deal with the subscribe/register part?
[21:22] <leonardr> well, what i have now doesn't open the browser (unless you choose the "browser" ui)
[21:22] <dobey> oh
[21:23] <leonardr> but the workflow only knows about one launchpad page: +authorize-token
[21:23] <dobey> i was reading the YOU_NEED_A_LAUNCHPAD_ACCOUNT string
[21:23] <dobey> and it says "i'm opening the browser"
[21:23] <leonardr> that's a failure condition - "come back later"
[21:23] <leonardr> ah
[21:23] <leonardr> yes, if you use the command-line client it will open your browser to the login page as a courtesy
[21:23] <dobey> is that a bug then? :)
[21:23] <leonardr> but it's still a failure condition, you can't continue
[21:24] <leonardr> i'd say it's a minor bug that the generic error string mentions command-line-specific behavior
[21:24] <dobey> ok, so it doesn't actually open the browser?
[21:25] <leonardr> RTAE never opens the browser or does anything on the client side
[21:25] <leonardr> it calls hook methods and it makes http requests to launchpad and screen-scrapes the html
[21:25] <leonardr> there's a "browser ui" hook method that will always open the browser and make the user log into launchpad through the browser
[21:25] <dobey> ok
[21:25] <leonardr> s/hook method/subclass/
[21:26] <dobey> there's no way to register from the class though?
[21:26] <leonardr> there's a "command-line" subclass that will ask for the username and password if the user has a launchpad account, and if they don't have one, tells them to get a launchpad account and opens their browser
[21:26] <leonardr> no
[21:26] <leonardr> that would mean more screen-scraping
[21:26] <dobey> ok
[21:26] <dobey> yeah i don't really like screen-scraping
[21:27] <wgrant> kfogel: Hi.
[21:27] <dobey> i was actually thinking of writing an "OAuth Desktop" extension spec, to respond with JSON for the client to build some UI, and do stuff
[21:27] <leonardr> if you're serious about this we should probably create a second web service that lets you register a user account, request a request token, authorize the request token
[21:27] <wgrant> bigjools: Sorry, no 2am during exams :(
[21:27] <kfogel> wgrant: Can I mine you for some information (if you're familiar with our DB schema -- if not, then don't worry about it)?
[21:27] <dobey> and perhaps a similar thing on top of openid (though i know less about how openid works than oauth)
[21:28] <wgrant> kfogel: Sure.
[21:28] <leonardr> your oauth desktop extension spec sounds like my second web service
[21:29] <dobey> heh
[21:29] <dobey> well if i did the oauth extension spec, i could implement it in my python oauth lib, and would be trivial for anyone to use in python
[21:30] <dobey> and it wouldn't really take a lot of time to do i don't think
[21:30] <leonardr> you'd have to get the launchpad team to sign off on it and implement it
[21:30] <dobey> right
[21:30] <dobey> would you be the one doing that work? :)
[21:31] <kfogel> wgrant: thanks.  Let me give you quick background first, then tell you where I am.  I'm trying to graph stats on failing code imports in Launchpad, by type of import (e.g., CVS, SVN, SVN via bzr-svn, and GIT).  I've got access to poke around in a read-only fashion using psql, and I've just now found lib/lp/code/enums.py and the RevisionControlSystems enum therein.  I see also that we have these four tables:
[21:31] <kfogel> er, six:
[21:31] <kfogel>  codeimport codeimportevent codeimporteventdata codeimportjob codeimportmachine codeimportresult
[21:31] <kfogel> wgrant: so I'm trying to figure out the connections between the tables, naturally.
[21:32] <leonardr> dobey: probably not, i'm booked on other stuff
[21:32] <kfogel> wgrant: is any of this sounding familiar to you, or are you also a beginning in this area?
[21:32] <kfogel> s/beginning/beginner/
[21:32] <leonardr> dobey: i wouldn't expect a whole lot of outside enthusiasm for your spec, because what we're doing is a security problem
[21:33] <dobey> leonardr: who should i discuss that with?
[21:33] <leonardr> the only secure client for your launchpad password is your web browser
[21:33] <leonardr> i'm talking about the general oauth-using public
[21:33] <dobey> leonardr: afaict, oauth is a security problem
[21:33] <leonardr> the only reason i'm doing this is that it's even worse to have everyone writing their own authentication client
[21:33] <leonardr> dobey, elaborate?
[21:33] <dobey> leonardr: if it were up to me, it would just be username/password and be done with it
[21:34] <dobey> well oauth was designed for the web, not the desktop
[21:34] <dobey> the "general oauth-using community" is "the web"
[21:35] <kfogel> wgrant: ah, ignore enum 3, svn via bzr-svn.  psql says there are none of those -- it must be a placeholder for something we haven't turned on yet.
[21:35] <dobey> typing one's password in a browser isn't really any more secure than typing it in a gtk+ dialog
[21:35] <wgrant> kfogel: SELECT COUNT(*) FROM codeimport WHERE review_status=40; should get the count that are regularly failing.
[21:35] <wgrant> Now, the various types...
[21:36] <leonardr> dobey: it sounds like you've got the desktop pov that if you installed it on your computer, you trust it
[21:36] <dobey> leonardr: no. my pov is that i don't trust anything
[21:36] <kfogel> wgrant: *nod*  trying it now.  Though when I did 'select distinct status from codeimportresult;', I got these three codes: 200, 300, 310
[21:36] <dobey> leonardr: if i haven't installed it on my computer, i certainly shouldn't be trusting it *more*
[21:36] <wgrant> kfogel: codeimport, not codeimportresult.
[21:37] <leonardr> dobey: not sure what's the hypothetical thing not installed on your computer
[21:37] <wgrant> kfogel: 40 is FAILING, and is set on the codeimport when it has failed repeatedly some number of times.
[21:37] <dobey> leonardr: "the web"
[21:37] <kfogel> wgrant: thanks.  (I know you said codeimport -- I was just pointing out there's this *other* table named codeimport result whose numbers apparently mean something entirely different).
[21:38] <dobey> leonardr: i'm not sure what makes people think the browser is a more trusted place to type a password, than a dialog box
[21:38] <leonardr> dobey: because you already type your launchpad password into a browser all the time
[21:38] <kfogel> wgrant: so, I'd expect the count to return something other than zero (from codeimport where review_status=40), yet it returns 0.
[21:38] <wgrant> kfogel: Hmmmm. That's unfortunate.
[21:38]  * wgrant pokes further.
[21:38] <dobey> leonardr: yes, and people type their paypal passwords in a browser all the time. yet they still get taken by phishing mails
[21:39] <dobey> they open their browser to a web page that looks like paypal, type their password, and then their account is empty
[21:39] <kfogel> wgrant: but yes, I see in enums.py the same thing you see, about review_status.  40 looks like the thing we want.
[21:39] <leonardr> dobey: the solution is not to increase the number of places where we can tell people it's ok to type their password
[21:39] <dobey> leonardr: i'm not saying it is. in fact, i want a single place for it on the desktop
[21:39] <dobey> leonardr: but that single place, is certainly not a web vm
[21:40] <kfogel> wgrant: I am continuing to poke too.
[21:40] <leonardr> people already type their launchpad passwords into a desktop application called 'mozilla'
[21:40] <leonardr> there's no web vm
[21:40] <dobey> mozilla is a web vm
[21:41] <dobey> as is opera, or epiphany, or midori
[21:41] <leonardr> and any other application you create will have the same essential properties
[21:41] <dobey> no
[21:41] <leonardr> plus, it will not look like the place people are used to already typing in their launchpad passwords
[21:42] <kfogel> wgrant: asking internally about that zero row count too.
[21:42] <dobey> leonardr: which is already the case with this new class, no?
[21:42] <wgrant> kfogel: The sample data isn't much good for code imports :(
[21:43] <leonardr> dobey: yes. that's why i don't like this new class and only did it because the alternative is even worse
[21:43] <kfogel> wgrant: ooooooh, good point, I forgot it's not real data.
[21:43] <kfogel> wgrant: thanks.
[21:43] <leonardr> this way, any non-browser ui mechanism you want to use will use the same underlying code
[21:44] <wgrant> kfogel: Oh. I presumed you were getting that zero row count from production. This makes more sense now.
[21:44] <leonardr> all the mechanisms will be in the same package and can be audited together
[21:44] <kfogel> wgrant: it does make sense, but it sure isn't going to make it easy for me to test what I want to test either :-).
[21:44] <dobey> what i really want is a central framework for accessing/using web services/APIs
[21:44] <dobey> but i haven't written it yet
[21:44] <kfogel> wgrant: let me see, maybe I can get access to prod db or a copy thereof.
[21:45] <wgrant> kfogel: Has stub produced his sanitised DB yet?
[21:45] <wgrant> That would be convenient for this.
[21:45] <kfogel> wgrant: that's exactly what I'm going to check on.
[21:45] <dobey> although it's high on the list of needing to get written
[21:45] <kfogel> wgrant: he doesn't come online for a while, I will ping him tonight (his morning)
[21:45] <leonardr> dobey, what other web services are you using?
[21:46] <leonardr> gary, maybe you want to review my trivial branch https://code.edge.launchpad.net/~leonardr/launchpadlib/restfulclient-0.9.10/+merge/14666 ?
[21:46] <gary_poster> leonardr: sure looking
[21:47] <dobey> leonardr: facebook, various bugzillas, ubuntu one, launchpad, twitter, identi.ca, the palm pre thing, google mail/calendar/docs/etc...
[21:47] <dobey> leonardr: practically everything i do on the comptuer every day is 'use some network service of some sort'
[21:47] <leonardr> right
[21:47] <dobey> but there are a million different ways to access them all
[21:48] <dobey> and it's overly painful, and firefox eats up all my resources
[21:48] <dobey> and it doesn't integrate with my workflow/system
[21:48] <gary_poster> leonardr: approved
[21:48] <leonardr> there are different ways to access them because there's no consistent design
[21:48] <leonardr> although: i don't know how deep you've looked into it, but all the google web services are basically the same
[21:49] <rockstar> abentley, have you seen that the bmp comments javascript is erroring?
[21:49] <dobey> well, they all extend the same basic API for the most part
[21:49] <rockstar> abentley, Y.all("a.menu-link-reply") is null
[21:49] <dobey> but accessing my mail on google, and messages people send me on facebook, are not the same
[21:49] <dobey> (though they should be)
[21:49] <leonardr> dobey: agreed. they are not the same because they were designed by different people
[21:50] <dobey> leonardr: yes, but they both provide APIs
[21:50] <dobey> leonardr: so you don't *HAVE* to use their UI
[21:50] <dobey> it's just that there are no good alternative UIs
[21:50] <dobey> and having to type the same password in 20 different places to access different parts of the service from different apps is also really lame
[21:51] <dobey> so to start off i want to centralize authentication to web services in the desktop
[21:51] <rockstar> thumper, around?
[21:53] <dobey> there are definitely still some interesting remaining issues with doing so, but i think their solutions will become apparent as the project grows and code gets written
[21:56] <dobey> leonardr: i need to call it a day now, and go do other stuff, but we can continue the discussion later/tomorrow.
[21:57] <dobey> leonardr: thanks for discussing it :)
[21:57] <leonardr> sure, np
[21:57] <dobey> later :)
[22:04] <kfogel> wgrant: I'm just going to proceed using the staging data and pretending that review_status=30 ("suspended") is what we want (even though in real life 40 is what I'll use).
[22:05] <leonardr> dobey: probably not relevant to you, but one point about how the google services "all extend the same basic API"
[22:05] <leonardr> that's by design. it didn't have to be that way. amazon put out a bunch of web services that were totally different. google decided to publish things that are superficially different (calendars and spreadsheets) in the same way
[22:07] <wgrant> kfogel: By 'staging data' you mean sample data? Or do you actually have access to staging?
[22:08] <kfogel> wgrant: I'm querying against the db staging is using.  it has some code import records in state 30, enough to work with.
[22:08] <kfogel> wgrant: I think I'm okay now, btw -- I mean, from here the query is obvious.
[22:08] <wgrant> kfogel: But that should have some in 40 as well.
[22:08] <kfogel> wgrant: the trick was learning to ignoer the codeimportresult table :-).
[22:08] <kfogel> wgrant: it doesn't have any 40 at all.
[22:28] <maxb> Does anyone fancy reviewing this for me? https://code.edge.launchpad.net/~maxb/pygettextpo/makefile-fix-version/+merge/14256
[22:33] <lfaraone> kfogel: pong
[23:45] <rockstar> thumper, hi
[23:47] <rockstar> maxb, r=me
[23:56] <maxb> rockstar: Thanks. How do I get it landed?
[23:57] <rockstar> maxb, dunno.  I may have to harass barry, but luckily, he's sitting on the other end of the table from me.
[23:58] <maxb> heh
[23:59] <maxb> gary_poster: did you get around to thinking about that meta-lp-deps wiki doc? I was thinking about writing some, but my biggest blocker is where to put it in the wiki! :-)