User1: I get a fun error when trying to run âbzr updateâ: UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 358465: ordinal not in range(128)
User1: backtrace and some info: http://pastebin.com/m2d85582c
User2: anyone have a favorite rhel/centos rpm that's newer than the one provided by EPEL?
User1: hah, I love bzr:   Conflict adding file .bzrignore.THIS.moved.  Moved existing file to .bzrignore.THIS.moved.moved.
User1: (how on earth I get conflicts when I only have one local branch is beyond me :-P)
User3: User1 you can conflict with someone else without needing two local branches
User1: User3 there is noone else, there is only one branch, my local one
User3: User1 can you do 'bzr inventory | grep .bzrgnore.THIS'
User4: Is there a way to change commit comments?
User1: User3 yeah, bzr inventory returns such a file
User3: User4 uncommit the commit, and recommit it with new comments.
User3: User1 ok, you need to 'bzr remove' that file. bzr uses '$filename.THIS' for storing its conflicts
User1: ah
User1: ok
User3: so by versioning it you've got it in a loop
User4: User3 I'm better off not doing this, it's an old revision
User3: User4 then no.
User4: ok thanks anyway
 * sandsmark blames etckeeper
User3: User1 could you file a bug? we should be more graceful/informative about that particular case.
User1: User3 well, 1.5 is pretty old
User3: even so
User1: ok
User3: if its fixed already it will be easy to close ;)
User1: heh, ok :-)
User3: but while I suspect we have a bug thats similar to this already, I'm fairly sure we haven't actioned it.
User3: so at worst this will be a dup and add data to the frequency people hit it.
User1: User3 uhm, is this really a bug, though? I would rather say the problem is with etckeeper, adding all files indiscriminately
User1: (the real question is where the conflict comes from, though)
User3: bzr could help - it could say 'this is a dangerous file to add', it could, on conflicts, not conflict on that file but instead know it can overwrite it;it could adjust the conflict path it uses
User1: yeah, true
User1: well, it might give some false positives, but a simple warning might be nice
User1: https://bugs.launchpad.net/bzr/+bug/414589
User5: Ubuntu bug 414589 in bzr "Bazaar doesn't notice/care if you try to version-control *.THIS, *.BASE, *.OTHER or *.moved" [Undecided,New]
User1: User3 something like that ok?
User3: User1 great
User1: k
User3: I'll add a little editorial when it gets to my inbox
User1: ok, thanks :-)
User1: hmm, I'll try to backport a more recent bazaar to see if it helps with the utf8-failings
User1: ah, it is in lenny-backports
User1: ah, awesome, that worked like a charm
User1: hmm, another odd error
User1: http://pastebin.com/m32268cf3
User6: User7 some people find documentation more exciting than writing code ;-)
User7: User6 really?? Name one. :-)
User6: crazy people I know :-)
User6: but exactly the ones you want to be writing your documentation
User7: User6 true. Too much knowledge of the code can be a disadvantage when it comes to writing clear docs :-)
User7: User6 well docs for beginners at least
User8: see the git documentation!
 * mzz ducks
