[03:06] <delinquentme> hey all .. is there a bzr command something akin to gitk?
[03:06] <delinquentme> like a way I can graphically view the commit history?
[04:59] <lifeless> delinquentme: bzr viz
[07:59] <mgz> morning all!
[08:59] <christiank> Hi! Our development team uses Bazaar in combination with Launchpad. I have filed a bug report on Sept. 11th and haven't had any replies. Is this the correct avenue to get help with it?
[08:59] <christiank> It is bug https://bugs.launchpad.net/bzr/+bug/1049124
[09:00] <bob2> how old is the repo
[09:00] <christiank> Good question, let me check
[09:01] <christiank> It got created on May 30th, 2009
[09:26] <christiank> bob2: Have you got any ideas as to why this bug might happen?
[10:19] <pled76> hello all
[10:21]  * christiank is away: Lunch
[10:22] <pled76> failed to enable bzr via ssh
[10:22] <pled76> server: ubuntu 10.04
[10:22] <pled76> clients: Windows (putty and pageant)
[10:22] <pled76> error:
[10:22] <pled76> Connected (version 2.0, client OpenSSH_5.3p1)
[10:22] <pled76> Authentication (publickey) failed.
[10:22] <pled76> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xcf in position 0: ordinal not in range(128)
[10:22] <pled76> putty ssh logins working ok
[10:22] <pled76> server encoding utf-8
[10:23] <pled76> clients are cp1251
[10:23] <pled76> pls, help to troubleshoot
[10:24] <mgz> pled76: please pastebin the corresponding section of your .bzr.log (running `bzr version` will tell you where to find that)
[10:24] <pled76> can provide full error message -- seems as python stack
[10:24] <mgz> !pastebin
[10:24] <pled76> mgz: log from client or from server?
[10:25] <mgz> client, but both wouldn't hurt
[10:26] <mgz> it looks like you've just not got your keys configured correctly, but have a knock-on problem trying to print a localised error message
[10:27] <pled76> keys are working -- putty can login from client
[10:27] <mgz> you probably haven't told bzr to use putty
[10:28] <mgz> by, eg setting envvar BZR_SSH to the path to your putty executable
[10:29] <pled76> http://paste.ubuntu.com/1253636/
[10:29] <pled76> thanks, will try to set BZR_SSH on client
[10:29] <mgz> heh: "0.078  looking for plugins in C:/Documents and Settings/P◈P◈PjPëPSPëC◈C‚C◈P°C‚PsC◈/Application Data/bazaar/2.0/plugins"
[10:29] <mgz> that's pretty mangled
[10:30] <pled76> thats Russian in ibm866 converted to cp1251
[10:30] <pled76> the word there is "/Администратор/"
[10:32] <mgz> so, your problem is just that it's falling back to calling 'ssh' as you haven't configured it to use putty
[10:32] <mgz> but the locale mangling is also confusing things
[10:33] <pled76> will try setting BZR_SSH to "plink"
[10:33] <mgz> because it's trying to prompt for a password, but can't encode the tranlated prompt in whatever it thinks your locale is
[10:34] <mgz> pled76: what does the locale bits at the bottom of that error in the terminal say?
[10:34] <mgz> fs_enc and so on.
[10:38] <pled76> encoding: 'cp1251', fsenc: 'mbcs', lang: None
[10:39] <pled76> on client I get:
[10:39] <pled76> D:\Temp\3>set BZR_SSH=D:\Tools\plink.exe
[10:39] <pled76> D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox
[10:39] <pled76> D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox
[10:39] <pled76> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
[10:39] <pled76> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[10:41] <mgz> but `plink 192.168.5.113` works?
[10:44] <pled76> plink 192.168.5.113 -l mikmer
[10:44] <pled76> works correctly -- does not prompt for password and logins to linux shell
[10:45] <mgz> you need to tell bzr about `-l mikmer` too.
[10:46] <pled76> but how?
[10:46] <mgz> can either stick it in the url, or in authentication.conf
[10:46] <mgz> read `bzr help authentication`
[10:46] <pled76> mgz: will try now, thanks
[10:56] <pled76> mgz: thanks a lot -- now it works!   :)
[10:58] <mgz> pled76: ace! did you add the details in authentication.conf or in the url?
[11:15] <pled76> mgz: I added section with host and user to authentication.conf
[11:16] <pled76> mgz: seems that adding user to url wiil do the trick also -- will try lately
[11:18] <mgz> right, the conf option is generally best, otherwise it's easy to forget :)
[12:01]  * christiank is back (gone 01:40:09)
[12:05] <bob2> probably want to turn that off
[12:28] <jelmer> hi jam, mgz
[12:29] <jam> hi jelmer, I just mentioned you in the other channel :)
[12:29]  * w7z is eating lunch
[12:29] <jelmer> jam: :-) I was first though; have just caught up on email
[12:29] <jam> w7z: still focused on sampledata, right?
[12:30] <w7z> yeah, though I left juju trying to deploy folsom when I went to put the pasta on
[12:31] <w7z> so I might have a cloud in a cloud by now (though more likely, a bunch of errors)
[13:01] <mgz> was an install error...
[13:38] <christiank> bob2: Hi, you have responded to my question from 11:02 Central European Time this morning (regarding a bug) with another question, but haven't come back to me since I provided the answer. Have you had an opportunity to look into that issue?
[13:38] <bob2> nope
[13:38] <bob2> <- not a bzr dev
[13:39] <christiank> Ah, OK
[13:39] <christiank> Is there somebody on the chat who might be able to have a look then?
[13:42] <mgz> christiank: you need to talk to the launchpad maintence squad, who can be found in #launchpad on mostly AUS/US timezones
[13:42] <christiank> OK, thanks!
[13:43] <christiank> Will do
[13:43] <mgz> was the branch derived from an SVN repo, or was it always bzr?
[13:59] <christiank> The code was originally in a git repository and got then into a Bazaar repository
[14:00] <mgz> jelmer: were there git ghost bugs, or is this a stacking issue?
[14:01] <jelmer> mgz: ghosts shouldn't occur with git imports; bugs could cause them to appear though
[14:02] <mgz> but, unlike svn there's not a well-known previously reported bug that causes ghost issues?
[14:02] <mgz> because otherwise it's probably from branches moving around and breaking a stacking relationship or something
[14:03] <jelmer> mgz: for svn ghosts aren't a well known bug; they are intentional behaviour
[14:05] <christiank> The thing is that we don't get problems when we use Bazaar Clients of Version 2.4.2. The problem exists for Bazaar Clients V 2.5.0 and V 2.5.1.
[14:05] <christiank> We find 2.4.2 quite buggy, it leaves a lot of 'dead' processes in memory all the time and would like to use 2.5.1, but then we get the issues I reported in the bug report
[14:06] <christiank> That is all on Windows
[14:06] <mgz> christiank: the bug you reported has two different issues
[14:06] <mgz> one of them (the binary junk from the smart server) is a seperate issue and has been fixed on trunk and 2.5 branch
[14:06] <christiank> Aha
[14:07] <mgz> having ghosts on an branch is still something that needs fixing though, most likely in the launchpad hosted repos
[14:07] <mgz> s/an/a/
[14:10] <christiank> We think that we were using Bazaar 2.5.x clients and didn't run into the issues reported until two or three days before I reported the bug, but aren't 100% sure about that. Could a Bazaar Server upgrade on Launchpad have caused the problem?
[14:10] <mgz> christiank: it caused at least the second issue
[14:11] <christiank> You mean the 'binary junt from the smart server'?
[14:11] <christiank> junt -> junk
[14:12] <mgz> yes, that's bug 1046265
[14:14] <christiank> Do you think a 'brz reconcile' on trunk might help with the 'ghost' problem that 'brz log' reports in recently created branches when we use 2.5.x Clients?
[14:16] <mgz> probably not, but creating a fresh repo might, but that's involved and affects all stacked branches
[14:20] <christiank> I'm just wondering the bug doesn't surface when using Version 2.4.2, and hence if there really is a problem with our repo, or if it's rather a problem of Bazaar 2.5.x Clients
[14:21] <mgz> christiank: so, as I understand it, you work in checkouts from launchpad rather than local branches
[14:22] <christiank> Correct
[14:22] <mgz> in 2.4 this was massively inefficient, because most actions end up fetching large chunks of the repository pack files when doing anything involving hitory
[14:22] <maxb> Out of curiosity, I ran bzr check -v on a local branch of lp:openpetraorg - am I misremembering that bzr check reports ghosts? This run did not
[14:22] <christiank> We use Bazaar Explorer to create the Branches, not the Launchpad web interface for that, though
[14:23] <mgz> maxb: there are no ghosts on trunk
[14:23] <mgz> the rev reported as a ghost exists on trunk
[14:23] <mgz> 2.5 added some optimsations that use specific smart server verbs that do the work server side and send just a small ammount of data back
[14:24] <christiank> I realised that 2.4.2 is slower when I stepped back from 2.5.2
[14:24] <mgz> but deploying the smart server code to launchpad revealed a few issues
[14:24] <mgz> this seems like something specific wrong with how launchpad is doing branches/stacking/?
[14:25] <christiank> I'm sorry, I need to take part in a meeting now. Are you available in let's say two or three hours or so?
[14:25] <mgz> but if you make a local branch and push back up to that ghost-reporting branch in your bug, that might affect things
[14:25] <mgz> christiank: I'll be around.
[14:25] <christiank> OK, great
[14:25] <christiank> Will come back later to you then
[14:25] <christiank> Thanks for helping
[14:27] <mgz> ...or not, a copy of that branch in my namespace is similarly borked
[15:09] <christiank> mgz: Hi, I am back from the meeting.
[15:10] <christiank> mgz: You write '...or not, a copy of that branch in my namespace is similarly borked'. Do I understand it correctly that you did a local checkout of one of our branches and can reproduce the issue I reported?
[15:38] <mgz> christiank: I branched the one from your bug report, and pushed it back up as lp:~gz/openpetraorg/dev_branching_OK_test1
[15:39] <mgz> which has the same issue
[15:40] <mgz> running `bzr log -r revid:christian.kendel@om.org-20120911071731-5eips99nkud84v3o` in the local branch is fine though, obviously
[15:40] <mgz> so it's checkout/stacking related
[15:40] <christiank> Aha
[15:41] <christiank> mgz: And you are running Bazaar 2.5.1?
[15:41] <mgz> that was 2.6b2 but yes basically
[15:41] <christiank> OK.
[15:42] <mgz> basically, using lightweight checkouts of remote branches was never really recommended
[15:42] <mgz> so has not been as well tested or debugged in general
[15:43] <christiank> mgz: Maybe you could try to a fresh branch from our trunk and try to push it back up as you did with the branch from my branch. That way we could see if you could create a 'healthy' branch from our trunk, or not
[15:43] <christiank> mgz: I see
[15:43] <mgz> your trunk seems healthy anyway
[15:44] <mgz> it's the branches created stacked on top that are unwell
[15:44] <christiank> mgz: I see. And the '51223 inconsistent parents' that bzr check reports on trunk - should we not worry about those, or is that report wrong?
[15:44] <mgz> how did you create them exactly? modify your local trunk then push back to a new location?
[15:47] <mgz> the inconsistent parents are probably just a side effect of the code import, and may or may not be related
[15:48] <christiank> mgz: We create new branches from within Bazaar Explorer, using the 'Bazaar' -> 'Start' -> 'Branch...' facility, giving 'lp:openpetraorg' as the 'From' and e.g. 'lp:~christian-k/openpetraorg/dev_branching_OK_test1' as the To Locations. After that we do a checkout of the new branch to a local directory of our Windows machine, using the 'Bazaar' -> 'Start' -> 'Checkout..' facility.
[15:50] <christiank> mgz: then we do modifications to the source files on the branch and check them in regularly, occasionally doing a merge from trunk to keep things up-to-date in the branch. Finally we merge that branch into trunk once we are done with development. We do all operations with Bazaar Explorer.
[15:50] <mgz> okay, that first step is a little funky, I'll see if I can reproduce
[15:50] <christiank> mgz: Thanks
[15:59] <mgz> hm, nope, trivial case works fine.
[16:00] <mgz> if there's anything else in common broken branches have, it may be worth looking at .bzr.log to see what the exact operations you did were (`bzr version` will tell you where to find that)
[16:05] <christiank> mgz: The problem is that I have now V 2.4.2 installed and not V 2.5.x so I can't do that
[16:10] <christiank> mgz: You write: 'hm, nope, trivial case works fine.' --- So did you create branch 'lp:~gz/openpetraorg/testborkedness' in the way you described with V 2.6b2 on Windows using Bazaar Explorer and you don't see any 'ghost' issues?
[16:11] <christiank> mgz: sorry - 'in the way you described' should have been ' in the way I described'
[16:21] <mgz> christiank: using the underlying bzr commands that explorer uses, yes
[16:21] <christiank> mgz: OK, that's good to know. Is there a release date for 2.6 yet?
[16:29] <mgz> christiank: to be clear, I suspect it's my steps to reproduce the problem are incomplete, rather than an issue fixed in 2.6
[16:29] <christiank> mgz: I'm having a break but will be back later
[16:29]  * christiank is away: Break
[17:30] <trashbird1240> hello
[17:33]  * christiank is back (gone 01:03:40)
[17:33] <christiank> mgz: I am back again
[17:36] <mgz> I'm nearly gone (well, I'm on downstairs as well)
[17:37] <christiank> mgz: Could you perhaps try to do the steps I outlined earlier really with Bazaar Explorer rather than the commands that Bazaar Explorer would use to create a new Branch in the way that I described? We hardly ever use the commandline commands but Bazaar Explorer. I did use the steps I outlined earlier to create the branch that I mention in the bug, lp:~christian-k/openpetraorg/dev_branching_OK_test1
[17:37] <mgz> christiank: for the first two steps, which were the most specific, I'm pretty confident they're entirely equivalent
[17:38] <mgz> explorer does just call into the bzr commandline for that underneath
[17:39] <christiank> OK
[17:40] <mgz> do other people also branches that also exhibit this problem?
[17:41] <mgz> I'm not clear if it's all branches made after a period, or just some of them
[17:41] <christiank> mgz: For Branch lp:~christian-k/openpetraorg/dev_branching_OK_test1 I did ONLY the first two steps and can produce the problem described in the bug
[17:42] <christiank> mgz: Yes, all developers who used V 2.5.x had the problems in branches that were created from a certain point in time on. Working on branches they had created earlier caused no problems.
[17:42] <trashbird1240> mgz: can you show a link to the bug? (I'm also having a problem)
[17:42] <mgz> christiank: okay, I'll try with the exact steps, and not from within the datacenter
[17:43] <mgz> trashbird1240: bug 1049124
[17:43] <christiank> trashbrid1240: Sure: https://bugs.launchpad.net/bzr/+bug/1049124
[17:43]  * mgz won! :)
[17:43] <trashbird1240> I think I"m having a different problem
[17:44] <mgz> trashbird1240: what's the error message you're getting?
[17:44] <christiank> mgz: One developer who was still on v2.4.2 had no problems whatsoever, also not with newer branches he created after the time the other developers who were on 2.5.x had created branches that exhibet the problem
[17:44] <trashbird1240> I'm getting "bzr: out of memory" when trying to pull to my laptop
[17:44] <trashbird1240> I have narrowed it down to one particular revision
[17:44] <christiank> mgz: Thanks for trying the exact steps.
[17:45] <mgz> ah, you have the good ol' bloated repo problem
[17:45] <trashbird1240> mgz: that appears to be the problem ;)
[17:45] <mgz> if you know which rev it is, and are an admin of the branch,
[17:45] <trashbird1240> which I am...
[17:46]  * trashbird1240 is waiting with baited breath
[17:46] <mgz> you can pull till just that rev, then rewrite the subsequent commits, then push up a new unbloated branch, and retarget trunk at that
[17:46] <trashbird1240> okay
[17:46] <mgz> so, `bzr branch -rLAST_GOOD lp:PROJ`
[17:46] <trashbird1240> is there any other way that would not require reversioning?
[17:47] <trashbird1240> I know that's my real problem, but is there any way to dump the branch to a file or something like that?
[17:47] <mgz> trashbird1240: depends, if it's in your history, nope.
[17:47] <trashbird1240> okay
[17:47] <trashbird1240> I really appreciate the help
[17:47] <trashbird1240> the annoying thing is that it's only this one machine
[17:47] <trashbird1240> and it didn't happen until I upgraded the operating system
[17:48] <trashbird1240> I therefore think the problem is somewhere outside bzr
[17:48] <trashbird1240> firefox keeps crashing too
[17:48] <trashbird1240> e.g. this same problem doesn't happen on Debian (on the same machine)
[17:48] <trashbird1240> it happens on Arch
[17:49] <w7z> ...that does sound like an issue just with that machine that bzr is tickling then
[17:51] <w7z> perhaps something else is sucking up memory and leaving scraps for everyone else?
[17:51] <w7z> try the normal nixy diagnostic things, top and so on
[18:06] <trashbird1240> w7z: thanks; I'm currently trying to get firefox to crash ;)
[18:06] <trashbird1240> I appreciate the help y'all!
[18:10] <trashbird1240> okay, this is weird
[18:10] <trashbird1240> it appears the pull actually worked this time
[18:11] <trashbird1240> that's strange, since it errored out
[19:07] <christiank> mgz: Have you had a chance to try the exact steps out?
[19:11] <w7z> just considering how exact I need to be... I don't have Qt on this box yet
[19:14] <w7z> okay, branch from lp->lp did it, using 2.5.1 from command line
[19:19] <w7z> http://pastebin.ubuntu.com/1254594/
[19:23] <christiank> w7z: Thanks. So what exactly does this prove - that 2.5.1 creates a broken branch from our trunk, I suppose?
[19:25] <w7z> that just the doing that operation is broken, probably server side. I'll try a few other things.
[19:25] <christiank> w7z: Thanks
[20:04] <christiank> w7z: Need to go for today. Please add any findings to the bug report. Will be on bzr the IRC channel tomorrow.
[20:05] <mgz> christiank: so, it's not specific to your project, and log against any cross-pushed stacked branch fails
[20:05] <christiank> mgz: Ah!
[20:06] <mgz> so, probably just a bug in the smart server log code
[20:06] <mgz> `bzr log -r6567 lp:~gz/bzr/tmptest` also fails
[20:07] <christiank> OK, so we found a wider problem
[20:07] <mgz> the simple workaround is not to use lightweight checkouts from launchpad
[20:07] <mgz> have a shared repo locally, and a real branch of trunk (perhaps without a tree)
[20:07] <mgz> then other branches for your feature work that you push back up to launchpad
[20:08] <christiank> Not sure what other consequences that has - we always used lightweight checkouts so far, I think
[20:09] <christiank> Will check with a colleague of mine if we want to go that way, or not (and wait for the bug to be fixed)
[20:10] <mgz> a few changed commands, easier merges, and faster responses :)
[20:10] <mgz> and backups on everyone's machines
[20:10] <christiank> Not to bad, then ;-)
[20:10] <christiank> And what about administration overhead on each developer's machines?
[20:12] <SamB_MacG5> christiank: that would be the aforementioned backups
[20:12] <christiank> OK, really need to go now. Thanks for your efforts, mgz and w7z!
[20:12] <mgz> probably a few extra commands to setup, and some additional initial data transfer
[20:12] <mgz> later!
[20:12]  * christiank is away: I'm busy
[20:16] <mgz> okay, this isn't perfect but I can mostly repo
[20:17] <mgz> have a local copy of lp:bzr, bzr serve --port 0 --allow-writes, bzr branch --stacked bzr://localhost:PORT/bzr bzr://localhost:PORT/bzr-stacked, bzr log -r1 bzr://localhost:PORT/bzr-stacked
[20:19] <mgz> server side traceback: <http://pastebin.ubuntu.com/1254742/>
[21:47] <mgz> jam: if you have any ideas on lp:~gz/bzr/hpss_log_stacked_ghost_1049124/ shout, I need to get some sleep
[21:47] <mgz> basically the code isn't looking up stacked on revs, but I don't know the right magic incantation to fix