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