=== flacoste is now known as flacoste_afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === mup is now known as _mup_ [03:24] is it just me, or are pages like https://bugs.edge.launchpad.net/bzr/+bug/4800 rendering really ugly for other folk ? [03:24] <_mup_> Bug #4800: Unwanted side effect of umask and 'bzr rspush' [03:24] the right hand side particularly [03:25] Already fixed. [03:25] Broke yesterday. [03:25] the overlapping areas? [03:25] Yep. [03:37] lifeless: sinzui has submitted a fix already [03:38] cool cool [03:39] Already in stable, so it'll be on edge tonight. [03:42] Should our test harness set the random number seed, or would that allow bugs to leak through? [03:42] Neither [03:42] it should be random by default [03:42] and you should be able to specify it if you need to reproduce a specific test run. [03:43] if you need a particular non-random-from-random-source sequence in a test, make the randomness provider replaceable for that code path. [03:43] IMO, YMMV, HTH [03:47] Because bugs might leak through? [03:49] largely [03:49] I know it wouldn't be an ideal architecture, but it might be practical. There are a few timebombs (which we triggered recently) we wouldn't have to worry about. I can't recall any bugs where random randomness saved us, but we don't have a large sample size. [03:49] more importantly though [03:50] if you set the random seed, you'd have to do it for every test separately [03:50] the randomness was for subsequent make harness runs (I believe) [03:50] so the factory didn't bitch [03:50] about a user already existing [03:50] when we just wanted some user [03:50] otherwise every time a test that uses randomness is added before an existing test using randomness, that latter test will blow up, if it depends on the output. [03:50] I'm with lifeless that the factory should have a seed set when created [03:50] if it needs to be tweaked [03:50] it should be alterable [03:51] but that would be enough IMO [03:51] sorry, are we talking test runs, or local-instance stuff ? [03:51] local-instance I don't care a hoot about in terms of this discussion - whatever works is fine [03:52] but test run changes can have serious maintenance impact [03:52] lifeless: we are getting spuriour test failures because factory created 'things' [03:52] lifeless: are now getting 'random' string names [03:52] which when searching for the non-existance of 'foo' sometimes fails to work [03:52] random random, or serial-numbers from an in-python generator ? [03:53] I've not looked recently [03:53] but random enough that 'foo' turns up in the random characters [03:53] this sounds like an isolation issue between tests ? [03:53] no [03:53] it is the factory [03:53] and a bug in that [03:53] although a bug in the fact that it isn't doing what we want [03:54] ok, so a given test starts with a clean sample-db; makes something using the factory, and then asserts that 'foo' doesn't exist, and sometimes it does. [03:54] in creating a project that won't match by name [03:54] lifeless: yes [03:54] ok [03:54] abentley and I talked about this on Friday and I think he had a branch in progress that fixed this [03:55] back to appending numbers to strings [03:55] if you're suggesting that you should be able to say 'do not call it foo' in the calls to the factory, that sounds appropriate to me. [03:55] alternatively, you could ask the factory 'what is an unused name' [03:55] and not random characters [03:55] I don't think so [03:55] the factory doesn't know what is an unused name [03:55] and it isn't matching 'foo' exactly [03:55] what we might say [03:56] is 'foo' in some unique branch name [03:56] one failure was a vocab search test [03:58] sure, just putting it out there. [03:58] in that 'make a unique thing' is a general factory function [03:58] and 'does not match' is still a case of making a unique thing [03:58] oh, and I hate my wifi driver [04:13] Or we can seed the random module (one line in one of the layers, or pass the seed as a parameter to Factory.__init__ and have readable tests... [04:14] vs. possibly not picking up genuine failures (although these failures may never show up anyway due to probability) [04:15] Still, first time it happened so maybe not worth changing anything and just tweaking the test [04:21] stub: I don't see that seeding the random module will avoid these issues [04:22] stub: can you lay out how it would help for me ? [04:22] The tests become deterministic [04:23] so if you pick a seed that works for existing tests, and every test has the same seed, what stops new tests from running into bad data at a different point in the sequence ? [04:23] You know what random.random() returns, thus Factory.makeSomethingWIthRandomName() returns an object with a random but known name, [04:23] The test will fail consistently so will never land [04:23] ok [04:23] I think I'd be more comfortable with the factory holding its own random generator and not futzing with the global generator [04:24] which sounds like what thumper was saying abentley was working on [04:25] If calling random.seed(xxx) in BaseLayer.testSetUp is futzing, then sure. BaseLayer would fix other occurrences too but maybe YAGNI [04:27] I have no idea if Aaron was fixing it that way or some other mechanism (generating random names from a smaller set of characters for instance, or prefixes or suffixes (although that doesn't help for substring matches, which I think is what we hit), or just refactoring the tests) [04:27] better to do [04:27] generator = random.Random(xxx) [04:27] and then return values from generator [04:28] that way you don't interact with any modules using the global random generator [04:28] and conversely, won't be broken if lp code itself were to start using more random values - throwing off the determinism you're going to be relying on. [04:34] I'm not suggesting that every value be random [04:34] just the first one [04:34] we used to add a unique integer to the end of the base string [04:35] this would create person1, person2 etc [04:35] what I suggest is that we seed the initial value with a random number [04:35] (which can be overridden if necessar) [04:35] and still do the increment and add approach [04:35] I like that [04:35] it is simple [04:35] and simple is good [04:47] ok, nose.against(grindstone) === mpt_ is now known as mpt [08:23] good morning [08:36] wgrant: The local Launchpad installation is online and should now be AGPL compliant... https://quickbuild.pearsoncomputing.net/ [08:36] In case you're interested ;-) [08:36] There is still the Ubuntu/Debian issue, but I'm working on that as I have time [08:37] Let me know if you see any potential copyright issues (e.g. I missed an image or something isn't quite right about the GPL stuff) and I'll fix them right away [08:40] Goodly morning [09:02] hi mrevell === almaisan-away is now known as al-maisan [11:02] Morning, all. [11:37] Hi. I need a second opinion on a couple of vcs-imports reviews [11:37] I did email the list, but no one responded [11:37] So I'm prodding :-) [11:53] maxb: what import? [11:58] jelmer: the blender win??libs ones [11:58] maxb: ah [11:59] maxb: I think it would be ok to have those imports as long as the license meets Launchpad's requirements and as long as the disk space isn't an issue. [12:00] maxb: Assuming the branch was requested by somebody who needed to have it imported. [12:03] hello launchpadders [12:04] 'morning Jono [12:27] in interface definitions, some times methods return collections of Interface. that was patched later on in a separate file to refer to the derived Interface (IBug etc.). i forgot where the patching process took place. anyone recalls? [12:32] nvm, found it at lib/canonical/launchpad/interfaces/_schema_circular_imports.py === mrevell is now known as mrevell-lunch [13:34] jml, I think the topic is stale - thumper set it last Thursday === ChanServ changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.06 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes === mrevell-lunch is now known as mrevell === flacoste_afk is now known as flacoste === henninge_ is now known as henninge === Ursinha is now known as Ursinha-lunch [15:56] gary_poster: Hi! If you have a spare minute, could you please take a look at the following zope security issue that I'm seeing: http://pastebin.ubuntu.com/449690/ [15:56] looking noodles775 [15:57] Thanks gary_poster . I'm confused, as it seems to recognise the correct proxy, and have the correct permission, but cannot access package_build. [15:57] Ah... or does it have *two* security proxies... and it's using the first? [15:58] noodles775: I'm still trying to grok the pastebin yougave me, but a common cause for this sort of behavior is *another* security proxied object [15:58] yeah, I didn't understand that either [16:00] noodles775: to try your hypothesis, see if you can access something else mentioned by the second proxy and not by the first. Meanwhile, I'll go try to see what debug_proxy does [16:01] The first is actually a subset of the second... but I'll dig a bit too. [16:02] matsubara, ping [16:02] hi sinzui [16:03] matsubara, I do not see any staging oops reports for the last 14 days [16:04] matsubara, I want to see reports for today mostly, and may some from May 30-31 [16:04] sinzui, you can see today's here: https://devpad.canonical.com/~lpqateam/staging-oops.html [16:05] sinzui, I'll look into why the previous days were empty [16:05] thankjs [16:05] matsubara, it may relate to the db update [16:07] sinzui, https://devpad.canonical.com/~lpqateam/oops-summaries/staging-2010-05-30.html and https://devpad.canonical.com/~lpqateam/oops-summaries/staging-2010-05-31.html [16:07] for the 30th and 31st [16:07] I see them in the folder thanks [16:08] matsubara, This is all I need to see that our MailingListAPIView optimisation does not work [16:08] noodles775: I believe that the nested security proxies would explain this (and I checked the code reporting it, and it looked sane). I have not encountered security proxies around security proxies before, so I don't know why or when they would occur, but maybe it has happened in LP before. [16:09] gary_poster, noodles775, thumper encounter this last week [16:09] gary_poster: yep, I can see why it's happening now. I'm manually setting a ProxyFactory() for the result of my adapter, but then it seems that getAdapter() also wraps the result in a proxy for the specified interface (which is different). [16:09] sinzui: interesting. was there a resolution? I was about to ask you and Francis if you had encountered [16:10] noodles775: ah-ha. [16:10] noodles775: so the getAdapter proxy is the outer one? [16:10] I think he unwrapped it twice. but we was very dissatisfied and may have come up with a solution or at least an explanation [16:11] gary_poster: yes. I'd like getAdapter to not add its own :/ [16:11] gary_poster, thumper was trying to reduce the number of queries we call for every page [16:11] noodles775: when you register your adapter, is it registered as "trusted"? [16:11] If it is, then that might be a solution [16:11] say it is not trusted [16:12] and then rip off the proxies yourself on entrance to your adapter [16:12] and then I don't think you will have external code that will add a proxy on exit [16:13] If that's not the case, and not a solution, I'll look deeper, but that's my first guess [16:13] gary_poster: I tried with trusted="True", but it didn't seem to change (hrm, maybe it's "true"). [16:13] noodles775: you want False [16:13] * noodles775 tries [16:14] (don't remember fals vs. False) [16:14] How do I rip off the proxies? [16:14] removeSecurityProxy [16:15] Ah, I'd not used it just for one proxy before... great... [16:15] * noodles775 tries [16:17] If this is the problem/solution maybe we can convince upstream to make the "trusted" behavior say "if the output is already security proxied then *leave it alone*". (Right now it says, IIRC, proxy the output, period.) Or maybe there's some other upstream solution [16:18] (like, why is it making a proxy based on an interface, when we already have a registered proxy?) [16:19] matsubara, I just noticed that https://devpad.canonical.com/~lpqateam/staging-oops.html is from May 31. We do not have a report for what is happening today [16:19] sinzui, so it's very likely that oopses are not being synced from staging to devpad or there are no oopses on staging at all [16:20] sinzui, I'm pinging the losas to find out what's up with the oopses [16:20] thanks [16:23] gary_poster: Thanks! Confirming that removing the outer proxy ensures that the returned result is just proxied with my specified one. Thanks sinzui too for the hint. [16:24] noodles775: great, so that is also confirmation that the "trusted" thing was the source of the additional proxy? [16:25] gary_poster: erm, no... I'll re-check now, but when I tried both trusted with true and false, I was still getting the wrapped proxy. [16:25] * noodles775 checks again. [16:25] * gary_poster would like to know the source of the naughty proxy [16:30] gary_poster: confirming that either way (trusted true or false), the calle to getAdapter() is proxied with the passed IFace... and actually, the docs seem to agree with this? http://apidoc.zope.org/++apidoc++/Interface/zope.component.zcml.IAdapterDirective/index.html [16:30] That is, trused just gives the adapter itself unfettered access to the object, it doesn't seem to change whether the result is proxied? [16:36] noodles775: my understanding was that, for trusted adapters, the output was supposed to be proxied if the input was. Checking implementation [16:48] noodles775: my understanding is confirmed that a "trusted" adapter has custom code to handle reproxying the output if the input was proxied. However, my guess is that your adapter registration also specifies permissions on it? [16:49] noodles775: sorry for dwelling on this, but someone else encountered this, and it pretty clearly is something that is lame somewhere. We should understand the cause at least, and quite possibly address it. [16:53] sinzui, syncing was disabled. it's now re-enabled and staging-oops.html should be updated within the hour [16:54] thanks! === beuno is now known as beuno-lunch === Ursinha-lunch is now known as Ursinha === matsubara is now known as matsubara-lunch === beuno-lunch is now known as beuno === bac` is now known as bac [18:07] sinzui: could you explain a little bit what was done to fix bug 590840? [18:07] <_mup_> Bug #590840: timeout MailingListAPIView

