[00:08] the date the bug first/last (?) left the New state I believe [00:10] I think it was something that bryceh requested? [00:12] did I? [00:12] no then :-) [00:12] well maybe, I've got an absolutely horrible memory [00:13] I thought it was something you wanted to use in your scripts [00:13] maybe Brian for bug gravity? [00:13] yeah could have been bdmurray [00:13] hi bryceh, btw. Will we have the pleasure of your company at the platform sprint this time around? [00:14] hi james_w, actually no I'll be going to the launchpad sprint instead this go-around [00:14] but raof is well up to speed on anything X related you need help with [00:15] bryceh: of course, but we don't just like you for your X knowledge :-) [00:16] how uncommon! [00:17] there's your inkscape knowledge too... ;-) [00:18] jml: I'm pretty sure its the first time it left the new state [00:18] sadly atrophied [00:19] 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] thanks for the tip about searching for 'widgets' on openclipart.org, I'll try and make use of that sometime [00:19] bryceh: that sounds sweet [00:20] 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] (further enable) === Ursinha is now known as Ursinha-afk [00:42] krkhan: the apidoc is generated once, you should see changes if you 'make clean' [00:48] what creates _pythonpath.py? [01:04] make build? [01:09] gary_poster: still around?/ [01:10] * thumper is running make schema and cpu is spinning, but no apparent progress [01:10] thumper, bdmurrary, bin/buildout does. make compile should generate that along with a bunch of other stuff [01:10] running buildout [01:11] will run away in 60 seconds :-) [01:11] when running make I'm getting the following error [01:11] src/zope/security/_proxy.c:19:20: error: Python.h: No such file or directory [01:12] In file included from src/zope/security/_proxy.c:20: [01:12] gary_poster: still running... [01:12] 3 minutes plus now [01:12] oh [01:12] and now its off [01:12] why so slow today? [01:12] I don't remember it being so bad [01:12] * thumper knows [01:12] 2.6 right? [01:12] bdmurray: almost certainly python 2.5 -> python 2.6 change [01:12] new buildout [01:12] I need to run [01:12] I'm sorry [01:12] * thumper nods [01:12] ok [01:12] ttfn [01:22] bdmurray: make clean then make build === matsubara is now known as matsubara-afk [02:30] Why do we only run Windmill tests on a single browser? [02:39] wgrant: as opposed to? [02:45] thumper: More browsers. So we don't have half the world broken on IE and Chromium. [02:50] wgrant: I'm under the impression that windmill only works with firefox [02:51] thumper: That wouldn't be very useful. [02:51] It supports at least IE/Firefox/Chrome. [02:51] Probably Safari as well. [02:52] What's the point of it if you can only run your tests in a single browser? [02:52] ok, well we should be able to at least support chrome easily [02:52] IE is a bit of a problem for our test environment :) [03:02] http://www.getwindmill.com/features [03:03] that ism it supports IE/Safari/Firefox/Chrome [03:03] thumper: ie can run under wine [03:03] I think [03:03] or we can run it on ec2 [03:03] IE6/7 can mostly run OK in Wine. [03:08] can we run IE legally; vs technically? [03:08] spm: on ec2, yes [03:08] really? we don't have windows licenses aiui. ?? [03:08] really [03:08] not uec [03:08] ec2 [03:08] wgrant: take it to the dev mailing list, and it should become a foundations issue [03:08] QA has licensed EC2 images for running IE tests. Ask QA if you need to use them. [03:09] wgrant: I'd suggest a buildbot builder per different browser [03:09] spm: on ec2 windows images are windows-per-hour charged [03:09] spm: its all bundleablemagic [03:09] wgrant: we could run them in parallel initially [03:10] 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] 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] spm: interesting you should say that [03:11] 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] nice [03:13] vendor ? [03:13] Digital Equipment Corporation [03:13] ah [03:13] VMS clusters ftw [03:13] spm: plz fix launchpad, kthxbye [03:13] I went to uni at otago... largest dec networking install in the southern hemisphere [03:14] thumper: when you've ported it to vms? sure! [03:14] spm: surely a small issue like that won't stop you [03:15] 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] thumper, you can start using HDFS for branch storage while you're at it! [03:15] shouldn't be hard, right? [03:15] mars: we use Hard Disk for File Storage now :-) WFM [03:15] hehe [03:16] haha [03:45] stable to db-devel is failing at the moment [03:45] calculate-bug-heat [03:46] lifeless: yeah [03:46] I was going to get to it after my DB analysis [03:46] ok cool [03:47] * thumper is starting to file bugs and tweak the view [03:47] to make it suck less [04:32] Just to verify, all the icons in launchpad/icing are under Canonical copyright, correct? [04:33] It appears that way. [04:33] Can I still use the Ubuntu/Debian/Redhat icons in lauchpad/images though? [04:33] Well, just about everything is under Canonical copyright. But the icons and other images are under a much more restrictive license. [04:33] OK, I mean non-free licensing then [04:34] I have no idea why the Debian/Red Hat ones are there. [04:34] Me either ;-) [04:34] Just wanted to know if they were free or if I should just delete them [04:35] we should probably split that into a theme pack [04:35] How about the ones under icing/contrib? [04:35] Free or non-free? [04:35] I mean icing-contrib, sorry [04:36] Never mind, there are no images there! [04:36] * kb9vqf needs some sleep [04:39] sinzui: That new +participation of yours is awesome. [04:39] wgrant, almost [04:40] wgrant, awesome would let me change my mailing list subscriptions and leave a team [04:40] +1 [04:42] I was driven to make the changes because I could not be sure I dealt with ~drsganesh carnival of teams [04:42] :) [04:42] Haha. [04:43] 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] I hope to see if I am done with him when I wake up in 8 hours [04:44] Is the file icon-sprites automatically or manually generated? [04:44] kb9vqf: no idea [04:44] kb9vqf: There's a script to generate it. [04:44] Let me find it. [04:44] * kb9vqf breathes a sigh of relief [04:44] make sprite_image [04:44] I think. [04:44] Let me try it real quick [04:45] Although you may actually need to make sprite_css. [04:45] sinzui: so did someone speak to drs ? [04:45] wgrant: make sprite_image worked, thanks! [04:46] He did not directly reply to my email. I had remarked that he appeared to be registering team that were already projects. [04:46] the next day he started creating projects that were already registered [04:46] sinzui: Oh, nice. [04:50] wow [04:50] thats really non cooperative [04:51] I think I'm going to have to take iwlagn out back and shoot it [04:52] 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 === lifeless_ is now known as lifeless [06:45] spm: code import dispatcher just blew up [06:46] spm: on pear [06:53] 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] I am unsure because they are in the dependencies branch, not the actual Launchpad branch [06:56] LAZR/LP licensing is all a bit broken. [06:56] lifeless: bleh, ta. [06:57] 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] wgrant: please file bugs; thats not a situation we want. [06:58] 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] lifeless: what's the error message? or where? [06:59] spm: in cron, xmlrpc fault [06:59] 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] Well I guess I'll have to replace all of them then...I'm most of the way there anyway :-P [07:00] lifeless: gar. I had that folder on a 'loganberry' search. no wonder I couldn't see it. [07:00] I did notice the missing headers, all over the LAZR stuff [07:00] Not good [07:01] wgrant: the history doesn't bother me, for all that it is clearly unclear [07:01] lifeless: But there is code in there that Canonical doesn't even own. [07:01] wgrant: if a tarball of tip isn't clearly redistributable, thats more of an issue [07:02] wgrant: a situation many open source projects are in - configure scripts being the most common :) [07:02] A tarball of tip is pretty much OK, although some of the files have partially incorrect licensing headers. [07:02] lifeless: heh. https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1621XMLP2 \o/ [07:02] wgrant: so, my refrain - please file bugs, or patches :) [07:02] lifeless: OK, proprietary code that Canonical doesn't own, which I believe required a paid license. [07:02] wgrant: bzr has a tool to check headers automatically; might be useful for lp [07:02] wgrant: really? that surprises me [07:03] spm: ah, load load load [07:03] The old calendar widget, IIRC. [07:04] 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] And, well, I might file bugs after exams. === almaisan-away is now known as al-maisan [07:56] lifeless: huh. interesting, given we were stumbling on that last week(??): https://answers.edge.launchpad.net/launchpad-registry/+question/113354 [08:02] spm: the bug I filed got converted to a question until i convinced sinzui that it was really a bug [08:03] spm: it didn't need renaming :) [08:03] spm: gary_poster found the bug, in zope guts [08:06] oh, it's a real bug eh? [08:06] yes, fix already merged [08:06] the ++oops++ handler [08:06] typical, well, the project is renamed anyhoo. [08:06] gets treated as a traversal adapter [08:06] which it isn't [08:06] heh [08:06] so any namespace we add, like ++oops++, breaks all traversals that match its name. [08:07] as they say [08:07] 'oops' [08:07] spm: how did you go about renaming it? just via db ? [08:07] yup. like all blacklisted names [08:08] kk [08:08] (its not blacklisted :P) [08:08] :-) details. don't bore me wit hthe details. ;-) [08:12] spm: ok, take #34 - please pull. [08:12] :-) [08:12] whose on after you - tom ? [08:12] lifeless: hrm. we're running a U1 whatsit at the moment. problematic? [08:12] yup [08:13] no problem [08:13] kk [08:13] unless they are really really unlucky. Which they won't be. [08:13] rev 239 [08:13] thanks [08:13] * spm is tempted to quotes page that line. something suitably context misleading.... [08:14] I think I need a shower now [08:14] hahaha [08:21] 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] good morning [09:00] Hmm. [09:00] "No recipes based off of this branch." [09:01] Is 'based off of' valid non-colloquial English? [09:01] I would have thought it was 'based on'. [09:02] 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] Bug #591613: Recipes view oopses with +junk branches [09:03] * noodles775 updates the description with a note. [09:06] noodles775: Heh, yes, I did find it while looking at that bug. [09:06] That bug looks pretty critical, given that they are *source package* recipes. [09:07] Yep... Just found both while trying to record a quick screencast. [09:08] g'day [09:08] Morning bigjools. [09:46] 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] there was a thread about that [09:46] it's because ~launchpad has that as a contact address [09:51] yes [09:51] mwhudson: oh, I wanted to talk to you. [09:51] mwhudson: ... and I've no idea why. [09:51] lifeless: awesome [09:51] I think so. [10:10] 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] noodles775: Looks like we should really have some check constraints on the build tables... [10:43] 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] noodles775: Hm, well, there are a couple of places where it's set to None. [10:50] One using setDateStarted, so it wasn't trivially greppable. [10:50] But it's in the unknown status handler, so should never be invoked. [10:50] (really we should assert that, I think) [10:53] 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] Sometimes I'd really like buildd-manage to keep a full statement log. [11:01] Oh. BuildFarmJob doesn't delegate all the date_* to Job yet? [11:04] 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] (it would have required more schema changes). [11:04] noodles775: Um, it looks like date_started wasn't unset. jobStarted was never called in the first place. [11:05] (date_first_dispatched is None, and it's much easier to audit all callsites of that) [11:05] wgrant: that's another bug... [11:05] * noodles775 finds it. [11:05] bug 590699 [11:05] Bug #590699: IBuildFarmJob.date_first_dispatched is None [11:06] Are we sure it's not the same bug? [11:06] I can't see how it would be possible for jobStarted to never be called and yet result in a FULLYBUILT build. [11:07] 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] Ah. [11:07] https://edge.launchpad.net/~chromium-daily/+archive/beta/+build/1750601 has no date_first_dispatched, but it does have a date_started. [11:07] So it's a separate issue. [11:08] But that was built before 10.05... [11:08] And it still strongly suggests that jobStarted was never called, since it's pretty clear on what it does. [11:11] Oh. I wonder... [11:16] Hm, no. [11:20] noodles775: Ah... [11:20] ? [11:21] The specific_job is BuildPackageJob, which inherits BuildFarmJobOldDerived, which delegates to BuildFarmJobOld, and BuildFarmJobOld.jobStarted is a no-op. [11:21] So date_first_dispatched is not getting set anywhere. [11:21] * noodles775 looks [11:21] And date_started isn't being set there, but is being set elsewhere sometimes, it appears. [11:23] wgrant: BuildPackageJob *should* be delegating to self.build_farm_job, which is BuildFarmBuildJob, which implements jobStarted()? [11:23] But this network of classes and interfaces is seriously confusing at the moment. [11:24] Hm, let's see. [11:24] It is... it will be great to get rid of all the intermediate classes (ie. once the queue is refactored). [11:25] Yeah, you're right, it looks like it is being called. [11:26] Hm. [11:26] And indeed, it is set sometimes. [11:26] Gnargh. [11:26] Just the few I looked at had it None. [11:26] Also, i386 builders have had a fit again. [11:26] Yay recipes? [11:27] yep. bigjools is aware of it. And yes, the logs show recipes being dispatched. [11:32] 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] So jobStarted must somehow not be called in some circumstances. But this seems impossible. [11:37] noodles775: What's the purpose of all these Old classes? [11:38] 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] Oh, right. [11:38] Like DistributionSourcePackage and DistributionSourcePackageInDatabase. [11:38] Yes, that would have been a better naming scheme. [11:39] 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] But in retrospect, we should have named it something completely different, IMO. [11:39] Yep :) [12:07] 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] Finished at 20100602-1154 [12:08] :) [12:08] I found four or five, I think. A query to find them (excluding gina-generated ones, obviously) shouldn't be difficult, though... [12:09] Are there any that have no date_started but do have a date_first_dispatched? [12:09] yeah, I'm doing that now (I expect more, but it certainly looks like it was rollout-related). [12:09] There are some that have both, some that have a date_first_dispatched and no date_started, and some that have neither. [12:09] Er. [12:09] Some do have a date_started but no date_first_dispatched, not the other way around. [12:10] Yep, I'll find out and updated the bug. [12:10] Oh, so they were running during the rollout? [12:11] See the timestamps at the end of the logs for the builds without date_started. [12:13] Heh, yes, the migration script bug is obvious. [12:13] So we only have one real bug -- the date_first_dispatched one. Phew. [12:14] Yep... :D, one less fire to put out. [12:15] And it's even easy enough to manually populate the field. [12:19] 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] So we may in fact have no real bugs at all. [12:23] noodles775: ^^ have you found any missing date_first_dispatched values from after the rollout? [12:25] hangon. [12:26] wgrant: so, as expected, 9 completed builds since rollout with date_started not set. [12:27] and 2415 completed builds with date_first_dispatched not set. [12:27] 2415 since the rollout, or ever? [12:27] since the rollout (so it's not being set). [12:28] Curses. [12:28] But are there any set from before the rollout? [12:28] Probably not, but best to be sure... [12:28] Nope. [12:28] OK. [12:29] 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] Yay. [12:29] Let's see (what has it been used for historically? I can't see it displayed in the ui) [12:31] date_first_dispatched? Nothing whatsoever. [12:33] Its value may be useful in the case of retried builds. [12:33] But it's only ever been exposed over the API, and the way Soyuz handles retries is completely braindead anyway. === salgado is now known as salgado-lunch [13:01] Hi there, people, how big is the launchpad branch? [13:02] several hundred megabytes [13:03] maxb: Over 200MB ? [13:04] $ du -hs launchpad/lp-branches/.bzr/ [13:04] 180M launchpad/lp-branches/.bzr/ [13:04] huh, not as big as I thought [13:04] The LP branch itself is less than 200MB. [13:04] 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] But there are many hundreds of megabytes of dependencies. [13:05] Right, it will probably have to download 250-300. [13:05] wgrant: deps? I have already installed lp-devel-deps [13:05] bilalakhtar: There are several other dependency branches which rocketfuel-setup will download. [13:06] wgrant: you mean lp:lp-source-dependencies or there are even other ones? [13:07] bilalakhtar: That, plus perhaps a hundred megabytes of other smaller branches which will be downloaded into ~/launchpad/lp-sourcedeps/sourcecode [13:08] wgrant: rocketfuel-setup downloads lp:launchpad/devel first. Am I right? [13:08] yes. And so any extra bandwidth must be bzr being ineffiicent [13:09] Right. [13:09] I believe it then calls rocketfuel-get, which downloads the rest. [13:10] wgrant: I downloaded lp:launchpad/devel yesterday, and it did not take as much time as it is taking now. [13:10] i downloaded manually yesterday [13:10] and later deleted and used rocketfuel [13:10] 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] there's a bug for that [13:56] never got around to looking at it [13:56] I suspect it's where a package was copied and the original file expired === salgado_ is now known as salgado === henninge_ is now known as henninge [15:06] hi sinzui, after the reviewers meeting: what QA problem exactly are you talking about there? [15:07] bug-tag qa report verses kanban qa coiumns [15:07] sinzui, ah, I see, that [15:07] sinzui, the QA report is updated every 15 minutes, I guess [15:08] * Ursinha checks [15:08] that's correct, 15 minutes [15:08] The cards on Kanban disagreed with the qa tags. some bugs were reported qa-needstestings, but they were fore the previous release [15:08] sinzui, how is the kanban board updated, manually? [15:08] Manually [15:09] and the card may represent many bugs, or no bugs [15:09] sinzui, but if the bugs were from past releases, they don't show in current cycle QA reports [15:09] sinzui, I see [15:10] Ursinha, malone had a lot of 10.04 bugs and they did show up in launchpad-project/?tag=qa-needstesting [15:10] sinzui, ah, that's what you're calling QA report? [15:11] 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] deryck: ping [15:14] sinzui, agreed [15:21] micahg, hi [15:21] deryck: hi, I wanted to chat about the multi dupe move in LP [15:21] sinzui, that was largely just oversite on my part. I'm trying to watch my team and milestones closer. [15:21] micahg, ok, please do. bend my ear. :-) [15:22] deryck: so, I was thinking perhaps if dupes > 3, only bug control should be able to in case there are issues [15:22] deryck: i.e. either malicious or mistakes [15:22] micahg, ah, right. Someone did mention limiting to bug supervisor since there is potential for huge mistakes now. [15:23] micahg, I'm happy with this change. in the case of a bug with other dupes only, though. [15:24] deryck: k, is there a bug I should comment on/mark as affecting me? [15:24] * deryck looks for number.... [15:27] micahg, please add a comment to bug 591705 saying we discussed and we need some limit for this, etc. [15:27] Bug #591705: Add confirmation dialog when marking duplicate a bug that itself has duplicates [15:28] and, of course, subscribe if you like. :-) [15:28] 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] oh, cool. [15:30] deryck: what about a "reverse dupe merge" option? [15:30] micahg, elaborate, please. What do you mean? Undo the mess automatically? [15:31] deryck: well, a button for bug supervisor to reverse the duplication as a group [15:32] micahg, interesting idea. It's a non-small amount of work. [15:32] deryck: k, is it worth filing a place holder bug and adding it to my comment on the dupe bug? [15:33] micahg, yes, I think so. [15:34] micahg, do you see a downside to limiting moving a bug with dupes to just bug supervisors? [15:35] deryck: only that regular users can't help, but given the possible damage, I think it's a good tradeoff [15:36] micahg, ok, I agree. I wonder if we limit to bug supervisor, if the conf dialog is even required. [15:37] deryck: yes :) bug supervisors are human [15:38] deryck: bug 591749 [15:39] Bug #591749: Allow mass deduplication option for bug supervisors [15:39] micahg, fair enough :-) [15:40] deryck: so if the bug I just filed gets fixed, maybe we can open the ACL [15:41] thanks deryck [15:41] micahg, np. Thanks for the feedback and input. === leonardr is now known as leonardr-afk === Ursinha is now known as Ursinha-lunch [16:26] Right at this moment, there are exactly 6000 open bug reports about Launchpad. [16:27] flacoste, ^ :) [16:28] we should just close randomly 5500 of those and see how many gets re-opened :-) [16:32] Probably 100 or 200 of them have been fixed or become invalid without anyone realizing [16:33] i bet it's more than that [16:33] but i'm not about to start trying to prove it :) [16:33] * jml has plans [16:34] jml: go away, supposedly on leave person [16:35] oh, jml, I should send you some sketches I've been doing this week [16:36] 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] adeuring, the OPINION status is completely un-acl'ed, right? Like Invalid, right? [16:36] deryck: yes [16:37]