[00:33] <maxb> Is someone visual on the need to initialize natty-cat-lpbuildd?
[00:35] <wgrant> It probably won't ever happen.
[00:36] <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:41] <maxb> Hrm. Someone really should just copy maverick-cat-lpbuildd for now, so that natty recipe builds aren't unilaterally doomed until then
[00:42] <wgrant> I suggested that.
[00:43] <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?
[01:10] <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:11] <mwhudson> hm, seems like there's a problem on staging too: https://code.staging.launchpad.net/~vcs-imports/pydoctor/trunk
[01:43] <lifeless> ola
[01:45] <wgrant> Afternoon.
[01:51] <lifeless> anyone else seeing ': lp.code.model.tests.test_recipebuilder.TestDispatchBuildToSlave.test_dispatchBuildToSlave ' fail in devel ?
[01:52] <lifeless> ugh yes, we're in testfix
[01:53] <wgrant> Yeah, broken here.
[01:55] <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:56] <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
[02:00] <wgrant> lifeless: Those are some interesting failures.
[02:00] <wgrant> (the webservice ones)
[02:01] <lifeless> yes
[02:01] <wgrant> But http://pastebin.ubuntu.com/534111/ fixes the real failure.
[02:02] <wgrant> 11938 changed the log level and added a new message.
[02:03] <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:06] <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:07] <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:08] <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:09] <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:15] <lifeless> wgrant: 404's - no idea why, file bugs.
[02:15] <lifeless> wgrant: gzip? zomg. file a patch.
[02:16] <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:17] <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:18] <lifeless> mwhudson: have a look between 11887 and 11926
[02:18] <abentley> lifeless: FSVO "here".
[02:18] <lifeless> abentley: we've got a firefight on our hands, and I'm about to be offline for an extended period
[02:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <lifeless> [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:27] <lifeless>       16 /   14  DistroSeries:+queue
[02:27] <lifeless>       11 /    0  BinaryPackageBuild:+retry
[02:27] <lifeless>       10 /  403  Distribution:+bugtarget-portlet-bugfilters-stats
[02:29] <wgrant> 13:27:02 < lifeless>       11 /    0  BinaryPackageBuild:+retry
[02:29] <wgrant> That is disturbing.
[02:37] <lifeless> I don't have the oops code sorry
[02:39] <lifeless> wgrant: so are you seeing folk copying and pasting the restricted urls into public channels or some such ?
[02:40] <wgrant> lifeless: Just the one bug so far.
[02:41] <lifeless> experienced user? new user?
[02:42] <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:43] <mwhudson> well i can reproduce locally
[02:44] <wgrant> The importd thing?
[02:44] <mwhudson> yesd
[02:46] <mwhudson> yes, it's the 2.2.1 upgrade
[03:02] <mwhudson> wth!
[03:03] <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:04] <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:10] <bac> mwhudson: do you know who is working on the issue lifeless raised?  wgrant?
[03:10] <mwhudson> bac: no
[03:11] <lifeless> which issue?
[03:11] <lifeless> bac: I've raised enough I don't know to which you refer
[03:12] <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:13] <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:17] <bac> lifeless: i can in a bit when i get out of this meeting
[03:36] <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:41] <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:43] <mwhudson> bac: i'm running away
[03:54] <poolie> well done mwhudson !
[04:02] <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:06] <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:07] <wgrant> lifeless: We've certainly not knowingly fixed it (although it doesn't affect the SFTP version of poppy).
[04:11] <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:12] <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:14] <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:20] <poolie> has anyone seen
[04:20] <poolie> KeyError: 'STORM_CEXTENSIONS'
[04:23] <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:24] <lifeless> it happens to me every storm upgrade we do
[04:26] <bac> thanks wgrant.  i have to relocate and will look at that patch shortly
[04:31] <wgrant> I think we need to do something about the footer.
[04:32] <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:33] <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:34] <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:35] <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:36] <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:37] <wgrant> And you have to read a lot of text to see the warning.
[04:37] <wgrant> If only we had a designer.
[04:38] <poolie> a little bird told me 'soon'
[04:39] <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:40] <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:41] <poolie> otherwise i think it's blocking but imbw
[04:44] <wgrant> I wish bug listings could be convinced to show a set of tags.
[04:44] <lifeless> ciao
[04:44] <poolie> sayonara
[05:08] <poolie> jml, dkim tests are running, we'll see what happens
[05:38] <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:39] <poolie> i'll file one then
[05:39] <wgrant> Thanks.
[06:02] <poolie> ok bug 677342 and bug 377339
[06:20] <wallyworld_> poolie: you still there?
[06:47] <poolie> hi, i am
[06:47] <poolie> wallyworld_: i am
[06:48] <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:49] <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:50] <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:51] <wallyworld_> ok. so 2.2.2 should be released around nowish?
[06:51] <wallyworld_> so i should upgrade lp to that?
[06:52] <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:53] <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:54] <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:55] <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:56] <wallyworld_> wgrant: yes, i ran the ones i found, something like test -vvt test_bzr*
[06:57] <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/
[07:22] <poolie> jtv: hi?
[07:22] <jtv> hi
[07:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <jtv> I have a feeling that this would solve another problem.
[07:33] <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:34] <jtv> That makefile needs some love.
[07:34] <poolie> getting more precise makefile rules is generally good
[07:34] <wgrant> buildout!!!
[08:01] <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:02] <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:04] <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:05] <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:06] <poolie> thus my shallow inclination to call it less
[08:06] <wgrant> Or just delete it like U1 did.
[08:12] <poolie> could be good
[08:12] <poolie> ok, good night
[08:13] <wgrant> Night.
[08:29] <adeuring> good morning
[08:30] <henninge> Moin adeuring ;)
[08:30] <adeuring> hi henninge!
[08:32] <bac> hi adeuring
[08:32] <adeuring> hi bac
[09:03] <mrevell> Guten morgen
[10:27] <LPCIBot> Yippie, build fixed!
[10:27] <LPCIBot> Project devel build (230): FIXED in 4 hr 2 min: https://hudson.wedontsleep.org/job/devel/230/
[11:09] <bigjools> $ time make -j2
[11:09] <bigjools> real    1m38.038s
[11:09] <bigjools> \o/  thanks jtv
[11:11] <jtv> bigjools: my pleasure... poolie got in on the game too, so expect more improvements soon
[11:17] <bigjools> jtv: I can't work out why -j4 takes longer
[11:18] <jtv> bigjools: otp, will explain in a bit
[11:18] <bigjools> no prob
[11:18] <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:21] <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:22] <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:23] <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:24] <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:25] <jtv> Dependencies still aren't entirely complete, I guess.  Martin found a missing one earlier today.
[11:26] <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:27] <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:28] <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:29] <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:30] <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:31] <jtv> Do we ever do less?
[11:31] <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:33] <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:35] <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:36] <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:37] <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:38] <bigjools> :)
[11:38] <bigjools> now I am surprised.  My i5 with SSD is slower than the AMD Phenom
[11:39] <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:40] <bigjools> yes, it's Heisenberg
[11:40] <jtv> That's a missing dependency.
[11:41] <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:42] <jtv> Is it a dual-core?
[11:42] <bigjools> 4 core
[11:43] <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:44] <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:45] <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:46] <jtv> bigjools: just for my piece of mind, could you grep ^buildout_bin Makefile ?
[11:47] <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:48] <jtv> It may just be the problem Martin spotted, where the virtual buildout_bin target gets re-built unnecessarily.
[11:49] <bigjools> jtv: http://pastebin.ubuntu.com/534245/
[11:53] <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:54] <jtv> I don't see that subvertpy build output though.
[12:02] <deryck> Morning, all.
[12:11] <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:12] <bigjools> yes
[12:12] <bigjools> I've put deliberate typos in the zcml and the interface to see if they get read, and they do
[12:13] <bigjools> webservice.py I mean
[12:14] <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:15] <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:16] <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:17] <bigjools> and, dine and dash
[12:35] <bigjools> jml: ahhh make -j3 is fastest yet on my i5
[12:36] <bigjools> jtv, sorry
[12:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <bigjools> jtv: -j2 is 2:12 !
[12:43] <jtv> bigjools: why not the 1:53 you got before?
[12:43] <bigjools> who knows
[12:45] <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:46] <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:47] <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.
[13:22] <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:23] <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:25] <bigjools> ISTR there needs to be a magic string in the interface somewhere
[13:25] <bigjools> otherwise the wadl parser ignores it
[13:26] <james_w> bigjools, what are you doing?
[13:26] <james_w> trying to export a new interface?
[13:27] <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:28] <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:29] <bigjools> https://code.launchpad.net/~julian-edwards/launchpad/api-expose-builders/+merge/39379
[13:31] <james_w> bigjools, what's the collection you export?
[13:31] <bigjools>  /builders
[13:32] <james_w> bigjools, and no builder stuff ends up in the wadl?
[13:32] <bigjools> nada
[13:33] <james_w> I can't see anything obvious, sorry
[13:36] <bigjools> thanks for looking
[13:36] <bigjools> I'm going to eat and hopefully Leonard will be around when I get back
[13:44] <deryck> reboot.  brb.
[14:07] <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:19] <abentley> jelmer, bigjools: ping
[14:20] <jelmer> abentley: hey
[14:20] <abentley> jelmer: can we chat about async uploads and source pagackge recipe builds?
[14:21] <jml> bigjools: it occurs to me that leonardr won't be around today.
[14:26] <jelmer> abentley: yes, sure. mumble?
[14:26] <abentley> jelmer: sure.
[14:28] <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:36] <abentley> jelmer: http://pastebin.ubuntu.com/534287/
[14:58] <bigjools> jml: bugger
[14:58] <bigjools> in that case, hey benji!
[15:00] <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:01] <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:03] <benji> looking
[15:22] <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:23] <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:24] <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:30] <bigjools> benji: trying that now - what are all those "Unknown entry URL:" things about?
[15:31] <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:32] <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:34] <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:48] <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:49] <abentley> bigjools: I haven't heard of that problem before.
[15:50] <bigjools> problems seem to follow me
[15:51] <abentley> bigjools: mercurial is provided as an egg.
[15:52] <bigjools> I see it in eggs
[15:52] <abentley> bigjools: It's not bzr-hg?  That's provided in sourcecode.
[15:54] <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:55] <abentley> bigjools: And when you try it from bin/py, does it puke?
[15:55] <bigjools> yes
[15:56] <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:57] <abentley> bigjools: You could torch your eggs directory and run "make".
[15:59] <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 :/
[16:00] <jelmer> abentley: this is sprb failure emails specifically?
[16:00] <abentley> jelmer: Yep.  Why would anyone care about binary builds :-D
[16:01] <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:02] <abentley> jelmer: perhaps processChangesFile is the wrong place for notification?
[16:02] <bigjools> thanks... I feel stupid now
[16:03] <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:04] <abentley> bigjools: I'm glad.
[16:05] <rockstar> deryck, what's going gangster?
[16:05] <deryck> rockstar, you know, livin' large, kickin' js ass and takin' names.
[16:06] <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:07] <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:08] <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:10] <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:11] <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:12] <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:14] <bigjools> benji: right - at least I think it should warn about things declarated but not exported.
[16:14] <bigjools> declarated?  I mean declared.
[16:15] <benji> that might work
[16:19] <rockstar> deryck, so we're basically concluding that it's the size of the js file that's causing all these headaches?
[16:20] <deryck> rockstar, it is indeed the size of the file.  I'm 100% certain of that.
[16:33] <rockstar> deryck, that's unfortunate.
[16:35] <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:37] <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:38] <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:43] <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:53] <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?
[17:15] <rockstar> mars, it was spinning on a socket call, yes.
[17:16] <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:17] <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:18] <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:19] <mars> rockstar, ok, thanks, that is somewhere to start
[17:24] <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:28] <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.
[19:17] <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:18] <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:47] <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:48] <sinzui> The rounded border around the form is only used on this page and only when a search was not performed
[19:49] <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:50] <mwhudson> has anyone tried to see if maxb's bzr fix helps the code import situation yet?
[19:51] <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:54] <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:56] <sinzui> deryck, my branch is near done, but I am dissatisfied with how I am leaving it
[19:56] <deryck> sinzui, how so?
[19:57] <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:58] <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:59] <deryck> sinzui, I see no reason not to append.  I assume it's just oversight that it doesn't currently.
[20:00] <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:01] <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:09] <jml> g'night all.
[20:12] <deryck> thanks for taking this on, sinzui.
[20:13] <sinzui> np. I am sure I will benefit from the fix if I can land it
[21:55] <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.
[22:25] <lifeless> morning
[22:25] <lifeless> flacoste: hi
[23:00] <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:01] <lifeless> any object returned from a store
[23:01] <lifeless> new objects need to be added to a store first
[23:12] <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:13] <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:31] <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:43]  * lifeless wonders if his branches landed.
[23:56] <wgrant> Can someone please harrass ISD about ixokai's issue (in #launchpad)?