[00:00] but i'm ok with making it a dependency of bzr, we don't aspire to have every feature working on a bare python install [00:01] with a _bare_ install, I can give you encrypted bzr server connections [00:02] surely, that's an improvement (even if minute) [00:02] so is that the main difference in your view? [00:04] yes - so far, it is something small that improves security and THEN makes possible authentication over an encrypted channel [00:09] i'm using bzr 1.17 and after doing 'bzr shelve' I get this: "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-5')]" [00:10] unshelve seems to work OK, but it worries me a little. :) [00:10] anything I can do to diagnose or fix this? [00:10] dash: are you shelving only some changes? [00:11] dash: also file a bug [00:12] no, all of them [00:12] OK [00:12] what does bzr status show, if you can show me? [00:12] hmm... my more general question has not been answered: how do I get a request to change something in the server e.g. in the connection (socket)? [00:13] denys: there isn't any way to do that at the moment, the server doesn't assume a socket even exists [00:13] denys: which is why I started talking about framing etc [00:13] lifeless: mmm, this is proprietary code, so i probably can't show it to you verbatim [00:14] lifeless: I know, but should I give up or is there value in trying to make that work? [00:14] dash: feel free to transform the filenames [00:14] dash: I want the structure [00:14] but it's just 4 files modified, 3 files added, no pending merges, mucho unknowns [00:14] OK [00:14] denys: and whether specific items are directories or files [00:15] denys: well, I don't see a lot of value, but if you do I'm happy to help you figure it all out. [00:15] denys, i thought i answered that, or at least pointed in the right direction [00:15] make the objects link to each other on the way up [00:15] so then the request can tell the socket to start encryption [00:16] denys: the reason I don't see a lot of value is that unlike e.g. SMTP, bzr's protocol aims to layer on transports that are already encrypted. SMTP though, defines a wire protocol for talking on a socket. [00:16] however, i really wish we could understand each other about ssh :-( [00:17] oh wow [00:17] http://www.techdirt.com/articles/20090328/1445494290.shtml [00:17] copyright law fail [00:17] poolie: there's a lot that I just can't do with with ssh that could be done if I have free reign. but I have to play with the cards I get. [00:18] denys: what sort of things? [00:18] lifeless: http://paste.ubuntu.com/256004/ [00:18] lifeless: mm i saw, that's a bit awful [00:18] lifeless: I can't sell it to admins [00:18] denys: it doesn't need system users though, or even to be on port 22 [00:18] mind you it'd probably be infeasible to run such a service _at all_ in au or uk because of libel law [00:18] I can't sell restricted shells [00:19] denys: it doesn't even need a shell [00:19] the SMH restaurant reviewer was sued for criticizing a restaurant [00:19] lifeless: you cannot reason it. this is not a reasonable requirement . it just is. and I have to deal with it. [00:20] oh; so you're saying that when you say 'ssh', your sysadmins think 'open ssh, PAM, passwd files and shells', but when you say 'https' they think 'some custom code I don't need to worry about' ? [00:21] they worry about it, but at least they have pretty goof hanlde on that [00:21] even though those two things are totally interchangable? [there are system web servers that offer shells and ssh servers that simply don't...] [00:21] ah :) [00:21] s/goof/good/ [00:21] * poolie made the classic mistake of assuming the requirements were rational [00:21] i have spent 3 years of lobbying :-( [00:22] what I have got is pretty good compared with we what we had before [00:23] so [00:23] one possibly thing to do would be to make bzrs be bzr+ssh :) [00:23] and just not tell anyone [00:24] lifeless: you don't work at a university ibviously [00:24] ;-) [00:24] so [00:24] denys: I used to [00:25] even if it's not externally visible at all, they're going to object if you're running a standard protocol at the top layer, but not if you're running a hand-crafted protocol? [00:25] * poolie wonders where you draw the line [00:25] lifeless: last time we did domething that the security officer didn#t approve of, he cut the entire university network === abentley1 is now known as abentley [00:25] denys: wow [00:25] if it's ssh but you must send the string 'cest la vie' before you start is that ok? [00:25] yeah! [00:26] poolie: no dice [00:26] ok [00:26] so that probably explains the confusion [00:26] i think at least some other it departments would actually prefer people use standard secured protocols [00:26] its a form of conflation [00:27] mm [00:27] 'ssh' is being conflated with implementations that have various implications [00:27] i've heard, years ago, of ssh being banned in favor of telnet [00:27] i'm not sure if it was that they wanted to sniff your traffic, or just fear of the new [00:27] they may eventually come that conclusion themselve, but it CANNOT be thrust upon them [00:28] poolie: fear of the new [00:28] right [00:28] denys: [and, that's very astute] [00:29] morning [00:29] denys: so, ok, [00:29] sheesh [00:29] poolie: the quick references cards did move some weeks back, yes [00:29] i'd like to help you out here but i'd also like something that makes sense for other people [00:30] and i think that's more likely to be builtin ssh [00:30] how about if you write a small separate program that works just like ssh but is not actually ssh [00:30] rephrase [00:30] 'uses the same encryption as ssh' [00:30] in other words it opens an ssl connection, sends a username and password, then runs a server process [00:30] :) [00:30] no, not the same protocol [00:31] so from bzr's point of view it will be 'program that gives me a connection to the server' [00:31] and 'program that starts the server in inetd mode' [00:31] poolie: I don't think that forcing EVERYTHING into the same mold is necessarily a good strategy. I'd like to see where we can take the bzr protocol. [00:32] the other consideration is: how hard is it to set up [00:32] I can guarantee you that setting things up on the university server is unbelievably hard [00:32] i can believe it [00:33] i'm reminded of getting an hp-ux account with no compiler and not even any cursor key support in the shell [00:33] that gets very very tedious [00:33] anyhow, if you put up clean patches, we can certainly look at them [00:34] my tack is to promove virtual servers - but I still have to ackonoledge the authentication rules set up by the univesity [00:34] i think your requirements here are weird enough they're not necessarily what we'd generally recommend [00:34] oops [00:34] but maybe it will turn out to be generally useful [00:34] my requirement are not weird. they are just what we have to deal with in france [00:34] lifeless & others: so on another topic, i'm wondering if rather than 1.18final we should do 2.0beta1 today [00:34] with the format set [00:35] acknowledging we'll need more bug fixes, but we may not need anything other than bug fixes [00:35] well, some things like selected-file commit may need to be fudged as bug fixes; they arguably are [00:35] poolie: uhm [00:35] poolie: I really think we're confusing people by changing the release labelling before 2.0 [00:36] there isn't a stable that we have been patching [00:36] so I'm very much in favour of 1.18 [00:36] to take a step back [00:36] and only changing the labelling at 2.0 [00:36] we could release 1.18final [00:36] off that branch [00:36] and then immediately release 2.0b1 at the base of a new branch [00:36] not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive [00:37] what's wrong with 2.0~beta1? [00:37] you can't have tildes in the upstream version? [00:37] a ~ means sort before [00:38] right [00:38] but its not part of the python version spec [00:38] which you said you wanted to follow [00:38] istm (2, 0, 0, 'beta', 1) === 2.0~beta1 [00:38] what is the problem? [00:39] that works for me I think [00:39] surely that's the commonsense way to represent it in both systems? [00:41] well, I'm only aware of ~ having this sort before meaning for dpkg specifically. [00:41] I think its fine to start using it elsewhere, but it doesn't follow on its own from the starting point of using python identifiers ;) [00:41] poolie: has it been 4 weeks since we released 1.18rc1? [00:41] i seem to be having a bad morning for communication [00:41] no [00:41] it's been a week and a half [00:42] then I think we should wait ;) [00:42] you said [00:42] > lifeless: not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive [00:42] i think i answered that [00:42] sure [00:43] i don't think we have to use the tilde anywhere else [00:43] in source or windows exe files it can be just 2.0beta1 [00:43] for rpms iirc they already have a special sort algorithm that treats 'beta' as meaning 'before' [00:50] lifeless: btw i suppose you implicitly fixed https://bugs.edge.launchpad.net/bzr/+bug/413584 ? [00:50] Ubuntu bug 413584 in bzr "TestStacking failures when default format is 2a" [High,In progress] [00:52] i marked it fixed [00:53] so did I:P [00:57] Um [00:57] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [00:57] bzr info? [00:57] All I was trying to do was `bzr pull` [00:57] AfC: is that a checkout ? [00:57] / bound branch [00:57] poolie: Repository checkout (format: 1.14-rich-root) [00:57] repository checkout root: . [00:57] checkout of branch: http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ [00:58] lifeless: yes [00:58] AfC: ok, so this is a bug [00:58] bzr 1.17 brand newly installed [00:58] we're not matching urls correctly [00:58] bzr unbind [00:58] k [00:58] bzr bind http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk [00:58] && pull? [00:58] then you'll be back to normal [00:58] and can use bzr update again [00:58] Bug? Isn't that just what you'd expect to do when pulling a checkout over http? [00:59] [sometimes I think that you guys should kill "checkout" and only offer branch & bind. [00:59] fullermd: no, the %7E != ~ [00:59] Sure, but what's that matter? [00:59] or, only offer branch ^W checkout & bind, etc] [00:59] If you're trying to pull INTO a http://something, you'd expect locking failure since it isn't writable. [00:59] fullermd: it fails the test in bzr.pull for master == source url [00:59] fullermd: trust me :) look in malone if you want the gory details [01:00] Well, maybe there's another bug there, but it *SHOULD* fail writing over HTTP regardless of any other matching. [01:00] I was trying to *pull* [01:00] fullermd: pulling from the master of a bound branch pulls locally only [01:00] In a checkout. Which means the branch you're trying to write to is across HTTP. [01:00] And then I recalled I really ought to "update" [01:01] can we please not paint the chicken a new colour right now? [01:01] It WHAT? That sounds like an insane level of DWIM... [01:01] (/me hates the fact that sometimes you do that as one step, sometimes two. eg push pull asymmetry, etc. I think in trying to make it easier we just made it more confusing) [01:01] fullermd: I'm not defending it, but its been there for years; and the url mismatch is causing the error AfC is getting [01:02] * fullermd never heard of that before. [01:02] fullermd: its part of the original bind patch I think [01:02] lifeless, poolie: thanks Robert & Martin. Fixed. [01:02] * AfC relocates [01:54] brb, fooding [02:13] dash: sorry, distractions [02:14] dash: so, uhm shelve is failing [02:14] yes [02:14] and you're doing shelve --all ? [02:14] using shelve1 at the moment in bzrtools [02:14] lifeless: well i hit 'f' at the first prompt so basically [02:14] to humour me, could you try shelve --all? [02:15] sure [02:15] also are there any pending merges? [02:15] no pending merges [02:15] kk [02:15] same error using --all [02:15] ok [02:15] definitely file a bug [02:15] except it says new-6 now, don't know if that's related to pulling new revs since i tried last [02:15] nope [02:15] you've modified another file probably [02:16] the parent of this branch is an svn branch, don't know if that's relevant [02:16] it might be; but the shelve operation is all local so shouldn't be [02:17] ok [02:17] guess i'll try this with 1.18rc1 too [02:17] thanks [02:24] Do the nautilus extensions work on ubuntu 9.04? I installed from source and I can't get olive to run and nothing shows up in nautilus. [02:26] This is what I get when I try to run olive-gtk: Traceback (most recent call last): [02:26] File "/usr/local/bin/olive-gtk", line 89, in [02:26] import bzrlib.plugins.gtk.ui as ui [02:26] ImportError: No module named gtk.ui [03:10] mozmck: sounds like you hvaen't got the bzr-gtk plugin installed [03:19] spiv: that's what I installed from source: bzr-gtk-0.96.2 [03:19] I'm running bzr 1.17 from the ppa deb package [03:20] how did you install it [03:20] ./setup.py install I think. [03:21] it may have installed to something not on your python path [03:21] oh, how would I find that out? where is the python path? [03:22] if you touch one of the source files [03:22] like __init__.py [03:22] and install it again, you can see the path it installs the python files to [03:22] touch it? [03:23] $ touch path/to/filename.py [03:24] ah, changes the timestamp. Then how do I find it once installed? [03:24] the installer outputs stuff [03:24] read what it outputs :) [03:25] /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk [03:25] and now [03:25] python -c "import sys; print sys.path" [03:26] '/usr/local/lib/python2.6/dist-packages' is at the end of the printout [03:27] ok [03:27] python -c "import bzrlib; print bzrlib.__path__" [03:28] ['/usr/lib/python2.6/dist-packages/bzrlib'] [03:28] so, this is a python limitation; by default it doesn't really know how to deal with different locations like that [03:28] I suggest moving /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk to /usr/lib/python2.6/dist-packages/bzrlib/plugins/gtk [03:28] ah, so I need to tell it to install in /usr/lib somehow [03:29] I'll try that [03:33] looks like that worked. The first time I tried to run olive it gave a different error than it was giving, but now it runs. [03:33] so should the nautilus stuff work after I log out and back in? [03:34] * igc lunch [04:32] so, it feels like every tweet gets a new spam follower [04:44] igc: hi [04:45] hi bialix [04:45] bialix: is qinfo better now? [04:45] igc, what version of PyQt/Qt you're have? [04:46] similar problem with layout and in quncommit [04:46] bialix: PyQt 4.4.4, Qt 4.5.0 [04:46] bilaix: jaunty [04:47] bialix: I'm seeing crap layout in quncommit - I'm yet to try tuning that, I just wanted something working first [04:47] what strange combination! [04:47] bialix: qinfo is ok for me though [04:48] I think PyQt should be 4.5.x too [04:48] weird weird weird [04:48] wait a sec [04:49] igc: http://imagebin.ca/view/RdaTOA.html [04:49] this is what I see by default [04:49] "move tip to" group should not be elastic. progress widget should be [04:50] bialix: ok [04:50] vila: hi :P [04:51] igc: there is several places that needs fixing in quncommit, unfortunately I have urgent work... [04:51] bialix: karmix will be pyqt 4.5.2, qt 4.5.1 by the look of things [04:51] * vila snores [04:51] igc: how about next plan: I'll merge quncommit as is but make it idden command [04:51] *hidden [04:52] bialix: if you can, let me fix it in the next hour or two [04:52] bialix: can the 0.14 release wait another few hours? === davidstrauss_ is now known as davidstrauss [04:52] igc: I will do release tonight in my tz, ~ +12 hours from now. But you'll be sleeping [04:53] bialix: cool. I have another 2-3 things to clean up so I'll have them up for review asap [04:54] bialix: I won't get to the qconfig nicer diff/merge tool selection so it will need to come later [04:55] igc: also, why for you need this code in do_start: [04:55] 280 + cwd = urlutils.local_path_to_url(os.getcwd()) + '/' [04:55] 281 + if cwd != dest: [04:55] 282 + args.append(dest) [04:55] 283 + self.process_widget.do_start(None, 'uncommit', *args) [04:55] igc: never never never never never use bare os.getcwd()!!! [04:55] os.getcwdu() [04:56] bialix: ah - ok [04:56] but I think that code is useless [04:56] you need just append branch location [04:56] and most important! [04:56] quncommit should operate on working tree root, not branch root! [04:57] because if you have light checkout you've got wrong thing [04:57] see qmerge as example [04:57] bialix: but it needs to work on a treeless branch [04:57] qpull then [04:57] igc: yes, it should [04:58] spiv: re: bug 250451, break-lock never suggests a URL, so I don't think your wording is an improvement. [04:58] bialix: ok, I'll take a look [04:58] igc: but if there is tree it should uncommit in the tree to update dirstate [04:58] Launchpad bug 250451 in bzr "break-lock suggests wrong URL for smart-server branches" [High,Confirmed] https://launchpad.net/bugs/250451 [04:59] igc: lib/html_log.py? [05:00] is it exisiting code from somewhere else? [05:00] bialix: code I use in explorer [05:00] ah [05:00] bialix: we could use qlog widget if I knew how [05:00] we have htmlize function in util.py instead of cgi.escape [05:01] but maybe it does not matter right now [05:01] This was a fun bug to run into today: https://bugs.launchpad.net/bzr/+bug/415936 [05:01] Ubuntu bug 415936 in bzr "Merge into new branch produces strange log" [Undecided,New] [05:02] igc: ok, so I've made almost full review over quncommit [05:02] bialix: thanks for the fast review [05:02] igc: I need to go to work, I'll check mails but will be busy [05:03] bialix: ok. Thanks [05:03] igc: qinfo is not critical for 0.14? [05:04] bialix: well, it breaks in explorer when users ask for Location Information on anything without a WT :-( [05:04] now qinfo better [05:05] but anyway something wrong when I'm resizing it [05:05] bialix: resizing is ok on Ubuntu fwiw [05:05] igc: perhaps I'll merge it anyway and we polish it later [05:05] wanna my screenshot? [05:06] bialix: please - it's a step forward definitely [05:06] yep [05:07] igc: http://imagebin.ca/view/21L7Di.html [05:08] igc: I'm just resize it by vertical up and dowm [05:08] down [05:08] bialix: might be a bug in QFormLayout in Qt 4.4 [05:08] poolie: ping [05:08] poolie: something is going wrong with your merges to bzr.dev [05:08] 1.18 is in there twice, and this morning hno reporting that changes from 1.18 are listed under 1.17 [05:09] igc: maybe, but it looks ugly nevertheless [05:09] ok, time runs out [05:09] * bialix disappears [05:09] bye for now [05:12] Hi, when I use *bzr push* to my branch on lauchpad.net, it shows that the"Unable to obtain lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock [05:12] held by xiaohui@bazaar.launchpad.net on host crowberry [process #10793] [05:12] locked 13 hours, 41 minutes ago [05:12] Will continue to try until 05:11:09, unless you press Ctrl-C [05:12] If you're sure that it's not being modified, use bzr break-lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock [05:12] bzr: ERROR: Could not acquire lock "(remote lock)": " [05:13] bzr break-lock lp:~xiaohui/opencog/moses [05:13] I use the *bzr break-lock lp:~/xiaohui/opencog/moses* but is unuseful [05:16] then it returns an error:bzr: ERROR: exceptions.TypeError: a float is required [05:16] xiaohui: what is your bzr version [05:16] I believe that was a bug that we have fixed [05:17] my version is 1.14 [05:17] I'm quite sure that that is fixed [05:20] xiaohui: upgrade your bzr, or use "nosmart+lp:~xiaohui/opencog/moses" (I think) as a workaround. [05:21] what is the *nosmart* mean [05:23] It disables most of the interesting smart protocol code, and just does direct file accesses. It's roughly equivalent to sftp. [05:24] If I'm remembering correctly, it also avoids that bug in that version of bzr. [05:27] hmm, it doesn't work [05:27] so I have to upgrade the bzr === abentley1 is now known as abentley [05:38] another error: [05:38] so what should I do? update the version of bzr [05:38] bzr: ERROR: Invalid url supplied to transport: "lp:~/xiaohui/opencog/moses": No such person or team: [05:39] why it said no such person or team [05:41] you've mispelt the url [05:41] you added a / between ~ and x [05:41] oh , my fault === abentley1 is now known as abentley [07:07] hi all [07:47] With bzr trunk, bzrtools tests are failing due to dirstate locks that did not fail previously: http://pastebin.ubuntu.com/256159/ Any ideas? [07:50] abentley: does that involve some transform_tree ? [07:51] abentley: https://code.launchpad.net/~lifeless/bzr/transform_tree/+merge/10440 may be related ? [07:51] vila: No, it doesn't involve that. [07:51] I' don't that's been merged yet tough [07:52] abentley: by the way, what TZ are you in right now ? 8-} [07:53] abentley: well, your pastebin shows a 'transform_tree' in the traceback, so have a look at lifeless patch maybe that's what you need [07:53] Perhaps America/Caffienated. [07:54] abentley: may be I should have said merge.transform_tree [07:54] abentley: you may find my merge request put up a couple hours ago fixes them [07:54] it fixed something like 1/2 the tests in bzr.dev that had been annotated as not being safe on windows [07:54] abentley: thanks for pointing out my thinko in that bug title. [07:55] spiv: np [07:55] abentley: if it doesn't fix them, you can make them pass by calling thisTestFailsStrictLocks() [07:55] vila: Okay, I could have sworn it was failing when opening the tree. [07:56] abentley: I've seen your announce for bzrtools-1.18 but no new commits on lp:bzrtools (and no tag either), that's what you're working on right now ? [07:56] abentley: hehe ,np, get more caffeine :0D [07:56] vila: did that just before posting to IRC. [07:57] abentley: excellent, pulled [07:58] lifeless: Your patch fixes my problem. [07:59] cool [08:23] hi vila? === AnMaster_ is now known as AnMaster [08:23] hey poolie1 [08:25] how's stuff? [08:26] good ! ;-D [08:28] is there anyway that I can tell bzr merge to always prefer the source tree if it encounters a text conflict? [08:37] mdke: no, but it'd be a nice feature to add [08:38] mdke: "bzr revert -r:parent `bzr conflicts`" or something like that would be a rough approximation. [08:47] poolie1: I'll file a bug I guess. [08:47] vila, beyond the stuff in the metronome mail i'm thinking about branching off 2.0 tomorrow [08:47] and then asking for only bug fixes into that [08:47] what do you think? [08:47] spiv: thanks, should I run that after the merge or instead of it? [08:47] poolie1: checking mail [08:49] poolie1: right, I agree, 1.18final today and 2.0 tomorrow [08:49] especially since karmic now passes the full test suite :-D [08:49] or monday [08:49] that's good [08:49] it'd be nice to fix some more of the critical 2.0 bugs firs [08:49] first* [08:51] poolie1: yeah and check with jam too [08:52] spiv: the merge command I'm running which gives me the conflicts is "bzr merge -r 147..150 ../intrepid" - any idea how I could adapt your formula to suit that? [08:55] poolie1: I'm fine with branching soon; just not 'releases' :) [08:57] brb [09:02] poolie1: by which I mean, 'do you want me to branch 2.0 when I get up tomorrow' [09:02] oh that'd be nice [09:05] spiv: nevermind - I've figured out that I can avoid the conflicts entirely by merging some earlier revisions first. Thanks for the help anyway though [09:09] oh i did mention that already [09:16] * igc dinner [09:20] lifeless: A small piece of information missing from your 2a format switch announcement.. which version are minimum required to use 2a repositories. [09:21] hno: 1.16 is the bare minimum, but its had _many many_ bugfixes since then [09:22] hno: I would recommend the absolute latest version you can get - 1.18rc1 at the moment, and 2.0 for sure once thats released, as there are still major bugs related to 2a. [09:22] (not in correctness, in performance regressions in various corner cases) [09:22] hno: the headsup announcement was preventative for folk tracking trunk; we assume those folk know this stuff somewhat :) [09:33] omg i just looked at the new project homepage https://edge.launchpad.net/bzr [09:33]