[00:11] <maxb> createlang: language installation failed: ERROR:  could not access file "$libdir/plpython": No such file or directory
[00:12] <maxb> hrm
[00:17] <maxb> got past that, only to run into
[00:17] <maxb> AssertionError: /usr/share/postgresql/8.4/contrib/tsearch2.sql does not exist
[00:19] <maxb> ah
[00:20] <maxb> with two versions of pgsql in play, lp-dev-deps does not necessarily ensure you have all the addons for each version installed
[04:10] <thumper> do I still need to use from __future__ import with_statement?
[04:10] <thumper> prolly do right?
[04:27] <lifeless> http://www.python.org/dev/peps/pep-0343/
[04:27] <lifeless> while we deploy with 2.5, you do
[04:27] <lifeless> when we deploy with 2.6, its always present
[04:27] <lifeless> (see under transition plan)
[04:51] <thumper> lifeless: yeah I knew that
[04:51] <thumper> I was kinda thinking out loud
[04:51] <thumper> since we are still deploying on 2.5 for now
[06:12]  * thumper EODs for now, back for the interview in 3 hours
[06:34] <lifeless> thumper: interview ?
[06:36] <thumper> lifeless: yeah, talking to an ozzie in 2.5 hours
[06:36] <lifeless> the code team position ? good luck
[07:43] <kb9vqf> Why is my buildd remote builder complaining about "/var/debbuild/srcdep-lock is not a directory"?
[07:43] <kb9vqf> I verified that it is a directory in the chroot environment
[07:43]  * kb9vqf realized he was yakking in the wrong channel for the past several hours :-P
[07:44] <kb9vqf> More worrying is this:
[07:44] <kb9vqf> 2010-06-11 01:41:35-0500 [-] Build log: cat:
[07:44] <kb9vqf> 2010-06-11 01:41:35-0500 [-] Build log: build-progress
[07:44] <kb9vqf> 2010-06-11 01:41:35-0500 [-] Build log: : No such file or directory
[07:51] <lifeless> kb9vqf: I'd assume that you don't have that directory etc
[07:52] <kb9vqf> My troubleshooting is indicating that sbuild is exiting immediately upon invocation
[07:52] <kb9vqf> Which would explain the missing status files
[07:52] <kb9vqf> Manually running it also causes an immediate exit with no error messages
[07:55] <kb9vqf> Here we go...die "conf::mailto not set\n" if !$conf::mailto;
[07:56] <kb9vqf> ^^^ That was in /usr/bin/sbuild
[07:58] <kb9vqf> Commenting that line out fixed the builder
[07:59] <kb9vqf> So, what should I have done instead of commenting it out? ;-)
[07:59] <lifeless> file a bug
[07:59] <lifeless> saying the following:
[07:59] <lifeless>  - the situation should have been more obviously debuggable
[07:59] <lifeless>  - and include enough pointers for you to have found docs
[07:59] <lifeless> what you should do to fix it, is to set the admin address to send mail to
[08:00] <kb9vqf> Yeah, silent exiting is not fun :-P
[08:00] <kb9vqf> How would I set that address
[08:02] <lifeless> Dunno
[08:02] <kb9vqf> Well, the builder is hanging now at this
[08:02] <kb9vqf> Finished at 20100611-0158
[08:02] <kb9vqf> Build needed 00:00:17, 133368k disk space
[08:02] <kb9vqf> Can't open average time db /var/debbuild/avg-build-times
[08:02] <kb9vqf> Can't open average space db /var/debbuild/avg-build-space
[08:03] <kb9vqf> So I guess I'll need to find some way to set it
[08:04] <kb9vqf> Hmmm....actually I'm not sure that has anything to do with the mail address--I don't see sbuild in ps aux any more
[08:04] <kb9vqf> After the package is built it just uploads to Librarian, correct?
[08:05] <kb9vqf> Something isn't generating the changes file
[08:06] <kb9vqf> Causing this:
[08:06] <kb9vqf> 2010-06-11 01:58:51-0500 [-] Iterating with success flag 0 against stage SBUILD
[08:06] <kb9vqf> 2010-06-11 01:58:51-0500 [-] Returning build status: OK
[08:06] <kb9vqf> 2010-06-11 01:58:51-0500 [-] unexpected error in processEnded
[08:07] <kb9vqf> Followed by this:
[08:07] <kb9vqf> exceptions.IOError: [Errno 2] No such file or directory: '/home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9/<packagename>.changes
[08:09] <kb9vqf> Looks like gatherResults is failing as a result, and the builder gets stuck
[08:16] <kb9vqf> On further inspection this shows up in the builder log
[08:16] <kb9vqf> Can't find redmond-default-settings-kde3_10.04-7_amd64.changes -- can't dump infos
[08:17] <adeuring> good morning
[08:20] <kb9vqf> More fun...the changes file is present in /home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9/chroot-autobuild/build/buildd/<packagename>.changes
[08:20] <kb9vqf> So either a copy or symlink operation is not being run
[08:20] <kb9vqf> My hunch is a symlink is missing
[08:30] <kb9vqf> Maybe someone who knows the buildd system could be of help here ^^^ ;-)
[08:32]  * wgrant returns.
[08:33] <kb9vqf> wgrant: Any idea why the buildd would not be symlinking or copying the .changes file as described above?
[08:34]  * kb9vqf is so close to having this working...
[08:34] <wgrant> kb9vqf: Which version of Ubuntu is this?
[08:34] <kb9vqf> Lucid
[08:34] <wgrant> Your earlier mailto error suggests that you don't have a /home/buildd/.sbuildrc, which the package does create, so you've probably done something very strange.
[08:36] <kb9vqf> I just ran the commands in your howto
[08:36] <kb9vqf> Dunno what would be strange there
[08:36] <wgrant> Do you have a /home/buildd/.sbuildrc?
[08:36] <kb9vqf> No!
[08:36] <kb9vqf> Odd
[08:36] <kb9vqf> How is it supposed to be created?
[08:36] <kb9vqf> Oh wait a minute...I know how this broke
[08:37] <kb9vqf> I tried moving the home directory around a few times
[08:37] <wgrant> launchpad-buildd's postinst creates it.
[08:40] <wgrant> noodles775: Morning.
[08:41] <kb9vqf> I did a dpkg-reconfigure and the file was recreated successfully
[08:41] <kb9vqf> Now I get exceptions.AttributeError: 'BinaryPackageBuildManager' object has no attribute '_subprocess'
[08:41] <wgrant> Restart the buildd.
[08:41] <wgrant> You may have to also unmount and remove /home/buildd/build-SOMESHA1.
[08:41] <wgrant> And then maybe restart it again.
[08:41] <wgrant> Depending on how bad a start it's wedged in.
[08:42] <wgrant> s/start/state/
[08:42] <kb9vqf> OK
[08:43] <kb9vqf> Now that I know about the dot files I'll be more careful with the home directory
[08:46] <kb9vqf> Build is in progress...
[08:48] <noodles775> Hi wgrant
[08:49] <kb9vqf> wgrant: Same problem: http://pastebin.ubuntu.com/448134/
[08:50] <kb9vqf> At least the Email is resolved though
[08:50] <kb9vqf>  /Email/Email problem/
[08:50] <wgrant> noodles775: So, I had a look at that new massive getBuildQueueSizes query that landed a few days ago... and it seems to me that it can be replaced with a join over just BuildQueue, Job and Processor, rather than BuildPackageJob, BinaryPackageBuild, PackageBuild, DistroArchSeries, BuildFarmJob, Archive, Processor and BuildQueue.
[08:51] <wgrant> Since BuildQueue has virtualized and processor fields, and Job has the estimated duration, we don't need to join anything else.
[08:52] <wgrant> (plus the smaller solution works for generalised jobs)
[08:52] <mwhudson> morning
[08:52] <wgrant> So I'm wondering if that was just missed, or if there is some reason that I've missed.
[08:53] <wgrant> kb9vqf: Your chroot is the architecture it says it is?
[08:53] <kb9vqf> wgrant: Pretty sure
[08:53] <wgrant> Can you pastebin the whole build log?
[08:53] <kb9vqf> The problem seems to be that /home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9/chroot-autobuild/build/buildd/redmond-default-settings-kde3_10.04-7_i386.changes is not linked to /home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9/redmond-default-settings-kde3_10.04-7_i386.changes
[08:54] <kb9vqf> Yeah, hang on
[08:55] <noodles775> wgrant: sounds great. It may have just been missed - I asked stub for help and he just optimised what the query was currently doing. Do you want to update the bug with that info and we can try it out when there's time. (or if you've already got a branch that passes those tests, just link it).
[08:56] <noodles775> wgrant: and thanks for looking deeper rather than just accepting a solution that works!
[08:56] <kb9vqf> wgrant: The log files are huge; pastebin won't accept them
[08:57] <wgrant> Uh, well, the tests are pretty bad, but it passes them.
[08:57] <wgrant> kb9vqf: OK. So /home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9/chroot-autobuild/build/buildd/redmond-default-settings-kde3_10.04-7_i386.changes exists, with the right arch and everything?
[08:58] <kb9vqf> Yes
[08:58] <kb9vqf> There's even a correct .deb file sitting in /home/buildd/build-bb6a61d51a36b9892717c7a7f03321b7024338e9
[08:58] <wgrant> Um.
[08:58] <wgrant> So the .deb got copied/linked across, but not the .changes?
[08:58] <kb9vqf> Yes
[08:58] <kb9vqf> Weird, huh?
[08:59] <kb9vqf> And this with no error messages in the logs
[08:59] <wgrant> sbuild says nothing odd about it?
[08:59] <kb9vqf> Nope
[08:59] <kb9vqf> The first sign of trouble is when the .changes file can't be found
[09:00] <kb9vqf> wgrant: That might not be entirely true:
[09:00] <kb9vqf> 2010-06-11 01:58:50-0500 [-] Build log: Can't find redmond-default-settings-kde3_10.04-7_amd64.changes -- can't dump infos
[09:00] <kb9vqf> 2010-06-11 01:58:50-0500 [-] ******************************************************************************
[09:00] <kb9vqf> 2010-06-11 01:58:50-0500 [-] Build log: Built successfully
[09:00] <kb9vqf> 2010-06-11 01:58:51-0500 [-] Build log: Purging chroot-autobuild/build/buildd/redmond-default-settings-kde3-10.04
[09:00] <kb9vqf> 2010-06-11 01:58:51-0500 [-] Build log: ------------------------------------------------------------------------------
[09:00] <kb9vqf> I missed it earlier
[09:00] <wgrant> Aha.
[09:00] <wgrant> So it is an arch conflict.
[09:01] <kb9vqf> So I have the wrong chroot image?
[09:01] <wgrant> Hm. Do you have i386 and amd64 lp-buildds on the same system?
[09:01] <kb9vqf> Yes
[09:01] <wgrant> Ah.
[09:01] <kb9vqf> Well, I configured them that way at any rate, all based off of the single amd64 launchpad-buildd installation
[09:02] <kb9vqf> Separate systems in the future?
[09:02] <wgrant> I think that when I told you earlier that that was OK, I was remembering slightly incorrectly: /home/buildd/.sbuildrc contains an arch definition. I must have hacked that out to use 'dpkg --print-architecture' or similar.
[09:02] <kb9vqf> Yeah, I noticed that when you originally mentioned the .sbuildrc file
[09:02] <kb9vqf> I was wondering if it might cause problems
[09:03] <kb9vqf> I have another system I can use for i386
[09:03] <kb9vqf> I'll just set that up tomorrow
[09:09] <kb9vqf> wgrant: I temporarily changed the arch type in .sbuildrc and it actually works!
[09:09] <kb9vqf> Thanks a bunch!
[09:10]  * kb9vqf has learned a lot about Launchpad in the process
[09:12] <wgrant> Great.
[09:32] <wgrant> noodles775: Given the recent history, it might be nice to see that this query doesn't perform ridiculously badly on production like the old one. http://paste.ubuntu.com/448145/ has the new and old queries -- how can I go about verifying there's no regression?
[09:34] <noodles775> wgrant: Given that the current query will need to be updated to support general builds, I'd personally create a new bug, attach your branch and as we go through the normal process, part of it would be to involve stub to test the query on production.
[09:35] <noodles775> If you don't have time, let me know and I'll do it.
[09:35] <wgrant> I've just finished my last exam for a week, so I've time.
[09:35] <wgrant> Preparing a branch now.
[09:37] <noodles775> Great. Thanks!
[09:48] <bigjools> congrats wgrant
[09:48] <bigjools> you get a week off :)
[09:49] <wgrant> Heh.
[10:16] <bigjools> wgrant: Any jobs with no processor are currently always dispatched to i386  builders aren't they?
[10:16] <bigjools> oh actually maybe we don't create those any more thinking about it
[10:17] <wgrant> bigjools: Right, they are dispatched to any builder.
[10:17] <wgrant> But, um, we can't do that any more.
[10:17] <bigjools> we fixed something to send all TTBJ and SPRBJ to i386
[10:17] <bigjools> I can;'t remember if we forced i386 or changed the dispatcher code
[10:17] <wgrant> Right, they set their BQ.processor to i386.
[10:17] <bigjools> to assume it
[10:17] <bigjools> ok
[10:20] <wgrant> We might be better off just implementing multi-arch builders, I think.
[10:32] <maxb> wgrant: I seem to remember you wrote a more up to date version of http://williamgrant.id.au/f/1/2009/soyuzness.html, but I can't seem to find it. Can you direct me?
[10:32] <wgrant> maxb: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally may interest you.
[10:32] <wgrant> It has evolved into that.
[10:33] <maxb> ah. See, I just remembered I needed to google for "Soyuzness" :-)
[10:33] <mwhudson> wgrant: do you know where the code in lp is to make copy archives is?
[10:34] <wgrant> mwhudson: scripts/populate-archive.py
[10:34] <mwhudson> wgrant: ta
[10:34] <wgrant> And lp.soyuz.scripts.populate_archive
[10:40] <mwhudson> right, given a start pulling the thread is easier :)
[10:41] <wgrant> Right.
[10:43] <wgrant> maxb: What's causing you to stray into dangerous Soyuz territory?
[10:43] <maxb> curiosity :-)
[10:44] <maxb> potentially of the "killed the cat" variety :-)
[10:46] <wgrant> Heh.
[10:57] <deryck> Morning, all.
[11:03] <wgrant> gmb: Hm, so this proposed solution will see the From column in my mail client rendered useless?
[11:08] <gmb> wgrant, bear with me a sec, OTP
[11:13] <wgrant> I can perhaps see some benefit in avoiding use of the author's email address.
[11:13] <wgrant> But filling a field with completely redundant and useless information probably isn't the right solution.
[11:19] <gmb> wgrant, Hmm. I can see your point, though I confess that if the body of the email told me who had made a change or comment I wouldn't care too much about the From field. As it is, I only care about it when I get a message from the bug email address that doesn't tell me who actually made a change.
[11:19] <gmb> wgrant, It would be worth you adding your voice to the lp-dev discussion so that other people with more brains than I could discuss your points.
[11:20] <wgrant> gmb: When I'm looking through my bug mail, I am going to be more interested in responding quickly to a bug reported by a user than a developer.
[11:20] <wgrant> If I want to look back through a thread for an email, I can now do it easily simply by remembering who wrote it.
[11:20] <gmb> wgrant, Yes, I see your point.
[11:20] <wgrant> If you obliterate the sane From value, every email relating to a bug looks identical until you open it.
[11:23] <gmb> wgrant, True. And yet, the person whose name the email is sent in didn't actually send an email; it's an auto-generated notification sent by the application. Most webapps don't purport to send notifications from a user directly, AFAIK (I'm trying to think of one that isn't Launchpad that does).
[11:23] <wgrant> gmb: Not many do, no. And it's something that I love about LP.
[11:23] <wgrant> Because it doesn't gratuitously stuff its name in prominent places on all of my mail.
[11:24] <wgrant> It's in my Launchpad Bugs folder -- of course it's from Launchpad.
[11:24] <wgrant> I don't need another column to tell me that.
[11:24] <wgrant> The user performed the actions. They wrote the text.
[11:24] <wgrant> They are surely the author.
[11:24] <wgrant> And the author should be in From.
[11:26] <deryck> wgrant, I really think this is the correct way to send email from Launchpad bugs.  barry agrees.  There are technical benefits to doing so (e.g. batching).  The question really now is:  does the correctness/benefits outweight the loss of current functionality if we go this route?  Or does current functionality trump correctness/benefits?
[11:26] <deryck> wgrant, I know what you would say on this. :-)  We need others input, too.
[11:26] <wgrant> Erm, you're going to batch multiple comments together?
[11:26] <deryck> wgrant, potentially, yes.  But I suspect if so, it would be a configurable option.
[11:26] <wgrant> Can we please have a "please don't screw with my mail, I like it sane" flag?
[11:27] <bigjools> one man's sane is another man's madness
[11:27] <deryck> wgrant, shall I call it the "do you prefer your Launchpad like wgrant" option?
[11:27] <wgrant> bigjools: But this madness has been in place for five years and caused few complaints...
[11:27] <wgrant> And it makes LP a lot more transparent.
[11:27] <wgrant> Which is probably a good thing.
[11:28] <deryck> forging an email address is transparent? ;-)
[11:28] <bigjools> it's equivalent to people who like ML batch
[11:28] <wgrant> It means I can treat a bug as an email conversation. The bug tracker has a really nice email interface.
[11:28] <bigjools> I personally prefer individual emails too, but many people don't
[11:29] <deryck> bigjools, individual emails for comments, to be precise, no?
[11:29] <bigjools> yep
[11:29] <bigjools> you already coalesce status changes
[11:30] <didrocks> hey
[11:30] <deryck> bigjools, right.  but just pointing out it's a preference for a certain kind of individual email.
[11:30] <bigjools> absolutely
[11:30] <bigjools> I'm not disagreeing :)
[11:30] <deryck> :-)
[11:30] <wgrant> What are the benefits in batching more?
[11:30] <deryck> wgrant, less mail sent
[11:30] <wgrant> Er.
[11:30] <wgrant> So I don't get notified about bug activity for hours?
[11:30] <wgrant> That seems like a bug.
[11:31] <deryck> wgrant, I take your point, I really do.  And I agree if we change this, it is a serious change, and we should not do that lightly and get lots of input on it.
[11:31] <wgrant> Perhaps Launchpad needs to abandon its one-size-fits-all policy.
[11:31] <deryck> wgrant, no minutes still.  Just the comment is no longer the boundary.  And as I said, if we go this route, I seriously doubt we make it the default.  It's an option.
[11:32] <wgrant> I am trying to think of parts of the application that are configurable.
[11:32] <wgrant> All I can think of is the thing to show descriptions at the bottom of bugmail.
[11:32] <deryck> wgrant, branch subscriptions.
[11:32] <wgrant> Ah, true.
[11:35] <wgrant> I am glad that you are going to get lots of input.
[11:35] <wgrant> Because it didn't look like it a few days ago when a branch was proposed for merging without any discussion whatsoever.
[11:38] <deryck> wgrant, yes, we jumped the gun there, but didn't think this would be controversial.  Now we know and have changed our plans.
[11:38] <wgrant> Great.
[11:38] <deryck> wgrant, though to be fair, you are the only one passionate about the current form.  Most say "I like the current form" but don't argue why it is the one true way.
[11:38] <deryck> most who take this opinion, rather
[12:10] <wgrant> noodles775: Is the date_started on those 9 ill-fated builds going to be populated, in addition to the code fix?
[12:53] <ScottK> wgrant: Another point I would make is that the conversational nature of bugmail that you like may also encourage people to think of LP bugs like a forum.  That can certainly be problematic.
[13:11] <noodles775> wgrant: I wasn't planning to - unless there's a need. If the situation can happen again during the next release, my main concern is that it doesn't block peoples development efforts. Do you see a need?
[13:12] <noodles775> I'd be keen to spend any more time on that bug figuring out how we can ensure the data inconsistency doesn't happen at the db level.
[13:12] <wgrant> noodles775: It's not going to happen again, is it? It was a one-off issue in the migration.
[13:13] <wgrant> We can make the data less inconsistent easily with one-of setting of 9 values now. There is probably no other data like this. Eliminating it has to be a good thing.
[13:13] <noodles775> wgrant: I wasn't certain. As the data should have been consistent when the migration started. But haven't looked further.
[13:13] <noodles775> True.
[13:14] <noodles775> (Although, there is a lot of old data in a similar state... no date_started but successfully built).
[13:14] <wgrant> No date_started but successfully built is fine.
[13:14] <wgrant> No date_started, but successfully built *and with date_finished or builder* is not.
[13:14] <wgrant> gina creates successful builds with no dates or builders.
[13:15] <wgrant> My vision is that we will eventually be able to instead make it create BinaryPackageBuilds without a corresponding BuildFarmJob, but we'll see...
[14:15] <deryck> hmmm, we don't seem to be minifying js anymore.  at least in the lp.APP.javascript version.
[14:24] <maxb> deryck: In a clean branch or not? I've noticed some silly errors coming from that part of the build step when it's run in a branch where it has already run once.
[14:24] <maxb> Of course stupid stupid shhh.py will probably obscure this unless you turn it off :-(
[14:25] <deryck> maxb, yeah, I wonder if I have something hanging around.  Ran make clean_js though
[14:28] <deryck> good call about turning off SHHH though.  The noise may help me understand here.
[14:29] <gmb> mars, Is ec2 land safe to use now? I don't remember.
[14:34] <mars> gmb, it should be
[14:35] <gmb> mars, Cool, thanks.
[14:35] <mars> gmb, just haven't written the list yet.  Was waiting for buildbot to pass it
[14:38] <gmb> mars, Okay. In that case I'll do it the old fashioned way until you've confirmed it's fixed.
[14:48] <mars> sinzui or gary_poster, ping, do you know if any work was done on the +openid URL path recently?
[14:48] <gary_poster> mars, on call, but not to my knowledge
[14:48] <gary_poster> ask salgado?
[14:48] <sinzui> mars, no work on path, but I changed merge rules to avoid attempts to login to old Lp accounts
[14:50] <mars> sinzui, ok.  Not sure if that would do it.  buildbot and local are failing because the +openid URL has started returning a 404.  Strange because none of the recent landings appear related.
[14:52] <sinzui> I saw that before
[14:53] <sinzui> mars, did someone remove the old openid domain from the testrunner?
[14:53] <mars> The domain itself?  I don't know.  This tries to stay on the same domain by the looks of things
[14:54] <sinzui> mars, When we switched to Ubuntu SSO, we added the new domain for dev, but did not remove the old domain. Losts of tests use it. To remove the old domain, the tests need to switch to the new domain.
[14:54] <mars> salgado, ping, would you happen to know if any work was done on the launchpad +openid URL path recently?
[14:54] <mars> sinzui, do you know where that would be configured?
[14:54] <salgado> mars, don't know
[14:55] <sinzui> mars, I think +openid is the defunct url. it will not work in dev, but can work if the old vhost is started
[14:56] <sinzui> mars, testopenid.dev is new and in dev
[14:56] <sinzui> mars, openid.launchpad.dev and ubuntu-openid.launchpad.dev are old
[14:58] <mars> sinzui, odd.  IIRC the windmill tests don't cross domains when negotiating OpenID.
[14:58] <sinzui> That may be why we kept the old urls
[14:59] <sinzui> but someone could have disabled the servers in the testrunner
[15:00] <mars> now it looks like the logout button my be broken on dev as well
[15:02] <sinzui> mars, it has been broken for 4 weeks,, maybe more
[15:07] <mars> sinzui, I wonder why it is failing now then...
[15:08] <sinzui> Was there a config change made recently?
[15:09] <mars> going back to 10988 - no, nothing
[15:43] <kb9vqf> Is there a web interface where I can manage distroseries?
[16:31] <kb9vqf> In the database where are the pockets defined?
[16:46] <kb9vqf> Creating a new distribution...I figured out the distroseries, distroarch, and distribution tables, but poppy still won't accept uploads (says it can't find the distroseries)
[16:46] <kb9vqf> Did I miss a table?
[17:50] <kb9vqf> Creating a new distribution...I figured out the distroseries, distroarch, and distribution tables, but poppy still won't accept uploads (says it can't find the distroseries)
[17:50] <kb9vqf> Did I miss a table?
[17:51] <kb9vqf> Or, how would I create a new distribution and make it accept uploads?
[18:40] <kb9vqf> Any ideas on why this might happen when trying to upload to a manually created distroseries?
[18:40] <kb9vqf> 2010-06-11 17:30:11 INFO    Creating lockfile: /var/lock/process-upload-insecure.lock
[18:40] <kb9vqf> 2010-06-11 17:30:21 INFO    Processing upload redmond-default-settings-kde3_10.04-75656t_source.changes
[18:40] <kb9vqf> 2010-06-11 17:30:31 ERROR   Exception while accepting:
[18:40] <kb9vqf>  'NoneType' object has no attribute 'id'
[18:40] <kb9vqf>  -> http://quickbuild.pearsoncomputing.net:58080/155/cKHh1gV2I4VAtvWCgZvVlrkgYAI.txt ('NoneType' object has no attribute 'id')
[18:40]  * kb9vqf cant seem to find what is missing in the DB
[19:06] <deryck> rockstar, ping
[19:07] <rockstar> deryck, pong
[19:07] <deryck> rockstar, hey, dude.  You did the work to get js building from lp.$APP locations, right?  the lp-dep.py script, I mean.
[19:07] <rockstar> kb9vqf, is there a distro connected to the distroseries?
[19:07] <rockstar> deryck, yup, that's me.
[19:08] <deryck> rockstar, it doesn't minify the files.  I happen to be the lucky team to hit the 500k limit today because of it. :-)  So I'm playing with:  http://pastebin.ubuntu.com/448352/
[19:08] <deryck> rockstar, what do you think of that?
[19:09] <rockstar> deryck, wait, you want to minify the files that are only used in dev?
[19:10] <deryck> rockstar, no, I want launchpad.js to combine minified files, not the main files.
[19:10] <rockstar> deryck, ah, crap, I didn't realize it was doing that...  :/
[19:10] <rockstar> deryck, so I'm happy with launchpad.js combining minified files, but I was using a symlink because I don't want minified files used during development.
[19:10] <deryck> rockstar, yeah, ./bin/jsbuild normally takes care of it by passing in lib/canonical/launchpad/javascript as the BUILD_DIR
[19:11] <deryck> rockstar, right.  that makes sense.  This still links the non-min files in a real "bugs" or "code" directory alongside the debug and min files.
[19:12] <rockstar> deryck, okay, so long as we still have access to those unminified files during dev (otherwise, debugging would be a bitch)
[19:12] <deryck> rockstar, this is what link_and_minify does:  http://pastebin.ubuntu.com/448354/  (for the bugs directory as an example)
[19:13] <rockstar> deryck, ah, okay.  I'm good with that change then.
[19:14] <deryck> rockstar, ok, cool.  Thanks!
[19:14] <deryck> mars, can you look at the scrollback about this build change, since it relates to js.  You feel okay about what I'm proposing?
[19:45] <mars> deryck, those are ugly symlink paths, but if that gets things minified again, then +1 from me.
[19:46] <deryck> mars, ok, cool.  thanks.  The paths are just generated from lazr js builder.
[19:56] <mtaylor> hey all - I'm trying to run make schema from a recent pull and I'm getting Error: Couldn't find a distribution for 'zope.testing==3.9.4-p1'.
[19:58] <mars> mtaylor, checking
[19:58] <maxb> mtaylor: cd ~/launchpad/lp-sourcedeps/download-cache; bzr update
[19:59] <mars> mtaylor, a pull?  You didn't update the source dependencies
[19:59] <mars> (what maxb said :)
[19:59] <mtaylor> gotcha. thanks
[20:05] <deryck> mars, care to review my build changes for js?
[20:05] <kb9vqf> rockstar: Yes
[20:05] <rockstar> kb9vqf, what's the distribution?
[20:05] <kb9vqf> rockstar: Ubuntu
[20:05] <mars> deryck, sure
[20:06] <kb9vqf> I wanted it to be Debian, but that just pain wasn't workink
[20:06] <rockstar> kb9vqf, so I guess that eliminates the easy stuff.
[20:06] <deryck> mars, thanks!  https://code.edge.launchpad.net/~deryck/launchpad/minify-app-specific-js-592795/+merge/27395
[20:06]  * kb9vqf can't type
[20:06] <rockstar> kb9vqf, yeah, Launchpad doesn't support any distribution outside Ubuntu.
[20:06] <kb9vqf> Yeah I know
[20:06]  * kb9vqf has been hacking some along those lines
[20:09]  * maxb stares at the bzr history of launchpad-buildd and says "What?!"
[20:09] <maxb> Does lamont keep some other branch somewhere which is what really gets deployed?
[20:17] <mars> rockstar, your 500Kb JS warning just saved us a fair bit of trouble :)
[20:18] <mars> Kudos for that
[20:20] <rockstar> mars, That makes me quite happy then.  :)
[20:20] <rockstar> maxb, what's the issue?
[20:21] <maxb> only that it's really confusing to find unrelated production changes to launchpad-buildd landing back into devel via arbitrary feature branches
[20:22] <rockstar> maxb, only the packaging information.
[20:22] <rockstar> maxb, and that change keeps the buildds from killing itself.
[20:23] <maxb> "Do not check implicit pointers on 32-bit architectures" landed back onto devel as part of a merge "Enable building from recipe in the builder."
[20:23] <rockstar> maxb, oh, no idea there...
[20:24] <elmo> maxb: launchpad-buildd development is divorced from launchpad development; it sucks, and I'd love for it to stop, and I believe that is the medium term plan
[20:25] <rockstar> elmo, it's more "estranged" and we need to actually get the divorce papers signed.
[20:44] <mars> gary_poster, buildbot is green, guess the restart worked!
[20:44] <gary_poster> mars, cool.  Yeah, ec2 gets like that sometime. :-/
[21:25] <jelmer> win 23
[23:10] <wgrant> maxb: It's mostly developed in tree now.
[23:11] <wgrant> maxb: Since LP has mostly taken ownership.
[23:11] <wgrant> This has happened mostly within the last 6 months.
[23:12] <wgrant> But yes, historically the LP tree would occasionally get an update to the production version.