User6: not wanting to spend your time writing code means that you can instead focus on writing great documentation
User7: User8 it makes my head spin
User8: (it's not entirely fair towards the git folks, but the thing I remember most clearly about git is that it documentation suddenly went on and on about some kind of squid when I was trying to do some basic version control thing)
User7: User8 'git log' is 30 pages! (and I wish I understood half of it)
User6: I'd prefer code written by people passionate about it than code written by those who were just writing it because they felt they had to
User8: "I don't *want* to hunt deep sea creatures right now! stop talking to me about an octopus!"
User6: same goes for documentation
User9: am getting these errors: bzrlib.errors.LockContention: Could not acquire lock "<directory>/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable <== which I infer is a roundabout way of saying directory doesn't exist? or?
User9: This is seen via a cron task; but only 1 in 4 runs.
User3: User9 is it on nfs?
User9: User3 no, local. based on the full traceback tho - i suspect it may be a bzrlib issue of sorts. it's pulling in a local 1.16 copy to run with - which was a hack to get around 2a format updates back in July. Take that out and I get a full on boom. progress of sorts...
User9: User3 old vs new https://pastebin.canonical.com/21210/ - i suspect the cm bzrlib needs updating; and/or rejig the path to use the system one.
User3: User9 this shouldn't have suddenly gone odd
User3: however, the latter error means that you've broken it by whatever gives the boom:)
User9: truly :-)
User9: I've just put in a fix which works in manual testing; but in the leadup to, was seeing some really weird errors. My first suspicion was pebkac and inclined to hold that; but I wonder if something else is going on
User3: something changed ;)
User9: which is where it gets very weird; because a similar script isn't elizabeth73@example.org. Anyway. see if the fix in place works.
User9: User3 nope. same error. something else is happening here....
User3: User9 yes, I rather thought so :P
User9: aye. ah well. At least that cleans up one possible area of problem. <== searching for any silver lining
User2: let's say i have an existing bzr branch, and i want to bring in some code from another completely unrelated tree (think: main project, and plugin) -- is there any slick way to somehow preserve history, or even to keep that part of the tree "pointing" at the other branch to bring in updates later? Is this exactly what is going to be supported in the future with "subtrees"?
User3: bzr add --ids-from /path/to/main files_copied_from_main
User3: or something like that
User3: then if you do a cherry pick merge bzr will know the files are the same
User2: intriguing-- i'll check that out
User3: keeping the history the same is rather harder, unless you're happy to have all of the other tree copied around forever more.
User10: hi igc
User2: User3 this is a really cool feature, i'm amazed that i never encountered it in my hours of googling on the topic
User3: its not a panacea
User3: but it should help
User2: User3 so i put file-ids-from to the top of the branch, even if i'm only integrating a part of it?
User11: Hello, I accidentally moved a file under version control manually and then commited.  Is there a way to tell bzr I have moved the file to update its version history?
User11: I moved the file and then used "bzr add" and then commited instead of bzr move
User3: User2 yes, and you'll want the files being added at the same paths; then you can bzr mv then into their final place in the new tree
User3: User11 bzr uncommit
User3: User11 bzr remove --keep <file>
User10: User11 uncommit, revert add, then use bzr mv --after
User3: User11 bzr mv --auto
User3: User11 bzr commit
User11: Ok, I actually commited more than once before I realized it, can I uncommit to a certain revision?
User3: you can commit several times
User3: you may want to shelve each step
User3: unless you're happy to combine them
User11: User3 Hmm, ok thanks.  I will try to follow your instructions.  So I'd just uncommit a few times until I'm at the right revision before the move?
User11: User3 I think I need to read up some more on shelving.
User3: uncommit; shelve --all; uncommit; shelve --all; uncommit; do stuff
User3: commit; unshelve; commit; unshelve; commit
User7: hi bialix
User10: User7 I've read http://doc.bazaar-vcs.org/plugins/en/qbzr-plugin.html
User10: I see there is holes in or doc
User10: and based on your mail today I think I need to release 0.13.2 with some patches cherrypicked from trunk
User11: User3 ha, awesome.  I think I see what shelving is about.  I am mighty relieved to learn this.  Thanks.
User7: User10 why not a qbzr 0.14 at the end of thw week instead?
User3: the docs say more
User3: you don't want to uncommit past a merge, or stuff other folk will have merged, unless you really need to do.
User3: but uncommit + shelve - very powerful
User10: User7 can you explain this deadline?
User10: 1 week
User10: User7 btw, if you will be able to regenerate the doc with fresh qbzr trunk so I can see my latest doc improvements, it will be great.
User7: User10 iiuic, around aug 24? is the close off day for packages to make it into karmic. Beyond that, things can go in but the paperwork and approval process becomes larger
User10: aha
User10: understand
User11: User3 ok, I don't need to uncommit past a merge so I should be good.  Thanks again.
User10: User7 so yes, it's better to release 0.14 then
User7: User10 I'm not a deb/Ubuntu packaging guy though so take my comments with a grain of salt until someone closer to the process confirms that
User10: User7 I'm not either
User10: User7 but 0.14 cycle is kinda too short (2 weeks) I guess
User12: New upstream versions do need paperwork in a week, but it's not impossible paperwork.
User12: It gets progressively harder as time goes on, so you should endeavour to get it in ASAP.
User12: (August 27 is the date, I believe)
User7: bialix, User12 sounds right: https://wiki.ubuntu.com/KarmicReleaseSchedule
User7: User10 so if it's aug 27, I think next Monday is ok for 0.14
User7: User10 there's a lot there in a sense: qexport, qbind, qunbind and hopefully more if I pull my finger out this weekend and write quncommit say
User7: User10 and, no pressure, but qrun would be nice :-) :-)
User3: User7 it might be prettier for people to have qbzr uncommit
User10: User7 we have also new commit_data patch I'm about to merge
User10: User7 so I think I'd better release 0.14 in the middle of this week and have 1 week for user testing.
User10: so we can do 0.14.1
User10: if necessary
User10: User12 what is the process to ensure our release from PPA will go into karmic?
User7: User10 to regen the plugin docs yourself, just download the branch I mentioned in the email and run the built-topics.py script. I think you can give qbzr as an argument iirc
User7: User10 I need some lunch - bbl
 * igc food
