[02:04] <kiko-afk> cprov-afk, sou uma mmia. see email.
[02:05] <cprov-afk> kiko-afk: I've seen, running new code 
[02:05] <kiko-afk> cprov-afk, ah, do you have the output already?
[02:05] <cprov-afk> kiko-afk: in a bit 
[02:08] <cprov-afk> kiko-afk: https://sodium.ubuntu.com/~andrew/paste/fileZMTnvB.html
[02:09] <kiko-afk> what do you think?
[02:09] <cprov-afk> kiko-afk: the arch-all ones are those we did shit ...
[02:09] <cprov-afk> kiko-afk: I'm mean we didn't build the arch-indep binary
[02:09] <cprov-afk> kiko-afk: is that right ?
[02:10] <kiko-afk> cprov-afk, well, not exactly. we try and build /too much/ today
[02:10] <kiko-afk> cprov-afk, I'm trying to find out if we can live without binary PAS support.
[02:10] <kiko-afk> I'll reply to myself.
[02:10] <cprov-afk> kiko-afk: how do you mean ? /too much/
[02:11] <kiko-afk> well, these are binary PAS candidates
[02:11] <kiko-afk> but we ignore binary PAS
[02:11] <kiko-afk> so we try to build them everywhere regardless
[02:12] <cprov-afk> kiko-afk: they will got rejected, same name & version 
[02:12] <kiko-afk> they won't build
[02:12] <kiko-afk> it's not a problem (I think)
[02:12] <kiko-afk> it's just that we spam the buildds
[02:12] <kiko-afk> I'll call you in a bit
[02:12] <cprov-afk> kiko-afk: right
[04:22] <jamesh> I wonder if Python 2.5 will make it into edgy
[05:06] <jamesh> mpt: ping?
[05:17] <mpt> jamesh, pong
[05:17] <mpt> lifeless, ping
[05:18] <jamesh> mpt: what do you think about the wording changes in this patch? https://sodium.ubuntu.com/~andrew/paste/file8p1Pvs.html
[05:19] <jamesh> this affects the details portlet for people who aren't Launchpad users
[05:20] <mpt> jamesh, that looks like an improvement
[05:20] <spiv> 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] <lifeless> mpt: ?
[05:20] <spiv> jamesh: maybe this isn't a problem.  I'm happy to trust mpt's judgement anyway.
[05:21] <mpt> lifeless, can you confirm whether PQM received a couple of merge requests from me in the past 20 minutes?
[05:21] <jamesh> spiv: "Claim this person" also sounds weird though ...
[05:22] <lifeless> mpt: uhh, pqm.launchpad.net ;)
[05:22] <mpt> lifeless, it hasn't sent me mail, and nor has it included the branch in the queue
[05:22] <lifeless> mpt: it looks idle
[05:22] <spiv> jamesh: "claim" isn't an ideal verb, no
[05:22] <lifeless> mpt: then its probably not recieved it
[05:22] <lifeless> as in, almost certainly.
[05:22] <spiv> jamesh: "Claim this account" seems less weird, except there's no account yet
[05:22] <lifeless> -or- you've changed your config so its not sending the error to the right place
[05:22] <lifeless> 'I am this person'
[05:23] <jamesh> mpt: any thoughts on alternative wording for "I am this person" or "Claim this person"?
[05:23] <mpt> 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] <jamesh> lifeless: that's the wording I've got at the moment
[05:23] <lifeless> I like 'I am this person' ;)
[05:23] <mpt> jamesh: "Hey, that's me!"
[05:23] <mpt> :-)
[05:24] <lifeless> good - 'this is me'
[05:24] <spiv> 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] <jamesh> spiv: sure.
[05:24] <jamesh> this also makes the person merge form more visible too
[05:25] <spiv> Making the person merge form more visible would be great.
[05:25] <mpt> My judgement is currently impaired by lack of sleep
[05:25] <jamesh> since there is a link to it on each non-active person page if you're logged in
[05:25] <spiv> mpt: So you probably only have about 3x as much UI sense as me, rather than your usual 10x ;)
[05:26] <mpt> --dry-run looks all correct...
[05:27] <jamesh> mpt: does "mailq" show any queued messages?
[05:28] <mpt> eh.
[05:29] <mpt> there they are.
[05:29] <mpt> (Host or domain name not found. Name service error for name=pqm.ubuntu.com type=MX: Host not found, try again)
[05:30] <jamesh> try running "sudo sendmail -q"
[05:30] <mpt> That retries everything?
[05:30] <jamesh> yeah
[05:30] <mpt> It seems to have removed the error message, anyway
[05:31] <mpt> ... and now it's back
[05:31] <mpt> this time for both attempts
[05:31] <mpt> which is silly, because http://pqm.ubuntu.com/ loads just fine in a browser
[05:31] <lifeless> different DNS records
[05:32] <lifeless> host -t mx pqm.ubuntu.com (IIR the syntax C)
[05:32] <mpt> ;; connection timed out
[05:32] <mpt> I HATE COMPUTERS
[05:32] <mpt> ahem
[05:35] <jamesh> maybe DNS takes a bit longer to get to New Zealand, so times out
[05:35] <jamesh> probably because of the time zone differences
[05:36] <mpt> And the sunspots!
[05:36] <mpt> Nah, this is probably leftover from the horrible DNS problems I had Monday and yesterday, fixed by upgrading the router firmware
[05:37] <mpt> bbiab
[05:55] <mpt_> so, that sucks
[05:55] <mpt_> Sorry for bothering you lifeless, I didn't know about mailq
[06:06] <jamesh> 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] <jamesh> it has a really evil __contains__() implementation that mutates the object.
[06:08] <jamesh> so that "not_in_cache in cache" will return False the first time and True subsequent times
[06:08] <spiv> jamesh: ew
[06:09] <jamesh> that is, __contains__() adds items to the cache
[06:09] <lifeless> freakydeaky
[06:10] <lifeless> or should I say, freakerydeakerydoo
[06:10] <jamesh> the code I've added to cope with existing product releases should also make the cache code unnecessary
[06:12] <lifeless> excellent
[06:12] <lifeless> I was wondering if we could without it
[06:15] <jamesh> lifeless: btw, does bzr do anything special to avoid umask issues like Subversion does?
[06:15] <lifeless> somewhat yes
[06:15] <lifeless> we chmod files if an option has been set
[06:16] <jamesh> for reference, Subversion's fsfs backend copies the file permissions from the previous rev when creating a new one
[06:16] <lifeless> but we cant preserve sticky bit over sftp
[06:16] <lifeless> because openssh' sftp-server masks the sgid bit
[06:17] <jamesh> that's not as big a deal for updating existing branches (which is where the problem usually bites)
[06:18] <jamesh> actually, I suppose bzr would be creating dirs with the hashed subdirs
[06:18] <lifeless> yes
[06:20] <jamesh> well, I suppose an admin could create all 256 weaves/NN subdirs and then chgrp/chmod things appropriately
[06:22] <lifeless> yup
[06:52] <jamesh> I wonder how I got an Unauthorized test failure in a LaunchpadZopelessLayer test
[06:52] <jamesh> they're meant to be running with permissive security policy
[08:37] <BjornT> 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
[08:42] <carlos_> morning
[08:58] <jamesh> BjornT: wouldn't that be a forbidden error?
[08:59] <jamesh> BjornT: this was saying I didn't have launchpad.Edit on the object.
[08:59] <jamesh> (I'd updated the security declaration)
[09:01] <somerville32> Is launchpad down?
[09:02] <carlos> looks like that...
[09:02] <somerville32> Gah - I was in the middle of reporting a security bug :[
[09:04] <spiv> hmm, it's not down for me, but it is very slow.
[09:04] <spiv> I seem to recall the same thing happened around this time yesterday.
[09:04] <jamesh> this happened a few days ago too
[09:04] <jamesh> a cron script hammering one of the app servers
[09:04] <spiv> Right.
[09:05] <somerville32> When will the carnage be over?
[09:06] <BjornT> jamesh: right. yeah, you probably should have gotten a forbidden error.
[09:07] <jamesh> 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] <lifeless> hiya
[09:10] <lifeless> looks like update-cve is using a TONNE of memory
[09:10] <lifeless> let me unSTOP it
[09:10] <lifeless> see if this makes it suck again
[09:11] <jamesh> I wonder if is doing something stupid
[09:11] <lifeless> and look how slow it just got again
[09:11] <jamesh> (other than using xml.dom.minidom)
[09:11] <lifeless> by tonne, I mean gb's
[09:11] <jamesh> how big is the CVE database?
[09:11] <BjornT> jamesh: does it work if you do setSecurityPolicy(PermissiveSecurityPolicy) first?
[09:13] <lifeless> hmm,
[09:13] <lifeless> its the whole nightly scripts doing it I think
[09:14] <lifeless> them and an archvysn rsync job
[09:14] <lifeless> will ask admins later
[09:14] <jamesh> BjornT: the tests rely on LaunchpadZopelessLayer, which does execute_zcml_for_scripts(), which installs the PermissiveSecurityPolicy
[09:17] <BjornT> 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] <lifeless> mpt_: the fancy menu at the top of the lp pages does not honour ctrl-click :)
[09:18] <lifeless> is this by design ??
[09:19] <jamesh> lifeless: the dynarch menus stuff is designed to act as much like real menus as possible, rather than as a webpage
[09:20] <lifeless> 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] <jamesh> from what I can tell, that includes making them non-keyboard accessible ...
[09:20] <lifeless> ctrl-click has nothing to do with keyboard
[09:20] <lifeless> it has to do with them being considered links that the browser understands
[09:21] <jamesh> ctrl-click has to do with clicking hyperlinks
[09:21] <jamesh> I don't think they are hyperlinks
[09:21] <lifeless> (in point of fact, real menus *are* keyboard accessible)
[09:21] <lifeless> so, replace ctrl-click with 'middle mouse' then ;)
[09:21] <jamesh> it is code that'd be worth replacing at some point
[09:28] <SteveA> good morning
[09:29] <SteveA> lifeless: the dynarch menus are going away very soon
[09:29] <SteveA> lifeless: so, expend no effort around them now
[09:30] <SteveA> jamesh: the replacement code already exists.  i just need to find time to do the replacement.
[09:33] <lifeless> SteveA: ok
[09:34] <lifeless> SteveA: the slowdown yesterday in lp happened again today, and coincides with the lp nightly.sh, and an rsync by user archvsyn
[09:39] <SteveA> 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.
[09:41] <somerville32> 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] <jamesh> lifeless: the CVE database is XML, and 3 megs when gzip compressed
[09:41] <jamesh> lifeless: so it isn't too surprising to see it using shitloads of memory when loaded with xml.dom.minidom
[09:43] <jamesh> moving it to cElementTree would be an improvement.  Moving to an incremental parser would be even better
[09:45] <SteveA> jamesh: are you saying that the nightly cve sync may be slowing things down?
[09:46] <SteveA> on account of it making gangotri swap
[09:46] <jamesh> SteveA: earlier lifeless said that it was using gigabytes of memory
[09:46] <danilos> somerville32: you can assign a single bug to multiple packages, afaik
[09:47] <somerville32> How?
[09:48] <somerville32> I think I figured it out <g>
[09:48] <danilos> somerville32: great :)
[09:49] <SteveA> 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] <somerville32> When linking to remove bug report, do I just put in the bug report number?
[09:51] <somerville32> *remote
[09:51] <somerville32> Sorry, it is about 5am here, lol.
[09:54] <jamesh> SteveA: the script loads the gzipped cve db into memory, then gunzips it into memory, then parses the XML in memory.
[09:55] <jamesh> 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] <jamesh> there is a lot more information in the new XML format than there was in the old one -- votes and comments
[09:58] <somerville32> Can someone tell me if I set this up right? https://launchpad.net/distros/debian/+bug/58169
[10:03] <jamesh> SteveA: looks like switching over to cElementTree cuts the memory usage from gigabytes to ~ 125MB
[10:03] <carlos> danilos: hi, around?
[10:04] <danilos> carlos: hi, yeah
[10:04] <somerville32> If a bug would be fixed by upgrading it, should I mark it is fix released or just confirmed?
[10:04] <somerville32> *as
[10:06] <carlos> somerville32: upgrading a package?
[10:07] <carlos> 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
[10:10] <SteveA> jamesh: nice.
[10:10] <SteveA> jamesh: probably easier to use cElementTree than to convert it to event-based parsing.
[10:10] <Ubugtu> New bug: #58168 in rosetta "Missing upstream translations for ktorrent-2.0.1" [High,Confirmed]  http://launchpad.net/bugs/58168
[10:11] <somerville32> I'm not sure if this bug report should be private or not. Can anyone clarify if it should be or not?
[10:31] <smurf> Can somebody change katie's Wiki page in launchpad from UbuntuArchiveAutoSync (which doesn't exist) to ArchiveAdministration ?
[10:38] <SteveA> smurf: URL of katie's launchpad page?
[10:40] <sivang> away
[10:40] <smurf> SteveA: people/katie ;-)
[10:40] <sivang> morning
[10:40] <smurf> sivang: likewise
[10:41] <sivang> smurf: ;-) How you been? you have long periods of time where you disappear and then come back.
[10:41] <smurf> sivang: s/disappear/need to do some work which actually pays the bills
[10:42] <smurf> which is why I couldn't com eto Paris or Wiesbaden :-(
[10:42] <SteveA> smurf: this is actually katie's wiki username, not really the homepage
[10:42] <SteveA> why do you want it changed?
[10:44] <sivang> 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] <smurf> SteveA: because it's a dead link? I could add a redirect page to the wiki instead, of course...
[10:45] <SteveA> ok, I changed it.
[10:45] <sivang> smurf: we worked hard on it's GUI in Paris with glaztor and the KDE interface specialist.
[10:45] <smurf> SteveA: thx
[10:45] <lifeless> SteveA: 0800 I think - 
[10:45] <sivang> smurf: (and tons of suggestions and minor improvment from whoever cared to share his opinion on the tool)
[10:45] <smurf> sivang: cool. (NB: drop the apostrophe ;-)
[10:45] <lifeless> jamesh: it was one aspect of the slowdown
[10:46] <lifeless> jamesh: but it was still slow after that finished
[10:46] <jamesh> lifeless: could the memory pressure have caused the rest of the problems?
[10:46] <sivang> smurf: hehe, right. 
[10:46] <lifeless> jamesh: I saw it at 1.8gb of ram IIRC
[10:46] <lifeless> jamesh: could be related I guess, but:
[10:46] <lifeless> 3956672k
[10:46] <lifeless> thats a fair amount of memory to work with
[10:46] <ddaa> good local time of the day
[10:47] <lifeless> also, our launchpad instance is using 1.2gb of ram
[10:47] <SteveA> hi ddaa
[10:47] <lifeless> erm, 1.4gb now, for each instnace
[10:47] <jamesh> lifeless: well, reducing the cve-update script's memory usage by an order of magnitude couldn't hurt ...
[10:47] <lifeless> jamesh: agreed
[10:47] <SteveA> danilos, carlos, jordi: hi, who's around for a rosetta chat later?
[10:47] <carlos> I'm around
[10:47] <jordi> SteveA: what time?
[10:48] <SteveA> I'm flexible.  10 mins from now earliest
[10:48] <jordi> 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] <jordi> 11:30 my time, that is
[10:49] <carlos> that's 09:30 UTC
[10:50] <SteveA> ok
[10:50] <SteveA> i want us to talk through what's currently happening with rosetta, and also to make a plan for the licensing stuff
[10:50] <SteveA> so that I can talk about it when I next talk with mark on the phone
[10:50] <carlos> ok
[10:51] <SteveA> jordi: so, you're available at 10 UTC?
[10:52] <jordi> I should be, but if you cont on 10:15, better
[10:52] <jordi> count
[10:52] <SteveA> jordi: ping me, carlos and danilo when you're back
[10:52] <jordi> I'll sure
[10:53] <jordi> wtf
[10:53] <jordi> "what's currently happening" as in what's being hacked on for 1.0?
[10:53] <SteveA> 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] <SteveA> jamesh: this would help to narrow down ones that are due to interactions with cron jobs etc.
[10:53] <SteveA> jamesh: what do you think?
[10:54] <SteveA> jordi: yeah, current work going on, issues with translators etc.
[10:54] <jordi> nod
[10:54] <SteveA> serious bugs
[10:54] <carlos> 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] <jamesh> SteveA: so a time of day type thing?
[10:55] <SteveA> yeah, just to display the datetime of the first OOPS for that error, and the last occuring OOPS for that error
[10:55] <SteveA> or maybe...
[10:55] <jamesh> SteveA: should be pretty easy to get it to put together a histogram, and provide info about peaks
[10:55] <SteveA> a separate page showing the timeline for a day top to bottom
[10:55] <SteveA> but anyway
[10:56] <SteveA> 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] <SteveA> maybe when there was a network issue in the DC for those 30 mins
[10:56] <SteveA> or during the 45 mins when certain cron scripts are running
[11:00] <jordi> mpt_: I hadn't read your Security snake oil post. Very cool :)
[11:08] <SteveA> mpt_: Security snake oil?
[11:09] <SteveA> when you're all out of olive oil, gotta use snake oil
[11:13] <jordi> wow, spam with "Ogg Vorbis xm" in the subject
[11:13] <Spads> yes
[11:13] <Spads> I've been getting chunks of the GPL in mine
[11:14] <ddaa> jamesh: can you remind me the specifics of the fix you proposed for urlappend?
[11:15] <ddaa> Spads: that's pretty leet spam!
[11:16] <jordi> Spads: woa
[11:16] <jamesh> ddaa: make sure that "sftp" is in the urlparse.uses_netloc and urlparse.uses_relative
[11:16] <Spads> most spammers use gutenberg project files as their bayes chaff, I find
[11:16] <Spads> I occasionally google sections of spam chaff and find that it's Bullwer-Lytton or something
[11:17] <jamesh> ddaa: basically "if 'sftp' not in urlparse.uses_netloc: urlparse.uses_netloc.append('sftp')" and the same for uses_relative
[11:18] <ddaa> jamesh: test-wise, just checking that urlappend('sftp://foo/bar', 'gam') == 'sftp://foo/bar/gam' should be enough you think?
[11:18] <ddaa> or is there some corner case to cover as well?
[11:18] <jamesh> ddaa: yeah.  You probably want to update uses_netloc/uses_relative in the webapp/url.py module body.
[11:20] <ddaa> jamesh: yeah, what I was thinking, a simple _function that's called from the module body
[11:22] <ddaa> Will get that fix merged in a separate patch today
[11:22] <jamesh> cool.
[11:23] <ddaa> jamesh: then, can I merge my importd-bzr-native branch?
[11:23] <ddaa> (after using urlappend in the appropriate place there)
[11:23] <jamesh> ddaa: yep.
[11:28] <danilos> 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] <carlos> danilos: go ahead, but please, be sure that it lands on production
[11:29] <jamesh> 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] <carlos> 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] <danilos> carlos: it's already in the production
[11:33] <danilos> jamesh: yeah, thanks
[11:33] <carlos> then go ahead, as jamesh told you, you don't need to check sampledata changes with stuart
[11:34] <danilos> carlos: ok, it's going in
[11:34] <danilos> carlos: do I use [trivial]  or something?
[11:35] <carlos> yeah, [trivial] 
[11:35] <danilos> ok
[11:42] <jamesh> SteveA: got time for a quick review?
[11:44] <SteveA> jamesh: yes
[11:45] <jamesh> SteveA: https://sodium.ubuntu.com/~andrew/paste/fileYqNEig.html <- it moves the CVE updater to cElementTree
[11:47] <ddaa> jamesh: any clue how I run the doctests in webapp/url.py?
[11:48] <ddaa> I tried "./test.py -vv canonical urlappend", but it said "0 tests"
[11:48] <jamesh> ddaa: not sure.
[11:49] <jamesh> maybe they arent' being run currently
[11:54] <ddaa> my guess too :(
[11:54] <ddaa> well, any clue how to get them to run :) ?
[11:54] <ddaa> like an existing module with docstrings where I could cargo-cult from?
[11:59] <BjornT> ddaa: look at webapp/tests/test___init__.py
[11:59] <BjornT> ddaa: look at webapp/tests/test___init__.py
[12:00] <ddaa> Thank you
[12:00] <ddaa> stupid gaim gtk bug
[12:01] <ddaa> 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] <SteveA> jamesh: just add a decent docstring to getText(elem)
[12:05] <SteveA> jamesh: other than that, r=me
[12:05] <jamesh> SteveA: okay.  Thanks.
[12:21] <ddaa> jamesh: quick review requested https://chinstrap.ubuntu.com/~dsilvers/paste/fileaJXUpp.html
[12:23] <carlos> ddaa: I think we are supposed to use http://devpad.canonical.com/~andrew/paste/ instead the old one on chinstrap...
[12:24] <jamesh> ddaa: looks good.
[12:24] <jamesh> r=jamesh
[12:24] <ddaa> carlos: thank you, updated my bookmark
[12:24] <SteveA> jamesh: another candidate for inclusion in a URL class for our webapp libraries
[12:26] <jamesh> hmm?
[12:27] <SteveA> we were talking the other day about having a more OO URL class in webapp
[12:28] <jamesh> yep
[12:28] <SteveA> because the standard library url facilities are quite low-level, and very procedural to use
[12:28] <SteveA> and we have higher-level facilities that are important to us, like asking whether one URL is "inside" another
[12:28] <jamesh> I wonder if we should bypass urlparse completely with the new URL class
[12:29] <SteveA> that would be an implementation issue :-)
[12:29] <ddaa> I think we should, globally altering stdlib module is eeeeew for a library
[12:29] <SteveA> what I mean is, the interface to the URL class would be the same in any case
[12:29] <SteveA> ddaa: yes... although I think the std library is misdesigned here
[12:29] <SteveA> as it encourages such alterations
[12:29] <SteveA> compare it to random
[12:29] <SteveA> you have a global random number generator
[12:30] <SteveA> but you can create your own random() object for your application
[12:30] <SteveA> and seed it as you need to etc.
[12:30] <ddaa> SteveA: agreed, it should probably use factory and method patterns
[12:30] <jamesh> 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] <SteveA> jamesh: think that'll change in python 2.5 or 2.6 ?
[12:31] <ddaa> jamesh: the biggest problem IMO is that it fails silently for unknown scheme instead of raising.
[12:31] <jamesh> I haven't checked what's in 2.5 w.r.t. this
[12:31] <ddaa> BTW, it appears that the guilty code has a comment saying something like "that's a mess and should be rewritten"
[12:31] <jamesh> 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] <jordi> SteveA, danilos, carlos: here
[12:32] <jamesh> which is a very bad assumption
[12:32] <SteveA> hi jordi
[12:32] <danilos> jordi: hey
[12:32] <SteveA> I can be ready in 10 mins, say at 45 mins past the hour
[12:32] <SteveA> danilos, carlos: okay with you too?
[12:32] <ddaa> 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] <danilos> SteveA: sure
[12:33] <SteveA> cool
[12:33] <carlos> SteveA: yeah
[12:33] <SteveA> ok, done
[12:33] <jordi> SteveA: cool
[12:33] <jamesh> 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] <ddaa> if you say so... I am not familiar with those RFCs
[01:07] <Ubugtu> 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] <Seveas> (no ubugtu isn't laggy, he was broken)
[01:10] <SteveA> malcc: around?
[01:10] <malcc> SteveA: Yup
[01:51] <doko> carlos:
[01:51] <doko> $ tar xf oo-translations-20060808.tar.gz
[01:51] <doko> gzip: stdin: unexpected end of file
[01:51] <doko> tar: Unexpected EOF in archive
[01:51] <doko> tar: Unexpected EOF in archive
[01:51] <doko> tar: Error is not recoverable: exiting now
[01:51] <carlos> hmm, let me check...
[01:53] <carlos> hmm
[01:53] <carlos> seems like there was a problem with the upload
[01:53] <danilos> elmo: ping
[01:53] <carlos> doko: I don't have the file around
[01:53] <carlos> I will need to do a new download
[01:53] <carlos> I will do it after lunch and ping you again, ok?
[01:55] <carlos> later
[01:56] <doko> ok
[01:56] <doko> carlos: that's your current file on chinstrap
[01:56] <doko> s/chinstrap/people/
[01:56] <carlos> yeah, I know
[01:56] <carlos> I uploaded it from my laptop
[01:56] <carlos> but I removed it so I need to generate a new one
[02:11] <salgado> hey mpt_, have you had a chance to update PersonCreationRationale?
[02:44] <kiko> heeelo
[02:45] <Kuhrscher> Hi, which is the right mailing list, to post some thoughts about upstream import to Rosetta?
[02:45] <kiko> Kuhrscher, rosetta-users@lists.canonical.com
[02:46] <Kuhrscher> Is it only for the users, or for the devs as well?
[02:47] <kiko> for both
[02:47] <Kuhrscher> ah, thanks
[02:48] <SteveA> kiko: hi, how's it going?
[02:48] <Kuhrscher> Do I have to be a member of the list to post something?
[02:48] <kiko> SteveA, pretty good, pretty good
[02:48] <jordi> Kuhrscher: it'll get stuck for moderation
[02:48] <jordi> but I will moderate :)
[02:48] <kiko> Kuhrscher, I believe so, and I am not list admin
[02:49] <jordi> laters
[02:50] <Kuhrscher> thanks
[02:58] <salgado> is the librarian down again?
[02:58] <BjornT> kiko: hi. have you merged your patch to show a link to the original description, if the bug description has been edited?
[02:59] <kiko> BjornT, no, but I can do that today if you like
[02:59] <kiko> cprov, should I also drop permissions for the *PublishingView classes?
[02:59] <BjornT> kiko: that'd be good, thanks.
[02:59] <kiko> cool.
[02:59] <kiko> malcc, how's the testing coming along?
[03:00] <cprov> kiko: isn't malcc in charge of this ?
[03:00] <kiko> malcc, remember we want to do it /this week/..
[03:00] <kiko> cprov, well, I can drop it -- just a simple change to security.py
[03:00] <kiko> I wasn't meaning to drop the views themselves
[03:00] <cprov> kiko: I think if you removed all callsites for {S,B}PPV you can remove the perms and the classes
[03:01] <kiko> I think I did I'll check
[03:01] <BjornT> 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] <kiko> we can't drop the DB views yet though
[03:01] <cprov> kiko: right, they still living on DB but nobody uses it
[03:02] <malcc> kiko: The testing is coming along fine, blocked right now behind getting a nice fresh database snapshot, will send lifeless an email as he's acting DBA this week
[03:02] <LarstiQ> kiko: "The Subversion Project only accepts code whose copyright is assigned to CollabNet."
[03:02] <cprov> kiko: why not, I used this approach for {S,B}PP ... remove callsites and joins, purge classes and perms
[03:02] <malcc> kiko: As to /this week/, dude, your humour just doesn't work on IRC, it just comes across as being rude :)
[03:02] <kiko> BjornT, I think our comment collapsing is enough... I doubt we should really do the full-fledged optional collapsing
[03:05] <cprov> kiko: malcc: dudes, deadlines are hilarious by nature, you don't need to fight about it. Maybe, we can do it by the end the week, not sure though.
[03:05] <kiko> malcc, I wasn't being humorous!
[03:06] <kiko> seriously though I was implying that a) we shouldn't let it slip and b) keep us informed
[03:08] <BjornT> kiko: yeah, i also think that it's not necessary to do full-fledged collapsing. i'll send an email to mpt to see what he thinks about it, though.
[03:10] <cprov> kiko: well, "currently blocked on AU TZ" isn't a good status report, anyway. But counting on the fact we will have fresh daily snapshots for free, I'd not be waiting much for this. Can you join ##soyuz for helping us to sort alternative plan ?
[03:11] <ddaa> BjornT: thank you for annoying me about the browser/branch.py code in your review. I just found a nasty bug with the validation code.
[03:12] <ddaa> That what one get by writing code using the "hammer the square peg in until it fits" technique...
[03:12] <malcc> kiko: Dropping the permissions for these views in rocketfuel, is that going to lead to them being dropped from the live db while the old codeline still live on drescher requires them?
[03:14] <kiko> cprov, uhhh, I can, but I am trying to get the rest of the crap I have pending sorted out.
[03:14] <kiko> malcc, no, to drop something from the DB requires a DB patch.
[03:15] <cprov> malcc: it depends of when we intend to rollout production + soyuz cleanup. Facts point that we can't afford to wait more than next tuesday.
[03:16] <kiko> cprov, well, we can wait and just cherry pick the policy fix, just that it would be nice to not let the scheduled week slip
[03:16] <kiko> anyway let me ignore IRC so I can actually get this stuff done
[03:17] <cprov> kiko: why not just finish the cleanup, removing the views and land archive rework next week ?
[03:18] <LarstiQ> ddaa: is there a difference between C:\FOO and C:\\FOO ?
[03:18] <kiko> cprov, I'd be happy to, but we need the tests to do that. :)
[03:18] <cprov> kiko: anyway, it doesn't exclude the need of test env setup
[03:18] <kiko> no, it underlines it!
[03:18] <cprov> kiko: yes yes
[03:36] <ddaa> LarstiQ: no idea
[03:37] <kiko> LarstiQ, they would accept BSD-licensed translations, though?
[03:37] <LarstiQ> kiko: I can ask if you want to, but I really get the impression it is a case of copyright assignment.
[03:37] <kiko> malcc, btw, will you have time to look at that builddmaster patch?
[03:38] <kiko> LarstiQ, it's going to make things harder for them in general if they don't think BSD is okay for their translations I think.. I mean, BSD allows them to relicense as they may desire
[03:38] <malcc> kiko: Yes, I'm sure I'll have some time later
[03:39] <kiko> malcc, thanks, just wanted to check if I should context-switch back to it yet or not
[03:39] <LarstiQ> kiko: http://svn.haxx.se/dev/archive-2006-08/0946.shtml
[03:40] <LarstiQ> kiko: ianal, but this same thing with relicensing bsd was very messy in a recent bazaar thread 
[03:40] <kiko> mmm
[03:41] <kiko> I claim ignorance and go back to coding ;)
[03:41] <LarstiQ> kiko: could you give one look at that archived post I pasted?
[03:41] <kiko> LarstiQ, I did, and forwarded it to SteveA :)
[03:41] <kiko> he'd seen it
[03:41] <LarstiQ> I'm going to ask about bsd at least, but I'm nore sure about adressing the 'doubtful' claim
[03:48] <malcc> Ok, as outlined on https://launchpad.canonical.com/SoyuzSystemTest we're about to start flinging database snapshots and codelines around on mawson, tread there at your own peril :)
[03:53] <kiko> malcc, ROCK ON!
[03:59] <kiko> cprov, malcc: I am considering moving builddmaster.py out of c.l.scripts. how about a canonical.builddmaster ?
[03:59] <kiko> cprov, malcc: with pas.py, buildergroup.py and master.py in it?
[03:59] <cprov> kiko: sounds good
[04:00] <cprov> kiko: anything in direction to have less the 1K lines files is good at this point
[04:00] <malcc> kiko: Hmm, I agree c.l.scripts is the wrong place, but I'm not sure about the new location
[04:00] <kiko> cprov, so who uses builddmaster.py at the moment?
[04:00] <kiko> malcc, I'm fine with putting it elsewhere.. if you have a suggestion. :)
[04:00] <cprov> kiko: cronscripts/buildd-{queuebuilder, slavescanner}
[04:01] <kiko> cprov, thanks.
[04:01] <cprov> carlos: ping
[04:03] <carlos> cprov: pong
[04:03] <kiko> malcc, are you suggesting it should be a subdir under archivepublisher?
[04:03] <cprov> carlos: how long will take the lang-pkg process in mawson ? any idea ?
[04:04] <malcc> kiko: What I want to suggest is that we need to work out what these folder distinctions are supposed to mean and come up with a clear design for where stuff goes
[04:04] <cprov> kiko: no, please archivepublisher need to die ... it will end up with diskpool only in a short time.
[04:04] <malcc> cprov: It will?
[04:05] <carlos> cprov: one or two hours more
[04:05] <kiko> malcc, okay, agreed, but the build master seems to be a pretty significant module in soyuz?
[04:05] <carlos> cprov: but It's not using mawson's db
[04:05] <malcc> kiko: Yes it is, it's one of the big three, along with upload handling and publishing
[04:05] <cprov> carlos: yes, I know, only consuming CPU :P
[04:05] <salgado> malcc, I just noticed that the diff of your xx-farming branch is now twice the size of what it was when I reviewed it.  it seems to me that this was caused by a conflict; can you confirm that?
[04:05] <carlos> cprov: is it too expensive?
[04:06] <kiko> malcc, okay. does that not warrant a directory of its own?
[04:06] <carlos> cprov: then it's generating a tarball, it should finish soon
[04:06] <cprov> malcc: I think so, don't you ? after PipelinePublishing most of publicaion system will end up in content classes 
[04:06] <malcc> kiko: Maybe we should have three folders for those components, but maybe they all need to be inside a top-level folder for the general not-launchpad-pages parts of Soyuz
[04:07] <malcc> kiko: Any of these *might* be sensible designs, my point is just that it's hard to tell in a hurry, so perhaps the files shouldn't be moved to a new module in a hurry
[04:07] <cprov> carlos: not that much, but would be nice if we can coordinate run times in advance, how does it sound to you ? 
[04:07] <kiko> malcc, I think that reorganization can easily be done later, but the hard work of splitting things up and ensuring they still work could be done now.
[04:07] <kiko> malcc, i.e. I've already done it
[04:08] <malcc> salgado: Yes, there's a 500-line conflict in publishing.py doubling the patch size
[04:08] <carlos> cprov: sure, I execute it every day
[04:08] <carlos> cprov: at 8:30 UTC
[04:08] <kiko> malcc, moving stuff between directories is easy, but breaking up files is not so
[04:08] <carlos> cprov: but it takes a lot of time to complete, as it's for Hoary, Breezy, Dapper and Edgy....
[04:09] <cprov> carlos: right, thx.
[04:10] <carlos> cprov: I think I can execute it earlier 
[04:11] <carlos> but I have staging's database mirroring as the constraint, my script cannot be executed until that task is done
[04:12] <cprov> carlos: no much helpful, we may run tests on soyuz which can take hours, not easy to organise, it's fine we can just avoid running heavy things 8:30 UTC + 6 hours (wow)
[04:13] <carlos> cprov: 4 language packs exports .... you know...
[04:14] <carlos> anyway, we need to improve its performance
[04:14] <carlos> cprov: also, it's not too CPU intensive except when the tarball is being generated
[04:14] <carlos> well, it's not too CPU intensive in mawson
[04:15] <kiko> I/O intensive praps?
[04:15] <cprov> carlos: uhm ... any chance to have a rosetta machine ;)
[04:15] <kiko> heh
[04:16] <malcc> Gentlemen, let's wait and see if we have performance problems for real first, before we draw up battle lines over hardware :)
[04:17] <cprov> malcc: aha, good point ...
[04:17] <kiko> malcc, it's also a matter of having autonomy on the box. I've seen a lot of friction in this type of interaction in other situations..
[04:17] <kiko> so my wisdom says that separating into dedicated hardware makes the process more efficient
[04:17] <malcc> kiko: Autonomy, the over-specced search engine system? We definitely don't want *that* on the box, we *will* have performance problems :)
[04:17] <kiko> anyway.. back to code
[04:19] <teolemon> hi
[04:30] <ddaa> help, I'm under attack by a crazy cuddly kitten!!!
[04:31] <carlos> sorry, my dsl line went down
[05:18] <danilos> ddaa: (re cat) you deserve everything you get! ha!
[05:19] <ddaa> anyway, kittens are perfectly evolved for ballistic flight between the desk and the bed :)
[05:22] <LarstiQ> heh
[05:28] <sivang> you are working on forbidden grounds, ddaa :p
[05:29] <sivang> the bad thing about them, is they can take up some beating, and then suddenly, out of the blue, they start to talk back.
[05:29] <sivang> and when that happens, you better not be around them :)
[05:30] <ddaa> Sure, I'd rather not give a cat beating. It's just a matter of teaching them _too_ that when I'm at the computer I'm working and not to be disturbed :)
[05:32] <ddaa> Somehow, I think felines are more apt to understanding than some humans...
[05:32] <sivang> ddaa: I never said I beat them, I try my best to just stay away from them. I just spotted some kid that the cat taught enough is enough :)
[05:32] <sivang> Wikitexte_editieren => da schein schon dran gearbeitet worden sein, wie ich an dem von dir genannten Beitrag gesehen habe Smilie super!
[05:32] <sivang> Bueroprogramme => bersichtsseite zu "Broroutinearbeit" mit Ubuntu (v.a. fr Einsteiger und Windows-Umsteiger) und Kategorie
[05:32] <sivang> Podcast => hnlich der Audioplayer eine Programmbersichtsseite
[05:32] <sivang> Backup_Uebersicht => bersicht ber Backup-Methoden (in Edgy kommt noch das programm hubackup dazu, dazu evtl. eine Skriptsammlung
[05:33] <sivang> Synchronisationsmethoden => mglicher Fall: man hat einen Rechner und einen Laptop und mchte diese Sychron halten. Punkte: rsych-Link, drsynch, Unision, iFolder, WebDAV, Skriptsammlung Wikitexte_editieren => da schein schon dran gearbeitet worden sein, wie ich an dem von dir genannten Beitrag gesehen habe Smilie super!
[05:33] <sivang> Bueroprogramme => bersichtsseite zu "Broroutinearbeit" mit Ubuntu (v.a. fr Einsteiger und Windows-Umsteiger) und Kategorie
[05:33] <sivang> Podcast => hnlich der Audioplayer eine Programmbersichtsseite
[05:33] <sivang> Backup_Uebersicht => bersicht ber Backup-Methoden (in Edgy kommt noch das programm hubackup dazu, dazu evtl. eine Skriptsammlung
[05:33] <LarstiQ> sivang: oi!
[05:33] <sivang> hrm
[05:33] <sivang> SORRY, I guess I need my thinkpad kbd replaced..already.
[05:33] <ddaa> sivang: dogs are not really an option in a 35m2 flat in Paris...
[05:34] <sivang> ddaa: I agree, I think they're cool, but should be only kept in a garden. My folks have a dog inhouse, it's bad with all the hair falling and the dog just loosing shape.
[05:34] <sivang> I mean, kept mostly outdoors.
[05:34] <sivang> LarstiQ: sorry :-(
[05:35] <ddaa> Well, it depends on the sort of dog. Some small dogs are fine as long have you have a moderately spacious appartment.
[05:35] <Ubugtu> New bug: #58220 in launchpad "When an error occurs processing a request another oops is recorded because there's no interaction set up." [Low,Confirmed]  http://launchpad.net/bugs/58220
[05:36] <sivang> that one is a boxer breeed with a cocker spinal, not the ideal type for indoors.
[05:36] <sivang> s/breed/mixed/
[05:36] <ddaa> and we had to use our nail clippings for heating
[05:37] <sivang> ddaa: sersiously? (this is getting offtopic)
[05:37] <bradb> haha
[05:38] <ddaa> sivang: http://www.serve.com/bonzai/monty/classics/TheWeAreSoPoorSketch
[05:38] <ddaa> sivang: http://geekz.co.uk/lovesraymond/archive/in-my-day
[05:44] <kiko> malcc, cprov-lunch: okay, finished handling cprov's review of the build master fixes, did some refactoring and now waiting for malcc's input.
[05:45] <Ubugtu> New bug: #58222 in launchpad-cal "Broken traversal in calendar events" [Low,Confirmed]  http://launchpad.net/bugs/58222
[05:50] <Ubugtu> New bug: #58223 in rosetta "Reject backports pocket's translations" [High,Confirmed]  http://launchpad.net/bugs/58223
[05:54] <malcc> kiko: My feedback sent
[05:54] <kiko> malcc! the man!!
[05:59] <kiko> malcc, cprov-lunch: with those fixes, can I land this branch?
[05:59] <malcc> kiko: Yes from me
[06:00] <kiko> malcc, thanks. looking forward to seeing this branch in testing, will be fun to catch all the flying sparks <wink>
[06:00] <malcc> kiko: Compared to all the changes last week, I don't expect this branch to be the rock star of our system test, I suspect it will just quietly work
[06:00] <kiko> malcc, well, I hope so too, but it will be nice to see us produce less unnecessary builds.
[06:01] <kiko> malcc, of course, I still need to sort out binary PAS -- or better, what to do about it.
[06:01] <kiko-fud> let me go for lunch and will bbl
[06:01] <jamesh> kiko-fud: all those preferred wordings mix first person with second person, which is pretty confusing.
[06:01] <kiko-fud> jamesh, "I'd like to claim"?
[06:01] <kiko-fud> jamesh, though I don't know if it's that confusing -- in avoiding the "Click here" text it often happens on the web, doesn't it?
[06:01] <jamesh> kiko-fud: I mean mixing "I" with "you" or "your"
[06:02] <kiko-fud> hmmm. is it really that confusing?
[06:02] <kiko-fud> anyway those were suggestions, I just found "This is me" to be totally weird.
[06:02] <jamesh> it would be better if it was all first person or all second person
[06:02] <malcc> I am this person (merge him into *my* account) etc. seem more clear
[06:03] <kiko-fud> malcc++
[06:03] <kiko-fud> good suggestion
[06:03] <kiko-fud> jamesh, so if you think it's an improvement.. 
[06:03] <malcc> kiko-fud: Not mine, I'm just explaining what jamesh was on about :)
[06:04] <jamesh> kiko-fud: I'll talk with mpt about it tomorrow
[06:04] <kiko-fud> malcc, now now no need to try and undeserve credit
[06:04] <kiko-fud> jamesh, cool
[06:05] <jamesh> We also need text for the case where the user isn't logged in
[06:05] <jamesh> (in which case the link goes to the forgotten password page)
[06:06] <kiko-fud> mmm
[06:07] <flacoste> jamesh: do you have a moment to discuss the validation problem with LaunchpadFormView?
[06:07] <jamesh> flacoste: a short moment.  I was planning on going to sleep soon
[06:07] <flacoste> jamesh: ok, I'll be brief
[06:08] <flacoste> jamesh: I updated the TicketAddView to use LaunchpadFormView (after adding support for action handlers returning the rendered page)
[06:08] <flacoste> jamesh: that went fine
[06:09] <flacoste> jamesh: after that I even tried using a custom schema which didn't required the description to try to use only one validate method
[06:09] <flacoste> jamesh: since that made the use of custom error messages cleaner
[06:10] <flacoste> jamesh: the problem I have is that even with description not required, i get a validation error: FormError: ('No input', 'description')
[06:11] <jamesh> flacoste: what do you think of Steve's idea of splitting the workflow into two forms though:
[06:11] <flacoste> jamesh: i answered that and it doesn't work
[06:11] <jamesh> the first being a action="get" form that directs to the second URL
[06:12] <flacoste> jamesh: I tried that and it doesn't simplify things a bit, in fact, it just makes it more complicated
[06:12] <jamesh> the second URL uses the title to display the natural language ticket search results and has a self-posting form for adding the ticket
[06:12] <flacoste> jamesh: yeah, the problem is that you still need the title validation in both views
[06:13] <LarstiQ> is launchpad achingly slow for anyone else?
[06:14] <flacoste> jamesh: and in the second view case, there isn't any validation hook for the first display
[06:14] <jamesh> how much validation needs to be done on the title before it can be used for the ticket search?
[06:15] <flacoste> just testing that it is non-empty
[06:15] <flacoste> (the problem is hooking the validation in the machinery)
[06:15] <jamesh> okay.
[06:16] <jamesh> I suppose that could be done with two self-posting forms, the first of which passes the title on to the second in the query string
[06:16] <jamesh> I mean redirects to the second
[06:16] <flacoste> well, that was the original idea, and you still need to validate that a title was posted in the query string and redirect to the first one when missing
[06:17] <flacoste> trust me, one view for the whole process is the simplest thing to do and with the current code it is also very simple
[06:18] <flacoste> anyway, i think you can go to sleep, i'll fix my FormError by using an empty hidden widget and you'll have the result in your INBOX tomorrow morning for review :-)
[06:19] <jamesh> flacoste: okay.  To get round the missing widget problem, you could try overriding setUpWidgets() to trim description from the form in the case where the widget wasn't shown.
[06:20] <flacoste> jamesh: right, that is another alternative... thanks, I'll see what is simpler
[06:20] <jamesh> if the formlib code doesn't know about the description widget then it can't error out on missing input
[06:20] <bradb> man, i ate 540 bugmails this morning and now i'm hungry
[06:20] <flacoste> jamesh: actually, I think i'll override setUpFields
[06:21] <jamesh> flacoste: okay.  I did something like that in BranchEditView
[06:22] <flacoste> jamesh: thanks a lot for this discussion, have nice dreams!
[06:22] <jamesh> night.
[06:32] <jonlandrum> I need help setting up an account. I've tried three times, but each time I go to log in I'm told the email address and password don't match. When I tried to recover the password I was told there is no information on that email address.
[06:46] <carlos> jonlandrum: hi, from what you wrote, seems like the email address you are using is not registered in our system...
[06:47] <jonlandrum> Thanks, Carlos. What did I do wrong?
[06:47] <carlos> jonlandrum: well, first of all, from where did you get that login information?
[06:47] <jonlandrum> I've tried the whole process from scratch a number of times; it seems kind of dummy-proof, but I keep having problems.
[06:48] <jonlandrum> I registered.
[06:48] <jonlandrum> ...so I thought.
[06:48] <carlos> did you got an email to confirm your account?
[06:48] <jonlandrum> Yes, and followed the link supplied.
[06:49] <carlos> hmm, could you give me the email address where do you got the confirmation email?
[06:49] <jonlandrum> jonlandrum@gmail.com
[06:50] <jonlandrum> Just tried it with Opera and got a 500 message.
[06:51] <carlos> hmm, I see your account created
[06:51] <carlos> https://launchpad.net/people/jonlandrum
[06:51] <salgado> jonlandrum, have you tried entering your email address at https://launchpad.net/+forgottenpassword and submitting the form?
[06:53] <jonlandrum> Yes, and the message I got was the email address didn't exist in the database.
[06:53] <carlos> jonlandrum: I just did it for you
[06:53] <carlos> and I didn't get such error...
[06:53] <jonlandrum> Just noticed that I'm all-of-the-sudden logged in. When I tried the process this time I got a yellow box saying the email address had already been confirmed.
[06:54] <jonlandrum> Perhaps Apache was flooded or something.
[06:55] <jonlandrum> Thank you, carlos and salgado. I appreciate your help.
[06:55] <carlos> You are welcome
[06:55] <carlos> enjoy your account ;-)
[06:56] <salgado> jonlandrum, you're welcome!
[06:56] <jonlandrum> I will! You guys have a great day.
[07:20] <kiko> ahoy there
[07:20] <kiko> cprov, r=cprov for that landing?
[07:21] <cprov> kiko: yes (I thought r=cprov doesn't count anything, though)
[07:22] <kiko> cprov, thanks. kinda unfortunate the filechunks thing in nascentupload.py, eh?
[07:22] <cprov> kiko: btw, please join ##soyuz, we need your help.
[07:22] <cprov> kiko: yup
[09:06] <kiko> is launchpad responing to your requests?
[09:06] <kiko> timing out for me..
[09:06] <kiko> but connectivity is fine.
[09:06] <kiko> odd.
[09:07] <kiko> matsubara, salgado?
[09:08] <matsubara> kiko: last time I tried it worked
[09:08] <matsubara> kiko: but now it's not working anymore
[09:09] <kiko> same here
[09:12] <jdub> launchpad down?
[09:13] <kiko> something weird's going on there
[09:13] <kiko> somebody's looking into it (ps auxww tells me)
[09:13] <jdub> thanks
[09:13] <bradb> it's slow as teeth over here too
[09:14] <jordi> sounds great when you can say this -- i'm up to date on activity reports again
[09:35] <Ubugtu> New bug: #58246 in malone "The textarea's for bug descriptions/comments should use a fixed-width font" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58246
[09:36] <kiko> doesn't it?
[09:36] <kiko> oh, it doesn't. mmm.
[09:36] <Seveas> Why is there a delay between bzr push to bazaar and the changes actually appearing?
[09:45] <jelmer> Seveas: AFAIK to make sure the launchpad bazaar isn't used for generic hosting but only for bzr branches
[09:46] <Seveas> jelmer, ah ok
[09:46] <Seveas> as long as it's intended I don't need to file a bug ;)
[09:54] <flacoste> salgado: ping
[09:54] <salgado> flacoste, pong
[09:55] <flacoste> i have a problem merging my tt-buglinktarget
[09:55] <salgado> as in, a test failure?
[09:55] <flacoste> no a conflict
[09:55] <flacoste> i merged RF in my branch and everything is fine but there is a conflict merging to RF:
[09:55] <flacoste> bzr: WARNING: Conflict adding file lib/canonical/launchpad/templates/cve-portlet-bugs.pt.  Moved existing file to lib/canonical/launchpad/templates/cve-portlet-bugs.pt.moved.
[09:56] <Ubugtu> New bug: #58250 in launchpad "Unofficial distribution releases should not be allowed to use milestones" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58250
[09:56] <flacoste> this happen because I removed the file in my tree and decided later on to add it back
[09:56] <flacoste> any idea how should I resolve that?
[09:57] <salgado> and I guess somebody else touched this file in the meantime?
[09:58] <salgado> flacoste, I don't know how to woraround that.  I'd suggest asking on #bzr
[09:58] <salgado> but maybe ddaa can help you here
[09:58] <flacoste> will do, thanks
[09:59] <kiko> flacoste, wait up
[09:59] <kiko> flacoste, hmmm. you can uncommit 
[09:59] <kiko> until the file is readded
[09:59] <kiko> I had the same problem a while back
[09:59] <kiko> the trick is to uncommit the revisions you did that
[09:59] <flacoste> aargh, i would have to uncommit ~30 revisions
[09:59] <kiko> and then commit the final fix
[10:00] <kiko> can't you just uncommit those single changes?
[10:02] <flacoste> kiko: maybe... i'm getting help on #bzr now, I will report back
[10:14] <flacoste> kiko: bzr uncommit -r revno while uncommit all commits until that revision
[10:14] <kiko> I see.
[10:17] <BjornT> flacoste: there might be an easier solution, but you should be able to do this. create a new branch, branching from the revision before you deleted the file. then you merge in the rest of the old branch, reverting the file deletion before commiting.
[10:17] <BjornT> i'm not sure it will actually work, though.
[10:18] <flacoste> BjornT: actually, i though about something similar: create a new branch from RF, merge and reconcile my branch and try to merge that into RF
[10:19] <BjornT> flacoste: right, that should work as well.
[10:19] <flacoste> and the commit log will be preserved
[10:25] <flacoste> aargh, that didn't work I now have two conflits!!!
[10:29] <teolemon> jordi, would it be possible to ok the clamwin .po files ?
[10:31] <zyga> can anyone help me with https://wiki.ubuntu.com/PlanetUbuntu
[10:31] <zyga> my key is rejected and I got no idea why, it's been in lp for ages and I'm a member for just as long
[10:32] <teolemon> are you an ubuntero ?
[10:32] <teolemon> i think you need to be one to be able to be included on the planet
[10:32] <zyga> if that's an ubuntu member then yes
[10:33] <zyga> I'm listed in https://launchpad.net/people/ubuntumembers
[10:34] <teolemon> what's your pseudonym ?
[10:34] <zyga> zyga
[10:34] <zyga> :-)
[10:34] <zyga> my name is ZygmuntKrynicki
[10:35] <teolemon> yes that's ok on this part
[10:35] <salgado> BjornT, do you know if we run (or plan to run) cronscripts/update-debwatches.py or launchpad/scripts/debsync.py?
[10:37] <teolemon> zyga: i can't say for sure what it might be all about
[10:38] <zyga> bah, I got it\
[10:38] <salgado> BjornT, I'm asking because MessageSet.fromEmail() has a create_missing_persons argument that is only used there, and the fact that it may create new accounts kind of fucks me over
[10:38] <zyga> I use zyga as my nickname but zkrynicki as my launchpad id
[10:38] <zyga> I'll update the wiki to be more explicit about that
[10:42] <BjornT> salgado: we certainly don't run them. and i don't think we'll run them in the future either. basically, what's useful in there should be moved to the bugwatch code.
[10:44] <BjornT> salgado: if we do start pulling in comments (or assignee) from remote bugs, though, we'll need a way of representing the owner in the db.
[10:55] <flacoste> how can I list the files added/removed/modified by a given revision?
[10:55] <ddaa> http://ddaa.net/cats/
[11:15] <flacoste> i worked around bug 58257 by renaming the file in my tree, I'll rename it to the original name in a trivial landing afterwards
[11:15] <Ubugtu> Malone bug 58257 in bzr "Spurious conflicts when removing and adding back a file." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58257
[11:25] <jprieur> hi there
[11:26] <jprieur> Is it possible to drop bzr branches? Because I've locally done a bzr init and I would put that instead of the old one.
[11:27] <lifeless> do a bzr push --overwrite
[11:27] <ddaa> not yet, there's a bug open on that, but you you can push --overwrite
[11:28] <jprieur> it doesn't work
[11:28] <jprieur> wait, i get the error message
[11:28] <jprieur> johann@pc-rbs1101:~/projects/cocoon$ bzr push --overwrite http://bazaar.launchpad.net/~jprieur/cocoon/cocoon
[11:28] <jprieur> bzr: ERROR: Cannot lock: transport is read only: <bzrlib.transport.http._pycurl.PyCurlTransport url=http://bazaar.launchpad.net/~jprieur/cocoon/cocoon/.bzr/branch/>
[11:28] <ddaa> hu
[11:29] <ddaa> lifeless: can you handle that, I have to leave for the night now
[11:29] <ddaa> jprieur: I do not really understand what you want to do
[11:29] <jprieur> this morning, I set a branch, ok?
[11:30] <ddaa> is the branch you are talking about hosted on Launchpad (via SFTP) or is it an external branch?
[11:30] <jprieur> hosted on launchpad
[11:30] <LarstiQ> jprieur: you can't push to an http branch
[11:30] <ddaa> then why not push to the sftp url?
[11:30] <LarstiQ> jprieur: so try bzr push --overwrite sftp://bazaar.launchpad.net/~jprieur/cocoon/cocoon instead
[11:30] <LarstiQ> (and launchpad will mirror it over to http://)
[11:31] <jprieur> thanks a lot
[11:32] <jprieur> I didn't realized that
[11:32] <kiko> LarstiQ, is that bug finally fixed?!
[11:32] <ddaa> kiko: there never was a bug preventing that as far as I remember
[11:33] <ddaa> and AFAIK, when the existing sftp url is not a bzr branch, you are still screwed
[11:33] <kiko> oh.
[11:34] <LarstiQ> kiko: the bug I have in mind, no, I suck. But that isn't relevant for jprieur?
[11:34] <kiko> LarstiQ, yeah, I realize now. I guess I was reminded of it though.
[11:35] <LarstiQ> kiko: I have a branch that sort of helps, but I'm deeper in than I had hoped
[11:35] <LarstiQ> kiko: not being able to delete branches on launchpad makes it harder
[11:38] <ddaa> LarstiQ: I raised the importance of that bug to Hard just today.
[11:39] <LarstiQ> ddaa: the launchpad-bazaar one I guess, since I'm not seeing any bugmail on it?
[11:39] <ddaa> LarstiQ: https://launchpad.net/products/launchpad-bazaar/+bug/34540
[11:39] <Ubugtu> Malone bug 34540 in launchpad-bazaar "cannot delete a branch" [High,Confirmed]  
[11:39] <LarstiQ> ah yes
[11:40] <LarstiQ> ddaa: High importance you mean?
[11:40] <ddaa> Yeah, sorry
[11:40] <ddaa> it's not Hard, actually
[11:40] <LarstiQ> just a long story?
[11:41] <ddaa> nope, should be pretty easy to get the user-visible result
[11:42] <ddaa> I'll try to push that as the next UI improvement. But, as usual, there are a lot of tasks competing for little hands :(
[11:45] <LarstiQ> wasn't there extra help coming in?
[11:46] <kiko> there is supposed to be.
[11:46] <ddaa> yeah, but I'm concerned that extra traction is not going to be applied on fixing existing problems, but creating some new features the company cares about
[11:46] <kiko> ddaa, well, a-bit-o-both.
[11:48] <ddaa> if jamesh and spiv are to be relieved of some of their launchpad-bazaar work (which I understand would be useful because they also have a lot of infrastructure work to do), and some large new things like private branches are started, I do not expect to get a net increase in traction on the existing features
[11:49] <ddaa> Which I understand makes sense from a company development perspective, but is a bit disappointing for me.
[11:50] <ddaa> anyway, we'll see how it goes
[11:50] <ddaa> but I do not want to promise that things are going to be fixed faster
[11:57] <ddaa> Good night
[11:57] <sivang> night ddaa 
[11:58] <LarstiQ> hmm, I doubt the problem is lack of interested coders?