[00:00] <poolie> 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] <denys> with a _bare_ install, I can give you encrypted bzr server connections
[00:02] <denys> surely, that's an improvement (even if minute)
[00:02] <poolie> so is that the main difference in your view?
[00:04] <denys> yes - so far, it is something small that improves security and THEN makes possible authentication over an encrypted channel
[00:09] <dash> 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] <dash> unshelve seems to work OK, but it worries me a little. :)
[00:10] <dash> anything I can do to diagnose or fix this?
[00:10] <lifeless> dash: are you shelving only some changes?
[00:11] <lifeless> dash: also file a bug
[00:12] <dash> no, all of them
[00:12] <dash> OK
[00:12] <lifeless> what does bzr status show, if you can show me?
[00:12] <denys> 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] <lifeless> denys: there isn't any way to do that at the moment, the server doesn't assume a socket even exists
[00:13] <lifeless> denys: which is why I started talking about framing etc
[00:13] <dash> lifeless: mmm, this is proprietary code, so i probably can't show it to you verbatim
[00:14] <denys> lifeless: I know, but should I give up or is there value in trying to make that work?
[00:14] <lifeless> dash: feel free to transform the filenames
[00:14] <lifeless> dash: I want the structure
[00:14] <dash> but it's just 4 files modified, 3 files added, no pending merges, mucho unknowns
[00:14] <dash> OK
[00:14] <lifeless> denys: and whether specific items are directories or files
[00:15] <lifeless> 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] <poolie> denys, i thought i answered that, or at least pointed in the right direction
[00:15] <poolie> make the objects link to each other on the way up
[00:15] <poolie> so then the request can tell the socket to start encryption
[00:16] <lifeless> 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] <poolie> however, i really wish we could understand each other about ssh :-(
[00:17] <lifeless> oh wow
[00:17] <lifeless> http://www.techdirt.com/articles/20090328/1445494290.shtml
[00:17] <lifeless> copyright law fail
[00:17] <denys> 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] <lifeless> denys: what sort of things?
[00:18] <dash> lifeless: http://paste.ubuntu.com/256004/
[00:18] <poolie> lifeless: mm i saw, that's a bit awful
[00:18] <denys> lifeless: I can't sell it to admins
[00:18] <lifeless> denys: it doesn't need system users though, or even to be on port 22
[00:18] <poolie> mind you it'd probably be infeasible to run such a service _at all_ in au or uk because of libel law
[00:18] <denys> I can't sell restricted shells
[00:19] <lifeless> denys: it doesn't even need a shell
[00:19] <poolie> the SMH restaurant reviewer was sued for criticizing a restaurant
[00:19] <denys> lifeless: you cannot reason it.  this is not a reasonable requirement . it just is. and I have to deal with it.
[00:20] <lifeless> 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] <denys> they worry about it, but at least they have pretty goof hanlde on that
[00:21] <lifeless> 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] <poolie> ah :)
[00:21] <denys> s/goof/good/
[00:21]  * poolie made the classic mistake of assuming the requirements were rational
[00:21] <denys> i have spent 3 years of lobbying :-(
[00:22] <denys> what I have got is pretty good compared with we what we had before
[00:23] <lifeless> so
[00:23] <lifeless> one possibly thing to do would be to make bzrs be bzr+ssh :)
[00:23] <lifeless> and just not tell anyone
[00:24] <denys> lifeless: you don't work at a university ibviously
[00:24] <denys> ;-)
[00:24] <poolie> so
[00:24] <lifeless> denys: I used to
[00:25] <poolie> 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] <denys> lifeless: last time we did domething that the security officer didn#t approve of, he cut the entire university network
[00:25] <lifeless> denys: wow
[00:25] <poolie> if it's ssh but you must send the string 'cest la vie' before you start is that ok?
[00:25] <denys> yeah!
[00:26] <denys> poolie: no dice
[00:26] <poolie> ok
[00:26] <poolie> so that probably explains the confusion
[00:26] <poolie> i think at least some other it departments would actually prefer people use standard secured protocols
[00:26] <lifeless> its a form of conflation
[00:27] <poolie> mm
[00:27] <lifeless> 'ssh' is being conflated with implementations that have various implications
[00:27] <poolie> i've heard, years ago, of ssh being banned in favor of telnet
[00:27] <poolie> i'm not sure if it was that they wanted to sniff your traffic, or just fear of the new
[00:27] <denys> they may eventually come that conclusion themselve, but it CANNOT be thrust upon them
[00:28] <AfC> poolie: fear of the new
[00:28] <lifeless> right
[00:28] <AfC> denys: [and, that's very astute]
[00:29] <igc> morning
[00:29] <poolie> denys: so, ok,
[00:29] <poolie> sheesh
[00:29] <igc> poolie: the quick references cards did move some weeks back, yes
[00:29] <poolie> i'd like to help you out here but i'd also like something that makes sense for other people
[00:30] <poolie> and i think that's more likely to be builtin ssh
[00:30] <poolie> how about if you write a small separate program that works just like ssh but is not actually ssh
[00:30] <lifeless> rephrase
[00:30] <lifeless> 'uses the same encryption as ssh'
[00:30] <poolie> in other words it opens an ssl connection, sends a username and password, then runs a server process
[00:30] <lifeless> :)
[00:30] <poolie> no, not the same protocol
[00:31] <poolie> so from bzr's point of view it will be 'program that gives me a connection to the server'
[00:31] <poolie> and 'program that starts the server in inetd mode'
[00:31] <denys> 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] <denys> the other consideration is: how hard is it to set up
[00:32] <denys> I can guarantee you that setting things up on the university server is unbelievably hard
[00:32] <poolie> i can believe it
[00:33] <poolie> i'm reminded of getting an hp-ux account with no compiler and not even any cursor key support in the shell
[00:33] <poolie> that gets very very tedious
[00:33] <poolie> anyhow, if you put up clean patches, we can certainly look at them
[00:34] <denys> my tack is to promove virtual servers - but I still have to ackonoledge the authentication rules set up by the univesity
[00:34] <poolie> i think your requirements here are weird enough they're not necessarily what we'd generally recommend
[00:34] <denys> oops
[00:34] <poolie> but maybe it will turn out to be generally useful
[00:34] <denys> my requirement are not weird. they are just what we have to deal with in france
[00:34] <poolie> lifeless & others: so on another topic, i'm wondering if rather than 1.18final we should do 2.0beta1 today
[00:34] <poolie> with the format set
[00:35] <poolie> acknowledging we'll need more bug fixes, but we may not need anything other than bug fixes
[00:35] <poolie> well, some things like selected-file commit may need to be fudged as bug fixes; they arguably are
[00:35] <lifeless> poolie: uhm
[00:35] <lifeless> poolie: I really think we're confusing people by changing the release labelling before 2.0
[00:36] <lifeless> there isn't a stable that we have been patching
[00:36] <lifeless> so I'm very much in favour of 1.18
[00:36] <poolie> to take a step back
[00:36] <lifeless> and only changing the labelling at 2.0
[00:36] <poolie> we could release 1.18final
[00:36] <poolie> off that branch
[00:36] <poolie> and then immediately release 2.0b1 at the base of a new branch
[00:36] <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:37] <poolie> what's wrong with 2.0~beta1?
[00:37] <poolie> you can't have tildes in the upstream version?
[00:37] <lifeless> a ~ means sort before
[00:38] <poolie> right
[00:38] <lifeless> but its not part of the python version spec
[00:38] <lifeless> which you said you wanted to follow
[00:38] <poolie> istm (2, 0, 0, 'beta', 1) [00:38] <poolie> what is the problem?
[00:39] <lifeless> that works for me I think
[00:39] <poolie> surely that's the commonsense way to represent it in both systems?
[00:41] <lifeless> well, I'm only aware of ~ having this sort before meaning for dpkg specifically.
[00:41] <lifeless> 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] <lifeless> poolie: has it been 4 weeks since we released 1.18rc1?
[00:41] <poolie> i seem to be having a bad morning for communication
[00:41] <poolie> no
[00:41] <poolie> it's been a week and a half
[00:42] <lifeless> then I think we should wait ;)
[00:42] <poolie> you said
[00:42] <poolie> > 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] <poolie> i think i answered that
[00:42] <lifeless> sure
[00:43] <poolie> i don't think we have to use the tilde anywhere else
[00:43] <poolie> in source or windows exe files it can be just 2.0beta1
[00:43] <poolie> for rpms iirc they already have a special sort algorithm that treats 'beta' as meaning 'before'
[00:50] <poolie> lifeless: btw i suppose you implicitly fixed https://bugs.edge.launchpad.net/bzr/+bug/413584 ?
[00:52] <poolie> i marked it fixed
[00:53] <lifeless> so did I:P
[00:57] <AfC> Um
[00:57] <AfC> 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] <poolie> bzr info?
[00:57] <AfC> All I was trying to do was `bzr pull`
[00:57] <lifeless> AfC: is that a checkout ?
[00:57] <lifeless>  / bound branch
[00:57] <AfC> poolie: Repository checkout (format: 1.14-rich-root)
[00:57] <AfC>   repository checkout root: .
[00:57] <AfC>         checkout of branch: http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
[00:58] <AfC> lifeless: yes
[00:58] <lifeless> AfC: ok, so this is a bug
[00:58] <AfC> bzr 1.17 brand newly installed
[00:58] <lifeless> we're not matching urls correctly
[00:58] <lifeless> bzr unbind
[00:58] <AfC> k
[00:58] <lifeless> bzr bind http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk
[00:58] <AfC> && pull?
[00:58] <lifeless> then you'll be back to normal
[00:58] <lifeless> and can use bzr update again
[00:58] <fullermd> Bug?  Isn't that just what you'd expect to do when pulling a checkout over http?
[00:59] <AfC> [sometimes I think that you guys should kill "checkout" and only offer branch & bind.
[00:59] <lifeless> fullermd: no, the %7E != ~
[00:59] <fullermd> Sure, but what's that matter?
[00:59] <AfC> or, only offer branch ^W checkout & bind, etc]
[00:59] <fullermd> If you're trying to pull INTO a http://something, you'd expect locking failure since it isn't writable.
[00:59] <lifeless> fullermd: it fails the test in bzr.pull for master == source url
[00:59] <lifeless> fullermd: trust me :) look in malone if you want the gory details
[01:00] <fullermd> Well, maybe there's another bug there, but it *SHOULD* fail writing over HTTP regardless of any other matching.
[01:00] <AfC> I was trying to *pull*
[01:00] <lifeless> fullermd: pulling from the master of a bound branch pulls locally only
[01:00] <fullermd> In a checkout.  Which means the branch you're trying to write to is across HTTP.
[01:00] <AfC> And then I recalled I really ought to "update"
[01:01] <lifeless> can we please not paint the chicken a new colour right now?
[01:01] <fullermd> It WHAT?  That sounds like an insane level of DWIM...
[01:01] <AfC> (/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] <lifeless> 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] <lifeless> fullermd: its part of the original bind patch I think
[01:02] <AfC> lifeless, poolie: thanks Robert & Martin. Fixed.
[01:02]  * AfC relocates
[01:54] <lifeless> brb, fooding
[02:13] <lifeless> dash: sorry, distractions
[02:14] <lifeless> dash: so, uhm shelve is failing
[02:14] <dash> yes
[02:14] <lifeless> and you're doing shelve --all ?
[02:14] <dash> using shelve1 at the moment in bzrtools
[02:14] <dash> lifeless: well i hit 'f' at the first prompt so basically
[02:14] <lifeless> to humour me, could you try shelve --all?
[02:15] <dash> sure
[02:15] <lifeless> also are there any pending merges?
[02:15] <dash> no pending merges
[02:15] <lifeless> kk
[02:15] <dash> same error using --all
[02:15] <lifeless> ok
[02:15] <lifeless> definitely file a bug
[02:15] <dash> except it says new-6 now, don't know if that's related to pulling new revs since i tried last
[02:15] <lifeless> nope
[02:15] <lifeless> you've modified another file probably
[02:16] <dash> the parent of this branch is an svn branch, don't know if that's relevant
[02:16] <lifeless> it might be; but the shelve operation is all local so shouldn't be
[02:17] <dash> ok
[02:17] <dash> guess i'll try this with 1.18rc1 too
[02:17] <dash> thanks
[02:24] <mozmck> 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] <mozmck> This is what I get when I try to run olive-gtk:  Traceback (most recent call last):
[02:26] <mozmck>   File "/usr/local/bin/olive-gtk", line 89, in <module>
[02:26] <mozmck>     import bzrlib.plugins.gtk.ui as ui
[02:26] <mozmck> ImportError: No module named gtk.ui
[03:10] <spiv> mozmck: sounds like you hvaen't got the bzr-gtk plugin installed
[03:19] <mozmck> spiv: that's what I installed from source: bzr-gtk-0.96.2
[03:19] <mozmck> I'm running bzr 1.17 from the ppa deb package
[03:20] <lifeless> how did you install it
[03:20] <mozmck> ./setup.py install I think.
[03:21] <lifeless> it may have installed to something not on your python path
[03:21] <mozmck> oh, how would I find that out?  where is the python path?
[03:22] <lifeless> if you touch one of the source files
[03:22] <lifeless> like __init__.py
[03:22] <lifeless> and install it again, you can see the path it installs the python files to
[03:22] <mozmck> touch it?
[03:23] <AfC> $ touch path/to/filename.py
[03:24] <mozmck> ah, changes the timestamp.  Then how do I find it once installed?
[03:24] <lifeless> the installer outputs stuff
[03:24] <lifeless> read what it outputs :)
[03:25] <mozmck> /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk
[03:25] <lifeless> and now
[03:25] <lifeless> python -c "import sys; print sys.path"
[03:26] <mozmck> '/usr/local/lib/python2.6/dist-packages' is at the end of the printout
[03:27] <lifeless> ok
[03:27] <lifeless> python -c "import bzrlib; print bzrlib.__path__"
[03:28] <mozmck> ['/usr/lib/python2.6/dist-packages/bzrlib']
[03:28] <lifeless> so, this is a python limitation; by default it doesn't really know how to deal with different locations like that
[03:28] <lifeless> 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] <mozmck> ah, so I need to tell it to install in /usr/lib somehow
[03:29] <mozmck> I'll try that
[03:33] <mozmck> 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] <mozmck> so should the nautilus stuff work after I log out and back in?
[03:34]  * igc lunch
[04:32] <lifeless> so, it feels like every tweet gets a new spam follower
[04:44] <bialix> igc: hi
[04:45] <igc> hi bialix
[04:45] <igc> bialix: is qinfo better now?
[04:45] <bialix> igc, what version of PyQt/Qt you're have?
[04:46] <bialix> similar problem with layout and in quncommit
[04:46] <igc> bialix: PyQt 4.4.4, Qt 4.5.0
[04:46] <igc> bilaix: jaunty
[04:47] <igc> bialix: I'm seeing crap layout in quncommit - I'm yet to try tuning that, I just wanted something working first
[04:47] <bialix> what strange combination!
[04:47] <igc> bialix: qinfo is ok for me though
[04:48] <bialix> I think PyQt should be 4.5.x too
[04:48] <bialix> weird weird weird
[04:48] <bialix> wait a sec
[04:49] <bialix> igc: http://imagebin.ca/view/RdaTOA.html
[04:49] <bialix> this is what I see by default
[04:49] <bialix> "move tip to" group should not be elastic. progress widget should be
[04:50] <igc> bialix: ok
[04:50] <lifeless> vila: hi :P
[04:51] <bialix> igc: there is several places that needs fixing in quncommit, unfortunately I have urgent work...
[04:51] <igc> bialix: karmix will be pyqt 4.5.2, qt 4.5.1 by the look of things
[04:51]  * vila snores
[04:51] <bialix> igc: how about next plan: I'll merge quncommit as is but make it idden command
[04:51] <bialix> *hidden
[04:52] <igc> bialix: if you can, let me fix it in the next hour or two
[04:52] <igc> bialix: can the 0.14 release wait another few hours?
[04:52] <bialix> igc: I will do release tonight in my tz, ~ +12 hours from now. But you'll be sleeping
[04:53] <igc> bialix: cool. I have another 2-3 things to clean up so I'll have them up for review asap
[04:54] <igc> bialix: I won't get to the qconfig nicer diff/merge tool selection so it will need to come later
[04:55] <bialix> igc: also, why for you need this code in do_start:
[04:55] <bialix> 280	+ cwd = urlutils.local_path_to_url(os.getcwd()) + '/'
[04:55] <bialix> 281	+ if cwd != dest:
[04:55] <bialix> 282	+ args.append(dest)
[04:55] <bialix> 283	+ self.process_widget.do_start(None, 'uncommit', *args)
[04:55] <bialix> igc: never never never never never use bare os.getcwd()!!!
[04:55] <bialix> os.getcwdu()
[04:56] <igc> bialix: ah - ok
[04:56] <bialix> but I think that code is useless
[04:56] <bialix> you need just append branch location
[04:56] <bialix> and most important!
[04:56] <bialix> quncommit should operate on working tree root, not branch root!
[04:57] <bialix> because if you have light checkout you've got wrong thing
[04:57] <bialix> see qmerge as example
[04:57] <igc> bialix: but it needs to work on a treeless branch
[04:57] <bialix> qpull then
[04:57] <bialix> igc: yes, it should
[04:58] <abentley> spiv: re: bug 250451, break-lock never suggests a URL, so I don't think your wording is an improvement.
[04:58] <igc> bialix: ok, I'll take a look
[04:58] <bialix> igc: but if there is tree it should uncommit in the tree to update dirstate
[04:59] <bialix> igc: lib/html_log.py?
[05:00] <bialix> is it exisiting code from somewhere else?
[05:00] <igc> bialix: code I use in explorer
[05:00] <bialix> ah
[05:00] <igc> bialix: we could use qlog widget if I knew how
[05:00] <bialix> we have htmlize function in util.py instead of cgi.escape
[05:01] <bialix> but maybe it does not matter right now
[05:01] <davidstrauss> This was a fun bug to run into today: https://bugs.launchpad.net/bzr/+bug/415936
[05:02] <bialix> igc: ok, so I've made almost full review over quncommit
[05:02] <igc> bialix: thanks for the fast review
[05:02] <bialix> igc: I need to go to work, I'll check mails but will be busy
[05:03] <igc> bialix: ok. Thanks
[05:03] <bialix> igc: qinfo is not critical for 0.14?
[05:04] <igc> bialix: well, it breaks in explorer when users ask for Location Information on anything without a WT :-(
[05:04] <bialix> now qinfo better
[05:05] <bialix> but anyway something wrong when I'm resizing it
[05:05] <igc> bialix: resizing is ok on Ubuntu fwiw
[05:05] <bialix> igc: perhaps I'll merge it anyway and we polish it later
[05:05] <bialix> wanna my screenshot?
[05:06] <igc> bialix: please - it's a step forward definitely
[05:06] <igc> yep
[05:07] <bialix> igc: http://imagebin.ca/view/21L7Di.html
[05:08] <bialix> igc: I'm just resize it by vertical up and dowm
[05:08] <bialix> down
[05:08] <igc> bialix: might be a bug in QFormLayout in Qt 4.4
[05:08] <lifeless> poolie: ping
[05:08] <lifeless> poolie: something is going wrong with your merges to bzr.dev
[05:08] <lifeless> 1.18 is in there twice, and this morning hno reporting that changes from 1.18 are listed under 1.17
[05:09] <bialix> igc: maybe, but it looks ugly nevertheless
[05:09] <bialix> ok, time runs out
[05:09]  * bialix disappears
[05:09] <igc> bye for now
[05:12] <xiaohui> 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] <xiaohui> held by xiaohui@bazaar.launchpad.net on host crowberry [process #10793]
[05:12] <xiaohui> locked 13 hours, 41 minutes ago
[05:12] <xiaohui> Will continue to try until 05:11:09, unless you press Ctrl-C
[05:12] <xiaohui> If you're sure that it's not being modified, use bzr break-lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock
[05:12] <xiaohui> bzr: ERROR: Could not acquire lock "(remote lock)": "
[05:13] <lifeless> bzr break-lock lp:~xiaohui/opencog/moses
[05:13] <xiaohui> I use the *bzr break-lock lp:~/xiaohui/opencog/moses* but is unuseful
[05:16] <xiaohui> then it returns an error:bzr: ERROR: exceptions.TypeError: a float is required
[05:16] <lifeless> xiaohui: what is your bzr version
[05:16] <lifeless> I believe that was a bug that we have fixed
[05:17] <xiaohui> my version is 1.14
[05:17] <lifeless> I'm quite sure that that is fixed
[05:20] <spiv> xiaohui: upgrade your bzr, or use "nosmart+lp:~xiaohui/opencog/moses" (I think) as a workaround.
[05:21] <xiaohui> what is the *nosmart*  mean
[05:23] <spiv> It disables most of the interesting smart protocol code, and just does direct file accesses.  It's roughly equivalent to sftp.
[05:24] <spiv> If I'm remembering correctly, it also avoids that bug in that version of bzr.
[05:27] <xiaohui> hmm, it doesn't work
[05:27] <xiaohui> so I have to upgrade the bzr
[05:38] <xiaohui> another error:
[05:38] <xiaohui> so what should I do? update the version of bzr
[05:38] <xiaohui> bzr: ERROR: Invalid url supplied to transport: "lp:~/xiaohui/opencog/moses": No such person or team:
[05:39] <xiaohui> why it said no such person or team
[05:41] <lifeless> you've mispelt the url
[05:41] <lifeless> you added a / between ~ and x
[05:41] <xiaohui> oh , my fault
[07:07] <vila> hi all
[07:47] <abentley> 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] <vila> abentley: does that involve some transform_tree ?
[07:51] <vila> abentley: https://code.launchpad.net/~lifeless/bzr/transform_tree/+merge/10440 may be related ?
[07:51] <abentley> vila: No, it doesn't involve that.
[07:51] <vila> I' don't that's been merged yet tough
[07:52] <vila> abentley: by the way, what TZ are you in right now ? 8-}
[07:53] <vila> 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] <abentley> Perhaps America/Caffienated.
[07:54] <vila> abentley: may be I should have said merge.transform_tree
[07:54] <lifeless> abentley: you may find my merge request put up a couple hours ago fixes them
[07:54] <lifeless> it fixed something like 1/2 the tests in bzr.dev that had been annotated as not being safe on windows
[07:54] <spiv> abentley: thanks for pointing out my thinko in that bug title.
[07:55] <abentley> spiv: np
[07:55] <lifeless> abentley: if it doesn't fix them, you can make them pass by calling thisTestFailsStrictLocks()
[07:55] <abentley> vila: Okay, I could have sworn it was failing when opening the tree.
[07:56] <vila> 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] <vila> abentley: hehe ,np, get more caffeine :0D
[07:56] <abentley> vila: did that just before posting to IRC.
[07:57] <vila> abentley: excellent, pulled
[07:58] <abentley> lifeless: Your patch fixes my problem.
[07:59] <lifeless> cool
[08:23] <poolie1> hi vila?
[08:23] <vila> hey poolie1
[08:25] <poolie1> how's stuff?
[08:26] <vila> good ! ;-D
[08:28] <mdke> is there anyway that I can tell bzr merge to always prefer the source tree if it encounters a text conflict?
[08:37] <poolie1> mdke: no, but it'd be a nice feature to add
[08:38] <spiv> mdke: "bzr revert -r:parent `bzr conflicts`" or something like that would be a rough approximation.
[08:47] <mdke> poolie1: I'll file a bug I guess.
[08:47] <poolie1> vila, beyond the stuff in the metronome mail i'm thinking about branching off 2.0 tomorrow
[08:47] <poolie1> and then asking for only bug fixes into that
[08:47] <poolie1> what do you think?
[08:47] <mdke> spiv: thanks, should I run that after the merge or instead of it?
[08:47] <vila> poolie1: checking mail
[08:49] <vila> poolie1: right, I agree, 1.18final today and 2.0 tomorrow
[08:49] <vila> especially since karmic now passes the full test suite :-D
[08:49] <poolie1> or monday
[08:49] <poolie1> that's good
[08:49] <poolie1> it'd be nice to fix some more of the critical 2.0 bugs firs
[08:49] <poolie1> first*
[08:51] <vila> poolie1: yeah and check with jam too
[08:52] <mdke> 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] <lifeless> poolie1: I'm fine with branching soon; just not 'releases' :)
[08:57] <mdke> brb
[09:02] <lifeless> poolie1: by which I mean, 'do you want me to branch 2.0 when I get up tomorrow'
[09:02] <poolie1> oh that'd be nice
[09:05] <mdke> 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] <poolie1> oh i did mention that already
[09:16]  * igc dinner
[09:20] <hno>  lifeless: A small piece of information missing from your 2a format switch announcement.. which version are minimum required to use 2a repositories.
[09:21] <lifeless> hno: 1.16 is the bare minimum, but its had _many many_ bugfixes since then
[09:22] <lifeless> 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] <lifeless> (not in correctness, in performance regressions in various corner cases)
[09:22] <lifeless> hno: the headsup announcement was preventative for folk tracking trunk; we assume those folk know this stuff somewhat :)
[09:33] <poolie1> omg i just looked at the new project homepage https://edge.launchpad.net/bzr
[09:33] <poolie1> that is really nice
[09:35] <bob2> tad verbose
[09:35] <poolie1> mm the bit about packaging does not scale well
[09:35] <bob2> yeah
[09:36] <vila> poolie1: I had the same reaction yesterday evening
[09:37] <bob2> ah, looks less insane on a small monitor
[09:38] <bob2> on 24" the downloads stuff falls the bottom of the packages list
[09:40] <hno> lifeless: I would not bet on it..  memory quickly fades on in which version a format was added, and even quicker on which versions may have had serious bugs in the format...
[09:41] <lifeless> :)
[09:41] <lifeless> we'll make a serious song and dance about it when 2.0 is actually released.
[09:42] <lifeless> bob2: and they say size doesn't matter.
[09:45] <hno> regarding the new project page.. I agree that the packaging do not scale. Currently overly overbose, and sorted "wrongly". Should have most recent distribution first, and only list the current release per distribution by default with the full history collapsed.
[09:48] <marcchr> hi
[09:48] <marcchr> I have a problem merging from a bzr-branch into a svn-checkout. I get "AttributeError: 'Revision' object has no attribute 'foreign_revid'"
[09:49] <marcchr> http://pastebin.ubuntu.com/256202/
[09:51] <marcchr> bzr branch spam /tmp/test-zr; [modify something in test-zr and commit]; in spam: bzr merge /tmp/test-zr gives the error
[09:51] <marcchr> spam is the svn checkout
[10:04] <poolie1> marcchr: probably your copy of bzr-svn is out of date with bzr
[10:04] <poolie1> otherwise please file a bug in bugs.launchpad.net/bzr-svn
[10:05] <vila> lifeless: care to have a look at https://code.edge.launchpad.net/~vila/bzr/selftest-fixes/+merge/10364  ?
[10:05] <marcchr> bzr-svn 0.6.4 is the latest if I'm not mistaken?
[10:06] <marcchr> poolie1: ok, I will file a bug
[10:06] <marcchr> poolie1: I'm using bzr 1.17
[10:09] <poolie1> ok good night all
[10:11] <vila> poolie1: good night !
[10:26] <fullermd> Ooh, ...544432 for the 1.18 tar.  How cute.
[10:28] <vila> fullermd: Is that the size ?
[10:28] <fullermd> No, the lplibrarian dir.
[10:32]  * fullermd tosses ports updates out into the aether.
[11:28] <spirov92> hey, a quick question...
[11:28] <spirov92> if I in a branch I make a link to another branch(say, a module) how will bzr handle it?
[11:28] <spirov92> I mean a symlink
[11:30] <bob2> as a symlink
[11:30] <spirov92> but if the module folder has a .bzr folder, will it try to version it?
[11:31] <bialix> igc: are you still around?
[11:31] <bialix> igc: question about quncommit
[11:32] <igc> hi bialix
[11:32] <bialix> hi igc, I have some time to look at quncoomit
[11:32] <bialix> it looks better now
[11:32] <fullermd> spirov92: The symlink isn't dereferenced.  It's just stores as a symlink.
[11:32] <bialix> igc: I just wonder about terms, like tip
[11:33] <bialix> igc: why you're using idiom "move tip to"?
[11:33] <igc> bialix: would you prefer another name like "head"?
[11:33] <bialix> igc: this is not blocks me from merge, but if you have couple of minutes, I'd better ask
[11:34] <bialix> igc: no, I mean why we talk about moving tip and not about uncommit actually?
[11:34] <bialix> igc: e.g. we can show revision details under first radiobutton
[11:35] <bialix> and put the label for radiobutton: Uncommit last revision:
[11:35] <bialix> igc: actually I have troubles to correctly translate tip, and it does not seem bzr uses "tip" term internally or in the docs
[11:36] <igc> bialix: firstly, I think 'tip' is fine ...
[11:36] <igc> from core-concepts in the User Guide: The last revision is known as the *tip*
[11:36] <bialix> igc: ok, I did not know this
[11:37] <bialix> so I can translate tip as "last revision"?
[11:37] <igc> bialix: yes
[11:37] <bialix> I understand that "tip" is short and nice word in English
[11:37] <bialix> as many others: pull and push
[11:37] <igc> bialix: also, we need to display what revisions will be removed anyhow so there seems limited benefit in displaying that in advance
[11:38] <igc> bialix: I thought pretty hard about that and ...
[11:38] <bialix> it so nice to be Englishman and speak in so wonderful language
[11:38] <igc> I've been through several designs on paper over the last few months thinking about quncommit
[11:38] <bialix> igc: what if I want uncommit 100 last revisions?
[11:39] <bialix> what I'll see in confirmation dialog then?
[11:39] <igc> bialix: we'll display those just like the CLI does
[11:39] <igc> bialix: that would be very unusual, of course
[11:39] <bialix> on CLI any long info go out of my console
[11:40] <bialix> this becomes problem for GUI
[11:40] <igc> bialix: 99% of the time it's just one revision - to fix the commit message, bug metadata, etc :-)
[11:40] <bialix> you just can't have an infinite tall dialog, do you? ;-)
[11:40] <bialix> igc: so if this is 99% cases, why not show ther details right in the quncommit window?
[11:40] <igc> bialix: I guess we could use a scrolling panel or the qlog widget
[11:41] <igc> bialix: I'm ok with doing that
[11:41] <igc> bialix: I just don't think it's mandatory
[11:41] <igc> to land this
[11:41] <bialix> igc: no of course.
[11:41] <bialix> igc: +1 on land the last version
[11:42] <igc> bialix: thanks. Did you want to merge it or I?
[11:42] <bialix> igc: I'm just want to discuss with you how it could be improved, especially re better UI for translations to other languages
[11:42] <bialix> igc: if you can, merge n push it yourself
[11:42] <igc> bialix: no problem. I do think it can be improved
[11:42] <igc> bialix: but that can come later
[11:43] <bialix> yes, of course
[11:43] <igc> bialix: what about my qbind tweak?
[11:43] <bialix> but later I forgot what I'm thinking right now
[11:43] <bialix> qbind tweak sounds ok conceptually
[11:43]  * bialix looks at qbind patch now
[11:44] <igc> bialix: there have been a few threads re that on the main bzr list so ...
[11:44] <igc> I thought we'd make the GUI better at least
[11:44] <bialix> igc: can we just dump this discussion about quncommit to new bug report?
[11:44] <bialix> so I don't forget about it later?
[11:44] <igc> bialix: sure. Also, qexport should be cleaner now though ...
[11:45] <igc> bialix: I suspect it's still not perfect wrt lightweight checkouts
[11:45] <igc> bialix: but it ought to be a small tweak from here I hope
[11:50] <bialix> rats, what's going on with lp?
[11:51] <bialix> igc: what you mean when said: "there have been a few threads re that on the main bzr list so ..."?
[11:52] <igc> bialix: about checkout vs branch+bind
[11:53] <bialix> I'm lack context. This is related to qbind?
[11:54] <igc> bialix: yes. Basically having a bind checkbox on qbranch is desirable
[11:54] <igc> bialix: until then, it's nicer if qbind defaults to the parent if never bound before
[11:55] <bialix> igc: there is combain qgetnew
[11:55] <bialix> *combine
[11:55] <bialix> it do everything and makes you sandwitch
[11:55] <igc> bialix: right, but it's worth improving qbind anyway
[11:55]  * bialix looking at qbind actually
[11:55] <igc> bialix: I'm yet to warm to qgetnew
[11:56] <igc> bbiab
[11:56]  * bialix is not fun of qget new
[11:58] <bialix> igc: qbind patch is ok for me
[11:59] <bialix> igc: perhaps I'll look at qexport improvements later
[12:02] <bialix> igc: if you have any specific plans about releasing bzr-explorer let me know beforehand, I need to update translations
[12:27] <garyvdm> Hi all
[12:27]  * garyvdm was looking for jam
[12:28] <bialix> Hi garyvdm
[12:28] <bialix> too early for jam ,I guess
[12:39] <luks> bah, this reminds me why I stopped caring about bzr development
[12:49] <bialix> luks: ?
[12:52] <luks> bialix: nothing, I just read about the 2.0 branching and having a patch submitted at the start of 2.0dev cycle, it reminded me how non-Canonical patches are handled
[12:52] <luks> it's very demotivating
[12:53] <bialix> luks: I'm still under impression of discussion about review processes, I was guess it's relates
[12:54] <bialix> luks: yeah, it seems better way to ensure your patch will be merged is to poke people in this chat
[12:58] <fullermd> It IS rather disencouraging.
[12:59] <fullermd> Also makes one want to skip NEWS entries.  You know it'll just cause conflicts that have to be manually fixed anyway, 2 releases later when it's applied.
[13:17] <garyvdm> Hi bialix/luks
[13:17] <garyvdm> Hmm my irc is dodge. I can see bialix said hello to me here: http://irclogs.ubuntu.com/2009/08/20/%23bzr.html , but not in my irc client, and I was signed in....
[13:18] <bialix> your client seems timed out and reconnect then
[13:19] <garyvdm> luks: :-(  You should raise that as an issue.
[13:19] <bialix> I've heard this from luks beginnign from 2007
[13:22] <luks> garyvdm: it's not something I care that much about, it's just sad that bzr is even a GNU project, but the development process is far from the open source standard
[13:23] <fullermd> Well, I wouldn't go that far...
[13:23] <luks> I would :)
[13:23] <fullermd> But that's more a statement on the state of the 'open source standard'.
[13:24] <luks> well, I wouldn't say a word if patches were ignored and there were no releases
[13:24] <luks> but the issue is very visible with monthly releases
[13:35] <garyvdm> bailix: Anything important that you want me to look at for 0.14?
[13:36] <bialix> garyvdm: I guess everything is ok
[13:36] <bialix> luks mentioned slower startup of qcommit
[13:36] <bialix> I see this too
[13:36] <fullermd> I came across some annoying behavior in qlog that I'm not sure is a bug (or how to describe concisely if it is)...
[13:36] <bialix> I guess the problem in new treewidget stuff
[13:36] <luks> that's not easy to fix, I guess
[13:37] <bialix> garyvdm, luks: I'm still mulling the idea, but I have a feeling that we need either threads for long running stuff or launch subprocess to do heavy work and implement some sort of rpc
[13:37] <fullermd> Clicking on a rev in the list selects it, but there's no way to un-select it.
[13:37] <bialix> and implement multi-pass visualisation for things
[13:38] <bialix> garyvdm: no, I remember
[13:38] <luks> bialix: well, that will not make it faster, just more responsive
[13:38] <bialix> garyvdm: problem with misadded
[13:38] <fullermd> When you expand a branch in the history, it redraws the window, and adjusts placement to show the selected row, if there is one.
[13:38] <bialix> luks: if we populate the widget in qcommit with simplke data and then add more data, e.g. icons
[13:38] <fullermd> So, if you've selected a rev, scroll around a while, then expand a branch, *pow* you're dragged way the heck away from what you just expanded.
[13:39] <bialix> fullermd, garyvdm: I think it was fixed recently?
[13:39] <garyvdm> My irc seems very delayed.
[13:39] <garyvdm> bialix: bug 414729.
[13:39] <bialix> garyvdm: yes
[13:40] <bialix> garyvdm: I found the way how to hide this items from qcommit
[13:40] <bialix> but not from qbrowse
[13:41] <garyvdm> fullermd: Thats has been fixed.
[13:41] <fullermd> Hm, guess so.  Can I borrow this time machine sometime?
[13:42] <garyvdm> fullermd: in rev 902
[13:42] <bialix> fullermd: you're always welcome
[13:42] <fullermd> Doubly irritating since I was at 901   :p
[13:42] <bialix> garyvdm: here where I've started http://pastebin.com/m1cee143
[13:42] <luks> :)
[13:42] <bialix> lol
[13:43] <garyvdm> bialix: re bug 414729: we can just filter out the item in the FilterProxyModel.
[13:44] <bialix> garyvdm: we need the list of misadded for qcommit to implicitly commit them
[13:48] <garyvdm> bialix: I just checked on this: The FilterProxyModel affects what is displayed, but not what is passed to the command line. - So that would be the place to do it.
[13:49] <bialix> garyvdm: that's nice!
[13:49] <garyvdm> bialix: You will see in the FilterProxyModel that we allways show an item that is checked, so you will have to override that.
[13:51] <garyvdm> bialix: I'm going to do some profiling of qcommit. I be afk from about 4pm to about 8pm UTC+2
[13:51] <bialix> garyvdm: I'll start prepare release after 8pm UTC+2
[13:51] <bialix> and will be in iRC
[13:55] <davertron> hi, I'm getting "Cannot lock LockDir" when I try to pull from a remote repo due to a permission denied error trying to write to .bzr/branch/lock; however, if i go look at that directory, my user belongs to the right group and that group has write permission on that directory. Any idea what I'm doing wrong?
[13:57] <garyvdm> luks, bialix: In what situations is qcommit load slow. It is quick for me.
[13:58] <davertron> also, another interesting thing is that the parent branch isn't the directory where I get the error from
[13:58] <bialix> garyvdm: it's not slow as "really sloooooooooooooow". it's just now slower than before treewidget landed
[13:58] <bialix> qbrowse too
[13:59] <garyvdm> luks, bialix: If you have a situation that is slow, please email me a .callgrind.
[13:59] <garyvdm> davertron: please will you pastebin the last entry of ~/.bzr.log
[14:01] <davertron> garyvdm: from the directory i'm trying to pull from or the one i'm pulling to, or does it matter?
[14:02] <garyvdm> davertron: there will only be one on your computer.
[14:02] <garyvdm> davertron: are you on windows?
[14:02] <davertron> garyvdm: sorry, I'm pulling from a totally different machine, does it matter if it's from the machine i'm pulling to or the machine i'm pulling from?
[14:02] <davertron> garyvdm: nope, on ubuntu
[14:03] <garyvdm> davertron: The machine that you ran the bzr command on.
[14:04] <davertron> garyvdm: http://pastebin.ca/1536285
[14:06] <davertron> garyvdm: nm, I think i figured it out
[14:06] <davertron> looking at wrong machine i think
[14:06] <garyvdm> davertron: Cool
[14:06] <davertron> i was looking at the permissions on the remote machine, instead of the local machine
[14:07] <davertron> should have noticed the "file:///" stuff...
[14:07] <davertron> thanks :)
[14:18] <vila> http://instantrimshot.com/
[14:19] <vila> Finally no more './bzr selftest --no-plugins' that fail to test core plugins, welcome `BZR_PLUGIN_PATH=-site ./bzr selftest` :-D
[14:20]  * beuno is going to release loggerhead today so it can get updated for karmic
[14:23] <vila> fullermd: funny qlog bug huh ? Drove me nuts too but garyvdm fixed it as soon as I mentioned it :-D (Of course the pity is I mentioned it after having suffered a lot :)
[14:25] <vila> Can someone remember where we wanted to display the plugins path ?
[14:34] <bialix> vila: nice
[14:34] <vila> bialix: https://code.edge.launchpad.net/~bzr/bzr/412930-plugin-path/+merge/10458 pending review :-D
[14:35] <vila> bialix: Even if you don't vote, I'll appreciate your comments regarding windows,
[14:35] <bialix> vila: I'll try to look tonight
[14:35] <bialix> from home
[14:35] <vila> I've read a couple of bug reports but what needs/can/shouldn't be done on windows is a bit unclear to me,
[14:35] <bialix> ROTFL
[14:35] <vila> in particular, is there a clean way to have a 'site' directory for shared plugins ?
[14:35] <bialix> what?
[14:36] <vila> a directory where plugins can be installed and used by all users
[14:37] <vila> If I read the current code correctly we don't even try to define one for win32, I've respected that but I've also read various incoherent reports on that
[14:41] <davertron> man, still running into permissions errors trying a bzr pull...everything looks like it's going fine, but then i get a "Permission denied" on .bzr/repository/upload/598ikvm63uwlti81qibp.fetch", even though I own that file and have read/write permissions on it
[14:41] <davertron> everytime i run "bzr pull", i get a new file that is created in that directory and the same "permission denied" error
[14:44] <davertron> http://pastebin.ca/1536340 output from last entry in ~/.bzr.log
[14:48] <vila> davertron: you're working under /usr/local/lib ? With what login ?
[14:48] <davertron> david.davis
[14:49] <davertron> this is a repo that someone else intitally set up
[14:49] <davertron> so that's why i think i'm having the issues with it
[14:49] <davertron> i don't think they did a good job of setting permissions on the damn thing
[14:50] <vila> the permission denied is related to the containing directory (upload) do you have write access there ?
[14:50] <davertron> i do
[14:50] <davertron> in fact, the file that it claims "permission denied" on is created in that directory
[14:50] <davertron> whenever i run "bzr pull"
[14:50] <bialix> vila: vso what is your question?
[14:51] <bialix> vila: do you read bzrlib/plugin.py?
[14:51] <vila> hmm, yeah, right, sorry, look under the packs directory, that should be the target and the place where you lack access
[14:51] <vila> bialix: I patched it heavily yes, did you read my merge proposal ?
[14:51] <vila> :)
[14:52] <vila> damn, I just realized I dind't preserve the 'no site directory for win32' bit :-/
[14:52] <bialix> vila: sorry, I'm busy right now
[14:53] <vila> bialix: np
[14:53] <bialix> vila: I'll read your patch tonight, from home
[14:53] <davertron> vila: yeah, i just ran a chmod -R g+w on the whole .bzr dir
[14:53] <davertron> that seems to have gotten me a little farther
[14:53] <davertron> the perms on this repo are just all hosed
[14:53] <davertron> the guy who created it obviously didn't set perms correctly for anyone else to work on it
[14:53] <davertron> even though it's a damn production deploy repo
[14:54] <davertron> anyway
[14:54] <davertron> i'll just have to keep mucking with the stupid perms
[14:54] <davertron> and try not to take the site down :p
[14:54] <vila> davertron: may be you should just stop working in /usr/local but install there from root
[14:54] <vila> You already have a shared repo on another server right ?
[14:54] <davertron> yes
[14:54] <davertron> he didn't really set that one up right either :)
[14:55] <davertron> i had to muck with that for a bit so I could push to it
[14:55] <vila> davertron: no need to mess with permissions in two different places no ?
[14:55] <davertron> now i'm mucking more to pull
[14:55] <davertron> well, bzr doesn't preserve all perms does it?
[14:55] <vila> davertron: rm -fr the damn thing :-) (Kidding put it aside instead)
[14:55] <davertron> vila: heh
[14:55] <davertron> vila: i'll just rm -rf this other developer instead... :P
[14:56] <davertron> he's got different perms on the different repos, so he probably screwed it all up himself just to get it working in production
[14:56] <davertron> different groups own different things
[14:56] <davertron> it's a mess :)
[15:02] <emmajane> beuno, ping.
[15:02] <beuno> emmajane, hi
[15:02] <emmajane> PM ok?
[15:02] <beuno> always!
[15:02] <emmajane> excellent. :)
[15:06] <igc> night
[15:10] <beuno> igc, night!
[15:10] <beuno> I forgot to CC you on an email for the bazaar web page design
[15:10] <beuno> fwding now!
[15:11] <vila> beuno: wrong window ? :-D
[15:11] <beuno> vila, no!
[15:11] <beuno> it's public  :)
[15:12] <vila> but who is 'you' in 'CC you' then ? :)
[15:12] <beuno> vila, igc
[15:13] <beuno> I'm just lazy
[15:13] <vila> haaa
[15:13] <vila> right, makes sense, was a bit ambiguous, thought it was for emmajane :)
[15:14]  * emmajane is apparently off in another world and requires explicit pinging to see windows. :)
[15:30] <beuno> james_w, hi
[15:30] <james_w> hey beuno
[15:30] <beuno> james_w, how are you?
[15:31] <james_w> good thanks, how about you?
[15:31] <beuno> pretty good
[15:31] <beuno> sprinting, as usual  :)
[15:31] <beuno> james_w, I need your super powers
[15:31] <james_w> where are you this time?
[15:32] <beuno> james_w, buenos aires, but sprinting anyway  :)
[15:32] <james_w> nice
[15:32] <beuno> with the Ubuntu One guys
[15:32] <james_w> ah, cool
[15:32] <beuno> james_w, I've released a new version of Loggerehad
[15:32] <beuno> so we can get all the changes into loggerhead
[15:32] <beuno> er
[15:32] <beuno> karmic
[15:32] <beuno> :rolleyes"
[15:32] <james_w> ok
[15:33] <beuno> james_w, can you upload to ubuntu and/or karmic?
[15:33] <beuno> jelmer doesn't seem to be around
[15:33] <james_w> I'll work on it
[15:34] <beuno> james_w, THANK YOU
[15:34] <beuno> I'm in London for the last 2 weeks of Sept
[15:34] <beuno> please come by to say hi and claim your beer
[15:35] <james_w> heh
[15:42] <james_w> beuno: I like the new project overview pages, thanks
[15:43] <beuno> james_w, ah, I'm happy to hear that
[15:43] <beuno> a fe wmore changes in the pipeline, but it's roughly what it will look like
[15:43] <james_w> a lot less scrolling and hunting
[15:48] <beuno> james_w, how does the navigation feel?
[15:50] <james_w> beuno: better I think, though the fact that what were the tabs are now much less prominent threw me
[15:50] <james_w> plus I just noticed "Submit code" goes to what I presume is the wrong place
[15:51] <beuno> james_w, yeah, still working out the quirks
[15:51] <james_w> I certainly find it much more attractive, but I know you're interested in more than that :-)
[15:51] <james_w> and I still have quibbles with merge proposals
[15:51] <beuno> yes, merge proposals is the next thing I'm working on for the 3.0 re-design
[15:51] <beuno> will CC you on the email, if you like
[15:51] <beuno> it will go to the launchpad-dev list, if you're subscribed
[15:52] <james_w> I'm not, but I think I will do so now
[15:52] <james_w> there's a mail I need to send to it, but I can't remember what right now
[15:52] <james_w> I can't find a bug for this "Submit code" thing, I'll file it now unless you know it's known
[15:53] <beuno> james_w, it's been submitted to PQM already
[15:53] <james_w> ah, excellent
[16:26] <vila> beuno: 'last bugs reported' and 'last bugs touched' lists should be longer or an access to a longer list should be provided,
[16:27] <vila> I think the bug mentioned by james_w above is the one filed by lifeless less than a day a ago, and commented by me less than half a day ago, and yet, it's nowhere to be seen...
[16:28] <beuno> vila, yes, we're trying to figure out that page
[16:28] <vila> beuno: I understand, that's why I throw my 2 cents remark :)
[16:28] <vila> ha, here it is: bug #416125
[16:29] <vila> ha err, not sent to pqm then, were you talking about a different one ? james_w ? beuno ?
[16:30] <beuno> vila, the fix should be visible tomorrow
[16:30] <vila> beuno: don't you mark the bug Fix committed or at least in Progress ?
[16:30] <vila> or is it just a dupe ?
[16:30] <beuno> vila, it should be in progress
[16:30] <beuno> I'll ask  :)
[16:31] <vila> not really important. I was just wondering
[16:31] <beuno> vila, feedback is very useful, thank you
[17:30] <ddaa> hey
[17:30] <ddaa> anyone has figured out yet how to use the "parent diff" feature of reviewboard?
[17:31] <ddaa> it's driving me totally nuts
[17:36] <mtaylor> sadness has happened!
[17:36] <mtaylor> ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('lua-20081111233858-hzs0ti8sqjaycvlp-16', 'monty@inaugust.com-20081111233949-xwxzzzus31nn99aa')")
[17:47] <ddaa> Mh okay it SEEMS to expect the following
[17:48] <ddaa> diff = ancestor::prev..:last
[17:49] <ddaa> parent-diff = base-of-first-diff-for-this-review-request..ancestor::prev
[17:50] <ddaa> The problem I'm tying to solve is: How to feed reviewboard updated diffs when the branch to review merged changed from its base branch.
[18:51] <bialix> vila: why not: bzr --only-user-plugins selftest ...
[18:55] <rockstar> vila, tarmac just puked on me with the following error: http://pastebin.ubuntu.com/256461/
[18:56] <rockstar> It happened trying to commit from a heavyweight checkout.
[18:58] <bialix> rockstar: are you using 2a?
[18:58] <rockstar> bialix, I am indeed.
[18:58] <bialix> your server need upgrade maybe
[18:59] <rockstar> bialix, the server is Launchpad.  While we might be behind a bit, I don't think that's the issue, since I've been dealing with Launchpad all day.
[19:00] <bialix> error tells that some bzrlib does not understand your format
[19:00] <bialix> either your local installition or server
[19:00] <bialix> check /usr/lib/python2.6/dist-packages/bzrlib then
[19:02] <rockstar> bialix, I'm on bzr.dev
[19:02] <bialix> run bzr info -v then
[19:05] <bialix> are you sure that /usr/lib/python2.6/dist-packages/bzrlib is bzr.dev?
[19:17] <bialix> garyvdm: ping
[20:08] <garyvdm> bialix: Hi
[20:30] <sveinung> is this the correct place to ask questions about bzr builddeb?
[20:30] <james_w> sure
[20:31] <sveinung> I have checked out, built and installed the latest version from the bzr branch on launchpad
[20:31] <sveinung> how do I make it use the Debian date?
[20:31] <sveinung> when importing
[20:31] <sveinung> I see the code is there
[20:31] <sveinung> but I cant find an option to enable it
[20:32] <sveinung> (I look at bzr help import-dsc)
[20:32] <sveinung> when I say Debian date I mean the one from the changelog
[20:32] <james_w> hmm, it's not hooked up to the UI is it?
[20:34] <james_w> it's something I added later, and I didn't think it should be default
[20:34] <james_w> now I'm not so sure
[20:34] <sveinung> james_w: Ok, thanks
[20:34] <sveinung> so I should modify bzr builddeb if I want it?
[20:35] <james_w> patches welcome :-)
[20:51] <verterok> join #twisted
[21:10] <sveinung> james_w: is changelog-time an Ok name for an option?
[21:10] <james_w> I guess
[21:11] <james_w> should the default just change instead?
[21:13] <sveinung> I must admitt I was kind of confused when it used todays date. But I have looked at the autoimported branches at launchpad so I'm not sure if that is what will be least surprising for other people
[21:13] <sveinung> so I don't know
[21:15] <james_w> I think it might be better
[21:16] <james_w> I can't really remember my reasons now :-)
[21:17] <sveinung> ok
[21:18] <sveinung> (the it that might be better was to change the default, right?)
[21:32] <james_w> yeah
[21:46] <sveinung> james_w: is the test suite run during the building of the debian package?
[21:48] <lifeless> moin
[22:42] <sveinung> james_w: I found out how to run the test suite on my own. Merge request sendt
[22:57] <johnjosephbachir> if i have a lone checkout with no surrounding repo, but then make a repo, make a branch there, and then physcially move my checkout into the repo and bind it to the branch, will it [a] work, and [b] actually take advantage of the repo data?
[22:58] <bialix> a - yes, b - you need to run reconfigure
[23:00]  * johnjosephbachir looks at documentation for reconfigure
[23:00] <johnjosephbachir> bialix: thanks!
[23:00] <bialix> bzr help reconfigure
[23:02] <johnjosephbachir> bialix: hmm, even after doing that, my old reconfigured checkout (which i then turned into a branch) is  double the size of a fresh new branch
[23:03] <bialix> bzr reconfigure --use-shared ?
[23:04]  * johnjosephbachir reads the documentation more thoroughly......
[23:05] <johnjosephbachir> bialix: perfect.
[23:18] <Noldorin> lifeless: ping?
[23:25] <james_w> thanks sveinung
[23:25] <sveinung> np :)
[23:25] <james_w> I'll review tomorrow
[23:26] <sveinung> great
[23:27] <lifeless> Noldorin: hi?
[23:27] <Noldorin> heh
[23:27] <Noldorin> just checking you were there :)
[23:28] <Noldorin> lifeless: i'm trying to hack the source into outputing ftp commands now
[23:28] <Noldorin> but it doesn't seem trivial without altering the source for the actual ftp lib
[23:28] <Noldorin> any ideas here?
[23:28] <lifeless> if you want to log the exact commands tcpdump, or wireshark, or similar tools might be better suited
[23:28] <lifeless> I was suggesting just getting close :)
[23:30] <Noldorin> hmm, good point
[23:30] <Noldorin> might just use wireshark.
[23:30] <Noldorin> does the windows ftp client support ftp scripts?
[23:32] <Noldorin> the reason i'm wanting to replicate is purely out of laziness :)
[23:43] <Noldorin> RNTO /texdotnet/.bzr/repository/lock/held
[23:43] <Noldorin> FTP	Response: 550 /texdotnet/.bzr/repository/lock/held: Cannot create a file when that file already exists.
[23:44] <Noldorin> lifeless: that's what we expect, right?
[23:44] <igc> morning
[23:44] <goneri> hi igc
[23:44] <igc> hi goneri - I haven't forgotten your patch btw
[23:45] <goneri> (yes, I'm watching you :D)
[23:45] <igc> goneri: just flat out on non fast-import stuff yesterday
[23:45] <goneri> igc: I rewrite the second patch. There is just two tiny patches now.
[23:46] <goneri> s/rewrite/rewrote
[23:53] <lifeless> Noldorin: thats the behaviou, yes
[23:54] <Noldorin> lifeless: so there's a rename command before that which failed?
[23:54] <Noldorin> renaming /lock/held to something else
[23:54] <Noldorin> i presume
[23:54] <lifeless> yes
[23:54] <lifeless> but if theory is right it isn't actually erroring :)
[23:55] <lifeless> its just not working
[23:56] <Noldorin> yeah
[23:56] <Noldorin> just wanted to double check that
[23:56] <Noldorin> in the wireshark log
[23:57] <denys> I am unable to run the full test suite.  it always eventually errors out with "error: can't start new thread".  is there a trick I should know?
[23:57] <lifeless> is that with or without your patches?
[23:57] <lifeless> and on what platform?
[23:58] <denys> without and on gentoo/linux