Based on the discussion on IRC, it was found that the bzrlib.branchbuilder doctest was passing on systems that have whoami set. and failing where whoami was not set. Keeping this behavior the same is probably a good idea as (1) it will help discover if any test setup has no whoami. (2) a good fix would be using the same env for doctest as well as unittest (as mentioned in bug #321320).
So this is being marked as tech-debt with the suggestion that we should go for (2) rather than handle this specific case.
IRC Log:
<a212901390231901> what's the fallout from the nodefault whoami? I meant to review the change but didn't find the time.
* parthm starts reading bug #321320
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
<a212901390231901> ah, got the the pastebin link in the log
I'll see if I get it here
-->| vds (~<email address hidden>) has joined #bzr
<vila> parthm: found it, I'm sure you will appreciate the irony there: comment out your 'email' entry in .bazaar.conf
-->| e-jat (~fenris@ubuntu/member/fenris-) has joined #bzr
|<-- ejat has left freenode (Ping timeout: 240 seconds)
<parthm> vila: hmm. weird http://dpaste.com/191454/
* parthm checks if he has some other email set.
<parthm> vila: yup.
<a212901390231901> passes here too.
pretty sure I don't have any email or config stuff in the test account
<parthm> vila: reproduced it with EMAIL=<blank> and commented out email in bazaar.conf. phew! :)
<vila> a212901390231901: what does 'bzr whoami' says ?
say even
<parthm> vila: thanks for finding this.
<vila> parthm: so, summary: people without whoami set will see a failure
I think it's a good thing in fact :)
<parthm> vila: yes. :)
<vila> after all, your fix is about helping people falling into this trap, so...
<parthm> vila: heh :)
<vila> parthm: thank you for helping me finding out a hole in my slave setups :-D
<a212901390231901> okay, nope, does fail indeed
<parthm> vila: ooh :) ... yes. thats what this shows :)
-->| guilhembi (~<email address hidden>) has joined #bzr
<parthm> vila: so the interesting question is what do we do about this. we could setup EMAIL for the doctest. or we could let this be as a failsafe.
vila: ideally doctests should use the same env as other tests as mentioned in bug #321320 that you linked to this report.
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
<vila> failsafe sounds ok, I still have to understand while the tests *succeeded* in some slaves
parthm: that sounds right (even if it will *remove* the failsafe here)
<parthm> vila: if we keep these two setups separate eventually something else will be different and tests will behave weird.
vila: we can keep this as a tech-debt ticket. would you like to put a comment in or should i?
<vila> parthm: go ahead
parthm: you can also look at creating the papercut tag, I'm surprised you can't use it
Based on the discussion on IRC, it was found that the bzrlib. branchbuilder doctest was passing on systems that have whoami set. and failing where whoami was not set. Keeping this behavior the same is probably a good idea as (1) it will help discover if any test setup has no whoami. (2) a good fix would be using the same env for doctest as well as unittest (as mentioned in bug #321320).
So this is being marked as tech-debt with the suggestion that we should go for (2) rather than handle this specific case.
IRC Log:
<a212901390231901> what's the fallout from the nodefault whoami? I meant to review the change but didn't find the time. /launchpad. net/bugs/ 321320 ubuntu/ member/ fenris- ) has joined #bzr dpaste. com/191454/ /launchpad. net/bugs/ 321320
* parthm starts reading bug #321320
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https:/
<a212901390231901> ah, got the the pastebin link in the log
I'll see if I get it here
-->| vds (~<email address hidden>) has joined #bzr
<vila> parthm: found it, I'm sure you will appreciate the irony there: comment out your 'email' entry in .bazaar.conf
-->| e-jat (~fenris@
|<-- ejat has left freenode (Ping timeout: 240 seconds)
<parthm> vila: hmm. weird http://
* parthm checks if he has some other email set.
<parthm> vila: yup.
<a212901390231901> passes here too.
pretty sure I don't have any email or config stuff in the test account
<parthm> vila: reproduced it with EMAIL=<blank> and commented out email in bazaar.conf. phew! :)
<vila> a212901390231901: what does 'bzr whoami' says ?
say even
<parthm> vila: thanks for finding this.
<vila> parthm: so, summary: people without whoami set will see a failure
I think it's a good thing in fact :)
<parthm> vila: yes. :)
<vila> after all, your fix is about helping people falling into this trap, so...
<parthm> vila: heh :)
<vila> parthm: thank you for helping me finding out a hole in my slave setups :-D
<a212901390231901> okay, nope, does fail indeed
<parthm> vila: ooh :) ... yes. thats what this shows :)
-->| guilhembi (~<email address hidden>) has joined #bzr
<parthm> vila: so the interesting question is what do we do about this. we could setup EMAIL for the doctest. or we could let this be as a failsafe.
vila: ideally doctests should use the same env as other tests as mentioned in bug #321320 that you linked to this report.
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https:/
<vila> failsafe sounds ok, I still have to understand while the tests *succeeded* in some slaves
parthm: that sounds right (even if it will *remove* the failsafe here)
<parthm> vila: if we keep these two setups separate eventually something else will be different and tests will behave weird.
vila: we can keep this as a tech-debt ticket. would you like to put a comment in or should i?
<vila> parthm: go ahead
parthm: you can also look at creating the papercut tag, I'm surprised you can't use it