[00:20] <poolie> spm, there's some russian spam in https://answers.edge.launchpad.net/launchpad-code/+question/13796
[00:20] <poolie> i guess i should file a question?
[00:23] <spm> poolie: questions, even more so than bugs; yes. that's a hand  crafted sql task.
[00:24] <poolie> https://answers.edge.launchpad.net/launchpad/+question/111646 fwiw
[06:13] <cody-somerville> "This change is completely inert when not using XYZ" doesn't sound quite right at this hour. I have a feeling I'm actually looking to use a different, more appropriate word but can't think of it at the moment.
[06:14] <lifeless> A better word than is? Try etre.
[06:14] <cody-somerville> lol
[06:14] <cody-somerville> lifeless, was referring to 'inert'. :P
[06:16] <lifeless> You have a double negative
[06:16] <lifeless> I suggest a single positive.
[06:16] <cody-somerville> plus, etre is the verb 'to be'. I think you meant to recommend 'est'. :P
[06:16] <lifeless> "This change only takes effect when using XYZ."
[06:17] <lifeless> same word :)
[06:17] <lifeless> you need more practice at conjugation ;)
[06:17] <cody-somerville> conjug...
[06:18]  * cody-somerville was going to say conjugation is important :P
[06:18] <lifeless> http://www.wordreference.com/conj/FRverbs.asp?v=etre
[06:20]  * cody-somerville doesn't dispute his French could use a lot of work in many areas.
[06:20] <cody-somerville> lifeless, anyhow, thanks. :)
[06:20] <lifeless> de nada
[08:15] <adeuring> good morning
[08:20] <spm> noodles775: ta. I'm often not quite sure which sub group a bug belongs to; when it doubt, let you lot figure it out. :-)
[08:20] <noodles775> spm: no probs.
[08:58] <mrevell> Morning
[10:17] <lifeless> can Storm handle sets ? We have a comment about SQLObject failing on them in sqlbase.py
[10:17] <lifeless> and a workaround we could proably delete now
[11:01] <deryck> Morning, all.
[13:22] <deryck> BjornT, ping
[13:40] <BjornT> hi deryck
[13:41] <deryck> BjornT, hi.  I'm starting work on bug 418659 and you have some comments there about your previous work on this...
[13:41] <mup> Bug #418659: Reporting duplicate bugs leads to receiving notifications for every duplicate of the original bug <ubuntu-qa> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/418659>
[13:41] <deryck> BjornT, and I'm looking at your work in:  https://code.edge.launchpad.net/~bjornt/launchpad/bug-46237/+merge/8886
[13:42] <deryck> And I wonder if I'm reading your intent right....
[13:42] <deryck> BjornT, was your work to ensure that Bug A subscribers are *not* notified when Bug B is marked a dupe?  Or that Only Bug A subscribers are notified when Bug C is marked a dupe and Bug B subscribers via dupe are not notified about bug C?
[13:43] <deryck> if that makes sense :-)
[13:44] <BjornT> deryck: i think some clarification is needed :) in my example Bug B was the master bug
[13:46] <BjornT> deryck: might be easier if we take real example, e.g. bug 46237, which has a few duplicates
[13:46] <mup> Bug #46237: fine-tune delivery of duplicate notification mails <email> <Launchpad Bugs:Fix Released by bjornt> <https://launchpad.net/bugs/46237>
[13:46] <deryck> yeah, good idea.
[13:47] <deryck> BjornT, So when Bug #91212 was marked a dupe of that bug, should direct subscribers to bug 46237 be notified of this?
[13:47] <mup> Bug #91212: people subscribed to bugs that are duplicates shouldn't receive notifications of new duplicates to the master bug <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/91212>
[13:47] <mup> Bug #46237: fine-tune delivery of duplicate notification mails <email> <Launchpad Bugs:Fix Released by bjornt> <https://launchpad.net/bugs/46237>
[13:48] <BjornT> deryck: no. only the ones that are subscribed to bug #91212 should be notified about it.
[13:48] <mup> Bug #91212: people subscribed to bugs that are duplicates shouldn't receive notifications of new duplicates to the master bug <email> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/91212>
[13:49] <deryck> BjornT, ok.  Which should cover the second case of subscribers to 91212 being notified when the master add yet another bug marked as a dupe of it.  right?
[13:49] <deryck> s/add/had/
[13:50] <BjornT> deryck: right
[13:50] <deryck> BjornT, and people were generally in agreement that direct subscribers on the master do not want to know via email about dupes being added?
[13:54] <mars> sinzui, rockstar, is one of you working on the broken build?
[13:55] <sinzui> mars, I am trying to understand it
[13:55] <mars> ok.  Thanks sinzui.
[13:56] <BjornT> deryck: yes. they said that even though it's somewhat useful to get notified for the developers, decreasing the number of e-mails sent was more important.
[13:56] <deryck> BjornT, right, that makes sense, given the two choices.
[13:56] <deryck> BjornT, and the only test for this is in test_bugchanges.py?
[13:57] <BjornT> deryck: i think so, yes
[13:57] <deryck> BjornT, ok, great, thanks for helping me understand.
[14:09] <sinzui> mars, is the build really broken? I think my pre-emptive fix was not really run until gary restarted it?
[14:11] <mars> sinzui, I assume you can not reproduce this locally?  If you suspect is not broken, maybe you can throw a null [testfix] in there and see if it breaks again?
[14:11] <sinzui> mars, to force a build to see if the failure was spurious or real?
[14:12] <mars> sinzui, that of course assumes that a null testfix will force a full suite re-run without adding changes from the queue - I don't know if that is the case.
[14:12] <mars> sinzui, yes, to force a rebuild
[14:12] <sinzui> I can always reformat a test :)
[14:12] <mars> BjornT, ^ will that work?
[14:13]  * mars is still learning about the pqm part of the build system
[14:15] <BjornT> mars: i'm not sure what the question is :)
[14:17] <mars> BjornT, sinzui suspects the failure is suprious.  Can he submit an empty [testfix] to PQM to have it clear the flag and force a rebuild of just his and Paul's changes?
[14:17] <BjornT> sinzui: which failure?
[14:18] <BjornT> mars: ^^^
[14:19] <sinzui> faq-views in failed devel (ran on the wrong layer). I did a preemptive fix, while it was building
[14:19] <jelmer> jml: whoops, didn't mean to make you angry!
[14:19] <BjornT> sinzui: right. and that fixed it, no?
[14:19] <jml> jelmer: only blogging-angry
[14:19] <jelmer> jml: is that a good kind of angry?
[14:19] <jml> jelmer: it's the kind of angry that hurts no-one except my keyboard and maybe some people's bandwidth
[14:20] <sinzui> BjornT, but it was (reported) failed again  when gary forced it to restart. it is not clear if by forcing to to restart, my fix was in it so we saw a second failure?
[14:20] <jelmer> jml: ah, good
[14:21] <mars> sinzui, BjornT, fwiw, I was just looking for the "kick it again and see" answer here :)
[14:21] <mars> sinzui, BjornT, I just don't know the right way to give the test system said kick
[14:22] <BjornT> sinzui: if you look at build 900, you see that it's testing up to r10892. your fix was r10895. as far as i can see, buildbot is all green.
[14:22] <BjornT> mars: why kick it? the last build succeeded
[14:22] <sinzui> BjornT, thanks for seeing that! mars, I think db-devel has already played the test
[14:24] <mars> BjornT, ah, ok.  So I was confused because it got fixed without any mail to the list saying "Everything is good again".
[14:24] <mars> So I said "Oh, it must be broken"
[14:30] <BjornT> mars: yeah, we should teach people to always reply to build failures, so that others don't waste time trying to fix something that has already been fixed
[20:27] <bac> hi matsubara
[20:27] <matsubara> bac, hi
[20:27] <bac> matsubara: i'm getting the message rejection email when i submit a MP even though i am subscribed to launchpad-bugs.  does mesh with your understanding of the problem?
[20:32] <matsubara> bac, I'm looking at the subscribers list and your email is parenthesized which means: Parenthesized entries have list delivery disabled.
[20:32] <matsubara> maybe that's the reason?
[20:32] <bac> no
[20:32] <bac> i just talked to barry and he said i should be able to post still
[20:32] <bac> matsubara: i think the problem is canonical-ubuntu-platform is subscribed to devel
[20:32] <matsubara> I'm not even sure if the hypothesis is true anymore, since ~launchpad is configured to not receive any email from devel
[20:33] <matsubara> bac, but then email to that team would go to: mdz-ubuntuplatform@alcor.net
[20:33] <matsubara> s/email/emails/
[20:34] <bac> matsubara: ok, so maybe that's not it
[20:34] <bac> matsubara: but launchpad-bugs is not the culprit, i don't think
[20:34] <bac> it's really annoying
[20:35] <matsubara> bac, AFAICT, there can be only one team in LP using the launchpad-bugs@lists.ubuntu.com email address
[20:35] <matsubara> and that's ~launchpad
[20:35] <bac> matsubara: right but we don't really know that list is the culprit
[20:35] <matsubara> hmmm, unless we have another team with launchpad-bugs@lists.canonical.com
[20:35] <bac> matsubara: and that list has been the contact email forever
[21:11] <mwhudson> morning
[21:17] <thumper> morning
[21:22] <jelmer_> 'moin mwhudson, thumper
[21:22] <thumper> hi jelmer_
[21:23] <thumper> I saw in passing last night that you had tweaked dulwich
[21:25] <thumper> jelmer_: I can't seem to reproduce the original failure locally :(
[21:26] <jelmer_> Things that involve reference loops and the garbage collector never seem to be predictable :-/
[21:31]  * thumper does school run
[21:44] <mars> abentley, still online?
[21:44] <abentley> mars, sure.
[21:44] <mars> abentley, have a moment to look at that test suite problem you encountered?
[21:45] <abentley> mars, OTP
[21:45] <mars> abentley, ok, whenever you have a moment then