User10: ok
User11: User3 do I need to move the file back by hand?  I uncommitted to a revision that should have the file unmoved but when I "bzr status" it shows the file as removed.  Am I missing something?
User3: User11 uncommit doesn't change the tree
User3: User11 which is why you need to shelve between uncommits:)
User12: User10 You have to ask for it to happen, or it will not elizabeth73@example.org. https://wiki.ubuntu.com/SponsorshipProcess is what you want.
User3: User11 hwen you're back tot he point you want to be recommitting on, just do
User3: bzr remove --keep FILE
User3: bzr mv --auto
User3: and bzr will detect it
User11: sorry to be slow, but is FILE the path to the file that I have moved or the original location?  Trying the original location gave an unversioned error.
User3: the new location
User11: ah ok
User11: User3 "bzr mv --after" rather than "bzr mv --auto"?
User3: the latter is easier
User3: :)
User11: It gave me a no auto option error.  Do I need to upgrade bzr?
User3: oh
User3: if you have an old bzr then mv --after OLD NEW
User3: --auto is reasonably old itself though. strange.
User11: ugh, said OLD is not versioned
User3: hmm
User3: do 'bzr st'
User3: does OLD show as 'missing'?
User11: nope they show as 'removed'
User3: ok
User3: run 'bzr revert OLD'
User3: then, 'rm OLD' (!not bzr rm OLD)
User3: and then the mv --after should work
User11: you are a lifesaver!  I think that did the trick.  Thanks
User3: my pleasure
User13: are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ?
User14: hi all
User3: User14 hi vila
User3: User14 15:11 < thumper> are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ?
User14: User3 I saw that, but *I* am not windows savvey 8-)
User14: The best I can guess is that ssh or its agent is not configured as it should... but indeed someone can explain the steps needed to check that better than me...
User14: User3 and hi :)
User3: :)
User3: have a good weekend?
User14: could have been better, but life can't always be pink :)
User9: User3 that locking error we were chasing earlier. hypothetically :-) if we had two almost identical tasks (bzr update/config-manager) running simultaneously, would you expect that to generate that style of error?
User3: no
User3: but - a) bugs
User3: and b) bugs
User9: heh
User3: so
User3: we guard the dirstate _write_ lock with a lockdir lock on the tree
User3: and we take write locks out to write stuff (duh)
User3: we don't guard dirstate read locks like that, we expect the os to tell us it can/can't read lock it.
User9: makes sense
User9: as a "can't hurt" trial, I've offset the problematic of the two jobs to run 5 mins after the 1st. If we get a repeat, then life gets interesting again; if we don't...
User3: User9 kk
User3: if it 'fixes it', file a bug
User3: it may be a misconfigured sys/proc thing, or a code bug
User3: there may be a legitimate error we don't catch.
User3: \o/ 12 errors
User3: _closing in_
User9: right
User9: heh
User3: 11.
User9: just as well the number counts down. I'd be worried else...
User3: 5
User15: User3 hurrah!
User3: I love this:
User3: :!bzr commmit -m "Merge fix for test_knit in 2a."
User3: Command 'commmit' not found, perhaps you meant 'commit'? [y/n]: y
User10: User13 your question still open?
User10: User13 answered
User10: User14 bonjour
User14: User10 hi, argh, already gone
User3: Done!
User3: User15 ^
User14: User3 tests passing with 2a as default ?
User3: yes
User14: YES !
User14: :)
User3: ;)
User3: just in time too
User3: spamming the review queue++
User14: User3 since you seem to be in the right mood, care to fix the loom failures too ? :-}
User3: heh
User3: 6pm
User3: I started at 6:30 this morning.
User3: But you could put up a patch for loom !
User14: hehe, I tried :)
User3: [please do]
 * lifeless halts
User15: User3 sweet!
User15: User3 I churned through a bunch of your review proposals, btw :)
User3: User14 seriously - if you wanted to identify any remaining tests (i've been running a reduced set from what failed the first time I tried) that would be great
User3: User14 and secondly, loom is something we support, feel free to put time into keeping it working :)
User3: User15 i saw - thanks
User3: User15 I'm not going to shepard them today.
User3: I'll probably make pqm-submit a bit friendlier tomorrow and batch-submit them from lp directly.
User14: User3 (regarding loom), my last submission stalled, mostly because I had misconceptions about looms (when pushed mainly), I should look at it again...
User3: User14 bzr branch lp:bzr-loom; fix the failing tests; push and submit ;)
User3: the big question for me is 'should -b make a new branch or thread, in a loom' and I think the answer is 'thread'.
User14: User3 hehe, I know, that was bug #309730 I was referring to, marked for expiration tomorrow :-/
User5: Launchpad bug 309730 in bzr-loom "loom semantics around about push/stacking/clone unclear or buggy ?" [Undecided,Incomplete] https://launchpad.net/bugs/309730
User3: oh
User3: well, push in a loom to a new location is meant to make a loom
User3: otherwise it pushes to whatevers there - loom or branch
User14: yup, I thought it should always push to a branch (misconception)
 * igc dinner
