[00:01] (btw, the error is when doing a "bzr branch" using any bzr+http:// URL scheme) [00:01] is someone already working on git2bzr convertion?? [00:03] nxvl: yes, there's a fastimport reader, see list [00:03] moebius_: i don't recall it [00:03] can i suggest trying 1.3rc1 though [00:07] 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] nxvl: hi [00:08] james_w: hi! [00:08] nxvl: how are you? [00:08] james_w: fine, finishing with all my papers for attending to UDS and looking for a python project to work on :P [00:09] james_w: also waiting for the mentors list for GSOC being published tomorrow :P [00:09] nxvl: you're going to UDS? Great! [00:09] you know bzr is a python project? [00:10] james_w: yep, that's why i'm here :D [00:10] ah, great! [00:10] just starting to read the documentation and browsing the code [00:10] nxvl: are you interested in git->bzr conversion? [00:11] james_w: yep [00:11] I think it would make a great project. [00:11] james_w: i find it a nice and not so hard feature to start with [00:12] well, a few parts will be a bit tricky in terms of learning the bzr API. [00:12] btw, is bzr going to be part of GSCO? [00:12] james_w: yep, but is easier that learn the bzr code ;) [00:12] nxvl: no, we're going to do our own student projects through canonical [00:12] than* [00:12] are you interested [00:12] the rest will just be coming up with ways to not store the 300MB source repository in memory as you go. [00:12] poolie: yes of course [00:13] poolie: is there already a wiki or web where i can look for those? [00:13] poolie: nxvl is a cool Peruvian LoCo team member for Ubuntu. [00:13] He's also involved in MOTU. [00:13] and loads of other stuff I'm sure :) [00:13] * nxvl HUGS james_w [00:13] * james_w hugs nxvl back [00:14] :) [00:15] james_w: I will test 1.3rc1 and fill the bug, thanks [00:15] moebius_: great, thanks. [00:16] 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] nxvl: I'm sure there is a bunch of project ideas lurking around somewhere. [00:16] 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] that's just one problem someone bought up, we're keen to have it work on every platform. [00:18] james_w: isn't so hard with python [00:18] :P [00:18] that's the idea. [00:19] 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] mm [00:19] i have just had it open [00:19] let me check my history [00:19] the SummerOfCode page is old, I just renamed it [00:20] 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] james_w: http://bazaar-vcs.org/SummerOfCode2007 [00:20] ah, I only looked at the top, so I didn't realise the list was there. [00:21] james_w: 1.3rc1 works for me doing exactly the same operation as before [00:21] moebius_: meaning it reproduces the bug, or it works? [00:21] it works [00:21] great [00:22] no error with 1.3rc1 [00:22] the branch op gets done ok [00:22] moebius_: great, thanks for testing. [00:22] dato: bzr-hookless-email is quite slow for me; I'll look at it in my copious spare time [00:22] abentley: ping [00:22] 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] no problem, i like to help with those things [00:22] and bzr is so good it deserves some love :D [00:22] moebius_: bzr loves you too :-) [00:23] should I report the bug in the 1.2 series? [00:24] 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] moebius_: if you want to report it I would be happy to mark it fixed in 1.3 with an explanation. [00:24] moebius_: generally once we've made a new release we don't worry about older bugs [00:24] as james says [00:25] ok, I will report it, just for documentation [00:25] also, if someone hits the same bug, will know he can use 1.3 [00:27] what is bzrk? [00:28] I think it means bzr-gtk [00:28] oh! ok [00:28] bzrk is 'bzr viz' [00:28] hi lifeless [00:29] james_w: thx [00:30] lifeless: I have both the bzr and git emacs trees here and guess which is smaller? [00:30] you rock! [00:30] way to go [00:31] apparently the git one has some merge information added, so I don't know how much that will have added [00:31] although the git log >/dev/null time is pretty amazing. [00:31] james_w: which ? [00:31] lifeless: bzr of course :) [00:31] lifeless: thnx [00:32] james_w: thats pretty surprising [00:32] nice, but suprising [00:32] if they've recorded merges from other branches and we have not that might be part of it [00:32] 292M/333M [00:32] we are rather bad with merges today [00:33] well, that may be down to the way the import was done [00:33] although there are perhaps more branches in git, so I may not be being fair. [00:34] I didn't look properly last time, so I thought there was only one. [00:34] 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] awmcclain: hmm, sorry about that. [00:35] awmcclain: hum, I consider that a bug. Can you please file a bug on bzr-email about that [00:35] Either that or it DOES work and I'm don't have it configured somewhere else. [00:35] s/I'm/I [00:35] lets assume you've done it right [00:36] I'm going to try a conf var in a user directory next [00:36] I'll gather debugging stuff as needed via the bug [00:36] poolie: thanks for the tips on that debugging. [00:36] Is there any documentation about bzr configuration stuff? [00:36] the user guide [00:36] poolie: did you see John's bug about upgrading bzr.dev to -subtree? It looks like it may be the same thing. [00:36] not yet [00:37] awmcclain: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#configuring-bazaar [00:41] I believe the bug report should be ok: https://bugs.edge.launchpad.net/bzr/+bug/203031 [00:41] Launchpad bug 203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New] [00:41] haha, the bot catched me [00:41] xD [00:42] it is my first bug report, so please do not spank me if it is not well done [00:49] moebius_: you can mark it fixreleased if you like [00:51] I'll do it. [00:51] New bug: #203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New] https://launchpad.net/bugs/203031 [00:52] moebius_: thanks [00:52] moebius_: and it was a good bug report, make them all like that and you won't have any problems :-) [00:53] james_w: great! now time to sleep... it's somewhat late here in europe :D [00:54] moebius_: indeed it is. I must sleep too, thanks for the reminder. [00:54] night all. [00:55] i could say the same, good night and be happy. [00:59] james_w, nxvl: i posted http://bazaar-vcs.org/StudentProjects === poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing | === poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing | http://launchpad.net/bzr/1.3/1.3rc1 [01:22] * poolie looks at bzr ssh locking bugs with jml [01:24] in soviet russia ssh lock bugs you [01:25] it does bug me [01:27] are you in soviet russia? [01:27] knit proposal sent to list for rfc [01:28] james_w: Could you push your branch implementing the workaround option for bug 172657 to LP and link it to the bug? [01:28] Launchpad bug 172657 in bzr "bzr status after merge slower with packs" [Medium,Fix committed] https://launchpad.net/bugs/172657 [01:35] poolie: branch made [01:37] thank [01:41] 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] what do you think? [01:42] what happens today? [01:42] Does the smart server verb not disable polling ? [01:42] how often do we poll ? [01:46] i believe the server does the polling, from what jml tells me [01:47] will check [01:48] so [01:48] if we poll 1/sec [01:48] then I think its ok for the client to do it, but not optimal resource wise [01:48] if we poll 5/sec, then server load will be even more significant [01:49] I don't see why the client should do network traffic to ask the server 'are we there yet' [01:49] it's less than once per second [01:49] is the root problem 'client disconnections are not noticed' ? [01:49] no. [01:50] interrupting a bazaar client that's waiting for a lock does not cause a client disconnection [01:50] because it doesn't interrupt the ssh process. [01:51] 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] jml: and the client has gone before the lock was acquired [01:51] yes, that's right. [01:52] lifeless: it's partly that, and partly that at the moment the client gets no indication that anything is happening [01:52] so, we can't display progress to the user for example [01:52] 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] nor can it cancel the request once it's sent for that matter [01:52] lifeless: that's ok; it's comparable to a dangling lock over another protocol [01:53] poolie: sure, I'm just making sure I have a clear understanding [01:53] poolie: if I said what I think about some imaginary situation, it wouldn't help much :) [01:53] (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] jml: (user runs bzr push, push gets lock, user hits contorl-c, bzr dies, ssh keeps running ?) ? [01:54] that's the use-case that I'm particularly interested in [01:54] jml: I'm postulating that actually there is a significantly broader group hitting this than you realise [01:54] lifeless: not sure what happens in that situation. easy to find out though. [01:54] jml: e.g. what is special about lock waiting that stops bzr cleaning up ssh [01:55] lifeless: maybe. what's the significance if that's so? [01:55] jml: it means that the folk seeing the problem are not people waiting on lock contention [01:55] jml: but rather folk seeing little/no progress on push, or interrupting push [01:55] lifeless: that's not the reported bug. [01:56] * jml does an experiment or two [01:56] 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] poolie: so, what do I think. I think several things. [01:58] 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] 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] 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] and only doing that on non-local urls seems reasonable to me. [01:59] hitting ctrl-c during push kills the ssh process [01:59] at least, it does when I hit it :) [02:00] so, I consider the ssh not being killed during lock obtaining a severe bug [02:00] its got all sorts of implications [02:00] killing the ssh client is not a reliable way to avoid this [02:00] poolie: indeed; removing the network is the only way :) [02:01] * jml starts hacking on the ansible [02:01] (imagine the TF2 ping times!) [02:03] poolie: you could as an immediate quick fix just set the poll time to 0 on the smart server verb [02:03] poolie: I think this is not really a good idea, but it would stop the polling on the server side [02:03] e.g. just doing this on launchpad, today, would prevent the situation probably [02:04] I realise that this is roughly what you were suggesting. [02:04] 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] the problem is that the server is polling on its own account, and that should be controlled by the client [02:06] poolie: well, I disagree that it should be controlled by the client. [02:06] perhaps in the medium term we want to avoid lock operations going across the network at all? [02:06] we only lock branches today [02:06] and locking a branch is a human level action, not a bzr level one [02:07] if that makes sense [02:13] we could do some fancy nonce based stuff to detect collisions during a branch level operation [02:14] yay loggerhead, you go greedy thing [02:14] 930M [02:15] mwhudson: can we get some patch to loggerhead to dump objet allocation stats to the log once an hour or some such ? [02:15] also [02:15] its running python2.4 [02:16] IIRC 2.5 has the ability to free() memory [02:16] which might be useful. [02:17] that will probably cause some complaints from IS - it may need a distro upgrade [02:17] probably worth it though [02:17] they would love not having to stab loggerhead routinely [02:17] sigacly [02:18] its running 6.01.1 [02:18] 2.5 is not installed, we can likely get a backport though [02:19] that's dapper? [02:19] they say it is infeasibly hard to backport it [02:19] oh [02:20] meh, we can surely get a > dapper VM, or a distro upgrade [02:20] SEP :) [02:27] will send mail [02:42] lunching [02:50] lifeless: that sounds like a good idea [03:04] mwhudson: which, the patch or 2.5 ? ;) [03:04] lifeless: the patch [03:04] i'd be a little surprised if 2.5 made much difference [03:31] mwhudson: when did python start calling free()? [03:31] lifeless: probably 2.5, i don't really remember [03:32] but i don't think this will make much difference to the loggerhead situation [03:32] if entire arenas are free, python <2.5 will still reuse them [03:32] mwhudson: it will make peak/current memory usage clearer to the os [03:32] and if they're not free, python >=2.5 will not free them [03:32] how big is an area ? [03:33] arena [03:33] well, it's possible it will make things clearer, i guess [03:33] i would offer money that it would not really help much though [03:33] er, 256k i think, not sure though [03:33] so [03:34] I think it unlikely that in 930M of vss [03:34] that a majority of 256k regions are not empty, unless there is a genuine leak [03:35] eh [03:35] iirc 2.5 had more allocator improvements beyond just using free [03:36] if they are empty, then when loggerhead needs to allocate more objects, it will use an empty arena [03:37] mwhudson: sure, I get that [03:37] mwhudson: anyhow, 2.5 won't harm. [03:37] this is extremely likely [03:39] lifeless: i got "Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.3" [03:39] poolie: doh. one sec [03:41] poolie: fixed [03:59] thx [04:09] yay nm borked [04:09] now have to run iwconfig [04:09] remind me why we have a gui ? [04:22] lifeless: just as you said that my network collapsed :/ [04:29] ha! [06:02] poolie: I'm out; ciao. [09:33] 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] ls [09:37] . .. .bzr [09:46] Eek! It's a nekkid branch! Avert your eyes! [10:09] Arse, our decent HTTP proxy is down (ie, the one that doesn't demand NTLM auth to get out) [10:16] Meh, you know when you've been using vi to much when you try to quit every text editor with :wq [10:22] 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] disturbingly deals ok ctrl-x ctrl-s every few seconds [10:37] awilkins: I've just pushed the branch I'm currnetly using [10:37] that should at least build ok [10:38] you may have to fix the include dir detetion code in setup.py [10:41] jelmer: Judging by the fun I had on Friday with it, definitely [10:42] jelmer: Although I think I may have been overzealous with includes and libs, I might have been increasing my dependency nightmare [10:42] jelmer: Was trying with both MS 7.1 compiler and MinGW [10:42] Both have different issues === mwhudson__ is now known as mwhudson [11:11] you [11:11] 'd need both the apr and svn libraries [11:12] I got the "deps pack" for svn 1.4.6 win32 [11:12] But I'm not sure it has enough .lib files in it :-) [11:12] Anyway, I think it wil lhave to wait until later, my build environment is at home [11:13] APR builds easily on Win32, I wish SVN would take a leaf out of their book. [11:13] The best help they had to offer in #svn-dev was "good luck with that" === kiko-afk is now known as kiko [11:35] Wait a minute. [11:36] bzr-svn creating thousands of packs and instantly repacking them on a mostly-full file system can't be healthy for it. [12:14] re [12:15] 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] I wasn't complaining about the repacking, just thinking "augh, my poor hard drives". [12:16] instead of just one [12:16] How does something like "bzr pull" only write one pack then? [12:16] well, that's pull not commit. [12:17] currently when you do a commit it writes one pack. [12:20] Yeah.. [12:21] jelmer: we need to get bzr-svn in hardy sorted. [12:21] So what would be useful is being able to tell commit "don't save it yet, I'm about to commit again!"? [12:22] 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. === mrevell is now known as mrevell-lunch [12:24] james_w: ah, ouch [12:24] james_w: what is going to determine whether 1.3 will make it into hardy? [12:25] jelmer: whether the release team allow it. [12:25] james_w: ah, ok [12:25] the general rule is bug fix only releases. [12:25] bzr-svn 0.4.7 works with bzr 1.2 [12:25] it just warns you [12:25] so we should just disable the warning? [12:25] 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] or I could release 0.4.8, which would also help debian [12:30] I thought 0.4.8 would be 1.3 compatible [12:30] or is it both? [12:30] well, I was planning on making 0.4.8 1.3 compatible [12:30] Solving it in Debian is obviously important as well, but hardy is a little more pressing. [12:31] I think for Debian dato will upload the 1.3rc1 soon, so a bzr-svn release for 1.3 would work fine. [12:31] k [12:32] 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] afaik Martin Pitt already loosened the dependencies of the package itself [12:33] ah, ok. [12:33] I'll try and do that this week. === FreeNode_ is now known as herb === mrevell-lunch is now known as mrevell === mw|out is now known as mw [13:11] New bug: #203152 in bzr ""bzr merge --pull" does not list changes" [Undecided,New] https://launchpad.net/bugs/203152 [13:14] james_w: uploaded [13:15] dato: great, thanks. [13:16] spiv: did you see that Toshio says he is at pycon? Maybe you guys should try and catch up with him. [13:16] I think good relationships with distro packagers are very beneficial [13:16] isn't that right dato :) [13:17] heh [13:47] New bug: #119265 in trac-bzr "branch w/o commits produce traceback" [Medium,Fix released] https://launchpad.net/bugs/119265 [14:06] Hi, is there a way to resume a svn branch import? [14:07] morning [14:18] elmargol: with bzr-svn? [14:18] james_w: :( i try to import a 4000r svn repository [14:19] 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] elmargol: what error did it fail with? [14:23] I retry it... [14:23] don't have the errormessage anymore [14:31] 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] can someone explain the following error?? http://dpaste.com/39805/ [14:38] jetsaredim: you didn't specify a branch name [14:38] jetsaredim: ~jetsaredim/mplayerplug-in is an area to put branches related to mplayerplug-in [14:38] it can't itself be a branch [14:38] ahh [14:38] That message from Launchpad could be clearer. I'll file a bug. [14:39] so i need to call it something after that [14:39] spiv: how do I resume? [14:39] jetsaredim: yes. e.g. ~jetsaredim/mplayerplug-in/bug-123 or ~jetsaredim/mplayerplug-in/mine, or whatever [14:41] gotcha [14:41] thanks [14:41] and yes, that could be a little clearer [14:46] jetsaredim: bug 203178 filed. Thanks for the report. [14:46] 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] 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] spiv: that was fast [15:01] http://dpaste.com/39808/ [15:02] james_w: [15:09] elmargol: can you do "svn ls https://svn.participatoryculture.org/svn/dtv" ? [15:10] http://dpaste.com/39811/ [15:10] New bug: #203186 in bzr "authentication.conf isn't used with openssh" [Undecided,New] https://launchpad.net/bugs/203186 [15:10] so yes. [15:11] I'm not sure I'm afraid. [15:11] jelmer: do you have any ideas about this. [15:11] this happened after 600-700 revisions [15:11] these propfind errors seem familiar. [15:11] I think it's probably an intermittent error. [15:11] maybe that's just how a lot of errors manifest themselves [15:11] i.e. a temporary network glitch causing a request to fail at random. [15:12] elmargol: can you "bzr branch https://svn.participatoryculture.org/svn/dtv/trunk" ? [15:13] yes [15:25] elmargol: is that sufficient for your needs, or do you need the whole import? [15:25] its ok for me if it works... [15:25] i think it will crash... after some time [15:26] ah, sorry, I thought you were saying that you could. [15:29] http://dpaste.com/39815/ [15:33] elmargol: I'm not sure I'm afraid. [15:33] would you file a bug containing the trackebacks that you get please? [15:33] sure [15:40] https://bugs.launchpad.net/bzr/+bug/203190 [15:40] Launchpad bug 203190 in bzr "bzr svn-import fails" [Undecided,New] === thekorn_ is now known as thekorn [16:35] New bug: #203203 in bzr-loom "bzr nick breaks loom" [Undecided,New] https://launchpad.net/bugs/203203 [17:24] beuno: you'll never guess what, I just successfully build sid's baz in an up to date sid chroot. [17:25] james_w, wha? really? how!? [17:26] beuno: no idea. Just downloaded it and built it intending to get a shell with the failed build and it worked. [17:26] I'm going to try it on hardy now. [17:27] james_w, cool. Let me know if you want the files we worked on [17:28] beuno: yeah, they would be useful. [17:28] beuno: I think I can grab them from your PPA, let me look. [17:29] ok, I can get the baz one. [17:29] Did we do anything to bazaar-doc or bzr? [17:29] * beuno checks [17:30] james_w, we did bazaar-docs [17:31] I can zip that up and send it over [17:31] beuno: yes please. [17:33] james_w, sent [17:34] beuno: thanks. [17:36] james_w, good luck, and let me know if I can help you [17:36] thanks [17:43] vila, you rock ;) === FreeNode_ is now known as herb [18:02] beuno: it fails in hardy still [18:02] james_w, that's odd. Can you pinpoint it to the same library that failed before? [18:03] beuno: what do you mean? [18:03] james_w, there was a specific library that made it fail [18:04] which we tried to track down what was the last version it built with [18:04] lifeless pointed it out [18:06] beuno: I thought that was just a hunch. [18:06] he seemed pretty sure that they broke their ABI [18:07] oh yeah, they definitely did that. === mrevell is now known as mrevell-dinner [19:52] is it possible to see the progress in % for a push? [19:53] igc: nice work with the fast-import fix [19:54] james_w: please test!!!! It was a **BAD** bug [19:56] igc: did you see that the memcached guy confirmed that it worked for him? [19:56] no I hadn't - thanks for the update [19:57] 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] yep [19:58] is that fixed by this change as well? [19:58] should be [20:00] cool, I'll test that. [20:03] 'evening * [20:03] igc: using RevisionLoader seems to definitely help bzr-svn [20:04] hi jelmer - what sort of difference? [20:06] New bug: #203287 in bzr-loom "unable to create a new bottom thread" [Undecided,New] https://launchpad.net/bugs/203287 [20:07] New bug: #203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New] https://launchpad.net/bugs/203285 [20:18]