[12:04] <zyga> carlos: do you know who is?
[12:04] <carlos> moyogo, yes it's possible
[12:04] <carlos> zyga, jdub
[12:05] <moyogo> carlos: because we aren't that many right now, i'm still waiting for some answers, but even then
[12:05] <zyga> carlos: thanks
[12:05] <moyogo> i think it would be better if we could work on all these languages in 1 single team
[12:06] <zyga> I've **** up my slackware server this morning...
[12:06] <carlos> moyogo, just create the team and send us the name and we will add it to all those languages
[12:06] <zyga> and then I had to leave to work :/
[12:06] <lifeless> morning all
[12:06] <ajmitch> morning lifeless 
[12:07] <moyogo> carlos: i'm confused, don't i request for a team to be created ?
[12:07] <carlos> moyogo, you can create the team yourself
[12:08] <moyogo> carlos: where?
[12:08] <carlos> moyogo, we need to add it to the language inside Ubuntu
[12:08] <lifeless> SteveA_: ping
[12:08] <carlos> moyogo, https://launchpad.net/people/+newteam
[12:08] <moyogo> carlos: thanks
[12:09] <lifeless> doh, sorry about the pqm ui, its up again
[12:20] <moyogo> i guess the best subscription policy is "moderated"?
[12:24] <lifeless> ddaa: want to be a bzr guinea pig - for cscvs ?
[12:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=BjornT, r=carlos for newline test]  Tidies up the translatiion form. Rows now always line up with each other, translator notes and suggestions are presented as proper table rows, and Rosetta is now usable in Konqueror and Safari (fixes bug 2194). (patch-2693: mpt@canonical.com)
[12:25] <ddaa> lifeless: I'm sort of busy with coding launchpad and and teaching niemeyer until UBZ
[12:25] <lifeless> ddaa: indeed, everybody is busy.
[12:26] <ddaa> well, i mean I'm getting behind...
[12:26] <lifeless> ddaa: what I am suggesting is that I convert cscvs in rf to bzr.
[12:26] <lifeless> ddaa: you are clueful enough to tell me about any rocky patches without being blocked
[12:26] <ddaa> I'd rather not, it would be annoying for rollouts...
[12:26] <lifeless> it would mean a lot to me.
[12:27] <ddaa> I'd love to use bzr more, but I'll have to use baz anyway with cscvs for production rollouts.
[12:28] <lifeless> ddaa: I dont understand. This is the final conversion of branches.
[12:28] <lifeless> pqm's 'dists' tree is already converted.
[12:28] <ddaa> Is a bzr on every production system that runs cscvs?
[12:29] <lifeless> ddaa: the dependencies should be by now.
[12:29] <lifeless> ddaa: but we're back into deep dogfood mode, so I fully expect that you and stub and Kinnison will be running bzr from source for a while.
[12:30] <ddaa> That's what I'm doing.
[12:30] <ddaa> The BranchDataStorage work I'm doing with niemeyer is on a throw-away import branch.
[12:30] <lifeless> yes
[12:31] <ddaa> But I'd prefer not adding hair to production importd, especially for some code that if I have to change in the next week, that would be in a big hurry.
[12:31] <ddaa> * next weeks
[12:31] <lifeless> ddaa: I plan to finish converting all branches by my monday night
[12:32] <ddaa> ...
[12:32] <lifeless> ddaa: so you have a choice, be an early adopter and help me get anything missing you need, or dont, and tell me when you notice problems later.
[12:32] <ddaa> Well, I guess the issues I have with the conversion logic do not apply for company code.
[12:33] <lifeless> you and stub are key participants in this, in ensuring you are still able to rollout production updates properly
[12:33] <ddaa> I'm already an early adopter. I'm using bzr for daily development.
[12:33] <lifeless> good
[12:33] <lifeless> but not with pqm, nor all the trees converted.
[12:34] <ddaa> I just want to avoid breaking importd now, while I'm totally focusing on something else.
[12:34] <ddaa> Say
[12:34] <ddaa> I'll do the switch before rolling out BranchDataStorage
[12:34] <ddaa> But if something needs fixing now, I want to be done with it as quickly as possible and go back BDS.
[12:35] <lifeless> ddaa: I know, and that why its important to me that we test this stuff as soon as possible, rather than later
[12:36] <ddaa> If have any say, I'd rather test it later.
[12:37] <lifeless> how much later ?
[12:38] <ddaa> Not before UBZ I'm afraid.
[12:38] <lifeless> well, then I'm pretty sure you do not have a choice.
[12:38] <ddaa> lifeless: this stuff I'm working is what we started in London...
[12:38] <lifeless> yes
[12:38] <ddaa> It's LATE!
[12:38] <lifeless> yes
[12:38] <lifeless> so is converting to bzr.
[12:38] <ddaa> You know, like one year late.
[12:39] <lifeless> yes.
[12:39] <ddaa> Looks like you're not giving me a choice anyway.
[12:40] <lifeless> ddaa: noone in the lp team is getting a choice.
[12:40] <ddaa> Okay. Drop me a mail with what I need to know.
[12:40] <lifeless> if it doesn't work at any step along the way, *then* we'll stop and address issues.
[12:41] <lifeless> ddaa: shorthand is - baz-import on chinstrap using /home/warthogs/source/bzr.integration, then rsync that down to your machine and drop it in instead of your current branch.
[12:41] <ddaa> lifeless: email please
[12:41] <lifeless> ddaa: ok.
[12:42] <lifeless> -> lp list
[12:42] <ddaa> ok
[12:42] <lifeless> I have some things to do today before converting more branches. But tomorrow morning when you getup, cscvs will be in bzr.
[12:42] <ddaa> Anyway, you should be aware that I will probably not have to rollout importd code before UBZ anyway, so that's not making me a very useful ginea pig.
[12:43] <lifeless> stub will be testing too
[12:43] <Ron_o> I'm looking for the free ubuntu cd, and I gave launchpad my email addy so I can do so and I never got an email from the site. What gives? OR will it take some more time?
[12:44] <lifeless> Ron_o: you went to shipit.ubuntu.com ?
[12:44] <kiko> Ron_o, it should arrive shortly -- how long ago was it sent out?
[12:44] <kiko> we had some problem with emails delaying yesterday, but..
[12:44] <Ron_o> about 5 minutes ago.
[12:44] <Ron_o> I was thinking it's automated. :->>
[12:45] <lifeless> Ron_o: it is
[12:45] <lifeless> Ron_o: there was a backlog
[12:45] <Ron_o> we really expect a lot, don't we? lol.
[12:45] <Ron_o> OK.
[12:45] <Ron_o> must be a *huge* backlog.
[12:45] <Ron_o> I'm guessing that my CD will come some time from now.
[12:46] <Ron_o> I actually have the ISO, but my CD-R just went on the blink.
[12:46] <Ron_o> man, I'm really pissed.
[12:46] <Ron_o> talk about irony.. hehe.
[12:47] <kiko> CD-Rs are kinda flaky
[12:47] <kiko> Ron_o, it's odd. so you requested a new account and are still waiting for the account confirmation email?
[12:47] <Ron_o> Yes..
[12:48] <kiko> did you by any chance get your email address wrong?
[12:48] <kiko> I know it sounds silly but..
[12:48] <Ron_o> I typed it in twice.
[12:49] <kiko> what's your email address?
[12:49] <Ron_o> I really don't give that out on open channels.
[12:50] <Ron_o> I tried to private message you but I'm unregistered.
[12:50] <Ron_o> I'm just worried about bots...
[12:50] <Ron_o> I get like no spam. :->
[12:53] <kiko> Ron_o, mail it to kiko@async.com.br
[12:55] <lifeless> sabdfl: so you know, 'dists' is now in bzr.
[12:56] <Ron_o> i just sent: subject line: "Here's my email"
[12:58] <Belutz> why sometimes i get this message when accessing launchpad RequestExpired 
[12:58] <Belutz> A server error occurred. ?
[01:01] <kiko> Belutz, because our server is busted
[01:01] <Belutz> kiko, i see
[01:01] <kiko> (and we are working on making it cope with the traffic :)
[01:01] <Belutz> :)
[01:01] <kiko> Ron_o, hasn't arrived yet.
[01:02] <Ron_o> let me send again.
[01:04] <Ron_o> I just sent again, to here: kiko@async.com.br
[01:04] <Ron_o> maybe it's yahoo, then.
[01:04] <kiko> Ron_o, nothing.
[01:04] <Ron_o> wow..
[01:04] <Ron_o> I don't know what's going on.
[01:06] <Ron_o> I got it.
[01:06] <Ron_o> it must be yahoo.
[01:06] <Ron_o> it's a free account, or maybe they are virus checking or something.
[01:07] <kiko> aha.
[01:07] <Ron_o> kiko, I got lauchpad, just to make sure you know.
[01:07] <Ron_o> thanks.
[01:07] <kiko> Ron_o, sorry?
[01:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  make spec URLs nullable (patch-2694: brad.bollenbach@canonical.com)
[01:15] <AciD> oi
[01:19] <lifeless> garh
[01:19] <lifeless> me -> food
[01:20] <kiko> fala AciD 
[01:20] <kiko> hey Seveas 
[01:21] <Ron_o> I'm signing up to get my free cds.
[01:21] <kiko> I think Ubugtu doesn't recognize bug numbers followed by colons
[01:21] <kiko> Ron_o, okay so far.
[01:21] <Ron_o> Does the PC CD come with the Live CD?
[01:21] <Seveas> g'night all :)
[01:23] <Nafallo> Ron_o: yes
[01:23] <kiko> Ron_o, yes, it does
[01:23] <Nafallo> everything is install+live :-)
[01:23] <Ron_o> thanks..
[01:25] <Ron_o> it's all done.
[01:25] <kiko> Ron_o, so it worked?
[01:25] <Ron_o> Now, I must wait the few weeks.
[01:26] <Ron_o> yah, it worked.
[01:26] <Ron_o> I hope in Ubuntu my CD-R will work.
[01:26] <kiko> email is going out very slowly from this box
[01:26] <kiko> no clue why.
[01:26] <Ron_o> we'll see.
[01:34] <Kinnison> kiko: still wondering about uploaders?
[01:35] <kiko> Kinnison, yes, because I don't know where to put them
[01:35] <kiko> there's maintainership 
[01:35] <kiko> but it's not attached to releases
[01:35] <kiko> it just states the status quo
[01:35] <Kinnison> I'm not sure what you're trying to store and replicate
[01:36] <kiko> Kinnison, it's very simple. There's an Uploaders: line in some Sources.gz stanzas. What do I do with it?
[01:36] <Kinnison> Right
[01:36] <Kinnison> Currently we don't have anything in sourcepackagerelease for it
[01:36] <kiko> right.
[01:36] <Kinnison> if we later want to support it we'll just add it as a column and extract the info from the dsc we store in the dsc column
[01:45] <kiko> Kinnison, hmmm. okay, so it's in the DSC?
[01:47] <Kinnison> dmake_4.3-2.dsc:Uploaders: Chris Halls <halls@debian.org>, Rene Engelhard <rene@debian.org>
[01:47] <Kinnison> docbook-utils_0.6.14-1.dsc:Uploaders: Ardo van Rangelrooij <ardo@debian.org>
[01:47] <Kinnison> dput_0.9.2.19ubuntu3.dsc:Uploaders: Christian Kurz <shorty@debian.org>, Steve Kowalik <stevenk@debian.org>
[01:48] <Kinnison> there's some examples from my uploader test set
[01:48] <Kinnison> dbus_0.36.2-0ubuntu7.dsc:Uploaders: Daniel Stone <daniels@debian.org>, Daniel Silverstone <dsilvers@debian.org>, Sjoerd Simons <sjoerd@debian.org>
[01:48] <Kinnison> one including me :-)
[01:48] <kiko> cool
[01:48] <kiko> Kinnison, does this mean file a bug and move ahead?
[01:49] <kiko> anyway, gone
[01:50] <Kinnison> yes it does
[01:50] <Kinnison> ciao
[01:53] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix some broken links to /+editgpgkeys and also improve some wordings. (patch-2695: guilherme.salgado@canonical.com)
[01:57] <kiko-zzz> rock on salgado
[02:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix some broken links to /+editgpgkeys and also improve some wordings. (patch-2696)
[03:30] <lifeless> stu1: stub ?
[03:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: rs=mdz Fix specification permissions to allow editing by target owners as well as spec owners and launchpad admins (patch-2697: christian.reis@canonical.com)
[03:57] <kiko-zzz> thank god
[03:57] <kiko-zzz> stu1, that's the one to cherry-pick
[04:04] <mdz> what's rs=?
[04:04] <lifeless> rubber stamp
[04:05] <lifeless> 'hey that sounds fine, ok by me without looking at it'
[04:05] <mdz> meaning it's my fault? ;-)
[04:05] <mdz> ok, that's about accurate
[04:05] <lifeless> meaning our pqm policy *OBVIOUSLY* needs a list of who the reviewers are, not just the pattern match.
[04:08] <mdz> so long as I can rubber stamp things that are high priority for Ubuntu ;-)
[04:09] <kiko-zzz> that's the reason why I put rs=mdz
[04:09] <kiko-zzz> I thought it was most appropriate
[04:09] <mdz> I agree
[04:10] <lifeless> mmm, I always understood that r*= was about *review*, not about *who for*.
[04:10] <kiko-zzz> lifeless, rs= is not about review, it's about approval
[04:10] <lifeless> and its entirely important to get it in there fast for ubuntu.
[04:10] <kiko-zzz> r= is about approval though :)
[04:10] <kiko-zzz> err
[04:10] <lifeless> kiko-zzz: rs= is about 'rubber stamped review'
[04:10] <kiko-zzz> no
[04:11] <kiko-zzz> it's rubber-stamped checkin
[04:11] <kiko-zzz> there was no review
[04:11] <lifeless> I know
[04:11] <kiko-zzz> mdz doesn't even know what a security proxy is
[04:11] <kiko-zzz> :)
[04:11] <lifeless> why not [Trivial]  then ?
[04:11] <kiko-zzz> hopefully he will be able to remain ignorant of it 
[04:11] <kiko-zzz> to indicate I had a valid motivation to land something non-trivial
[04:11] <mdz> kiko said "I am going to fix that bug for you" and I thoroughly approved
[04:12] <kiko-zzz> anyway
[04:12] <lifeless> mdz: ack.
[04:12] <kiko-zzz> I'm doing 5 typos a second
[04:12] <kiko-zzz> which means
[04:12] <kiko-zzz> ZZZ time
[04:12] <lifeless> kiko-zzz: go to bed, more rf in bzr tomorrow.
[04:12] <mdz> kiko-zzz: good night and thanks
[04:12] <lifeless> kiko-zzz: dream of rsync
[04:12] <kiko-zzz> enjoy the winter of my absence
[04:12] <mdz> kiko-zzz: I owe you one ubuntu bugfix
[04:12] <mdz> (if at some point in the future a bug should be discovered in ubuntu)
[04:13] <lifeless> gosh, such a thing :0
[06:27] <spiv> lifeless: 25828 andrew    25   0  463m 408m 2388 R 99.8 11.3  86:06.90 python
[06:27] <spiv> lifeless: that importer is pretty resource hungry :)
[06:48] <stub> lifeless: stub
[07:16] <lifeless> stub: so, please read the bottom of RocketFuelSetup
[07:16] <lifeless> stub: and PQM Setup
[07:16] <lifeless> and basically check you can still commit configs
[07:21] <stub> Setting up bzr (0.1.1+20051020-0) ...
[07:21] <stub> Compiling /usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py ...
[07:21] <stub> Sorry: IndentationError: ('unindent does not match any outer indentation level', ('/usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py', 70, 20, ' PLUGIN_TEXT = """\\\n'))
[07:22] <stub> Which causes the install to return an error code
[07:23] <stub> signatures are still borked too (just 0 bytes files)
[07:23] <ajmitch> jbailey probably hasn't signed his archive
[07:25] <lifeless> stub: garh. ok, lets go with integration : http://people.ubuntu.com/~robertc/baz2.0/integration
[07:25] <lifeless> you can pull that with bzr from breezy
[07:25] <stub> I can?
[07:26] <lifeless> yes, choose bzr 0.1.1 from synaptic
[07:29] <stub> Huh. Looks like the daily did install, despite update manager telling me it screwed up
[07:30] <stub> (this all goes rather slowly with a baz merge in the background)
[07:30] <ajmitch> no doubt it'll be half-installed & the postinst will run again next time you touch dpkg
[07:31] <stub> 12:30:53~/src $ bzr --version
[07:31] <stub> bzr (bazaar-ng) 0.6pre
[07:31] <stub> Copyright 2005 Canonical Development Ltd.
[07:31] <stub> http://bazaar-ng.org/
[07:31] <fabbione> lifeless: is cm-0.2 in the incoming queue or does it need NEW love?
[07:31] <ajmitch> good enough to use, anyway :)
[07:31] <lifeless> fabbione: incoming
[07:32] <fabbione> lifeless: ok thanks
[07:32] <lifeless> fabbione: no NEW love needed
[07:32] <fabbione> you mean 0.1p123 ?
[07:42] <lifeless> 0.2-1 it should be
[07:42] <lifeless> does the changelog say 'new upstream', and 'adds python' ?
[07:46] <fabbione> lifeless: dunno.. it's 0.1p123 in incoming
[07:46] <lifeless> garh. I'll slap him I will
[07:46] <fabbione> lifeless: also.. python2.4-cjkcodecs aren't in breezy...
[07:46] <fabbione> only python-2.3
[07:46] <fabbione> is that still a requirement or can it be skipped?
[07:46] <lifeless> it should not depend on cjkcodecs for 2.4, they are rolled into python core
[07:47] <fabbione> than you want to update the wiki :)
[07:47] <lifeless> fabbione: ah.
[07:52] <fabbione> and as stub said.. bzr is borked :)
[07:53] <fabbione>  config-manager (0.1p123-1) unstable; urgency=low
[07:53] <fabbione>  .
[07:53] <fabbione>    * Many new upstream releases
[07:53] <fabbione>    * Incorporate new python version of config manager
[07:53] <fabbione> lifeless: i assume that should be good enough
[07:54] <lifeless> fabbione: sure
[08:01] <fabbione> lifeless: is there any specific reason why we need to sign the pqm key?
[08:03] <stub> lifeless: I don't understand that last section of RocketfuelSetup. It starts with 'Run 'baz inventory -t' to find the nested tree roots. Do a clean checkout of the converted to bzr tree, and move the trees you gather before into the right place', but fail to mention where 'the converted to bzr tree' is or an example of how to 'do a clean checkout' of it.
[08:06] <stub> Also '/home/warthogs/source/bzr.integration/bzr baz-import $ARCHIVENAME $ARCHIVENAME' looks like a typo, or rather risky if we are overwriting the existing archive since there is no mention of backups
[08:08] <spiv> stub: Turns out it does something ok, but it certainly looks scary :)
[08:08] <fabbione> No ID or fingerprint found in the allowed list for this checksum.
[08:08] <fabbione> ********************************
[08:08] <fabbione> INVALID SIGNATURE ON REVISION!
[08:08] <fabbione>   archive: rocketfuel@canonical.com
[08:08] <fabbione>   revision dists--devel--0--patch-121
[08:08] <fabbione>   checksum file: ancestry.gz.checksum
[08:08] <fabbione> ********************************
[08:08] <fabbione> kthxbye
[08:08] <fabbione> that's doing the baz checkout
[08:15] <lifeless> fabbione: you did not import the allcommitters I think
[08:15] <lifeless> fabbione: or you have set a strict policy in your baz
[08:15] <fabbione> lifeless: i am following the wiki step by step
[08:15] <lifeless> stub: ok
[08:15] <lifeless> fabbione: hmm
[08:15] <lifeless> fabbione: cat ~/.arch-params/archives/defaults please
[08:16] <fabbione> cat .arch-params/archives/defaults | grep -v ^#
[08:16] <fabbione> [Signing] 
[08:16] <fabbione> gpg_command=gpg --default-key 63549F8E
[08:16] <sivang> Morning all
[08:16] <sivang> hey fabbione 
[08:17] <fabbione> hi sivang 
[08:17] <lifeless> fabbione: cat ~/.arch-params/archives/rocketfuel@canonical.com
[08:17] <lifeless> fabbione: what wiki page? you should not be dealing with dists in rocketfuel now anyway, unless you made a local dists branch
[08:17] <fabbione> cat .arch-params/archives/rocketfuel@canonical.com | grep -v ^#
[08:17] <fabbione> allowed_ids=pqm@canonical.com
[08:17] <fabbione> when_unsigned=error
[08:17] <fabbione> url=sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/rocketfuel@canonical.com
[08:18] <fabbione> https://wiki.launchpad.canonical.com/RocketFuelSetup
[08:18] <fabbione> lifeless: ^^
[08:18] <lifeless> fabbione: what part of the page are you at?
[08:18] <fabbione> Grabbing the code
[08:18] <fabbione> baz get rocketfuel@canonical.com/dists--devel--0 launchpad
[08:18] <fabbione> i did all the above, step by step
[08:18] <lifeless> fabbione: ok, let me update that
[08:19] <lifeless> spiv: cjkcodecs are in python2.4 core right ?
[08:19] <spiv> lifeless: iirc, yes.
[08:20] <stub> sshchinstrapmkdir-p/home/warthogs/archives/$yourusercode/launchpad -> does $yourusercode mean 'stub' or 'stuart.bishop@canonical.com' ?
[08:20] <lifeless> stub: up to you
[08:21] <lifeless> stub: I use robertc
[08:21] <stub> it will fail if I use the latter since it already exists ;)
[08:21] <lifeless> fabbione: updated
[08:21] <spiv> lifeless: google says yes :)
[08:27] <fabbione> lifeless: so you use bzr to do the first branching and later baz?
[08:31] <lifeless> fabbione: for now, yes
[08:31] <fabbione> ok
[08:32] <stub> The rsync commands should be documented. rsync has dozens of options and I haven't the foggiest what ones bzr cares about.
[08:33] <fabbione> lifeless: 
[08:33] <fabbione> baz branch rocketfuel@canonical.com/launchpad--devel--0 $myarchive/launchpad--devel--0
[08:33] <fabbione> ********************************
[08:33] <fabbione> INVALID SIGNATURE ON REVISION!
[08:33] <fabbione>   archive: rocketfuel@canonical.com
[08:33] <fabbione>   revision launchpad--devel--0--patch-2697
[08:33] <fabbione>   checksum file: checksum
[08:33] <fabbione> ********************************
[08:33] <lifeless> fabbione: you have not got the rocketfuel key 
[08:33] <lifeless> gpg --list-keys | grep pwm
[08:33] <lifeless> *pqm*
[08:33] <fabbione> gpg --list-keys | grep pqm
[08:34] <fabbione> uid                  Patch Queue Manager (Canonical.com arch-pqm) <pqm@canonical.com>
[08:34] <fabbione> yes i do
[08:34] <fabbione> lifeless: again. i am really following the setup step by step
[08:36] <lifeless> fabbione: I believe you
[08:36] <lifeless> fabbione: but common errors first :)
[08:37] <lifeless> fabbione: I'm in the middle of a alate lunch, I'll be back in 20
[08:37] <fabbione> ok
[08:38] <stub> lifeless: pqm is rather stuck. Anything I need to know about the new setup before I kill it?
[08:40] <stub> Hmm... pqm isn't doing anything useful at all, but there are three items in the queue
[08:40] <lifeless> stub: let me see
[08:41] <lifeless> ok
[08:41] <lifeless> its the production config
[08:41] <lifeless> you need to update it to the new format, see development for an example
[08:42] <stub> ok.
[08:44] <fabbione> lifeless: i think i found the problem, but the solution sucks to death
[08:46] <fabbione> basically my set of private keys is big enough to require a --check-trustdb on each operation
[08:46] <fabbione> so by default i disable it and run it manually once in a while
[08:46] <fabbione> baz doesn't like that status, interacting with gpg
[08:46] <fabbione> and it errors out
[08:50] <lifeless> ok, so just do one db check
[08:50] <lifeless> and it will fix it
[08:51] <fabbione> yes i did.. that's how i figured
[08:51] <fabbione> i did the check after signing the key
[08:51] <fabbione> see the error
[08:51] <fabbione> got the checksum file from chinstrap
[08:51] <fabbione> tryed to verify it again
[08:51] <fabbione> see the extra lines from gpg
[08:51] <fabbione> rerun the check
[08:51] <fabbione> make the lines disappear for one operation
[08:51] <fabbione> recheck.. baz branch
[08:52] <fabbione> lifeless: i think you also want to finetune the cacherev on pqm
[08:52] <fabbione> there have been more than 120 commits from the last cacherev
[08:58] <SteveA_> stub: can you cherrypick my steve.alexander@canonical.com/launchpad--trivial--1 branch into production?
[08:59] <lifeless> ok, back
[08:59] <lifeless> fabbione: nah, we're switching very very soon
[08:59] <SteveA_> this adds a robots.txt to shipit, fixes a bunch of broken pages and various other good stuff
[09:00] <fabbione> lifeless: ok...
[09:00] <lifeless> spiv: how are you going with sqlobject ?
[09:00] <stub> SteveA: ok
[09:02] <stub> SteveA: Make sure you land it in rocketfuel too
[09:03] <SteveA_> stub: i think it is already there
[09:04] <SteveA_> although, staging doesn't have that robots.txt either
[09:05] <stub> lifeless: I can't see what has changed in configs/canonical.com/launchpad/development
[09:08] <stub> robots.txt not being there isn't important. 
[09:09] <stub> staging has a static one added by elmo (because we don't want it indexed)
[09:10] <lifeless> stub: 
[09:10] <lifeless> [09:10] <lifeless> --- configs/canonical.com/launchpad/development
[09:10] <lifeless> +++ configs/canonical.com/launchpad/development
[09:10] <lifeless> @@ -1,18 +1,16 @@
[09:10] <lifeless>  # If you update this file, you probably want to update 'staging' too
[09:10] <lifeless>  #
[09:10] <lifeless> -./launchpad    rocketfuel@canonical.com/launchpad--devel--0
[09:10] <lifeless> -./launchpad/lib/sourcerer      rocketfuel@canonical.com/sourcerer--devel--0
[09:10] <lifeless> -./launchpad/lib/hct            rocketfuel@canonical.com/hct--devel--1
[09:10] <lifeless> -./launchpad/lib/psycopgda      rocketfuel@canonical.com/psycopgda--test--3.0
[09:10] <lifeless> ....
[09:10] <lifeless> +./launchpad    arch://rocketfuel@canonical.com/launchpad--devel--0
[09:10] <lifeless> +./launchpad/lib/sourcerer      arch://rocketfuel@canonical.com/sourcerer--devel--0
[09:10] <lifeless> +./launchpad/lib/hct            arch://rocketfuel@canonical.com/hct--devel--1
[09:10] <lifeless> +./launchpad/lib/psycopgda      arch://rocketfuel@canonical.com/psycopgda--test--3.0
[09:10] <lifeless> stub: its in bzr now too.
[09:10] <lifeless> stub: as per rocketfuel setup
[09:11] <stub> Oh.
[09:11] <stub> SteveA: I can't cherry pick until later sorry
[09:11] <lifeless> stub: I have updated the conversion doco at the bottom of the page
[09:11] <lifeless> stub: rsync examples are now present
[09:12] <SteveA_> stub: hmmm... not landed in RF yet.  i'll get it in there today.
[09:13] <stub> Whats with this 'ubuntu' directory in the docs? Should be 'canonical' ;)
[09:13] <SteveA_> stub: robots.txt wasn't the only change.  the cherrypick fixes many of the top ten errors we're seeing
[09:13] <stub> yup
[09:13] <SteveA_> just, robots.txt is the way i can easily see if it was applied
[09:13] <lifeless> stub: where are you at with bzr, can I help
[09:15] <slomo> does someone know why i get "RequestExpired. A server error occurred. " when trying to load https://launchpad.net/people/motu/+assignedbugs ?
[09:15] <slomo> everything else works
[09:15] <stub> Just trying to work out how the new stuff works so I can work out how to keep it organized
[09:16] <lifeless> stub: ok
[09:16] <lifeless> stub: so lets talk it out
[09:16] <lifeless> stub: the conversion mimics the structure that baz had
[09:16] <stub> 13:37:14~/launchpad/launchpad $ baz merge rocketfuel@canonical.com/launchpad--devel--0
[09:16] <stub> * auto-adding rocketfuel@canonical.com/launchpad--devel--0--patch-2697 to greedy revision library /home/stub/.arch-revlib
[09:16] <stub> * Scanning for full-tree revision .. done.
[09:17] <stub> * from revision library (linking): rocketfuel@canonical.com/launchpad--devel--0--patch-2696
[09:17] <stub> * Applying 1 revision . done.
[09:17] <stub> * Searching for best merge point .....
[09:17] <stub> ***********************************
[09:17] <stub>   CHECKSUM FILE(S) DISAGREE WITH
[09:17] <lifeless> one thing you can do is keep that structure, and work in esentially a copy of the branch all the time.
[09:17] <stub>   DIRECTORY LISTING ABOUT WHAT
[09:17] <stub>   FILES SHOULD BE PRESENT IN
[09:17] <stub>   REVISION DIR OF ARCHIVE
[09:17] <stub>   archive: robert.collins@canonical.com
[09:17] <stub>   revision: launchpad--devel--0--patch-139
[09:17] <stub>   url: sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/robert.collins@canonical.com
[09:17] <stub> ***********************************
[09:17] <lifeless> stub: thats a bit of a bugger. let me see
[09:18] <lifeless> looks good here
[09:19] <fabbione> stub: try to do a gpg --check-trustdb and issue the command again? ;)
[09:19] <lifeless> fabbione: different error
[09:19] <lifeless> stub: I've confirmed its good here.
[09:20] <stub> What should I nuke then?
[09:20] <lifeless> stub: nothing ?
[09:20] <lifeless> stub: have you merged sideways with people ? if not, do merge --star-merge 
[09:21] <stub> I don't think there is anything sideways on this branch (but it goes back a month...)
[09:21] <lifeless> then do that
[09:22] <stub> meanwhile in my other window.... "bzr branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/dists/devel production" just seems to be sitting there having given me no feedback
[09:24] <lifeless> thats good
[09:25] <lifeless> sftp without async -> slow.
[09:25] <lifeless> and while the envelope is different, bzr is still slow there.
[09:26] <stub> ooh... its going now
[09:30] <Keybuk> lifeless: http://www.informit.com/articles/article.asp?p=405513&rl=1
[09:30] <zyga> gaaa
[09:30] <zyga> jbailey: ping
[09:30] <zyga> there is a indentation error in todays bzr packages
[09:31] <zyga> Compiling /usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py ...
[09:31] <zyga> Sorry: IndentationError: ('unindent does not match any outer indentation level',  ('/usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py', 70, 20, ' P LUGIN_TEXT = """\\\n'))
[09:34] <stub> Grrr... bzr by default is using gpg instead of gnome-gpg. And then I Ctrl-C and my terminal goes into that fucked up 'lets not do carriage returns' mode
[09:35] <lifeless> stub: edit ~/.bazaar/bazaar.conf
[09:35] <lifeless> its on the rocketfuel page
[09:36] <stub> No it aint. Only for baz, not bzr
[09:40] <lifeless> Bazaar-NG setup
[09:40] <lifeless> Set your user id and enable signing.
[09:40] <lifeless> mkdir ~/.bazaar
[09:40] <lifeless> echo '[DEFAULT] 
[09:40] <lifeless> email=Firstname Lastname <firstname.lastname@canonical.com>
[09:40] <lifeless> check_signatures=require
[09:40] <lifeless> ' > ~/.bazaar/bazaar.conf
[09:40] <lifeless> say its not so
[09:43] <lifeless> stub: ^^
[09:44] <Keybuk> lifeless: that doesn't say how to use gnome-gpg
[09:44] <lifeless> Keybuk: oh, oops :)
[09:44] <lifeless> gpg_signing_command=gnome-gpg
[09:44] <Keybuk> and the bottom bit on that page is gibberish too
[09:45] <Keybuk> and it tells you how to get bzr set up, and cm, but never to use either of them
[09:45] <lifeless> Keybuk: cm is used higher up the page
[09:45] <lifeless> Keybuk: and so is bzr
[09:45] <Keybuk> it wasn't in the page I read last night
[09:45] <lifeless> gibberish does not help me improve it
[09:46] <Keybuk> ahh, no, you've improved it a lot since last night
[09:46] <lifeless> I do not write well at 2am
[09:46] <Keybuk> no, who does?
[09:47] <Keybuk> should we convert all the branches to bzr now then?
[09:47] <BjornT> slomo: it's a known bug (bug 3310). i'll try to get it fixed today.
[09:47] <lifeless> Keybuk: well, I am converting branches one at a time
[09:47] <Ubugtu> Malone bug #3310: The assigned bugs page triggers RequestExpired Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3310
[09:47] <lifeless> Keybuk: if you have a branch you'd like to convert and test it merges with me, I'm happy to do that
[09:47] <lifeless> would love to in fact
[09:47] <lifeless> I am waiting for spiv at the moment :0
[09:48] <lifeless> oh, I should put bzr in the config.
[09:48] <lifeless> hmm. it will need paramiko too
[09:48] <BjornT> slomo: in the meantime you can go to https://launchpad.net/distros/ubuntu/+bugs?advanced=Advanced and enter motu in the Assignee field (bottom of the page)
[09:49] <slomo> BjornT: thanks :)
[09:50] <spiv> lifeless: Sorry, been doing other things.  I'm kinda lacking any real use for a converted branch atm; the stuff I'm hacking on atm is in launchpad branches.
[09:50] <lifeless> spiv: launchpad converts last of all
[09:50] <spiv> Right.
[09:50] <lifeless> spiv: I want to ensure everything is good first.
[09:50] <lifeless> spiv: so you will be accelerating launchpad in bzr by converting the projects you 'own' - sqlos and sqlobject
[09:51] <spiv> But I don't have any active sqlobject or sqlos branches in my archive.
[09:51] <lifeless> its up to you, I can just switch them and say 'tra la la'
[09:51] <spiv> As far as I can anticipate, further work I'll do on those will start by branching from rocketfuel :)
[09:52] <spiv> So converting my branches in my archive isn't much use to me for testing that.
[09:52] <lifeless> its not about 'work', its about verifying the process
[09:52] <lifeless> I need victims^Wearly adopters
[09:53] <Keybuk> lifeless: one of my keys is missing from allcommitters.gpg
[09:53] <Keybuk> C978C8AE
[09:53] <zyga> Keybuk: hi
[09:53] <lifeless> Keybuk: perhaps, but not one you have committed to rocketfuel with.
[09:53] <lifeless> Keybuk: I can guarantee this ;)
[09:53] <Keybuk> I've committed to my branches with this
[09:53] <zyga> Keybuk: did you do that fanboy applet? :)
[09:53] <lifeless> Keybuk: noone else should depend on it though
[09:53] <Keybuk> zyga: yeah
[09:53] <lifeless> Keybuk: you should naturally import it for yourself.
[09:53] <Keybuk> lifeless: ok, so it's not going to halt the conversion process?
[09:54] <zyga> Keybuk: I was wondering about one thing though... the sysfs path is different here
[09:54] <Keybuk> oh, right, I need to add it to my keyring
[09:54] <Keybuk> zyga: sysfs? procfs! :p
[09:54] <lifeless> Keybuk: it should not for other people. but we'll see
[09:54] <zyga> right!
[09:54] <zyga> I've got /proc/acpi/thermal_zone/THRM/temperature
[09:54] <zyga> I've also added i18n as usual :)
[09:54] <zyga> I'd send you a patch but there seems to be no public svn repo 
[09:55] <zyga> Keybuk: how about a bzr repo? :)
[09:55] <lifeless> zyga: uhm ECHANNEL - thats ubuntu-devel, and the bzr report was #bzr please.
[09:55] <zyga> lifeless: k, sorry
[09:55] <lifeless> np
[09:55] <Kinnison> stub: My merge failed because of a bizarre error:
[09:56] <Kinnison> stub: OperationalError: FATAL:  IDENT authentication failed for user "uploader"
[09:56] <Kinnison> stub: ; used connection string 'dbname=launchpad_ftest user=uploader'
[09:56] <Keybuk> lifeless: ok, it's whirring on my 2004 archive currently
[09:56] <Kinnison> stub: shouldn't the presence of the uploader user in security.cfg cover that?
[09:57] <stub> Kinnison: I also need to setup access on chinstrap when a new user is created sorry
[09:57] <Kinnison> stub: pants
[09:57] <lifeless> Kinnison: you gotta tell us these things
[09:57] <Kinnison> lifeless: I thought that was the whole point of security.cfg
[09:58] <Kinnison> stub: Okay, can you please add 'uploader' and 'queued' as users on chinstrap?
[09:58] <lifeless> Kinnison: no, thats the policy template, not the entire shebang.
[09:58] <Kinnison> the latter has no security.cfg yet, but will soon enough
[09:58] <Kinnison> then I'll resubmit my merge before I wibble off to take the mother-out-law to the station
[09:59] <stub> Ideally there would be a wildcard entry on chinstrap but I haven't figured that out without opening up too much
[09:59] <stub> submit it now
[09:59] <Kinnison> ta
[10:00] <Kinnison> got a few hours wait :-(
[10:08] <lifeless> woo
[10:08] <lifeless> final launchpad import underway
[10:08] <lifeless> I'm so excited
[10:09] <ajmitch> final?
[10:09] <lifeless> yah
[10:09] <lifeless> I've done a number of demo imports
[10:09] <lifeless> this is live baby, live.
[10:09] <ajmitch> importing into bzr then?
[10:10] <ajmitch> impressive, it's come a long way quite quickly
[10:18] <sivang> lifeless: so now upstream package sources are automatically imported into bzr, are are you talking about automatically importing baz archives?
[10:18] <sivang> s/aree/or/
[10:18] <lifeless> sivang: exsqueeze me ?
[10:18] <lifeless> sivang: this is converting the rocketfuel launchpad source code from baz to bzr
[10:19] <sivang> eh :)
[10:19] <lifeless> its one step along the way to sanity
[10:19] <sivang> lifeless: yes, so SteveA_ told me
[10:19] <sivang> lifeless: I was confusing between that and Kinnison's work and the auto build system.
[10:19] <sivang> lifeless: sorry
[10:19] <lifeless> np
[10:20] <sivang> lifeless: so, now working with launchpad code will be less slow and less memory consuming? 
[10:20] <lifeless> sivang: it will be differently slow
[10:20] <lifeless> less memory consuming yes
[10:20] <sivang> cool
[10:21] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA]  LaunchpadBrowserNotifications (patch-2698: stuart.bishop@canonical.com)
[10:24] <stub> lifeless: So I'm going to convert my dists--devel--0 branch from baz to bzr. Near the top of RocketFuelSetup it tells me to create the directory. But that seems odd since the conversion tools will be doing that (?)
[10:24] <lifeless> stub: so I'm not sure how to separate out the 'new user instructions' from the 'conversion details'
[10:25] <lifeless> stub: at the top it tells you how to make a new branch, yes ?
[10:25] <stub> There are way too many target audiences mushed into this single document - new developers setting up for the first time, existing developers switching. Seperate documents would probably have been easier for all concerned in hindsight.
[10:25] <lifeless> stub: yes
[10:25] <lifeless> stub: lets do that tomorrow or something
[10:25] <stub> 'For each branch you will be committing to do this'
[10:25] <lifeless> ok, this line: ssh chinstrap mkdir -p /home/warthogs/archives/$yourusercode/launchpad
[10:26] <lifeless> that is because new user will not have converted
[10:26] <lifeless> and the *parent dir* of the branch must exist
[10:26] <lifeless> i.e. to push into .../launchpad/devel
[10:28] <stub> Is that rsync line right? We are excluding .py files?
[10:28] <lifeless> yes
[10:28] <lifeless> there are lots of them
[10:28] <lifeless> and its wasteful as we are downloading the branch
[10:31] <carlos> morning
[10:32] <carlos> I cannot believe it... It's near a week that I'm not able to merge a branch into rocketfuel because every time, I get a conflict with the sampledata
[10:33] <zyga> morning carlos 
[10:35] <sivang> ajmitch: in what way? 
[10:36] <lifeless> stub: once you have the branch you can revert you see, to get a full tree on disk.
[10:36] <stub> lifeless: Are you channelling yoda again?
[10:37] <lifeless> stub: channeling needed not is
[10:37] <ajmitch> sivang: in that I've got things to write, and I don't feel like using straight mod_python for now
[10:38] <sivang> ajmitch: mod_python embedded just like mod_php ?
[10:39] <ajmitch> similar
[10:39] <ajmitch> it gives me an excuse to do more with zope
[10:40] <sivang> hehe :)
[10:43] <stub>  $ /home/warthogs/source/bzr.integration/bzr baz-import stuart.bishop@canonical.com stuart.bishop@canonical.com
[10:43] <stub> importing stuart.bishop@canonical.com/banzai--devel--1 into /home/warthogs/archives/stuart.bishop@canonical.com/banzai/1/devel
[10:43] <stub> [                                                     ]  revisions  0/17 -:--:--unable to access ancestor scott@canonical.com--2004/banzai--devel--0.2--patch-3, making into a merge.
[10:43] <stub> [[10:43] <stub> That a problem?
[10:43] <lifeless> nope
[10:43] <lifeless> well there is a bug that the output is screwed up
[10:43] <lifeless> but thats it
[10:43] <stub> also nable to access ancestor robert.collins@canonical.com/buildbot--devel--0--base-0
[10:43] <lifeless> it says 'you branched from scott, but hes not available'
[10:43] <stub> ok
[10:45] <stub> And in my other window... bzr-submit-merge "Convert production config to new format"
[10:45] <stub> Please push your branch first
[10:45] <stub> ok. found that.
[10:46] <fabbione> i guess there is no way to register new specs right now, is it?
[10:46] <stub> 15:14:12~/production $ bzr push chinstrap:/home/warthogs/archives/stub/dists/devel
[10:46] <stub> bzr: ERROR: 'tuple' object has no attribute 'controlfilename'
[10:46] <stub>   command: '/usr/bin/bzr' 'push' 'chinstrap:/home/warthogs/archives/stub/dists/devel'
[10:46] <stub>   pwd: /home/stub/production
[10:46] <stub>   at /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/bzrtools.py line 103, in get_push_data()
[10:46] <stub>   see ~/.bzr.log for debug information
[10:46] <fabbione> https://launchpad.net/distros/ubuntu/+addspec
[10:46] <fabbione> RequestExpired
[10:46] <fabbione> A server error occurred.
[10:47] <fabbione> and it took me 10 seconds beween "Create new specs" -> fill the form -> click add
[10:47] <fabbione> at what speed are we supposed to do that? ;)
[10:47] <stub> fabbione: Try again. Something else must have been locking resources in the database. It is working for me.
[10:47] <fabbione> bah...
[10:48] <fabbione> stub: ok.. now one step and error further
[10:48] <fabbione> Name (required)
[10:49] <fabbione> myinput: UbuntuCluster
[10:49] <fabbione>   Constraint not satisfied  
[10:49] <fabbione> May contain letters, numbers, and dashes only. Examples: mozilla-type-ahead-find, postgres-smart-serial.
[10:49] <fabbione> so what's wrong with it?
[10:49] <fabbione> uppercase?
[10:50] <fabbione> seems so
[10:51] <stub> Yup. Uppercase. That should be mentioned.
[10:54] <stub> Boom!
[10:54] <stub> importing stuart.bishop@canonical.com/cookiecrumbler--canonical--1.2 into /home/warthogs/archives/stuart.bishop@canonical.com/cookiecrumbler/1.2/canonical
[10:54] <stub> Cleaning up
[10:54] <stub> bzr: ERROR: conflict when applying pybaz.Revision('stuart.bishop@canonical.com/cookiecrumbler--release--1.2--patch-1') to /home/warthogs/archives/stuart.bishop@canonical.com/cookiecrumbler/1.2/baz2bzr-quGBIl/rd
[10:54] <stub>   command: '/home/warthogs/source/bzr.integration/bzr' 'baz-import' 'stuart.bishop@canonical.com' 'stuart.bishop@canonical.com'
[10:54] <stub>   pwd: /home/warthogs/archives
[10:54] <stub>   at /home/pqm/source/pybaz/pybaz/_builtin.py line 2078, in apply()
[10:54] <stub>   see ~/.bzr.log for debug information
[10:54] <stub> stub@chinstrap /home/warthogs/archives $
[10:56] <stub> lifeless: ^^^ (and there was another one above from bzr push if you were not watching)
[10:59] <ajmitch> morning sabdfl 
[11:01] <fabbione> https://launchpad.net/distros/ubuntu/+spec 404 ???
[11:01] <fabbione> nevermind
[11:02] <sabdfl> moin moin
[11:02] <lifeless> stub: was not
[11:02] <lifeless> stub: fun
[11:03] <carlos> lifeless, mpool latest bzr snapshot package is broken
[11:03] <lifeless> yes
[11:03] <lifeless> it is
[11:04] <carlos> ok
[11:04] <lifeless> SteveA: uhm
[11:04] <lifeless> SteveA: this is jbailey packaging magically, not bzr developer ussers
[11:05] <SteveA> if pylint were run on checkins it would probably avoid indentation issues
[11:08] <fabbione> https://launchpad.net/distros/ubuntu/+spec/installer-volume-management/+setdistrorelease is missing "ubuntu dapper" as option
[11:09] <fabbione> well +setdistrorelease in general is missing dapper
[11:09] <lifeless> SteveA: so would the test suite
[11:09] <lifeless> SteveA: so 'dists' is in bzr now
[11:09] <lifeless> SteveA: and am about to convert something else over
[11:09] <SteveA> cool
[11:09] <lifeless> just determing what that should be
[11:09] <SteveA> oh, so jbailey doesn't run the tests before packaging?
[11:10] <lifeless> apparently :0
[11:10] <lifeless> we are likely to set up a PQM post UBZ
[11:10] <SteveA> jbailey: can you add something that runs the tests before doing a bzr package?
[11:20] <Keybuk> lifeless: how does it define "available", out of interest?
[11:20] <lifeless> Keybuk: carefully.
[11:21] <Keybuk> does it look around the filesystem for another conversion?
[11:21] <lifeless> Keybuk: sorry, seriously, how does which what where when to whom ?
[11:21] <Keybuk> well, I've converted my baz branches to bzr
[11:21] <Keybuk> how did it know where to find the rocketfuel branches?
[11:21] <lifeless> baz
[11:21] <Keybuk> or does it just stuff a ghost revision in with the right id?
[11:21] <lifeless> it just converts all the history that is available
[11:21] <fabbione> lifeless: another error in the procedure...
[11:21] <fabbione> lifeless: 
[11:21] <fabbione> cm.py build configs/canonical.com/launchpad/development
[11:22] <lifeless> parallel branch revisions become ghosts
[11:22] <Keybuk> right, but how does it know to link it up to the bzr conversion of the baz branch?
[11:22] <fabbione> ImportError: No module named pybaz
[11:22] <Keybuk> ok, so if I import A and B
[11:22] <fabbione> lifeless: what provides pybaz?
[11:22] <Keybuk> where B is a continuation of A
[11:22] <Keybuk> that isn't actually done properly?
[11:22] <Keybuk> because it won't find A
[11:22] <Kinnison> SteveA: if you were going to review the buildd zcml refactor then hold off on it for a bit
[11:22] <lifeless> fabbione: scotts pybaz packages. Keybuk can you _please_ upload those to the distro!
[11:22] <Keybuk> lifeless: no
[11:22] <Kinnison> SteveA: I'm mailing cprov with a bunch of comments I want dealt with before it goes for full review
[11:22] <lifeless> Keybuk: :[
[11:22] <lifeless> Keybuk: why not ?
[11:22] <Keybuk> we don't have a distro to upload to!
[11:22] <fabbione> lifeless: we can't upload.. dapper is not there yet
[11:23] <fabbione> Keybuk: where i can grab pybaz?
[11:23] <SteveA> Kinnison: is this cprov's branch that is in the pending revue page?
[11:23] <lifeless> Keybuk: why not to debian & then dapper when its ready ?
[11:23] <Keybuk> fabbione: deb http://people.ubuntu.com/~scott/pybaz/ ./
[11:23] <fabbione> Keybuk: thanks
[11:23] <lifeless> fabbione: can you please update the wiki page with that ?
[11:23] <Keybuk> lifeless: we've had this discussion ... I don't want to maintain any more packages in Debian
[11:23] <lifeless> Keybuk: no we haven't, but ok.
[11:23] <Keybuk> which is why people like fabbione and jbailey package software I've written :p
[11:24] <Keybuk> lifeless: yeah, we did; is why I uploaded baz in bob2's name
[11:24] <Kinnison> SteveA: no, buildd scoring still needs doing
[11:24] <SteveA> ok
[11:24] <lifeless> Keybuk: ok, so conversions. you did register rocketfuel as per the doco right ?
[11:24] <Keybuk> lifeless: right
[11:24] <SteveA> bug 2570
[11:24] <Ubugtu> Error: I cannot access this bug
[11:24] <lifeless> Keybuk: in which case its followed continuations back
[11:24] <fabbione> lifeless: i will try
[11:24] <Keybuk> lifeless: but A is in my --2004 archive, and B is in my --2005 archive
[11:25] <Keybuk> oh, does it just import the entire history, and hope that it does exactly the same as what the last import did
[11:25] <lifeless> Keybuk: it follows the ancestry. 
[11:25] <Keybuk> rather than go "aha! I've imported that already" ?
[11:25] <lifeless> yes
[11:25] <Keybuk> right, I understand now
[11:25] <lifeless> its designed to generate identical imports
[11:25] <lifeless> because people may not have other folks archives.
[11:25] <Keybuk> right
[11:25] <lifeless> the one 'spethial bit' is when the ancestor is not available.
[11:26] <Keybuk> so that's why the import of hct actually worked
[11:26] <lifeless> then it lies and cheats.
[11:26] <Keybuk> even though bob2's archives are long gone
[11:26] <lifeless> it tells bzr that its a new branch *with a ghost merge of the real parent*
[11:26] <lifeless> so you get a revision history that starts where you have data
[11:27] <lifeless> but the first revision will have the same parents as if you had imported with that ancestory being available.
[11:27] <Keybuk> ouch
[11:27] <lifeless> lying, cheating :)
[11:27] <Keybuk> so what is the general plan?
[11:27] <Keybuk> when should we start using bzr archives instead of baz ones?
[11:27] <lifeless> as soon as you are ready for a given project.
[11:28] <lifeless> i.e. want to switch hct or something over ?
[11:28] <lifeless> the main archive has a converted hct.
[11:28] <Keybuk> hct makes immediate sense for me, as my branch is bzr-ng
[11:29] <Keybuk> as does sourcerer
[11:29] <lifeless> ok, lets do hct.
[11:29] <lifeless> give me 15 to tidy some stuff up
[11:29] <Keybuk> yeah, it'll take a bit to finish my --2005 archive anyway
[11:31] <sabdfl> SteveA: ping
[11:36] <lifeless> SteveA: ping
[11:36] <SteveA> hi sabdfl 
[11:36] <SteveA> hi lifeless 
[11:36] <lifeless> sabdfl: hugo first
[11:36] <sabdfl> steve-o
[11:36] <sabdfl> SteveA: what do you think about making tomorrow a "Launchpad UBZ Spec Day"?
[11:37] <sabdfl> devote the day to mapping out specs for each of the sections
[11:37] <sabdfl> we can get the whole team together for a morning meeting
[11:37] <sabdfl> or, most of them
[11:37] <sabdfl> lay out some broad goals
[11:37] <sabdfl> then individual meetings with different teams through the day
[11:37] <sabdfl> discussion, prioritising
[11:37] <SteveA> morning in what timezone?
[11:37] <sabdfl> maybe even do it by voice call?
[11:39] <SteveA> so let's see... we've got three sources of specs i can think of
[11:39] <SteveA> 1. specs in launchpad developers' heads
[11:39] <SteveA> 2. specs in your head
[11:39] <SteveA> 3. specs that have been discussed already
[11:40] <SteveA> i think it will be a good start if you and i (and maybe kiko too) did a voice call
[11:40] <SteveA> to talk about specs, and what you want to see there
[11:40] <SteveA> and then we get that written up and out to the launchpad team for additions and modifications
[11:41] <SteveA> then we've got something large and more concrete to work with, before getting everyone involved together
[11:41] <SteveA> what do you think about that?
[11:44] <SteveA> we can do that call later today, when kiko is around, and get people thinking about specs in the launchpad meeting that is later today.
[11:45] <sabdfl> cool, wfm
[11:45] <SteveA> then over the course of tomorrow and monday, get the groups of specs refined
[11:45] <SteveA> okay.  want me to fix a time with cvd?
[11:45] <sabdfl> monday i'll be doing this with the distro team
[11:45] <sabdfl> but you should keep going on it
[11:45] <SteveA> sure, monday won't need you directly
[11:46] <SteveA> we need to get things in the spec tracker asap after discussing / deciding
[11:46] <SteveA> so that it is kept visible
[11:46] <SteveA> and we can see holes / inappropriate things early on
[11:48] <Keybuk> lifeless: has pybaz been dropped from the launchpad config now then?
[11:48] <lifeless> Keybuk: no
[11:48] <Keybuk> why the requirement to install my packages then?
[11:49] <lifeless> Keybuk: for config-manager.
[11:49] <lifeless> it needs pybaz to build the launchpad tree while we convert.
[11:49] <Keybuk> ohh
[11:49] <Keybuk> right, got ya
[11:50] <lifeless> SteveA: ping
[11:50] <SteveA> lifeless: 
[11:50] <lifeless> so we have some new deps for lp
[11:50] <lifeless> hct needs bzr on its next landing
[11:51] <lifeless> sourcecode/bzr ok for that? and a symlink in launchpad/lib/bzrlib->../sourcode/bzr/bzrlib
[11:51] <lifeless> as pqm is now running bzr we can add bzr natively :)
[11:52] <SteveA> okay
[11:52] <lifeless> related to that is the question of whether we want a bzr fork that can be committed to, or a manually updated branch I can do directly, or point at upstream.
[11:52] <SteveA> actually, i want to make a change to this stuff along with this conversion
[11:52] <SteveA> that is, to have everything that is an 'external' in sourcecode
[11:52] <SteveA> and symlinked into lib
[11:52] <lifeless> SteveA: be my guest :)
[11:53] <lifeless> SteveA: or do you want me to do that?
[11:53] <SteveA> can you do it?
[11:53] <lifeless> sure
[11:53] <SteveA> great, thanks
[11:53] <Keybuk> yeah, SteveA and I have discussed that one ... when we do hct and sourcerer, move them into sourcecode and just symlink them in lib
[11:53] <lifeless> we all have :)
[11:53] <SteveA> it'll just mean one less thing for people to learn
[11:54] <lifeless> SteveA: so, for bzr, I suggest I put a bzr branch in rocketfuel, but not enable pqm commits to it yet
[11:54] <lifeless> ok ?
[11:54] <lifeless> Keybuk: do you need bzrtools too ?
[11:54] <Keybuk> lifeless: not that I'm aware
[11:54] <lifeless> Keybuk: k
[11:54] <Keybuk> I don't even use it myself
[11:54] <SteveA> lifeless: we can't just install it as a package?
[11:54] <lifeless> SteveA: not bloody likely.
[11:54] <lifeless> ;)
[11:54] <SteveA> okay
[11:54] <SteveA> code it is
[11:55] <lifeless> its python, its changing fast, its something we're developing.
[11:55] <SteveA> yeah.
[11:55] <Keybuk> and it's a dep of something that changes equally fast
[11:55] <lifeless> we will probably have it installed on chinstrap, but the test suite needs to be able to use the right one.
[11:55] <SteveA> but, will this be the same bzr people are using to do switch / checkout etc.
[11:55] <lifeless> no, it won't be.
[11:55] <SteveA> okay
[11:55] <SteveA> so we have the bzr libs for launchpad
[11:55] <lifeless> they can if they wish, but if you dont tell, I wont.
[11:56] <SteveA> and the bzr app people use to work on launchpad
[11:56] <lifeless> ack
[11:57] <SteveA> okay.  i hope at some point in the coming months, we can just use bzr packages
[11:57] <lifeless> for the app we are now
[11:57] <lifeless> but I don't think its likely while hct is developing that we will do that for bzr.
[11:57] <lifeless> nor do I understand why it has that goal when we dont do that for sqlobject et al
[11:58] <Keybuk> (or pybaz, up until now)
[11:58] <lifeless> we still dont for pybaz, the tests will be on our internal one
[11:58] <lifeless> its just being installed for the toolchain.
[11:58] <sabdfl>  - bradb and bjornt
[11:58] <sabdfl>  - carlos
[11:58] <sabdfl>  - kinnison and celso
[11:58] <sabdfl>  - spiv and stub
[11:58] <sabdfl>  - niemeyer and ddaa (with lifeless)
[11:58] <sabdfl>  - keybuk and niemeyer
[11:58] <sabdfl> who did i miss?
[11:58] <Keybuk> SteveA: it'll be lib/bzrlib -> sourcecode/bzr/bzrlib ...
[11:58] <lifeless> sabdfl: for what ?
[11:59] <sabdfl> lifeless: teams on LP
[12:00] <SteveA> sabdfl: jamesh with spiv  and stub?
[12:00] <carlos> sabdfl, daf
[12:00] <Belutz> sabdfl, sorry it's a bit offtopic, but greetings from Indonesia :)
[12:01] <SteveA> carlos: this is to arrange talks about what specs we need to plan for ubz
[12:01] <SteveA> carlos: so, daf is still unwell
[12:02] <SteveA> we also have salgado
[12:02] <SteveA> on the foaf team
[12:03] <carlos> ok
[12:03] <sabdfl> hey Belutz
[12:04] <Belutz> sabdfl, hello :)
[12:04] <SteveA> hi mpt 
[12:04] <mpt> yo
[12:04] <Belutz> sabdfl, do you have plan for coming to Indonesia?
[12:04] <sabdfl> Belutz: could do
[12:04] <mpt> meeting's still in one hour, right?
[12:04] <SteveA> mpt: do you have any specs in mind for UBZ?
[12:04] <SteveA> 2 hours
[12:04] <mpt> two hours!
[12:04] <mpt> ok
[12:05] <Belutz> sabdfl, we are still prepraring for the locoteams
[12:05] <Belutz> sabdfl, and i just want to say that i love ubuntu, that's why i help translating in rosetta :)
[12:05] <Kinnison> Urgh, chinstrap is being so slow
[12:06] <mpt> SteveA, I put the ones I thought of on the BOFs page
[12:06] <SteveA> mpt: URL?
[12:06] <sabdfl> Belutz: thank you! do you like rosetta? file bugs if you don't :-)
[12:07] <Belutz> sabdfl, i really like it, but i think it would be great if there is a feature like a dictionary, so people can have consistency in translating
[12:07] <mpt> SteveA: https://wiki.ubuntu.com/UbuntuBelowZero/BOFs
[12:07] <SteveA> sankar: getting ddaa, lifeless and niemeyer together at the same time is tough.  We have the brazil <-> australia issue
[12:08] <mpt> Did PQM accept anything of mine?
[12:08] <SteveA> sabdfl: getting ddaa, lifeless and niemeyer together at the same time is tough.  We have the brazil <-> australia issue
[12:08] <SteveA> sorry sankar, xchat completion errorr
[12:08] <sankar> SteveA: :)
[12:09] <SteveA> sabdfl: as a user of launchpad, particularly malone and issue tracker, jbailey
[12:09] <lifeless> SteveA: is there a good standard library routine to send email ?
[12:10] <SteveA> you mean python standard lib?
[12:10] <lifeless> SteveA: i.e. equivalent to 'mail -s subject user@goo'
[12:10] <lifeless> yes
[12:10] <lifeless> not something that talks smtp.
[12:10] <lifeless> (I mean, it may choose to talk smtp on some platforms, but thats irrelevant to my needs)
[12:10] <SteveA> there is such a thing in zope3
[12:11] <lifeless> ah. I don't see bzr depending on that though :|
[12:11] <mpt> yay, translation form landed
[12:13] <SteveA> the zope3 one also had a horrendous security hole for quite a while
[12:13] <SteveA> although it was generally disabled by default
[12:15] <SteveA> lifeless: mailman probably has some stuff for this
[12:18] <SteveA> spiv: ping
[12:19] <SteveA> spiv: i just got a test failure in test_disconnects.txt
[12:19] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/fileP7hHKa.html
[12:20] <lifeless> SteveA: can I define __call__ in a  module ?
[12:20] <SteveA> to make a module callable?
[12:20] <lifeless> yes
[12:20] <SteveA> no
[12:20] <SteveA> not with regular modules
[12:20] <lifeless> :[
[12:20] <SteveA> same as you can't just add a __call__ attribute that is a function to new style classes
[12:20] <SteveA> you could do this with classic classes
[12:21] <lifeless> thats fine
[12:21] <SteveA> you need to use a different class of module
[12:21] <lifeless> its just that with a module, you are being parsed so, def __call__ seems naturale
[12:21] <SteveA> eau
[12:21] <lifeless> water ?
[12:21] <SteveA> what do you want to do it for?
[12:21] <SteveA> au naturale
[12:21] <lifeless> yes
[12:22] <lifeless> A short term ui needs a python function named, and I wanted to keep it short.
[12:22] <SteveA> i see.  put it in the package's __init__.py ?
[12:22] <SteveA> hack it into __builtins__ 
[12:23] <SteveA> no, i didn't say that
[12:23] <lifeless> haha
[12:23] <lifeless> if its in __init__.py, as __call__ it won't take effect though
[12:23] <SteveA> guido kicked my butt for doing that once 
[12:23] <lifeless> right ?
[12:23] <SteveA> it would be package.__call__
[12:23] <SteveA> not package()
[12:23] <lifeless> right. so, I'm doing bzrlib.plugins.email.post_commit
[12:23] <lifeless> longer but explicit
[12:23] <SteveA> ok
[12:23] <lifeless> I wanted bzrlib.plugins.email
[12:25] <Kinnison> damnit chinstrap is slow
[12:25] <lifeless> Kinnison: poor thing is BUSY
[12:25] <Kinnison> there's pqm, pending-reviews *and* baz2bzr going on it
[12:25] <Kinnison> and some rsyncs
[12:25] <lifeless> tough
[12:25] <lifeless> I've turned pqm off
[12:26] <lifeless> I'm about to move all the sourcecode stuff around for stevea when the current branch finished
[12:26] <Kinnison> argh
[12:26] <lifeless> which is soon.
[12:26] <lifeless> yay
[12:26] <Kinnison> because I cannot be blocked by this
[12:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix $calendar/{today,this-*} traversal and add test.  Fixes bug 3357 (patch-2699: james.henstridge@canonical.com)
[12:33] <lifeless> SteveA: ping
[12:33] <lifeless> we have sourcerer, hct, psycopgda, sqlos in lib. Which ones should stay there ?
[12:34] <SteveA> they should all go in sourcecode, and be symlined
[12:34] <lifeless> ok
[12:34] <SteveA> so, we have only subtrees only in sourcecode
[12:35] <SteveA> and only symlinks to these, or 'the same tree, regular subdirs' in lib
[12:38] <lifeless> ok
[12:40] <SteveA> hi salgado 
[12:41] <salgado> yo SteveA!
[12:41] <SteveA> lifeless: what's the latest time tomorrow that you can make a meeting?
[12:42] <SteveA> lifeless: i'm trying to arrange a time for you and niemeyer and ddaa and mark and me to have a cal
[12:42] <lifeless> SteveA: how long a meeting ?
[12:42] <SteveA> it is to talk about UBZ specs we need to do, and what their scope is
[12:43] <SteveA> max 1 hr on the phone
[12:43] <lifeless> 3pm sydney time. I have to cat a 405 pm train
[12:43] <SteveA> salgado: what time is it in brazil now?
[12:43] <SteveA> what's that in UTC?
[12:43] <lifeless> AUUG is having a convetion, we have slug moved around
[12:44] <lifeless> but i'll be working from 7am probably, so perhaps we can do it in the morning ?
[12:44] <salgado> SteveA, 8:44
[12:45] <SteveA> lifeless: maybe, but what time is that in UTC?
[12:45] <lifeless> SteveA: Thursday, 20 October 2005 at 21:00:00Fri 7:00 AM
[12:45] <lifeless> utc 2100 is 7am
[12:45] <lifeless> utc 0500 is 3pm
[12:46] <SteveA> that's 0000 for me. 2300 for ddaa. 2200 for mark.
[12:46] <SteveA> it's do-able.  although it does mean i'll be working saturday ;-)
[12:46] <lifeless> uhm
[12:47] <lifeless> its your thursday dude
[12:47] <lifeless> not your friday
[12:47] <SteveA> i'm talking tomorrow, not today, btw
[12:47] <SteveA> although today is doable too
[12:47] <lifeless> I am too
[12:47] <lifeless> remember, I get it the day *before* you
[12:47] <lifeless> brazil are the slackers behind you
[12:47] <SteveA> it's thursday evening now, for you, right?
[12:48] <lifeless> yes
[12:48] <lifeless> so
[12:48] <SteveA> okay.  can you do a 6.30 start tomorrow?
[12:48] <lifeless> its pushing the friendship :0
[12:48] <SteveA> screw you hippy
[12:48] <lifeless> given we finish at 11 at best after the meeting
[12:48] <lifeless> but yes
[12:49] <lifeless> awww, how sweet.
[12:49] <SteveA> be careful... that might have been up RMS's nose
[12:49] <lifeless> I thought you said beautiful
[12:50] <ddaa> Duh
[12:50] <ddaa> I won't be online at 2300
[12:50] <SteveA> ddaa: can you make a conference phonecall at 22.30 ?
[12:51] <SteveA> this one is a bastard to arrange
[12:51] <lifeless> I suggest we dont do it
[12:51] <lifeless> instead get ddaa and niemeyer
[12:51] <lifeless> they are working together right now
[12:51] <lifeless> and then get me and mpool
[12:51] <ddaa> SteveA: I suppose I could, but my spoken english being what it is, I'd rather avoid phone meetings.
[12:52] <ddaa> Last time I had lifeless on the phone we just decided to drop back to the chat.
[12:52] <SteveA> hmm...
[12:53] <SteveA> okay.  we still need to schedule a time to have this meeting online
[12:53] <ddaa> besides, I would not a have a landline at all at that time...
[12:55] <ddaa> 1800 pm is the latest possible for me today
[12:55] <ddaa> (utc)
[12:55] <ddaa> going to my new appt which does not yet have connectivity :(
[12:56] <ddaa> tomorrow should be easier though
[12:56] <lifeless> SteveA: split the meeting really. I trust ddaa and niemeyer to give good coverage on the stuff they think needs work, and I can add stuff to that
[12:57] <SteveA> ok
[12:57] <SteveA> salgado: any idea when kiko will be starting work tomorrow morning?
[12:57] <ddaa> what's the purpose of the meeting BTW?
[12:57] <SteveA> to plan specs for UBZ
[12:57] <lifeless> ddaa: ubz spec round up
[12:58] <lifeless> SteveA: I'll do a round up on the phone with mpool tomorrow
[12:58] <SteveA> ok
[12:58] <SteveA> lifeless: please add the 'sprint server in a box' spec to it
[12:58] <SteveA> i still haven't written it up
[12:58] <salgado> SteveA, he usually arrives around 1000 (UTC-2)
[12:58] <lifeless> but I think I miss everyone europe tomorrow
[12:59] <SteveA> salgado: can he arrive at 0900 tommorrow do you think
[12:59] <salgado> SteveA, sure, I guess he can
[12:59] <lifeless> SteveA: because I start at your late evening and finish your insane morning
[01:01] <SteveA> ddaa, niemeyer: how about a phone call tomorrow, 1100 UTC with me and mark and kiko, to go through UBZ specs?
[01:01] <niemeyer> SteveA: Fine with me
[01:01] <SteveA> ddaa: ?
[01:01] <SteveA> thanks niemeyer 
[01:02] <ddaa> SteveA: I will available at that time.
[01:02] <SteveA> okay, thanks
[01:03] <SteveA> niemeyer: can you do another call right afterwards?
[01:03] <SteveA> Keybuk: hi.  can you make a phone call tomorrow, 1200UTC?
[01:03] <niemeyer> SteveA: Sure :)
[01:04] <SteveA> actually, 1/2 an hour later
[01:04] <SteveA> Keybuk: hi.  can you make a phone call tomorrow, 1230UTC?
[01:06] <SteveA> Kinnison: what's the latest time you can take a phone call tomorrow? 
[01:06] <SteveA> carlos: what's the latest time you can take a phone call tomorrow?
[01:07] <matsubara> good morning!
[01:07] <Kinnison> SteveA: tomorrow is friday, uhm, in practice, no later than 1200 UTC
[01:07] <Kinnison> SteveA: But I would like to be free to go out, so unless it has to be, ideally no later than 1800 UTC lasting no more than 1h
[01:07] <SteveA> really?  that's difficult... as i want to get you on the phone with celso and mark
[01:07] <Kinnison> erm s/1200 UTC/0000 UTC/
[01:07] <carlos> SteveA, hmm, I guess 17:00 UTC 
[01:08] <carlos> perhaps later
[01:08] <carlos> I will know it tonight
[01:08] <Kinnison> SteveA: Basically if I am going out tomorrow, It'll be at 20:00 local-time
[01:08] <SteveA> that should be fine carlos, thanks
[01:08] <Kinnison> SteveA: which for me is UTC+1
[01:09] <carlos> SteveA, why aren't we using shtoom?
[01:09] <SteveA> carlos: because we don't have its conferencing stuff set up properly
[01:09] <carlos> ok
[01:15] <mara007> hello
[01:16] <mara007> I would like to help with some translating into czech language: 
[01:17] <SteveA> jordi: ?
[01:18] <Lathiat> mara007: http://launchpad.net/rosetta/ i think
[01:21] <mara007> he:)
[01:21] <SteveA> mara007: talk with jordi or carlos
[01:21] <SteveA> carlos develops rosetta.  jordi helps projects and people to use rosetta well, and makes sure it is going smoothly.
[01:22] <carlos> mara007, what's the problem?
[01:22] <mara007> when Iam tranlating app and putting characters in a special coding - and those spec chars like , should I care about encoding?
[01:23] <mara007> or it is managed "somehow" automaticaly?
[01:23] <mara007> btw first time on irc :-)
[01:23] <SteveA> it should just work
[01:24] <mara007> ok, that sounds good 
[01:25] <carlos> mara007, are you getting errors with that?
[01:28] <mara007> carlos, no.. propably.. sorry for disturptin. I have just registered on launchpad I "please feel free to join #launchpad" appeared there, so I did.. because I was a little worried about this
[01:28] <carlos> mara007, don't worry, it's not a problem, we are here to help you ;-)
[01:32] <mara007> so.. good work, good luck and keep on it .. bye ;)
[01:33] <SteveA> hi jamesh 
[01:33] <jamesh> hi
[01:33] <SteveA> take a look at this: https://chinstrap.ubuntu.com/~dsilvers/paste/fileP7hHKa.html
[01:34] <SteveA> it was a failure when running nthe test suite
[01:34] <SteveA> next time i ran it, no problem
[01:34] <salgado> SteveA, is the LaunchpadView class something new?
[01:34] <SteveA> salgado: pretty new
[01:35] <SteveA> salgado: i'm slowly converting view classes to use it
[01:35] <salgado> you should tell us about these things. ;)
[01:35] <SteveA> salgado: there are conflicts sometimes though, like in many malone classes that use 'user' to mean something different
[01:35] <SteveA> it is part of a plan of mine to 1. get rid of much repetitive zcml, 2. make page titles much better arranged
[01:36] <SteveA> and 3. make writing views much more pleasant
[01:36] <salgado> that's cool. I'll remember to use it from now on. :)
[01:36] <jamesh> SteveA: weird.  I wonder why the twisted daemon died?
[01:40] <salgado> evening stub 
[01:40] <stub> hi
[01:40] <salgado> stub, do you think it's a problem if we nuke all teammembership/teamparticipation entries for all merged accounts?
[01:41] <stub> salgado: No problem.
[01:41] <stub> You think the size of the table is giving us trouble?
[01:42] <salgado> no, it's just because these memberships show up in the +members page 
[01:43] <salgado> and so are shown the merged accounts, which shouldn't show up anywhere
[01:43] <stub> ok. Sure - we can nuke 'em. It is just noise in the db. I think we could even consider removing the entries in the Person table (but one step at a time)
[01:43] <salgado> I definitely agree
[01:44] <salgado> do you want me to write a patch to clean the membership entries?
[01:46] <stub> Cleaning up would just be 'DELETE FROM TeamParticipation WHERE person IN (select id from person where merged is not null);', no? The real work is changing the merge code to do that.
[01:46] <salgado> the merge code already does that
[01:46] <stub> ok. So I just need to run some commands on the production db.
[01:47] <stub> What team is an example?
[01:47] <stub> (with the dud accounts in it)
[01:47] <salgado> first it tries to transfer it to the remaining account. if that account already has a membership for that team, then it deletes the membership from the dupe account
[01:48] <salgado> https://launchpad.net/people/ubuntu-core-dev/+members has "Jeff Bailey"
[01:48] <salgado> jbailey-ubuntu-merged
[01:49] <stub> ta. I'll sort this out tomorrow or maybe after the meeting
[01:49] <salgado> great. thank you
[01:50] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: move nested trees out of lib (patch-2700)
[01:50] <lifeless> ok, reenabled launchpad
[01:51] <lifeless> SteveA: I have done that move
[01:51] <lifeless> SteveA: over to you to tell people about it :)
[01:53] <jamesh> lifeless: I updated the pending-reviews code to work with recent bzr
[01:53] <lifeless> jamesh: today ?
[01:53] <lifeless> jamesh: or a few days back, its broken again :)
[01:54] <jamesh> lifeless: I fixed the test failures today (and added support for collecting the conflicts list)
[01:54] <lifeless> jamesh: cool
[01:54] <lifeless> jamesh: there is a bug that is now fixable
[01:54] <jamesh> lifeless: the values in the ROCKETFUEL_BZR dict probably need changing (we probably don't want to use sftp URLs)
[01:55] <lifeless> jamesh: the test for 'is merged' - rather than 'branch.has_revision(other_head)' it should be 'other_head in branch.get_ancestry(branch.last_revision())'
[01:56] <lifeless> jamesh: right, well I can put up dists branch for testing in live
[01:56] <jamesh> lifeless: I also fixed the handling of explicitly specified revisions
[01:57] <lifeless> why not use sftp ?
[01:58] <lifeless> sftp is what I would use to pull that branch locally, or to 'bzr log' it
[01:58] <stub> SteveA: Meeting in 2 mins?
[01:58] <SteveA> yes
[01:58] <lifeless> jamesh: ok, I have a branch up there for your live-testing pleasure
[01:58] <jamesh> lifeless: how would the cron job get the ssh passphrase?
[01:59] <jamesh> lifeless: also, the script has local access to the branches
[01:59] <lifeless> jamesh: it does not need one. generate a local keypair,and put its .pub file as authorized_keys
[01:59] <lifeless> or the script could know to map sftp://chinstrap/ -> /
[01:59] <kiko> hello people of the 4th world
[01:59] <lifeless> pqm knows that
[02:00] <jamesh> "do what pqm does" sounds good
[02:00] <kiko> uhm
[02:00] <ddaa> meeting?
[02:00] <SteveA> MEETING STARTS
[02:00] <SteveA> who is here?
[02:00] <bradb> me
[02:00] <lifeless> jamesh: right, well in the first place, just a hardcoded transform :)
[02:00] <BjornT> me
[02:00] <lifeless> SteveA: my body is
[02:01] <matsubara> me
[02:01] <jamesh> me
[02:01] <spiv> me
[02:01] <niemeyer> Boo
[02:01] <ddaa> me and my lunch
[02:01] <Belutz> me, but i'm not a developer
[02:01] <kiko> me is me
[02:01] <ddaa> Belutz: neither is my lunch
[02:01] <salgado> I'm here
[02:01] <Belutz> :D
[02:02] <cprov> here
[02:02] <kiko> salgado!
[02:02] <stub> yo
[02:02] <SteveA> == Agenda ==
[02:02] <SteveA>  - roll call
[02:02] <SteveA>  - agenda
[02:02] <SteveA>  - activity reports
[02:02] <SteveA>  - next meeting (skipped... travel to UBZ in progress)
[02:02] <SteveA>  - staging / production
[02:02] <SteveA>  - gina / opening dapper
[02:02] <SteveA>  - spec day!
[02:02] <SteveA>  - three sentences
[02:02] <SteveA> 
[02:02] <SteveA> here's the agend
[02:02] <SteveA> a
[02:02] <SteveA> um, yeah
[02:02] <SteveA> typic
[02:02] <SteveA> um
[02:03] <SteveA> typing
[02:03] <SteveA> that's better
[02:03] <SteveA> any other items?
[02:03] <lifeless> bzr pie status
[02:03] <gneuman> here
[02:03] <SteveA> okay
[02:03] <SteveA> okay, let's go
[02:03] <SteveA>  - activity reports
[02:03] <ddaa> bzr: ERROR: unknown command 'pie'
[02:03] <lifeless> GOD
[02:03] <SteveA> who's warming up, who is below zero?
[02:03] <stub> I'm up to date
[02:03] <mpool> lifeless: here! :)
[02:04] <lifeless> mpool: :0
[02:04] <Kinnison> sorry
[02:04] <Kinnison> and up to date
[02:04] <mpool> uptodate
[02:04] <ddaa> hot as chilly
[02:04] <ddaa> I mean, up to date
[02:04] <spiv> Not up to date -- but catching up as we speak.
[02:04] <kiko> I just skipped yesterday because I was on crack, will send now
[02:04] <kiko> apart from that up to date
[02:04] <jamesh> need to send ones for this week
[02:04] <mpt> I'm here, and also up to date
[02:05] <SteveA>  - next meeting
[02:05] <SteveA> i propose to skip it, as we'll be traveling to UBZ
[02:06] <SteveA>  - staging / production
[02:06] <kiko> SteveA, yeah, sounds good
[02:06] <Kinnison> nor will many of the developers
[02:06] <SteveA> stub: what's happening?
[02:06] <kiko> I will be
[02:06] <lifeless> I won't be travelling, I will be there.
[02:06] <mpool> i'll still be here
[02:06] <SteveA> hmm...
[02:06] <Kinnison> Most of the launchpadders won't travel until tuesday 1st Nov
[02:06] <stub> staging has started to pick up some too-long requests, because it is (deliberatly) running with a shorter timeout.
[02:06] <SteveA> okay, maybe we will have it after all
[02:06] <stub> Minor things like the front page
[02:07] <stub> Salgado was last seen looking into that issue (spurious count(*)'s on the person table), but I don't know the status of that
[02:07] <SteveA> stub: i have an issue salgado discovered about page templates iterating over resuts
[02:07] <kiko> stub, salgado and I noticed that production seemed to be very slow at particular queries and sending email
[02:07] <SteveA> i'm looking into it
[02:07] <salgado> stub, I found why we're getting these extra count(*)s
[02:07] <stub> Staging is currently unstable for Gina testing too
[02:07] <kiko> people are waiting more than 10 minutes for email
[02:07] <spiv> SteveA: So, meeting next week or not?
[02:08] <spiv> SteveA: Flip a coin and tell us :)
[02:08] <Lathiat> people/motu/+assignedbugs is randomly throwign timeouts
[02:08] <SteveA> spiv: we'll decide when stub is done with this item
[02:08] <Lathiat> works for osme, not for others, randomly
[02:08] <stub> Production is running fine. Rollout next tuesday might be awkward depending on my status with bzr. But we can work that out.
[02:08] <stub> Pretty much it.
[02:08] <kiko> stub, the slow emails out?
[02:08] <kiko> and the query bustage is summarized by count(*) queries?
[02:09] <stub> kiko: not my department I'm afraid. Z3 gives them to our mail infrastructure where they disappear into elmo's bowels.
[02:09] <kiko> salgado and I thought there was something seriously busted with the database..
[02:10] <stub> We are still running in 'deliver immediatly' mode so there are no delays going out of Z3
[02:10] <kiko> stub, could it be that we're taking to long.. ah. 
[02:10] <kiko> is that definitely true?
[02:10] <Kinnison> surely deliver-immediate means "wait until the deliver completes"
[02:10] <Kinnison> that's what it means in /usr/lib/sendmail speak
[02:10] <kiko> who waits
[02:11] <SteveA> yes.  they're delivered at transaction commit i think, sent to port 25
[02:11] <stub> kiko: Yes. we are using directDelivery, not queuedDelivery
[02:11] <Kinnison> SteveA: right, that means that we're potentially waiting on in-band checks on the smtp
[02:11] <Kinnison> SteveA: e.g. sender verify and recipient verify
[02:11] <SteveA> can we turn them off?
[02:11] <Kinnison> Dunno if they're even on
[02:11] <Kinnison> depends what the config is on the box's MTA
[02:12] <stub> Kinnison: Indeed. It is not optimal, but we had an issue with queued and it hasn't been a problem so we just stuck with it.
[02:12] <kiko> elmo-question then, I guess
[02:12] <Kinnison> kiko: or znarl
[02:12] <SteveA> RT issue
[02:12] <Kinnison> aye
[02:12] <SteveA> okay, all done?
[02:12] <stub> yup
[02:13] <SteveA> next meeting, then.  who cannot be here at the usual time next week?
[02:13] <lifeless> I htink I can :)
[02:13] <SteveA> kiko: ?
[02:13] <niemeyer> I can
[02:13] <kiko> I can't
[02:14] <kiko> I leave tuesday
[02:14] <ddaa> can (at niemeyer's)
[02:14] <stub> I don't think there is a point, as the only thing we would be discussing is what to do the next day and what we expect the food to be like on the plane.
[02:14] <mpool> i can be
[02:14] <SteveA> i agree with stub
[02:14] <SteveA> so, anyone's welcome to turn up and talk
[02:15] <Kinnison> except for the status update
[02:15] <SteveA> but there isn't an official meeting
[02:15] <Kinnison> okay
[02:15] <SteveA> talking of travel, i'm traveling to london on monday, and i'll be working from london tuesday and part of wednesday
[02:15] <SteveA>  - gina / opening dapper
[02:16] <SteveA> kiko and Kinnison
[02:16] <Kinnison> kiko: you go first, I'll fill in the gaps
[02:16] <stub> And I'm now in Bangkok on UTC+7
[02:16] <kiko> okay
[02:16] <kiko> gina's growing tests
[02:16] <kiko> more tests
[02:16] <kiko> more tests
[02:16] <kiko> and bugfixes
[02:16] <kiko> I'm now testing source packages over two distro releases
[02:16] <stub> Ginas growing testies?
[02:16] <ddaa> gina's got big tests?
[02:17] <kiko> I need to do some final investigation on the tables we manipulate during source package import but this part should be ready and with XXX: untested bits indicated where I chose not to test
[02:17] <kiko> don't say "why don't you test them?"
[02:17] <kiko> I am going to move into testing binary packages
[02:17] <kiko> there was a certain war over how to detect binary packages are part of a build
[02:18] <kiko> it wasn't really solved, in good launchpad-versus-the-sab style, so I guess I'll go with what mdz, Kamion, Kinnison and I think is the right thing to do
[02:18] <kiko> the issue revolves around detecting bin-only NMUs (AIUI) are in a separate build
[02:18] <kiko> these can only be detected by looking at .changes files, which the archive doesn't have
[02:19] <kiko> to process them will take a kidney and a liver..
[02:19] <jamesh> or package times?
[02:19] <jamesh> or don't debs store that information?
[02:19] <kiko> jamesh, package times?
[02:19] <jamesh> kiko: the time the package was built
[02:19] <stub> What is an NMU?
[02:19] <SteveA> "non maintainer upload"
[02:19] <SteveA> someone like elmo uploading a package that is someone else's
[02:20] <SteveA> because that someone else was being slack about something
[02:20] <jamesh> kiko: I know RPM stores the build host and build time in a binary package.  I don't know if there is something similar for debs
[02:20] <SteveA> seems to be equivalent to throwing down the proverbial gauntlet in debian terms
[02:21] <kiko> SteveA, it often happens close to release if deadlines-r-us
[02:21] <gneuman> I am the king.
[02:21] <kiko> jamesh, I don't know if debs store them, I will find out
[02:21] <kiko> NMUs are okay -- bin-only NMUs are what fuck us over
[02:21] <Kinnison> Well, we model NMUs in the sense of knowing up uploaded it vs. who changed it vs. who is the mainainter
[02:21] <SteveA> are there any?
[02:22] <SteveA> are there many?
[02:22] <Kinnison> bin-nmus are harder
[02:22] <kiko> they aren't even legal in ubuntu AIUI
[02:22] <kiko> they happen in Debian though
[02:22] <Nafallo> we don't have the big maintainer lock, so NMUs _can't_ happen :-)
[02:23] <kiko> Nafallo, interesting point -- does this mean that you don't really care about the maintainer?
[02:23] <kiko> anyone can upload other people's packages?
[02:23] <Nafallo> kiko: we have the maintainer intact from what debian has if it's not our own packages.
[02:24] <Nafallo> so yes, maintainer makes not much sence in ubuntu :-).
[02:24] <kiko> is there no permissions checking on upload beyond being in the trusted keyring?
[02:24] <Nafallo> we have seperated the rights in main/restricted and universe/multiverse instead, and that's all :-)
[02:24] <SteveA> we need to move on soon
[02:24] <cprov> Nafallo: indeed, I'd suggest to not keep the NMU policy, but I'm not an expert, its use will be very rare
[02:24] <SteveA> really, got a lot else to talk about
[02:25] <kiko> sure
[02:25] <kiko> so I'll be testing binary imports today and tomorrow 
[02:25] <Nafallo> cprov: for ubuntu we never use it. if we want to get debian to use lp though... :-P
[02:25] <kiko> who knows saturday we'll be in a position to run this babe
[02:25] <Nafallo> should not be a blocker for dapper though.
[02:25] <kiko> I travel on monday
[02:26] <SteveA> kiko: you have a full schedule of phone calls friday, btw
[02:26] <kiko> SteveA, I don't know how people hope me to do all this at once
[02:26] <cprov> Nafallo: you're right, then we will need to model their other weirdness too ;)
[02:26] <SteveA> kiko: let's chat about this later
[02:27] <SteveA>  - bzr pie status
[02:27] <ddaa> I think lifeless fell asleep on his keyboard...
[02:28] <lifeless> no
[02:28] <lifeless> on the phone
[02:28] <lifeless> so
[02:28] <lifeless> dists is converted to bzr
[02:28] <lifeless> yay!
[02:28] <kiko> he was taking a chug at the crackpipe
[02:28] <lifeless> pqm is running bzr
[02:28] <lifeless> yay!
[02:28] <lifeless> pending reviews does bzr.
[02:28] <lifeless> I'm hoping to convert hct and sourcerer over tonight
[02:28] <lifeless> and all the remaining subprojects tomorrow 
[02:29] <lifeless> if there are no showstoppers, I'll do launchpad on monday
[02:29] <jamesh> we'll see how successfully pending-reviews does bzr soon ...
[02:29] <kiko> lifeless, did you solve the gpg signature issue?
[02:29] <lifeless> kiko: what issue ?
[02:29] <lifeless> jamesh: :)
[02:29] <mpt> so will Monday be a Flag Day where we all have to switch to bzr at once?
[02:29] <kiko> supporting signed archives? how can I remember
[02:29] <lifeless> mpt: yes.
[02:29] <kiko> please no
[02:30] <mpt> ok
[02:30] <kiko> lifeless, dude, we're going to be opening dapper next week
[02:30] <spiv> .
[02:30] <kiko> I really don't imagine we want to live a toolchain switch for that 
[02:30] <lifeless> kiko: sabdfl is asking me daily where bzr for rf is at
[02:30] <kiko> I'll happily take the pie if I'm the one holding us back
[02:30] <kiko> dude
[02:31] <kiko> this needs to be phased in with a little more care than monday flick the switch
[02:31] <kiko> seriously
[02:31] <kiko> there will be issues
[02:31] <lifeless> well, I'm providing a service here, so you and steve a get to drive at this point
[02:31] <kiko> who here has used bzr before?
[02:31] <kiko> granted
[02:31] <lifeless> ddaa, niemeyer, mpt, keybuk, kinnion, spiv.
[02:31] <mpt> a little
[02:31] <niemeyer> \o
[02:31] <sabdfl> kiko: morning! how's gina today?
[02:31] <kiko> I haven't at all
[02:31] <kiko> sabdfl, is that a trick question
[02:32] <ddaa> niemeyer and I are working from our own little launchpad import
[02:32] <carlos> kiko, if you know bazaar you will be able to use bzr without documentation ;-)
[02:32] <mpool> tbh if it weren't for the pie thing
[02:32] <kiko> lifeless, has it been real-world tested with anything as big as launchpad in terms of history, team size and patch flow?
[02:32] <mpool> i'd prefer to do some workshops on it at montreal and then switch
[02:32] <kiko> mpool, I can take the pie if that's the problem
[02:33] <kiko> jesus
[02:33] <lifeless> lets not argue. I'm happy to wait indefinately.
[02:33] <sabdfl> no no
[02:33] <sabdfl> DOIT
[02:33] <spiv> kiko: otoh, our existing toolchain eats any system with less than 1GB of RAM ;)
[02:33] <lifeless> however the critical pipeline identified in brasil is there
[02:33] <lifeless> and I'm doing all the non launchpad projects first.
[02:33] <kiko> I'm not happy to wait indefinitely, but I don't want us to stop work next week because of the toolchain
[02:33] <SteveA> sabdfl: the concern is about any problems holding up dapper
[02:34] <sabdfl> AFAIK it's just gina now, right?
[02:34] <Kinnison> That and the final bits of queue merge from me
[02:34] <mpool> kiko: i feel about 0.8 sure you want have any showstopper bugs
[02:34] <Kinnison> and any tools I have to write
[02:34] <mpool> and fairly sure you will have some annoyances
[02:34] <kiko> mpool, then we will have the 0.2 that you're not sure about
[02:34] <kiko> :)
[02:34] <lifeless> 100% sure there will be annoyances
[02:34] <bradb> lifeless++ # realistic
[02:35] <kiko> 100% sure there will be issues that stop people from working 
[02:35] <jamesh> there will be annoyances whenever we do the switch
[02:35] <mpool> no, i don't think so
[02:35] <kiko> agreed with annoyances
[02:35] <mpool> i mean 20% chance there'll be something that stops people working
[02:35] <ddaa> with all the time people are already spending waiting after baz, I do not expect it to be huge blocker, relatively.
[02:35] <kiko> I asked a question
[02:35] <kiko> lifeless, has it been real-world tested with anything as big as launchpad in terms of history, team size and patch flow?
[02:36] <kiko> no answers so far
[02:36] <lifeless> kiko: no.
[02:36] <stub> And it never will be until we do it
[02:36] <kiko> I am not disagreeing, stub 
[02:36] <kiko> I am saying there will be issues.
[02:36] <lifeless> but.
[02:36] <kiko> (that will hamper work)
[02:36] <lifeless> it has been *tested* by bsd ports, by gentoo portage.
[02:36] <SteveA> lifeless: if you throw the switch on monday, then you're traveling, when will you be around to fix up problems?
[02:37] <kiko> so why not postpone it at a less time-critical moment?
[02:37] <kiko> second
[02:37] <mpool> lifeless: and, tbh, has been quite slow for them, but has not fallen over
[02:37] <lifeless> they are respectively 40 times our size and 60 times
[02:37] <mpool> quite slow == 40s commits
[02:37] <lifeless> mpool: right
[02:37] <kiko> can we revert back to baz if we find out we flicked the switch too early?
[02:37] <mpool> i'd call that "annoyance" not "can't work"
[02:37] <spiv> How hard would it be to reverse the switch throw if it all goes belly up?
[02:37] <kiko> right
[02:38] <lifeless> spiv: relatively easy. just change the config in the dists tree
[02:38] <mpool> so, hypothetically
[02:38] <jamesh> kiko: we'd still have all the trees up to the point of the switchover
[02:38] <spiv> mpool: 40s commits would be an *improvement* :)
[02:38] <mpool> would doing it after montreal be less risky?
[02:38] <lifeless> which me, stub, stevea can commit too
[02:38] <mpool> we'd have more chance to talk about what might happen
[02:38] <SteveA> hey, everyone.  this meeting is going to overrun by about 10 minutes.  sorry... there's always a first time.
[02:38] <mpool> can train everyone
[02:38] <mpool> can do some tests in person
[02:38] <kiko> I think mpool is smart.
[02:38] <jamesh> kiko: theoretically you could continue to work on your baz tree after the switch up until you wanted to merge
[02:38] <mpool> however, i don't see how you're going to be any less busy then than now
[02:38] <mpool> however, i suspect the sab will say i'm being a wimp
[02:39] <lifeless> I actually think this is the best time to do it
[02:39] <lifeless> because we will be Together to work out any issues that have arisen
[02:39] <lifeless> rather than missing the opportunity
[02:39] <mpt> 40s commits would be an improvement of about 90%
[02:39] <mpool> otoh we are meant to be planning in montreal, not fixing bzr bugs
[02:39] <lifeless> and you will -not- get the same immersion that you do when you are switched on to it.
[02:39] <kiko> mpool, not for the first week
[02:40] <kiko> lifeless, you didn't answer SteveA either.
[02:40] <lifeless> mpool: how can we plan 'needed things' when no one has really used it? Plus, were you not just suggesting training :)
[02:40] <lifeless> kiko: I arrive in montreal on tuesday at 0700
 lifeless: if you throw the switch on monday, then you're traveling, when will you be around to fix up problems?