User13: User10 thanks
User10: User13 I think there is bug report in bzr about using paramiko as default SSH client
User10: plink (PuTTY SSH tool) has too much caveats
User10: and that guy using plink
User13: ah
User13: what is the default setup with bzr on windows?
User13: I have some people locally that want me to give them a tutorial on bzr
User13: but they all use windows
User13: they are interested in using LP though
User13: so they need SSH keys
User13: are there docs on the wiki about the easiest way to set this up?
User13: I don't have a windows machine myself any more
User10: User13 I guess you need to ask for this in Bzr-Windows mailing list
User10: I don't think there is good wiki about setup ssh for windows
User10: I'm working with lp and sftp and ssh since 2006 and during this years I've minted the gold rule: always use paramiko
User10: User13 btw, launchpad wiki resource about setting up ssh keys is very good
User10: the problem not in lp itself or ssh keys
User13: ok...
User10: problem in initial connection when user should say: yes, I'm trust this ssh server
User10: paramiko do it implicitly
User10: plink just fails
User13: hah
User13: how does one add a trusted server for plink then?
User10: manually
User10: bzr can;t help here
User13: ick
User10: one need run plink to connect the server
User10: first time
User10: User13 http://pastebin.com/m2d48ac6e
User10: maybe launchpad plugin for bzr can help here? with some sort of special command. I dunno
User13: hmm, not right now for sure :)
User10: yep, I mean somebody need to write this special command
User10: but I'm just suggest people to avoid using plink
User10: paramiko using the same ssh keys from pageant
User10: and I don't find any significant difference in speed between both
User10: and paramiko bundled into bzr.exe by default
User10: so paramiko -- it's almost the right way
User10: and perhaps one can file a bug against lp:paramiko and asking for y/n when unknown ssh server signature encountered
User16: hi there, I'm moving my first steps with bzr.. seems pretty cool so far.. I've been able to create a centralized development infrastructure ..
User16: now I'm not sure how the workflow for creating different versions of my software will be..
User16: should I have to tag the trunk? or creating subdirectories? .. I'm confused
User15: User13 btw, for casual launchpad code users password auth would probably be more convenient... I wonder if we should enable that in code hosting's ssh server?
User13: User15 I'm not sure I could sell that
User15: Yeah.  And I kinda like that we're currently only asking users to type their password directly into the website, so maybe it's not worth it.
User13: User15 keep thinking though :)
User15: But it would probably ease the pain for SSH newbies.
User13: I'm sure there's something for our windows users
User13: perhaps we should do something with the launchpad plugin like bialix suggests
User15: Make the bzr installer automatically add launchpad's fingerprint to plink's registry of known hosts?
User15: The difficulty is partly that windows doesn't have a de facto standard SSH install like /usr/bin/ssh that we can rely on, and partly that the one of the common options (plink) is pretty crummy.
User15: So insulating ourselves from that via bundling paramiko is perhaps the best we can do?  Dunno.
User10: User15 just for note: in the past (~2006-2007) plink was disabled for long time, at all
User10: because the same problem with initial y/n
User10: thumper, User15 Bug #296110
User5: Launchpad bug 296110 in bzr "bzr should install launchpad ssh host keys" [Low,Confirmed] https://launchpad.net/bugs/296110
User10: User17 hi
User17: hi bialix
User18: hello is there a list of project hosting sites with bazaar support?
User10: User17 today I've stumbled with problem in qconflicts
User10: User17 mark_item_as_resolved try to convert file_id to filename. do you remember why in needed?
User17: User10 not really, sorry
User10: heh
User10: currently I'm just using filename we shows in the widget
User10: I'll dogfood it more, maybe can found use case for this
User14: User10 Are you sure you didn't mean bug #237297 instead of #296110 ?
User5: Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297
 * vila trying to better understand for the next time the question is raised
User10: User14 no
User10: they are different ways to solve th eproblem
User10: 296100 is about lp
User10: spiv and thumper talking about ssh server fingerprint, and this bug about certificates
User14: User10 ???
User10: [14:53]	<vila>	User10 Are you sure you didn't mean bug #237297 instead of #296110 ?
User5: Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297
User14: both #237297 and #296110 are about host keys
User10: yep
User10: vila, I teach you right answer for this problem on WIndows: set BZR_SSH=paramiko
User14: User10 ok, good :)
User10: https://bugs.launchpad.net/bzr/+bug/414743
User5: Ubuntu bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New]
User10: hmmm
User14: and which ssh agent ?
User10: why ubottu said it's a "Ubuntu bug"?
User10: if paramiko then pageant
User14: ok
User19: bzrlib.tests.blackbox.test_serve.TestBzrServeSSH.test_bzr_connect_to_bzr_ssh is leaking threads among 1 leaking tests.
User19: should I worry?
User10: User14 https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
User14: User19 no
User10: User14 this guide is OK, but it miss the problem with plink/paramiko
User14: User10 may be mention that in bug #414743 ?
User5: Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New] https://launchpad.net/bugs/414743
User10: it's really hard
User10: bbiab
User10: User14 it seems either nobody care too much about plink or don't want to prohibit it.
User10: User14 and there is only jam who can do something about windows
User10: cila: and jam too busy with other things
User10: it's a stalemate I'd say
User14: These are good reasons to collect the information in the bug reports
User10: which sort of information
User14: <bialix> User14 this guide is OK, but it miss the problem with plink/paramiko
User14: the sooner people get good directions... the less problems they will encounter down the road...
User10: User14 IIUC there is possible that people could use not plink but openssh port for win32 that may not affected by plink problem
User10: I'm afraid there is no "right" answer
User10: perhaps just prohibit plink from auto-detection will be enough
User10: somebody should say: "yes, this is the right way"
User10: as of today nobody dare enough
User14: User10 JFDI :)
User10: JFDI?
 * bialix never was good in acronyms
