[00:00] wgrant: ack [00:12] kirkland: consider that other buildds can run arbitrary users arbitrary code [00:12] lifeless: yeah [00:13] now if you say I don't care about that, thats fine [00:13] but we can't really offer a secure embargo *and* have such an obvious wart that we'd need to warn folk off [00:16] we don't currently have a bi-directional channel for 'I need file X' from the buildd's. [00:17] we probably need something like that to deal with arbitrary build-dependencies w/in the PPA (unless you say 'no build dependencies with hidden sources needed') [00:17] $blah etc. [00:17] lifeless: Huh? [00:17] You don't build-depend on sources :) [00:17] wgrant: I know. Still sickish. [00:17] We know the needed source files before we start the build. [00:17] wgrant: I regretted that bit as soon as I wrote it. [00:18] well [00:18] as soon as I hit ENTER. [00:18] Heh [00:18] anyhoo [00:19] key thing - kirkland - if you want to work on this, by all means. The constraints are: soyuz assumes source available everywhere today; there is no guaranteed sequencing for htaccess changes and publication IIRC (different processes write it, IIRC), buildds are untrustable [00:19] personally, I'd still try a TLT approach first and foremost. [00:19] Indeed. [00:19] It's easily doable now. [00:20] lifeless: what's TLT? [00:20] TimeLimitedToken [00:20] a time limited access pass to one file in the private librarian [00:20] lifeless: ah, tokay [00:21] click on a bug attachment on a private bug, or a private build log, for instance. [00:21] it will work for a day, but then stop working unless you go back to the LP web UI and click on the link there again [00:21] which does a redirect dance to issue a token and forward you to the token-including url on the librarian === nigelb_ is now known as nigelb [00:31] wgrant: https://code.launchpad.net/~wallyworld/launchpad/fix-convoy-make/+merge/90225 [00:32] wgrant: i'll need to ask to to lp-land also since it's broken on my system [00:40] wallyworld__: What creates build/js/yui/yui-3.3.0? [00:40] buildout? [00:44] wgrant: yui-dep.py [00:45] ah, hang on, yui-deps uses that dir [00:45] i think it's buildout.cfg, yes [00:45] is where it's defined [00:46] yes, just refreshed my memory, it is buildout [00:47] Great. === wgrant changed the topic of #launchpad-dev to: JS build broken until r14727 | https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 [01:29] lifeless, so, thinking about it over dinner, I'm not sure that we would get any benefit from txlongpoll in this bit of the system, but we may well want to use it for updating the browser when the this backend processing job gets all the way back to the user-facing web service to update browsers. Is there a reason that we would want to use it between that user-facing service and the backend jobs that I'm missing? [01:30] lifeless, if it's not a good time then this can obviously wait [02:15] james_w: sorry, was on the other machine [02:15] james_w: uhm,I don't know what you're putting together at the moment, so I can't really comment ;) [02:16] Yeah, I realize it's a bit vague [02:17] We're basically adding an async job system to developer.u.c that packages tarballs [02:17] and you wanted webhooks in there somehow [02:17] ? [02:18] We have webhooks between d.u.c and the service that coordinates the workers [02:19] pkgme-service is the second system [02:19] any reason for webhooks in particular? [02:19] Not strong reasons [02:20] In fact it's probably pointless [02:20] so for LP I've advocated PSHB as the public event system for a while [02:20] with rabbit internally [02:20] Given that rabbit is used as well [02:20] txlongpoll isn't quite PSHB, but a little refactoring and it could be the browser side, with our own internal PSHB hub [02:21] james_w: I presume you would like events out of LP too [02:22] For this? Eventually [02:22] For other things, definitely [02:23] hah, '404 Bugs reported by me ' [02:23] heh [02:25] anyhow, broadly speaking: [02:25] - I think one event system internally, and one publically is fine [02:26] public/internal being split on *data* protection not teams. [02:30] and I'm massively pro using event systems to let different bits be built separately [02:30] I presume you've seen the guidelines for things in LP done this way? [02:30] they dont' apply directly to you but may still be useful [02:38] I think so, you mean ServicesRequirements? [02:40] yes [02:40] . [02:40] I hate my ISP. Hates. [02:41] They couldn't keep DSL reliable if they were paid to. [02:47] Yeah, we look over that doc frequently [02:52] james_w: I love feedback, if you ever have any :) [02:54] sure will [02:55] this is totally unrelated but you may find it fun - http://piumarta.com/software/maru [03:04] lifeless: You *do* pay them to keep your DSL reliable. [03:07] StevenK: I know === jam3 is now known as jam === danilo_ is now known as danilos [08:28] What is the easiest way to get a package from Oneiric universe into a PPA for Lucid? Copy without rebuild should be fine, but I think that is only point and drool when the source is a PPA? [08:44] stub: You can't copy it directly; the source name conflicts with the 8.4 one. [08:44] You'll need to rename it to postgresql-9.1-debversion, like the binary already is. [08:45] I'm not that far. Can't even see a link to download the sourcepackage so am bzr branching atm. [08:48] http://launchpad.net/ubuntu/oneiric/+source/postgresql-debversion [08:48] Scroll down a little, and there is the link. [08:50] I still don't see it [08:50] oh.. not looking for a .deb am I [08:51] good morning === jtv is now known as jtv-eat === jtv-eat is now known as jtv === almaisan-away is now known as al-maisan === jtv1 is now known as jtv [09:58] lifeless: yo [10:01] I can haz testresources release please? === _mup__ is now known as _mup_ [12:29] wgrant: still around? wondering about the combo loader/convoy setup [12:30] rick_h: Did you get the convoy MP approved? [12:31] StevenK I did from U1, I'm waiting to hear back from landscape folks [12:31] they're not as sure how the heck it works on their end [12:31] Well, they don't need to upgrade to it right away ... [12:32] StevenK: right, I'm pinging sidnei right now to let him know I talked with landscape and we should be good [12:33] so I'm prodding to get the MP merged [12:33] they both had to check their apache configs because my change would break things on their end [12:33] however, sidnei says they have rewrite rules that negate my change for them so it should be all good [12:34] StevenK: he says all sounds good to him, so hopefully sidnei will merge soon now [12:37] StevenK: did you follow how it is that not all prod machines will have convoy installled and avail in their setups? I kind of assumed they'd have to because the same apache config/etc was serving the combo files so they appeared to be from the app server? [12:39] rick_h: Right, it makes sense. [12:41] So then convoy and the combo loader live on one app server? [12:42] rick_h: Apache doesn't run on the appservers [12:42] Icing is served from the Apache on the frontends, banana and nutmeg. [12:42] They run apache+squid+haproxy [12:42] They are the only things in production that need to run convoy. [12:46] ok, so the app servers need a config to pass the requests up a level then and then they'll cache the combo files? [12:47] rick_h: The appservers aren't involved. [12:47] rick_h: The frontend Apache on banana+nutmeg will intercept /+combo and send it to the local WSGI app [12:47] ok [12:47] All the appservers do is generate the +combo URL. [12:47] ok, gotcha [12:48] wgrant: lifeless' opinion was WSGI was too risky to run on banana/nutmeg [12:48] So we'd proxypass to the appservers [12:48] That's my opinion too, but I thought webops said otherwise. [12:48] webops agreed with lifeless [12:48] no, at Budapest we ping'd webobs on it and they said it'd be fine I thought [12:49] That's what I thought, yeah. [12:49] heh, so we're definitely not doing this on a friday :) [12:49] I don't even want to set up qas/staging on a Friday [12:50] rick_h: Oh yeah -- do you remember how you wanted +combo at the end of the URL? So say someone generates a branch called 'make-use-of+combo' == game over [12:51] Since then the branch URL ends with it [12:51] StevenK: well it would have to be /+combo has the branch namne [12:51] the / is improtant I believe [12:51] What benefit does that provide? [12:52] It's important for +login, but that's all. [12:52] nothing, it was just the initial thought that urls that end in /combo would be sent to convoy so that things worked kind of like a normal url routing. /prod1/combo /prod2/combo etc [12:53] it's something that got changed based on StevenK's advice so we should be good [12:59] WCPGW [13:00] I'd rather qas wasn't on fire over the weekend. === jcsackett changed the topic of #launchpad-dev to: JS build broken until r14727 | https://dev.launchpad.net/ | On call reviewer: rick_h*, jcsackett | Firefighting: - | Critical bugtasks: 4*10^2 [13:59] hi, would someone have a few minutes to do a wadllib release for us to put in Debian/Ubuntu? [13:59] I assume it's just a few minutes to do a release at least [14:01] james_w: that's a good question. I suppose that'd fall under my territory and I'm not sure how that's done. [14:01] but fortunately I see deryck just joined in here so I can pester him about it :) [14:01] :-) [14:02] deryck: james_w> hi, would someone have a few minutes to do a wadllib release for us to put in Debian/Ubuntu? [14:02] oh, hmmm, that's not my thing either. :) Let's look around the room. [14:03] maybe flacoste or lifeless? [14:03] https://dev.launchpad.net/HackingLazrLibraries#releases [14:03] maybe that helps? [14:03] dang, there's always a wiki page. [14:03] just once I want to punt. ;) [14:03] james_w: yea, just looking at that and checking the branches/etc [14:03] rick_h, back to you. ;) [14:04] heh [14:04] deryck, "accidentally" delete the wiki? [14:04] james_w: so we're just looking to create a tarball of the latest lp:wadllib right? [14:04] ha! [14:04] rick_h, I believe so [14:04] the branch I want has landed at least :-) [14:05] james_w: excellent, I'll get it checked out and work my way through this, give me a few [14:06] thanks rick_h, much appreceiated? [14:06] err, that's not a question [14:06] it surely is [14:07] heh [14:14] james_w: in looking over the changes this would be a 1.2.0 -> 1.2.1 change? [14:15] oh nvm, add py3 would seem a bigger point [14:23] james_w: rick_h and i have been looking at your MP for python-oops, and rick_h has pointed out that it doesn't look like the code actually requires bson. what was the situation you encountered leading to this change? did something break on you, or is it just in response to other comments in the code about "must be bson serializable"? [14:24] james_w: i see other parts of our oops infrastructure require bson, which is what i believe prompts the comments in lp:python-oops. [14:28] jcsackett, rick_h, that's a very good point [14:28] I think I just invented that dependency [14:29] it's actually python-oops-datedir-repo that doesn't mention it in the README [14:29] I think I just read the mailing list thread and assumed [14:29] james_w: easy thing to do; it took me a few moments of digging through the related code to figure out what might be going on. :-) [14:31] I've pushed a new revision that drops bson [14:31] thanks for catching it [14:49] it seems download-cache is pruned without regard to other projects that rely on it (e.g. python-oops)? [14:51] james_w: got a sec to give me a hand here? I've branched this and run bootstrap, buildout, and running tests are failing [14:51] rick_h, wadllib? [14:51] I'm guessing there's a step I'm missing here? [14:51] james_w: yes, do you need to run a python setup.py develop kind of thing first? [14:52] I don't think so [14:52] let me buildout a copy and see what I get [14:52] rick_h, thanks for the thorough review on https://code.launchpad.net/~james-w/python-oops/update-readme-dependencies/+merge/90028 you were correct about iso8601 [14:53] rick_h: could you please review https://code.launchpad.net/~abentley/launchpad/data-download-view/+merge/90269 ? [14:53] abentley: sure thing, will be a few. [14:53] rick_h: thanks. [14:53] james_w: awesome, glad those weren't needed. [14:55] james_w: with wadllib, the doctests import wadllib, but that would mean there was an egg for it for it to import from right? [14:55] since the doctest it in the wadllib directory, I think === mbarnett` is now known as mbarnett [14:59] rick_h, yeah, I would expect buildout to take care of that though [14:59] james_w: yea, I think I'll ping benji [14:59] benji: got a sec to give me a hand with this wadllib fun? [15:00] rick_h: sure, what's up? [15:00] benji: I've been asked to do a release of it and I"m trying to get the env setup so I can run tests and increment versions and all that fun [15:00] benji: my understanding is I need to branch, bootstrap.py, and buildout and from there .bin/test should work ? [15:01] benji: except the tons of the doctests blow up on me and I'm not sure I've got things setup right [15:01] rick_h: that's the right steps; let me see if I can reproduce the problem [15:02] I can't even bootstrap [15:02] it's complaining about the version of distribute in a seemingly contradictory way [15:02] james_w: yea, I had to create the download-cache directory to bootstrap [15:02] ah, I'll try that [15:02] I was using lp-sourcedeps [15:03] james_w: if you do it in a virtualenv like the docs say, it gives a giant warning that you're double dipping the no-site-packages, but I think that's just a warning not a true error [15:12] rick_h, so my first error is: [15:12] ParseError: not well-formed (invalid token): line 1, column 1 [15:12] james_w: yea, same here [15:13] so I guess the first couple do pass so perhaps it's not my setup but actual failing tests [15:13] wadl_string starts "" [15:13] I wonder if the Application API has changed [15:15] james_w: I'm going to get a py3 env setup since that was the last commit and see if it works there and can start figuring out blaming py versions or what [15:17] ok === matsubara is now known as matsubara-lunch [15:24] rick_h: I've narrowed it down to some problem elementtree is having parsing the WADL XML [15:25] benji: ok, yea that makes sense [15:25] benji: so my setup is ok then, just a matter of real failing tests [15:26] rick_h: yep (although there is at least one thing in the buildout that needs to be fixed, buildout.cfg defines a cache directory and eggs directory, but it shouldn't [15:26] benji: right, that fits with my download-cache I had to create I think [15:27] right, it shouldn't do that [15:28] sorry, getting a crash course in buildout which was on the plan for today anyway but wheeee [15:28] ah, _make_unicode [15:28] (if you want a download cache and an egg cache (and you do), they should be configured in .buildout/default.cfg) [15:29] elementtree hates unicode apparently [15:30] bah, setting up with py3 fails as well with issues getting the right distribute it looks like [15:32] rick_h, I just added the distribute it said it picked to versions.cfg [15:32] james_w: yea, just tried that but I get http://paste.mitechie.com/show/516/ [15:32] I updated the bootstrap.py to be a py3 compatible one from: http://pypi.python.org/pypi/zc.buildout/2.0.0a1 [15:33] did you add "distribute = 0.6.24" to versions.cfg? [15:33] it downloads the right distribute egg into /tmp [15:33] james_w: yes [15:33] hmm, why do some packages have one = and some == ? [15:34] rick_h: it's a huge hack, but this makes the tests pass: http://paste.ubuntu.com/817767/ [15:34] rick_h: I need to attend to some other things now, but feel free to contact me if I can be of assistance. [15:35] benji: ok, thanks for the help. I'm going to ping allenap since he has the last commit commenting on py3 support [15:35] allenap: how does this work please? james_w would love a release but it seems kind of broken atm [15:35] I wonder about http://paste.ubuntu.com/817769/ [15:36] rick_h: What are we talking about [15:36] ? [15:36] allenap: james_w would love a wadllib release, but when I pull it and try to run tests/prep it the tests fail, there's buildout errors about download-cache, and when trying to make it work in py3 the bootstrap doesn't seem to work and I can't get bootstrap to run once I download the py3 compat version [15:37] allenap: since you have the last commit about py3 compatibility I'm hoping you know what's up and how you made it all work [15:37] rvba: Right, let's have a look. [15:38] allenap: I suppose you meant to talk to rick_h… or do you need me for something? [15:38] rvba: I think he was too quick on the autocomplete [15:38] Dammit. [15:38] allenap: that's ok ;) [15:38] Hi rick_h btw :) [15:39] rvba: howdy? hope FR is well today lol [15:39] rick_h: Just try: python3 setup.py test [15:39] allenap: without any buildout setup? [15:40] rick_h: Doesn't need it :) [15:40] allenap: AttributeError: 'HTTPMessage' object has no attribute 'getheaders' [15:40] rick_h: Okay, maybe it does. Are you on Precise? [15:40] allenap: no, oneiric. I've gotten py3, py3-setuptools and that's it so far [15:41] well, installed py3 pip manually as well since that wasn't in a deb yet [15:42] http://paste.mitechie.com/show/517/ allenap [15:42] rick_h: Ah, I am. Okay, buildout doesn't work on Python 3 (afaik). Does python2.7 setup.py test work? [15:42] allenap: no, we get the test failures [15:43] allenap: which benji *fixed* with http://paste.ubuntu.com/817767/ === al-maisan is now known as almaisan-away [15:43] but guessing that's not going to be nice in py3 [15:43] "fixed" in some sense of the word ;) [15:43] allenap: and heads up, buildout *kind* of is supposed to work with py3: http://pypi.python.org/pypi/zc.buildout/2.0.0a1 bit alpha == scary and all that [15:46] hmm, this error was supposed to be fixed it looks like: https://bitbucket.org/tarek/distribute/issue/206 [15:47] rick_h: From a clean tree, I do: mkdir download-cache && python bootstrap.py && bin/buildout [15:47] The reason that download-cache is missing is, I think, so that it can be easily symlinked to the Launchpad download-cache. [15:48] Same with eggs. [15:48] allenap: for the python2 side I did that and got the tests failing with unable to parse the xml test data file [15:48] rick_h: Do you have a pastebin for that? [15:49] allenap: http://paste.mitechie.com/show/518/ [15:50] this is what benji's "cast to str()" fix corrected [15:51] allenap: ok, on the py3 side I updated my distribute version and python3 setup.py test passes [15:51] allenap: the download-cache and eggs-directory should be configured locally, not in a project's buildout; configuring them locally will still allow them to be shared with LP [15:55] rick_h: Can you try with this patch? http://paste.ubuntu.com/817787/ [15:55] allenap: sure thing, sec [15:55] benji: Yeah, agreed. I guess this was cargo-culted from Launchpad. [15:56] probably [16:00] allenap: same error for me [16:01] abentley, shall we G+ hangout or mumble for our call? [16:01] rick_h: Have you removed the str(...) thing? [16:01] deryck: Your call, but I'm having a bad hair day. [16:01] allenap: yea, I never applied it [16:01] abentley, let's G+ then, it will be even more fun with bad hair. :) [16:01] http://paste.mitechie.com/show/519/ [16:03] abentley, should have an invite in bound. [16:07] rick_h: Can you try with another patch? http://paste.ubuntu.com/817803/ [16:08] rick_h: Sorry about this; I can't replicate the problem :-/ [16:12] allenap: sure thing [16:14] allenap: success, tests pass [16:14] rick_h: \o/ [16:14] let me run that on the py3 side and make sure that still runs as well then [16:14] grabbing some quick grub/eyeball break. Thanks for helping with this. [16:14] I'll let you know how the py3 side goes [16:14] rick_h: I'm not sure that _make_unicode() in _from_string() is needed, but I guess we need some tests to prove that. [16:15] allenap: k [16:27] james_w: so summary, how bad do we need the release atm? I've got to catch up on some code review duties today and it looks like we need some tests and tweaking of the buildout setup and docs before I'd really feel comfy doing a release. [16:27] allenap: do you think adding py3 support is worthy of jumping 1.2.0 to 2.0? [16:29] rick_h: A non-technical question. I suddenly feel out of my depth. Why not? (Why? too). [16:29] allenap: so just to shake poeple into seeing 2.0 means craps changed from 1.2, 1.3 means small changes, I should check that changelog [16:29] allenap: purely opinion and not having worked on this don't feel qualified to make it [16:30] rick_h, it's not urgent [16:30] cjwatson, do you still have your py3 wadllib environment around by any chance? [16:30] rick_h: Yeah, then stick with 1.x I guess. I assume that means it's working with py3? [16:30] rick_h, which change makes it pass? [16:31] james_w: that patch file from allenap http://paste.ubuntu.com/817803/ [16:31] and for py3 you need to make sure you've got distribute > 0.6.20 [16:32] james_w: and realize not to use buildout [16:32] james_w: finally, I want to file a bug and get the download-cache thing fixed per benji on the py2 side [16:32] and update some of the docs in https://dev.launchpad.net/HackingLazrLibraries#releases [16:33] rick_h, I don't think that actually fixes the bug [16:33] as in, it makes the tests pass, but only because they are doing something different [16:33] james_w: right, which is why I want to hold off on the release and update some tests and look at this more carefully [16:34] I'm not sure what wadllib does tbh and so need to catch up [16:35] james_w: probably [16:35] I think http://paste.ubuntu.com/817769/ may well be better [16:35] (2.0 seems overkill) [16:35] cjwatson, would you try the patch in http://paste.ubuntu.com/817769/ if you do please? [16:35] cjwatson: k, thanks. 1.3 it is [16:38] james_w: that looks wrong; it would prevent Application from being initialised using a Unicode string [16:39] cjwatson, true, but that currently fails on Python2 [16:39] really? what's the problem we started with here? [16:39] cjwatson: http://paste.mitechie.com/show/518/ [16:39] cjwatson, the tests fail under Python 2 [16:39] the intent of the code definitely seems to be to accept either bytes or unicode there [16:39] james_w: they pass here [16:39] cjwatson: yea, they pass for allenap, appears he's on precise? [16:40] because it gets bytes, unicodes them, puts them in a StringIO and then reads them [16:40] on my oneric it fails and benji and james_w got the same failures [16:40] oneiric here too [16:40] james_w: which should work fine in Python 2 [16:40] its StringIO should tolerate either [16:40] so an API difference in elementtree or pkg_resources [16:40] precise here [16:40] hmm [16:41] but it's true, I see the failure in an oneiric chroot [16:41] with Python 2.7 even [16:42] if you drop the unicode call then it works again, suggesting that elementtree is choking on unicode [16:44] so if we're on Python 2 we should skip unicoding there, and all should work right? [16:44] no change for Python2, and the right thing for Python3? [16:44] * cjwatson is analysing ... [16:45] Doing unicode(a_string) does an implicit decode, and you shouldn't do that to XML bytes unless you know the encoding. [16:46] Well, you shouldn't do an implicit decode on XML at all. [16:46] Keep it as bytes, let the parser do the rest. [16:46] Using BytesIO in Python 3 prevents people passing in strings in the natural way, though. [16:46] (The first pkg_resources change I made might have been a red herring.) [16:47] If you want to do that, you'll have to encode strings. Seems clunky though. [16:47] cjwatson: The second patch (http://paste.ubuntu.com/817803/) still allows for strings and streams. [16:47] so minimal reproduction case in oneiric: [16:47] >>> import xml.etree.cElementTree as ET [16:47] >>> from cStringIO import StringIO [16:47] >>> list(ET.iterparse(StringIO(u""))) [16:47] Traceback (most recent call last): [16:48] File "", line 1, in [16:48] File "", line 84, in next [16:48] cElementTree.ParseError: not well-formed (invalid token): line 1, column 1 [16:49] allenap: with the justification being that opening XML files in text mode is wrong? [16:49] cjwatson: Yes. [16:49] There is ET.fromstring that seems to do the right thing. [16:49] I guess. But in that case you'll still need to use BytesIO in Python 3. [16:50] And I think it'd be better to call it BytesIO in Python 2 as well (from cStringIO import StringIO as BytesIO) for clarity [16:51] agreed (BytesIO) [16:51] Yeah, I agree too. === matsubara-lunch is now known as matsubara === deryck is now known as deryck[lunch] [17:00] allenap, so the fix should be to use fromstring? [17:01] james_w: Yeah, I think that makes sense. Punt the problem over to the stdlib :) [17:07] allenap, are you putting a patch together? [17:08] james_w: I wasn't. I thought rick_h and benji were doing that? [17:11] allenap: I stepped back for a few while you guys debated the best fix. I think I can put something together based on your conversation. It'll probably be tomorrow when I get that together and I'll bug you guys again if I hit trouble [17:12] great, thanks rick_h [17:12] * rick_h saves this irc log like there's no tomorrow :) [17:13] abentley: ping, question on the MP. line 92 removes the content-length header, but I don't see where it gets added? I was expecting DataDownloadView to add it in __call__? [17:14] abentley: but I do see you have a test for it checking the length in line 188 [17:14] rick_h: It happens in the Zope machinery. [17:14] abentley: ah ok [17:15] abentley: so the previous setting was just superfluous? [17:17] abentley: bah nvm, I see the comment in there about that point [17:34] rick_h: Cool :) === jtv1 is now known as jtv [18:04] james_w: so think I've landed your changes to the python-oops, not sure how long it'll take to show in trunk [18:04] james_w: so ping me if you don't seem them in a bit [18:08] rick_h, great, thanks [18:09] james_w: there it goes, looks like it went through yay [18:09] yay [18:19] sinzui: do you know anything about DistroSeriesDifferenceComment ? [18:19] I do not [18:19] abentley, I *think* it is an explanation for a change in packaging === deryck[lunch] is now known as deryck [18:20] rick_h: fancy a review? https://code.launchpad.net/~adeuring/launchpad/bug-834303/+merge/90304 [18:20] for you adeuring, any time :) [18:20] eg backport upstream fix to lucid-based series for partner [18:20] rick_h: thanks! [18:21] sinzui: Okay, thanks. I just asked 'cause none of the authors were around. [18:31] abentley, rick_h, adeuring -- about to have to go offline to head home. tornadoes are coming and need to relocate for safety. [18:31] deryck: ok, head deep [18:31] deryck: good luck! [18:31] but will work online once back there. [18:31] deryck: ack. [18:31] it's safe now, but we get a bit paranoid around here when those storms come now. :) [18:31] so before they hit, I'll get home. :) [18:31] adeuring: in line 30 of your MP, do you need the cast to set? will you possibly get multiple of the smae subscriber_id? [18:32] rick_h: good catch -- the IDs are unique. I'll remove the set() [18:43] jcsackett: you're mentoring rick_h, right? [18:44] abentley: yea, did I not add him to the reviewers list? [18:44] abentley: he was nomming some lunch a few ago [18:44] rick_h: Oh, I just wanted to make sure a mentor review was going to happen. [18:45] abentley: yea, I've added him as a requested review and should happen when get gets back from lunch [19:12] abentley, rick_h: i'm back. had a bit of hiccup, but looking through reviews now. [19:12] sorry for delays. :-P [19:12] jcsackett: No worries. [19:24] abentley: i have nothing to add to rick_h. that's a really nice change, r=me. [19:24] jcsackett: You guys are going to have to get tougher with me, or I'm gonna get a swollen ego :-) [19:25] abentley: i promise to tear a branch to pieces some day. just not today. :-) [19:25] jcsackett: thanks. [19:25] * jcsackett laughs. [19:26] only from lp devs do we thank each other for promises to be mean in MPs. === jcsackett changed the topic of #launchpad-dev to: JS build broken until r14727 | https://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugtasks: 4*10^2 [20:21] hi people [20:21]