| lifeless | wgrant: so | 00:00 |
|---|---|---|
| lifeless | wgrant: you're expressing the point I made | 00:01 |
| lifeless | wgrant: but the point the malone folk made is also valid | 00:01 |
| thumper | lifeless: advice: where should the canonical_url method go? lp.app... ??? | 00:27 |
| lifeless | thumper: is it a function or a method ? | 00:28 |
| thumper | lifeless: it is a function used all over the place | 00:28 |
| thumper | right now it is in canonical.launchpad.webapp.publisher | 00:29 |
| lifeless | so, I'd leave it there, for now | 00:29 |
| thumper | but mostly imported from canonical.launchpad.webapp | 00:29 |
| lifeless | probably we want lp.components or someting for it, but its not going to be cleaner just pulling it out | 00:29 |
| lifeless | its fairly rightly connected to that core mess ;) | 00:29 |
| thumper | what do you mean by lp.components? | 00:30 |
| lifeless | oh bah | 00:31 |
| lifeless | I wwas thinking of ./lib/canonical/launchpad/components | 00:31 |
| lifeless | naming is hard. Call it chicken_url and be done :P | 00:31 |
| mwhudson | thumper: we don't really have a place for most of the things in canonical.launchpad.webapp yet aiui | 00:32 |
| mwhudson | thumper: of course, it should really be in lazr.something :-) | 00:32 |
| thumper | :-( | 00:32 |
| lifeless | 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 |
| thumper | yeah | 00:32 |
| thumper | :( | 00:33 |
| thumper | I'm trying to get a failing test case | 00:33 |
| thumper | translations have layer specific views for ITranslator | 00:33 |
| thumper | but you can't go: canonical_url(factory.makeTranslator()) | 00:33 |
| thumper | nor for translation queues | 00:34 |
| thumper | and no factory method for distro series language | 00:34 |
| thumper | yah | 00:35 |
| thumper | found one | 00:35 |
| thumper | POFilee | 00:35 |
| mwhudson | thumper: what do you need for a test case? | 00:36 |
| thumper | an existing page on a specific layer | 00:36 |
| mwhudson | is it possible to create that situation for a test? | 00:36 |
| thumper | I found one anyway | 00:36 |
| mwhudson | i wrote a test case that registered a new view a couple of weeks back | 00:36 |
| thumper | ah | 00:37 |
| thumper | remember where? | 00:37 |
| mwhudson | lp.testing.test_publication i think | 00:37 |
| mwhudson | it's bonkers | 00:37 |
| mwhudson | but that can be hidden i expect | 00:37 |
| mwhudson | lp.testing.tests.test_publication | 00:38 |
| mwhudson | perhaps should be rewritten as a fixture rather than a test method | 00:38 |
| thumper | mwhudson: heh | 00:38 |
| thumper | mwhudson: you are right, it does look a little bonkers | 00:39 |
| lifeless | mwhudson: you could use my shiny new project ;) | 00:40 |
| mwhudson | lifeless: i need to look at that again | 00:40 |
| mwhudson | lifeless: where is it? | 00:40 |
| thumper | lifeless: another project? | 00:41 |
| lifeless | lp:python-fixtures | 00:42 |
| lifeless | or pypi | 00:42 |
| lifeless | pyppi:fixtures | 00:42 |
| mwhudson | lifeless: so the new thing over what testtools' useFixture is the reset() method? | 00:45 |
| lifeless | mwhudson: its a more complete API, yes | 00:46 |
| lifeless | also no tearDown | 00:46 |
| mwhudson | oh ok | 00:46 |
| lifeless | rather a cleanup contract | 00:46 |
| mwhudson | well sure, if you have addCleanup... | 00:46 |
| lifeless | so as a developer of these fixtures | 00:46 |
| lifeless | you do different (and I hope less) work | 00:46 |
| lifeless | I thought testtools had installFixture, rather than useFixture, or possibly even just LP has it | 00:47 |
| mwhudson | oh right | 00:47 |
| mwhudson | i was just going from http://pypi.python.org/pypi/fixtures | 00:47 |
| lifeless | right | 00:47 |
| lifeless | rest is nice :) | 00:48 |
| mwhudson | hm | 00:49 |
| mwhudson | i wonder how hard it would be to kill ILaunchBag | 00:49 |
| jelmer | hmmm, lunch | 00:50 |
| lifeless | I've love to kill the magic thread locals scattered all over | 00:50 |
| lifeless | more context less magic. _please_ | 00:50 |
| mwhudson | lifeless: there's the zope interaction and the database connections, i can't see them going away | 00:51 |
| lifeless | mwhudson: why not ? | 00:51 |
| lifeless | both have the request as context | 00:51 |
| mwhudson | well, for the former, i think it would be a pretty massive change to zope | 00:51 |
| mwhudson | although maybe it wouldn't be too bad | 00:52 |
| lifeless | I'm sure there would be fallout | 00:52 |
| lifeless | but | 00:52 |
| mwhudson | you're right though that the request is the real context | 00:52 |
| lifeless | 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 |
| lifeless | and systematically, so that it doesn't bite us in the a** | 00:53 |
| mwhudson | the launchbag particularly is stuff that's mostly semi-trivially derived from the request | 00:53 |
| mwhudson | which is why it should be first up against the wall | 00:53 |
| lifeless | so how does one order_by a Reference ? | 00:54 |
| wgrant | I believe you need to join against it and order by a column of it. | 00:56 |
| lifeless | ._local_key looks promising | 00:57 |
| wgrant | The _ does not. | 00:57 |
| lifeless | details | 00:57 |
| lifeless | python, consenting adults. \o/ | 00:58 |
| wgrant | Ew. | 00:58 |
| poolie_ | hi all | 00:59 |
| lifeless | ok, bbiab, selftest running | 01:02 |
| lifeless | do we use __str__ in the UI anywhere ? | 01:13 |
| lifeless | like, on distribution or such things ? | 01:13 |
| === Ursinha-bbl is now known as Ursinha | ||
| lifeless | \o/ /participants fix in devel | 01:50 |
| thumper | mwhudson: using flacoste's idea, I can make canonical url work without huge changes to the publisher zcml | 01:57 |
| thumper | <utility | 01:57 |
| thumper | component="lp.code.publisher.CodeLayer" | 01:57 |
| thumper | provides="zope.publisher.interfaces.browser.IDefaultBrowserLayer" | 01:57 |
| thumper | name="code" /> | 01:57 |
| thumper | getUtility(IDefaultBrowserLayer, "code") gets you the layer then | 01:57 |
| thumper | s/"code"/rootsite/ and we should be good | 01:58 |
| thumper | with an extra default for no defined layer | 01:58 |
| mwhudson | thumper: yeah, makes sense | 01:58 |
| thumper | is there a layer for the mainsite? | 01:58 |
| mwhudson | canonical.launchpad.layers.LaunchpadLayer i think | 02:00 |
| thumper | mwhudson: ta | 02:00 |
| poolie | thumper: your thing of resolving lp: for private branches on the server side only | 02:40 |
| poolie | how are you testing that? | 02:40 |
| thumper | poolie: pushing to bzr+ssh://bazaar.staging.launchpad.net/+branch/project | 02:51 |
| poolie | iwbn to eventually eliminate the upfront check in bzr | 02:58 |
| poolie | at least for some cases, or at least experimentally | 02:58 |
| thumper | poolie: yes, but there are several other things I want to get done first | 03:00 |
| thumper | poolie: but yes, I agree | 03:00 |
| thumper | poolie: and for the record, +lots from me on nested trees | 03:00 |
| poolie | ok | 03:00 |
| poolie | and i know commit-to-stacked is still around | 03:00 |
| poolie | it may be small enough we can just do it | 03:00 |
| thumper | +1 on that too | 03:04 |
| === lifeless_ is now known as lifeless | ||
| mars | lifeless, https://devpad.canonical.com/~mars/qa-pipeline/deployable.txt | 03:24 |
| lifeless | mars: looking good | 03:28 |
| mars | I think it looks ugly, but it works! | 03:28 |
| lifeless | its alot quieter without the rrors | 03:29 |
| lifeless | when its logged in it should be quite readable | 03:29 |
| michaelh1 | Hi there. When is staging due back up? | 03:29 |
| lifeless | anytime | 03:30 |
| lifeless | it updates automatically | 03:30 |
| lifeless | so its down when applying the updat | 03:30 |
| lifeless | ehttps://staging.launchpad.net/successful-updates.txt | 03:30 |
| michaelh1 | It's been down for around 20 minutes. Is that normal? | 03:31 |
| lifeless | yes | 03:31 |
| mars | https://staging.launchpad.net/successful-updates.txt for the link-lazy | 03:31 |
| Ursinha | so everyone else is working late too :) | 03:42 |
| Ursinha | mars, https://code.edge.launchpad.net/~ursinha/qa-tagger/change-to-newer-api/+merge/33078 | 03:46 |
| thumper | Ursinha: I'm not | 03:47 |
| Ursinha | ha | 03:47 |
| Ursinha | :) | 03:48 |
| Ursinha | 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 | 03:49 |
| michaelh1 | Hmm. Staging has been down for 90 minutes. The last successful-update line is from 3 hours ago | 04:26 |
| thumper | spm: ^^ | 04:27 |
| spm | awesome. it's the same failure that clobbered edge yesterday. | 04:52 |
| thumper | michaelh1: hey | 05:38 |
| thumper | michaelh1: regarding nested trees in bzr | 05:38 |
| adeuring | good morning | 08:23 |
| StevenK | Anyone around who can help cook some SQL? | 08:38 |
| spiv | StevenK: stir-fry it with some mushrooms, garlic, and losa sauce. | 08:45 |
| StevenK | Hah | 08:45 |
| StevenK | spiv: And serve on a bed of Storm? | 08:45 |
| spiv | StevenK: and scrambled python eggs. | 08:47 |
| StevenK | 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:49 | |
| StevenK | 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:50 |
| spiv | spm: I don't reveal my sauces ;) | 08:51 |
| spm | *groan* | 08:51 |
| StevenK | Haha | 08:51 |
| StevenK | This is complicated by the fact that there can be multiple packagesets for the distroseries | 08:54 |
| mrevell | Alright everyone? | 09:07 |
| noodles775 | Yep :) | 09:08 |
| mrevell | Good :) | 09:08 |
| mrevell | noodles775, One of our participants in the second round is an Arm person working for Linaro. | 09:08 |
| noodles775 | Aha | 09:09 |
| noodles775 | mrevell: btw: I just updated two of the mockups this morning adding a comment column. | 09:09 |
| mrevell | Ah, thanks noodles775 | 09:10 |
| stub | lifeless: Are you going to land https://code.edge.launchpad.net/~lifeless/launchpad/foundations/+merge/32299 ? | 10:17 |
| stub | Or should I kick off an ec2 land? | 10:19 |
| === maxb_ is now known as Guest7510 | ||
| === jelmer is now known as Guest46994 | ||
| === Guest46994 is now known as jelmer | ||
| lifeless | stub: could you please | 10:45 |
| lifeless | stub: I had thought it was going in with your branch :) | 10:45 |
| stub | Its all been mushed together | 10:46 |
| lifeless | stub: thanks | 10:57 |
| lifeless | gnight | 10:57 |
| deryck | Morning, all. | 12:01 |
| === 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 | ||
| jml | bac, mars: this is my rough plan for changing the ec2 mail: http://paste.ubuntu.com/480435/ – thoughts? | 14:44 |
| jml | thoughts welcome from others, too. | 14:44 |
| jelmer | 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:48 |
| jml | jelmer, multiple attachments is pretty easy. which profiling data do you mean, and what would you use it for? | 14:50 |
| jelmer | jml: The "Test suite profiling information" | 14:52 |
| jelmer | jml: Actually, thinking about what I use it for, I don't need it. | 14:52 |
| jelmer | 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:53 |
| stub | sinzui: OpenIDIdentifier or OpenIdIdentifier? | 14:56 |
| sinzui | I like the latter | 14:59 |
| bac | 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:14 |
| jml | bac, thanks. | 15:26 |
| === deryck is now known as deryck[lunch] | ||
| mars | 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:13 |
| jml | mars, good to know. I lean toward the "tests shouldn't print to stdout/err" approach anyway. | 16:15 |
| jml | 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 |
| mars | 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:15 |
| mars | jml, yep, the subunit forwarding would probably be enough. Just wanted to make sure the output wasn't accidentally eaten. | 16:16 |
| === salgado is now known as salgado-lunch | ||
| mars | 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 |
| jml | list of failing tests. | 16:18 |
| mars | branches, revno, X passed, Y failed, roll of failures - all very nice | 16:18 |
| mars | the plan looks good to me. I would be happy with any of those changes | 16:21 |
| mars | bac, why would you check the test failures on the phone? Surely you can't *fix* the test failures on the phone? :) | 16:22 |
| mars | If you can't do anything about it, why check? | 16:22 |
| bac | mars: b/c i'm nuts | 16:22 |
| bac | 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:23 |
| dobey | 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:34 |
| jml | I think that's a known bug, not being able to build stuff on maverick with source package recipes. | 16:39 |
| jelmer | I think rockstar was working on a fix for that last week | 16:43 |
| jelmer | s/I think// | 16:44 |
| jml | https://bugs.edge.launchpad.net/launchpad-code/+bug/617072 | 16:44 |
| === deryck[lunch] is now known as deryck | ||
| gary_poster | bug 607691 | 17:13 |
| gary_poster | _mup_ is dead :-/ | 17:13 |
| === benji is now known as benji-lunch | ||
| dobey | ah ok | 17:16 |
| dobey | guess we just have to wait for it to get deployed to edge then | 17:18 |
| niemeyer | bug 123456 | 17:23 |
| niemeyer | bug 123456 | 17:27 |
| niemeyer | Hmm | 17:27 |
| niemeyer | bug 123456 | 17:30 |
| _mup_ | Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456> | 17:30 |
| niemeyer | _mup_: Way to go | 17:30 |
| === al-maisan is now known as almaisan-away | ||
| sabdfl | hi folks, could you amend the LP CSS to use UbuntuBeta as a preferred font, if it's available, please? | 17:37 |
| sabdfl | and let me know when that's on edge? | 17:37 |
| sabdfl | we'll have a Mono in due course too | 17:37 |
| jml | sabdfl, will do. | 17:40 |
| === salgado-lunch is now known as salgado | ||
| === benji-lunch is now known as benji | ||
| === almaisan-away is now known as al-maisan | ||
| lifeless | gmb: love the quotes page quote..what was the context ? ;) | 18:14 |
| === almaisan-away is now known as al-maisan | ||
| sabdfl | thanks jml | 18:16 |
| jml | sabdfl, np. | 18:17 |
| * jml off for the day | 18:17 | |
| sabdfl | cheerio | 18:17 |
| lifeless | danilos: flacoste: what bug was the cronscript db-loop-tuner issue filed as ? | 18:22 |
| danilos | lifeless, none yet, sorry 'bout that | 18:22 |
| lifeless | no worries | 18:22 |
| lifeless | of course, I can't put my super clever simple fix in the bug until there is one :) | 18:23 |
| lifeless | would you like me to write up my understanding as a new bug? .... it might be a bit biased | 18:23 |
| === jsackett is now known as jcsackett | ||
| lifeless | hah | 18:41 |
| lifeless | raise RuntimeError("Unexpected situation. " | 18:41 |
| lifeless | RuntimeError: Unexpected situation. Please contact the developers. | 18:41 |
| lifeless | leonardr: nice work on the storm collection changes | 18:44 |
| lifeless | leonardr: I'm really looking forward to seeing that live | 18:44 |
| leonardr | thanks, it's still in progress... | 18:44 |
| lifeless | naturally | 18:45 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | jkakar: around ? | 18:58 |
| leonardr | jamesh_, are you around for some storm help? | 19:11 |
| leonardr | lifeless, i talked to jkakar today, he's on holiday and avilable intermittently | 19:11 |
| lifeless | yeah, I was being hopeful | 19:12 |
| lifeless | storm has decided to take a code path with an assertion in it :( | 19:12 |
| lifeless | jamesh_ will be 2am local tz now | 19:12 |
| leonardr | oh well | 19:12 |
| lifeless | leonardr: maybe I can help ? | 19:12 |
| lifeless | or were you asking for me ? | 19:13 |
| leonardr | lifeless: no, i was just telling you about jkakar | 19:13 |
| leonardr | i also need storm help | 19:13 |
| lifeless | whats up | 19:13 |
| lifeless | leonardr: whats the storm help you need ? | 19:14 |
| leonardr | 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 |
| lifeless | whats the exception | 19:15 |
| leonardr | *** FeatureError: __contains__() does not yet support set expressions that combine ORDER BY with LIMIT/OFFSET | 19:15 |
| lifeless | ah | 19:16 |
| leonardr | 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 |
| lifeless | so by getting the data, you mean slicing ? | 19:16 |
| leonardr | yes | 19:16 |
| leonardr | i kind of think it's a problem in batchnavigator | 19:16 |
| lifeless | interestingly | 19:17 |
| lifeless | my storm here does a copy() in __getitem__ | 19:17 |
| lifeless | I wonder if its a sqlobject glue issue | 19:17 |
| flacoste | lifeless: good news, mthaddon said that they will be able to start on the new 'stable' staging | 19:17 |
| leonardr | so does mine, that's why i think it's batchnavigator | 19:17 |
| flacoste | iow, that doesn't need to wait for the completion of the Lucid upgrade | 19:17 |
| flacoste | which should be finalized with the next DB roll-out | 19:18 |
| lifeless | flacoste: \o/ | 19:18 |
| lifeless | flacoste: you da man | 19:18 |
| lifeless | or rather | 19:18 |
| lifeless | mthaddon and the losas are da men | 19:18 |
| flacoste | the losa are the maen | 19:18 |
| flacoste | exactly | 19:18 |
| lifeless | :) | 19:18 |
| lifeless | still | 19:19 |
| lifeless | praise the messenger, shoot the messenger. Its all good :) | 19:19 |
| lifeless | leonardr: whats the class of the resultset ? | 19:19 |
| lifeless | leonardr: it might be a tableset, resultset or sqlobjectresultset, | 19:20 |
| lifeless | leonardr: or a decoratedresultset | 19:20 |
| leonardr | lifeless, pretty sure it's a resultset | 19:20 |
| lifeless | leonardr: lets make certain | 19:20 |
| leonardr | 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 |
| leonardr | so it's either storm or the FiniteSequenceAdapter | 19:22 |
| leonardr | now to answer your question | 19:22 |
| leonardr | lifeless, self.list.context is a storm.store.ResultSet | 19:23 |
| lifeless | whats self.list then, a security proxy ? | 19:23 |
| leonardr | self.list is a canonical.launchpad.webapp.batching.FiniteSequenceAdapter | 19:24 |
| leonardr | which does pretty much nothing--maps foo() to self.context.foo() for some common operations (iter, len, getitem) | 19:25 |
| lifeless | ok | 19:25 |
| leonardr | so it's probably not the FSA's fault | 19:25 |
| lifeless | so does self.list.context.count(); self.list.context[whatever:whatever]; self.list.context.count() | 19:25 |
| lifeless | also blow up ? | 19:25 |
| leonardr | lifeless: no, that works | 19:29 |
| leonardr | however, self.list.context[whatever:whatever].count() blows up | 19:29 |
| leonardr | 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 |
| lifeless | ah | 19:30 |
| lifeless | [] | 19:30 |
| lifeless | the __getitem__ returns a curried resultset which only answers whatever:whatever | 19:30 |
| lifeless | you aren't expected to call count on it | 19:30 |
| lifeless | (and indeed, calling count on it would return a different value to count on self.list.context) | 19:31 |
| leonardr | and afaict i never do. but i have a feeling that must be what's happening | 19:31 |
| lifeless | does self.list.context.count() work after len(self.list) starts blowing up ? | 19:31 |
| leonardr | 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:31 |
| leonardr | lifeless: no | 19:32 |
| lifeless | leonardr: so once len(self.list) starts going boom, self.list.context.count() starts going boom | 19:32 |
| lifeless | do you perhaps replace self.list.context? | 19:33 |
| leonardr | checking now, but i don't think so | 19:33 |
| leonardr | no, same object | 19:33 |
| leonardr | unfortunately i don't have visibility into its ._limit | 19:33 |
| lifeless | removeSecurityProxy ? | 19:34 |
| salgado | 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:35 |
| leonardr | lifeless: that worked, but it makes things more confusing. both ._limit and ._offset are Undef | 19:36 |
| lifeless | leonardr: are you in pdb ? | 19:36 |
| lifeless | leonardr: if so, consider | 19:36 |
| lifeless | debug self.list.context.count() | 19:36 |
| james_w | salgado: from the buildds, unless they go through a different mechanism. | 19:37 |
| leonardr | ok, give me a minute | 19:37 |
| james_w | salgado: mixed upload is what we want in some cases for vostok. | 19:37 |
| salgado | james_w, oh, right, I'd seen that in a test a few days ago and then forgot it completely | 19:38 |
| leonardr | lifeless: i'm forming a hypothesis that the ResultSet object and the temporary copy of it have an 'expr' object in common | 19:38 |
| salgado | james_w, yeah, that I got; was just trying to figure out if there were other things I could get rid of | 19:38 |
| leonardr | and that this 'expr' object is the one that has its limit and offset modified by the count() | 19:39 |
| lifeless | leonardr: that would be exciting | 19:40 |
| lifeless | leonardr: and plausible | 19:40 |
| lifeless | I'm facing a potentially similar exciting situation | 19:40 |
| leonardr | lifeless: yes, the ResultSet self._limit is Undef, but self._get_select().limit is 3 | 19:41 |
| lifeless | \o/ | 19:42 |
| leonardr | 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:45 |
| lifeless | -hah- | 19:48 |
| lifeless | its bug filin time! | 19:48 |
| leonardr | lifeless: ok, here's the problem | 19:51 |
| leonardr | the expr object is shared between the slice and the original | 19:51 |
| leonardr | _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 |
| lifeless | and that may be deliberate | 19:52 |
| lifeless | >< | 19:52 |
| leonardr | who knows | 19:52 |
| lifeless | jaaaaamuuuuuuuu | 19:52 |
| leonardr | so either _get_select needs to change or we need to copy the expr object | 19:52 |
| leonardr | lifeless: https://bugs.edge.launchpad.net/storm/+bug/620508 | 20:06 |
| _mup_ | Bug #620508: Slicing a ResultSet breaks subsequent len() calls. <Storm:New> <https://launchpad.net/bugs/620508> | 20:06 |
| lifeless | I'd try changing it to fixup when limit isn't supplied | 20:09 |
| lifeless | and see if any tests break | 20:09 |
| leonardr | seems to work basically, but now that i've established it's not my fault i need to fight a different fire | 20:13 |
| lifeless | gl | 20:13 |
| salgado | james_w, do we still accept uploads without .orig.tar.gz files when they've been included in previous uploads? | 20:30 |
| james_w | salgado: yes, that would be normal | 20:31 |
| salgado | james_w, and in that case the .orig is included in the .dsc but not in the .changes, is that correct? | 20:32 |
| james_w | salgado: correct | 20:32 |
| james_w | and the checksum in the .dsc has to match the file we already have | 20:33 |
| salgado | right | 20:33 |
| salgado | 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 |
| james_w | salgado: where's the test? | 20:35 |
| salgado | 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 |
| salgado | james_w, lib/lp/archiveuploader/tests/nascentupload.txt | 20:35 |
| salgado | it uploads lib/lp/archiveuploader/tests/data/ed_0.2-20_i386.changes | 20:36 |
| salgado | if you remove ed_0.2.orig.tar.gz from there, the one test which says uploads without .orig are allowed breaks | 20:37 |
| mtaylor | thumper: morning? | 20:37 |
| mtaylor | 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 |
| lifeless | mtaylor: details ;P | 20:38 |
| mtaylor | thumper, lifeless: https://code.edge.launchpad.net/~eday/nova/api-tests/+merge/32960 | 20:38 |
| mtaylor | lifeless: that's showing conflict markers as if there were a merge conflict | 20:38 |
| mtaylor | lifeless: but if you merge it into the target, those merge conflicts are not there | 20:38 |
| lifeless | so | 20:39 |
| lifeless | its been merged already | 20:39 |
| lifeless | naturally it won't conflict - theres nothing to do. | 20:39 |
| lifeless | also | 20:39 |
| mtaylor | hrm | 20:39 |
| lifeless | you probably have your 'use weave merge' settings still | 20:39 |
| lifeless | because lp doesn't have all plugins installed | 20:40 |
| lifeless | and doesn't have per project tweaks | 20:40 |
| mtaylor | I do? I don't have that set up at all | 20:40 |
| lifeless | it cannot predict faithfully whats going to happen | 20:40 |
| lifeless | hm | 20:40 |
| lifeless | well | 20:40 |
| salgado | 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 |
| mtaylor | 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:43 |
| lifeless | uhm | 20:44 |
| lifeless | it may have conflicted before trunk changes | 20:44 |
| lifeless | we don't recalcualte the diff except when the branch itself changes | 20:45 |
| mtaylor | ah | 20:46 |
| mtaylor | ok. that explains it | 20:46 |
| mtaylor | lifeless: I would like to request a "regenerate diff" button then | 20:47 |
| lifeless | mtaylor: me too the bug then | 20:48 |
| lifeless | I don't want a button | 20:48 |
| lifeless | I want DTRT | 20:48 |
| lifeless | regenerate the diff when you land on the page | 20:48 |
| lifeless | or something | 20:48 |
| mtaylor | well yeah, that would be great | 20:51 |
| james_w | salgado: yeah, DSCFile will find the .orig.tar.gz in that path, even though it isn't in the .changes? | 20:52 |
| mtaylor | I only want a button in as much as I want to be able to make sure I can do a current review | 20:52 |
| salgado | 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 |
| james_w | salgado: I haven't dug that far. That would be the intention though | 20:53 |
| mtaylor | while I'm whinging - it would be great if I could see all bugs with a certain tag regardless of project ... :) | 20:54 |
| lifeless | mtaylor: patches ... | 20:57 |
| james_w | salgado: yeah, DSCFile._getFileByName as part of DSCFile.checkFiles should get the LFA and compare the checksums | 20:58 |
| mtaylor | lifeless: yeah - getting closer. todo list... long | 20:59 |
| salgado | james_w, ok, I'll make a comment explaining that the test is cheating. thanks for the help | 21:00 |
| james_w | salgado: what's the failures | 21:00 |
| james_w | salgado: I don't see why the test should have to cheat | 21:00 |
| james_w | Is it "Unable to find %s in upload or distribution."? That would make sense | 21:01 |
| salgado | 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 |
| james_w | ah, I see what you mean. Does the test fail if you delete that file? | 21:02 |
| salgado | it does, yes | 21:02 |
| mwhudson | gary_poster: ping | 21:53 |
| gary_poster | hey mwhudson! I have to run really soon, but can talk for a sec | 21:53 |
| mwhudson | gary_poster: i wanted to talk a little about buildout | 21:53 |
| gary_poster | sure | 21:53 |
| mwhudson | gary_poster: for linaro we're open sourcing an internal project | 21:54 |
| mwhudson | and a set up like launchpad uses for managing dependencies would probably work well | 21:54 |
| mwhudson | but as with launchpad, the tendency of buildout/setuptools to go grabbing things off the internet is a bit undesired | 21:55 |
| mwhudson | i seem to recall that you had to patch buildout to support this | 21:55 |
| mwhudson | are those changes upstream yet> | 21:55 |
| mwhudson | ? | 21:55 |
| jml | hello again Launchpadders. | 21:55 |
| mwhudson | also i remember you said you had a better plan that a branch for the download-cache, but i can't remember what it was now | 21:55 |
| gary_poster | My changes are about being able to use a system Python | 21:55 |
| mwhudson | oh ok | 21:56 |
| gary_poster | They will hopefully be released next week in a beta 3 (a previous version was beta 1) | 21:56 |
| gary_poster | You have two options for what (I thnk) you want | 21:56 |
| gary_poster | 1) you can do the bzr-managed download-cache. Kinda lame as you know, but gets you off the ground. | 21:57 |
| gary_poster | 2) you can set up a random apache directory (mars is using devpad.canonical.com/~mars/pypi or something like that) to store the eggs you want and point the deployment to that directory using find-links. If that's in the data center then you are good. | 21:58 |
| gary_poster | Actually third option: | 21:58 |
| mwhudson | gary_poster: what are the issues with using a system python? trying to not use the stuff from that python's site-packages? | 21:59 |
| mwhudson | gary_poster: also, one more question, one of the dependencies is a very large js library | 21:59 |
| gary_poster | 3) you can use zc.sourcerelease for your own deployments. This means that it goes over the internet when you build a package up to deploy. Then you send the tgz over to where you want to deploy and run a provided script. Ask mars for an example of how he is using it. | 22:00 |
| lifeless | jml: why hello there | 22:00 |
| mwhudson | gary_poster: would it be possible/not completely crazy to write a recipe that extracts the tarball and puts it somewhere so the code can find it? | 22:00 |
| mwhudson | gary_poster: zc.sourcerelease means you basically create a tarball that already has the eggs/ directory populated doesn't it? | 22:01 |
| gary_poster | system python: yeah, stuff in debian's site-packages is installed in a very different/conflicting way than other egg installations. Lots of other niggly problems. my patch lets you use system Python and still use some of the dependencies in it, or not as you wish. | 22:02 |
| mwhudson | ok | 22:02 |
| jml | I wonder if I should convert unexpected test runner errors into a result.addError call. | 22:02 |
| jml | I think that will be simpler. | 22:02 |
| mwhudson | i guess i need to try to understand that issue then | 22:02 |
| gary_poster | very large js library: if it is packaged as Python library, np. if it is packaged as a configure-make-make install, there's zc.recipe.cmmi. dunno what to tell you about that | 22:03 |
| mwhudson | ok | 22:03 |
| mwhudson | i was a tiny bit surprised that there didn't seem to be a recipe for "untar this tarball *here*" | 22:03 |
| gary_poster | write a recipe that does a tarball: yeah, sounds like zc.sourcerelease | 22:04 |
| lifeless | jml: what does it do today? | 22:04 |
| gary_poster | zc.recipe.cmmi might, not sure | 22:04 |
| jml | lifeless, has a special logger method "error_in_testrunner", re-raises. | 22:04 |
| mwhudson | gary_poster: ok, i'll take a look | 22:04 |
| lifeless | >< | 22:04 |
| mwhudson | gary_poster: did you consider other things like virtualenv + pip for launchpad? | 22:05 |
| mwhudson | this is a whole space that i've kind of seen moving around from a distance for a long time, but not really paid any attention to | 22:05 |
| jml | lifeless, before it just printed stuff to some files | 22:05 |
| gary_poster | mwhudson, http://pypi.python.org/pypi/zc.recipe.cmmi has the string "tgz" in the docs ;-) | 22:06 |
| lifeless | oh | 22:06 |
| lifeless | that reminds me | 22:06 |
| lifeless | time to mail barry a 'python packing is all wrong and heres what the stdlib has to do to fix it' note | 22:07 |
| gary_poster | virtualenv + pip: perhaps not as closely as I should have, but yes. virtualenv does not let you install eggs robustly with a system python. It lets you make a virtual python with *no* system packages if you want | 22:07 |
| gary_poster | but not letting some through | 22:07 |
| gary_poster | which is what we wanted | 22:07 |
| mwhudson | i think that's what we'll want too | 22:08 |
| mwhudson | for psycopg2 and stuff like that | 22:08 |
| gary_poster | I won't comment on pip, because I'd probably make an a** of myself | 22:08 |
| gary_poster | right | 22:08 |
| barry | lifeless: pythons generally don't know how to pack, that's why they always arrive with way too much luggage than they need | 22:08 |
| mwhudson | gary_poster: i at least hope to avoid having bzr branches in a directory called sourcecode/ :-) | 22:09 |
| gary_poster | mwhudson: +1 :-) | 22:09 |
| lifeless | mwhudson: what is the problem with that? | 22:09 |
| gary_poster | mwhudson, I really have to release the new version of buildout. I was on vacation last week and had a dental operation. this week. I'll try to make the release next week. | 22:10 |
| mwhudson | lifeless: well, having 2 mechanisms for managing dependencies is bad enough | 22:10 |
| lifeless | mwhudson: agreed | 22:10 |
| gary_poster | so that will help with the system Python thing if you go that way | 22:10 |
| gary_poster | jml, do you happen to know if twisted.web.wsgi.WSGIResource is pretty cooked? Putting that in front of Launchpad instead of ZServer seemed interesting | 22:10 |
| gary_poster | I thought it might go a ways to giving an avenue for something lifeless was interested in | 22:11 |
| lifeless | \o/ | 22:11 |
| mwhudson | long poll? | 22:11 |
| lifeless | yeah | 22:11 |
| gary_poster | yeah | 22:11 |
| mwhudson | lifeless: we haven't completely ruled out making debian packages of everything either | 22:11 |
| lifeless | mwhudson: that would rule | 22:11 |
| mwhudson | but there are issues there too | 22:11 |
| lifeless | mwhudson: but, there are some functional issues | 22:11 |
| lifeless | hah | 22:11 |
| jml | gary_poster, no idea | 22:12 |
| mwhudson | like all the deps are already on the cheeseshop but not in ubuntu | 22:12 |
| mwhudson | and currently rollouts don't require root | 22:12 |
| gary_poster | debian packages issue: no good for people who aren't on debian | 22:12 |
| gary_poster | rollouts don't require root: I'm pretty sure James would be happy to get rid of that requirement in exchange for getting everything packaged | 22:13 |
| mwhudson | i hear rumours that using debian packages doesn't strictly *require* root for rollouts, but i don't know anything about them | 22:13 |
| mwhudson | gary_poster: people who aren't on debian/ubuntu can always use a vm ;-) | 22:13 |
| gary_poster | ack jml, thanks | 22:13 |
| gary_poster | heh :-) | 22:13 |
| gary_poster | ok guys I have to run | 22:13 |
| mwhudson | i don't think there are any known problems with WSGIResource currently... | 22:14 |
| mwhudson | gary_poster: thanks | 22:14 |
| gary_poster | np :-) | 22:14 |
| gary_poster | have a nice ...day or night | 22:14 |
| mars | mwhudson, regarding zc.sourcerelease: it works pretty well. It bundles the download-cache into the tgz, you run 'install.py' on the target system and it builds in place (download-cache items become eggs) | 22:25 |
| barry | lifeless: yep. mind if i forward your message to tarek and/or distutils-sig? | 22:25 |
| mars | I am using it right now to run the latest versions of bzr, launchpadlib and httplib2 onto devpad (which still runs hardy) | 22:26 |
| === salgado is now known as salgado-afk | ||
| lifeless | barry: sure | 22:29 |
| lifeless | barry: it may not need stdlib changes | 22:29 |
| lifeless | barry: but it needs a champion in the debian community, one that can sensibly decide when something needs to be in-stdlib to be used, or just new-conventions | 22:29 |
| lifeless | barry: for instance, one problem is that eggs are installed unversioned | 22:30 |
| barry | lifeless: but eggs aren't used in debian packaging, right? | 22:31 |
| lifeless | barry: they are | 22:31 |
| lifeless | barry: dpkg -S egg-info | 22:32 |
| lifeless | If I had more tuits I'd try just doing it | 22:32 |
| barry | lifeless: oh i see what you're saying. not the .egg format, but egg-infos | 22:32 |
| lifeless | well | 22:32 |
| lifeless | all the various bits of machinery | 22:32 |
| lifeless | you could put eggs on disk | 22:33 |
| lifeless | or you could use the version number to put unpacked egg dirs on disk and .pth files | 22:33 |
| lifeless | or whatever | 22:33 |
| lifeless | lots of options | 22:33 |
| lifeless | the key thing is that | 22:33 |
| lifeless | a simple 'import foo' needs to keep working | 22:33 |
| barry | lifeless: thinking about this more, it's probably a debian-python policy thing. and the trick will be in either setting up sys.path correctly, or adding import support in python (or a combination of both) | 22:39 |
| lifeless | right | 22:39 |
| lifeless | its -nearly- done | 22:40 |
| barry | lifeless: i have to leave now (for an early rehearsal). let's talk tomorrow or next week about it some more if you want | 22:42 |
| lifeless | I don't want to talk about it... just want it working :) | 22:42 |
| lifeless | But I'm happy to help-by-talking :P | 22:43 |
| lifeless | -> new house ADSL connection, one hopes. | 23:44 |
| wgrant | Gah. | 23:50 |
| wgrant | Why do so many people want a server-side GitHub-like 'Fork' feautre? | 23:50 |
| wgrant | This isn't Git, people... | 23:50 |
| mwhudson | wgrant: because github is perfect, clearly | 23:53 |
| jelmer | wgrant: because doing so is hard using the command-line in git.. | 23:53 |
| wgrant | jelmer: My guess is that it's because Git doesn't have stacking. | 23:54 |
| mwhudson | more seriously, we probably need to work on documenting workflows with launchpad + bzr | 23:54 |
| mwhudson | wgrant: i think it's because git push expects there to already be something git-ish on the remote side | 23:54 |
| wgrant | mwhudson: Yeah, some documentation on code.launchpad.net/blah would be nice. | 23:55 |
| wgrant | It'd also be nice if one could just push to lp:project without a branch being there already. | 23:56 |
| mwhudson | thumper is working on that... | 23:58 |
| wgrant | Yay. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!