User10: jump for dumb iphone?
User14: Just Do it :)
User14: Colonel-Rosa: very polite way 'focus', thanks ;)
User10: oooh, quoting fullermd: where I can download extra 8 hours to do everythong I want?
User10: Colonel-Rosa: you can ask about bzr server
User10: the answer will depends on question
User10: plain bzr serve has no support for ACL
User10: so you need to use bzr+ssh
User10: and specify users via ssh stuff
User10: good question
User7: night all
User10: User7 night
User10: Colonel-Rosa: maybe because when you run bzr+ssh it invokes bzr serve via ssh in write-enabled mode?
User15: Colonel-Rosa: in some situations (e.g. a small, isolated network with only trusted users) a simple unauthenticated write-enabled server is all you need.
User10: I'm using it in such conditions at work
User10: small network
User7: User10 before I forget, that bug where qbzr and bzr-pipeline are incompatible needs fixing in qbzr 0.14.*. Can you chat to garyvdm about it? If we have to, I'd like to drop support for us override the merge command - I don't think the feature we're offering is important enough to break compatibility with other plugins overriding merge. You guys may feel otherwise though
User15: Or you could run "bzr serve" on a localhost only port, and then and use another tool to provide simple authentication based on SSL client certs on a public port.
User20: Hi, is there any way to make bzr remember the password I use for my googlecode SVN? (HTTPS checkout). Currently it asks me every time.
User10: User7 Id like to remove merge --qpreview
User10: User7 but garyvdm has another opinion. but I can remove it just for 0.14 and later fix it in trunk
User10: User7 good point though. if you can write some comment tomorrow in that bug report
User14: User15 regarding ssl client certs, did you review denys merge proposal about bzrs:, you nay have to chase the right one a bit as he made several resubmit
User14: User10 good mail on bzr-windows :)
User10: why?
User10: I hope it will start discussion
User14: User10 exactly !
User15: User14 I did, yes.
User14: User15 great
User14: User15 I should check that to stay in touch then :)
User21: User6 good morning, do you have some time to look at bug 405251 again? Our new repo's are killing themselves in the same way...
User5: Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251
User21: I don't know why Kopete always replaces jam with James_W: I mean jam...
User22: User21 I can probably look at it some today, I need to check for any other pressing matters, though
User22: morning vila
User10: User22 hello
User22: hi bialix
User10: User22 did you saw my message about installing Pyreadline on kerguelen?
User23: hi everyone!
User23: i'm in big trouble! :(
User23: i think maybe i lost 2 weeks of work
User10: bzr heads --dead
User23: bialix > yes!
User23: bialix > i see my last (true) revision in the list
User10: bzr pull -r revid:your-revisioin-id --overwrite .
User23: trying...
User10: or branch with this revid
User21: User6 thanks, I will wait.
User21: User6 thankx
User21: Thanks, jam... Very irritating.
User21: I will check why Kopete always replaces jam.
User23: omfg bialix! :)
User22: User21 you might be typing jam<tab> which wouldn't autocomplete the exact name, I guess
User21: I'm just typing User22
User10: User23 what? I'm in telepatic mode?
User21: I'll check the settings.
User22: bialix, User23 or 'bzr merge . -r revid:'
 * bialix : telepatic mode off
