[00:00] <lifeless> jelmer: test_fixup_expected_errors (subunit.tests.test_subunit_filter.TestTestResultFilter)
[00:00] <lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_expected_errors ... ok
[00:00] <lifeless> test_fixup_expected_failures (subunit.tests.test_subunit_filter.TestTestResultFilter)
[00:00] <jelmer> lifeless: thanks, I'll have a look
[00:00] <lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_expected_failures ... ok
[00:00] <lifeless> test_fixup_unexpected_success (subunit.tests.test_subunit_filter.TestTestResultFilter)
[00:00] <lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_unexpected_success ... ok
[00:00] <lifeless> jelmer: for me locally, but failed in the package build
[00:00] <lifeless> cool
[00:00] <lifeless> its probably shallow
[00:00] <mgz> yeah, those are the problems
[00:01] <mgz> see <https://code.launchpad.net/~lifeless/subunit/bug-654474/+merge/59627> jelmer
[00:01] <mgz> wth ubotu5.
[00:02] <mgz> lifeless: while I have you, can you update the milestone etc on bug 770519?
[00:05] <lifeless> dne
[00:06] <mgz> thx
[00:08]  * maxb removes bzr/daily's dependency on testing-cabal for now as a workaround
[00:08] <maxb> and on jelmer/daily since that also contains a subunit
[00:10] <jelmer> maxb: that's going to break all packages for old distroseries
[00:10] <maxb> oh?
[00:10] <jelmer> maxb: they need newer versions of subunit - that's why we have the dependency on testing-cabal
[00:11] <lifeless> maxb: mgz: better to fix bzr I think
[00:11] <maxb> There is a new enough but not too new version in bzr/ppa
[00:11] <lifeless> the subunit test failures are not the cause of whatever bzr's issue is
[00:11] <mgz> lifeless: I agree, would prefer if maxb left it borked so I knew if I'd fixed it
[00:12] <mgz> as I'm not certain yet if it's a bzr issue or a subunit one.
[00:12] <jelmer> maxb: what about the version of testtools?
[00:12] <mgz> ...or testtools
[00:12] <mgz> which could also be my fault!
[00:12] <maxb> I believe testtools should be adequately satisfied from bzr/ppa too
[00:12] <lifeless> maxb: so I suspect mgz is debugging now
[00:13] <jelmer> maxb: why does bzr/daily have a bzr/ppa dependency in the first place? It seems like that might risk bringing in dependencies
[00:13] <maxb> In any case, if there's stuff in your personal daily PPA that the bzr one depends on, it would be good to make that less ad-hoc
[00:13] <jelmer> agreed
[00:14] <maxb> bzr/daily has a dep on bzr/ppa precisely for things which we don't do daily builds of, but still need a recent release of
[00:14] <maxb> (IIUC, anyway)
[00:14] <jelmer> maxb: which ones?
[00:14] <maxb> testtools, subunit
[00:15] <jelmer> maxb: THat's why we have the dependency on testing-cabal
[00:15] <lifeless> but we do daily builds of them
[00:15] <lifeless> in ~testing-cabal
[00:15] <lifeless> so they don't match the 'dont do daily builds' part of your statement
[00:15] <maxb> "That ~bzr doesn't do daily builds of"
[00:16] <mgz> yup, I've got it repo'd
[00:21] <mgz> it is related to the two tests I knew about, not sure which rev where triggered the build failure but it's easy enough to fix the root cause
[00:22] <lifeless> what is the root cause
[00:22] <lifeless> maxb: is there any harm having testing-cabal as a dep
[00:22] <lifeless> maxb: it seems useful to me
[00:23] <maxb> I've got no problem with adding it back later, but right now I'm aiming to try to fix the sorry state bzr/daily is currently in, for which I need a bzr build which completes successfully
[00:23] <mgz> the test bt.per_workingtree.test_smart_add.TestSmartAddTreeUnicode.test_accessible_explicit has its expectFailure logic backwards
[00:29] <maxb> jelmer: Do you have unpushed revisions for bzr-buildddeb/unstable locally?
[00:30] <jelmer> maxb: you mean lp:bzr-builddeb?
[00:31] <maxb> oh, sorry, I was confused by the misleading presence of the alioth branch
[00:31] <maxb> also, ugh, the recipe is set to use {debupstream}+.... - which of course generates bogus versions when the changelog is UNRELEASED
[00:32] <jelmer> yeah, that should be ~bzr probably
[00:33] <mgz> gra, testtools still doesn't make debugging this easy, it loses the matcher output
[00:33] <lifeless> mgz: it doesn't attach it?
[00:35] <maxb> I'll set the recipe to use 2.7.4+bzr... (literally) for now. that will ensure we don't need to fix it in sync with pushing the next changelog entry
[00:35] <mgz> nope, never even formats the exception.
[00:41] <maxb> jelmer: Hi. I see you have a Build-Depends of bzr (<< 2.4.0~beta1-2) | python-bzrlib.tests in bzr-cvsps-import - unfortunately LP's sbuild is too stupid to resolve that - it only tries to install the first alternative
[00:42] <maxb> Can you see any downside to swapping them around?
[00:44] <jelmer> maxb: Yeah, I'm working on swapping them right now
[00:44] <jelmer> seger pinged me about it earlier
[00:44] <jelmer> I have a test build running atm
[00:44] <mgz> maxb: okay, I have a fix for you.
[00:45] <maxb> jelmer: ok. Might be worth making it bzr (<< 2.4.0~beta1-2~) whilst you do (trailing ~)
[00:45] <jelmer> maxb: to what point?
[00:46] <maxb> So the condition applies as intended to any backports that exist (like the bzr PPA ones)
[00:47] <jelmer> that doesn't seem like a particularly worthwile revision to backport (a beta release?)?
[00:48] <maxb> Not particularly important, no. Just a thought given they need editing anyway
[00:49] <jelmer> maxb: There was a merge request for the addition of python-bzrlib.tests to debian/control of bzr-builddeb
[00:50] <jelmer> james_w`: What's the exact policy on reviews for lp:bzr-builddeb?
[00:53] <maxb> oh, sorry. I was in the "Packaging branch, no launchpad, exercise good judgement" mentality
[04:41] <AuroraBorealis> so, is this the place we ask about bzr explorer questions?
[04:55] <bignose> AuroraBorealis: yes, go for it. (I'm not someone who knows though, so can't asnwer.)
[04:55] <AuroraBorealis> for some reason on windows bazaar explorer wont connect to my ftp server anymore.
[04:55] <AuroraBorealis> it just sits there on 'starting' and freezes
[05:25] <poolie> hi spiv, all
[05:30] <spiv> Hi poolie
[05:30] <spiv> How's the springy side of the planet?
[05:30]  * fullermd jumps up and down a bit to check which side he's on...
[06:20] <poolie> nice thanks
[06:32] <james_w`> jelmer, trivial -> no review, everything else -> one review, unless you explicitly want more
[06:45] <maxb> james_w`: and, who constitutes a valid reviewer?
[07:05] <james_w`> maxb, anyone on the bzr team, myself and people like you who know something about it
[07:09] <poolie_droid> hi vila
[07:14] <poolie_droid> thanks for that mail to linaro John
[07:26] <vila> hi droid :)
[07:30]  * vila bbl
[08:08] <vila> So I said, 'Horse?  That looks more like a peanut to me!
[08:12]  * fullermd applauds.
[08:36]  * vila giggles
[09:20] <vila> fullermd: ViewSourceWith tracks the tmp file ! I thought I had to quit my editor but I only need to save... There is a small lag but I'm already getting used to it, this rocks ;)
[09:21] <fullermd> Yeah, it's Pretty Durn Shiny(tm).
[09:27] <vila> . o O (Funny that *I* was pushed to use my favorite editor even more ...)
[09:28]  * vila grins 
[09:40] <fullermd> Hey, I told you how to set it up to use a good editor instead...  ;p
[09:40] <poolie> vila, what's ViewSourceWith?
[09:41] <vila> poolie: a firefox extension that allows you to use your favorite editor for text fields
[09:41] <fullermd> Firefox extension to let you use $EDITOR_OF_CHOICE for, among other things, View Source and <textarea>'s.
[09:41] <vila> poolie: perfect fit for reviews
[09:42] <vila> poolie: most notably because you can still scrolll the page to view the diff and copy/paste excerpts
[09:43] <poolie> oh right
[10:03] <vila> rhaaa, don't we have some option listing the warnings one want to ignore ? I can't remember :-/
[10:05] <vila> ha ! suppress_warnings
[10:36] <vila> jelmer: hmm, trying to rebuild the OSX-10.5 installer, I got a compile error in subvertpy (tip) in wc.c about svn_wc_conflict_choice_t being undeclared... rings a bell ? want a bug ?
[10:36] <vila> jelmer: telling me that I need some recent svn version will only make me cry
[10:39] <poolie> vila i kind of wonder if these WIP mps will be lost
[10:40] <vila> which ones ?
[10:41] <vila> poolie: anyway, PP should switch to https://code.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1 when https://code.launchpad.net/bzr/+activereviews  is back under control no ?https://code.launchpad.net/bzr/+activereviews
[10:42] <vila> which is what we say on http://wiki.bazaar.canonical.com/PatchPilot/
[10:42] <poolie> for instance the one from Joke
[10:42] <poolie> just an observation that many of them seem to get lost there
[10:43] <vila> poolie: if I get feedback I'll finish this one
[10:43] <vila> poolie: if I don't, well, it's not active anymore ;)
[13:34] <maxb> jelmer: Hi. Do you want any help adjusting the rest of the python-bzrlib.tests Build-Depends, or would you rather do each one as you upload?
[13:46] <AfC> Why would upgrade to Natty be forcing me to remove bzr-git ?
[14:03] <vila> AfC: Because you installed it from something else than the official repos ?
[14:04] <vila> AfC: in which case you can just re-install it after the upgrade (after re-activating whatever repos you added)
[14:05] <jelmer> maxb: No, thanks; I doubt it would save much time as I have to process each package anyway.
[14:06] <vila> naughty naughty loom bug... An AttributeError caused by a missing import and wrongly interpreted higher in the stack as meaning: this is not a loom...
[14:07] <vila> bzrlib.merge.anything syntax is Evil
[14:07] <AfC> vila: oh, right
[14:07] <AfC> I hate how Ubuntu keeps deactivating your PPA list.
[14:07]  * vila nods
[14:09] <vila> AfC: but there may be another reason than just that, Ubuntu is pretty "good" at keeping packages so maybe some other dependency triggered that
[14:09] <vila> python version, whatever
[14:09] <AfC> We'll see
[14:36] <vila> loom devs: I'd like to land https://code.launchpad.net/~vila/bzr-loom/tweaks/+merge/60185
[14:36] <vila> lifeless, jelmer, whoever: ^
[14:39] <vila> had I filed a bug I would have set it to Critical, but the fix is so trivial I can't bother
[14:39] <vila> ... and I don't think it's worth searching why it occurred
[14:40] <vila> if that doesn't wet your appetite I don't what will :)
[15:19] <jelmer> vila: sorry, missed that earlier. Approved
[15:19] <vila> done
[15:20] <vila> jelmer: keep crawling the history back ;)
[15:20] <vila> jelmer: hmm, trying to rebuild the OSX-10.5 installer, I got a compile error in subvertpy (tip) in wc.c about svn_wc_conflict_choice_t being undeclared... rings a bell ? want a bug ?
[15:20] <vila> jelmer: telling me that I need some recent svn version will only make me cry
[15:20] <jelmer> well, either you need a new version of svn or we need to fix a bug in subvertpy..
[15:20] <jelmer> can you pastebin the traceback?
[15:21] <vila> jelmer: *compile* error
[15:21] <vila> err, C compilation error
[15:21] <jelmer> uhm, sorry :0
[15:21] <vila> ;)
[15:21] <jelmer> Can you pastebin the compile error, mr pedantic ? :-P
[15:22] <vila> isn't subertpy implemented from scratch ?
[15:22] <vila> hehe
[15:22] <vila> justasec, different host
[15:22] <vila> (and no copy/paste linked to *this* one)
[15:23] <vila> !paste
[15:24] <vila> http://paste.ubuntu.com/604104/
[15:25] <jelmer> thanks
[15:31] <vila> jelmer: is it just a matter of ONLY_SINCE_SVN(1, 5) or something more elaborate ?
[15:32] <jelmer> vila: probably
[15:32] <jelmer> looking at it now
[15:34] <vila> ok, thanks
[15:46] <jelmer> vila: sorry, had to install libsvn-dev
[15:47] <jelmer> vila: what svn are you using, 1.5?
[15:47] <vila> jelmer: no idea, it's the default one coming with OSX 10.5 AFAIK
[15:48] <vila> 'svn help' says 1.4.4
[15:48] <jelmer> vila: that's really too old for a decent bzr-svn experience..
[15:49] <vila> jelmer: tsk tsk, I'm not an OSX 10.5 user, only an installer builder ;)
[15:51] <vila> jelmer: I mean, bzr-svn has been packaged so far and nobody complained, I think there is at least one bug about how hard it is to upgrade svn there and if we should drop it completely, let's do that. But if there is a simple way to keep supporting it for a few more months...
[15:51] <jelmer> hmm, ok
[15:51] <vila> We'll drop OS 10.5 support all at once at some point (10.7 is around the corner)
[15:51] <vila> let me check what is the default on 10.6
[15:51] <jelmer> I'm happy to fix this build issue for subvertpy, but svn 1.4 has much much worse performance for bzr-svn
[15:53] <vila> right, I have no doubt about that ;)
[15:53] <vila> err, both points !
[15:53] <vila> bah
[15:53] <vila> 1) thanks for fixing it, 2) no doubt about the perfs
[15:55] <vila> svn 1.6.15 on OSX 10.6
[15:58] <vila> jelmer: so, IIUC, subvertpy wraps libsvn and as such depends on it for providing features. Does that mean some features will not be available on OSX 10.5 or only that they will be slower ?
[15:58] <jelmer> vila: some features in subvertpy won't be available, but bzr-svn works around that by using slower code paths
[15:59] <jelmer> and in some cases subvertpy provides the extra functionality if it can
[15:59] <vila> jelmer: wft (t == them ;) then
[15:59] <jelmer> :)
[16:03] <jelmer> vila: pushed a fix, can you try with current trunk?
[16:04] <vila> huh, no revisions to pull
[16:04] <vila> revno 2333
[16:08] <vila> jelmer: ^
[16:08] <jelmer> vila: I think lp:subvertpy is a mirror, try http://people.samba.org/bzr/jelmer/subvertpy/trunk/
[16:11] <vila> damn cached parent_location
[16:17] <vila> jelmer: that fixes the first compilation error
[16:17] <vila> err, not even wait
[16:19] <vila> hmpf
[16:25] <vila> jelmer: http://paste.ubuntu.com/604131/
[16:25] <vila> jelmer: i.e. one typo and a different error
[16:26] <vila> ha, shooting in the dark sometimes works :)
[16:26] <vila> s/2/3/
[16:26] <jelmer> vila: fixed
[16:29] <vila> yup, I trust your fix more :) Using svn_wc_resolved_conflict3 (instead of 2) was compiling too but was probably not producing the right code ;)
[16:29] <vila> and it compiles fine
[16:30] <vila> jelmer: thanks
[16:30] <jelmer> vila: according to the header _conflict3 is only available in svn >= 1.5
[16:31] <vila> ...
[17:55] <pindonga> hi, I was wondering.. I want to modify the lp-propose command to include some extra options... what is the best way to approach this for inclusion? shall I just submit an MP, or should I first discuss with someone if the changes will ever be approved first?
[18:09] <vila> pindonga: MP is best, even to *start* a discussion, IRC logs are << MPs threads
[18:09] <vila> pindonga: I'm not saying you should create a MP with no patch at all either ;)
[18:14] <pindonga> vila, no, sure, I have the mp almost ready
[18:14] <pindonga> but no tests yet :)
[18:14] <pindonga> I'll submit it later, and let you know
[18:14] <vila> pindonga: ha, not TDD-addict yet :)
[19:11] <maxb> jelmer: When you touch bzr-colo for the Build-Depends fix, it looks like it's erroneously Architecture: any as well
[19:30] <maxb> Hmm, oneiric's python-subunit is broken, it's built only for python 2.7, not all supported versions
[19:54] <pindonga> vila, sorry to bother, I'm trying to find out where the tests are for the launchpad plugin
[23:16] <cbz> jelmer: just sent in a bug report https://bugs.launchpad.net/bzr-svn/+bug/778793