[00:00] <wgrant> This might tie in interestingly with the ideas presented in bug #532055
[00:00] <mup> Bug #532055: Trusted credential-management apps are broken and may be doomed <launchpadlib :New> <https://launchpad.net/bugs/532055>
[00:01] <jml> heh heh
[00:02] <wgrant> Does anybody know what is happening with https://bugs.launchpad.net/bugs/529348? It's a trivial fix..
[00:23] <adiroiban> is there any documentation for @cachedproperty ? I don't know why, if I use it, I get raise ClosedError("Connection is closed") in the tests
[00:36]  * mwhudson lunches
[00:42] <jtv> Good morning antipodeans and others
[00:48] <thumper> I was going to say hi to jtv
[00:48] <thumper> but he has no staying power :)
[00:51] <jtv> I think I used to be able to do this: push a branch to launchpad.dev... what am I missing
[00:54] <jtv> ah, it's documented!
[00:54] <thumper> jtv: yeah
[00:55] <mwhudson> bzr-svn is at least better than cscvs: after some 10 hour long failures, bzr-svn succeeds in 46 minutes: https://code.edge.launchpad.net/~vcs-imports/maxosx/trunk
[00:55] <thumper> w00t
[02:31] <jtv> hi stub
[02:32]  * stub waves groggily and moans something unintelligable
[02:41] <jtv> stub: I could murder a lumberjack...
[02:41] <jtv> cuppa?
[02:41] <jtv> (I've been at it for a few hours already... don't ask what got into me)
[02:41] <stub> Maybe in a couple of hours...
[02:42] <stub> I'm still stuffed full of roast beef and belgian fries
[02:43] <jtv> John's cooking?
[02:43] <stub> need consciousness...
[02:43] <stub> yer
[02:45] <jtv> Sorry I missed it...  I grabbed some delicious "hello sir" from 3/1 to eat while watching a film at home with the missus—her idea—who then decided to skip the film so as to get up early for the temple this morning.
[02:45] <jtv> TIT
[02:46] <jtv> stub: meanwhile, I'm just moving some stuff over to the slave store.
[02:59] <stub> jtv: I could probably be arsed dragging myself down for a coffee now
[03:02] <jtv> stub: good, because what I just cooked up looks too horrible to swallow
[03:02] <jtv> stub: I can be on a motoecy in a few minutes
[03:03]  * stub crawls off looking for his pants
[03:39] <wgrant> I just love seeing XXX comments with text like "I have no idea what the code below is meant to do."
[03:46] <mwhudson> wgrant: soyuz code i presume?
[03:46] <wgrant> mwhudson: But of course.
[03:47] <mwhudson> thumper: around to review a branch?
[03:48] <mwhudson> 1 whole line of changes!!
[03:52] <thumper> mwhudson: yeah
[03:52] <thumper> mwhudson: I have one for you too
[03:53] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/git-http-imports-bug-438929/+merge/20716
[03:53] <mwhudson> thumper: ok
[03:54] <thumper> mwhudson: actually, you know what?
[03:54] <thumper> mwhudson: it can wait
[03:54] <thumper> mwhudson: otherwise I'll be proposing against the wrong branch
[03:54] <thumper> mwhudson: just to not show you the db-devel changes
[03:54] <thumper> mwhudson: when db-devel is merged into devel it'll make more sense
[03:55] <mwhudson> thumper: heh, ok
[03:55] <mwhudson> thumper: my rc branch landed fine btw
[03:55] <thumper> mwhudson: yours is done
[03:55] <thumper> cool
[03:55] <thumper> mwhudson: which one was that?
[03:55] <mwhudson> thumper: the one fixing xmlrpc requests in read only mode
[03:56] <thumper> mwhudson: ah, was that what was screwing us over?
[03:56] <mwhudson> thumper: which screwage do you mean?
[03:56] <mwhudson> but no, probably not
[03:56] <thumper> mwhudson: about connections hanging around
[03:57] <mwhudson> thumper: no
[03:57] <thumper> oh
[03:57] <mwhudson> at least, that seems very unlikely
[03:57] <thumper> so what was the change?
[03:57] <mwhudson> thumper: it just fixes loads of spurious oopses
[03:57] <thumper> mwhudson: fair enough
[03:57] <thumper> mwhudson: how's your afternoon going?
[03:58] <mwhudson> thumper: well, i was being fairly unproductive, so i decided to fix a couple of trivial code import bugs
[03:58]  * thumper nods
[03:58] <thumper> I've been watching the code imports fairly closely
[03:58] <mwhudson> that git one and https://bugs.edge.launchpad.net/launchpad-code/+bug/513182
[03:58] <mup> Bug #513182: +code-imports should show VCS type <code-import> <trivial> <ui> <Launchpad Bazaar Integration:In Progress by mwhudson> <https://launchpad.net/bugs/513182>
[03:58] <thumper> we seem much better now
[03:58] <thumper> cool
[03:59] <thumper> I've been making the description changes get emailed :)
[03:59] <mwhudson> cool
[04:05] <thumper> mwhudson: what if we renamed +junk to +branch?
[04:05] <thumper> confusing?
[04:06] <mwhudson> seems a bit random, somehow
[04:06] <mwhudson> it doesn't really distinguish it from the other, um, branches
[04:06] <persia> If you change +junk (and I've seen some chatter about that bug), could you leave an invisible redirect for the various immutable docs out there (mostly email archives)
[04:07] <mwhudson> surely
[04:07] <persia> Wonderful :)
[04:08] <thumper> I've been trying to think of a meaningful anem
[04:08] <thumper> name
[04:08] <thumper> +own
[04:08] <thumper> +my
[04:08] <thumper> +personal
[04:08] <thumper> all a bit weird
[04:08] <persia> Weren't there some suggestions in the bug?  If not, there were certainly some in -motu and I can dig up logs.
[04:08] <thumper> I want to make sure it still makes sense with a team branch
[04:08] <thumper> persia: there were
[04:09] <thumper> persia: discussed in -motu?
[04:09] <persia> That bug was.
[04:09] <persia> (someone found +junk offensive, and ranted for a bit, and a few names were thrown out)
[04:09] <persia> I'll see if I can find the log.
[04:10] <thumper> bug 147407
[04:10] <mup> Bug #147407: Junk sounds too harsh <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/147407>
[04:10] <mwhudson> thumper: thanks for making rockstar do make run_codehosting btw :)
[04:10] <thumper> +user
[04:12] <persia> Which doesn't work for teams.  And the conversation I remember ended being a tutorial on how to stick a branch on people.ubuntu.com
[04:12] <thumper> +misc
[04:12] <thumper> +code
[04:13] <thumper> I think I'd rather have +branch over +coe
[04:13] <thumper> +code that is
[04:13] <thumper> the branch to change this will be relatively simple, and I'd like to get it done
[04:14] <thumper> I'm going to go with +branch
[04:14] <poolie> hi thumper
[04:14] <thumper> and see what happens
[04:14] <thumper> hi poolie
[04:14] <thumper> I'm just trying to walk out the door
[04:17]  * thumper afk
[04:17] <wgrant> Odd. Somebody added LFC.sha256 a year ago, but didn't add the three extra lines to actually get it populated for new files.
[07:26] <wgrant> al-maisan, noodles775: Since LP again won't have emailed anybody, have a poke about https://bugs.edge.launchpad.net/bugs/532445 and https://bugs.edge.launchpad.net/bugs/532454
[07:27] <al-maisan> wgrant: thanks, looking.
[07:50] <henninge> Hi wgrant! ;)
[07:50] <wgrant> Morning henninge.
[07:51] <henninge> wgrant: thanks for the help the other day, I got the buildd to work and command it via rpc.
[07:51] <wgrant> henninge: Excellent.
[07:51] <wgrant> henninge: I see I forgot the ensurepresent call. I'm glad you worked it out in the end.
[07:52] <henninge> wgrant: yes, I got that from the code ... ;)
[07:52] <wgrant> Being able to see the code is handy.
[07:52] <henninge> wgrant: that chroot you pointed me to, is that the same that is used on the production builders
[07:52] <henninge> or will be
[07:52] <henninge> ?
[07:52] <wgrant> henninge: It's the same.
[07:53] <henninge> wgrant: Can I adapt it to my purposes?
[07:53] <wgrant> henninge: You can now directly get the current URL from https://launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url
[07:53] <wgrant> henninge: Please don't.
[07:53] <wgrant> Your script should be able to run on the chroot you get from LP.
[07:53] <wgrant> Unless we want to start having separate chroots for each job type, which we have so far avoided.
[07:53] <wgrant> and would like to continue to avoid.
[07:54] <wgrant> You'll see that the recipe build job installs the packages that it needs itself.
[07:54] <henninge> yes, I was trying that, too.
[07:55] <henninge> I get  "permission denied" when trying to run apt-get.
[07:55] <henninge> wgrant: what do you mean by "recipe build job" ?
[07:55] <wgrant> Sounds like you are running that from inside a script that runs as the user.
[07:56] <henninge> so, what user does the buildd run as? root?
[07:56] <wgrant> henninge: See lib/canonical/buildd/buildrecipe
[07:56] <wgrant> It runs as buildd, but can sudo.
[07:56] <henninge> That's what I am doing.
[07:57] <henninge> wgrant: there is no sudo in the chroot, though
[07:57] <wgrant> henninge: No. You have to sudo from outside.
[07:58] <henninge> wgrant: so should the build job inside the chroot do everything as root?
[07:58] <wgrant> henninge: Probably not.
[07:58] <wgrant> You need a script running outside the chroot to:
[07:58] <wgrant>  1) sudo into the jail and install your dependencies
[07:59] <wgrant>  2) jump into the jail as the normal user, and run pottery or whatever it is you want to do.
[08:00] <henninge> wgrant: oh, I think I was not aware that I don't need to be root to call chroot.
[08:01] <wgrant> henninge: You do need to be.
[08:01] <wgrant> henninge: see the 'su -c' calls in buildrecipe.
[08:01] <wgrant> That is run inside the chroot to switch back to the right user.
[08:01] <henninge> looking at that now
[08:01] <wgrant> So you end up doing 'sudo chroot su -c "whatever command" buildd'
[08:01] <henninge> oh, forgot about su with all the sudoing ...
[08:01] <wgrant> er, of course there's the chroot path in there somewhere.
[08:02] <wgrant> Yeah, it's horrifyingly messy.
[08:02] <henninge> yes, shure
[08:02] <henninge> s/h//
[08:02] <wgrant> 'shure' makes more sense!
[08:02] <henninge> ;-)
[08:02] <henninge> wgrant: thanks, I feel a lot more enlightened
[08:03] <wgrant> henninge: Excellent.
[08:03] <wgrant> You may still beat recipes to production..
[08:15] <henninge> wgrant: I see that buildrecipe installs sudo in the chroot. I uses both sudo -u and su -c
[08:15] <wgrant> henninge: Heh, I wonder why.
[08:16]  * wgrant looks.
[08:16] <wgrant> Ah, right, I remember from the sprint now.
[08:16] <wgrant> The environment variables.
[08:16] <henninge> wgrant: sudo is nicer to handle with call
[08:16] <wgrant> Yeah.
[08:17] <wgrant> It was going to be risky and difficult to escape them and stick them in a string for su -c.
[08:19] <henninge> wgrant: also, it is a bit hard to try out the installing because the sources.list in the chroot points to ftpmaster.internal
[08:19] <henninge> I'll just have to overwrite that
[08:20] <wgrant> henninge: You can pass a list of sources.list entries in the build call.
[08:21] <wgrant> Assuming that you're using the normal chroot infrastructure code (unpack, override sources.list, upgrade).
[08:21] <henninge> hm, I have not yet seen the "overide sources.list" part
[08:22] <wgrant> Add to the extra_args of your build call: "'archives': ['deb http://blah/ubuntu blah blah blah', '..']"
[08:22] <henninge> I see
[08:27] <henninge> ok, found it
[08:27] <henninge> wgrant: I am not using the DebianBuildManager btw. Maybe I should.
[08:27] <noodles775> Where are you looking? (/me wants to follow along as much as I can)
[08:28] <wgrant> henninge: I think you should.
[08:28] <wgrant> Let me look.
[08:28] <wgrant> I created it, but that was almost two months ago now so blaaaah.
[08:28] <wgrant> Yeah, you should probably use it.
[08:28] <henninge> noodles775: DebianBuildManager.doSourcesList
[08:28] <noodles775> henninge: ta.
[08:29] <henninge> noodles775: it calls slavebin/override-sources-list
[08:29] <henninge> wgrant: ok, let me look into that
[08:29] <wgrant> henninge: If you want to see how normal builds work, look at the build logs on production.
[08:30] <henninge> wgrant: where do I see them
[08:30] <henninge> ?
[08:31] <wgrant> https://edge.launchpad.net/ubuntu/+builds?build_text=&build_state=built
[08:31] <henninge> wgrant: cheers
[08:33] <henninge> oh yeah, very interesting
[08:35] <adeuring> good monring
[08:37] <wgrant> henninge: What's still to do with the slave and master template code?
[08:37] <henninge> wgrant: what do you mean?
[08:37] <henninge> adeuring: moin
[08:38] <wgrant> henninge: Well, what are you doing to it?
[08:38] <adeuring> moin henninge
[08:38] <wgrant> I thought it was mostly working.
[08:38] <henninge> wgrant: well, obviously it's not ...
[08:38] <wgrant> Heh, yeah, I've just looked at the stuff in the tree and seen that it doesn't do much.
[08:39] <henninge> It's obviously never been run like I am trying to run it now.
[08:40] <wgrant> Right.
[08:40] <henninge> I have added the call to the actual template generation code but getting it to be run is my challange now.
[08:40] <henninge> wgrant: but I think I am getting there
[08:40] <wgrant> The call to that code seems to already be there.
[08:40] <wgrant> Although the filename is wrong.
[08:41] <henninge> you mean "generate...py"?
[08:41] <wgrant> And you can save an awful lot of code by using DebianBuildManager.
[08:41] <wgrant> Yeah, that.
[08:41] <henninge> that's just a dummy, too.
[08:42] <henninge> wgrant: oh no, sorry
[08:42] <henninge> I already landed that part ... ;-)
[08:42] <wgrant> It doesn't look like it will actually check out the branch, though.
[08:42] <wgrant> And it imports from lp.*, so it won't work in the slave.
[08:43] <henninge> wgrant: I added stuff to debian/rules
[08:43] <henninge> so the importing works
[08:43] <wgrant> henninge: Oh.
[08:43] <wgrant> That seems a bit ugly. But I guess the whole slave thing is pretty ugly.
[08:44] <henninge> My thinking ...
[08:44] <henninge> ;)
[08:44] <wgrant> henninge: Is there a reason for that file to live in lp.translations at all?
[08:45] <henninge> wgrant: I was trying to mimic the way tachandler was included.
[08:46] <henninge> it seemed to replicate the structure from the canonical tree, so I did the same for the lp tree
[08:46] <henninge> wgrant: the code is only needed in the buildd, so it could live in canonical/buildd .
[08:46] <wgrant> henninge: tachandler is copied in because it's used on both sides.
[08:47] <wgrant> So I would just put your file in lib/canonical/buildd and be done with it.
[08:47] <henninge> I guess that's true.
[08:48] <henninge> wgrant: but it seems nicer for all translation code to live lp.translations ...
[08:48]  * wgrant is very tempted to split up lib/canonical/buildd's contents into subdirectories.
[08:49] <noodles775> Into what for example?
[08:49] <henninge> good idea
[08:49] <noodles775> per app?
[08:49] <wgrant> translations, recipe, binary
[08:49] <noodles775> Right.
[08:49] <wgrant> Per build type, yeah.
[08:49] <wgrant> And a general one.
[08:49] <wgrant> Since the dir is getting pretty big.
[08:49] <wgrant> And there is obvious separation.
[08:49] <noodles775> +1
[08:50] <henninge> +1
[08:50]  * henninge has to relocate, back in 20 min max.
[09:13] <mrevell> Morning
[09:15]  * henninge is back
[09:20] <jml> mrevell, good morning
[09:20] <mrevell> Good morning jml
[09:33] <jtv1> I'm having some trouble with codehosting on my dev machine...  I "make run" and "make run_codehosting."  I push a branch to lp://dev/...  I make changes to the branch, and when I push again, I'm told the branches have diverged.
[09:33] <jtv1> Anyone know what I'm doing wrong?
[09:39] <henninge> jtv: is make run_codehosting new? I just do make_run
[09:39] <henninge> used to, I mean
[09:39] <jtv> henninge: I believe it's new, yes
[09:40] <jtv> killall -9 firefox
[09:40] <jtv> ahhhh
[09:41] <jtv> I should put that in cron.hourly
[09:44] <jtv> stub: I believe you said tests were going back to a single store... do we have a bug for that?
[09:45] <stub> launchpad is, not just tests
[09:45] <stub> single replication set
[09:45] <wgrant> How are lp_* going to be replicated to c-i-p?
[09:46] <stub> I'm not counting that as part of launchpad ;)
[09:46] <jtv> stub: oh, so still replicated...  Using the slave store will require some extra commits in tests then.
[09:46] <stub> Yup.
[09:48] <jml> didrocks, hi
[09:48] <didrocks> hey jml
[09:48] <didrocks> jml: sorry, but yesterday, it was like hell :)
[09:48] <jml> didrocks, understood
[09:48] <didrocks> jml: I pulled your branch and get scared by the amount of change :)
[09:50] <jml> didrocks, wgrant makes a very interesting objection -- if we have an API for adding, say, SSH keys, then a malicious application that gained your approval could add a key, then use that key to get your branch data even after you revoked privileges from the application
[09:51] <wgrant> jml: I think modification of that belongs in the trusted client. Not the cleanest solution, but just about anything else is unsafe.
[09:51] <didrocks> jml: GC already does that manually (upload a ssh key for you). I'm not sure not exposing that will prevent this usage
[09:52] <wgrant> didrocks: People should soon be educated to not give their password to such applications.
[09:52] <wgrant> And that will stop working soon.
[09:52] <wgrant> I hope.
[09:52] <didrocks> wgrant: right :)
[09:53] <didrocks> that's just too much hope on the user side I'm afraid against a promise for a "wonderful application making your life better (and spamming you, destroying your data and so on…)"
[09:54] <didrocks> but that's just my opinion :)
[09:57] <jml> didrocks, anyway, I'm not sure how to proceed. The work we've done already is good & useful and should be merged.
[09:58] <didrocks> jml: right, but unfortunately, that won't save the "I don't achieve to upload my gpg/ssh key or uploading wrong one, and so on…"
[10:01] <jml> didrocks, hmm.
[10:04] <jml> adeuring, I notice that the bugs with patches view includes fix released bugs
[10:04] <adeuring> jml: yes
[10:04] <jml> adeuring, is this deliberate?
[10:05] <adeuring> yes
[10:05] <adeuring> ...but I can't remember the exact reason. Probably because "fix released" is intersting for upstream
[10:05] <adeuring> kfogel might remember better ;)
[10:05] <jml> ok. I'll ask him.
[10:07] <wgrant> Doesn't that just mean it's going to get longer and longer and become less and less useful?
[10:07] <henninge> wgrant: I think DebianBuildManager has too much specific stuff that I don't need.  Any reason doSourcesList, doUpdateChroot, doReapProcesses should not be in BuildManager instead (and their confgis moved to allmanagers) ?
[10:07] <wgrant> henninge: What specific stuff don't you want?
[10:08] <henninge> wgrant: what's ogre model btw ;-)
[10:08] <wgrant> henninge: It's not used any more. The master used to pass in a component rather than a full sources.list
[10:08] <wgrant> ogre model refers to the layering of the components.
[10:08] <wgrant> main includes just main. restricted includes restricted and main.
[10:09] <wgrant> universe includes universe and main.
[10:09] <wgrant> multiverse includes multiverse, universe, restricted and main.
[10:09] <henninge> ah, I see.
[10:09] <henninge> wgrant: changes file handling for example I don't need
[10:10] <henninge> gatherResults will work differently for me, too.
[10:10] <wgrant> Yeah, so just gatherResults, _parseChangesFile and getChangesFilename?
[10:10] <jtv> wgrant, henninge: the FSM for DebianBuildManager is also a lot more extensive than we need, isn't it?
[10:10] <henninge> jtv: yes, that's another thing
[10:11] <wgrant> jtv: Why?
[10:11] <wgrant> I think you need everything there.
[10:11] <jtv> wgrant: our job is simpler... no need to install build dependencies, for one
[10:12] <wgrant> DebianBuildManager doesn't handle build-dependencies AFAIK.
[10:13] <jtv> Then who installs them before building a package?
[10:13] <wgrant> jtv: sbuild in the binary case, or the recipe build script in the recipe case.
[10:13] <jtv> oh, it's further down in the hierarchy
[10:13] <wgrant> Yes.
[10:14] <jtv> So is DebianBuildManager not limited to building Debian packages then?
[10:14] <jtv> The branches we work with don't necessarily have a debian/ dir etc.
[10:14] <henninge> jtv: no, it doesn't look that way
[10:16] <henninge> wgrant: Yes, you are right with that list (gatherResults...)
[10:16] <jtv> Looks like
[10:16] <wgrant> henninge: Why not just override gatherResults?
[10:16] <jtv> Yes, that does seem to make sense
[10:16] <henninge> wgrant: yes, the obvious next step
[10:17] <wgrant> You already need to do similar things on the master side, where we've made assumptions in superclasses that you have a build.
[10:17] <wgrant> So you might as wlel make it easy for yourself and just override the two methods.
[10:17] <henninge> correct
[10:17] <wgrant> (the one to do the actual building, and gatherResults)
[10:17] <henninge> wgrant, jtv: yes, I will do that.
[10:18] <henninge> thanks
[10:18] <jtv> It does mean that DebianBuildManager is a total misnomer
[10:18] <jtv> (what's this Ogre thing btw?  Do we need that at all?)
[10:19] <wgrant> jtv: It doesn't. You're building in a Debian chroot.
[10:19] <wgrant> You don't care about that. We should remove ogre support.
[10:19] <jtv> ahh, Debian only in _that_ sense
[10:19] <wgrant> It hasn't been used in nearly three years.
[10:19] <jtv> So... what build managers do we have that are not debian build managers in that sense?
[10:19]  * jml rebooting
[10:19] <wgrant> None at this point.
[10:21] <wgrant> But there could quite conceivably be some later.
[10:28] <wgrant> stub: Do you know why there is a LFC.sha256 column, but it's not actually being populated?
[10:29] <stub> because soyuz team decided they needed it, added the column, but didn't need it enough to make the librarian actually store it when files are uploaded.
[10:29] <bigjools> lol
[10:29] <wgrant> Odd, since it was about 3 lines extra to do it.
[10:30] <stub> Yup. Also about 3 lines to drop the column again...
[10:30] <wgrant> But we'll need the column soon.
[10:30] <wgrant> We should be using more than MD5 in the indices.
[10:30] <stub> I've heard that for maybe a year now ;)
[10:30] <wgrant> This is Soyuz. Time is different here.
[10:31] <bigjools> my clock says it's 1984
[10:31] <stub> So three line fix to the librarian to store the sha256. A quick and ugly data migration script to fill in the values for the existing files. A DB patch to set the column to NOT NULL.
[10:31] <stub> Party like its 1999
[10:32] <wgrant> Quick, ugly, and several-week-taking?
[10:32] <jml> didrocks, so what are we going to do?
[10:32] <stub> wgrant: Its only a few terrabytes - shouldn't take too long.
[10:33] <wgrant> Was SHA1 there from the start?
[10:33] <jml> bigjools, "It was a bright cold day in April, and the clocks were striking thirteen."
[10:33] <stub> I think it was, yes.
[10:34] <wgrant> So it's not been done before :(
[10:34] <bigjools> jml: we need to talk!
[10:34] <didrocks> jml: that's a good question…  :/
[10:34] <stub> Its pretty trivial. I can hack up the migration if nobody else wants to.
[10:34] <jml> bigjools, we do.
[10:34] <jml> bigjools, lemme book a time
[10:41] <jml> bigjools, 12:30 ok? or we can talk now until 11
[10:41] <bigjools> jml: no 12:30 is bad, I have a hospital appt at 1
[10:41] <bigjools> so now is good
[10:41] <jml> ok. I'll skype you.
[10:53] <jtv> henninge: you may have to pretend that the dir with your packages is an apt cache... something like -o Dir::Cache=/tmp/extra-packages
[10:54] <henninge> jtv: let me try that out
[10:54] <jtv> was I stopping you?
[10:55] <wgrant> henninge, jtv: Alternatively, upload them to a local or real PPA.
[10:55] <wgrant> What custom packages are there?
[10:56] <henninge> wgrant: no, it's launchpad-buildd
[10:56] <henninge> wgrant: I am using pbuilder to try it out and want to install it in there
[10:57] <henninge> actually, pbuilder might be able to do it, too
[10:57] <wgrant> henninge: Ahh.
[10:57] <wgrant> pbuilder login
[10:57] <henninge> exactly
[11:06] <jtv> henninge: does that solve it?
[11:06] <deryck> Morning, all.
[11:06] <henninge> jtv: havn't gotten that far, got distracted. Read it on the wiki page next week ... ;-)
[11:07] <jtv> henninge: I'm also looking at ways to do this
[11:07] <noodles775> henninge: ah, you are capturing all this on a wiki page? Great!
[11:07] <henninge> noodles775: not yet but we just decided to do it
[11:10] <jtv> henninge: haven't found anything better than adding a "file:" URL into the slave's /etc/apt/sources.lists.d
[11:10] <jtv> hi joey!
[11:10] <joey> hi jtv
[11:10] <wgrant> jtv: henninge: Why can't you just dpkg -i it?
[11:10] <jtv> wgrant: need to satisfy the deps as well
[11:10] <henninge> wgrant: I want dependencies to be pulled automatically
[11:11] <wgrant> jtv: dpkg -i blah.deb; then 'apt-get -f install'
[11:11] <jtv> eh
[11:11] <jtv> I guess that'd work too  :)
[11:11] <wgrant> I thought I described this on the wiki page.
[11:11]  * jtv facepalms
[11:11] <jtv> wgrant: which wiki page is that?
[11:11] <jtv> There's so much text out there, sometimes it's like not having any
[11:11] <henninge> wgrant: which wiki page
[11:11] <wgrant> jtv: HowToUseSoyuzLovally
[11:11] <henninge> uh-oh
[11:12] <wgrant> s/v/c/
[11:12] <henninge> Lovely
[11:12] <henninge> ;)
[11:12] <wgrant> Or Run or whatever it is.
[11:12] <wgrant> Heh.
[11:12] <jtv> Use, yes
[11:13] <noodles775> wgrant: I thought henninge was going to document something like, extending the build-system for translations.
[11:13] <henninge> noodles775: that's next
[11:13] <noodles775> Great.
[11:13] <jtv> But first, "running a local build slave"
[11:14] <jtv> at all
[11:14] <wgrant> I think the wiki page probably describes it OK.
[11:16] <noodles775> Yeah, so do I? I followed the current wiki page and binary builds went through fine. BUt I think you guys are already talking about custom stuff for translations right? (ie. talking directly with the buildd via xml-rpc)
[11:16] <jtv> maybe... it's a bit hard to get the general drift when you're not "into" soyuz.
[11:16] <henninge> noodles775: yes
[11:16] <noodles775> OK.
[11:16] <henninge> I'll just describe what I did and we can converge afterwards.
[11:17] <noodles775> Great!
[11:18] <wgrant> noodles775: The talking directly to the buildd is just for testing.
[11:19] <wgrant> The real setup will go through buildd-manager.
[11:28] <jtv> wgrant: whee, is that an easier way of getting the latest chroot tarball that you found?
[11:29] <wgrant> jtv: I didn't find it; I added it last week.
[11:29] <jtv> wgrant: ah :)
[11:30] <jtv> very cool.  One gotcha: the URL on the wiki page doesn't quite work for some reason, but if I go up one "directory" I get the information
[11:30] <wgrant> jtv: It does work if you wget it.
[11:30] <wgrant> Your browser is probably trying to interpret it as XHTML.
[11:30] <jtv> niiice!
[11:38] <jtv> wgrant: adding a command line to download the tarball in one go
[11:40] <wgrant> jtv: So I can say 'grab-chroot-from-launchpad ubuntu lucid i386' and it will download it and upload it to my dev instance?
[11:41] <jtv> wgrant: nothing so fancy, but that would be a good idea wouldn't it?
[11:41] <jtv> for now it's just a wget command line
[11:41] <jtv> There must be some way to make the architecture default to whatever you're currently running...  all my attempts so far give me i686 when I want to see i386
[11:42] <jtv> (Which is nice for those pre-Pentium users out there of course :)
[11:42] <wgrant> jtv: Just use i386.
[11:42] <wgrant> It'll work everywhere Launchpad runs.
[11:42] <jtv> not going to break on native amd64?
[11:43] <jtv> (wow, lsb_release takes a while to collect lots of data, but no architecture there)
[11:43] <wgrant> Hm, it's possible that the buildd package will default to amd64 there. It's one line in a config file to switch it to i386, but that's a good point.
[11:43] <wgrant> 'dpkg --print-architecture' will work.
[11:45] <jtv> yay
[11:47] <jtv> But this is going to be relatively hard work for replacing a wget command line.  Laziness is beginning to appeal...
[11:48] <wgrant> Yeah.
[11:50] <jtv> wgrant: of more urgency is a fix needed to the setup script I wrote: it fails to register your ssh key(s)
[11:50] <jtv> easily fixed, but saves more trouble right now
[11:50] <wgrant> jtv: Refactor make-lp-user, I guess?
[11:51] <jtv> either way I think my script should use make-lp-user; the question is should the GPG key registration be moved in there.
[11:52] <wgrant> Probably. It and the CoC signing are both useful.
[11:54] <jtv> Ah yes, now I see why I hesitated about that: it means adding options parsing.  :)  make-lp-user <user> [<team> [<team> [...]]]
[11:55] <wgrant> Ahh.
[11:55] <jtv> not exactly hard though :)
[11:55] <jtv> I could lift the -e option across wholesale
[12:12] <henninge> noodles775, wgrant: First iteration but not final yet (have to try it all out once more) https://dev.launchpad.net/BuildFarm/TryOutBuildSlave
[12:12]  * henninge lunches
[12:15] <jtv> wgrant: new & improved make-lp-user is underway.  :)
[12:16] <jtv> wgrant: bug 532354
[12:16] <mup> Bug #532354: Set up ssh keys for ppa-user <Soyuz:Triaged> <https://launchpad.net/bugs/532354>
[12:19] <wgrant> jtv: Excellent.
[12:23] <jml> jtv, why does make-lp-user need to change to address that bug?
[12:23] <adiroiban> hi. I have this interface inherited by IProducSeriesPublic and IDistriSeriesPublic http://paste.ubuntu.com/388916/, does anyone know why active and summary is visible in API, while drivers_collection_link is not ?
[12:24] <jtv> jml: it already registers your ssh keys; it seems madness to register your gpg keys in another script.
[12:25] <jtv> jml: and I suspect automated gpg key registration can be useful for other uses as well.
[12:25] <jtv> (it's optional, of course)
[12:25] <jml> jtv, ahh yes. that makes sense. the bug itself says "ssh", so I was confused.
[12:26] <jtv> jml: that is my fault.  From my perspective, I found that I duplicated much of the make-lp-user functionality, but not this part—and it was needed for full usage.
[12:26] <jml> heh
[12:26] <jtv> So for me the immediate problem was, "my ssh key isn't registered when I set things up this way."
[12:26] <jml> adiroiban, I don't know, sorry.
[12:27] <wgrant> jtv: Pure Soyuz people need no SSH keys.
[12:27] <wgrant> adiroiban: Can you pastebin the entire diff?
[12:27] <wgrant> adiroiban: There's nothing obviously wrong there.
[12:27] <jtv> wgrant: I can't quite tell if that's a "real men don't need [...]" joke or reality.  ;)  But it'll come in handy in any case.
[12:28] <wgrant> jtv: A combination. But in reality they're only useful for branches, which I don't often use.
[12:28] <jtv> wgrant: let's just hope the bridges will continue to sprout though :-)
[12:28] <wgrant> Indeed.
[12:28] <jtv> It may also be a good idea to rename the script...
[12:29] <jtv> But now the problem is, what do we call the build farm _plus_ soyuz?  :-)
[12:29] <bigjools> wgrant: urgh, you've forced me to remember how utterly shite dscfile.py is
[12:29]  * bigjools does some refactoring to make testing easier
[12:29] <jtv> wgrant: ^^^ well done, you made him improve the code :-)
[12:30] <wgrant> bigjools: Yeah, it's not very nice.
[12:31] <adiroiban> wgrant: http://paste.ubuntu.com/388921/ , but it's rather huge ... don't worry, I will continue to dig
[12:31] <wgrant> Ah, right, it does the format and file combo checking as well.
[12:31] <wgrant> Now I remember it.
[12:32] <wgrant> It fits a lot of evil into 800 lines.
[12:33] <wgrant> adiroiban: (not related to the problem, but DistroSeries should probably be an ISeries, not an IHasSeries)
[12:34] <wgrant> adiroiban: I think IHasDrivers is probably clobbering IHasSeriesMixin.drivers.
[12:34]  * wgrant checks.
[12:34] <wgrant> At least I presume IHasDrivers has a drivers attribute.
[12:34] <adiroiban> wgrant: true :) thanks!
[12:35] <wgrant> Yeah, that's it.
[12:39] <deryck> intellectronica, is the branch for bug 531433 going to land before the re-roll?
[12:39] <mup> Bug #531433: migration-assistant crashes ubiquity <apport-bug> <i386> <ubiquity (Ubuntu):New> <https://launchpad.net/bugs/531433>
[12:39] <deryck> hmmmm
[12:39] <deryck> bug 531443
[12:39] <mup> Bug #531443: Bug heat flames should be calculated based on the context, not the bugtask's target <story-bug-heat> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/531443>
[12:39] <lifeless> jml: you might enjoy https://code.edge.launchpad.net/~jelmer/launchpad/testr/+merge/20511
[12:40] <jml> lifeless, I do.
[12:46] <didrocks> jml: ok, got some time now. Should we first push the "read only mode"?
[12:47] <wgrant> jml, didrocks: Do you have a launchpad.View adapter for them so they'll appear anonymously?
[12:48] <jml> didrocks, yes.
[12:48] <jml> wgrant, no, not yet. what's involved there?
[12:48] <wgrant> jml: Just a launchpad.View adapter inheriting from AnonymousAuthorization.
[12:48] <wgrant> Otherwise lazr.restful will return empty collections for anonymous users.
[12:49] <wgrant> (it checks for launchpad.View, and there is no default anonymous launchpad.View adapter. The global (ie. Interface) authenticated one is deprecated, so it was forbidden to extend it to cover anonymous too.)
[12:49] <wgrant> So each exported object that will appear in a collection needs a launchpad.View adapter, even if it is actually zope.Public.
[12:56] <lifeless> jml: not sure why it would have been big... we did the heavy lifting already.
[12:56] <lifeless> gnight all
[12:57] <jml> lifeless, I didn't know the config lifting was done
[13:02] <allenap> abentley: Do you have time to help me with an issue I'm having with TestTwistedJobRunner? I'm trying to run it in a sub-process using subunit.IsolatedTestCase, but the assertions are failing. My branch is lp:~allenap/launchpad/isolate-tests.
[13:04] <lifeless> jml: I was referring to zope testerunner with subunit and load-list
[13:04] <jml> lifeless, oh ok.
[13:04]  * lifeless switches off his monitor. *yawn*
[13:12] <deryck> adeuring, what about bug 511240 for the re-roll?  Did the branch make it in?
[13:12] <mup> Bug #511240: bug heat calculation should use Bug.users_affected_count_with_dupes instead of Bug.users_affected_count <story-bug-heat> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/511240>
[13:14] <deryck> ah, I found the branch.
[13:20] <intellectronica> i'm getting test failures in doc/launchpadlib.txt in EC2, which i can't reproduce locally and are unlikely to be related to my changes. anyone seen anything like that lately?
[13:21] <intellectronica> deryck: also, my branch still hasn't landed, because of ^^^^^ (and some real errors i found in an earlier run) :(
[13:21] <deryck> intellectronica, ok.  at least we caught the errors.
[13:25] <wgrant> Hm, daily CHR again?
[13:40] <danilos> wgrant, yeah
[13:42] <adeuring> deryck: yes, it landed (sorry for the delay, was out for lunch)
[13:43] <deryck> adeuring, no worries.  Thanks for the update.
[13:46] <jml> didrocks, I've proposed my branch for merging w/ read-only
[13:46] <jml> didrocks, in terms of quickly's goals, I think your stuck for lucid -- sorry.
[13:47] <didrocks> jml: well, do you think we can do something for +1, discuss at UDS, maybe?
[13:47] <jml> didrocks, yeah.
[13:47] <didrocks> jml: I just have to propose my branch as well?
[13:48] <jml> didrocks, please propose your branch
[13:48] <didrocks> jml: so, still some room for adding announcement?
[13:48] <jml> didrocks, it'd make an interesting UDS conversation... I don't know who the right Launchpad folk would be
[13:48] <jml> didrocks, oh right, announcements.
[13:48] <jml> lemme look
[13:51] <didrocks> jml: sweet, thanks :)
[13:58] <jml> :(
[14:03] <didrocks> jml: ?
[14:03] <abentley> allenap, hi.
[14:03] <abentley> allenap, what assertions are failing?
[14:04] <allenap> abentley: self.assertEqual(1, len(runner.completed_jobs)) is the first one. It looks like it's not actually running the jobs, even though iterReady() is called.
[14:05] <abentley> allenap, or perhaps the jobs are failing?
[14:07] <allenap> abentley: incomplete_jobs is also empty.
[14:08] <abentley> allenap, does it run runJobInSubprocess?
[14:09] <allenap> abentley: I don't think so...
[14:09] <allenap> abentley: TwistedJobRunner.getTaskSource() is called once only; the generator it forms is never pulled from.
[14:10] <jml> didrocks, it's hard.
[14:10] <abentley> allenap, does the reactor start?
[14:10] <allenap> abentley: I'll check that and get back to you.
[14:10] <didrocks> jml: really? seems I don't have any luck… :(
[14:11] <jml> didrocks, well, maybe someone here will know
[14:12] <jml> hey guys, if I want to expose the ability to create announcements on projects over the API, what should I do?
[14:12] <james_w> is there a method on IProject that takes some text and other things and creates the annoncement?
[14:16] <allenap> abentley: It does start. (Fwiw, I've instrumented my branch with http://paste.ubuntu.com/388968/)
[14:20] <intellectronica> james_w: i think it's project.announce()
[14:21] <intellectronica> james_w: yeah, see lib/lp/registry/doc/announcement.txt
[14:21]  * didrocks opens as well
[14:22] <james_w> yes
[14:22] <james_w> so, lib/lp/registry/interfaces/announcement.py
[14:22] <james_w> IMakesAnnouncements.announce should be exported
[14:22] <james_w> and probably IHasAnnouncements too
[14:23] <intellectronica> james_w: i'm happy to review a branch :)
[14:23] <james_w> and IAnnouncement too I guess
[14:23] <james_w> intellectronica: I'm trying to answer Jono's question ;-)
[14:23] <intellectronica> oic
[14:23] <didrocks> james_w: jml's, no? :)
[14:23] <didrocks> (and mine as well in fact :))
[14:24] <didrocks> thanks a lot james_w, intellectronica
[14:24] <intellectronica> james_w:  i thought by 'should' you meant 'the gnomes should export it' :)
[14:24] <intellectronica> didrocks: likewise i'm happy to help if you need. though i think by now you're an api export guru already, no?
[14:24] <james_w> @export_write_operation() is the basic decorator for announce()
[14:25] <james_w> you can pass some options to control the exported name and things
[14:25] <didrocks> intellectronica: far far far from it :)
[14:25] <james_w> there are other decorators for tweaking some other things, a grep for export_write_operation will find you some things to consider
[14:25] <didrocks> I'll give it a try beginning at the next week. Sounds easier and more streamline than gpg and ssh stuff :)
[14:25]  * didrocks logs the conversation
[14:26] <abentley> allenap, see http://paste.ubuntu.com/388976/
[14:26] <didrocks> intellectronica: james_w: thanks for the help, I hope to be able to do something useful next Monday with this
[14:26] <james_w> sweet
[14:27] <intellectronica> didrocks: np. shout if you need help. it will be great to have this stuff exported.
[14:27] <didrocks> intellectronica: be sure I'll shout for help :)
[14:27] <didrocks> first, just pushing the ssh branch
[14:28] <allenap> abentley: Ah, that's odd. Any ideas why it might be doing that? Also, what incantation did you use to get the log output? Somehow I was logger-blind when reading that file.
[14:29] <abentley> There's a debug logger named "gloop" defined near the ParallelLimitedTaskConsumer.  I just fed it in.
[14:30] <abentley> I can't think why launchpad_ftest wouldn't exist, but I'd guess it was due to missing environment variables.
[14:31] <allenap> abentley: Ah, that's a good thought.
[14:45] <abentley> allenap, interestingly, when turn TestJobRunner into an IsolatedTestCase, it tries to create duplicate keys.
[14:47] <jml> if you'll pardon a wild-arsed guess, is that because the factory has all-new internal state when it's in a subprocess?
[14:47] <allenap> abentley: Gah.
[14:48] <abentley> jml, the duplicate keys?
[14:48] <jml> abentley, yes.
[14:49] <allenap> jml: Ah, that sounds like a problem. Perhaps the factory should use a uuid or a counter driven from a file instead of a per-process counter?
[14:50] <abentley> jml, this is a constraint on the primary key not being duplicated.  That's a serial, and I don't think the factory would have anything to do with that.
[14:50] <jml> abentley, ok. that makes sense. sorry for the noise.
[14:50] <abentley> jml, no worries.
[14:51] <sinzui> danilos: Can you trade chr with me? I am sprint on the 8. (monday)
[14:52] <danilos> sinzui, sure, please mark the change in the calendar as well (or remind me: I love when I am reminded :)
[14:53] <sinzui> danilos: okay
[14:53] <MTecknology> I'm curious, you guys ever try to use nginx and launchpad?
[14:54] <danilos> sinzui, thanks
[14:55] <intellectronica> MTecknology: no, we rely on apache quite heavily. also, since the front-end web server does little of the work in launchpad, there probably won't be much benefit in replacing it even if nginx is slightly more efficient
[14:56] <MTecknology> intellectronica: oh, I was just curious because for my web servers it made a massive change. I was going to have to upgrade hardware because I was running out of resources and then I changed and magic happened. But not for the speed of script processing
[14:56] <leonardr> jml: by some freakish chance are you around? otherwise i'll email you
[14:56] <jml> leonardr, it's not even 3pm on a working day :)
[14:57] <jml> leonardr, it's not so much freakish chance as par for the course
[14:57] <leonardr> jml: can we skype?
[14:57] <jml> leonardr, sure.
[14:57] <gary_poster> jml, what's your skype id?
[14:58] <gary_poster> I'm garyposter
[14:58] <leonardr> jml: it's going to be me and gary
[14:58] <jml> blackjml
[14:59] <intellectronica> jml: you know what's freakish? i'm getting errors, on ec2, in doc/launchpadlib.txt, which i can't reproduce locally. does it ring a bell?
[14:59] <intellectronica> argh, i meant to ask leonardr, not you jml
[14:59] <leonardr> intellectronica: show me the errors
[14:59] <jml> intellectronica, good good :)
[15:00] <intellectronica> leonardr: http://pastebin.ubuntu.com/389001/
[15:38] <allenap> abentley: I think the problem is that, by the time <testcase>.run() is called, Zope has already done some set-up (based on the layer perhaps/probably), and the forking breaks things.
[15:39] <allenap> abentley: Wrapping each test case with an IsolatedTestSuite makes things work, but is not ideal or correct; it does not isolate each test method in a test case from one another.
[15:40] <abentley> allenap, that sounds plausible.
[15:41] <abentley> allenap, is TestCaseWithFactory.setUp / tearDown being called?
[15:42] <allenap> abentley: I don't know, but I didn't suspect that it wasn't...? Ah, is this to do with the ids problem in TestJobRunner from earlier?
[15:43] <abentley> allenap, I still can't imagine what would cause the TestJobRunner problem.
[15:44] <abentley> allenap, it sounds like it might not be valid to derive from both TestCaseWithFactory and IsolatedTestCase.
[15:44] <allenap> abentley: No, I can't either. It's odd. It works if wrapped in IsolatedTestSuite, so I think it's a bad interaction between Zope and everything else.
[15:45] <allenap> abentley: Right now, I suspect it's not safe to derive from IsolatedTestCase when using the Zope test runner, at least with our layer set-up.
[15:47] <abentley> allenap, quite possible, considering that layers span multiple tests.
[15:47] <abentley> allenap, I think layers have their own setup/teardown, so you might be able to invoke those manually.
[15:52] <abentley> allenap, I'm not sure what IsolatedTestCase is meant to imply, but if it means test cases don't share resources like the librarian, it doesn't sound like a good idea to me.
[15:54] <allenap> abentley: It forks before running each test method (by overriding TestCase.run) and sends the results back to the calling process using subunit. It's meant to be basically transparent, but there's something nasty going on there.
[15:54] <abentley> allenap, it only forks, or it forks and execs?
[15:55] <allenap> abentley: Just forks.
[15:56] <allenap> See run_isolated() in lib/subunit/__init__.py. There's not a lot of code (IsolatedTestCase and IsolatedTestSuite are tiny.)
[16:15] <abentley> allenap, seems to work okay if I do the fork myself: http://pastebin.ubuntu.com/389042/
[16:26] <allenap> abentley: Oh, now that's really confusing :)
[16:28] <abentley> allenap, one approach would be to gradually turn my run into run_isolated, until it breaks.
[16:41] <Ursinha> hi rockstar, is bug 531687 really triaged? there's not importance set on it..
[16:41] <mup> Bug #531687: Accessing a merge proposal during the rollout (ie R/O mode) oopsed <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/531687>
[16:42] <rockstar> Ursinha, huh.  Apparently something went wrong in the setting of it.
[16:43] <Ursinha> rockstar: thank you very much :)
[17:39] <allenap> abentley: This diff against my branch - http://paste.ubuntu.com/389095/ - works fine... until you uncomment line 48, and I have no idea why.
[17:41] <allenap> abentley: Anyway, thank you for your help today. I have to go now, but I'll check back here later in case you think of something. Bye :)
[17:41] <abentley> allenap, you're welcome.
[17:42] <abentley> allenap since this seems subunit-specific, lifeless or jml might be able to help.
[17:42] <jml> have you tried with the latest subunit code?
[18:20] <jml> g'night all