[00:03] <thumper> poolie: correction, no lp committers have commented on it
[00:03] <thumper> I've looked at it and determined that I'm not qualified
[00:03] <thumper> I'll poke jml and mwhudson :)
[00:03] <poolie> haha
[00:03] <poolie> ok, thanks :)
[00:04] <lifeless> so, if its conditional.
[00:04] <lifeless> lets land it.
[00:04] <lifeless> and iterate.
[00:04] <thumper> lifeless: you review it then
[00:04] <lifeless> rs=lifeless
[00:04] <lifeless> done
[00:04] <mwhudson> poolie: is it proposed into the right branch?
[00:04] <mwhudson> 4907	+<!-- TranslationTemplateBuild -->
[00:04] <mwhudson> doesn't seem like something i'd expect to see
[00:05] <poolie> lifeless: i think it is worth fixing the issues andrew raised
[00:05] <lifeless> poolie: right
[00:05] <poolie> but none of them seem profound so i wanted to pipeline other reviews
[00:05] <lifeless> I knew that the code had been reviewed.
[00:05] <lifeless> and andrew is an emeritus lp reviewer.
[00:05] <lifeless> so he can vote it through.
[00:05] <poolie> mwhudson: i suspect it is a mix of db-devel and devel, so it may not be possible to land until they merge
[00:06] <poolie> which may now have happeende
[00:06] <poolie> jam will also need someone to sponsor this and to help him shake it out on staging
[00:06] <thumper> or it is landed on db-devel
[00:06]  * thumper is off next week
[00:09] <poolie> thumper:  you mean it could land on db-devel instead?
[00:09] <thumper> yes
[00:13] <mwhudson> poolie: it definitely can't land on devel until the next release
[00:13] <mwhudson> well, unless there's some history rewriting
[00:13] <poolie> meaning 2 weeks from now?
[00:14] <mwhudson> i think it's a bit more than that
[00:14] <poolie> but if it landed on db-devel, it would be available for testing on staging?
[00:14] <mwhudson> yes
[00:18] <mwhudson> poolie: the branch has conflicts with db-devel it seems
[00:18] <mwhudson> jam: can you merge db-devel, fix the conflicts and repropose it against db-devel?
[00:25] <poolie> i don't think he's here at the moment but i put that on the mp
[00:26] <mwhudson> thanks
[00:29] <thumper> I think getting a new mp against db-devel would help
[00:30] <thumper> as it would avoid all the extra crap
[00:30] <thumper> we should allow target editing
[00:30] <thumper> (but don't yet)
[00:30] <thumper> and a way to regenerate the diff
[00:30] <thumper> yet more on the mp todo list
[00:54] <nh2> hi, I'd like to develop new features for rosetta (launchpad translations), but there are quite a lot of branches. Which one should I use as a base?	
[01:00] <maxb> https://dev.launchpad.net/Trunk will help you understand how the various branches relate
[01:00] <maxb> Or, in short, base of lp:launchpad/devel
[01:06] <nh2> maxb: nice, thank you
[01:07] <wallyworld> thumper: yo
[01:13] <thumper> wallyworld: hi
[01:14] <wallyworld> skype?
[01:15] <thumper> ok
[01:21] <poolie> thumper: i agree changing the target wbn
[01:28] <wgrant> mars: Um, good luck with getting dpkg to downgrade packages.
[01:28] <wgrant> Downgrades aren't actually supported.
[01:29] <poolie> ?
[01:29] <wgrant> s/dpkg/apt/
[01:29] <poolie> meaning the packages aren't required to cope with it?
[01:29] <wallyworld> packaging 101 question: is there a script to make a tar.gz from an egg for adding to download-cache?
[01:30] <wgrant> poolie: Correct.
[01:31] <wgrant> apt will try very hard to avoid it.
[01:39]  * thumper feels like crying
[01:39] <thumper> why is this so fucking hard
[01:39]  * thumper is upset bzr doesn't allow me to push without stacking
[01:40] <poolie> thumper: init the branch, turn off stacking, then push
[01:40] <thumper> I can't init the branch
[01:40] <thumper> the branch is trunk
[01:40] <poolie> ?
[01:40] <thumper> I'm trying to fix up the remaining 9 maverick branches that are stacked on lucid
[01:40] <poolie> it already exists on lp and is stacked?
[01:40] <thumper> where reconfigure --unstacked breaks
[01:41] <thumper> poolie: yes
[01:41] <thumper> I have local full copies of the branches on devpad
[01:41] <thumper> and I was trying to move the existing .bzr to backup.bzr using hitchhiker
[01:41] <thumper> and repush the full unstacked branch
[01:41] <thumper> but I can't
[01:41] <thumper> two problems stop it
[01:42] <thumper> there is a bug in LP where the trunk is offered to stack when pushing trunk
[01:42] <thumper> (in the weird edge case where you do that)
[01:42] <thumper> and that bzr can't avoid stacking at creation time
[01:44] <thumper> you'd think it wouldn't be that hard
[01:45] <wgrant> thumper: --stacked-on= doesn't help?
[01:45] <thumper> wgrant: is that valid?
[01:45] <wgrant> thumper: I think so.
[01:45] <wgrant> It used to be.
[01:45]  * thumper pokes something
[01:46] <thumper> $ bzr push lp:~thumper/wikkid/test --stacked-on=
[01:46] <thumper> Created new stacked branch referring to file:///home/tim/sandbox/wikkid-sandbox.
[01:46] <wgrant> .... great.
[01:46] <wgrant> Well, you could start pushing, kill it before it finishes, then push again.
[01:46] <wgrant> That should result in it being unstacked.
[01:47] <thumper> I'm tempted to just use hitchhiker to copy the .bzr dir from the devpad copy
[01:48] <thumper> that may work
[01:48] <poolie> :/
[01:48] <lifeless> poolie: lynne is back, but I'm feeling shitty - going to find a local gp and pop in.
[01:48] <lifeless> once I get through to a human @ vodafone
[01:48] <poolie> np
[01:48] <thumper> although I'd have to do something about the checkout dir
[01:49] <poolie> there is a medical centre under the forum, on the side nearest the urban; good luck
[01:49] <lifeless> 6 minutes on hold so far
[01:49] <thumper> poolie: can you think of a better idea?
[01:50] <poolie> i'm trying to understand what you're trying to do
[01:50] <thumper> poolie: ok... here goes
[01:51] <thumper> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick is stacked on https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/libsoup2.4/lucid
[01:51] <thumper> it shouldn't be
[01:51] <thumper> the lucid branch should be stacked on maverick
[01:51] <thumper> I'm trying to fix that
[01:51] <thumper> or
[01:51] <thumper> more correctly
[01:51] <thumper> I'm trying to unstack the maverick branch
[01:51] <thumper> I don't care about lucid not being stacked
[01:51] <thumper> however
[01:51] <poolie> ok, and just reconfiguring it fails how?
[01:52] <thumper> reconfigure --unstacked breaks
[01:52] <thumper> with an error similar to what I pastebinned yesterday
[01:52] <thumper> http://pastebin.ubuntu.com/502991/
[01:52] <thumper> well, this is for lp:ubuntu/language-pack-gnome-tg
[01:52] <thumper> but it is also one of the 9 that fail
[01:53] <poolie> ok and you have new proper copies of the branches elsewhere
[01:53] <thumper> 312 of the 321 incorrectly stacked branches got unstacked correctly using reconfigure --unstacked
[01:53] <thumper> yes, on devpad
[01:54] <poolie> hm
[01:55] <poolie> is it an option to just overwrite it using sftp+?
[01:56] <thumper> what do you mean?
[01:57] <poolie> well, first, let me try to work out if that revision is meant to be in either of those brancehs
[01:58] <maxb> thumper: Why can't you just mv .bzr backup.bzr.~1~ in hitchhiker, then bzr init lp:foo; bzr reconfigure --unstacked lp:foo; bzr push lp:foo ?
[01:58] <thumper> maxb: because bzr init lp:foo errors
[01:58] <maxb> !
[01:58] <thumper> yeah
[01:58] <poolie> thumper: because it tells it to stack on itself?
[01:59] <poolie> can you pastebin that error?
[01:59] <thumper> the error is worse now :(
[02:00] <poolie> uh, still?
[02:00] <thumper> bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches.">')
[02:00] <poolie> !
[02:01] <poolie> that's not my fault :)
[02:01] <thumper> I was going to look at those after I had fixed these branches
[02:01] <poolie> hm so what do you want?
[02:01] <poolie> i can make a patch to disable stacking on random things
[02:01] <poolie> or we can manually edit that repo
[02:01] <poolie> or we can investigate why it won't unstack
[02:03] <thumper> poolie: is it possible to have a hacky plugin to allow me to push without stacking?
[02:03] <thumper> poolie: that might be easiest
[02:04] <poolie> sure
[02:04] <thumper> poolie: then I could move the .bzr to backup.bzr with hitchhiker
[02:04] <thumper> poolie: and push the full copy in
[02:04] <poolie> i'm just wondering if you're going to hit the same zope error?
[02:04] <thumper> that zope error is due to it looking for the branch to stack on
[02:04] <thumper> I can use the full url to hitchhiker in still
[02:05] <thumper> so all we need is to be able to push an unstacked branch
[02:05] <thumper> then we can look into the unstacking failure
[02:05] <thumper> et al
[02:05] <thumper> I need to fix those error messages
[02:05] <thumper> but I'm not sure that'll get done in time
[02:05] <thumper> i.e. by EOD as I'm off next week
[02:05] <thumper> I might get abentley to look into it next week
[02:06] <thumper> I'm guessing it isn't actually that hard
[02:06] <thumper> just catching the error in the right place
[02:06] <thumper> and returning it correctly though the smart server
[02:15]  * thumper looks for food
[02:16] <poolie> thumper, i'll see what i can do about it
[02:16] <poolie> i don't think i'll have access to write to those branches but that can probably be fixed
[02:35] <thumper> poolie: if you can get me the hacky plugin, I can put it on devpad and push the branches
[02:35] <thumper> poolie: you can always test it locally
[02:35] <poolie> k
[02:39] <poolie> just testing it
[03:09] <maxb> Did anyone make any headway on the CSCVS  NoWhoami problem yesterday?
[03:10]  * maxb is collating a list of failed imports
[03:10] <thumper> maxb: not that I know of
[03:11] <thumper> maxb: is there a bug filed?
[03:11] <mwhudson> we need a losa to look at the importds i think
[03:12] <thumper> mwhudson: do you think that is better than hacking CSCVS?
[03:13] <mwhudson> thumper: maybe not
[03:13] <poolie> thumper: ok, lp:~mbp/bzr/stacking adds a -Ddisable_stacked_on_url debug flag
[03:13] <poolie> which should do what you need
[03:13] <poolie> you can set that for pushing, etc
[03:13] <mwhudson> i don't understand why it changed though :/
[03:15] <thumper> poolie: can I just check that out on devpad and use the bzr in it directly?
[03:15] <thumper> poolie: do I have to compile anything?
[03:16] <thumper> $ bzr branch  lp:~mbp/bzr/stacking mbp-bzr
[03:16] <thumper> bzr: ERROR: The branch lp:~mbp/bzr/stacking has no revision None.
[03:16] <thumper> ?
[03:17] <poolie> ah, heh
[03:17] <poolie> i'm using it to push itself, so it's taking a bit longer than usual :)
[03:17] <poolie> i'll push it to devpad in a shared repo
[03:17] <poolie> hang on
[03:23] <poolie> thumper: that branch is there for you now
[03:23] <thumper> poolie: on lp?
[03:24] <poolie> yup
[03:27] <thumper> poolie: do I have to "make" anything
[03:27] <thumper> ?
[03:47] <thumper> poolie: doesn't quite work: $ ~/mbp-bzr/bzr push -Ddisable_stacked_on_url --use-existing lp:~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick
[03:47] <thumper> Using default stacking branch /~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick at lp-64804368:///~ubuntu-branches/ubuntu/maverick/libsoup2.4
[03:47] <thumper> bzr: ERROR: The branch 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick/' cannot be stacked on '/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick'.
[04:13] <poolie> thumper: sorry, back now, no, you shouldn't need to build anythnig
[04:14] <poolie> can you paste the traceback please?
[04:15] <thumper> there was no traceback
[04:15] <poolie> not even in .bzr.log?
[04:16]  * thumper looks
[04:17] <thumper> poolie: devpad:/home/tim/.bzr.log
[04:17] <thumper> mwhudson: ping
[04:19] <poolie> sorry thumper, that's -Ddisable_set_stacked_on_url
[04:19] <poolie> :/
[04:19] <poolie> my mistake
[04:19]  * thumper sighs
[04:19] <poolie> obviously it's too long
[04:20] <thumper> what about -Ddisable_stacking
[04:20] <mwhudson> thumper: hi
[04:20] <thumper> mwhudson: got a few minutes for a pre-impl?
[04:20] <poolie> that would've been smarter
[04:20] <thumper> mwhudson: translatePath errors
[04:20] <mwhudson> thumper: ok
[04:21] <thumper> mwhudson: thanks
[04:22] <mwhudson> hmm
[04:22] <mwhudson> thumper: can you hear me?
[04:22] <thumper> mwhudson: no all I could here was me
[04:22] <mwhudson> bah
[04:23] <poolie> thumper: i'm trying to work out if i should file a follow-on bug to  fix this properly
[04:24] <mwhudson> oh ffs
[04:24] <poolie> perhaps it is that we want a configuration option to say whether bzr should trust server-suggested stacking?
[04:24] <thumper> poolie: it would be great to have a client side way of saying "ignore stacking"
[04:31] <poolie> thumper:  i guess it's bug 368913
[04:31] <_mup_> Bug #368913: bzr tries to stack on a new branch with stacking policy pointing at . <launchpad> <stacking> <Bazaar:Confirmed> <https://launchpad.net/bugs/368913>
[04:31] <poolie> and bug 391405
[04:31] <_mup_> Bug #391405: want an option to force stacking or not when creating a branch <stacking> <Bazaar:Confirmed for mbp> <https://launchpad.net/bugs/391405>
[04:38] <poolie> thumper: sorry for the lag, is it ok now?
[04:41] <thumper> poolie: looks like that works
[04:41] <thumper> 8 left to fix
[04:55] <poolie> it's hard to get used to having so much code in .txt files
[05:09] <poolie> how do i run just a single doctest?
[05:09] <poolie> i mean, a single file?
[05:11] <wgrant> bin/test -t blahblah.txt
[05:11] <wgrant> Don't try to give the full path -- it's often not what you expect.
[05:14] <poolie> ah, so bugs-emailinterface as a workaround for something appears under lib.canonical.launchpad.ftests
[05:15] <poolie> not the module that actually contains it
[05:17] <wgrant> It varies.
[05:18] <stub> poolie: Everything in canonical.launchpad shouldn't be there (but where to put it? Its still unclear often where under lp. things should go)
[05:23] <poolie> stub: well, in this case the actual file is in lp.bugs.tests
[05:23] <poolie> which is not a bad place for it imo
[05:24] <poolie> something to do with bug 305856
[05:24] <_mup_> Bug #305856: Spurious/intermittent test failure in answers/doc/emailinterface.txt <spurious-test-failure> <tech-debt> <Launchpad Answers:Triaged> <https://launchpad.net/bugs/305856>
[05:24] <stub> right. but people are encouraged to put new stuff in the 'correct' place rather than in canonical. which might explain the disconnect
[06:45] <thumper> wallyworld: normally page tests test no-js functionality
[06:45] <thumper> wallyworld: and the windmill ones test js functionality
[06:46] <thumper> wallyworld: interactively I use a firefox plugin to disable js
[06:46] <wallyworld> thumper: in that case, everything should be sweet, no?
[06:46] <thumper> wallyworld: have you checked that the existing test coverage covers the case you care about?
[06:46] <wallyworld> yes, xx-branchmergeproposals.txt
[06:47] <thumper> wallyworld: have you made the fix?
[06:47] <wallyworld> that doc test basically creates merge proposals etc and checks the results
[06:47] <wallyworld> i added to it as well as part of the increased test coverage for the new stuff in the branch
[06:48] <thumper> wallyworld: you are good to go now
[06:48]  * thumper EOWs
[06:49] <wallyworld> thumper: thanks. enjoy your week off :-)
[07:32] <noodles775> Morning
[07:32] <wgrant> Morning noodles775.
[07:59] <poolie> ok
[07:59] <poolie> trying to fix my dkim/gpg failures now
[08:07] <poolie> omg these doctests with everything running together
[08:35] <poolie> w
[08:40] <adeuring> good morning
[09:01] <lifeless> stub: ttps://bugs.edge.launchpad.net/launchpad-foundations/+bug/640125 is linked to the branch in rev 11567, but it needs qa
[09:01] <_mup_> Bug #640125: cron scripts should log everything, but only send mail for errors <canonical-losa-lp> <qa-needstesting> <Launchpad Foundations:Fix Committed by stub> <https://launchpad.net/bugs/640125>
[09:02] <stub> Yup. That might have got to staging now so can be tested when I've kicked off the 8.4 slave
[09:03] <wgrant> What do we use python-tickcount for?
[09:04] <wgrant> It seems odd that nobody else on the planet needs it.
[09:04] <lifeless> stub: its causing https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt issues  because (like me) you reuse branches
[09:04] <lifeless> wgrant: lsprof didn't exist
[09:05] <bigjools> morning all
[09:05] <wgrant> Morning bigjools.
[09:07] <poolie> oh yay
[09:07] <wgrant> lifeless: Can we use lsprof instead?
[09:07] <lifeless> well we won't get ticks, but I'm not sure they are a great proxy
[09:07] <lifeless> better to implement bug xxxx for per thread resource usage in oops.
[09:08] <wgrant> (python-tickcount and ubuntu-keyring are the two packages that really tie us to Ubuntu)
[09:09] <mrevell> Hey
[09:12] <jml> Good morning
[09:12] <jml> thumper, poolie: hi
[09:13] <jml> thumper, poolie: I've honestly been meaning to check out jameinel's branch. Really.
[09:19] <poolie> np, it shouldn't be your job to review everything
[09:19] <poolie> though i guess this is a bit in your areao
[09:23] <poolie> gmb: can i trouble you for an incremental review on https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
[10:15] <jml> noodles775: just looking at your comment ordering post...
[10:16] <jml> noodles775: out of curiosity, is the code in that demo using lp.services.comments?
[10:16] <noodles775> jml: yep.
[10:16] <jml> noodles775: cool :)
[10:18] <mrevell> noodles775: ping
[10:19] <noodles775> jml: I had to modify lp.services.comments a bit, and I think lp.services.comments could be generalised a bit more too.
[10:19] <noodles775> mrevell: yup?
[10:19] <jml> noodles775: both make sense.
[10:19] <jml> noodles775: as far as I know, lp.s.comments is an intent-to-generalize more than an actual proven generic solution.
[10:20] <mrevell> noodles775: Hey, do you have time for a call today? I'd like to pick your brains on your screencast recording setup.
[10:20] <noodles775> mrevell: sure, although it's just gtk-recordmydesktop. I can talk now, or after lunch, whatever works for you.
[10:21] <mrevell> noodles775: Is in five minutes okay?
[10:21] <noodles775> Sure, I'll be in the soyuz 1-1 on mumble?
[10:21] <mrevell> Ta
[10:46] <jml> afk for ~20 mins
[11:07] <jml> now, to action
[11:12] <bigjools> jml: where is your bzr plugin to show the XXXes?
[11:13] <jml> lp:difftodo
[11:13] <bigjools> jml: rock, thanks
[11:13] <jml> it's not bundled as a regular plugin. am happy to help w/ install issues
[11:13]  * bigjools as adding copious more to the b-m code
[11:18] <bigjools> jml: I checked it out in plugins/ and did "bzr todo" - how easier can it be? :)
[11:19] <jml> bigjools: glad to hear it. it's just been ages since I've installed it or had a new user, so was expecting worse.
[11:28] <bigjools> jml: this _deferred_list stuff is a nightmare :/
[11:28] <jml> bigjools: I've long thought so :)
[11:29] <bigjools> jml: in particular the way it chains callables together in the recording slave with the *DispatchResult at the end
[11:29] <jml> bigjools: you mean the way it hangs so much on exactly what kind of dispatch result you get?
[11:30] <bigjools> jml: it's a consequence of the recording slave strategy.  Because it doesn't know in advance what Deferreds will be fired or how many of them, it just keeps processing the recorded slave calls until it hits an instance of the BaseDispatchResult
[11:31] <jml> ahh
[11:31] <bigjools> which, when called,p does a Thing
[11:31] <jml> bigjools: that makes a strange kind of sense
[11:31] <bigjools> the Thing to do was decided ages ago
[11:31] <bigjools> jml: yes, that's the annoying thing about it :)
[11:32] <jml> bigjools: actually, I was going to ask you about the branch anyway...
[11:32] <bigjools> jml: fire away
[11:33] <jml> bigjools: I'd like to keep up-to-date with the changes. I'll probably have thoughts, questions etc. What's the most helpful way of sending those back to you?
[11:33] <jml> bigjools: as I get them, or wait until you've reached some kind of checkpoint or... ?
[11:33] <bigjools> jml: as you get them would be good - I'm committing a few times a day when I work on it, but that's not regular at all
[11:33] <jml> bigjools: will do.
[11:33] <bigjools> I'm trying to make the commit messages as useful to you as possible
[11:34] <lifeless> stub: any idea about the 15 second update in the +delete bug?
[11:34] <stub> ENOCONTEXT
[11:34] <jml> bigjools: not promising I'll get any time. I just filled up an a4 page with "work things currently on the go"
[11:34] <bigjools> ha
[11:35] <lifeless> stub: https://bugs.edge.launchpad.net/launchpad-registry/+bug/652802
[11:35] <_mup_> Bug #652802: Person:+delete timeouts on teams <Launchpad Registry:Triaged> <https://launchpad.net/bugs/652802>
[11:35] <bigjools> jml: BTW remember all those traps we added that just log messages?
[11:35] <jml> bigjools: yeah.
[11:35] <bigjools> jml: I've decided that we should remove them, because inside scan() it catches all errors anyway and does the failure counting.
[11:36] <bigjools> if we can make all aspects of the job management get failure counted for free, that would be...win
[11:36] <jml> bigjools: that makes sense... as long as the errors don't get lost.
[11:36] <bigjools> jml: I can still log - just throw the failure again
[11:37] <jml> bigjools: for me, the confusing part of the error handling is that some parts catch and throw away and others re-raise and others catch and then signal failure with some different mechanism
[11:37] <bigjools> jml: you're not alone in confusion
[11:37] <jml> bigjools: it would be nice if everything just damn well raised & let the bm take care of it all.
[11:38] <lifeless> exceptions are great for errors
[11:38] <bigjools> in exceptional cases
[11:38] <bigjools> routine errors - no
[11:41] <lifeless> you've argued this before, but not made a compelling case
[11:44] <stub> lifeless: It is slow because it is trying to update 25k rows in a table of 60million
[11:44] <lifeless> oh wow.
[11:45] <lifeless> deceptive ;P
[11:45] <lifeless> thanks for looking that up
[11:46] <stub> real question is how come it managed that query in 15s. Took my test 46s :)
[12:02] <deryck> Morning, all.
[12:07] <lifeless> night all
[12:35]  * bigjools drowns in build manager hideousness
[12:37] <deryck> That rabbitmq hang on shutdown is annoying.
[12:38] <bigjools> deryck: yes
[12:39] <bigjools> I've made a /etc/default/rabbitmq file that overrides the DAEMON variable in the startup script to /bin/true
[12:39] <deryck> I shall do that now.
[12:40] <bigjools> death to persistent services only needed by LP....
[13:03] <jml> om nom nom
[13:14] <maxb> My /etc/default/rabbitmq says "exit 0" :-)
[13:27] <bigjools> heh
[13:31] <bigjools> our fake logger copes quite miserably when one of the strings it's trying to log has a % in it
[13:31] <jelmer> which of our 3 fake loggers ? :-)
[13:32] <bigjools> quite
[13:40] <allenap> bryceh: Can you triage bug 644794? It's one of yours :)
[13:40] <_mup_> Bug #644794: Link BugTrackerComponents to distro/sourcepackages <Launchpad Bugs:New> <https://launchpad.net/bugs/644794>
[13:43] <jml> bigjools: I thought we fixed that.
[13:45] <jml> sinzui: hi
[13:45] <sinzui> hi jml
[13:45] <jml> sinzui: (foo,) is perfectly valid Python syntax, PEP 8 preferred and our historical coding standard. Why are we changing it?
[13:46] <sinzui> because PEP8.py is complaining and I do not want to see the complaint
[13:46] <jml> sinzui: fix pep8.py
[13:47] <sinzui> maybe
[13:49] <jml> sinzui: or stop using it. it's putting the cart before the horse to change the way we write code to match a bug in a third-party tool.
[13:49] <sinzui> would you like to put pylint back
[13:49] <jml> no.
[13:49] <jml> but that's not the only other option open to us :)
[14:01] <jml> sinzui: https://code.edge.launchpad.net/~jml/pocket-lint/singleton-tuples/+merge/37242
[14:02] <deryck> allenap, many many thanks for helping triage bugs today.  Sorry if I'm stepping on you, too. :-)  Was trying to help catch them up today as well.
[14:02] <allenap> deryck: I haven't noticed actually.
[14:03] <deryck> ok, cool
[14:07] <jml> sinzui: thanks for the review. how soon can we have the patched version on developer machines?
[14:07] <bigjools> jml: we have, but this time it's in the string outside of the exc_info
[14:07] <jml> deryck: is sladen filing bugs by email, or is the dupe checker substantially worse
[14:07] <jml> bigjools: huh what?
[14:08] <bigjools> jml: a traceback being passed in instead of using exc_info, basically
[14:08] <sinzui> jml: soon is never an option with building PPAs. maybe Wednesday
[14:08] <jml> sinzui: what needs to happen?
[14:08] <jml> bigjools: sorry I think I missed some context.
[14:09] <jml> bigjools: oh never mind
[14:09] <bigjools> sinzui: there are plenty of buildd-admins around who can rescore builds, I'm one of them ;)
[14:09] <sinzui> I push the new source package then we wait for its turn to be built
[14:09]  * sinzui has never consider cheating
[14:09] <jml> sinzui: I have a graph that shows the queue empties regularly
[14:09] <sinzui> wel not on this subject anyway
[14:10] <sinzui> jml, the last pocket-lint build for Jelmer took about a weeks to do all the hops
[14:10] <bigjools> sinzui: anyway the queue is small
[14:11] <jml> sinzui: well, let me know when you've pushed the build. I guess it has to go into the launchpad developer PPA?
[14:11] <sinzui> jml, okay
[14:11] <sinzui> jml, we just vopy it
[14:11] <sinzui> copy
[14:12] <jml> sinzui: nice.
[14:24] <allenap> deryck: Can you triage bug 651128? I can't really judge how important it is.
[14:24] <_mup_> Bug #651128: Email bug submission fails due to erroneous bad signature detection <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/651128>
[14:41] <deryck> allenap, sure, I'll take a look.
[14:41] <allenap> deryck: Thanks.
[14:42] <deryck> np
[14:43] <deryck> jml, I believe he is email filing the bugs.
[14:44] <jml> deryck, I wish we could force a dupe checker into everyone's email client.
[14:44] <deryck> yup
[14:45] <deryck> would save us all a lot of time. :-)
[14:50] <deryck> I don't really like our behavior of adding bug watches when someone adds a link for a tracker we recognize.
[14:50] <deryck> Maybe this helps other projects but for malone it's almost always wrong to do this.
[15:04] <noodles775> mars: Regarding bug 644984, does that mean that lifeless' fix (r11597 in devel) is not in production-devel, or that it is but didn't fix it?
[15:04] <_mup_> Bug #644984: test_runAll_mails_oopses fails sometimes <qa-needstesting> <Launchpad Foundations:Fix Committed by mars> <https://launchpad.net/bugs/644984>
[15:05] <noodles775> (you might want to re-open the bug if so)
[15:05] <mars> noodles775, I haven't looked yet (that is why I left it Fix Commited)
[15:05] <noodles775> Ah.
[15:05] <mars> need to do this first, then thtat
[15:06] <deryck> hurray for allenap and I!  bug box 0.
[15:06] <allenap> deryck: We rule :)
[15:07] <mars> deryck, is that a first?
[15:07] <mars> for anyone?
[15:08] <deryck> mars, oh, no.  We keep our New bug count at zero as best we can.
[15:08] <deryck> mars, I've just let it slip for a little over a week as I was coding more.  And I new most of them were dupes or need lots of explaining to users and was being lazy.
[15:09] <deryck> to my defense this is often the case for malone bugs and I was just worn down by it temporarily :-)
[15:09] <mars> heh
[15:18] <deryck> The overlays are not aligned properly anymore, I think
[15:23] <deryck> allenap, what do you make of kitterman's comment in the follow up to bug 651128?  Maybe this is a problem with that script?  No one else is having issues with bad sigs.
[15:23] <_mup_> Bug #651128: Email bug submission fails due to erroneous bad signature detection <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/651128>
[15:25] <malaria> danilos: Hi, are you here?
[15:26] <allenap> deryck: We could ask him to file a bug by email directly to try and isolate requestsync.
[15:26] <deryck> allenap, indeed.  I'll ask him to confirm on staging.
[15:29] <malaria> danilos: about the agreement, do I send it to you? (I mean, in addition to contributor-agreement@canonical.com )
[15:29] <danilos> malaria, hi, no, no need to
[15:30] <malaria> danilos: ok, so just for contributor-agreement@canonical.com
[15:33] <malaria> danilos: done. I re-created my branch on top of trunk and I updated the patch (now tests in browser-helpers.text work)
[15:34] <malaria> danilos: what more can I do?
[15:35] <danilos> malaria, the next step is to propose it for merging :)
[15:36] <danilos> malaria, see https://dev.launchpad.net/CoverLetters for how to describe the change as well :)
[16:12] <jml> danilos: can you please give me a non-ascii unicode literal for Python?
[16:15] <danilos> jml, in what format? :)
[16:15] <danilos> \u0422 is probably a Cyrillic character
[16:15] <jml> danilos: something I can paste into a Python file as a unicode literal :)
[16:16] <mars> jml, ā
[16:16] <danilos> jml, does the above work, or you want something like "д" :)
[16:16] <danilos> I seem to ask too many questions and mars is quicker to the point :)
[16:16] <jml> foo = <thing>; I want something for <thing>
[16:17] <danilos> jml, right, well, foo = u'проба' should do if you are using utf-8 encoding
[16:17] <jml> danilos, mars: thanks.
[16:17] <jml> danilos: groda?
[16:18] <danilos> jml, it's "proba" (п is like Greek pi :), meaning "test"
[16:18] <jml> dammit. I always get that wrong.
[16:19] <jml> some day...
[16:20] <jml> fwiw, if you paste the literal into a file, you get... SyntaxError: Non-ASCII character '\xd0' in file testrepository/tests/ui/test_cli.py on line 198, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[16:20] <jml> using         error_text = u'\u043f\u0440\u043e\u0431\u0430'
[16:20] <jml>  instead.
[16:20] <mars> jml, you have to tell your editor to save it as utf-8 with a BOM
[16:21] <danilos> jml, you need to use "# -*- encoding: utf-8" (PEP-9 I think)
[16:22] <danilos> uhm, I mean PEP263 as the error message says :)
[16:22] <jml> ahh :)
[16:22] <jml> I'm going to live on in merry ignorance of what BOM means in this context
[16:22] <mars> byte order mark
[16:22] <mars> silly thing needed by Windows
[16:24] <danilos> jml, BOM with UTF-8 is creepy stuff (it's "byte-order mark" and "byte-order" doesn't make much sense with a byte stream like UTF-8; it's something like \ufffe or \ufeff)
[16:25] <jml> although I value the beauty and richness of human culture
[16:26] <jml> sometimes I wish the Romans had beaten everyone
[16:28] <mpt> Credo te iustum locum quaerere Quotes Page
[16:41] <jml> mpt: no, I'm not.
[16:41] <mpt> :-)
[16:57] <malaria> danilos: 'make lint' give me some "Line exceeds 78 characters" warning is this a problem? (there are other warnings for no-patched parts of the code...)
[16:58] <danilos> malaria, yeah, a reviewer will usually ask you to fix these (even if you didn't cause them)
[16:58] <malaria> danilos: ok, so I'm going to fix these.
[17:01] <malaria> danilos: one more thing, it complains about "narrative uses a moin header." I don't really get what this mean...
[17:09] <bigjools> jml: have you looked at my changes yet?  No rush, but I have a question if you have.
[17:09] <jml> bigjools: no, not ye.
[17:10] <bigjools> jml: ok, I am in the mood to delete code and I think I can blitz about 100 lines of crap in manager.py
[17:11] <bigjools> but some of it is most intriguing
[17:12] <jml> bigjools: ooh.
[17:12] <malaria> danilos: ok, I found
[17:12] <jml> bigjools: which bits?
[17:14] <bigjools> jml: it's all of the stuff that deals with recording slave, processing the deferred_list etc
[17:14] <bigjools> but I can't figure out wtf the stuff in checkDispatch is needed for
[17:15] <bigjools> the error handling I think can move moved wholesale to the startCycle method
[17:15] <bigjools> s/move/be/
[17:16] <jml> bigjools: agree re error handling
[17:16] <jml> (also, we should have a doCycle method, or something that does everything sans scheduling the next call)
[17:17] <bigjools> jml: already done :)
[17:17] <jml> bigjools: sweet.
[17:17] <bigjools> makes the tests somewhat nicer ...
[17:17] <jml> bigjools: in that case, error handling should be there, not startCycle
[17:17] <jml> bigjools: I'm not at all surprised :)
[17:17] <bigjools> yes the error handling is in the equivalent of your doCycle
[17:18] <jml> on checkDispatch, the bit that I don't get is this:
[17:18] <jml>             if method in buildd_success_result_map:
[17:18] <jml>                 expected_status = buildd_success_result_map.get(method)
[17:18] <jml>                 status, info = response
[17:18] <jml>                 if status == expected_status:
[17:18] <jml>                     self.callSlave(slave)
[17:18] <jml>                     return None
[17:18] <bigjools> that's exactly what I am pondering over too
[17:19] <jml> under what circumstances is 'response' a 2-list?
[17:19] <bigjools> I think it's checking return values only for some of the calls
[17:19] <bigjools> why.... who knows
[17:19] <jml> 'callSlave' is just "do the next step", iiuc
[17:19] <bigjools> yep
[17:19] <bigjools> it's clearly not needed any more, I'm just trying to work out if it's doing something we need
[17:20] <bigjools> err that doesn't parse well
[17:20] <bigjools> but you get the idea :)
[17:20] <jml> yeah, I do :)
[17:21] <jml> bigjools: my guess is that the chunk of code pasted above is belt-and-braces for RecordingSlave
[17:21] <jml> based on how buildd_success_result_map gets used in it
[17:21] <bigjools> I tend to agree
[17:21] <jml> where does checkDispatch get 'response' from?
[17:21] <jml> from callSlave...
[17:21] <bigjools> xmlrpc.Proxy callback
[17:23] <jml> yeah
[17:24] <jml> so if I'm reading this correctly (big 'if'), the behaviour in trunk is to terminate the series of calls to the remote slave as soon as we get an 'ensurepresent' return value that's not (True, $SOMETHING) or a 'build' return value that's not (BUILDING, $SOMETHING)
[17:25] <bigjools> that's about it
[17:25] <jml> I don't know why that's desirable behaviour.
[17:26] <bigjools> I've looked at that code many many times in the last 6 months and I still don't know either
[17:26] <jml> it sounds to me as if those checks ought to be done around explicit calls to build() and ensurepresent()
[17:26] <jml> perhaps it's a fail-fast kludge?
[17:26] <bigjools> we can bear it in mind when we change the BlockingProxy over
[17:26] <jml> I don't think we need to.
[17:27] <jml> we can bear it in mind if stuff on dogfood breaks because we call the slave too often.
[17:28] <bigjools> mebbe
[17:29] <bigjools> in that case, I'm nearly done, it's just a case of removing swathes of this code, its tests, and dealing with the errors at the top of the call chain
[17:30] <jml> woot :)
[17:32] <bigjools> oh, and working out where to commit now that I'm removing the *DispatchResults
[17:32] <jml> bigjools: this code & conversation reminds me of Kernighan's Law
[17:32] <jml> "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
[17:32] <bigjools> they're wrapped in @write_transaction
[17:32] <bigjools> indeed
[17:35] <jml> bigjools: I guess it makes sense to commit at the very end
[17:36] <bigjools> jml: I'm not sure about that
[17:36] <jml> bigjools: well, that's what it does now.
[17:36] <bigjools> jml: not entirely - it has three separate commits
[17:37] <bigjools> there's the one around scan(), the one after calling updateStatus and the one when dealing with the end of the dispatch chain
[17:40] <jml> bigjools: yeah, I mean one to replace the calls in dispatch
[17:45] <malaria> danilos: I requested merge :)
[17:46] <jml> bigjools: just in case you missed it...
 bigjools: yeah, I mean one to replace the calls in dispatch
