[00:00] <maxb> igc: Hi. When you have a moment, could you take a peek at my fastimport MP?  https://code.edge.launchpad.net/~maxb/bzr-fastimport/branch-mapper-stuff/+merge/14594
[00:12] <igc> hi maxb: shall do.
[00:14] <maxb> thanks
[00:14] <igc> james_w: what's the timeframe for changes landing into bzr-builder's trunk? Are you back home now or still travelling?
[00:14] <lifeless> igc: hes on leave for a week
[00:15] <lifeless> igc: and there is a backlog :P - I have a month old patch now :(
[00:15] <igc> james_w, lifeless: I've got some doc and minor code changes ready to go in. I'm asking because if that backlog :-)
[00:15] <james_w> things will be leapfrogging rob's change as I have time to merge them
[00:16] <igc> lifeless: maybe I should submit them over a non-trunk branch?
[00:16] <james_w> I reviewed some on the plane yesterday, but as LP doesn't send you a merge proposal I couldn't merge them
[00:16] <igc> hi james_w
[00:16] <james_w> hi igc
[00:17] <igc> james_w: https://code.edge.launchpad.net/~spiv/bzr-builder/merge-subdirs-479705 looks like it builds on Rob's patch
[00:17] <james_w> I'll make it ~bzr-core owned or something one day
[00:17] <lifeless> igc: it does
[00:17] <igc> james_w: is that still to be reviewed?
[00:17] <lifeless> igc: that builds on one of my patches. the really old one is more complex and not relevant for the lp daily builds project
[00:17] <james_w> I'd just like to play gatekeeper for a while so that we can learn what the project is
[00:18] <james_w> it is still to be reviewed
[00:18] <james_w> I have some comments that will make it resubmit, but I asked for the merge proposal early anyway, so we could discuss whether merging subdirs is something that should be supported
[00:18] <igc> james_w: my doc tweaks can go over trunk easily
[00:19] <igc> james_w: my code changes are pretty trivial so I'll submit those over trunk as well
[00:19] <james_w> please do
[00:19] <igc> james_w: I just wanted to minimise merge pain for both of us if you were about to release a new trunk
[00:21] <igc> given six branches are more recent than trunk, I thought it was worth asking. Anyhow, enjoy your break james_w!
[00:21] <james_w> oh, this new prerequisite branches feature is confusing
[00:22] <james_w> it's cool and all
[00:22] <james_w> but I reviewed this diff I was sent, the mail said nothing about prerequisite branches, and then the diff I got when I merged was a lot larger than I reviewed
[00:22]  * james_w goes the other way
[00:24] <lifeless> james_w: start at the branch with no prerequisite
[00:24] <james_w> well, yeah
[00:29] <james_w> when was permit_dir added?
[00:29] <lifeless> context?
[00:30] <lifeless> oh, the test suite?
[00:30] <lifeless> a few months back now
[00:31] <james_w> time to make dinner anyway
[00:43] <thumper> james_w: please file a bug about the prerequisite info missing the email
[00:48] <idnar> how do I figure out what merge algorithm bzr merge is using?
[00:55] <lifeless> idnar: default is 3-way, anything else is what you told it
[00:55] <idnar> ah, okay
[00:55] <idnar> the help should probably mention that
[01:06] <AfC> I have http://paste.pocoo.org/show/152361/ in my .vimrc; on Gentoo it used to work that when `bzr commit`ing it would [among other things] set tw=70.
[01:06] <AfC> For some reason having switched to Ubuntu this doesn't work anymore, though other things in .vimrc are being picked up.
[01:06] <AfC> Anyone have even the vaguest notion of why this might not be working, and what I might try doing to re-enable it?
[01:08] <lifeless> you might need set nocompat at the top o the .vimrc
[01:12] <AfC> lifeless: Hm. Well, /etc/vim/vimrc seems to suggest that Debian has compatible on. I'll try your suggestion right now, though
[01:12] <idnar> I think by default, "vi" will run vim in vi-compat mode, whereas "vim" won't
[01:13] <idnar> but I could be confused
[01:14] <AfC> idnar: really? oh, that could be the problem
[01:15] <lifeless> I've found that I need set nocompat at the top for things to consistently work right
[01:16] <AfC> aside: vim.basic, vim.tiny... is there a third I should have installed, vim.kitchen_sink? :)
[01:17] <spm> AfC: that's vim.scripts I think you mean... ;-)
[01:18] <AfC> spm: just extrapolating from what `update-alternatives --display vi` had to say :)
[01:18] <spm> heh
[01:20] <lifeless> spiv: note that stuff submitted on the 20th is still on your watch ;)
[01:20] <AfC> Ok. Well,
[01:20] <AfC> $ export EDITOR=/usr/bin/vim
[01:20] <AfC> caused things to behave, but prefacing ~/.vimrc with "set nocompatible" does not seem to have had any effect
[01:21] <idnar> maybe .vimrc isn't even parsed when it's invoked as "vi"
[01:21] <AfC> so idnar seems to be on the right track, but I'd like `vi` to work properly, not to assume I have some nostalgia for the 1980s vi that we all loved to hate.
[01:22] <AfC> Is there a Debian way to make `vi` be Vim as Vim? I thought that was the whole point of the alternatives system
[01:22] <lifeless> vim is special
[01:23] <lifeless> because the vi/vim behaviour is not separate packages, its 'how was I invoked'
[01:23] <spm> AfC: "set nocompatible" in your vimrc - I believe should do the trick
[01:24] <spm> alternately; just alias vi=vim for a Q&D override
[01:24] <AfC> spm: as I just said above, that had no effect
[01:24] <spm> gah. soory - missed that. bummer!
[01:24] <AfC> spm: yeah, I'm trying to do this "right" (in Debian terms) rather than fighting the system
[01:25] <AfC> spm: [I would have _hoped_ compatible / nocompatible would have done the trick, seeing as how that was originally [&upstream] the way to take vim and ask it to dumb itself down to classic behaviour]
[01:25]  * AfC digs some more
[01:25] <spm> AfC: strace it on startup? it may be trying an old style vi rc file. name eludes me atm. ??
[01:25] <AfC> I guess I could set EDITOR
[01:25] <spm> ew
[01:26] <AfC> [better than alias, but still somewhat dirty unless done persistently system wide]
[01:26] <lifeless> you should set EDITOR
[01:26] <idnar> setting EDITOR seems reasonable to me
[01:27] <idnar> I'm not sure why it would need to be system-wide, it's just a user setting
[01:27] <idnar> I mean, setting EDITOR=vim isn't much different to, say, EDITOR=emacs
[01:27] <AfC> idnar: why don't you just pretend for a minute that all the other users on the system want it to be the same
[01:28] <AfC> [notably, that root fellow]
[01:28] <AfC> lifeless: if that's what you recommend, that's what I will do
[01:28]  * AfC goes off to learn about how Debian is handling /etc/profile these days
[01:28] <lifeless> I set EDITOR so that I get the editor I want
[01:42] <phcoder> Hello all. How can one prevent replacement of one branch by another on the server?
[01:45] <AfC> lifeless, spm, idnar: thanks for your help
[02:03] <lifeless> phcoder: do you mean 'make push prevent push --overwrite' or do you mean 'stop rm -rf' ?
[02:04] <phcoder> lifeless: both in preference however I suppose for the second one would need bzr+ssh
[02:06] <phcoder> (bzr+ssh only server I mena)
[02:06] <phcoder> *mean
[02:08] <lifeless> so filesystem permissions are the answer there
[02:09] <phcoder> lifeless: but how exactly? We still want people to be able to do a non --overwrite push
[02:09] <lifeless> oh
[02:09] <lifeless> so you can set append_revisions_only in branch.conf - see bzr help configuration
[02:11] <phcoder> lifeless: thanks
[02:12] <Peng> Of course, people can do anything if they *really* want to.
[02:12] <mwhudson> where's that no-vfs smart server
[02:13] <phcoder> Peng: they can send a missile on server, sure ;)
[02:15] <Peng> phcoder: Well yeah, but firing up hitchhiker or bzrlib and turning off append_revisions_only or outright manipulating files through the VFS is trivial.
[02:17] <phcoder> Peng: if one has only bzr+ssh access can't one instruct daemon to ignore such activity and send a notification e-mail?
[02:19] <Peng> phcoder: The VFS is necessary for some normal operations.
[02:20] <phcoder> Peng: like? Couldn't one adjust bzr+ssh to handle it as well?
[02:20] <Peng> phcoder: Examples? ...I don't know.
[02:21] <Peng> phcoder: Of course it's possible (and ideal) to make everything use smart methods, but the work hasn't been done yet.
[02:23] <lifeless> even if everything is smart
[02:23] <lifeless> append_revisions_only is settable through the smart API
[02:24] <Peng> \o/
[02:24] <spiv> Though presumably it'd be easy to add a hookpoint that could restrict changes to branch config objects.
[02:24] <Peng> When you run with -Dhpss, can you grep for VFS operations?
[02:24] <spiv> Not trivially.
[02:24] <Peng> Aww.
[02:24] <spiv> Basically, they are the verbs without '.' in them.
[02:25] <Peng> Ah. Yeah, that's bad.
[02:25] <spiv> So something like "hpss call.*?'[^.]*?' I guess.
[02:26] <Peng> Looks like 2 of the 3 VFS operations on one push I did were getting .bzr/branch-format and .bzr/checkout/format.
[02:26] <Peng> Ah, then getting .bzr/bzr-search/format at the end.
[02:27] <spiv> Well, that one would be bzr-search's fault ;)
[02:27] <Peng> The others could've been the fault of plugins, too.
[02:27] <spiv> Probably not :(
[02:28] <spiv> You could try -Dhpssvfs if you're really keen.
[02:28] <Peng> I'm kind of keen. Is that enough?
[02:29] <spiv> Peng: try it and find out :)
[02:30] <Peng> I just tried it on a different push. There was only the bzr-search one. :\
[02:31] <lifeless> -Dhpss_vfs
[02:31] <Peng> No underscore.
[02:33] <Peng> (I don't care enough to reproduce the conditions of the original push. It's a bit complicated.)
[02:33] <Peng> (Although I'll probably change my mind in a minute.)
[02:42] <Peng> Just did it. push_branch tries open_workingtree calls has_workingtree calls _ensure_real.
[02:42] <Peng> Dunno about the other one.
[02:43] <Peng> I bet it didn't happen in my other test because the destination branch didn't exist.
[02:43] <spiv> Peng: Hmm, I thought I fixed the open_workingtree/has_workingtree case.  Ah well.
[02:45] <lifeless> spiv: with my fix you can see it ;)
[02:45] <lifeless> spiv: different trigger I think, but yeh still bust
[02:46] <lifeless> spiv: you're still piloting the things filed on friday, right?
[02:46] <Peng> spiv: I still can't reproduce it with a test branch, though.
[02:47]  * igc lunch
[02:47]  * Peng unhappily munches on Cheerios
[02:49] <spiv> lifeless: I guess so, although I'm not sure what a good way to track that is
[02:49] <spiv> lifeless: possibly we should keep that info on the PatchPilot wiki page?
[02:51] <lifeless> spiv: I'd say 'I'm piloting this' in a merge proposal you're piloting
[02:52] <spiv> Hmm, yeah.
[02:52] <phcoder> Thanks guys. Good night
[04:17] <poolie> hi spiv
[04:17] <poolie> thanks for the report
[04:18] <spiv> No problem.
[04:21] <poolie> i think we should mention it, at a broader level, on the blog too
[04:26] <poolie> OldAl: hi, still here?
[04:27] <OldAl> poolie: Yes, apparently :)
[04:28] <OldAl> (Actually, I was away - shame on me for not telling.)
[04:31] <OldAl> menesis: Labas, bičiuli (Koks gražus žodis - "bičiulis", nieko panašaus nežinau kitose kalbose).
[04:34] <OldAl> poolie: I am off to an afternoon nap - good for my. and all mine, health!  Be back in an hour or so.
[04:34] <poolie> OldAl: i was just going to say
[04:34] <poolie> you made a page about yourself called /wiki
[04:34] <poolie> i'm just going to rename that to OldAl
[04:34] <poolie> just so you know
[04:36] <OldAl> poolie: That's b. disgraceful... Thanks for telling me. It was meant to be called "OldAl". Thanks for telling me.  The name probably can not be changed, can it?  If it is a problem to "move" it, just delete it, please.  I will need to read up on how to name a page.
[04:36] <poolie> it's no problem
[04:36] <poolie> it's now here
[04:36] <poolie> http://bazaar-vcs.org/OldAl
[04:36] <poolie> edit away
[04:36] <poolie> possibly we should move all of them into /People/ though
[04:38] <OldAl> poolie: That sounds a good idea. I probably can do that - just make a link to it and then copy via clipboard the contents of them; start with my own.
[04:38] <OldAl> poolie: In about an hours time, please...
[04:46] <DarkwingDuck> I have a question...
[04:47] <DarkwingDuck> I'm getting an error when I try to branch a project.
[04:47] <DarkwingDuck> Permission denied (publickey).
[04:47] <DarkwingDuck> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[04:47] <DarkwingDuck> This is only on my desktop. when I try it with my netbook it works just fine.
[04:47] <poolie> DarkwingDuck: there's probably an error from ssh further up?
[04:48] <DarkwingDuck> So, redo my ssh?
[04:50] <spiv> DarkwingDuck: the "Permission denied (publickey)." is from ssh, saying that it couldn't log in
[04:50] <DarkwingDuck> ahh. Okay.
[04:51] <spiv> Are you trying to branch from Launchpad?
[04:51] <DarkwingDuck> Yes
[04:52] <DarkwingDuck> I had it working a couple days ago and now it wont work on my desktop
[04:52] <DarkwingDuck> However, my netbook connects just fine
[04:54] <spiv> In that case, you can either configure your desktop's SSH so that it can connect to Launchpad (possibly by generating a public key and adding it to your account on https://launchpad.net/), or you can reconfigure bzr to connect to Launchpad anonymously (assuming read-only access is fine)
[04:55] <DarkwingDuck> Okay, thanks
[05:25] <OldAl> igc: I looked and qrun with regard to "too verbose explanation".  I can not reproduce anything like what you quote.  Would it be too much to ask you for more detail?
[05:27] <OldAl> igc: not "and qrun" bat at "qrun and pull"
[05:30] <OldAl> igc: A really serious flaw - bug - the GUI quits quietly if it encounters and error, viz. pull from a directory that is not a branch and the like.  It tells nothing to the user, nothing at all - just quits...
[05:33] <OldAl> igc: You seem to be absent, so I will leave it at that and go to try to do something else.
[05:35] <OldAl> poolie: Thanks for moving my "wiki" page to OldAl.  It is a flat file system, no?  Do you want me to create a "People" page and link to it my own CV page?
[05:36] <poolie> oldal, it is possible to create a People page and move yours to People/OldAl
[05:36] <poolie> you can do that if you want
[05:37] <OldAl> poolie: There is always a chance with an old timer that he will make a mess of it... So I do ask!
[05:37] <OldAl> poolie: Thanks for the advice - I will go away and give it a go.
[05:38] <OldAl> poolie: "go away" as in next desktop...
[05:39] <poolie> biab
[05:45] <igc> hi OldAl
[05:46] <OldAl> igc: Hi, igc!
[05:46] <igc> OldAl: try "bzr qpull --ui-mode" to keep the dialog open when a problem is encountered
[05:46] <OldAl> igc: I will do that and see what happens.
[05:47] <OldAl> igc: I just could not reproduce any kind of advice how to use the qpull or pull. Nothing like what you quote.
[05:48] <igc> OldAl: to reproduce my bug, grab a simple branch from lp, cd to the created directory and run "bzr qpull --ui-mode"
[05:48] <igc> OldAl: you can try it in a branch of qbzr say :-)
[05:49] <OldAl> igc: OK: so it seems that --ui-mode is the magic command?
[05:50] <OldAl> igc: So why would anybody want to use it in general?
[05:50] <igc> OldAl: nearly all q* commands take a --ui-mode parameter
[05:51] <igc> explorer, TortoiseBzr and qbzr-eclipse all call the q* command that way
[05:51] <igc> i.e. with that option turned on
[05:51] <OldAl> igc: What turns the ui-mode on?
[05:51] <igc> OldAl: sending error messages to the console isn't helpful to most users (unless they run every q* command from the console)
[05:52] <igc> OldAl: I don't get the question. Using the --ui-mode option turns that mode on
[05:54] <OldAl> igc: So if I call from CLI "bzr qpull"  that will be in ui-mode?  Or does one give this with every command to get feedback?
[05:55] <OldAl> igc: I will go to the next desktop to try - be back RSN
[05:58] <OldAl> igc:   p, li { white-space: pre-wrap; }  Run command: bzr "pull --ui-mode" bzr: ERROR: unknown command "pull --ui-mode"  I see where the *Run command* comes from. It is not really helpful with "pull", however.  "qpull" maybe?
[06:00] <igc> OldAl: yep, --ui-mode is onyl for q* commands
[06:02] <OldAl> igc: Well, with wrong data (no reference to where mirror is) the gui gives "unknown command".
[06:02] <spiv> OldAl: the quotes in  'bzr "
[06:02] <igc> OldAl: let's try again ...
[06:03] <OldAl> igc: I still fail to reproduce your "too verbose" reply.
[06:03] <igc> 1) bzr branch lp:qbzr qbzr
[06:03] <igc> 2) cd qbzr
[06:04] <igc> 3) bzr qpull --ui-mode
[06:04] <spiv> OldAl: the double-quotes in  'bzr "pull --ui-mode"'  are odd, I'm not sure why you put them in.  Generally you want to do 'bzr cmd --option', with no quotes.  Quotes change the meaning quite dramatically.
[06:04] <OldAl> igc: All from CLI, right?
[06:04] <igc> yes
[06:05] <igc> OldAl: if you already have a qbzr branch, skip 1
[06:05] <OldAl> igc: I only use the "xxx" here to show it is an item that was put into GUI.
[06:06] <OldAl> igc: No, I don't mind the branch bit - not at all.  Good stuff.
[06:11] <OldAl> igc: It (the PC) is pulling the qbzr - step 1.
[06:13] <OldAl> igc:   p, li { white-space: pre-wrap; }  Run command: bzr pull bzr+ssh://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/ --directory /dat/work/dummy/qbzr No revisions to pull.  Sort of success...
[06:15] <igc> OldAl: yep -that's success
[06:15] <igc> in reproducing the bug
[06:15] <OldAl> igc: It is a naughty message, I must say.  OK, so I better go and try to get a fix on that.  The freshly made branch would be useful.
[06:16] <OldAl> igc`Has anybody told you that you are a born teacher?
[06:17] <igc> OldAl: I write lots of documentation so I don't need to answer questions so .... no
[06:17] <OldAl> igc: (I come from a family of teachers, or persons engaged in some form of teaching.)
[06:18] <OldAl> igc: Thanks for your patience with an old man - me!
[06:18] <OldAl> igc:  Hope to repay you in some small way!
[06:19] <igc> OldAl: no problem. In return, I expect you to find every retired people who and program and get them submitting patches to Ubuntu using bzr and launchpad. :-) :-)
[06:19] <igc> and -> can
[06:19] <OldAl> igc: I confess that I was not looking at the CLI interface with qpull.
[06:21] <poolie1> spiv, i am about 50% of the way to automatically marking reviews that need to be signed
[06:21] <poolie1> s//need the contributor agreement to be/
[06:22] <OldAl> igc: Typical misunderstanding - I was really interested and looking at [bzr qrun], which has a potential to compete with ... bzr-explorer. At least in some areas. I will now switch to looking at qpull - thanks again.
[06:22] <spiv> poolie1: nice.  Marking them in what way?
[06:23] <igc> OldAl: I'm happy for you to work on qrun. qpull is a gentle introduction to the qbzr code
[06:23] <poolie1> i think i'm going to make it post into the review thread
[06:23] <poolie1> assuming there's an api for that
[06:23] <spiv> There's always email ;)
[06:23] <igc> OldAl: qrun will help explorer 10x more than compete with it IMO
[06:24] <igc> OldAl: if it's good enough for a class of users, great
[06:24] <OldAl> igc: I could not agree more.  You need several GUI implementations.
[06:25] <OldAl> igc: Preferably different from each other more than a skin.
[06:26] <OldAl> igc: All the best. Buy for now.
[06:26] <igc> OldAl: bye
[06:27] <OldAl> igc buy -> bye  :-D :'(
[07:30] <maxb> Is there a better way to write:    graph.heads((a, b)) == set((a,))  ?
[07:30] <maxb> it doesn't feel very nice
[07:30] <lifeless> in a test ?
[07:31] <maxb> in rebase's actual code
[07:31] <lifeless> b not in graph.heads((a,b))
[07:31] <lifeless> I guess
[07:31] <maxb> Oh, excellent point :-)
[07:32] <maxb> I was so tied up in checking that it had length 1 as well
[07:33] <maxb> oh
[07:34] <maxb> but no, because sometimes a and b are equal
[07:49] <igc> lifeless: maybe you could add your thoughts on how to do what james is after in https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/15137
[07:51] <lifeless> igc: I've discussed it with vila already
[07:51] <lifeless> we need a change to the plugin path infrastructure
[07:52] <igc> lifeless: cool. Thanks.
[07:56] <poolie1> spiv, if you're still here, can you add people who signed the agreement for you to that team?
[07:59]  * igc dinner
[08:08] <poolie1> also spiv, i blogged about it
[08:08] <poolie1> corrections welcome
[08:13] <MvG> Hi! For trac-bzr, does anyone here have an opinion about what a revid without a branch name should mean? I'd like feedback on https://bugs.launchpad.net/trac-bzr/+bug/486795 for this, or directly here on IRC.
[08:14] <chx> MvG: hi
[08:14] <chx> MvG: I am just a user , nothing more
[08:15] <chx> MvG: but how can a changeset exist without a branch?
[08:17] <lifeless> MvG: you could synthesis a branch for it, with it as the tip
[08:26] <chx> lifeless: following up on a discussion yesterday, I would believe that http://freshmeat.net/projects/fl-cow this can be of interest to bzr users.
[08:27] <chx> lifeless: this makes the --hardlink option much more useful
[08:28] <lifeless> chx: it makes it safer ;)
[08:28] <lifeless> theres another thing like that around somewhere.
[08:28] <chx> oh?
[08:28] <chx> I am rather curious
[08:28] <lifeless> I don't recall the other projects name offhand
[08:28] <chx> see, our svn checkouts eat more than 100MB each (wowsie)
[08:29] <chx> so when we migrate to bzr, I would like to see this stop.
[08:30] <poolie1> chx: how about using one tree and switching between branches?
[08:30] <poolie1> i guess if you wanted that, you'd do it in svn too
[08:31] <chx> poolie1: ?
[08:31] <chx> poolie1: we typically do one checkout per ticket
[08:31] <poolie1> ok
[08:31] <poolie1> my point is
[08:31] <chx> poolie1: so that the QA people can independently check the results
[08:32] <poolie1> ok
[08:32] <poolie1> i guess my point is
[08:32] <chx> if you know a better workflow , i am listening
[08:32] <poolie1> you can remove the checkout and then people can recreate it from the branch when they need it
[08:32] <poolie1> for example just bzr remove-tree and bzr checkout
[08:33] <lifeless> chx: so 50% of that 100MB is the svn cache
[08:33] <lifeless> chx: which bzr doesn't have.
[08:33] <chx> lifeless: i presume
[08:33] <chx> yay
[08:34] <lifeless> chx: do your QA people have their own machines?
[08:34] <chx> lifeless: no
[08:34] <lifeless> ok
[08:34] <chx> lifeless: this is a web project so they just browse to the developers address , easy (?)
[08:34] <lifeless> I see
[08:35] <lifeless> yes, for that you'll want separate checkouts
[08:35] <chx> also allows for designers , project managers other assorted riff-raff ;) to see etc
[08:35] <lifeless> but as long as you have a shared repo it will be only your files that show up in terms of space.
[08:35] <chx> hm?
[08:35] <chx> a shared repo?
[08:35] <lifeless> bzr init-repo myrepo
[08:35] <chx> I was thinking we will use a bzr branch -- local commits -- gatekeeper merges in flow
[08:35] <lifeless> then do your branching/checkouts within myrepo
[08:36] <lifeless> its a storage optimisation tool, it doesn't affect merge/push etc
[08:36]  * chx reads bzr help repositories
[08:40] <chx> oh i see
[08:41] <chx> i created a repo, checked in Drupal HEAD, branched it and now i see that the repo .bzr is 5MB but the branches .bzr are only 440 and 500kb respectively
[08:41] <chx> that's a good trick indeed
[08:48] <MvG> Sorry, didn't realize I got replies here...
[08:48] <MvG> chx: while revisions without a branch are possible, e.g. when you remove the branch from which they originated, the issue at hand is a different one: trac-bzr is a bzr plugin for trac, and offers several ways for trac to name revisions. One is "branch,revno", one is "branch,revid" and one is simply "revid".
[08:48] <MvG> chx: so the question is, if you don't know the branch a revid is supposed to belong to, how to you treat this in trac.
[08:56] <bialix> hello all
[08:56] <bialix> hello MvG
[08:56] <poolie1> hello bialix
[08:56] <MvG> Hi there, bialix!
[08:56] <bialix> :-)
[08:56] <bialix> hello poolie1
[08:56] <poolie1> and good night...
[08:57] <MvG> 10am here...
[08:57] <bialix> poolie1: just yesterday read about five whys: http://www.startuplessonslearned.com/2008/11/five-whys.html
[08:57] <bialix> maybe it could be interested for pilot improvements
[08:58] <bialix> and good night
[08:59] <bialix> MvG: this channel dancing arounf the world. aussies going to sleep
[08:59] <bialix> *around
[08:59] <MvG> So I guessed...
[08:59] <MvG> Just have to resist the temptation to join in just yet...
[08:59] <MvG> ;-)
[08:59] <bialix> :-)
[09:19] <doctormo> Hey again, I'm re-looking for a way to express the progress of branching and checkout options to a GUI, so far I can either popen the bzr command with a thread and hack together the progress from the stderr output, I'd prefer to use bzrlib, is there any way to do this?
[09:21] <poolie1> bialix: yes i think that would be relevant
[09:21] <poolie1> we shouldn't just do stuff to work around the current problems, we should dig in to them
[09:22] <bialix> agreed, and spiv report make me think this way
[09:22] <bialix> glad it maybe useful for you
[09:39] <lifeless> doctormo: sure, you can see what bzr-gtk does (uses the API), or qbzr does (wrapps the command line) or bzr-eclipse does (uses the bzr-xmloutput plugin to control it)
[09:40] <doctormo> lifeless: Looking at all of those, bzr-gtk doesn't seem to do anything, it's magic.
[09:40] <bialix> doctormo: look at qbzr
[09:41] <doctormo> bialix: Is wrapping the command line to prefered way of getting progress status?
[09:41] <lifeless> doctormo: I'm not sure why you'd say its magic :)
[09:41] <doctormo> lifeless: magic == I don't understand it
[09:41] <lifeless> doctormo: Not to me; install a ui_factory is what I think is preferred.
[09:42] <lifeless> doctormo: but opinions about 'preferred' are, by definition, subjective.
[09:42] <bialix> doctormo: no, the point not about wrapping
[09:42] <doctormo> lifeless: yes I can tell the ui_factory is involved, it creates by default a TextProgress class
[09:42] <bialix> doctormo: there is good example of how to install your ui_factory and how to tie it with GUI
[09:43] <lifeless> bialix: oh cool, I'll remember that
[09:43] <doctormo> bialix: In qbzr? thanks
[09:43] <bialix> lifeless: is it irony?
[09:43] <bialix> or sarcasm perhaps
[09:44] <lifeless> bialix: neither.
[09:44] <bialix> ok, nm
[09:45] <doctormo> bialix: lifeless believed that qbzr wrapped the command line output, if I understand, so your correction about it using the ui_factory is interesting.
[09:45] <bialix> doctormo: actullay we do both
[09:45] <bialix> but for you is relevant ui_factory part
[09:45] <bialix> it's just very closer to wrapping command-line
[09:46] <bialix> you can omit the latter and use the former as example
[09:47] <doctormo> thanks bialix
[09:48] <bialix> doctormo: it's in qbzr/lib/subprocess.py
[09:48] <doctormo> bialix: I'm going tomake a simple QUIFactory copy, I assume that's involved too
[09:49] <bialix> yes, that's correct
[09:56] <doctormo> ui.ui_factory = QUIFactory() <- this part I think
[09:58] <doctormo> brilliant, got a simple thing up and running.
[10:44] <maxb> Does bzr-explorer "Advanced Commands" work on Windows? It does nothing when I click it.
[10:45] <lifeless> does anything? :P
[10:45] <bialix> maxb: yes
[10:46] <maxb> hmm
[10:46] <bialix> until recently it invoked console shell
[10:46] <bialix> now it launch qrun dialog from qbzr
[10:46] <bialix> maxb: if you have black console window behind -- look there
[10:46] <maxb> oh, there it is
[10:47] <bialix> I suggest to use latest bzr-explorer version from trunk to get qrun instead
[10:47] <bialix> this console thing is a bit buggy
[10:51] <maxb> Gladly, for my own use on Linux. But I'm briefly evaluating it on Windows for my less technical colleagues
[10:52] <bialix> that's why I'm suggesting using version with qrun
[11:23] <RenatoSilva> Is there a way to customize annotation colors? I want to distinguish clearly with colors the lines below and the lines above a certain revision.
[11:49] <hsn> do i have to uninstall old bzr in windows before installing a new one?
[11:52] <bialix> hsn: as usual Start -> Settings -> Control Panel -> Add/Remove Programs
[13:20] <ryanhaigh> hi all im having a problem with the bzr add command
[13:20] <ryanhaigh> for some reason when i run bzr add without any arguments it doesn't add one of my subdirectories
[13:21] <RenatoSilva> check bzr log
[13:21] <RenatoSilva> clean it, then add
[13:21] <ryanhaigh> if i try to add the directory or any file in it explicity, it is also not added
[13:21] <ryanhaigh> clean it?
[13:22] <bialix> ryanhaigh: is this directory ignored?
[13:22] <ryanhaigh> no
[13:22] <bialix> check output of bzr ignored
[13:22] <ryanhaigh> i have done that the output is blank
[13:22] <bialix> does this directory holds another branch inside?
[13:23] <ryanhaigh> no
[13:23] <RenatoSilva> ryanhaigh: if you try to add that specific directory you don't get any error, but the directory is not added?
[13:24] <bialix> can you check this with `bzr info /path/to/dir/which/refuse/to/add` ?
[13:24] <ryanhaigh> thats right, it remains unkown
[13:24] <bialix> this cannot be true
[13:25] <bialix> either you discover very interesting bug (but I doubt) or you have something unusual with your directory
[13:26] <RenatoSilva> ryanhaigh: open the bazaar log and delete the content, then run bzr add dir and check what's outputed there, it may tell you what's happening
[13:27] <ryanhaigh> how do i open the bzr log to delete the content?
[13:27] <bialix> in your favorite editor
[13:27] <bialix> check output of bzr version to see where the log located
[13:27] <ryanhaigh> ahh ok, sorr
[13:27] <ryanhaigh> sorry
[13:28] <bialix> I bet you have another branch there
[13:28] <RenatoSilva> if so bzr should say something anyway
[13:28] <ryanhaigh> bialix: you are correct there is another branch
[13:28] <bialix> bingo!
[13:28] <ryanhaigh> thanks
[13:28] <bialix> I'm WON! hoorah!
[13:29] <bialix> :-)
[13:37] <fullermd> Graah.
[13:37]  * fullermd stabbies LP
[13:38] <fullermd> Every damn week, it comes up with some new way to send mail I have to filter out, usually into oblivion...
[13:47] <bialix> hello fullermd :-)
[14:41] <MvG> If someone is interested in reviewing a bit of trac-bzr code: https://code.launchpad.net/~gagern/trac-bzr/bug274609/+merge/15148 removes some unreachable code, as described in the corresponding bug report. Comments?
[14:47] <MvG> bialix, https://code.launchpad.net/~gagern/trac-bzr/bug177683/+merge/15149 might be of special interest to you, as you first merged the original patch regarding bug 177683. Now I've added some str conversions and proper parsing for revids without a branch name. Will you have a look?
[14:52] <bialix> MvG: I need some time to recall what I've doing in the past
[14:52] <bialix> MvG: thanks, I'm really interested in trac-bzr stuff, I'll look into your code tonight
[14:53] <MvG> bialix: That's great!
[14:53] <MvG> Thanks a lot.
[14:53] <bialix> thank *you* a lot!
[14:53] <MvG> cd wo
[14:54] <MvG> (wrong window...)
[14:57] <bialix> cd wrong window - lol
[15:55] <bialix> MvG: ping
[15:55] <MvG> bialix: pong
[15:55] <bialix> MvG: from time to time I'm thinking about speed up of trac-bzr operations
[15:56] <bialix> do you have any plans on this front?
[15:56] <MvG> Not yet.
[15:56] <bialix> I'm mulling idea of some sort of cache
[15:56] <MvG> There are already some caches in place.
[15:56] <MvG> And I believe bzrlib itself does some caching as well.
[15:56] <bialix> for me is the worst case is to get Timeline with "Repository checkins" selected
[15:57] <bialix> for my server it takes several minutes
[15:58] <bialix> MvG: I'm not sure bzrlib cache help here
[15:58] <MvG> OK, that's a thing that should be fixable.
[15:59] <bialix> that will be nice
[15:59] <bialix> MvG: do you have any hints re debugging trac-bzr plugin?
[16:00] <bialix> how you do development actually?
[16:00] <MvG> Debugging performance?
[16:00] <bialix> bugs in first place
[16:00] <bialix> performance is second
[16:01] <MvG> As of last friday, I've got a dedicated apache for this, running as my user on a non-privileged port, so I don't have to worry about matching IDs.
[16:02] <MvG> On the python part I've discovered virtualenv, so I've set up two different python environments, one for trac 0.10 and one for 0.11.
[16:02] <bialix> no, I'm asking how you get info about what's going on inside plugin?
[16:02] <MvG> So far performance hasn't been of interest, so I'm running trac as cgi, which ensures I'm always running the latest code.
[16:02] <bialix> in bzrlib there is .bzr.log where one can print debug info
[16:02] <MvG> There is a similar log for trac.
[16:02] <MvG> Every trac component has self.log which provides this.
[16:02] <MvG> Only trac-bzr doesn't use it for the most part.
[16:02] <bialix> ok, I'll try to use it
[16:03] <bialix> is there special reason for this?
[16:03] <bialix> reasons for not using logs?
[16:03] <MvG> Oh yes, and BzrRepository.sync even overwrites this log with None. No clue why that's the case, doesn't seem related to the rest of the commit that introduced it.
[16:04] <bialix> weird
[16:04] <bialix> MvG: another question: do you think running Trac with built-in server tracd is bad idea?
[16:04] <MvG> Should fix this in trunk soon. Do you want to review such a fix?
[16:04] <MvG> Depends on the environment.
[16:05] <bialix> MvG: I'd like to review, but I need to dive deep enough into the code first
[16:05] <bialix> I'm not good hacker re trac-bzr
[16:05] <MvG> Apache has some nice features for cleaning up malicious requests, which tracd might miss.
[16:06] <bialix> tracd is much easier for me, as dev environmenbt
[16:06] <bialix> tracd is much easier for me, as dev environment
[16:06] <MvG> Other than that, I always want to embed trac inside a larger page, so I wouldn't use it as a production env.
[16:06] <bialix> ok, understand
[16:06] <MvG> For development it certainly has benefits, and shouldn't hurt in most cases, unless you want to explicitely test something depending on the frontend.
[16:07] <bialix> btw, currently I'm using trac+bzr trunk revno.34 with custom patch applied
[16:07] <MvG> What custom patch? SOmething suitable for trunk?
[16:08] <bialix> I hope so
[16:08]  * bialix pastebins
[16:08] <bialix> MvG: http://pastebin.com/d29e24ad1
[16:08] <bialix> I'm not sure, maybe it already in trunk
[16:09] <bialix> I'm stuck with revno 34 and bzrlib 1.5 because later versions does not work well for my case
[16:09] <bialix> I have many shared repo and branches on my server
[16:09] <MvG> In a modified version: authors = ";".join(self.revision.get_apparent_authors())
[16:10] <bialix> yep, modified version is more correct for newer bzrlib
[16:10] <MvG> Multiple shared repos for the same trac env cause trouble.
[16:10] <bialix> what kind of trouble?
[16:10] <MvG> Well, locking for instance. There seems to be code that only locks the whole repo once.
[16:10] <bialix> :-/
[16:11] <MvG> Existence of revid checks in some places.
[16:11] <bialix> locks locks locks
[16:11] <bialix> heh
[16:11] <MvG> Both of these I encountered in code that was broken in some other way as well, and which I plan to remove,
[16:11] <MvG> So it might coincidentially work with multiple repos as well, but I wouldn't rely on it yet.
[16:11] <MvG> There is a whishlist for it, iirc.
[16:11] <bialix> For me multiple shared repo is critical feature
[16:12] <bialix> we have many components in our project
[16:12] <bialix> keep all components in one big shared repo proved to be a *bad* idea
[16:12] <eydaimon> is it possible to just merge only the changes of a particular revision, and not changes of some previous revisions? let's say repo A has revision 100, and repo B has revision 98. I want to merge in only changes in revision 100 to B, not 99. Can I merge in, and then at a later time merge the changes for 99? Does that require a special syntax?
[16:12] <bialix> (performance) of smart server
[16:12] <bialix> eydaimon: bzr merge -c100
[16:13] <eydaimon> bialix: and then next time I do bzr merge, then c99 will get merged automatically?
[16:13] <bialix> yes
[16:13] <eydaimon> thanks
[16:13] <bialix> always happy to help
[16:14] <chx> MvG: so you are the trac+bzr developer?
[16:15] <MvG> chx: I'm the newest member of the trac-bzr-team, i.e. recently got commit permissions on the trac-bzr trunk.
[16:15] <MvG> Other than that, I'm mostly busy writing bug fixes for issues I encountered myself, and pushing these for review. Haven't made a single commit to trunk yet.
[16:16] <bialix> MvG: re splitting support for 0.10 and 0.11: I'd create new series (say "0.10") and use it for 0.10-specific branch
[16:17] <eydaimon> is it possible to merge several changes using -c? I tried range, but it said it's not possible
[16:17] <MvG> bialix: Dunno... series are usually for feature-stable releases of the component itself, and I'd wish to include as many new features into the 0.10 branch as possible.
[16:17] <eydaimon> would I have to merge twice?  (I actually want to merge 386 and 387)
[16:18] <bialix> MvG: hm? I think they can be used more flexible
[16:18] <eydaimon> or do I have to merge 386 first, commit, then merge 387?
[16:19] <bialix> eydaimon: if youo want merge from X to Y you need to use: bzr merge -r (X-1)..Y
[16:19] <MvG> eydaimon: bzr merge -r 386..387
[16:19] <bialix> -r385..387
[16:19] <bialix> -r386..387 is equal to -c387
[16:19] <eydaimon> oh, so now the -r syntax as opposed to -c?
[16:19] <eydaimon> ok, thanks
[16:19] <bialix> eydaimon: -c is syntax sugar
[16:19] <bialix> -cN means -r (N-1)..N
[16:20] <NfNitLoop> whoah.  didn't reailze 'bzr init' in a svn directory would comlplain that it's already a (svn) branch. :p
[16:20] <bialix> NfNitLoop: --no-plugins :-)
[16:21] <eydaimon> ok thanks much guys :) appriciate it
[16:24] <chx> MvG: sounds awesome
[16:24] <chx> MvG: i am about to use trac+bzr :)
[16:25]  * bialix using trac and trac+bzr 2+ years now and found it very nice tool
[16:25] <MvG> chx: Don't hesitate to file any bug you encounter with latest trac-bzr.
[16:26] <chx> bialix: really.
[16:26] <bialix> Trac has very rich plugins system
[16:26] <bialix> on this front it outperform even Redmine
[16:26]  * bialix heavily using IncludeWiki macros
[16:29] <MvG> I find the current state of trac-bzr to be somewhat lacking - which is the reason I'm filing that many bug reports, and writing that many fixes... :-)
[16:30] <bialix> given in mind there is not much activity around trac-bzr development...
[16:30] <bialix> MvG: today is only barely usable
[16:32] <bialix> MvG: what version of Apache do you recommend?
[16:33] <MvG> abentley: http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/28.1.146 indicates that you committed the line which sets self.log = None for trac-bzr. Can you recall your reason for this? I know, it has been 3 years ago, but still worth asking, I guess.
[16:34] <MvG> bialix: Using 2.2 myself, and would suggest that to others as well.
[16:34] <bialix> MvG: thanks
[16:34] <MvG> But my main reason for 2.2 is content negotioation fo static content, so the choice isn't that important for trac.
[16:35] <abentley> MvG: Sorry, I don't remember.
[16:35] <MvG> abentley: Understandable. Thanks for looking. Will simply remove that line, as it doesn't seem to make sense in current code.
[16:36] <matt_pi> Hi. I have a terminology problem. REVISION is a name for the currently commited data, or a name for all the data commited before a certain commit (including this commit).
[16:39] <abentley> matt_pi: revision refers to the current state at commit time.  This includes files that were not modified in this commit, but doesn't include old data for files that were modified in this commit.
[16:39] <MvG> I just realized that I can't seem to have a lightweight checkout tree of a heavyweight checkout without a tree. Would be useful, though: the lightweight checkout would be my working tree, which i switch from branch to branch as need arises. The heavyweight checkout would be simply a bound branch to ensure that commit and push become atomic, that my trunk will never diverge from upstream trunk unless I explicitely ommit locally.
[16:40] <jelmer> mvg: in general you can't have checkouts of checkouts
[16:41] <MvG> Is there a good reason for this?
[16:42] <matt_pi> abentley: I think I understand. So in a revision are also included other files that werent changed in a commit. In other words: revision is a status of the whole branch, not only a few files.
[16:44] <abentley> matt_pi: Yes, but I would say "whole tree", not "whole branch", because the branch includes all of the past revisions.  "Snapshot" vs "changeset" is a common distinction.
[16:45] <matt_pi> abentley: OK, many thanks.
[16:45] <abentley> matt_pi: np
[18:31] <stuartpb> How do I set up bzr-git on Windows?
[18:50] <stuartpb> How do I set up bzr-git on Windows?
[19:03] <stuartpb> How do I set up bzr-git on Windows?
[19:09] <LarstiQ> ehm, same as usual?
[19:09]  * LarstiQ uses neither bzr-git or Windows
[19:10] <LarstiQ> stuartpb: are you hitting a snag?
[19:12] <stuartpb> well yeah
[19:12] <stuartpb> i can't figure out how to install Dulwich for it
[19:12] <LarstiQ> ah
[19:13]  * LarstiQ wonders if there is any C code in Dulwich
[19:14]  * LarstiQ acquires a copy
[19:15] <LarstiQ> stuartpb: yeah, there is C code in there
[19:15] <LarstiQ> stuartpb: so if there isn't a binary for Dulwich, you'll need to have a functioning Python-extensions-compilation toolchain
[19:16] <chx> i just set up my first bzr server. that was not particularly hard. if i want permissions the easiest is to use bzr+ssh and ssh keys isnt it?
[19:17] <LarstiQ> chx: yes
[19:17] <LarstiQ> chx: and posix acls
[19:17] <chx> (however, the inetd instructions are outdated , seemingly most distributions use xinetd (?). standalone is easy.)
[19:42] <RenatoSilva> verterok: hi
[20:12] <Peng> beuno: Copyright assignments for Loggerhead? That's new.
[20:12] <mwhudson> not really
[20:12] <beuno> Peng, it hasn't been as public as it should have been  :)
[20:13] <Peng> "(Last modified 14 May 2009)" I guess it isn't new... Huh.
[20:13] <Peng> I didn't see it on the list last time I looked at that page.
[20:13] <Peng> Most of Loggerhead's code is copyrighted by specific people.
[20:13] <beuno> Peng, does this create a problem for you?
[20:13] <Peng> Or at least...some large portion.
[20:14] <Peng> beuno: I dislike copyright assignments, but I'd rather do that than stop contributing.
[20:14] <Peng> Or...it's not a copyright assignment? I don't remember. Anyway.
[20:15] <beuno> Peng, unfortunetly, laws are complicated
[20:15] <beuno> so we've been asked to do this for all Canonical projects
[20:15] <Peng> Oh yes, it is a copyright assignment.
[20:15] <LarstiQ> can't Canonical invest some money in simplifying laws the world over?
[20:15] <beuno> the FSF strongly suggests this approach
[20:16] <beuno> LarstiQ, if it was feasible, it would probably be money well spent  ;)
[20:16] <beuno> (and hi!)
[20:16] <LarstiQ> beuno: yes :)
[20:16] <LarstiQ> heya! :)
[20:16] <LarstiQ> there are also jurisdictions where you can't sign (all of) your copyright away
[20:16] <LarstiQ> ah well
[20:16] <Peng> LarstiQ: The agreement covers that.
[20:16] <LarstiQ> Peng: ok
[20:17] <Peng> I already signed it for Bazaar; should I do it for Loggerhead too?
[20:17] <beuno> Peng, I think it's the same
[20:19] <Peng> Hmm. The contributor agreement says "The term 'Software' refers to all computer programs created as part of a Canonical programme listed at http://canonical.com/contributors ...", so I guess I unintentionally signed it over for everything, not just Bazaar.
[20:20] <RenatoSilva> Peng: you'd rather assign copyright than stop contributing. How about the company stoping asking contributors to do that?
[20:21] <Peng> RenatoSilva: Oh. Yes, that would be better.
[20:22] <RenatoSilva> beuno: FSF suggests what approach, the assignment? For a trustable organization afaik (like themselves)
[20:22] <beuno> RenatoSilva, yes. I may be very naive, but I expect Canonical to be trustable
[20:23] <beuno> you know, considering they are trusted with basically root access to all Ubuntu users' computers
[20:23] <Peng> Haha, that's a good point.
[20:23]  * Peng is scared of Canonical now
[20:23] <beuno> if you don't trust Canonical, you probably have bigger problems than the Copyright assignement
[20:23] <luks> beuno: well, I think FSF and Canonical have different reasons for it
[20:23] <luks> I'm not sure which reason is better though :)
[20:24] <RenatoSilva> beuno: I'm afraid FSF doesn't consider any commercial organization trustable
[20:24] <LarstiQ> I'm reasonably sure the FSF has a nuanced stance on that
[20:24] <Peng> I suppose I trust Canonical to behave well with their control of my computer, but I do not necessarily believe they'll do what I want with source code.
[20:25] <Peng> I already feel funny about how they can and do make it available under other license terms.
[20:25] <Peng> It's _probably_ all for a good cause, but _I_ don't know that.
[20:25] <Peng> (Well, not necessarily "and do". I don't know that.)
[20:28] <RenatoSilva> I think the assignment to FSF or related organizations is like "GPLv2 or later". You trust FSF is compromized with certain principles and that they won't leave it. So you trust that any later version of GPL is better according to what you believe regarding FOSS. The same way, I think when you disclaim copyright to FSF, you believe that if e.g. they decide switch from GPL to LGPL, that's because they have a good reason.
[20:28] <Peng> RenatoSilva: Not everybody does the "or later". :D
[20:29] <LarstiQ> same thing with Canonical
[20:30] <lifeless> Peng: there is only one now; we used to have many seperate ones but consolidated
[20:30] <RenatoSilva> Peng: many do afaik. I think the best reason to not assign copyright to a commercial organization is that because of its nature, there's no guarantee that the company will only use the source code for community benefit rather than its own
[20:30] <Peng> lifeless: OK. :)
[20:31] <lifeless> RenatoSilva: thats like saying 'there are no guarantees'
[20:32] <LarstiQ> RenatoSilva: there are no guarantees with FSF either.
[20:32] <LarstiQ> RenatoSilva: it comes down to trust, and I trust Canonical with the Bazaar source.
[20:32] <Peng> I'm kind of an untrusting person. :\
[20:32] <LarstiQ> whether someone else trusts them with the same thing is up to them.
[20:32] <luks> LarstiQ: I've seen many posts on the ML lists that suggested that you can talk to Canonical to get a difference license conditions
[20:32] <luks> I haven't seen such posts from FSF on FSF software
[20:33] <LarstiQ> luks: so there is a level of trust etc.
[20:34] <RenatoSilva> Peng: another good reason is to ask the company a good reason for doing that. That is, why do you want to TAKE my code from me? What's bad about the source code belonging to "all people in the earth". It makes difficult to change license? Well, that's reasonable to accept if we're talking about FSF or any non-profit organization, but not for a commercial company.
[20:35] <lifeless> RenatoSilva: No one takes the code from you. And updating to newer licences that work better in court as the law changes is a pretty important thing to be able to do.
[20:36] <lifeless> or even just to add compatibility with another open source project - like the openssl exception that GPL projects using openssl need.
[20:36] <RenatoSilva> LarstiQ: FSF and Canonical have different natures. I trust FSF much more than Canonical. Actually, I would not trust any commercial company that much, or at all.
[20:37] <LarstiQ> RenatoSilva: that's your choice, and that's fine.
[20:37] <luks> note that I care about the Bazaar agreement much, but this why I'd have trouble signing it
[20:37] <luks> I signed a similar agreement for Qt/Nokia, but they were pretty open that they want it because they want to provide a commercial version
[20:37] <beuno> luks, do you feel Canonical is not open about it?
[20:37] <LarstiQ> luks: right
[20:38] <luks> beuno: everybody here is claiminig that it's because they want to keep the code free
[20:38] <LarstiQ> beuno: about wanting to offer a commercial version of bzr?
[20:38] <beuno> they *will* use it in other scenarios if the situation comes up
[20:38] <luks> beuno: but tell me that Canonical doesn't offer a non-GPL version of Bazaar
[20:38] <beuno> luks, I am not aware that they do
[20:38] <RenatoSilva> lifeless: ok, so why not Canonical disclaims copyright to FSF or some non-profit organization? Because they like to have control and be free to do whatever they want in the future, regardless of that meaning that the actual code authors can't do anything about it
[20:39] <lifeless> luks: Canonical does not offer a non-GPL version of Bazaar
[20:39] <lifeless> luks: have a look at our website; we offer support and training.
[20:39] <luks> lifeless: well, I've seen posts on the bzr ML telling people to talk to Canonical about such posibilities
[20:40] <lifeless> luks: http://www.canonical.com/projects/bazaar
[20:40] <Peng> The Bazaar website *used* to mention it before the redesign.
[20:40] <luks> (posts by Canonical employees)
[20:41] <lifeless> Peng: perhaps; nevertheless we've never done it, and its not suggested now AFAIK
[20:42] <Peng> lifeless: Interesting.
[20:43] <lifeless> RenatoSilva: I don't really follow your logic there. This has been discussed on the mailing list very recently too.
[20:43] <Peng> http://web.archive.org/web/20080527233931/http://bazaar-vcs.org/: "If you want to embed Bazaar into your products under a different license, please contact us."
[20:44] <Peng> That's what it said.
[20:44] <Peng> FYI.
[20:44] <RenatoSilva> luks: withy that single copyright, they can embed Bazaar into commercial software at any time, for own benefit or any other reason (and without notifying the community -- I'm afraid the agreement doesn't even cover this). I don't like this idea, and others don't either (hg users seem to not like this aspect of bazaar)
[20:44] <lifeless> Peng: yup.
[20:44] <lifeless> Peng: To the best of my knowledge it never happened.
[20:44] <luks> RenatoSilva: I know why are they doing it :)
[20:45] <lifeless> RenatoSilva: I think you mean 'proprietary' rather than 'commercial'
[20:49] <Peng> I think this was the third time i started a copyright argument in this channel. :D
[20:51] <RenatoSilva> lifeless: yes, as commercial software anre usually proprietary. But what I strictly mean is any derived work that the author would not agree with. For example, I think Bazaar contributors would not like to see their code being distributed as BSD for some customer.
[20:51] <RenatoSilva> s/anre/are
[20:52] <lifeless> do you really think we'd do that?
[20:52] <luks> RenatoSilva: Bazaar contributors always had to assign the copyright to Canonical, even if without a signed agreement, I think they would be fine with it
[20:56] <RenatoSilva> the commercial nature is a negative point in that matter. It's the same as saying that you don't trust Chrome binaries, then one says you shouldn't trust FF's either. However, Mozilla foundation is far different from Google, and that makes a big difference in which you trust more (or suspect less)
[20:57] <bialix> what's the point?
[21:01] <RenatoSilva> luks: I would not be fine. I would not like to see my free time spent for the benefif of all people in a work that now I have no control, and that now is delivered as BSD which may become easily a proprietary software making them (not me) gaining money with my work whose initial intention was to benefit everybody, not someone (and worse, someone *else*).
[21:02] <lifeless> RenatoSilva: Even if Canonical went evil and did something like that, the current GPL code would stay GPL, everyone would still be getting the benefit from it.
[21:03] <lifeless> but we're not evil - as stewards of Bazaar I think we do pretty well
[21:04] <RenatoSilva> lifeless: ok but as we said, we have no control behind the scenes, unless Canonical includes a compromise in the agreement of informing teh world of anything different they do with the contributions, which would make things less interesting commercially, which makes me wonder if they would do such a thing.
[21:05] <RenatoSilva> lifeless: I don't know if you are evil :) But just like we say here in my country, we stay with one feet behind :)
[21:06] <lifeless> you have no control with any assignment anywhere (even FSF).
[21:06] <luks> but the chances of FSF selling your code are pretty thin :)
[21:07] <luks> well, "your"
[21:07] <RenatoSilva> lifeless: but FSF is not Canonical, they're different natures.
[21:07] <RenatoSilva> yes, can anyone imagine Stallman in some TV commercial selling "hey GNU/Hurd for only $99"
[21:08] <LarstiQ> RenatoSilva: yeah, for one thing, Canonical employees actually wrote the vast majority of bzr
[21:08] <LarstiQ> and RMS certainly has nothing to do with the Hurd
[21:10] <RenatoSilva> maybe Bazaar should be maintained by a non-profit organization with legal commitment to public interests
[21:10] <RenatoSilva> about selling the code, that's much more easy to imagine with a commercial company than with that crazzy man
[21:11] <chx> I have a technical question. For trac+bzr i would like to point to one place but if that's one branch then it's not possible to check out / commit parts . I would like to get something like an svn repo (and bzr init-repo is not a branch either)
[21:11] <chx> how do people use trac+bzr to support multiple branches?
[21:12] <mwhudson> lifeless: btw i would be interested what a test for https://code.edge.launchpad.net/~mwhudson/bzr/bytestring-environment-variables/+merge/15113 would look like
[21:13] <mwhudson> lifeless: or more particularly i guess, where it would go
[21:14] <mwhudson> hm, i guess TestTestCaseWithMemoryTransport
[21:16] <bialix> chx: I'm not quite understand your question
[21:17] <chx> bialix: nevermind
[21:17] <lifeless> mwhudson: seems relevant
[21:17] <lifeless> mwhudson: perhaps higher up
[21:17] <bialix> chx: ?
[21:17] <lifeless> chx: this is one of the problems with trac; its got a _very_ svn specific model.
[21:17] <chx> bialix: I now read the trac-bzr README and it says "Allows a collection of branches to be treated as a "trac repository", regardless of whether they are related or in the same bzr repository."
[21:17] <bialix> luks: evening
[21:17] <bialix> chx: yes
[21:18] <mwhudson> lifeless: overrideEnvironmentForTesting, the method i'm patching is on TestCaseWithMemoryTransport
[21:18] <lifeless> mwhudson: then ttwmt is right
[21:18] <lifeless> :)
[21:18] <luks> hi bialix
[21:18] <chx> I am fine, i am fine, sorry for asking and not RTFMing
[21:18] <bialix> luksL how are you?
[21:18] <bialix> luks: I have question about lazy_register in qbzr
[21:19] <luks> is there a problem with it?
[21:20] <bialix> luks: register_lazy_command deliberately don't use plugin_cmds.register_lazy
[21:20] <bialix> luks: no, not the problem, I just trying to figure out how to slightly change it
[21:20] <luks> I think it should only use plugin_cmds.registry_lazy now
[21:21] <bialix> luks: that's my guess as well
[21:21] <luks> there was the problem with overwriting commands
[21:21] <luks> but I see that's now commented how, so it no longer overwrites merge
[21:21] <luks> the custom function was mainly necessary to provide lazy registration before bzrlib supported that
[21:22] <bialix> luks: I want to put all lazy commands definitions into big tuple and iterate over it inside one function instead of calling it again and again
[21:22] <luks> that seems good
[21:22] <luks> I think bzrtools does something like that, right?
[21:22] <bialix> luks: yes, we have conflicts with pipeline plugin about overriding merge
[21:23]  * bialix looks into bzrtools
[21:24] <bialix> luks: yes, bzrtools using dict as map between cmd names and aliases
[21:24] <luks> ah
[21:24] <bialix> I'd prefer keep them as tuples (as it looks now)
[21:24] <luks> yep
[21:25] <bialix> ok, thx :-)
[21:25] <luks> didn't help much :)
[21:26] <bialix> well, you said yes two times where I need
[21:26] <bialix> this helps
[21:26] <bialix> luks: if you still want to get notifications about new revisions in qbzr trunk you may want to subscribe to trunk2a branch
[21:27] <mwhudson> lifeless: https://code.edge.launchpad.net/~mwhudson/bzr/bytestring-environment-variables/+merge/15136 has a test now, who can we hassle into being the second reviewer?
[21:27] <luks> heh, I've been busy enough last weeks that I didn't even notice :)
[21:27] <luks> thanks
[21:28]  * bialix hopes it was not too much shameless
[21:36] <luks> heh, I see jelmer is also working on bzr-hg
[21:37] <luks> I wonder in what state it is
[21:38] <mwhudson> luks: it'll probably a code import option on lp in a couple of months
[21:38] <mwhudson> maybe even in december i guess
[21:39] <luks> cool
[21:39] <luks> do you think dpush works/will work soon?
[21:40] <mwhudson> i don't know, but would guess on "soon" if it doesn't work yet
[21:40] <luks> I need to try it out
[21:41] <luks> I really don't get what people like about hg
[21:41] <luks> I've tried hard to work with it, but I find my way around it
[21:41] <luks> +can't
[21:42] <luks> speaking of the devil :)
[21:42] <luks> hi jelmer
[21:42] <meoblast001> hi
[21:42] <meoblast001> i set up a bzr repository on my system, how can i make it public?
[21:42] <meoblast001> it uses SSH
[21:42] <lifeless> mwhudson: Do you have commit access yet?
[21:42] <bialix> luks: I don't know why, but I can't force myself to use hg longer then 15 minutes
[21:43] <mwhudson> lifeless: no
[21:43] <luks> bialix: I have hard time understanding how they work with multiple branches
[21:43] <lifeless> poolie: ^ mwhudson for commit access?
[21:43] <luks> bialix: it seems multiple clones is the way to go, which is just weird
[21:43] <jelmer> hey luks
[21:44] <bialix> meoblast001: serve it via http perhaps?
[21:44] <luks> jelmer: I was wondering, does dpush work in bzr-hg?
[21:44] <meoblast001> hm :/
[21:44] <jelmer> luks, no, not yet
[21:44] <meoblast001> so just put the repository in /var/www?
[21:44] <meoblast001> or make a symlink to the directory? (is that possible)
[21:44] <jelmer> luks: well, it might sortof work if you don;t add any new files
[21:44] <bialix> luks: multiple branches is not worse, multiple unnamed heads is nightmare
[21:45] <luks> jelmer: ok, no problem, I just noticed that you were working on it
[21:46] <luks> (on bzr-hg)
[21:46] <bialix> what's the cool tool to check python sources for unused imports? pyflakes?
[21:46]  * bialix don't remember
[21:48] <bialix> hmm, it seems what I'm looking for: https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
[21:48] <bialix> mwhudson: your branch still not merged to upstream? hm?
[21:49] <chx> oh btw. thanks for using python. i am not python coder. but , that does not stop me from coding in python when there is a need.
[21:49] <mwhudson> bialix: i haven't proposed it, it seems a bit bzrlib specific
[21:49] <chx> (I wrote a two way skype-konversation gateway in less than 40 min when i first tried .py coding earlier this year. easy...)
[21:50] <bialix> mwhudson: um, ok
[21:52] <bialix> chx: it's strange but I've chose bzr mostly because it was written in python (initially)
[21:52] <meoblast001> i want to make my repository accessible via HTTP, but i don't want to have to type bzr push bzr+ssh://blah.com/var/www/bzr
[21:52] <meoblast001> the /var/www shouldn't be necessary
[21:53] <chx> bialix: I picked bzr when meld began to support it (yes. that was very very long ago)
[21:54]  * bialix not using meld unfortunately
[21:54] <chx> bialix: now I am migrating my team to it four years later because a) yes, python. we are php guys but I know we won't stuck in a corner because of python b) it's atomic. and it means it. really. one dir , one commit. no messing with less c) easy to learn.
[21:55] <bialix> d) it has good GUI
[21:56] <chx> svn and git with its staging area fails b) and after i needed to abandon an svn branch because it got so messed up with subdir commits -- I do not want to be there any more
[21:56] <bialix> mwhudson: anyway your branch is cool: `commands.py:22: import of 'sys' could be lazy` -- cool
[21:56] <mwhudson> bialix: yeah, it's ok
[21:56] <bialix> thanks mwhudson
[21:56] <lifeless> meoblast001: You can use a bookmark to make 'myserver:' mean 'bzr+ssh://blah.com/var/www/bzr', then you could do 'myserver:foo'
[21:56] <lifeless> meoblast001: (install bzr-bookmarks)
[21:56] <mwhudson> bialix: though it's a bit trigger happy -- not much reason to import sys lazily...
[21:57] <meoblast001> lifeless: better question.. how does Launchpad do it?
[21:57] <meoblast001> i want a familiar design
[21:57] <lifeless> meoblast001: custom ssh implementation
[21:57] <bialix> mwhudson: I'm mostly happy about it's overall behavior
[21:57] <meoblast001> :/
[21:57] <meoblast001> lifeless: where can i get this custom ssh implementation?
[21:57] <lifeless> meoblast001: in the launchpad source code
[21:57] <meoblast001> and can i run it and a normal ssh at the same time?
[21:58] <lifeless> not on the same port
[21:58] <meoblast001> on different ports
[21:58] <lifeless> you'll have to do some development, or run a pretty big subset of launchpad itself
[21:58] <bialix> mwhudson: just one nitpick: `pyflakes -h` don't want show me even smallest help
[21:58] <luks> does it really matter if you type /var/www or not, it's only once
[21:59] <meoblast001> lifeless: can you symlink directories?
[21:59] <meoblast001> perhaps that is an option
[21:59] <mwhudson> bialix: that's a pyflakes thing, it doesn't do any option processing at all
[21:59] <mwhudson> bialix: and it sucks, yes
[21:59] <bialix> mwhudson: bzr teached me to use -h all the time :-/
[22:00] <bialix> so now all other utilities that does not react on -h just look sweird
[22:00] <lifeless> meoblast001: yes you can
[22:00] <meoblast001> lifeless: that would work perfectly
[22:06]  * bialix loves pyflakes
[22:16] <poolie> hello bialix
[22:17] <poolie> lifeless: mwhudson++
[22:17] <bialix> hello poolie :-)
[22:17] <poolie> lifeless: also, remember, you can use your discretion as to whether a second review is needed
[22:17] <lifeless> poolie: yes, I am.
[22:19] <lifeless> poolie: I've made too many mistakes myself on equally small things to be inclined to short circuit review trivially.
[22:19] <poolie> fairy nuff
[22:19] <poolie> iwbni launchpad made it more clear which reviews i could vs should do
[22:20] <meoblast001> bzr: ERROR: Server sent an unexpected error: ('error', "Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\\n'")
[22:20] <meoblast001> that's 1.9.. shouldn't the Jaunty version of Bazaar work with that?
[22:20] <meoblast001> or wait.. i think i have hardy on my server >.<
[22:20] <poolie> meoblast001: there's a hardy 2.0 in the ppa
[22:20] <meoblast001> ah, ok
[22:23] <mwhudson> hnngh
[22:28] <mwhudson> spiv: hello
[22:29] <lifeless> poolie: code.launchpad.net/bazaar/+activereviews is a useful page.
[22:29] <poolie> it's a great page
[22:29] <poolie> i wouldn't say it's optimal though
[22:30] <bialix> 2.0.2 and 2.1.0b3 is not annonced yet? where is jam?
[22:31] <mwhudson> b3 got announced, i thought?
[22:32] <bialix> mayb channel topic needs tuning then?
[22:32] <mwhudson> spiv: nm
[22:33]  * bialix waves and disappear
[22:33] <lifeless> spiv: have you pushed your pqm-submit fixes to trunk?
[22:51] <meoblast001> lifeless: another question.. how does Launchpad manage permisions?
[22:52] <meoblast001> SSH works using the UNIX filesystem, and permisions are done with groups
[22:53] <mwhudson> lifeless: how does commit access relate to "not having to get two reviews" ?
[22:54] <lifeless> mwhudson: as a committer you count ass one of the two reviews.
[22:54] <lifeless> and also get to land your own things. I'm bored of ferrying things for you :)
[22:54] <mwhudson> lifeless: ok
[22:54] <Peng> meoblast001: Launchpad runs a custom SSH server.
[22:54] <meoblast001> oh
[22:55] <meoblast001> ok
[22:55] <mwhudson> lifeless: i was aware the two were related, but not sure that they were precisely the same
[23:14] <lifeless> mwhudson: oh and it also means you can be the +1 on other peoples merges.
[23:14] <mwhudson> lifeless: ah right
[23:18] <mwhudson> lifeless: so, to be sure, you're ok with me landing that bytestring-environment branch?
[23:19] <lifeless> yes, with poolies concerns addressed.
[23:19] <spm> lifeless: I've only added him to bzr, not bazaar_releasemgr - that was the intent y/n?
[23:19] <lifeless> spm: yes, its fine
[23:19] <spm> coolio
[23:21] <lifeless> james_w: ever seen this:
[23:21] <lifeless> bzr merge-upstream ../lptools-0.0.1.tar.gz bzr+ssh://bazaar.launchpad.net/~dobey/lptools/trunk/ --version=0.0.1
[23:21] <lifeless> ~bzr9
[23:21] <lifeless> Using distribution karmic
[23:21] <lifeless> gzip: stdout: Broken pipe
[23:21] <lifeless> tar: Child returned status 1
[23:21] <lifeless> tar: Exiting with failure status due to previous errors
[23:22] <lifeless> running tar xzf ...ptools_0.0.1.orig.tar.gz -C /tmp/tmphzmaq2 --strip-components 1 by hand works
[23:25] <mwhudson> lifeless: oh, i hadn't seen his review yet
[23:28] <james_w> lifeless: please file a bug, I think I know the cause
[23:33] <lamalex> Does anyone know about the bzr integration for monodevelop?
[23:36] <spiv> lifeless: not yet, I still haven't gotten around to looking at the tests
[23:37] <lifeless> james_w: if you can give me a hint I'd love to fix it - am a tad blocked.
[23:37] <james_w> lifeless: search for preexec_fn in the source
[23:38] <james_w> something like that anyway
[23:38] <james_w> subprocess doesn't reset SIGCHILD
[23:38] <james_w> so you have to do it for it
[23:38] <james_w> it might be something else, but it looks sufficiently similar
[23:38] <lifeless> james_w: tar is invoked using 'os.system'
[23:38] <lifeless> import_dsc.py _extract_tarball_to_tempdir
[23:40] <james_w> well, maybe that is affected too
[23:40] <lifeless> so, you change SIGCHILD in bzr builddeb ?
[23:40] <james_w> no
[23:40] <james_w> except to reset it when something else is execed
[23:41] <lifeless> do you mean SIGPIPE ?
[23:41] <james_w> yeah, sorry
[23:41] <james_w> http://bugs.python.org/issue1615376
[23:42] <james_w> http://bugs.python.org/issue1652
[23:44] <lifeless> thanks
[23:44] <lifeless> I'll submit a branch shortly.
[23:44] <igc> morning
[23:45] <mwhudson> perhaps dumping this comment into irc isn't super appropriate
[23:46] <mwhudson> but from launchpad's pov it would help to know at connection time whether bzr ever intended to write to the thing being opened
[23:46] <lifeless> mwhudson: it would help bzr too in some ways
[23:47] <mwhudson> i guess it would be quite an upheaval
[23:54] <lifeless> james_w: linked
[23:55] <lifeless> james_w: so bzr-builder -> 2a. spm has a script that can upgrade everyones branches.
[23:55] <spm> I do?
[23:56] <lifeless> spm: jkakars thing
[23:56] <spm> didn't work :-)
[23:56] <lifeless> spm: data problem, not script
[23:57] <lifeless> spm: remember the old bug with bzr branches not having enough data?
[23:57] <spm> heh; doesn't ring a bell....
[23:57] <eric_f> anyone have a script (that will work on OS X) to do a "bzr status" on multiple project's in a workspace? I had CD'ing into each folder and running bzr status!
[23:57] <lifeless> eric_f: for dir in `ls $1` ...
[23:58] <lifeless> spm: bug 364 something
[23:58] <spiv> Bug 354036
[23:59] <eric_f> lifeless: just type that in the console?
[23:59] <spm> spiv: that scares me when you do that. ;-)
[23:59] <spiv> spm: that bug number has been etched into my brain.
[23:59] <lifeless> jkakar: ^
[23:59] <spiv> I actually checked the NEWS file just in case, but no, I remembered it all too clearly :)