/srv/irclogs.ubuntu.com/2012/10/01/#bzr.txt

delinquentmehey all .. is there a bzr command something akin to gitk?03:06
delinquentmelike a way I can graphically view the commit history?03:06
=== bigjools-afk is now known as bigjools_
lifelessdelinquentme: bzr viz04:59
mgzmorning all!07:59
christiankHi! 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
christiankIt is bug https://bugs.launchpad.net/bzr/+bug/104912408:59
ubot5Ubuntu bug 1049124 in OpenPetra.org "bzr log -rxxx crashes out with 'ghost' in branch, but not in trunk" [Undecided,New]08:59
bob2how old is the repo09:00
christiankGood question, let me check09:00
christiankIt got created on May 30th, 200909:01
christiankbob2: Have you got any ideas as to why this bug might happen?09:26
=== mmrazik is now known as mmrazik|lunch
pled76hello all10:19
* christiank is away: Lunch10:21
pled76failed to enable bzr via ssh10:22
pled76server: ubuntu 10.0410:22
pled76clients: Windows (putty and pageant)10:22
pled76error:10:22
pled76Connected (version 2.0, client OpenSSH_5.3p1)10:22
pled76Authentication (publickey) failed.10:22
pled76bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xcf in position 0: ordinal not in range(128)10:22
pled76putty ssh logins working ok10:22
pled76server encoding utf-810:22
pled76clients are cp125110:23
pled76pls, help to troubleshoot10:23
mgzpled76: please pastebin the corresponding section of your .bzr.log (running `bzr version` will tell you where to find that)10:24
pled76can provide full error message -- seems as python stack10:24
mgz!pastebin10:24
ubot5For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.10:24
pled76mgz: log from client or from server?10:24
mgzclient, but both wouldn't hurt10:25
mgzit looks like you've just not got your keys configured correctly, but have a knock-on problem trying to print a localised error message10:26
pled76keys are working -- putty can login from client10:27
mgzyou probably haven't told bzr to use putty10:27
=== mmrazik|lunch is now known as mmrazik
mgzby, eg setting envvar BZR_SSH to the path to your putty executable10:28
pled76http://paste.ubuntu.com/1253636/10:29
pled76thanks, will try to set BZR_SSH on client10:29
mgzheh: "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
mgzthat's pretty mangled10:29
pled76thats Russian in ibm866 converted to cp125110:30
pled76the word there is "/Администратор/"10:30
mgzso, your problem is just that it's falling back to calling 'ssh' as you haven't configured it to use putty10:32
mgzbut the locale mangling is also confusing things10:32
pled76will try setting BZR_SSH to "plink"10:33
mgzbecause it's trying to prompt for a password, but can't encode the tranlated prompt in whatever it thinks your locale is10:33
mgzpled76: what does the locale bits at the bottom of that error in the terminal say?10:34
mgzfs_enc and so on.10:34
pled76encoding: 'cp1251', fsenc: 'mbcs', lang: None10:38
pled76on client I get:10:39
pled76D:\Temp\3>set BZR_SSH=D:\Tools\plink.exe10:39
pled76D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox10:39
pled76D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox10:39
pled76ConnectionReset reading response for 'BzrDir.open_2.1', retrying10:39
pled76bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.10:39
mgzbut `plink 192.168.5.113` works?10:41
pled76plink 192.168.5.113 -l mikmer10:44
pled76works correctly -- does not prompt for password and logins to linux shell10:44
mgzyou need to tell bzr about `-l mikmer` too.10:45
pled76but how?10:46
mgzcan either stick it in the url, or in authentication.conf10:46
mgzread `bzr help authentication`10:46
pled76mgz: will try now, thanks10:46
pled76mgz: thanks a lot -- now it works!   :)10:56
mgzpled76: ace! did you add the details in authentication.conf or in the url?10:58
pled76mgz: I added section with host and user to authentication.conf11:15
pled76mgz: seems that adding user to url wiil do the trick also -- will try lately11:16
mgzright, the conf option is generally best, otherwise it's easy to forget :)11:18
* christiank is back (gone 01:40:09)12:01
bob2probably want to turn that off12:05
jelmerhi jam, mgz12:28
jamhi jelmer, I just mentioned you in the other channel :)12:29
* w7z is eating lunch12:29
jelmerjam: :-) I was first though; have just caught up on email12:29
jamw7z: still focused on sampledata, right?12:29
w7zyeah, though I left juju trying to deploy folsom when I went to put the pasta on12:30
w7zso I might have a cloud in a cloud by now (though more likely, a bunch of errors)12:31
mgzwas an install error...13:01
christiankbob2: 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
bob2nope13:38
bob2<- not a bzr dev13:38
christiankAh, OK13:39
christiankIs there somebody on the chat who might be able to have a look then?13:39
mgzchristiank: you need to talk to the launchpad maintence squad, who can be found in #launchpad on mostly AUS/US timezones13:42
christiankOK, thanks!13:42
christiankWill do13:43
mgzwas the branch derived from an SVN repo, or was it always bzr?13:43
christiankThe code was originally in a git repository and got then into a Bazaar repository13:59
mgzjelmer: were there git ghost bugs, or is this a stacking issue?14:00
jelmermgz: ghosts shouldn't occur with git imports; bugs could cause them to appear though14:01
mgzbut, unlike svn there's not a well-known previously reported bug that causes ghost issues?14:02
mgzbecause otherwise it's probably from branches moving around and breaking a stacking relationship or something14:02
jelmermgz: for svn ghosts aren't a well known bug; they are intentional behaviour14:03
=== mmrazik is now known as mmrazik|otp
christiankThe 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
christiankWe 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 report14:05
christiankThat is all on Windows14:06
mgzchristiank: the bug you reported has two different issues14:06
mgzone of them (the binary junk from the smart server) is a seperate issue and has been fixed on trunk and 2.5 branch14:06
christiankAha14:06
mgzhaving ghosts on an branch is still something that needs fixing though, most likely in the launchpad hosted repos14:07
mgzs/an/a/14:07
christiankWe 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
mgzchristiank: it caused at least the second issue14:10
christiankYou mean the 'binary junt from the smart server'?14:11
christiankjunt -> junk14:11
mgzyes, that's bug 104626514:12
ubot5Launchpad bug 1046265 in Launchpad itself ""Could not understand response from smart server" when diffing lightweight checkout of smart server branch" [High,Triaged] https://launchpad.net/bugs/104626514:12
christiankDo 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:14
mgzprobably not, but creating a fresh repo might, but that's involved and affects all stacked branches14:16
christiankI'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 Clients14:20
mgzchristiank: so, as I understand it, you work in checkouts from launchpad rather than local branches14:21
christiankCorrect14:22
mgzin 2.4 this was massively inefficient, because most actions end up fetching large chunks of the repository pack files when doing anything involving hitory14:22
maxbOut 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 not14:22
christiankWe use Bazaar Explorer to create the Branches, not the Launchpad web interface for that, though14:22
mgzmaxb: there are no ghosts on trunk14:23
mgzthe rev reported as a ghost exists on trunk14:23
mgz2.5 added some optimsations that use specific smart server verbs that do the work server side and send just a small ammount of data back14:23
christiankI realised that 2.4.2 is slower when I stepped back from 2.5.214:24
mgzbut deploying the smart server code to launchpad revealed a few issues14:24
mgzthis seems like something specific wrong with how launchpad is doing branches/stacking/?14:24
christiankI'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
mgzbut if you make a local branch and push back up to that ghost-reporting branch in your bug, that might affect things14:25
mgzchristiank: I'll be around.14:25
christiankOK, great14:25
christiankWill come back later to you then14:25
christiankThanks for helping14:25
mgz...or not, a copy of that branch in my namespace is similarly borked14:27
=== mmrazik|otp is now known as mmrazik
christiankmgz: Hi, I am back from the meeting.15:09
christiankmgz: 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:10
mgzchristiank: I branched the one from your bug report, and pushed it back up as lp:~gz/openpetraorg/dev_branching_OK_test115:38
mgzwhich has the same issue15:39
mgzrunning `bzr log -r revid:christian.kendel@om.org-20120911071731-5eips99nkud84v3o` in the local branch is fine though, obviously15:40
mgzso it's checkout/stacking related15:40
christiankAha15:40
christiankmgz: And you are running Bazaar 2.5.1?15:41
mgzthat was 2.6b2 but yes basically15:41
christiankOK.15:41
mgzbasically, using lightweight checkouts of remote branches was never really recommended15:42
mgzso has not been as well tested or debugged in general15:42
christiankmgz: 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 not15:43
christiankmgz: I see15:43
mgzyour trunk seems healthy anyway15:43
mgzit's the branches created stacked on top that are unwell15:44
christiankmgz: 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
mgzhow did you create them exactly? modify your local trunk then push back to a new location?15:44
mgzthe inconsistent parents are probably just a side effect of the code import, and may or may not be related15:47
christiankmgz: 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:48
christiankmgz: 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
mgzokay, that first step is a little funky, I'll see if I can reproduce15:50
christiankmgz: Thanks15:50
mgzhm, nope, trivial case works fine.15:59
mgzif 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:00
christiankmgz: The problem is that I have now V 2.4.2 installed and not V 2.5.x so I can't do that16:05
christiankmgz: 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:10
christiankmgz: sorry - 'in the way you described' should have been ' in the way I described'16:11
mgzchristiank: using the underlying bzr commands that explorer uses, yes16:21
christiankmgz: OK, that's good to know. Is there a release date for 2.6 yet?16:21
mgzchristiank: to be clear, I suspect it's my steps to reproduce the problem are incomplete, rather than an issue fixed in 2.616:29
christiankmgz: I'm having a break but will be back later16:29
* christiank is away: Break16:29
=== deryck is now known as deryck[lunch]
trashbird1240hello17:30
* christiank is back (gone 01:03:40)17:33
christiankmgz: I am back again17:33
mgzI'm nearly gone (well, I'm on downstairs as well)17:36
christiankmgz: 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_test117:37
mgzchristiank: for the first two steps, which were the most specific, I'm pretty confident they're entirely equivalent17:37
mgzexplorer does just call into the bzr commandline for that underneath17:38
christiankOK17:39
mgzdo other people also branches that also exhibit this problem?17:40
mgzI'm not clear if it's all branches made after a period, or just some of them17:41
christiankmgz: 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 bug17:41
christiankmgz: 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
trashbird1240mgz: can you show a link to the bug? (I'm also having a problem)17:42
mgzchristiank: okay, I'll try with the exact steps, and not from within the datacenter17:42
mgztrashbird1240: bug 104912417:43
ubot5Launchpad bug 1049124 in OpenPetra.org "bzr log -rxxx crashes out with 'ghost' in branch, but not in trunk" [Undecided,New] https://launchpad.net/bugs/104912417:43
christianktrashbrid1240: Sure: https://bugs.launchpad.net/bzr/+bug/104912417:43
* mgz won! :)17:43
trashbird1240I think I"m having a different problem17:43
mgztrashbird1240: what's the error message you're getting?17:44
christiankmgz: 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 problem17:44
trashbird1240I'm getting "bzr: out of memory" when trying to pull to my laptop17:44
trashbird1240I have narrowed it down to one particular revision17:44
christiankmgz: Thanks for trying the exact steps.17:44
mgzah, you have the good ol' bloated repo problem17:45
trashbird1240mgz: that appears to be the problem ;)17:45
mgzif you know which rev it is, and are an admin of the branch,17:45
trashbird1240which I am...17:45
* trashbird1240 is waiting with baited breath17:46
mgzyou can pull till just that rev, then rewrite the subsequent commits, then push up a new unbloated branch, and retarget trunk at that17:46
trashbird1240okay17:46
mgzso, `bzr branch -rLAST_GOOD lp:PROJ`17:46
trashbird1240is there any other way that would not require reversioning?17:46
trashbird1240I know that's my real problem, but is there any way to dump the branch to a file or something like that?17:47
mgztrashbird1240: depends, if it's in your history, nope.17:47
trashbird1240okay17:47
trashbird1240I really appreciate the help17:47
trashbird1240the annoying thing is that it's only this one machine17:47
trashbird1240and it didn't happen until I upgraded the operating system17:47
trashbird1240I therefore think the problem is somewhere outside bzr17:48
trashbird1240firefox keeps crashing too17:48
trashbird1240e.g. this same problem doesn't happen on Debian (on the same machine)17:48
trashbird1240it happens on Arch17:48
w7z...that does sound like an issue just with that machine that bzr is tickling then17:49
w7zperhaps something else is sucking up memory and leaving scraps for everyone else?17:51
w7ztry the normal nixy diagnostic things, top and so on17:51
=== deryck[lunch] is now known as deryck
trashbird1240w7z: thanks; I'm currently trying to get firefox to crash ;)18:06
trashbird1240I appreciate the help y'all!18:06
trashbird1240okay, this is weird18:10
trashbird1240it appears the pull actually worked this time18:10
trashbird1240that's strange, since it errored out18:11
=== yofel_ is now known as yofel
christiankmgz: Have you had a chance to try the exact steps out?19:07
w7zjust considering how exact I need to be... I don't have Qt on this box yet19:11
w7zokay, branch from lp->lp did it, using 2.5.1 from command line19:14
w7zhttp://pastebin.ubuntu.com/1254594/19:19
christiankw7z: Thanks. So what exactly does this prove - that 2.5.1 creates a broken branch from our trunk, I suppose?19:23
w7zthat just the doing that operation is broken, probably server side. I'll try a few other things.19:25
christiankw7z: Thanks19:25
christiankw7z: Need to go for today. Please add any findings to the bug report. Will be on bzr the IRC channel tomorrow.20:04
mgzchristiank: so, it's not specific to your project, and log against any cross-pushed stacked branch fails20:05
christiankmgz: Ah!20:05
mgzso, probably just a bug in the smart server log code20:06
mgz`bzr log -r6567 lp:~gz/bzr/tmptest` also fails20:06
christiankOK, so we found a wider problem20:07
mgzthe simple workaround is not to use lightweight checkouts from launchpad20:07
mgzhave a shared repo locally, and a real branch of trunk (perhaps without a tree)20:07
mgzthen other branches for your feature work that you push back up to launchpad20:07
christiankNot sure what other consequences that has - we always used lightweight checkouts so far, I think20:08
christiankWill check with a colleague of mine if we want to go that way, or not (and wait for the bug to be fixed)20:09
mgza few changed commands, easier merges, and faster responses :)20:10
mgzand backups on everyone's machines20:10
christiankNot to bad, then ;-)20:10
christiankAnd what about administration overhead on each developer's machines?20:10
SamB_MacG5christiank: that would be the aforementioned backups20:12
christiankOK, really need to go now. Thanks for your efforts, mgz and w7z!20:12
mgzprobably a few extra commands to setup, and some additional initial data transfer20:12
mgzlater!20:12
* christiank is away: I'm busy20:12
mgzokay, this isn't perfect but I can mostly repo20:16
mgzhave 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-stacked20:17
mgzserver side traceback: <http://pastebin.ubuntu.com/1254742/>20:19
mgzjam: if you have any ideas on lp:~gz/bzr/hpss_log_stacked_ghost_1049124/ shout, I need to get some sleep21:47
mgzbasically the code isn't looking up stacked on revs, but I don't know the right magic incantation to fix21:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!