[12:14] hmmm [12:14] kiko: The traceback doesn't say, but I'm sure I can find where it leads to drq.addSource, if that's useful [12:14] 2029. [12:14] queue_root = self.distrorelease.createQueueEntry(self.policy.pocket, [12:14] self.changes_basename, self.changes["filecontents"] ) [12:14] # Next, if we're sourceful, add a source to the queue [12:14] if self.sourceful: [12:14] queue_root.addSource(self.policy.sourcepackagerelease) [12:14] kiko: Yes, that looks like the one [12:15] kiko: I'm sure nascentupload and the zcml are right, the question is, why is zopeless layer working to give me permissive security on my machine, but not on pqm? [12:15] malcc, what's the test? === lbm [n=lbm@82.192.173.92] has joined #launchpad [12:16] kiko: https://devpad.canonical.com/~andrew/paste/filei63hW3.html [12:17] but malcc... [12:18] do you know which test is failing? [12:18] kiko: Yes, testUploadToFrozenDistro [12:18] kiko: It's failing where it first compares the email results - the first upload is rejected, instead of going to NEW [12:18] kiko: Funny enough, the other test is passing. Hmm... [12:19] and it's run exactly before this one? [12:19] kiko: Hmm, no it isn't, it isn't running the other one [12:20] at all? [12:20] kiko: Sorry cancel that, getting tired [12:20] kiko: It runs the other one just before this one and it works fine [12:20] kiko: Runs them in the same order locally [12:22] malcc: I can help you tomorrow morning, will wake up 9 UTC [12:23] weird weird weird. === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [12:27] Hmm. Good job we had this think about it, I've just realised my fix is wrong anyway [12:29] Ah, no it isn't. I persuaded myself it would stop publishing frozen distros, but actually the code right now would refuse to publish release on a frozen distro, and that's wrong too [12:29] My change would start publishing them. But I'm not going to force it through until I've had another think in the morning [12:29] Ok, night all === Burgwork [n=corey@ubuntu/member/burgundavia] has joined #launchpad === niemeyer [n=niemeyer@201.23.168.11] has joined #launchpad [12:33] cprov-afk, ping [12:33] darn, ten minutes too late [12:42] mpt: not really ;),pong [12:42] cprov-afk, I was wondering yesterday if any of the Soyuz pages on the Canonical wiki are useful any more [12:43] mpt: they are not, maybe only SoyuzCatchUp === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad [12:43] Ok, actually, I was talking nonsense, it all came clear, the fix is exactly right [12:44] malcc, what the hell [12:44] malcc: go to sleep then? :-) [12:45] cprov-afk, ok, I'll move that one and delete the rest [12:45] kiko: I mean, you see those last few lines before I logged out, where I'd convinced myself maybe my status fix wasn't right? Well I was talking nonsense, the status fix is exactly right [12:45] kiko: I still don't have a clue about the pqm issue though [12:45] heh [12:45] sleep over it [12:46] Yeah [12:46] tomorrow morning there are wizards available to help [12:46] anyway, zzzing here as well [12:47] Nafallo: Yes, good idea :) [12:47] Night again all [12:47] malcc: night :-) === Nafallo starts the timer :-P === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] === danilo_ [n=danilo@cable-89-216-150-8.dynamic.sbb.co.yu] has joined #launchpad [02:31] Gooooooooooooooooooooood afternoon Launchpadders! === AlinuxOS [n=alinux@d83-176-121-107.cust.tele2.it] has joined #launchpad === lamont [i=lamont@nat/hp/x-e347698875221e4a] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad [04:10] New bug: #60169 in launchpad-bazaar "Product's +branches page contains misleading link to www.bazaar-vcs.org" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60169 === stub [n=stub@ppp-58.8.6.29.revip2.asianet.co.th] has joined #launchpad [04:29] I wonder if it would be a good idea to randomly perturb the db sequences after building the database for the tests [04:30] to remove the possibility of relying on the exact value of new sequence numbers === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad [04:39] random Q ... it's not possible for a spec to exist for multiple products? [04:39] or should I say pillars? [04:39] Keybuk: no. [05:40] New bug: #60172 in launchpad "Launchpad shouldn't auto-link "sftp://" by itself" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60172 [05:45] New bug: #60173 in blueprint "Attendance list of a sprint should be private, or attendance should be markable as private" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60173 [06:54] jamesh: We already use a script to reset all the sequences to the correct values, it would be trivial to add a random number to them. [06:54] Has this been a problem? [06:56] stub: I ran into a few extra test failures when landing a branch that added to the sample data -- if the sequences didn't have a fixed starting value this would have been less of a problem [06:57] might not be worth the hassle though [06:58] It involves adding a --random argument to database/schema/reset_sequences.py and a random parameter to canonical.database.postgresql.resetSequences - pretty trivial. === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === frodon_ido [n=patrick@ip-213-49-147-165.dsl.scarlet.be] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === lfittl [n=lfittl@193.170.41.114] has joined #launchpad === mpt [n=mpt@203-167-187-118.dsl.clear.net.nz] has joined #launchpad [08:25] jamesh, is there any way of exporting your calendar as an .ics or anything like that? [08:27] mpt: yeah. add "/+icalendar" to the end [08:27] e.g. https://launchpad.net/people/mpt/+calendar/+icalendar [08:27] jamesh, awesome, thanks === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === carlos [n=carlos@138.Red-81-39-35.dynamicIP.rima-tde.net] has joined #launchpad [08:34] morning [09:01] morning === Burgundavia_ [n=corey@ubuntu/member/burgundavia] has joined #launchpad === glatzor [n=sebi@ppp-82-135-82-91.dynamic.mnet-online.de] has joined #launchpad [09:15] mpt: hi [09:17] hi SteveA, cooking dinner right now, back in an hour or so [09:20] mpt: ok === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:37] morning guys === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad [10:16] Any testing gurus in the house? === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [10:16] I have a test (https://devpad.canonical.com/~andrew/paste/filei63hW3.html) which passes fine on my machine, but when run on PQM fails with a permissions error [10:16] Which is a surprise, as the zopeless layer ought to let me do whatever I like, and indeed this seems to work on my local machine just fine === Spads_ [n=spacehob@host-87-74-83-75.bulldogdsl.com] has joined #launchpad [10:23] malcc: could you put up the full error log (i.e. pqm's failure message) somewhere? [10:31] malcc: also, it'd be worth doing exactly what pqm does. take a fresh RF branch, merge in your branch and run the tests. just to rule out any strange merge behaviour. [10:32] BjornT: Thanks, I'll try that. pqm log extract here: https://devpad.canonical.com/~andrew/paste/fileyhMbAZ.html. Let me know if you really did mean the whole thing [10:44] jamesh: hi [10:45] SteveA: hi [10:45] stub, jamesh: I'd like to do a quick infrastructure irc meeting [10:45] when's a good time? [10:48] I'd prefer a time before 8pm (midday UTC) [10:48] earlier if it is on a Friday [10:48] oh, I meant today [10:48] just a quick informal catchup [10:48] okay. Any time then :) [10:49] ok, let's see what stub says [10:51] malcc: i think i do need the whole pqm log. [10:53] BjornT: https://devpad.canonical.com/~andrew/paste/files7NCdF.html [10:53] jamesh: meanwhile, do you have time for a pre-implementation review call? [10:54] SteveA: okay [10:54] try sip? [10:54] sure === jamesh fires up ekiga [10:55] i'll call you === civija [i=msabljic@193.198.206.5] has joined #launchpad === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad [10:57] hy guys! [10:58] can you tell how to change my prefered e-mail address in launchpad? [10:59] civija: hi [10:59] hi carlos [10:59] civija: Go to: https://launchpad.net/people/carlos/+editemails (change carlos with your launchpad name) [10:59] and select the one you want as the Contact Address [11:01] SteveA, back [11:02] carlos: tnx! i've changed it [11:02] civija: you are welcome === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:04] BjornT: Merging changes into a fresh branch from rocketfuel, the test still passes locally [11:05] malcc: did you run just a subset of the tests, or 'make check_merge'? [11:05] BjornT: Just a subset. make check_merge tends to be non-terminating on my hardware [11:06] BjornT: I'll give it a go though [11:11] New bug: #60190 in soyuz "Misleading email when uploads are UNAPPROVED" [Medium,Confirmed] http://launchpad.net/bugs/60190 === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [11:16] is it possible to edit a comment on launchpad? [11:16] seb128, no [11:16] ok === Spads [n=spacehob@217.205.109.249] has joined #launchpad [11:17] I got a mail from an user saying he's getting spam since his email is listed by one comment on launchpad [11:17] I was wondering if there was a way to drop it [11:20] malcc: it's hard to say exactly what's wrong. what you could do is to insert a self.assertEquals(getSecurityPolicy(), PermissiveSecurityPolicy) in the failing test and send it off to pqm again. [11:20] BjornT: Thanks, I'll give that a try [11:24] at least that will tell you whether something's wrong with the test setup [11:27] mpt: hi === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [11:35] How do I return a custom HTTP code (e.g. 404) for a particular Launchpad page? [11:35] New bug: #60195 in malone "May need to obfuscate email addresses in bug comments" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60195 [11:38] mpt: in the view class: self.request.response.setStatus(404) [11:38] thanks BjornT === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad [12:15] mpt: why do you want to return a 404? [12:15] SteveA, 410 Gone for the calendar, so we don't get bazillions of "Sorry" pages showing up in Google [12:15] or "402 Payment Required" [12:15] Launchpad 3.0, jamesh, Launchpad 3.0 [12:16] it'd make a good april fools day joke for shipit ... === mpt looks for other uses of self.request.response so that he won't have to ask another annoying question [12:20] mpt: is it that you want to do a special 404 page? [12:20] we have a particular way of doing that [12:20] oh, I can do it just in __init__ [12:20] mpt: please have a call with jamesh about how to do this efficiently [12:20] don't do anything in __init__ [12:21] that's what error.py does [12:21] mpt: is the plan to make the calendar pages inaccessible or just not linked to? [12:21] then it is wron [12:21] g [12:21] Should I report a bug, or is that a one-line fix? :-) [12:21] mpt: that depends. [12:21] jamesh, the latter. I have changed the template to include an explanation plus a download link. [12:21] but please talk through what you want to do with james [12:22] maybe by voice [12:22] otherwise, you may take an inappropriate approach, and so it will have to be re-done after a code review [12:22] mpt: so what page would the "Gone" response be for? [12:23] jamesh, any calendar page [12:23] calendar-view-*.pt, calendar-subscribe.pt, calendar-event-*.pt [12:24] mpt: okay. I don't think Mark bothered with that for the bounty tracker pages. [12:25] jamesh, he did that several weeks ago, and Launchpad's bountry tracker currently features two bounties registered four days ago, so I don't think that's a particularly good example. [12:25] mpt: I think this can be done in two stages [12:25] 1. remove links to calendar [12:25] (Maybe I should hide the bounty tracker more thoroughly in this branch too?) [12:25] 2. remove pages [12:25] it's important to land 1 [12:26] 2. is less important [12:26] I don't really care if two or three users are a little confused [12:26] I do care if 20 or 60 users are [12:26] I'd like to see removing the calendaring have a simple low risk landing first [12:27] that can get into the next rollout [12:27] I get the impression that many more people use the calendar than used the bounty tracker [12:27] no statistics to back that up, though [12:27] so, they can still use it if they know the URL [12:27] that's not a big deal [12:27] it's okay for it to stay there, hidden, and we're not supporting it [12:27] i'd rather your time was spent improving areas of launchpad we care about [12:28] not areas of launchpad we currently don't care about [12:28] in other words [12:28] Don't polish the lack of a calendar! [12:28] we can apply polish after all the 1.0 UI stuff is done [12:29] If we don't want Google indexing certain parts of the site, a robots.txt file might be more appropriate [12:31] ok [12:33] mpt: also, please do use the facility of pre-implementation calls to discuss implementation plans with a reviewer [12:33] I like that you work on the python code in launchpad [12:33] certain areas of the code are tricky in terms of infrastructure [12:33] so I want you to seek guidance when you work in those areas === xenru [n=Miranda@85.192.12.67] has joined #launchpad [12:40] New bug: #60211 in launchpad "webapp/error.py uses self.request.response.setStatus() in __init__ and that's bad" [Untriaged,Unconfirmed] http://launchpad.net/bugs/60211 [12:43] thanks mpt. I commented on the bug. [12:44] stub: hi, around? [12:45] carlos: yes === SteveA --> lunch [12:45] stub: is there any way to know more or less at what time the language pack DB mirror is ready to use? [12:45] I would like to adjust the timing with the export scripts [12:46] jamesh, meanwhile, would you have time to review some pagetest changes? [12:46] mpt: sure. [12:46] It seems to be consistently finishing rebuilding at 4:15, so 4:45 or later is a safe bet. [12:46] jamesh, https://devpad.canonical.com/~jamesh/pending-reviews/mpt/launchpad/2006-09-compatibility/full-diff [12:46] stub: London time? [12:46] carlos: I can create a file after the rebuild if you want stating that the rebuild is complete [12:46] mpt: you have a conflict [12:46] carlos: yes - london time [12:47] jamesh, I was just going to say, it contains one six-line conflict, for which I'll be using the MERGE-SOURCE [12:47] stub: as you wish, but I will not use it yet (I don't have too much time to expend on this) I have the logs anyway to detect any problem there... [12:47] stub: I will start at 5:00 [12:47] stub: thanks [12:47] mpt: well, you should integrate the change from TREE (products/firefox/milestones => products/firefox/trunk) [12:48] oh. of course. [12:48] carlos: it can be rebuilt earlier if you need, but then it will be using the previous days backup. [12:49] mpt: as a general comment, your page test modifications make things harder to debug in the failure case [12:49] stub: no, that's good enough, thanks [12:50] mpt: before, we'd get a diff of the contents vs. what was expected. After the change it'll be a simple True vs. False [12:51] jamesh, the problem is that the expected items are present in a particular order on mainline, and in a different order on 1.0 [12:52] I suppose the other option is to print browser.contents twice, and pick out one thing each time [12:52] (or three times, or however many) [12:53] mpt: the alternative is to use BeautifulSoup to extract a portion of the page and check that -- we really need a helper for some common cases here ... [12:53] jamesh, that wouldn't really help in this case, because the markup is very different too [12:53] no common element IDs or classes? [12:53] no [12:54] we'd still be eliding content [12:54] We have very few IDs, and the classes are all different [12:54] I suppose I could add IDs, but putting IDs in a page just for test purposes seems odd [12:55] probably not for a simple change like this. [12:56] not odd, or not appropriate? :-) [12:57] well [12:57] adding ids for testing is often appropriate [12:58] I think jameshs point was about the size of the effort/reward ratio here [12:58] what I mean is that (1) it would be good to have some helpers available for things like this, (2) I am not expecting you to write those helpers for this change and (3) it isn't worth holding up your merge til those helpers are available [01:02] mpt: your branch looks okay to merge r=jamesh. The tests you've converted were not the most informative to start with, so it probably doesn't affect debugability much [01:02] thanks jamesh [01:02] BjornT: I added your suggested assert to both tests in that class. Both passed locally, both failed on PQM with AssertionError: != [01:03] BjornT: I'm still not able to run make check_merge locally, so this may be a one test vs. entire suite problem, rather than different machines, arches or whatever [01:05] malcc: why cant you run check_merge locally ? [01:05] lifeless: Swap death. I think I need to order some more RAM [01:06] At least it looks like swap death, things stop, much processor time is in wait state [01:06] vmstat will tell you [01:08] malcc: ok. i suggest sending an email about this to the list, CC stub. my guess is that the layers are setUp:ed and tearDown:ed incorrectly, but i'm not sure. could be something else as well. the pqm log didn't give me any clue. === mpt cries as his girlfriend utterly fails to figure out how to confirm a bug in Launchpad [01:12] 'your girlfriend sucks dude' [01:13] Enough with the double entendres [01:14] Does *anybody* find the magic controls hidden behind what looks like a link to the product, without being told? [01:14] malcc, probably 2 or 3 percent do [01:14] (wild-ass guess) [01:17] more people guessed when we had the expander arrow [01:19] lifeless: I think I've got the dl.openafs.org product-release-finder bug fixed, btw [01:19] jamesh: fantastic [01:19] this time it'll work for sure. [01:20] hhahaha [01:20] but I hope you are right [01:20] the change should also greatly reduce how much of a site it walks looking for releases === civija [i=msabljic@193.198.206.5] has left #launchpad [] [01:30] canonical.testing.layers.LayerInvariantError: Component architecture should not be available === malcc -> Lunch === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:33] mpt: probably bug 55041 [01:35] BjornT, so it is [01:37] so I'll run all tests overnight instead [01:42] mpt: another solution is to try to be a bit more specific which tests you want to run [01:43] for example, instead of running: python test.py -f --test=shipit [01:43] you could divide it into to test runs: python test.py -f --test='pagetests.*shipit.*' [01:44] and: python test.py -f --test='doc/.*shipit.*' [01:44] and possible a few more like that if there are tests in other places you want to run. === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === aa_ [n=ali@pida/aa] has joined #launchpad [01:54] hi, are we allowed to delete stuff like branches? [01:54] (oops we are not in a meeting are we?) [01:57] aa_, that isn't implemented yet, sorry [01:57] mpt: fair enough [01:58] bzr is crushing my testicles :) [01:58] aa_, subscribe to bug 34540 if you want to be notified of any progress [01:58] Malone bug 34540 in launchpad-bazaar "cannot delete a branch" [High,Confirmed] http://launchpad.net/bugs/34540 [01:59] mpt: ok, thanks [01:59] aa_: however you can rename branches, so you can reuse the object for something else instead of registering new branches. [01:59] that's a workaround, but it's better that it used to be [02:00] aa_: also, I'd be interested in why you want to delete a branch. There are some other bugfixes in the plans that might fix the root cause of your problem. [02:01] ddaa: I want to move back to svn [02:01] a sorry state I know [02:01] sounds a weird thing to want to do, but you must have compelling reasons [02:01] well, no one ever seems to be able to get my source code [02:02] aa_: I think the best match for what you want to do is to set the branch status to "ABANDONED" and explains where the code is now hosted in the whiteboard of the branch. [02:03] sounds good [02:03] well, I used to host an http mirror of the branch myself, before the branch backup thing was working [02:03] but I think launchpad does that now [02:04] yeah, mirroring of external branches was one of the initial features of the bzr support in launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:27] salgado: ping [02:27] cprov, pong [02:28] well, thanks for the advice everyone, launchpad looks better every day, keep it up :) [02:28] salgado: did you check the last diff of my small-fixes (-backports fix) ? === aa_ [n=ali@pida/aa] has left #launchpad [] === carlos -> lunch [02:30] cprov, not yet [02:30] I'll check today [02:31] salgado: fair enough, it's blocking some guys to fix stuff in dapper, thank you [02:34] SteveA: I was going to drop by for the meeting, but I've been up for 15 hours, body is telling me it needs sleep now [02:34] SteveA: sorry === jelmer [n=jelmer@a62-251-123-16.adsl.xs4all.nl] has joined #launchpad [02:40] New bug: #59573 in ubiquity "The installer crashed" [Untriaged,Needs info] http://launchpad.net/bugs/59573 [02:43] jamesh, around? === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === niemeyer [n=niemeyer@201.23.160.13] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:12] stub, around? [03:12] salgado: Can I get a 2 minute review of https://devpad.canonical.com/~andrew/paste/fileOV33Nk.html ? [03:12] :-) [03:12] heh [03:13] hmmm. firefox is failing to load that [03:14] works for me... [03:14] I restarted and now it works [03:15] stub, do you know if that keyring trust analyzer was ever run in production? === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [03:17] salgado: No, it never was. It got blocked on creating the initial trusted set of keyrings IIRC. [03:23] stub, have you tried writing an old-style pagetest with no Referer line, to see if we get the referer set to None in the session? === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad [03:26] No, but I think the current tests are good enough. They will still detect breakage, and the comment explains why the test is slightly screwed. [03:31] stub, I guess it's not possible to have a non-ASCII referrer, right? [03:31] I stuck 'replace' in there just incase [03:31] I'm concerned that any unexpected problems on this code will prevent new users from using launchpad completely === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad [03:32] That should stop the decode call ever raising an exception (?) [03:33] should it? can you add with a test with a non-ASCII referrer just to make sure? [03:33] s/with// [03:37] salgado: yes, it should; that's what that docs for {str,unicode}.{encode,decode} say (see sections 2.3.6.1 and 4.9.1 of the python library reference). [03:39] I'll add a test demonstrating crazy encoded referrer headers anyway. [03:39] lifeless: meeting? [03:40] lifeless: maybe you were confused about the day of the week? [03:40] SteveA: see comment from him on this channel a little over an hour ago === bradb_ [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad [03:40] He's gone to sleep [03:40] spiv: I read the comment addressed to me [03:40] Oh, right. [03:40] I wasn't expecting a meeting today anyway [03:40] I misunderstood what you meant by "meeting?" [03:41] ah, right [03:41] as in "what meeting?" [03:41] That's clear now :) === bradb_ [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad [04:14] spiv: hi [04:14] spiv: still around? [04:15] SteveA: yeah, but not for much longer... [04:15] New bug: #60235 in launchpad "Disabling mirrors when they fail a single probe is not fair" [High,Confirmed] http://launchpad.net/bugs/60235 === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [04:15] spiv: you'll be working with lifeless tomorrow? [04:15] Yep [04:16] After I get the stitches removed from the back of my head... [04:16] spiv: would you ask him to give an estimate of when he'll be able to do the bzr code update in RF that ddaa asked for? [04:16] Ok. [04:16] thanks [04:16] SteveA: thanks === spiv puts a big tomboy note in the middle of the relevant workspace to make sure I don't forget [04:18] thanks! === Spads [n=spacehob@host-87-74-19-213.bulldogdsl.com] has joined #launchpad === lfittl [n=lfittl@193.170.41.114] has joined #launchpad === lbm [n=lbm@82.192.173.92] has joined #launchpad [04:33] morning [04:33] hello hello [04:34] hello america [04:34] hello south america [04:35] how's it going? [04:36] yeah, top === xenru|clone [n=Miranda@85.192.13.219] has joined #launchpad === bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [04:48] https://launchpad.net/products/launchpad/+bug/60211 is forbidden for me but it was initally reported as a public bug. [04:49] did mpt remove everyone from the subscribers list? [04:51] matsubara, let me check === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [04:55] hey malcc, cprov-afk [04:55] Hey kiko [04:55] how's the surf? === mvo [n=egon@p54A6572B.dip.t-dialin.net] has joined #launchpad [04:56] Not sure, I'm a long way from any useful surfing locations here [04:57] On a separate note, soyuz development is going quite well :) [04:57] as usual! [04:57] My branch still isn't merged though... [04:57] did you find out what was up yesterday? [04:57] Bjorn made a suggestion, which showed beyond doubt that I'm not getting the same security manager when running all tests on PQM [04:58] SteveA, can you help malcc? this is really blocking us [04:58] And I've sent an email out to the launchpad list with my failure [04:58] you are a * [04:58] An asterisk? :) [04:59] that too [05:00] Or did you mean a ? [05:00] I am against unicode [05:01] matsubara, did you see this SMTPRecipientsRefused oops today? really neat [05:01] kiko: glanced over [05:01] matsubara, validation error? [05:02] that imported branch looks strange: https://launchpad.net/people/vcs-imports/+branch/xine-lib/head - the latest 16 revisions date from 2001, but then there come commits from yesterday [05:02] how comes? [05:03] kiko, malcc: what's up? the test failure you posted to the list? [05:03] kiko: looks like [05:03] SteveA, yeah. pretty serious for us [05:04] I don't know what the answer could be. It's really a stub issue. === kiko cries [05:05] malcc: have you merged from RF recently? [05:05] and also check you've updated all your subtrees [05:05] like zope, in particular [05:05] SteveA: Yup, and Bjorn also suggested taking a fresh rf and merging from my branch. And yes, I've got the latest other bits :) === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has joined #launchpad [05:06] siretart: looks like a ddaa question ;-) [05:06] I suspect I'd be able to reproduce the issue locally if I had enough RAM to run all the tests === ddaa looks [05:08] siretart: yes it does look weird, yes it's expected behaviour, yes it's because CVS sucks [05:08] malcc: you shouldn't need to run all the tests [05:08] malcc: because they run in a separate process [05:08] malcc: running all the launchpad tests should be enough. try python test.py canonical [05:09] SteveA: Willdo [05:09] siretart: those "Filler changeset" commits are here to emulate the CVS notion of "default branch" which affects the result of checking out HEAD but is orthogonal to normal history. [05:10] ddaa: will those 'filler changesets' always be the latest revisions? [05:10] siretart: no, when further commits are made to other files, the filler changesets will stay where they are in history [05:10] ah, so the import just finished today? [05:11] matsubara, yeah, a validation issue. interesting one. it will require some manual intervention once fixed.. do you think that's really a valid email address? [05:11] siretart: yes, it completed very recently after a fixed on one-letter bug. [05:11] lucky :) [05:11] thanks for all ddaa! :) [05:12] kiko, why manual intervention? that email is not registered in launchpad [05:12] It is my duty to please my users ;) [05:12] salgado, yeah, I now understand the traceback. just a token. [05:13] kiko: This domain cannot be registered because it contravenes the Nominet UK [05:13] naming rules. The reason is: [05:13] third-level domains may neither start nor end with a hyphen. [05:13] matsubara, :) [05:13] it was a typo btw. [05:14] malcc, do other ftests depend on the PermissiveSecurityPolicy, I wonder? [05:17] kiko: When Jamesh suggested I use the LaunchpadZopelessLayer to avoid the need for login etc., he didn't sound like he was describing anything experimental [05:17] kiko: A few other tests use that layer, but it's hard to say immediately whether they rely on the security aspects of it [05:18] kiko: all tests in the ZoplessLayer should use PermissiveSecurityPolicy since that's what scripts use. === matthewrevell [i=synchron@outbound.silenceisdefeat.org] has left #launchpad [] [05:54] SteveA: kiko: any of you want to rs=him the removal of utilities/{library-cut-tails.py,library-relink.py,arch} from launchpad? [05:54] does nobody use them? [05:54] kiko: dude... they are user helpers for arch/baz [05:55] if somebody on the team still use them, he has way bigger problems! [05:55] I have no idea what they are for [05:55] go ahead and nuke them then [05:55] kiko: okay, rs=kiko then [05:56] same applies to utilities/rocketsync [05:57] utilities/rocketmeld [05:57] utilities/refuel [05:57] utilities/launch [05:58] crazy that stuff that depends on the launchpad code being hosted on baz has stayed around that long === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [06:01] well, it's just the matter that few people use bzr rm [06:03] I'm way happy to do it. It's just going to large a diff to be [trivial] [06:04] kiko: what about bug 60211? Could you subscribe LP-devel to it? [06:05] done. [06:05] kiko: thanks [06:40]