[17:47] <danilos> malaria, cool, you can probably get a review from someone on #launchpad-reviews, if not, I'll get to it on Monday (mostly done for the day and I am starving :)
[17:47] <bigjools> jml: those ones are only wrapping the assesFailureCounts() and the reset_result which cleans the job
[17:47] <bigjools> both already dealt with
[17:47] <bigjools> jml: so I'm going to add one at the end of the scan for good measure :)
[17:48] <jml> hmm.
[17:48] <malaria> danilos: ok, I'm going to #launchpad-review. Otherwise, have a good week-end ;)
[18:03] <danilos> malaria, thanks :)
[18:05] <dobey> deryck, allenap: do you guys know what the heck http://pastebin.ubuntu.com/504016/ means?
[18:05] <deryck> dobey, I do, unfortunately :-)
[18:06] <deryck> dobey, your trying to edit the slave bug task rather than the master. where the series is the master, the upstream the slave.
[18:08] <dobey> i don't think so?
[18:08] <dobey> or i don't understand what that means
[18:08] <dobey> but the error message is obviously not helpful to me directly :)
[18:09] <bigjools> good evening all, have a nice weekend
[18:14] <dobey> hmm
[18:14] <dobey> deryck: ok, if that is the problem, how do i determine if i am editing the right thing?
[18:25] <deryck> dobey, sorry, on call.  I'll explain better in a minute.
[18:28] <dobey> ok
[18:38] <jml> g'night all.
[18:38] <jml> if you see lifeless, tell him to release testr.
[18:59] <deryck> dobey, sorry for delay.  Had to finish calls.  Does this help explain?  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/annotate/head%3A/lib/lp/bugs/doc/bugtask.txt#L286
[19:00] <deryck> The section starting there, "Conjoined Bug Tasks"
[19:04]  * dobey reads
[19:12] <dobey> deryck: does launchpadlib know anything about the conjoined_* attributes?
[19:13] <deryck> dobey, no
[19:14] <dobey> deryck: so how do i tell if the target i'm looking at, is the one i want, if the bug has a conjoined task for the development series?
[19:16] <deryck> dobey, perhaps bdmurray or bryceh have some stock code snippets for this they could share.  I don't do this myself much since we don't use series targeted bugs on launchpad.
[19:16] <deryck> bdmurray, bryceh -- what sort of check do you guys do in lplib to make sure you have the right side of the conjoined bug task?
[19:20] <bdmurray> I'm still not clear on what a conjoined bug task is. ;-)
[19:21] <maxb> Urgh. We need support for the code import dispatcher to only dispatch one job per svn repository uuid per importd
[19:21] <dobey> bdmurray: i think it's sort of like http://southparkstudios-intl.mtvnimages.com/shared/sps/images/shows/southpark/vertical_video/import/season_02/sp_0205_08_v6.jpg?width=480
[19:23] <sinzui> leonardr, your authorisation email is a great read
[19:24] <leonardr> sinzui, thanks
[19:25] <dobey> bdmurray: do you know where the code is that closes Ubuntu bugs based on the (LP: #xxx) comments in debian/changelog for package uploads?
[19:26] <deryck> bdmurray, so what do you do?  try/except around conjoined?
[19:26] <deryck> dobey, if it were me, I would inspect the target and see what it is before trying to edit the task.
[19:26] <bdmurray> deryck: I can't answer that without knowing what exactly a conjoined bug task is
[19:27] <dobey> deryck: yes, but there is no obvious information about whether the target and series are the same
[19:27] <dobey> deryck: because the main generic task always has no series
[19:27] <bryceh> I'm not sure what conjoined means either
[19:27] <dobey> deryck: better question: why doesn't editing the master, simply edit the slave instead?
[19:27] <deryck> you'll get a ConjoinedBugTask error if you try to edit the main bug task when it's tracked in the series.
[19:27] <bdmurray> dobey: No someone the code team would know there is a dpkg part that parses the changelog gets the numbers though
[19:28] <deryck> it's in soyuz.
[19:28] <bdmurray> right, that's what I meant!
[19:28] <dobey> bdmurray: yeah, i'm less interested in the number parsing, than how it deals with picking the bug task based on series
[19:28] <deryck> dobey, if you edit the master, it will work.  it's editing the slave that fails.  In this case, the primary task, not series task, is the slave.
[19:28] <dobey> oh
[19:29] <dobey> deryck: ok, then transpose slave and master in my question :)
[19:29] <dobey> Launchpad does not know where Soyuz - The Launchpad Package Manager hosts its code.
[19:29] <dobey> nice.
[19:29] <deryck> dobey, just construct your searchTasks query to get the ones you want.  using nominated_for
[19:30] <dobey> deryck: branches don't have a nominated_for
[19:30] <deryck> so you're going branch-->bug-->bugtask?
[19:30] <dobey> deryck: i am taking a list of the bugs fixed in a branch (from bzr commit --fixes=blah), and trying to mark them as 'fix committed' when the branch is merged into its target
[19:31] <dobey> deryck: and having to support different series, makes it hate life
[19:31] <dobey> because the conjoined task thing kind of screws everything up
[19:32] <deryck> dobey, I don't know how you can do that without looking at the target.  Because there could be any number of tasks on the bug.
[19:32] <dobey> deryck: i am looking at the target
[19:33] <deryck> and can you not tell the different in a series targeted bug from the regular task, looking at the target?
[19:34] <dobey> deryck: let me try to find a meaningfully useful example to explain with
[19:39] <james_w> see process_bug in http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head:/mass-sync.py
[19:40] <james_w> it does two passes, one to fill related_tasks for those tasks which have a slave task, then the other to process the bugs
[19:41] <dobey> deryck: so on             try:
[19:41] <dobey>                 print task.target.development_focus
[19:41] <dobey>             except AttributeError:
[19:41] <dobey>                 pass
[19:41] <dobey> ah, stupid paste
[19:41] <dobey> sorry
[19:42] <deryck> dobey, I think what james_w pasted above will get you unstuck.  Thanks much, james_w! :-)
[19:47] <dobey> not sure that will help
[19:50] <bdmurray> will a rootsite parameter with canonical_url remove 'edge' from a returned url?
[20:16] <bdmurray> sinzui: do you know? the answer to my question above?
[20:17] <sinzui> bdmurray, no it removed bugs|translations|etc
[20:18] <bdmurray> sinzui: does anything strip edge?
[20:18] <sinzui> no
[20:18] <sinzui> well, logout does it very well
[20:18] <bdmurray> heh
[20:19] <sinzui> bdmurray, few conditions that allow users to leave the env name do so by hardcoding the url, or they set the cookie to disable edge redirection
[20:20] <bdmurray> sinzui: it's appearing in a bug email body which is then sent to users
[20:22] <sinzui> well I think that is correct. as an edge user it should be clear I am being directed to edge
[20:22] <sinzui> bdmurray, is the issue that non-edge users are being sent to edge?
[20:23] <sinzui> I recall that lp recognises that the user is not an edge user a redirects him or her to lpnet instead
[20:24] <bdmurray> I believe its more a matter of consistency most, if not all, urls don't contain edge
[21:43] <sinzui> bdmurray, did you find a solution to you link problem?
[21:44] <sinzui> bdmurray, I think a lot of email orginate from an lpnet process so they always have lpnet urls
[21:45] <bdmurray> sinzui: no I did not find a solution
[21:47] <sinzui> i'll look too
[21:50] <sinzui> bdmurray, what part of the application is sending emails? is it in proc. Most bug mail is queue and the bug mailer which runs on lpnet only send the email, which has the expected urls
[21:54] <bdmurray> its in bugchange.py which I think is used by the cronjob that sends bug change notifications
[21:54] <sinzui> bdmurray, many templates do something like this instead of a canonical_url https://launchpad.net/~%(person)s/+editemails
[21:56] <sinzui> bdmurray, I do not think edge has cronjobs running
[21:57] <sinzui> bdmurray, so the problem is in getBugNotification()?
[21:58] <bdmurray> of BugDuplicateChange yes
[22:00] <bdmurray> I'm really pretty sure that bugnotification.py is running on loganberry as I had to have a fix cowboyed there once
[22:00] <sinzui> looks like we are making the data too early. We make it in proc on edge. The data is queue. An external proc on lpnet then pull from the queue and it has urls with edge in it
[22:02] <sinzui> I wonder if we want to do create something like expand path that takes a path and make it a canonical_url for the current env
[22:05] <sinzui> bdmurray, so gmb introduce the bug last month, but the first wrong use if it was added by myself in 2007
[22:06] <sinzui> no, this bug is from 2009
[22:07] <sinzui> well, regardless we need to decide how to postpone making URLs until we are ready
[22:16] <sinzui> bdmurray, we may want try forcing canonical url to use config.launchpad,non_restricted_hostname
[22:18] <sinzui> bdmurray, I think this can be used in any env to make make a canonical path that is concatenated to the non-edge version of the site:  config.launchpad.non_restricted_hostname + canonical_url(bug_task, force_local_path=True)
[22:22] <bdmurray> sinzui: how would you test it?
[22:24] <sinzui> bdmurray, this is an example of a less hackish way. We do this for openid/XRDS to ensure lpnet is used: http://pastebin.ubuntu.com/504160/
[22:29] <bdmurray> sinzui: okay, thanks for the help!
[22:30] <sinzui> bdmurray, I think we need to push test information into the config to be certain the method under test is making the url we control: maybe http://pastebin.ubuntu.com/504162/
[22:30] <sinzui> config.pop() reset the config. the config is global...we need to do this so that other tests do not see it
[22:33] <sinzui> bdmurray, I can see other things, to covert bug to question is also broken
[22:34] <sinzui> instead of hacking this method. write a function that takes any canonical url, converting it to a URI, then switches the host. That is very easy to test and then reuse
[22:35] <bdmurray> where would you put such a function?
[22:37] <lifeless> why do you ned to do that ?
[22:40] <sinzui> bdmurray, I think we might want add helpers.py to lp.services.mail. There is already a helpers in c.l and I think it too has mail template helpers in it
[22:42] <sinzui> lifeless, urls are generated in some case edge, then inserted into emails. I see three cases for bugs. I see that many old registry templates avoid the edge host by hard coding the domain in the email template, and interpolate the path from the canonical_url
[22:43] <lifeless> well we're nuking edge very soon
[22:43] <lifeless> may be simpler to justs not bother addressing this
[22:43] <sinzui> oh, then we can also nuke some openid code then
[22:44] <lifeless> by soon, on the order of weeks
[22:44] <lifeless> the roadmap is:
[22:44] <sinzui> bdmurray, maybe you can mark the bug as wont fix, or just note it will be fixed when edge is torn down in a few weeks
[22:44] <lifeless>  - get qastaging going [in progress with losa]
[22:45] <lifeless>  - disable edge deploys - start deploying just stable (to both the lpnet and edge servers)
[22:45] <bdmurray> that makes a fair amount of sense to me when I first looked at the bug I didn't realize the amount of work required
[22:45] <lifeless>  - disable the edge redirect
[22:45] <lifeless>  - make apache redirect edge urls to lpnet
[22:53] <bdmurray> does anybody see what's wrong in my commit message?
[22:53] <bdmurray> http://pastebin.ubuntu.com/504170/
[22:55] <lifeless> jam: https://bugs.edge.launchpad.net/loggerhead/+bug/653297 may interest you (or may not, I'm not sure if its something you've looked at)
[22:55] <_mup_> Bug #653297: http://bazaar.launchpad.net/%7Eindicator-applet-developers/libindicate/trunk/revision/382 errors <oops> <loggerhead:Triaged> <https://launchpad.net/bugs/653297>
[22:58] <sinzui> gary_poster, ping
[22:58] <gary_poster> sinzui, here, but running very soon
[22:59] <sinzui> gary_poster, do you have any immediate plans for Account and EmailAddress
[23:00] <gary_poster> sinzui: all plans are recorded in https://dev.launchpad.net/LEP/OpenIdRoadmap with associated (linked) bugs
[23:00] <jam> lifeless: I had not seen that before, offhand it looks like concurrent access to the structure, popping an item out while the other is accessing it.
[23:01] <sinzui> gary_poster, I think Foundations does not claim EmailAddress any more since full separation and I also think you have no interest in LoginToken because only the registry uses it to confirm (not login)
[23:01] <lifeless> jam: yeah, thats plausible
[23:01] <jam> anyway, end-of-week here
[23:01] <lifeless> ditto :)
[23:02] <gary_poster> sinzui: noone is working on these at this time, nor will they be in the next few weeks at least (and you can see that stuff ideally happens before EmailAddress/Account work, in the form of separating ShipIt)
[23:02] <gary_poster> does not claim...um...
[23:02] <sinzui> gary_poster, I want to move LoginToken and EmailAddress to lp.registry. I may do that with Account because I think it is being demoted to something smaller like an ssh key
[23:04] <sinzui> gary_poster, unless you say no right now, I am taking all three objects. your roadmap tells me you do not want them and are working to not have them
[23:05] <gary_poster> sinzui, we care about EmailAddress because of SSO integration; and we have some clean-up plans for it that you can see on that wiki page (e.g. bg 629172).  Other than that we don't care about it.  I don't care about LoginToken at all AFAIK.  If you are OK with our plans on the roadmap and with being very careful with the EmailAddress because of the SSO stuff, I'm happy for you to take them (and even appreciative)
[23:06] <gary_poster> May have been truncated: ...If you are OK with our plans on the roadmap and with being very careful with the EmailAddress because of the SSO stuff, I'm happy for you to take them (and even appreciative).
[23:06] <sinzui> my immediate goal it to get A and EM out of c.l so that I can make progress resolving circular imports
[23:07] <sinzui> I can move account somewhere else, I think I think in 6-12 months, you will be done and the models will be largely a registry concern
[23:08] <gary_poster> sinzui, I like that goal.  The SSO stuff is my only immediate concern, and I don't think that your change will affect it.  Maybe check with stub if you are not confident yourself.
[23:09] <sinzui> gary_poster, thank. I am not changing db. I just want the import lines in our code fixes
[23:09] <gary_poster> sinzui, great, thank you.  have a great weekend.
[23:12] <lifeless> sinzui: rev 11576 needs qa
[23:12] <lifeless> sinzui: you reviewed it, perhaps you can tell if its ok or not ?
[23:12] <lifeless>   [r=gmb][ui=salgado, sinzui][bug=439831, 489483,
[23:12] <lifeless>         629063] Add a font-family declaration for inline description editing
[23:13] <lifeless>         widgets which ensures consistency and uses the Ubuntu font if present.
[23:13]  * sinzui lookds
[23:13] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/435865 is the blocking bug I think
[23:13] <_mup_> Bug #435865: Use fixed-width fonts for bug summaries <Launchpad Bugs:Fix Committed by deryck> <https://launchpad.net/bugs/435865>
[23:13] <lifeless> according to https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[23:17] <lifeless> sinzui: thanks
[23:18] <lifeless> back after breakfast
[23:18] <sinzui> well that is a little easier than my negative tag search
[23:25] <sinzui> lifeless, does this report of fix committed without tags concern you: https://bugs.edge.launchpad.net/launchpad-project/+bugs?orderby=targetname&search=Search&field.status:list=FIXCOMMITTED&field.tag=-qa-ok+-qa-needstesting+-qa-untestable&field.tags_combinator=ALL
[23:25] <sinzui> I use it from time to time to check if we missed something
[23:28] <lifeless> that useful
[23:28] <lifeless> (not back, just picking upo a book for lynne)