User23: User10 kind of ;)
User23: i did not know this command but i was pretty sure bzr could not lose my files
User23: but "bzr log" made me nervous :P
User23: maybe i'll explain how i did to lose my files
User23: 1. commit changes locally
User23: 2. commit to the repo
User23: 3. uncommit the repo
User23: 4. do a lot of changes to the --locla
User23: 5. update from the repo
User23: 6. panicking while reading the list of actions done by the update command
User23: 7. revert to the last:1 rev
User23: 8. panicking even more
User22: User23 so update changes your local work into the upstream work and 'merges' the local stuff in
User22: when you reverted you through away your local work
User22: 'bzr heads --dead' shows you the local work again
User22: and you can merge that back into your upstream
User23: jam > okay
User23: bialix > thanks, really :) and to the bzr team for anticipating my mistakes (and for building a *real* VCS, unlike that sh** of VSS i have to use at my office :P)
User10: User23 np
User23: bye!
User10: User22 I've got very strange error: ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex(GraphIndex('bzr://host/repo/.bzr/repository/indices/1be11e45e6965720333219afc18eac5b.rix'))) is not locked
User22: User10 happens when you use "-r XXX" + log + bzr+ssh
User22: I assume we aren't locking the branch before evaluating -r
User10: User22 no, I'm using merge
User10: and plain bzr://
User22: User10 you are using a remote access, and -r, right?
User10: User22 I did not found such bug, and pehaps just filed duplicate
User22: bzr+ssh == bzr for pretty much all purposes
User10: yes
User10: Bug #414869
User5: Launchpad bug 414869 in bzr "backout merge from default location (bzr server) fails with ObjectNotLockedError" [Undecided,New] https://launchpad.net/bugs/414869
User22: there is one for log
User22: presumably log and merge both aren't locking the branch
User22: which works ok locally for some reason
User10: error message misleading then
User10: it tells about locking index file. not the repo itself
User22: it is a bug, people shouldn't get that sort of error
User14: morning jam !
User22: The error could probably be clearer, not sure if it is worth tracking it all down
User22: hi vila
User24: Hi, who should I contact to get a review of the patch done to fix 'Bug #347729: git-bzr doesn't work'
User5: Launchpad bug 347729 in bzr-fastimport "git-bzr doesn't work" [Undecided,New] https://launchpad.net/bugs/347729
User22: User24 jelmer is the maintainer of bzr-git, last I checked
User6: git-bzr, not bzr-git :-)
User10: if this bug about fastimport you need Ian Clatworthy, igc
User10: he's sleeping right now
User24: User6 I know but It's broken by bzr-fastimport
User10: AU timezone
User24: User10 ok good to know. thanks
User14: User22 you haven't submitted 1.19-kg-merge-sort yet right ?
User22: User14 afaik it is 1.19-known-graph-sorted and no, it hasn't been submitted yet
User14: User22 yeah, typed it from memory, I knew you recognize it :-)
User14: It seems to come along nicely...
User22: User14 I'm at ~3x faster for merge_sort
User22: it doesn't change the algorithm at all, though
User22: I at least feel that I have a better understanding of the algorithm now
User14: Well, I wanted to work on it too, but you fired first :-D I'm ready to review though
User22: User14 well, review this one first, then :)
User22: https://code.edge.launchpad.net/~jameinel/bzr/2.0b1-merge-sort/+merge/10253
User22: User14 so the current open questions for me are
User22: 1) Am I exposing it in a reasonable manner (VF.get_known_graph_ancestry())
User22: 2) Should merge_sort handle ghosts internally or not
User22: (i think it should, since it removes a lot of the _strip_NULL_parents calls)
User14: 2) yes
User22: 3) Should bzrlib.tsort.merge_sort be a thunk over to KnownGraph(parent_map).merge_sort()
User14: 1) sounds ok to me (that was your last commit right ?)
User22: 4) Should KnownGraph.__init__() check for graph cycles
User22: User14 1) last-ish
User22: (rather than merge_sort and topo_sort doing it now)
User14: 3) for backward compatibility, but my feeling is that we should deprecate bzrlib.tsort
User22: for (3) it would basically mean moving the current tsort implementations into KnownGraph.py and then changing the tsort.py functions to import graph, etc.
User22: 5) KnownGraph.topo_sort() == 10ms, KnownGraph.merge_sort() == 50-60ms, can I get that down any further?
User25: User26 hi
User26: User25 Hi
User26: I am having trouble getting revisions that glyph is committing.
User22: (like not allocating extra info per record, but instead hanging it off of the original KnownGraphNode object.)
User14: 4) hmm, if they can appear, there should be a cheap way to check, so yes
User25: User26 so, the revisions are there.  the file in question does exist in my homedir on charm.
User22: User14 right now, if gdfo = None after processing, we know we have a cycle
User22: it just means another pass across the data
User22: or something along those lines
User25: (why did this have to happen only with the *one* highly proprietary and sensitive bzr repository I've worked with this year rather than one of the dozens of totally harmless open source ones)
User26: User25 How did the revisions get there?  Did you 'bzr push ...' to charm?
User25: User26 yes.
User25: from illidan, as it happens
User25: are you pulling from alastor?
User14: User22 hmm, I'm surprised there is not a simpler way... but that can come later if really needed (i.e. start with the check in one pass, and we found a better place, we'll get rid of the pass)
User25: wait no
User25: crap, this is my fault
User26: Oh too many hosts
User25: for some reason 'charm' is an ssh alias for alastor on this machine
User22: User14 well, we can check as we pass over the data already
User26: User25 Wow awesome
User22: the current code pops things out of a dictionary
User22: and notices when what it wants to pop isn't there
User22: but
User22: 1) doesn't handle ghosts
User22: 2) takes time to build that dict, and pop everything out of it
User26: okay got it
User22: I'm down to around 4microseconds per node
User22: which sounds great
User25: sorry everybody, bzr's great, no bugs
User22: but still means it is 1.0s to merge_sort the OOo graph
User22: though at 10s to load it, I'm probably in the right ballpark
User14: User22 my feeling is that a two passes algo should be possible,
User14: if loading still dominate, don't bother optimize the algo :-D
User14: User22 two passes, not counting building the graph !
User22: User14 2 passes for merge_sort?
User22: it is 1 two depth-first traverse
User22: 1 to pop that back out and number
User22: 1 to reverse it for display
User22: (as it stands now)
User22: (1 *to* depth-first trav)
User22: oh, and convert _MergeSortNodes into merge_sort tuples
User14: User22 ok, I haven't look at how it works in detail right now, if it's already 2 passes, then good. I'm not sure the reversing counts as a pass though, if it is, it may be worth avoiding it
User22: User14 it costs 10-15 ms out of 55 ms of processing
User22: though there is some more actual processing going on there
User22: which I'm trying to factor out
User22: well, move to a different place at least
User14: User22 by the way, about revno 4627, don't worry too much about the layering yet, my feeling is that at one point we'll have a node_index and from there we'll be able to have dedicated arrays for specific processing
User27: Hey I am having a problem adding a directory. It doesn't look to be ignored so I don't see why it won't add... http://stikked.com/view/88043329 - my bash session
User27: ah so interesting the files/ dir was ignored in .bzrignore in a previous revision http://stikked.com/view/60255181
User27: since then I have removed that rule but it is as if that has cached somewhere
User27: abyone seen something like this before?
User17: well, if you want to know more information use bzr add -v
User17: but if you just want to add the directory, add it manually
User27: luks - http://stikked.com/view/20119491 so I added it and it doesn't give me any errors but still shows as unknown with a status
User17: what does "bzr add -v" say?
User17: but I don't know what could be the issue
User27: ignored config/site.php matching "config/site.php"
User27: which is fine as that corresponds with my .bzrignore rule
User27: this is truly weird. Not seen anything like this before
User17: my guess would be that there is something wrong with the checkout, so I'd make a new checkout to see if it works there
User27: doh the files/ dir was a different checkout!
User3: moinmoin
User14: Good morning User3)
User3: 4 new failures since I last ran full test run
User28: wooo
User28: go 2.0, go!
User14: User3 merge trunk and use --parallel=fork again :-)
User29: re
User30: What's the command I should run to update my repository (which I created around 1.08 or somesuch)?
User31: User30 bzr upgrade --<format>
User31: User30 e.g., bzr upgrade --1.9
User3: User30 is bzr telling you to ?
User30: User3 No, it's not, but it's been quite slow branching and doing everything.
User3: User30 we have a bug open at the moment about an apparent performance regression
User3: I suggest you file one yourself
User30: User3 Oh... this isn't a regression. This is more like I haven't seen any speed increases since I've started using bzr.
User3: ah
User30: What's the newest repository format?
User30: --19?
User3: what does bzr info -v report for the repository you have?
User30: 1.9
User30: Format:
User30: control: Meta directory format 1
User30: repository: Packs containing knits with rich root support
User30: so....should I upgrade?
User28: awmcclain, upgrade --2a should give you give significant performance improvments
User3: what bzr version do you have?
User3: User30 ^
User30: 1.18a
User30: 1.18rc1, sorry
User3: User30 yes, switching to --2a would be sensible. There are docs on doing this on the web
User3: User30 please do follow the upgrade guide ;)
User30: User3 Great! Will do.
User30: Hrm... my bzr status is borked. (Haven't run the upgrade yet). here's the traceback: http://dpaste.com/81857/
User3: try --no-plugins
User30: a ha...
User32: weird traceback though
User3: User30 if that works, try upgrading your plugins, or something
User30: User3 It was the xmloutput plugin, which was nearly 18 months old
User30: I don't even need it anymore
User30: Thank you!
User33: hi lifeless
User3: hi Noldorin
User33: thought i might try to prgoress a bit more with my FTP issue now
User33: while i have some time
User3: cool
User33: i got your last message...but wasn't quite clear on a few things
User3: User15 :( you broke my testsuite
User33: <lifeless>	there is a function in that file that the lock object uses to check that its in the right place on disk and has the right nonce
User33: i'll be glad to test that now, if you could just clarify things slightly
User30: One thing I'm not sure of after reading http://people.canonical.com/~ianc/doc/en/upgrade-guide/#data-migration, I have a local shared repository containing a bound "trunk" branch to a remote server (which also has a shared repo) as well as my local branches. Do I need to update the repo on the remote server before I update my local repo?
User3: User33 self.confirm()
User3: put that after the self.transport.rename()
User33: right
User3: in normal operation that will raise
User3: with your symptoms it may not raised
User33: i see
User3: User30 no, you can upgrade them independently
User3: the server will need bzr 1.16 (1.18 preferred) though
User3: User33 so you probably need a try:except:else: around the confirm
User3: with the else clause being the 'ftp breakage is occuring code path'
User33: hrmm...we're not still talking about __init__.py here?
User3: never were
User3: lockdir.py
User33: oh sorry
User33: i missed that bit
User33: we were messing with __init__.py at first
User33: a while ago
User33: User3 in the _attempt_lock function i presume?
User3: User33 unlock()
User3: User33 locking works fine, its unlocking that is failing
User3: lock appears to fail because the unlock isn't working
User33: ok, got it
User33: User3 http://pastebin.ca/1533028
User33: does that look right to you?
User34: hi glyph, are you about?
User25: User34 what's up?
User34: glyph, something boring I am afraid..it's about python
User34: I understand you are the founder.. can I pm you?
User34: I mean #python
User3: User33 you have some tabs
User3: just use spaces (python limitation)
User3: the except needs to be
User3: except LockBroken:
User3: pass
User3: else:
User3: print "ftp breakage"
User33: ok
User33: got it
User33: thanks. i can read python, but no more really :)
User33: User3 http://pastebin.ca/1533033
User33: ftp breakage indeed
User3: right, we're detecting it
User3: I'd add that patch to the bug
User33: :)
User3: its also now at the point you might be able to show your FTP server admins
User3: we can continue hunting for a work around
User3: perhaps a while loop
User33: ok sure
User33: hmm, so what exactly is the FTP server doing wrong?
User3: its not renaming the directory.
User3: but its not erroring either
User33: (this is IIS6 btw, so i'm not sure how much they could do, short of changing the server software)
User33: hmm
User33: due to the fact the OS is locking it, you think?
User3: something :P
User33: heh
User33: shall we test this manually perhaps?
User33: (is there any way to do so?)
User3: with an ftp client perhaps
User33: yep, i have filezilla or windows explorer at hand
User3: doing the same operations by hand
User33: User3 so just renaming the /branch/lock/held dir to something arbitrary?
User3: yes, with a file in that dir called info, and with the sort of text we put in our info files
User33: ok
User33: Status:	Renaming '/httpdocs/repos/texdotnet/.bzr/repository/lock/held' to '/httpdocs/repos/texdotnet/.bzr/repository/lock/held-temp'
User33: Command:	RNFR held
User33: Response:	350 File exists, ready for destination name
User33: Command:	RNTO held-temp
User33: Response:	250 RNTO command successful
User33: User3 no problems there :S
User3: User33 you don't know that
User3: does held still exit
User3: *exist*
User3: I suspect you need the whole set of operations to trigger it
User33: hrmm i see
User3: if simply renaming was broken all the time, it would never be able to work
User33: but if i'll really need to tell my ftp server admin the entier set of steps...
User33: if they're to reproduce it
User3: 'bzr init' :)
User3: with your build
User33: User3 i tested this on the repo i just pushed btw
User33: lol
User3: if you run with -Dtransport
User3: then you can see the FTP commands
User33: i'm not sure i'm paying them enough for that :)
User33: ok
User3: and make a script to match
User3: we could also automate that using bzrlib
User33: ok, sounds like a plan
User33: User3 http://pastebin.ca/1533056
User33: User3 anything interesting in there?
User3: User33 if thats the commands bzr is doing, not for me
User3: we know whats going on - bzr is doing a rename, server is saying it has but not doing it
User33: yeah
User3: there are two main things to do:
User3: - get the server environment fixed, now that we have bzr able to report on it being broken
User3: - get an optional flag to make bzr retry the rename some number of times, which you can use to workaround the problem
User33: right, so if i wrap the rename command in a loop with a 1 second delay, then test that...?
User3: for instance, yes
User33: User3 say i loop 10 times, and exit the loop when self.confirm succeeds, will that be the right thing to try?
User3: sure
User3: for pos in range(10):
User3: rename
User3: try:
User3: self.confirm
User3: except LockBroken:
User3: break
User3: else:
User3: print "ftp breakage"
User33: heh, cheers :)
User3: hmm, indent the print more
User33: yep, noticed
User33: ho hum
 * Noldorin crosses fingers..
