[00:07] hi [00:07] I'm trying to configure my lp instance for remote access, and I'm in the /etc/hosts file [00:08] is this rule supposed to remain unchanged? 127.0.0.77 vostok.dev archive.vostok.dev [00:08] have you looked on the wiki [00:08] Running/VM [00:08] I think [00:09] covers some sutff [00:11] I hadn't, because I'm running this on a physical machine :-) [00:11] has the same issues though [00:11] note that a dev environment isn't suitable for production use (in case thats what you're trying to do) [00:12] I'm experimenting, but that was the eventual plan, yes [00:12] hosts files are local - you'll need actual DNS, ssl certificates, front end servers etc [00:13] Unless I use ssh forwarding, I still get unstyled main pages that say: Lost something? [00:13] There’s no page with this address in Launchpad. [00:13] (For the front page.) [00:14] you'll need a production config, lazr schema, slave db etc too [00:15] we don't really document how to run production LP - its not something that was envisioned when we open sourced it (note too that you /must/ rebrand it - the look n feel is not opened) [00:15] you may want to record the things you learn on the wiki somewhere. [00:16] I don't know why you'd get Lost something pages, unless you're bypassing your front-end apache [00:16] I'm not trying to kick any shins, I'm fine just using ye olde bzr + roundup... [00:17] sorry, I can't parse that [00:17] (Is there a canonical acronym for LAMP, but for developing software instead of serving webapps?) [00:18] lifeless: I'm not trying to piss people off by running my own instances of lp that aren't for developing lp. [00:18] lifeless: If that's something you don't want people doing, that's fine -- unfortunate, since that means I have to set up like twenty things instead of one, but I'll survive :-) [00:19] its fine to run your own instance, thats clearly something the AGPL permits; What you can't do is use the launchpad branching - the stock icons, widget set - because thats (IIRC) trademarked. [00:19] lvh: I am curious why you want to run your own instance rather than use launchpad.net (but its not really my business :)) [00:19] Doesn't that just prohibit use to the public? [00:19] (but ask counsel for detailed use restrictions on trademarks) [00:20] persia: https://dev.launchpad.net/LaunchpadLicense [00:20] lifeless: IANAL but I did the relevant parts of a law degree [00:20] (Enough to know nobody really understands the AGPL ;-)) [00:21] I wasn't part of the open sourcing process; its a bit neither-fish-nor-fowl at the moment. [00:21] it would be nice to move the theming into a dedicated tree and just say 'whats in tip, is fully agpl, go free'. [00:21] but there's some implications for test and development [00:21] lifeless: Mostly because I'm researching development stacks at the moment [00:21] lifeless: for closed-source stuff [00:22] lvh: sure. Are you aware that launchpad.net supports closed-source stuff ? [00:22] lifeless: Yes [00:22] great [00:22] lifeless: I think their pricing system is wrong ;-) [00:22] anyhow, I hope I've helped with the issue you're seeing [00:22] lvh: have you given that feedback to mrevell ? [00:22] lifeless, Makes sense. I simply don't know enough of the relevant precedent to know if it's enforceable in cases where it's undiscoverable. Given that it's an explcit restriction on license, rather than just a trademark claim, I'm no longer tempted to believe it's a public/private thing (which is the common trademark model) [00:22] lifeless: Yeah. [00:22] lvh: ok, cool [00:23] lifeless: Something along the lines of "I see your point, but it works for some people, and we're not changing it anyway" [00:23] mmm [00:23] nothing is unchangable [00:23] lifeless: (I believe you should limit *people*, not *projects*) [00:24] Or at least not primarily projects. [00:24] (because?) [00:24] (And about a week after I blogged about that, Atlassian went out and did it with Bitbucket) [00:24] lifeless: Well, practical example [00:25] lifeless: Small interdependent pieces of code: good, big monolithic pieces of code: bad, right? [00:25] bitbucket does closed source by user, not product ? [00:25] lifeless: bitbucket lets you make infinite repos [00:25] closed or open [00:25] yeah, I can see the argument. [00:25] it makes sense to me. [00:25] lifeless: however, if you want to *share* those repositories, that's when it costs you [00:25] for 5 or below, it's 0, etc [00:26] afterall users are what incur costs, not small bits of metadata. [00:26] right [00:26] plus everything else pretty much bills you per user [00:26] the cutoff point is pretty high too [00:27] 250/yr, let's say 20/month [00:27] that gets you 25 users at bitbucket, which isn't a trivial two-bit operation anymore [00:27] and they get infinite projects [00:28] (I realise my comparison is flawed because bitbucket doesn't have merge proposals and their bugtracker is useless, but you get the basic idea) [00:28] yeah [00:29] we're primarily here for open source though [00:29] somewhat different concerns [00:29] well, that's true, but [00:29] the closed source stuff is so I *can* work on open source stuff for free [00:29] I still gotta eat at some point in time [00:29] sure [00:30] (it actually says that explicitly in the notary ... not sure what the correct english term is. deed? document-that-starts-a-company. One of the goals of the comapny is to contribute to open source projects) [00:31] cool [00:31] articles of incorporation [00:31] constitution [00:32] depends on the country [00:32] yeah, I'm from belgium, country-ish things are vague and fleeting [00:32] hmm, the quake a wee bit back was a 5.0 [00:35] http://www.geonet.org.nz/earthquake/drums/ [00:35] Doesn't that just prohibit use to the public? (but ask counsel for detailed use restrictions on trademarks) [00:35] this is kind of fud-ish [00:35] i know it's not meant maliciously [00:37] poolie, It's structurally built into things: it's published that anyone providing legal advice who is not so licensed (where I live, where you live, and many other places) can be (successfully) sued by any counsel without such comments. [00:37] well, don't provide legal advice then [00:38] if i say "how do i set up gpg" and you tell me "ask counsel for detailed use restrictions" it may be technically true but it's not very welcoming [00:40] do you see what i mean? [00:40] That's kinda different. I may be overcareful when it comes to disclaimers when talking about licenses, trademarks, patents, etc., but I don't think it's better to not talk about them. [00:41] i think it's better not to say something vaguely worrying [00:41] Which is the worrying bit? [00:44] the "ask counsel" bit [00:49] I guess. Similar to IANAL. Anyway, off-topic, and taking to /query [00:56] yeah, i guess it is just "ianal" [00:56] to me, it's a more alarming way of saying it, but i see what you mean === Ursinha-afk is now known as Ursinha [01:14] lifeless: hey, did you figure out your testtools error? [01:14] no [01:14] no idea at all [01:14] lifeless: i mean "Subject: [Launchpad-dev] Fwd: Test results: testtools => devel: FAILURE" [01:14] lifeless: i just had a WAG [01:15] \o/ [01:15] basically == anything is true? [01:15] so perhaps some change in testtools now tests types, or something? [01:15] i.e. the tests were already bong [01:15] could be [01:15] I'll look more closely; thanks. [01:16] lifeless: hmm, doesn't look likely actually [01:16] but it's still worth checking i guess [01:30] lifeless: i was right, the test is broken [01:30] lifeless: and the reason your branch exposes it is that some change in testtools flips the order of the comparison [01:31] (Pdb) p operator.eq(matchee, matcher.expected) [01:31] False [01:31] (Pdb) p operator.eq(matcher.expected, matchee) [01:31] [01:31] \o/ ? [01:31] hah [01:32] Heh. [01:32] self.assertEqual(UTC_NOW, branch.next_mirror_time) [01:32] sigh [01:33] should be [01:33] self.assertSqlAttributeEqualsDate(branch, 'next_mirror_time', UTC_NOW) [01:33] i guess [01:33] lifeless: i guess you can fix that in your branch? [01:34] otp [01:34] k [01:34] the other failure is probably something similar [01:35] are we still importing the with statement from the future? [01:38] no need [01:38] so we are 2.6 everywhere now [01:38] ? [01:38] yes [01:38] no [01:38] w00t [01:38] I lied [01:38] was there an email? [01:38] future still [01:38] yes [01:38] There were a few emails, all contradicting each other. [01:38] thread with mars and me [01:39] so... [01:39] from __future__ is still needed [01:39] still future [01:39] ok [01:39] The PQM chroot? [01:39] Or is there something else? === Ursinha is now known as Ursinha-afk [02:18] Project db-devel build (82): STILL FAILING in 3 hr 44 min: https://hudson.wedontsleep.org/job/db-devel/82/ [02:18] * Launchpad Patch Queue Manager: [r=abentley][ui=None] Add database patch for branch merge queues [02:18] * Launchpad Patch Queue Manager: [r=rockstar][ui=none][bug=662664] Ensure recipe builds run only under [02:18] Xen [02:30] mwhudson: thanks for looking into that [02:31] lifeless: s'ok -- i hate mysteries :) [02:31] wild stab in the dark, but I thought "bin/test -m lp.code.windmill" would only run the code windmill tests [02:32] * thumper thinks [02:32] actually I think there is a bug layer one there [02:32] canonical.testing.layers.LayerIsolationError: Test didn't reset the socket default timeout. [02:32] anyone seen that running windmill tests? [02:34] http://i.imgur.com/IOBPq.jpg [02:37] I wonder how many page loads were needed to get the right ad :) [02:38] :) [02:38] ERROR DISABLED: Test left new live threads: [] ?!? [02:41] thumper: bin/test -vvt code.windmill.tests has been working for me [02:41] but yours should have worked too i guess [02:41] i'm also seeing the live threads stuff [02:53] bombs away [02:56] An interesting proposal. [02:56] 3 minutes, you're running slow [02:57] Shh. [02:57] ;) [03:00] wgrant: any more feedback than that ? [03:01] lifeless: I think it's a good idea to try it. [03:01] As long as the scope is clear. [03:01] But I haven't really got time to think about it too much at the moment. === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [04:35] wgrant, if you are talking about lifeless' reviews experiment: the scope is 'anything that requires craftsmanship', which basically means even a single line of code: SQL, Python, or otherwise. [04:50] mars: hi [04:51] mars: I think you're projecting [04:51] mars: I realise my examples can be categorised that way, but its not what I meant. [04:51] s/project/something/ [04:59] lifeless, yes, but as wgrant pointed out, drawing the line can be difficult. I just pointed out a minimum point at which the line may be drawn. Hopefully discussion will take us beyond that. [05:00] * mars signs off for the night - bye! [05:59] wallyworld_, I'm tempted to just say "forget the test, just land the code" [06:03] * persia suspects that is a recipe for summoning for certain well-meaning over-knowledgeable folk [06:11] persia, then I punt to them. :) [06:26] rockstar: whats the question ? [06:28] Project devel build (130): STILL FAILING in 3 hr 56 min: https://hudson.wedontsleep.org/job/devel/130/ [06:29] rockstar: i'd still like to know what's going on [06:29] lifeless: the issue is that some ajax stuff works fine but fails under windmill [06:32] ugh [06:32] that sucks [06:33] yep. basically Y.io(...) is just plain failing [06:33] wallyworld_: btw [06:33] bug 663068 [06:33] <_mup_> Bug #663068: Remove hard coded test urls [06:33] the tag is unusual [06:33] normally bugs are put on the launchpad-foundations *project* with separate tags ;) [06:34] bugger. i stuffed that one up. sorry [06:34] no worries [06:34] I've fixed [06:34] thanks [06:34] but I thought something might have got lost in translation [06:34] so letting you know [06:34] bug 663068 [06:34] <_mup_> Bug #663068: Remove hard coded test urls [06:34] see^ [06:35] * wallyworld_ files mental note [06:35] I think it would be nice to have all bugs on the launchpad project [06:35] but thats not the current practice ;) [06:36] well, it would make it easier perhaps [08:18] mwhudson: looks interesting vis a vis our discussion earlier - http://pypi.python.org/pypi/withrestart/0.2.7 [08:19] not sure its tasteful though ;) [08:36] good morning [08:54] jelmer: hi [08:55] jelmer: the thing you CP'd. what rev of trunk is it? (by CPing you've kind of blocked all deployments till we catch up, now that we're on the new process) [08:55] jelmer: I want to assess what we should do now [08:56] hmmm [08:56] 9pm [08:56] time to write some code [08:56] [one of those days] === almaisan-away is now known as al-maisan [09:23] good morning [09:24] morning [09:28] hmmm, leaked config dirs [09:30] lifeless: any traction on your testtools => devel fail? [09:30] some [09:30] its a storm expr being used in the test [09:30] so its dependent on the magic ordering of == [09:31] lifeless: oh wow. [09:31] we need to rewrite those tests, shallowly, or thoroughly [09:31] lifeless: ok [09:31] mwhudson dug into it, and phrased it as broken. [09:31] :) [09:31] lifeless: I retract any offer of help that my enquiry might have implied :P [09:31] hah! [09:34] jml: did you see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/662519 ? [09:34] <_mup_> Bug #662519: lp test startup exhausts dev/random [09:34] no [09:34] but I love that title :) [09:34] it will add some hilarity to your day [09:35] of all of the problems that I would have guessed we had... [09:54] jml: well, the thing about surprises [09:57] wgrant: hello [09:59] bigjools: Hi. [09:59] wgrant: evening. I'm trying to test your fix for bug 629921 [09:59] <_mup_> Bug #629921: Archive:+packages with empty name search does like '%%' search.

