[08:28] good morning [08:28] Morning adeuring. [08:28] hi wgrant! [08:29] * wgrant prepares a few post-exam branches. [08:33] Right. Big pot of Java, time to resolve some conflicts. [08:34] gmb: Is that the branch from... before the open-sourcing? [08:35] wgrant: You know, I can't remember when I started this fricking thing. Possibly. Async dupefinder. [08:35] It's one of those "everyone thought it was less important than I did" branches. [08:35] gmb: Yeah, that's the one that has been on +activereviews since the start. [08:35] Hahaha. [08:36] But if you fix it, Ubuntu will drown in bugs even more :( [08:36] 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] wgrant: Nah, we'll just disable it for Ubuntu so that the interface keeps timing out all the time. [08:37] Fuck, the branch doesn't even *build*. [08:37] Man alive. [08:37] gmb: Awesome. [08:38] Right, I'm gonna delete me some branches. [08:38] adeuring: Can you please ec2test & land those two branches of mine? [08:39] wgrant: thanks for the reminder! will do it right now [08:39] adeuring: Thanks. [08:47] 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] 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] sure [09:10] Can we take TAL out and shoot it, please? [09:10] It's harshing my mellow. [09:11] twisting your melons [09:11] wgrant: if only all reviews were as easy [09:11] bigjools: This melon is for display purpose only. [09:12] gmb: slightly scratched? [09:12] 'Chafed' is the word. [09:13] Morning troops. [09:13] eyup mrevell === mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 1 of 3.1.11 | PQM is open - release manager is noodles775 (flacoste, BjornT) | I am Zero OOPS and So Can You! http://is.gd/4fkLl | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ [09:13] wgrant: I'll land that for you [09:15] bigjools: Thanks. [09:19] gmb: How many branches did you get through before son-of-bride-of- or whatever it is? [09:19] 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] wgrant: did you see https://bugs.edge.launchpad.net/soyuz/+bug/478691 ... jeez [09:42] Bug #478691: empty ppa builders should allow more builds from a single ppa [09:45] bigjools: I did say that would happen. [09:45] bigjools: The current algorithm sucks. It just sucks less than the old one for non-daily PPAs. [09:45] I do not know how to make it better :( [09:45] me neither [09:46] other than adding more builders [09:46] 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] We need to start discriminating against either daily PPAs or long builds. I cannot see a way around it. [09:50] we could auto-lower the priority for anything with a high build ETA [09:51] That doesn't help much. [09:51] 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] who said anything about removing the current fix? [09:51] it seems we have 2 situations [09:52] The current fix is annoying. [09:52] either the long-build PPA owners complain, or everyone else complains [09:52] either way there's a lot of complaining [09:52] the current fix annoys the fewest people [09:53] I will also complain when I upload a few several-minute builds and it takes a couple of hours to build. [09:53] While 45 builders sit idle. [09:54] Wow, bugspam from adeuring1! [09:55] gmb: yeah, time tp update some bug statuses ;) [09:55] adeuring1: Oh, sod, you're right. I'd forgotten. [09:55] wgrant: have you seen that happen? === adeuring1 is now known as adeuring [09:55] bigjools: I haven't watched that closely, but I'm 99% sure it has. [09:56] * gmb does the same thing [09:56] bigjools: Why wouldn't it have? It's a very common case. [09:56] Upload a few new versions to each series. [09:57] 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] 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] bigjools: But then that will cause daily builds to monopolise again. [09:58] 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] wgrant: the daily builds need more than one builder to complete within 24 hours it seems [09:58] bigjools: They do. [09:59] rock -> me <- hard place [09:59] bigjools: The current restriction is too restrictive for even daily builds. [09:59] But there needs to be *some* restriction. [09:59] Just a slightly smarter one. [09:59] so bump to 2 builders from 1? [09:59] ETOOSTATIC [10:00] or allow all builders as before unless we know it's a long build [10:00] Not all, I don't think. [10:00] But some large fraction. [10:00] And a much smaller fraction if they are going to be long. [10:00] But that still has a problem if there are lots of daily PPAs. [10:00] hmmm [10:01] we need more builders [10:01] So some fraction needs to be reserved for un-long builds. [10:01] al-maisan_'s quit message is very relevant. [10:01] so is my away message :/ [10:01] * wgrant doesn't know that one. [10:02] Ah. [10:02] I see. [10:02] /away [10:02] fail [10:03] Describes this situation rather well. [10:04] Somebody needs to think and draw up lots of cases. [10:09] 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] wgrant: you may have free access to it since you're still a university student [10:10] 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] Doesn't look like I have access to that, sadly. [10:59] bigjools: Bug #476036 probably wants to be worked on with some priority. [10:59] Bug #476036: sbuild needs to run dpkg-source inside the chroot [10:59] wgrant: yeah [10:59] I'll poke lamont === matsubara-afk is now known as matsubara [11:16] wgrant: http://pastebin.ubuntu.com/313996/ [11:16] brb, need caffeine [11:17] bigjools: That looks like it should only fix the opposite situation :( [11:17] Although.. hm. [11:23] I've not looked at it in detail - it was to fix the upload problem === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:27] 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] i can import psycopg2 from a normal python shell but not from the bin/py shell [13:34] leonardr, the upgrade kills the launchpad-developer-dependencies package, and the LP ppas - did you re-enable them? [13:35] mars: thanks, argh [13:35] that's my least favorite feature of ubuntu--it gets me every time [13:37] 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] it got me too, that one [13:38] hehe [14:02] mars: i'm not getting "ImportError: libgettextpo.so.0: cannot open shared object file: No such file or directory" [14:02] s/not/now/ [14:03] looks like i might be missing a zope package... [14:03] but perhaps that package ought to be put in sourcecode/ [14:04] leonardr: I think that is pygttext in sourcecode. [14:04] hmm [14:04] ok, i guess the problem is that it's looking for .so.0 and only .so is in that directory? [14:05] leonardr: I think that is sourcecode/pygettextpo [14:06] We don't hack on pygettextpo or old_xmlplus (dtdparser) I wonder what needs to happen to make them eggs [14:06] adding a symlink doesn't help [14:06] i wonder who's looking for .so.0? [14:07] gary, maybe you have a clue [14:07] i'm trying to get launchpad working again after karmic upgrade [14:08] ok [14:08] when i run 'import gettext' from bin/py or try to run the tests, i get this error: [14:08] ImportError: libgettextpo.so.0: cannot open shared object file: No such file or directory [14:08] sinzui said it might be looking in sourcecode/pygettextpo [14:09] leonardr: I did, but I see 'import gettext' as something else :( [14:09] sinzui: i gave the symlink the wrong name. giving it the right name makes it work. [14:10] 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] leonardr: gettext somes with python [14:12] stub, yeah, there was a mailing list thread about that IIRC. "make clean doesn't follow the GNU Makefile conventions" [14:12] leonardr: I don't know. What happens when you try ``$ locate libgettextpo.so`` [14:12] ? [14:14] 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] Do you mean like realclean should be doing? [14:15] I think so. In GNU terms, distclean == realclean [14:15] we just grab a new copy of the branch, but the tradition is to run 'make distclean' before 'make dist' === leonardr is now known as leonardr-afk [14:30] * maxb finds "bzr clean-tree --unknown --ignored --detritus --force" to be rather useful [14:31] 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] maxb: awesome! (and I regard the broken CIP as a burning issue for this week, so hopefully that will be squashed) [14:33] broken CIP-needing-test I should say [14:51] Hell, tracking down these 'o is null' errors in YUI is a pain. [14:51] wgrant: still up? [15:13] 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] 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] maxb: hm, ok, so #launchpad-foundations you mean? [15:15] yes [15:15] alright [15:15] hey danilos [15:15] Ursinha, hey hey [15:16] I see one of those TraversalErrors on Saturday, in translations, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1407F2349 [15:16] danilos, is this supposed to happen? [15:16] Ursinha, well, yes :) [15:17] 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] Bug #462891: user.preferredemail shouldn't be None

