[02:15] <magcius> Is there any way to undo a commit?
[02:19] <lifeless> bzr uncommit
[02:40] <magcius> lifeless: thanks
[02:55] <magcius> uh
[02:55] <magcius> 1) are there any loggerhead maintainers in here? (or should I ask in #lp or #lp-dev)
[02:56] <magcius> I filed about 2-3 bugs and they're still filed "NEW"
[02:56] <lifeless> loggerhead is a little light on maintainers at the moment
[02:56] <magcius> ok
[02:56] <lifeless> here is as good as any place
[02:56] <magcius> uh, I also filed a bug on LP and a bug on bzr.
[02:57] <lifeless> how long ago ?
[02:57] <magcius> uh
[02:58] <magcius> lifeless: April
[02:58] <lifeless> and they're still new ? thats unusual
[02:58] <lifeless> url?
[02:58] <magcius> lifeless: er whoops, thought it was new
[02:59] <magcius> lifeless: er, the bzr one has had progress
[02:59] <magcius> lifeless: the LP one I believe is "New"
[02:59] <lifeless> do you know the number?
[02:59] <magcius> lifeless: er, it's Triaged. There's been a tag, but that's it
[02:59] <lifeless> there are lots of lp bugs :)
[02:59] <magcius> https://bugs.launchpad.net/launchpad-registry/+bug/569356
[03:00] <magcius> This one seems a very, very easy one to fix
[03:00] <magcius> But yeah, the two Loggerhead ones are the ones that I hate the most
[03:03] <lifeless> I wish loggerhead had more devs
[03:03] <lifeless> :)
[03:22] <thumper> lifeless: me too
[03:23] <lifeless> thumper: do you have any ideas about where we can find them?
[03:24] <lifeless> thumper: could lp-code start owning it again, perhaps?
[03:24] <thumper> lifeless: while I'd love to, we don't have any development time to invest
[03:24] <thumper> lifeless: we're already letting things slip
[03:28] <lifeless> thumper: is that because your team size changed, or your accepted too much work, or something else?
[03:29] <thumper> lifeless: primarily team size
[03:29] <lifeless> sounds like something that should, in principle, be fixed.
[03:29] <lifeless> eventually.
[03:32] <thumper> maybe
[03:33] <thumper> parly it requires someone who cares about the project
[03:33] <lifeless> definitely
[03:33] <lifeless> I guess I see the lp-code team as that in the sense that its deployed  in LP :)
[03:33] <lifeless> maybe thats not enough.
[03:34] <thumper> no it is not enough
[03:34] <thumper> we don't really use loggerhead
[03:35] <thumper> sure, we have it deployed on LP
[03:35] <thumper> but I really don't use it that often
[05:11] <willmarshall> Git user's question about BZR: I want to branch my current branch, then commit that new branch back to my server while I work on an experimental feature
[05:11] <willmarshall> How would I do this?
[05:14] <lifeless> bzr branch . ../new; cd new; bzr push $server_url
[05:14] <lifeless> or just bzr push $server_url, and then keep working
[05:14] <lifeless> if you want to let trunk move on for a while, you might instead do
[05:14] <lifeless> bzr branch . ../new; $work_in_new_for_a_while
[05:15] <lifeless> bzr merge ../new; bzr commit -m "merge in some progress"; bzr push
[05:16] <willmarshall> That worked! Thanks :)
[05:16] <lifeless> anytime
[05:28] <lifeless> jelmer: ping
[06:32] <BlindWolf8> Hello?
[06:34] <lifeless> hi
[06:46] <BlindWolf8> Hey lifeless
[06:47] <BlindWolf8> I wasn't paying attention to the chat. You still here?
[06:47] <lifeless> passing through from time to time
[06:47] <lifeless> its roughly dinnertime here
[06:48] <BlindWolf8> Gothca. About 1:45 AM here (US EST/EDT)
[06:48] <BlindWolf8> I do have a quick question for you if you have a moment.
[06:48] <lifeless> sure; in general just ask your questions
[06:49] <lifeless> in this medium, someone will usually answer eventually
[06:49] <BlindWolf8> Would I easily be able to change my repository style once it's made?
[06:49] <lifeless> what do you mean by style ?
[06:50] <BlindWolf8> feature branch, colocated, shared repo, etc.
[06:50] <lifeless> sure
[06:51] <lifeless> the only thing that isn't easy to change is the /format/ - which you shouldn't need to be concerned with at this point
[06:51] <BlindWolf8> If I need to, I'm confused on how to do this as...
[06:51] <lifeless> so just go ahead and play
[06:51] <BlindWolf8> 1) I forgot what I chose when setting it up...
[06:51] <BlindWolf8> ...and 2) not files are listed on the seerver. I am not sure if this is normal.
[06:51] <lifeless> bzr branches and repositories store their files in .bzr/
[06:51] <BlindWolf8> *no files
[06:52] <BlindWolf8> yeah, I looked in the .bzr folder on the server
[06:52] <lifeless> its a form of database. So your source code is only present on your workstation
[06:52] <lifeless> this is normal
[06:52] <BlindWolf8> no files are readable...I'm assuming they're all compressed/packed
[06:52] <BlindWolf8> ah, OK.
[06:52] <BlindWolf8> what would I do in a case in which I wanted the files to be accessible?
[06:53] <lifeless> well it depends on why
[06:53] <lifeless> for instance
[06:53] <lifeless> if you want to deploy to a web server; use the bzr-upload plugin
[06:53] <lifeless> if you want to browse the files and history with a web browser, use loggerhead
[06:53] <BlindWolf8> ah, I'm assuming that would update the bzr db and upload the file as well?
[06:54] <lifeless> bzr-upload works without the .bzr database
[06:54] <lifeless> for security
[06:54] <lifeless> it uses a very small record of whats been uploaded so that it can only upload changed files
[06:54] <BlindWolf8> right, but where would it keep revisions?
[06:55] <lifeless> bzr-upload ? it has them on your source branch, wherever that is - normally your workstation.
[06:55] <BlindWolf8> ah, OK, so it won't make a .bzr dir on the server for security reasosn, only locally...OK, that makes sense
[06:56] <lifeless> collaborating on your source code, and deploying it to a webserver are very different tasks
[06:56] <BlindWolf8> agreed
[06:56] <lifeless> does this help? I realise I haven't answered the direct question :)
[06:57] <BlindWolf8> yeah, it helps...I was just shocked as I didn't see any files on the server...just a bit concerned about things being compressed
[06:58] <BlindWolf8> figured that I would need to do something different for webdev, but the doc explains it about 80%...I may have missed something
[06:58] <lifeless> if you ssh into your server
[06:58] <lifeless> and run 'bzr log -p' you'll see all your patches going back to the start of your history
[06:58] <lifeless> (run that in a branch on the server)
[06:58] <BlindWolf8> Also, I'm assuming that all revisions are copied to clients as well?
[06:59] <BlindWolf8> in their .bzr dirs?
[06:59] <lifeless> when you do 'bzr branch server localdir' , it copies all the history by default
[06:59] <BlindWolf8> My main concern was that if the server got hacked/fubared, I'd be SOL
[06:59] <lifeless> there are options that you can pass to copy less than everything (--stacked, specifically) - but its not the default.
[06:59] <BlindWolf8> I do Pull via the GUI, so I'm assuming it gets all the revs
[07:00] <lifeless> yes
[07:00] <BlindWolf8> Good, everyone's up to date and can do a restore if needed
[07:00] <lifeless> (unless you made the branch stacked - but I don't think bzr explorer has an option to do that)
[07:00] <BlindWolf8> and the restore will rebuild all the revisions...sweet
[07:00] <BlindWolf8> so Bazaar == RAID, lol
[07:01] <fullermd> RAIR.  Blood RAIR.
[07:01]  * fullermd licks his lips.
[07:01] <BlindWolf8> 0_\
[07:02] <BlindWolf8> Anyway, thanks again lifeless
[07:02] <BlindWolf8> I'd be happy to write some docs/tutorials
[07:04] <BlindWolf8> Still here?
[07:09] <lifeless> yes
[07:10] <BlindWolf8> OK. When I was having my teammate setup bzr, I had him pull our branch from the repo I setup.
[07:10] <BlindWolf8> bzr prompted him to turn the dir he was putting the files into a repo. I told him to select No, as there seems to be issues with doing that.
[07:11] <BlindWolf8> Why would you want to turn the local dir into a shared repo?
[07:14] <BlindWolf8> Whoops, back.
[07:15] <vila> hi all !
[07:15] <BlindWolf8> hey vila
[07:16] <lifeless> BlindWolf8: 'shared' in shared repo refers to 'between branches' not 'between users'
[07:16] <lifeless> BlindWolf8: so you want that to make switching between branches fast and efficient
[07:16] <vila> BlindWolf8: The repo is where revisions are stored. Once you start having multiple branche of the same project, using a shared repo means all common revisions are stored only once
[07:17] <BlindWolf8> in a common .bzr dir?
[07:17] <vila> BlindWolf8: yes
[07:17] <lifeless> one .bzr dir for the history, one .bzr per branch, but without history
[07:18] <lifeless> the branch ones get their history from the repository .bzr dir
[07:18] <BlindWolf8> then what does each .bzr dir store for each branch?
[07:19] <lifeless> the branch configuration, the revision id of the branch's most recent commit and the tags for the branch
[07:21] <BlindWolf8> Before, you mentioned that if I wanted to do webdev, it wouldn't upload the revsision history. What if I wanted to regardless?
[07:22] <BlindWolf8> vila: you've been credited, btw.
[07:23] <vila> BlindWolf8: Me ? Credited ? Argh, what did I do wrong again ? :)
[07:23] <BlindWolf8> lol
[07:24] <vila> BlindWolf8: bzr-upload aim is to maintain a remote working tree *without* its history, if you want to update a remote working tree whenever its history change, you want the bzr-push-and-update plugin (which requires bzr on the server and an ssh access IIRC)
[07:25] <vila> the two plugins work from a different set of constraints and address different needs
[07:26] <BlindWolf8> Thanks for that info. All of this is very helpful.
[07:30] <BlindWolf8> By the way, why would someone want a checkout when they can just bind a branch?
[07:32] <vila> BlindWolf8: Don't summon fullermd ....
[07:32] <vila> BlindWolf8: a checkout *can* be configured to use a branch on a remote server without any history stored locally
[07:33] <fullermd> Who dares invoke the Great and Powerful fullermd??
[07:36] <vila> fullermd: someone wanting clarifications about checkouts and bound branches :-P
[07:36] <BlindWolf8> :-P
[07:42] <fullermd> First, you must pass the Seven Trials of Courage.
[07:42] <BlindWolf8> Hey Matt, we're going to incur your wrath
[07:43] <BlindWolf8> so anyways....
[07:44] <BlindWolf8> binding a branch to a dir makes bzr more like Perforce, which is the first VCS/SCM I used
[07:48] <BlindWolf8> As far as I know, I've got this: http://wiki.bazaar.canonical.com/StandaloneTree
[07:49] <BlindWolf8> on the server, anyways
[07:49] <BlindWolf8> the clients/workers have the same thing, but they have a full revision history (Heavyweight Checkout)
[07:50] <BlindWolf8> the files are also viewable/changable on their machines, and not sotred in the .bzr dir
[07:50] <BlindWolf8> (not sure what to call that...Working Tree?)
[07:51] <vila> yes, see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
[07:53] <BlindWolf8> Thanks! If you guys need helps in organizing docs or making things clearer, I have a knack for that
[07:55] <vila> BlindWolf8: help is always welcome, have a look at https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc, or clarify anything you didn't understand in the actual docs :)
[07:57] <BlindWolf8> You guys rock! :-D
[08:03] <lifeless> vila: https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27473
[08:04] <vila> lifeless: Updating diff... :-)
[08:05] <lifeless> vila: pull it :)
[08:09] <lifeless> vila: I'm going to cook dinner
[08:09] <lifeless> vila: but I'd *love* to get this landed
[08:09] <lifeless> vila: so if you can pp it for me, that would be most awesome
[08:09] <lifeless> I'll pop back in a bit
[08:09] <vila> lifeless: enjoy your cooking and don't worry, I *need* this patch
[08:10] <vila> lifeless: (I even thought it has already landed :)
[08:10] <BlindWolf8> I'm out. Thanks again you guys!
[08:57] <vila> lifeless: 4 tests erroring out, see mp
[08:58] <lifeless> thank you
[08:59] <lifeless> vila: that will be shallow
[08:59] <vila> lifeless: certainly
[08:59] <vila> well, hopefully :)
[08:59] <saxicek> hello everybody
[09:00] <lifeless> vila: they work for me
[09:00] <lifeless> vila: disable your non-core plugins
[09:01] <vila> lifeless: already done, I've kept only loom...
[09:01] <lifeless> :!bzr selftest --no-plugins bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_tags_streaming_acceptance test_switch_lightweight_directory bzrlib.tests.blackbox.test_tags.TestTagging.test_branch_push_pull_merge_copies_tags bzrlib.tes
[09:01] <lifeless> ts.blackbox.test_tags.TestTagging.test_list_tags
[09:01] <lifeless> bzr selftest: /home/robertc/source/baz/bzr-test-fixes/bzr
[09:01] <lifeless>    /home/robertc/source/baz/bzr-test-fixes/bzrlib
[09:01] <lifeless>    bzr-2.2.0dev1 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid
[09:01] <lifeless> ----------------------------------------------------------------------
[09:01] <lifeless> Ran 4 tests in 1.207s
[09:01] <lifeless> OK
[09:01] <vila> !paste
[09:03] <vila> http://paste.ubuntu.com/449550/
[09:04] <lool> vila: Heya
[09:04] <lool> vila: With whom should I discuss performance of the gcc-linaro branches?
[09:05] <vila> lifeless: and even without loom:  running 5(?) tests, failed 3 :-/
[09:05] <vila> lool: here should be fine, filing a bug report tagged udd, about the slow checkouts will be even better
[09:06] <vila> lool: not finished replying to your emails, but you can try --hardlink too for branch and checkout
[09:06] <lool> vila: Would you think it's something fixable, or will we always suffer from the size of history + size of the tree?
[09:07] <lool> vila: In my experience, the CPU was maxed for long periods of time during the lenghty operations, not I/O
[09:07] <vila> lool: I suspect it's more a tree size bug than an history size one
[09:07] <lool> (I'm on SSD BTW)
[09:07] <saxicek> Can you guys please help me with setting custom merge app in bazaar explorer? I tried "d:/Program Files/Beyond Compare 3/BComp.exe" %r %b %t %o but I am getting "Error while running merge tool (code 0)" but did not see what it is actually trying to run in the log
[09:07] <vila> I got worse performances for massive IO on SSD than on 7200rpm HDs
[09:08] <vila> lool: ^
[09:08] <lool> vila: BTW what is the udd tag for?  Does it cover code imports or is it just for package imports?  Cause here it's a code import branch, not a package import one
[09:08] <vila> lool: it's for Ubuntu Distributed Dev
[09:08] <lool> vila: Ok; I have a relatively unreliable I/O indicator in my panel which showed modest amount of I/O, and CPU maxed out, so I didn't blame it on I/O but it's not 100% out of the picture I guess
[09:09] <vila> lool: if you use the stock performance monitor, setting Red as the color for IOWait instead of the default black will show you some interesting side-effects
[09:11] <lool> vila: Yes, one CPU ws 100% busy with both IO wait and actual work
[09:13] <vila> lool: try on a regular disk or use a better SSD ;-) The CPU@100% needs to be investigated, filing a bug is the best way to ensure it's not forgotten
[09:14] <lifeless> vila: lets let pqm decide ;)
[09:15] <vila> lifeless: AttributeError: 'GenericInterBranch' object has no attribute 'tags' looks unambiguous to me
[09:17] <jelmer> lifeless: pong
[09:21] <lool> vila: bug #593560
[09:21] <vila> lifeless: plus you should be running 5 tests not 4, the 5th one is bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags_revision_filtering caught by bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags, are you sure !bzr use the right bzr ?
[09:24] <vila> lool: first comment, I didn't noticed it earlier but using *different* projects for gcc-linaro and gcc, defeats the stacking scheme defined on lp, you'd better use the 'gcc' project itself
[09:25] <lool> vila: Does it matter for the project series branches, or for the actual branches or both?
[09:25] <lifeless> vila: when only two people are speaking pastebin is a nuisance :P
[09:26] <lool> vila: I mean, I can have gcc-linaro/4.4 point at ~gcc-linaro-dev/gcc/linaro-4.4 or something like that
[09:26] <lifeless> vila: did you pull my branch, or merge it ?
[09:26] <vila> lifeless: pull
[09:26] <lifeless> vila: aah, yes, ./bzr :P
[09:26] <lifeless> ok will fix
[09:27] <vila> lool: one stacked-on branch is defined by project on lp AFAIR
[09:27] <vila> lool: it's called the devlopment focus on lp I think
[09:29] <lool> vila: How would I setup my branches to tell LP that they are stacked on multiple branches of the gcc project
[09:29] <lifeless> jelmer: it was InterBranch.pull I was pinging about
[09:29] <lifeless> jelmer: its rather odd in trunk
[09:29] <lool> vila: IOW that ~gcc-linaro-dev/gcc/linaro-4.4 is stacked on lp:gcc/4.4 and same for 4.5
[09:29] <lifeless> lool: you wouldn't, why do you want to do that ?
[09:29] <lool> vila: the gcc development focus is the trunk vcs-import
[09:30] <lool> lifeless: Well, gcc development results in yearly releases with relatively lots of changes in 4.4 and 4.5 branches, we're mostly going to work on 4.4 and 4.5 branches as a baseline, maintaining forks basically
[09:30] <vila> lool: I don't think you want to do that on lp (nor that you can), either you define branches in the gcc project or you define a development focus in gcc-linaro (the former sounds better to me)
[09:30] <lool> the gcc focus of development correctly points at trunk which is always where most development is going on
[09:30] <lifeless> lool: sure, but you can have all the history in lp:gcc, so that stacking is always efficient
[09:31] <lool> vila: Oh I did define a development focus on gcc-linaro
[09:31] <lool> vila: I had to chose a branch, so I picked the 4.4 one
[09:31] <lool> lifeless: You don't have history of the 4.4.x and 4.5.x commits surely?
[09:31] <vila> lool: wrong :) Then your push for 4.5 needs to carry all the missing revisions
[09:32] <lool> lifeless: They are backports at the patch / SVN level upstream, but from bzr pov, they are entirely separate branches
[09:32] <vila> lool: no, all the imports are from the same master svn repo, the revisions are shared
[09:32] <lifeless> lool: nevertheless, we can, with cron, get all the content into one branch.
[09:32] <lool> vila: It's true, but 4.4 and 4.5 will differ significantly, and most of the work will happen in 4.4 right now; if I setup 4.5 as dev focus, I will miss the 4.4 revs when pushing 4.4 based branches
[09:33] <lifeless> lool: its 3 lines of python and a pear tree
[09:33] <lool> lifeless: awesome, that sounds like something we would want
[09:33] <lifeless> lool: stacking is an approximate thing, don't aim for perfection.
[09:33] <lifeless> lool: 1 years dev on a 25 year old tree is peanuts
[09:33] <lifeless> you'll have many more issues that aren't related to how much is/isn't shared in stacking.
[09:33] <lifeless> we're working on that at the moment.
[09:35] <lifeless> vila: fixed
[09:35] <lifeless> vila: missing .source
[09:35] <lool> lifeless: So how would I ask for this cron to be setup, or are you saying that it's probably not going to gain much?
[09:36] <lool> vila: I've changed development focus to gcc-linaro/4.5 now
[09:37] <lifeless> lool: r1 = bzrlib.repository.Repository.open('lp:gcc-linaro/devfocus'); r2=bzrlib.repository.Repository.open('lp:gcc-linaro/4.4'); r1.fetch(r2)
[09:37] <lifeless> lool: repeat as needed
[09:37] <lifeless> you need to import bzrlib.repository
[09:37] <lifeless> and bzrlib.plugin
[09:37] <lifeless> and do bzrlib.plugin.load_plugins()
[09:38] <lool> cute
[09:38] <lifeless> separated concerns ftw
[09:39] <vila> lool: yup, lifeless proposal is the best solution for your case, this way you can load your devfocus branch with whatever you want and pushes will benefit
[09:39] <lool> vila: So you were arguing earlier that we should use the gcc project for this stuff instead of the gcc-linaro one, is this still useful if we push revisions like above?
[09:39] <vila> lool: and you won't have to think about which of trunk, 4.4 or 4.5 is the best starting point
[09:39] <lifeless> lool: it woud model it more accurately in launchpad
[09:40] <lool> vila: I should probably load the devfocus branch of gcc-linaro with the gcc/trunk /4.4 and /4.5 revs too, shouldn't I?
[09:40] <lifeless> lool: but really, do what makes sense to you
[09:40] <vila> lool: no, doesn't matter anymore
[09:40] <vila> lool: if you start with trunk, the later ones should be almost covered
[09:41] <lool> vila: So the trunk vcs-import contains all the 4.4 and 4.5 revisions because it's the way bzr svn operates?
[09:42] <vila> lool: I don't thin kit's related to svn or vcs-import but most of the history of these branches is the same one
[09:43] <vila> lifeless: still one failure if I use the loom plugin: ERROR: blackbox.test_switch.TestSwitch.test_switch_lightweight_directory -> TypeError: run() got an unexpected keyword argument 'directory' most probably on loom itself ;)
[09:45] <lifeless> vila: yes, trunk breakage with decorated command
[09:45] <lifeless> vila: please review, its nearly bedtime
[09:45] <lifeless> vila: my problem to have tests passing
[09:45] <lifeless> vila: also, a suggestion for lool's bug: ask for data, always ask for data ;)
[09:47] <vila> lifeless: .bzr.log ? I was typing an additional comment ;)
[09:48] <lifeless> calgrind
[09:48] <lifeless> logs are nice
[09:48] <lifeless> callgrind is heaven
[09:48] <vila> lifeless: tests pass without the loom plugin, review time
[09:49] <lifeless> vila: a meta comment for you: I think your priorities are the wrong way around there; its up to the submitter and PQM to care about tests.
[09:50] <lifeless> vila: better to review, and *then* note that its got issues, than to put the review back - it breaks the flow up more.
[09:51] <vila> lifeless: sure, especially when the submitter run the full test suite before submitting ;-)
[09:52] <lool> lifeless: I have flexibility on the naming of the real branches; I chose to create a gcc-linaro project to host tarballs in the future, then it seemed logical to have gcc-linaro/xxx branches
[09:53] <lifeless> lool: I think lp would traditionally model that as gcc/linaro-4.5 as the series, which can host tarballs just fine.
[09:54] <lool> IIUC, the fact I pushed the "series" branches to /gcc-linaro namespace means they were not stacked on gcc and I payed a price for that, however because I've set the focus of dev to one of these branches, people pushing to gcc-linaro branches wont pay much
[09:54] <lifeless> lool: OTOH if you want to be able to say on a bug, 'fixed in linaro gcc 4.5, still open in fsf gcc 4.5' then you must have a separate project at the moment.
[09:54] <lool> lifeless: Don't I need ownership of the gcc project for that?
[09:54] <lifeless> lool: no
[09:54] <lifeless> lool: anyone can create series, or at least they are meant to be able to.
[09:54] <lool> Yes, we want to track the bugs separately
[09:55] <lool> the fsf bugs are not tracked in Launchpad though
[09:55] <lool> Well they are tracked by Launchpad as remote bugs in upstream bugzilla
[09:55] <lifeless> right
[10:10] <vila> lifeless: Why can you remove InterToBranch5 now ? Did something change or was it an error to introduce it at the time ?
[10:10] <lool> vila, lifeless: Hmm one thing I'm thinking could impact performance very badly is ecryptfs
[10:11] <lool> I'm using ecryptfs on my whole $HOME; it caused issues in the past with things such as sparse files, but performance was overall comparable to before using that in my experience
[10:12] <lool> I should try on another system
[10:15] <vila> lifeless: ha, bug #593515, but why didn't your mp reference that ??
[10:16] <vila> lifeless: approved
[10:20] <lifeless> vila: thanks
[10:20] <lifeless> lool: just get callgrind stats
[10:20] <lifeless> they should show up stat() if stat time is relevant
[10:21] <lifeless> or sha1time, if ecryptfs breaks stat fingerprinting
[10:25] <lifeless> vila: you haven't set merge:approve ;)
[10:27] <vila> lifeless: pff, patch pilot noob...
[10:31] <lifeless> vila: no worries, I shall train you :)
[10:32] <vila> hehe, cool
[11:38] <lool> lifeless: I ran an "enrich-gcc-linaro-repo" script, took 6mn41s on the first run and 18s on the second run, seems to have done some useful stuff on the first run, so was definitely a good idea, thanks
[11:39] <lool> Will cron it now
[11:43] <lool> Hmm I should create a separate account with a separate bzr key
[11:49] <lool> I wonder how to tell bzr to use a separate launchpad login + ssh key for a single run
[11:56] <lool> Overriding BZR_HOME is fine, but ssh won't use $HOME, and I can't find a way to pass random args to ssh from bzr
[11:56] <lifeless> ln -s .ssh somewhere ?
[12:00] <lifeless> lool: ssh can handle multiple ssh keys to offer, you know :)
[12:00] <lifeless> lool: just have the right one on your keyright/passwordless/whatever
[12:32] <lool> lifeless: Hmm right, I can just offer the key all the time
[12:33] <lool> problem is user name actually, not key
[12:33] <lool> it's the unix user I should be using
[13:15] <rumbert> Is there GUI(s) which let you browse repositories without branching/checking out? (not counting HTTP/WWWeb)
[14:13] <lamont> bzr branch bzr+ssh://example.com/
[14:13] <lamont> bzr: ERROR: gnomekeyring.IOError:
[14:13] <lamont> W.T.F...
[19:27] <servilio> hi! can someone please point me out to a documentation on BranchReference's?
[21:16] <TresEquis> jelmer: anything I can do to help with lp:480102?
[21:16] <TresEquis> I saw you had marked it 'inprogress' over the weekend
[21:19] <jelmer> bug 480102?
[21:20] <jelmer> TresEquis: one thing that would really help is a trivial python script that reproduced the issue so we can put that into the bzr-svn testsauite
[21:31] <TresEquis> jelmer: ugh, I really don't understand how to provoke the error in a nice testcase-ish way
[21:32] <jelmer> TresEquis: well, any help reproducing that error in the simplest way possible would be appreciated
[21:33] <TresEquis> I know that it appeared to be true that the "blob loader ID" for the failing file in the failing revision was somehow pointing to the older revision
[21:33] <TresEquis> so that when the patch was applied, the resulting file didn't match the checksum for the current transaction
[21:35] <TresEquis> I just don't know the mechanics well enough to guess how that might occur
[21:36] <jelmer> right
[21:36] <jelmer> so I know it has something to do with merges
[21:49] <TresEquis> I don't know if it is significant, but there is a 'bzr:ancestry:v4' property which shows up in the tree at the point of the apparently-successful merge
[21:49] <TresEquis> the one after which the later transaction touching the same files blows up
[21:50] <TresEquis> also, svn:mergeinfo shows up at that point
[22:02] <jam> mkanat: I pushed a possible fix for bug 586122 for you
[22:02] <jam> Can you test it out and let me know?
[22:02] <mkanat> jam: Awesome! Yes, I will check it out.
[22:02] <mkanat> jam: It might be a bit later today; the Bugzilla freeze is tomorrow, so I'm a little busy.
[22:03] <jam> mkanat: No rush on my part, everything works here :)
[22:03] <mkanat> jam: Okay. :-)
[22:32] <lifeless> hi jam
[22:33] <jam> hi lifeless
[22:34] <assad> i did a merge, but i am getting : 6 conflicts encountered. at the end
[22:34] <assad> is the merge done?
[22:35] <TresEquis> assad: you need to fix the conficts, 'bzr resolve' them, and commit
[22:35] <TresEquis> assad: you need to fix the conficts, 'bzr resolve' them, and commit
[22:39] <jam> lifeless: somehow you managed to gather more resources than me, even though I'm fully capped (on all resources right now).
[22:39] <jam> I guess you managed to upgrade something faster than me? (and thus spend more resources?)
[22:39] <jam> anyway, you now outrank me in bym
[22:40] <assad> TresEquis, to fix the conflicts i have to copy the code from the "to be merged with" branch?
[22:42] <TresEquis> assad:  it's a judgement call
[22:42] <TresEquis> you have to figure out what the right course is for each case where there are conflict markers
[22:43] <TresEquis> and then riun all your tests to be sure you didn't blow it
[22:43] <TresEquis> resolving conflicts in the test code is for extra bonus points
[22:43] <lifeless> jam: I don't know - how do I tell that?
[22:44] <jam> lifeless: on the bottom, your toon comes before mine, indicating you outrank me
[22:44] <lifeless> jam: I have 3/6 lvl 10 goos; and been having a back n forth war with some naively defended person who attacks me and gets 3/4 twigs max
[22:44] <lifeless> then I go wipe their entire base out ;P
[22:44] <TresEquis> lifeless: you in Kiwiland now?
[22:44] <lifeless> TresEquis: Yup
[22:44] <jam> lifeless: hmm, maybe it is the extra twigs
[22:45] <jam> I've got 6 lvl 10 goos, and a couple other lvl 10 items
[22:45] <jam> but I haven't been warring as much :)
[22:45] <lifeless> jam: it might be the fighting giving xp
[22:45] <jam> also, it takes 3x the build time before a resource repays itself
[22:45] <jam> (so a 3-day build time takes 9-days before it produces more)
[22:46] <jam> could be
[22:46] <jam> I've fought a little, but not a lot
[22:46] <mtaylor> mordred@camelot:~/src$ bzr whoami
[22:46] <mtaylor> bzr: ERROR: Connection closed:
[22:47] <TresEquis> lol
[22:47] <jam> mtaylor: I assume you are in a checkout?
[22:47] <mtaylor> jam: nope
[22:47] <mtaylor> just in a normal directory
[22:47] <lifeless> jam: TresEquis I'm in chch, if you're familiar with nz
[22:47] <jam> mtaylor: is $HOME a checkout?
[22:47] <mtaylor> jam: nope
[22:47] <lifeless> mtaylor: are you lying ?
[22:47] <jam> you could run with -Derror
[22:47] <mtaylor> lifeless: not to my knowledge
[22:48] <TresEquis> lifeless: not except from reading maps
[22:48] <lifeless> mtaylor: bzr info -v
[22:48] <mtaylor> lifeless: mordred@camelot:~/src$ bzr info -v
[22:48] <mtaylor> bzr: ERROR: Connection closed:
[22:50] <lifeless> file a bug - we need a way to help people debug this.
[22:50] <lifeless> secondly, look in .bzr/branch, ../.bzr/branch etc
[22:55] <mtaylor> lifeless: searched all the way up the tree - no .bzr dirs anywhere
[22:57] <lifeless> mtaylor: that is extremely odd
[22:57] <lifeless> mtaylor: strace bzr
[22:58] <mtaylor> lifeless: found it - there is an .svn dir
[22:58] <mtaylor> lifeless: which is causing bzr-svn to vomit
[22:58] <lifeless> mtaylor: oh right, of course
[22:58] <lifeless> mtaylor: so, the bug is 'connection errors don't signal why we were making them'
[22:58] <lifeless> or something
[23:02] <mtaylor> lifeless: ok.
[23:03] <lifeless> assuming that that is actually the entire output you've been pasting
[23:03] <mtaylor> lifeless: or also - bzr whoami should perhaps not need to connect to anything?
[23:03] <mtaylor> lifeless: yes
[23:03] <lifeless> whoami can be configured by the branch
[23:03] <lifeless> checkouts can reference an external branch
[23:03] <lifeless> so no, whoami was doing the right thing
[23:04] <lifeless> we could add a whoami --global or something
[23:04] <lifeless> but you'd still not be able to commit where you were ;P
[23:04] <mtaylor> lifeless: nah - I think you were right before - hinting at the bzr-svn cause would be the right thing here
[23:26] <mgz> lifeless: any objection to just backing out testtools r70 when the unicode traceback work is finished?
[23:27] <lifeless> mgz: why? it seems clearly less broken than it was
[23:27] <lifeless> mgz: I'd be happy to have something less broken than it wsa and is
[23:27] <mgz> well, because you're enhancing wrong code there
[23:28] <mgz> actually, I think it's worse than that
[23:31] <mgz> Python 3 does the right thing (the exceptions are always unicode), and Python 2 needs the input fixing, not a per-str()-call fixup
[23:32] <mgz> hardcoding UTF-8 there is the wrong place at any rate, needs to happen in subunit if you want it, otherwise you break the normal output with say, unittest
[23:33] <lifeless> so, subunit with multipart attachments already generates unicode exception objects
[23:33] <lifeless> r70 in testtools is to *handle* that
[23:33] <mgz> okay, I know it was to fix a current issue
[23:34] <mgz> but I'm interested in what needs to change when testtools is only creating _StringException objects with unicode args
[23:35] <lifeless> as long as we're using a fixed traceback module
[23:35] <lifeless> and a subunit with the patch to make unicode string exceptions for non-multipart attachments
[23:35] <lifeless> and the matching XXX fixed to encode in utf8 explicitly for non-multipart serialising
[23:35] <lifeless> then we shouldn't ever be calling __str__ on a StringException
[23:36] <mgz> okay, great, that's what I'm aiming for
[23:36] <lifeless> and if we're not calling __str__, then it shouldn't matter
[23:36] <lifeless> uhm
[23:36] <lifeless> actually, it will matter
[23:37] <lifeless> if someone with a different TestResult uses the standard traceback module.
[23:37] <mgz> right, this is the case I worry about
[23:37] <lifeless> they will run into precisely the same brokenness, unless __str__ *works*
[23:37] <mgz> I currently am testing testtools internals with the unittest runner
[23:37] <mgz> r70 will break those tests
[23:37] <lifeless> and this is the upstream Exception.__str__ bug in python2.x
[23:37] <lifeless> mgz: no, r70 will fix it.
[23:37] <mgz> no, this is er... the second pass
[23:38] <mgz> testtools is formatting the exception
[23:38] <lifeless> hmm, I've two uk people timesharing me
[23:38] <mgz> and unittest is stringifying the _StringException for the output
[23:38] <mgz> I'll retire, this can wait.
[23:38] <lifeless> which is broken. It should be unicodifying
[23:39] <mgz> right, but it's a broken case that comes up, bzr currently does the same I believe
[23:39] <lifeless> the question is, when someone asks for an insane thing, do we: break; encode to their default; encode to utf8; something else
[23:39] <mgz> yup.
[23:39] <poolie> hi there mgz, lifeless
[23:39] <mgz> hey poolie
[23:39] <lifeless> mgz: I'm happy to change it to 'use their console encoding' or something, once your patch lands and that is feasible.
[23:40] <mgz> so, looked at like that, it boils down to r70 picking "always utf-8" and my compat one doing "ascii and questionmarks"
[23:40] <lifeless> hi poolie
[23:40] <mgz> where the right thing will be to change it to use unicode till it actually hits the console/whatever other output method
[23:40] <lifeless> mgz: right
[23:40] <lifeless> mgz: back in 2 minutes
[23:44] <BitSprocket> How does one remove a folder from bazaar control?
[23:44] <lifeless> mgz: back
[23:46] <BitSprocket> How does one remove a folder from bazaar control?
[23:46] <poolie> BitSprocket, 'bzr rm --keep'
[23:46] <poolie> note that this will propagate to other checkouts as a deletion of that folder
[23:47] <BitSprocket> Thanks poolie.  It's a private project so no worries.  That won't delete any of my files right?
[23:47] <BitSprocket> Said differently, I want to keep the files, just remove version control.
[23:48] <poolie> that's what --keep does
[23:48] <BitSprocket> Sweet, thanks!
[23:48] <poolie> you might then want to do 'bzr ignore THING' to avoid it being re-added in future
[23:48] <poolie> np
[23:49] <BitSprocket> Does that apply to subdirectories/files as well?
[23:49] <BitSprocket> Or do I have to do them manually?
[23:50] <BitSprocket> ...looks like it took care of it recursively for me...
[23:56] <BitSprocket> Well, it doesn't look like it worked after all.  What am I missing?