[00:03] lifeless: no, i didn't [00:03] lifeless: i disappeared offline for after my laptop lost power. sorry [00:11] Noldorin: whats the bug number for this problem [00:15] lifeless: i still haven't been sure what to submit yet :) [00:15] i've been testing the repo a bit more the past day [00:16] seems init always succeeds [00:16] or almost always [00:19] Noldorin: please file a bug. [00:19] it lets us gather data. [00:19] lifeless: ok, will do. what should i detail specifically as the cause though? [00:19] Don't worry about it being 'right' - bugs are conversations. [00:19] yeah, probably a good idea [00:20] hmm [00:20] fair enough [00:20] if we knew the cause, we probably wouldn't need a bug ;) [00:21] lifeless: knowing the cause can often (though not always) still be quite a long way from the fix ;) [00:21] thats true too :) [00:22] heh, we've made progress in understanding at least [00:34] lifeless: interestingly, breaking the lock doesn't seem to be a problem now [00:34] is that with the delay in it? [00:34] nope [00:35] don't have that available on this comp at the moment, unfortunately [00:36] ok [00:36] (the source and dependencies that is) [00:36] ok [00:47] ok, submitted now [00:47] #412244 [00:48] lifeless: https://bugs.launchpad.net/bugs/412244 [00:48] Launchpad bug 412244 in bzr "Cannot push to Windows FTP server (Microsoft FTP Service IIS6)" [Undecided,New] [00:48] thanks [00:48] no problem [00:49] it's probably still very incomplete at the moment [00:49] but it describes the core of the problem [00:50] 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] lifeless: ah, i see your summary already. [00:56] i'll be hear for a while longer, if you care to debug things further with me [00:56] here* [00:56] :P [00:56] I'm in the middle of a few other things right now [00:56] alright, sure [00:56] When I get a chance I'll brain dump my memory to the bug [00:56] well ping me if you have a miunte :) [00:56] otherwise no worries [00:56] ok cheers [00:59] igc: ping [00:59] igc: do the docs in trunk suggest in-place upgrade or doing rename dances? [00:59] https://bugs.edge.launchpad.net/bzr/+bug/374735 [00:59] Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Fix committed] === _thumper_ is now known as thumper [01:25] lifeless: http://doc.bazaar-vcs.org/bzr.1.18rc1-html/en/upgrade-guide/index.html [01:25] lifeless: the process is that recommended by thumper wrt stacked branches [01:25] morning all === ivan is now known as Guest79018 === Guest79018 is now known as ivan [02:08] igc: so, I think this approach is a real problem [02:08] igc: should I talk to you or thumper about that [02:09] lifeless: thumper. I'm happy to write up what you agree [02:09] thumper: ping [02:10] whazzup? [02:10] lifeless: but the one thing I do want is a *simple* answer, even if that means more code in bzr or lp [02:10] lifeless, thumper: complex won't cut it imo [02:14] igc: my way is real simple: bzr upgrade URL [02:14] 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] 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] lifeless: if you can fix the bugs, then sure, upgrade in place [02:15] thumper: _what bugs_ [02:16] lifeless: there are bugs filed that it doesn't work [02:16] lifeless: upgrading stacked branches fails [02:16] I've seen one failure, which isn't upgrade relaated, its a fetch failure - being fixed at the moment. [02:17] 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] lifeless: ok... well if it works, then do it in place [02:18] this will use less disk space on launchpad, avoid dead branches, keep bug links and reviews intact etc. [02:18] sure [02:25] igc: ^ [02:39] vila: ping [03:01] igc, I hope I'm dismissed from writing up the summary of the RFC that turned into secretaries and incompetent developers. ;) [03:08] lifeless: can packs (or later non-rr) be stacked on 2a now? [03:08] no, stacking is format locked [03:09] you can upgrade something thats invalidly stacked though - upgrade doesn't open the basis branch [03:17] emmajane: yes :-) [03:17] igc, *phew* :) [03:17] emmajane: a nice case study though on why reporting bugs is good practice :-) [03:17] igc, did y'all know that was going to happen when poolie asked me to write up the RFC? [03:18] emmajane: predicting the future isn't my strong point, so no [03:18] heh [03:19] as long as it wasn't "trial by fire for the newb" ;) [03:24] Oh, no. Nobody thinks it through that much. It's more like "trial by fire for somebody other than me"... [03:24] hehe [03:41] * igc lunch [04:02] igc: well, it looks like the git source tree is GPL v2 (only) [04:03] Coming out of Linus, I'd be a little surprised to see it otherwise. [04:13] sometimes he mixes it up a little and says "let's SPL this" ;-P [04:13] (more or less) [04:14] Pfft, spl's are so 1985... [04:15] even GNU says you might as well use them when your program is shorter than the GPL itself [04:16] SPLs are my favorite, and I was born in '86 ;-P [04:17] special purpose limousine? [04:17] Simple Permissive Licenses [04:17] Alas, my archaic kernel humor is lost on you people :p [04:17] like BSD3, BSD2, or better, something which doesn't have in it ;-P [04:23] hmm, you know, the latest PPA build has the wrong version number ... [07:23] hi all [07:27] hi === Jc2k_ is now known as Jc2k [08:22] lifeless, yep :) [08:24] jml: excellent === sabdfl1 is now known as sabdfl === raimue is now known as Raim [09:50] * igc dinner [09:53] lifeless: just noticed your earlier ping :-/ [12:13] 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] I suppose it's a NULL_REVISION="null:" === kiko is now known as kiko-phone [12:25] hello all [12:26] bialix: yes it is [12:34] poolie1: hi [12:35] 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] rats [12:36] Elvis left the building === mrevell is now known as mrevell-lunch [13:25] jelmer: you about? === johnf1 is now known as johnf [13:25] johnf: somewhat [13:25] jelmer: are you planning to split out bzr-doc in debian like we've done in the PPA? [13:30] johnf: it's on my list of things to look into, I just haven't found time to do so yet [13:30] jelmer: ok no problems [13:31] 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] johnf: you're welcome to help regardless [13:32] 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] but commits to the bzr repo shouldn't be a problem [13:33] ok cool. [13:33] 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] 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] johnf: yeah, that makes sense [13:35] tvainika: I'm not sure how well checkouts work, standalone branches should work [13:36] 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] LarstiQ: do you know what happened to 1.17.1? === mrevell-lunch is now known as mrevell === cprov1 is now known as cprov [13:53] 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] in git, i'd "git log HEAD..origin/master" or "git diff origin/master" [13:57] bzr diff --old path/to/the/other/branch [13:57] but there is also bzr missing [13:58] or bzr diff -r ancestor: [13:59] jelmer: got pqm sorted out on monday and submitted some things, did another cherrypick but not submitted yet [13:59] jelmer: at HAR now, and it's too rainy to pitch a tent [13:59] * LarstiQ sends a pqm request instead [14:00] LarstiQ: ah [14:00] Let's talk about this at HAR then >-) [14:00] I'll be there for the first two days [14:01] jelmer: ah cool, I thought you wouldn't attend [14:01] jelmer: you _do_ have a ticket? [14:01] yeah [14:01] I bought one early but was considering selling it again because I had to miss the last two days [14:01] but I decided to go anyway, don't want to wait *another* 4 years [14:02] * LarstiQ nods [14:16] luks, thanks [15:06] jelmer: any thoughts? http://paste2.org/p/375184 [15:06] that's on a small commit to a big bzr-svn bound branch [15:07] got a similar one on update as well; other operation seem to be fine [15:07] err, from monodevelop-bzr ^^ === kiko-phone is now known as kiko [16:23] night all [16:24] igc: night [16:24] vila: bonjour! [16:25] hello bialix [16:25] I've finally managed to finish commit_data stuff [16:26] if you want comment on my approach, it will be nice [16:26] code is here: https://code.launchpad.net/~qbzr-dev/qbzr/commit_data [16:26] vila: ^ === deryck is now known as deryck[lunch] [16:27] beuno, ping [16:27] igc, night :) [16:28] emmajane, hi [16:29] beuno, hey :) Any updates from the designers? [16:29] emmajane, none. I haven't even managed to get confirmation of the time being booked yet [16:29] I have a call in 2 hours that gives me hope :) [16:29] beuno, :( [16:30] hopefully the call has good news! [16:31] hello emmajane, beuno [16:31] poolie1, hey :) [16:32] poolie1, hey! What are you doing around here at this hour? [16:32] i'm in Taipei, going to the COSCUP conference this weekend and to visit canonical here [16:33] poolie1, ah! that's right [16:33] how's Taipei? [16:33] good [16:33] i just got to the hotel [16:33] am gaing to bed soon, it's 1130 [16:34] poolie1, I thought today was a travel day for you. But then all I could remember was, "Wednesday" [16:36] it is, i've been travelling all day and then i just arrived [16:36] it's the end of my wednesday [16:36] poolie1, enjoy Taipei [16:36] poolie1, :/ sleep will be nice for you then. :) [16:37] hi poolie1 ! === beuno is now known as beuno-lunch [16:53] hi vila [16:54] poolie1: do you will be able to comment on my mail during this week? [16:54] hi, [16:55] any mail in particular? [16:55] i am going to be reading some [16:56] poolie1: about Qbzr site, Gary asking to stay on bazaar-vcs.org [16:57] oh ok [16:57] i'll look [16:57] it's not urgent, but I'd like to know how busy you are [16:58] i saw the thread but i didn't read all of it [17:00] check qbzr ML [17:00] ok, answered [17:01] i hope that helps [17:01] thanks [17:03] did that answer the question? [17:07] poolie1: what it means: "We could arrange for qbzr to point to some site you like." [17:07] ? [17:07] we can add a dns entry for it [17:07] i.e. qbzr.bazaar-vcs.org? [17:08] right [17:08] ok [17:09] I need to catch garyvdm now. But it seems ok for me. (less money for domain) [17:10] poolie1: we have a big move for last year [17:11] ? [17:11] a big change since last year? [17:11] poolie1: we want to release qbzr 1.0 soon [17:11] yes [17:11] cool [17:11] it seems to be moving really well [17:11] so the site will be nice additon for this [17:11] Gary is really wizard [17:13] 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] poolie1: aren't you up *way* to late? [17:13] or is it a different TZ? [17:13] i'm 2 hours earlier, but it's still late and i should sleep [17:13] bialix, wow [17:14] i'm just going to mail S then sleep [17:14] doesn't that just show it takes way more LOC to do the same thing using qt? ;-P [17:14] Tak: :-P [17:14] :-P :-P [17:14] :-P :-P :-P [17:15] * Tak moc < bialix [17:15] what is "moc <" ? [17:15] hmm, doesn't qt still use moc? [17:16] http://doc.trolltech.com/4.0/moc.html [17:17] Tak: we're using PyQt [17:18] so pyqt uses some dynamic stuff to avoid all the mocery? [17:19] I guess so [17:20] * bialix disappear [17:22] Tak: moc is just a way to have meta information about classes in a static language such as C++ [17:22] Tak: you can get all that info from Python objects at runtime [17:22] * Tak nod [17:24] luks: well given that moc is a precompiler, is it really even that? [17:24] I thought it was just a way to have nice syntax for slots [17:24] jam: it's not a precompiler [17:24] jam: it extracts info from .h files into _moc.cpp files [17:24] jam: the nice syntax is standard c++ [17:24] (#defines) === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === EdwinGrubbs is now known as Edwin-afk [18:26] Tak: sorry, no idea, haven't seen a crash in a while [18:26] * Tak nod [18:27] and the c#->c->python->c->python roundtrip is nice for debugging anyway ;-) [18:29] :-) === Colonel-Rosa_ is now known as Colonel-Rosa [19:04] Could anyone point me to a resource on storing the current revision number in a file using a commit hook? [19:05] I tried making my own pre_commit hook, but it's one revision behind (the commit doesn't send the updated file) [19:05] Any ideas? [19:08] 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] Google hasn't been helping either... [19:34] divokz1: look for the keywords plugin [19:38] jam, I don't think lp #412657 is a dup [19:38] Launchpad bug 412657 in bzr "update fails when trying to lock master branch (in a readonly checkout) (dup-of: 412244)" [Undecided,New] https://launchpad.net/bugs/412657 [19:38] Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP Service IIS6)" [Medium,Confirmed] https://launchpad.net/bugs/412244 [19:38] cody-somerville: it's a dupe of something [19:38] perhaps just not that one :-) [19:38] let me find the correct one [19:38] andy_: nested trees don't work yet.. [19:38] cody-somerville: update fails when updating from master branch [19:38] I'm pretty sure both are a dupe of a third bug [19:39] but perhaps I typed the wrong bug # [19:39] cody-somerville: bug #412223 [19:39] Launchpad bug 412223 in bzr "bzr up locks master branch" [High,Triaged] https://launchpad.net/bugs/412223 [19:40] though ISTR yet another bug [19:40] with this same basic issue [19:40] sorry about the noise of the wrong bug # [19:41] In this other case, was it working and then stopped? [19:41] cody-somerville: we changed normalization rules somewhere [19:41] jam, bzr hasn't been updated [19:41] so doing "bzr-old co $PROJECT; bzr-new up" was failing [19:42] cody-somerville: so sometime when it fails for you [19:42] jam: I remember that other bug as well, but I can't find it either [19:42] try doing "cat .bzr/branch/branch.conf" [19:42] to see what we have recorded as the master branch [19:42] and I'm also 90% sure that all these failures will be found with branches with "~" in them [19:42] which is the bug [19:43] of course, all LP branches have ~ so that isn't a great discriminator [19:44] 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] jelmer: I'm using v 1.13.1 [19:49] * Tak can't wait for externals=>nested-trees support in bzr-svn [19:51] jelmer: so, are you saying that nested trees are unstable/should be avoided? [19:54] anyone here using nesting successfully? [19:55] jam, the ones that work have ~ in them too :P [19:56] andy_: by-value nested trees should work and are stable [19:56] andy_: svn:externals is the equivalent of --reference [19:57] jelmer: ahh...thanks for clarifying. [19:57] andy_: for by-value nested trees, use 1.9-rich-root [19:57] cody-somerville: out of curiosity, does it only break on projects that you don't have commit access to? [19:57] (aka readonly branches) [19:57] andy_: or just plain --default-rich-root [19:58] andy_: which is an alias for the default rich root format [19:58] 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] andy_: yes [19:59] jelmer: any idea of a by-value tree could be converted later on when --reference becomes stable? [19:59] andy_: I don't think that would be possible [19:59] jam, Thus far yes. But its via read/write transport (ie. bzr+ssh and not http). [19:59] jelmer: very helpful. thanks. [20:00] andy_: of course, you would always be able to remove the by-value tree and add a by-reference nested tree [20:00] jelmer: that would work fine for me, I think. [20:02] cody-somerville: it is a read-write transport of a readonly location [20:02] and the issue is probably that we are *always* locking the master [20:03] but only when it is a readonly does that fail [20:03] we have code that says "if update_branch.base == self.get_bound_location(): lock_read else: lock_write" [20:03] Why would it work and then just randomly stop? [20:04] I don't know why it would stop working without changing the bzr client in the meantime [20:04] the fact that unbind + bind fixes it [20:04] hints strongly about the bzr client issue [20:04] are you positive you didn't upgrade? [20:05] jam, I'll have someone from IS check [20:05] your bug report doesn't include the bzr version [20:06] vila: ping [20:06] in case you are still on [20:06] jam: pong [20:06] Are you still actively connected to Kerguelen? [20:07] (I had a network connection hiccup yesterday, which left Kerguelen thinking someone was connected) [20:07] and since there are 2 active connections [20:07] just connected a few minutes ago to look at the installer failures, did you do anything in the related directories ? (Just checking) [20:07] I can't even get to the login screen [20:07] I've been trying to fix file permissions [20:07] I didn't have any problem to connect [20:07] so that I can get 1.18rc1 built [20:07] are you connected as administrator right now? [20:08] on the shared/builbot/bzr/ directory ? [20:08] if so, can you go to task manager and close my connection? [20:08] vila: on 'shared' in general [20:08] jam: yes connected as admin [20:08] it should all be owned by Users [20:08] and writeable by Users [20:08] vila: should be Task Manager / Users "disconnect" or "logoff" [20:09] jam: you're connected as jameil right ? [20:09] jam: done [20:10] vila: yeah, unfortunately there are "disconnected but still running" [20:10] and there is "your connection died so you are still "connected"" [20:10] if there are 2 active connections [20:10] nobody else can even log in [20:10] to kill the connection [20:10] about the access rights, admistrator thinks it has read-only access to the whole shared/buildbot/bzr hierarchy and that's wrong [20:11] jam: regarding the connection, I'm pretty sure I've been able to reconnect with rdesktop once [20:11] vila: I'm not really happy running "make" as Administrator anyway, is there a way we can change that? [20:11] vila: consider if you would run "make" as root? [20:11] vila: if you "close" the connection, the session stays in semi-active state [20:11] if your connection dies it stays in fully-active state (from what I can tell) [20:12] semi-active state lets me connect to the login, and start the session I had running earlier [20:12] 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] fully active ends up running out of licensed connections and I can't even get to login to logout :) [20:12] jam: yeah, it was semi-active then [20:13] I find it odd that Administrator isn't in Users... but I should be able to set the perms for Admi [20:14] though I think I need to log in as Admin to do s. [20:14] so [20:14] jam: I logged of [20:14] jam: I logged off [20:16] vila: thx [20:16] vila: so where is the start point for buildbot (where does it decide what command to run?) [20:16] is that in 'master.cfg'? [20:16] or one of the slave configs? [20:16] master.cfg on the master host [20:17] vila: what is the lp branch for this stuff? [20:17] bzr info in shared/buildbot/bzr :-) [20:17] lp:~bzr-buildbot-net-dev/bzr-buildbot-net/trunk/ [20:19] vila: so effectively, I'm just going to set Full Control to "administrator" and "users" for the whole "shared" and all subfolders [20:19] it will probably take a while === Edwin is now known as Guest11851 === Guest11851 is now known as EdwinGrubbs [20:20] ok, thanks, I'll add 'not run as root' in the TODO anyway [20:20] 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] the fact that PYTHON needs to be set, right? [20:21] 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] I'd also like to define BZR_PLUGIN_PATH there you see.. [20:22] I'm referring to the slave Makefile, not the bzr one [20:23] well, both "BzrBuildExtensions" and "BzrTests" are going to fail on kerguelen since [20:23] 1) 'make' will try to build using cygwin's python [20:23] yes [20:23] and [20:23] 2) 'python bzr selftest' ... will likely fail because it uses cygwin python [20:24] yes, that's a slave setup IMHO, that's what I want to debug locally before breaking everything on kerguelen :-D [20:24] s/slave setup/slave setup bug/ [20:32] perhaps [20:32] certainly there are a few aspects [20:33] like ideally we would end up running the selftest on windows on py2.5 *and* py2.6 [20:33] and possibly other platforms as well [20:33] Mac, certainly [20:33] jam: so far I've handle that at the slave level by saying that a given slave use a given python version [20:34] I don't know wether that is a different salve [20:34] or a different build on a given slave [20:34] both are possible [20:34] vila: so I finished with the perms update, I'll log in as me again [20:38] vila: out of curiosity, is buildbot a push or pull system? [20:38] (does the master connect to the client and tell them what to do, or do the clients connect to master and ask?) [20:38] jam: the client connect and the master ask :) [20:38] and the client use a keepalive mechanism to stay connected [20:39] jam: some perm error apparently :-/ [20:40] s/some/same/ [20:41] hm... I just gave Administrator Full Control over all subdirs of 'shared' [20:42] I can see that... but yet properties on shared/buildvot/bzr says Read Only :-) [20:42] hi [20:43] vila: so run as 'vila' instead of Administrator [20:43] hmm... maybe I only set it to Full Control for "Administrators" the group, not "Administrator" the user [20:43] jam: I'll try that [20:43] though I would have thought Administrator was in Administrators... [20:43] hi bpierre [20:43] or Admistrator is not part of Administrators :) [20:43] 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] bpierre: beuno or igc are probably the best to ask about that [20:44] jam: ok, thanks [20:44] sidnei: ping about buildbot [20:45] bpierre, http://people.samba.org/bzr/jelmer/bzr-recursive-upgrade/trunk [20:45] beuno: thanks [20:45] jam: yo [20:46] jam: vila got Read Only too 8-( [20:46] sidnei: I'm getting this failure: http://paste.ubuntu.com/252107/ [20:46] which is weird, because if I look in "build-win32/qbzr/" the only thing left in there is ".bzr" [20:46] (note that right now I'm trying again after deleting the whole qbzr dir) [20:46]