=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has left #launchpad ["Ex-Chat"] === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] === abhay_ [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad [02:04] cprov-afk, sou uma mmia. see email. [02:05] kiko-afk: I've seen, running new code [02:05] cprov-afk, ah, do you have the output already? [02:05] kiko-afk: in a bit [02:08] kiko-afk: https://sodium.ubuntu.com/~andrew/paste/fileZMTnvB.html [02:09] what do you think? [02:09] kiko-afk: the arch-all ones are those we did shit ... [02:09] kiko-afk: I'm mean we didn't build the arch-indep binary [02:09] kiko-afk: is that right ? [02:10] cprov-afk, well, not exactly. we try and build /too much/ today [02:10] cprov-afk, I'm trying to find out if we can live without binary PAS support. [02:10] I'll reply to myself. [02:10] kiko-afk: how do you mean ? /too much/ [02:11] well, these are binary PAS candidates [02:11] but we ignore binary PAS [02:11] so we try to build them everywhere regardless [02:12] kiko-afk: they will got rejected, same name & version [02:12] they won't build [02:12] it's not a problem (I think) [02:12] it's just that we spam the buildds [02:12] I'll call you in a bit [02:12] kiko-afk: right === doko [n=doko@dslb-088-073-066-130.pools.arcor-ip.net] has joined #launchpad === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === jml [n=nnnnnjml@203-217-8-89.perm.iinet.net.au] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === somerville32 [n=somervil@fctnnbsc15w-156034073036.nb.aliant.net] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === spiv [n=andrew@ppp245-86.static.internode.on.net] has joined #launchpad [04:22] I wonder if Python 2.5 will make it into edgy [05:06] mpt: ping? [05:17] jamesh, pong [05:17] lifeless, ping [05:18] mpt: what do you think about the wording changes in this patch? https://sodium.ubuntu.com/~andrew/paste/file8p1Pvs.html [05:19] this affects the details portlet for people who aren't Launchpad users [05:20] jamesh, that looks like an improvement [05:20] jamesh: "I am this person" is a declaration, rather than the name of an action like "Claim this person", so it doesn't "look" so much like an action, if you know what I mean. [05:20] mpt: ? [05:20] jamesh: maybe this isn't a problem. I'm happy to trust mpt's judgement anyway. [05:21] lifeless, can you confirm whether PQM received a couple of merge requests from me in the past 20 minutes? [05:21] spiv: "Claim this person" also sounds weird though ... [05:22] mpt: uhh, pqm.launchpad.net ;) [05:22] lifeless, it hasn't sent me mail, and nor has it included the branch in the queue [05:22] mpt: it looks idle [05:22] jamesh: "claim" isn't an ideal verb, no [05:22] mpt: then its probably not recieved it [05:22] as in, almost certainly. [05:22] jamesh: "Claim this account" seems less weird, except there's no account yet [05:22] -or- you've changed your config so its not sending the error to the right place [05:22] 'I am this person' [05:23] mpt: any thoughts on alternative wording for "I am this person" or "Claim this person"? [05:23] lifeless, right, I was trying to narrow it down to between (a) it never received my request and (b) it received my request and I never received its reply [05:23] lifeless: that's the wording I've got at the moment [05:23] I like 'I am this person' ;) [05:23] jamesh: "Hey, that's me!" [05:23] :-) [05:24] good - 'this is me' [05:24] jamesh: I'm not making a strong objection or anything, just a passing observation. I'm more than happy to trust mpt's judgement on this sort of thing. [05:24] spiv: sure. [05:24] this also makes the person merge form more visible too [05:25] Making the person merge form more visible would be great. [05:25] My judgement is currently impaired by lack of sleep [05:25] since there is a link to it on each non-active person page if you're logged in [05:25] mpt: So you probably only have about 3x as much UI sense as me, rather than your usual 10x ;) [05:26] --dry-run looks all correct... [05:27] mpt: does "mailq" show any queued messages? [05:28] eh. [05:29] there they are. [05:29] (Host or domain name not found. Name service error for name=pqm.ubuntu.com type=MX: Host not found, try again) [05:30] try running "sudo sendmail -q" [05:30] That retries everything? [05:30] yeah [05:30] It seems to have removed the error message, anyway [05:31] ... and now it's back [05:31] this time for both attempts [05:31] which is silly, because http://pqm.ubuntu.com/ loads just fine in a browser [05:31] different DNS records [05:32] host -t mx pqm.ubuntu.com (IIR the syntax C) [05:32] ;; connection timed out [05:32] I HATE COMPUTERS [05:32] ahem === lifeless pats mpts shoulder sadly [05:35] maybe DNS takes a bit longer to get to New Zealand, so times out [05:35] probably because of the time zone differences [05:36] And the sunspots! [05:36] Nah, this is probably leftover from the horrible DNS problems I had Monday and yesterday, fixed by upgrading the router firmware [05:37] bbiab === mpt_ [n=mpt@203-167-187-19.dsl.clear.net.nz] has joined #launchpad [05:55] so, that sucks [05:55] Sorry for bothering you lifeless, I didn't know about mailq [06:06] lifeless: assuming the next lot of product-release-finder tests are successful, we should be able to remove the "Cache" class and associated code [06:07] it has a really evil __contains__() implementation that mutates the object. [06:08] so that "not_in_cache in cache" will return False the first time and True subsequent times [06:08] jamesh: ew [06:09] that is, __contains__() adds items to the cache [06:09] freakydeaky === jml [n=jml@203-217-8-89.perm.iinet.net.au] has joined #launchpad [06:10] or should I say, freakerydeakerydoo [06:10] the code I've added to cope with existing product releases should also make the cache code unnecessary [06:12] excellent [06:12] I was wondering if we could without it [06:15] lifeless: btw, does bzr do anything special to avoid umask issues like Subversion does? [06:15] somewhat yes [06:15] we chmod files if an option has been set [06:16] for reference, Subversion's fsfs backend copies the file permissions from the previous rev when creating a new one [06:16] but we cant preserve sticky bit over sftp [06:16] because openssh' sftp-server masks the sgid bit [06:17] that's not as big a deal for updating existing branches (which is where the problem usually bites) [06:18] actually, I suppose bzr would be creating dirs with the hashed subdirs [06:18] yes [06:20] well, I suppose an admin could create all 256 weaves/NN subdirs and then chgrp/chmod things appropriately [06:22] yup [06:52] I wonder how I got an Unauthorized test failure in a LaunchpadZopelessLayer test [06:52] they're meant to be running with permissive security policy === mpt_ [n=mpt@203-167-187-19.dsl.clear.net.nz] has joined #launchpad === abhay [n=abhay@pdpc/supporter/student/Aranis] has joined #launchpad === abhay [n=abhay@pdpc/supporter/student/Aranis] has left #launchpad [] === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === xenru [n=Miranda@85.192.12.172] has joined #launchpad === Spads [n=crack@host-84-9-51-91.bulldogdsl.com] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad [08:37] jamesh: if you get an Unauthorized failure in Zopeless, it means that there are no security declarations for the attribute you're trying to get/set === carlos_ [n=carlos@214.Red-88-0-159.dynamicIP.rima-tde.net] has joined #launchpad [08:42] morning [08:58] BjornT: wouldn't that be a forbidden error? [08:59] BjornT: this was saying I didn't have launchpad.Edit on the object. [08:59] (I'd updated the security declaration) [09:01] Is launchpad down? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:02] looks like that... [09:02] Gah - I was in the middle of reporting a security bug :[ [09:04] hmm, it's not down for me, but it is very slow. [09:04] I seem to recall the same thing happened around this time yesterday. [09:04] this happened a few days ago too [09:04] a cron script hammering one of the app servers [09:04] Right. [09:05] When will the carnage be over? [09:06] jamesh: right. yeah, you probably should have gotten a forbidden error. [09:07] BjornT: the security declaration must have worked, since it said I needed launchpad.Edit to write to that attribute. That's why I found it weird [09:07] hiya [09:10] looks like update-cve is using a TONNE of memory [09:10] let me unSTOP it [09:10] see if this makes it suck again [09:11] I wonder if is doing something stupid [09:11] and look how slow it just got again [09:11] (other than using xml.dom.minidom) [09:11] by tonne, I mean gb's [09:11] how big is the CVE database? [09:11] jamesh: does it work if you do setSecurityPolicy(PermissiveSecurityPolicy) first? [09:13] hmm, [09:13] its the whole nightly scripts doing it I think === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad [09:14] them and an archvysn rsync job [09:14] will ask admins later [09:14] BjornT: the tests rely on LaunchpadZopelessLayer, which does execute_zcml_for_scripts(), which installs the PermissiveSecurityPolicy [09:17] jamesh: i know. i just thought it'd be good to know if something else changed the security policy, or if it's the permissive policy that is to blame. [09:18] mpt_: the fancy menu at the top of the lp pages does not honour ctrl-click :) [09:18] is this by design ?? === spiv [n=andrew@ppp245-86.static.internode.on.net] has joined #launchpad [09:19] lifeless: the dynarch menus stuff is designed to act as much like real menus as possible, rather than as a webpage [09:20] thats fine by me, as long as I have all the links for navigation that it replaces, somewhere I can ctrl-click to get a new tab from [09:20] from what I can tell, that includes making them non-keyboard accessible ... [09:20] ctrl-click has nothing to do with keyboard [09:20] it has to do with them being considered links that the browser understands [09:21] ctrl-click has to do with clicking hyperlinks [09:21] I don't think they are hyperlinks [09:21] (in point of fact, real menus *are* keyboard accessible) [09:21] so, replace ctrl-click with 'middle mouse' then ;) [09:21] it is code that'd be worth replacing at some point [09:28] good morning [09:29] lifeless: the dynarch menus are going away very soon [09:29] lifeless: so, expend no effort around them now [09:30] jamesh: the replacement code already exists. i just need to find time to do the replacement. [09:33] SteveA: ok [09:34] SteveA: the slowdown yesterday in lp happened again today, and coincides with the lp nightly.sh, and an rsync by user archvsyn [09:39] lifeless: that's interesting. can you say what UTC time the slowness was happening? maybe matsubara will be able to find something in the list of soft timeouts. === xenru [n=Miranda@85.192.12.172] has joined #launchpad [09:41] If there is a bug that applies to multiple packages, should I create a bug for each one or is there a way to connect them? [09:41] lifeless: the CVE database is XML, and 3 megs when gzip compressed [09:41] lifeless: so it isn't too surprising to see it using shitloads of memory when loaded with xml.dom.minidom [09:43] moving it to cElementTree would be an improvement. Moving to an incremental parser would be even better === Fujitsu [n=Fujitsu@c58-107-56-223.eburwd7.vic.optusnet.com.au] has joined #launchpad [09:45] jamesh: are you saying that the nightly cve sync may be slowing things down? [09:46] on account of it making gangotri swap [09:46] SteveA: earlier lifeless said that it was using gigabytes of memory [09:46] somerville32: you can assign a single bug to multiple packages, afaik [09:47] How? [09:48] I think I figured it out [09:48] somerville32: great :) [09:49] jamesh: so, a quick fix may be to turn off the appservers on gangotri while that script is running... or turn off that script ;-) [09:50] When linking to remove bug report, do I just put in the bug report number? [09:51] *remote [09:51] Sorry, it is about 5am here, lol. === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad [09:54] SteveA: the script loads the gzipped cve db into memory, then gunzips it into memory, then parses the XML in memory. [09:55] SteveA: I just tried testing these steps independently: I was at 26MB RSS after gunzipping the db (it is 18MB). When I ran xml.dom.minidom.parseString() it got up to 800MB, at which point I killed it [09:58] there is a lot more information in the new XML format than there was in the old one -- votes and comments [09:58] Can someone tell me if I set this up right? https://launchpad.net/distros/debian/+bug/58169 [10:03] SteveA: looks like switching over to cElementTree cuts the memory usage from gigabytes to ~ 125MB [10:03] danilos: hi, around? [10:04] carlos: hi, yeah [10:04] If a bug would be fixed by upgrading it, should I mark it is fix released or just confirmed? [10:04] *as [10:06] somerville32: upgrading a package? [10:07] In that case, I guess it would be 'Fix released' as you already fixed it in a new version of the software that is already available === somerville32 nods. [10:10] jamesh: nice. [10:10] jamesh: probably easier to use cElementTree than to convert it to event-based parsing. [10:10] New bug: #58168 in rosetta "Missing upstream translations for ktorrent-2.0.1" [High,Confirmed] http://launchpad.net/bugs/58168 [10:11] I'm not sure if this bug report should be private or not. Can anyone clarify if it should be or not? === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === smurf [n=smurf@debian/developer/smurf] has joined #launchpad [10:31] Can somebody change katie's Wiki page in launchpad from UbuntuArchiveAutoSync (which doesn't exist) to ArchiveAdministration ? [10:38] smurf: URL of katie's launchpad page? [10:40] away [10:40] SteveA: people/katie ;-) [10:40] morning [10:40] sivang: likewise [10:41] smurf: ;-) How you been? you have long periods of time where you disappear and then come back. [10:41] sivang: s/disappear/need to do some work which actually pays the bills [10:42] which is why I couldn't com eto Paris or Wiesbaden :-( [10:42] smurf: this is actually katie's wiki username, not really the homepage [10:42] why do you want it changed? [10:44] smurf: eh, well, I wasn't in Wiesbaden, but Paris was really nice. re: bills, I know the feeling, might have to face this in a couple's of months time as well. Make sure you checkout the renovated HomeUserBackup spec :-) [10:44] SteveA: because it's a dead link? I could add a redirect page to the wiki instead, of course... [10:45] ok, I changed it. [10:45] smurf: we worked hard on it's GUI in Paris with glaztor and the KDE interface specialist. [10:45] SteveA: thx [10:45] SteveA: 0800 I think - === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [10:45] smurf: (and tons of suggestions and minor improvment from whoever cared to share his opinion on the tool) [10:45] sivang: cool. (NB: drop the apostrophe ;-) [10:45] jamesh: it was one aspect of the slowdown [10:46] jamesh: but it was still slow after that finished [10:46] lifeless: could the memory pressure have caused the rest of the problems? [10:46] smurf: hehe, right. [10:46] jamesh: I saw it at 1.8gb of ram IIRC [10:46] jamesh: could be related I guess, but: [10:46] 3956672k [10:46] thats a fair amount of memory to work with [10:46] good local time of the day [10:47] also, our launchpad instance is using 1.2gb of ram [10:47] hi ddaa [10:47] erm, 1.4gb now, for each instnace [10:47] lifeless: well, reducing the cve-update script's memory usage by an order of magnitude couldn't hurt ... [10:47] jamesh: agreed [10:47] danilos, carlos, jordi: hi, who's around for a rosetta chat later? [10:47] I'm around [10:47] SteveA: what time? [10:48] I'm flexible. 10 mins from now earliest [10:48] I'll have to leave for 30 mins at 11:30 or so, but I should be sitting here for the rest of the morning [10:49] 11:30 my time, that is [10:49] that's 09:30 UTC [10:50] ok [10:50] i want us to talk through what's currently happening with rosetta, and also to make a plan for the licensing stuff [10:50] so that I can talk about it when I next talk with mark on the phone [10:50] ok [10:51] jordi: so, you're available at 10 UTC? [10:52] I should be, but if you cont on 10:15, better [10:52] count [10:52] jordi: ping me, carlos and danilo when you're back [10:52] I'll sure [10:53] wtf [10:53] "what's currently happening" as in what's being hacked on for 1.0? [10:53] jamesh: I was thinking about the oops summary pages... what if the page also showed against each error the duration that the oopses occured over [10:53] jamesh: this would help to narrow down ones that are due to interactions with cron jobs etc. [10:53] jamesh: what do you think? [10:54] jordi: yeah, current work going on, issues with translators etc. [10:54] nod [10:54] serious bugs [10:54] SteveA: FYI, danilo and I are maintaining a wiki page with all tasks done to help kiko with his summaries at: https://launchpad.canonical.com/RosettaChanges [10:54] SteveA: so a time of day type thing? [10:55] yeah, just to display the datetime of the first OOPS for that error, and the last occuring OOPS for that error [10:55] or maybe... [10:55] SteveA: should be pretty easy to get it to put together a histogram, and provide info about peaks [10:55] a separate page showing the timeline for a day top to bottom [10:55] but anyway [10:56] the point is for matsubara to be able to glance over the errors, and see easily if the errors only occurred for say 30 mins [10:56] maybe when there was a network issue in the DC for those 30 mins [10:56] or during the 45 mins when certain cron scripts are running [11:00] mpt_: I hadn't read your Security snake oil post. Very cool :) === Tomcat_ [n=tomcat@p54A1992D.dip0.t-ipconnect.de] has joined #launchpad === Tomcat_ [n=tomcat@p54A1992D.dip0.t-ipconnect.de] has left #launchpad ["Ex-Chat"] [11:08] mpt_: Security snake oil? [11:09] when you're all out of olive oil, gotta use snake oil === danilos [n=danilo@82.117.204.242] has joined #launchpad === mholthaus_ [n=mholthau@32.34.3.213.cust.bluewin.ch] has joined #launchpad [11:13] wow, spam with "Ogg Vorbis xm" in the subject [11:13] yes [11:13] I've been getting chunks of the GPL in mine [11:14] jamesh: can you remind me the specifics of the fix you proposed for urlappend? [11:15] Spads: that's pretty leet spam! [11:16] Spads: woa [11:16] ddaa: make sure that "sftp" is in the urlparse.uses_netloc and urlparse.uses_relative === Spads shrugs [11:16] most spammers use gutenberg project files as their bayes chaff, I find [11:16] I occasionally google sections of spam chaff and find that it's Bullwer-Lytton or something [11:17] ddaa: basically "if 'sftp' not in urlparse.uses_netloc: urlparse.uses_netloc.append('sftp')" and the same for uses_relative [11:18] jamesh: test-wise, just checking that urlappend('sftp://foo/bar', 'gam') == 'sftp://foo/bar/gam' should be enough you think? [11:18] or is there some corner case to cover as well? [11:18] ddaa: yeah. You probably want to update uses_netloc/uses_relative in the webapp/url.py module body. [11:20] jamesh: yeah, what I was thinking, a simple _function that's called from the module body [11:22] Will get that fix merged in a separate patch today [11:22] cool. [11:23] jamesh: then, can I merge my importd-bzr-native branch? [11:23] (after using urlappend in the appropriate place there) [11:23] ddaa: yep. [11:28] carlos: is it ok to commit things like https://devpad.canonical.com/~jamesh/pending-reviews/danilo/launchpad/trivial/full-diff, or should I wait for stub? [11:28] danilos: go ahead, but please, be sure that it lands on production [11:29] danilos: you don't need stub's permission to update the sample data, but note that the change won't be reflected in production [11:29] danilos: anyway, you can send the request to lifeless, he's the dba while stub is on holidays and it's a quite trivial change [11:33] carlos: it's already in the production [11:33] jamesh: yeah, thanks [11:33] then go ahead, as jamesh told you, you don't need to check sampledata changes with stuart [11:34] carlos: ok, it's going in [11:34] carlos: do I use [trivial] or something? [11:35] yeah, [trivial] [11:35] ok === jinty [n=jinty@19.Red-83-50-220.dynamicIP.rima-tde.net] has joined #launchpad [11:42] SteveA: got time for a quick review? [11:44] jamesh: yes [11:45] SteveA: https://sodium.ubuntu.com/~andrew/paste/fileYqNEig.html <- it moves the CVE updater to cElementTree [11:47] jamesh: any clue how I run the doctests in webapp/url.py? [11:48] I tried "./test.py -vv canonical urlappend", but it said "0 tests" [11:48] ddaa: not sure. [11:49] maybe they arent' being run currently [11:54] my guess too :( [11:54] well, any clue how to get them to run :) ? [11:54] like an existing module with docstrings where I could cargo-cult from? [11:59] ddaa: look at webapp/tests/test___init__.py === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:59] ddaa: look at webapp/tests/test___init__.py [12:00] Thank you [12:00] stupid gaim gtk bug [12:01] something to do with and active selection and moving out of the window, but I haven't still figured out how to repeat it :( [12:05] jamesh: just add a decent docstring to getText(elem) [12:05] jamesh: other than that, r=me [12:05] SteveA: okay. Thanks. [12:21] jamesh: quick review requested https://chinstrap.ubuntu.com/~dsilvers/paste/fileaJXUpp.html [12:23] ddaa: I think we are supposed to use http://devpad.canonical.com/~andrew/paste/ instead the old one on chinstrap... [12:24] ddaa: looks good. [12:24] r=jamesh [12:24] carlos: thank you, updated my bookmark [12:24] jamesh: another candidate for inclusion in a URL class for our webapp libraries [12:26] hmm? [12:27] we were talking the other day about having a more OO URL class in webapp [12:28] yep [12:28] because the standard library url facilities are quite low-level, and very procedural to use [12:28] and we have higher-level facilities that are important to us, like asking whether one URL is "inside" another [12:28] I wonder if we should bypass urlparse completely with the new URL class === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [12:29] that would be an implementation issue :-) [12:29] I think we should, globally altering stdlib module is eeeeew for a library [12:29] what I mean is, the interface to the URL class would be the same in any case [12:29] ddaa: yes... although I think the std library is misdesigned here [12:29] as it encourages such alterations [12:29] compare it to random [12:29] you have a global random number generator [12:30] but you can create your own random() object for your application [12:30] and seed it as you need to etc. [12:30] SteveA: agreed, it should probably use factory and method patterns [12:30] ddaa: the problem is that the stdlib module is written to the old spec, and has useless defaults for unknown schemes. The newer URI RFC specifies rules for processing arbitrary URIs [12:31] jamesh: think that'll change in python 2.5 or 2.6 ? [12:31] jamesh: the biggest problem IMO is that it fails silently for unknown scheme instead of raising. [12:31] I haven't checked what's in 2.5 w.r.t. this [12:31] BTW, it appears that the guilty code has a comment saying something like "that's a mess and should be rewritten" [12:31] ddaa: it doesn't fail. It just assumes that unknown schemes don't have a netloc section (the "//host:port" bit) and don't support relative references [12:32] SteveA, danilos, carlos: here [12:32] which is a very bad assumption [12:32] hi jordi [12:32] jordi: hey [12:32] I can be ready in 10 mins, say at 45 mins past the hour [12:32] danilos, carlos: okay with you too? [12:32] jamesh: well, I call that a silent failure since any default is likely not to do the correct thing. It's not avoiding the temptation to guess. [12:32] SteveA: sure [12:33] cool [12:33] SteveA: yeah [12:33] ok, done [12:33] SteveA: cool [12:33] ddaa: yep. I think it would be good to just implement the rules in the new RFC, which generally does the right thing [12:34] if you say so... I am not familiar with those RFCs === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === ogra [n=ogra@ubuntu/member/ogra] has joined #launchpad [01:07] New bug: #58187 in soyuz "uploads to frozen should land in unapproved, not be rejected" [Critical,In progress] http://launchpad.net/bugs/58187 [01:08] (no ubugtu isn't laggy, he was broken) [01:10] malcc: around? [01:10] SteveA: Yup === ogra [n=ogra@ubuntu/member/ogra] has joined #launchpad === ogra [n=ogra@ubuntu/member/ogra] has joined #launchpad [01:51] carlos: [01:51] $ tar xf oo-translations-20060808.tar.gz [01:51] gzip: stdin: unexpected end of file [01:51] tar: Unexpected EOF in archive [01:51] tar: Unexpected EOF in archive [01:51] tar: Error is not recoverable: exiting now [01:51] hmm, let me check... [01:53] hmm [01:53] seems like there was a problem with the upload [01:53] elmo: ping [01:53] doko: I don't have the file around [01:53] I will need to do a new download [01:53] I will do it after lunch and ping you again, ok? === carlos -> lunch [01:55] later [01:56] ok [01:56] carlos: that's your current file on chinstrap [01:56] s/chinstrap/people/ [01:56] yeah, I know [01:56] I uploaded it from my laptop [01:56] but I removed it so I need to generate a new one === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === danilos is off to bank [02:11] hey mpt_, have you had a chance to update PersonCreationRationale? === Kuhrscher [n=jannick@88.134.176.136] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === niemeyer [n=niemeyer@200-203-209-139.ctame7004.dsl.brasiltelecom.net.br] has joined #launchpad [02:44] heeelo [02:45] Hi, which is the right mailing list, to post some thoughts about upstream import to Rosetta? [02:45] Kuhrscher, rosetta-users@lists.canonical.com [02:46] Is it only for the users, or for the devs as well? [02:47] for both [02:47] ah, thanks [02:48] kiko: hi, how's it going? [02:48] Do I have to be a member of the list to post something? [02:48] SteveA, pretty good, pretty good [02:48] Kuhrscher: it'll get stuck for moderation [02:48] but I will moderate :) [02:48] Kuhrscher, I believe so, and I am not list admin [02:49] laters [02:50] thanks [02:58] is the librarian down again? [02:58] kiko: hi. have you merged your patch to show a link to the original description, if the bug description has been edited? [02:59] BjornT, no, but I can do that today if you like [02:59] cprov, should I also drop permissions for the *PublishingView classes? [02:59] kiko: that'd be good, thanks. [02:59] cool. [02:59] malcc, how's the testing coming along? [03:00] kiko: isn't malcc in charge of this ? [03:00] malcc, remember we want to do it /this week/.. [03:00] cprov, well, I can drop it -- just a simple change to security.py [03:00] I wasn't meaning to drop the views themselves [03:00] kiko: I think if you removed all callsites for {S,B}PPV you can remove the perms and the classes [03:01] I think I did I'll check [03:01] kiko: btw, as for the rest of the spec (KeepingBugsConcise), is everything in there a 1.0 goal? i.e, are we going to do comment collapsing? [03:01] we can't drop the DB views yet though [03:01]