[12:38] <kiko> anyway
[12:38] <kiko> night guys
[12:52] <zyga> night 
[01:24] <mdke> who would be a good person to start to talk to about integration between launchpad and the ubuntu documentation team svn repository?
[01:25] <khorben> someone knows if there are still actual bounties opened?
[01:26] <jordi> mdke: what kind of integration?
[01:26] <jordi> automatic import of pos?
[01:28] <spiv> mdke: Or commit privileges based on launchpad team membership?
[01:29] <mdke> spiv, yeah that
[01:29] <spiv> Ah :)
[01:29] <mdke> jordi, pos?
[01:30] <mdke> oh doh
[01:30] <mdke> yeah
[01:30] <mdke> no, not that
[01:30] <jordi> ok
[01:30] <spiv> mdke: So, we have something like this for bzr coming fairly soon.
[01:30] <jordi> then I have no idea :)
[01:30] <mdke> just commit privs and such
[01:30] <jordi> ah
[01:30] <jordi> that's cool
[01:31] <mdke> maybe karma :D
[01:31] <spiv> Where every member of a team will be able to commit to bzr branches at sftp://bazaar.launchpad.net/~team-name/product-name/branch-name
[01:31] <mdke> spiv, we are quite slow with technology, we have to get our heads around bzr eventually and see if we can use it
[01:32] <spiv> And that gets republished at http://... (same url, aside from http/sftp).
[01:32] <spiv> mdke: Right.
[01:32] <mdke> if so, then that would be cool
[01:32] <spiv> mdke: At the moment, bzr is probably slightly rough for svn users.
[01:32] <mdke> spiv, got a simple guide anywhere?
[01:32] <spiv> mdke: But there's stuff that was spec'd at UBZ that would make it pretty friendly.
[01:33] <mdke> sounds good
[01:34] <spiv> Specs about "lockstep development" iirc, but the bzr guys will know more :)
[01:34] <spiv> mdke: So, it's probably a case of "not yet, but soon" for you.
[01:34] <spiv> Where is soon is only a month or two, hopefully.
[01:35] <mdke> cool
[01:35] <mdke> spiv, so given that, it's probably not worth arranging any svn integration
[01:37] <mdke> ah the guides look comprehensive
[01:38] <spiv> mdke: #bzr are pretty helpful too.
[01:38] <mdke> thanks
[01:38] <spiv> Yeah, we're hoping that everyone will think bzr is better than svn :)
[01:38] <mdke> i need to understand the why's and wherefores of decentralised version control
[01:39] <mdke> i suppose there must be some projects where decentralisation is bad?
[01:39] <spiv> For sufficiently simple stuff, it can be a complication you don't need.
[01:39] <spiv> I think you may be in that basket, from what I've heard.
[01:39] <mdke> me too
[01:39] <spiv> Hence the lockstep development stuff :)
[01:39] <mdke> is there a way round that with bzr?
[01:39] <mdke> ah, ok
[01:40] <spiv> There's specs about this on bazaar.canonical.com
[01:40] <spiv> http://bazaar.canonical.com/LockStepDevelopment?highlight=%28Lock%29
[01:40] <spiv> Or just http://bazaar.canonical.com/LockStepDevelopment
[01:40] <mdke> :)
[01:41] <mdke> yeah that sounds like what we do a lot
[01:41] <spiv> With that you could still use the decentralised bits if you need them, but the default mode of operation has everyone working with the same branch.
[01:42] <mdke> ok that sounds promising stuff
[01:43] <mdke> spiv, by the way do you know if that MoinMoin user.py hack of yours would work on Moin 1.3.5?
[01:43] <spiv> mdke: Probably -- that's roughly the version we're using, I think.
[01:43] <mdke> on the off chance
[01:43] <spiv> https://wiki.ubuntu.com/SystemInfo says 1.3.4
[01:44] <mdke> yeah, same on the canonical one
[01:44] <spiv> Which is probably 1.3.4 + debian patches + my hack.
[01:44] <mdke> okay cool
[01:45] <mdke> spiv, thanks for your help
[01:45] <spiv> You're welcome.
[02:33] <spiv> Hmm, I can't seem to add a comment to a malone bug in the web UI using only the keyboard.
[02:33] <spiv> Because I can't tab to the "Add a comment to this bug" expander.
[02:34] <spiv> Time for shift-numlock I guess...
[02:50] <jamesh> lifeless: I'm getting this error on a merge from rocketfuel:
[02:50] <jamesh> bzr: ERROR: Branch /home/james/src/rocketfuel is missing revision Arch-1:rocketfuel@canonical.com%launchpad--devel--0--patch-1071 of x_Carlos_Perello_Marin_<carlos.perello@canonical.com>_Sun_Oct__3_15:36:08_2004_9002.0
[02:51] <lifeless> jamesh: hmm
[02:51] <lifeless> jamesh: I would try a reweave-branches/
[02:52] <jamesh> my bzr doesn't seem to have a reweave-branches command
[02:53] <lifeless> its a plugin
[02:53] <lifeless> checks the plugins page ;0
[02:53] <jamesh> so reweave my branch, or rocketfuel, or both?
[02:54] <lifeless> reweave rocketufel yourbranch
[02:54] <lifeless> one command
[04:32] <jamesh> lifeless: doesn't seem to make any difference
[04:33] <lifeless> jamesh: garh. 
[04:33] <lifeless> let me see
[04:34] <jamesh> the branch is /home/warthogs/archives/jamesh/launchpad/bzimport
[04:34] <jamesh> s/bzimport/bugzilla-import/
[04:57] <jamesh> lifeless: any ideas?
[04:59] <lifeless> jamesh: not yet, juggling things
[04:59] <jamesh> okay
[05:51] <lifeless> jamesh: try a fetch-ghosts
[05:51] <lifeless> that revision *is* in rocketfuel
[05:51] <lifeless> (bzr log -r revid:Arch-1:rocketfuel@canonical.com%launchpad--devel--0--patch-1071)
[05:52] <jamesh> fetch-ghosts from rocketfuel to my branch, or the reverse?
[05:52] <jamesh> the error message claims that the revision is missing from a file in the rocketfuel branch
[05:54] <jamesh> the "bzr log" command you gave prints a log message in both my branch and rocketfuel
[05:54] <lifeless> oh I see
[05:56] <jamesh> the file ID appears to correspond to database/sampledata/current.sql
[05:57] <stub> lifeless: Can you please tag launchpad/devel rev 2848 as production/1.40 (or should I attempt PQM again?)
[05:57] <lifeless> stub: I shall do so
[05:58] <lifeless> stub: I think pqm needs some tweaks in tag, so if you have a problem do this:
[05:58] <lifeless> sudo to pqm
[05:58] <lifeless> bzr branch -r 2848 launchpad/devel launchpad/production/1.40
[05:58] <lifeless> in the pqm home
[05:58] <lifeless> and copy that to the public copy in /home/warthogs/archives/
[05:59] <stub> Ok. In tomboy for next time.
[06:05] <lifeless> the last commit that that pulled was 
[06:05] <lifeless> revno: 2848
[06:05] <lifeless> committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[06:05] <lifeless> timestamp: Wed 2005-11-23 22:10:04 +0000
[06:05] <lifeless> message:
[06:05] <lifeless>   Speed up search for shipit orders, which was causing lots of RequestTimeOuts in production. r=stub
[06:05] <stub> Yup - that is the one
[06:05] <lifeless> copying to public now
[06:07] <stub> I think I was wrong suggesting category/version/branch btw. 
[06:08] <lifeless> I'll try to debug it for tuesday
[06:09] <lifeless> that missing revision error
[06:09] <lifeless> which way around made it work ?
[06:10] <lifeless> stub: ^^
[06:11] <stub> The dud branch is stub/launchpad/LibrarianGarbageCollection.unmergable. You get the error message merging trunk into that branch.
[06:11] <stub> Merging that branch into trunk works, however.
[06:12] <lifeless> hmm
[06:12] <lifeless> was it baz2bzr'd ?
[06:12] <stub> Nope. Pure bzr.
[06:12] <lifeless> funky cold medina
[06:12] <jamesh> stub: was your error anything like mine?
[06:13] <stub> Missing patch (blah blah Arch1 carlos blah blah)
[06:15] <lifeless> jamesh: same thing
[06:16] <stub> Yah launchpad/production/1.40/1.40. lifeless - You want me to nuke it and recopy ?
[06:17] <lifeless> stub: huh? did you do it while I was ?
[06:17] <stub> Nope
[06:17] <lifeless> ...
[06:20] <lifeless> well we have a 1.40 which has teh right tip
[06:20] <lifeless> what do you want me to do ?
[06:22] <stub> Nuke the 1.40/1.40 directory so I only have 200MB to transfer around instead of 400MB?
[06:22] <lifeless> done
[06:26] <lifeless> I'll look more closely at this missing revision error tomorrow
[06:26] <lifeless> I have to go for SLUG now
[06:28] <stub> Reverting...
[06:28] <stub> Traceback (most recent call last):
[06:28] <stub>   File "./refuel.py", line 382, in ?
[06:28] <stub>     main()
[06:28] <stub>   File "./refuel.py", line 378, in main
[06:28] <stub>     config.buildMirror()
[06:28] <stub>   File "./refuel.py", line 126, in buildMirror
[06:29] <stub>     self.buildBranchMirror(source, launchpad=True)
[06:29] <stub>   File "./refuel.py", line 165, in buildBranchMirror
[06:29] <stub>     Branch.open_containing('.')[0] .set_pending_merges([] )
[06:29] <stub> AttributeError: '_Branch' object has no attribute 'set_pending_merges'
[06:29] <stub> :-(
[06:29] <stub> I'll try some work arounds later
[06:29] <stub> (pull the prebuilt rocketfuel and bzr pull --overwrite on it)
[06:29] <lifeless> erm
[06:30] <lifeless> that looks like a mismatch in bzr
[06:30] <lifeless> are you using the bzr from sourcecode/rollouts ?
[06:30] <lifeless> because it definately does not do that
[06:30] <stub> ok - could me my cut&paste revert implementation in refuel.py - I'll do it manually
[06:31] <stub> Yes - that is it. My problem.
[06:34] <lifeless> code in refuel should use the bzr in the lp tree I think
[06:34] <lifeless> does that make sense to you?
[06:34] <stub> Yes - I'll invoke it using subprocess. It was previously using cargo culted code from bzrlib's revert command
[06:35] <lifeless> thats not -quite- what I meant
[06:35] <lifeless> I mean, it can either subprocess, or it can use the bzrlib library from sourcecode/bzr
[06:35] <lifeless> but it cant use a random system one, bzr is moving too fast
[06:36] <stub> Refuel can't use bzr form the lp tree, because its function is to *build* the lp tree. That is what rollouts/bzr.integration is to avoid (?)
[06:36] <lifeless> isn't refuel to *update* the lp tree?
[06:37] <stub> Unless I start by rsyncing the prebuild rocketfuel tree and working back from there.
[06:37] <lifeless> thats what it was before
[06:37] <stub> It does both. 
[06:37] <lifeless> then it should be *in* the lp tree, surely?
[06:37] <stub> It is in the configs tree
[06:37] <lifeless> ah
[06:37] <stub> Anyway - go to SLUG. I have enough to work with for now.
[06:38] <jamesh> lifeless: re: your mail to launchpad-devel, will the sftp paths passed to pqm have to change like the ones to bzr are changing?
[06:38] <lifeless> jamesh: hmmm ?
[06:38] <jamesh> i.e. sftp://chinstrap.ubuntu.com//home/warthogs/archives/login/launchpad/branch instead of sftp://chinstrap.ubuntu.com/home/warthogs/archives/login/launchpad/branch
[06:38] <lifeless> presumably
[06:38] <lifeless> I should check that spec, as I think that that is a very dubious thing
[06:39] <jamesh> section 2.2 of http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-03.txt
[06:39] <stub> It would be nice if we can shorten those URLs sometime - the '/home/warthogs' bit could go with the simple addition of a symlink in chinstraps root directory
[06:39] <lifeless> later, byte
[06:48] <jamesh> so the arch patch log for rocketfuel@canonical.com/launchpad--devel--0--patch-1071 doesn't actually modify database/sampledata/current.sql
[06:48] <jamesh> weird
[07:06] <stub> I'm off for an hour or three.
[09:56] <carlos_> morning
[10:11] <SteveA> morning
[10:13] <SteveA> hi stub 
[10:15] <stub> SteveA: Hi
[10:17] <SteveA> i skimmed the channel scrollback.  was there some stuff about xmlrpc interfaces earlier?
[10:23] <sabdfl> lifeless, SteveA: http://www.linux.com/article.pl?sid=05/09/23/1954240
[10:23] <sabdfl> linux softphones
[10:26] <stub> SteveA: Not when I was online
[10:29] <SteveA> carlos: hello
[10:29] <carlos> SteveA, hi
[10:30] <stub> Launchpad will be going down in 30 mins. Downtime estimate is 45 mins total.
[10:30] <SteveA> i just looked over your code review responses, and i'll make a full reply when you send me the new diff.
[10:30] <jordi> carlos: can we look into the pending plural forms and country languages?
[10:30] <SteveA> i think if you use "return None" rather than "raise NotFoundError" in the places I pointed out, it will result in less code, and less complex code overall.
[10:31] <carlos> jordi, as soon as I finish with UploadTranslations review I will do it
[10:31] <carlos> jordi, don't worry ;-)
[10:31] <jordi> k
[10:31] <SteveA> that is, there isn't any point in raising NotFoundError in database code if you always catch that error and use some other value in other code
[10:31] <carlos> SteveA, ok
[10:31] <SteveA>  __getitem__ should always raise NotFoundError
[10:31] <SteveA> because NotFoundError is a subclass of KeyError
[10:32] <SteveA> and __getitem__ has a contract that says it raises KeyError if it is not found
[10:32] <SteveA> (actually, the mail libraries in python break this, and it is confusing because of that)
[10:37] <\sh> morning
[10:38] <SteveA> hello \sh 
[10:40] <\sh> guys...is there any way to have a global ML for all bugreports coming into malone...no matter which product and which person/team is assigned to a product
[10:40] <SteveA> maybe.  what would it be for?
[10:42] <\sh> but only bugs, which are affecting one distro (as add)
[10:42] <\sh> to have a similar functionality like bugzilla
[10:43] <SteveA> you want to be able to subscribe to all new bugs filed on a particular distro?
[10:43] <\sh> as an example: affects /distros/ubuntu/ace where ubuntu is the distro, ace the package/product...but the mail is now only received or send out to the assignee
[10:43] <\sh> yes
[10:44] <SteveA> so, this list wouldn't get changes in those bugs or resolutions to those bugs
[10:44] <\sh> SteveA: well..this should be implemented :=
[10:44] <\sh> :) even
[10:44] <SteveA> i'm trying to understand exactly what you're asking for, and what it could be used for
[10:45] <\sh> right now I'm only able to see changes to a bug report, when the assignee has a ML for the bugreports (e.g. universe-bugs for the MOTU team)
[10:45] <SteveA> sometimes, making launchpad send mail is the answer.  sometimes, this reveals something that launchpad itself should offer that isn't necessarily mail.
[10:46] <\sh> but if someone else (an individual) is assigning the bug to himself, only the assignee and requestor are seeing the changes..but nobody else (via mail)
[10:47] <\sh> I would like to see such a feature like sending out emails for all new reports, changes and all status changes towards a global distro specific ML or email address...
[10:47] <BjornT> \sh: bradb is working on https://wiki.launchpad.canonical.com/InitialBugContacts, that should cover your use case
[10:47] <SteveA> okay, i understand what you're asking for now.
[10:47] <\sh> regarding all bugs filed against a distro product
[10:48] <SteveA> https://wiki.launchpad.canonical.com/InitialBugContacts does this, as BjornT points out.  Although, it is for all bug traffic.
[10:49] <SteveA> if you just wanted new bugs, you'd have to filter it at the mail-receiving end.
[10:50] <BjornT> \sh: the bug contact for ubuntu will probably be ubuntu-bugs, which will receive all the notifications, so you would have to subscribe to that ml and filter out the ones your interested in.
[10:50] <\sh> so reading this spec...it should work like this: distro X has several bug contacts (means teams in LP) and I can assign the teams as bug contacts..the team itself has a ML for email support
[10:50] <SteveA> carlos: as to returning SelectResults, we do it quite a lot.  The main problem with doing so is that SelectResults is a very broad interface, and hard to use in unit tests.  But it works out okay in general.
[10:51] <carlos> SteveA, is there any problem if I leave the code as it is? or do you prefer the SelectResults?
[10:52] <BjornT> \sh: well. a distro only has one bug contact (but that will probably be a ml you can subscribe to). then each source package in the distro can have a bug contact as well.
[10:53] <SteveA> carlos: it should be simpler to just return the SelectResults.  and simpler code is easier to maintain.
[10:53] <\sh> BjornT: ok..I'm asking because e.g. ubuntu is splitted in 2 halfs, main and universe, and I don't want to subscribe to two or more MLs :) 
[10:53] <BjornT> \sh: the long term plan is that you should be able to subscribe to distribution and package bugs in launchpad itself, but we don't have time to implement that at the moment.
[10:54] <carlos> SteveA, ok
[10:54] <SteveA> it should be possible to filter based on component
[10:54] <SteveA> if the email has the component in it
[10:54] <BjornT> \sh: well. you'll only have to subscribe to ubuntu-bugs, it will receive both main and universe bugs
[10:54] <SteveA> and i see that it does
[10:54] <\sh> BjornT: cool :)
[10:54] <SteveA> in X-Launchpad-Bug
[10:54] <SteveA> in that header
[10:54] <\sh> thx for all the informations :)
[10:55] <BjornT> np, happy to help
[10:58] <siretart> btw, is it possible to get a list of all open bugs I'm currently subscribed to?
[10:59] <carlos> stub, how could I know from a pagetemplate if there are error messages in the notification queue after using BrowserNotificationMessages ?
[10:59] <carlos> stub, request/getNotifications ?
[11:05] <BjornT> siretart: not at the moment, but soon. bug 4788 is reported about this, and it's in pending upload state, so the fix is waiting to be rolled out.
[11:05] <Ubugtu> Error: Could not parse data returned by Malone: Connection to Malone bugzilla failed: HTTP Error 503: Service Unavailable
[11:06] <siretart> BjornT: cool. and thanks!
[11:31] <stub> carlos: Yes - that would work. webapp.interfaces.INotificationRequest and INOtificationResponse for the API
[11:32] <stub> (sorry - sound was off again)
[11:33] <stub> carlos: But it isn't designed for message passing, so you might want to consider storing your status flags elsewhere rather than attempting to parse and understand the notifications
[11:33] <carlos> stub, ok
[11:33] <carlos> stub, I just need to know if there was any error or not
[11:33] <stub> carlos: Just because there is a notification, doesn't mean there is an error.
[11:33] <carlos> so I thought that perhaps the new system has a way to know that
[11:33] <carlos> yeah
[11:33] <carlos> I know
[11:33] <carlos> I will use my own flag then
[11:34] <carlos> with old code I check if the 'alerts' list was empty or not
[11:34] <carlos> stub, thanks
[11:39] <SteveA> stub: the interfaces should really be in interfaces/launchpad.py
[11:57] <stub> launchpad is back up
[11:58] <ajmitch> yay
[11:59] <jordi> ajmitch: did you DO IT?
[12:01] <ajmitch> need to merge in a patch before I upload!
[12:01] <jordi> cooome on man
[12:13] <matsubara> good morning!
[12:14] <SteveA> hi diogo
[12:14] <SteveA> stub: what things should go in a launchpad development deb that shouldn't go on a production server one?
[12:15] <SteveA> stub: um... ctags, vi, gnu id tools, submit to pqm scripts
[12:28] <carlos> SteveA, dude, after all changes I'm doing you will need a new full review...
[12:34] <SteveA> carlos: that's fine.  it should be a straightforward review, with lots of familiar code.
[12:35] <SteveA> you're doing important work.
[12:35] <SteveA> i'll review it for you as soon as you're ready.
[12:37] <carlos> SteveA, I know, don't worry
[12:38] <carlos> it's just that I'm changing many code at the same time I'm changing the methods
[12:38] <carlos> not a big deal ;-)
[12:46] <carlos> SteveA, running tests
[12:46] <carlos> SteveA, should I sent the diff directly to you or with the answer to last review ?
[12:50] <niemeyer> Morning cprov, morning everyone
[12:51] <gneuman> mornig niemeyer 
[12:51] <cprov> niemeyer: moning gustavo, how is it going with grumpy ? 
[12:53] <niemeyer> cprov: Slowly and constantly :)
[12:54] <cprov> niemeyer: right, did you set your local buildfarm ?
[12:54] <niemeyer> cprov: Is the plan for changing the soyuz build system for hct still up?
[12:55] <niemeyer> cprov: Nope.. still mirroring, and I've spent some time helping David with some bits this week as well
[12:55] <cprov> niemeyer: in thesis, yes, but practically speaking, we are way busy til soyuz production
[12:56] <niemeyer> cprov: And what does it mean, in practice? :)
[12:56] <SteveA> carlos: it is easier for me if you send the answer to me and the reviews list, and send the new diff directly to me
[12:57] <cprov> niemeyer: I see, mirroring is painfull, since you get the stuff in a hard drive  you need to protect them as you protect your child ;)
[12:57] <carlos> SteveA, ok
[12:57] <SteveA> niemeyer: how did things go yesterday?
[12:57] <cprov> niemeyer: the plan is not up for this year :(
[12:57] <niemeyer> SteveA: Quite good.. 9.4 out of 10.. I just have to fix a few bits in the paper to keep the grade.
[12:58] <niemeyer> cprov: And when do you see yourself starting to work on it, and finishing it?
[12:59] <SteveA> niemeyer: sounds good :-)
[01:00] <carlos> SteveA, also, you want a diff against my previous code or a diff against rocketfuel?
[01:01] <cprov> niemeyer: huuu, hard to say, in fact, no schedule was done for it yet and the priority is low, IMO any ETA I can give you would be blue sky idea, sorry 
[01:01] <niemeyer> SteveA: Yeah.. but what is really good is getting over that step. I wasn't looking for a nice grade like that even.. getting over it is the biggest prize.. :-)
[01:01] <cprov> niemeyer: how much does it affects you and grumpy ?
[01:01] <SteveA> carlos: there was a lot to change.  can you send me both?
[01:01] <carlos> sure
[01:01] <niemeyer> One year writing something is.. erm.. boring..
[01:02] <niemeyer> cprov: Let's say that without this Grumpy doesn't exist :)
[01:03] <niemeyer> cprov: We'll have to change that priority somehow, to put it on schedule
[01:04] <cprov> niemeyer: I see,  jump to ##soyuz1.0, let's sort it out (if you have time now)
[01:07] <salgado> SteveA, ping
[01:07] <SteveA> hi salgado 
[01:08] <salgado> SteveA, I'm having some problems with ShipItReports. do you have some time to talk about it? (should be quick)
[01:09] <SteveA> okay.  can we talk in 10 mins time?
[01:09] <salgado> sure
[01:09] <SteveA> is there any code you want me to look at?
[01:09] <SteveA> or is it a design issue?
[01:10] <salgado> SteveA, I think it can be considered a design issue.
[01:10] <SteveA> ok
[01:21] <SteveA> hi salgado 
[01:21] <SteveA> talk here okay?
[01:24] <salgado> sure
[01:24] <salgado> maybe not
[01:24] <SteveA> okay.  #c-m
[01:24] <stub> SteveA: PostgreSQL 8 and friends and any setup scripts
[01:26] <stub> salgado: If shipitreports gives you trouble, punt it to me. I can throw it together with psql and cron fairly easily which will keep people happy.
[01:27] <salgado> stub, is it possible to get csv filed out of cricket?
[01:28] <stub> salgado: cricket isn't really suitable for this. psql can spit out csv if you ask nicely though.
[01:28] <SteveA> stub: can you talk with mdz (email perhaps) about what should go in what launchpad dependency packages to make it useful for you to use in production?
[01:29] <stub> SteveA: I can't use it in production - I can't install debs. This would be for elmo/Znarl
[01:29] <SteveA> yeah
[01:29] <SteveA> but, how often do these things change?
[01:30] <SteveA> and when they do, getting admins to install a deb is a nice way to do it
[01:30] <SteveA> and to update a dev
[01:30] <SteveA> deb
[01:30] <stub> Enough that nearly every time we setup a new box something is missing ;) 
[01:30] <SteveA> so a deb would help
[01:30] <stub> yes
[01:31] <stub> I'll talk to mdz anyway - it is pretty obvious what is dev and what is base
[01:31] <SteveA> ok
[01:31] <SteveA> i'd like to get the ctags and idtools in a development package
[01:31] <SteveA> basically, get all recommended tools in one place for developers
[01:33] <jordi> SteveA: I started writing the announcement for the import policy last night
[01:33] <jordi> I want to run it through carlos and you before sending to the list though
[01:34] <carlos> jordi, URL to the annoucement?
[01:36] <jordi> carlos: scp://nubol/Mail/postponed :)
[01:36] <jordi> ie, not yet :)
[01:36] <carlos> ok
[01:36] <carlos> :-)
[01:41] <Kinnison> elmo: can you please email myself and cprov with how to get at the uploads on rockhopper for testing the launchpad uploader?
[01:42] <carlos> stub, .... where is the getNotifications implementation?
[01:42] <carlos> stub, I'm able to see the interface, but I don't find the implementation
[01:42] <carlos> stub, I have a test that uses "from zope.publisher.browser import TestRequest"
[01:43] <carlos> and I need to get the notifications that the test produced
[01:44] <carlos> and If it's possible, I don't want to add my own boolean variable in this case as it's only needed to run the tests...
[01:50] <SteveA> jamesh: did you get the "turn mail off on bugzilla import" thing sorted?
[02:11] <BjornT> SteveA: i've braindumped the implementation part in https://wiki.launchpad.canonical.com/LaunchpadFormLayout, could you take a look at it and see if it makes sense, or if we should try to do it in some other way?
[02:12] <stub> carlos: I don't think it is possible except as a page test - brad was looking into it.
[02:12] <SteveA> BjornT: can you ask me for feedback on it using launchpad?
[02:12] <BjornT> SteveA: sure
[02:12] <SteveA> ta
[02:12] <carlos> stub, ok, then I need to reduce the test checks removing the info message check and relay on the database changes...
[02:13] <stub> carlos: But I still suspect you are going about the problem the wrong way - remember that other code might start adding notifications too that you don't control
[02:13] <stub> eh?
[02:13] <carlos> stub, it's a test that Is checking the "the submit worked, thanks" message
[02:13] <carlos> using the old way to do notifications
[02:13] <carlos> is not a new test
[02:14] <carlos> and I'm trying to adapt it without rewrite it completely
[02:14] <stub> It should be a page test really.
[02:14] <carlos> we already have such page tests
[02:14] <stub> Just because you used to set the alerts list doesn't mean it was ever displayed ;)
[02:14] <carlos> so I suppose I can leave the other tests and just remove the info message test
[02:15] <stub> The implementation is in webapp/notifications.py anyway. Brad might have had some success looking into this - ask him when he is online
[02:16] <stub> It would be possible to do the test as you describe, but needs more infrastructure to wire it up.
[02:16] <stub> (extend the TestRequest, adding a stub implementation of the notifications machinery)
[02:17] <stub> Which wouldn't be hard really - it doesn't need to actually work or propogate the messages - just store them where tests can look
[02:18] <stub> Feel like extending TestRequest and making it implement INotificationRequest enough for your test to work?
[02:18] <stub> It would just need to stuff the arguments in a list where your tests can inspect them
[02:20] <carlos> stub, I suppose that would work...
[02:20] <carlos> I will take a look after lunch
[02:22] <carlos> stub, hmmm the implementation lacks the getNotifications method
[02:22] <carlos> stub, but I suppose it's the same as getting the notifications property, right?
[02:23] <stub> Oh - looks like that should be removed. notifications is a property
[02:25] <stub> But I doubt accessing the real implementation in your tests will work, because the session machinery won't be hooked up. Anyway - a mock implementation is fine.
[02:25] <carlos> stub, I was just noting that the interface and the implementation was out of sync, I don't think I will use it ;-)
[02:31] <stub> ok :)
[02:31] <stub> Feel free to remove the unused method from the interface while you are there.
[02:32] <carlos> ok
[02:32] <carlos> stub, should I update the spec?
[02:33] <stub> I don't know. The spec is implemented, and I don't think we bother to keep them in sync with future code changes.
[02:34] <carlos> stub, well, the spec is supposed to reflect the implementation...
[02:34] <carlos> anyway, will talk about that later
[02:34] <carlos> lunch time!
[02:43] <stub> kiko: Looks like the gina run finished 5 hours ago.
[02:43] <kiko> that's not bad news, thanks stub 
[02:44] <kiko> stub, mdz, Kinnison: gina run 100% successful.
[02:44] <kiko> SteveA, did you get my emails from yesterday?
[02:47] <SteveA> i got some emails from you yesterday
[02:48] <kiko> thanks. I'm concerned about getting the show on the road
[02:48] <kiko> SteveA, also, could you formalize the "catching exceptions" thread into a FAQ of sorts?
[02:49] <SteveA> kiko: project G ?
[02:50] <kiko> SteveA, well, that one I'm scratching my head about. but the other ones, related to soyuz
[02:50] <SteveA> i just had part in a discussion about hct and soyuz infrastructure with niemeyer, Kinnison and cprov.  cprov is summarizing, and will mail you a summary.
[02:50] <kiko> okay, cool
[02:51] <kiko> niemeyer, what's on your plate at the moment?
[02:51] <SteveA> there are other soyuz things of course
[02:54] <cprov> kiko: the summary will  be delayed for 14:00[BRT] , I'm still working on it 
[02:54] <kiko> sure
[03:13] <niemeyer> kiko: I was (am) away for lunch.. sorry..
[03:13] <kiko> sure
[03:13] <niemeyer> kiko: No outstanding individual tasks for the moment
[03:13] <kiko> so what are you looking at starting today? :)
[03:13] <niemeyer> kiko: Planning to have a look at soyuz
[03:13] <kiko> hmmmm
[03:14] <kiko> may I interest you in some soyuz work?
[03:14] <niemeyer> kiko: Btw, I have a system that redirects personal messages as SMS to my mobile phone when I'm out
[03:14] <niemeyer> kiko: Was quite funny to get "what's on your plate at the moment?" in the restaurant. :-)
[03:15] <niemeyer> kiko: Sure
[03:15] <kiko> heh :)
[03:15] <Nafallo> lol
[03:18] <niemeyer> kiko: Btw, I'll stay 2 weeks bothering you at async in January, programming with cprov on Soyuz.
[03:19] <kiko> niemeyer! why don't you come next week?
[03:20] <kiko> we need soyuz help today
[03:20] <niemeyer> Yes, I think that might be possible indeed
[03:20] <niemeyer> And would speed up SoyuzProduction
[03:20] <niemeyer> Which is a dependency of the generalization
[03:21] <kiko> and I /really/ need soyuzproduction delivered
[03:23] <niemeyer> Yes, sounds great
[03:23] <kiko> mdz arrives on the 14th ftr
[03:25] <niemeyer> I'll check if I have any pending local tasks to do, and try to be there on Monday or Tuesday.
[03:33] <ddaa> niemeyer: looks like you're not going to have too much trouble finding work to do :)
[03:33] <kiko> great.
[03:35] <niemeyer> ddaa: Indeed :)
[03:36] <niemeyer> ddaa: Anything besides graduation projects, and I'm happy :-)
[03:37] <niemeyer> ddaa: So far it looks more like "yours! yours! yours!"
[03:37] <ddaa> Matter of perspective, I was thinking "your time is mine!"
[03:41] <niemeyer> ddaa: Ahh, yes :)
[03:43] <ddaa> kiko: how would you feel about letting me add the following snippet to lib/canonical/launchpad/ftests/harness.py? https://chinstrap.ubuntu.com/~dsilvers/paste/fileDqFPj3.html
[03:44] <kiko> ddaa, you're going to need to give me some context.
[03:45] <ddaa> The idea is that in a unittest source file, you just do "register(__name__)" at the end, and that 1. creates a automatic test_suite function 2. execute the tests in this file if it was called as a script.
[03:45] <ddaa> It's more or less ripped from something Keybuk and I invented independently for pybaz and hct.
[03:46] <ddaa> The only issue is that some people may find the "register(__name__)" to be a bit too magic.
[03:46] <ddaa> you can propose a better name if you can think of one though
[03:47] <ddaa> kiko: so, how does that sound?
[03:47] <kiko> how are unittests being run at the moment?
[03:47] <ddaa> usually, through the ./test.py
[03:48] <ddaa> But I think that some of them may be runnable directly.
[03:48] <ddaa> most of them
[03:48] <ddaa> need to check though...
[03:49] <ddaa> Mh...
[03:52] <Kinnison> :-(
[03:52] <ddaa> hu?
[03:53] <Kinnison> ddaa: take a look at a bzr vis in launchpad
[03:53] <ddaa> URL to the plugin please
[03:53] <Kinnison> petitemort% cat dev-bzr/bzrk/.bzr/parent
[03:53] <Kinnison> http://people.ubuntu.com/~scott/bzr/bzrk/
[03:53] <Nafallo> package bzrk in jbailey's repo.
[04:04] <ddaa> Kinnison: I see.
[04:04] <Kinnison> ddaa: any idea what that was?
[04:04] <ddaa> the launchpad--branchdatastorage--0--base-0 is fucking the display up
[04:06] <ddaa> It might help if somebody converts the branch it tagged from and merge it into rocketfuel.
[04:06] <ddaa> That should be a no-change merge that would only fill ghosts.
[04:06] <ddaa> Though I can imagine the issue becoming quite recursive...
[04:07] <ddaa> That's probably a consequence of my "custom" conversion script.
[04:07] <ddaa> too lazy
[04:07] <ddaa> Kinnison: get the idea?
[04:08] <elmo> Kinnison: rsync rockhopper::
[04:08] <Kinnison> elmo: right
[04:08] <Kinnison> cprov: ping
[04:09] <ddaa> Mh...
[04:09] <ddaa> No apparently, it's more than that...
[04:09] <Kinnison> elmo: only from inside the DC yes?
[04:09] <elmo> Kinnison: yes.  it's like 13Gb of stuff; do you really want it available from elsewhere?
[04:09] <ddaa> look like this base-0 has some redundant ancestors
[04:10] <elmo> kinnison: I can make it available if you like *shrug*
[04:10] <Kinnison> elmo: I think it's okay for it to be inside the DC
[04:10] <Kinnison> elmo: any chance we can have ubuntu.com in chinstrap's search path?
[04:10] <ddaa> Kinnison: maybe the ancestry would be worth sanitizing, for removal of redundant ancestors.
[04:11] <Kinnison> ddaa: I guess this is a call that lifeless will have to make
[04:11] <ddaa> Kinnison: I mean, in bzrk
[04:11] <ddaa> input sanitisation
[04:11] <Kinnison> ddaa: Oh right
[04:11] <elmo> Kinnison: done
[04:12] <Kinnison> elmo: thanks dude
[04:18] <Kinnison> elmo: can you do me a favour and dump the output of running du -sk / on mawson, into my homedir on chinstrap? bzip2ed would be fine
[04:18] <Kinnison> only half the disk is in the dogfood librarian
[04:18] <Kinnison> where is the other half :-)
[04:20] <SteveA> salgado-lunch: hi
[04:32] <SteveA> salgado-lunch: mailed you some monday-handling code
[04:41] <Znarl> Kinnison : I could do that.
[04:47] <Kinnison> Znarl: if you could, I'd appreciate it
[04:48] <Znarl> Kinnison : If you could create an RT ticket?
[04:48] <Kinnison> remind me how to do that?
[04:49] <Znarl> Email to rt@admin.canonical.com
[04:52] <Nick1> hello
[04:53] <Nick1> someone?
[04:53] <SteveA> hello Nick1 
[04:53] <Nick1> I want to start using Linux
[04:53] <Nick1> do i have to know something
[04:53] <Nick1> spacial
[04:53] <Nick1> ?
[04:53] <Nick1> special**
[04:53] <SteveA> well, ubuntu is a good place to start looking at linux
[04:54] <SteveA> unfortunately, we don't tend to talk about this on the launchpad channel
[04:54] <SteveA> try #ubuntu maybe?  but i'm interested to know
[04:54] <SteveA> where did you read about #launchpad ?
[04:54] <Nick1> OK 10x
[04:54] <Nick1> ill check it
[04:55] <Kinnison> Znarl: sent
[04:55] <Nick1> mm at: https://launchpad.net/+login
[04:55] <ddaa> I though it was spelt "200 OK"...
[04:55] <Znarl> Thanks.
[04:55] <SteveA> Nick1: and how did you get there?
[04:55] <SteveA> Nick1: do you know about shipit ?  you can get ubuntu cds sent to you for free.  shipit.ubuntu.com
[04:55] <Nick1> my friend ordered a disk from you
[04:55] <SteveA> cool
[04:56] <Nick1> and told me that linux is good:)
[04:56] <Nick1> so i want to start using that cause i dont like windows
[04:56] <SteveA> in my opinion, linux is the way of the future.  but it it's pretty good already.
[04:57] <Nick1> so is that 100% free to israel? [ths shipit
[04:57] <ddaa> Nick1: just curious, why do not you like windows?
[04:57] <Nick1> i has many bugs:\
[04:57] <SteveA> there isn't any charge to have a few CDs sent to you.  however, it is possible that the israel customs people will make a small charge
[04:57] <Nick1> O.. OK ill cjek it
[04:58] <ddaa> Nick1: all software has bugs.
[04:58] <Nick1> ddaa: u use windows or linux?
[04:58] <Nick1> mm.. yes but linux less has less
[04:58] <Nick1> has less**
[04:58] <ddaa> Well, I'm a developer for this Canonical company, so I'd be in trouble if I used Windows :)
[04:59] <Nick1> O..:) i understand:)))
[04:59] <Nafallo> heh
[04:59] <ddaa> Nick1: quality is important, but here is a better reason to like Ubuntu: http://www.gnu.org/philosophy/why-free.html
[05:00] <Nick1> O.. 1 sec
[05:00] <ddaa> no hurry
[05:00] <Nick1> and what is that Kubuntu :\?
[05:01] <ddaa> It's ubuntu but which installs KDE instead of GNOME by default. If you do not know about KDE and GNOME, just pick plain Ubuntu.
[05:01] <Nick1> i read about that some where, don't remeber where:\\
[05:01] <bradb> BjornT: Hi, I've got a user asking if they can put more than one "affects" line in a submit-bug mail. Does this work?
[05:02] <Nick1> ddaa: O.. OK thnks... and if i order it today, for example, when will i get it?
[05:03] <ddaa> Isn't that explained on the shipit page? It should usually takes between 2 weeks and 2 months.
[05:03] <Nick1> O.. i didnt read everything :) i amd such kazy:)
[05:03] <ddaa> There are plans in the work for people to be able to pay to get a faster delivery.
[05:03] <Nick1> OK but thank u very much
[05:04] <Nick1> ddaa: where did u come from?>
[05:04] <ddaa> I'm here all the time.
[05:05] <BjornT> bradb: well, yes, it should be possible. multiple affects means multiple bug tasks, though, not multiple bugs.
[05:05] <SteveA> BjornT: hi
[05:05] <BjornT> hi SteveA 
[05:05] <bradb> BjornT: That's what I'd expect.
[05:05] <SteveA> BjornT: why don't we just use a view @@widgetrow or something for the LaunchpadFormLayout ?#
[05:06] <SteveA> the view can be registered at the level different classes if needed
[05:06] <BjornT> SteveA: and register different views on different widget classes?
[05:06] <SteveA> but we might want to impose some order on it by using a range of launchpad-specific interfaces
[05:07] <SteveA> and slap these interfaces onto existing classes
[05:07] <SteveA> indirectly, so we can add interfaces to zope classes from launchpad configuration
[05:07] <Nick1> ddaa: no... :) a country.... I'm from israel
[05:07] <SteveA> then just use views, rather than new TALES namespace stuff, or tal:condition stuff
[05:07] <ddaa> Nick1: I live in Paris, France.
[05:07] <SteveA> make a view that says "i know how to render a table row for this"
[05:08] <BjornT> SteveA: yes,  the last section talks about that (not in detail, though)
[05:08] <Nick1> O.. cool
[05:08] <SteveA> BjornT: if the only reason not to do that is to get the HTML into one file, then we can still do that
[05:09] <SteveA> but that's really an optimisation
[05:09] <BjornT> SteveA: i'd be happy to go for that, and skip the TALES adapter.
[05:09] <SteveA> do it as "normal" views, and we'll work out a way to put it all in one file after it lands, if it proves to be still important then
[05:10] <SteveA> for example, we can do tricks with macros to do this
[05:10] <BjornT> SteveA: i originally wrote it because it was the first i thought of, without changing anything in zope3. than i remembered that it's easy to make classes implement interfaces without changing the class definition ;)
[05:10] <SteveA> yes
[05:10] <SteveA> we can also register view / adapters directly for classes
[05:11] <SteveA> although that does require a bit of faff (and for no good reason) in zope3 using zcml to do it
[05:11] <SteveA> in brief, at some point in the past, shane noticed that there were no tests explicitly of registering adapters / views for classes from zcml
[05:11] <SteveA> so he disabled it
[05:12] <SteveA> and i don't think anyone has written tests of this since
[05:12] <SteveA> there have been a couple of times i've wanted to use it, but not been sufficiently inconvenienced to write tests upstream
[05:12] <SteveA> anyway, nice to see an effort to tidy up the launchpad UI infrastructure
[05:13] <BjornT> SteveA: i'll change the spec, to talk about defining marker interfaces and define views instead of a TALES adapter.
[05:13] <SteveA> what views do we need?
[05:13] <SteveA> i think it is just a view that represents this widget as a table row
[05:13] <BjornT> yeah, that should do it
[05:14] <SteveA>  interfaces/widget.py and browser/widget.py and zcml/widget.py ?
[05:15] <BjornT> SteveA: ?
[05:17] <SteveA> suggestion of places for the code to live
[05:18] <SteveA> the interfaces need to be in interfaces/(something) or people will get confused
[05:18] <SteveA> maybe  interfaces/widget.py  and webapp/widget.py and webapp/widget.zcml
[05:18] <SteveA> i think i like that better, actually
[05:18] <BjornT> ah, i was confused by zcml/widget.py
[05:20] <cprov> Kinnison: pong
[05:21] <Kinnison> cprov: hey, so from the DC you can rsync to rockhopper which has the breezy autotest stuff
[05:21] <Kinnison> cprov: it has the sources as well as binaries
[05:21] <Kinnison> cprov: okay?
[05:22] <Kinnison> cprov: if you start with main, then that'll be grand
[05:22] <cprov> Kinnison: do you mean rsync from DC to here ? much like "no way" whit the current link
[05:22] <BjornT> i'm not sure what the policy is, of what goes under webapp, but it sounds good to me.
[05:22] <Kinnison> cprov: Hmm
[05:22] <cprov> Kinnison: ok only main 
[05:22] <Kinnison> cprov: once i've worked out where the space went on mawson, you could use that if you want
[05:23] <Kinnison> It'd be nice to try stuart's librarian GC on mawson
[05:23] <Kinnison> see how much we can clean up
[05:23] <cprov> Kinnison: I've seen, librarian is that ... I wonder if we can use LibrarianGC in DF
[05:23] <cprov> oh ... duhhh
[05:24] <Kinnison> the librarian is only 50% of the usage on mawson
[05:25] <cprov> Kinnison: it would be very nice to use mawson for upload-tests, instead of locally sync ... 
[05:25] <Kinnison> cprov: once we've worked it out and cleaned it up, you're welcome to use mawson for it
[05:25] <cprov> Kinnison: I'll sync at least main or other minimal set during the weekend
[05:25] <ddaa> pqm has reached the 24h backlog hallmark
[05:26] <ddaa> I think at this point it's safe to call it a productivity bottleneck :(
[05:26] <Kinnison> ddaa: cripes
[05:26] <Kinnison> ddaa: You think each merge costs four hours?
[05:26] <ddaa> I'm not saying anything about how long merges take, just that they certainly take too long.
[05:26] <Kinnison> Oh, you mean the top merge is 24hrs old
[05:27] <Kinnison> I wonder if pqm is bustificated
[05:27] <Kinnison> It might be turned off
[05:27] <Kinnison> ready for the transfer to a dedicated host
[05:27] <SteveA> maybe
[05:27] <ddaa> dunno, I received my last failure notification not very long ago today.
[05:27] <SteveA> salgado: do you have all the week / date stuff you need now?
[05:28] <Kinnison> ddaa: Unfortunately the UI doesn't show us when pqm started on the top item in the queue
[05:28] <ddaa> (the cvs spawning bug, not fixing it because it'll go away when pqm gets a dedicated system)
[05:28] <Kinnison> ddaa: So all we know is it was 24 hrs since that one was submitted
[05:28] <salgado> SteveA, haven't looked yet. I'll look now
[05:28] <ddaa> Kinnison: yup, feel like asking lifeless about fixing that lack of diagnostic info?
[05:34] <Kinnison> carlos: ping?
[05:34] <carlos> Kinnison, pong
[05:35] <Kinnison> carlos: Your ~ on mawson is 18G
[05:35] <Kinnison> carlos: care to clean it up a bit?
[05:35] <carlos> sure
[05:35] <carlos> just a second..
[05:35] <salgado> SteveA, that should do it. thank you very much!
[05:37] <niemeyer> Will be back later today.
[05:38] <carlos> Kinnison, wow, where did the other 500GB go?
[05:38] <Kinnison> carlos: we're working that out now :-)
[05:38] <Kinnison> carlos: 50% of it is in the dogfood librarian
[05:38] <Kinnison> carlos: and we're unsure what to do yet about all that
[05:39] <carlos> ok
[05:39] <stub> Kinnison: LibrarianGarbageCollection is in pqm if you want to test it ;)
[05:39] <Kinnison> stub: Does it handle the following:
[05:40] <Kinnison> stub: stuff in .../incoming/ which is now dnagling?
[05:40] <Kinnison> stub: stuff in the librarian root which is dangling/orphaned
[05:40] <Kinnison> ?
[05:41] <stub> IIRC incoming is only used during upload - should be able to clear that out on a restart. And nothing should be in the librarian root. Or am I not following you?
[05:42] <Kinnison> I mean 00/* etc
[05:42] <stub> It merges duplicates and removes entries that are no longer being referenced by anything
[05:42] <stub> yes
[05:42] <Kinnison> right
[05:42] <Kinnison> cool
[05:42] <Kinnison> once it's in RF I'll deploy it on mawson and try it
[05:46] <Kinnison> ddaa: I think the current delays aren't helped by there still being three baz2bzrs running
[05:46] <Kinnison> ddaa: namely cprov's stub's and sabdfl's
[05:47] <ddaa> yeah, and somebody claims that's baz2bzr is fast so we can just convert all the importd branches on a single system :(
[05:47] <SteveA> we should have those killed off until we've moved pqm
[05:47] <SteveA> elmo / Znarl ?
[05:47] <cprov> let me know if you should stop it again
[05:50] <Znarl> SteveA ?
[05:50] <Kinnison> it's incremental
[05:50] <Kinnison> so stopping them won't hurt restarting them later
[05:51] <SteveA> Znarl: please would you kill baz2bzr processes on chinstrap
[05:53] <Kinnison> in fact, pqm isn't even vying for CPU on chinstrap
[05:53] <Kinnison> so killing them isn't worthwhile for now
[05:54] <SteveA> is cpu the issue?
[05:54] <Kinnison> Right now, PQM isn't even trying to run
[05:55] <Kinnison> so I assume it has been stopped for the swapover to the dedicated box
[05:56] <SteveA> okay, looks like it
[05:56] <SteveA> Znarl: so, sorry, false alarm
[05:56] <Znarl> No problem.
[06:21] <Kinnison> ARGH, rollout.py doesn't work
[06:21] <Kinnison> stub: ^^^
[06:22] <carlos> Kinnison, I'm using now 123MB
[06:22] <carlos> Kinnison, I hope it's enough for you ;-)
[06:22] <Kinnison> carlos: thanks babe
[06:22] <kiko> babe?
[06:22] <Kinnison> kiko: calm down. You're still my number one
[06:22] <carlos> ;-)
[06:23] <Mystilleef> Hello, how do I set up my project to use rosetta?
[06:24] <carlos> Mystilleef, https://wiki.ubuntu.com/RosettaFAQ
[06:24] <kiko> Kinnison, thanks for your reply to silbs. I think.
[06:24] <Kinnison> kiko: I wish I could be more positive about this
[06:24] <kiko> I only ask that we be realistic
[06:25] <kiko> do you think my prediction is unrealistic?
[06:25] <Kinnison> as I said, without a detailed look into things, I don't want to even guess
[06:25] <Kinnison> given how bad at it I've been in the past
[06:25] <kiko> safe 
[06:30] <kiko> gneuman, I have a patch for bug 2718 already done in a tree of mine
[06:30] <Ubugtu> Error: I cannot access this bug
[06:30] <carlos> SteveA, hi, around?
[06:31] <SteveA> hi, around
[06:32] <carlos> SteveA, so
[06:32] <gneuman> kiko, then i am closing it
[06:32] <gneuman> ok?
[06:32] <carlos> I have zope.publisher.browser.TestRequest
[06:32] <kiko> gneuman, leave it, I'll close it when I merge
[06:32] <gneuman> ok
[06:32] <carlos> SteveA, and I have to expand it to implement INotificationRequest
[06:33] <carlos> SteveA, where should I add the new class?
[06:33] <carlos> canonical.launchpad.webapp.TestRequest ?
[06:33] <bradb> carlos: I've already extended it in my branch
[06:33] <carlos> bradb, oh
[06:33] <carlos> bradb, is it merged into rocketfuel?
[06:33] <bradb> carlos: but, i'm only half way there, there's sessions to get working with the test machinery too
[06:33] <bradb> carlos: nope
[06:33] <carlos> hmmm
[06:33] <SteveA> bradb: that makes me worried
[06:34] <SteveA> bradb: why do you want to get sessions workingn with the test machinery?
[06:34] <bradb> SteveA: So that notifications work
[06:34] <SteveA> i see
[06:34] <SteveA> can you punt this back to stu?
[06:34] <SteveA> i'd rather you were focused on getting directly malone stuff done
[06:34] <bradb> SteveA: Yeah, I've been meaning to. I gave up on the sessions a few days ago.
[06:35] <SteveA> bradb: unless already done: file a bug, assign to stu.
[06:35] <bradb> ok
[06:35] <SteveA> "hard to test notification messages in normal tests" or something like that. 
[06:35] <SteveA> i guess
[06:35] <stub> Kinnison: Pull rollout.py from stub/dists/devel (which is still with pqm)
[06:36] <Kinnison> stub: urgh
[06:36] <Kinnison> PQM like this is utterly arresting development/progress for me
[06:37] <bradb> Kinnison: Indeed. Landing is pretty much a no-go lately.
[06:38] <bradb> My most recent submission has been in pqm's queue for about 24 hours. Is it possible to not be pissed off by that? :)
[06:40] <Kinnison> Well, as I said earlier, I think PQM has been turned off
[06:40] <bradb> Oh, missed that
[06:40] <stub> It has - I just checked the crontab and the cron job is commented out. An announcement would have been nice :-/
[06:41] <Kinnison> go Lifeless
[06:43] <stub> Oops... getting snarky. Must be bed time. Night!
[06:43] <Kinnison> night stub
[06:45] <kiko> Kinnison, there's some mail that I'd like you to get to sooner rather than later so if PQM is fscking you..
[06:45] <Kinnison> kiko: which ones?
[06:45] <kiko> anything related to soyuzproduction
[06:47] <Kinnison> I.E. braindump the launchpad taskmaster stuff
[06:49] <kiko> are you in sync with cprov's latest messages? if so, okay
[06:49] <Kinnison> what? the three-task ones, yeah they're okay
[06:49] <kiko> you saw mark's suggestion to do a single one, right?
[06:51] <Kinnison> yes
[06:51] <kiko> and you have no reply? :)
[06:52] <Kinnison> It would work
[06:52] <Kinnison> it'd be a shorter test, but it'd show up anything glaring
[06:52] <Kinnison> We still intend to do the breezy autotest stuff
[06:52] <Kinnison> which will catch anything major
[06:54] <kiko> that only tests uploads, though.
[06:56] <Kinnison> yes, but tracking dapper for three days will test the autobuild
[06:56] <kiko> "test" you mean.
[06:58] <kiko> Kinnison, I mean, 3 days of testing critical infrastructure which has never been used before..
[06:58] <TheMistery> sal all
[06:58] <kiko> am I being too negative?
[07:00] <Kinnison> kiko: You're being unfair
[07:00] <TheMistery> any macedonians here ?
[07:00] <Kinnison> kiko: The build system was tested strongly by dogfood
[07:01] <kiko> Kinnison, that is a good point.
[07:23] <Kinnison> kiko, cprov: https://wiki.launchpad.canonical.com/LaunchpadTaskMaster#
[07:23] <salgado> SteveA, ping!
[07:24] <SteveA> hi salgado 
[07:26] <salgado> SteveA, I have a security-proxied StringIO object, and it seems like we don't have the necessary zcml to say it's a file-like object
[07:27] <salgado> in other words, I can't do anything with my StringIO
[07:27] <SteveA> we can fix that
[07:27] <SteveA> what is the exact type() of the object
[07:27] <salgado> should I add the necessary zcml so I can use its methods?
[07:27] <SteveA> ?
[07:27] <SteveA> yes. 
[07:27] <salgado> cStringIO.StringO
[07:29] <Kinnison> cprov: If you have updates, add 'em
[07:29] <Kinnison> cprov: let's spend the next few days adding any braindump notes we can think of to the spec
[07:29] <Kinnison> cprov: when niemeyer returns, ask the same of him
[07:29] <cprov> Kinnison: will do so ...
[07:30] <salgado> SteveA, I looked for the zcml to change, but couldn't find it
[07:38] <SteveA> salgado:  we need to write new zcml
[07:44] <salgado> SteveA, should it be in lib/canonical/launchpad/zcml/?
[07:57] <bradb> BjornT_: I submitted a bug via email about half an hour ago, but the bug hasn't been opened yet in production, and I've gotten no email (error or otherwise) about it. Any idea?
[07:57] <niemeyer> The item no. 1 in PQM queue has more than 24 hours. Is that usual!?
[07:58] <salgado> niemeyer, pqm was turned off without any notice
[07:58] <niemeyer> :-(
[08:00] <salgado> I hope it'll be comming back in a new dedicated box
[08:07] <BjornT> bradb: for some reason the signature failed to verify. i'll take a look why that happened, it could be the bug i fixed yesterday
[08:08] <bradb> BjornT: FWIW, I only just add another uid to it an hour or two ago, but I sent it to the keyservers, and it worked okay uploading the key into LP.
[08:08] <bradb> (s/uploading/importing/)
[08:15] <BjornT> bradb: hmm. could you send a small signed message to me, like only one line or so? makes it easier to debug.
[08:17] <bradb> oops, /me does that once more, unencrypted
[08:18] <bradb> BjornT: sent, ignore the first message that comes down
[08:18] <BjornT> thanks
[08:24] <bradb> BjornT: Would it be easy to make sure that the user always gets an error message if an email they send doesn't process successfully?
[08:25] <BjornT> bradb: not too hard, that's one of the things i plan to work on next week.
[08:26] <bradb> cool
[08:39] <BjornT> bradb: hmm, i think i know how to fix it. i'll take care of it on monday. btw, could you send me an email where the signature is detached from the message?
[08:41] <kiko> Kinnison, nice job dude. nice job.
[08:43] <bradb> BjornT: sent
[08:51] <BjornT> bradb: thanks. i just wanted to make sure it validated ok. so until the bug is fixed, detached signatures should work.
[08:51] <bradb> ah, ok. /me tries again.
[08:55] <bradb> BjornT: cool, it worked (except it ignored "priority High", when it should have set the priority to High)
[08:56] <BjornT> hmm, that's strange
[08:57] <BjornT> or maybe not....
[08:58] <bradb> ?
[08:58] <BjornT> bradb: it's not implemented yet ;) i'll probably include that in some patch, though, it's less than 30 minutes of work.
[08:59] <bradb> maybe I can try writing that patch?
[08:59] <bradb> I have a vague idea of how to do it, I think
[08:59] <bradb> and you can be the reviewer? (I need to get to know the email code. It's all a black box to me currently.)
[09:00] <bradb> And because I plan to drive Malone via email pretty much entirely from this point forward.
[09:01] <kiko> rock and roll bradb 
[09:01] <BjornT> bradb: sure, it's an easy fix, and it shouldn't conflict with my work.
[09:02] <bradb> BjornT: cool, thanks. /me starts looking around.
[09:13] <kiko> SteveA, before you leave, give me a ping?
[09:22] <carlos> bradb, are you using the 'addInfoNotification' methods or just 'addNotification' ?
[09:22] <bradb> carlos: addNotification
[09:23] <carlos> stub told me to use addInfoNotification as the spec says
[09:23] <carlos> bradb, I see the  implementation, but when I try to use them I get: AttributeError: 'BrowserResponse' object has no attribute 'addInfoNotification'
[09:25] <carlos> bradb, do you use anything special to use the notification system?
[09:25] <bradb> carlos: nope
[09:25] <carlos> other than just call self.request.response.addNotification...
[09:26] <bradb> carlos: There should be a method with a name shorter than addInfoNotification, that should Just Work. addNotification seems reasonable, IMHO. if the callsite wants to do something explicitly different than the default (like an error message, warning, etc.) that should be the time to think about extra typing. IMHO.
[09:26] <bradb> carlos: that's all
[09:27] <carlos> bradb, well, I have some Warning and Error messages to
[09:28] <bradb> for those passing in an extra arg to addNotification is reasonable, IMHO
[09:29] <carlos> bradb, but the spec says... : "Steve thinks we should not expose the base addNotification method, and developers instead only use the shortcuts.
[09:29] <carlos> "
[09:30] <bradb> Yeah, I saw that.
[09:30] <carlos> bradb, What drives me crazy is that if addNotification works, the others should work too...
[09:32] <bradb> There is some benefit in shortcut methods in that they reduce import. I don't really care too much either way, tbh.
[09:34] <carlos> ok..... that's weird... AttributeError: 'BrowserResponse' object has no attribute 'addNotification'
[09:34] <carlos> I think this is a problem with the tests....
[09:34] <bradb> carlos: how are you creating that error?
[09:34] <bradb> carlos: yep, that would be it.
[09:35] <carlos> so I should disable the test until your patch is finished and merged into rockefuel?
[09:35] <bradb> carlos: I opened a bug on this problem and gave it to stub. High priority.
[09:36] <carlos> ok, I will disable the test in the mean time....
[09:36] <bradb> ok
[09:40] <SteveA> lifeless: ping
[09:56] <bradb> BjornT: I've got a patch to add the priority command. Short and sweet. Do you have a couple mins to take a look, by any chance?
[10:14] <BjornT> bradb: bradb sure. e
[10:21] <bradb> BjornT: sent
[10:41] <kiko> hey lifeless 
[11:00] <BjornT> bradb: looks good. although, could you please rename the function to submit_commands again? i've modified it to take a bug as well, so it would save me some conflict resolution.
[11:01] <bradb> BjornT: ah, ok, in that case it would make sense. thanks.