[18:07] barry, EdwinGrubbs optimised the set sender and receiver address in the ML model [18:08] barry, last db update we had 248 timeouts on staging. We have about 9 this tine [18:08] barry, The loop you added worked and still works, but the queries work more often on the first try now [18:09] barry: the main improvement was retrieving only the three columns necessary from the db instead of all the columns from four tables. [18:09] sinzui: ah, so it's not trying to collate all the lists together, like the last (unsuccesful - i suck) attempt? [18:09] s/set sender and receiver/GET sender and receiver/ [18:10] barry, right [18:11] Lp in py2.6 ready. I do not know when lpnet will be Lucid, but we may be ready for MM3 soon [18:11] sinzui: excellent. [18:11] Lp /in/is/ [18:11] sinzui: very cool [18:11] sinzui: i'll have to allot some background time to that work now [18:11] * sinzui has got to stop typing with kittens next to me [18:12] me. ow! [18:12] I have a deaf kitten who likes to sleep on my keyboard. [18:12] I'm quite looking forward to the importds getting to be lucid, for Subversion 1.6 [18:12] She often sets the volume to 11 and scares the other cats away [18:13] Night all === matsubara-lunch is now known as matsubara [19:54] sinzui, I recreated staging oops summaries for the 7th to 13th. there are no oopses for 1st to 6th. You can see them at https://devpad.canonical.com/~lpqateam/oops-summaries/staging-YYYY-mm-dd.htmll [19:55] matsubara, thanks [19:55] I was able to verify that edwin's mailing list changes reduces timeouts by 95% [19:56] cool! [20:00] g'night all === ubuntujenkins is now known as revisionist === revisionist is now known as ubuntujenkins [20:35] gary_poster or leonardr, do you know if the lp-land command works for non-launchpad PQM projects as well? [20:36] I don't mars [20:36] nor do i. i always land manually [20:36] mars, it does not: [20:36] $ bzr lp-land --help [20:36] Purpose: Land the merge proposal for this branch via PQM. [20:37] ... [20:37] From: plugin "pqm" [20:37] yes, so it should work, since the information comes from the proposal [20:37] :-) [20:37] is package building service still available? [20:37] oh I misread your question [20:37] so, maybe so [20:38] zyga, you mean PPAs? If so, definitely [20:38] gary_poster, no, packages from bzr + recipe [20:38] 'fraid I don't know, sorry [20:39] https://wiki.ubuntu.com/DailyBuilds/GettingStarted [20:39] zyga, abentley or rockstar may know [20:39] jcastro, you mean with source package recipe builds? I'm running a stress-test right now. If that goes well, we could see it deployed on edge soon. [20:39] (from #launchpad, not long ago) [20:40] james_w, ^^ do you know something about this, you seem to (https://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds) maintain lots of them [20:40] abentley, rockstar: can I setup daily builds of my branch? [20:40] zyga, that service is not currently available. [20:40] ok, thanks [20:41] zyga, we had hoped to have it deployed by now, but some changes were made that caused it to wreak havoc on the buildfarm, so we had to disable it. [20:42] zyga, but we have fixes in place now, and we're in the middle of testing them. [20:42] * mars jots down another case for something like http://www.google.com/appsstatus#hl=en [20:43] abentley, thanks for the explanation === al-maisan is now known as almaisan-away [21:05] Can anyone confirm, launchpad-database-dependencies needs to stay on 8.3 until such time as production migrates to 8.4? Or not? [22:55] So...any good reason why the keyserver deleted all my keys when the computer was restarted? === Ursinha is now known as Ursinha-dinner === matsubara is now known as matsubara-afk [23:15] kb9vqf: The dev configuration keeps things in /var/tmp, and there's probably a Makefile target somewhere that purges /var/tmp/zeca, which contains the keys. [23:15] Ah, OK. Thanks! [23:15] Nothing else was affected, so the keyserver must be unique that way [23:18] make clean erases some stuff. [23:18] Like that. [23:19] Maybe it shouldn't. But then it probably also shouldn't erase PPAs. [23:19] And I stupidly ran it to get the AGPL source tarball [23:19] kb9vqf: can I ask what the purpose is of setting up your own Launchpad instance? [23:19] :-P [23:19] thumper: Debian packages [23:19] kb9vqf: what isn't the public Launchpad offering? [23:19] thumper: Debian support [23:20] And possibly other distros [23:20] how do you envision keeping things in sync? [23:20] Not sure yet [23:21] I might create a diff between my instance and the branch it originated from, and then keep applying that to the latest LP trunk [23:21] Don't know if that will work though [23:21] wgrant: Anything special about the ppa_key_guard celebrity? [23:22] e.g. how would I create it? [23:22] kb9vqf: It's where the PPA keys are attached. [23:22] It's just a normal unactivated user. [23:22] OK [23:22] Similar to the janitor. [23:26] kb9vqf: and so I'm clear, this is intended to be a public service? [23:26] thumper: I'm considering it [23:26] At the very least the built PPA packages will need to be publically accessable for Trinity [23:27] kb9vqf: what is Trinity? [23:27] http://trinity.pearsoncomputing.net [23:27] Continuation of KDE3 [23:27] Lots of packages, would be a nightmare without Launchpad [23:28] kb9vqf: and your reason for not using the public one is lack of debian build support? [23:28] thumper: Yes [23:28] ok [23:28] thumper: And I was also considering extending the build system to handle RedHat [23:29] Although that will be far in the future [23:29] Do you see any legal problems with what I'm trying to do now? [23:30] I'm not a lawyer [23:30] the code is AGPL [23:30] the code you run has to be publicly accessable [23:31] I know; just don't want to step on any toes [23:31] perhaps just social fragmentation [23:31] the intent of Launchpad is to be a central location and project registry [23:31] having multiple public launchpad instances dilutes this ideal [23:31] Ah... [23:31] My purpose isn't really to deal with Ubuntu stuff though [23:32] Not on this instance [23:32] This is more for Debian and other distros [23:32] I'm still using the public Launchpad for Ubuntu packages [23:33] * kb9vqf notes that the code is up as a tarball under the QuickBuild project at https://quickbuild.pearsoncomputing.net/quickbuild for AGPL compiance [23:34] wgrant: I tried to run this code: [23:34] ppa_key_guard = factory.makePerson( [23:34] name='ppa_key_guard', displayname='Launchpad PPA Key Guard', [23:34] email='ppa_key_guard@example.com') [23:34] And I got: lp.registry.interfaces.person.InvalidName: ppa_key_guard is not a valid name for a person. [23:34] Which doesn't make much sense [23:36] wgrant: Is it supposed to be ppa-key-guard? [23:38] I guess it was [23:40] kb9vqf: Right. underscores in the Python name, hyphens in the Launchpad name. [23:40] Underscores are ugly. [23:40] Makes sense. And it worked right up until when I ran out of disk space [23:40] :-P [23:40] Heh.