[00:00] wgrant: so [00:01] wgrant: you're expressing the point I made [00:01] wgrant: but the point the malone folk made is also valid [00:27] lifeless: advice: where should the canonical_url method go? lp.app... ??? [00:28] thumper: is it a function or a method ? [00:28] lifeless: it is a function used all over the place [00:29] right now it is in canonical.launchpad.webapp.publisher [00:29] so, I'd leave it there, for now [00:29] but mostly imported from canonical.launchpad.webapp [00:29] probably we want lp.components or someting for it, but its not going to be cleaner just pulling it out [00:29] its fairly rightly connected to that core mess ;) [00:30] what do you mean by lp.components? [00:31] oh bah [00:31] I wwas thinking of ./lib/canonical/launchpad/components [00:31] naming is hard. Call it chicken_url and be done :P [00:32] thumper: we don't really have a place for most of the things in canonical.launchpad.webapp yet aiui [00:32] thumper: of course, it should really be in lazr.something :-) [00:32] :-( [00:32] thumper: so yeah, serious - don't move it as part of this, I know you want to, but its the wrong end of webapp to start at [00:32] yeah [00:33] :( [00:33] I'm trying to get a failing test case [00:33] translations have layer specific views for ITranslator [00:33] but you can't go: canonical_url(factory.makeTranslator()) [00:34] nor for translation queues [00:34] and no factory method for distro series language [00:35] yah [00:35] found one [00:35] POFilee [00:36] thumper: what do you need for a test case? [00:36] an existing page on a specific layer [00:36] is it possible to create that situation for a test? [00:36] I found one anyway [00:36] i wrote a test case that registered a new view a couple of weeks back [00:37] ah [00:37] remember where? [00:37] lp.testing.test_publication i think [00:37] it's bonkers [00:37] but that can be hidden i expect [00:38] lp.testing.tests.test_publication [00:38] perhaps should be rewritten as a fixture rather than a test method [00:38] mwhudson: heh [00:39] mwhudson: you are right, it does look a little bonkers [00:40] mwhudson: you could use my shiny new project ;) [00:40] lifeless: i need to look at that again [00:40] lifeless: where is it? [00:41] lifeless: another project? [00:42] lp:python-fixtures [00:42] or pypi [00:42] pyppi:fixtures [00:45] lifeless: so the new thing over what testtools' useFixture is the reset() method? [00:46] mwhudson: its a more complete API, yes [00:46] also no tearDown [00:46] oh ok [00:46] rather a cleanup contract [00:46] well sure, if you have addCleanup... [00:46] so as a developer of these fixtures [00:46] you do different (and I hope less) work [00:47] I thought testtools had installFixture, rather than useFixture, or possibly even just LP has it [00:47] oh right [00:47] i was just going from http://pypi.python.org/pypi/fixtures [00:47] right [00:48] rest is nice :) [00:49] hm [00:49] i wonder how hard it would be to kill ILaunchBag [00:50] hmmm, lunch [00:50] I've love to kill the magic thread locals scattered all over [00:50] more context less magic. _please_ [00:51] lifeless: there's the zope interaction and the database connections, i can't see them going away [00:51] mwhudson: why not ? [00:51] both have the request as context [00:51] well, for the former, i think it would be a pretty massive change to zope [00:52] although maybe it wouldn't be too bad [00:52] I'm sure there would be fallout [00:52] but [00:52] you're right though that the request is the real context [00:53] if we want to e.g. move to twisted throughout, or spread requests across threads in scatter-gather, or suspend requests for AJAX, we need to fix this. [00:53] and systematically, so that it doesn't bite us in the a** [00:53] the launchbag particularly is stuff that's mostly semi-trivially derived from the request [00:53] which is why it should be first up against the wall [00:54] so how does one order_by a Reference ? [00:56] I believe you need to join against it and order by a column of it. [00:57] ._local_key looks promising [00:57] The _ does not. [00:57] details [00:58] python, consenting adults. \o/ [00:58] Ew. [00:59] hi all [01:02] ok, bbiab, selftest running [01:13] do we use __str__ in the UI anywhere ? [01:13] like, on distribution or such things ? === Ursinha-bbl is now known as Ursinha [01:50] \o/ /participants fix in devel [01:57] mwhudson: using flacoste's idea, I can make canonical url work without huge changes to the publisher zcml [01:57] component="lp.code.publisher.CodeLayer" [01:57] provides="zope.publisher.interfaces.browser.IDefaultBrowserLayer" [01:57] name="code" /> [01:57] getUtility(IDefaultBrowserLayer, "code") gets you the layer then [01:58] s/"code"/rootsite/ and we should be good [01:58] with an extra default for no defined layer [01:58] thumper: yeah, makes sense [01:58] is there a layer for the mainsite? [02:00] canonical.launchpad.layers.LaunchpadLayer i think [02:00] mwhudson: ta [02:40] thumper: your thing of resolving lp: for private branches on the server side only [02:40] how are you testing that? [02:51] poolie: pushing to bzr+ssh://bazaar.staging.launchpad.net/+branch/project [02:58] iwbn to eventually eliminate the upfront check in bzr [02:58] at least for some cases, or at least experimentally [03:00] poolie: yes, but there are several other things I want to get done first [03:00] poolie: but yes, I agree [03:00] poolie: and for the record, +lots from me on nested trees [03:00] ok [03:00] and i know commit-to-stacked is still around [03:00] it may be small enough we can just do it [03:04] +1 on that too === lifeless_ is now known as lifeless [03:24] lifeless, https://devpad.canonical.com/~mars/qa-pipeline/deployable.txt [03:28] mars: looking good [03:28] I think it looks ugly, but it works! [03:29] its alot quieter without the rrors [03:29] when its logged in it should be quite readable [03:29] Hi there. When is staging due back up? [03:30] anytime [03:30] it updates automatically [03:30] so its down when applying the updat [03:30] ehttps://staging.launchpad.net/successful-updates.txt [03:31] It's been down for around 20 minutes. Is that normal? [03:31] yes [03:31] https://staging.launchpad.net/successful-updates.txt for the link-lazy [03:42] so everyone else is working late too :) [03:46] mars, https://code.edge.launchpad.net/~ursinha/qa-tagger/change-to-newer-api/+merge/33078 [03:47] Ursinha: I'm not [03:47] ha [03:48] :) [03:49] mars, it took me a bit more to submit that simple branch because that assignment wasn't working with my launchpadlib version; after talking to leonard I tried with the trunk version and it worked fine, then I submitted the mp [04:26] Hmm. Staging has been down for 90 minutes. The last successful-update line is from 3 hours ago [04:27] spm: ^^ [04:52] awesome. it's the same failure that clobbered edge yesterday. [05:38] michaelh1: hey [05:38] michaelh1: regarding nested trees in bzr [08:23] good morning [08:38] Anyone around who can help cook some SQL? [08:45] StevenK: stir-fry it with some mushrooms, garlic, and losa sauce. [08:45] Hah [08:45] spiv: And serve on a bed of Storm? [08:47] StevenK: and scrambled python eggs. [08:49] The code in InitialiseDistroSeries currently grabs all of the packagesets in the packageset table associated with the parent distroseries and inserts them back, with the distroseries pointing at the child. [08:49] * spm questions where spiv gets his 'losa sauce'. Does he have some sort for machine that crushes hapless losas!?!?! Said machine called "launchpad" or maybe "ubuntuone". [08:50] I'd like to do the same for the packagesetsources table, select all rows where the packageset is in the packageset table with a distroseries of the parent, and insert them back with the packageset ids pointing to the child [08:51] spm: I don't reveal my sauces ;) [08:51] *groan* [08:51] Haha [08:54] This is complicated by the fact that there can be multiple packagesets for the distroseries [09:07] Alright everyone? [09:08] Yep :) [09:08] Good :) [09:08] noodles775, One of our participants in the second round is an Arm person working for Linaro. [09:09] Aha [09:09] mrevell: btw: I just updated two of the mockups this morning adding a comment column. [09:10] Ah, thanks noodles775 [10:17] lifeless: Are you going to land https://code.edge.launchpad.net/~lifeless/launchpad/foundations/+merge/32299 ? [10:19] Or should I kick off an ec2 land? === maxb_ is now known as Guest7510 === jelmer is now known as Guest46994 === Guest46994 is now known as jelmer [10:45] stub: could you please [10:45] stub: I had thought it was going in with your branch :) [10:46] Its all been mushed together [10:57] stub: thanks [10:57] gnight [12:01] Morning, all. === Guest7510 is now known as maxb === maxb is now known as Guest10006 === maxb_ is now known as maxb === henninge_ is now known as henninge === mrevell is now known as mrevell-lunch === jcsackett|afk is now known as jsackett === mrevell-lunch is now known as mrevell [14:44] bac, mars: this is my rough plan for changing the ec2 mail: http://paste.ubuntu.com/480435/ – thoughts? [14:44] thoughts welcome from others, too. [14:48] jml: I'm not sure how hard having multiple attachments is, but would it make sense to attach the profiling information as an attachment as well. [14:50] jelmer, multiple attachments is pretty easy. which profiling data do you mean, and what would you use it for? [14:52] jml: The "Test suite profiling information" [14:52] jml: Actually, thinking about what I use it for, I don't need it. [14:53] I've been discovered a few launchpad layers I didn't know about using it, but that doesn't seem like a good reason to keep it in the emails. [14:56] sinzui: OpenIDIdentifier or OpenIdIdentifier? [14:59] I like the latter [15:14] jml: that sounds like a good plan. i really like the idea of having failures up front. makes checking it on a phone much better. i don't do that often but flicking through an insanely long message to get to the bottom is tiresome. [15:26] bac, thanks. === deryck is now known as deryck[lunch] [16:13] jml, be careful with the stdout/stderr capture code. if test_on_merge.py crashes, it writes to stderr. Not sure if you can control stdout and stderr just for the tests themselves. [16:15] mars, good to know. I lean toward the "tests shouldn't print to stdout/err" approach anyway. [16:15] mars, fwiw, the way it works now is that subunit forwards all the gunk it doesn't recognize onto a file-like object that you give it. [16:15] jml, I should be more specific: if the test infrastructure detects a hang, it will start printing to the pipes, and that will be appended randomly to the output :/ [16:16] jml, yep, the subunit forwarding would probably be enough. Just wanted to make sure the output wasn't accidentally eaten. === salgado is now known as salgado-lunch [16:18] jml, I like the outline for adding a sort of test summary to the head of the email (don't remember the exact terminology) [16:18] list of failing tests. [16:18] branches, revno, X passed, Y failed, roll of failures - all very nice [16:21] the plan looks good to me. I would be happy with any of those changes [16:22] bac, why would you check the test failures on the phone? Surely you can't *fix* the test failures on the phone? :) [16:22] If you can't do anything about it, why check? [16:22] mars: b/c i'm nuts [16:23] mars: you know, you're out having a nice dinner, get email with a FAILURE message. it's nice to know what failed so you can obsess over it rather than enjoying your meal. [16:34] can anyone tell me what the problem is exactly in https://launchpadlibrarian.net/53996367/buildlog.txt.gz ? looks like bzr is not happy to build stuff on maverick with source package recipes? [16:39] I think that's a known bug, not being able to build stuff on maverick with source package recipes. [16:43] I think rockstar was working on a fix for that last week [16:44] s/I think// [16:44] https://bugs.edge.launchpad.net/launchpad-code/+bug/617072 === deryck[lunch] is now known as deryck [17:13] bug 607691 [17:13] _mup_ is dead :-/ === benji is now known as benji-lunch [17:16] ah ok [17:18] guess we just have to wait for it to get deployed to edge then [17:23] bug 123456 [17:27] bug 123456 [17:27] Hmm [17:30] bug 123456 [17:30] <_mup_> Bug #123456: podcast crashes amarok

[17:30] _mup_: Way to go === al-maisan is now known as almaisan-away [17:37] hi folks, could you amend the LP CSS to use UbuntuBeta as a preferred font, if it's available, please? [17:37] and let me know when that's on edge? [17:37] we'll have a Mono in due course too [17:40] sabdfl, will do. === salgado-lunch is now known as salgado === benji-lunch is now known as benji === almaisan-away is now known as al-maisan [18:14] gmb: love the quotes page quote..what was the context ? ;) === almaisan-away is now known as al-maisan [18:16] thanks jml [18:17] sabdfl, np. [18:17] * jml off for the day [18:17] cheerio [18:22] danilos: flacoste: what bug was the cronscript db-loop-tuner issue filed as ? [18:22] lifeless, none yet, sorry 'bout that [18:22] no worries [18:23] of course, I can't put my super clever simple fix in the bug until there is one :) [18:23] would you like me to write up my understanding as a new bug? .... it might be a bit biased === jsackett is now known as jcsackett [18:41] hah [18:41] raise RuntimeError("Unexpected situation. " [18:41] RuntimeError: Unexpected situation. Please contact the developers. [18:44] leonardr: nice work on the storm collection changes [18:44] leonardr: I'm really looking forward to seeing that live [18:44] thanks, it's still in progress... [18:45] naturally === al-maisan is now known as almaisan-away [18:58] jkakar: around ? [19:11] jamesh_, are you around for some storm help? [19:11] lifeless, i talked to jkakar today, he's on holiday and avilable intermittently [19:12] yeah, I was being hopeful [19:12] storm has decided to take a code path with an assertion in it :( [19:12] jamesh_ will be 2am local tz now [19:12] oh well [19:12] leonardr: maybe I can help ? [19:13] or were you asking for me ? [19:13] lifeless: no, i was just telling you about jkakar [19:13] i also need storm help [19:13] whats up [19:14] leonardr: whats the storm help you need ? [19:15] lifeless, i'm in a situation where i can call len() on a ResultSet object before getting the data, but calling len() after getting the data raises an exception [19:15] whats the exception [19:15] *** FeatureError: __contains__() does not yet support set expressions that combine ORDER BY with LIMIT/OFFSET [19:16] ah [19:16] limit and offset are somehow being associated with the dataset when i get the data, and it's persisting beyond the data fetch [19:16] so by getting the data, you mean slicing ? [19:16] yes [19:16] i kind of think it's a problem in batchnavigator [19:17] interestingly [19:17] my storm here does a copy() in __getitem__ [19:17] I wonder if its a sqlobject glue issue [19:17] lifeless: good news, mthaddon said that they will be able to start on the new 'stable' staging [19:17] so does mine, that's why i think it's batchnavigator [19:17] iow, that doesn't need to wait for the completion of the Lucid upgrade [19:18] which should be finalized with the next DB roll-out [19:18] flacoste: \o/ [19:18] flacoste: you da man [19:18] or rather [19:18] mthaddon and the losas are da men [19:18] the losa are the maen [19:18] exactly [19:18] :) [19:19] still [19:19] praise the messenger, shoot the messenger. Its all good :) [19:19] leonardr: whats the class of the resultset ? [19:20] leonardr: it might be a tableset, resultset or sqlobjectresultset, [19:20] leonardr: or a decoratedresultset [19:20] lifeless, pretty sure it's a resultset [19:20] leonardr: lets make certain [19:22] lifeless: ok, it's not a problem with batchnavigator. i can run len(self.list), and then i can slice self.list, and then len(self.list) raises an exception. self.list is the same object in all 3 cases [19:22] so it's either storm or the FiniteSequenceAdapter [19:22] now to answer your question [19:23] lifeless, self.list.context is a storm.store.ResultSet [19:23] whats self.list then, a security proxy ? [19:24] self.list is a canonical.launchpad.webapp.batching.FiniteSequenceAdapter [19:25] which does pretty much nothing--maps foo() to self.context.foo() for some common operations (iter, len, getitem) [19:25] ok [19:25] so it's probably not the FSA's fault [19:25] so does self.list.context.count(); self.list.context[whatever:whatever]; self.list.context.count() [19:25] also blow up ? [19:29] lifeless: no, that works [19:29] however, self.list.context[whatever:whatever].count() blows up [19:30] but i don't see where one object is being substituted for the other, even though i'm pretty certain that's what's happening [19:30] ah [19:30] [] [19:30] the __getitem__ returns a curried resultset which only answers whatever:whatever [19:30] you aren't expected to call count on it [19:31] (and indeed, calling count on it would return a different value to count on self.list.context) [19:31] and afaict i never do. but i have a feeling that must be what's happening [19:31] does self.list.context.count() work after len(self.list) starts blowing up ? [19:31] i don't store the result of self.list[self.start:self.end+1]. the first thing i do is turn it into a python list, and i do store that [19:32] lifeless: no [19:32] leonardr: so once len(self.list) starts going boom, self.list.context.count() starts going boom [19:33] do you perhaps replace self.list.context? [19:33] checking now, but i don't think so [19:33] no, same object [19:33] unfortunately i don't have visibility into its ._limit [19:34] removeSecurityProxy ? [19:35] james_w, in that thread about binary upload, bigjools said we no longer accept mixed uploads anywhere, but do we still accept binary-only uploads anywhere? [19:36] lifeless: that worked, but it makes things more confusing. both ._limit and ._offset are Undef [19:36] leonardr: are you in pdb ? [19:36] leonardr: if so, consider [19:36] debug self.list.context.count() [19:37] salgado: from the buildds, unless they go through a different mechanism. [19:37] ok, give me a minute [19:37] salgado: mixed upload is what we want in some cases for vostok. [19:38] james_w, oh, right, I'd seen that in a test a few days ago and then forgot it completely [19:38] lifeless: i'm forming a hypothesis that the ResultSet object and the temporary copy of it have an 'expr' object in common [19:38] james_w, yeah, that I got; was just trying to figure out if there were other things I could get rid of [19:39] and that this 'expr' object is the one that has its limit and offset modified by the count() [19:40] leonardr: that would be exciting [19:40] leonardr: and plausible [19:40] I'm facing a potentially similar exciting situation [19:41] lifeless: yes, the ResultSet self._limit is Undef, but self._get_select().limit is 3 [19:42] \o/ [19:45] lifeless: there's code in _get_select that is supposed to avoid this problem, but i do see a big "# XXX UNTESTED!" next to the relevant bit [19:48] -hah- [19:48] its bug filin time! [19:51] lifeless: ok, here's the problem [19:51] the expr object is shared between the slice and the original [19:52] _get_select includes code to change expr.limit if a new one is provided, but not to remove an existing expr.limit if one is _not_ provided [19:52] and that may be deliberate [19:52] >< [19:52] who knows [19:52] jaaaaamuuuuuuuu [19:52] so either _get_select needs to change or we need to copy the expr object [20:06] lifeless: https://bugs.edge.launchpad.net/storm/+bug/620508 [20:06] <_mup_> Bug #620508: Slicing a ResultSet breaks subsequent len() calls. [20:09] I'd try changing it to fixup when limit isn't supplied [20:09] and see if any tests break [20:13] seems to work basically, but now that i've established it's not my fault i need to fight a different fire [20:13] gl [20:30] james_w, do we still accept uploads without .orig.tar.gz files when they've been included in previous uploads? [20:31] salgado: yes, that would be normal [20:32] james_w, and in that case the .orig is included in the .dsc but not in the .changes, is that correct? [20:32] salgado: correct [20:33] and the checksum in the .dsc has to match the file we already have [20:33] right [20:35] james_w, I'm confused because there's a test which says it makes an upload where the .orig is missing (and indeed it's not in the .changes). however, when I remove the .orig from the same directory where the .dsc and .diff.gz are, the test fails [20:35] salgado: where's the test? [20:35] maybe that's because I'm assuming it'd look up the .orig in the librarian but it's actually looking it up on that same directory [20:35] james_w, lib/lp/archiveuploader/tests/nascentupload.txt [20:36] it uploads lib/lp/archiveuploader/tests/data/ed_0.2-20_i386.changes [20:37] if you remove ed_0.2.orig.tar.gz from there, the one test which says uploads without .orig are allowed breaks [20:37] thumper: morning? [20:38] lifeless: I need to report a bug, but it's on something I'm afraid will go away so I'm not sure how to capture/point folks at it [20:38] mtaylor: details ;P [20:38] thumper, lifeless: https://code.edge.launchpad.net/~eday/nova/api-tests/+merge/32960 [20:38] lifeless: that's showing conflict markers as if there were a merge conflict [20:38] lifeless: but if you merge it into the target, those merge conflicts are not there [20:39] so [20:39] its been merged already [20:39] naturally it won't conflict - theres nothing to do. [20:39] also [20:39] hrm [20:39] you probably have your 'use weave merge' settings still [20:40] because lp doesn't have all plugins installed [20:40] and doesn't have per project tweaks [20:40] I do? I don't have that set up at all [20:40] it cannot predict faithfully whats going to happen [20:40] hm [20:40] well [20:43] james_w, yeah, the test is just lying, I think. it says it's not uploading the .orig bug in fact it makes it accessible to NascentUpload directly, so it's like if it had been uploaded. IIUC [20:43] lifeless: so - it showed the conflicts markers as it does now - but when eday did a manual test it didn't conflict - so he marked it approved and it landed fine ... should I file a bug or should I wait until it happens again [20:44] uhm [20:44] it may have conflicted before trunk changes [20:45] we don't recalcualte the diff except when the branch itself changes [20:46] ah [20:46] ok. that explains it [20:47] lifeless: I would like to request a "regenerate diff" button then [20:48] mtaylor: me too the bug then [20:48] I don't want a button [20:48] I want DTRT [20:48] regenerate the diff when you land on the page [20:48] or something [20:51] well yeah, that would be great [20:52] salgado: yeah, DSCFile will find the .orig.tar.gz in that path, even though it isn't in the .changes? [20:52] I only want a button in as much as I want to be able to make sure I can do a current review [20:53] james_w, exactly, but I think in a real upload with a .changes that doesn't include the .orig, it wouldn't be there -- it would have to be found in the distribution. correct? [20:53] salgado: I haven't dug that far. That would be the intention though [20:54] while I'm whinging - it would be great if I could see all bugs with a certain tag regardless of project ... :) [20:57] mtaylor: patches ... [20:58] salgado: yeah, DSCFile._getFileByName as part of DSCFile.checkFiles should get the LFA and compare the checksums [20:59] lifeless: yeah - getting closer. todo list... long [21:00] james_w, ok, I'll make a comment explaining that the test is cheating. thanks for the help [21:00] salgado: what's the failures [21:00] salgado: I don't see why the test should have to cheat [21:01] Is it "Unable to find %s in upload or distribution."? That would make sense [21:02] james_w, well, it says the .orig is not included in the upload but it does include the .orig.tar.gz in the data that is given directly to NascentUpload [21:02] ah, I see what you mean. Does the test fail if you delete that file? [21:02] it does, yes [21:53] gary_poster: ping [21:53] hey mwhudson! I have to run really soon, but can talk for a sec [21:53] gary_poster: i wanted to talk a little about buildout [21:53] sure [21:54] gary_poster: for linaro we're open sourcing an internal project [21:54] and a set up like launchpad uses for managing dependencies would probably work well [21:55] but as with launchpad, the tendency of buildout/setuptools to go grabbing things off the internet is a bit undesired [21:55]