[07:34] <vila> hello all !
[07:40] <poolie> hello vila
[07:40] <vila> poolie: hi there !
[07:40] <vila> poolie, spiv: Regarding the doc-new-config mp, thanks for the feedback !
[07:40] <poolie> hi there
[07:41] <poolie> thanks for posting it; sorry for the delay
[07:42] <vila> I don't think it's ready to land in trunk, devnotes sounds more like it, but even there, I think more work is needed before landing, so I will reply to the points raised and put it in wip
[07:42] <poolie> well, i think you should merge it to devnotes then
[07:42] <poolie> there doesn't have to be any guarantee that files in that tree are finished or agreed-upon
[07:43] <poolie> and it makes them visible and shareable
[07:43] <poolie> (more so than being in just a random wip branch)
[07:44] <vila> good point, I'll do that then
[07:48] <MTecknology> So... somebody just asked me "How do I do bzr?"
[07:49] <MTecknology> any link?
[07:49] <vila> MTecknology: http://doc.bazaar.canonical.com/en/ ?
[07:49] <vila> MTecknology: http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html ?
[07:50] <MTecknology> thanks :)
[07:50] <poolie> vila, so on the sru
[07:50] <vila> poolie: So, as maxb raised, on step forward two steps backwards for the Mricro Release Exception, we need testtools included in the main archive to be able to run the tests as part of the build
[07:51] <vila> poolie: as you pointed out in your reply, this means running the tests externally
[07:51] <vila> poolie: and making sure testtools is part of main for natty
[07:53] <vila> poolie: jml said he doesn't care whether python-testtools is part of main or universe, I've started looking at what is needed to get it in main (hopefully not much)
[07:53] <vila> https://wiki.ubuntu.com/MainInclusionProcess is the relevant page AIUI
[07:55] <poolie> ok
[07:55] <vila>  From https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, I think this shouldn't cause any problems
[07:55] <poolie> meant to do it today; didn't
[07:55] <vila> ?
[07:55] <vila> *I* meant to do it Friday but couldn't finish ;)
[07:56] <vila> well, I didn't get farer than reading the above pages really
[07:59] <lifeless> vila: farther
[08:01] <vila> lifeless: haaaa, but of course !
[08:01] <poolie> *further*
[08:02] <poolie> or not?
[08:02] <vila> meh
[08:02] <poolie> apparently yes, but only barely: http://englishplus.com/grammar/00000213.htm
[08:03] <vila> I meant: I've started, there is more to do, but I lacked time to continue
[08:04] <poolie> right, that's what i understood :)
[08:05] <vila> so literally I think it's farther, but the English usage is probably further, thanks to both of you anyway ;)
[08:05] <spm> "farer" that's perfect! it even makes sense following the insane rules of english.
[08:05] <poolie> i think i'll just send a brief note to tb and see what they say
[08:06] <vila> poolie: ok, can you CC me ?
[08:08] <poolie> i will
[08:09] <lifeless> poolie: heh, whoops.
[08:09] <lifeless> poolie: I've finally logged into netbank and wired you that stuff
[08:11] <poolie> thanks
[08:19] <poolie> vila, maxb: just so i don't embarrass myself, it is correct that the test suite is now clean both during a build and from the installed package
[08:19] <poolie> in 2.2.2
[08:19] <vila> I haven't checked recently, but that's my understanding
[08:20] <vila> If that's not the case, it should be fixed
[08:55] <poolie> vila: sent; we'll see
[08:56] <vila> ok
[08:58] <vila> poolie: maverick slave upgraded to 2.2.2, running the test suite there to confirm
[09:05] <poolie> ok, good night vila
[09:06] <vila> hehe, good night to you ;)
[09:10] <lifeless> poolie: http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
[09:13] <poolie> nice
[09:13] <poolie> "Google.... decided the best way to make forward progress was to just turn it on and see whether the internet actually melts down or not"
[09:13] <poolie> :)
[09:16] <fullermd> Which do they consider success?   :p
[15:22] <vila> jelmer: ping
[15:23] <jelmer> vila: hey
[15:24] <vila> jelmer: I tried to upgrade lp:~bzr-core/bzr/devnotes which is still in format knitpack6 (bzr 1.9) but it failed because it's still stacked on the old trunk
[15:24] <vila> there is now a backup.bzr.~1~ there with the previous content
[15:25] <vila> jelmer: is there a way for me to either restore that and re-stack on the new trunk and upgrade or do I need someone powerful hand behind the scenes ?
[15:26] <jelmer> vila: It should be possible to use hitchhiker to move the old backup directory and manually fix the stacked-on branch using hitchhiker as well
[15:27] <vila> jelmer: ha right, made a typo with lftp
[15:28] <vila> and got a misleading Access failed: Permission denied: "Cannot create '.bzr-broken'. Only Bazaar branches are allowed.
[15:29] <jelmer> there are particular file names that are allowed
[15:29] <jelmer> I think backup.bzr* is allowed
[15:29] <jelmer> as well as .bzr
[15:30] <vila> yeah, the typo was backup.bzr~2~ instead of backup.bzr.~2~ after .bzr-broken was refused
[15:30] <vila> so the last period is mandatory
[15:49] <vila> jelmer: I had to upload a locally patched branch.conf to update the stacked-on repo :-/ After the upgrade failed successfully 8-/
[15:49] <jelmer> vila: \o/
[15:49] <jelmer> vila: This is too hard for somebody not familiar with the internals though :-/
[15:50] <vila> jelmer: yeah, filing a bug asking for --stacked-on parameter for upgrade
[15:50] <vila> jelmer: exactly my point
[16:28] <jam> morning vila and jelmer
[16:28] <vila> hey jam 1
[16:28] <vila> how was the turkey ?
[16:28] <jam> pretty good
[16:28] <jelmer> hey John
[16:28] <jam> fun to be around my family
[16:35] <maxb> jelmer: hey. Got a moment to talk about how to run tests on a buildd and the 2.2.2 SRU?
[16:35] <jelmer> maxb: sure
[16:35] <maxb> The thing is, the 2.2.2 SRU as is doesn't pass the tests
[16:35] <maxb> The problem is the tests in 2.2 fail if they are run in a directory containing setup.py and run as root
[16:35] <jelmer> maxb: I don't think we should be introducing the change to run the tests in a SRU
[16:35] <vila> maxb: which ones ?
[16:36] <jelmer> maxb: I fixed the setup.py test a week or two ago in bzr.dev.
[16:36] <maxb> The one which tests 'setup.py install', and tries to write to /usr/share/apport/
[16:36] <maxb> This is not a problem in bzr.dev because I ripped out the apport installation from setup.py there with poolie's blessing
[16:37] <jelmer> maxb: Why did you remove the apport installation?
[16:38] <maxb> I can dig up the MP, but the summary is "This is never the right thing to do - configuring apport is something for distros to do."
[16:38] <vila> maxb: I think this test should be skipped if run by root, sounds far too dangerous anyway
[16:39] <maxb> https://code.launchpad.net/~maxb/bzr/no-install-apport/+merge/38463
[16:39] <jelmer> maxb: Ah, ok. That's a reasonable approach (though it'd mean we'd have to patch bzr in Ubuntu)
[16:39] <maxb> vila: To be honest, I'm rather confused why this test is considered valuable at all
[16:40] <jelmer> maxb: Making sure that "setup.py install" works seems like a nice thing, it's broken in the past.
[16:40] <vila> maxb: catching up regressions
[16:40] <maxb> jelmer: The interesting fact to note is that the old apport installation code does *not* install the apport hooks in the bzr ubuntu package :-)
[16:40] <jelmer> maxb: https://code.launchpad.net/~jelmer/bzr/setup.py-root/+merge/40067
[16:40] <maxb> Oh, I get it now, you want to catch setup.py install failures in PQM
[16:40] <vila> maxb: which is why eager tests are bad :(
[16:40] <jelmer> maxb: But I guess that's been obsoleted by your change.
[16:42] <vila> maxb: I ran http://babune.ladeuil.net:24842/job/selftest-maverick/ this morning, but not as root, is it the only test failing ?
[16:42] <maxb> --root is more technically correct anyway
[16:42] <maxb> vila: checking for my ppa build log...
[16:43] <vila> meh, wrong url, the correct one is: http://babune.ladeuil.net:24842/job/selftest-maverick-proposed/
[16:43] <maxb> https://code.launchpad.net/~maxb/+archive/ppa/+build/2064150
[16:43] <vila> maxb: so I used the bzr from the bzr/proposed ppa
[16:43] <maxb> That buildlog shows just the one failure
[16:44] <maxb> Oh, you are testing the run-tests-when-installed part of the puzzle, I am focussing on the run-tests-on-buildd part of the puzzle
[16:45] <vila> maxb: yes
[16:46] <vila> maxb: my understanding was that we couldn't use python-testtools during the build so I reverted to the manual check
[16:47] <vila> oh, so you activate the tests in your private ppa (was wondering where I got my bzr-2.2.2 suddenly ;)
[16:54] <maxb> vila: I'm testing in ~maxb because ~bzr has a newer testtools than the primary archive, so wouldn't be a realistic test
[16:56] <maxb> Also, I am running the tests in ~bzr, but with some tweaks to how they are invoked in debian/rules, which I haven't managed to convince jelmer of the rightness of for Debian&Ubuntu yet.
[19:44] <bzr> Hi--I'm having some trouble with pushing from bzr explorer.  Is this the right place to be?
[19:58] <bzr> Is anyone here?
[20:06] <jelmer> bzr: hi
[20:06] <bzr> Hi!
[20:06] <jelmer> bzr: I'm afraid I don't really have much experience with bzr-explorer. What's the problem?
[20:06] <bzr> I seem to have set my username wrong--I'm George from that tricky bzr push bug.
[20:07] <bzr> When I try to push, I get:
[20:07] <bzr> Run command: bzr push
[20:07] <bzr> Using saved push location: https://george@nanotech.com@pl3.projectlocker.com/nano/www/svn
[20:07] <bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
[20:07] <bzr> (The bug was https://bugs.launchpad.net/bzr/+bug/681285?comments=all)
[20:08] <jelmer> bzr: you're using bzr-svn trunk?
[20:08] <bzr> I think so.
[20:09] <bzr> Is that:
[20:09] <bzr> svn 1.0.3
[20:09] <jelmer> your copy of subvertpy was linked against an old version of libsvn
[20:09] <bzr>    Support for Subversion branches
[20:09] <bzr>    /Library/Python/2.5/site-packages/bzrlib/plugins/svn
[20:09] <bzr> How do I fix that?
[20:09] <bzr> I tried rebuilding bzr using MacPorts, but that didn't work at all...
[20:09] <jelmer> bzr: you can either recompile subvertpy against a newer libsvn or install bzr from another source
[20:10] <bzr> Can I recompile just subvertpy using MacPorts?  Or is there another way to do that?
[20:10] <bzr> What other sources can I use to install bzr?
[20:10] <jelmer> bzr: I'm not sure (I've never really used a Mac)
[20:11] <bzr> Hm.
[20:11] <jelmer> bzr: I think the other alternative is the installer on the bzr site
[20:11] <Tak> macports is a quick path to brokenness
[20:11] <dash> nah
[20:11] <bzr> I used the installer from the bzr site.
[20:11] <bzr> This one:
[20:11] <bzr> http://edge.launchpad.net/bzr/2.2/2.2.1/+download/Bazaar-2.2.1-OSX-10.5-1.dmg
[20:11] <bzr> Right?
[20:11] <dash> yeah you can't use the installer if you want to use macports stuff
[20:13] <bzr> I've also tried: http://launchpad.net/bzr/2.2/2.2.0/+download/Bazaar-2.2.0-OSX-10.5-1.dmg
[20:14] <bzr> Shouldn't those have a more up-to-date svn version?
[20:14] <bzr> Do I want to try: http://launchpad.net/bzr/2.3/2.3b3/+download/Bazaar-2.3b3-OSX-10.5-1.dmg
[20:14] <bzr> ?
[20:15] <jelmer> I've been using 2.3 for quite some time without problems
[20:16] <bzr> Okay, I guess I'll try that then...
[20:17] <bzr> Is it possibly that I'm on OS X 10.5?
[20:23] <bzr> Same error on bzr 2.3b3.
[20:24] <poolie> hi all
[20:24] <poolie> hm, that's confusing :)
[20:24] <bzr> Run command: bzr push
[20:24] <bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
[20:24] <jelmer> 'morning poolie
[20:24] <bzr> Hi poolie.
[20:27] <bzr> I just tried downloading and installing the py26-subvertpy via MacPorts.  Same error.
[20:27] <jelmer> bzr: I'm not sure what's going on there. It could be that you end up using the system svn libraries or something like that
[20:28] <bzr> My system svn claims to be 1.6.9.
[20:28] <maxb> bzr: Perhaps you could first confirm where this Subversion 1.4.4 installation is - the system one? Something else?
[20:28] <bzr> (from svn help)
[20:28] <bzr> It's not the system one.
[20:28] <bzr> I really don't know where it is.
[20:29] <bzr> Is there any way to get bzr to tell me where it's getting its svn?
[20:36] <poolie> bzr set 'BZR_PDB=1' in the environment
[20:36] <poolie> then when it/if it crashes, type 'pp sys.modules()'
[20:38] <bzr> Where do I type pp sys.modules()?  And will it work if bzr doesn't crash?
[20:40] <bzr> It just fails with:
[20:40] <bzr> Run command: bzr push
[20:40] <bzr> Using saved push location: https://george@nanotech.com@pl3.projectlocker.com/nano/www/svn
[20:40] <bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
[20:40] <maxb> If it does not crash, you will not get the prompt at which you would type the pp command
[20:40] <bzr> Hm.
[20:40] <bzr> Is there a way to get it to crash?
[20:41] <maxb> bzr: OK, so I have checked the bzr-svn source code, and the 1.4.4 being reported is the version of Subversion that the subvertpy python extension was compiled against
[20:41] <bzr> Thanks.
[20:42] <bzr> So...I need to upgrade subvertpy?
[20:42] <bzr> Shouldn't updating subvertpy via MacPorts have worked?
[20:42] <maxb> I have zero Mac knowledge
[20:43] <maxb> But certainly, you do need to rebuild subvertpy against a newer subversion
[20:45] <bzr> Who would know how to do that?
[20:48] <maxb> I have to go now, sorry.
[20:51] <bzr> I have to go too.  More anon.  Thanks!
[21:30] <rootart> hello to all
[21:31] <rootart> I have a question about the bzr hooks and signals, how we can check on server side that new branch is created?
[21:32] <rootart> I found this hook post_branch_init but I'm not very familar with API so, can someone suggest how to work with this ?
[22:39] <spiv> rootart: have you seen http://doc.bazaar.canonical.com/development/en/user-guide/hooks.html ?
[22:41] <spiv> rootart: the object passed to the hook is http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BranchInitHookParams.html
[22:42] <rootart> spiv: yes, I saw that, for now I think I can get the action, but now I have over one, I have a repository 'repo', I want create a branch 'b1', I am getting the new one branch object, but how can I know what repository this branch is a copy of ?
[22:42] <rootart> spiv: thanks again, that is done I think
[22:42] <rootart> spiv: now have only this last one question
[22:49] <spiv> rootart: if you have a branch object, the repository is 'your_branch.repository'
[23:35] <poolie> hi maxb, spiv, jelmer
[23:40] <dOxxx> evening
[23:54] <mgz> ...if I try and delete the bug watch from bug 682600 I get OOPS-1794O2309