[15:18] 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] Ursinha, we've just worked around the most common one [15:18] danilos, I understand [15:18] Ursinha, my other branch attached to the bug fixes it in the property, but I don't know how to test it === matsubara is now known as matsubara-lunch [15:32] danilos: ping [15:32] sinzui, hi [15:33] 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] danilos: Is there something else that must happen to satisfy translations? [15:35] sinzui, it'd be nice for those links to automatically propagate over series, or even better, to be shared among them [15:36] 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] 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] sinzui, and it'd be PITA to ask people to manually enter them with every ubuntu release [15:36] sinzui, right, I'll let you worry about solving that problem then [15:37] 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] danilos: So you thinking is that while the linked series is carried forward, the packaging link is not created [15:38] sinzui, yeah [15:39] 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] 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] sinzui, right, that's about it then [15:40] danilos: I have seen that bug about just product. [15:41] 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] I'll collection my notes this week and send the to you and the others to comment on. [15:42] sinzui, excellent, sounds good! thanks for looking into it === leonardr-afk is now known as leonardr [16:26] gary, stub: reopening the pygettextpo drama... [16:26] i followed stub's suggestion and removed the build directories, then did make clean and make [16:26] now there's no longer any gettextpo.so in sourcecode/pygettextpo, and i don't know how to build one [16:27] leonardr: looking [16:27] leonardr: rocketfuel-get might do the right thing [16:27] but looking [16:28] I don't have a .so there either [16:28] oh yes I do [16:30] leonardr: I'm trying to dupe [16:31] gary: ok, rocketfuel-getting [16:31] leonardr: skeptical of myself. feel free, but probably won't help is my new new new opinion [16:31] i agree [16:40] 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] leonardr: maybe do ``make clean`` and then ``make SHHH=`` and pastebin the output for me? [17:06] 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] 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] https://pastebin.canonical.com/24523/ [17:06] 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] gary_poster: (on phone, or about to be, but will look as soon as off. it's just a standup call) [17:07] maxb: :-) [17:08] * gary_poster helps leonardr_ and maxb : http://paste.ubuntu.com/314235/ :-) [17:09] leonardr_: Can you try running 'make PYTHON=python2.4 PYTHON_VERSION=2.4' in sourcecode/pygettextpo/ ? [17:10] sure [17:10] leonardr_: And also, do you somehow not have python2.4-dev installed? Nor launchpad-developer-dependencies ? [17:10] argh, it looks like 2.4-dev was removed in the karmic upgrade [17:10] Well, yeah, that'll break things :-) [17:10] heh [17:10] thanks maxb [17:11] leonardr_: check launchpad-dependencues too [17:11] that should have required python2.4-dev [17:12] IIRC [17:12] I think lp-dev-deps depends on the other two [17:12] maxb: ah ok [17:12] 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] That is, do you think I should include python2.5 versions of all of the python2.4 things? [17:13] I'll go to flacoste if you are not sure. He is the keeper of this key. [17:14] Theoretically, if we want a working python 2.4 and python 2.5 launchpad environment, we should include them, [17:15] That's what I figured [17:15] Practically, however, I don't think any packages that support python2.4 but don't support python2.5 will exist [17:15] So really it's only a matter of theoretical correctness, not actual breakage [17:16] Oh, and on the subject of policy w.r.t the bzr branches - policy? what policy? :-) [17:16] Basically "bzr push what you dput" [17:16] 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] Agreed. [17:17] Cool. [17:17] policy: heh, fair enough. Perhaps I was thinking more of instructions [17:17] That is, do I check out the branch, and then that's the same as if I had gotten a source deb? [17:17] 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] heh [17:18] gary_poster: That's the intent. [17:18] 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] 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] ah, yes, that sounds like something I would never have thought of [17:19] ok running away for a bit [17:35] rockstar, hi [17:36] rockstar, I'm chr this week and checking all the pending vcr-imports [17:36] rockstar, I see one that the repo url is valid, but it has no files in it, yet, maybe [17:36] rockstar, should I approve it or is it going to bork somehow? [17:55] gary: i'm having another, even stranger problem [17:56] 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] do you know what could cause that to happen? [17:56] i'm going to remove my old lazr.restfulclient eggs but it's annoying [17:56] leonardr_: so, this is not in launchpad, but in a branch. Yes, I know what would cause that. [17:56] 1 sec [17:57] np [17:59] this is rich, i don't even have a 0.9.3 egg [17:59] 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] ah, the deb is to blame [18:01] i see. now that apport uses launchpadlib, my previous strategy (1) is no longer tenable [18:01] gary, can you run me through (3)? [18:04] 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] (there are many variants; that's just what I do) [18:04] all right [18:09] 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] gary: --prefix is a configure argument, right? i'm getting through configure and make but python setup.py is failing me [18:17] leonardr_: yes, configure. don't use python's setup.py. do ``./configure --prefix=...`` then ``make`` then ``make install`` [18:18] aha, make install, thanks [18:21] ok, that's working, but i need to install some dev packages like lib-devreadline to make this environment nicer [18:31] 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 === leonardr_ is now known as leonardr [18:33] leonardr: that's what I was going to recommend, yes [18:33] I have it installed [18:34] gary_poster: back [18:34] kfogel: cool [18:34] gary_poster: sorry, remind me of context. the ~launchpad-committers team will be for [?] [18:36] 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] there was some discussion of other uses [18:37] 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] 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] gary_poster: or is this about write access? [18:38] This is about community write access [18:38] kfogel: write access, for branches not managed by pqm [18:38] 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] kfogel: not necessarily because of PQM [18:38] but in some cases [18:38] 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] kfogel: that is the case but we do not have all branches managed by PQM [18:39] kfogel: cases include lazr.*, launchpad-dependencies branches, and the Python 2.5 sprint work [18:39] 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] 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] maxb: yeah [18:40] 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] 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] gary_poster: so this is for other, non-PQM-managed branches right now... [18:41] gary_poster: I'm getting kind of an edgy feeling about this. Let me explain: [18:41] 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] 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] 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] leonardr: probably not a dependency? [18:42] 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] gary_poster: I was more thinking about mere finger-work typing "bzr foo lp:~launchpad-committers/...." [18:42] gary_poster: i.e., is membership in the team a statement of "we trust this person's intentions and competence"? [18:43] gary, aren't the dependencies what's listed in setup.py? i don't have a separate versions.cfg for this [18:43] gary_poster: I'm not saying that's bad, just trying to make sure we agree what we're doing. [18:43] leonardr: yes [18:43] kfogel: your questions are harder :-) [18:43] so yeah, lazr.uri is mentioned in setup.py as a dependency but is not importable [18:44] leonardr: ok give me a branch and I'll look at it [18:44] gary_poster: I think now is the time to ask them, since we're apparently creating One Team To Rule Them All :-). [18:44] gary_poster: but yeah, answer leonard first, it's no problem [18:44] gary: it's a branch off of lp:launchpadlib. it's got to be some problem with my setup [18:44] kfogel: my inclination is JFDI. Here's my argument. [18:44] i can import the system lazr.uri (from the deb) using the system python [18:47] 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] 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] 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] may have been truncated. tail: [18:47] 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] and, may I add: [18:48] ) [18:48] and "." even [18:48] ok leonardr trying [18:48] gary_poster: I completely agree with you so far. Some of your text got elided. [18:48] and, may I add: [18:48] ) [18:48] and "." even [18:49] sorry, that was me trying to be funny :-/ [18:49] gary_poster: oh, heh [18:49] gary: if i set an impossible version for lazr.uri in setup.py i do get an error [18:49] so, done [18:49] 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] kfogel: ok, will do. thank you [18:50] gary_poster: thank _you_! [18:50] high time [18:50] 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] maxb: I don't know. [18:51] maxb: not for production. for edge and such, yes [18:51] leonardr: what version of py did you use? [18:52] 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] gary: 2.6.4 [18:52] leonardr: ok [18:52] maxb: eh...I'll add that to the email I guess, but I'm in favor of one step at a time :-) [18:53] gary: i see references to .buildout/eggs/lazr.restfulclient (etc) in sys.path, but not lazr.uri [18:53] Sure... just trying to assemble all possible uses for a community write-access team [18:53] cool [18:54] leonardr: bah, I wonder if this is a setuptools c11 problem }:-( [18:59] gary, what's a c11? === Ursinha is now known as Ursinha-afk [18:59] at this point i'm tempted to remove apport packages and all other things that use launchpadlib to restore solution (1) [18:59] the newest version that phil eby released after much annoyance in the distutils list that is not worth recounting. [19:00] ah [19:00] 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] gary: np [19:04] gary: fyi, rick spencer is not going to work on the gtk launchpad credential client until after uds [19:05] leonardr: urg. :-( ok [19:05] gary_poster: ping. [19:05] leonardr: I was able to import lazr.uri just fine. [19:05] lfaraone: hello [19:07] leonardr: uh. are there any helpful error messages you can share? [19:07] gary_poster: What additional information would you need, re branded domains. [19:08] gary_poster: I talked to kfogel and kiko about it about a week ago in #launchpad. [19:10] gary: unfortunately not. it just doesn't show up in sys.path [19:10] 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] i'll look through the output of buildout [19:10] gary_poster: ah, okay. (I was wondering... :) [19:10] :-) [19:11] gary_poster: let us know if you need anything. [19:11] lfaraone: will do, thank you, and sorry for not being clear :-) [19:12] 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] gary: i get an "Unbuilt egg for ClientCookie [unknown version]" warning, but that's probably not relevant [19:16] (like linking branches, etc) [19:18] 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] 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] 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] 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] gary_poster: understood. [19:24] gary: do i need to use home-installed python for everything, or just bootstrap? i've been using it for bootstrap [19:24] yeah, bootstrap writes the right #! lines, so it shuold be fine [19:25] gary: however, you're right that it is looking in /usr/lib/python2.6/dist-packages for the ClientCookie [19:25] leonardr: just bootstrap, and then bin/buildout without a Python invocation [19:25] yeah, that's what i did [19:26] 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] does it include site-packages? === matsubara_ is now known as matsubara [19:31] gary: [19:31] >>> [x for x in sys.path if 'site' in x] [19:31] ['/home/leonardr/bin/python/lib/python2.6/site-packages'] [19:31] so, yes [19:32] leonardr: yeah, sorry wasn't clear [19:32] that's your local site-packages [19:32] which is presumably empty [19:32] ok. is there a site packages in my personal install? [19:32] did i configure incorrectly maybe? [19:34] leonardr: is this using a launchpadlib that had previously used a system python? [19:34] IOW, you are reusing a checkout [19:34] ? [19:35] trying to duplicate that way [19:36] heh that didn't get very far [19:36] but leonardr, if you think that's possible, try a fresh checkout. [19:37] 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] that's a promising line of inquiry [19:38] but I'd try the fresh checkout to be sure [19:38] yeah, trying that [19:52]