[00:37] <thumper> mwhudson: I checked out the brothers hotel, it looks really nice
[00:38] <thumper> mwhudson: nice rooms, wifi reaches and isn't charged for, no kids, breakfast included, only 15 rooms in the entire place
[00:38] <thumper> mwhudson: quiet, nice views
[00:38] <thumper> mwhudson: probably similar pricing to the southern cross
[00:38] <mwhudson> thumper: sounds good to me, do they have room for us?
[00:38] <thumper> mwhudson: yep
[00:39] <thumper> mwhudson: I've got him to book them already
[00:39] <thumper> mwhudson: I'm going to email flacoste and marianna with the details
[00:39] <mwhudson> thumper: nice
[00:39] <thumper> mwhudson: hopefully get sign off before the end of the week
[00:48] <thumper> mwhudson: email sent
[00:48] <thumper> mwhudson: fingers crossed for a quick approval
[01:36]  * mwhudson zooms into town for a short while
[01:37] <lifeless> zoom zoom zoom
[02:47] <thumper> mwhudson: https://blueprints.edge.launchpad.net/launchpad-code/+spec/personal-branch-url-change
[02:51] <thumper> mwhudson: https://blueprints.edge.launchpad.net/launchpad-code/+spec/code-import-watchdog, really deployment?
[02:57] <wgrant> thumper: Bazaar follows 403s? Do you mean 301s/302s?
[03:10] <mwhudson> that wasn't exactly a zoom :(
[03:12] <mwhudson> thumper: yes
[03:12] <mwhudson> oh, no
[03:12]  * mwhudson misunderstood blueprint statuses, how did i manage that
[03:32] <wgrant> Argh pagetitles.py.
[04:00] <thumper> wgrant: probably
[04:00] <thumper> wgrant: did you edit the page?
[04:02] <wgrant> thumper: No.
[04:16] <thumper> wgrant: I've edited the page now, thanks
[04:17] <wgrant> Great.
[04:41]  * wgrant points pointedly at the project reactivation request in #launchpad.
[04:43]  * thumper goes to make dinner
[04:47] <thumper> wgrant: thanks
[04:49] <lifeless> re the project reactivation request
[04:49] <lifeless> seems that folk misunderstand the 'registry' aspect of LP a lot
[04:49] <lifeless> 'shutting it down' because its in  LP doesn't make a lot of sense.
[04:50] <wgrant> LP misunderstands the Registry aspect of LP a lot.
[04:50] <lifeless> :P
[04:50] <lifeless> L:
[04:51] <wgrant> It doesn't handle placeholder projects well.
[04:51] <lifeless> ack. Have a tie fighter. or two. |-<>-| +-o-+
[04:52] <wgrant> /Now/ I'm confused.
[04:53] <lifeless> ;P
[05:09] <poolie> hi
[05:09] <poolie> mthaddon: in bug 534066 james_w says
[05:09] <mup> Bug #534066: can't update bugtask importance via api <api> <Launchpad Bugs:New> <https://launchpad.net/bugs/534066>
[05:09] <poolie> "OK, please ask a LOSA to check if all the edge appservers are on the same revision currently"
[05:09] <poolie> spm^^
[05:09] <poolie> could one of you do that please?
[05:10] <mthaddon> poolie: they are, yes (the same as lpnet/production)
[05:10] <poolie> k thanks
[05:11] <poolie> mthaddon: separately, re my recent tuolumne merge, michael said
[05:11] <poolie> the next step is setting up the datfiles (if they haven't been), graphs, and their associations.
[05:11] <poolie> could you tell me how to do that?
[06:10] <lifeless> 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] <poolie> yep, tom's helping me
[06:23] <poolie> lifeless: in case you're interested, a slightly old version was accidentally merged that didn't record them properly
[08:17] <adeuring> good morning
[08:33] <wgrant> noodles775: Morning.
[08:33] <noodles775> Hi wgrant!
[08:34] <wgrant> noodles775: Can you please have a look at bug #534216 and maybe give some suggestions?
[08:34] <noodles775> Suer.
[08:34] <noodles775> Sure.
[08:38] <noodles775> wgrant: pleasantly surprised that it's not a security bug :) So, +1 for the suggested breadcrumb urls, and regarding the second question,
[08:38] <wgrant> noodles775: I decided that you didn't need any more of them in one week. :)
[08:39] <noodles775> 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] <noodles775> heh.
[08:39] <wgrant> Right, it's not really important.
[08:39] <wgrant> And it's a rare case anyway.
[08:40] <noodles775> Yep, so +1 from me :).
[08:40] <wgrant> Great, thanks.
[08:40]  * wgrant quickly implements.
[08:42] <noodles775> wgrant: are you against there being a 'Packages for..." breadcrumb after the PPA title?
[08:42] <noodles775> (ie. look at the breadcrumb when you traverse to +packages)
[08:42] <wgrant> noodles775: Ah, yes, I thought about that earlier but it slipped my mind.
[08:42] <noodles775> Great.
[08:43] <wgrant> There should be, and probably a Builds breadcrumb as well. But that needs a custom hierarchy thingy.
[08:45] <noodles775> 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] <wgrant> Right, probably.
[09:07] <mrevell> Morning
[09:14] <jtv> hi mrevell
[09:15] <mrevell> hey there jtv
[09:15] <jtv> 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] <henninge> HowToUseSoyuzLocally
[09:17] <jtv> Oh, sorry
[09:23] <jtv> henninge: why all the trouble with the ntp IP address?  Doesn't pool.ntp.net work?
[09:27] <henninge> jtv: I just couldn't remember if I can put other host names into /etc/hosts ...
[09:27] <henninge> like: "pool.ntp.net  ntp.buildd"
[09:28] <wgrant> henninge: Or just edit /etc/launchpad-buildd/default
[09:28] <jtv> copy the ntp setup from the host?
[09:28] <jtv> I mean, we do ship with a workable default I suppose
[09:36] <noodles775> 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] <wgrant> noodles775: What happens when you try?
[09:36] <noodles775> wgrant: http://pastebin.ubuntu.com/390927/
[09:37] <wgrant> Um.
[09:37] <wgrant> What?
[09:37] <wgrant> That's not one I've seen before.
[09:37] <noodles775> Yeah, me either. That's after logging out and trying to log back in on r10429
[09:37]  * wgrant pulls.
[09:37] <noodles775> ah, maybe I should update my source deps...
[09:38] <noodles775> hrm, no that shoudl have been done by rf-get.
[09:40] <wgrant> noodles775: Note that update-sourcecode is broken in lucid.
[09:40] <wgrant> You need to change its interpret to the system Python.
[09:41] <noodles775> ah thanks wgrant.
[09:41] <wgrant> s/interpret/interpreter
[09:41] <adiroiban> 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] <wgrant> 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] <noodles775> 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] <wgrant> noodles775: OK, no problem.
[09:44] <wgrant> Thanks.
[09:44] <noodles775> wgrant: btw, I assume you can login/out fine on r10429?
[09:45] <wgrant> noodles775: Still updating/rebuilding.
[09:45] <noodles775> wgrant: ah, thanks.
[09:45] <noodles775> utilities/update-sourcecode appears to work fine here (on lucid).
[09:45] <wgrant> Hm, odd.
[09:46] <wgrant> It can't import bzrlib here, because it's running with 2.5 which is no longer in Lucid.
[09:47] <noodles775> Mine's getting it from lp-sourcedeps/eggs/bzr-2.1.0-py2.5-linux-x86_64.egg/bzrlib/__init__.pyc
[09:48] <henninge> wgrant, jtv: sorry, had a call
[09:50] <henninge> 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] <noodles775> adiroiban: that's kinda weird given that the project entries are sorted by displayname just a few lines above.
[09:53] <wgrant> henninge: Well, a config file is pretty close to the environment.
[09:53] <doctormo> jml: https://blueprints.launchpad.net/launchpad/+spec/launchpad-desktop
[09:53] <henninge> wgrant: yeah, I guess that's true.
[09:53] <noodles775> 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] <adiroiban> noodles775: ok. so this only happend on my computer?
[09:55] <jtv> 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] <adiroiban> noodles775: ok. so this only happens on my computer?
[09:55] <noodles775> adiroiban: the test passes here on r10429, but it looks spurious - sorting by both should ensure it will always work.
[09:56] <adiroiban> 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] <mup> Bug #531261: Move ISeriesMixin to lp.registry.interfaces.series <cleanup> <iseries> <tech-debt> <Launchpad Registry:In Progress by adiroiban> <https://launchpad.net/bugs/531261>
[09:56] <jtv> 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] <wgrant> jtv: What changes are there, apart from the NTP host?
[09:57] <noodles775> 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] <jtv> wgrant: whatever setup will be needed to check out a branch from the dev machine
[09:58] <wgrant> jtv: Hmm.
[09:58] <jtv> Can be done with ssh setup, but that requires your personal ssh key.  :/
[09:59] <jtv> Another way is to copy the branch into the chroot's fs, but that has to be done from the outside.
[09:59] <jtv> I guess it doesn't help for that.
[09:59] <jtv> So never mind.  :)
[09:59] <adiroiban> noodles775: well, I found it while working on that branch, but then I also tested with a fresh devel
[10:00] <noodles775> adiroiban: Right.
[10:01] <wgrant> bigjools: So, it turns out buildd-manager is really over-complicated...
[10:01] <bigjools> wgrant: turns out?  We've known that for ever :)
[10:02] <bigjools> if we had the time I'd re-write it
[10:02] <bigjools> but given the pain last time it was re-written, it would be hard
[10:03] <wgrant> 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] <bigjools> yes the dbnote stuff is utter crack
[10:03] <bigjools> was part of the original code, from 5 years ago
[10:04]  * bigjools -> otp
[10:05] <jml> mrevell, hi
[10:05] <mrevell> Hello Mr jml
[10:05] <doctormo> jml: Are you are awake!
[10:06] <wgrant> 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] <bigjools> buildmaster should mostly die
[10:07] <wgrant> Well, I got rid of all but master.py.
[10:07] <bigjools> \o/
[10:07] <wgrant> So only the twisted stuff lives outside the model.
[10:09]  * jml interested in wgrant & bigjools conversation
[10:09] <jml> doctormo, I am.
[10:11] <doctormo> jml: See link to blueprint and bug it's linked to
[10:11] <jtv> hey doctormo, สบายดีหมไ
[10:11] <wgrant> jml: Basically, buildd-manager scared me, so I deleted most of it.
[10:12] <jml> wgrant, destructive rampage is sometimes an appropriate response to fear.
[10:12] <doctormo> jtv: ก็ดี
[10:14] <jtv> doctormo: glad to see you haven't lost it :)
[10:15] <jtv> Where does the chroot go?  Arbitrary /tmp subdir?
[10:17] <jtv> wgrant, henninge?
[10:17] <wgrant> jtv: Doesn't matter.
[10:17] <henninge> jtv: which chroot?
[10:18] <henninge> pbuilder's goes into /var/cache/pbuilder/build/<buildno>
[10:18] <jtv> ah, thanks
[10:18] <wgrant> Oh, right, pbuilder.
[10:18] <henninge> jtv: but you can specify it on the command line for pbuilder
[10:18] <jtv> 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] <jtv> henninge: mind if I extend the instructions for that at some point, and pick a fixed location?
[10:19] <wgrant> jtv: There is a Makefile target to construct demo branches.
[10:19] <jtv> Makes it so much easier to write ready-to-go instructions.
[10:19] <wgrant> jtv: Can't you use that, then get the slave to check it out normally?
[10:19] <adiroiban> 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] <jtv> wgrant: I guess we could install the lp bzr plugin on the slave...
[10:20] <jtv> wgrant: creating the branch itself isn't the issue, but getting it onto the simulated slave.
[10:21] <wgrant> jtv: Your dev appserver must be able to generate direct HTTP URLs, or it could not resolve lp: URLs.
[10:21] <henninge> jtv: do you want to copy stuff into the chroot? Or why do you need the location?
[10:21] <wgrant> Therefore it can also pass HTTP URLs into the slave.
[10:21] <persia> 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] <henninge> adeuring: it's missing intltool
[10:21] <jtv> wgrant: it generates a direct http url, but that won't work on a dev system will it?
[10:21] <henninge> adiroiban: ^
[10:21] <henninge> adeuring: moin ;-)
[10:21] <wgrant> persia: This pbuilder is just to install the buildd code into on dev machines.
[10:21] <wgrant> jtv: It should for dev, but not for tests.
[10:22] <wgrant> In fact, yes, it does.
[10:22] <wgrant> because recipe builds work.
[10:22] <henninge> adiroiban: you need to install launchpad-developer-dependencies on the testing computer
[10:22] <wgrant> So HTTP access works fine.
[10:22] <jtv> wgrant, henninge: _running_ the buildd code on dev machines, right?
[10:22] <wgrant> jtv: Right.
[10:23] <adiroiban> henninge: thanks. I will do. I guess the package in installed, but not updated
[10:23] <persia> wgrant: But why pbuilder?  That just adds wider support.  schroot can handle tarballs, etc. just fine.
[10:23] <jtv> wgrant: can you show me an appropriate http url for dev access?  I tried before but couldn't make it work.
[10:23] <wgrant> persia: Don't ask me! I use schroot.
[10:23] <wgrant> jtv: http://bazaar.launchpad.net/~path/to/branch
[10:23] <wgrant> Er.
[10:23] <wgrant> s/net/dev/
[10:24] <persia> Who suggested pbuilder for this?  I'd like to disabuse them :)
[10:24] <jtv> hmm... that's what I thought didn't work earlier
[10:24] <henninge> persia: me, I simply don't know about schroot ...
[10:24] <henninge> wgrant: that's just the way I got it to run
[10:25] <henninge> I am not saying that that is a canonical way.
[10:26] <persia> 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] <wgrant> persia: Note that Soyuz's sbuild doesn't use schroot.
[10:27] <persia> wgrant: Yes, but not also using pbuilder makes the future alignment less painful :)
[10:27] <wgrant> persia: Potentially, yes.
[10:27] <henninge> persia: how do you build your chroot environment?
[10:28] <henninge> or, were do you get it from?
[10:28] <persia> `mk-sbuild lucid`
[10:28] <henninge> s/were/where/
[10:28] <henninge> oh, new in lucid?
[10:29] <henninge> persia: ^ ?
[10:29] <wgrant> mk-sbuild-lv has been around for a few releases, but I think mk-sbuild is reasonably new.
[10:29] <persia> For non-LVM use cases, yes.
[10:29] <persia> But the code ought to work in karmic, it just didn't get published then.
[10:38] <jtv> wgrant: not having any luck with those http URLs...  maybe I need to re-do my setup or something
[10:38] <wgrant> jtv: You've run make sync_branches?
[10:38] <jtv> yes
[10:39] <jtv> just says "not a branch" for every variant of the URL that I can think of
[10:40]  * wgrant tries.
[10:40] <jml> doctormo, that looks sane to me. I'll bounce it off gary & leonard
[10:41] <jml> doctormo, you're in US east coast, right?
[10:41] <doctormo> jml: souns good
[10:41] <doctormo> jml: In Boston, MA, yes
[10:42] <jml> 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] <doctormo> jml: Agreed.
[10:47] <wgrant> jtv: Do you have anything in /var/tmp/bazaar.launchpad.net except for push-branches?
[10:47] <jelmer> jml: hi
[10:47] <jml> jelmer, hi
[10:48] <jelmer> 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] <jtv> wgrant: a few things besides that... a log listing some bzr+ssh sessions, and directories config & mirrors
[10:48] <jml> jelmer, no, sorry. I know that you aren't the only person to experience this behaviour though.
[10:48] <jtv> wgrant: config/launchpad-lookup.txt, which is empty
[10:49] <jelmer> jml: ok, I'll see if I can find something.
[10:49] <jtv> wgrant: and mirrors/00/00/00/4d/.bzr
[10:49] <wgrant> jtv: ps aux | grep rewrite
[10:49] <jtv> wgrant: not running
[10:49] <wgrant> I bet your branch-rewrite.py is failing due to that PATH error.
[10:49] <jtv> (isn't aux bsd syntax?)
[10:49] <jtv> what PATH error?
[10:49] <wgrant> jtv: shhh I've been using that for 9 years years. old habits, etc.
[10:50] <jtv> wgrant: just admit it, you picked it up while working on darwin
[10:50] <wgrant> jtv: If you restart Apache, wait a few seconds, and check the error log you should see it.
[10:50] <wgrant> jtv: I've not used OS X for more than half an hour, actually.
[10:50] <jml> jelmer, thanks.
[10:50] <jtv> wgrant: "oh, it was _that_ long ago?"  :)
[10:50] <jml> jelmer, if you want to debug out loud, feel free to call me.
[10:51] <jelmer> jml: ok - thanks
[10:51] <jtv> wgrant: indeed, a beautiful traceback mentioning PATH
[10:52] <wgrant> 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] <wgrant> Then restart Apache, wait a few seconds, and try the branch again.
[10:52] <jtv> wgrant: thanks... that's pretty horrible!
[10:52] <wgrant> Yes.
[10:52] <wgrant> I'm not sure if there's a bug.
[10:53] <jtv> wgrant: something's clearing PATH... that does have the ring of a bug to it
[10:53] <jtv> (And by the same token, how difficult is it to treat that as an empty string?)
[10:53] <wgrant> Well, perhaps a better question is why WindmillTestClient is being imported there, and/or why it needs a PATH.
[10:56] <jtv> wgrant: a less invasive fix perhaps is to use os.environ.get('PATH', '') instead of os.environ['PATH'].  Seems to work
[10:58] <wgrant> jtv: Pfft.
[10:58] <jtv> 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] <wgrant> It's not trying to redirect to a non-running Loggerhead, is it?
[10:59] <lifeless> jtv: for an ISE, check the loggerhead log file
[11:00] <jtv> is that in the branch or somewhere in /var/log?
[11:01] <wgrant> jtv: It works for me after I comment Windmill imports out of two files.
[11:01] <jtv> wgrant: then I'll stop trying to be clever and just imitate.
[11:01] <wgrant> jtv: Heh.
[11:02] <deryck> Morning, all.
[11:02] <wgrant> 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] <jtv> hi deryck
[11:13] <jtv> wgrant: same result.  :(
[11:13] <jtv> wgrant: yes, I did.
[11:13] <jtv> (I assume you were about to ask if I restarted apache)
[11:14] <jtv> wgrant: ah, I think I just edited in the wrong branch or something
[11:14] <wgrant> I was, yes.
[11:15] <wgrant> It's probably the last branch you ran 'make install' on, which is probably devel.
[11:15] <jtv> "trunk" in my case, but yes.
[11:15] <jtv> So I edited that, and still the same.  :(
[11:17] <deryck> adeuring, I see you've take the doNotSnapshot-related OOPS card on the board...
[11:17] <adeuring> deryck: yesß
[11:17] <wgrant> Nothing in the error log a few seconds after restarting?
[11:17] <adeuring> ...yes?
[11:17] <wgrant> And branch-rewrite.py still not running?
[11:17] <deryck> adeuring, just a pointer that the notes when you open the card list multiple bugs needing this.
[11:18] <adeuring> deryck: yes, I've seen two bugs
[11:18] <jtv> wgrant: branch-rewrite is running this time
[11:18] <jtv> wgrant: maybe it's this...  ... waiting .Warning: DocumentRoot [/var/tmp/bazaar.launchpad.dev/static/] does not exist
[11:19] <deryck> adeuring, great, thanks.
[11:19] <wgrant> jtv: That's unlikely.
[11:19] <wgrant> jtv: What happens when you browse to the branch in a browser?
[11:19] <jtv> wgrant: with the http url?
[11:19] <wgrant> jtv: And are you sure the branch exists in /var/tmp/bazaar.launchpad.dev/mirrors?
[11:20] <wgrant> jtv: yeah.
[11:20] <jtv> (btw after I created that dir & restarted apache, I got a _new_ complaint about /var/tmp/ppa not existing)
[11:20] <deryck> 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] <deryck> adeuring, if the second is a dupe, feel free to mark it so.
[11:21] <jtv> wgrant: visiting the branch http URL in a browser I get 404
[11:21] <adeuring> 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] <mup> Bug #505999: Unsubscribe OOPS <oops> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/505999>
[11:22] <adeuring> sigh, his comment is on bug 507642
[11:22] <mup> Bug #507642: "Does this bug affect you?" link produces error <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/507642>
[11:22] <deryck> adeuring, agreed.
[11:23] <wgrant> jtv: You may find 'utilities/get-branch-info lp://dev/~path/to/branch' handy for working out paths.
[11:24] <jtv> wgrant: that gives me an https url though
[11:24] <jtv> (but thanks for the tip btw, nice to have)
[11:24] <wgrant> jtv: That gives you an HTTPS path to the webapp, but it gives you filesystem paths to check.
[11:24] <jtv> wgrant: ah yes, and indeed that's what I had in /var/tmp
[11:25] <jtv> wgrant: seems I _can_ check out the branch from code.launchpad.dev!
[11:26] <wgrant> jtv: But that should just redirect too bazaar.lp.d...
[11:26] <jtv> wgrant: the http redirects to https, but for a local test that's fine
[11:26] <jtv> actually, "https+urllib" not https
[11:27] <jtv> and if the message is to be believed, still on code not bazaar
[11:27] <wgrant> Huh.
[11:27] <wgrant> That should be impossible.
[11:28] <jtv> I've done something impossible already?  Great, then my working day is done.  :)
[11:30] <jtv> oh, my chroot is ready
[11:31] <wgrant> What was your chroot doing?
[11:32] <jtv> setting up
[11:32] <jtv> I had that going as a background task
[12:24] <deryck> intellectronica, gmb -- everything should be landed for bug heat updating by now, right?
[12:24] <intellectronica> deryck: for updating, yes
[12:24] <intellectronica> is pqm open again? if so then i can also land my last branch for heat display
[12:25] <deryck> 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] <intellectronica> deryck: correct
[12:26] <deryck> intellectronica, hmmm, ok, so we may have a problem.  still all gray icons on the hots bugs list.
[12:27] <wgrant> bigjools: Any objections to moving BuildStatus and BuildQueue to lp.buildmaster?
[12:27] <deryck> intellectronica, and yes, pqm is open now.
[12:27] <intellectronica> deryck: is that because setHeat is not being called, or because max_heat is not set?
[12:27] <bigjools> wgrant: no it's fine
[12:27] <deryck> intellectronica, max_bug_heat was not set, I assume.
[12:27] <bigjools> consistency FTW
[12:28] <wgrant> 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] <deryck> intellectronica, but if setHeat wasn't called, max_bug_heat wouldn't be set, right?  So it could be either.
[12:28] <intellectronica> deryck: exactly
[12:28] <bigjools> wgrant: I can imagine
[12:28] <intellectronica> 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] <deryck> intellectronica, right.
[12:31] <deryck> intellectronica, let's check with gmb when he's available again and see if something obvious springs to his mind.
[12:32] <intellectronica> sure
[12:35] <jml> meh. code homepage timed out
[12:35] <jml> memcache anyone?
[12:37] <wgrant> Isn't it now just a matter of adding the magic attribute, since the TALES branch landed a day or two ago?
[12:37] <jtv> wgrant: yup
[12:37] <wgrant> Eeeexcellent.
[12:38] <jtv> (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] <jtv> wgrant: how do I tell soyuz about the chroot tarball for an ubuntu release?
[12:39] <jtv> the manage-chroot script?
[12:39] <wgrant> 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] <wgrant> jtv: scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 -f something.tar.bz2 add
[12:40] <jtv> wgrant: thanks
[12:41] <jtv> wgrant: I don't think we're using these new caches anywhere yet
[12:41] <wgrant> jtv: The front page now caches a few sections.
[12:41] <jtv> 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] <jtv> oh cool
[12:42] <jtv> wgrant: oh wow, I think I've made a simulated slave accept a TranslationTemplatesBuildJob.
[12:42] <wgrant> jtv: Checking out a branch and everything?
[12:43] <jtv> wgrant: patience, patience!  I made it "accept" it.
[12:43] <wgrant> Heh.
[12:43] <jtv> wgrant: It went to Building and then Aborted, probably because of the things you already discovered with Henning
[12:43] <wgrant> jtv: ... ABORTED? I hope it didn't end up there.
[12:44] <wgrant> That should only happen when you call abort().
[12:44] <jtv> wgrant: isn't that done for me when things fail horribly?
[12:44] <wgrant> And even then, it's very unlikely to actually leave ABORTING, because it's buggy as hell.
[12:45] <jtv> ah, the ntp setup was lost somewhere along the line
[12:45] <wgrant> Odd.
[13:08] <jtv> 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] <jtv> The page looks disappointingly short for the amount of BSW that went into it...
[13:10] <jtv> Sorry, BST
[13:10] <jtv> Blood, Sweat & Tears
[13:11] <wgrant> jtv: What are you trying to do with buildd-queue-builder?
[13:11] <wgrant> Whatever it is, you probably don't.
[13:11] <jtv> wgrant: oh
[13:11] <jtv> Then take that note as "I have to figure out what the right thing to do is, then do it."  :-)
[13:11] <jtv> I'm trying to get soyuz to dispatch the job to the local slave.
[13:12] <wgrant> buildd-manager will do that, and it's run by start-soyuz
[13:12] <jtv> I suppose I'll also want to register the slave with soyuz somehow
[13:12] <wgrant> Yeah, probably.
[13:12] <wgrant> Does your code create the appropriate BuildQueue entry for your job?
[13:12] <wgrant> Also, if you merge devel buildd-manager's logging will magically NO LONGER SUCK!
[13:13] <wgrant> So you'll be able to see what it does.
[13:13] <jtv> Yes, it creates a BuildQueue entry.
[13:13] <wgrant> OK, so it should Just Work.
[13:13] <jtv> No need to register the slave?
[13:13] <wgrant> Not if it's running on localhost:8221.
[13:13] <wgrant> But check out https://launchpad.dev/builders, anyway.
[13:13] <wgrant> What is the state of the virtualized flag on your BuildQueue?
[13:14] <jtv> oh!  that's probably True, innit?
[13:14] <wgrant> True or None are what you want.
[13:14] <jtv> I see a builder bob, and a disabled builder frog.
[13:14] <wgrant> Right.
[13:14] <wgrant> So...
[13:14] <wgrant> Make bob virtualized.
[13:14] <wgrant> By clicking the Virtualized checkbox, and entering anything at all into the PPA host box thingy.
[13:14] <wgrant> And the build might start.
[13:15] <jtv> BuildQueue.virtualized is null; there's also a "manual" flag there
[13:15] <wgrant> (frog is on localhost:9221 and disabled, so buildd-manager won't be touching it)
[13:15] <wgrant> Ignore the manual flag.
[13:15]  * jtv tries
[13:17] <jtv> ...and documents
[13:18] <jtv> wgrant: leave Bob active?
[13:19] <wgrant> jtv: If you disable it then you'll have no active builders, which is probably counterproductive.
[13:19] <jtv> wgrant: Done.  I still see only the two builders.
[13:20] <wgrant> jtv: Why would there be more?
[13:20] <wgrant> You just adjusted bob to meet your needs.
[13:20] <jtv> wgrant: oh, our local slave is going to _be_ Bob?
[13:20] <wgrant> jtv: Yes.
[13:20] <wgrant> bob is the primary local slave. frog is the secondary one that doesn't normally exist.
[13:21] <jtv> Okay... but bob says it's building firefox-0.9 for hoary.
[13:21] <wgrant> Well, that's pretty stupid of it.
[13:21] <wgrant> Flip the OK checkbox off for 10 seconds.
[13:21] <wgrant> That should fix that.
[13:26] <jtv> You'd think that after a few years of attempted build, it'd get the hint.
[13:27] <jtv> wgrant: bob is idle
[13:27] <gmb> intellectronica, deryck: You rang m'luds?
[13:27] <deryck> gmb, yeah, not sure bug heat is updating as it should...
[13:27] <jtv> danilos, henninge: pieces of the puzzle are coming together on https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm
[13:27] <wgrant> jtv: If you flip it back to OK, does it then start working?
[13:27] <jtv> wgrant: that's after flipping it back to OK.
[13:28] <danilos> jtv, woohooo, ready for me to try it out already? :)
[13:28] <jtv> danilos: patience.
[13:28] <deryck> gmb, I marked myself affected by a bug, expecting a job to be created, setHeat to be run, max_bug_heat to be updated...
[13:28] <danilos> jtv, heh, ok, ok
[13:28] <wgrant> jtv: Grrr. Merge devel, restart buildd-manager, and watch the logs.
[13:28] <deryck> gmb, yet the flames icons are all gray still.
[13:28] <gmb> deryck: Okay, have you checked with a LOSA to see if a job was created?
[13:29] <deryck> gmb, no.  I can do that.  would it still be hanging around some 60 minutes later now to confirm?
[13:29] <jtv> danilos: the page looks brief but plenty of effort went in (I probably removed more text from manual steps that I automated)
[13:29] <gmb> deryck: I don't know. I'll walk through the process myself and have a LOSA query while I go.
[13:29] <deryck> gmb, excellent.  thanks!
[13:31] <jtv> wgrant: I think my bzr got swapped out...  Slow as molasses :)
[13:31] <wgrant> jtv: Yeah, that happens :(
[13:31] <wgrant> Particularly with eCryptFS.
[13:31] <wgrant> And lots of Soyuz services.
[13:31] <wgrant> And a slave VM or two.
[13:31] <jtv> and criss-cross merges on devel
[13:31] <wgrant> Urgh.
[13:33] <jtv> stupid thing is, this should be an unmodified devel branch
[13:39] <gmb> deryck: So, weirdly enough it looks like jobs aren't getting created. I just subscribed to bug 373683 but the oldest job in the DB is from the 5th. Lemme take a look at the source, see if I can figure out what's happening.
[13:39] <wgrant> jtv: Any luck?
[13:43] <deryck> gmb, thanks for looking into this
[13:43] <gmb> np
[13:45] <kfogel> deryck: I'd like to convert bug #345577 into a bidirectional "patch<->branch" equivalence bug.  Is that kind of expansion generally okay to do?
[13:45] <mup> Bug #345577: Patches should be made into Bazaar branches <bug-branch-links> <code-review> <feature> <patch-tracking> <Launchpad Bazaar Integration:Triaged> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/345577>
[13:45] <wgrant> noodles775: I'm glad we elected to not move BuildStatus when we created BuildBase during the sprint... just changing all the imports is a 1500 line diff.
[13:45] <deryck> kfogel, yup
[13:45] <kfogel> deryck: cool
[13:56] <wgrant> jtv: Why do you run both upload2librarian and manage-chroot? The latter does the former.
[13:57] <jml> kfogel, I think it's ok to do, but I'm curious -- why do you want to do it?
[13:57] <kfogel> jml: because I feel that the equivalence is bidirectional, and this is the only bug in our database about it, so it should reflect that.
[13:58] <kfogel> (rather than create a new bug for the other direction)
[13:58] <jtv> wgrant: I just added the manage-chroot to an existing page...  but I think the URL is also needed further down on that page.
[13:58] <jml> kfogel, what would that mean in terms of user-visible behaviour?
[13:59] <kfogel> jml: oh, btw, when I see the "
[13:59] <kfogel> Updating branch...
[13:59] <kfogel> Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes." message in the Launchpad web UI, that's irrelevant for ec2 / pqm, right?
[13:59] <jml> kfogel, ummm.... I don't know, sorry.
[13:59] <jml> kfogel, If they are reading the branch over SSH as someone who has write access, then yes it's irrelevant.
[14:00] <kfogel> jml: what it would mean (I'm updating the desc to say this) is that also if someone links a branch to a bug, that it would be possible to get that branch in patch form, via the web UI without having to have bzr installed locally.
[14:00] <intellectronica> kfogel: patches and branches aren't really equivalent, because patches lack the context for applying them. in practice, that makes them a lot less useful, and there's a lot less we can say about them with certainty.
[14:01] <persia> Are chroots in Soyuz always .bz2 compressed?
[14:01] <jml> kfogel, that sounds like a good thing, although maybe less desirable than the other way around
[14:01] <kfogel> intellectronica: uhm.  Two things: one, I'm not completely sure that assertion is true in ways that are important here, but two, even if it were, the directionality in which it is important is the one already covered by the bug.  That is, the direction I'm adding (branch->patch) is the one where we *definitely* have enough information to make the transition.
[14:01] <wgrant> persia: I think so.
[14:02] <kfogel> jml: for an upstream dev it could be hugely important.  Now someone else makes a bzr branch against your code, and you can get it in a form you can actually use.
[14:02] <persia> wgrant: Thanks.  I'll make that assumption in my code then.
[14:02] <kfogel> (if you're not a bzr user)
[14:02] <wgrant> persia: The buildd assumes that they are.
[14:02] <intellectronica> kfogel: good point
[14:02] <wgrant> persia: I really do not know why, but it bunzip2s the tarball before it untars it.
[14:03] <kfogel> intellectronica: Also, I never thought I'd be standing here tonight, holding this little golden guy, and I'd like to thank all my teammates, and my mom and my dad, and especially Tom Berger for teaching me everything I know about JavaScript code with YUI.
[14:03] <wgrant> Looks like they could also be uncompressed, but they never are in practice.
[14:03] <kfogel> intellectronica: ooops, sorry, wires crossed -- was up too late last night.
[14:03] <jml> kfogel, in that case, we'd probably want something a bit richer than patches for git & hg upstreams
[14:03] <kfogel> jml: yes, that's part of the (blue-sky section of the) proposal :-).
[14:03] <persia> wgrant: Autodetection of internal compression mechanism is relatively new (and may not have sunk into all developers heads)
[14:03] <jml> kfogel, :)
[14:03] <intellectronica> heh :)
[14:04] <wgrant> persia: I guess this code is 5 years old, too.
[14:04] <persia> I forget if that predates autodetection, but yeah.
[14:07] <ricotz> Are there currently known problems with translation importing on launchpad?
[14:07] <danilos> ricotz, not that I know of
[14:07] <wgrant> jml: Will bug #534391 be fixed if an extra breadcrumb for the build is added, so the PPA breadcrumb becomes a link again?
[14:08] <mup> Bug #534391: Build failure page for PPA has no link to PPA page <Soyuz:New> <https://launchpad.net/bugs/534391>
[14:08] <danilos> ricotz, though, this is probably better asked in #launchpad (this channel is for development discussion)
[14:08] <danilos> ricotz, I'd be happy to help diagnose the problem for you on #launchpad :)
[14:08] <ricotz> danilos, ok
[14:10] <jml> wgrant, I guess.
[14:10] <wgrant> jml: Because I have a branch awaiting review that does just that.
[14:10] <jml> wgrant, kaching!
[14:11] <wgrant> Also, I've just noticed there is a link to the PPA on that page -- the top of the right column.
[14:12] <jml> wgrant, oh I see.
[14:12] <jml> wgrant, that's not a good place for a link, I feel.
[14:18] <noodles775> wgrant: heh, sounds like the recent trivial fix I did to ensure the privacy of PPA's can't be switched once it's got publishings. 100line diff for the fix and 4.5k diff in total.
[14:18] <wgrant> noodles775: Yeah, I saw that. Ouch...
[14:20] <gmb> deryck: So, I'm going to go and write some tests to try and reproduce this; all of my testing so far suggests that subscribing or marking yourself as affected should create a job.
[14:21] <deryck> gmb, ok.
[14:25] <jml> sinzui, btw, I love the "Launchpad doesn't know which packages" thing on the package overview page! (just saw https://edge.launchpad.net/pino)
[14:27] <jml> sinzui, I reckon the copy could do with a bit of tweaking, but otherwise it's very much what I hoped for.
[14:28] <jelmer> jml: ooh, that is very neat indeed
[14:28] <jml> sinzui, I guess it could also be more ajaxy too.
[14:29] <wgrant> Can I tell that section to go away?
[14:29] <wgrant> Lots of projects will probably never be packaged.
[14:32] <sinzui> jml:We decided to postpone ajax for that feature until the core features were landed. Like its counter part on sourcepackages, the entire portlet could be an ajax call.
[14:33] <jml> sinzui, that's a sound plan.
[14:36] <aolmedo> hi, it's aolmedo from libresoft.es (spain)
[14:44] <mrevell> Hi aolmedo
[14:57] <allenap> abentley: I've just figured out the running-tests-in-a-subprocess issue you helped me with last week. The zope.testing TestResult object does layer setup and teardown if you can believe it, so replacing it with a non-Zope TestResult (i.e. subunit.TestProtocolClient) causes things to break a lot.
[14:58] <allenap> abentley: I've worked around it using MultiTestResult for now.
[14:58] <abentley> allenap, aha!  I'm glad you figured it out.
[14:59] <bigjools> jml: dude, you don't look very hard to find links
[15:00] <jml> bigjools, why should I have to look hard?
[15:00] <bigjools> jml: well you don't :)
[15:00] <bigjools> that's the point
[15:00] <abentley> allenap, so why were you converting that test anyhow?
[15:01] <jml> allenap, oh, I knew that. sorry I didn't actually think to help you with it.
[15:01] <allenap> abentley: Because it was hanging when run in the same test run as one of my tests; both start the Twisted reactor.
[15:02] <abentley> allenap, but as long as they both *stop* the twisted reactor, that shouldn't be a problem, right?
[15:02] <allenap> jml: Hehe :) Oh well, I learnt a lot, and I don't have much hair left to tear out anyway :)
[15:02] <jml> allenap, you might find https://code.edge.launchpad.net/~jml/zope.testing/subunit-output-formatter/+merge/19825 interesting
[15:03] <allenap> abentley: They do, but for some reason they were not happy. I never figured that out. jml said that, in general, starting and stopping the reactor is not supported, so I just focused on running tests that need the reactor in a subprocess.
[15:03] <abentley> jml, could you clarify?
[15:04] <jml> abentley, starting the reactor after stopping it in the same process is not supported and expected to break. I don't know the details off-hand.
[15:04] <abentley> jml, and this applies to any process that uses the reactor, not just Launchpad?
[15:05] <jml> abentley, that's correct.
[15:05] <jml> it's a deficiency of Twisted.
[15:06] <henninge> jtv: you sounded like you were doing some investigating, too. Any useful information before your eod?
[15:06] <jtv> henninge: I'm not eod, I'm still otp
[15:07]  * henninge can't find a funny tla to respond .... ;)
[15:07] <abentley> jml, I'm surprised that doesn't come up more often.  Back when we were talking about using Twisted in bzr, there was talk about converting async operations into synchronous ones, and I always assumed it would involve starting and stopping the reactor.
[15:07] <jml> abentley, yes it would involve that.
[15:08] <jml> abentley, trial gets around this by faking reactor start and stop in a really really horrible way that no one should ever use.
[15:08] <jml> abentley, the Twisted community AIUI generally agrees that they should be restartable, but no one is interested in working on it right now.
[15:09] <allenap> jml: Ah, so I could introduce a new layer that raises NotImplementedError in tearDown() for use with reactor tests?
[15:09] <jml> allenap, maaaaaaaaaybe.
[15:09] <abentley> allenap, thank you for correcting my oversight.
[15:09] <allenap> abentley: Perhaps I should have told you why I was pursuing this earlier :)
[15:09] <jml> allenap, I mean, I don't know what "reactor tests" means here.
[15:10] <jml> allenap, we already have tests in the launchpad suite that subclass trial's TestCase and return Deferreds.
[15:10] <allenap> jml: I mean anything that needs to start the reactor.
[15:10] <jml> allenap, what sort of code do you have that calls reactor.start()?
[15:10] <jml> .run
[15:10] <jml> dammit
[15:12] <james_w> one of my branches got somehow un-merged, how could that have happened?
[15:12] <allenap> jml: Some tests for checkwatches; I want to <insert correct xunit term here> out lots of the actual networking stuff, but run the whole shebang up.
[15:14] <jml> allenap, ok.
[15:15] <abentley> jml, my test that runs a reactor is testing TwistedJobRunner, which itself starts and stops the reactor.
[15:16] <jml> abentley, may I see the code?
[15:17] <abentley> jml, of course.  lib/lp/services/job/runner.py
[15:20] <jml> abentley, the idea of TwistedJobRunner is that it presents a synchronous interface?
[15:20] <abentley> jml, yes.
[15:21] <jml> abentley, ok.
[15:23] <jml> abentley, could you test it by making 'reactor' a parameter to the constructor and providing a reactor that logs calls to key methods?
[15:23] <jml> abentley, also, if I read the code aright, the reactor will spin forever if there's an exception raised in doConsumer
[15:24] <jml> abentley, wait, I don't read it aright.
[15:24] <abentley> jml, I don't think I care whether calls any particular methods on the reactor.
[15:24] <jml> abentley, then what do you care about?
[15:25] <abentley> jml, I care whether it runs the jobs and kills them if they take too long.
[15:26] <jml> abentley, you can test that by calling runAll from a trial testcase if you make runAll return 'd'.
[15:27] <jml> my DNS is playing up :(
[15:27] <abentley> jml, you mean instead of running the reactor?
[15:27] <jml> abentley, yes.
[15:28] <jml> abentley, you'd also need to change terminated to not call reactor.stop itself.
[15:28] <abentley> jml, I think I'd rather care less about the guts.
[15:29] <abentley> And more about ensuring that it provides the same API as the synchronous runner.
[15:29] <jml> abentley, in which case, subprocesses.
[15:30] <abentley> jml, i.e. what allenap has done.
[15:30] <jml> yeah.
[15:30] <allenap> jml: Ah, the tearDown() idea doesn't work; Zope doesn't spawn a new process after each test case, just at the end.
[15:30] <jml> allenap, testTearDown raising NotImplementedError then?
[15:31] <jml> abentley, I think it would be useful to provide an interface that behaves more like regular Twisted code, but that's a separate issue.
[15:36] <james_w> no-one has any suggestions?
[15:37] <james_w> it could be that a bunch of fixes were just removed in the last week
[15:42] <deryck> gah!  freakin' task age.
[15:43] <deryck> james_w, is that what you're asking about?
[15:43] <james_w> yeah
[15:43] <james_w> I had a branch merged, and all was fine on edge again
[15:43] <intellectronica> this is very very weird
[15:43] <james_w> then some time in the last week (rollout?) the fix went away
[15:43] <deryck> james_w, I suspect it was conflict resolution that caused this.  Someone likely being conservative, thinking it should be in there.
[15:44] <deryck> unless we submitted to production-devel without going through devel?  intellectronica ?
[15:45] <james_w> pretty sure it was devel
[15:45] <intellectronica> no, this definitely was on devel
[15:47] <deryck> oh, well.  I groan inwardly, but at this point we should just get it landed again. intellectronica, do you mind landing it and asking for a CP again?
[15:47] <intellectronica> deryck: of course
[15:47] <deryck> intellectronica, many thanks.  and james_w, thanks for the debugging help.
[15:47] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/kill-task_age/+merge/18418
[15:48] <deryck> james_w, I'm assigning the bug to you again, just so you get the karma you're due. :-)
[15:48] <james_w> heh
[15:49] <deryck> I linked the old branch for reference, but I assume intellectronica will propose another version of the branch for re-submitting.
[15:50] <deryck> intellectronica, in fact, rs=deryck on the same branch to devel.  then ask flacoste for the CP approval.
[15:51] <jml> :(
[15:51] <jml> internet is bad.
[15:51] <allenap> jml: NotImplementedError in testTearDown() just breaks :( I will continue on the subunit+testtools path I think. That's working now; I just need to make it pretty.
[15:51] <jml> ok.
[15:52] <jml> allenap, fwiw, I'm working on a patch that'll give zope.testing native support for subunit.
[15:52] <jml> allenap, it's 90% done, with only 90% to go.
[15:53] <allenap> jml: Hehe :) That sounds cool :)
[15:53] <jml> allenap, the second 90% includes actually reading lifeless's comments, responding to them and then navigating through whatever junk I need to in order to get it landed.
[16:04] <james_w> deryck: yes, it appears to have been reverted in "Merging db-stable"
[16:10] <intellectronica> james_w: i don't understand why. bzr should be able to recognize it.
[16:11]  * kfogel is away: reboot
[16:11] <intellectronica> unless some had a conflict involving these lines
[16:18] <jtv> abentley: another thing I've been meaning to ask you... on my dev system, I can check out branches from http://code.launchpad.dev/ but not from http://bazaar.launchpad.dev/
[16:18] <jtv> abentley: is that normal?  Because if so, we ought to fix composePublicURL for it
[16:21] <deryck> james_w, thanks for checking into it further.  yeah, intellectronica, I recall adeuring and maybe someone else having to do manual conflict resolution once or twice the last week.
[16:21] <abentley> jtv, no, it's not normal.
[16:21] <mramirez> hi
[16:27] <james_w> deryck: should we just delete task_age, I didn't realise it was created purely to be exported?
[16:28] <deryck> james_w, yes, we should, especially since we have to re-land anyway.
[16:29] <james_w> hmm
[16:29] <james_w> doesn't seem to have been conflict resolution
[16:30] <james_w> seems like bzr decided that the older code should win
[16:30] <james_w> right
[16:31] <james_w> the maze of branches meant that the merge from db-stable just has the export winning
[16:35] <intellectronica> interesting
[16:36] <intellectronica> james_w:  that's something we should write to the list about
[16:36] <intellectronica> i'm happy to do that, but it looks like you might have more to say about the bzr side of things
[16:41] <james_w> right
[16:41] <james_w> except I've just confused myself more
[16:41] <james_w> I was looking at the merge back, not at the devel->db-stable merge
[16:42] <james_w> which is where the issue likely is
[17:39] <allenap> jml, abentley: Here's my (working) solution to running individual tests in sub-processes (using subunit): http://paste.ubuntu.com/391187/
[17:40]  * allenap will be back in 3 hours.
[18:00]  * gary-lunch wants to know if https://bugs.edge.launchpad.net/launchpad-foundations/+bug/534399 is an annoyance or a critical problem.  He welcomes input, though responses may wait till after he returns from lunch.
[18:00] <mup> Bug #534399: Windmill breaks branch-rewrite on dev systems <Launchpad Foundations:New> <https://launchpad.net/bugs/534399>
[18:00] <gary-lunch> jtv: ^^^
[18:00] <mrevell> night
[18:02] <jtv> gary-lunch: doesn't affect production, but breaks manual testing.  So a major annoyance for a small group of developers.
[18:47] <jml> g'night folks
[18:56] <gary_poster> OK thanks jtv
[19:19] <mwhudson> morning
[19:34] <sinzui> Ursinha: why is you or your script changing the qa state of the work I QAed?
[19:35] <Ursinha> sinzui: I put it to do a full run and as a default behavior it removes all qa tags if any and adds the qa-needstesting one
[19:35] <Ursinha> sinzui: I've fixed all of them already
[19:36] <Ursinha> sinzui: sorry for the noise, shouldn't happen again
[19:37] <Ursinha> sinzui: just let the script add the qa-needstesting tag and it should be fine when you change to qa-ok
[19:37] <sinzui> okay one pug has not passed QA. I see that it is still in needs testing so we will continue looking at a timeout oops that relates to it
[19:38] <Ursinha> sinzui: you can add the qa-bad then and when the script detects a new commit with the fix it should change back to qa-needstesting again
[19:38] <Ursinha> sinzui: I'm writing the docs and should mail the list soon explaining how it works
[19:38] <sinzui> Well, the I will do that now
[19:38] <Ursinha> sinzui: don't mark it as qa-needstesting, but as qa-bad, please :)
[19:39] <Ursinha> sinzui: the script checks if the fix is already in staging or edge and then marks the bug as QAable, with the qa-needstesting tag
[19:40] <sinzui> EdwinGrubbs: bug 512408
[19:40] <mup> Bug #512408: Project page could suggest unlinked source packages <qa-bad> <Launchpad Registry:Fix Committed by bac> <https://launchpad.net/bugs/512408>
[19:43] <Ursinha> thanks sinzui
[20:19] <gary_poster> beuno: ping?
[20:19] <beuno> gary_poster, pong
[20:20] <gary_poster> hey beuno.  Do you know of any research that says what a minimally acceptable time to interact for a web page is, from a usability perspective?
[20:21] <beuno> gary_poster, that's a big "it depends"
[20:21] <beuno> is this load time?
[20:21] <gary_poster> beuno: yeah, ish.  Time before you can use the page.
[20:24] <beuno> gary_poster, off the top of my head, under 2 seconds
[20:24] <beuno> I'll look up research once I finish bashing this javascript into complianhce
[20:24] <gary_poster> beuno: awesome thank you that would be great
[20:28] <wgrant> Can somebody please land lp:~wgrant/launchpad/fix-soyuz-build-and-queue-titles and lp:~wgrant/launchpad/buildqueue-to-buildmaster? They both passed EC2 three hours ago except for buildd-slavescanner.txt which was testfixed in devel overnight.
[20:36] <beuno> gary_poster, http://www.useit.com/papers/responsetime.html
[20:36] <beuno> is one of them
[20:37] <gary_poster> beuno: ah, awesome, that sounds perfect. looking.
[20:38] <beuno> gary_poster, the numbers change slightly depending on the audience
[20:38] <beuno> and the task they're trying to achieve
[20:38] <beuno> 2 seconds seemed to be acceptable for web apps that users wanted/needed to use, and where familiar with
[20:41] <lifeless> beuno: ugh
[20:41] <lifeless> 2 seconds is enough to switch, read an email, and return.
[20:41] <beuno> lifeless, total time?  from click to render?
[20:42] <beuno> very few websites give you 2 seconds
[20:44] <wgrant> Ooh. It has improved. Only 6 seconds now to load a new bug with another bug page recently loaded, and 4 of those seconds were SQL time. That isn't actually too bad.
[20:46] <wgrant> Can somebody please pqm-submit those above branches? I have another 5 or so dependent on them to get reviewed in the next day or two, so it would be nice to have these merged.
[21:07] <mwhudson> jelmer: can you remember if there's a bug already about sharing revisions between related imports?
[21:10] <wgrant> mwhudson: Do you guys notice when only one import machine needs a cert accepted?
[21:10] <wgrant> Since I guess that won't often trigger suspension.
[21:10] <mwhudson> wgrant: not automatically no :/
[21:10] <mwhudson> galapagos got reinstalled a few months back and lost all it's certs
[21:10] <mwhudson> -'
[21:10] <wgrant> Ah. Yuck.
[21:11] <wgrant> It doesn't know about the one for https://code.edge.launchpad.net/~vcs-imports/iptables/main.
[21:11] <mwhudson> there are some crappy shell scripts somewhere to smear the certs around the various machines
[21:11] <mwhudson> it would be really nice to fix this properly i guess, i just have no idea how
[21:12] <mwhudson> (well, apart from turning all the branches into bzr-svn branches)
[21:12] <wgrant> Get people to use non-crappy certs!
[21:16] <intellectronica> wgrant: morning
[21:17] <intellectronica> wgrant: i sent you some errors i got when running your branch through ec2, but i think they are actually unrelated errors that have since been fixed. if you merge the latest from devel i'll resubmit it.
[21:17] <wgrant> intellectronica: Ah, you're still around. Great.
[21:17]  * wgrant merges.
[21:17] <intellectronica> wgrant: also, sorry, but eventually i didn't get to review your mega branch. it's been a busy day.
[21:17] <wgrant> intellectronica: No problem, I'll find someone else to do it tonight.
[21:21] <wgrant> intellectronica: OK, merged and pushed (r9083)
[21:21] <wgrant> intellectronica: Can you also re-land lp:~wgrant/launchpad/fix-soyuz-build-and-queue-titles? henninge tried to do it last night, but failed the same way.
[21:21] <intellectronica> wgrant: cool. resubmitted
[21:21] <wgrant> intellectronica: Thanks.
[21:21] <intellectronica> wgrant: sure
[21:32] <jelmer> mwhudson: moin
[21:32] <jelmer> mwhudson: afaik there is a bug about that (something like "code imports should use fallback repositories")
[21:37] <mwhudson> ah yeah https://bugs.edge.launchpad.net/launchpad-code/+bug/485932
[21:37] <mup> Bug #485932: should stack foreign branch imports <code-import> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/485932>
[21:38]  * mwhudson ups importance
[21:38] <wgrant> What, you don't want to have to spend a couple of months importing each Linux series?
[21:39] <mwhudson> jelmer: it seems to me that fixing this bug would be much easier if we first fixed bug 375013
[21:39] <mup> Bug #375013: Cannot commit directly to a stacked branch <commit> <stacking> <Bazaar:Triaged> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/375013>
[21:39] <mwhudson> wgrant: yeah, a clearly silly suggestion!
[21:41] <jelmer> mwhudson: wasn't that the bug that was just two hours worth of work?
[21:41] <jelmer> wgrant: :-)
[21:41] <mwhudson> jelmer: i don't know
[21:43] <mwhudson> jelmer: i think i understand the bug well enough, but i certainly don't know how the apis that "allow a stacked repository to ask for more data" work
[21:43] <lifeless> so ask
[21:43] <lifeless> I hear bzr devs are accessible
[21:46] <mwhudson> lifeless: well, i mainly mentioned it to see if jelmer agreed fixing it would help
[21:46] <lifeless> mwhudson: do you want to know more about stacking/fallback repos?
[21:47] <mwhudson> lifeless: not right now
[21:49] <jelmer> mwhudson,lifeless: do we actually need to have that bug fixed before foreign branches can stack?
[21:49] <lifeless> what bug
[21:50] <lifeless> oh, 375013 - hell no
[21:50] <mwhudson> jelmer: well, not necessarily, i can see various approaches that would work
[21:50] <jelmer> so bug 375013 is not a prerequisite for bug 485932
[21:50] <lifeless> thats /only/ relevant when doing WT.commit() and the WT.branch is itself stacked.
[21:50] <mup> Bug #375013: Cannot commit directly to a stacked branch <commit> <stacking> <Bazaar:Triaged> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/375013>
[21:50] <mup> Bug #485932: should stack foreign branch imports <code-import> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/485932>
[21:50] <jelmer> lifeless: ok, good - thanks
[21:50] <mwhudson> oh ok
[21:50] <lifeless> e.g. in command line terms, you would have to be doing 'bzr checkout --lightweight <existing stacked branch url> foo; cd foo; bzr commit' for it to matter.
[21:51] <lifeless> if however, you do that as part of your import workflow, then yes, you need to fix it.
[21:51] <mwhudson> so we could create a branch, stack it on the existing kernel import, and then do bzr pull git://git.kernel.org/foo
[21:52] <jelmer> mwhudson: right, so since you already do pull manually I guess the main change would be actually adding the stacking
[21:52] <lifeless> jelmer: do you use commit builder ?
[21:52] <lifeless> jelmer: or do you generate a stream ?
[21:52] <jelmer> lifeless: no, insert_record_stream() and inventory delta's
[21:52] <lifeless> then bug 375013 is totally irrelevant
[21:52] <mup> Bug #375013: Cannot commit directly to a stacked branch <commit> <stacking> <Bazaar:Triaged> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/375013>
[21:53] <lifeless> yes mup, we know. now STFU
[21:54] <mwhudson> oh good
[21:55] <mwhudson> jelmer: yeah, and it would make sense to preserve the stacking as the branch moves from import slave to central store to mirrored area
[21:55] <mwhudson> but that's all pretty easy too i tihnk
[21:56] <jelmer> mwhudson: yeah
[21:57] <jelmer> mwhudson: how do the slaves work? do they have an NFS share that they pull into ? or do they fetch a copy of the branch, pull from the foreign repo and then push back
[21:57] <mwhudson> jelmer: the latter
[21:57] <mwhudson> there is some hystery here, i don't think we should take the existing setup as necessarily making perfect sense
[21:58] <jelmer> ah, ok
[21:58] <mwhudson> oh right, that was another reason i was thinking of stacking
[21:59] <mwhudson> would it make sense for the slaves to do the equivalent of "bzr branch --stacked $central; bzr pull $foreign; bzr push $central" ?
[22:00] <mwhudson> and it definitely makes sense to put the equivalent of a "--no-tree" in there
[22:00] <jelmer> mwhudson: yeah, there's no need for trees
[22:01] <jelmer> mwhudson: let me see what --stacked actually does, I'm not really familiar with anything other than the API :-)
[22:01] <jelmer> mwhudson: no, you wouldn't be able to use --stacked
[22:01] <jelmer> mwhudson: since you can't stack onto the source branch, only on another (bzr) branch
[22:01] <jelmer> inter-format stacking does not (yet) work
[22:01] <mwhudson> i think i was unclear
[22:01] <mwhudson> this is for an update of an import
[22:02] <mwhudson> $central is the location where the imported revisions live between import updates
[22:02] <mwhudson> i guess the local network is fast, it probably doesn't matter too much
[22:02] <mwhudson> otoh, branching outside a repo is cpu-intensive for 2a formats...
[22:03] <jelmer> ahh, now I understand - yeah, that makes sense
[22:33] <lifeless> mwhudson: shouldn't be that intensive
[22:35] <wgrant> lifeless: It is, though :/
[22:35] <lifeless> wgrant: mmm
[22:37] <maxb> Alternatively, try 'bzr reconfigure --use-shared' in a launchpad branch when you mucked up and didn't branch into a repo in the first place.... you will cry :-(
[22:37] <wgrant> lifeless: Also, do you know why non-empty LP pushes always transfer at least a megabyte, even for a tiny revision? Is seems to be "Inserting missing keys" for ages.
[22:37] <lifeless> wgrant: new or existing branches ?
[22:37] <wgrant> lifeless: Existing.
[22:40] <lifeless> wgrant: we are a little lazy in that area at the moment - we don't try to diff the basis CHK pages, we just calculate the adjacent closure and send.
[22:40] <lifeless> wgrant: please file a bug
[22:48] <wgrant> lifeless: My local repo-less branch just started creating a working tree, 12 minutes after the fetch started.
[22:49] <lifeless> wgrant: ok
[22:49] <wgrant> That is slow, and it eats a core the whole time. That sounds intensive to me.
[22:54] <wgrant> lifeless: Bug #534724
[22:54] <mup> Bug #534724: Pushing an LP branch with an empty commit is slow and bandwidth-hungry <Bazaar:New> <https://launchpad.net/bugs/534724>
[23:10] <wgrant> I would really like it if branch listings would show the review status rather than just the MP icon.
[23:15] <wgrant> mwhudson/thumper: Can one of you please send https://code.edge.launchpad.net/~wgrant/launchpad/fix-build-breadcrumbs/+merge/20888 off to ec2test?
[23:16] <mwhudson> wgrant: sure
[23:18] <wgrant> mwhudson: Thanks.
[23:27] <mwhudson> wgrant: it's gone headless now
[23:30] <wgrant> mwhudson: Excellent.