[00:33] Is someone visual on the need to initialize natty-cat-lpbuildd? [00:35] It probably won't ever happen. [00:36] Since we're moving to run bzr-builder outside the chroot. [00:36] But we had to roll production back from that. [00:36] Probably because bzr likes to eat RAM. [00:41] Hrm. Someone really should just copy maverick-cat-lpbuildd for now, so that natty recipe builds aren't unilaterally doomed until then [00:42] I suggested that. [00:43] mwhudson: Are you on the case with the importd breakage, or should I send a heads-up email to launchpad-dev@ to increase visibility of the problem? [01:10] maxb: a heads up email is probably a good idea [01:10] i'm completely clueless and there's no losa around now [01:11] hm, seems like there's a problem on staging too: https://code.staging.launchpad.net/~vcs-imports/pydoctor/trunk [01:43] ola [01:45] Afternoon. [01:51] anyone else seeing ': lp.code.model.tests.test_recipebuilder.TestDispatchBuildToSlave.test_dispatchBuildToSlave ' fail in devel ? [01:52] ugh yes, we're in testfix [01:53] Yeah, broken here. [01:55] care to do a binary chop to find the rev? [01:55] Its after 11936 [01:55] I presume 11938 [01:55] Yeah. [01:55] It can't have been tested. [01:56] Is that the only failure? [01:56] lets not jump to conclusions [01:56] no [01:56] forwarding you the mail [02:00] lifeless: Those are some interesting failures. [02:00] (the webservice ones) [02:01] yes [02:01] But http://pastebin.ubuntu.com/534111/ fixes the real failure. [02:02] 11938 changed the log level and added a new message. [02:03] thumper: https://bugs.launchpad.net/launchpad-code/+bug/677290 [02:03] <_mup_> Bug #677290: test_dispatchBuildToSlave (lp.code.model.tests.test_recipebuilder.TestDispatchBuildToSlave failing [02:06] lifeless: Ahh, the XML-RPC change. Of course. [02:06] lifeless: Also, bug #677270 raises a few issues: [02:06] <_mup_> Bug #677270: restricted librarian broken, content decoding error [02:07] 1) Some restricted files 404. [02:07] wgrant: my WAG about xmlrpc firewalling appears wrong. [02:07] 2) gzip encoding is set on the 404 page, when it's not gzipped [02:07] 3) It's not obvious to people that those URLs are meant to be private. [02:08] wgrant: well its up to them if they want to share it [02:08] lifeless: Everything else in LP requires a cookie. [02:08] wgrant: it was a design feature; we could make it one-time-use if we want [02:08] It's not obvious that the librarian URL is sufficient to grant access. [02:09] I don't think making them one-time tokens is a fantastic idea, but we should probably think about something. [02:09] wgrant: you have a valid issue, I don't know what to do right now, and a) importds and b) testfix and c) plane flights [02:09] lifeless: Of course. [02:09] (also, 11938 can't have been tested -- it was in the queue too soon after the review) [02:15] wgrant: 404's - no idea why, file bugs. [02:15] wgrant: gzip? zomg. file a patch. [02:16] lifeless: I suspect they're related. I can't see why it 404s in that case, and it only gzips in that case. [02:16] thumper: ping [02:17] bac: ping [02:17] abentley: perhaps you're still here? [02:17] hmm, bzr upgraded to 2.2.1 on the -11 in devel [02:17] [work wise] [02:17] what are the chances that got rolled out on the 15th? [02:18] mwhudson: have a look between 11887 and 11926 [02:18] lifeless: FSVO "here". === lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.11 | PQM open for 10.12 | firefighting: importd system failing to import | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [02:18] abentley: we've got a firefight on our hands, and I'm about to be offline for an extended period [02:19] abentley: I'm looking for a volunteer to get the incident report rolling, and handoff to someone in asia as soon as such a person can be located [02:19] lifeless: if it turns out to be the bzr upgrade, i'll try to get a downgrade organized [02:19] lifeless: i can do that [02:19] mwhudson: thanks [02:20] mwhudson: I haven't tweeted or anything [02:20] mwhudson: thanks. [02:20] i can do that too [02:20] mwhudson: you'll need to cowboy [02:20] lifeless: if it's the bzr upgrade, that's easy [02:21] mwhudson: because https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html is out of date [02:21] mwhudson: we can't tell whats up qa wise. [02:22] lifeless: fantastic [02:22] I think we need to do a manual check and nodowntime deploy of the revision that merged db-stablew [02:22] then it will work again. [02:22] mwhudson: also we're in test fix [02:22] mwhudson: per https://bugs.launchpad.net/launchpad-code/+bug/677290 [02:22] <_mup_> Bug #677290: test_dispatchBuildToSlave (lp.code.model.tests.test_recipebuilder.TestDispatchBuildToSlave failing [02:23] mwhudson: so, I don't see any sane option except cowboy [02:23] yeah [02:23] at least the code import systems are isolated [02:23] in that touching them isn't going to **** up anything else [02:23] https://devpad.canonical.com/~lpqateam/oops-summaries/code-import-2010-11-18.html claims very few oopses [02:24] well, very few imports are running [02:24] because the average import time has increased by like 300 [02:24] mwhudson: it only had 16 [02:24] if every import is failing [02:24] that is low [02:24] I'd still expect more than 16 attempts a day [02:25] yeah, should be 4*2*24 or so [02:25] https://lp-oops.canonical.com/oops.py/?oopsid=1783CIW11 [02:25] has room to improve [02:25] mwhudson: so, definitely a bug on why didn't see it [02:26] === Top 10 Time Out Counts by Page ID === [02:26] Hard / Soft Page ID [02:26] 282 / 56 Person:+commentedbugs [02:26] 101 / 5112 Archive:+index [02:26] 83 / 256 BugTask:+index [02:26] 31 / 317 Distribution:+bugs [02:26] 28 / 2 LoginToken:+accountmerge [02:26] 24 / 241 POFile:+translate [02:26] 21 / 28 Person:+bugs [02:27] 16 / 14 DistroSeries:+queue [02:27] 11 / 0 BinaryPackageBuild:+retry [02:27] 10 / 403 Distribution:+bugtarget-portlet-bugfilters-stats [02:29] 13:27:02 < lifeless> 11 / 0 BinaryPackageBuild:+retry [02:29] That is disturbing. [02:37] I don't have the oops code sorry [02:39] wgrant: so are you seeing folk copying and pasting the restricted urls into public channels or some such ? [02:40] lifeless: Just the one bug so far. [02:41] experienced user? new user? [02:42] Not sure. Bug #677270 [02:42] <_mup_> Bug #677270: restricted librarian broken, content decoding error [02:42] OEM. [02:43] well i can reproduce locally [02:44] The importd thing? [02:44] yesd [02:46] yes, it's the 2.2.1 upgrade [03:02] wth! [03:03] it's hanging somewhere inside of SFTPTransport.__del__ [03:03] hi lifeless, mwhudson: i just got the ping for this issue. i can help later if you need to hand off [03:04] bac: thanks, i will need to fairly shortly [03:04] mwhudson: fwiw, the links in the bug report download ok in webkit-browsers [03:04] bac: that's not the issue i'm working on :-) [03:04] mwhudson: i'm in a meeting right now but will be around later [03:04] hm, seems present in 2.3b1 too... [03:10] mwhudson: do you know who is working on the issue lifeless raised? wgrant? [03:10] bac: no [03:11] which issue? [03:11] bac: I've raised enough I don't know to which you refer [03:12] lifeless: the one you pinged me about. the one requiring an incident report and a handoff to someone in asia. sorry if i didn't comprehend the full scrollback. just trying to get up to speed. [03:12] bac: mwhudson is currently handling it [03:13] bac: he will want to handoff to you within the hour [03:13] oh sorry [03:13] ok [03:13] Also, someone needs to land that testfix. [03:13] bac: perhaps you could to that ^ too ? [03:13] if you have time [03:17] lifeless: i can in a bit when i get out of this meeting [03:36] wgrant: where is the testfix branch? [03:36] Well that was bizarre. LP just temporarily decided I didn't have permission to view https://code.launchpad.net/+code-imports/+machines [03:41] i bet a code import branch that was private could do that [03:41] pretty sure we don't filter for visibility anywhere [03:41] bac: I don't have a branch. But there's a patch on https://bugs.launchpad.net/launchpad-code/+bug/677290 which I could turn into a branch if you don't want to. [03:41] <_mup_> Bug #677290: test_dispatchBuildToSlave (lp.code.model.tests.test_recipebuilder.TestDispatchBuildToSlave failing [03:43] bac: i'm running away [03:54] well done mwhudson ! [04:02] Project devel build (229): STILL FAILING in 3 hr 41 min: https://hudson.wedontsleep.org/job/devel/229/ [04:02] Launchpad Patch Queue Manager: [r=danilo][ui=none][bug=676657] Memory-limit recipe builds. [04:02] sinzui: https://bugs.launchpad.net/malone/+bug/244998 - looks like a candidate for bridging the gap to me [04:02] <_mup_> Bug #244998: "Also affects project" is inconsistent and obscure when in package context [04:06] wgrant: is https://bugs.launchpad.net/soyuz/+bug/251685 happening still? [04:06] <_mup_> Bug #251685: PPA upload hangs with 1K to go [04:06] lifeless: I think so. [04:07] lifeless: We've certainly not knowingly fixed it (although it doesn't affect the SFTP version of poppy). [04:11] is there a new styleguide-type requirement introduced by the 'no more globs' launchpad changes? [04:11] just trying to work out how to resolve conflicts in import statements in the right way [04:11] whatever works, try not to re-export things where possible. [04:12] poolie: utilities/format-imports forces imports to match our style. But that's not changed directly by the anti-glob policy. [04:12] not that its evil in principle, but the export * from foo idiom is pretty unmaintainable., [04:14] sure, i just saw it now imports many things from different places [04:14] i'll just tweak it if they fail [04:20] has anyone seen [04:20] KeyError: 'STORM_CEXTENSIONS' [04:23] run 'make [04:23] ' [04:23] thanks, that was my guess [04:23] new storm eggs seem to be missing the C extensions or some such [04:24] it happens to me every storm upgrade we do [04:26] thanks wgrant. i have to relocate and will look at that patch shortly === Ursinha-afk is now known as Ursinha [04:31] I think we need to do something about the footer. [04:32] about its appearance? [04:32] The fact that it tells people to file bugs against Launchpad. [04:32] we're getting about a bug a day for Ubuntu [04:32] Sometimes several. [04:32] but OTOH we were getting that before anyway [04:32] its a little higher frequency but really not a Big Deal [04:32] The frequency increased immensely once the footer made it onto production. [04:33] wgrant: mmmm, I'd like stats for that actually [04:33] "Please report any problems with Launchpad." has a highly ambiguous "with" :-) [04:33] yes [04:33] improvements appreciated [04:33] its in lp-production-configs [04:33] "I have a persistent self of ennui" [04:34] seems like that could merge with "contact support" too [04:34] Ah hm. [04:34] That link bypasses all the warnings. [04:34] although for that matter if someone lands on an ubuntu bug page, "contact support" is an obvious way to ask about problems with ubuntu [04:34] which one? [04:35] oh wow, so much fail [04:35] Please describe the bug in a few words, for example, "weather applet crashes on logout": [04:35] it's _really_ inviting people to file ubuntu bugs, isn't it? [04:35] https://launchpad.net/launchpad-project has a bit of a warning, but it's not terribly obvious. [04:35] There is also a warning at the bottom of the page once you've entered the summary and description. [04:36] But that's it;. [04:36] i thought there was a way to put text onto the filebug page? [04:36] conveniently below the fold on my browser [04:36] There is. [04:36] Yeah. [04:36] For this case it probably needs to be in a yellow alert above the initial dupesearch. [04:36] and anyhow, once people have entered their text, they're fairly invested in continuing [04:36] Although mpt will probably throttle me for suggesting that. [04:36] Yeah. [04:37] And you have to read a lot of text to see the warning. [04:37] If only we had a designer. [04:38] a little bird told me 'soon' [04:39] lifeless: The problem with AJAX file uploads is that they're impossible. [04:39] You have no choice but to post a form in an iframe. [04:40] is that what gmail does? [04:40] I don't know... it's been quite a few years since I used it. [04:40] But probably. [04:40] i think they prefer to use a flash component [04:40] * wgrant vomits. [04:41] otherwise i think it's blocking but imbw [04:44] I wish bug listings could be convinced to show a set of tags. [04:44] ciao [04:44] sayonara [05:08] jml, dkim tests are running, we'll see what happens [05:38] wgrant: shall we file a bug for the footer problems? [05:38] there might be an mpt bug already [05:38] poolie: It was restricted to edge until its demise. [05:38] So there's probably not an existing bug. [05:38] really? the whole footer? [05:38] or just the invitation to file bugs [05:38] Just the invitation. [05:39] i'll file one then [05:39] Thanks. [06:02] ok bug 677342 and bug 377339 [06:20] poolie: you still there? [06:47] hi, i am [06:47] wallyworld_: i am [06:48] poolie: i had to go out for a few hours - belinda's car broke down in the middle of a car park :-(, had to get tow truck etc, but i think i saw that the lp bzr 2.2.1 upgrade has broken something? [06:49] that sucks about the car [06:49] yeah :-( will be expensive [06:49] was that the old one or the new one? [06:49] the new(er) one [06:49] anyhow, apparently gc of an sftp socket causes a hang [06:50] i tihnk it's now resolvede [06:50] ok. and that behaviour came about due to the upgrade? [06:50] they rolled back to 2.2.0? [06:50] Right, the importds are back on 2.2.0. [06:50] And it's probably already fixed in the 2.2 branch. [06:50] just the importds? [06:50] so it should stay fixed when they go to 2.2.2 [06:51] ok. so 2.2.2 should be released around nowish? [06:51] so i should upgrade lp to that? [06:52] are there any tests i should have run apart from the test_bzr* ones when i did the lp upgrade to 2.2.1? [06:53] indeed, it should be pretty soon [06:53] not that i know of [06:53] could be worth finding the particular bug [06:54] yep. i'm not entirely across the importds stuff. i just want to not see the same thing happen next time [06:54] iwbn if we could upgrade just one importd first and see how it behaves [06:54] in the code review for the 2.1.1 upgrade, i listed the bzr tests i ran [06:55] but, perhaps it's not so bad, it's not immediately user critical if they have trouble [06:55] don't all the tests get run? [06:55] LP doesn't run the bzr tests, but presumably the bzr tests ran before 2.2.1 was released. [06:55] yes, when it lands via ec2 which it did. but i also specifically ran a few by hand first [06:56] wgrant: yes, i ran the ones i found, something like test -vvt test_bzr* [06:57] wgrant: there were the ones i mentioned in the mp comments. i was hopeing that if there were any others i would be told to run them [06:57] s/there/these/ === almaisan-away is now known as al-maisan [07:22] jtv: hi? [07:22] hi [07:23] hi, i'm just looking at your parallel build stuff [07:23] it's great it's done [07:23] some of the use of phony targets is a bit strange though [07:23] i think we can do even better [07:24] in particular i think we shouldn't depend on the phony target buildout_bin, but rather on $(BUILDOUT_BIN), the actual files [07:24] or perhaps on specific files, like $(PY) [07:24] were the $(PY) dependencies not catching everything we needed? [07:25] Heh… what you're saying is pretty much the way it was. :) [07:25] ok, and it didn't work? [07:25] The old way broke with parallel builds. [07:25] There were two problems: [07:25] yes, i know [07:26] i was trying to fix some of them myself [07:26] It'd be fine AFAIC to depend on $(PY) instead of on buildout_bin where appropriate. [07:26] (I really just got annoyed with the different ${PY}/$(PY) spellings) [07:27] :) [07:27] So if you want to make that change, go ahead. I don't think it'll change anything in the effects, since depending on $(PY) will still require the buildout_bin target to be built. [07:28] (Which is the way it needs to be in order to avoid breakage) [07:28] Yes, definitely a lot of room for improvement still and nice to hear you're interested. [07:28] the problem with depending on a phony target is [07:28] everything that depends on it must always be rebuilt [07:28] True. [07:29] since it does not exist on disk, make can't know it's up to date [07:29] I missed that. [07:29] secondly, when you put that on the left hand side, and you do "rm $@", make tries to delete buildout_bin [07:29] and doesn't delete the files it previously was deleting [07:29] Whoopsie! [07:29] :) teamwork :) [07:30] Actually I took out the $(RM) at one point. [07:30] i just worked out why that's there (i think) [07:30] which is that buildout tries to be smart and not touch the file if the contents would be the same [07:30] unfortunately then make always rebuilds it [07:31] Gah. [07:31] Wouldn't a "touch" have sufficed then!? [07:31] i think so [07:31] i'm kind of inferring it [07:32] I have a feeling that this would solve another problem. [07:33] I did run into an unnecessary rebuild at one point when I tried "make -j3 default schema" (with the don't-build-everything-for-schema patch). Made one of the targets fail. [07:33] it might [07:34] That makefile needs some love. [07:34] getting more precise makefile rules is generally good [07:34] buildout!!! [08:01] poolie: …and the stupid thing bounced again. Did I miss anything? [08:01] not sure [08:01] https://code.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/41268 [08:01] are my suggestions [08:02] let me know what you think? [08:02] "It would be great if we could also avoid the fairly slow js build [08:02] happening every time..." [08:02] Why should the JS build take more than a second? [08:04] i don't know [08:04] for me it does, doesn't it for you? [08:04] It does, yeah. [08:04] it's well over 10s on my laptop; i really notice it [08:04] I just think we should make it less insane rather than reducing the frequency at which we call it. [08:04] There's no reason for it to take a non-trivial amount of time! [08:05] is it just catting the files, or is it doing complicated optimization? [08:05] It's some lazr.js voodoo. [08:05] I don't know what lazr.js is meant to do. [08:06] thus my shallow inclination to call it less [08:06] Or just delete it like U1 did. [08:12] could be good [08:12] ok, good night [08:13] Night. === al-maisan is now known as almaisan-away [08:29] good morning [08:30] Moin adeuring ;) [08:30] hi henninge! [08:32] hi adeuring [08:32] hi bac === adeuring1 is now known as adeuring [09:03] Guten morgen === Guest77235 is now known as jelmer [10:27] Yippie, build fixed! [10:27] Project devel build (230): FIXED in 4 hr 2 min: https://hudson.wedontsleep.org/job/devel/230/ === almaisan-away is now known as al-maisan [11:09] $ time make -j2 [11:09] real 1m38.038s [11:09] \o/ thanks jtv [11:11] bigjools: my pleasure... poolie got in on the game too, so expect more improvements soon [11:17] jtv: I can't work out why -j4 takes longer [11:18] bigjools: otp, will explain in a bit [11:18] no prob === Guest54849 is now known as jelmer [11:18] I'm trying to make the webservice pick up my interface in the new brave world of post-jml interfaces apocalypse, and failing miserably. === matsubara-afk is now known as matsubara [11:21] does this look ok? http://pastebin.ubuntu.com/534239/ [11:21] bigjools: back. About -j4: of course 2 CPUs don't necessarily give you a 2× speedup, because the real bottleneck is often memory. That much is obvious. [11:21] jtv: right, I suspect it's disk-bound [11:21] will try on my SSD in a sec [11:21] * jtv won't be any help to bigjools about that pastebin, and wait for someone else [11:22] bigjools: I don't think it's I/O—then -j4 would help you cover the latency and so be faster, assuming you have plenty of memory. [11:22] But because of that, running multiple threads/processes at the same time will slow down each of them individually. [11:23] jtv: if it's thrashing the disk head it'll be slower [11:23] Of course. [11:23] But I don't think the footprint will be large enough to do that. [11:24] I've seen the same problems when running parallel test suites by virtue of VMs [11:24] I haven't kept up with I/O schedulers; sure there may be a bit of extra seeking. [11:24] make -j2 on a fresh branch bails out with bin/py missing [11:25] Dependencies still aren't entirely complete, I guess. Martin found a missing one earlier today. [11:26] In any case, as per my email, there's currently not much theoretical gain left beyond -j2 because the wadl script is the bottleneck. [11:27] This is one of those nasty things in parallelization: if you distribute n+1 tasks across n CPUs, what's your ideal speedup? [11:27] The answer is n/2. [11:27] Which is very disappointing. [11:28] :( [11:28] In the theoretical ideal case, n jobs finish n× faster than with 1 CPU, and then n-1 CPUs sit around twiddling thumbs while the lucky one does the one remaining job, still at the same speed. [11:28] since we write three wadls, won't -j3 help? or is something else at play [11:29] We'd have to break up the script. One nasty thing there is we'd pay 3× the ZCML overhead. [11:29] urgh [11:29] In parallel, ideally, but that's no good to whoever isn't joining the SMP party. [11:29] I think ZCML is really costing us quite a lot. [11:29] both my boxes have 4 cores. It makes me weep to see them idle :) [11:30] You'll be interested to know that, because of the slowdown effect I mentioned earlier, AMD is actually dropping SMT. [11:30] Because multiple threads will still slow down a single thread, and by and large people simply have enough cores now. [11:30] reading *all* the zcml is costing us a lot [11:31] Do we ever do less? === al-maisan is now known as almaisan-away [11:31] we read it all in every startup. It's crazy. We talked about moving it to registering via code on the ML some time ago [11:33] I haven't looked much further but I get the impression that, with my next makefile tweak, "make schema" is basically 45 seconds of "spend several seconds processing zcml… do something very quickly, done. Start new script: spend several seconds processing zcml... work flash done. Start new script:" etc. [11:35] I got the last question at James Clark's XML presentation last month. I asked him to swear that neither he, nor any of the other team members to his knowledge were taking money from CPU or memory vendors. :) [11:36] bigjools: I'm still not getting any problems with "make -j2" on a fresh branch. Are you sure you were using the updated Makefile and that you'd run the link-sourcecode script first? [11:37] jtv: I * thought* I was... but it seems ok now. Ho hum. [11:37] Well that's the problem with debugging parallel builds. Everything goes Heisenberg. [11:38] :) [11:38] now I am surprised. My i5 with SSD is slower than the AMD Phenom [11:39] And the second time you run it? [11:39] doing so now [11:39] I mean, again on a clean branch [11:39] it failed [11:39] but with the good stuff in fscache [11:39] failed!? [11:39] error about import gpgme ... ! [11:39] ran again and it worked [11:40] yes, it's Heisenberg [11:40] That's a missing dependency. [11:41] I get the impression that some of the targets' dependencies were written from a mental model of "build this, then this, then that." [11:41] And some of them are definitely missing. [11:41] quicker 2nd time, still 3 seconds slower than the old Phenom [11:42] Is it a dual-core? [11:42] 4 core [11:43] well, the i5 is a fake 4 core [11:43] Part of the fun of optimizing CPUs for this sort of thing is that the applicability of your benchmarks matters hugely. [11:43] it's got the old hyperthreading guff [11:43] Vendors like AMD and Intel have their internal benchmarks. [11:43] random gpgme import fail again [11:43] From the wadl script? [11:44] Did you run a "make clean" between builds? [11:44] yes [11:44] * jtv tries frantically to reproduce the problem [11:44] it's failing quite often [11:44] if I run again without a clean it works and continue [11:44] s [11:44] Though I went through that "make clean ; make -j2" routine so often that I would have seen it by now. [11:45] I'll paste in a bit [11:45] I've seen a failure like that, but with "make -j3 default schema" and the lightweight "make schema." [11:45] I guess it's just too system-specific or something. [11:46] bigjools: just for my piece of mind, could you grep ^buildout_bin Makefile ? [11:47] jtv: it's on my other machine so not easy to paste, were you expecting output? [11:47] Yes. [11:47] it's a fresh devel pulled down 20 mins ago [11:47] Then it should have the updated makefile, definitely. [11:48] It may just be the problem Martin spotted, where the virtual buildout_bin target gets re-built unnecessarily. [11:49] jtv: http://pastebin.ubuntu.com/534245/ [11:53] bigjools: where did you get that verbose output? [11:53] jtv: the command I used is at the top of the paste [11:54] I don't see that subvertpy build output though. [12:02] Morning, all. [12:11] adeuring, hey, did you see lifeless' email on the librarian? Do you have time today to get that landed for him? [12:11] bigjools: looks right to me [12:11] jml: that's what I thought too - but the stuff is not in the wadl :/ [12:11] bigjools: hmm. [12:11] bigjools: debugging this stuff is a pain too. [12:12] yes === almaisan-away is now known as al-maisan [12:12] I've put deliberate typos in the zcml and the interface to see if they get read, and they do [12:13] webservice.py I mean [12:14] bigjools: do you actually have the webservice interface decorators in builder.py? [12:14] jml: yes, my branch worked fine until your changes landed [12:14] bigjools: yay inventory :) [12:14] bigjools: umm... hmm... thinking. [12:15] I've moved off to something else until leonard shows up :) [12:15] bigjools: not a bad idea. I'll background it while I go off and pay for the drinks I forgot to pay for last night. [12:15] lol [12:16] left the CC behind the bar? [12:16] not even that. they had table service and when we were done we just waltzed out not even thinking that we had to pay. [12:16] anyway, off. back soon enough. [12:17] and, dine and dash [12:35] jml: ahhh make -j3 is fastest yet on my i5 [12:36] jtv, sorry [12:37] bigjools: that's unexpected… I have no idea how CPU governors will play into this btw. [12:37] Say you have 4 cores and 2 build processes, and maybe postgres and some other daemon that both wake up to do work from time to time. [12:37] Say each tends to stick to one core. [12:38] 1m42s fwiw [12:38] Not bad. [12:38] Though slower than -j2, no? [12:38] better than the 5m it used to take! [12:38] I get something like 1:32 on -j2 [12:38] Yes, that's what I did it for. :-) [12:38] hmmm I was getting 1m53s on -j2 [12:38] Poor boy. [12:39] Then I guess this is good, yes. :) [12:39] * bigjools will try and beat 1:32 [12:39] But it also means that the performance characteristics are very different in your setups. [12:39] Mine are pretty consistent, and that may explain how a missing dependency could be "hidden" on my machine fairly consistently. [12:40] Surprising how you don't seem to bottleneck on the wadl build. [12:40] Are you sure the wadl build is completing? Maybe benji's optimization landed already? [12:41] deryck: yes, I've seen his mail. but I haven't found yet much time to look at the test failures [12:41] bigjools: Can you access it if you ignore the WADL? [12:41] wgrant: que? [12:42] bigjools: What if you try to retrieve a builder through the API manually, not using the WADL at all. Does that work? [12:42] wgrant: I don't know how to do that [12:42] bigjools: Browse to https://launchpad.dev/api/devel/builders/bob [12:42] well, I probably do but I can't remember [12:43] jtv: -j2 is 2:12 ! [12:43] bigjools: why not the 1:53 you got before? [12:43] who knows [12:45] bigjools: what does your load graph look like with -j2 or -j3? Is there a lot of time where you've got only 1 CPU busy? [12:46] I'll check later - busy running tests now [12:46] adeuring, ok. Do you think you'll have some time today to look at it? [12:46] ah windmil, I hate you [12:47] deryck: well, hard to say. Right now, I'm looking a bit more, but if anybody wants a review... ;) [12:47] adeuring, right. I understand. If you have time, great. If not, np. [13:22] wgrant: yeah it works without the wadl [13:22] bigjools: Have you tried deleting the WADL to force its regeneration? [13:22] That's sometimes needed. [13:22] yes [13:22] :( [13:22] make clean until my fingers bleed [13:23] I'm not sure that's enough. [13:23] it is [13:23] it removes the whole apidoc dir [13:23] Hm, should be, yeah. [13:23] and I see it getting re-generated on the next make [13:23] :( [13:23] I've run into this before. But I cannot remember how I resolved it. [13:25] ISTR there needs to be a magic string in the interface somewhere [13:25] otherwise the wadl parser ignores it [13:26] bigjools, what are you doing? [13:26] trying to export a new interface? [13:27] james_w: I had something that worked until jml got rid of canonical.launchpad.interfaces, now I've added some zcml + a webservice.py in lp.buildmaster but it dunt werk [13:28] but yeah it's a new export of IBuilder [13:28] You're sure that ZCML file is actually included? [13:28] yes [13:28] buildmaster is a little incomplete. [13:28] you added a webservice:register? [13:28] yep [13:28] should work then :-) [13:28] yep :) [13:29] https://code.launchpad.net/~julian-edwards/launchpad/api-expose-builders/+merge/39379 [13:31] bigjools, what's the collection you export? [13:31] /builders [13:32] bigjools, and no builder stuff ends up in the wadl? [13:32] nada [13:33] I can't see anything obvious, sorry === mrevell is now known as mrevell-lunch [13:36] thanks for looking [13:36] I'm going to eat and hopefully Leonard will be around when I get back [13:44] reboot. brb. === mrevell-lunch is now known as mrevell === jaycee is now known as jcsackett [14:07] Project devel build (231): FAILURE in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/231/ [14:07] Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=677020] The advanced subscription features [14:07] are now flagged correctly on the StructuralSubscriptionView. [14:19] jelmer, bigjools: ping [14:20] abentley: hey [14:20] jelmer: can we chat about async uploads and source pagackge recipe builds? [14:21] bigjools: it occurs to me that leonardr won't be around today. === matsubara is now known as matsubara-lunch [14:26] abentley: yes, sure. mumble? [14:26] jelmer: sure. [14:28] jelmer: https://bugs.launchpad.net/launchpad-code/+bug/676776 [14:28] <_mup_> Bug #676776: Recipe build stuck with "Uploading build" status [UI] [14:36] jelmer: http://pastebin.ubuntu.com/534287/ === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === Ursinha is now known as Ursinha-lunch [14:58] jml: bugger [14:58] in that case, hey benji! [15:00] hey bigjools, what's up? [15:00] benji: I've got an API problem, do you have a moment to help please? [15:00] sure [15:00] great, thanks. Can you look at this branch https://code.launchpad.net/~julian-edwards/launchpad/api-expose-builders/+merge/39379 [15:01] it exposes /builders on the API. It used to work before the canonical.launchpad.interfaces removal [15:01] I added the extra zcml declaration and webservice.py in lp.buildmaster [15:01] but it still doesn't generate the wadl [15:01] I'm at a bit of a loss [15:03] looking [15:22] bigjools: I couldn't find a problem by inspecting the diff so I built your branch and it seems the WADL and HTML docs were built correctly; there's an entry for "builder" that includes the description "Builder instance represents a single builder slave machine..." [15:22] benji: what about /builders ? [15:23] that's the first line in the test and it fails [15:23] more to the point does xx-builders.txt work there :) [15:24] I'll run it... [15:24] in the mean time, try rebuilding the WADL like so: LPCONFIG=development bin/py ./utilities/create-lp-wadl-and-apidoc.py --force "lib/canonical/launchpad/apidoc/wadl-development-%(version)s.xml" === matsubara-lunch is now known as matsubara [15:30] benji: trying that now - what are all those "Unknown entry URL:" things about? [15:31] I vaguely remember us having to do something about those in the past but then everyone stopped bothering [15:31] benji: and re-generating the wadl didn't help :( [15:31] I don't know the full details, but it's XSLT not being told to be quiet about a particular element or value. [15:32] darn [15:32] I have a feeling something was needed in lazr.restful [15:32] benji: another thing comes to mind, I have another vague recollection of having to put some magic string in the interface somewhere to make the wadl generator see a top-level collection [15:32] I'm still trying to run the xx-builders.txt test. (make schema, librarian kill error message) [15:34] bigjools: I got this error "AttributeError: 'Launchpad' object has no attribute 'builders'" [15:34] benji: that's it [15:34] "builders" is not in the wadl [15:34] ok, cool; digging deeper [15:34] thanks === Ursinha-lunch is now known as Ursinha [15:48] abentley: loads of codehosting tests always fail locally for me (mercurial module missing for example), do we have missing dependencies in sourcecode or the dep packages? [15:49] bigjools: I haven't heard of that problem before. [15:50] problems seem to follow me [15:51] bigjools: mercurial is provided as an egg. [15:52] I see it in eggs [15:52] bigjools: It's not bzr-hg? That's provided in sourcecode. [15:54] bigjools: Try "bin/py -c 'import mercurial'" [15:54] abentley: it's failing when doing "from mercurial import error as hg_errors" with "No module named mercurial" [15:55] bigjools: And when you try it from bin/py, does it puke? [15:55] yes [15:56] bigjools: Something is wrong with your mercurial egg, then. [15:56] it's the bzr-hg stuff in sourcecode that's importing it [15:56] seems so [15:57] bigjools: You could torch your eggs directory and run "make". [15:59] jelmer: It appears that upload failures cause two emails now: A "build-style" "failed to upload" message and an upload-style "rejected" message. [15:59] abentley: yeah :/ [16:00] abentley: this is sprb failure emails specifically? [16:00] jelmer: Yep. Why would anyone care about binary builds :-D [16:01] abentley: with our analysis from earlier this afternoon in mind, that would make sense. [16:01] bigjools: here's the fix: http://pastebin.ubuntu.com/534311/ [16:01] benji: argh! [16:02] jelmer: perhaps processChangesFile is the wrong place for notification? [16:02] thanks... I feel stupid now [16:03] abentley: Hmm [16:03] jelmer: It could raise exceptions, and then the caller could handle them appropriately according to the upload type, perhaps. [16:03] abentley: yeah trashing the eggs worked [16:03] thanks [16:03] abentley: The special casing in PackageUpload.notify() is what's biting us there, too. [16:03] rockstar, ping a ring a ling [16:04] bigjools: I'm glad. [16:05] deryck, what's going gangster? [16:05] rockstar, you know, livin' large, kickin' js ass and takin' names. [16:06] deryck, straight. [16:06] rockstar, so question about your work on this branch initially-- [16:06] deryck, shoot [16:06] rockstar, did you link all yui modules in base-layout-marcro, or make some determination about which we actually used? [16:06] deryck, I only added the ones that were complaining on the pages that I looked at. [16:07] ah, crap. I worried about that. [16:07] rockstar, so this could be the smallest number we can get away with? [16:07] deryck, yeah, although it might be bringing in things it may not care about anymore as well. [16:07] deryck, that's a long shot though. [16:08] rockstar, since we don't do dynamic loading, how can it bring in something? Requirements should be a straight chain, no? [16:08] benji: I think I'm going to file a bug about that. Silently failing is wrong. [16:10] it's probably a good idea to file a bug, but I suspect the silence is by design; you can enable different parts of a web service using ZCML, so how can it know when you intentionally don't want to expose a service and when you do? [16:11] also, export in __all__ so it's obvious that it is being imported to be re-exported [16:11] rather than for some kind of side effect or by accident [16:12] deryck, well, I meant "maybe we're manually bringing in a file for a dependency that doesn't exist anymore in YUI 3.2" [16:12] ah, right [16:12] ok, that makes sense. I'll just poke at it to see. [16:14] benji: right - at least I think it should warn about things declarated but not exported. [16:14] declarated? I mean declared. [16:15] that might work [16:19] deryck, so we're basically concluding that it's the size of the js file that's causing all these headaches? [16:20] rockstar, it is indeed the size of the file. I'm 100% certain of that. [16:33] deryck, that's unfortunate. [16:35] rockstar, yeah. and yui without any lp js code is 1.1 of that 1.3 mb. and getting it smaller is hard. Just cut 250 files (around datatype) and got it to 900Mb. [16:37] deryck, that's odd. U1 has yui AND the U1 code down to ~870K. [16:37] deryck, are you including lazr-js in the "yui" you speak of? [16:37] rockstar, perhaps we're including too much then. [16:37] rockstar, I thought lazr-js was compiled separately to lazr.js [16:37] deryck, no, not in launchpad it's not. [16:38] deryck, at least, I'm pretty sure it's not. [16:38] ah, I see now. It is but included in launchpad. js. if I'm reading this right. let me play some more.... [16:43] rockstar, yeah, so with our yui deps, I get 1020k. That's no lazr.js and no code from the lp tree. Using the files you linked in base-layout-macros.pt [16:43] rockstar, perhaps we can trim some, but that's still a pretty ginormous file. === benji is now known as benji-lunch [16:53] rockstar, do you remember what the exact source of the 512K JS file bug was? [16:53] socket code? Gzip hard-coded limit? === al-maisan is now known as almaisan-away [17:15] mars, it was spinning on a socket call, yes. [17:16] mars, but we found that it was indeed a 512K limit, and I put code in there to halt when it's larger. [17:17] Unfortunately, I disabled that in the branch that is now deryck's because I thought "Oh, at this point, either windmill will have fixed the bug, or we'll have to disable windmill." [17:18] rockstar, do you have any pointers to where the discussion may have been? #tarmac, a LP bug, #launchpad-dev? [17:18] mars, I believe the discussion was on the mailing list. [17:19] rockstar, ok, thanks, that is somewhere to start [17:24] jelmer: in that bug, the user said he received an email, not two. I wonder if the failure happened sending the second email? [17:28] abentley: that would certainly explain a lot. [17:28] abentley: since it's the second email that was attempting to access the 'builder' table. === benji-lunch is now known as benji === Ursinha is now known as Ursinha-afk [19:17] Launchpad Development Channel: Pulling (mirrors, imports) now fixed. | Week 4 of 10.11 | PQM open for 10.12 | firefighting: importd system failing to import | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [19:18] Launchpad Development Channel | Week 4 of 10.11 | PQM open for 10.12 | firefighting: pulling (mirrors, imports) now fixed. | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting === timrc_ is now known as timrc === Ursinha-afk is now known as Ursinha [19:47] deryck, ping [19:47] hi sinzui [19:47] deryck, I am looking at a css issue with this page: https://bugs.launchpad.net/launchpad [19:48] The rounded border around the form is only used on this page and only when a search was not performed [19:49] deryck, It is messing with font color. I need to fix it to put a branch in review, but I do not think this style should exist. Why does this form need an exceptional style? [19:49] * sinzui should see if .portlet looks right [19:50] has anyone tried to see if maxb's bzr fix helps the code import situation yet? [19:51] sinzui, it doesn't need it's own style. Was just a design element that was preserved. We can drop the border if it gets you going. [19:54] deryck, using the portlet classes, the page might look like this: http://people.canonical.com/~curtis/upstream-bugs.png [19:54] sinzui, +1. Looks better to me actually. [19:56] deryck, my branch is near done, but I am dissatisfied with how I am leaving it [19:56] sinzui, how so? [19:57] deryck, I expect the link the evolution in ubuntu to retry my search in ubuntu. It does not because or a common bug with this form. The search param are not added to the Advanced|Simple search links [19:58] I see there is a method that will encode the params for a URL. Deryck, to you know of a reason why we do not want to ensure the params are appended to these alternate search links [19:59] sinzui, I see no reason not to append. I assume it's just oversight that it doesn't currently. [20:00] I will start a second branch to see if I can fix this. this will also mean that changing the sort order will preserve the query [20:00] ah [20:01] I see now. We need to fix the refine this search/search again problem because we do not know if the user is starting a new search [20:01] right, that makes sense [20:01] If this works, I will fix 3 or more bugs [20:09] g'night all. [20:12] thanks for taking this on, sinzui. [20:13] np. I am sure I will benefit from the fix if I can land it === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === matsubara is now known as matsubara-afk === Ursinha is now known as Ursinha-afk [21:55] Project devel build (232): STILL FAILING in 3 hr 43 min: https://hudson.wedontsleep.org/job/devel/232/ [21:55] * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=666838] Export /builders and IBuilder on [21:55] the webservice. [21:55] * Launchpad Patch Queue Manager: [r=adeuring][ui=none][no-qa] Fix spurious test failure in [21:55] test_message_sharing_migration. [21:55] * Launchpad Patch Queue Manager: [r=jcsackett, [21:55] sinzui][ui=sinzui][bug=667900] Add form to DistributionSourcePackage [21:55] +index page to set upstream project link more easily. [21:55] * Launchpad Patch Queue Manager: [r=jcsackett, [21:55] sinzui][ui=none][bug=677077] Find merge proposal by revno [21:55] * Launchpad Patch Queue Manager: [r=allenap][ui=salgado, [21:55] sinzui][bug=670431] Suggest branch owner as recipe owner [21:55] * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=673590] Change the log level of [21:55] QueueInconsistentStateError during upload processing so that [21:55] the logger handler for cron scripts doesn't generate OOPSes. [21:55] * Launchpad Patch Queue Manager: [r=allenap][ui=none][no-qa] Factor out gathering of POFiles for [21:55] translations export to bzr branches. === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [22:25] morning [22:25] flacoste: hi [23:00] i'm not sure how i've gotten this far without already encountering this issue, but if how does one set up a store on an object such that Store.of returns something other than None? [23:01] any object returned from a store [23:01] new objects need to be added to a store first [23:12] lifeless: okay, so i must just have a logic error. i thought classes needed some sort of setup. [23:12] lifeless: thanks! [23:13] Store.of(Class) ? IIRC that will return the default store [23:13] which can be a problem when something gets forced rather than defaulting [23:31] lifeless, jcsackett: Store.of(object) will only work if object has been retrieved is a model object from a store. [23:31] The IStore, IMasterStore, ISlaveStore objects are Launchpad-specific and work on classes. [23:31] s/objects/adapters/ [23:43] * lifeless wonders if his branches landed. [23:56] Can someone please harrass ISD about ixokai's issue (in #launchpad)?