/srv/irclogs.ubuntu.com/2006/05/23/#launchpad.txt

ddaa	lifeless: does svn_oo support the svn equivalent of module configs?	12:04
Keybuk	kikoX: obviously the biggest problem for us is that it means bugs are getting assigned to packages that should not exist, so there's nobody who's bug contact for them, or even looking for them	12:06
lifeless	externals ? dont know	12:06
Keybuk	so I've been going down the list of packages and trying to look for "bugs on binaries" too	12:06
Keybuk	so will see if I find any more examples that prove or disprove that syncs aren't doing it	12:06
ddaa	carlos: can you file a bug about that, provided I can stay focused on importd long enough, I will come around to in the medium term	12:07
ddaa	(a few months) unless somebody contributes code after we release cscvs	12:07
kikoX	Keybuk yeah. this needs to be fixed ASAP	12:07
kikoX	cprov is on it	12:07
carlos	ddaa: ok, will do	12:08
carlos	ddaa: thanks for looking into it	12:08
=== ddaa -> bed
=== SnkBite [n=SnkBite@212.25.63.35] has joined #launchpad
kiko	salgado, what's the RT number?	12:15
salgado	kiko, 9143	12:16
kiko	thanks salgado	12:16
kiko	hey Znarl	12:16
Znarl	Hello	12:16
kiko	sorry to bump you this late	12:17
salgado	yeah, sorry for the short notice	12:17
kiko	Znarl, salgado filed RT 9143	12:17
salgado	it's all my fault	12:17
Znarl	It's fine. How can I help?	12:17
lifeless	hi znarl. thanks	12:17
kiko	but basically we need to ensure lifeless and you synchronize on flicking the switch for the shipit apache redirect setup	12:17
kiko	it's only really a problem for shipit.ubuntu	12:18
Znarl	RT#9143.	12:18
Znarl	ok.	12:18
kiko	lifeless, Znarl: perhaps #canonical-meeting?	12:18
kiko	Znarl, it's important that it be done more or less in sync with lifeless or else the redirect will break until the rollout happens.	12:18
Znarl	Sure.	12:18
kiko	salgado, I'll let you handle things on #canonical-meeting :)	12:20
Yannig	Hum, problem with the server :(	12:21
Yannig	OperationalError	12:21
Yannig	A server error occurred.	12:21
kiko	Yannig, oops id?	12:21
Keybuk	OperationalError	12:22
Keybuk	A server error occurred.	12:22
Keybuk	heh	12:22
Keybuk	ok, somebody beat me	12:22
Keybuk	kiko: no oops, just "BOOM"	12:22
kiko	Keybuk, Yannig: the system is being upgraded, hold on for some turbulence	12:23
Keybuk	kiko: it told me 14 minutes not more than 3 minutes ago :p	12:23
kiko	apparently lifeless is not wasting a minute	12:23
lifeless	Keybuk: sorry, it lied to you	12:27
kiko	we normally have a launchpad is down page	12:27
kiko	for some reason it's down too	12:27
carlos	kiko, lifeless: are you doing the rollout?	12:28
kiko	yep	12:28
carlos	I didn't finished with mark's branch merge...	12:30
kiko	carlos, too late now :)	12:30
carlos	I guess..	12:31
carlos	anyway, I'm going to merge it tonight as I told SteveA...	12:31
carlos	kiko: about https://launchpad.net/bugs/45164	12:31
carlos	kiko: mpt told me that we should not add the navigation links to the bottom of the translation form, because people would click on 'Next' instead of submit translations and that would make them lose their translations	12:32
carlos	there is already a rejected bug about it	12:32
kiko	I see. then dupe it.	12:32
carlos	ok	12:33
Yannig	The "launchpad is down" page is up :)	12:34
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
Yannig	Any idea when it should be back? Nothing hurrying but I was about to download po file and I'll have to go to bed reasonably early :)	12:48
lifeless	10 minutes	12:49
Yannig	Thanks :)	12:49
=== ploum [n=ploum@ubuntu/member/ploum] has left #launchpad ["Ex-Chat"]
lifeless	web ui is back	01:07
carlos	lifeless: hi, why does my pqm request say: "Request for non-PQM managed branch" at http://pqm.launchpad.net/ ?	01:17
salgado	carlos, are you using a bzr repo and the pqm-submit plugin?	01:18
carlos	no, I'm using a wave bzr repository and the old bzr-submit-merge script	01:19
carlos	it worked this morning	01:19
carlos	after the knit migration	01:20
salgado	odd	01:21
lifeless	I encourage you to switch to pqm-submit	01:22
salgado	lifeless, is there a workaround for bug 45306?	01:23
Ubugtu	Malone bug 45306 in bzr "LocationConfig should look for options on parent locations when they're not found" [Normal,Unconfirmed] http://launchpad.net/bugs/45306	01:23
salgado	I think that's going to be a problem for people using pqm-submit and not manually rsyncing their branches up	01:24
lifeless	salgado: yeah, we should change that	01:25
=== kbrooks [n=kbrooks@unaffiliated/kbrooks] has joined #launchpad
lifeless	I think the workaround is 'write the code'	01:25
kbrooks	is the shipit code proprietary?	01:25
=== cprov [n=cprov@201-68-2-63.dsl.telesp.net.br] has joined #launchpad
carlos	lifeless: is it included with bzrtools?	01:26
lifeless	SteveA: around ?	01:26
lifeless	carlos: no, I think that james's repository use page documents how to get it	01:27
salgado	gotta go now. be back in a few minutes	01:27
carlos	ok	01:27
kbrooks	is the shipit code proprietary?	01:27
kbrooks	is the shipit code proprietary?	01:28
=== kbrooks waits
=== kbrooks prepares for the stuff.
carlos	kbrooks: yes, it is	01:29
kbrooks	carlos: why?	01:29
mpt	Gooooooooooooooooooooooooood morning Launchpadders!	01:29
kbrooks	hmm, i have a bug?	01:30
carlos	kbrooks: https://launchpad.net/faq <- Please, look at "Is Launchpad open source? Will it be?"	01:30
carlos	mpt: morning	01:30
=== Yannig [n=LokaUsr@AToulouse-254-1-24-55.w81-250.abo.wanadoo.fr] has joined #launchpad
carlos	lifeless: pqm-submit seems like fixed the issue, but the old request is stalled or at least, looks stalled	01:39
carlos	anyway... it's too late already here... and I missed the production update..	01:40
kbrooks	um, i have a bug, carlos	01:40
carlos	I will continue tomorrow	01:40
carlos	kbrooks: where?	01:40
kbrooks	"3 CDs requested in 2006-01-01. 3 CDs approved and sent to the shipping company in 2006-01-03."	01:41
kbrooks	but I DID NOT request there cds on january 1, 2006	01:41
kbrooks	three*	01:41
carlos	kbrooks: please, file a but about it at https://launchpad.net/products/shipit/+bugs	01:42
kbrooks	OK.	01:42
carlos	kbrooks: thanks	01:42
=== carlos -> bed
carlos	good night!	01:42
=== alexandros_se [i=ctrl@2-1-1-18a.spa.sth.bostream.se] has joined #launchpad
=== salgado [n=salgado@201-1-130-8.dsl.telesp.net.br] has joined #launchpad
=== mpt_ [n=mpt@203.109.220.214] has joined #launchpad
=== stub [n=stub@ppp-58.8.2.77.revip2.asianet.co.th] has joined #launchpad
=== stub [n=stub@ppp-58.8.2.77.revip2.asianet.co.th] has joined #launchpad
stub	lifeless: was jubany acting up?	03:12
stub	ahhh - would have been the shipit rollout	03:13
lifeless	stub: I found the rollout instructions a little ... sparse.	03:14
lifeless	i.e. no db backup in there	03:14
lifeless	nor info on bouncing librarian/authserver etc.	03:14
lifeless	I've added some info and some nicer ways of doing things	03:15
stub	yup. db backup takes over an hour, so we need to rely on dailys now (and pitr when set up)	03:15
stub	well... cloneing the db would be faster, but still too slow	03:15
lifeless	well, we downed it and just copied the pg dir, took about 15 minutes	03:15
elmo	rsync it before and after should be faster tan 15 minutes	03:16
lifeless	elmo: sure. we were adhocing it - I woke up to a 'please rollout and stub is sick' email	03:17
stub	ahh good - you found push.py (work in progress but useful)	03:17
lifeless	stub: :)	03:17
lifeless	stub: the notes I have on the rollout page may be useful for commands push could run	03:17
stub	yup	03:17
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
Keybuk	kiko: those dups are still definitely getting created by the uploader	03:27
Keybuk	s/dups/strange sources/	03:27
Keybuk	a package that just added new binaries created them	03:27
Keybuk	I had a thought though	03:27
Keybuk	could this be a result of overrides?	03:27
=== mpt_ [n=mpt@203.109.220.214] has joined #launchpad
lifeless	popping out for a bit	03:53
salgado	lifeless: is pqm still disabled?	03:54
mpt_	"-537 revision(s) pulled."	03:56
mpt_	heh	03:56
=== stub wanders off to hospital
mpt_	!	04:03
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad
jamesh	mpt_: your branch history was canonicalised	04:23
jamesh	mpt_: leading to a shorter revision history	04:23
mpt_	uh oh	04:23
mpt_	I just finished all the steps on RocketfuelToKnits	04:24
mpt_	And now I've merged rocketfuel into MaloneSimplifications	04:24
mpt_	and got a conflict	04:24
mpt_	and the conflict's MERGE-SOURCE is something that's from neither rocketfuel nor MaloneSimplifications	04:25
mpt_	it's from a separate branch	04:25
mpt_	spiv?	04:26
mpt_	Yes, now MaloneSimplifications branch is full of code from the other branch	04:27
mpt_	Is there a missing step 6 in those instructions?	04:27
mpt_	jamesh: any ideas?	04:48
jamesh	mpt_: what commands did you run exactly?	04:49
mpt_	Exactly the commands given on RocketfuelToKnits	04:50
mpt_	and then	04:50
jamesh	so what command produced the "-537 revision(s) pulled." message?	04:50
mpt_	2006-03-MaloneSimplifications> bzr merge ../rocketfuel/	04:50
mpt_	The -537 was a long time beforehand	04:51
jamesh	if it was from the "bzr pull --overwrite" command, then that might be expected	04:51
mpt_	sure, you explained that	04:51
mpt_	I don't think it's related to my problem at all.	04:52
jamesh	it basically reports (# of revisions now - # revisions before)	04:52
jamesh	so bzr picked a weird merge base	04:52
mpt_	My problem is that my copy of rocketfuel now contains stuff from one of my branches.	04:52
jamesh	okay.	04:53
mpt_	Which doesn't really surprise me, since I used "bzr pull --overwrite" from the branches into rocketfuel	04:53
jamesh	when you were upgrading your branches, did you do the "bzr pull --overwrite" stuff onto a copy of rocketfuel-built, or the main copy you use?	04:54
mpt_	but when I asked about that yesterday, spiv and lifeless said it was fine	04:54
dilys	Merge to devel/launchpad/: [r=bjornt] Fix bug #36420 (archive-cruft-check redesigned, old script kept for tests), fix bug #41600 (buildd-sequencer crashes, add socket_timeout config option), fix SPR.getBuildByArch() (using selectFirst properly), merge elmo's sync-source fixes. (r3568: Celso Providelo)	04:54
Ubugtu	Malone bug 36420 in qprocd "archive-cruft-check broken" [Critical,In progress] http://launchpad.net/bugs/36420	04:54
mpt_	jamesh: I don't understand that distinction	04:54
mpt_	I keep one copy of rocketfuel-built to merge from. I don't change it directly.	04:54
jamesh	mpt_: when you do "bzr pull --overwrite foo", you are overwriting the branch history of the current branch with the history of "foo"	04:55
jamesh	so you'd be modifying rocketfuel-built	04:55
mpt_	I know	04:55
mpt_	that's why step 2 seems so strange	04:55
jamesh	if you've done all the upgrades, just rsync down rocketfuel-built again to get it back to normal	04:56
jamesh	step 2 says "Pull your branch into your rocketfuel-built (or a copy of it),"	04:56
mpt_	yep	04:57
mpt_	and when I went through this yesterday, I pointed out that this would mean that the second branch I did would end up with the history of the first and second branches	04:57
mpt_	and that the third branch I did would end up with the history of the first, second, and third branches, and so on	04:58
mpt_	and that that seemed strange	04:58
jamesh	there are two concepts of "history" here	04:58
mpt_	so was it wrong after all?	04:58
jamesh	see this picture: http://blogs.gnome.org/attachment/jamesh/2006/04/23/0/bzr-repo.png	04:58
jamesh	think of each of the nodes in the graph as a particular state of your source tree	04:58
jamesh	the blue line indicates the line of development you've taken in your branch	04:59
jamesh	and the collection of all the nodes includes stuff you've merged	05:00
jamesh	so with the instructions on the RocketfuelToKnits page, the last branch will contain the history of the other branches in the sense that those nodes will be in the branch's internal repository	05:00
jamesh	but it won't contain the history of those branches in the sense of the blue line indicating the line of development for the branch	05:01
mpt_	ok	05:01
jamesh	does that make things clearer or less clear?	05:01
jamesh	:)	05:01
mpt_	so the other branches now have records of the changes, but not the changes themselves	05:01
jamesh	the changes of your other branches wouldn't be in the linear branch history, no.	05:02
jamesh	the reason for the complicated steps on the RocketfuelToKnits page is that converting weave data to knits is expensive	05:02
jamesh	the already converted version of rocketfuel contains most of the tree states as your local branches in knit format	05:03
mpt_	So, RocketfuelToKnits is missing a final instruction: "When you've converted all your branches, rsync your copy of rocketfuel-built again so that it doesn't contain code from any of your other branches."	05:03
mpt_	Is that accurate?	05:03
mpt_	"rsync down", even	05:03
jamesh	so the "pull --overwrite" command just adds the missing nodes as knit data so it can trace the blue line for that branch	05:04
jamesh	which is cheaper	05:04
jamesh	that sounds accurate.	05:04
=== doko [n=doko@201.160.17.131.cableonline.com.mx] has joined #launchpad
mpt_	thanks jamesh	05:12
mpt_	ok, next question:	05:12
mpt_	"To push a standalone knit branch to chinstrap the first time..."	05:12
mpt_	Is that necessary for existing branches, or just newly-created ones?	05:12
spiv	mpt_: sorry, was afk for a bit. You and jamesh are right, I'll update the instructions.	05:14
spiv	Oh, someone beat me to it :)	05:14
jamesh	mpt_: after having upgraded your branch to knit format, basically all the revision control files have changed	05:14
mpt_	:-)	05:14
jamesh	mpt_: if you don't mind pushing 200MB+ for each branch, you can ignore it :)	05:15
mpt_	oh, so I should do it anyway	05:15
jamesh	the idea is to put something similar to the branch in place on chinstrap, so that when you rsync your branch you are only sending the differences	05:15
mpt_	assuming that the changes in each of my branches are less than 200 MB :-)	05:16
mpt_	right	05:16
spiv	mpt_: "bzr push" will preserve the format of an existing branch, so it would push your local knit branch to a remote weave branch if it already existed, which would be massively slow. So you should do it for every converted branch you want to push.	05:16
mpt_	ok	05:16
mpt_	so maybe it should be step 6?	05:16
jamesh	spiv: good point. Hadn't thought of that ..	05:16
spiv	Probably, I only added that note quickly last night before I went to bed.	05:17
mpt_	spiv, and it has an error	05:18
spiv	Ideally, we'd use repositories...	05:18
mpt_	bash: /home/warthogs/archives/rocketfuel.knits/launchpad/devel/: is a directory	05:18
mpt_	stray slash?	05:18
mpt_	two stray slashes?	05:18
jamesh	mpt_: did you do "cp" or "cp -a"?	05:18
mpt_	ahaha	05:19
mpt_	I did "-a"	05:19
spiv	The trailing slash shouldn't matter.	05:19
mpt_	Yes, the problem wasn't the missing "-a", it was the missing "cp"	05:19
spiv	Oh, right :)	05:19
jamesh	mpt_: thanks for cleaning up some of the text on the WokringWithSharedRepositories page	05:20
mpt_	Well, lifeless asked me to read it, so I was just practising	05:22
mpt_	"bzr: WARNING: This transport does not update the working tree of: sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/trivial/"	05:30
mpt_	Then what does it update?	05:30
jamesh	the repository data and the branch data	05:32
jamesh	i.e. the stuff that pqm cares about	05:32
mpt_	ok	05:32
=== elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad
=== jsgotangco [n=jsg@210.4.38.43] has joined #launchpad
=== tambaqui [n=tambaqui@201.160.20.136.cableonline.com.mx] has joined #launchpad
=== stub [n=stub@ppp-58.8.2.77.revip2.asianet.co.th] has joined #launchpad
=== stub [n=stub@ppp-58.8.2.77.revip2.asianet.co.th] has joined #launchpad
=== olive [n=olive@pigeon.moostik.net] has joined #launchpad
=== Keybuk [n=scott@quest.netsplit.com] has joined #launchpad
=== mpt__ [n=mpt@203.109.220.214] has joined #launchpad
=== dsas [n=dean@host81-129-228-205.range81-129.btcentralplus.com] has joined #launchpad
=== Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad
mpt__	lifeless: When will PQM be available again?	07:01
=== fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad
=== ..[topic/#launchpad:lifeless] : https://launchpad.net/ \| developer meeting: Thu 18 May, 1200UTC (wiki:MeetingAgenda) \| launchpad-users@lists.canonical.com (wiki:MailingLists) \| Channel logs: http://tinyurl.com/72w39
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad
=== BjornT [n=bjorn@213.226.190.253] has joined #launchpad
=== mpt [n=mpt@203-173-174-236.bliink.ihug.co.nz] has joined #launchpad
mpt	"bzr: ERROR: Parent directory of sftp://chinstrap.ubuntu.com/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/ does not exist."	08:09
spiv	mpt: That's right.	08:10
spiv	mpt: You're missing a /home	08:11
mpt	a-ha	08:11
spiv	It would be nice if it said which part of the path specifically was causing the problem...	08:12
spiv	Although I think that's hard to do 100% correctly, because it optimistically tries the full thing, and the error the SFTP server sends doesn't contain that information.	08:12
mpt	spiv: If you're using --overwrite, what's the point of the ssh chinstrap cp... before it?	08:15
spiv	mpt: overwrite won't make it push what's already there.	08:16
mpt	So how does --overwrite differ from not overwriting?	08:16
mpt	"Ignore differences between branches and overwrite unconditionally"	08:17
spiv	It just tells it to continue even if the branch you are pushing to has a different history to yours.	08:17
mpt	ah	08:17
mpt	and knits vs. weaves = different history	08:17
spiv	Specifically, if the rocketfuel you cp from is more recent than when your branch branched off rocketfuel, the push would refuse to work without --overwrite.	08:18
spiv	Because you would be overwriting revisions that aren't in the branch you're pushing.	08:18
spiv	It's not about knits vs. weavs.	08:18
spiv	weaves, rather.	08:19
mpt	ok	08:19
spiv	It's about bzr refusing to overwrite revision 1234 with a different revision 1234 by default.	08:19
spiv	The help for --overwrite probably ought to be clearer that it's talking about overwriting revision history, rather than talking about just blinding sending everything.	08:20
spiv	s/blinding/blindly/	08:21
=== spiv sets up some repositories
spiv	Or a repository, I should say...	08:22
=== mpt_ [n=mpt@203-173-174-236.bliink.ihug.co.nz] has joined #launchpad
=== mpt__ [n=mpt@203.109.220.214] has joined #launchpad
mpt__	spiv: I lost my Internet connection while pushing, and now I get "bzr: ERROR: Lock error: File 'branch-lock' already locked"	08:29
mpt__	Should I just delete that file?	08:29
spiv	mpt__: try the "bzr break-lock" command.	08:29
spiv	I've never bumped into this myself, though, so I'm just making educated guesses :)	08:30
jamesh	spiv: one thing to note: doing an sftp push of a branch inside a shared repository can cause some sections of the ~/.bazaar/branches.conf file to be shadowed (if you use the pqm-submit config I gave on the WorkingWithSharedRepositories page)	08:38
BjornT	SteveA: ping	08:39
jamesh	it creates an entry for $repository/$branchname giving the push location, and bzr doesn't look at sections for parent directories	08:39
SteveA	BjornT: hi	08:41
Keybuk	hi guys,	08:41
SteveA	hello scott	08:42
Keybuk	just to give you an idea of the problem caused by that "sourcepackagenames exist for things that aren't source packages" bug	08:42
Keybuk	http://people.ubuntu.com/~scott/reports/unpublished.html	08:42
Keybuk	we've got 182 bugs assigned to them at the moment :-/	08:42
=== sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad
BjornT	hi SteveA. just wanted to make sure you were awake. i'm leaving my place now, so i'll be at your place in 20 minutes or so depending on traffic.	08:42
SteveA	okay, fine	08:44
mpt__	hmm, that didn't work	09:03
=== rpedro [n=rpedro@87-196-70-18.net.novis.pt] has joined #launchpad
Keybuk	do people in here know about schooltool ?	09:04
lifeless	fsvo about	09:05
mpt__	bah	09:05
Keybuk	lifeless: it's sitting in main, but begging to be moved to universe	09:06
lifeless	its python right ;)	09:06
lifeless	SteveA is probably the most aware of the circumstances/policy about it	09:07
Keybuk	it doesn't appear to be seeded anymore	09:07
SteveA	hello scott	09:07
Keybuk	don't know if it ever has been	09:07
SteveA	i know a little about schooltool	09:07
lifeless	its a tool	09:07
lifeless	for schools.	09:07
lifeless	^ a little ^	09:07
sivang	morning all	09:07
Keybuk	hmm, that's odd actually	09:08
Keybuk	edubuntu-server depends on it	09:08
SteveA	i haven't followed recent development	09:08
Keybuk	oh,	09:08
Keybuk	schoolbell	09:08
Keybuk	what's that one? :p	09:08
SteveA	schoolbell is a product based on schooltool, a cut-down version that just does calendaring	09:08
jsgotangco	hmm that's odd if ubuntu-server depends on them	09:09
SteveA	rather than calendaring + attendance for schools + other schools stuff	09:09
Keybuk	ok, it's that that's fallen out	09:09
Keybuk	I should probably just seed it somewhere, yes?	09:09
Keybuk	it should be in main and not universe?	09:10
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
SteveA	i guess so.	09:10
SteveA	ubuntu is the primary distribution channel for schooltool	09:10
Keybuk	it looks like schooltool used to depend on schoolbell	09:11
SteveA	jinty would know more	09:11
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
SteveA	mpt: hello	09:14
stub	Bah - 14kb/s from chinstrap via ssh :-(	09:15
Keybuk	yeah chinstrap is poorly today	09:15
SteveA	jamesh: we're due to have a call sometime soon, to talk about review processes	09:15
Keybuk	08:15:55 up 89 days, 15:27, 5 users, load average: 5.58, 4.91, 4.49	09:16
SteveA	Keybuk: what's up?	09:16
jamesh	SteveA: yeah.	09:16
jamesh	Keybuk: we did the knit upgrade yesterday, so I guess everyone's branches are churning	09:16
Keybuk	that's what I figured	09:16
SteveA	you mean, lots and lots of rsync and disk IO?	09:17
SteveA	what does user archvsyn do?	09:17
SteveA	jamesh: so, skype call?	09:21
jamesh	seems to be rsyncing launchpad logs from gangotri	09:22
jamesh	SteveA: okay	09:22
lifeless	top shouls 87 % in IO wait	09:24
lifeless	shows	09:24
lifeless	bzr conversions are memory hungry, but there is no python in top-sortyed-by-memory	09:25
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has joined #launchpad
lifeless	lots of rsyncs though ;)	09:25
lifeless	however, I think aide is the culrpit	09:25
freeflying	need help. can not sign COC error:str: The signed text does not match the Code of Conduct. Make sure that you signed the correct text (white space differences are acceptable).	09:27
=== carlos [n=carlos@175.Red-88-9-38.dynamicIP.rima-tde.net] has joined #launchpad
carlos	morning	09:28
freeflying	carlos: hi, why can't Isign coc now? thx	09:29
carlos	freeflying: I guess your problem could be https://launchpad.net/products/launchpad/+bug/39547	09:30
Ubugtu	Malone bug 39547 in launchpad "Code of Conduct 1.0.1 signatures not accepted" [Critical,Confirmed]	09:30
carlos	SteveA: hi, around?	09:30
freeflying	carlos: thx, just the same	09:31
mpt	hi SteveA	09:40
=== `6og [n=kgoetz@ppp202-110.lns1.adl4.internode.on.net] has joined #launchpad
=== malcc [n=malcolm@host81-154-31-97.range81-154.btcentralplus.com] has joined #launchpad
=== mpt_ [n=mpt@203.109.220.214] has joined #launchpad
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
SteveA	spiv: hello	10:09
spiv	SteveA: hi	10:09
SteveA	spiv: shall we have a skype call?	10:09
spiv	Sure.	10:09
carlos	SteveA: mark's branch was rejected (and anyway, I was late for the rollout)	10:13
carlos	SteveA: I'm doing the knit migration to merge rocketfuel into that branch and solve any conflict I find	10:13
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has left #launchpad ["Konversation]
stub	Using sftp, will the 95Mb inventory.knit need to be pushed in entirety?	10:23
lifeless	stub: no	10:24
lifeless	stub: the 2M index is downloaded, the new data calculated, and then appended to the inventory.knit and new index entries appended to the index.	10:24
stub	But can you do that on push with sftp?	10:25
lifeless	I'm describing what sftp push with knits does.	10:25
lifeless	What are you asking?	10:25
=== mpt__ [n=mpt@203.109.220.214] has joined #launchpad
=== jinty [n=jinty@212.Red-83-54-75.dynamicIP.rima-tde.net] has joined #launchpad
stub	I didn't think you could append with sftp. I'm wondering if I bzr push an updated branch to update a previous push, using sftp, if the entire inventory.knit will need to be shoved up ?	10:27
lifeless	sftp supports append	10:28
stub	ok	10:28
lifeless	what will happen is that the 2M index is downloaded, the new data calculated, and then appended to the inventory.knit and new index entries appended to the index.	10:28
carlos	stub: hmmm, I see my branch with the needs-reply status... but I didn't get any email with the review	10:29
stub	I'll resend	10:30
carlos	could you resend it, please?	10:30
carlos	thanks	10:30
carlos	stub: are you working today, or still sick?	10:30
stub	working	10:30
carlos	ok, could you take a look to my email about the DELETE SQL commands?	10:31
carlos	stub: we should run all those SQL commands as soon as possible to close that issue with Kurdish	10:31
=== Yannig [n=yannick@AToulouse-254-1-24-55.w81-250.abo.wanadoo.fr] has joined #launchpad
stub	resent	10:31
carlos	stub: got it, thanks	10:34
Yannig	Hello everybody :)	10:35
=== mpt_ [n=mpt@203.109.220.214] has joined #launchpad
carlos	stub: btw, I sent you an email to have a meeting to talk about the RSS feature that will use that new API	10:36
carlos	stub: when would you have time to have such meeting?	10:36
stub	carlos: I have two patches from you, one with a number of updates and a single delete. And another with just deletes. Both need to run?	10:36
carlos	that will answer some of your questions raised on that review email	10:37
stub	carlos: Now if you like.	10:37
carlos	stub: the second on with deletes is a modification of the single DELETE in the first patch	10:37
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad
carlos	s/on/one/	10:37
stub	ok. So only run the updates from the first patch, and all the deletes from the second	10:37
carlos	stub: well, you can just execute the first one	10:38
carlos	stub: but the delete is really, really slow	10:38
carlos	I rewrote it with 25 differente deletes to reduce the amount of time we would have the table locked	10:38
carlos	but it's still too slow	10:38
carlos	if you could give me a hint to reduce its execution time...	10:39
carlos	SteveA: do you have time now to talk about the RSS feature with stub?	10:39
stub	It will be slow - it is a big table.	10:39
carlos	Yannig: hi	10:39
carlos	stub: will that lock Rosetta?	10:39
stub	Maybe	10:39
SteveA	even if you run it with no isolation?	10:40
SteveA	oh, you're not talking about the RSS output being slow	10:40
stub	SteveA: The individual queries will each take a few minutes.	10:40
SteveA	you're talking about the update sql patch thing being slow	10:41
carlos	SteveA: no, sorry, talking about data migration too	10:41
SteveA	i can talk about RSS now	10:42
carlos	ok	10:42
stub	So I said we need a mockup of the RSS feed we are after, and then I could review the appropriateness of the API.	10:42
carlos	stub: the idea is to prepare an RSS feed with latest updated POTemplate	10:43
stub	I'm not sure what sort of an RSS feed people wanted by reverse engineering the API changes	10:43
carlos	that way, translators would subscribe to it to know when new strings appear	10:43
stub	That is vague. We need a mockup. Just .txt will do	10:44
SteveA	carlos: so, can you prepare a short amount of text, in a chinstrap pastebin	10:44
SteveA	that explains what you want to see in an RSS reader?	10:44
SteveA	like	10:44
carlos	so the RSS feed would use IPOTemplate.title as its title and the URL canonical_URL(potemplate)	10:44
SteveA	--------	10:44
carlos	sure	10:44
SteveA	11 July 2006: Foo uploaded whatever <--- link to http:///.....	10:44
SteveA	By John Smith	10:44
SteveA	Whatever	10:44
SteveA	--------	10:44
SteveA	etc.	10:44
=== ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad
carlos	SteveA, stub: https://chinstrap.ubuntu.com/~dsilvers/paste/fileA8eN9F.html	10:47
carlos	I guess it would be more or less that way	10:48
carlos	all that information is stored inside the POTemplate object	10:48
carlos	and the API I added is returning a list of all POTemplates we have	10:48
stub	So we will have an RSS feed per (distribition, sourcepackage), or is it just coincidence that your mockup only contains one sourcepackage?	10:49
carlos	leaving to the RSS feed code the decision of the amount of potemplates to show	10:49
ddaa	hello	10:50
carlos	stub: well, I wrote it so we could have an RSS feed for the whole system and others specific to a distrorelease, a productseries or a distrorelease and sourcepackagename	10:50
carlos	stub: it depends on the context object we use, IPOTemplateSet or IPOTempalteSubset	10:50
carlos	ddaa: hi	10:51
stub	I'll need to go over your code and estimate how expensive it is doing these queries on request. I suspect we will need to refactor it to use events and a message store similar to what was specced for RSS feeds in Brazil.	10:52
carlos	stub: I added the new field to the POTemplate object so we only need to use one table to get the information and reduce the query time	10:54
carlos	the new field is a cached value with the last date when it was updated	10:54
carlos	so I guess it depends on the amount of potemplates we have in our database	10:54
SteveA	stub: this is meant to be a quick fix for a communication problem we have right now	10:58
SteveA	so, if it will work, i'd like to get something out without refactoring, then refactor later	10:58
stub	What does 'updated template' actually mean might have happened?	10:59
SteveA	(that is, assuming that refactoring is time consuming)	10:59
carlos	stub: we got a .pot upload into the system	11:00
carlos	stub: that is newer than the previous upload	11:01
carlos	so we accepted it to be imported into the system	11:01
stub	A pot upload will not delete the previous pot? The old one is still there?	11:01
carlos	well, not delete but update	11:02
carlos	will add/remove strings from the previous one	11:02
stub	I'm more interested in what a user sees if their RSS reader is polling every 60 minutes, and several uploads of the same potemplate were made during that period.	11:03
carlos	only the latest one will appear	11:04
carlos	so yes, it's a removal from that point of view	11:04
stub	Will the new POTemplate get a new id?	11:07
carlos	no	11:07
stub	This is making the RSS feed generator much more complex, and only applicable to this particular feed - it will need rewriting for future feeds.	11:08
stub	Each article will need a unique, unchanging id. We can't use the id's we have in the database, as they are mutating. And we also have to store publication dates and such too.	11:09
SteveA	stub: so, you think using an events-table would be simpler?	11:09
stub	An events table will mean the feed generator will work on anything that can fill in a similar structure, and the table will also be usable for emailing noifications, or pushing notifications out via other means such as IRC or Jabber.	11:10
carlos	stub: I don't understand this... you say that we need a unique ID	11:10
stub	We need an events table anyway to store the information the RSS feed needs to be stable (article ids etc)	11:10
carlos	and we have such unique IDs	11:10
carlos	but you also say that they will be mutating... why?	11:11
carlos	potemplate.id will not change at all	11:11
stub	Each article in an rss feed has a publication date, an id, title, and content. The id can't change. The publication date can't change (there is a different field for last changed).	11:11
stub	So if you upload a potemplate 3 times, each article generated needs a stable and unique id and publication date.	11:12
carlos	we have that	11:12
carlos	potemplate.datecreated could be used as publication date	11:12
carlos	and then potemplate.date_last_updated as the last changed	11:13
carlos	would that be enough?	11:13
carlos	ony date_last_updated will be changed with every update	11:13
stub	That might work. It depends on if the readers support last changed well.	11:14
stub	I'll go over the RSS2.0 spec again quickly...	11:14
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
carlos	ok	11:15
stub	What you are suggesting is we only ever publish a single feed item per potemplate, but update the information on each upload.	11:15
carlos	if that's possible, yes	11:16
carlos	I know nothing about RSS details	11:16
carlos	so I'm not sure if that's possible or not	11:16
=== `6og is now known as kgoetz
stub	Hmm... no date changed in RSS. That must be Atom I was thinking of.	11:22
stub	It might be possible to generate a guid using the POTemplate.id and last_changed - that should cover things.	11:23
carlos	stub: could I do anything to help there?	11:25
stub	Nah.	11:27
carlos	ok	11:29
carlos	I will apply your review changes	11:30
stub	Just need to figure out caching of the feed, so it only gets regenerated evey 30 mins or so.	11:30
stub	So we don't want to generate the feed on the fly, or we reward people who set their refresh time to tiny amounts.	11:34
stub	We can't pregenerate the feeds and serve them of the filesystem via Apache as there are too many of them.	11:34
stub	We could use Squid to serve and cache the RSS feeds, but that adds another moving part to the Launchpad production environment.	11:34
stub	Probably the best option is to cache in the main PostgreSQL database.	11:35
stub	I'm still leaning towards maintaining an events table as described in https://wiki.launchpad.net/RssFeeds personally	11:37
SteveA	we can cache rss in apache	11:37
SteveA	but...	11:38
=== WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad
SteveA	stub: if you want to implement RssFeeds, it looked mostly fine to me. it needs a little updating though.	11:38
uws	rss feeds are pretty straightforward to implement most of the time (i've done in several webapps)	11:40
SteveA	ANNOUNCEMENT: launchpad development meeting in 2 hours.	11:53
SteveA	now is a good time to ensure your activity reports are up to date.	11:53
stub	carlos: The code is setting potemplate.last_update_date instead of potemplate.date_last_updated	11:53
carlos	stub: really? hmmm, I wonder if I forgot to run tests after that change...	11:54
stub	carlos: I'm curious as to why we are setting it in the getLastTranslator method (a hidden side effect), and setting it to whatever was specified in the templates headers instead of the current time.	11:54
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
carlos	stub: it's not done inside getLastTranslator...	11:55
carlos	stub: it's done inside import_po	11:55
stub	Yer - misreading diffs.	11:55
carlos	stub: about the value... that date is the actual date when the pot file was generated	11:56
carlos	there could be a newer version with a newer date	11:56
stub	But we can't rely on it because it is user input. Or at least we can't rely on it to be the actual time it was last modified.	11:56
carlos	well, it's supposed to be updated on .pot generation time	11:57
carlos	not manually handled by the user	11:57
carlos	but gettext	11:57
stub	We are still trusting the remote environment and people to work the way you expect them to (rather than the way they want to, which might be different)	11:58
carlos	the user handled field is for .po files not .pot files	11:58
carlos	stub: right	11:58
carlos	stub: so you think we should use current time instead?	11:58
carlos	ok, I see your point and is a good concern	11:59
carlos	will do it that way	11:59
stub	It all depends on what you want date_last_updated to store. If you want it to store the value from that header, it probably should be renamed and I can't rely on it for RSS feed generation (so we will still need a date_last_updated set to CURRENT_TIMESTAMP anyway)	11:59
stub	We definitely want a limit argument passed into the new methods, which is propagated through to the select() calls.	12:00
stub	Which I guess means the methods should also be renamed, removing the 'All'	12:01
ddaa	carlos: re users-don't-read	12:02
ddaa	carlos: maybe the default for that selector should be "I don't know", then	12:02
stub	Or If I do foo.select(blah)[:200] , does that issue the SQL with a LIMIT command?	12:04
stub	c/command/clause/	12:05
stub	Geez... my rocketfuel-built rsync is still syncing. 3 hours!	12:06
ddaa	yowzer, it would probably have been faster for you to download it as a tarball	12:07
ddaa	interesting	12:08
ddaa	just compared rsync and nested-pull (a trivial script that does pull on every nested tree) for rocketfuel built	12:08
ddaa	rsync ran in 1 min 30s	12:08
ddaa	pull ran in 1 min 20s	12:08
ddaa	(wallclock time)	12:09
carlos	stub: it should, yes	12:10
carlos	stub: I'm returning a selectresult	12:11
stub	carlos: No need for the limit argument - slicing the select results issues the SQL with the LIMIT	12:11
stub	ok	12:11
carlos	stub: about the date field, I will do what you suggest, that field is specific for the RSS feature	12:11
carlos	no need to have the header value parsed	12:11
stub	ok. Will it get updated if someone uploads an identical potemplate?	12:12
carlos	ddaa: it's already the default	12:12
ddaa	hehe hehe hehe	12:12
stub	The TranslationSubscriptions spec was using a checksum to detect rather than a timestamp.	12:12
ddaa	carlos: okay, that why this quote is funny	12:12
carlos	stub: yes, it will be updated	12:12
ddaa	it's not obvious from just the quote	12:12
carlos	ddaa: ;-)	12:12
carlos	ddaa: ok, I will update it to show that fact	12:13
carlos	;-)	12:13
stub	carlos: Do we care if we tell users that the template was updated when it actually hasn't been modified at all in this particular case? I suspect it wouldn't happen often?	12:13
stub	Will we ever be doing bulk potemplate uploads that could cause this case?	12:14
carlos	stub: I think is ok to do it that way until we implement the checksum thing you noted	12:14
stub	ok	12:14
stub	carlos: I think we can run with what we have after you have fixed the naming of the column and the typo I mentioned earlier. If we want to make the feed richer though (eg. '44 new message id's added, 12 removed' etc.) we will need to refactor.	12:15
carlos	yeah, I know	12:16
carlos	but the idea is to provide a basic functionality, so it's ok to go with what we have atm	12:16
stub	SteveA: Are you sure our Apache is capable of caching?	12:17
SteveA	i'm sure it can be made so by the admins	12:18
SteveA	they've done it for the wiki sites	12:18
stub	Cool. If they are doing the wikis, a few thousand RSS feeds shouldn't be a burden.	12:18
lifeless	if apache can't, we can always stuff squid in front	12:18
lifeless	:)	12:19
SteveA	they're doing the ubuntu website, which is a moin wiki	12:19
stub	lifeless: This is a quick hack. I've got other plans for doing this properly ;)	12:19
lifeless	2.6 is coming out very soon, with all the rproxy stuff in it. going to rock.	12:19
carlos	stub: Could you give me a patch number for my db patch?	12:20
carlos	stub: also, I assume that with the two changes you noted, I can request a merge into rocketfuel, right?	12:20
stub	The db patch also needs an index added -- CREATE INDEX potemplate__date_last_updated__idx ON POTemplate(date_last_updated);	12:21
stub	carlos: patch-40-56-0.sql	12:23
carlos	ok	12:23
carlos	thanks	12:23
stub	r=stub	12:23
jamesh	mpt: have you seen this? http://code.google.com/webtoolkit/	12:23
stub	carlos: And file a bug for the RSS feeds so it doesn't get dropped	12:23
carlos	stub: ok	12:24
carlos	thanks	12:24
SteveA	jamesh: hah -- they implemented menus	12:25
jamesh	SteveA: among other things, it lets you write code in Java and it translates it to javascript	12:25
stub	Sounds similar to mochikit, but in Java.	12:25
jamesh	SteveA: letting you use Java development tools to debug/test the code	12:25
SteveA	i see	12:27
SteveA	BjornT: lunch? ili pica across the road is quick and kinda edible	12:35
BjornT	SteveA: sure, sounds good.	12:36
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad
ddaa	stub: is there a config for the recently rolled out code?	12:41
lifeless	ddaa: I did not update any configs.	12:42
ddaa	the branch-scanner config has been broken since the last rollout, but the last time I fixed it in place because there was not a production config and because merging anything was way too much pain anyway	12:42
lifeless	ddaa: was not in the RolloutProcedure	12:42
ddaa	I'll add it then.	12:43
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
ddaa	lifeless: updating the config should happen when creating the production branch	12:49
ddaa	but the "create the new production branch" step is not in LaunchpadRollout	12:50
ddaa	so I cannot add the "update the config" step	12:50
lifeless	ddaa: so add both!	12:51
ddaa	mh, thought that "create the production branch" bit was somewhere else	12:51
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
=== ploum [n=ploum@ubuntu/member/ploum] has joined #launchpad
cprov	good morning, guys	01:15
carlos	cprov: hey!	01:18
cprov	carlos: yo, how is it going ?	01:19
carlos	burning my hard drive and my DSL line with the knits migration ;-)	01:19
cprov	carlos: it's worth, I would not think twice, it's much faster	01:22
carlos	yeah	01:22
ddaa	I'm sure we'll find something to bitch about, in time	01:22
carlos	I'm converting branches as soon as I need to merge from rocketfuel	01:22
ddaa	but right now, it feels great	01:22
carlos	ddaa: but not now ;-)	01:22
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
=== cprov looks for coffee, back in a minute
Yannig	I don't if you saw it when I told it last night but the Untranslated strings number does not change anymore since the server update (example: https://launchpad.net/distros/ubuntu/dapper/+lang/oc/)	01:35
Yannig	(only the general one: the counter for each template works fine)	01:36
carlos	Yannig: those values are cached ones and I think they are updated once per day	01:36
carlos	so don't expect to get real time updates for it	01:37
Yannig	Fair enough :)	01:38
Yannig	So I'll stick to 99,62 % untranslated today :D	01:39
SteveA	launchpad meeting in 18 mins	01:40
carlos	Yannig: I guess... not sure if it's executed more often	01:41
carlos	stub: ?	01:41
carlos	stub: talking about the cron job that update the cached statistics	01:41
stub	eh?	01:41
carlos	I don't remember how often is it executed	01:41
Yannig	carlos> I thought it was done at once befoce yesterday, that's why (but I don't really mind, it's just stats :))	01:41
stub	daily	01:41
carlos	Yannig: perhaps yesterday's update was not executed due the production update	01:42
Yannig	I should be able to survive :)	01:43
carlos	Yannig: no, the update was executed today "They were last generated on 2006-05-18 at 07:20:57 CEST."	01:43
carlos	Yannig: you can see it at https://launchpad.net/rosetta on the left portlet	01:44
Yannig	OK	01:44
Yannig	Thanks a lot :)	01:44
cprov	stub: ping	01:50
stub	pong	01:50
cprov	stub: could you, please, copy a new production backup to mawson ? don't override the current launchpad_dogfood DB right now	01:51
SteveA	meeting in 7 mins	01:51
stub	ok	01:51
SteveA	i'm going to take a workrave	01:51
cprov	stub: thank you	01:51
cprov	stub: btw, could you double check the indexes are correcly installed, I suspect the last copy hasn't proper index, because the performance on publisher was much lower than production. I didn't have time to investigate it properly, though.	01:54
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
stub	You would have seen errors when restoring from the backup. Most likely, it is because production is running on 4 fast dual core AMD 64's with 32GB of RAM, and mawson isn't.	01:55
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
cprov	stub: yes, propably (with sarcasm :)	01:57
carlos	stub: hmm what are you going to do with the SQL commands to migrate data that I gave you?	01:57
carlos	are you going to execute it on production?	01:57
stub	carlos: run them ;) I'll kick it off in a tick and we can see if rosetta is affected.	01:58
carlos	lifeless: I cannot believe it... did you added the Hackergotchi images to pqm.launchpad.net? dude!! that's sooo sweet (well, the links are broken, but I love the idea :-P)	01:59
carlos	stub: ok, thanks	01:59
lifeless	looks like a quoting bug	01:59
lifeless	its just test output	01:59
SteveA	hello	01:59
lifeless	probably failing tests	01:59
SteveA	LAUNCHPAD DEVELOPERS MEETING	02:00
carlos	lifeless: ooh... well, it's a good idea anyway ;-)	02:00
SteveA	welcome to this week's launchpad development meeting	02:00
SteveA	starting at 3.01pm sharp, vilnius time	02:00
SteveA	who is here today?	02:00
mpt	me	02:00
malcc	me	02:00
bradb	me	02:00
ddaa	me	02:00
carlos	me	02:00
BjornT	me	02:00
lifeless	oi oi oi	02:00
cprov	me	02:01
spiv	me	02:01
stub	me	02:01
jamesh	me	02:01
salgado	me	02:01
Yannig	I'm here too, but I may not be necessary :p	02:01
kiko	me	02:01
matsubara	me	02:02
SteveA	jordi: ?	02:02
kiko	how is everyone?	02:02
malcc	I tried to switch on my brain this morning, it said: No swap space	02:02
stub	sore	02:02
malcc	Other than that, fine :)	02:02
mpt	I made the mistake of having a nap, and I started dreaming about Launchpad	02:02
SteveA	never the second clown, don't you?	02:03
SteveA	== Agenda ==	02:03
SteveA	* Roll call	02:03
SteveA	* Agenda	02:03
SteveA	* Next meeting	02:03
SteveA	* Activity reports	02:03
SteveA	* Actions from last meeting	02:03
SteveA	* Launchpad oops milestone report	02:03
SteveA	* Outstanding sysadmin requests	02:03
SteveA	* Production and staging (stub)	02:03
SteveA	----	02:03
SteveA	* Are we all using bzr and bzrtools from dapper (kiko)	02:03
SteveA	* Status of bugwatches work (bjorn)	02:03
SteveA	* Result of converting to knits (steve)	02:03
SteveA	----	02:03
SteveA	* Keep, Bag, Change	02:03
SteveA	* Three sentences	02:03
SteveA		02:03
SteveA	next meeting, same time next week	02:03
=== SteveA allows 10s to object while he removes a teabag from a teacup
kiko	let's have it at midnight UTC!!11!	02:04
=== mpt scowls at kiko
=== ..[topic/#launchpad:SteveA] : https://launchpad.net/ \| developer meeting: Thu 25 May, 1200UTC (wiki:MeetingAgenda) \| launchpad-users@lists.canonical.com (wiki:MailingLists) \| Channel logs: http://tinyurl.com/72w39
kiko	ok let's have it at the same time as usual then	02:04
SteveA	it is done	02:04
jamesh	mpt: that's like midday for you	02:04
SteveA	* activity reports	02:05
mpt	up to date	02:05
ddaa	uptodate	02:05
kiko	as usual	02:05
BjornT	up to date	02:05
salgado	up to date	02:05
bradb	up to date	02:05
cprov	up to date	02:05
jamesh	sent a summary for this week	02:05
matsubara	up to date	02:05
spiv	up to date	02:05
lifeless	up to date	02:05
SteveA	i sent a summary of my activity this week, so if i send today's i'll be back on the straight and narrow	02:05
malcc	up to date	02:05
stub	up to date	02:05
carlos	up to date	02:05
malcc	Yay woo, go us, we rock, etc.	02:06
SteveA	is that a full house (allowing for summaries?)	02:06
SteveA	cool	02:06
SteveA	well done everyone	02:06
carlos	jordi: up to date	02:06
SteveA	jamesh: be sure to send in today's activity report	02:06
SteveA	thanks carlos	02:06
SteveA	* Actions from last meeting	02:07
SteveA	* '''kiko''' to talk to bzrtools and bzr packagers to sort out this nonsense	02:07
kiko	it's been done as you saw via email	02:07
SteveA	do we have consistent compatible bzr and bzrtools in dapper now?	02:07
SteveA	yay	02:07
kiko	has everyone upgraded to bzr-in-dapper?	02:07
SteveA	* Launchpad oops milestone report	02:07
SteveA	matsubara: take the floor!	02:07
kiko	oops jumped the gun	02:07
matsubara	We're seeing bugs like 1887 and 44834 (Out of order SQL queries). stub, spiv?	02:07
SteveA	bug 1887	02:08
SteveA	bug 44834	02:08
matsubara	where's ubugtu when we need it?	02:08
spiv	I wish I had even half a clue about how that happens.	02:08
matsubara	both a private	02:08
matsubara	s/a/are	02:08
SteveA	I'd like Ubugtu to give the bug URL nonetheless, in these cases	02:08
stub	Haven't looked further into this. As far as we can tell, it is impossible. It has not been reproduced in a controlled environment.	02:08
matsubara	so, I should just ignore it when it hits the oops report?	02:09
SteveA	would having the value of locals up the stack be any help diagnosing this from oopses?	02:09
SteveA	or any other particular diagnostic data?	02:09
=== zorglub [n=zorglub@wahe.diwi.org] has left #launchpad []
kiko	could it be server overload?	02:09
matsubara	what can I do that might help?	02:09
salgado	can't this be the same issue with the merge people test that is failing randomly?	02:09
stub	I'm at a bit of a loss on what we can do to debug this further.	02:09
stub	salgado: Yes - quite likely.	02:09
SteveA	kiko: i don't think so. it seems like a correctness issue.	02:10
SteveA	correctness shouldn't suffer when the server gets loaded	02:10
spiv	kiko: I'd say only if postgres has extremely wierd and subtle bugs.	02:10
SteveA	although, perhaps it could be that python does more gc when memory is tight	02:10
kiko	mmmm. yeah, but maybe it happens only when there is pressure on the server. random guess, anyway	02:10
SteveA	not sure about that though	02:10
SteveA	or if there's more blocking on IO	02:10
SteveA	so more time to do gc	02:10
kiko	having the loadavg would be ideal in the OOPS report	02:11
kiko	it's clear that out	02:11
spiv	It's interesting that it only tends to affect certain pages, rather than randomly victimising everything.	02:11
jamesh	IIRC, the Python GC is only triggered by creating/deleting objects	02:11
kiko	of course, having the loadavg of the /database box/ may be even more useful	02:11
kiko	spiv, well, the pages which are used the most, it appears, no? standard statistical spread?	02:11
spiv	jamesh: And calling gc.collect(), but otherwise that's my understanding too :)	02:11
SteveA	i don't think it is a database box issue -- i think it is more likely that sqlobject makes things less correct	02:11
SteveA	than we have a correctness problem in postgres	02:11
stub	kiko: loadavg will not be interesting. cpu utilization maybe, but my gut feeling is that this isn't a client issue.	02:12
jamesh	Given the way the SQL statement log is recorded, it can't be a multithreading issue	02:12
SteveA	stub: isn't a client issue?	02:12
jamesh	it only records statements from one thread	02:12
spiv	kiko: Hmm, I don't think so, there isn't enough randomness to the victims.	02:12
kiko	spiv, +translate is the usual victim, no?	02:12
stub	SteveA: Unless our logging is screwed - IIRC when I checked, the queries were being sent correctly to the server.	02:12
kiko	which is by far the most hit page	02:12
kiko	which does writes anyway	02:12
SteveA	stub: i'd like to have a voice call with you about this after the meeting	02:12
matsubara	kiko: yes, but it happened too in +editstatus	02:13
stub	ok	02:13
SteveA	ok	02:13
SteveA	time to move on	02:13
matsubara	moving on	02:13
kiko	matsubara, second page most hit I suspect	02:13
kiko	yes let's	02:13
SteveA	matsubara: anything else on the oops report?	02:13
matsubara	Retry Exceptions still happening and bug 31479 would help diagnose the real problem. spiv?	02:13
Ubugtu	Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Normal,Confirmed] http://launchpad.net/bugs/31479	02:13
matsubara	yes lots of things	02:13
jordi	hi	02:13
SteveA	hi jordi.	02:13
matsubara	Steve's patch to tickcount. Steve asked me to test it, but I don't know C enough to understand what the patch does, so I'm not sure if I'm the right person to do it.	02:13
SteveA	ordi: carlos said you're up to date with activity reports	02:13
matsubara	Outstanding Timeouts (bugs 2497, 3991, 6459) all assigned to kiko.	02:13
jordi	sorry I'm late, I was in some other nmeeting	02:13
Ubugtu	Malone bug 3991 in rosetta "Timeout error on translation page (+translate)" [Normal,Confirmed] http://launchpad.net/bugs/3991	02:13
Ubugtu	Malone bug 6459 in rosetta "SoftTimeout error on distribution release language page" [Normal,Confirmed] http://launchpad.net/bugs/6459	02:13
jordi	SteveA: I'm up to date.	02:14
kiko	matsubara, this week I'll have some coding time, fingers crossed	02:14
SteveA	matsubara: i spoke with kiko, and you have other things to do. i'll get someone else to do it.	02:14
matsubara	From the QA side, while triaging I noticed bug 43263. Rosetta can't handle Dapper Universe packages, so is it difficult to add some page that tell people to not report bugs asking to add the templates? Currently users end up in a page that tells them to ask the inclusion of the template via Rosetta list or reporting a bug.	02:14
matsubara	I'd like to suggest that malcc be assigned to bug 44914, since he's working on soyuz and he could do that while getting confortable with the code.	02:14
Ubugtu	Malone bug 43263 in rosetta "No translatable templates for Dapper Universe packages" [Normal,Rejected] http://launchpad.net/bugs/43263	02:14
spiv	matsubara: 31479 is on my todo list, but I'm unlikely to get to it until late next week.	02:14
Ubugtu	Malone bug 44914 in soyuz "Updade soyuz tests to use Zope 3.2 style " [Normal,Confirmed] http://launchpad.net/bugs/44914	02:14
malcc	I'm happy to take 44914	02:14
kiko	matsubara, great suggestion!	02:15
kiko	carlos, what do you say about dapper/universe?	02:15
kiko	malcc, thanks!	02:15
carlos	matsubara: well, the thing is that edgy will have universe imported	02:15
carlos	matsubara: we are going to add a feature to solve the problem that prevented us to import universe	02:16
SteveA	bug 31479	02:16
Ubugtu	Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Normal,Confirmed] http://launchpad.net/bugs/31479	02:16
carlos	I'm preparing an announcement about dapper translations, I will add there an explanation about it anyway and jordi should add an entry to our FAQ explaining it	02:16
carlos	jordi: ^^^	02:17
jordi	explaining wghat?	02:17
jordi	oh I see	02:17
jordi	that dapper has no universe in rosetta	02:17
jordi	okie dokie	02:17
carlos	right	02:17
matsubara	carlos: great. shouldn't be a problem then. and edgy will open soon, right?	02:17
carlos	jordi: thanks	02:17
carlos	matsubara: as soon as dapper is released	02:17
jordi	yeah, we hope the edgy process will be smooth from the beginning	02:18
kiko	okay then.	02:18
SteveA	matsubara: anything else?	02:18
matsubara	I'm done SteveA , thanks	02:18
SteveA	thank you matsubara	02:18
cprov	malcc: glad you assume 44914, i can help, since there is a lot and I need to learn more about new test style	02:18
SteveA	* Outstanding sysadmin requests	02:18
SteveA	6	02:19
SteveA	5	02:19
SteveA	4	02:19
SteveA	3	02:19
stub	shipit urls	02:19
SteveA	2	02:19
SteveA	stub: what's that?	02:19
stub	Which is new, but I suspect urgent	02:19
SteveA	got an RT number?	02:19
stub	No - lifeless CC'd it.	02:19
spiv	pushsftp log file access (rt #8372)	02:19
stub	And I can't mention details in public	02:19
SteveA	stub: i saw that karl fixed some vhost thing recently. is that it?	02:20
kiko	stub, hasn't it been handled yet?	02:20
spiv	It's progressed slightly since last week, but it's still outstanding.	02:20
SteveA	spiv: when do you want rt 8372 to be done by?	02:20
stub	Oh... seems to be working now.	02:20
spiv	SteveA: sooner rather than later ;)	02:20
SteveA	spiv: when will you start work on that stuff?	02:21
SteveA	like, monday, tuesday?	02:21
spiv	SteveA: early next week would be great.	02:21
stub	shipit seems to be ready to announce then.	02:21
SteveA	okay	02:21
SteveA	MeetingAction: stevea to ask admins about rt 8372 to see if they can finish it before tuesday	02:21
SteveA	* Production and staging (stub)	02:21
stub	Production was updated to HEAD about 10 hours ago by lifeless. This was primarily to get shipit-for-dapper landed. I believe we are still waiting for new DNS changes and Apache rewrites done before we can announce it is open and the new surprises.	02:22
stub	Staging is currently not being updated daily for shipit testing. Please let me know if I can switch the updates back on.	02:22
stub	Erm... ignore the 'still waiting' but	02:22
stub	bit	02:22
salgado	stub, yes, you can swith the updates back	02:22
stub	ta	02:22
kiko	yeah, shipit's already live	02:22
SteveA	on all hosts?	02:22
SteveA	all domains rather	02:22
salgado	all	02:22
kiko	yes	02:22
salgado	we even have requests from different domains	02:22
SteveA	cool	02:23
kiko	amazing	02:23
kiko	lifeless, Znarl, salgado: outstanding work	02:23
SteveA	carlos: you have the translation priority stuff that needs landing still	02:23
carlos	SteveA: it's on PQM again	02:23
kiko	SteveA, I think that could wait till next tuesday?	02:23
SteveA	okay. so, we'll want that cherrypicked when it lands	02:24
kiko	I mean, we will have updates to go in by then	02:24
carlos	SteveA: lifeless offered to cherry pick it	02:24
SteveA	great	02:24
SteveA	kiko: please talk with me about that after the meeting	02:24
SteveA	* Are we all using bzr and bzrtools from dapper (kiko)	02:24
kiko	so, Are We?	02:24
kiko	I am	02:24
bradb	yar	02:24
carlos	I am	02:25
BjornT	me too	02:25
mpt	me	02:25
stub	yer	02:25
malcc	Yup	02:25
spiv	yep	02:25
jamesh	yeah	02:25
SteveA	ii bzr 0.8-0ubuntu1 bazaar-ng, the next-generation distributed v	02:25
SteveA	ii bzrtools 0.8.1-0ubuntu1 Collection of tools for bzr	02:25
ddaa	yup	02:25
ddaa	well	02:25
kiko	I know salgado and matsubara aren't but we will move them to dapper this week.	02:25
ddaa	not bzrtools	02:25
salgado	not the most recent one, but I'll upgrade right away	02:25
SteveA	(I ran: dpkg -l bzr bzrtools )	02:25
salgado	we're using a two weeks old version, or something like that	02:25
SteveA	kiko: done?	02:26
kiko	SteveA, yeah.	02:26
SteveA	thanks kiko	02:26
SteveA	* Status of bugwatches work (bjorn)	02:26
=== ddaa rm's his bzrtools symlink
BjornT	ok	02:27
BjornT	One branch (bugwatches-rework) I haven't been able to merge due to test failures in 30-mergepeople.txt. With that branch, a branch which is up for review, the bug watches work as according to the discussion in "Re: Immutable upstream task".	02:27
BjornT	When everything is merged i'm going to ask mpt to take a look at the UI, i'm sure it can be improved.	02:27
BjornT	kiko: btw, you were going to fix bug 42573, how's that going?	02:27
Ubugtu	Malone bug 42573 in malone "Look in the debbugs archive when syncing bug watches" [Critical,Confirmed] http://launchpad.net/bugs/42573	02:27
kiko	BjornT, I'll have time for coding this week, previous weeks have been very busy	02:27
BjornT	cool	02:27
kiko	BjornT, one question is: did you unconflict and attempt to remerge again?	02:27
BjornT	kiko: i'm resolving conflicts now, i'll try to merge again soon.	02:28
SteveA	BjornT: if 30-mergepeople.txt fails again, please discuss it right away with me/stub	02:28
BjornT	will do	02:28
kiko	BjornT, okay. I'd like to know if 30-mergie fails again	02:28
SteveA	i may need to put some tasks aside and do some sqlobject spelunking	02:28
=== SteveA moves on
SteveA	* Result of converting to knits (steve)	02:29
SteveA	any feedback on using bzr now that we've converted to knits?	02:29
kiko	knits are the future!	02:29
bradb	the speed improvements have so far been very encouraging	02:29
cprov	bradb: +1	02:29
ddaa	got a rsync-like performance on a test I ran this morning	02:30
kiko	ddaa, for push you mean?	02:30
ddaa	(daily update of rocketfuel-built)	02:30
ddaa	kiko: for pull	02:30
kiko	rspush worked for me -- push did not	02:30
salgado	push did work for me	02:30
bradb	m etoo	02:30
spiv	kiko: interesting, someone should talk with you after the meeting and figure out why.	02:30
mpt	Can someone help me push after the meeting? (I'm not strong enough)	02:30
jamesh	working fine for me	02:30
carlos	I guess we could do a bzr merge against rocketfuel instead of getting a local branch first, right?	02:31
cprov	yes, me too. progress bar still a bit obscure	02:31
ddaa	carlos: ?	02:31
mpt	there's a progress bar??	02:31
carlos	ddaa: instead of fetching rocketfuel-build	02:31
carlos	s/build/built/	02:31
SteveA	who will help mpt after the meeting?	02:32
carlos	ddaa: we could do a merge using sftp now, right?	02:32
ddaa	carlos: ha, yes	02:32
ddaa	carlos: looks like it would perform reasonably	02:32
kiko	I think it's very fast	02:32
ddaa	though I still find rocketfuel-built useful for keeping in touch with config changes	02:32
lifeless	ddaa: for those of you in europe. latency will still make the brazilians and australians cry	02:32
ddaa	carlos: looks like it would perform reasonably for us who live on the right continent	02:33
carlos	ok	02:33
kiko	ha ha	02:33
=== SteveA will find someone to help mpt, after the meeting
SteveA	moving on...	02:33
SteveA	* Keep, Bag, Change	02:33
ddaa	got one	02:33
ddaa	CHANGE: remove the redundant cruft from the launchpad configs. Only keep config entries for the machines where a system is deployed.	02:34
mpt	CHANGE: stop mailing me translation import statistics every day	02:34
mpt	It's interesting information, but it should be on Launchpad (/distros/ubuntu/+translations), so non-Launchpadders can read it and Launchpadders don't have to	02:34
kiko	KEEP: translation import statistics! I definitely want to have that logged daily	02:34
kiko	it is vital information for keeping track of how the Dapper import/export process is working	02:35
SteveA	change: use topics for the launchpad list	02:35
mpt	So, why not on Launchpad?	02:35
=== slux [n=antti@82-203-196-131.dsl.gohome.fi] has joined #launchpad
carlos	mpt: it will not make sense when all things are done	02:35
kiko	mpt, it's a little more complicated than that. if you are curious /msg carlos after the meeting.	02:35
mpt	ok	02:35
ddaa	KEEP: fast review	02:35
=== SteveA does a countdown
slux	how am I supposed to add comments to bugs on launchpad? clicking the link at the end of the page just jumps to the beginning...	02:35
SteveA	8	02:35
SteveA	7	02:36
ddaa	posted a cscvs review request yesterday, got a replay today. Still one outstanding though :)	02:36
SteveA	6	02:36
kiko	slux, what browser? javascript on or off?	02:36
SteveA	5	02:36
SteveA	4	02:36
SteveA	3	02:36
ddaa	BAG: sourcecode/ breakage AGAN	02:36
SteveA	2	02:36
lifeless	ddaa: bjornt just woke up ;)	02:36
SteveA	1	02:36
slux	kiko, Firefox 1.0.8	02:36
SteveA	done.	02:36
slux	breezy's latest	02:36
=== niemeyer [n=niemeyer@200.138.41.159] has joined #launchpad
kiko	slux, JS off by any chance?	02:36
SteveA	kiko, slux: the channel is about to become very noisy	02:36
SteveA	you may want to continue elsewhere	02:36
SteveA	* Three sentences	02:37
SteveA	go ahead, state your sentences	02:37
mpt	DONE: MaloneSimplifications fixes, PageHeadings spec, bugfixes, knits	02:37
mpt	TODO: land MaloneSimplifications(!!!), portlet trimming, menus, specs	02:37
mpt	BLOCKED: no	02:37
stub	TODO: text searching, unless preempted by basic Rosetta RSS or impossible-sql-query-problem	02:37
ddaa	DONE: switched to importd/cscvs coding	02:37
ddaa	TODO: bugfixes to seamlessly handle CVS repo migrations, a ton of cscvs cleanups, bzr-native imports	02:37
ddaa	BLOCKED: bzr test failures blocks sourcecode/ merges _AGAIN_	02:37
stub	DONE: Mainly production stuff and did something nasty to my wrist	02:37
stub	BLOCKED: Nope	02:37
salgado	DONE: ShipItForDapper, some small changes on the mirror prober	02:37
slux	kiko, it's on	02:37
salgado	TODO: Finish the new custom-request page for shipit and get it on production	02:37
salgado	BLOCKED: No	02:37
jamesh	DONE: supermirror pull list stuff, sprint scheduler work, convert to knits, WorkingWithSharedRepositories documentation, code reviews	02:37
jamesh	TODO: finish sprint scheduler work, code reviews	02:37
jamesh	BLOCKED: no	02:37
BjornT	DONE: improved the bug watch widgets. bug fixes. reviews.	02:37
BjornT	TODO: Work on my assigned bugs list, fixing the most important ones.	02:37
BjornT	BLOCKED: can't merge bugwatches-rework branch due to 30-mergepeople.txt failure.	02:37
matsubara	DONE: oops report analysis, bug triage, oops bugs	02:37
matsubara	TODO: more of the same	02:37
matsubara	BLOCKED: no	02:37
carlos	DONE: PoMsgSetPage, API to add potemplate RSS, import queue review, bugs #35631, #38472, #44529, #37078, #41071, debugged and fixed a bug with the batching code while using it with POMsgSetPage	02:37
carlos	TODO: Fix tests after the migration of POMsgSetPage to the standard batching code, finish #35631 and a set of easy to fix bugs noted at https://wiki.launchpad.canonical.com/CarlosPerelloMarin, migrate translations from breezy to dapper	02:37
carlos	BLOCKED: No	02:37
Ubugtu	Malone bug 35631 in rosetta "Karma handling on Rosetta is broken" [Major,In progress] http://launchpad.net/bugs/35631	02:37
Ubugtu	Malone bug 38472 in amarok "Korean instead of Kurdish imported into Rosetta" [Normal,Unconfirmed] http://launchpad.net/bugs/38472	02:37
Ubugtu	Malone bug 44529 in rosetta "Translation import queue query needs validation." [Normal,Rejected] http://launchpad.net/bugs/44529	02:37
malcc	DONE: Learnt more, fixed some bugs, finished startup admin	02:37
Ubugtu	Malone bug 37078 in rosetta "+admin page for IPOTemplate is not working for Rosetta experts" [Major,Fix committed] http://launchpad.net/bugs/37078	02:37
Ubugtu	Malone bug 41071 in openoffice.org "All ooo-translations are overridden by the English originals" [Normal,Fix released] http://launchpad.net/bugs/41071	02:37
lifeless	DONE: knit rf upgrade, various bzr tweaks and improvements.	02:37
lifeless	TODO: travel finalisating, europython talk abstract	02:37
lifeless	BLOCKED: No	02:37
jamesh	kiko: with JS turned off, the form would never get hidden	02:37
bradb	DONE: Laptop died. Various bug fixes. Spent some time on implicit subscriptions.	02:37
bradb	TODO: Land implicit subs. Fix OOPS bugs as they appear.	02:37
bradb	BLOCKED: No.	02:37
malcc	TODO: Learn more, fix more bugs, sprint with cprov next week	02:37
kiko	DONE: finished perf reviews, helped ShipIt definitions and rollout, upgrade trees, production report, architecting.	02:37
malcc	BLOCKED: No.	02:38
jordi	DONE: list Email, imports of new templates	02:38
spiv	DONE: bug 44182, bug 44183, worked on bug 41414, reviews, knit upgrade, started ubuntu wiki stuff.	02:38
spiv	TODO: ubuntu wiki stuff, make importd tests (and thus check_merge) pass with bzr 0.8, sftp server bugs.	02:38
spiv	BLOCKED: No.	02:38
Ubugtu	Malone bug 44182 in launchpad-bazaar "supermirror branch puller leaves empty branch when initial mirroring fails" [Major,Fix committed] http://launchpad.net/bugs/44182	02:38
kiko	TODO: coding! some minor reviews and assist shipit post-rollout, catch up with team activity	02:38
Ubugtu	Malone bug 44183 in launchpad-bazaar "supermirror branch puller does not preserve source branch format" [Major,Confirmed] http://launchpad.net/bugs/44183	02:38
Ubugtu	Malone bug 41414 in launchpad-bazaar "supermirror-branch-puller ignores format changes" [Major,Confirmed] http://launchpad.net/bugs/41414	02:38
SteveA	DONE: management, menus, review	02:38
SteveA	TODO: menus, management, various	02:38
SteveA	BLOCKED: no	02:38
jordi	TODO: clear Needs_Review in the queue, pending teams creations	02:38
kiko	BLOCKED: various email responses by stub, SteveA, cprov and others	02:38
jordi	BLOCKED: no	02:38
kiko	BLOCKED: on jamesh updating the error reports cron-runner too	02:38
cprov	DONE:archive-cruft-check redesign, queue-ui, various pending fixes in buildd-UI	02:39
cprov	TODO: sprint with malcolm, PPA design consolidation	02:39
cprov	BLOCKED: none	02:39
SteveA	kiko: please state your blocked issues in more detail	02:40
stub	I haven't got any kikograms flagged for response	02:40
jamesh	kiko: I'll look at getting the weekly report thingee done tonight	02:40
kiko	SteveA, I can't remember all of them, but off the top of my head: experimental server, database removal analysis for source package names, some database optimization queries I sent in...	02:41
stub	Oh - bogus sourcepackage stuff	02:41
kiko	there are other things, I need to look at my sent-mail	02:41
kiko	yeah	02:41
kiko	stub, that's sore because the distro guys are very inconvenienced by this	02:41
stub	I responded to experimental server	02:41
kiko	only you	02:41
kiko	- write access to staging	02:42
kiko	- milestones and upstreams	02:42
salgado	mpt, can you have a quick look at bug 5812? (I'm sure you'll know what I can use to avoid the issue I mentioned in the last comment)	02:42
salgado	https://launchpad.net/bugs/5812	02:42
stub	I never wanted the sourcepackagename table in the first place ;)	02:43
kiko	heh	02:43
kiko	- ppa-ng tables	02:43
SteveA	it's almost meeting ending time	02:43
kiko	(please please help with that)	02:43
kiko	(it is my coffin)	02:43
SteveA	okay, that's it	02:44
SteveA	not even time for a countdown-of-dooom	02:44
kiko	okidokie	02:44
SteveA	MEETING ENDS	02:44
SteveA	thanks everyone	02:44
SteveA	mpt: will you do the meeting summary again this week?	02:44
mpt	naturally	02:44
ddaa	lifeless: you might have noticed that the bzr test suite fails in pqm	02:44
SteveA	thanks mpt	02:44
ddaa	that is blocking the cscvs merges, AGAIN	02:44
lifeless	ddaa: well, as bzr.dev is managed by pqm, I haven't noticed that.	02:45
SteveA	spiv, jamesh, ddaa, lifeless: would one of you please help mpt with bzr push	02:45
jamesh	SteveA: okay	02:45
cprov	stub: would be nice if you can comment the sql view solution proposed by kiko for ppa-ng, is it feasible ?	02:45
SteveA	thanks jamesh	02:45
lifeless	ddaa: spiv and I are working on this. I have some branches to publish for him.	02:45
ddaa	lifeless: I'll forward you the failure	02:45
kiko	cprov, I'm trying to avoid our funeral earlier!	02:45
stub	kiko: I only have the sourcepackagename query from you. I don't have a record of ppa-ng (or even know what the abbeviation stands for)	02:45
ddaa	mpt: SteveA: I need to have lunch now	02:45
kiko	stub, you got email on it though: Subject: REVIEW: cprov/ppa-ng	02:46
SteveA	stub: i have a phone call to make, but can we talk on skype after that about the data disordering issue?	02:46
jamesh	stub: personal package archive - next generation	02:46
stub	SteveA: ok	02:46
kiko	stub, the email starts by saying	02:46
SteveA	ta	02:46
kiko	Daniel, Stuart, I need some advice from you below on how we can reduce	02:46
kiko	the impact of this change. Full diff:	02:46
slux	hm, the firefox should be pretty much stock, only unusual thing about it is that it's locked down for public access	02:46
mpt	brb	02:46
stub	found ppa-ng message	02:47
kiko	slux, it's odd because it appears that javascript is broken. can you check the javascript console, clear it, and reload the page?	02:47
kiko	stub, do you filter stuff that is directly To: you?	02:47
stub	kiko: No - just gives me duplicates and makes my life hard	02:47
kiko	stub, when I add you to the To: it's because I expect you to read it as directed to you	02:48
=== ddaa -> lunch
cprov	stub: good, looking forward to your comments, maybe we can sort this out easily exploring SQL views	02:48
kiko	otherwise I'd just leave the standard CC:s	02:48
kiko	because I know you subscribe to everything	02:48
kiko	stub, is there another technique I should use? forward you emails?	02:49
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
stub	kiko: No - I read them. I don't always respond - most of the time I'm CC'd other people answer queries or I'm not actually needed.	02:49
kiko	stub, your opinion is one that I highly value, so I usually hang on waiting for an answer from you	02:50
mpt	Can anyone help me with bzr push?	02:52
kiko	mpt, what happens?	02:52
jamesh	mpt: what did you try, and what error did you get?	02:52
LarstiQ	only with non-launchpad specific issues	02:52
mpt	jamesh: I lost my Internet connection part-way through pushing. When I try again I get "bzr: ERROR: Lock error: File 'branch-lock' already locked", even after "bzr break-lock" (which produces no output).	02:54
lifeless	mpt: do bzr break-lock URLYOUWEREPUSHINGTO	02:54
=== jamesh has flashbacks of arch
slux	kiko, if using the chrome url to access the console is acceptable, I didn't get anything in there when reloading the page...	02:56
mpt	that seems to be working, thanks lifeless	02:56
mpt	Is it a bug that break-lock doesn't return a proper error?	02:56
kiko	slux, yeah, it's accessible. and you say javascript is running? what happens when you click on a status line in the table at the top of the page?	02:56
jamesh	mpt: if you ran "bzr break-lock" without an argument, it would have operated on your local branch	02:57
jamesh	mpt: it then successfully broke the stale locks on that tree (all zero of them)	02:57
mpt	ok, now it's stopped again	02:57
mpt	with exactly the same error	02:57
mpt	bzr: WARNING: This transport does not update the working tree of: sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/	02:58
mpt	bzr: ERROR: Lock error: File 'branch-lock' already locked	02:58
jamesh	mpt: try ssh'ing into chinstrap, and change to the branch directory	02:58
stub	kiko: I don't see why your a) option requires yet another layer of views (securepackagepublishinghistory becomes a view, I think you suggested), when we could just update the existing views on securepackagepublishinghistory	02:58
mpt	jamesh: done	02:58
jamesh	mpt: does "ls .bzr/branch-lock/" show anything?	02:59
kiko	stub, some of the queries are directly on SSPPH and SBPPH.	02:59
mpt	mpt@chinstrap:/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/.bzr $ ls branch-lock	02:59
mpt	branch-lock	02:59
mpt	that's all	02:59
lifeless	mpt: 'ls' please	02:59
kiko	stub, and those queries would still need to be band-aided	03:00
stub	kiko: The fallout from doing it would be a pain anyway, as any updates would need to be refactored to use the underlying table (unless I went sick on table rules, which I'd rather not)	03:00
mpt	mpt@chinstrap:/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/.bzr $ ls -l \| grep lock	03:00
mpt	-rw-rw-r-- 1 mpt warthogs 0 May 14 09:55 branch-lock	03:00
mpt	-rw-r--r-- 1 mpt warthogs 0 May 18 07:12 branch-lock.write-lock	03:00
slux	kiko, if you mean clicking on the link under "Affects", a form for changing the bug details appears on the page	03:00
stub	Cause we don't have updatable views	03:00
lifeless	mpt: this branch is in 0.7 firmat	03:00
lifeless	format	03:00
lifeless	mpt: you need to perform the same upgrade procedure you did on your devel machine, on chinstrap	03:00
kiko	stub, no, we'd change all queries to use the view, and leave inserts inserting into the right table	03:00
lifeless	then it will all work better	03:00
mpt	oh, foo	03:00
kiko	stub, as it works today for other views.	03:00
lifeless	right now, you should rm branch-lock.write-lock	03:01
kiko	stub, the main difference being that the SSPPH and SBPPH table queries would be done on the views.	03:01
jamesh	mpt: okay. try this: change to the /home/warthogs/archives/mpt/launchpad directory and move 2006-03-MaloneSimplifications out of the way	03:01
slux	clicking the link at the end of the page makes "Virhe: icon.getAttribute("src") has no properties	03:01
slux	Lhdetiedosto: https://launchpad.net/@@/launchpad.js	03:01
jamesh	mpt: then "cp -a /home/warthogs/archives/rocketfuel.knit/launchpad/devel 2006-03-MaloneSimplifications"	03:01
slux	" appear (sorry for the newlines)	03:02
jamesh	mpt: that'll give you a rocketfuel branch at the right location	03:02
lifeless	jamesh: wrong tree	03:02
jamesh	lifeless: oh?	03:02
lifeless	jamesh: /home/warthogs/archives/rocketfuel/launchpad/devel	03:02
lifeless	that .knit one is going to be deleted RSN	03:02
jamesh	lifeless: well, the "cp" trick won't work for that one because it is in a repo (last I checked)	03:02
=== beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
lifeless	jamesh: true. So use branch!	03:03
mpt	cancel the cp?	03:03
lifeless	mpt: no need, it will work ok.	03:03
lifeless	its just out of date now	03:03
jamesh	mpt: nah.	03:04
jamesh	lifeless: it is close enough though	03:04
mpt	ok	03:04
kiko	stub, can you consider that and follow-up via email?	03:04
=== mpt -> food, brb
kiko	slux, how odd.	03:04
jamesh	mpt: now on your local machine, run "bzr push --overwrite sftp://chinstrap.ubuntu.com/home/..."	03:04
stub	kiko: I'm seeing a choice between complicating the data model or complicating the code. I'm leaning towards complicating the code, because the data model in this area is already too complex. The existing views were justified because the queries were just getting too complex and because grabbing wrong rows would be a security hole (with embargod stuff).	03:05
slux	"https://launchpad.net/@@/launchpad.js" is the source of that error	03:05
stub	kiko: Splitting the tables might be an option	03:05
slux	Line 155	03:05
jamesh	slux: is there any other earlier errors?	03:06
kiko	stub, complicating the code.. seems to be a non-option. did you look at the diff?	03:06
kiko	stub, the risk and potential for us missing or getting a callsite wrong is /very/ large	03:08
kiko	stub, this code is not unit-tested.	03:08
kiko	(and yes, that is being addressed, but more slowly than ppa-ng is going it appears)	03:08
stub	What is the risk?	03:08
cprov	kiko: yes, I agree with you on this point, code is already enough complicated & untested.	03:08
slux	jamesh, I'm getting some uncaught exceptions, NS_ERROR_XPC_BAD_CONVERT_JS in the console, it's not just that page though	03:08
kiko	stub, did you /read/ the patch?	03:09
stub	ie. What could happen if code thought a personal package archive was not personal? Something that shouldn't getting rolled out into the official release?	03:09
stub	I'm reading it	03:09
jamesh	slux: try this: open the JS console and clear all the messages. Then reload the bug page and try to expand the comment box	03:09
cprov	stub: system break down, data model corruption andso on	03:09
jamesh	slux: that way you'll only have the messages from the LP bug page	03:09
=== Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad
salgado	BjornT, around?	03:10
slux	jamesh: what should expand the comment box? the link that jumps to the start of the page and is labeled "add comment to this bug"? :P	03:10
kiko	stub, getting something wrong could range from disaster to bad	03:10
=== aa__ [n=ali@host81-153-29-123.range81-153.btcentralplus.com] has joined #launchpad
kiko	slux, yes. that link shouldn't behave that way, though.	03:10
jamesh	slux: yeah.	03:11
slux	jamesh: doing that results in the first icon.getattribute error and that exception	03:11
jamesh	slux: I'm wondering if the javascript run when the page loads is failing	03:11
jamesh	slux: are there any other messages?	03:11
slux	jamesh: nope	03:11
cprov	stub: a noise in the current publication system has extremelly bad consequences over the distro team, mirrors, etc and it's hard to detect in the model (remember dup librarian filenames took 3 days to debug)	03:11
jamesh	slux: that's weird. the img element it is looking up is created in the onload handler	03:12
stub	Do personal package archives need all that embargo and security stuff?	03:12
stub	cprov, kiko: ^^	03:12
kiko	stub, probably not.	03:12
jamesh	slux: do you see a little arrow next to the "Add comment to this bug" link?	03:12
cprov	stub: no, it's not strictly necessary	03:12
stub	Might it be necessary? I'm thinking about the pros and cons of splitting the personal stuff from the .... erm... impersonal?	03:13
slux	jamesh, just the text	03:13
kiko	stub, it might be a nice-to-have feature but is not really necessary	03:13
kiko	given the fact that embargo only really makes sense for stuff that is going through a security process	03:14
kiko-afk	I need to skip out for 30m for an appointment, but email is appreciated	03:14
malcc	If we stick with one table, can we reduce the risk of old-school queries by implementing PPA with an existing field, eg having a new distrorelease name for my personal version of dapper?	03:14
kiko-afk	or cprov can keep it	03:14
malcc	We already know the code doesn't muddle up different distros	03:14
jamesh	slux: there is meant to be an arrow pointing to the right next to the link, that changes to a down arrow when the form gets expanded	03:15
kiko-afk	malcc, mmmm. it would mean a new distrorelease entry, which is dangerous.	03:15
SteveA	stub: call in 15 mins?	03:15
stub	SteveA: ok	03:15
cprov	stub: by being personal we can also model it _private_ and it will reach some level of security	03:15
kiko-afk	well, not dangerous per se, but certainly causes the data model to become weaker in semantic	03:15
malcc	kiko-afk: That seems to be the underlying tradeoff here, to choose a different data model than the most semantically clear one, to try to mitigate the risks from the code change	03:16
slux	jamesh, right. the only thing between the comment boxes and the footer is the link that reads "Add comment to this bug", there's nothing but whitespace on either side of it or between footer/comment boxes and it	03:16
cprov	malcc: kiko is right, since even PPA packages are target to an existent distrorelease	03:16
kiko-afk	malcc, yes, you're right. I'm mainly proposing using views to try and mitigate the risk, but...	03:16
slux	so I guess I'm not seeing all I should be for some reason..	03:17
kiko-afk	slux, can we see a screenshot?	03:17
kiko-afk	anyway, bbiab	03:17
malcc	cprov: Yes, it would effectively mean giving distroreleases parents which are other distroreleases, so my personal dapper becomes semantically a child of the main dapper	03:17
malcc	Anyway I less than half have a clue about this data model so I'm just making stuff up here	03:18
malcc	Although the advantage of implementing PPA as a tree in distrorelease would be I could make a personal version of your personal version of dapper...	03:18
mpt	heh	03:18
mpt	jamesh: bzr: ERROR: No repository present: 'sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/'	03:19
cprov	malcc: that's the derivation model, which overkill for PPA, since includes specifics semantics for archive publication, domination and etc, that are not necessary for PPA.	03:19
BjornT	hi salgado	03:20
slux	jamesh, kiko: http://lib2.vaasa.fi/shot.png	03:20
malcc	cprov: Hmm, ok, but if we need that model anyway, we can turn bits of it off for PPA and only have to implement one model	03:20
malcc	cprov: Otherwise we implement two systems, one for distro derivation the big way, and one for distro derivation on a small scale for PPA	03:21
cprov	malcc: and also improve things we don't like from the current publication model but we can't experiment in the main publication tables (like apt-ftparchive dependency and filesystem based archive)	03:22
mpt	lifeless: --^	03:23
=== carlos -> lunch
carlos	later	03:23
mpt	Any idea about fixing that error?	03:23
cprov	malcc: yes, having two system for the same issue freaks me out, fixing bugs twice would be utterly distressing	03:24
ddaa	bah, dapper bzrtools does not have my switch plugin	03:24
=== ddaa re-enables local bzrtools
malcc	cprov: I need to read around this issue more, I'm just starting. But all my instincts are telling me PPA is a special case of derivation and we should implement this once only	03:24
cprov	malcc: after pondering a lot, I'm really inclined to use the SQL view approach and deal with complex DB arreangement instead of be in risk of break the code or having two models for the same feature	03:26
cprov	malcc: I'm glad that you interested and aware of this topic, I think it'll be the main topic of our sprint. Would you like to face this problem with me ?	03:27
malcc	cprov: Yes, I think this is the ideal problem for us to work on together	03:27
SteveA	stub: i'm running skype	03:27
mpt	lifeless / spiv: By the way, if rocketfuel.knits is going away RSN, the "To push a standalone knit branch to chinstrap the first time" instructions on RocketfuelToKnits should be updated	03:28
lifeless	jamesh: can you finish helping mpt out ?	03:29
lifeless	jamesh: its 2330 for me	03:29
ddaa	mpt: why use standalone branches at all?	03:29
ddaa	at least for lauchpad	03:29
mpt	ddaa: Because I haven't had repositories fully explained to me yet, and I'm doing one thing at a time	03:29
cprov	malcc: great, I'll do some reserch on writable SQL views, but first of all, we needs to reorganize the spread queries on SSPPH/SBPPH, currently it's awkward how we do this.	03:30
ddaa	mpt: let's go to #bzr, and I'll give you as full an explanation as you wish	03:30
spiv	mpt: fixed, thanks.	03:30
mpt	ddaa: ok, how about tomorrow? It's 1.30am, and I just want to push this branch while people are here	03:31
ddaa	if you prefer	03:31
mpt	In my current state, if you explained repositories to me I'd have forgotten by tomorrow anyway :-)	03:32
ddaa	there's really not much to understand	03:32
=== mpt wonders if rm-ing the branch on chinstrap, then following spiv's new instructions, will work
=== mpt tries
=== Who_ [n=jonny@194-247-228-106.dynamic.dsl.as9105.com] has joined #launchpad
Who_	kiko-afk: are you around?	03:38
ddaa	heya, somebody up for a quick review? Got a branch fixing the annoying logging in the importd test suite.	03:43
ddaa	mh, gotta admit sftp push is not terribly fast yet	03:44
kiko-afk	Who_!	03:44
ddaa	ha, my rocketfuel repo was still weave :)	03:45
Who_	kiko: did you get my email?	03:46
kiko	Who_, I did, I need to tackle my inbox shortl	03:46
kiko	y	03:46
Who_	yea, that's fine - I had to get the email address off Launchpad and wasn't 100% certain I'd got you :P	03:47
kiko	you got me!	03:47
Who_	well I'll wait my turn for your time then. Thanks very much :)	03:48
kiko	thanks	03:48
=== kiko gets the lowercase failure
slux	oh well, ended up adding the comment on a different system that had ffox 1.5	03:55
kiko	slux, that actually worked?	03:56
slux	kiko, yeah	03:57
=== Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad
slux	wonder if it does on a stock breezy badger with 1.0.8... this one should be rather close to that...	03:58
kiko	slux, we use breezy here and no problems, so I don't think so	03:59
slux	kiko, it's really strange then.. the only customization I've done to this one is a firefox.js that has some of the prefs set as locked	03:59
kiko	any prefs that are worth mentioning?	04:00
slux	kiko, I don't know really... the only javascript related stuff is the firefox javascript popup prevention etc.	04:04
spiv	slux: hmm, maybe it's possible that popup prevention interferes with some onload javascript that page depends on...	04:05
dilys	Merge to devel/launchpad/: [r=salgado] make bugtasks editable if they don't have a bugwatch. some other fixes as well. (r3569: Bjorn Tillenius)	04:06
kiko	yes!	04:07
kiko	yes!	04:07
kiko	yes!	04:07
kiko	my patch is a winner :)	04:07
kiko	slux, how about trying that firefox.js in the newer version and seeing if it also breaks?	04:08
kiko	SteveA, so it appears my patch may have helped the 30-mergie	04:08
=== mdz [n=mdz@201.160.20.139.cableonline.com.mx] has joined #launchpad
slux	kiko, now that I found the correct lockdown file and removed it for a test I found what disables it	04:12
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
slux	kiko, it's simply preventing javascript from changing images (the last checkbox in the js permission ffox preferences)	04:13
kiko	aha	04:13
kiko	slux, would you be able to file a bug on that, explaining how to reproduce?	04:13
SteveA	kiko: so, you added some gc stuff	04:15
kiko	I did indeed	04:16
SteveA	kiko: so i reckon it may be an sqlobject/sqlos object's connection issue	04:16
kiko	even more than the recommended amount	04:16
kiko	it went well over the RDA	04:16
SteveA	ODed on OJ	04:16
slux	sure, if that's needed... quite straightforward though, 5 clicks or so :P	04:17
kiko	slux, thanks -- we are ODing on tasks right now	04:17
mpt	eh	04:20
mpt	What should .bzr/parent contain for Launchpad branches?	04:21
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
kiko	mpt, sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel	04:22
ddaa	without trailing newline	04:23
ddaa	actually	04:23
mpt	thanks	04:23
lifeless	mpt: .bzr/branch/parent	04:23
ddaa	on knit branches it's not there anymore	04:23
lifeless	mpt: .bzr/parent is not used nomore	04:23
lifeless	goodnight all	04:23
mpt	So the error message is out of date?	04:23
ddaa	as lifeless said, except if your branch is a light checkout is actually removed one more level	04:23
mpt	"Please identify where you want submitted merges to occur in .bzr/parent (or use bzr pull --remember)"	04:23
ddaa	hu?	04:24
ddaa	Where does that come from?	04:24
mpt	oh, never mind	04:24
mpt	that's from the publish script, not part of bzr	04:24
mpt	ok, now I'm cooking	04:26
ddaa	what's the dessert?	04:26
ddaa	boys'n berries ice cream?	04:26
mpt	Dessert is PQM	04:31
mpt	It's berry-colored at the moment	04:31
mpt	http://pqm.launchpad.net/	04:32
mpt	Is that bug 42866?	04:34
Ubugtu	Malone bug 42866 in pqm "Web UI dies with NotImplementedError if a "patch" command is in the queue" [Normal,Unconfirmed] http://launchpad.net/bugs/42866	04:34
=== mpt reports a bug anyway
stub	carlos: That first DELETE is being really slow because you are joining with the Person table in the subquery, but the Person table isn't in the WHERE clause (or being used). So the subquery is returning several orders of magnitude more rows than it needs to.	04:34
carlos	stub: really?	04:35
carlos	:-(	04:35
spiv	mpt: It looks like the same traceback as 42886, anyway.	04:35
carlos	could you fix it or should I do it and send you it back?	04:35
mpt	bug 42886	04:35
Ubugtu	Malone bug 42886 in hotkey-setup "ibm-acpi volume control unpredictable" [Normal,Unconfirmed] http://launchpad.net/bugs/42886	04:35
spiv	mpt: er, 42866 :)	04:35
=== mpt will assume spiv means 42866 :-)
stub	carlos: Yup. Nasty bug because there is no warning ;)	04:35
mpt	So now I can't tell whether MaloneSimplifications is in the queue or not	04:36
=== aa_ [n=ali@host81-153-29-123.range81-153.btcentralplus.com] has joined #launchpad
mpt	anyway, bedtime	04:37
=== mpt [n=mpt@203.109.220.214] has left #launchpad ["Ex-Chat"]
spiv	mpt: damn.	04:37
=== ddaa would really like pMock in launchpad
spiv	Well, for the record, PQM is processing a branch from carlos, and has two more in the queue, then a mystery command that breaks PQM.	04:38
kiko	spiv, it just breaks the HTTP. it's not a big deal	04:39
ddaa	or mock, or some or other mock-object implementation	04:39
spiv	Which means mpt's merge isn't in the queue.	04:39
ddaa	kiko: what would you think of that?	04:39
spiv	Or, if his is the mystery command, it may as well not be because the odds of mpt meaning anything other than star-merge are low :)	04:39
kiko	ddaa, you mean, something better than Snapshot?	04:40
ddaa	snapshot?	04:40
ddaa	kiko: I mean something that provides a mock-object implementation	04:41
SteveA	ddaa: what is this mock-object stuff for?	04:41
stub	carlos: Delete took 10 seconds with it removed ;)	04:41
ddaa	so we would not have to implement our own half-assed mock objects everytime we need it	04:41
=== WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad
=== fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad
=== Bluekuja [n=andrea@ubuntu/member/bluekuja] has joined #launchpad
=== havarha [i=havarha@dragon.idi.ntnu.no] has joined #launchpad
=== siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad
=== JanC [n=janc@lugwv/member/JanC] has joined #launchpad
=== LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad
=== lifeless [n=robertc@dsl-152.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad
=== zakame [n=zakame@ubuntu/member/zakame] has joined #launchpad
=== jmg [n=jmg@shinobi.thoughtcrime.org.nz] has joined #launchpad
=== lamont [n=lamont@mib.fc.hp.com] has joined #launchpad
SteveA	what do you mean by "mock object" exactly?	04:41
ddaa	SteveA: it's for unit testing	04:41
SteveA	is there a project you can point me at to look at these?	04:42
carlos	stub: wow....	04:42
malcc	SteveA: Put mock objects into google, a lot has been written about them (mostly in the Java world)	04:43
ddaa	http://c2.com/cgi/wiki?MockObject	04:43
SteveA	ddaa: i mean, a specific implementation you think we should consider	04:43
ddaa	I have experience with no specific implementation so far	04:43
SteveA	ok	04:44
ddaa	a couple of candidates could be http://pmock.sourceforge.net/ and http://python-mock.sourceforge.net/	04:44
SteveA	i have discussed with bjorn and (i think) stub in the past about using our interfaces to create mock objects	04:44
SteveA	the interfaces describe the boundaries of units	04:44
ddaa	SteveA: I have a lot of uses for mock objects in non zopy stuff, too	04:44
SteveA	and so by using interfaces, we can get reasonable mock behaviour, without needing to say a great amount	04:45
ddaa	now that I'm starting to grok unit testing, I'm finding uses for them in cscvs and importd	04:45
SteveA	ddaa: you may use interfaces to describe any python systems you like	04:45
SteveA	it is a descriptive idea, not something that a system must conform to in order for you to use this approach	04:45
ddaa	I'm very far form convinced that interface are sufficient, and that it's worth adding them just for mock object testing purposes	04:46
ddaa	actually, except for security wrapping purposes, I am not yet convinced of the usefulness of interfaces except in some very spethial applications (zope and twisted have a lot of implementations and adapters, so that make sense there)	04:47
ddaa	even in launchpad, I see we use interfaces for two purposes: security wrapping and automatic form generation	04:47
LarstiQ	mock objects aren't only good	04:47
ddaa	and I'd rather have the automatic form generation stuff in the content or browser classes	04:48
malcc	Zope interfaces aren't interfaces in the conventional sense, they provide behaviour as well as describing API	04:48
stub	carlos: Does https://chinstrap.ubuntu.com/~dsilvers/paste/fileAXE2I7.html look sane?	04:48
ddaa	malcc: also, I'm not really convinced of the interface for the sake of defining interfaces in general python programming	04:49
ddaa	looks to me like an attempt to force some kind of static type checking onto python	04:49
carlos	stub: hmm, it's a bit difficult to see it, more or less, yes, I don't see any high number that should not be there	04:49
=== stub commits
carlos	stub: if you are 100% sure that only translations from rosetta-admins were removed... go ahead	04:49
carlos	removed == DELETE ...	04:49
SteveA	malcc: how do you mean "they provide behaviour" ?	04:50
ddaa	SteveA: well, the next time the issue pops up, I'd really like a mock object implementation that integrates usefully with unittest	04:50
malcc	SteveA: Just yesterday I made a change to how one of our forms validated. I did so by editing an interface class, but my change made no change to any APIs, it just changed the behaviour of some objects	04:50
SteveA	ddaa: file a spec on launchpad	04:51
malcc	SteveA: As in a certain type of database object changed how it validated its fields	04:51
SteveA	that's interesting. i wouldn't call the constraint in a schema "behaviour"	04:52
carlos	stub: thank you for your help	04:52
SteveA	certainly changing an interface can change the behaviour of parts of the system that look to that interface to inform how they should behave	04:52
SteveA	this is the same as in other systems that allow introspection of interfaces	04:52
SteveA	for example, removing an attribute from an interface may have the effect in the whole application of removing a field from a form	04:53
malcc	SteveA: Yes, most systems with interfaces allow this kind of thing, eg in Java you can include constants in interfaces if you choose, and then make code elsewhere conditional on them	04:53
SteveA	you can make java code conditional on the API of an interface too	04:53
malcc	SteveA: Many coding guidelines call for not doing this, as it's not what interfaces are "supposed to be for"	04:53
SteveA	although, because of compile time type-checking, this is less common except on systems that allow very dynamic assembly of parts	04:54
malcc	SteveA: I think this is another one for over-a-beer	04:54
carlos	jordi: around?	04:54
ddaa	SteveA: too much meta-work	04:54
SteveA	i don't think this is a property of interfaces as such	04:54
SteveA	but more a property of the system that makes use of them	04:54
=== ddaa goes back to teach importd how to properly deal with repo migrations
malcc	Hmm, interesting statement!	04:55
SteveA	so i would not say "an interface provides behaviour". i would say "an interface specifies or constrains the behaviour of other parts of the system"	04:55
malcc	Surely interfaces are given their properties by how they fit into the system around them?	04:55
SteveA	i don't know what you're saying, so i'll leave this for the beer.	04:56
SteveA	i'll note that one thing i'll be doing on launchpad very soon is making it so that we don't need to duplicate method signatures and attributes between implementation and interfaces	04:57
SteveA	yet, we'll still have interfaces	04:57
ddaa	okay, so that's a very different sort of interface than in java	04:57
malcc	Interesting. How will the implementing class indicate which method in the interface it is providing the implementation for, without duplicating the signature?	04:58
carlos	SteveA, kiko-fud: Now that I fixed the bug that required me to be a Launchpad admin, I just removed myself from that team	04:58
SteveA	ok	04:58
SteveA	thanks	04:58
carlos	np	04:59
SteveA	ddaa: i agree that there are some differences than in java. but i think my statement holds true for java too.	04:59
carlos	lifeless: http://pqm.launchpad.net/ is broken atm	05:00
SteveA	malcc: this margin is not large enough for the full explanation.	05:01
SteveA	malcc: so, it's either when the code lands, or over a beer...	05:01
malcc	SteveA: Cool	05:04
spiv	carlos: It'll right itself as soon as it processes the request that's breaking the web UI.	05:14
carlos	spiv: it's already fixed	05:15
carlos	spiv: so it's a problem with test output?	05:15
spiv	Oh, so it is.	05:15
spiv	Interesting.	05:15
spiv	carlos: Did you get a big colourful traceback?	05:16
carlos	yes	05:16
spiv	I doubt it's the test output then :)	05:16
=== doko [n=doko@201.160.19.41.cableonline.com.mx] has joined #launchpad
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
stub	cprov: ~stub/launchpad_prod.20060518.dump on mawson	05:27
cprov	stub: great, could you paste the restore cmdline if it is special ? (don't remember if simply pg_restore will work appropriately)	05:29
stub	cprov: pg_restore --no-acl --no-owner --dbname=whatever ~stub/launchpad_prod.20060518.dump	05:30
stub	Then upgrade.py, fti.py and security.py as normal	05:30
cprov	stub: ahh --no-acl --no-owner, remeber now, thanks	05:31
=== sabdfl [n=mark@201.160.17.131.cableonline.com.mx] has joined #launchpad
malcc	I'm using this: python test.py -vvf canonical pagetests/soyuz to run pagetests, and also editing them at the same time, as it takes a while. The test runner is choking on the .#... files emacs leaves lying around. Is there an easy fix? Pls don't say vi.	05:47
SteveA	there is code in the test runner that attempts to find stuff while ignoring junk files	05:48
SteveA	so it would be a reasonable patch in our test runner and upstream in zope to make it ignore those files too	05:48
SteveA	i think you can also configure emacs to leave the turds in a different place	05:49
carlos	bradb, BjornT: How could I know why rosetta-admins is subscribed to https://launchpad.net/distros/ubuntu/+source/xfce4-terminal/+bug/41791 ?	05:49
Ubugtu	Malone bug 41791 in xfce "Xubuntu-Dapper Drake (AMD64): Missing Terminal RC File" [Unknown,Unknown]	05:49
malcc	SteveA: Thanks	05:49
carlos	the activity log does not show anything...	05:50
bradb	carlos: indeed, hm, that's a bit curious	05:51
carlos	I'm not completely sure, but I think this is not the first time it happens	05:51
bradb	oh, it's because you are the upstream registrant	05:51
SteveA	malcc: although actually... maybe it is just our test runner	05:52
bradb	carlos: https://launchpad.net/products/xfce/	05:52
carlos	bradb: ?	05:52
carlos	I see	05:52
carlos	that's confusing...	05:52
SteveA	malcc: because the way we do pagetests is not how they're done in zope	05:52
bradb	you, i.e., the rosetta admins	05:52
carlos	anyway, I will change the ownership to the register team	05:52
carlos	thanks for checking it	05:52
malcc	SteveA: Thanks, I found the emacs turd-moving recipe and I'm going to go that route	05:52
bradb	no prob	05:52
spiv	malcc, SteveA: the file to look at is lib/canonical/launchpad/ftests/test_pages.py	05:55
spiv	It just filters a listdir with "filename.lower().endswith('.txt')".	05:55
=== aa__ [n=ali@host81-153-29-10.range81-153.btcentralplus.com] has joined #launchpad
spiv	So if emacs is just prefixing its backup files and not suffixing, then I can see how that would confuse it.	05:56
=== sits [n=sits@cpc3-cwma2-0-0-cust739.swan.cable.ntl.com] has joined #launchpad
=== carlos -> out
carlos	see you!	05:56
dilys	Merge to devel/launchpad/: [r=kiko] Implemented POTemplate priorities to help our users to know what's more important to get translated. This feature has been implemented by Mark (r3570: Carlos Perello Marin, Mark Shuttleworth, Carlos Perell Marn)	06:02
=== bradb & # lunch
=== aa_ [n=ali@host81-153-25-44.range81-153.btcentralplus.com] has joined #launchpad
=== glatzor [n=sebi@ppp-82-135-8-223.mnet-online.de] has joined #launchpad
spiv	Good grief. "bzr viz" is about 3000 pixels wide for launchpad...	06:22
=== BjornT [n=bjorn@195.182.78.95] has joined #launchpad
kiko	spiv, that's hard work. :)	06:24
kiko	BjornT, you got lucky :)	06:24
BjornT	kiko: yeah :) hard to tell if it was your fix that did it, or something else, though.	06:26
kiko	BjornT, what are you talking about? it is OBVIOUS that my fix is PERFECT!!1	06:27
=== salgado can bet that kiko's fix is a sleep(5)
kiko	no it contains advanced gc.collect() calls too	06:29
kiko	ddaa, ping?	06:30
=== acko88 [n=alexanda@212.62.51.89] has joined #launchpad
=== ddaa is singing in the shower
kiko	ddaa, vostok's loadavg is high. check it out	06:31
Znarl	ddaa : CRITICAL - load average: 161.65, 160.64, 159.85	06:32
=== tambaqu1 [n=tambaqui@201.160.17.131.cableonline.com.mx] has joined #launchpad
ddaa	wow :)	06:32
=== acko88 [n=alexanda@212.62.51.89] has left #launchpad []
ddaa	Znarl: I can have a look, but your judgement is a good as mine. I do not own the code that runs there (spiv and salgado do) and I do not have any priv to manage it.	06:33
jordi	carlos: here	06:33
=== auth00 [n=auth@evot.olf.sgsnet.se] has joined #launchpad
ddaa	kiko: I know what it is	06:33
ddaa	I bet that a new bzrlib was rolled out	06:33
ddaa	sigh	06:33
kiko	rock and rollit	06:33
=== tambaqu1 [n=tambaqui@201.160.17.131.cableonline.com.mx] has left #launchpad []
ddaa	there's a couple of bugs that cause it to mirror a bunch of knit branches as weave	06:34
ddaa	thus doing knit->weave conversion	06:34
ddaa	which is a bad idea	06:34
ddaa	thus meltdown	06:34
ddaa	I made noises about not rolling out the new bzr before that was fixed	06:34
ddaa	a think that can be done to help is put down the branch puller now and downgrade bzrlib until the problems are fixed	06:35
ddaa	https://launchpad.net/products/launchpad-bazaar/+bug/44183	06:36
Ubugtu	Malone bug 44183 in launchpad-bazaar "supermirror branch puller does not preserve source branch format" [Major,Confirmed]	06:36
kiko	ddaa, is that something znarl can do?	06:36
ddaa	https://launchpad.net/products/launchpad-bazaar/+bug/44182	06:37
Ubugtu	Malone bug 44182 in launchpad-bazaar "supermirror branch puller leaves empty branch when initial mirroring fails" [Major,Fix committed]	06:37
ddaa	https://launchpad.net/products/launchpad-bazaar/+bug/41414	06:37
Ubugtu	Malone bug 41414 in launchpad-bazaar "supermirror-branch-puller ignores format changes" [Major,Confirmed]	06:37
ddaa	kiko: whatever, it's not going to break it anymore...	06:37
ddaa	kiko: combine these three bugs, and do a careless rollout of the new bzr, and you get the current situation	06:38
ddaa	kiko: though stub or lifeless would be best qualified to do it	06:38
ddaa	lifeless was aware of the problem, but we disagreed on the seriousness of the issue	06:40
spiv	ddaa: Are you sure that's the issue? The new bzr isn't in rocketfuel yet.	06:41
kiko	ddaa, are you sure that's what's up?	06:41
ddaa	not absolutely sure	06:41
kiko	walk the mile	06:41
ddaa	spiv: but the pqm failure I got when trying to merge cscvs the last time suggest the new bzr is in rocketfuel	06:41
spiv	So a "careless rollout" is unlikely to have changed the bzr in use.	06:41
spiv	ddaa: It isn't.	06:41
spiv	ddaa: I suspect the testsuite of the old bzr in rocketfuel is unfortunately senstive to the system bzr being upgraded.	06:42
ddaa	mh	06:42
ddaa	kiko: okay, so I'm probably wrong	06:43
ddaa	and then I've no clue	06:43
kiko	well, I did say walk the mile :)	06:43
ddaa	what does that mean?	06:43
kiko	go the distance to debug what is wrong	06:43
dilys	Merge to devel/launchpad/: [rs=kiko] Improved security adapters for DistroReleaseQueue and view/template code (r3571: Celso Providelo)	06:43
ddaa	I'm not going to have the time.	06:43
kiko	rock on cprov	06:43
kiko	ddaa, the loadavg is blowing up /now/ though	06:43
ddaa	I about to leave for a school reunion	06:43
kiko	well, what should znarl do meanwhile	06:44
spiv	ddaa: As soon as bzr in rf is upgraded, I will be merging a bugfix for 44183, the code part of 44182 is already in rf, and I have already half-done the fix for 41414. You can relax :)	06:44
ddaa	spiv: if you can land the fix for 41414 before rollout, there should be no need for manual fixup, that would help my peace of mind a lot	06:45
spiv	(well, assuming reviews don't get in the way, but I don't expect that to be a significant impediment)	06:45
=== ddaa goes to have a look on vostok
=== mpt [n=mpt@203.109.220.214] has joined #launchpad
kiko	cprov-lunch, we will need to make fixing up the source package name creation a priority today	06:46
spiv	It's my bedtime... g'night.	06:46
kiko	night spiv	06:46
kiko	cprov, I am doing some research as we speak	06:47
cprov	kiko: did you discovered something new ?	06:47
ddaa	Znarl: there seems to be a crazy moin load there	06:48
cprov	s/discovered/discover	06:48
kiko	cprov, well, stub cleared out the DB, and I am going to snapshot the list of bogus SPNs now and in 2 hours	06:48
kiko	cprov, are there uploads being processed in the next two hours?	06:48
cprov	kiko: sure, do you want to stop it ?	06:49
ddaa	Znarl: any clue what could be causing that?	06:49
kiko	cprov, no, let them run	06:49
ddaa	spiv: what does the listbranches script do?	06:49
kiko	cprov, we have a log of everything processed, right?	06:49
Znarl	ddaa : Checking.	06:49
spiv	ddaa: I don't think I've heard of that one.	06:50
cprov	kiko: yes, in lp_archive mailbox in drescher	06:50
kiko	cprov, that's perfect. let's wait for now.	06:50
ddaa	spiv: there's also seem to be a very busy sftp server	06:50
ddaa	spiv: I have no idea what could be the cause	06:50
cprov	kiko: understood, i'm going to office soon	06:50
kiko	cprov, okay, awaiting your arrival, I already have the data I needed.	06:51
ddaa	spiv: listbranches seems to be old supermirror	06:51
spiv	ddaa: That's interesting. Neither do I at the moment, but I should be getting access to the logfiles soon, which may tell me something.	06:51
spiv	ddaa: jblack code then? I know nothing of it.	06:51
ddaa	I think we are just being brutaly DOSed	06:51
=== spiv -> really sleep
cprov	kiko: how do you mean ? did you identify the bogus spn creation ?	06:51
=== Who_ [n=jonny@194-247-228-106.dynamic.dsl.as9105.com] has joined #launchpad
ddaa	Znarl: if you have a network activity log somewhere, it might tell something interesting	06:52
kiko	cprov, I have at least times and names that were created	06:52
kiko	that should allow us to debug better	06:52
ddaa	maybe a spam harvester run amok	06:52
cprov	kiko: right	06:53
Znarl	ddaa : Restarting apache will kill off all these old moin processes.	06:53
ddaa	oh, right, the moin thingies have completely crazy cpu times	06:53
ddaa	up to 99 mins	06:54
Znarl	Yes, moin is running as part of wiki.gnuarch.org.	06:54
ddaa	Znarl: is that regular cgi?	06:55
ddaa	because 99 mins cpu time for a regular one-off moin.cgi process is a caracterised DOS	06:55
=== lbm [n=lbm@0x555298ca.adsl.cybercity.dk] has joined #launchpad
Znarl	ddaa : Yes, I've never seen moin do this before.	06:57
=== mpt sighs at conflicts
ddaa	Znarl: okay, now that we have that one out of the way, it looks like old supermirror is burning	06:58
ddaa	it looks like something is wrong the the cron	06:59
ddaa	there are two cron.daily runs atm	07:00
ddaa	and large number of listbranches cronjobs too	07:00
ddaa	should probably be safe to kill all the listbranches	07:00
Znarl	ddaa : You'd like me to kill off the listbranches?	07:01
ddaa	mh	07:01
ddaa	maybe not necessary	07:01
ddaa	I know that jblack stuff is designed to work in massively parallel fashion	07:02
ddaa	so the "thundering herd of cronscripts" thing is probably normal	07:02
ddaa	Znarl: though you probably want to disable updatedb from the cron.daily	07:02
ddaa	especially because the old supermirror involves an insane filesystem hierarchy	07:03
cprov	Znarl: RT #9209, let me know when it's done, thank you	07:03
ddaa	Znarl: I think the load should decrease to something reasonable now	07:04
Znarl	ddaa : OK, lets leave it for a few hours and see if it recovers instead of killing?	07:05
ddaa	yup	07:05
Znarl	Load seems to be staying around 85 presently.	07:05
ddaa	now, it's steadily decreasing	07:05
=== Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #launchpad
ddaa	Znarl: please disable updatedb too	07:07
ddaa	it's a waste of i/o bandwidth on this system	07:07
Znarl	ddaa : OK, good idea.	07:08
Znarl	ddaa, kiko : Thanks for your help.	07:10
Kamion	I'm getting timeouts on all my attempts to fetch translations at the moment; is this known?	07:10
Kamion	(OOPS-138C492 e.g.)	07:10
Ubugtu	https://chinstrap.ubuntu.com/~jamesh/oops.cgi/138C492	07:10
Kamion	it's rather urgent as I need to finalise translations before distro RC freeze	07:11
kiko	let's see	07:11
kiko	Kamion, the language table is locked, apparently.	07:15
kiko	Kamion, have you retried since and obtained a more recent OOPS?	07:15
kiko	Kamion, what are you trying to do, btw?	07:15
kiko	view the desktop pots?	07:16
Kamion	I retried a few times ...	07:16
Kamion	fetch https://launchpad.net/distros/ubuntu/dapper/+source/ubiquity/+pots/desktop and https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer which aren't subject to language packs, I need to integrate them into the packaging	07:16
Kamion	OOPS-138A573	07:16
Ubugtu	https://chinstrap.ubuntu.com/~jamesh/oops.cgi/138A573	07:16
kiko	Kamion, so basically download those translations?	07:16
Kamion	yes	07:16
kiko	yes, language table locked. how strange.	07:16
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad
kiko	Kamion, so far no luck. I'm a bit confused because a lock could not hold on to this table for so long, I thought	07:23
=== cpro1 [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad
kiko	carlos, stub: ping?	07:23
stub	yo	07:27
kiko	stub, can you check up on kamion's oops? Language table seems to be locked...	07:28
kiko	https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-05-18/C492	07:28
kiko	https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-05-18/A573	07:28
kiko	been locked for at least 20 minutes, stub	07:28
stub	Try again - I was dropping a large index	07:28
salgado	kiko, http://shipit.async.com.br/requests	07:29
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
kiko	salgado, connection refused.	07:30
salgado	had to restart, sorry.	07:30
kiko	stub, works now, thanks.	07:31
salgado	it's up again	07:31
kiko	Kamion, should be working, sorry	07:31
kiko	s/All/Any	07:32
kiko	oh mmm	07:32
Znarl	ddaa : CRITICAL - load average: 26.02, 41.00, 70.44	07:32
ddaa	looks like it's returning to normal	07:32
Kamion	kiko,stub: works now. thanks!	07:33
kiko	Kamion, sorry bout that	07:33
kiko	ddaa, good work	07:33
Kamion	no problem	07:33
=== tambaqui [n=tambaqui@201.160.20.139.cableonline.com.mx] has joined #launchpad
Kamion	hmm, publisher blowing up now	08:07
Kamion	http://librarian.launchpad.net/2735165/u65u22gL5U0AUkGbYhKvKVa4gGS.txt	08:07
=== sits [n=sits@cpc3-cwma2-0-0-cust739.swan.cable.ntl.com] has left #launchpad []
Kamion	I think I might just retry that, looks like it could be transient	08:07
kiko	Kamion, yes, just retry.	08:12
kiko	somebody's working on the importqueue	08:12
Kamion	it's running now and apparently working	08:15
Kamion	sorry to be are-we-there-yet, it's a rather stressful day in distro-land	08:15
=== tambaqui [n=tambaqui@201.160.17.131.cableonline.com.mx] has joined #launchpad
=== AlinuxOS [n=AlinuxOS@d83-176-106-124.cust.tele2.it] has joined #launchpad
=== tambaqui [n=tambaqui@201.160.20.139.cableonline.com.mx] has joined #launchpad
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad []
kiko	Kamion, no worries, help as I can	08:59
=== jmg [n=jmg@shinobi.thoughtcrime.org.nz] has joined #launchpad
=== lbm [n=lbm@0x555298ca.adsl.cybercity.dk] has joined #launchpad
cprov	kiko: miscreated spn bug reproduced, do you want do discuss the fix ?	09:47
kiko	yep	09:47
kiko	I have the fix I think	09:47
kiko	come on down	09:47
=== Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has left #launchpad []
cprov	kiko: yup	09:50
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad
=== doko [n=doko@201.160.20.136.cableonline.com.mx] has joined #launchpad
=== tambaqui [n=tambaqui@201.160.20.139.cableonline.com.mx] has joined #launchpad
mdke	spiv: around?	10:40
bradb	kiko: do you have time for a drive-by for bug 33882? it's a bug mark pointed out the other day.	10:41
Ubugtu	Malone bug 33882 in malone "Critical bugs are listed as 8 in the side bar, but there actually aren't any" [Normal,In progress] http://launchpad.net/bugs/33882	10:41
=== jinty [n=jinty@212.Red-83-54-75.dynamicIP.rima-tde.net] has joined #launchpad
kiko	bradb, yes I do.	10:49
bradb	kiko: cool, https://chinstrap.ubuntu.com/~dsilvers/paste/filec9m2wg.html	10:51
kiko	bradb, can we convert getSearchFilterUrl to have explicit params instead of the **?	10:53
kiko	the ** is what let the bug appear.	10:53
kiko	that's my main reservation.	10:53
bradb	Hm? The bug appeared because some URLs and some search count queries were just wrong.	10:53
=== sistpoty [n=sistpoty@ubuntu/member/sistpoty] has joined #launchpad
kiko	- unassigned='on')	10:54
kiko	bradb, is unassigned='on' still valid? see what I mean?	10:54
sistpoty	hi folks	10:54
bradb	kiko: Ok. Is it sufficient to define enough of the API to work for what it's currently being used for? (i.e. just status, assignee, etc.)	10:56
kiko	bradb, just do it all!	10:56
kiko	what difference should it may?	10:56
kiko	make	10:56
bradb	just seems to be adding unneeded code	10:57
kiko	hmm	10:57
kiko	do you understand what I'm suggesting?	10:57
kiko	removing **extra_params	10:58
bradb	yep	10:58
bradb	replacing it with explicit kw args	10:58
kiko	right	10:58
bradb	I'm just wondering if we need to define all the possible filter args, even though this few only uses like three or four of them	10:58
bradb	s/this few/this view/	10:59
kiko	let's see	10:59
kiko	oh	11:00
kiko	ISWYM	11:00
kiko	is there a place where we can read the standard form schema from?	11:00
bradb	this portlet doesn't have a form. can you elaborate on what you have in mind?	11:02
kiko	well	11:02
kiko	I would like us to be able to determine which options are valid	11:02
kiko	instead of supplying anything via **extra_params	11:02
kiko	if you have a set of fixed options	11:02
kiko	you could validate	11:02
kiko	to see if an extra_param had been supplied which you did not expect	11:03
bradb	i'm suggesting something like def getSearchFilterURL(self, assignee, status, ...):	11:03
kiko	bradb, okay. so what are you asking, then? :)	11:03
bradb	if doing the above for just the params we use is ok, or if you want it to be def getSearchFilterURL(self, assignee, status, every, other, possible, param, that, exists, even, though, we, dont, use, them, here):	11:04
kiko	oh!	11:04
kiko	no, just the params we use of course	11:04
bradb	ok :)	11:04
kiko	if you wanted to do the complete solution	11:04
kiko	you could try and obtain a list of such params	11:05
kiko	and then, well, use kwargs and validate the kwargs with them. but that's fluff.	11:05
kiko	good work	11:05
kiko	bbiab	11:05
bradb	cheers	11:05
=== aa__ [n=ali@host81-153-24-22.range81-153.btcentralplus.com] has joined #launchpad
=== ChanServ [ChanServ@services.] has joined #launchpad
=== tambaqui [n=tambaqui@201.160.20.136.cableonline.com.mx] has joined #launchpad
dilys	Merge to devel/launchpad/: [r=kiko] Fix bug 33882 (Critical bugs are listed as 8 in the side bar, but there actually aren't any) (r3572: Brad Bollenbach)	11:51
Ubugtu	Malone bug 33882 in malone "Critical bugs are listed as 8 in the side bar, but there actually aren't any" [Normal,In progress] http://launchpad.net/bugs/33882	11:51
=== marienz [i=marienz@gentoo/developer/marienz] has joined #launchpad
marienz	I'm probably just being daft, but why does launchpad.net/people/marienz/ tell me "Ubuntero: Not yet"? What's an ubuntero?	11:54
LarstiQ	marienz: someone who has agreed to and signed the code of conduct	11:54
marienz	ahhh	11:55
LarstiQ	marienz: btw, you're not at SANE, are you?	11:55
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
marienz	err	11:55
marienz	what's a SANE? :)	11:55
LarstiQ	marienz: sane.nl	11:56
LarstiQ	sane2006 is taking place this week in Delft	11:56
marienz	ahh, nope	11:56
=== raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad
=== aa_ [n=ali@host81-153-27-115.range81-153.btcentralplus.com] has joined #launchpad
=== LarstiQ_ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad
=== havarha_ [i=havarha@dragon.idi.ntnu.no] has joined #launchpad

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!