[10:00] bigjools: Navigate to the page ++oops++, filter to Superseded packages, verify that the query isn't insane. [10:00] wgrant: it's timing out [10:00] ... hah. [10:00] I don't need a ++oops++ :) [10:01] Declivitous? [10:02] yes [10:03] It sounds negative. [10:03] it means "sloping down steeply" [10:04] Ah. [10:04] we're half way through the development [10:04] Optimistic! [10:05] not really [10:13] bigjools: I have the first three lucilleconfig-elimination branches proposed, if you'd like to eyeball them. [10:13] I still need to work out what to do about the germanium temproot issue, though. [10:14] wgrant: I don't have the time right now - I can look probably Thursday if you can sit on it a while [10:14] bigjools: Sure. [10:14] No urgency. [10:14] yeah :) [10:15] I am doing QA on your other publisher change at the moment [10:15] Ah, thanks. Sorry for leaving that to you, but I can't really do it myself yet... [10:15] indeed [10:16] right now you do increase my workload quite a lot :) [10:19] https://code.edge.launchpad.net/~jml/launchpad/codebrowse-port-config/+merge/38812 – need a review [10:19] it's part of getting qastaging up [10:19] +1 [10:19] lifeless: heh heh [10:19] lifeless: thanks [10:20] lifeless: can you please rubber stamp for landing tools. [10:20] I did [10:21] wgrant: the next thing you might want to look at that would be most beneficial if you're feeling like doing more work is to do that query speedup in the domination [10:22] the PPA publishing cycle is slow :/ [10:22] bigjools: Yeah, I need to do that. But I want to try to fix the actual query. [10:22] wgrant: fix? [10:22] bigjools: To not use a temp table. [10:22] lifeless: ta [10:22] wgrant: there's nothing wrong with that [10:22] bigjools: A big part of the publisher slowness (at least locally) is the regular cache purging. [10:23] Removing that cuts a primary run from >1min to <10s. [10:23] are you talking about the storm cache? [10:23] (every (distroarchseries, pocket) domination clears the Storm cache twice) [10:23] right [10:24] the first question is - why does it need to flush it [10:24] I'm not sure hwo dumb our cache eviction strategy is. [10:24] It may not evict at all. [10:25] I'm sure lifeless will have something useful to contribute :^) [10:26] beware the tides, wait oh what ? [10:26] storm cache depends on the cache thats installed [10:27] we have a custom one [10:27] I don't recall the details about when its installed [10:27] how does the sql temp table relate to storm cache flushing? [10:27] I no approximately nothing [10:27] jeez [10:27] know* [10:27] lifeless: I don't think it should relate, besides being in roughly the same piece of code. [10:27] lifeless: this is something that cprov may have talked to you about in the past when we started using storem [10:28] ok, so I was confused ;) [10:28] bigjools: which this do you refer to ? [10:28] wgrant: so are we talking storm performance or the query ? [10:28] lifeless: caching on the publisher [10:28] The publisher drops caches. [10:28] Frequently. [10:29] ok, as a correctness thing I guess? you're changing values in the db [10:29] lifeless: see judgeAndDominate() inside lib/lp/archivepublisher/domination.py [10:29] which calls clear_cache() [10:29] That code isn't *too* painful any more. [10:29] So you won't go insane from reading it. [10:30] I don't think it's correctness. [10:30] We create a temp table, read in a list of publications from it, then use Storm operations on those. [10:30] lifeless: I've no idea why it needs to flush_database_updates() then clear_current_connection_cache() then gc.collect() [10:31] I have a vague recollection of it blowing memory into small pieces [10:31] bigjools: Because it wants to take 20 minutes :D :D :D [10:31] yeah [10:31] I don't see why it would be dealing with a particularly huge number of objects. [10:32] the conection cache so cccc is store.invalidate [10:32] At worst it should be a few thousand during an autosync run. [10:32] blah late night typing [10:32] so you could do this in a more direct form [10:32] drop the store object [10:32] put a new one in its place [10:33] wgrant: I agree - but - numbers will help. [10:33] lets get peak memory utilisation logged (sys.utimes or whatever) [10:33] it is logged [10:33] great [10:34] hows it look at the moment? [10:34] actually - maybe it's not logged for domination [10:35] ah it's deathrow that does it [10:35] it uses process_in_batchers [10:35] bah [10:35] sigh [10:35] librarian hates [10:35] process_in_batches [10:36] psycopg2.OperationalError: FATAL: database "launchpad_ftest" does not exist [10:36] bigjools: Doesn't lots of publisher stuff use that? [10:36] Or is PublishingTunableLoop a separate thing? [10:36] There are a few things like that. [10:36] wgrant: just deathrow and ftparchive it seems [10:36] Ah, yeah. [10:36] when overriding, for the latter [10:36] Not for generating file lists too? [10:37] ah yes [10:37] Yeah. [10:37] I've been in that code a bit lately... [10:37] :) [10:37] lucky you [10:38] Hey, deleting crappy code makes a good break from finishing my last two projects evaar. [10:38] I am running the ubuntu publisher on DF at the moment, when it finishes in about an hour or so we'll see if your other fix worked [10:38] if the publisher code is a break, I'd hate to see what your projects look like [10:39] bigjools: The file list generation really takes most of that time? [10:39] Not a-f itself? [10:39] I do not understand :( [10:41] wgrant: domination is SLOW [10:42] bigjools: The three minutes it takes on production is also slow. But I guess your definition is different. [10:42] dogfood is spethial [10:44] jml: hey, whats 'stnadard' to log something in twistd [10:44] 2010-10-19 09:38:42 DEBUG Sorting packages... [10:44] 2010-10-19 09:43:39 DEBUG Dominating packages... [10:44] wgrant: ^ [10:44] bigjools: Ah, so only twice production's slowness. [10:44] Not so bad. [10:44] lifeless: log.msg(), where log = twisted.python.log [10:54] jml: nothing gets logged [10:55] jml: I guess the log only shows after the tac is parsed? [10:55] lifeless: that sounds vaguely familiar [10:55] lifeless: but I don't know for sure. [10:56] I wonder how I can easily make this easier to debug [10:56] lifeless: also, our tachandler nonsense might interfere with early logging === bac` is now known as bac [11:17] wgrant: filelist generation is the slowest part on dogfood it seems. Probably production too. [11:18] bigjools: Better than before cprov fixed it a year ago... [11:20] bigjools: Prod file list calculation seems to take just a couple of minutes. [11:21] Then a-f takes ~15 minutes. [11:22] Debian recently parallelised a-f calls. [11:49] Project db-devel build (83): STILL FAILING in 3 hr 54 min: https://hudson.wedontsleep.org/job/db-devel/83/ [12:04] Morning, all [12:23] bigjools: btw, now that the first cut of testtools twisted support has landed, I'm blocking on the mega-branch for converting all our trial tests & deleting the twisted layers [12:23] jml: sweet [12:23] jml: are you going to make the change so I can merge it? [12:24] bigjools: no, I'm going to wait until your branch lands before I try to land on trunk [12:24] ok [12:24] bigjools: Launchpad doesn't have the testools twisted support yet, it's only landed in testtools trunk. [12:24] bigjools: Has dogfood blessed me yet? [12:25] wgrant: hahaha no [12:25] :( [12:25] 2010-10-19 09:50:16 DEBUG Calculating binary filelist. [12:25] 2010-10-19 11:16:49 DEBUG Iteration 9 (size 10000.0): 518.693 seconds [12:25] bigjools: I'm working on the existing twisted tests in LP in a branch now, working out the kinks with my perfect-in-theory twisted support code [12:25] 2010-10-19 11:25:25 DEBUG Iteration 10 (size 10000.0): 516.320 seconds [12:25]