[00:03] <Noldorin> lifeless: no, i didn't
[00:03] <Noldorin> lifeless: i disappeared offline for after my laptop lost power. sorry
[00:11] <lifeless> Noldorin: whats the bug number for this problem
[00:15] <Noldorin> lifeless: i still haven't been sure what to submit yet :)
[00:15] <Noldorin> i've been testing the repo a bit more the past day
[00:16] <Noldorin> seems init always succeeds
[00:16] <Noldorin> or almost always
[00:19] <lifeless> Noldorin: please file a bug.
[00:19] <lifeless> it lets us gather data.
[00:19] <Noldorin> lifeless: ok, will do. what should i detail specifically as the cause though?
[00:19] <lifeless> Don't worry about it being 'right' - bugs are conversations.
[00:19] <Noldorin> yeah, probably a good idea
[00:20] <Noldorin> hmm
[00:20] <Noldorin> fair enough
[00:20] <lifeless> if we knew the cause, we probably wouldn't need a bug ;)
[00:21] <Noldorin> lifeless: knowing the cause can often (though not always) still be quite a long way from the fix ;)
[00:21] <lifeless> thats true too :)
[00:22] <Noldorin> heh, we've made progress in understanding at least
[00:34] <Noldorin> lifeless: interestingly, breaking the lock doesn't seem to be a problem now
[00:34] <lifeless> is that with the delay in it?
[00:34] <Noldorin> nope
[00:35] <Noldorin> don't have that available on this comp at the moment, unfortunately
[00:36] <lifeless> ok
[00:36] <Noldorin> (the source and dependencies that is)
[00:36] <lifeless> ok
[00:47] <Noldorin> ok, submitted now
[00:47] <Noldorin> #412244
[00:48] <Noldorin> lifeless: https://bugs.launchpad.net/bugs/412244
[00:48] <lifeless> thanks
[00:48] <Noldorin> no problem
[00:49] <Noldorin> it's probably still very incomplete at the moment
[00:49] <Noldorin> but it describes the core of the problem
[00:50] <Noldorin> i don't have some of the logs i posted you earlier, but i'm sure we can get them again if they're relevant :)
[00:55] <Noldorin> lifeless: ah, i see your summary already.
[00:56] <Noldorin> i'll be hear for a while longer, if you care to debug things further with me
[00:56] <Noldorin> here*
[00:56] <Noldorin> :P
[00:56] <lifeless> I'm in the middle of a few other things right now
[00:56] <Noldorin> alright, sure
[00:56] <lifeless> When I get a chance I'll brain dump my memory to the bug
[00:56] <Noldorin> well ping me if you have a miunte :)
[00:56] <Noldorin> otherwise no worries
[00:56] <Noldorin> ok cheers
[00:59] <lifeless> igc: ping
[00:59] <lifeless> igc: do the docs in trunk suggest in-place upgrade or doing rename dances?
[00:59] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374735
[01:25] <igc> lifeless: http://doc.bazaar-vcs.org/bzr.1.18rc1-html/en/upgrade-guide/index.html
[01:25] <igc> lifeless: the process is that recommended by thumper wrt stacked branches
[01:25] <igc> morning all
[02:08] <lifeless> igc: so, I think this approach is a real problem
[02:08] <lifeless> igc: should I talk to you or thumper about that
[02:09] <igc> lifeless: thumper. I'm happy to write up what you agree
[02:09] <lifeless> thumper: ping
[02:10] <thumper> whazzup?
[02:10] <igc> lifeless: but the one thing I do want is a *simple* answer, even if that means more code in bzr or lp
[02:10] <igc> lifeless, thumper: complex won't cut it imo
[02:14] <lifeless> igc: my way is real simple: bzr upgrade URL
[02:14] <lifeless> igc: its a fraction of the way described in your docs; which is why I asked about this in the merge review before it was merged :(
[02:15] <lifeless> thumper: I think the upgrading docs should just say to upgrade all the branches in place. I'm not sure why they describe uploading new branches, shuffling stuff around, and igc points me at you to discuss this.
[02:15] <thumper> lifeless: if you can fix the bugs, then sure, upgrade in place
[02:15] <lifeless> thumper: _what bugs_
[02:16] <thumper> lifeless: there are bugs filed that it doesn't work
[02:16] <thumper> lifeless: upgrading stacked branches fails
[02:16] <lifeless> I've seen one failure, which isn't upgrade relaated, its a fetch failure - being fixed at the moment.
[02:17] <lifeless> We can't release 2.0 with fetch failures anyway; so I think we should be documenting in-place and *if* we get new bug reports fixing them.
[02:17] <thumper> lifeless: ok... well if it works, then do it in place
[02:18] <lifeless> this will use less disk space on launchpad, avoid dead branches, keep bug links and reviews intact etc.
[02:18] <thumper> sure
[02:25] <lifeless> igc: ^
[02:39] <lifeless> vila: ping
[03:01] <emmajane> igc, I hope I'm dismissed from writing up the summary of the RFC that turned into secretaries and incompetent developers. ;)
[03:08] <thumper> lifeless: can packs (or later non-rr) be stacked on 2a now?
[03:08] <lifeless> no, stacking is format locked
[03:09] <lifeless> you can upgrade something thats invalidly stacked though - upgrade doesn't open the basis branch
[03:17] <igc> emmajane: yes :-)
[03:17] <emmajane> igc, *phew* :)
[03:17] <igc> emmajane: a nice case study though on why reporting bugs is good practice :-)
[03:17] <emmajane> igc, did y'all know that was going to happen when poolie asked me to write up the RFC?
[03:18] <igc> emmajane: predicting the future isn't my strong point, so no
[03:18] <emmajane> heh
[03:19] <emmajane> as long as it wasn't "trial by fire for the newb" ;)
[03:24] <fullermd> Oh, no.  Nobody thinks it through that much.  It's more like "trial by fire for somebody other than me"...
[03:24] <emmajane> hehe
[03:41]  * igc lunch
[04:02] <SamB> igc: well, it looks like the git source tree is GPL v2 (only)
[04:03] <fullermd> Coming out of Linus, I'd be a little surprised to see it otherwise.
[04:13] <SamB> sometimes he mixes it up a little and says "let's SPL this" ;-P
[04:13] <SamB> (more or less)
[04:14] <fullermd> Pfft, spl's are so 1985...
[04:15] <SamB> even GNU says you might as well use them when your program is shorter than the GPL itself
[04:16] <SamB> SPLs are my favorite, and I was born in '86 ;-P
[04:17] <lifeless> special purpose limousine?
[04:17] <SamB> Simple Permissive Licenses
[04:17] <fullermd> Alas, my archaic kernel humor is lost on you people   :p
[04:17] <SamB> like BSD3, BSD2, or better, something which doesn't have <organization> in it ;-P
[04:23] <SamB> hmm, you know, the latest PPA build has the wrong version number ...
[07:23] <vila> hi all
[07:27] <lifeless> hi
[08:22] <jml> lifeless, yep :)
[08:24] <lifeless> jml: excellent
[09:50]  * igc dinner
[09:53] <vila> lifeless: just noticed your earlier ping :-/
[12:13] <bialix> hi bzr hackers, what is used in bzrlib internally as revision id of None revision (-r0)? Just Python's None? Or some special string?
[12:17] <bialix> I suppose it's a NULL_REVISION="null:"
[12:25] <poolie1> hello all
[12:26] <poolie1> bialix: yes it is
[12:34] <bialix> poolie1: hi
[12:35] <bialix> poolie1: did you receive my mail about qbzr site? (I don't need the answer right now, but in next couple of days will be nice to get some comments from you or I should ask another Canonical person?)
[12:36] <bialix> rats
[12:36] <bialix> Elvis left the building
[13:25] <johnf1> jelmer: you about?
[13:25] <jelmer> johnf: somewhat
[13:25] <johnf> jelmer: are you planning to split out bzr-doc in debian like we've done in the PPA?
[13:30] <jelmer> johnf: it's on my list of things to look into, I just haven't found time to do so yet
[13:30] <johnf> jelmer: ok no problems
[13:31] <johnf> I'd offer to help out with the debian packaging but I'm still waiting to become active again. Getting out of emeritus status is painful
[13:32] <jelmer> johnf: you're welcome to help regardless
[13:32] <jelmer> johnf: You should be able to join the packaging team on alioth without being a DD, although you'll still need sponsoring to do actual uploads
[13:32] <jelmer> but commits to the bzr repo shouldn't be a problem
[13:33] <johnf> ok cool.
[13:33] <tvainika> about bzr-git, how much is currently missing from bzr checkout git+ssh://repo; $EDITOR LL.po; bzr commit -m 'something' (with bound branch)? I just wonder because I'm reluctant to learn git and I wonder if I could bzr-git for gnome translations :)
[13:33] <johnf> I figure it makes sense for me to help out with both. I may as well build and upload the debian packages at the same time I do the PPA ones
[13:35] <jelmer> johnf: yeah, that makes sense
[13:35] <jelmer> tvainika: I'm not sure how well checkouts work, standalone branches should work
[13:36] <jelmer> tvainika: they shouldn't be hard to get working in any case. if you find they don't work, please file a bug and I'll look into it.
[13:36] <jelmer> LarstiQ: do you know what happened to 1.17.1?
[13:53] <smoser> apologies for newbie-ish question. If I bzr branch from some location, make some changes (bzr commit), how can I see what those changes were ?
[13:53] <smoser> in git, i'd "git log HEAD..origin/master" or "git diff origin/master"
[13:57] <luks> bzr diff --old path/to/the/other/branch
[13:57] <luks> but there is also bzr missing
[13:58] <luks> or bzr diff -r ancestor:
[13:59] <LarstiQ> jelmer: got pqm sorted out on monday and submitted some things, did another cherrypick but not submitted yet
[13:59] <LarstiQ> jelmer: at HAR now, and it's too rainy to pitch a tent
[13:59]  * LarstiQ sends a pqm request instead
[14:00] <jelmer> LarstiQ: ah
[14:00] <jelmer> Let's talk about this at HAR then >-)
[14:00] <jelmer> I'll be there for the first two days
[14:01] <LarstiQ> jelmer: ah cool, I thought you wouldn't attend
[14:01] <LarstiQ> jelmer: you _do_ have a ticket?
[14:01] <jelmer> yeah
[14:01] <jelmer> I bought one early but was considering selling it again because I had to miss the last two days
[14:01] <jelmer> but I decided to go anyway, don't want to wait *another* 4 years
[14:02]  * LarstiQ nods
[14:16] <smoser> luks, thanks
[15:06] <Tak> jelmer: any thoughts? http://paste2.org/p/375184
[15:06] <Tak> that's on a small commit to a big bzr-svn bound branch
[15:07] <Tak> got a similar one on update as well; other operation seem to be fine
[15:07] <Tak> err, from monodevelop-bzr ^^
[16:23] <igc> night all
[16:24] <bialix> igc: night
[16:24] <bialix> vila: bonjour!
[16:25] <vila> hello bialix
[16:25] <bialix> I've finally managed to finish commit_data stuff
[16:26] <bialix> if you want comment on my approach, it will be nice
[16:26] <bialix> code is here: https://code.launchpad.net/~qbzr-dev/qbzr/commit_data
[16:26] <bialix> vila: ^
[16:27] <emmajane> beuno, ping
[16:27] <emmajane> igc, night :)
[16:28] <beuno> emmajane, hi
[16:29] <emmajane> beuno, hey :) Any updates from the designers?
[16:29] <beuno> emmajane, none. I haven't even managed to get confirmation of the time being booked yet
[16:29] <beuno> I have a call in 2 hours that gives me hope  :)
[16:29] <emmajane> beuno, :(
[16:30] <emmajane> hopefully the call has good news!
[16:31] <poolie1> hello emmajane, beuno
[16:31] <emmajane> poolie1, hey :)
[16:32] <beuno> poolie1, hey!  What are you doing around here at this hour?
[16:32] <poolie1> i'm in Taipei, going to the COSCUP conference this weekend and to visit canonical here
[16:33] <beuno> poolie1, ah! that's right
[16:33] <beuno> how's Taipei?
[16:33] <poolie1> good
[16:33] <poolie1> i just got to the hotel
[16:33] <poolie1> am gaing to bed soon, it's 1130
[16:34] <emmajane> poolie1, I thought today was a travel day for you. But then all I could remember was, "Wednesday"
[16:36] <poolie1> it is, i've been travelling all day and then i just arrived
[16:36] <poolie1> it's the end of my wednesday
[16:36] <beuno> poolie1, enjoy Taipei
[16:36] <emmajane> poolie1, :/ sleep will be nice for you then. :)
[16:37] <vila> hi poolie1 !
[16:53] <poolie1> hi vila
[16:54] <bialix> poolie1: do you will be able to comment on my mail during this week?
[16:54] <poolie1> hi,
[16:55] <poolie1> any mail in particular?
[16:55] <poolie1> i am going to be reading some
[16:56] <bialix> poolie1: about Qbzr site, Gary asking to stay on bazaar-vcs.org
[16:57] <poolie1> oh ok
[16:57] <poolie1> i'll look
[16:57] <bialix> it's not urgent, but I'd like to know how busy you are
[16:58] <poolie1> i saw the thread but i didn't read all of it
[17:00] <bialix> check qbzr ML
[17:00] <poolie1> ok, answered
[17:01] <poolie1> i hope that helps
[17:01] <bialix> thanks
[17:03] <poolie1> did that answer the question?
[17:07] <bialix> poolie1: what it means: "We could arrange for qbzr to point to some site you like."
[17:07] <bialix> ?
[17:07] <poolie1> we can add a dns entry for it
[17:07] <bialix> i.e. qbzr.bazaar-vcs.org?
[17:08] <poolie1> right
[17:08] <bialix> ok
[17:09] <bialix> I need to catch garyvdm now. But it seems ok for me. (less money for domain)
[17:10] <bialix> poolie1: we have a big move for last year
[17:11] <poolie1> ?
[17:11] <poolie1> a big change since last year?
[17:11] <bialix> poolie1: we want to release qbzr 1.0 soon
[17:11] <bialix> yes
[17:11] <poolie1> cool
[17:11] <poolie1> it seems to be moving really well
[17:11] <bialix> so the site will be nice additon for this
[17:11] <bialix> Gary is really wizard
[17:13] <bialix> poolie1: it's a shameless, but I can't resist: https://www.ohloh.net/p/compare?metric=Codebase&project_0=QBzr&project_1=Bazaar+GTK%2B+frontends
[17:13] <jam> poolie1: aren't you up *way* to late?
[17:13] <jam> or is it a different TZ?
[17:13] <poolie1> i'm 2 hours earlier, but it's still late and i should sleep
[17:13] <poolie1> bialix, wow
[17:14] <poolie1> i'm just going to mail S then sleep
[17:14] <Tak> doesn't that just show it takes way more LOC to do the same thing using qt? ;-P
[17:14] <bialix> Tak: :-P
[17:14] <bialix> :-P :-P
[17:14] <bialix> :-P :-P :-P
[17:15]  * Tak moc < bialix 
[17:15] <bialix> what is "moc <" ?
[17:15] <Tak> hmm, doesn't qt still use moc?
[17:16] <Tak> http://doc.trolltech.com/4.0/moc.html
[17:17] <bialix> Tak: we're using PyQt
[17:18] <Tak> so pyqt uses some dynamic stuff to avoid all the mocery?
[17:19] <bialix> I guess so
[17:20]  * bialix disappear
[17:22] <luks> Tak: moc is just a way to have meta information about classes in a static language such as C++
[17:22] <luks> Tak: you can get all that info from Python objects at runtime
[17:22]  * Tak nod
[17:24] <jam> luks: well given that moc is a precompiler, is it really even that?
[17:24] <jam> I thought it was just a way to have nice syntax for slots
[17:24] <luks> jam: it's not a precompiler
[17:24] <luks> jam: it extracts info from .h files into _moc.cpp files
[17:24] <luks> jam: the nice syntax is standard c++
[17:24] <luks> (#defines)
[18:26] <jelmer> Tak: sorry, no idea, haven't seen a crash in a while
[18:26]  * Tak nod
[18:27] <Tak> and the c#->c->python->c->python roundtrip is nice for debugging anyway ;-)
[18:29] <jelmer> :-)
[19:04] <divokz1> Could anyone point me to a resource on storing the current revision number in a file using a commit hook?
[19:05] <divokz1> I tried making my own pre_commit hook, but it's one revision behind (the commit doesn't send the updated file)
[19:05] <divokz1> Any ideas?
[19:08] <andy_> I'm looking for some input on converting projects from svn to bzr.  I'm using nested trees to mimic svn:externals but am not sure which repo format would work best.  Seems like the options that I've tried that work are for me (v1.13.1) are:  rich-root (complains alot tho), i.9-rich-root and development-subtree.  Any recommendations/suggestions as to which format to use?
[19:08] <divokz1> Google hasn't been helping either...
[19:34] <Kinnison> divokz1: look for the keywords plugin
[19:38] <cody-somerville> jam, I don't think lp #412657 is a dup
[19:38] <james_w> cody-somerville: it's a dupe of something
[19:38] <james_w> perhaps just not that one :-)
[19:38] <james_w> let me find the correct one
[19:38] <jelmer> andy_: nested trees don't work yet..
[19:38] <jam> cody-somerville: update fails when updating from master branch
[19:38] <jam> I'm pretty sure both are a dupe of a third bug
[19:39] <jam> but perhaps I typed the wrong bug #
[19:39] <jam> cody-somerville: bug #412223
[19:40] <jam> though ISTR yet another bug
[19:40] <jam> with this same basic issue
[19:40] <jam> sorry about the noise of the wrong bug #
[19:41] <cody-somerville> In this other case, was it working and then stopped?
[19:41] <jam> cody-somerville: we changed normalization rules somewhere
[19:41] <cody-somerville> jam, bzr hasn't been updated
[19:41] <jam> so doing "bzr-old co $PROJECT; bzr-new up" was failing
[19:42] <jam> cody-somerville: so sometime when it fails for you
[19:42] <james_w> jam: I remember that other bug as well, but I can't find it either
[19:42] <jam> try doing "cat .bzr/branch/branch.conf"
[19:42] <jam> to see what we have recorded as the master branch
[19:42] <jam> and I'm also 90% sure that all these failures will be found with branches with "~" in them
[19:42] <jam> which is the bug
[19:43] <jam> of course, all LP branches have ~ so that isn't a great discriminator
[19:44] <andy_> jelmer: They've been working for me so far as long as I use rich-root, 1.9-rich-root or development-subtree and don't use the --reference option when doing a join.
[19:47] <andy_> jelmer: I'm using v 1.13.1
[19:49]  * Tak can't wait for externals=>nested-trees support in bzr-svn
[19:51] <andy_> jelmer: so, are you saying that nested trees are unstable/should be avoided?
[19:54] <andy_> anyone here using nesting successfully?
[19:55] <cody-somerville> jam, the ones that work have ~ in them too :P
[19:56] <jelmer> andy_: by-value nested trees should work and are stable
[19:56] <jelmer> andy_: svn:externals is the equivalent of --reference
[19:57] <andy_> jelmer: ahh...thanks for clarifying.
[19:57] <jelmer> andy_: for by-value nested trees, use 1.9-rich-root
[19:57] <jam> cody-somerville: out of curiosity, does it only break on projects that you don't have commit access to?
[19:57] <jam> (aka readonly branches)
[19:57] <jelmer> andy_: or just plain --default-rich-root
[19:58] <jelmer> andy_: which is an alias for the default rich root format
[19:58] <andy_> jelmer: thanks.  So, by-value nested trees keep a copy of the branched tree in the containing tree rather than just a pointer to it?
[19:58] <jelmer> andy_: yes
[19:59] <andy_> jelmer: any idea of a by-value tree could be converted later on when --reference becomes stable?
[19:59] <jelmer> andy_: I don't think that would be possible
[19:59] <cody-somerville> jam, Thus far yes. But its via read/write transport (ie. bzr+ssh and not http).
[19:59] <andy_> jelmer: very helpful.  thanks.
[20:00] <jelmer> andy_: of course, you would always be able to remove the by-value tree and add a by-reference nested tree
[20:00] <andy_> jelmer: that would work fine for me, I think.
[20:02] <jam> cody-somerville: it is a read-write transport of a readonly location
[20:02] <jam> and the issue is probably that we are *always* locking the master
[20:03] <jam> but only when it is a readonly does that fail
[20:03] <jam> we have code that says "if update_branch.base == self.get_bound_location(): lock_read else: lock_write"
[20:03] <cody-somerville> Why would it work and then just randomly stop?
[20:04] <jam> I don't know why it would stop working without changing the bzr client in the meantime
[20:04] <jam> the fact that unbind + bind fixes it
[20:04] <jam> hints strongly about the bzr client issue
[20:04] <jam> are you positive you didn't upgrade?
[20:05] <cody-somerville> jam, I'll have someone from IS check
[20:05] <jam> your bug report doesn't include the bzr version
[20:06] <jam> vila: ping
[20:06] <jam> in case you are still on
[20:06] <vila> jam: pong
[20:06] <jam> Are you still actively connected to Kerguelen?
[20:07] <jam> (I had a network connection hiccup yesterday, which left Kerguelen thinking someone was connected)
[20:07] <jam> and since there are 2 active connections
[20:07] <vila> just connected a few minutes ago to look at the installer failures, did you do anything in the related directories ? (Just checking)
[20:07] <jam> I can't even get to the login screen
[20:07] <jam> I've been trying to fix file permissions
[20:07] <vila> I didn't have any problem to connect
[20:07] <jam> so that I can get 1.18rc1 built
[20:07] <jam> are you connected as administrator right now?
[20:08] <vila> on the shared/builbot/bzr/ directory ?
[20:08] <jam> if so, can you go to task manager and close my connection?
[20:08] <jam> vila: on 'shared' in general
[20:08] <vila> jam: yes connected as admin
[20:08] <jam> it should all be owned by Users
[20:08] <jam> and writeable by Users
[20:08] <jam> vila: should be Task Manager / Users "disconnect" or "logoff"
[20:09] <vila> jam: you're connected as jameil right ?
[20:09] <vila> jam: done
[20:10] <jam> vila: yeah, unfortunately there are "disconnected but still running"
[20:10] <jam> and there is "your connection died so you are still "connected""
[20:10] <jam> if there are 2 active connections
[20:10] <jam> nobody else can even log in
[20:10] <jam> to kill the connection
[20:10] <vila> about the access rights, admistrator thinks it has read-only access to the whole shared/buildbot/bzr hierarchy and that's wrong
[20:11] <vila> jam: regarding the connection, I'm pretty sure I've been able to reconnect with rdesktop once
[20:11] <jam> vila: I'm not really happy running "make" as Administrator anyway, is there a way we can change that?
[20:11] <jam> vila: consider if you would run "make" as root?
[20:11] <jam> vila: if you "close" the connection, the session stays in semi-active state
[20:11] <jam> if your connection dies it stays in fully-active state (from what I can tell)
[20:12] <jam> semi-active state lets me connect to the login, and start the session I had running earlier
[20:12] <vila> jam: I agree about make, but the setup is wrong anyway and I can't find the right way to debug it remotely
[20:12] <jam> fully active ends up running out of licensed connections and I can't even get to login to logout :)
[20:12] <vila> jam: yeah, it was semi-active then
[20:13] <jam> I find it odd that Administrator isn't in Users... but I should be able to set the perms for Admi
[20:14] <jam> though I think I need to log in as Admin to do s.
[20:14] <jam> so
[20:14] <vila> jam: I logged of
[20:14] <vila> jam: I logged off
[20:16] <jam> vila: thx
[20:16] <jam> vila: so where is the start point for buildbot (where does it decide what command to run?)
[20:16] <jam> is that in 'master.cfg'?
[20:16] <jam> or one of the slave configs?
[20:16] <vila> master.cfg on the master host
[20:17] <jam> vila: what is the lp branch for this stuff?
[20:17] <vila> bzr info in shared/buildbot/bzr :-)
[20:17] <vila> lp:~bzr-buildbot-net-dev/bzr-buildbot-net/trunk/
[20:19] <jam> vila: so effectively, I'm just going to set Full Control to "administrator" and "users" for the whole "shared" and all subfolders
[20:19] <jam> it will probably take a while
[20:20] <vila> ok, thanks, I'll add 'not run as root' in the TODO anyway
[20:20] <jam> vila: so your specific complaint is that "BzrBuildExtensions" is defined in master.cfg across all clients, and clients don't have a chance to customize t
[20:20] <jam> the fact that PYTHON needs to be set, right?
[20:21] <vila> my complaint is that I couldn't define such environment variable in the slave Makefile like I was able to do for all other slaves
[20:21] <vila> I'd also like to define BZR_PLUGIN_PATH there you see..
[20:22] <vila> I'm referring to the slave Makefile, not the bzr one
[20:23] <jam> well, both "BzrBuildExtensions" and "BzrTests" are going to fail on kerguelen since
[20:23] <jam> 1) 'make' will try to build using cygwin's python
[20:23] <vila> yes
[20:23] <jam> and
[20:23] <jam> 2) 'python bzr selftest' ... will likely fail because it uses cygwin python
[20:24] <vila> yes, that's a slave setup IMHO, that's what I want to debug locally before breaking everything on kerguelen :-D
[20:24] <vila> s/slave setup/slave setup bug/
[20:32] <jam> perhaps
[20:32] <jam> certainly there are a few aspects
[20:33] <jam> like ideally we would end up running the selftest on windows on py2.5 *and* py2.6
[20:33] <jam> and possibly other platforms as well
[20:33] <jam> Mac, certainly
[20:33] <vila> jam: so far I've handle that at the slave level by saying that a given slave use a given python version
[20:34] <jam> I don't know wether that is a different salve
[20:34] <jam> or a different build on a given slave
[20:34] <vila> both are possible
[20:34] <jam> vila: so I finished with the perms update, I'll log in as me again
[20:38] <jam> vila: out of curiosity, is buildbot a push or pull system?
[20:38] <jam> (does the master connect to the client and tell them what to do, or do the clients connect to master and ask?)
[20:38] <vila> jam: the client connect and the master ask :)
[20:38] <vila> and the client use a keepalive mechanism to stay connected
[20:39] <vila> jam: some perm error apparently :-/
[20:40] <vila> s/some/same/
[20:41] <jam> hm... I just gave Administrator Full Control over all subdirs of 'shared'
[20:42] <vila> I can see that... but yet properties on shared/buildvot/bzr says Read Only :-)
[20:42] <bpierre> hi
[20:43] <jam> vila: so run as 'vila' instead of Administrator
[20:43] <jam> hmm... maybe I only set it to Full Control for "Administrators" the group, not "Administrator" the user
[20:43] <vila> jam: I'll try that
[20:43] <jam> though I would have thought Administrator was in Administrators...
[20:43] <jam> hi bpierre
[20:43] <vila> or Admistrator is not part of Administrators :)
[20:43] <bpierre> I think I saw mentioned in the mailing list a script for upgrading to 2a, with support for recursively updating a tree, do you know where I can find it?
[20:44] <jam> bpierre: beuno or igc are probably the best to ask about that
[20:44] <bpierre> jam: ok, thanks
[20:44] <jam> sidnei: ping about buildbot
[20:45] <beuno> bpierre, http://people.samba.org/bzr/jelmer/bzr-recursive-upgrade/trunk
[20:45] <bpierre> beuno: thanks
[20:45] <sidnei> jam: yo
[20:46] <vila> jam: vila got Read Only too 8-(
[20:46] <jam> sidnei: I'm getting this failure: http://paste.ubuntu.com/252107/
[20:46] <jam> which is weird, because if I look in "build-win32/qbzr/" the only thing left in there is ".bzr"
[20:46] <jam> (note that right now I'm trying again after deleting the whole qbzr dir)
[20:46] <jam> sidnei: same result... :(
[20:47] <jam> sidnei: and from what I can see now, there isn't even a qbzr dir around to uninstall from
[20:47] <jam> hm... maybe it is the staging location?
[20:47] <sidnei> jam: i suspect so
[20:48] <jam> sidnei: "find build-win32 -name "qbzr-en.po" returns nothing
[20:49] <jam> sidnei: same for "find . -name po"
[20:49] <jam> ahh damn
[20:49] <jam> I copied this directory
[20:49] <jam> to save disk space
[20:49] <jam> and it is probably thinking to re-use the old dirs in another build directory
[20:50] <jam> I can delete .installed.cfg
[20:50] <jam> though I'm guessing that means it will download everything again
[20:50] <jam> which is what I was hoping to avoid
[21:01] <jam> oh well, I'll start from scratch
[21:22] <andy_> jelmer: any idea when by-reference nested tree support will be available?  I looked on site, but only could find that the effort started in 2006...
[21:24] <andy_> jelmer: ... or where I can look to find out?
[21:52] <jam> so I finally got to the point where I can build the win32 installer for 1.18rc1
[21:52] <jam> anyone know if there is a new bzr-svn or bzr-rewrite or subvertpy I should watch out for?
[21:54] <lifeless> no info, sorry.
[22:01] <jam> yeah, I don't think there is anything, at least quick looks on launchpad don't show anything
[22:22] <LarstiQ> jam: bzr-svn 0.6.4 is released
[22:24] <SamB> LarstiQ: dude, wasn't that, like, days ago?
[22:24] <jam> LarstiQ: thanks for the heads up
[22:25] <jam> now if we could only get the Launchpad page updated when releases are made...
[22:25] <jam> :)
[22:25] <SamB> oh, I guess that's new for *windows* users ...
[22:25] <SamB> jam: how is launchpad supposed to know there was a release?
[22:25] <LarstiQ> jam: yeah sorry, still on my todo list
[22:26] <jam> SamB: in the same way it knows about all the other ones listed here: https://launchpad.net/bzr-svn
[22:26] <jam> hmm, I see an 0.6.4 there now
[22:26] <jam> I wonder if somebody got poked into updating it :)
[22:26] <SamB> I betcha it involves too much manual labour
[22:38] <jam> lifeless: feel free to file the bug about reconcile on stacked repos, I'm just about at EOD, and trying to get the windows installers built
[22:40] <jam> so... how should installers be named:
[22:40] <lifeless> jam: sure, I'll file it so we don't lose it. I dunno if its a 2a blocker or not.
[22:40] <jam> bzr-1.18rc1-1-setup.exe
[22:40] <jam> bzr-1.18rc1-setup-1.exe
[22:41] <jam> bzr-1.18rc1-1.setup.exe
[22:41] <jam> and to go along with those
[22:41] <jam> bzr-1.18rc1-1.win32-py2.4.exe
[22:41] <jam> etc
[22:41] <jam> I sort of like bzr-1.18rc1-setup-1.exe
[22:41] <jam> but it doesn't translate well into the python standalone installers
[22:42] <jam> or python installers I mean
[22:42] <lifeless> bzr-1.18rc1-setup-1.exe
[22:42] <lifeless> is what I like
[22:42] <jam> lifeless: sure, but what about bzr-1.18rc1-1.win32-py2.4.exe
[22:42] <jam> vrs bzr-1.18rc1win32-1-py2.4.exe
[22:42] <lifeless> bzr-1.18rc1-setup-1.win32-py2.4.exe
[22:42] <lifeless> ?
[22:42] <jam> vs bzr-1.18rc1.win32-py2.4.exe
[22:42] <jam> bzr-1.18rc1.win32-py2.4-1.exe
[22:42] <jam> lifeless: so... 'setup' is the installer that installs bzr to Program files
[22:43] <jam> w/o setup, is the ones that install it into C:\Python2.x
[22:43] <jam> the "standard" python naming is
[22:43] <lifeless> bzr-1.18rc1-standalone-1.exe
[22:43] <lifeless> bzr-1.18rc1-py2.4-1.exe
[22:43] <jam> bzr-1.18rc1.win32.py2.4.exe
[22:43] <jam> So 2.4-1 certainly looks like a release of *python*
[22:44] <jam> and not a version of the binary installer
[22:44] <lifeless> true
[22:44] <lifeless> bzr-1.18rc1-py2.4-setup-1.exe
[22:44] <lifeless> bzr-1.18rc1-standalone-setup-1.exe
[22:44] <lifeless> I think it would be nice to make the two more comparable to each other, which is what I'm fiddling with here
[22:45] <jam> so the easiest thing to wedge into distutils is bzr-1.18rc1-1.win32.py2.4.exe
[22:45] <jam> though you can write your own builder that overrides the naming function
[22:46] <lifeless> ah, and we can't just rename after?
[22:46] <lifeless> or, if we do, does that break easy_install magic?
[22:46] <jam> lifeless: we *can* and to date I do it all manually
[22:47] <jam> I'd like to have it slightly more automated
[22:48] <jam> bdist_wininst has a function "get_installer_filename" where it does:
[22:48] <jam> fullname =
[22:48] <jam> def get_fullname (self):
[22:48] <jam>     return "%s-%s" % (self.get_name(), self.get_version())
[22:48] <jam> and then
[22:48] <jam> installer_name = os.path.join(self.dist_dir,
[22:48] <jam>                               "%s.win32-py%s.exe" %
[22:48] <jam>                                (fullname, self.target_version))
[22:49] <jam> 'get_version' just returns what was passed in the ARGS of setup()
[22:49] <jam> so it is easy enough to change that
[22:49] <jam> and also means that the *installer* will say that this is "bzr 1.18rc1-1"
[22:51] <mac9416> Hello, how can I overwrite a branch?
[22:51] <lifeless> push --overwrite ...
[22:55] <mac9416> lifeless, sorry, wasn't paying attention. Thanks
[22:56] <mac9416> Worked fine
[23:29] <Noldorin> lifeless: ping
[23:35] <Noldorin> lifeless: time not good for you?