[00:08] <james_w> the date the bug first/last (?) left the New state I believe
[00:10] <james_w> I think it was something that bryceh requested?
[00:12] <bryceh> did I?
[00:12] <james_w> no then :-)
[00:12] <bryceh> well maybe, I've got an absolutely horrible memory
[00:13] <james_w> I thought it was something you wanted to use in your scripts
[00:13] <james_w> maybe Brian for bug gravity?
[00:13] <bryceh> yeah could have been bdmurray
[00:13] <james_w> hi bryceh, btw. Will we have the pleasure of your company at the platform sprint this time around?
[00:14] <bryceh> hi james_w, actually no I'll be going to the launchpad sprint instead this go-around
[00:14] <bryceh> but raof is well up to speed on anything X related you need help with
[00:15] <james_w> bryceh: of course, but we don't just like you for your X knowledge :-)
[00:16] <bryceh> how uncommon!
[00:17] <james_w> there's your inkscape knowledge too... ;-)
[00:18] <bdmurray> jml: I'm pretty sure its the first time it left the new state
[00:18] <bryceh> sadly atrophied
[00:19] <bryceh> james_w, but lately I have been doing some low level cairo experimentation for visualizing bug tasks that I'd like to show you some day
[00:19] <james_w> thanks for the tip about searching for 'widgets' on openclipart.org, I'll try and make use of that sometime
[00:19] <james_w> bryceh: that sounds sweet
[00:20] <bryceh> yeah there's not too much there yet, but I would bet that one or two people posting some additional widgets there could enable inkscape for mockups pretty quickly
[00:20] <bryceh> (further enable)
[00:42] <leonardr> krkhan: the apidoc is generated once, you should see changes if you 'make clean'
[00:48] <bdmurray> what creates _pythonpath.py?
[01:04] <thumper> make build?
[01:09] <thumper> gary_poster: still around?/
[01:10]  * thumper is running make schema and cpu is spinning, but no apparent progress
[01:10] <gary_poster> thumper, bdmurrary, bin/buildout does.  make compile should generate that along with a bunch of other stuff
[01:10] <thumper> running buildout
[01:11] <gary_poster> will run away in 60 seconds :-)
[01:11] <bdmurray> when running make I'm getting the following error
[01:11] <bdmurray> src/zope/security/_proxy.c:19:20: error: Python.h: No such file or directory
[01:12] <bdmurray> In file included from src/zope/security/_proxy.c:20:
[01:12] <thumper> gary_poster: still running...
[01:12] <thumper> 3 minutes plus now
[01:12] <thumper> oh
[01:12] <thumper> and now its off
[01:12] <thumper> why so slow today?
[01:12] <thumper> I don't remember it being so bad
[01:12]  * thumper knows
[01:12] <thumper> 2.6 right?
[01:12] <gary_poster> bdmurray: almost certainly python 2.5 -> python 2.6 change
[01:12] <thumper> new buildout
[01:12] <gary_poster> I need to run
[01:12] <gary_poster> I'm sorry
[01:12]  * thumper nods
[01:12] <thumper> ok
[01:12] <thumper> ttfn
[01:22] <gary_poster> bdmurray: make clean then make build
[02:30] <wgrant> Why do we only run Windmill tests on a single browser?
[02:39] <thumper> wgrant: as opposed to?
[02:45] <wgrant> thumper: More browsers. So we don't have half the world broken on IE and Chromium.
[02:50] <thumper> wgrant: I'm under the impression that windmill only works with firefox
[02:51] <wgrant> thumper: That wouldn't be very useful.
[02:51] <wgrant> It supports at least IE/Firefox/Chrome.
[02:51] <wgrant> Probably Safari as well.
[02:52] <wgrant> What's the point of it if you can only run your tests in a single browser?
[02:52] <thumper> ok, well we should be able to at least support chrome easily
[02:52] <thumper> IE is a bit of a problem for our test environment :)
[03:02] <lifeless> http://www.getwindmill.com/features
[03:03] <lifeless> that ism it supports IE/Safari/Firefox/Chrome
[03:03] <lifeless> thumper: ie can run under wine
[03:03] <lifeless> I think
[03:03] <lifeless> or we can run it on ec2
[03:03] <wgrant> IE6/7 can mostly run OK in Wine.
[03:08] <spm> can we run IE legally; vs technically?
[03:08] <lifeless> spm: on ec2, yes
[03:08] <spm> really? we don't have windows licenses aiui. ??
[03:08] <lifeless> really
[03:08] <lifeless> not uec
[03:08] <lifeless> ec2
[03:08] <thumper> wgrant: take it to the dev mailing list, and it should become a foundations issue
[03:08] <mars> QA has licensed EC2 images for running IE tests.  Ask QA if you need to use them.
[03:09] <thumper> wgrant: I'd suggest a buildbot builder per different browser
[03:09] <lifeless> spm: on ec2 windows images are windows-per-hour charged
[03:09] <lifeless> spm: its all bundleablemagic
[03:09] <thumper> wgrant: we could run them in parallel initially
[03:10] <spm> lifeless: granted; but we're not using windows instances on our test images; expect per mars' noting above. aiui, wgrant is referring to testing within the one image/instance. ??
[03:10] <lifeless> distributed is the now
[03:11]  * spm refrains from making rude comment about (oh to pick a name at random) oracle who haven't yet got that memo
[03:11] <lifeless> spm: interesting you should say that
[03:11] <lifeless> spm: given their clustering backend $magic they've been doing for a decade+ :)
[03:12]  * spm was working with systems in the early 90's that could be physically moved across a city without any downtime :-)
[03:12] <lifeless> nice
[03:13] <lifeless> vendor ?
[03:13] <spm> Digital Equipment Corporation
[03:13] <lifeless> ah
[03:13] <spm> VMS clusters ftw
[03:13] <thumper> spm: plz fix launchpad, kthxbye
[03:13] <lifeless> I went to uni at otago... largest dec networking install in the southern hemisphere
[03:14] <spm> thumper: when you've ported it to vms? sure!
[03:14] <thumper> spm: surely a small issue like that won't stop you
[03:15] <spm> lifeless: was always amusing at decus conferences; "Oh? you work in Canberra too? Which Department?" Resp:Attorney Generals "Hrm. But AG's is all Mac's. Oh wait. You're ASIO. NM, you can't confirm/deny." :-D
[03:15] <mars> thumper, you can start using HDFS for branch storage while you're at it!
[03:15] <mars> shouldn't be hard, right?
[03:15] <thumper> mars: we use Hard Disk for File Storage now :-) WFM
[03:15] <mars> hehe
[03:16] <spm> haha
[03:45] <lifeless> stable to db-devel is failing at the moment
[03:45] <lifeless> calculate-bug-heat
[03:46] <thumper> lifeless: yeah
[03:46] <thumper> I was going to get to it after my DB analysis
[03:46] <lifeless> ok cool
[03:47]  * thumper is starting to file bugs and tweak the view
[03:47] <thumper> to make it suck less
[04:32] <kb9vqf> Just to verify, all the icons in launchpad/icing are under Canonical copyright, correct?
[04:33] <wgrant> It appears that way.
[04:33] <kb9vqf> Can I still use the Ubuntu/Debian/Redhat icons in lauchpad/images though?
[04:33] <wgrant> Well, just about everything is under Canonical copyright. But the icons and other images are under a much more restrictive license.
[04:33] <kb9vqf> OK, I mean non-free licensing then
[04:34] <wgrant> I have no idea why the Debian/Red Hat ones are there.
[04:34] <kb9vqf> Me either ;-)
[04:34] <kb9vqf> Just wanted to know if they were free or if I should just delete them
[04:35] <lifeless> we should probably split that into a theme pack
[04:35] <kb9vqf> How about the ones under icing/contrib?
[04:35] <kb9vqf> Free or non-free?
[04:35] <kb9vqf> I mean icing-contrib, sorry
[04:36] <kb9vqf> Never mind, there are no images there!
[04:36]  * kb9vqf needs some sleep
[04:39] <wgrant> sinzui: That new +participation of yours is awesome.
[04:39] <sinzui> wgrant, almost
[04:40] <sinzui> wgrant, awesome would let me change my mailing list subscriptions and leave a team
[04:40] <lifeless> +1
[04:42] <sinzui> I was driven to make the changes because I could not be sure I dealt with ~drsganesh carnival of teams
[04:42] <sinzui> :)
[04:42] <wgrant> Haha.
[04:43] <wgrant> There is a bit of a bug due to the Role column's conflation of ownership and membership, but it's still a great step.
[04:43] <sinzui> I hope to see if I am done with him when I wake up in 8 hours
[04:44] <kb9vqf> Is the file icon-sprites automatically or manually generated?
[04:44] <thumper> kb9vqf: no idea
[04:44] <wgrant> kb9vqf: There's a script to generate it.
[04:44] <wgrant> Let me find it.
[04:44]  * kb9vqf breathes a sigh of relief
[04:44] <wgrant> make sprite_image
[04:44] <wgrant> I think.
[04:44] <kb9vqf> Let me try it real quick
[04:45] <wgrant> Although you may actually need to make sprite_css.
[04:45] <lifeless> sinzui: so did someone speak to drs ?
[04:45] <kb9vqf> wgrant: make sprite_image worked, thanks!
[04:46] <sinzui> He did not directly reply to my email. I had remarked that he appeared to be registering team that were already projects.
[04:46] <sinzui> the next day he started creating projects that were already registered
[04:46] <wgrant> sinzui: Oh, nice.
[04:50] <lifeless> wow
[04:50] <lifeless> thats really non cooperative
[04:51] <lifeless> I think I'm going to have to take iwlagn out back and shoot it
[04:52] <sinzui> maybe. I think he is clueless and thought he was helping. Since he didn't remove the teams I decided to do it for him
[06:45] <lifeless> spm: code import dispatcher just blew up
[06:46] <lifeless> spm: on pear
[06:53] <kb9vqf> Are the images sprinkled in lp-sourcedeps/eggs/lazr_js-0.9.2DEVr170-py2.5.egg/lazrjs/inlineedit/assets/skins/sam free or non-free?
[06:54] <kb9vqf> I am unsure because they are in the dependencies branch, not the actual Launchpad branch
[06:56] <wgrant> LAZR/LP licensing is all a bit broken.
[06:56] <spm> lifeless: bleh, ta.
[06:57] <wgrant> eg. the LP branch is not redistributable. Possibly not even legally possessible. And the image license restriction is too vague, and the LAZR stuff is even less clear.
[06:58] <lifeless> wgrant: please file bugs; thats not a situation we want.
[06:58] <kb9vqf> Great, so I could be on legally shaky territory if I allow public access to a custom installation even if I replaced all the image files?
[06:59] <spm> lifeless: what's the error message? or where?
[06:59] <lifeless> spm: in cron, xmlrpc fault
[06:59] <wgrant> I don't think access to it is much of a concern. But there's code in the history of the branch that is proprietary, files are missing license headers, and nobody is sure which images count and which do not.
[07:00] <kb9vqf> Well I guess I'll have to replace all of them then...I'm most of the way there anyway :-P
[07:00] <spm> lifeless: gar. I had that folder on a 'loganberry' search. no wonder I couldn't see it.
[07:00] <kb9vqf> I did notice the missing headers, all over the LAZR stuff
[07:00] <kb9vqf> Not good
[07:01] <lifeless> wgrant: the history doesn't bother me, for all that it is clearly unclear
[07:01] <wgrant> lifeless: But there is code in there that Canonical doesn't even own.
[07:01] <lifeless> wgrant: if a tarball of tip isn't clearly redistributable, thats more of an issue
[07:02] <lifeless> wgrant: a situation many open source projects are in - configure scripts being the most common :)
[07:02] <wgrant> A tarball of tip is pretty much OK, although some of the files have partially incorrect licensing headers.
[07:02] <spm> lifeless: heh. https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1621XMLP2 \o/
[07:02] <lifeless> wgrant: so, my refrain - please file bugs, or patches :)
[07:02] <wgrant> lifeless: OK, proprietary code that Canonical doesn't own, which I believe required a paid license.
[07:02] <lifeless> wgrant: bzr has a tool to check headers automatically; might be useful for lp
[07:02] <lifeless> wgrant: really? that surprises me
[07:03] <lifeless> spm: ah, load load load
[07:03] <wgrant> The old calendar widget, IIRC.
[07:04] <wgrant> kb9vqf: I suspect that the lazr-js images are OK, but there aren't many so you might as well replace them anyway...
[07:04] <wgrant> And, well, I might file bugs after exams.
[07:56] <spm> lifeless: huh. interesting, given we were stumbling on that last week(??): https://answers.edge.launchpad.net/launchpad-registry/+question/113354
[08:02] <lifeless> spm: the bug I filed got converted to a question until i convinced sinzui that it was really a bug
[08:03] <lifeless> spm: it didn't need renaming :)
[08:03] <lifeless> spm: gary_poster found the bug, in zope guts
[08:06] <spm> oh, it's a real bug eh?
[08:06] <lifeless> yes, fix already merged
[08:06] <lifeless> the ++oops++ handler
[08:06] <spm> typical, well, the project is renamed anyhoo.
[08:06] <lifeless> gets treated as a traversal adapter
[08:06] <lifeless> which it isn't
[08:06] <spm> heh
[08:06] <lifeless> so any namespace we add, like ++oops++, breaks all traversals that match its name.
[08:07] <lifeless> as they say
[08:07] <lifeless> 'oops'
[08:07] <lifeless> spm: how did you go about renaming it? just via db ?
[08:07] <spm> yup. like all blacklisted names
[08:08] <lifeless> kk
[08:08] <lifeless> (its not blacklisted :P)
[08:08] <spm> :-) details. don't bore me wit hthe details. ;-)
[08:12] <lifeless> spm: ok, take #34 - please pull.
[08:12] <spm> :-)
[08:12] <lifeless> whose on after you - tom ?
[08:12] <spm> lifeless: hrm. we're running a U1 whatsit at the moment. problematic?
[08:12] <spm> yup
[08:13] <lifeless> no problem
[08:13] <spm> kk
[08:13] <lifeless> unless they are really really unlucky. Which they won't be.
[08:13] <spm> rev 239
[08:13] <lifeless> thanks
[08:13]  * spm is tempted to quotes page that line. something suitably context misleading....
[08:14] <lifeless> I think I need a shower now
[08:14] <spm> hahaha
[08:21] <wgrant> gmb: Thanks for fixing bug #373683. Looking at the diff, though, it appears that in the case where the old bug was public you've forgotten to actually % in the number and summary (bugchange.py:374).
[08:24] <adeuring> good morning
[09:00] <wgrant> Hmm.
[09:00] <wgrant> "No recipes based off of this branch."
[09:01] <wgrant> Is 'based off of' valid non-colloquial English?
[09:01] <wgrant> I would have thought it was 'based on'.
[09:02] <noodles775> Me too... wgrant, can you comment on the bug... we could change it at the same time (assuming you're looking at bug 591613)
[09:02] <mup> Bug #591613: Recipes view oopses with +junk branches <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/591613>
[09:03]  * noodles775 updates the description with a note.
[09:06] <wgrant> noodles775: Heh, yes, I did find it while looking at that bug.
[09:06] <wgrant> That bug looks pretty critical, given that they are *source package* recipes.
[09:07] <noodles775> Yep... Just found both while trying to record a quick screencast.
[09:08] <bigjools> g'day
[09:08] <wgrant> Morning bigjools.
[09:46] <jkakar> Maybe this is a known issue, but I'm commenting (via the web UI) on my merge proposal for a launchpadlib branch and getting "Your message was rejected" messages from launchpad-bugs-owner@l.c.c.  Seems odd. :)
[09:46] <mwhudson> there was a thread about that
[09:46] <mwhudson> it's because ~launchpad has that as a contact address
[09:51] <lifeless> yes
[09:51] <lifeless> mwhudson: oh, I wanted to talk to you.
[09:51] <lifeless> mwhudson: ... and I've no idea why.
[09:51] <mwhudson> lifeless: awesome
[09:51] <lifeless> I think so.
[10:10] <jkakar> mwhudson: Ah, okay, thanks.  I just wanted to make sure it was a known issue and not something weird happening just to me.
[10:42] <wgrant> noodles775: Looks like we should really have some check constraints on the build tables...
[10:43] <noodles775> wgrant: yes... did you look at the code to see where date_started is set? It's only in the one place, when the status is also set :/
[10:50] <wgrant> noodles775: Hm, well, there are a couple of places where it's set to None.
[10:50] <wgrant> One using setDateStarted, so it wasn't trivially greppable.
[10:50] <wgrant> But it's in the unknown status handler, so should never be invoked.
[10:50] <wgrant> (really we should assert that, I think)
[10:53] <wgrant> But apart from that it's only set to None in retry, reset and jobReset. There's a bit of duplication there, which suggests that the code hasn't been looked at all together closely...
[10:53] <wgrant> Sometimes I'd really like buildd-manage to keep a full statement log.
[11:01] <wgrant> Oh. BuildFarmJob doesn't delegate all the date_* to Job yet?
[11:04] <noodles775> wgrant: no, I wasn't prepared to bloat that branch further... as you pointed out, it can be done just as easily afterwards.
[11:04] <noodles775> (it would have required more schema changes).
[11:04] <wgrant> noodles775: Um, it looks like date_started wasn't unset. jobStarted was never called in the first place.
[11:05] <wgrant> (date_first_dispatched is None, and it's much easier to audit all callsites of that)
[11:05] <noodles775> wgrant: that's another bug...
[11:05]  * noodles775 finds it.
[11:05] <noodles775> bug 590699
[11:05] <mup> Bug #590699: IBuildFarmJob.date_first_dispatched is None <Soyuz:Triaged> <https://launchpad.net/bugs/590699>
[11:06] <wgrant> Are we sure it's not the same bug?
[11:06] <noodles775> I can't see how it would be possible for jobStarted to never be called and yet result in a FULLYBUILT build.
[11:07] <noodles775> And no, not sure, but I'm also not sure that we can assume jobStarted was never called because the api (?) has date_first_dispatched as None.
[11:07] <wgrant> Ah.
[11:07] <wgrant> https://edge.launchpad.net/~chromium-daily/+archive/beta/+build/1750601 has no date_first_dispatched, but it does have a date_started.
[11:07] <wgrant> So it's a separate issue.
[11:08] <wgrant> But that was built before 10.05...
[11:08] <wgrant> And it still strongly suggests that jobStarted was never called, since it's pretty clear on what it does.
[11:11] <wgrant> Oh. I wonder...
[11:16] <wgrant> Hm, no.
[11:20] <wgrant> noodles775: Ah...
[11:20] <noodles775> ?
[11:21] <wgrant> The specific_job is BuildPackageJob, which inherits BuildFarmJobOldDerived, which delegates to BuildFarmJobOld, and BuildFarmJobOld.jobStarted is a no-op.
[11:21] <wgrant> So date_first_dispatched is not getting set anywhere.
[11:21]  * noodles775 looks
[11:21] <wgrant> And date_started isn't being set there, but is being set elsewhere sometimes, it appears.
[11:23] <noodles775> wgrant: BuildPackageJob *should* be delegating to self.build_farm_job, which is  BuildFarmBuildJob, which implements jobStarted()?
[11:23] <wgrant> But this network of classes and interfaces is seriously confusing at the moment.
[11:24] <wgrant> Hm, let's see.
[11:24] <noodles775> It is... it will be great to get rid of all the intermediate classes (ie. once the queue is refactored).
[11:25] <wgrant> Yeah, you're right, it looks like it is being called.
[11:26] <wgrant> Hm.
[11:26] <wgrant> And indeed, it is set sometimes.
[11:26] <wgrant> Gnargh.
[11:26] <wgrant> Just the few I looked at had it None.
[11:26] <wgrant> Also, i386 builders have had a fit again.
[11:26] <wgrant> Yay recipes?
[11:27] <noodles775> yep. bigjools is aware of it. And yes, the logs show recipes being dispatched.
[11:32] <wgrant> The transaction is clearly being committed, or the builder and job state wouldn't be set, and the slave would end up rescued next scan.
[11:32] <wgrant> So jobStarted must somehow not be called in some circumstances. But this seems impossible.
[11:37] <wgrant> noodles775: What's the purpose of all these Old classes?
[11:38] <noodles775> wgrant: BuildFarmJob already existed as an in-memory object used by the queue infrustructure, and yet provided a lot of the interface we needed.
[11:38] <wgrant> Oh, right.
[11:38] <wgrant> Like DistributionSourcePackage and DistributionSourcePackageInDatabase.
[11:38] <noodles775> Yes, that would have been a better naming scheme.
[11:39] <wgrant> Well, I think an uglier and more obscure one is probably better -- gives everyone more incentive to destroy it at the first possible opportunity.
[11:39] <noodles775> But in retrospect, we should have named it something completely different, IMO.
[11:39] <noodles775> Yep :)
[12:07] <noodles775> wgrant: how many builds are you aware of that have a null date_started? I can only see 4, and there's something in common about them all that might help explain:
[12:08] <noodles775> Finished at 20100602-1154
[12:08] <noodles775> :)
[12:08] <wgrant> I found four or five, I think. A query to find them (excluding gina-generated ones, obviously) shouldn't be difficult, though...
[12:09] <wgrant> Are there any that have no date_started but do have a date_first_dispatched?
[12:09] <noodles775> yeah, I'm doing that now (I expect more, but it certainly looks like it was rollout-related).
[12:09] <wgrant> There are some that have both, some that have a date_first_dispatched and no date_started, and some that have neither.
[12:09] <wgrant> Er.
[12:09] <wgrant> Some do have a date_started but no date_first_dispatched, not the other way around.
[12:10] <noodles775> Yep, I'll find out and updated the bug.
[12:10] <wgrant> Oh, so they were running during the rollout?
[12:11] <noodles775> See the timestamps at the end of the logs for the builds without date_started.
[12:13] <wgrant> Heh, yes, the migration script bug is obvious.
[12:13] <wgrant> So we only have one real bug -- the date_first_dispatched one. Phew.
[12:14] <noodles775> Yep... :D, one less fire to put out.
[12:15] <wgrant> And it's even easy enough to manually populate the field.
[12:19] <wgrant> And, um, I don't see anything in the DB patch that takes date_first_dispatched from BuildInfo and puts it into a permanent table.
[12:19] <wgrant> So we may in fact have no real bugs at all.
[12:23] <wgrant> noodles775: ^^ have you found any missing date_first_dispatched values from after the rollout?
[12:25] <noodles775> hangon.
[12:26] <noodles775> wgrant: so, as expected, 9 completed builds since rollout with date_started not set.
[12:27] <noodles775> and 2415 completed builds with date_first_dispatched not set.
[12:27] <wgrant> 2415 since the rollout, or ever?
[12:27] <noodles775> since the rollout (so it's not being set).
[12:28] <wgrant> Curses.
[12:28] <wgrant> But are there any set from before the rollout?
[12:28] <wgrant> Probably not, but best to be sure...
[12:28] <noodles775> Nope.
[12:28] <wgrant> OK.
[12:29] <wgrant> So we accidentally obliterated a whole lot of useless data, but we're still losing it somehow, so the massive confusion from earlier continues.
[12:29] <wgrant> Yay.
[12:29] <noodles775> Let's see (what has it been used for historically? I can't see it displayed in the ui)
[12:31] <wgrant> date_first_dispatched? Nothing whatsoever.
[12:33] <wgrant> Its value may be useful in the case of retried builds.
[12:33] <wgrant> But it's only ever been exposed over the API, and the way Soyuz handles retries is completely braindead anyway.
[13:01] <bilalakhtar> Hi there, people, how big is the launchpad branch?
[13:02] <maxb> several hundred megabytes
[13:03] <bilalakhtar> maxb: Over 200MB ?
[13:04] <maxb> $ du -hs launchpad/lp-branches/.bzr/
[13:04] <maxb> 180M	launchpad/lp-branches/.bzr/
[13:04] <maxb> huh, not as big as I thought
[13:04] <wgrant> The LP branch itself is less than 200MB.
[13:04] <bilalakhtar> maxb: Wierd... Yesterday when I branched devel it took only an hour and downloaded only 95MB. Now, its getting more than 200MB and is still in "Fetching Revisions: Inserting stream"
[13:04] <wgrant> But there are many hundreds of megabytes of dependencies.
[13:05] <wgrant> Right, it will probably have to download 250-300.
[13:05] <bilalakhtar> wgrant: deps? I have already installed lp-devel-deps
[13:05] <wgrant> bilalakhtar: There are several other dependency branches which rocketfuel-setup will download.
[13:06] <bilalakhtar> wgrant: you mean lp:lp-source-dependencies or there are even other ones?
[13:07] <wgrant> bilalakhtar: That, plus perhaps a hundred megabytes of other smaller branches which will be downloaded into ~/launchpad/lp-sourcedeps/sourcecode
[13:08] <bilalakhtar> wgrant: rocketfuel-setup downloads lp:launchpad/devel first. Am I right?
[13:08] <maxb> yes. And so any extra bandwidth must be bzr being ineffiicent
[13:09] <wgrant> Right.
[13:09] <wgrant> I believe it then calls rocketfuel-get, which downloads the rest.
[13:10] <bilalakhtar> wgrant: I downloaded lp:launchpad/devel yesterday, and it did not take as much time as it is taking now.
[13:10] <bilalakhtar> i downloaded manually yesterday
[13:10] <bilalakhtar> and later deleted and used rocketfuel
[13:10] <maxb> that was unnecessary
[13:55]  * maxb is disturbed to find that urls like https://edge.launchpad.net/~launchpad/+archive/ppa/+files/slony1_1.2.20.orig.tar.bz2 404
[13:56] <bigjools> there's a bug for that
[13:56] <bigjools> never got around to looking at it
[13:56] <bigjools> I suspect it's where a package was copied and the original file expired
[15:06] <Ursinha> hi sinzui, after the reviewers meeting: what QA problem exactly are you talking about there?
[15:07] <sinzui> bug-tag qa report verses kanban qa coiumns
[15:07] <Ursinha> sinzui, ah, I see, that
[15:07] <Ursinha> sinzui, the QA report is updated every 15 minutes, I guess
[15:08]  * Ursinha checks
[15:08] <Ursinha> that's correct, 15 minutes
[15:08] <sinzui> The cards on Kanban disagreed with the qa tags. some bugs were reported qa-needstestings, but they were fore the previous release
[15:08] <Ursinha> sinzui, how is the kanban board updated, manually?
[15:08] <sinzui> Manually
[15:09] <sinzui> and the card may represent many bugs, or no bugs
[15:09] <Ursinha> sinzui, but if the bugs were from past releases, they don't show in current cycle QA reports
[15:09] <Ursinha> sinzui, I see
[15:10] <sinzui> Ursinha, malone had a lot of 10.04 bugs and they did show up in launchpad-project/?tag=qa-needstesting
[15:10] <Ursinha> sinzui, ah, that's what you're calling QA report?
[15:11] <sinzui> No, that is pointing out we are not using Lp as we claim. That list should be near zero when we are closing PQM
[15:13] <micahg> deryck: ping
[15:14] <Ursinha> sinzui, agreed
[15:21] <deryck> micahg, hi
[15:21] <micahg> deryck: hi, I wanted to chat about the multi dupe move in LP
[15:21] <deryck> sinzui, that was largely just oversite on my part.  I'm trying to watch my team and milestones closer.
[15:21] <deryck> micahg, ok, please do.  bend my ear. :-)
[15:22] <micahg> deryck: so, I was thinking perhaps if dupes > 3, only bug control should be able to in case there are issues
[15:22] <micahg> deryck: i.e. either malicious or mistakes
[15:22] <deryck> micahg, ah, right.  Someone did mention limiting to bug supervisor since there is potential for huge mistakes now.
[15:23] <deryck> micahg, I'm happy with this change.  in the case of a bug with other dupes only, though.
[15:24] <micahg> deryck: k, is there a bug I should comment on/mark as affecting me?
[15:24]  * deryck looks for number....
[15:27] <deryck> micahg, please add a comment to bug 591705 saying we discussed and we need some limit for this, etc.
[15:27] <mup> Bug #591705: Add confirmation dialog when marking duplicate a bug that itself has duplicates <dupe-handling> <javascript> <Launchpad Bugs:Triaged by deryck> <https://launchpad.net/bugs/591705>
[15:28] <deryck> and, of course, subscribe if you like. :-)
[15:28] <micahg> deryck: I'm actually subscribed to Malone :)  I figure since I'm a heavy user of LP, it's good to know what's going on
[15:28] <deryck> oh, cool.
[15:30] <micahg> deryck: what about a "reverse dupe merge" option?
[15:30] <deryck> micahg, elaborate, please.  What do you mean?  Undo the mess automatically?
[15:31] <micahg> deryck: well, a button for bug supervisor to reverse the duplication as a group
[15:32] <deryck> micahg, interesting idea.  It's a non-small amount of work.
[15:32] <micahg> deryck: k, is it worth filing a place holder bug and adding it to my comment on the dupe bug?
[15:33] <deryck> micahg, yes, I think so.
[15:34] <deryck> micahg, do you see a downside to limiting moving a bug with dupes to just bug supervisors?
[15:35] <micahg> deryck: only that regular users can't help, but given the possible damage, I think it's a good tradeoff
[15:36] <deryck> micahg, ok, I agree.  I wonder if we limit to bug supervisor, if the conf dialog is even required.
[15:37] <micahg> deryck: yes :) bug supervisors are human
[15:38] <micahg> deryck: bug 591749
[15:39] <mup> Bug #591749: Allow mass deduplication option for bug supervisors <Launchpad Bugs:New> <https://launchpad.net/bugs/591749>
[15:39] <deryck> micahg, fair enough :-)
[15:40] <micahg> deryck: so if the bug I just filed gets fixed, maybe we can open the ACL
[15:41] <micahg> thanks deryck
[15:41] <deryck> micahg, np.  Thanks for the feedback and input.
[16:26] <mpt> Right at this moment, there are exactly 6000 open bug reports about Launchpad.
[16:27] <mars> flacoste, ^ :)
[16:28] <flacoste> we should just close randomly 5500 of those and see how many gets re-opened :-)
[16:32] <mpt> Probably 100 or 200 of them have been fixed or become invalid without anyone realizing
[16:33] <mwhudson> i bet it's more than that
[16:33] <mwhudson> but i'm not about to start trying to prove it :)
[16:33]  * jml has plans
[16:34] <mwhudson> jml: go away, supposedly on leave person
[16:35] <mpt> oh, jml, I should send you some sketches I've been doing this week
[16:36] <mpt> of "How do we get people excited about the possibility of contributing to Ubuntu", in the medium of Launchpad's distribution series overview page
[16:36] <deryck> adeuring, the OPINION status is completely un-acl'ed, right?  Like Invalid, right?
[16:36] <adeuring> deryck: yes
[16:37] <deryck> adeuring, excellent.  thanks.
[16:38] <mpt> Oh, lordy, that OPINION thing went ahead?
[16:49] <deryck> mpt, yes, it did.
[16:50] <deryck> mpt, were trying to have careful tracking of its usefulness, so that if it doesn't prove good, we can verify that and remove the status.
[16:50] <mpt> ok, good
[16:58] <mars> If there was some way to mark comments as either "evidence" or "discussion", then you can change the visual design based on which type the user wants to see.
[17:02] <mpt> see also bug 1734
[17:02] <mup> Bug #1734: Need ability to mark bug comments as obsolete <feature> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/1734>
[17:02] <mars> a four-digit issue, nice
[17:14] <abentley> noodles775, any tips on how to avoid 'read committed' assertion when testing handl_status_OK?
[17:15]  * noodles775 looks
[17:15] <mars> mpt, reading that thread reiterated in my mind how a simple 'fault' tag may be the best filter for engineers like myself.  I think on some days we would be happiest to ignore everything else.
[17:16] <noodles775> abentley: I'm not sure... i've never had it triggered.
[17:16] <abentley> noodles775, it looks like changing the layer from LaunchpadFunctionalLayer to LaunchpadZopelessLayer fixes it.
[17:17] <noodles775> ok.
[17:17] <mpt> mars, if I was designing it we'd just have states {Unconfirmed, Confirmed, Ready, In Progress, Done, Declined}. On your hack days you'd concentrate just on {Ready, In Progress}. Everything else would be the job of either design sprints or QA.
[17:19] <bigjools> abentley: buildmaster runs as zopeless
[20:50] <mars> gary_poster, ping, any idea what we should do about the DeprecationWarnings being raised by ec2 test now that we are on Python2.6?  Silence them or upgrade the offending library?
[20:52] <gary_poster> mars, I suggest that we silence them in lp_sitecustomize.py and add a bug.  However, if you are up for it and there's a new version of the library that claims to address the issue, you can give it a whirl in ec2 test pretty easily.
[20:52] <mars> gary_poster, just checked, pycrypto is the culprit, still on 2.0.1
[20:53] <gary_poster> silence is the order of the day then :-)
[20:53] <mars> lp_sitecustomize it is then
[21:30] <sinzui> gary_poster, ping
[21:31] <gary_poster> sinzui: pong
[21:31] <sinzui> gary_poster, do you have time to talk about canonical.launchpad and shipit?
[21:32] <gary_poster> sinzui: ...in about 30, at 5PM?
[21:32] <sinzui> thanks
[21:32] <gary_poster> cool
[21:55] <maxb> allenap: I like your simile
[21:55] <maxb> :-)
[21:58] <jelmer> aas/win 23
[22:01] <gary_poster> back to ya ;-)
[22:01] <gary_poster> sinzui: hey.  now?
[22:01] <sinzui> hi gary, mumble or skype
[22:02] <gary_poster> sinzui, either fine, but mumble is my default
[22:40] <thumper> sinzui: can I have a call with you after gary_poster?
[22:40] <gary_poster> we're done :-)
[22:40]  * sinzui starts skype
[22:48] <gary_poster> I will call it, "a day".  Look, a day!
[22:48] <gary_poster> bye
[23:26] <sinzui> thumper, https://bugs.edge.launchpad.net/launchpad-registry/+bug/58297
[23:26] <mup> Bug #58297: Making a project part of a project group should require project group owner's approval <feature> <oem-services> <registry> <Launchpad Registry:Triaged by sinzui> <https://launchpad.net/bugs/58297>
[23:59] <jml> http://people.canonical.com/~jml/convergence/