[00:37] mwhudson: I checked out the brothers hotel, it looks really nice [00:38] mwhudson: nice rooms, wifi reaches and isn't charged for, no kids, breakfast included, only 15 rooms in the entire place [00:38] mwhudson: quiet, nice views [00:38] mwhudson: probably similar pricing to the southern cross [00:38] thumper: sounds good to me, do they have room for us? [00:38] mwhudson: yep [00:39] mwhudson: I've got him to book them already [00:39] mwhudson: I'm going to email flacoste and marianna with the details [00:39] thumper: nice [00:39] mwhudson: hopefully get sign off before the end of the week [00:48] mwhudson: email sent [00:48] mwhudson: fingers crossed for a quick approval [01:36] * mwhudson zooms into town for a short while [01:37] zoom zoom zoom [02:47] mwhudson: https://blueprints.edge.launchpad.net/launchpad-code/+spec/personal-branch-url-change [02:51] mwhudson: https://blueprints.edge.launchpad.net/launchpad-code/+spec/code-import-watchdog, really deployment? [02:57] thumper: Bazaar follows 403s? Do you mean 301s/302s? [03:10] that wasn't exactly a zoom :( [03:12] thumper: yes [03:12] oh, no [03:12] * mwhudson misunderstood blueprint statuses, how did i manage that [03:32] Argh pagetitles.py. [04:00] wgrant: probably [04:00] wgrant: did you edit the page? [04:02] thumper: No. [04:16] wgrant: I've edited the page now, thanks [04:17] Great. [04:41] * wgrant points pointedly at the project reactivation request in #launchpad. [04:43] * thumper goes to make dinner [04:47] wgrant: thanks [04:49] re the project reactivation request [04:49] seems that folk misunderstand the 'registry' aspect of LP a lot [04:49] 'shutting it down' because its in LP doesn't make a lot of sense. [04:50] LP misunderstands the Registry aspect of LP a lot. [04:50] :P [04:50] L: [04:51] It doesn't handle placeholder projects well. [04:51] ack. Have a tie fighter. or two. |-<>-| +-o-+ [04:52] /Now/ I'm confused. [04:53] ;P [05:09] hi [05:09] mthaddon: in bug 534066 james_w says [05:09] Bug #534066: can't update bugtask importance via api [05:09] "OK, please ask a LOSA to check if all the edge appservers are on the same revision currently" [05:09] spm^^ [05:09] could one of you do that please? [05:10] poolie: they are, yes (the same as lpnet/production) [05:10] k thanks [05:11] mthaddon: separately, re my recent tuolumne merge, michael said [05:11] the next step is setting up the datfiles (if they haven't been), graphs, and their associations. [05:11] could you tell me how to do that? [06:10] poolie: your sql queries should be generating the datfiles; the db record for the datfiles can only by done by someone with web admin access [06:13] yep, tom's helping me [06:23] lifeless: in case you're interested, a slightly old version was accidentally merged that didn't record them properly [08:17] good morning [08:33] noodles775: Morning. [08:33] Hi wgrant! [08:34] noodles775: Can you please have a look at bug #534216 and maybe give some suggestions? [08:34] Suer. [08:34] Sure. [08:38] wgrant: pleasantly surprised that it's not a security bug :) So, +1 for the suggested breadcrumb urls, and regarding the second question, [08:38] noodles775: I decided that you didn't need any more of them in one week. :) [08:39] Why does it matter if two builds have the same breadcrumb (it's not a url), and the last breadcrumb (the i386) won't be a link anyway. [08:39] heh. [08:39] Right, it's not really important. [08:39] And it's a rare case anyway. [08:40] Yep, so +1 from me :). [08:40] Great, thanks. [08:40] * wgrant quickly implements. [08:42] wgrant: are you against there being a 'Packages for..." breadcrumb after the PPA title? [08:42] (ie. look at the breadcrumb when you traverse to +packages) [08:42] noodles775: Ah, yes, I thought about that earlier but it slipped my mind. [08:42] Great. [08:43] There should be, and probably a Builds breadcrumb as well. But that needs a custom hierarchy thingy. [08:45] Yeah, although the Builds breadcrumb is a nice-to-have-but-less-important IMO, as I'm assuming that most of the time people get to an individual build directly from the +packages page, rather than searching from +builds. [08:46] Right, probably. [09:07] Morning [09:14] hi mrevell [09:15] hey there jtv [09:15] henninge: I just updated RunningSoyuzLocally. It refers to your buildd instructions (I much prefer the chroot, obviously!) and it strips out lots and lots of manual work. [09:16] HowToUseSoyuzLocally [09:17] Oh, sorry [09:23] henninge: why all the trouble with the ntp IP address? Doesn't pool.ntp.net work? === noodles785 is now known as noodles775 [09:27] jtv: I just couldn't remember if I can put other host names into /etc/hosts ... [09:27] like: "pool.ntp.net ntp.buildd" [09:28] henninge: Or just edit /etc/launchpad-buildd/default [09:28] copy the ntp setup from the host? [09:28] I mean, we do ship with a workable default I suppose [09:36] I've already got testopenid.dev in my /etc/hosts, but can no longer login on the devserver. Should I debug this or has it already been resolved? [09:36] noodles775: What happens when you try? [09:36] wgrant: http://pastebin.ubuntu.com/390927/ [09:37] Um. [09:37] What? [09:37] That's not one I've seen before. [09:37] Yeah, me either. That's after logging out and trying to log back in on r10429 [09:37] * wgrant pulls. [09:37] ah, maybe I should update my source deps... [09:38] hrm, no that shoudl have been done by rf-get. [09:40] noodles775: Note that update-sourcecode is broken in lucid. [09:40] You need to change its interpret to the system Python. [09:41] ah thanks wgrant. [09:41] s/interpret/interpreter [09:41] I have just updated lp/devel and the test from lib/lp/registry/stories/webservice/xx-project-registry.txt is failing http://paste.ubuntu.com/390930/ [09:42] noodles775: Can I convince you to review the build breadcrumb fix along with another small old branch of mine to fix the titles and breadcrumbs of build listings and queue pages? Or should I use OCR? [09:43] wgrant: I'd love to, but would prefer the OCR right now as I'm a bit behind with a few other things. [09:44] noodles775: OK, no problem. [09:44] Thanks. [09:44] wgrant: btw, I assume you can login/out fine on r10429? [09:45] noodles775: Still updating/rebuilding. [09:45] wgrant: ah, thanks. [09:45] utilities/update-sourcecode appears to work fine here (on lucid). [09:45] Hm, odd. [09:46] It can't import bzrlib here, because it's running with 2.5 which is no longer in Lucid. [09:47] Mine's getting it from lp-sourcedeps/eggs/bzr-2.1.0-py2.5-linux-x86_64.egg/bzrlib/__init__.pyc [09:48] wgrant, jtv: sorry, had a call === jelmer_ is now known as jelmer [09:50] wgrant: I guess, because I was trying out the buildd package, I didn't want to change any files in the package, rather change the environment to work with the package. [09:52] adiroiban: that's kinda weird given that the project entries are sorted by displayname just a few lines above. [09:53] henninge: Well, a config file is pretty close to the environment. [09:53] jml: https://blueprints.launchpad.net/launchpad/+spec/launchpad-desktop [09:53] wgrant: yeah, I guess that's true. [09:53] adiroiban: ah, sorted by display name, not project name, so it looks like you could fix it by ensuring it's sorted on both? [09:55] noodles775: ok. so this only happend on my computer? [09:55] henninge: what you wrote is particularly useful to me because I wouldn't have taken the time to figure it out otherwise. As I follow your trail I'll try to automate more; I'd love it if anyone could do all this. [09:55] noodles775: ok. so this only happens on my computer? [09:55] adiroiban: the test passes here on r10429, but it looks spurious - sorting by both should ensure it will always work. [09:56] noodles775: ok. I found it while working for bug 531261. Should I fix it in a new branch or together with this one? [09:56] Bug #531261: Move ISeriesMixin to lp.registry.interfaces.series

[09:56] henninge: would it make sense to make all the changes needed for a working setup in the chroot, then publish those changes as a package? [09:57] jtv: What changes are there, apart from the NTP host? [09:57] adiroiban: if your branch consistently fails with it, you'll need to fix it there (I thought you were testing your devel branch?). If it's a quick fix, I'd included there anyway. [09:58] wgrant: whatever setup will be needed to check out a branch from the dev machine [09:58] jtv: Hmm. [09:58] Can be done with ssh setup, but that requires your personal ssh key. :/ [09:59] Another way is to copy the branch into the chroot's fs, but that has to be done from the outside. [09:59] I guess it doesn't help for that. [09:59] So never mind. :) [09:59] noodles775: well, I found it while working on that branch, but then I also tested with a fresh devel [10:00] adiroiban: Right. [10:01] bigjools: So, it turns out buildd-manager is really over-complicated... [10:01] wgrant: turns out? We've known that for ever :) [10:02] if we had the time I'd re-write it [10:02] but given the pain last time it was re-written, it would be hard [10:03] bigjools: You know how it does that thing where it gets all the builders for each DAS, adds them to an internal strange DBNote thing, then eventually iterates of each builder in each DAS... that can be replaced with a 3-line for loop. [10:03] yes the dbnote stuff is utter crack [10:03] was part of the original code, from 5 years ago === stub1 is now known as stub [10:04] * bigjools -> otp [10:05] mrevell, hi [10:05] Hello Mr jml [10:05] jml: Are you are awake! [10:06] bigjools: Yeah, well, it's easy to get rid of. I was looking at what needed to be moved from buildmaster to soyuz and vice-versa, and realised that all of that code could die. A bit of refactoring later, it was replaced with three lines and everything was a few hundred lines shorter. [10:07] buildmaster should mostly die [10:07] Well, I got rid of all but master.py. [10:07] \o/ [10:07] So only the twisted stuff lives outside the model. === bigjools is now known as bigjools-otp [10:09] * jml interested in wgrant & bigjools conversation [10:09] doctormo, I am. [10:11] jml: See link to blueprint and bug it's linked to [10:11] hey doctormo, สบายดีหมไ [10:11] jml: Basically, buildd-manager scared me, so I deleted most of it. [10:12] wgrant, destructive rampage is sometimes an appropriate response to fear. [10:12] jtv: ก็ดี [10:14] doctormo: glad to see you haven't lost it :) [10:15] Where does the chroot go? Arbitrary /tmp subdir? [10:17] wgrant, henninge? [10:17] jtv: Doesn't matter. [10:17] jtv: which chroot? [10:18] pbuilder's goes into /var/cache/pbuilder/build/ [10:18] ah, thanks [10:18] Oh, right, pbuilder. [10:18] jtv: but you can specify it on the command line for pbuilder [10:18] I'm asking because the only sane way I can think of for getting a branch in there is to copy it into the chroot from the outside. [10:19] henninge: mind if I extend the instructions for that at some point, and pick a fixed location? [10:19] jtv: There is a Makefile target to construct demo branches. [10:19] Makes it so much easier to write ready-to-go instructions. [10:19] jtv: Can't you use that, then get the slave to check it out normally? [10:19] henninge: any idea why this test is passing on my devel computer, but alwasy failing on my testing computer http://paste.ubuntu.com/390946/ ? [10:20] wgrant: I guess we could install the lp bzr plugin on the slave... [10:20] wgrant: creating the branch itself isn't the issue, but getting it onto the simulated slave. [10:21] jtv: Your dev appserver must be able to generate direct HTTP URLs, or it could not resolve lp: URLs. [10:21] jtv: do you want to copy stuff into the chroot? Or why do you need the location? [10:21] Therefore it can also pass HTTP URLs into the slave. [10:21] If you're talking about building code from arbitrary branches in chroots, why invoke pbuilder? Isn't there already a sbuild inside Soyuz? [10:21] adeuring: it's missing intltool [10:21] wgrant: it generates a direct http url, but that won't work on a dev system will it? [10:21] adiroiban: ^ [10:21] adeuring: moin ;-) [10:21] persia: This pbuilder is just to install the buildd code into on dev machines. [10:21] jtv: It should for dev, but not for tests. [10:22] In fact, yes, it does. [10:22] because recipe builds work. [10:22] adiroiban: you need to install launchpad-developer-dependencies on the testing computer [10:22] So HTTP access works fine. [10:22] wgrant, henninge: _running_ the buildd code on dev machines, right? [10:22] jtv: Right. [10:23] henninge: thanks. I will do. I guess the package in installed, but not updated [10:23] wgrant: But why pbuilder? That just adds wider support. schroot can handle tarballs, etc. just fine. [10:23] wgrant: can you show me an appropriate http url for dev access? I tried before but couldn't make it work. [10:23] persia: Don't ask me! I use schroot. [10:23] jtv: http://bazaar.launchpad.net/~path/to/branch [10:23] Er. [10:23] s/net/dev/ [10:24] Who suggested pbuilder for this? I'd like to disabuse them :) [10:24] hmm... that's what I thought didn't work earlier [10:24] persia: me, I simply don't know about schroot ... [10:24] wgrant: that's just the way I got it to run [10:25] I am not saying that that is a canonical way. [10:26] henninge: So let me know when you have time for a /query about the benefits of only supporting one chroot management system in the buildd environment (including the dev environment). Until then, I'm happy to answer questions about schroot or point at code to achieve what you seek. [10:26] persia: Note that Soyuz's sbuild doesn't use schroot. [10:27] wgrant: Yes, but not also using pbuilder makes the future alignment less painful :) [10:27] persia: Potentially, yes. [10:27] persia: how do you build your chroot environment? === bigjools-otp is now known as bigjools [10:28] or, were do you get it from? [10:28] `mk-sbuild lucid` [10:28] s/were/where/ [10:28] oh, new in lucid? [10:29] persia: ^ ? [10:29] mk-sbuild-lv has been around for a few releases, but I think mk-sbuild is reasonably new. [10:29] For non-LVM use cases, yes. [10:29] But the code ought to work in karmic, it just didn't get published then. [10:38] wgrant: not having any luck with those http URLs... maybe I need to re-do my setup or something [10:38] jtv: You've run make sync_branches? [10:38] yes [10:39] just says "not a branch" for every variant of the URL that I can think of [10:40] * wgrant tries. [10:40] doctormo, that looks sane to me. I'll bounce it off gary & leonard [10:41] doctormo, you're in US east coast, right? [10:41] jml: souns good [10:41] jml: In Boston, MA, yes [10:42] doctormo, cool. gary & leonardr are in the same tz, so hopefully after I talk to them you can avoid relying on someone on the other side of the atlantic :) [10:46] jml: Agreed. [10:47] jtv: Do you have anything in /var/tmp/bazaar.launchpad.net except for push-branches? [10:47] jml: hi [10:47] jelmer, hi [10:48] jml: "ec2 land" is reliably losing email for me while "ec2 test" seems to mail back without problems, do you have any idea what the cause of that might be ? [10:48] wgrant: a few things besides that... a log listing some bzr+ssh sessions, and directories config & mirrors [10:48] jelmer, no, sorry. I know that you aren't the only person to experience this behaviour though. [10:48] wgrant: config/launchpad-lookup.txt, which is empty [10:49] jml: ok, I'll see if I can find something. [10:49] wgrant: and mirrors/00/00/00/4d/.bzr [10:49] jtv: ps aux | grep rewrite [10:49] wgrant: not running [10:49] I bet your branch-rewrite.py is failing due to that PATH error. [10:49] (isn't aux bsd syntax?) [10:49] what PATH error? [10:49] jtv: shhh I've been using that for 9 years years. old habits, etc. [10:50] wgrant: just admit it, you picked it up while working on darwin [10:50] jtv: If you restart Apache, wait a few seconds, and check the error log you should see it. [10:50] jtv: I've not used OS X for more than half an hour, actually. [10:50] jelmer, thanks. [10:50] wgrant: "oh, it was _that_ long ago?" :) [10:50] jelmer, if you want to debug out loud, feel free to call me. [10:51] jml: ok - thanks [10:51] wgrant: indeed, a beautiful traceback mentioning PATH [10:52] jtv: If you see the PATH KeyError, remove the WindmillTestClient import from lib/lp/testing/__init__.py in the branch mentioned in the traceback. [10:52] Then restart Apache, wait a few seconds, and try the branch again. [10:52] wgrant: thanks... that's pretty horrible! [10:52] Yes. [10:52] I'm not sure if there's a bug. [10:53] wgrant: something's clearing PATH... that does have the ring of a bug to it [10:53] (And by the same token, how difficult is it to treat that as an empty string?) [10:53] Well, perhaps a better question is why WindmillTestClient is being imported there, and/or why it needs a PATH. [10:56] wgrant: a less invasive fix perhaps is to use os.environ.get('PATH', '') instead of os.environ['PATH']. Seems to work [10:58] jtv: Pfft. [10:58] Still doesn't work though. :( Internal server error. There's stuff in the apache error log, but nothing that looks like an error. [10:59] It's not trying to redirect to a non-running Loggerhead, is it? [10:59] jtv: for an ISE, check the loggerhead log file [11:00] is that in the branch or somewhere in /var/log? [11:01] jtv: It works for me after I comment Windmill imports out of two files. [11:01] wgrant: then I'll stop trying to be clever and just imitate. [11:01] jtv: Heh. [11:02] Morning, all. [11:02] jtv: Try killing the windmill.bin.admin_lib import from lib/canonical/testing/layers.py too. [11:02] * jtv looks for blunt instrument [11:09] hi deryck [11:13] wgrant: same result. :( [11:13] wgrant: yes, I did. [11:13] (I assume you were about to ask if I restarted apache) [11:14] wgrant: ah, I think I just edited in the wrong branch or something [11:14] I was, yes. [11:15] It's probably the last branch you ran 'make install' on, which is probably devel. [11:15] "trunk" in my case, but yes. [11:15] So I edited that, and still the same. :( [11:17] adeuring, I see you've take the doNotSnapshot-related OOPS card on the board... [11:17] deryck: yesß [11:17] Nothing in the error log a few seconds after restarting? [11:17] ...yes? [11:17] And branch-rewrite.py still not running? [11:17] adeuring, just a pointer that the notes when you open the card list multiple bugs needing this. [11:18] deryck: yes, I've seen two bugs [11:18] wgrant: branch-rewrite is running this time [11:18] wgrant: maybe it's this... ... waiting .Warning: DocumentRoot [/var/tmp/bazaar.launchpad.dev/static/] does not exist [11:19] adeuring, great, thanks. [11:19] jtv: That's unlikely. [11:19] jtv: What happens when you browse to the branch in a browser? [11:19] wgrant: with the http url? [11:19] jtv: And are you sure the branch exists in /var/tmp/bazaar.launchpad.dev/mirrors? [11:20] jtv: yeah. [11:20] (btw after I created that dir & restarted apache, I got a _new_ complaint about /var/tmp/ppa not existing) [11:20] adeuring, one may be a dupe of the other, but for some reason I kept the second open. I think the OOPS looked slightly different. [11:21] adeuring, if the second is a dupe, feel free to mark it so. [11:21] wgrant: visiting the branch http URL in a browser I get 404 [11:21] deryck: yes, I think it is worth to have a look at several properties, as sinzui notes in a comments on bug 505999 [11:21] Bug #505999: Unsubscribe OOPS [11:22] sigh, his comment is on bug 507642 [11:22] Bug #507642: "Does this bug affect you?" link produces error [11:22] adeuring, agreed. [11:23] jtv: You may find 'utilities/get-branch-info lp://dev/~path/to/branch' handy for working out paths. [11:24] wgrant: that gives me an https url though [11:24] (but thanks for the tip btw, nice to have) [11:24] jtv: That gives you an HTTPS path to the webapp, but it gives you filesystem paths to check. [11:24] wgrant: ah yes, and indeed that's what I had in /var/tmp [11:25] wgrant: seems I _can_ check out the branch from code.launchpad.dev! [11:26] jtv: But that should just redirect too bazaar.lp.d... [11:26] wgrant: the http redirects to https, but for a local test that's fine [11:26] actually, "https+urllib" not https [11:27] and if the message is to be believed, still on code not bazaar [11:27] Huh. [11:27] That should be impossible. [11:28] I've done something impossible already? Great, then my working day is done. :) [11:30] oh, my chroot is ready [11:31] What was your chroot doing? [11:32] setting up [11:32] I had that going as a background task === daniloff is now known as danilos [12:24] intellectronica, gmb -- everything should be landed for bug heat updating by now, right? [12:24] deryck: for updating, yes [12:24] is pqm open again? if so then i can also land my last branch for heat display [12:25] intellectronica, so I marked a malone bug as affecting me... that should trigger a job for setHeat, which should recalculate max_bug_heat, too. Is that right? [12:25] deryck: correct [12:26] intellectronica, hmmm, ok, so we may have a problem. still all gray icons on the hots bugs list. [12:27] bigjools: Any objections to moving BuildStatus and BuildQueue to lp.buildmaster? [12:27] intellectronica, and yes, pqm is open now. [12:27] deryck: is that because setHeat is not being called, or because max_heat is not set? [12:27] wgrant: no it's fine [12:27] intellectronica, max_bug_heat was not set, I assume. [12:27] consistency FTW [12:28] bigjools: I'm trying to get buildmaster's Soyuz dependencies under control, since at the moment it's more than a bit ugly. [12:28] intellectronica, but if setHeat wasn't called, max_bug_heat wouldn't be set, right? So it could be either. [12:28] deryck: exactly [12:28] wgrant: I can imagine [12:28] deryck: i'd bet on setHeat not called, because it would be hard to explain setHeat being called without recalculatMaxHeat being called at the end (without some error to account for that) [12:30] intellectronica, right. === salgado is now known as salgado-brb [12:31] intellectronica, let's check with gmb when he's available again and see if something obvious springs to his mind. [12:32] sure [12:35] meh. code homepage timed out [12:35] memcache anyone? [12:37] Isn't it now just a matter of adding the magic attribute, since the TALES branch landed a day or two ago? [12:37] wgrant: yup [12:37] Eeeexcellent. [12:38] (and if the problem is querying for both private-but-visible-to-user and public branches in the same query, of picking the right caching mode) [12:39] wgrant: how do I tell soyuz about the chroot tarball for an ubuntu release? [12:39] the manage-chroot script? [12:39] I guess there aren't any caches active on edge, though, since the caching on the front page doesn't reduce the query count. [12:40] jtv: scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 -f something.tar.bz2 add [12:40] wgrant: thanks [12:41] wgrant: I don't think we're using these new caches anywhere yet [12:41] jtv: The front page now caches a few sections. [12:41] wgrant: but the usual problem pattern isn't visible in query count; it's querying "where foo.private is false or is_visible_to(user, foo)" [12:41] oh cool [12:42] wgrant: oh wow, I think I've made a simulated slave accept a TranslationTemplatesBuildJob. [12:42] jtv: Checking out a branch and everything? [12:43] wgrant: patience, patience! I made it "accept" it. [12:43] Heh. === mrevell is now known as mrevell-lunch [12:43] wgrant: It went to Building and then Aborted, probably because of the things you already discovered with Henning [12:43] jtv: ... ABORTED? I hope it didn't end up there. [12:44] That should only happen when you call abort(). [12:44] wgrant: isn't that done for me when things fail horribly? [12:44] And even then, it's very unlikely to actually leave ABORTING, because it's buggy as hell. [12:45] ah, the ntp setup was lost somewhere along the line [12:45] Odd. [13:08] wgrant: got a whole lot of this documented... once we have it working and streamlined we can integrate it more. https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm [13:09] The page looks disappointingly short for the amount of BSW that went into it... [13:10] Sorry, BST [13:10] Blood, Sweat & Tears [13:11] jtv: What are you trying to do with buildd-queue-builder? [13:11] Whatever it is, you probably don't. [13:11] wgrant: oh [13:11] Then take that note as "I have to figure out what the right thing to do is, then do it." :-) [13:11] I'm trying to get soyuz to dispatch the job to the local slave. [13:12] buildd-manager will do that, and it's run by start-soyuz [13:12] I suppose I'll also want to register the slave with soyuz somehow [13:12] Yeah, probably. [13:12] Does your code create the appropriate BuildQueue entry for your job? [13:12] Also, if you merge devel buildd-manager's logging will magically NO LONGER SUCK! [13:13] So you'll be able to see what it does. [13:13] Yes, it creates a BuildQueue entry. [13:13] OK, so it should Just Work. [13:13] No need to register the slave? [13:13] Not if it's running on localhost:8221. [13:13] But check out https://launchpad.dev/builders, anyway. [13:13] What is the state of the virtualized flag on your BuildQueue? [13:14] oh! that's probably True, innit? [13:14] True or None are what you want. [13:14] I see a builder bob, and a disabled builder frog. [13:14] Right. [13:14] So... [13:14] Make bob virtualized. [13:14]