User33: hrmm
User33: ftp breakage
User33: bzr: ERROR: Parent directory of ftp://elizabeth73@example.org/texdotnet doe
User33: s not exist.
User33: User3 strangeness..
User3: heh
User22: User3 do you know if poolie is back around?
User33: now i'm baffled...
User3: User22 I don't, sorry.
User3: User22 hugh got in last night, so if poolie left on the same day he should be around today
User33: User3 http://pastebin.ca/1533085 - sorry for more code review, but can you spot any issue there?
User33: or perhaps explain the error otherwise?
User3: that looks accurate
User3: I have to assueme that other error is either a) unrelated or b) part of the same server environment issue ;)
User33: yeah, that was my conclusion
User33: (well, there really isn't any other)
User22: User3 k. poolie and I usually have a weekly call ~ now, and I was just wondering if he was going to show up this week
User33: User3 brb 20 mins. let me know if the reason strikes you :)
User3: User22 You can ring me if you need to talk to someone ;)
User22: User3 thanks.
User22: No specific need
User22: just trying to keep in a weekly habit
User3: I have 2a default w/no test failures
User22: \o/
User33: User3 otherwise, i'm just going to have to send my build over to my web host admin and hope they bother checking into it :P
User3: User33 try pushing again
User3: does this new error repeat?
User33: yes
User3: if so, pastebin a -Dtranspot trace of it
User33: User3 http://pastebin.ca/1533089
User33: interesting. it seems like the unlock is succeeding now (?)
User33: brb
User3: looks like
User3: rename
User3: check
User3: rename again
User3: then a traceback
User3: can you run with BZR_PDB=1
User22: User3 I'm probably going offline now. If you see poolie he can call my house or cell
User3: User22 ok. gnight
User13: ImportError: cannot import name weave
User13: ?!?
User13: nm
User13: it was probably my update updating bzr while I was pulling :)
User3: User13 yes
User13: is there a bzrtools that works with bzr.dev?
User33: back
User33: User3 no luck still
User33: :S
User3: try http://pastebin.ca/1533125
User33: will do
User7: morning
User33: bzr: ERROR: At ftp://elizabeth73@example.org/texdotnet you have a valid .bz
User33: r control directory, but not a branch or repository. This is an unsupported conf
User33: iguration. Please move the target directory out of the way and try again.
User33: User3 isn't that lovely?
User3: User33 did you delete the texdotnet dir first?
User3: and check it was actually gone ?
User33: yeah
User3: !
User33: hrmm
User33: works now
User33: well i say works but...
User33: back to thsi again:
User33: ftp breakage
User33: bzr: ERROR: Parent directory of ftp://elizabeth73@example.org/texdotnet doe
User33: s not exist.
User33: no "past unlock step"
User3: ok, some exception is being raised
User33: mm
User3: http://pastebin.ca/1533138
User33: heh, i like this way of resolving bugs :)
User33: it's tedious, though methodical at least
User3: User6 hi
User33: ftp breakage
User33: fail:  No such file: '/texdotnet/.bzr/branch-lock/held': : unable to rename to '
User33: /texdotnet/.bzr/branch-lock/releasing.1db1o9w8i4g6wxax077u.tmp': 550 /texdotnet/
User33: .bzr/branch-lock/held: The system cannot find the file specified.
User33: bzr: ERROR: Parent directory of ftp://elizabeth73@example.org/texdotnet doe
User33: s not exist.
User3: User33 fun!
User3: so we rename
User33: yep
User3: but the rename hasn't taken effect (because we read back)
User3: then, when we try to rename again, its been moved
User6: hey lifeless
User33: yep
User3: User6 the .so
User33: makes sense
User3: User6 the .so's in the wrong place, what corrects that for the debs - or did you manually work around?
User6: sorry, I think I'm lacking context
User6: the bzr pyrex speedups?
User33: User3 anything further to test?
User3: User6 yeah, on karmic setup.py puts them in bzrlib/bzrlib/*.so
User3: there was a bug filed on the nightly debs
User6: I missed the bug
User3: And I thought you closed that; we still have a bug in the core about it too (the deb bug being that the dailies should fail to build if the .so's are not there)
bzr
Ubuntu IRC