[00:01] <moebius_> (btw, the error is when doing a "bzr branch" using any bzr+http:// URL scheme)
[00:01] <nxvl> is someone already working on git2bzr convertion??
[00:03] <poolie> nxvl: yes, there's a fastimport reader, see list
[00:03] <poolie> moebius_: i don't recall it
[00:03] <poolie> can i suggest trying 1.3rc1 though
[00:07] <james_w> moebius_: it seems like a bug to me, so please file it with the full traceback. If you can test with 1.3rc1 that would be great.
[00:07] <james_w> nxvl: hi
[00:08] <nxvl> james_w: hi!
[00:08] <james_w> nxvl: how are you?
[00:08] <nxvl> james_w: fine, finishing with all my papers for attending to UDS and looking for a python project to work on :P
[00:09] <nxvl> james_w: also waiting for the mentors list for GSOC being published tomorrow :P
[00:09] <james_w> nxvl: you're going to UDS? Great!
[00:09] <james_w> you know bzr is a python project?
[00:10] <nxvl> james_w: yep, that's why i'm here :D
[00:10] <james_w> ah, great!
[00:10] <nxvl> just starting to read the documentation and browsing the code
[00:10] <james_w> nxvl: are you interested in git->bzr conversion?
[00:11] <nxvl> james_w: yep
[00:11] <james_w> I think it would make a great project.
[00:11] <nxvl> james_w: i find it a nice and not so hard feature to start with
[00:12] <james_w> well, a few parts will be a bit tricky in terms of learning the bzr API.
[00:12] <nxvl> btw, is bzr going to be part of GSCO?
[00:12] <nxvl> james_w: yep, but is easier that learn the bzr code ;)
[00:12] <poolie> nxvl: no, we're going to do our own student projects through canonical
[00:12] <nxvl> than*
[00:12] <poolie> are you interested
[00:12] <james_w> the rest will just be coming up with ways to not store the 300MB source repository in memory as you go.
[00:12] <nxvl> poolie: yes of course
[00:13] <nxvl> poolie: is there already a wiki or web where i can look for those?
[00:13] <james_w> poolie: nxvl is a cool Peruvian LoCo team member for Ubuntu.
[00:13] <james_w> He's also involved in MOTU.
[00:13] <james_w> and loads of other stuff I'm sure :)
[00:13]  * nxvl HUGS james_w 
[00:13]  * james_w hugs nxvl back
[00:14] <poolie> :)
[00:15] <moebius_> james_w: I will test 1.3rc1 and fill the bug, thanks
[00:15] <james_w> moebius_: great, thanks.
[00:16] <james_w> nxvl: I don't think there's any sort of list or anything yet, I'm not sure how far along the planning is.
[00:16] <james_w> nxvl: I'm sure there is a bunch of project ideas lurking around somewhere.
[00:16] <nxvl> james_w: on the bzr list there is some info, i have just found it, but is more on fastimport on windows :S
[00:17] <james_w> that's just one problem someone bought up, we're keen to have it work on every platform.
[00:18] <nxvl> james_w: isn't so hard with python
[00:18] <nxvl> :P
[00:18] <james_w> that's the idea.
[00:19] <james_w> I can't find a list of project ideas on the wiki, if you are keen for others I'm sure we can generate some.
[00:19] <nxvl> mm
[00:19] <nxvl> i have just had it open
[00:19] <nxvl> let me check my history
[00:19] <poolie> the SummerOfCode page is old, I just renamed it
[00:20] <james_w> though I think the fast-import one is great, as it is a useful tool, not too involved with the core, but would possibly involve adding some changes to core code to make it more efficient.
[00:20] <nxvl> james_w: http://bazaar-vcs.org/SummerOfCode2007
[00:20] <james_w> ah, I only looked at the top, so I didn't realise the list was there.
[00:21] <moebius_> james_w: 1.3rc1 works for me doing exactly the same operation as before
[00:21] <poolie> moebius_: meaning it reproduces the bug, or it works?
[00:21] <moebius_> it works
[00:21] <poolie> great
[00:22] <moebius_> no error with 1.3rc1
[00:22] <moebius_> the branch op gets done ok
[00:22] <james_w> moebius_: great, thanks for testing.
[00:22] <lifeless> dato: bzr-hookless-email is quite slow for me; I'll look at it in my copious spare time
[00:22] <lifeless> abentley: ping
[00:22] <nxvl> james_w: that happends here also, but when i was looking for what has been done last year i found the list :D
[00:22] <moebius_> no problem, i like to help with those things
[00:22] <moebius_> and bzr is so good it deserves some love :D
[00:22] <james_w> moebius_: bzr loves you too :-)
[00:23] <moebius_> should I report the bug in the 1.2 series?
[00:24] <james_w> I don't think it's likely to get fixed as 1.3 is so close, so the only reason would be documentation in case anyone else fixes it.
[00:24] <james_w> moebius_: if you want to report it I would be happy to mark it fixed in 1.3 with an explanation.
[00:24] <poolie> moebius_: generally once we've made a new release we don't worry about older bugs
[00:24] <poolie> as james says
[00:25] <moebius_> ok, I will report it, just for documentation
[00:25] <moebius_> also, if someone hits the same bug, will know he can use 1.3
[00:27] <nxvl> what is bzrk?
[00:28] <james_w> I think it means bzr-gtk
[00:28] <nxvl> oh! ok
[00:28] <lifeless> bzrk is 'bzr viz'
[00:28] <james_w> hi lifeless
[00:29] <nxvl> james_w: thx
[00:30] <james_w> lifeless: I have both the bzr and git emacs trees here and guess which is smaller?
[00:30] <james_w> you rock!
[00:30] <poolie> way to go
[00:31] <james_w> apparently the git one has some merge information added, so I don't know how much that will have added
[00:31] <james_w> although the git log >/dev/null time is pretty amazing.
[00:31] <lifeless> james_w: which ?
[00:31] <james_w> lifeless: bzr of course :)
[00:31] <nxvl> lifeless: thnx
[00:32] <lifeless> james_w: thats pretty surprising
[00:32] <lifeless> nice, but suprising
[00:32] <poolie> if they've recorded merges from other branches and we have not that might be part of it
[00:32] <james_w> 292M/333M
[00:32] <lifeless> we are rather bad with merges today
[00:33] <poolie> well, that may be down to the way the import was done
[00:33] <james_w> although there are perhaps more branches in git, so I may not be being fair.
[00:34] <james_w> I didn't look properly last time, so I thought there was only one.
[00:34] <awmcclain> james_w: Remember yesterday when I was asking you about bzr configuration values? Seems like branch.conf doesn't work for bzr-email either.
[00:34] <james_w> awmcclain: hmm, sorry about that.
[00:35] <lifeless> awmcclain: hum, I consider that a bug. Can you please file a bug on bzr-email about that
[00:35] <awmcclain> Either that or it DOES work and I'm don't have it configured somewhere else.
[00:35] <awmcclain> s/I'm/I
[00:35] <lifeless> lets assume you've done it right
[00:36] <awmcclain> I'm going to try a conf var in a user directory next
[00:36] <lifeless> I'll gather debugging stuff as needed via the bug
[00:36] <james_w> poolie: thanks for the tips on that debugging.
[00:36] <awmcclain> Is there any documentation about bzr configuration stuff?
[00:36] <lifeless> the user guide
[00:36] <james_w> poolie: did you see John's bug about upgrading bzr.dev to -subtree? It looks like it may be the same thing.
[00:36] <poolie> not yet
[00:37] <james_w> awmcclain: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#configuring-bazaar
[00:41] <moebius_> I believe the bug report should be ok: https://bugs.edge.launchpad.net/bzr/+bug/203031
[00:41] <ubotu> Launchpad bug 203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New]
[00:41] <moebius_> haha, the bot catched me
[00:41] <moebius_> xD
[00:42] <moebius_> it is my first bug report, so please do not spank me if it is not well done
[00:49] <poolie> moebius_: you can mark it fixreleased if you like
[00:51] <james_w> I'll do it.
[00:51] <ubotu> New bug: #203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New] https://launchpad.net/bugs/203031
[00:52] <james_w> moebius_: thanks
[00:52] <james_w> moebius_: and it was a good bug report, make them all like that and you won't have any problems :-)
[00:53] <moebius_> james_w: great! now time to sleep... it's somewhat late here in europe :D
[00:54] <james_w> moebius_: indeed it is. I must sleep too, thanks for the reminder.
[00:54] <james_w> night all.
[00:55] <moebius_> i could say the same, good night and be happy.
[00:59] <poolie> james_w, nxvl: i posted http://bazaar-vcs.org/StudentProjects
[01:22]  * poolie looks at bzr ssh locking bugs with jml
[01:24] <lifeless> in soviet russia ssh lock bugs you
[01:25] <poolie> it does bug me
[01:27] <lifeless> are you in soviet russia?
[01:27] <lifeless> knit proposal sent to list for rfc
[01:28] <Odd_Bloke> james_w: Could you push your branch implementing the workaround option for bug 172657 to LP and link it to the bug?
[01:28] <ubotu> Launchpad bug 172657 in bzr "bzr status after merge slower with packs" [Medium,Fix committed] https://launchpad.net/bugs/172657
[01:35] <lifeless> poolie: branch made
[01:37] <poolie> thank
[01:41] <poolie> lifeless: i'm suggesting we should fix the bzr+ssh leftover locks bug by making the client control polling for the lock, rather than the server
[01:41] <poolie> what do you think?
[01:42] <lifeless> what happens today?
[01:42] <lifeless> Does the smart server verb not disable polling ?
[01:42] <lifeless> how often do we poll ?
[01:46] <poolie> i believe the server does the polling, from what jml tells me
[01:47] <poolie> will check
[01:48] <lifeless> so
[01:48] <lifeless> if we poll 1/sec
[01:48] <lifeless> then I think its ok for the client to do it, but not optimal resource wise
[01:48] <lifeless> if we poll 5/sec, then server load will be even more significant
[01:49] <lifeless> I don't see why the client should do network traffic to ask the server 'are we there yet'
[01:49] <poolie> it's less than once per second
[01:49] <lifeless> is the root problem 'client disconnections are not noticed' ?
[01:49] <jml> no.
[01:50] <jml> interrupting a bazaar client that's waiting for a lock does not cause a client disconnection
[01:50] <jml> because it doesn't interrupt the ssh process.
[01:51] <lifeless> jml: well, sounds like its the same thing at the top level - the bzr client has gone away, but the server doesn't know this
[01:51] <lifeless> jml: and the client has gone before the lock was acquired
[01:51] <jml> yes, that's right.
[01:52] <poolie> lifeless: it's partly that, and partly that at the moment the client gets no indication that anything is happening
[01:52] <poolie> so, we can't display progress to the user for example
[01:52] <lifeless> so the race condition is the window between 'rpc_send obtain_lock' and 'rpc_reply lock_obtained' being sufficient for the client to go away.
[01:52] <poolie> nor can it cancel the request once it's sent for that matter
[01:52] <poolie> lifeless: that's ok; it's comparable to a dangling lock over another protocol
[01:53] <lifeless> poolie: sure, I'm just making sure I have a clear understanding
[01:53] <lifeless> poolie: if I said what I think about some imaginary situation, it wouldn't help much :)
[01:53] <jml> (user runs bzr push, bzr push waits for lock, user hits control-c, bzr dies, ssh keeps running, user runs break-lock, stale ssh acquires the lock)
[01:54] <lifeless> jml: (user runs bzr push, push gets lock, user hits contorl-c, bzr dies, ssh keeps running ?) ?
[01:54] <jml> that's the use-case that I'm particularly interested in
[01:54] <lifeless> jml: I'm postulating that actually there is a significantly broader group hitting this than you realise
[01:54] <jml> lifeless: not sure what happens in that situation. easy to find out though.
[01:54] <lifeless> jml: e.g. what is special about lock waiting that stops bzr cleaning up ssh
[01:55] <jml> lifeless: maybe. what's the significance if that's so?
[01:55] <lifeless> jml: it means that the folk seeing the problem are not people waiting on lock contention
[01:55] <lifeless> jml: but rather folk seeing little/no progress on push, or interrupting push
[01:55] <jml> lifeless: that's not the reported bug.
[01:56]  * jml does an experiment or two
[01:56] <lifeless> jml: I know its not the reported bug. But imagine for a second that everyone that reports the bug has actually hit it first on push on the branch, and then when they try to diagnose they have their own stale lock already present.
[01:57] <lifeless> poolie: so, what do I think. I think several things.
[01:58] <lifeless> poolie: I think that bzr's client code is already correct re: lock cleanup, so really fixing this ssh handling is the most important thing to do, as it smells like the end of a thread of related issues to me.
[01:58] <lifeless> poolie: I think that repeated network round trips to poll is rather ugly, as event based operations are so much cleaner, requests to the server have a cost, and polling designs are well known to scale poorly.
[01:59] <lifeless> poolie: I think the lack of UI feedback is fixable without restoring to network polling; just displaying the progress bar immediately with 'obtaining lock' would do it for instance.
[01:59] <lifeless> and only doing that on non-local urls seems reasonable to me.
[01:59] <jml> hitting ctrl-c during push kills the ssh process
[01:59] <jml> at least, it does when I hit it :)
[02:00] <lifeless> so, I consider the ssh not being killed during lock obtaining a severe bug
[02:00] <lifeless> its got all sorts of implications
[02:00] <poolie> killing the ssh client is not a reliable way to avoid this
[02:00] <lifeless> poolie: indeed; removing the network is the only way :)
[02:01]  * jml starts hacking on the ansible
[02:01] <jml> (imagine the TF2 ping times!)
[02:03] <lifeless> poolie: you could as an immediate quick fix just set the poll time to 0 on the smart server verb
[02:03] <lifeless> poolie: I think this is not really a good idea, but it would stop the polling on the server side
[02:03] <lifeless> e.g. just doing this on launchpad, today, would prevent the situation probably
[02:04] <lifeless> I realise that this is roughly what you were suggesting.
[02:04] <poolie> for me the ssh client being killed or not, while good to fix, is not essential, because the same bug can occur withotu it
[02:05] <poolie> the problem is that the server is polling on its own account, and that should be controlled by the client
[02:06] <lifeless> poolie: well, I disagree that it should be controlled by the client.
[02:06] <poolie> perhaps in the medium term we want to avoid lock operations going across the network at all?
[02:06] <lifeless> we only lock branches today
[02:06] <lifeless> and locking a branch is a human level action, not a bzr level one
[02:07] <lifeless> if that makes sense
[02:13] <lifeless> we could do some fancy nonce based stuff to detect collisions during a branch level operation
[02:14] <lifeless> yay loggerhead, you go greedy thing
[02:14] <lifeless> 930M
[02:15] <lifeless> mwhudson: can we get some patch to loggerhead to dump objet allocation stats to the log once an hour or some such ?
[02:15] <lifeless> also
[02:15] <lifeless> its running python2.4
[02:16] <lifeless> IIRC 2.5 has the ability to free() memory
[02:16] <lifeless> which might be useful.
[02:17] <poolie> that will probably cause some complaints from IS - it may need a distro upgrade
[02:17] <poolie> probably worth it though
[02:17] <lifeless> they would love not having to stab loggerhead routinely
[02:17] <poolie> sigacly
[02:18] <lifeless> its running 6.01.1
[02:18] <lifeless> 2.5 is not installed, we can likely get a backport though
[02:19] <poolie> that's dapper?
[02:19] <poolie> they say it is infeasibly hard to backport it
[02:19] <lifeless> oh
[02:20] <lifeless> meh, we can surely get a > dapper VM, or a distro upgrade
[02:20] <lifeless> SEP :)
[02:27] <poolie> will send mail
[02:42] <lifeless> lunching
[02:50] <mwhudson> lifeless: that sounds like a good idea
[03:04] <lifeless> mwhudson: which, the patch or 2.5 ? ;)
[03:04] <mwhudson> lifeless: the patch
[03:04] <mwhudson> i'd be a little surprised if 2.5 made much difference
[03:31] <lifeless> mwhudson: when did python start calling free()?
[03:31] <mwhudson> lifeless: probably 2.5, i don't really remember
[03:32] <mwhudson> but i don't think this will make much difference to the loggerhead situation
[03:32] <mwhudson> if entire arenas are free, python <2.5 will still reuse them
[03:32] <lifeless> mwhudson: it will make peak/current memory usage clearer to the os
[03:32] <mwhudson> and if they're not free, python >=2.5 will not free them
[03:32] <lifeless> how big is an area ?
[03:33] <lifeless> arena
[03:33] <mwhudson> well, it's possible it will make things clearer, i guess
[03:33] <mwhudson> i would offer money that it would not really help much though
[03:33] <mwhudson> er, 256k i think, not sure though
[03:33] <lifeless> so
[03:34] <lifeless> I think it unlikely that in 930M of vss
[03:34] <lifeless> that a majority of 256k regions are not empty, unless there is a genuine leak
[03:35] <mwhudson> eh
[03:35] <poolie> iirc 2.5 had more allocator improvements beyond just using free
[03:36] <mwhudson> if they are empty, then when loggerhead needs to allocate more objects, it will use an empty arena
[03:37] <lifeless> mwhudson: sure, I get that
[03:37] <lifeless> mwhudson: anyhow, 2.5 won't harm.
[03:37] <mwhudson> this is extremely likely
[03:39] <poolie> lifeless: i got "Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.3"
[03:39] <lifeless> poolie: doh. one sec
[03:41] <lifeless> poolie: fixed
[03:59] <poolie> thx
[04:09] <lifeless> yay nm borked
[04:09] <lifeless> now have to run iwconfig
[04:09] <lifeless> remind me why we have a gui ?
[04:22] <poolie> lifeless: just as you said that my network collapsed :/
[04:29] <lifeless> ha!
[06:02] <lifeless> poolie: I'm out; ciao.
[09:33] <awilkins> jelmer: Did you manage to solve that pyrex issue you had? I had a go at building the branch you had on Win32 ; it's not fun (and I've not succeeded yet).
[09:34] <awilkins> ls
[09:37] <Odd_Bloke> .   ..   .bzr
[09:46] <fullermd> Eek!  It's a nekkid branch!  Avert your eyes!
[10:09] <awilkins> Arse, our decent HTTP proxy is down (ie, the one that doesn't demand NTLM auth to get out)
[10:16] <awilkins> Meh, you know when you've been using vi to much when you try to quit every text editor with :wq
[10:22] <fullermd> Oh, that's nothing.  Wait 'till you get stuck in front of Word one day, and see how it reacts to Esc getting smacked all the time...
[10:30] <bob2> disturbingly deals ok ctrl-x ctrl-s every few seconds
[10:37] <jelmer> awilkins: I've just pushed the branch I'm currnetly using
[10:37] <jelmer> that should at least build ok
[10:38] <jelmer> you may have to fix the include dir detetion code in setup.py
[10:41] <awilkins> jelmer: Judging by the fun I had on Friday with it, definitely
[10:42] <awilkins> jelmer: Although I think I may have been overzealous with includes and libs, I might have been increasing my dependency nightmare
[10:42] <awilkins> jelmer: Was trying with both MS 7.1 compiler and MinGW
[10:42] <awilkins> Both have different issues
[11:11] <jelmer> you
[11:11] <jelmer> 'd need both the apr and svn libraries
[11:12] <awilkins> I got the "deps pack" for svn 1.4.6 win32
[11:12] <awilkins> But I'm not sure it has enough .lib files in it :-)
[11:12] <awilkins> Anyway, I think it wil lhave to wait until later, my build environment is at home
[11:13] <awilkins> APR builds easily on Win32, I wish SVN would take a leaf out of their book.
[11:13] <awilkins> The best help they had to offer in #svn-dev was "good luck with that"
[11:35] <Peng> Wait a minute.
[11:36] <Peng> bzr-svn creating thousands of packs and instantly repacking them on a mostly-full file system can't be healthy for it.
[12:14] <jelmer> re
[12:15] <jelmer> Peng: well, a part of the problem is that the API provides no way to indicate that you're going to write a bunch of revisions
[12:16] <Peng> I wasn't complaining about the repacking, just thinking "augh, my poor hard drives".
[12:16] <jelmer> instead of just one
[12:16] <Peng> How does something like "bzr pull" only write one pack then?
[12:16] <james_w> well, that's pull not commit.
[12:17] <james_w> currently when you do a commit it writes one pack.
[12:20] <Peng> Yeah..
[12:21] <james_w> jelmer: we need to get bzr-svn in hardy sorted.
[12:21] <Peng> So what would be useful is being able to tell commit "don't save it yet, I'm about to commit again!"?
[12:22] <james_w> I don't know if bzr 1.3 will get in to hardy, so we may have to instead put some bzr-svn package in.
[12:24] <jelmer> james_w: ah, ouch
[12:24] <jelmer> james_w: what is going to determine whether 1.3 will make it into hardy?
[12:25] <james_w> jelmer: whether the release team allow it.
[12:25] <jelmer> james_w: ah, ok
[12:25] <james_w> the general rule is bug fix only releases.
[12:25] <jelmer> bzr-svn 0.4.7 works with bzr 1.2
[12:25] <jelmer> it just warns you
[12:25] <james_w> so we should just disable the warning?
[12:25] <jelmer> so I guess one option would be to simply upload a new ubuntu package that adds (1,2) to the list of supported bzr versions
[12:26] <jelmer> or I could release 0.4.8, which would also help debian
[12:30] <james_w> I thought 0.4.8 would be 1.3 compatible
[12:30] <james_w> or is it both?
[12:30] <jelmer> well, I was planning on making 0.4.8 1.3 compatible
[12:30] <james_w> Solving it in Debian is obviously important as well, but hardy is a little more pressing.
[12:31] <james_w> I think for Debian dato will upload the 1.3rc1 soon, so a bzr-svn release for 1.3 would work fine.
[12:31] <jelmer> k
[12:32] <jelmer> james_w: I guess just adding (1,2) to the list of supported bzr versions in the bzr-svn ubuntu package should fix things then
[12:32] <jelmer> afaik Martin Pitt already loosened the dependencies of the package itself
[12:33] <james_w> ah, ok.
[12:33] <james_w> I'll try and do that this week.
[13:11] <ubotu> New bug: #203152 in bzr ""bzr merge --pull" does not list changes" [Undecided,New] https://launchpad.net/bugs/203152
[13:14] <dato> james_w: uploaded
[13:15] <james_w> dato: great, thanks.
[13:16] <james_w> spiv: did you see that Toshio says he is at pycon? Maybe you guys should try and catch up with him.
[13:16] <james_w> I think good relationships with distro packagers are very beneficial
[13:16] <james_w> isn't that right dato :)
[13:17] <dato> heh
[13:47] <ubotu> New bug: #119265 in trac-bzr "branch w/o commits produce traceback" [Medium,Fix released] https://launchpad.net/bugs/119265
[14:06] <elmargol> Hi, is there a way to resume a svn branch import?
[14:07] <igc> morning
[14:18] <james_w> elmargol: with bzr-svn?
[14:18] <elmargol> james_w: :( i try to import a 4000r svn repository
[14:19] <james_w> elmargol: if you have a partial branch on disk then you can bzr pull, if not I think you may have to start over.
[14:19] <james_w> elmargol: what error did it fail with?
[14:23] <elmargol> I retry it...
[14:23] <elmargol> don't have the errormessage anymore
[14:31] <spiv> elmargol: with bzr-svn, it's best to do the branch inside a repo made with "bzr init-repo --rich-root-pack", because then you can resume very easily.
[14:37] <jetsaredim> can someone explain the following error??  http://dpaste.com/39805/
[14:38] <jelmer> jetsaredim: you didn't specify a branch name
[14:38] <dato> jetsaredim: ~jetsaredim/mplayerplug-in is an area to put branches related to mplayerplug-in
[14:38] <dato> it can't itself be a branch
[14:38] <jetsaredim> ahh
[14:38] <spiv> That message from Launchpad could be clearer.  I'll file a bug.
[14:39] <jetsaredim> so i need to call it something after that
[14:39] <elmargol> spiv: how do I resume?
[14:39] <dato> jetsaredim: yes. e.g. ~jetsaredim/mplayerplug-in/bug-123 or ~jetsaredim/mplayerplug-in/mine, or whatever
[14:41] <jetsaredim> gotcha
[14:41] <jetsaredim> thanks
[14:41] <jetsaredim> and yes, that could be a little clearer
[14:46] <spiv> jetsaredim: bug 203178 filed.  Thanks for the report.
[14:46] <ubotu> Launchpad bug 203178 in launchpad-bazaar "Unclear error when pushing over bzr+ssh: "This method is only for creating branches:"" [Undecided,New] https://launchpad.net/bugs/203178
[14:47] <spiv> elmargol: If the branch is inside a repo, then you can just delete the branch and re-run the bzr branch command.  The already converted revisions will be stored in the repo, so it won't need to convert them again.
[14:50] <jetsaredim> spiv: that was fast
[15:01] <elmargol> http://dpaste.com/39808/
[15:02] <elmargol> james_w:
[15:09] <james_w> elmargol: can you do "svn ls https://svn.participatoryculture.org/svn/dtv" ?
[15:10] <elmargol> http://dpaste.com/39811/
[15:10] <ubotu> New bug: #203186 in bzr "authentication.conf isn't used with openssh" [Undecided,New] https://launchpad.net/bugs/203186
[15:10] <james_w> so yes.
[15:11] <james_w> I'm not sure I'm afraid.
[15:11] <james_w> jelmer: do you have any ideas about this.
[15:11] <elmargol> this happened after 600-700 revisions
[15:11] <james_w> these propfind errors seem familiar.
[15:11] <spiv> I think it's probably an intermittent error.
[15:11] <james_w> maybe that's just how a lot of errors manifest themselves
[15:11] <spiv> i.e. a temporary network glitch causing a request to fail at random.
[15:12] <james_w> elmargol: can you "bzr branch  https://svn.participatoryculture.org/svn/dtv/trunk" ?
[15:13] <elmargol> yes
[15:25] <james_w> elmargol: is that sufficient for your needs, or do you need the whole import?
[15:25] <elmargol> its ok for me if it works...
[15:25] <elmargol> i think it will crash... after some time
[15:26] <james_w> ah, sorry, I thought you were saying that you could.
[15:29] <elmargol> http://dpaste.com/39815/
[15:33] <james_w> elmargol: I'm not sure I'm afraid.
[15:33] <james_w> would you file a bug containing the trackebacks that you get please?
[15:33] <elmargol> sure
[15:40] <elmargol> https://bugs.launchpad.net/bzr/+bug/203190
[15:40] <ubotu> Launchpad bug 203190 in bzr "bzr svn-import fails" [Undecided,New]
[16:35] <ubotu> New bug: #203203 in bzr-loom "bzr nick breaks loom" [Undecided,New] https://launchpad.net/bugs/203203
[17:24] <james_w> beuno: you'll never guess what, I just successfully build sid's baz in an up to date sid chroot.
[17:25] <beuno> james_w, wha?  really?  how!?
[17:26] <james_w> beuno: no idea. Just downloaded it and built it intending to get a shell with the failed build and it worked.
[17:26] <james_w> I'm going to try it on hardy now.
[17:27] <beuno> james_w, cool. Let me know if you want the files we worked on
[17:28] <james_w> beuno: yeah, they would be useful.
[17:28] <james_w> beuno: I think I can grab them from your PPA, let me look.
[17:29] <james_w> ok, I can get the baz one.
[17:29] <james_w> Did we do anything to bazaar-doc or bzr?
[17:29]  * beuno checks
[17:30] <beuno> james_w, we did bazaar-docs
[17:31] <beuno> I can zip that up and send it over
[17:31] <james_w> beuno: yes please.
[17:33] <beuno> james_w, sent
[17:34] <james_w> beuno: thanks.
[17:36] <beuno> james_w, good luck, and let me know if I can help you
[17:36] <james_w> thanks
[17:43] <beuno> vila, you rock  ;)
[18:02] <james_w> beuno: it fails in hardy still
[18:02] <beuno> james_w, that's odd. Can you pinpoint it to the same library that failed before?
[18:03] <james_w> beuno: what do you mean?
[18:03] <beuno> james_w, there was a specific library that made it fail
[18:04] <beuno> which we tried to track down what was the last version it built with
[18:04] <beuno> lifeless pointed it out
[18:06] <james_w> beuno: I thought that was just a hunch.
[18:06] <beuno> he seemed pretty sure that they broke their ABI
[18:07] <james_w> oh yeah, they definitely did that.
[19:52] <jetsaredim> is it possible to see the progress in % for a push?
[19:53] <james_w> igc: nice work with the fast-import fix
[19:54] <igc> james_w: please test!!!! It was a **BAD** bug
[19:56] <james_w> igc: did you see that the memcached guy confirmed that it worked for him?
[19:56] <igc> no I hadn't - thanks for the update
[19:57] <james_w> I've looked at that HACK before, it appears to be what makes the changed files not show up as modified: after in the log.
[19:57] <igc> yep
[19:58] <james_w> is that fixed by this change as well?
[19:58] <igc> should be
[20:00] <james_w> cool, I'll test that.
[20:03] <jelmer> 'evening *
[20:03] <jelmer> igc: using RevisionLoader seems to definitely help bzr-svn
[20:04] <igc> hi jelmer - what sort of difference?
[20:06] <ubotu> New bug: #203287 in bzr-loom "unable to create a new bottom thread" [Undecided,New] https://launchpad.net/bugs/203287
[20:07] <ubotu> New bug: #203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New] https://launchpad.net/bugs/203285
[20:18] <jelmer> igc: I haven't done any benchmarking yet
[20:20] <spiv> jelmer: when's the 0.4.8 release btw?  People at PyCon keep asking :)
[21:16] <lifeless> james_w: neon breaks that test; it was memory not a hunch
[21:17] <james_w> lifeless: ah, sorry for doubting you.
[21:17] <james_w> lifeless: however it works on sid now. I think the failure there was for a different reason originally though
[21:17] <james_w> lifeless: I'm talking to a couple of people about bzr-loom on #vcs-pkg/freenode at the moment.
[21:39] <unenough> hi, I have a shared repo with some repos inside
[21:40] <unenough> can i somehow see the tree for the whole shared repo? that is showing merges between sub-repos
[21:40] <unenough> ooooooops
[21:40] <unenough> i mean: repo (instead of shared repo) and branches (instead of "repos")
[21:42] <james_w> unenough: no, there's no tool to visualise a set of branches yet unfortunately.
[22:11] <mpt> Hi, I've installed bzr-loom and it shows up in "bzr plugins", but when I branch a branch that's in loom format, I still get "bzr: ERROR: Could not understand response from smart server: ('error', "Unknown branch format: 'Bazaar-NG Loom branch format 1\\n'")"
[22:11] <mpt> Is there something else I need to do?
[22:11] <james_w> mpt: is loom installed on the server?
[22:11] <james_w> hi mpt btw
[22:11] <mpt> hi :-)
[22:12] <mpt> I don't know whether loom is installed on the server, it's not my server
[22:12] <mpt> How would I find out?
[22:12] <james_w> ah, the message seems be suggesting that it isn't
[22:12] <james_w> what protocol are you using to branch?
[22:13] <mpt> Oh, so it's the server that's giving that "Unknown branch format" error, not my copy of bzr
[22:13] <mpt> I don't know what protocol I'm using to branch, I'm just using "bzr branch"
[22:13]  * mpt is a bear of very little brain
[22:14] <mpt> Ok, so I SSHed to the server and its copy of bzr doesn't have bzr-loom installed
[22:16] <mpt> thanks for the help
[22:17] <james_w> mpt: the protocol would bzr bzr+ssh:// or something.
[22:18] <mpt> oh, right
[22:18] <mpt> yes, bzr+ssh
[22:18] <mpt> oh, I could use sftp:// instead?
[22:18]  * mpt tries
[22:18] <mpt> then bzr on the server wouldn't need to get involved at all
[22:20] <james_w> mpt: good idea
[22:20] <nxvl> james_w: hi!
[22:20] <james_w> I was asking to know if you had ssh access to the server
[22:20] <james_w> hi nxvl. how are you?
[22:21] <nxvl> good, working on some packages, and at work
[22:21] <james_w> cool
[22:21] <mpt> hurrah
[22:21] <mpt> thanks james_w
[22:21] <nxvl> this has been the first light day after a really hard week
[22:22] <nxvl> james_w: did you know something about the canonical summer of code poolie mention last time
[22:22] <james_w> mpt: glad it works
[22:22] <nxvl> james_w: i have ask to dendrobates and dholbach, and non of them seems to know anything
[22:23] <james_w> nxvl: I don't know anything, sorry.
[22:23] <nxvl> mm, it seems that no one know, so it mustn't going to run this year :S
[22:24] <james_w> nxvl: I don't know if Ubuntu is doing it as well, I just saw that they weren't on the GSoC list.
[22:24] <james_w> I think it's a pretty recent idea, so it might be because people haven't heard yet.
[22:25] <nxvl> james_w: yep, but last time i was here poolie mention something about a running a student program thru canonical
[22:25] <james_w> nxvl: that's what I mean
[22:25] <james_w> nxvl: I think that idea is quite new.
[22:26] <nxvl> mm
[22:26] <nxvl> ok, i will give a try to gsoc this year on a debian project, and next year maybe on canonical program
[22:26] <nxvl> :P
[22:27] <james_w> nxvl: if you are interested you could send an email to the list to say that.
[22:27] <nxvl> james_w: the bzr list?
[22:28] <james_w> yep
[22:28] <nxvl> mm
[22:28] <james_w> unless you're more interested in Ubuntu
[22:28] <nxvl> actually yes
[22:28] <nxvl> i'm more interested in ubuntu
[22:28] <james_w> ok
[22:29] <nxvl> but i'm also interested on bzr, but is still 2nd on my list
[22:29] <nxvl> :S
[22:32] <lifeless> james_w: still on vcs-pkg  ?
[22:36] <james_w> lifeless: I am, but the discussion has petered out.
[22:38] <lifeless> james_w: I dont see anyone in that channel
[22:38] <lifeless> james_w: #vcs-pkg right ?
[22:41] <lifeless> dato: bzr-hookless-email seems to set From and Sender
[22:41] <lifeless> dato: is that deliberate?
[22:42] <james_w> lifeless: did I say freenode?
[22:42] <james_w> sorry, I meant OFTC.
[22:47] <james_w> How do I force urllib?
[22:48] <TFKyle> james_w: to do what?
[22:49] <james_w> To force bzr to use urllib for http connections?
[22:49] <Peng> http+urllib, I think
[22:49] <TFKyle> ah, the http+urllib:// protocol iirc
[22:49] <Peng> I think I've been using pycurl recently. No problems so far.
[22:49] <james_w> https+urllib://
[22:50] <james_w> I was trying to use my 0.14 client on my server to tell me, and wondered why it had so few help topics.
[22:50] <TFKyle> Peng: used to be a problem with it branching from certain lighttpd instances, think it was related to lighttpd not doing certain range requests
[22:50] <Peng> Huh.
[22:50] <Peng> Also, there's stuff like it being bad about getting Ctrl+Ced or something.
[22:51] <Peng> james_w: Heh, oops.
[22:52] <james_w> It doesn't like SSL certificates it can't verify as they are self signed or it is missing the CA cert.
[22:52] <Peng> Ah.
[22:52] <Peng> Well, that's a good thing.
[22:52] <Peng> Python will gain cert verification in 2.6.
[22:52] <dwon> I created a project in bzr, and now I'm trying to svn-push it into a new svn repository, but I get "These branches have diverged. Use the merge command to reconcile them.".  With some fiddling, it looks like I can get it to merge my entire tree in one svn revision, but I'd like to get the revision history into subversion.  Is it possible?
[22:53] <TFKyle> Peng: really? bug/commit link?
[22:53] <Peng> TFKyle: There's an "ssl" module, AFAIK.
[22:53] <Peng> dwon: Wait, what? Why not push it to, y'know, bzr?
[22:54] <james_w> Peng: that is a good thing, except when the user can't override it.
[22:54] <dwon> Peng: because everyone else at the company I work for uses svn
[22:54] <Peng> james_w: Indeed.
[22:54] <james_w> dwon: it should be possible. I'm not sure why you get that error.
[22:55] <TFKyle> Peng: ah
[22:56] <james_w> dwon: you could file a bug with as much information as you can.
[22:56] <james_w> dwon: in particular an "svn ls URL_you_are_trying_to_push_to" might provide a hint.
[22:56] <james_w> and svn log of that too.
[22:57] <james_w> you can obscure filenames if that is a problem for you.
[23:00] <TFKyle> Peng: hmm, from a quick look at the ssl module it looks like it's up to the person using it to validate the cert
[23:00]  * TFKyle could be blind and wrong though
[23:00] <Peng> TFKyle: Does urllib2 use it, though?
[23:01] <TFKyle> or httplib rather, not sure :)
[23:01] <TFKyle> (urllib uses httplib under the covers for http connections :))
[23:02] <james_w> urllib ignores certificates, I know that much
[23:02] <lifeless> poolie: /win 50
[23:02] <lifeless> meh sorry
[23:02] <lifeless> poolie: I'm going to be chasing knits today
[23:03] <TFKyle> looks like httplib uses it if available, doesn't do checking itself though
[23:04] <TFKyle> (in current svn trunk anyway, might be a bug adding checking if nothing does already)
[23:05] <lifeless> dwon: for a new svn branch use 'svn-push'
[23:05] <dwon> lifeless: Did that
[23:06] <TFKyle> hmm, actually I'm probably blind and ssl/_ssl actually do do it
[23:07] <TFKyle> (assuming you give it a proper ca_certs arg
[23:08] <TFKyle> (and cert_reqs)
[23:12] <poolie> lifeless: did you see jml around yet?
[23:12] <poolie> he said he was still jetlagged...
[23:14] <Peng> jelmer: Would your new svn Python bindings be useful to other projects?
[23:15] <jelmer> Peng: yep, they're more python than the original bindings
[23:15] <jelmer> *pythonic
[23:16] <TFKyle> mm, they're in bzr-svn or?
[23:17] <Peng> TFKyle: http://people.samba.org/bzr/jelmer/bzr-svn/pyrex/
[23:18] <Peng> jelmer: Cool.
[23:18] <jml> yes, I'm around
[23:19] <jml> poolie: I said I was still very tired :)
[23:19] <jml> I'm uncertain as to whether this constitutes jetlag.
[23:25] <poolie> me too
[23:25] <poolie> i want to go out to the vet
[23:25] <poolie> (doctors can't help me anymore :-)
[23:26] <poolie> but did not want to leave you standing outside
[23:26] <poolie> if you were coming over
[23:27] <jml> poolie: that's ok. I'm waiting for thumper to get back
[23:31] <dwon> james_w: https://bugs.launchpad.net/bzr/+bug/203365
[23:31] <ubotu> Launchpad bug 203365 in bzr "Can't create new svn branch from a bzr branch" [Undecided,New]
[23:33] <spiv> jelmer: "bzr svn-push" does weird things if the branch has no new history (e.g. bzr branch svn://.../trunk new-branch; cd new-branch; bzr svn-push svn://.../branches/new-branch)
[23:41] <ubotu> New bug: #203365 in bzr "Can't create new svn branch from a bzr branch" [Undecided,New] https://launchpad.net/bugs/203365
[23:45] <lifeless> man npviewer.bin must die
[23:45] <lifeless> keeps using 99% cpu
[23:49] <RAOF> lifeless: I see you're another member of the x86-64 self-flageltion society :(
[23:52] <lifeless> RAOF: users -> bug reports -> fixed software
[23:52] <lifeless> or thats the theory
[23:52] <lifeless> RAOF: have you filed a bug ?
[23:53] <jml> poolie: so, when would be a good time to come over?
[23:53] <slangasek> jelmer: so if I'm getting backtraces with bzr-svn trying to merge into the grub branch that was 'bzr join'ed, is this a bzr-svn bug, or a grade-A Fail of the unsupported join functionality? :)
[23:54] <poolie> hm i still haven't left
[23:54] <poolie> but if you plan to arrive at 12 that should be ifne
[23:54] <poolie> jml, or even a bit earlier
[23:55] <jml> poolie: ok.
[23:55] <ubotu> New bug: #203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Undecided,New] https://launchpad.net/bugs/203368
[23:56] <RAOF> lifeless: I've filed a number of bugs against nspluginwrapper.  Some have even been fixed!
[23:56] <lifeless> slangasek: file a bug with the backtrace ?
[23:56] <lifeless> RAOF: was one of them 'insane battery use' ?
[23:56] <RAOF> No, I don't believe so.  The one I was particularly thinking of is "crashes when there's lots of flash"
[23:57] <RAOF> I should probably follow that up.  The debian package has it fixed (by actually initialising glib's thread support before using threads, IIRC).
[23:59] <slangasek> lifeless: if I'm not going to get glared at for using undocumented and unsupported features, ok ;)
[23:59] <lifeless> slangasek: we want to make it supported
[23:59] <lifeless> slangasek: as long as you don't expect it to be fixed, bug reports on this stuff are good