[02:40] <SteveA> okay.  i thinnk that's acceptable
[02:40] <SteveA> let's do it monday.
[02:41] <SteveA> if a really bad thing happens, lifeless can sort it out from montreal
[02:41] <SteveA> bradb: we'll have internet from tuesday, right?
[02:41] <kiko> is internet access sorted in montreal already?
[02:41] <bradb> no idea
[02:41] <bradb> you'd have to ask cvd
[02:41] <lifeless> I can go to bradbs office
[02:41] <lifeless> on tuesday
[02:41] <SteveA> yes
[02:41] <SteveA> okay.  sorted.
[02:41] <SteveA> sabdfl: still here?
[02:41] <SteveA>  - spec day
[02:42] <SteveA> tomorrow is spec day.  it is the day when the launchpad team will have a bunch of phone and irc sessions
[02:42] <SteveA> to go through planning what specs we'll have at ubz
[02:42] <SteveA> i've put proposed times for the sessions here
[02:42] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/fileBwFx9W.html
[02:42] <SteveA> please look at this now
[02:42] <SteveA> and tell me now, if there is a problem with your time
[02:43] <SteveA> in fact
[02:43] <SteveA> please say "yes, that's fine"
[02:43] <SteveA> if it is fine
[02:43] <kiko> no lunch for me
[02:43] <jamesh> looks okay
[02:43] <mpt> yes, that's fine :-)
[02:43] <lifeless> fine
[02:43] <ddaa> fine
[02:43] <kiko> k
[02:43] <Kinnison> yes, that's fine
[02:43] <stub> yup
[02:43] <bradb> sounds good to me
[02:43] <BjornT> fine for me
[02:43] <stub> erm.... 'yes, that's fine'
[02:44] <cprov> fine
[02:44] <kiko> SteveA, why is mpt missing?
[02:44] <carlos> yes, that's fine
[02:44] <SteveA> kiko: he's special
[02:44] <salgado> SteveA, I won't be here tomorrow, as I mailed you and kiko
[02:44] <mpt> speshul
[02:44] <ddaa> mpt: you'r not a devel, you're a resident fascist.
[02:44] <SteveA> salgado: okay, can we talk later today?
[02:44] <mpool> uh
[02:44] <salgado> SteveA, sure
[02:44] <kiko> salgado, that's okay. you can dial in.
[02:44] <SteveA> it is for a phone call, kiko
[02:44] <mpool> i can't seem to get to that page
[02:45] <spiv> yes, that's fine.
[02:45] <kiko> SteveA, he will have a phone where he will be at..
[02:45] <SteveA> all these are for phone calls except the one with niemeyer and ddaa
[02:45] <SteveA> cool
[02:45] <SteveA> mpool: you're not on it, so that's okay
[02:45] <ddaa> SteveA: thanks
[02:45] <kiko> SteveA, why except ddaa and niemeyer?
[02:45] <kiko> why is mpt special, SteveA?
[02:45] <SteveA> ddaa specially requested irc rather than phone
[02:45] <ddaa> Because my english is too bad to handle phone comfortably.
[02:46] <bradb> me too
[02:46] <salgado> kiko, SteveA, I can't be sure I'll have a phone tomorrow at that time
[02:46] <SteveA> kiko: mark doesn't want to schedule a special phone call to talk about mpt-related specs tomorrow. we can talk about that later.
[02:46] <SteveA> salgado: okay, we'll sort that out another time, if we need to
[02:46] <SteveA> salgado: when do you travel to UBZ?
[02:47] <salgado> SteveA, monday (31)
[02:47] <SteveA> okay
[02:47] <SteveA> so we can maybe talk next week
[02:47] <SteveA> so, mark sent an email to the launchpad list asking:
[02:47] <SteveA> In order for us to plan things nicely, I would like to ask you please to
[02:47] <SteveA> register ALL your outstanding specs in Launchpad, today (Thursday).
[02:47] <SteveA> 
[02:48] <salgado> SteveA, sure. next week will be great. anyway, saturday I'll have a landline for sure
[02:48] <ddaa> SteveA: I guess that means registering a number of existing specs that need to be updated and/or rewritten.
[02:48] <stub> What exactly is an outstanding spec?
[02:48] <ddaa> (or just finished)
[02:48] <SteveA> so, this means specs you expect to be working on at UBZ
[02:48] <SteveA> specs that still need approval
[02:48] <sabdfl> hey, i don't mind a call for mpt
[02:48] <SteveA> specs that aren't yet implemented
[02:48] <SteveA> sabdfl: i think we ran out of time in that day, but it's possible in the next week
[02:49] <SteveA> or late late tomorrow
[02:49] <SteveA> actually, if salgado can't make it, mpt can take salgado's slot
[02:49] <SteveA> mpt: what do yo uthink?
[02:50] <mpt> one moment, please
[02:50] <mpt> 6pm? yup, I should be here
[02:50] <SteveA> okay, tvarka
[02:50] <SteveA> any other points / questions about spec day?
[02:51] <SteveA> okay
[02:51] <SteveA> - three sentences
[02:51] <mpt> actually, 5pm, I might not be back from class
[02:51] <mpt> I should be back by 5.30, possibly earlier
[02:51] <ddaa> DONE: BranchDataStorage, some fixing and testing, much Launchpad testing learning. Much teaching Niemeyer.
[02:52] <ddaa> TODO: More of the same: BranchDataStorage, teach Niemeyer.
[02:52] <ddaa> BLOCKED: xfs for python
[02:52] <salgado> DONE: Lots of random fixes and triaging, some code review and help to gneuman/matsubara
[02:52] <salgado> TODO: Code review, shipit reports, more random fixes
[02:52] <salgado> BLOCKED: No
[02:52] <SteveA> DONE: reviews, bugfixing
[02:52] <SteveA> TODO: travel to montreal.  reviews.  code.
[02:52] <SteveA> BLOCKED: no
[02:52] <matsubara> DONE: fixed bugs
[02:52] <matsubara> TODO: fix more bugs, faster if possible
[02:52] <matsubara> BLOCKED: no
[02:52] <mpt> DONE: Style sheet cleanup; trying to land big branches with little success.
[02:52] <mpt> TODO: Finish landing branches, LaunchpadMenus-checking blitz.
[02:52] <mpt> BLOCKED: baz per usual.
[02:52] <bradb> DONE: Landed: admin awareness for private bugs, priority/title breakage fix, sortwidget. Demo'd smart nav portlet to kiko.
[02:52] <bradb> TODO: Finish smart nav portlet. Do some long needed QA. Save the world.
[02:52] <bradb> BLOCKED: No.
[02:52] <spiv> DONE: Parts of AuthServerCaching, reviews, some miscellanous bzr (segfault hunting).
[02:52] <spiv> TODO: Polish and merge AuthServerCaching code.
[02:52] <spiv> BLOCKED: no.
[02:52] <lifeless> DONE: bzr rollouts happening.
[02:52] <niemeyer> DONE: Fixed taxi+tests in importd, discussions with David, fixes on Smart, fixes on svn2bzr, upgraded system, ...
[02:52] <niemeyer> TODO: Put buildbot to work, Sprint with David next week.
[02:52] <niemeyer> BLOCKED: Nope
 DONE: Uploader done. Queue processor well on the way, various publisher and build system tweaks done or guided.
 TODO: Finish Queue processor, open dapper goddamnit
 BLOCKED: Gina rework being finished by kiko and run on production. I have little-to-no time to help with this unfortunately :-(
[02:52] <lifeless> TODO: finish that, flyl
[02:52] <jamesh> DONE: fix pending-reviews to work with new bzr / bugzilla -> LP importer / scheduler
[02:52] <jamesh> TODO: finish off bugzilla importer / code reviews
[02:52] <jamesh> BLOCKED: no
[02:52] <lifeless> LBOCKED: hours in day
[02:52] <gneuman> DONE: finally merged namefield fixes
[02:52] <BjornT> DONE: started making ticket tracker send some emails, landed one branch. reviews. general ticket tracker and malone work.
[02:52] <stub> DONE: LaunchpadBrowserNotifications
[02:52] <stub> TODO: Production and staging procedures with bzr, maybe LibrarianGarbageCollection
[02:52] <stub> BLOCKED: Converting my archive to bzr
[02:52] <BjornT> TODO: make ticket tracker send more mail, start with the incoming interface.
[02:52] <BjornT> BLOCKED: no
[02:53] <carlos> DONE: RosettaTeamlessTranslating, new attach infrastructure and merged my language pack branch
[02:53] <gneuman> TODO: improve a few pagetests and more samll fixes
[02:53] <gneuman> BLOCKED: no
[02:53] <mpool> DONE: part of faster storage, various tests and bugs, learned something about twisted
[02:53] <carlos> TODO: New attach infrastructure, bug triage, user support
[02:53] <carlos> BLOCKED: no
[02:53] <mpool> TODO: 0.6 release, finish faster storage, catch up on patches
[02:53] <mpool> BLOCKED: no
[02:53] <kiko> DONE: can't remember very well. gina work, bugfixing, helping users, helping interns, merging fixes from matsubara and gneuman
[02:54] <cprov> DONE: dependency-aware scoring and loading ZCML infor for buildd scripts
[02:54] <SteveA> jblack: DONE: Traffics, bazaar-ng support, some supermirror planning
[02:54] <SteveA> jblack: TODO: Lot of supermirror planning, bazaar-ng support
[02:54] <SteveA> jblack: BLOCKED: sysadmin stuff
[02:54] <cprov> TODO: uploader integration, missed issues for buildd open dapper and builddUI
[02:54] <cprov> BLOCKED: None
[02:54] <kiko> TODO: fix gina, spec stuff, travel to montreal
[02:54] <kiko> BLOCKED: no, but would need more time to do all of this
[02:54] <ddaa> BLOCKED: https://launchpad.net/bazaar/series/+bazaar-index is borken
[02:54] <kiko> ddaa, broken...?
[02:54] <kiko> can I help?
[02:55] <ddaa> kiko: try it: AssertionError: ProductSeriesSet not initialised with product.                    
[02:55] <SteveA> okay, so i have some sysadmin stuff to check out
[02:55] <SteveA> sysadmin stuff:
[02:55] <SteveA>  - xfs for python
[02:55] <SteveA>  - diskspace on supermirror
[02:55] <SteveA>  - planet bazaar setup
[02:55] <SteveA> 
[02:55] <kiko> ddaa, no pagetest? gross. okay, do you need a fix like now-ish?
[02:55] <kiko> or can you fix?
[02:55] <SteveA> kiko, ddaa: that is a Subset not a Set then.  and it is probably misdesigned...
[02:55] <lifeless> yes, and they are edging into the months
[02:56] <SteveA> lifeless: noted
[02:56] <SteveA> okay.
[02:56] <SteveA> any other blocked issues not dealt with?
[02:56] <kiko> xfs for python is sweet
[02:56] <ddaa> kiko: can work-around it actually, thanks to sql superpowers. Filing bug now. High priority, please
[02:56] <SteveA> okay
[02:56] <SteveA> that's it folks
[02:56] <SteveA> MEETING ENDS
[02:57] <spiv> Thanks.
[02:57] <carlos> thanks
[02:57] <bradb> jamesh: Do you have a bugzilla dump yet?
[02:57] <gneuman> thx
[02:57] <spiv> SteveA: Good job keeping the meetings on time until this week, btw :)
[02:57] <mpt> SteveA: Do you have time to explain a test failure to me?
[02:57] <jamesh> bradb: yeah.  I got it at the end of last week
[02:57] <kiko> ddaa, I can fix it nowish then.
[02:57] <kiko> FFS
[02:58] <cprov> SteveA: do you have finished that review ?
[02:58] <bradb> jamesh: Sweet! Do you know on what day it's planned to run an import on production?
[02:58] <SteveA> mpt: gotta get some food
[02:58] <mpt> kiko?
[02:58] <SteveA> spiv: this will be a one-off seldom repeated extention by 10 mins
[02:58] <SteveA> spiv: i'll repeat it only for baz 3.0
[02:58] <kiko> mpt, what test failure are you getting?
[02:58] <mpt> File "/home/mpt/ubuntu/launchpad/lib/canonical/launchpad/ftests/../doc/distrorelease.txt", line 108, in distrorelease.txt
[02:59] <mpt> Failed example:
[02:59] <mpt>     for c in hoary.real_components:
[02:59] <mpt>         print c.name
[02:59] <mpt> Differences (ndiff with -expected +actual):
[02:59] <mpt>     - main
[02:59] <mpt> and one other like that.
[02:59] <ddaa> kiko: bug 3410
[02:59] <Ubugtu> Malone bug #3410: Bazaar index page is broken Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3410
[02:59] <SteveA> cprov: no.  i'll look later today.
[02:59] <jamesh> bradb: no plan yet, but it should be ready for a test fairly soon -- just decide which bugs to import, and whether the information not getting imported is important
[02:59] <cprov> SteveA: right, thank you
[02:59] <jamesh> bradb: e.g. I'm not currently importing duplicated status, but that wouldn't be important if we skipped dups
[03:00] <bradb> jamesh: did you mean "just decide" (like me) or "just deciding" (like that's something you're doing now)?
[03:00] <mpt> jamesh: Will bugzilla be retired at the same time?
[03:01] <jamesh> bradb: probably some people on the Ubuntu team; as I understand it we won't be importing many (any?) closed bugs though.
[03:01] <jamesh> mpt: it will remain, but be readonly
[03:01] <mpt> ok
[03:02] <mpt> Linking to the equivalent Launchpad bug report would be nice :-)
[03:02] <jamesh> mpt: each imported bug will have a bugwatch pointing at the corresponding bugzilla bug in case there is useful info still there
[03:02] <mpt> (redirecting would be nicer, but probably not a good idea for debugging purposes)
[03:02] <jamesh> mpt: yeah.  that is also planned.
[03:02] <bradb> jamesh: from reading your 3s, you're not blocked at all on doing the import work then, right?
[03:02] <kiko> jamesh, but not a task linked to the watch, I assume?
[03:02] <mpt> kiko: any idea? It's not part of the code I've touched
[03:02] <spiv> SteveA: Well, the lack of meeting next week compensates for it nicely. ;)  Seriously, I appreciate your discipline -- thanks.
[03:02] <mpt> hummmm, maybe it's a database issue
[03:03] <jamesh> kiko: no.
[03:03] <kiko> okay.
[03:03] <jamesh> bradb: I think the code is pretty much ready for a test import on staging
[03:04] <kiko> meeting ends?
[03:04] <bradb> it already ended
[03:04] <kiko> that's tragic
[03:04] <kiko> no countdown
[03:04] <jamesh> kiko: not much point in getting the bug watch to update a task if the corresponding bugzilla isn't going to change ...
[03:04] <bradb> jamesh: freaky cool. when can we do that test import?
[03:04] <kiko> jamesh, that's right, which is why I was asking.
[03:05] <jamesh> bradb: I'll see if I can get the last bits sorted tomorrow
[03:05] <jamesh> here's the list of information I'm not migrating at the moment:
[03:05] <jamesh> #  * Operating system and platform
[03:05] <jamesh> #  * version (not really used in Ubuntu bugzilla though)
[03:05] <jamesh> #  * target milestone
[03:05] <jamesh> #  * keywords
[03:05] <jamesh> #  * private bugs (none of the canonical-only bugs seem sensitive though)
[03:05] <jamesh> #  * bug dependencies
[03:05] <jamesh> #  * duplicate bugs
[03:05] <jamesh> #  * "bug XYZ" references inside comment text (would need a second pass)
[03:06] <jamesh> a fair number of those probably don't matter though
[03:07] <bradb> those exclusions seems reasonable
[03:07] <bradb> s/seems/seem/
[03:08] <bradb> jamesh: so a test run possibly mondayish, you think?
[03:08] <mpt> jamesh: that last one would be icky
[03:09] <kiko> jamesh, how do you mean, bug XYZ references won't be migrated -- do you import unlinked text (that launchpad will linkify to launchpad bugs)?
[03:09] <jamesh> bradb: yeah, with assuming we can get access to the database set up
[03:09] <bradb> indeed. sounds good.
[03:09] <kiko> jamesh, I think we should swap bug XXX for the URL 
[03:10] <jamesh> kiko: if a bug has a comment like "bug $BUGZILLA_NUM", it will stay like that rather than being changed to "bug $LAUNCHPAD_NUM"
[03:10] <SteveA> stub: that branch i asked to be cherrypicked is at #4 in pqm now
[03:10] <kiko> jamesh, I think you should do a textswap
[03:10] <kiko> otherwise the links will be crazy
[03:11] <kiko> jamesh, s/bug XXX/<a href="http://...">http://...</a>
[03:11] <jamesh> kiko: yeah.  I haven't done it yet because it requires a second pass through the bugs
[03:11] <sabdfl> jamesh: the textswap is a pretty awesome idea :-)
[03:11] <kiko> jamesh, why?
[03:11] <sabdfl> kiko: so you know which number to swap to
[03:11] <kiko> when you encounter a bug reference, 
[03:11] <kiko> oh
[03:11] <jamesh> kiko: if bug N links to bug N+1, and I import them in order, I don't know the Launchpad bug number of N+1
[03:11] <kiko> I'm not saying link to the launchpad bug
[03:11] <kiko> I'm saying keep a link to the ubuntu bug, jamesh 
[03:11] <sabdfl> but i am :-p
[03:12] <kiko> the bug may not even have been imported, sabdfl 
[03:12] <kiko> that's crazy
[03:12] <kiko> it's a lot simpler to just swap bug XXX for a link to the ubuntu bugzilla
[03:12] <sabdfl> sure, just create the bug watch
[03:12] <sabdfl> that happens automatically
[03:13] <sabdfl> using... some method on BugWatchSet ... .fromText I tihkn
[03:13] <kiko> in the comment text, I mean
[03:13] <sabdfl> but why not make it point at the relevant launchpad bug, if in fact that bug has been imported?
[03:13] <kiko> well, because of the added complexity
[03:13] <mpt> jamesh: If you're importing in order, bug N is never going to link to bug N+1 except by accident
[03:14] <kiko> I'm talking 5c fix here
[03:14] <kiko> not an afternoon of work
[03:14] <mpt> jamesh: so you should be able to do it in one pass.
[03:14] <kiko> mpt, why not?
[03:14] <kiko> I could file bug X
[03:14] <kiko> you could file bug X+1
[03:15] <kiko> I could add a comment linking bug X to bug X+1?
[03:15] <jamesh> mpt: I can add a comment to bug 1 that says "see bug 2"
[03:15] <Ubugtu> Malone bug #1: Microsoft has a majority market share Fix req. for: Ubuntu, Severity: Critical, Assigned to: Mark Shuttleworth, Status: Accepted http://launchpad.net/malone/bugs/1
[03:15] <Ubugtu> Error: Error getting Malone bug #2: Bug does not exist
[03:15] <mpt> kiko: Because Bugzilla doesn't allow editable descriptions, and at least 99.9% of bug reporters aren't psychic
[03:15] <mpt> ahhhhh, comments
[03:15] <kiko> wtf do editable descriptions have to do with anything
[03:15] <kiko> there are no descriptions in the bugzilla schema
[03:15] <jamesh> here's an HTML dump of one of the imported bugs: https://chinstrap.ubuntu.com/~jamesh/malone-bugzilla-import.html
[03:15] <kiko> only comments
[03:15] <kiko> comment 0 is called description in the UI
[03:16] <sabdfl> does ubugtu know about private bugs?
[03:16] <mpt> sabdfl: the error for a private bug is different from the error it just gave, yes
[03:16] <sabdfl> coolio
[03:16] <mpt> something like "I can't get the information for xxx
[03:16] <mpt> "
[03:16] <sabdfl> "fuck off, stranger?"
[03:16] <kiko> sabdfl, it knows it can't access it
[03:16] <kiko> thank Seveas 
[03:16] <sabdfl> thanks, Seveas
[03:17] <Seveas> yw :)
[03:17] <sabdfl> jamesh: that import rocks. was the debugs sync stuff useful?
[03:17] <jamesh> so that page shows it importing comments with the right dates (creating people as necessary), importing attachments, and bug info
[03:17] <jamesh> sabdfl: it was useful as a guide
[03:18] <sabdfl> find any bugs?
[03:18] <jbailey> zyga: pong
[03:18] <jamesh> sabdfl: I found a bug in the IBug.findCvesInText(), but have merged the fix for it in
[03:18] <zyga> jbailey: hey
[03:18] <sabdfl> thanks dude
[03:19] <zyga> jbailey: know issue already, broken package in your repo this morning
[03:20] <jamesh> in that particular dump, the bug is filed directly against ubuntu because there is no "hal" package in the sample data
[03:20] <jamesh> if I import a firefox bug, it gets filed correctly
[03:20] <jbailey> zyga: Thanks, I'll check what happpened.
[03:20] <zyga> jbailey: indentation error
[03:20] <stub> lifeless: Can you please change the format of the production-1.37 config so I can get some cherry picks through PQM?
[03:21] <zyga> jbailey:  /usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py
[03:21] <zyga> I guesss around line 70
[03:21] <zyga> jbailey: #bzr for anything more
[03:21] <Nafallo> zyga, jbailey: I think there is a bug in Malone about it already :-).
[03:22] <kiko> jamesh, will you consider my workaround for linkification?
[03:22] <zyga> Nafallo: a bug about extra whitespace, shessshh... :-)
[03:22] <kiko> jamesh, filtering out "Created an attachment (id=\d+)" is a definite plus :)
[03:23] <kiko> jamesh, looks sweet!
[03:24] <Nafallo> zyga: #3366 :-)
[03:24] <bradb> Bring on Dapper.
[03:25] <sabdfl> bradb: +1
[03:25] <bradb> :)
[03:26] <Simira> why isn't my code of conduct in launchpad yet?
[03:27] <jbailey> ajmitch: I can't reasonably sign the archive.  I run apt-ftparchive on a remote machine, I have no way of trusting it.
[03:28] <jbailey> ajmitch: That and apt would have no reason to trust my key, I think.
[03:32] <stub> So all the launchpad devs are supposed to be running untrusted debs?
[03:33] <jamesh> kiko: sure.  I'll do do something like that.
[03:33] <kiko> thanks jamesh 
[03:33] <stub> Sounds like we need to build from source ourselves then
[03:33] <jamesh> kiko: I actually search for the "Created an attachment" text after adding the comments to decide which bugmessage to link the attachment to
[03:34] <jamesh> jbailey: too bad you can't sign packages :(
[03:34] <kiko> jamesh, hoho
[03:34] <stub> The 'I have no way of trusting it' is the worrying bit. You can always sign the packages.
[03:34] <jamesh> (as opposed to an entire repository, that is)
[03:35] <jamesh> stub: you can't directly attach signatures to deb packages though
[03:35] <jamesh> (yet)
[03:35] <jbailey> jamesh: debsigs will work, but nothing looks at them.
[03:35] <jbailey> It's existed for ages.
[03:35] <jbailey> stub: Dude, what do you mean by "untrusted"
[03:35] <stub> (20:27:48) jbailey: ajmitch: I can't reasonably sign the archive.  I run apt-ftparchive on a remote machine, I have no way of trusting it.
[03:35] <jbailey> stub: It goes from my machine to a Canonical owned machine.
[03:36] <stub> ok then ;)
[03:36] <jamesh> jbailey: but elmo could replace your packages with trojans
[03:36] <jbailey> stub: I beleive that it's probably safe.  But it would be unreasonable for me to put my signature on anything that's generated on the remote machine.
[03:36] <jbailey> jamesh: Right!
[03:36] <stub> jbailey: It is reasonable. Just create a key to sign those archives.
[03:36] <jbailey> jamesh: If you trust Canonicals machines, then this repo is safe.
[03:37] <jbailey> stub: True.  I wonder if gpg is installed on rookery.
[03:37] <stub> I don't trust my network, and retrieving unsigned debs via HTTP is naughty
[03:37] <jbailey> stub: The source is equally unsigned. =)
[03:38] <stub> gah
[03:38] <lifeless> stub: sure
[03:38] <jbailey> Ah it is.
[03:38] <jbailey> Hmm
[03:38] <jbailey> So I will create a passwordless gpg key the is only readable by my UID and is sitting on the common machine.
[03:39] <jbailey> And therefore should be as secure as the debs themselves.
[03:39] <stub> Yup
[03:39] <jbailey> So you're protected in transit anyway.
[03:39] <jbailey> Of course, https would protect you just as well... =)
[03:39] <jamesh> jbailey: does apt do SSL certificate checks? :)
[03:40] <jbailey> jamesh: No.  You'll have to add this public key to your keyring too, though.
[03:40] <jbailey> Actually, right.  apt doesn't do https.
[03:41] <jbailey> I forgot that is on my hack-sometime-when-I'm-bored list.
[03:41] <stub> There is UI in synaptic for that so update-manager will happily suck in the daily builds
[03:41] <stub> jbailey: Feel free to fix the baz dailies while you are at it ;)
[03:42] <jbailey> stub: I am not involved in the baz dailies.
[03:42] <lifeless> ddaa: :!  File "/home/pqm/source/pybaz/pybaz/_patchlog.py", line 326, in _get_new_patches
[03:42] <lifeless>   File "/home/pqm/source/pybaz/pybaz/_builtin.py", line 140, in Revision
[03:42] <lifeless>   File "/home/pqm/source/pybaz/pybaz/_builtin.py", line 1790, in __init__
[03:42] <lifeless> NamespaceError: invalid fully-qualified revision: 29034.3
[03:42] <jbailey> stub: If you put then in a bzr repo, I'll add them to my nightlies. =)
[03:42] <lifeless> stub: whats wrong with the baz dailies ?
[03:42] <jbailey> Hmm.
[03:42] <lifeless> jbailey: they autobuild on commit, better than nightly
[03:42] <ddaa> lifeless: sounds like a corrupt patchlog
[03:42] <stub> lifeless: http://bazaar.canonical.com/packages/debs/./Release: Unable to find expected entry  Sources in Meta-index file (malformed Release file?)
[03:42] <jbailey> lifeless: I think that would be difficult for me to arrange for a remote bzr repo. =)
[03:43] <jbailey> Hmm
[03:43] <lifeless> ddaa: garfunkel.
[03:43] <lifeless> ddaa: I'll bet its stub again
[03:44] <stub> I certainly hope so ;)
[03:45] <lifeless> stub: IIRC you only corrupted your tree, not hte archive.
[03:45] <lifeless> right ?
[03:46] <jamesh> lifeless: on the PQMSetup wiki page, it doesn't look like the bzr pqm submit script specifies a revision number.
[03:46] <lifeless> jamesh: it does not.
[03:46] <lifeless> bzr will not do empty merges by default though
[03:47] <lifeless> so the commits will not go through
[03:47] <lifeless> hmm
[03:47] <stub> lifeless: I can't remember what happened or how many times. I do seem to recall corruption in my archive infecting rocketfuel though.
[03:48] <lifeless> ddaa: pybaz.PatchLog, is there something that grabs that from the archive ?
[03:48] <jamesh> lifeless: but if I send a merge request then do another commit, it will pick up those extra changes when the request gets processed, right?
[03:51] <jbailey> stub: https doesn't seem to be worknig on people.ubuntu.com at the moment.  Do you have ssh access to rookery?
[03:51] <jbailey> Otherwise getting the public key might be a bit of a challenge.
[03:52] <stub> jbailey: Nope. scp it to chinstrap or send it in a signed email to the launchpad mailing list (?)
[03:53] <jbailey> Hmm, I can scp it to chinstrap.  But you need to know that it crossed a network connection then.
[03:57] <jbailey> stub: chinstrap:~jbailey/snapshotkey/repositorykey.asc
[03:59] <stub> jbailey: ta
[04:02] <jbailey> stub: It's done now.
[04:03] <stub> http://people.ubuntu.com/~jbailey/snapshot/bzr/./Release: Unable to find expected entry  Packages in Meta-index file (malformed Release file?)
[04:03] <stub> (I've seen that before I think..)
[04:03] <jbailey> Err, hmm
[04:03] <jbailey> I didn't get that when I ran it just before I said it was ready...
[04:04] <jbailey> Get:3 http://ca.archive.ubuntu.com breezy Release.gpg [189B] 
[04:04] <jbailey> Get:4 http://ca.archive.ubuntu.com breezy-updates Release.gpg [189B] 
[04:04] <jbailey> I get this at the end:
[04:04] <jbailey> W: GPG error: http://people.ubuntu.com ./ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B0B7481B1F44842D
[04:04] <jbailey> But that's expected, since I haven't said to trust the key yet.
[04:05] <kiko> stub, can I have your help in finalizing fixes for bug 2668 and 2669? I need your opinion
[04:05] <Ubugtu> Error: I cannot access this bug
[04:05] <jbailey> stub: Are you running released breezy?
[04:05] <stub> yes
[04:06] <jbailey> Hmm, so much for an easy one. =)
[04:06] <stub> I'm running this with synaptic btw.
[04:06] <lifeless> night all
[04:06] <jbailey> stub: Can you try apt-get?
[04:06] <lifeless> stub: that config is fixed
[04:07] <kiko> stub, privmsged
[04:07] <Nafallo> jbailey: I'll get that error aswell :-)
[04:07] <stub> Failed to fetch http://people.ubuntu.com/~jbailey/snapshot/bzr/./Release  Unable to find expected entry  Packages in Meta-index file (malformed Release file?)
[04:07] <stub> Reading package lists... Done
[04:07] <stub> W: Couldn't stat source package list http://people.ubuntu.com ./ Packages (/var/lib/apt/lists/people.ubuntu.com_%7ejbailey_snapshot_bzr_._Packages) - stat (2 No such file or directory)
[04:08] <stub> lifeless: ta
[04:08] <jbailey> Nafallo: Right.  But if it works in apt-get, then I'll punt it off to someone who knows something about synaptic. =)
[04:08] <jbailey> Oh!
[04:08] <Nafallo> jbailey: indeed. mvo we go then ;-).
[04:08] <jbailey> You have src packages in your /etc/apt/sources.list
[04:08] <jbailey> Lemme add those.
[04:08] <kiko> ddaa, ping?
[04:09] <jbailey> Nafallo: Patience, my little smurf. =)
[04:09] <ddaa> kiko: wassup?
[04:09] <jbailey> Nafallo: We still haven't gotten rid of all the errors with apt-get yet. =)
[04:09] <Nafallo> jbailey: which ones? :-P
[04:09] <Nafallo> gpg: requesting key 1F44842D from hkp server subkeys.pgp.net
[04:09] <Nafallo> gpgkeys: key 1F44842D not found on keyserver
[04:09] <Nafallo> ey! :-P
[04:10] <jbailey> Nafallo: It's on chinstrap or at http://people.ubuntu.com/~jbailey/snapshot/repositorykey.asc
[04:10] <kiko> ddaa, do you ever mark products or projects inactive?
[04:10] <ddaa> kiko: pong
[04:10] <ddaa> hu... well... if I know what that's useful for...
[04:10] <jbailey> Nafallo: It's only self signed, so fetching it over unencrypted http is just as safe as getting it from a keyserver.
[04:10] <kiko> ddaa, if so, would you be okay with them returning 404s and requiring manual DBA intervention to turn back on?
[04:10] <jbailey> (safer, in fact)
[04:11] <kiko> ddaa, it will turn them /off/
[04:11] <Nafallo> jbailey: indeed.
[04:11] <kiko> no more traversing to them
[04:11] <ddaa> kiko: I think this feature needs designing.
[04:11] <kiko> ddaa, please comment in bug 2668 and 2669 then.
[04:11] <Ubugtu> Error: I cannot access this bug
[04:11] <ddaa> kiko: either a project is linked to by something, and it should not turn inactive, or it's not, and it can be deleted
[04:12] <kiko> ddaa, the only place where it can be changed is +review. 
[04:12] <kiko> ddaa, isn't this preliminary fix reasonable?
[04:12] <ddaa> bug 2668
[04:12] <Ubugtu> Error: I cannot access this bug
[04:12] <jbailey> Nafallo: So you're not seeing the error that stub is.
[04:12] <jbailey> I'm not seeing it either.
[04:12] <ddaa> bug 2669
[04:12] <Ubugtu> Error: I cannot access this bug
[04:12] <Nafallo> jbailey: yes
[04:12] <kiko> anyway
[04:12] <jbailey> stub: Sorry dude, no idea.  Have to punt this to mvo then for further troubleshooting.
[04:13] <ddaa> kiko, I can imagine that being sort of annoying... since that will prevent admins (like me) doing anything with inactive product/projects
[04:14] <ddaa> kiko: however, I think it makes sort of sense as a preliminary thing.
[04:14] <stub> jbailey: The paste before was from apt-get. Hmm... 
[04:14] <kiko> ddaa, okay, cool. the way to do it would be to have traversal work and then change brower code to say it was inactive, I guess.
[04:14] <kiko> I'll leave that till when somebody complains about it
[04:14] <kiko> stub, no chance for a quick comment from you?
[04:14] <jbailey> stub: Right.  But since neither nafallo and I are seeing it with apt-get, I have to pass you on to someone who knows apt-get better than I.
[04:15] <ddaa> deleting++
[04:15] <kiko> ddaa, can I rs=ddaa on that? :)
[04:15] <stub> jbailey: ic
[04:15] <stub> kiko: eh?
[04:15] <kiko> stub, see privmsg
[04:15] <jbailey> stub: The problem still could be something I've done in the repo, but I don't know what it is or how to find it.
[04:15] <stub> (21:08:51) stub: Sure. Or leave it like it is - +review is admins only so fixing UI glitches is low priority
[04:15] <kiko> I realize you're busy
[04:15] <Nafallo> jbailey: I'll see the error stub see about malformed Releasefile. I'm digging into it atm :-)
[04:15] <kiko> stub, I never got that. are you not registered?
[04:16] <stub> i am registered
[04:16] <ddaa> kiko: more importantly, I think you need to fix all the rest of launchpad so you do not get broken links.
[04:16] <jbailey> Nafallo: Lovely, thanks!
[04:16] <kiko> stub, okay. this feature may add some DBA overhead (to reactive products/projects) but I guess you're okay with that.
[04:16] <kiko> ddaa, that can also be done later :)
[04:16] <ddaa> broken links = bugs
[04:17] <stub> kiko: unhiding hidden products will be rare, and possibly never happen at all.
[04:17] <Nafallo> jbailey: (basically looking at breezy's Release and try to figure out what's missing ;-))
[04:17] <kiko> stub, cool
[04:19] <Nafallo> jbailey: where did the Release-files go? :-P
[04:20] <ddaa> kiko: I sort of think that 410 might be more approriate, but maybe not since things can be reactivated, or renamed over...
[04:20] <jbailey> Nafallo: 10:17  * jbailey tries the automated update, and apt-get update will break for
[04:20] <jbailey>           a moment.
[04:20] <jbailey> Nafallo: It's back now. =)
[04:20] <ddaa> kiko: 404 links sort of give a knee-jerk reaction "show me my page, stupid!"
[04:21] <kiko> yeah
[04:21] <kiko> ddaa, we could make it return a special "disabled" page
[04:21] <ddaa> kiko: at least, you should give 404 with a personalised error page that explains what's the matter with this page.
[04:21] <kiko> and then reap these later
[04:21] <kiko> ddaa, sure -- but not today
[04:21] <Nafallo> jbailey: ehm, 0 Release
[04:21] <kiko> I'll file a bug on that
[04:21] <jbailey> ddaa: Sort of like internal error pages that tell me to go file a bug?  My thought is always (You have more info than I do.  You have referrer and the state of this page.  What more do you want?" *g*
[04:21] <Nafallo> jbailey: why doesn't Release have a size?
[04:21] <salgado> BjornT, you got mail
[04:22] <jbailey> Nafallo: The snake eats it's own tail...
[04:22] <jbailey> Nafallo: It doesn't exist yet at that point.
[04:22] <Nafallo> jbailey: try to cut it out from there? :-)
[04:22] <ddaa> jbailey: that's different, we want to say to the user "the product you are trying to view is inactive."
[04:22] <jbailey> ddaa: Ah. =)
[04:23] <Nafallo> it shouldn't have to know about itself :-P
[04:23] <jbailey> Nafallo: It shouldn't attempt to know about itself  Sounds like  afun bug in apt-ftparchive.
[04:23] <Nafallo> indeed.
[04:23] <stub> lifeless: I now remember that the branch the bzr migration code stopped on was pretty stuffed. Is there any way to tell the migrater 'skip this branch', or should I just remove the directory on chinstrap?
[04:23] <ddaa> kiko: jbailey has a point, if the referrer is launchpad, we should say "sorry, we're a lazy bunch and we've not yet fixed the dangling links to inactive products", if the referrer is external we should say "this product is no longer active, go to hell".
[04:24] <jbailey> Nafallo: Lemme try something, JustASec.
[04:24] <ddaa> Except in more friendly terms, but friendliness is not my dept.
[04:24] <Nafallo> jbailey: sure :-).
[04:25] <ddaa> kiko: anyway to answer the initial question, making inactive things 404 should not prevent me from working.
[04:25] <ddaa> I just find it in bad taste.
[04:25] <ddaa> IOW go ahead
[04:26] <Kinnison> carlos: ping
[04:26] <carlos> Kinnison, pong
[04:26] <Kinnison> carlos: rosetta tarball imports
[04:26] <Kinnison>     def publish_ROSETTA_TRANSLATIONS(self):
[04:26] <Kinnison>         """See IDistroReleaseQueueCustom."""
[04:26] <Kinnison>         raise NotImplementedError()
[04:26] <Kinnison> I have... a context (distrorelease, sourcepackagerelease etc)
[04:26] <Kinnison> that is published
[04:27] <Kinnison> I have a libraryfilealias of the tarball
[04:27] <Kinnison> care to tell me what to call?
[04:27] <carlos> the method is not yet at rocketfuel
[04:27] <Kinnison> Oh okay
[04:27] <carlos> are your changes at rocketfuel?
[04:27] <carlos> or your branch?
[04:28] <Kinnison> no, I'm writing the queue stuff now
[04:28] <Kinnison> I've almost finished it ready for review
[04:28] <Kinnison> Any idea when your stuff will hit RF?
[04:28] <carlos> hmmm. Will it land into production next Tuesday?
[04:28] <Kinnison> It'll have to hit production before we can open dapper
[04:29] <Kinnison> so I can grant access for the queued user
[04:29] <Kinnison> stub: did you add a queued user to chinstrap?
[04:29] <carlos> Kinnison, well, my performance has been a bit low this week but I will work a bit this weekend so I hope It will be merged on Monday
[04:30] <Kinnison> that's cool
[04:30] <stub> Kinnison: yes
[04:30] <Kinnison> I'll leave an XXX in there
[04:30] <Kinnison> stub: thanks dude
[04:30] <jordi> sabdfl: I just added mark@ubuntu.com as a valid address to post to rosetta-users@; it seems you've changed your mail setup
[04:30] <carlos> Kinnison, I could do that integration for you
[04:30] <carlos> Kinnison, before merging my changes
[04:30] <Kinnison> carlos: that'd be cool
[04:31] <carlos> Kinnison, perhaps you could add there the XXX: and pass
[04:31] <Nafallo> jbailey: got my msg?
[04:31] <Kinnison> carlos: I'll do something like that
[04:31] <carlos> and I will integrate it with my code removing the pass and adding the real call
[04:32] <jbailey> Nafallo: Had wandered off to the bathroom.
[04:32] <carlos> lifeless, SteveA https://chinstrap.ubuntu.com/~dsilvers/paste/fileDt8eRR.html
[04:32] <carlos> I get that error with a merge request
[04:33] <Nafallo> jbailey: that didn't answer the question now, did it? ;-)
[04:33] <jbailey> Nafallo: I can add that, but funny that my apt-get isn't erorring the same way.
[04:34] <Nafallo> jbailey: indeed. no idea why though.
[04:34] <Nafallo> jbailey: (this is breezy) ;-)
[04:34] <jbailey> Yeah, so is mine
[04:36] <jbailey> Nafallo: The zero byte Release file is always mentioned there.  I don't know why.
[04:36] <Nafallo> k
[04:36] <Nafallo> so the problem for me is Packages ;-)
[04:37] <BjornT> stub: https://launchpad.net/people/motu/+assignedbugs causes a RequestExpired exception. do you have time to look at it, to see how to make it more optimized? (it's hard for me to do it without db access)
[04:37] <jbailey> Nafallo: Should it be Packages.gz.gpg?
[04:38] <Nafallo> jbailey: huh? just try adding an uncompressed Packages :-)
[04:38] <Nafallo> and in the Release-file aswell...
[04:39] <Nafallo> fwiw, I'm trying to make my home-repo doing the same thing :-P
[04:39] <kiko> SteveA, I have a question about /bazaar
[04:39] <kiko> or ddaa 
[04:39] <SteveA> yeah
[04:39] <SteveA> i'm back now
[04:40] <kiko> ddaa, what is /bazaar/series/ supposed to take you to?
[04:40] <ddaa> yeah
[04:40] <ddaa> he's back now
[04:40] <jbailey> Nafallo: As well as the compressed or instead of?
[04:40] <kiko> ddaa, I have no clue, honestly
[04:40] <ddaa> SteveA: what kiko just said
[04:40] <kiko> the code is completely broken
[04:40] <Nafallo> jbailey: as well as.
[04:40] <ddaa> kiko: I have no clue either
[04:40] <SteveA> i have no idea
[04:40] <SteveA> this needs a design
[04:40] <SteveA> some specs
[04:40] <SteveA> some communication about what it needs to do
[04:40] <ddaa> SteveA: we need fewer specs
[04:40] <ddaa> not more
[04:40] <stub> BjornT: Is the page batched? If the rendering takes ages the timeout will only be triggered on the next SQL command
[04:41] <SteveA> we need clearer communication about what "the bazaar" is supposed to do
[04:41] <ddaa> I have several dozen baz-related specs that need cleaning up.
[04:41] <SteveA> if that means more or fewer specs, whatever
[04:41] <SteveA> but it means clearer and more accurate specs
[04:41] <kiko> ddaa, why is fixing /bazaar/series urgent if we don't even know what it should do?
[04:41] <ddaa> kiko: somebody dumped that stuff on me, like 6 months ago
[04:41] <ddaa> kiko: because the index page is what allows me to see what passed autotest
[04:41] <kiko> that's okay
[04:41] <kiko> ah
[04:42] <kiko> that's relevant
[04:42] <kiko> can you tell me some text that is on that page?
[04:42] <ddaa> you want what, the template?
[04:42] <kiko> yes
[04:42] <kiko> aha
[04:42] <kiko> sources-index!
[04:42] <kiko> now wtf is that
[04:43] <ddaa> That looks like it
[04:43] <kiko> okay
[04:43] <kiko> so this is crack
[04:43] <kiko> why is it hung on productseriesset?
[04:43] <ddaa> mhhhh, crack :)
[04:43] <mpt> ha
[04:43] <mpt> https://launchpad.net/sprints/ubz/+edit
[04:43] <BjornT> stub: no. making it batched is one solution, but it'd be nice to see if there's something we can do to make it work anyway.
[04:43] <mpt> teh aewsome
[04:44] <kiko> what, mpt?
[04:44] <kiko> bradb_, what's the local temperature like at 6am? 7am? 8am? :-(
[04:44] <stub> BjornT: ZPT is slow. If the page is a non-trivial length there is nothing we can do apart from buying faster CPUs (which is only a temporary solution)
[04:44] <bradb_> kiko: http://src.ca/meteo/cities/bulletins/aff_bulletin.asp?zone=can&CityCode=YUL
[04:45] <bradb_> it was about 2C at 5:30 this morning
[04:45] <kiko> makes me cry
[04:45] <kiko> ddaa, since when is this broken?
[04:45] <mpt> kiko: "Edit this paragraph to be a nice summary description of the edit form. It will be displayed at the top of the page, in bold text. The form       errors and update status will be displayed above it if they are needed."
[04:46] <ddaa> kiko, less than a month
[04:46] <kiko> it looks like it could not have worked in the current configuration of the code
[04:46] <kiko> mpt, :-)
[04:46] <ddaa> I'm not using it very often, but it used to work
[04:46] <kiko> ok
[04:46] <stub> BjornT: Looks pretty CPU bound on the Z3 server as far as I can tell (which is not in any particulary scientific way)
[04:46] <BjornT> stub: i still think it can be optimized, it seems that it times out only if you're logged in.
[04:46] <sabdfl> stub: should staging be alive?
[04:47] <stub> yes
[04:47] <sabdfl> url? 
[04:47] <stub> https://staging.ubuntu.com
[04:47] <stub> WFM
[04:47] <sabdfl> ah
[04:48] <SteveA> works for me, slowly
[04:48] <sabdfl> staging.canonical.com is giving me a bad gateway
[04:48] <SteveA> yeah
[04:48] <SteveA> it should be at staging.launchpad.net
[04:49] <salgado> staging.launchpad.net is shipit
[04:49] <salgado> at least it was
[04:50] <sabdfl> stub: could you run update-pkgcache.py?
[04:50] <sabdfl> on staging?
[04:50] <stub> sabdfl: it has been run
[04:50] <sabdfl> stub: ah... but gina hasn't right?
[04:50] <stub> There arn't any packages on there though, as it is prepared for gina testing
[04:50] <stub> yup
[04:50] <sabdfl> need to run gina, then the pkgcache magic
[04:58] <SteveA> kiko, sabdfl: call in 3 mins, right?
[05:03] <SteveA> kiko: ?
[05:03] <kiko> SteveA, now, right?
[05:03] <SteveA> yes
[05:03] <SteveA> i'm on the phone
[05:09] <SteveA> jamesh: ping
[05:11] <jbailey> stub: The repo now works for Nafallo.  Can you try again, please?
[05:19] <jamesh> SteveA: pong
[05:19] <SteveA> hi james
[05:19] <SteveA> can you get to montreal earlier?
[05:20] <jamesh> SteveA: I'd have to check with the travel agent.
[05:20] <SteveA> this is really important, so you can get the spec scheduler polished before the conference proper started
[05:21] <SteveA> can you get there on th 26th?
[05:21] <SteveA> to arrive in montreal on th 26th?
[05:21] <kiko> jamesh, you should have booked for september already, you are always in short supply :)
[05:25] <jamesh> SteveA: I can ask about it at the travel agent.
[05:25] <kiko> it's a sab-request, FTR
[05:26] <SteveA> please do, and call me (unless i'm asleep) if there is a problem
[05:29] <SteveA> jamesh: when can you call the travel agent?
[05:30] <jamesh> SteveA: tomorrow morning (probably 9-10 hours away)
[05:30] <SteveA> ok.  i'm at utc+3
[06:03] <SteveA> bug 1419
[06:08] <kiko> ubuntulog, bug 1419 ffs
[06:09] <kiko> Seveas, where's our bot? :)
[06:09] <mpt> ubuntulog can't help you :-)
[06:13] <mpt> and dilys has fallen asleep too
[06:14] <mpt> the bots are on strike
[06:15] <Belutz> hmm sorry, a bit offtopic, who should i contact if i want to make an ubuntu training in my country?
[06:15] <mpt> carlos_: ping
[06:15] <carlos_> mpool, pong
[06:15] <carlos_> s/mpool/mpt/
[06:15] <mpt> close enough
[06:15] <mpt> carlos_: When I asked you what the Global Translation Wiki was, you said it was suggestions made by non-editor
[06:15] <mpt> but on the mailing list, Mark said it was suggestions from other packages
[06:15] <mpt> which is true?
[06:16] <carlos_> sabdfl, the ones from the other packages are the ones like 'Translated somewhere else...' right?
[06:19] <kiko> ddaa, care to do a review?
[06:19] <mpt> carlos: at the moment we have "Suggestions", "Currently Published Elsewhere", and "From the Global Translation Wiki"
[06:19] <mpt> well, that's what we had yesterday
[06:20] <mpt> today we have "Suggestions", "Published elsewhere", and "Unofficial suggestions"
[06:20] <carlos> mpt, Suggestions are the ones added to that concrete message
[06:20] <ddaa> kiko: depends, if it takes more than 10 mins, I'll do tomorrow.
[06:20] <carlos> mpool, currently published elsewhere are the ones accepted in other modules
[06:20] <carlos> grrr
[06:20] <mpt> so the "Unofficial suggestions" needs to be changed to "Suggested elsewhere"
[06:20] <mpt> Get yourself a better IRC client, carlos :-)
[06:21] <mpt> anyway, time for me to go to class
[06:21] <carlos> ok
[06:21] <ddaa> kiko: currently preparing the spec day with niemeyer
[06:21] <ddaa> There's a lot of work to bring some orders to all the Bazaar/SuperMirror/Launchpad/Branch specs around.
[06:22] <gneuman> doesn anyone know why milestones are linked to product and distibution in a separate way?
[06:22] <kiko> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/fileG87cWV.html
[06:23] <kiko> gneuman, can you elaborate?
[06:23] <kiko> gneuman, a milestone is only linked to one or the other at once, I think
[06:23] <gneuman> hm
[06:24] <gneuman> and why doesnt it have a product series or releases linked to it?
[06:25] <kiko> milestones are for the future, gneuman 
[06:25] <kiko> they point out things that will or should happen
[06:25] <kiko> series or releases refer to the past
[06:27] <gneuman> thx, now it makes sense
[06:27] <ddaa> kiko: are you aware that I never wrote or patched any of this code?
[06:27] <gneuman> then there are 3 possible contexts
[06:27] <matsubara> Does anybody know if it is possible to add a select box in an autogenerated form? I'm trying to change the productseries +source form to an autogenerated one
[06:27] <ddaa> And that I'm in the process of doing my first Launchpad web app patch...
[06:29] <ddaa> kiko: I plead incompetence to review this code.
[06:30] <kiko> wimp!
[06:30] <ddaa> kiko: if you insist, I can learn about this code tomorrow after the spec conf.
[06:30] <kiko> nah
[06:31] <ddaa> sorry
[06:52] <BjornT> matsubara: yes, it's possible. the short answer is that you should use a Choice field to get a select box. don't know enough details to provide a better answer.
[06:54] <matsubara> thank you BjornT. 
[06:59] <Kinnison> dudes, a fresh checkout of launchpad can't build-config
[06:59] <Kinnison> any guesses as to why?
[07:00] <Kinnison> Or, in other words... WHAT THE FUCK HAPPENED TO ROCKETFUEL?
[07:21] <bradb> Kinnison: The error message is God.
[07:21] <jblack> heis 
[07:21] <Kinnison> bradb: well, the error message is:
[07:22] <Kinnison> baz: uncaught exception: -1:(I/O error)
[07:22] <Kinnison> sorry
[07:22] <Kinnison> unable to rename "/srv/launchpad.ubuntu.com/dogfood/launchpad/lib/,,get.hct.1129827136.15808.36" to "/srv/launchpad.ubuntu.com/dogfood/launchpad/lib/hct" (Not a directory)
[07:22] <Kinnison> when doing a build-config
[07:22] <bradb> oh, that's easy (I think)
[07:22] <bradb> somebody added symlinks to lib for hct, psycopgda, sourcerer and sqlos
[07:23] <Kinnison> and didn't fix the dogfood config?
[07:23] <bradb> they link to the relevant dirs that you have to "get" into ../sourcecode
[07:23] <bradb> Kinnison: perhaps. I'm not sure what config changes are required. But that sounds almost surely like the cause of the problem.
[07:23] <Kinnison> Right
[07:24] <Kinnison> gits
[07:24] <Kinnison> well, I've only got 5 minutes before I head out
[07:24] <Kinnison> so this isn't getting sorted tonight
[07:24] <bradb> it was patch-2700 that added those symlinks, fwiw
[07:24] <bradb> i spent a couple hours unbreaking my stuff this morning already :P
[07:25] <aboe> got a question about launchpad, translations, when does launchpad updates..all the work 
[07:25] <bradb> Kinnison: can't you just change the config to get those libs into the sourcecode dir instead?
[07:25] <Kinnison> no, because dogfood is meant to run from fresh rocketfuel
[07:26] <bradb> ok
[07:28] <Kinnison> ciao
[07:29] <bradb> later dude
[08:01] <svaksha> hi all
[08:01] <kiko> hello svaksha 
[08:01] <svaksha> kiko, hi :) 
[08:02] <svaksha> Can the Templates for smeg be imported to Rosetta
[08:02] <kiko> carlos or jordi can explain why they haven't I think
[08:02] <kiko> there's a good reason
[08:02] <kiko> I just forget
[08:02] <svaksha> there is a bug filed against it
[08:02] <kiko> was there an explanation placed there?
[08:02] <svaksha> so ogra asked me to holler here :)
[08:03] <svaksha> nope, i was on #ubuntu-bugs chan
[08:03] <carlos> svaksha, seems like the application needs to be converted to use gettext
[08:03] <carlos> it lacks i18n support from what jordi saw
[08:04] <svaksha> ok, thanks, i left it as is
[08:04] <carlos> svaksha, http://lists.ubuntu.com/archives/rosetta-users/2005-October/000832.html
[08:05] <svaksha> thanks :)
[08:07] <svaksha> bye :)
[08:15] <carlos> see you!
[08:47] <bradb> kiko, mpt, BjornT: just so you know: I'm refactoring the filebug views into one class on this branch, and adding feedback, now that stub's BrowserNotificationMessages branch landed
[08:57] <kiko> bradb, thanks -- are you fixing up the domain classes as well?
[09:01] <bradb> Fixing them how? You mean like adding a .createBug method to IBugTarget? (Or, rather, replacing .newBug with a proper .createBug method?)
[09:10] <kiko> yeah
[09:11] <bradb> yeah, I can do that too
[09:11] <kiko> hey SteveA_ 
[09:14] <einheit_> kiko
[09:15] <SteveA_> cprov: ping
[09:15] <cprov> SteveApong
[09:16] <cprov> SteveA_: einheit ?! pong
[09:17] <SteveA_> hi cprov 
[09:18] <SteveA_> so, what review do you need next?
[09:18] <SteveA_> i had a day of meetings and phone calls and conference calls, i'm afraid
[09:18] <SteveA_> so i didn't get any code reviews done
[09:23] <SteveA_> cprov: ?
[09:24] <cprov> SteveA: you own me my launchpad--buildd-scoring--0, its about dependency aware scoring
[09:25] <cprov> SteveA_: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/celso.providelo@canonical.com/launchpad--buildd-scoring--0/filtered-diff (417 lines)
[09:26] <SteveA_> yep
[09:26] <SteveA_> i'll do it right now
[09:28] <cprov> SteveA_: thank you, btw, kick the old nick, it's just boring ;) 
[09:46] <SteveA_> cprov: mailed the review
[09:46] <SteveA_> can you manage a quick reply?
[09:46] <SteveA_> which nick do you say i should ditch?
[09:46] <cprov> SteveA_:  yes sir
[09:47] <SteveA_> cool
[09:47] <SteveA_> any other reviews you need right away?
[09:49] <mpt> bradb: Do you have an example line handy for how to fix the hct/psycopgda/sourceror/sqlos conflict?
[09:49] <bradb> mpt: so, two steps
[09:50] <bradb> 1. "baz get ..." each of hct, sourcerer, psycopgda and sqlos into your sourcecode directly
[09:50] <bradb> er, directory
[09:50] <bradb> then 2. manually add the symlinks under lib/ to point to each ../sourcecode/$foo
[09:50] <mpt> so I'm in sourcecode/
[09:50] <bradb> e.g.
[09:50] <bradb> in sourcecode/
[09:51] <bradb> baz get --link rocketfuel@canonical.com/sqlos--test--3.0 sqlos
[09:51] <bradb> the in lib/
[09:51] <bradb> ln -s ../sourcecode/sqlos sqlos
[09:51] <mpt> ok, where did you get the 3.0 number from?
[09:51] <bradb> hang on, i'll grep my history for you
[09:51] <mpt> oh, never mind, it's in my bash history
[09:51] <bradb> the get commands are:
[09:52] <bradb>   471  baz get --link rocketfuel@canonical.com/hct--devel--1 hct
[09:52] <bradb>   472  baz get --link rocketfuel@canonical.com/psycopgda--test--3.0 psycopgda
[09:52] <bradb>   473  baz get --link rocketfuel@canonical.com/sourcerer--devel--0 sourcercer
[09:52] <bradb>   474  baz get --link rocketfuel@canonical.com/sqlos--test--3.0 sqlos
[09:52] <mpt> that's great, bradb, thanks
[09:52] <bradb> np
[09:55] <kiko> ARGH
[09:55] <kiko> why is pqm bouncing my commit with failures in HCT?
[09:55] <pkern> Any rosetta admins in here who could add me some translation templates to the database?
[09:56] <mpt> ohhh, bradb, that broke
[09:56] <bradb> mpt: broke how?
[09:56] <mpt> These files would be source but lack inventory ids (`baz add' perhaps?):
[09:56] <mpt> lib/sourceror
[09:56] <mpt> These explicit ids have no corresponding file:
[09:56] <mpt> lib/.arch-ids/sourcerer.id
[09:56] <bradb> ergh, i have a typo in my history
[09:56] <mpt> These symlinks point to nonexistent files:
[09:56] <mpt> lib/sourcerer.rej
[09:56] <kiko> has anyone managed to commit today?
[09:57] <bradb> mpt: it should have been: baz get --link rocketfuel@canonical.com/sourcerer--devel--0 sourcerer
[09:57] <SteveA_> me, no
[09:57] <kiko> pkern, you should try carlos or jordi 
[09:57] <bradb> (i.e. i typoed "sourcercer" up above)
[09:57] <SteveA_> got a rejection with some merge crap in it
[09:57] <mpt> aha
[09:57] <kiko> SteveA_, failures about pybaz?
[09:58] <pkern> kiko: Ok.
[09:58] <carlos> pkern, please, follow the procedure noted at https://wiki.ubuntu.com/RosettaFAQ
[09:58] <SteveA_> cscvs error
[09:59] <kiko> rocketfuel@canonical.com/launchpad--devel--0--patch-2700
[09:59] <bradb> SteveA_, kiko: did you guys already fix your trees in the way i showed mpt above?
[09:59] <kiko> SteveA_, was that the last commit? I think lifeless landed and then broke the tree
[09:59] <bradb> yeah, patch-2700 :)
[09:59] <SteveA_> and a pybaz error
[09:59] <kiko> bradb, should it matter?
[09:59] <bradb> kiko: yup
[09:59] <kiko> I suspect it shouldn't matter for commits, bradb 
[09:59] <kiko> we're just sending merge requests to PQM
[10:00] <kiko> it doesn't pull anything related to configs AFAICS
[10:00] <bradb> you have a tree in conflict though
[10:00] <kiko> I don't 
[10:00] <pkern> carlos: Ah. Rosetta itself told me to mail rosetta-users, thanks.
[10:00] <kiko> my tree is fine
[10:00] <bradb> kiko: you do, unless you merged and fixed the conflicts
[10:00] <carlos> pkern, yeah, we need to update that page :-(
[10:00] <bradb> kiko: you can find out by doing a merge
[10:00] <kiko> I merged and there were no conflicts
[10:00] <bradb> kiko: you merged in patch-2700?
[10:01] <pkern> carlos: I just wondered why nothing happened, only Mark replied that I need to add series and stuff, which already happened.
[10:01] <kiko> bradb, just trying now, I guess
[10:01] <carlos> pkern, jordi handles those requests so I don't know its concrete status
[10:01] <carlos> pkern, which application are we talking about?
[10:02] <pkern> carlos: net6 and obby, one other (gobby) is following soon
[10:02] <kiko> bradb, do you have any clue whether this will help merges?
[10:02] <pkern> carlos: review-* should not be touched, right? Why are they imported then anyway?
[10:03] <bradb> kiko: only a guess, because i haven't merged since i spent two hours this morning unfucking my tree because of this. :/
[10:03] <carlos> pkern, well, review-* need to be reviewed as its name says, anything special you are interested on?
[10:03] <kiko> bradb, I very much doubt it will work
[10:03] <carlos> I can give it priority
[10:03] <carlos> pkern, about net6, jordi answered the email, not sure why he didn't redirect you to the FAQ page...
[10:04] <cprov> SteveA_: mail for you 
[10:04] <carlos> pkern, follow the procedure so he will do the import, please
[10:04] <pkern> carlos: Well, I didn't get the answer then |:
[10:04] <pkern> carlos: Ok.
[10:04] <pkern> carlos: What do you mean with "anything special"?
[10:04] <carlos> pkern, hmmm he sent it directly to the mailing list
[10:04] <cprov> SteveA_ :I need to go out for 20 min ... please, send me an email
[10:04] <carlos> pkern, if you are interested on any sourcepackage with a review-* template
[10:05] <pkern> carlos: Ok. But one question: How are those handled anyway? Are special translation uplodas made in the frozen distribution?
[10:05] <carlos> We fix them as our time allows us to do it but we give priority to the templates people ask for
[10:05] <SteveA_> cprov: sure
[10:05] <BjornT> bradb, kiko: kinnison reported that the build-config for dogfood wasn't updated. seems like the development config wasn't updated either.
[10:05] <carlos> pkern, those are just a side effect of our automatic imports from Ubuntu's archive
[10:05] <bradb> yep, i told Kinnison what the problem was
[10:06] <carlos> with dapper they should not appear again
[10:06] <pkern> carlos: Yeah I know. But I registered those products just a few days ago and they still happen. I mean, it's quite useless to keep them around if no automatic uploads to Ubuntu's archive happen because of them?
[10:06] <pkern> carlos: The requests are added, thanks for the hint.
[10:06] <bradb> er, does that mean somebody needs to use bzr to fix this then?
[10:07] <BjornT> so who can fix dists--devel--0?
[10:07] <bradb> to my understanding, dists would need to be changed with bzr
[10:07] <carlos> pkern, the review-* templates only appear with Ubuntu translations
[10:07] <cprov> SteveA_: stayed .. can talk anytime
[10:07] <carlos> pkern, but they would be linked from the product page
[10:08] <bradb> i guess what happened here is the build-config completed, and *then* the symlink additions were applied before the tests ran, so it all went ok. but, in effect, it was a suicide bombing.
[10:08] <pkern> carlos: Yep, they are and that's the point. If there are no real translations imported but if the product is linked to a source package in breezy, this template looks like the primary one.
[10:09] <pkern> carlos: But anyway thanks for your help. Is there any way to remove those review ones? (:
[10:09] <carlos> pkern, it's a real translation, but we need to fix the translation domain (that's the name) of the template, nothing more
[10:09] <bradb> hm, i still don't understand how the symlinks additions could get applied though.
[10:09] <kiko> bradb, I think lifeless just merged that in without tests.
[10:09] <pkern> carlos: Ok.
[10:09] <carlos> pkern, give me links and I will fix them
[10:10] <bradb> kiko: without running the tests, you mean?
[10:10] <kiko> yes.
[10:10] <pkern> carlos: I'll wait for the import and hope that the other template from the sync, which is then obsoleted, could then be deleted.
[10:10] <bradb> yeah, that would make sense.
[10:10] <kiko> I don't  actually understand how configs work, though
[10:11] <kiko> I guess I should just cool down and have lunch
[10:11] <kiko> worry about this on saturday
[10:12] <carlos> pkern, you didn't understood me....
[10:13] <carlos> pkern, those templates will never be deleted, those are the Ubuntu ones
[10:13] <pkern> carlos: ):
[10:13] <carlos> pkern, they need to be renamed, nothing more
[10:13] <pkern> carlos: Ok.
[10:18] <SteveA_> cprov: replied
[10:18] <SteveA_> cprov: this timing thing is a big deal
[10:19] <cprov> SteveA_: do you really think ? what do you suggest , decrease the accurancy ? 
[10:21] <SteveA_> cprov: for now, perhaps yes.   it really needs to be made so that testing the rules doesn't depend upon the time that passes
[10:21] <cprov> SteveA_: understood .. will increase the interval and that's it ... 
[10:21] <SteveA_> getting the time should really be something we can plug in when testing
[10:22] <SteveA_> maybe an ITimeAndStuff utility...
[10:22] <SteveA_> anyway, 10s minimum error allowed, and r=me
[10:23] <cprov> SteveA_: it's not that easy, but you can add your onw timestampt in DB row creation and rearrange the tests ... soonish, not now, this code must go, 10s ;)
[10:23] <SteveA_> and file a bug to refactor it so that time passing doesn't matter
[10:24] <cprov> SteveA_: thank you for the review stamp 
[10:40] <mpt> Anyone got an URL for jamesh's archive?
[10:43] <mpt> nm, I figured it out
[11:19] <Belutz> i got this error: Application error.  Unauthenticated user POSTing to page that requires authentication. 
[11:19] <Belutz> but i already login to the launchpad
[11:20] <kiko> Belutz, your login may have expired -- it's a known problem
[11:21] <Belutz> i see, how much time until the login expired?
[11:21] <kiko> it's normally more than 24h, but sometimes it hiccups for some reason
[11:22] <Belutz> oh ok, thanks kiko
[11:31] <carlos> lifeless, hi, around?
[11:32] <carlos> anyone was able to do the migration to bzr?
[11:33] <kiko> carlos, not me -- still have a ton of stuff to merge :-(
[11:35] <carlos> kiko, well, I suppose it's only a problem if you have changes that are not yet in your local tree 
[11:49] <lifeless> carlos: yes
[11:55] <kiko> lifeless, what do you mean, yes?
[11:55] <kiko> PQM merges are failing btw
[11:57] <lifeless> kiko: how so ?
[11:57] <lifeless> kiko: I was replying to carlos question
[11:59] <kiko> lifeless, your last patch, 2700, concluded PQM for the day
[11:59] <kiko> lifeless, forwarded email
[11:59] <lifeless> danke
[11:59] <lifeless> from you
[12:00] <lifeless> got it
[12:00] <lifeless> failed import for pybaz
[12:00] <kiko> right
[12:01] <lifeless> pybaz is in the right in the config
[12:01] <lifeless> let me check the tree
[12:01] <kiko> thanks
[12:01] <lifeless> I can import pybaz from lib
[12:02] <lifeless> I have import hct and pybaz from lib
[12:02] <kiko> still failed for everybody committing...
[12:03] <kiko> :)
[12:03] <kiko> man no lunch makes me cranky
[12:03] <lifeless> I'm checking out a clean tree, this may take a bit