[00:10] <ubuntujenkins> thanks for your help guys, night
[01:28] <mars> mwhudson or thumper, ping
[01:30] <mwhudson> mars: i
[01:30] <mwhudson> hi
[01:31] <mars> hi mwhudson.  Would you happen to have a moment to help debug a failing test I have?
[01:31] <mars> I need someone else to verify that it fails on their system
[01:34] <mwhudson> mars: sure
[01:35] <mars> mwhudson, thanks.  Could you please tell me if this fails:
[01:35] <mars> mwhudson, xvfb-run -s '-screen 0 1024x768x16' bin/test -t test_newly_linked_branch_diff_popup
[01:35] <mwhudson> mars: hang on, updating devel
[01:35] <mars> I assume you have xvfb installed.  If not, then just drop that part.
[01:37] <mwhudson> mars: ok, running
[01:43] <mwhudson> mars: bah, need to run make schema
[01:43] <mars> boo
[01:43] <mars> that is really annoying :)
[01:44] <mars> I wonder if it could be made to fail earlier
[01:44] <mars> 'make check_schema'
[01:44] <mars> I've had that happen many times
[01:54] <mars> confirm_dbrevision_on_startup() seems to do all the work to raise a database revision error.  How to get that function into a script...
[02:01] <mwhudson> mars: anyway, that test passes for me
[02:01] <mars> mwhudson, perfect, thanks for the help.
[02:07]  * wgrant wonders why make clean decides to obliterate a whole lot of data directories.
[02:19] <mwhudson> lunchtime
[02:30] <dhastha> need help: error in make schema  Missing ./download-cache.
[02:30] <dhastha> Developers: please run utilities/link-external-sourcecode.
[02:30] <dhastha> make: *** [download-cache] Error 1
[02:31] <dhastha> i got this error while building a pristine trunk (devel) instance
[02:32] <spm> dhastha: a pristine trunk doesn't have all the external code that is needed. per the message, (i guess...) run utilities/link-external-sourcecode
[02:34] <dhastha> i am getting error while run utilities/link-external-sourcecode
[02:35] <dhastha> spm, Invalid line at line "4".
[02:35] <dhastha> Invalid line at line "7".
[02:36] <dhastha> bzrlib.errors.ParseConfigError: Error(s) parsing config file /home/dhastha/.bazaar/locations.conf:
[02:43] <dhastha> spm, how to rectify those errors?
[02:43] <spm> dhastha: I'd suggest you look at the file suggested and see why that appears broken as a 1st step. ?
[02:57] <thumper> dhastha: have you followed the setup instructions on the dev wiki?
[03:37] <mwhudson> heh
[03:37] <mwhudson> i can tell the uk is in summer time now, i'm getting mails from the future about bugs
[03:38] <wgrant> That's still not fixed?
[03:39] <wgrant> Bug #262040
[03:39] <mup> Bug #262040: Bogus timestamps on some unbatched bugmail <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/262040>
[03:40] <mwhudson> hey look i commented on that bug roughly a year ago
[03:40] <mwhudson> what are the chances
[03:41] <wgrant> Heh heh.
[04:14] <wgrant> spm: Has the PPA process-accepted.py gone and died again?
[04:15] <spm> i hope not...
[04:16] <wgrant> spm: Ah, no, just very late.
[04:17] <spm> where does that one run again? soyuz is a mini nightmare of odd corners and crontabs...
[04:18] <wgrant> It's germanium. Some of my binaries appeared 5 minutes late, but they did appear.
[04:18] <wgrant> cron.publish-ppa on germanium.
[04:18] <spm> bleh. that'd be right. i was on cocoplum and cesium.
[04:18] <wgrant> Heh.
[04:20] <spm> now if only i could find which of the 6 users it runs under... /me gives up and looks for a logfile for clues
[04:21] <wgrant> lp_publish
[04:22] <spm> is that called by something else then? cronscripts/publishing/cron.publish-ppa cronscripts/publishing/cron.daily-ppa scripts/process-death-row.py and keys and htaccess
[04:23] <spm> are the only tasks of note that run
[04:23] <wgrant> cron.publish-ppa calls process-accepted.py.
[04:23] <spm> ahh there it is. the 1st. yup
[04:24] <spm> one of the "possibilities" for our sprint coming up; is to drag eg Julien by the ear and nail him to the floor until he completely explains the entire soyuz "WTF" and how it "works".
[04:25] <wgrant> Hahaha.
[04:25] <wgrant> '"works"' is right.
[04:25] <spm> with diagrams, if we're feeling really vindictive
[04:26] <wgrant> https://wiki.ubuntu.com/CelsoProvidelo/SoyuzInfrastructureOverview but worse :P
[04:31] <mwhudson> there are already diagrams!
[04:31] <mwhudson> some of them may even be accurate
[04:32]  * spm is NOT game to click on that link before breaking for lunch. maybe after. and after I've digested. but not before.
[04:34] <lifeless> wgrant: what was the oops that you needed looked at in the weekend ?
[04:35] <wgrant> spm: Refreshing https://edge.launchpad.net/~wgrant/+archive/openttd/+build/1654520 regularly shows that shipova is being dodgy and keeps dropping the build (note the fluctuating start time). Can you marks shipova not-OK or something? I've seen others complaining about this one over the past couple of weeks too.
[04:35] <wgrant> lifeless: Good point.
[04:35] <spm> wgrant: not sure I can; one sec...
[04:36] <wgrant> spm: https://launchpad.net/builders/shipova/+edit; uncheck the OK checkbox; save. unless you mean policy-wise.
[04:37] <spm> policy/perms wise; looks like I can. see if that stops it
[04:38] <spm> and is now showing disabled with a nice message as to why :-)
[04:38] <wgrant> Great. And my build is going OK.
[04:38] <wgrant> Thanks.
[04:38] <spm> \o/
[04:38] <wgrant> I knew there was a dodgy builder around, but hadn't managed to work out which.
[04:39] <wgrant> spm: Also, do you know why cocoplum OOPSes aren't syncing to the OOPS viewer thingy?
[04:39] <wgrant> There are some interesting cocoplum OOPSes which cannot be viewed.
[04:42] <spm> wgrant: I'ev just done a full manual sync - see if that works?
[04:42]  * spm afks for coffee... brb
[04:42] <mwhudson> thumper: were you asking for http://pythonpaste.org/webob/ earlier?
[04:43] <thumper> yeah, but found it elsewhere, thanks
[04:43] <mwhudson> :)
[04:43] <thumper> mwhudson: do you know if it has taken over as the prime development from paste?
[04:43] <mwhudson> thumper: i think so but i don't know so
[04:44] <mwhudson> it's only a replacement for bits of paste aiui
[04:44]  * wgrant is interested in OOPS-1553FTPMASTER11 and OOPS-1553FTPMASTER16
[04:44] <wgrant> Maybe they will exist now.
[04:45] <mwhudson> seems not
[04:45] <wgrant> Grrr.
[04:49]  * spm has a look on the filesystem...
[04:50] <spm> wgrant: when were they generated?
[04:50] <spm> roughly?
[04:50] <spm> actually - roughly to "which day" would work.... :-/
[04:51] <mwhudson> i can't even see how you'd get an oops prefix like that
[04:51] <wgrant> Actually, now I think about it...
[04:51] <spm> because for the days of the 5th, 6th and 7th of April, there is only 1 oops. 81309.FTPMASTER1
[04:51] <wgrant> While the OOPS prefix was FTPMASTER...
[04:52] <wgrant> The log was from a process that runs on cesium.
[04:52] <spm> Ah ha!
[04:52]  * wgrant gives the production configs an A+ in confusion.
[04:53] <wgrant> It was Friday or so, IIRC.
[04:53] <spm> :-)
[04:53] <spm> I think I can see why the oops *may* not show up. drwx------ 6 lp_buildd  lp_buildd     4096 2010-04-02 14:28 lp_queue/ <== oops dir on cesium
[04:54] <wgrant> Heh.
[04:54] <spm> bingo. there they are.
[04:54] <spm> all their perms are crap too. /me envisages another bug report for tdoay
[04:56] <wgrant> lalalala that's not Soyuz any more lalalala
[04:57] <mwhudson> funky umask?
[04:58] <spm> not likely - we've seen too many cases of these shenanigans before acorss all parts of LP to blame umasks; but I will check.
[04:59] <spm> btw, have we ever mentioned how much we hate the twisted 1Mb log rotation evilness? <== grrrrr.
[05:00] <spm> wgrant: try now?
[05:00] <wgrant> spm: I don't actually have access to OOPSes.
[05:00] <spm> hahaha. thought you did :-)
[05:01] <spm> ad it still doesn't show. that may need a diogo fix
[05:01] <wgrant> :(
[05:02] <spm> authentication failed for user "uploader"
[05:02] <spm> DB error - I'd guess it's been fixed since, as there are no more since then. Date: 2010-04-02T13:38:29.286748+00:00
[05:02] <mwhudson> wgrant: OperationalError: FATAL:  Ident authentication failed for user "uploader"
[05:03] <wgrant> Ah, great. Thanks.
[05:03] <wgrant> I didn't think it had happened since, but there appeared to be quite a few that day.
[05:03] <spm> post rollout; and I'd suspect no one informed us of the new DB user in advance. Or we missed it. :-)
[05:13] <spm> wgrant: what *&^%*&ing process/script generated those oops? I'm guessing cronscripts/buildd-queue-builder.py ?
[05:14] <wgrant> spm: buildd-manager.
[05:14] <wgrant> buildd-queue-builder is one of four scripts which do the job that buildd-manager does.
[05:14] <spm> Oh ho ho. the daemon itself.
[05:14] <wgrant> But it is way obsolete.
[05:14] <wgrant> Oh, wait.
[05:14] <wgrant> No. process-upload.py, launched by buildd-manager.
[05:14] <wgrant> It will soon be buildd-manager itself, but not yet.
[05:15] <spm> ahh; kk. thanks!
[05:16] <spm> I think I will stop trying for accuracy or precision where soyuz bugs are concerned and just go with "it's broken. pls fix" reports.
[05:16] <thumper> testfix?
[05:16] <thumper> grr
[05:17] <mwhudson> spm: buildbot kickage pls
[05:17] <thumper> mwhudson: it says wrong python used
[05:17] <thumper> mwhudson: do you know what is going on?
[05:17] <spm> damn. new there was a reason I wanted to stay logged onto prasé
[05:17] <mwhudson> thumper: yes
[05:18] <spm> mwhudson: kicked
[05:18] <mwhudson> thumper: buildbot is fixed, it needs a restart and a force
[05:20] <thumper> spm: kicked or restarted?
[05:20] <spm> restarted type of kicking
[05:20] <thumper> spm: thanks
[05:22] <thumper> mwhudson: my big branch passed all tests, and is on its way to landing on db-devel
[05:23] <mwhudson> thumper: woo
[05:27] <thumper> oh ffs, pqm still thinks it needs testfix
[05:27] <thumper> how do I smack it around?
[05:27] <spm> sudo spm fix! <== probably
[05:30] <thumper> sudo spm fix plz
[05:31] <spm> plz. command not recognised
[05:32] <spm> thumper: ?? waterfall looks good? or are you referring to db_devel?
[05:32] <thumper> yes
[05:33] <mwhudson> it looks like buildbot-poll should be moving out of testfix
[05:33] <spm> ah yup. we're in failure according to the pqm configs
[05:33] <mwhudson> thumper: when did you get the failure from pqm?
[05:33] <mwhudson> oh
[05:33] <mwhudson> silly pqm configs
[05:33] <thumper> mwhudson: after it was booted
[05:33] <mwhudson> spm: any log files to say why?
[05:33] <spm> that hsould sort itself every 5 mins. hrm. wonder if just forcing a build should clear it?
[05:35] <spm> Starting buildbot-poll at Wed Apr  7 05:34:35 BST 2010
[05:35] <spm> Builder lp at http://lpbuildbot.canonical.com:8010 failed building r10635 [failed shell_7].
[05:35] <spm> Builder db_lp at http://lpbuildbot.canonical.com:8010 succeeded building r9202.
[05:36] <spm> so i read that as devel is the cause; and a build is underway to rectify that as we speak. ???
[05:36] <mwhudson> oh right
[05:36] <mwhudson> that sort of makes sense, the tip of devel did fail to build
[05:37] <spm> yup
[05:37] <mwhudson> i wonder if there's a way to fake it
[05:37] <thumper> so I have to wait then?
[05:37] <mwhudson> we could kill the current build and then force a build
[05:37] <thumper> meh
[05:37]  * thumper goes to guitar lesson
[05:37] <spm> well the script that generated the above is run every 5 and is more or less getting it's status from the 'last build - I believe. and setting the failure/success mode accordingly.
[06:29] <cody-somerville> wgrant, Did you say that process-accepted is dying again?
[06:29] <wgrant> cody-somerville: No. It was just being slow.
[06:33] <cody-somerville> hmmm... yea, I see at the tail of the cron.ppa.log that it failed to grab the lockfile several times.
[06:34] <wgrant> What was it doing in the previous runs that took so long?
[06:35] <wgrant> p-a normally takes <20s, AFAICT.
[06:35] <wgrant> I guess a couple of big PPA index regenerations could easily throw p-d over 5 minutes, but I don't know of any PPAs that big.
[06:38] <cody-somerville> looks like a bunch of nightly builds.
[06:38] <wgrant> They must be huge.
[06:38] <wgrant> Even chromium was only a couple of hundred MiB last time I looked.
[06:41] <cody-somerville> Looks like there is a bunch of PoolFileOverwriteError exceptions that cause numerous PPAs to be processed each run.
[06:41] <cody-somerville> And the fact that the publisher seems to publish suites and pockets that aren't even dirty probably doesn't help.
[06:41] <wgrant> Bug #387049
[06:42] <mup> Bug #387049: Copy backend does not detect file conflicts <ppa> <Soyuz:In Progress by stevenk> <https://launchpad.net/bugs/387049>
[06:42] <wgrant> They must be dirty -- maybe they have pending deletions?
[06:43] <wgrant> Domination is probably also significantly slower than it needs to be, but I have a simple fix for that.
[06:43] <wgrant> Source domination, that is.
[06:45] <cody-somerville> Looking here, an entire second per PPA is eaten processing suites and pockets that don't exist in PPAs at all and/or probably don't exist in that specific PPA.
[06:45] <wgrant> In which step? Domination?
[06:46] <cody-somerville> Step A: Publishing
[06:46] <wgrant> Hmm.
[06:46] <wgrant> Bad queries must be bad.
[06:47] <cody-somerville> I see here a PPA that had nothing to be published and it took 2 seconds just for the publishing step.
[06:47] <wgrant> I've almost fixed B and C', but I've not looked at A yet.
[06:48] <wgrant> I wasn't aware that it took long at all.
[06:50] <cody-somerville> On average, it looks like it takes half a second per file that actually has to be published plus a static 2-3 second overhead.
[06:51] <wgrant> I know the indices on the publishing tables are stupid.
[06:51] <wgrant> Maybe most of that overhead is just initial query time.
[07:57] <underdrk> morning
[07:58] <underdrk> is it normal for rocketfuel-setup to use mor than ~300 meg ram?
[07:59] <underdrk> its eating trough all the ram on my virtualbox system getting killed eventually
[07:59] <wgrant> underdrk: That's probably bzr.
[07:59] <wgrant> noodles775: Morning.
[07:59] <underdrk> wgrant: yup
[07:59] <wgrant> noodles775: I need Soyuz acks on four MPs, when you have a moment.
[08:00] <underdrk> so, what is bzr doing that it needs ~300m ram?
[08:00] <wgrant> underdrk: Not sure.
[08:00] <underdrk> shoudn't it just download and store stuff on disk?
[08:00] <noodles775> Hey wgrant, jkust on the phone. Will look in a tick.
[08:01] <wgrant> underdrk: Probably. But the LP branches are a little ancient and special, so may be causing some interesting behaviour.
[08:01] <wgrant> noodles775: No urgency. Thanks!
[08:01] <underdrk> wgrant: hmm, thats a pitty
[08:02] <underdrk> ill see if I can make it download an a machine with more ram and then scp it into my virtualbox
[08:02] <wgrant> underdrk: Your VM has only a few hundred megabytes of RAM assigned?
[08:03] <spm> assign some more swap and see if that helps it continue; vs dying. hopefully without io thrashing as well. ???
[08:04] <wgrant> I don't like your chances of running much of LP with <1GB on i386, or much <2GB on amd64.
[08:05] <spm> heh; given I just killed a 4Gb of memory importd that was running away a tad; yes; agreed :-)
[08:05] <wgrant> spm: Linux as usual?
[08:05] <spm> ruby actually; but not a bad guess.
[08:05] <wgrant> Ah.
[08:06] <spm> we have 3 nasties: linux kernel; gcc and ruby.
[08:06] <wgrant> gcc shouldn't be so bad since incremental bzr-svn was deployed a week ago, right?
[08:08] <wgrant> Ah, yes, it's even finished its initial import now.
[08:08] <spm> oh cool. was just updating the related bug report; and noted that gcc was the 3rd of the triumvirate of pain, so :-)
[08:09] <adeuring> good morning
[08:10] <simon-o> hi :-)
[08:18] <wgrant> Hm: http://forum.biosinteractive.com/viewtopic.php?f=5&t=7&p=28#p28
[08:18] <wgrant> People are not happy with Launchpad.
[08:22] <underdrk> wgrant: for a development platform yes, I'd hope half a gig would be enough
[08:23] <underdrk> but, ill mount some more swap
[08:51] <wgrant> jelmer: Morning.
[09:05] <wgrant> noodles775: Thanks for those.
[09:05] <noodles775> wgrant: thank you :)
[09:06] <wgrant> buildd-manager is a whole lot more understandable after that lot.
[09:06] <noodles775> Yeah, it's great seeing the code continually improved!
[09:22] <wgrant> So, I have a branch that removes 9500 lines of unused code.
[09:23] <noodles775> !
[09:24] <wgrant> That seems to violate the 800 line rule by a little bit.
[09:35] <mrevell> Hi
[10:12] <james_w> how do I find out if PQM is in textfix?
[10:18] <dhastha> need help: error occuring while running ./utilities/link-external-sourcecode ~/launchpad/lp-sourcedeps
[10:19] <dhastha> Wanted to link /home/dhastha/launchpad/lp-sourcedeps/download-cache to ./download-cache but source does not exist
[10:19] <jelmer> james_w: if there's an email to the mailing list with a test failure and pqm rejects your requests, while its error message mentions requiring [testfix]
[10:19] <jelmer> dhastha: hi
[10:20] <dhastha> jelmer, hi error while installing launchpad locally
[10:20] <jelmer> dhastha: how did you create lp-sourcedeps?
[10:21] <james_w> jelmer: yeah, I got rejections, I want to know if it's safe to submit again yet.
[10:21] <dhastha> jelmer, after run rocketfuel-setup
[10:21] <wgrant> Odd. buildbot merged 20 minutes ago.
[10:21] <wgrant> Which suggests that thins weren't too unhealthy.
[10:23] <jelmer> dhastha: perhaps rocketfuel-get fixes it?
[10:24] <dhastha> jelmer, after run rocketfuel-get i got lp-branches and lp-soucedeps files automatically
[10:26] <dhastha> jelmer, sorry i run rocketfuel-setup only, i don know about rocketfuel-get
[10:26] <james_w> wgrant: so it's probably ok now?
[10:26] <james_w> I got rejected some hours ago
[10:26] <jelmer> dhastha: did rocketfuel-setup interrupt halfway through?
[10:26] <wgrant> james_w: Ah, if it was that long ago, then go for it.
[10:26] <james_w> ok
[10:26] <james_w> anyone know how to land skipping ec2?
[10:27] <james_w> I just did "ec2 land", but it seems wasteful to run the tests again?
[10:27] <dhastha> jelmer, no error in rocketfuel-setup
[10:27] <jelmer> james_w: use "bzr lp-land" ?
[10:27] <dhastha> jelmer, there is no error in database-setup also
[10:28] <mwhudson> james_w: you can't tell if we're in testfix, it really sucks
[10:28] <mwhudson> (there's a bug report, but i don't have any ideas on fixing it)
[10:29] <dhastha> jelmer, error starting in  make schema
[10:33] <james_w> what's PQM's address for LP?
[10:33] <james_w> (I have searched dev.launchpad.net for all this, but I couldn't find it)
[10:35] <StevenK> james_w: Heh heh, I had exactly the same problem about a week ago.
[10:36] <jelmer> pqm_email = Canonical PQM <launchpad@pqm.canonical.com>
[10:36] <StevenK> Bah, jelmer! I was about to paste that
[10:37] <dhastha> jelmer, download-cache folder is not available in my lp-sourcedeps folder so only error occuring. isn't it?
[10:37] <jelmer> dhastha: yeah, I wonder what went wrong there. What happens if you run rocketfuel-setup again?
[10:37] <jelmer> dhastha: it should be taking care of creating lp-sourcedeps
[10:38] <wgrant> dhastha: Does lp-sourcedeps contain anything at all?
[10:38] <wgrant> If it doesn't contain any significant volume of data, remove it and run rocketfuel-setup again.
[10:39] <dhastha> jelmer, eggs, sourcecode two folders only are there
[10:41] <dhastha> wgrant, k
[10:49] <danilos> dhastha, hi, is wgrant's suggestion helping?
[10:50] <dhastha> danilos, i removed all the datas and trying once again
[10:55] <danilos> dhastha, cool
[11:01] <deryck> Morning, all.
[11:50] <persia> LP rollouts are the third thursday of the month, right?
[11:51] <wgrant> It depends.
[11:51] <wgrant> This is a 5 week cycle (hence this is week 0)
[11:51] <wgrant> persia: See https://dev.launchpad.net/Releases/2010Calendar
[11:51] <wgrant> (no, there is not a release the day before Lucid)
[11:51] <persia> Oh, perfect.  THanks.
[11:53] <thumper> oh, we are in a week 0?
[11:53] <thumper> groovey
[11:53]  * wgrant points at /topic
[11:54] <wgrant> (although I set it)
[11:56] <dhastha> danilos, Permission denied (publickey).
[11:56] <dhastha> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[11:57] <dhastha> danilos, same error
[11:58] <danilos> dhastha, what do you have in ~/launchpad? and what user did you run rocketfuel-setup under?
[11:58] <wgrant> dhastha: You don't have your SSH key registered with Launchpad?
[11:58] <danilos> wgrant, he does
[11:59] <wgrant> dhastha: What does 'bzr launchpad-login' say?
[12:00] <dhastha> rocketfuel-setup file only i am having in ~/launchpad. while i run i am getting that error. but am having ssh key registered
[12:00] <danilos> dhastha, perhaps it's related with the keyserver, can you try changing it as suggested on https://dev.launchpad.net/Getting:
[12:00] <danilos>     ## Sometimes the keyserver from Ubuntu doesn't respond, especially on Karmic
[12:00] <danilos>     ## Try changing keyserver.ubuntu. to pool.sks-keyservers.net
[12:00] <wgrant> danilos: That's for OpenPGP keys.
[12:00] <wgrant> This is an SSH key problem.
[12:00] <danilos> wgrant, right, dumb me
[12:01] <danilos> dhastha, ok, so the only thing I can suggest is to make sure whatever environment bzr gets executed in, it has SSH_AGENT env variables properly set (i.e. don't run it with sudo options where it unsets some of these "unsafe" variables)
[12:06] <dhastha> danilos, making local branch of launchpad trunk. bzr: ERROR: [Errno 13] Permission denied: '/home/dhastha/.bazaar/bazaar.conf'
[12:07] <dhastha> danilos, finding revision going on
[12:07] <danilos> dhastha, ok, you'll probably have to revert those privileges to your own user using something like "sudo chown -r dhastha.dhastha /home/dhastha/.bazaar"
[12:08] <maxb> And be sure not to run rocketfuel-setup under sudo in the future. that's not right
[12:10] <danilos> that was my fault, I suggested it might be needed
[12:16] <wgrant> jtv: Is your soyuz-sampledata-setup failure fixed by my sampledata reversion yesterday?
[12:16] <wgrant> jtv: Its output was accidentally added to the sampledata a couple of weeks ago.
[12:16] <jtv> wgrant: that's what I was hoping for yesterday, but unless I was less up-to-date than I thought, it doesn't seem to help.
[12:17] <jtv> wgrant: oh wait, did you end up landing that on db-devel or not?
[12:17] <wgrant> jtv: It landed on db-devel a couple of days ago, and on devel a little over 24 hours ago.
[12:17] <wgrant> devel r10627
[12:17] <wgrant> db-devel r9194
[12:18] <jtv> wgrant: it may be a "missing link" in how the revisions flowed on this system... I'll try again.
[13:32] <deryck> gmb, I think we should make Bug #557252 a priority.  Seems a simple fix with many gains.  Would you agree?
[13:32] <mup> Bug #557252: Creating CalculateBugHeatJob is very slow <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/557252>
[13:33] <gmb> deryck, I just triaged it as medium :). But if we've got someone to spare to fix it then yes, we should deal with it, if only to make garbo-hourly happier
[13:34] <deryck> gmb, yeah, that sounds fine.
[14:36]  * wgrant loves bugmail from 'Tomorrow 00:32'
[14:47] <kfogel> wgrant: http://fts.ifac.cnr.it/cgi-bin/dwww/usr/share/doc/emacs21-common/etc/future-bug
[14:48] <wgrant> kfogel: Heh.
[14:49] <wgrant> (Bug #262040 is the problem.)
[14:49] <mup> Bug #262040: Bogus timestamps on some unbatched bugmail <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/262040>
[14:59] <bac> reviewers meeting starting in one minute
[15:16] <dhastha> danilos, are you there?
[15:17] <kfogel> Anyone know why PQM is suddenly being very coy about showing details?  http://people.canonical.com/~kfogel/images/pqm-opacity.png
[15:19] <danilos> dhastha, yeah
[15:35] <kfogel> danilos (or anyone): know why PQM is suddenly being very coy about showing details?  http://people.canonical.com/~kfogel/images/pqm-opacity.png
[15:35] <kfogel> ?
[15:36] <danilos> kfogel: hum, probably submissions for non-LP branches, or something is weird with the PQM configuration
[15:37] <kfogel> danilos: no, it's been like this for a while, and I know I had a submission in the queue then.  I think the configuration is messed up.  What's the best way to report that: RT, or file a bug?
[15:37] <danilos> kfogel: it's probably best to check with LOSAs
[15:37] <kfogel> danilos: will do
[15:37] <danilos> kfogel: thanks :)
[16:24] <deryck> adeuring, Bug 550973 is really just about adding the referrer header exception and a good comment.  So I moved it to easy bugs backlog.
[16:24] <mup> Bug #550973: checkbox should send a referer header when it POSTs data to Launchpad. <checkbox:Fix Committed by cr3> <Launchpad Foundations:Invalid by adeuring> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/550973>
[16:25] <adeuring> deryck: OK, I know. The exception already exists, BTW
[16:25] <deryck> adeuring, oh, hmmm.  So it's landed?
[16:26] <adeuring> deryck: yes, as an RC branch, IIRC. But the comment that gary wants is still missing.
[16:26] <adeuring> deryck: at least LP receives and prcesses again HWDB submissions
[16:26] <gary_poster> yeppers
[16:26] <deryck> adeuring, ok.  so even more easy then :-)
[16:27] <adeuring> deryck: I know; I just wnat to finish this mantis related bug. Otherwsie, I'll never finish that branch, I'm afaid. After that, I'll add this comment
[16:28] <deryck> adeuring, oh, yeah, I didn't mean to imply it should be done now.  Just noting that I moved it to a different queue.
[16:28] <adeuring> deryck: OK ;)
[18:16] <jml> hello again
[18:21] <dhastha> daniloff, are u there?
[18:22]  * maxb imagines that the "off" suffix means no
[18:24] <dhastha> need help: error occuring while run launchpad locally.     make run
[18:25] <maxb> dhastha: that is not much detail for anyone to be able to help you with. Please pastebin the error
[18:26] <dhastha> maxb, http://paste.ubuntu.com/410637/
[18:27] <maxb> Hmm, I guess your rocketfuel-setup never finished successfully?
[18:28] <maxb> Do you have a /home/dhastha/launchpad/lp-sourcedeps/download-cache/dist/setuptools-0.6c9-py2.5.egg ?
[18:28] <dhastha> maxb, finished successfully. no error found
[18:29] <dhastha> maxb, upto download-cache only am having. there is no dist as well as setuptools.0.
[18:30] <maxb> What do you see if you run 'bzr info' in the download-cache dir?
[18:31] <dhastha> Bound branch (format: pack-0.92)
[18:31] <dhastha> Location:
[18:31] <dhastha>       branch root: .
[18:31] <dhastha>   bound to branch: bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/
[18:32] <maxb> And 'bzr status' ?
[18:32] <dhastha> bzr: ERROR: No WorkingTree exists for "file:///home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr/checkout/".
[18:32] <dhastha> dhastha@dhastha-desktop:~/launchpad/lp-branches/devel/download-cache$ bzr statusbzr: ERROR: No WorkingTree exists for "file:///home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr/checkout/".
[18:33] <maxb> OK, run 'bzr checkout' and it should create a dist/ directory
[18:34] <dhastha> bzr: ERROR: File exists: u'/home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr': [Errno 17] File exists: '/home/dhastha/launchpad/lp-sourcedeps/download-cache/.bzr'
[18:36] <maxb> Hrm
[18:36] <dhastha> maxb, bzr checkout  returns above error
[18:36] <maxb> Ok, try this: 'bzr unbind; bzr checkout; bzr bind lp:lp-source-dependencies'
[18:39] <dhastha> same above error
[18:44] <dhastha> maxb: rocketfuel-setup had taken somuch of time to complete
[18:45] <maxb> dhastha: How fast is your internet connection? One option would be to just throw away download-cache and re-fetch it
[18:47] <dhastha> maxb, 60kb per sec. How to refetch that particular file only?
[18:47] <maxb> Unfortunately, that branch is huge
[18:49] <maxb> dhastha: Could you please run 'ls .bzr' in download-cache?
[18:49] <dhastha> branch  branch-format  branch-lock  checkout  README  repository
[18:50] <maxb> OK, 'rm -rf .bzr/checkout' and then try 'bzr checkout' again
[18:51] <dhastha> no error found
[18:51] <maxb> Great, do you now have dist/ and cmmi/ directories in download-cache?
[18:52] <maxb> Also, please re-run 'bzr info'
[18:53] <dhastha> there is no one folder there
[18:54] <dhastha> while run bzr info       it returns Checkout (format: unnamed)
[18:54] <dhastha> Location:
[18:54] <dhastha>        checkout root: .
[18:54] <dhastha>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/
[18:54] <maxb> OK, this part is now sorted.
[18:54] <mrevell> Night all
[18:55] <maxb> dhastha: Now that this has been sorted out, you should re-run rocketfuel-get
[18:56] <dhastha> maxb, k sure
[20:09] <rockstar> sinzui, hi
[20:09] <sinzui> hi rockstar
[20:11] <rockstar> sinzui, so, I'm trying to add a method to lp.registry.models.product.Product - I've made IProduct inherit from IHasRecipes and added the method getRecipes to IProduct, but my test still says there is no getRecipes method.
[20:11] <rockstar> sinzui, so I'm assuming that there's some sekrit zcml somewhere, but I don't see anything suspicious in lp/registry/configure.zcml
[20:12] <rockstar> sinzui, I seek enlightenment grandfather.
[20:12] <sinzui> rockstar, verifyObject() says there is no problem?
[20:13] <sinzui> rockstar, you added the method to IProductPublic?
[20:14] <rockstar> sinzui, verifyObject (as used by assertProvides) says there is a problem, so I'm assuming that proxy is getting in the way.
[20:14] <rockstar> sinzui, no, I added it to IProduct
[20:14] <rockstar> Er, I made IProduct inherit from IHasRecipes, which has the method.
[20:14] <rockstar> And then created the method in Product
[20:14] <sinzui> okay
[20:15] <rockstar> sinzui, I guess using IProductPublic might be okay.  As far as I know, we don't have a story for private recipes.
[20:16] <sinzui> rockstar, I do not see IHasRecipes in any zcml, so there are not permissions to see it. My tree may be out of date
[20:17] <rockstar> sinzui, yeah, it landed this morning.
[20:17] <sinzui> rockstar, the other way to explore this is to make IProductPublic inherit IHasRecipes and see if the attr is visible
[20:17] <rockstar> sinzui, ack.  I'll try that.
[20:20] <rockstar> sinzui, it worked. Screw it.  I'm leaving it that way.
[20:23] <sinzui> :)
[20:24] <sinzui> rockstar, take a look at the other interfaces in the file first to be sure it is what you want. Most registry objects define permission on the base Interfaces for webservice API reasons
[20:24] <rockstar> sinzui, yeah.  I don't think we care that recipe listings are public.  As it looks now, Recipes can't be private.
[21:01] <dhastha> maxb, error occuring while make run:    http://paste.ubuntu.com/410703/
[21:03] <maxb> dhastha: Could you please pastebin 'dpkg -l' (it will be quite long)
[21:04] <dhastha> maxb, http://paste.ubuntu.com/410704/
[21:09] <maxb> dhastha: You do not have launchpad-developer-dependencies installed
[21:14] <dhastha> maxb, http://paste.ubuntu.com/410709/
[21:15] <maxb> dhastha: https://dev.launchpad.net/Running, under the "Building" heading
[21:17] <thumper> morning
[21:18] <thumper> sinzui: I've cc'ed you on an email
[21:18] <thumper> sinzui: would be happy to talk about it at some stage
[21:19] <dhastha> maxb, success. Thanks a lot
[21:19] <maxb> np
[21:22] <sinzui> leonardr, anyone: How to I go about making the fascist happy?
[21:22] <sinzui> You should not import copy_field from lazr.restful.declarations:
[21:22] <sinzui>     lp.registry.interfaces.distribution
[21:23] <sinzui> ah I see:
[21:23] <sinzui> from lazr.restful.interface import copy_field
[21:23] <leonardr> glad you figured it out since i had no clue
[21:23] <sinzui> :)
[21:26] <thumper> what was the reason for: Module canonical.launchpad.webapp.login, line 255, in login
[21:26] <thumper>     email = removeSecurityProxy(account.preferredemail).email
[21:26] <thumper> AttributeError: 'NoneType' object has no attribute 'email'
[21:26] <thumper> on login again?
[21:26] <thumper> user in #launchpad having issues
[22:26] <mwhudson_> i would have less wtfs if buildout and buildbot didn't look so similar