[00:00] <sivang> just wanted to say thanks to bzr.
[00:00] <sivang> it enabled me to pull from qt.gitorious when git itself cannot.
[00:00] <lifeless> lol, nice
[00:01] <sivang> lifeless: :)
[00:01] <sivang> lifeless: ah, but how do I use the git plugin? in svn it works ootb
[00:02] <sivang> odd, I've done that already and forgot...
[00:04] <sivang> ahh stupid git
[00:04] <sivang> why can't everybody just use bzr...life would be so much simpler.
[00:13] <luke-jr> dunno, I kinda like git
[00:13] <luke-jr> but I use both
[00:16] <sivang> luke-jr: so it was me who was stupid
[00:16] <sivang> luke-jr: s/http/git/
[00:17] <sivang> luke-jr: can't expect every DRCS to do hg/bzr guggling of urls.
[00:17] <sivang> anyway, back to hacking
[00:19] <thumper> lifeless: do you know if there are any presentation on the bzr wiki that are up to date(ish) that I can base my talk on?
[00:25] <duckx_> Hello
[00:26] <poolie> hi duckx_
[00:26] <duckx_> I was wondering what was the current state of nested trees in bazaar
[00:26] <poolie> i'd recommend you use the bzr-externals or scmproj plugins
[00:26] <poolie> see the plugin guide
[00:27] <duckx_> Ok I will have a look, thx
[00:27] <duckx_> I played with bzr-loom this WE
[00:27] <duckx_> Nice plugin, very easy to use
[00:28] <duckx_> Well I tried to find out what could be the best Workflow to get debian python-modules in sync in ubuntu
[00:28] <duckx_> Using the debian repository ;)
[00:30] <duckx_> That is using svn with merge mode ...
[00:30] <duckx_> That fun,  make me play a lot with bzr
[00:33] <duckx_> Thx poolie
[00:33] <duckx_> I will see what I can do with bzr externals
[00:38] <igc> hi poolie
[00:38] <poolie> hi there
[00:51] <thumper> poolie, igc: I'm looking for a big bzr image for my presentation
[00:51] <thumper> know where to find one?
[00:51] <poolie> meaning a big screenshot?
[00:51] <thumper> igc: how are you feeling today?
[00:52] <thumper> poolie: just the bzr image for the slide master background
[00:52] <igc> hi thumper - I'm ok today thanks
[00:52] <poolie> the logo?
[00:52] <thumper> igc: up for a skype call?
[00:52] <thumper> poolie: yes
[00:52] <igc> thumper: sure
[00:53] <igc> thumper: let me fire up my laptop first
[00:53] <thumper> poolie: we should have links to the images somewhere of the front web page I reckon
[00:53] <thumper> s/of/off/
[00:53] <igc> thumper: http://wiki.bazaar.canonical.com/LogoOptions
[01:02] <igc> thumper: I have Skype up but it doesn't think you're online
[01:36] <duckx_> poolie, thx again
[01:37] <duckx_> the externals plugin was exactly was I was looking for !
[01:37]  * duckx_ : my  english is really crappy today
[01:47] <AfC> So, someone just asked me if there was a continuous integration server that integrates nicely with a DVCS (bzr, obviously)
[01:47] <AfC> I know lifeless was playing with Hudson recently, but I don't know whether that was Canonical internal, or a customer of theirs, or...
[01:55] <lifeless> we're using hudson at canonical
[01:55] <lifeless> for bzr (vila's test environment - I think he posted a url to it), for some dx stuff (internal builds - not public)
[01:55] <lifeless> drizzle use hudson, its where I was introduced to it
[02:02] <poolie> igc is bug 537387 something that was fixed in a later installer?
[02:02] <poolie> it looks familiar
[02:03] <igc> poolie: he's using the latest installer already
[02:03] <igc> poolie: it certainly includes the latest explorer
[02:04] <igc> poolie: maybe the problem is fixed in 2.1.1 or a more recent bzr-svn?
[02:05] <sili> Is it possible to mirror repositories?
[02:25] <lifeless> yes
[02:28] <dcoles> Is bzr git-serve part of the bazaar package these days?
[02:29] <dcoles> I just noticed the 'server' module in the git plugin and was trying to see how it worked.
[02:40] <lifeless> dcoles: I'd expect it to hook into 'bzr serve --protocol='
[02:41] <dcoles> Ah! I misread the wiki page
[02:42] <dcoles> Yes, `bzr serve --git` will do it
[05:23] <poolie> lifeless: your thoughts wanted on bug 185211
[05:31] <lifeless> poolie: well, looks like I created a shell demo for it
[05:32] <poolie> yes, it's fine as an open bug
[05:32] <poolie> if that's all it is that's fine
[05:32] <poolie> i just wondered if you knew more about it than is described there
[05:33] <lifeless> ENOENT :P
[05:38] <poolie> also, does https://bugs.edge.launchpad.net/bzr/+bug/337455 look like something that might have been fixed with bug 397705?
[05:40] <lifeless> no
[05:40] <lifeless> I suspect dirstate corruption there, but we should have fixed that too.
[05:40] <lifeless> I'd be fine with closing it as 'we think it works now'.
[05:51] <spm> igc: and others. bzr-explorer? <3 that is all. :-)
[05:53] <RAOF> How do you spell “bzr missing” in git? :/
[05:53] <mwhudson> apt-get install bzr-git ? :)
[05:54] <RAOF> You'd make me a happy man if you could tell me that (a) that now has some way to specify non-master branches, and (b) I can use it on the kernel tree :)
[05:54] <bob2> 'git log origin/master...' or so
[05:55] <mwhudson> for (a) ah, um, for (b) i think revgraph stuff /might/ be ok on the kernel?
[05:55] <RAOF> bob2: Imagine, if you will, that there are some 6400 commits in the last couple of weeks of git history :)
[05:56] <RAOF> Hm.  I think I want “git branch --contains”.  That's not totally insane.
[05:57] <stewart> hi! how dho i recover from BranchInTheWay when using pipes? basically, i want to overwrite whatever is on launchpad (because it is wrong)
[05:57] <lifeless> stewart: I don't know. delete the one on lp perhaps?
[05:59] <stewart> lifeless, trying... had fail because of that in the past...
[06:00] <stewart> lifeless, now get a "Not a branch" error.
[06:01] <bob2> RAOF: pretty sure it will find all unmerge commits
[06:01] <bob2> (note /3/ dots)
[06:02] <RAOF> bob2: Oh!  I thought that was an elipsis, rather than a part of the command.
[06:02] <bob2> ah
[06:03] <RAOF> That's impressively arcane.  Makes up for git branch --contains!
[06:10] <igc> spm: ?
[06:11] <igc> spm what does <3 mean?
[06:11] <spm> igc: <3 == is love :-)
[06:11] <lifeless> its a heart
[06:11] <lifeless> turn your heard to the right
[06:11] <lifeless> or your screen to the left
[06:11] <igc> aha
[06:11] <igc> spm: thanks!
[06:12] <spm> igc: for someone (me) who spends all day staring at grey text on a black screen in consoles; a gui that makes life easier on less used tasks is a truly *wonderful* thing. magic stuff!
[06:13] <igc> spm: I'd love it more myself if it stopped crashing all the time. One day soon I really need to fix that
[06:13] <spm> ha. obvioulsy I haven't hit a crash yet. I'll revise my love for the tool and send a hate message when that happens
[06:13] <stewart> lifeless, but then, if i go to launchpad and create the branch... i get the "Not a branch" error still. if i push into that branhc, i get the BranchInTheWay error. so it seems that i'm a bit screwed...
[06:26]  * stewart notes this wouldn't happen with quilt.
[06:26] <stewart> lifeless, so tried to avoid syncing that pipe.... by adding a new pipe (with a new name) and removing the old one. I still get the "not a branch" error. so there's something on LP.... any idea what? or how?
[06:29] <stewart> hrm.. ~/.bazaar/pipeline-cachedir can go away.... let's hope that does something.
[06:30] <stewart> wtf...
[06:33] <poolie> stewart: i think you'll find the config inside .bzr/branch/branch.conf
[06:33] <poolie> you can break the pipeline there probably
[06:34] <stewart> poolie, i'm getting "bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~stewart-flamingspork/drizzle/embedded-innodb-configuration-table-function/"."    yet grepping for "configuration" in .bzr reveals no results
[06:35] <stewart> i could go and try deleting the 29 branches on launchpad...
[06:35] <stewart> potentially screwing up everything i have linked to them...
[06:36] <lifeless> stewart: try grepping in .
[06:38] <stewart> lifeless, still nothing...
[06:38] <lifeless> try ~/.bazaar
[06:38] <lifeless> and try .bzr of the branches you have on lp
[06:39] <stewart> lifeless, nope. not on my system at all.
[06:39]  * stewart is not gonig to grep / as that'll probably take 3 hours
[06:39] <lifeless> reminder: bzr your mai
[06:39] <lifeless> l
[06:41] <stewart> lifeless, i'll wait until some point after i can upload my work and propose merge reqs of it...
[06:42]  * stewart sees what damage deleting all 29 damn branches on lp may cause.
[06:42] <stewart> not especially nice UI that... 29 times several page loads... urgh.
[06:43] <stewart> oh wait... there's merge requests with comments on them.
[06:45] <stewart> now trying deleting the single empty branch... eep.
[06:46] <stewart> fuck.
[06:48] <parthm> hello. i was writing some tests for bzr-grep and noticed that some tests were not seen. changing the name from test_something to test_somethingelse made it ok.
[06:48] <parthm> are there any rules to test naming?
[06:49] <lifeless> parthm: the function name?
[06:50] <parthm> lifeless: yes the function name. e.g. "def test_version_something" was not seen. If I changed it to "def test_ver_someting" the test count went up by 1.
[06:50] <lifeless> parthm: did you perhaps have another function with the same name?
[06:51] <parthm> lifeless: hmm. could be. i will check again.
[06:55] <lifeless> parthm: so yes there are restrictions, but both test_version_something and test_ver_something pass the them
[06:57] <parthm> lifeless: you are right. i think it was duplicate names. does bzr use pyunit or its own test framework. maybe such a thing can be an error?
[06:58] <parthm> as the number of tests go up (51 in this case) we can end up with duplicates.
[07:05] <lifeless> parthm: python itself does the compilation
[07:05] <jelmer> moin lifeless
[07:05] <lifeless> parthm: and its at that stage that you'd want to catch it.
[07:05] <lifeless> hi jelmer
[07:06] <lifeless> parthm: we use a derivative of pyunit
[07:08] <parthm> lifeless: ok. thanks. i will need to be more careful with the names :-)
[07:19] <vila> hi all !
[07:20] <lifeless> hai
[07:20] <jelmer> hey Vincent
[07:20] <lifeless> so, lost+found :)
[07:41] <lifeless> EODing
[07:42] <vila> lifeless: have a nice evening
[08:14] <thumper> where are the API docs?
[08:15] <lifeless> p.c.c/~mwhudson
[08:23]  * vila @dentist
[08:44]  * igc dinner
[09:41]  * vila back
[10:01] <lifeless> vila: so, lost + found?
[10:02] <vila> lifeless: hehe, not yet on the top of my TODO graph but I'm targeting the related tests in test_conflicts already
[10:03] <vila> lifeless: I will also start implementing the basic feature so I can *then* plug it in the right places
[10:04] <vila> basic feature: moving an unversioned file in some trash with a bare-bones handling and how it was called and when it was trashed (to address the likely collisions)
[10:08] <vila> lifeless: does a '_trash' method on the wt sounds fine ? (AIUI we need it only for unversioned files right ?)
[10:09] <lifeless> vila: lost_and_found please, trash is explicitly discarded
[10:11] <vila> trash (or recycle bin) are more mainstream than lost_and_found IMHO, besides, what is 'lost' in our case ? (found as 'found' in bzr way can fly but requires a bit of explanation
[10:12] <lifeless> they are diferent concepts
[10:12] <lifeless> I don't see how one can be a mainstream version of the other
[10:13] <vila> well, to me, lost+found in the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly the connection here,
[10:13] <vila> I'm fine with not using trash, so maybe 'quarantined' or something ?
[10:14] <vila> err
[10:14] <vila> well, to me, lost+found *is* the unix way to store... 'garbage' found when errors occurred at the fs level, I don't clearly *see* the connection here,
[10:16] <Kamping_Kaiser> i dont like to think of my files as garbage >.>
[10:17] <vila> Kamping_Kaiser: well, we are talking about files like .pyc, .o etc, as far as versioning is concerned, how would you like them to be called ?
[10:18] <Kamping_Kaiser> vila: i was refering more to your comment 'lost+found *is* the unix way to store... 'garbage''
[10:19]  * Kamping_Kaiser heads off
[10:19] <vila> Kamping_Kaiser: ha, right, well, the ellipsis was intended to carry my lack of precise wording here :) My experience is that the files or directories found in lost_found are not always in good shape :0
[10:20] <lifeless> vila: so, lost+found in ext* fs's caries files that the filesystem has recovered because they no longer had a directory to belong in.
[10:20] <lifeless> vila: the connection is that lost+found in a bzr tree would carry files that bzr no longer has a directory to put them in.
[10:20] <vila> lifeless: wow, yeah in that case there is a 1-1 match, but who knoes that ?
[10:20] <vila> orphans ?
[10:21] <lifeless> no value judgement is made about the files - they might be databases or temp files - we don't know
[10:21] <lifeless> 'trash' is a value judgement
[10:21] <vila> I got that
[10:21] <lifeless> orphans would be fine
[10:21] <lifeless> recovered
[10:21] <lifeless> lost + found would be bad because folk that do know what it is might think their file system is insane if bzr makes such a dir ;)
[10:22] <vila> recovered is slightly misleading as there aren't lost today :)
[10:23] <vila> recoverable ?
[10:23] <lifeless> uhm
[10:23] <lifeless> I don't get what you mean
[10:23] <vila> anyway, I'll outlight all this naming issues in my proposal so we can find a consensus
[10:23] <lifeless> *foo*-able would imply some way that the user can *foo* files.
[10:23] <vila> yes, that's the idea
[10:24] <lifeless> foo-ed or foo-s implies that bzr has done foo for the user, and they can now decide what do to.
[10:24] <vila> I don;t intend to propose commands for that but at least a naming scheme that allows once to find back these files
[10:24] <vila> s/once/one/
[10:25] <vila> there will be cases where an unknwon file was really a not-yet-added but precious file
[10:26] <vila> but the general case should be that the user can cleanup all of them on a regular basis
[10:27] <lifeless> indeed
[10:27] <lifeless> I don't really like recoverable
[10:27] <lifeless> can't articulate why
[10:27] <lifeless> recovered I could cope with
[10:27] <lifeless> or orphans
[10:27] <lifeless> oh, I suggest a bzr- prefix
[10:28] <lifeless> bzr-recovered
[10:28] <lifeless> bzr-orphans
[10:28] <vila> then I'll start with orphans
[10:28] <vila> you mean in as a first-level directory in the wt ?
[10:28] <vila> I thought it will be in .bzr/checkout... but no strong feeling,
[10:29] <vila> I'm still unclear about how the user should restore from there...
[10:30] <vila> ...and how to avoid the content growing out of control if it's not noticed...
[10:33] <lifeless> vila: I don't think we should hide it
[10:33] <lifeless> it should be in-your-face if this happens, but not in-your-way
[10:33] <lifeless> and yes, I mean a sibling of .bzr
[10:34] <vila> hmm
[10:35] <vila> That makes sense. At least for me, I can imagine I will promptly delete it as soon as I discover it...
[10:35] <vila> after a quick content check of course
[10:36] <lifeless> exactly
[10:37] <vila> So that raises the question of the content naming, reproducing the full relpaths (with some anti-collision scheme added) doesn't look very good, using fully random names requires some way to translate back to a (date, relpath)
[10:37] <vila> the later requires an additional command (or two)
[10:38] <vila> namely: list, recover <xxx> <here>
[10:39] <lifeless> vila: huh, using the full relpath is great.
[10:39] <vila> lifeless: not if you have tenths or hundreds of them
[10:39] <lifeless> uhm
[10:39] <lifeless> I think you're over designing
[10:39] <lifeless> we expect folk to clean this up regularly and promptly.
[10:39] <vila> and I'm a bit concerned about max-length paths
[10:40] <lifeless> we can merge the directories
[10:40] <lifeless> and we only add len(bzr-orphans) to the max length
[10:41] <vila> I was thinking about adding yyyymmdd-hhmmss stamps
[10:41] <vila> but if folks clean it regularly, that may be useless
[10:41] <lifeless> so don't do that
[10:41] <lifeless> thats ugly
[10:42] <lifeless> it would stop people trivially moving them back into place
[10:42] <lifeless> and the files will have a mtime of their own already if we don't break it
[10:42] <vila> well, they can't move them back normally since that's why the files end up here in the first place
[10:42] <lifeless> sure they can
[10:42] <Peng> Might be good to add an incrementing number to the end of the first directory in the relpath, like with backup.bzr.
[10:42] <vila> yeah, mtime, good point
[10:42] <Peng> (Or similar to it, anyway; I don't remember exactly how backup.bzr works.)
[10:43] <lifeless> we delete the directory - but now we'll preserve the directory in this tree
[10:43] <lifeless> lastly
[10:43] <vila> lifeless: right, but AIUI that's why the merge can't complete successfully
[10:44] <lifeless> I think it might be fine to just overwrite existing files in this dir: if the user has the same precise file generated + not versioned twice, then they very likely are autogenerating it
[10:45] <vila> or re-create it in which case the last one is as good as the previous one
[10:45] <vila> yeah, that's certainly sounds like a good first implementation anyway, I'll go that route
[13:55] <Oli``> Is there an export function that could upload version controlled files up to another location but didn't write any .bzr (et al) files?
[13:56] <Peng> Oli``: "bzr export" or the bzr-upload plugin if it's remote.
[13:57] <Oli``> Peng: doh - thank you
[15:25] <jml> hi
[15:26] <jml> I got these errors when trying to use --lsprof-file: http://paste.ubuntu.com/395662/
[15:33] <Peng> jml: Try 'bzr --lsprof-file grep.callgrind' instead of using an =. Maybe it will like that.
[15:33] <jml> Peng: ahh yes, it does. thanks
[15:34] <Peng> Global options use really basic parsing. It's like 5 'if' statements.
[15:34] <Peng> No optparse or anything./
[15:38] <jml> Peng: good to know, thanks.
[16:17] <kareeser> hello everybody :)
[16:18] <kareeser> I'm a bzr newbie... and I have some silly questions to ask... anyone interested in humouring me?
[16:18] <rubbs> fire away
[16:18] <rubbs> that's what the channel is for ;)
[16:19] <kareeser> awesome.
[16:19] <kareeser> so, I use svn, and am trying out bzr for the first time
[16:19] <kareeser> whenever I delete a folder in svn, svn treats it as being accidentally deleted, and recreated it on the next update
[16:20] <kareeser> in bazaar, it treats it as being removed from versioning
[16:20] <kareeser> is that correct?
[16:20] <rubbs> if you mean bzr rm filename then yes.
[16:20] <kareeser> nope...
[16:20] <rubbs> it will remove it from versioning
[16:20] <kareeser> just "rm filename"
[16:20] <kareeser> when I run bzr status, it reports it as "removed"
[16:20] <rubbs> gotcha.
[16:20] <kareeser> is this just a byproduct of using bzr-svn?
[16:21] <rubbs> I could be wrong, but IIRC anything "removed" from the repo is automatically detected by bzr as removed from versioning.
[16:21] <rubbs> this can be reversed
[16:22] <rubbs> if you are using bzr with as SVN repo, I'm not entirely sure, but others here are bigger experts with bzr-svn than I am
[16:22] <kareeser> right.. I thought so
[16:22] <kareeser> I'm in the process of uploading my code to launchpad anyway, so I probably won't have to use bzr-svn for too long...
[16:24] <rubbs> btw that wasn't a stupid newbie question ;)
[16:24] <rubbs> sorry i couldn't answer it with more authority :(
[16:26] <kareeser> haha... sorry
[16:26] <kareeser> I guess you were expecting something more along the lines of "what's a checkout?!"
[16:27] <kareeser> okay, then, answer me this
[16:27] <kareeser> trunks are branches, yes?
[16:27] <kareeser> then... branches are not trunks?
[16:27] <kareeser> the trunk*
[16:28] <rubbs> haha
[16:28] <rubbs> best way to look at it is a trunk is just the central focus on where the development will take place
[16:29] <rubbs> every branch is a copy of that trunk
[16:29] <rubbs> so you have a branch on your computer, the "branch" you make as your focus/target for others to develop to is the "trunk"
[16:30] <kareeser> and the trunk is the one hosted on a central server (arbitrarily determined) for others to checkout/branch from?
[16:30] <kareeser> i.e. Launchpad?
[16:30] <rubbs> most of the time yes. For our purposes in this example that is exactly correct
[16:31] <rubbs> any branch can be a trunk. in distrubited version control like bzr "trunk" is more of a social thing than a technical difference
[16:31] <kareeser> okay...
[16:32] <kareeser> so when I "pushed" my code onto launchpad... and it called it a branch (both on my computer and on LP)... that's fine?
[16:32] <rubbs> yes
[16:32] <kareeser> even if the branch is named "trunk"?
[16:32] <rubbs> correct
[16:32] <kareeser> this is all very confusing. :P
[16:32] <kareeser> I see.
[16:32] <rubbs> it gets better once you use it a little more
[16:32] <kareeser> I sure hope so, heh.
[16:33] <rubbs> bzr makes not technical distinctions between branches and trunks. Most people make the distinction themselves by naming a branch "trunk" like you did.
[16:33] <kareeser> I see, that makes sense.
[16:34] <rubbs> LP also helps because you can make the specific branch as the "focus of development"
[16:34] <rubbs> this tells other LP users that "trunk" is the one to branch from
[16:34] <kareeser> right
[16:35] <kareeser> okay, next...
[16:35] <rubbs> ready
[16:36] <kareeser> in my app, I have a check in index.php to see if ../install is present. If so, it halts the script and tells the user to go to the install script. Makes sense, I hope.
[16:36] <kareeser> once the install script finishes, the user is instructed to delete the /install folder.
[16:36] <kareeser> got the idea from mediawiki, I think...
[16:36] <rubbs> ok, I'm following so far
[16:37] <kareeser> anyways, if the user maintained their program using bzr, then wouldn't bzr automatically recreate ../install every time?
[16:37] <kareeser> basically, I'm asking, the way I designed my program, is it "anti-bzr"? :P
[16:37] <kareeser> I don't mind having to rely on .tar.gz releases, I'm just wondering.
[16:38] <rubbs> well, two things to think about with that issue. 1) bzr isn't really designed for distribution of the final product, but most people work around that.
[16:38] <kareeser> okay, that's what I thought...
[16:39] <rubbs> 2) there are ways around it but it could require some work from either you or your "customers"
[16:39] <rubbs> one way I would think about doing it is having a "trunk" for development
[16:39] <rubbs> and having a "distrubtion" branch
[16:40] <rubbs> in the distribution branch you pull from the trunk and delete the install directory
[16:40] <rubbs> that way when people update from the dist branch they dont' get a new install dir every time
[16:40] <abeaumont> kareeser: to workaround that, suppossing that newer versions never need reinstalling, use a .installed file or similar, instead of removing your dir, bzr will ignore that file
[16:40] <kareeser> and if development continues in trunk, then distribution is updated periodically?
[16:41] <abeaumont> (just an idea)
[16:41] <kareeser> abeaumont, elegant, I like it.
[16:41] <rubbs> kareeser: yes, but you'd have to do that manually
[16:42] <rubbs> but I think abeaumont's idea is better than mine
[16:43] <kareeser> hm..
[16:43] <kareeser> okay, thanks rubbs, abeaumont, for your help :)
[16:43] <kareeser> A+.
[16:43] <rubbs> np.
[16:43] <abeaumont> you're welcome :)
[16:44] <rubbs> come back and ask more questions if you have any. most of the time someone knows where to look if they don't know the answer outright.
[16:49] <kareeser> I only ask, because I do development on three computers, one of which is the actual implementation (with real data)
[16:49] <kareeser> and with bzr being unfamiliar, I'm afraid I'll accidentally delete the repository with a stray rm command ;)
[17:19] <dolphinling_> I have some files I need version controlled with filenames that match bzr's default ignore rules. How can I get bzr to not use its default ignore rules?
[17:20] <rubbs> dolphinling_: I might not remember this right, but there should be a global config file you can edit. What system are you using?
[17:21] <rubbs> er Operating system I meant
[17:21] <dolphinling_> gentoo linux
[17:22] <rubbs> k... just as sec. I'm going to check before I tell you the wrong thing ;)
[17:23] <dolphinling_> All right, I'm searching through system dirs to see if I can find this file
[17:25] <dolphinling_> rubbs: heh, I found it, it's ~/.bazaar/ignore
[17:25] <rubbs> ah, ok, sorry
[17:25] <rubbs> I thought there was a global one too
[17:25] <rubbs> but I could be wrong
[17:26] <dolphinling_> This is fine for me.
[17:26] <dolphinling_> I wish there were some way to just override it rather than editing it, but oh well.
[17:27] <rubbs> dolphinling_: I'm sure there probably is, I'm just not remembering it right now
[17:38] <IslandUsurper> dolphinling_, you should be able to just bzr add specific_filename
[17:39] <IslandUsurper> of course, that's only useful if you have only a few of those files to unignore
[17:39] <fullermd> 2.1 and later have support for negative ignore patterns.
[17:40] <fullermd> It's definitely better to not edit the builtin ignore if at all possible.  That tends to have unpleasant knockon effects down the line.
[17:42] <IslandUsurper> I have a website that I've been updating with bzr-upload, but I've recently gotten shell access. Is there a clean way to convert that folder into a branch without having to reconstruct all of those files again?
[17:47] <IslandUsurper> maybe I should say, without having lots of conflicts that would disrupt the working of the site
[17:47] <fullermd> I don't know, but I doubt it.
[17:47] <fullermd> I can think of some unclean ways that might work.
[17:48] <IslandUsurper> I've thought about making a new branch, doing one commit, and then pull --overwrite
[17:48] <IslandUsurper> if the file content is the same, no one outside should notice...
[17:49] <fullermd> If what you've uploaded is exactly what's in the branch, you could try making a throwaway branch somewhere, transplanting its .bzr/ over to the location, and seeing what 'stat' etc have to say.
[17:51] <IslandUsurper> yeah. but I've read that Bzr compares file IDs first, and those will probably be different, especially for the directories
[17:51] <fullermd> How?  The existing files from upload don't really ahve id's.
[17:51] <fullermd> ID's are an internal bzr thing, they don't exist in the filesystem.
[17:51] <IslandUsurper> hmm. ok
[17:52] <IslandUsurper> I'll give that a shot then
[17:52] <barry> hi folks.  i have a question about bzr-pipeline.  is it known/expected that renaming the top-level directory breaks the pipelines?
[17:52] <fullermd> barry: Absolute paths used in cross-references?
[17:58] <barry> fullermd: dunno.  it was weird though.  when i moved the dir back to its original name, the pipes below it showed up again (phew! :)
[19:16] <mwhudson> jelmer: ping?
[19:30] <mwhudson> another inconsistent sha bug :( https://code.edge.launchpad.net/~vcs-imports/fetchmail/master
[19:34] <rbriggsatuiowa> I am having problems with bzr unshelve - i just get a dump of bzr metadata with the following error at the top
[19:34] <rbriggsatuiowa> bzr: ERROR: The file id "workflow.html.erb-20100305150443-x3ac2am7beykb5dz-1" is not present in the tree
[19:36] <rbriggsatuiowa> https://bugs.launchpad.net/bzr/+bug/253806 is the problem I am having
[19:36] <rbriggsatuiowa> ubottu: any idea what release?
[19:36] <rbriggsatuiowa> 1.13 it looks like
[19:37] <rbriggsatuiowa> sigh - way to fail the reverse turing test
[19:37]  * rbriggsatuiowa heads off to try a newer version of bzr
[20:31] <jelmer> mwhudson, looking
[20:31] <mwhudson> jelmer: i filed a bug btw
[20:36] <jelmer> mwhudson, ah, merci
[20:42] <parthm> hello. for bzr-grep, i am seeing UnicodeDecodeError while printing the output. whats the recommended way to handle this? http://pastebin.com/x7TLnMAV
[20:46] <mwhudson> jelmer: the question of the uber-slow kernel import came up again in the stand up
[20:46] <mwhudson> jelmer: do you know why it's as slow as it is?
[20:47] <jelmer> mwhudson, one part of it is the indexes
[20:48] <mwhudson> oh, the using bzr indexes thing?
[20:49] <jelmer> mwhudson, s/indexes/cache/
[20:49] <jelmer> mwhudson, yeah
[20:49] <jelmer> mwhudson, that's about 25% I suspect; not sure how the other part could be optimized, we'd have to do performance analysis first
[20:50] <mwhudson> jelmer: do you have any idea why the kernel is so much slower than everything else?
[20:50] <mwhudson> just because it's a really big tree?
[20:51] <jelmer> mwhudson, yeah, the size of the tree
[21:16] <mwhudson> jelmer_: https://code.edge.launchpad.net/~vcs-imports/iso-codes/master failed in the same way :(
[21:28] <ubuntujenkins> how do i slve this? bzr commit bzr: ERROR: Could not acquire lock "/home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailab
[21:28] <ubuntujenkins> *solve
[21:39] <kfogel> lifeless: ayt?
[21:44] <lifeless> hai
[21:44] <lifeless> ubuntujenkins: is that a fuse mount or something?
[21:44] <lifeless> kfogel: hai
[21:45] <ubuntujenkins> I did a bzr commit and exited badly which caused it.
[21:46] <kfogel> lifeless: hey, so I'm trying to test out some of your recommendations for bzr+ssh in the proposed savannah.gnu.org setup.  If you have some time, I'd love your help -- I think I'm stumbling on perhaps basic ssh configuration issues.
[21:46] <lifeless> ok
[21:46] <lifeless> shoot
[21:47] <lifeless> ubuntujenkins: what does fuser /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate show?
[21:47] <kfogel> lifeless: so I'm testing out your first recommendation: (one sec, I'll paste)
[21:47] <kfogel> lifeless: this one: http://paste.ubuntu.com/395841/
[21:47] <ubuntujenkins> lifeless nothing
[21:47] <kfogel> lifeless: what I'm first trying to do is get the 'command="foo"' option working at all -- I just want to see it have an effect.
[21:48] <kfogel> lifeless: so I've created a user ~jennifer on my machine, and given her a ~/.ssh/authorized_keys file, and put a new authorized key in there like this:
[21:48] <kfogel> command="/bin/echo fish" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzvPivbVMjyzQTwEhCVuD+WinVw8rhIKY5k3PzH7HxFtarXZH/NAPkvYqDhKG0iJnHoxGIY5K6Of1V+D77+5Lyd+FtdRNneT4OATLDI/gRGWmrIJhYJr7Ag3eeVBjMZBsC6ty/jMAiBUfWs5GxF3ajKgwo4nZmbVJjEKwBmunFeoO7295qve++tgF8isDUwaZmpKwOr/Rxe8eJYmdbOHqOAu0dwnDNIf45daUurqlJaounjQVkrgLDQ/xLoNE2WnXfnAFmsNUF48acrXWeP6D3+fqh6HgnDttR6mbPY5ZxZx9jlTl1d/FkJZLaCUjDJbtOr3vaBxD69TRm6cDAJxfLQ== kfogel@kfogel-work
[21:48] <lifeless> ubuntujenkins: thats odd
[21:48] <kfogel> lifeless: then I substituted the corresponding (new, temporary) private key for my own ~kfogel/.ssh/id-rsa
[21:48] <ubuntujenkins> hang on i know
[21:48] <kfogel> and did 'ssh jennifer@localhost'
[21:49] <kfogel> lifeless: and the result is that she just logs in successfully.  Not what I was expecting :-).
[21:49] <kfogel> lifeless: am I doing something wrong, perhaps?
[21:49] <ubuntujenkins> nope nothing, I think it would be quicker to copy the chnages to a new branch
[21:50] <lifeless> ubuntujenkins: I hate to ask this in a unix environment, but have you tried a reboot?
[21:51] <ubuntujenkins> nope I will be back
[21:51] <stewart> abentley, hi! i'm having pipeline issues
[21:51] <lifeless> kfogel: so the limit is per key
[21:51] <lifeless> kfogel: do you have more than one key, or more than one authorised keys file?
[21:51] <kfogel> lifeless: nope.  that's the only authorized key in the file
[21:52] <kfogel> in ~jennifer/.ssh/authorized_keys, that is
[21:52] <abentley> stewart, what's the issue?
[21:52] <stewart> abentley, i think i need a --overwrite to sync-pipeline. as i've managed to get into a situation where the trees on lp reference a pipe that i don't have, and deleting the branch doesn't work.
[21:52] <lifeless> kfogel: ok. does -vvv give any hints?
[21:53] <kfogel> lifeless: not to my untrained eye, but let me take another look (and I'll paste if I don't see anything obvious)
[21:54] <abentley> stewart, yes, sync-pipeline only adds pipes, never deletes them, because it can't tell whether a discrepancy is because side A added a pipe or because side B deleted it.
[21:54] <ubuntujenkins> no difference lifeless
[21:54] <stewart> abentley, so on sync-pipeline i get "Not a branch" for a pipe that used to exist.
[21:55] <stewart> abentley, any way to override it....
[21:55] <lifeless> kfogel: it works for me
[21:55] <lifeless> kfogel: I bet you either have an authorized_keys2 file, or two keys in the same file
[21:56] <abentley> stewart, there's nothing built in for that.  You'd need to edit the branch.conf file in the neighbour branches to fix it.
[21:56] <lifeless> $ ssh localhost
[21:56] <lifeless> foo
[21:56] <lifeless> Connection to localhost closed.
[21:56] <stewart> abentley, and that'd be on launchpad, as there is no reference to this pipe locally (grepped *everywhere*)
[21:57] <abentley> stewart, correct.
[21:57] <stewart> abentley, could i delete a few of the branches around it on launchpad and that would fix it?
[21:57] <abentley> stewart, I think you'd need to delete all of them.
[21:58] <stewart> abentley, hrrm.... all of them is problematic... there's 29 of them, and there's many links to merge requests, blueprints, bugs......
[21:59] <lifeless> ubuntujenkins: oh
[21:59] <abentley> stewart, perhaps you're thinking it's not possible to edit a branch.conf on Launchpad?
[21:59] <lifeless> ubuntujenkins: run whatever is failing with '-Derror' you should get a backtrace
[21:59] <kfogel> lifeless: definitely only one key in the authorized_keys file, and no authorized_keys2 file, but I think I see the problem (http://paste.ubuntu.com/395844/).  The fact that I was being prompted for a password (!) seemed wrong, and it looks like ssh is not reading the file as rsa2...
[21:59] <lifeless> ubuntujenkins: pastebin that, we can look at it
[21:59] <kfogel> lifeless: I mean, i should not get a password prompt, right?
[21:59] <lifeless> ubuntujenkins: also, please include the output of 'mount'
[21:59] <lifeless> kfogel: right, you want password auth disabled
[22:00] <stewart> abentley, how do i do that?
[22:00] <lifeless> kfogel: -v will have told you, but - chmod 0700 .ssh, chmod 0600 .ssh/keyfile
[22:00] <abentley> stewart, you can use an sftp client or lp:hitchhiker
[22:00] <ubuntujenkins> lifeless: I am quite happy to carry on if it interests you but I am quite happy to copy stuff to a new version of the branch. You seem like a busy person
[22:01] <lifeless> ubuntujenkins: we should find out whats happening, so we can fix or document it
[22:01] <kfogel> lifeless: in ~kfogel/.ssh ?
[22:01] <stewart> abentley, let me try...
[22:01] <lifeless> kfogel: yes
[22:02] <ubuntujenkins> no problem I will get the information for you lifeless
[22:02] <lifeless> kfogel: it will have said 'key foo has inappropriate permissions, ignoring' or something like that
[22:02] <kfogel> lifeless: already are that way
[22:02] <lifeless> kfogel: or, you haven't added the key to your agent - ssh-add .ssh/filename
[22:02] <lifeless> or pass -i .ssh/filename when you invoke ssh
[22:02] <kfogel> lifeless: note that's not in the -v output (see paste)
[22:02] <kfogel> lifeless: ah, didn't know about -i, I'll try it
[22:02] <kfogel> lifeless:  when you say .ssh/filename, you mean the private key?
[22:03] <lifeless> yes
[22:03] <kfogel> for kfogel, that is?
[22:03] <lifeless> the one for jennifer
[22:03] <kfogel> well, I'd already substituted it for my normal id_rsa
[22:03] <kfogel> it is the standard filename right now
[22:03] <kfogel> lifeless:  and it's chmod 600
[22:03] <kfogel> too
[22:03] <lifeless> I'd put it back to a different name TBH
[22:03] <lifeless> could be caching effects
[22:05] <ubuntujenkins> ok after the reboot lifeless the only error occurs with bzr commit the error and the output of mount is here http://paste.ubuntu.com/395847/
[22:06] <lifeless> ok, thats a different error
[22:06] <kfogel> lifeless: on phone, one sec
[22:06] <abentley> stewart, I have to go, but you can email me if you get stuck.
[22:06] <lifeless> you can run 'bzr break-lock' to fix that one
[22:08] <ubuntujenkins> lifeless I did bzr break-lock but I now get this error http://paste.ubuntu.com/395849/ wehn doing bzr commit
[22:09] <lifeless> this is really strange
[22:09] <lifeless> we're calling fcntl.lockf(self.f, fcntl.LOCK_SH | fcntl.LOCK_NB)
[22:10] <lifeless> where self.f is an open file on /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate
[22:10] <lifeless> do you have a view defined ?
[22:11] <ubuntujenkins> whats a view?
[22:11] <lifeless> ok, you don't ;)
[22:11] <ubuntujenkins> cool
[22:11] <ubuntujenkins> I guessed you were not talking about the one out of my window :-P
[22:11] <lifeless> can you run '
[22:12] <lifeless> 'fuser -ki /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate'
[22:13] <lifeless> ubuntujenkins: what version of bzr?
[22:13] <ubuntujenkins> ok i did that and agreed to all of it and I now get http://paste.ubuntu.com/395852/
[22:14] <lifeless> could you paste what it output as well ?
[22:14] <ubuntujenkins> Bazaar (bzr) 2.1.0
[22:14] <lifeless> you'll need to break-lock again
[22:14] <ubuntujenkins> http://paste.ubuntu.com/395854/
[22:14] <ubuntujenkins> i will do bzr break-lock
[22:14] <lifeless> ok
[22:15] <lifeless> now after the break lock, I expect it will fail again - thats ok
[22:15] <ubuntujenkins> now it works again
[22:15] <lifeless> ok
[22:15] <lifeless> thats great
[22:15] <lifeless> next time it fails
[22:15] <lifeless> please run
[22:15] <lifeless> fuser -v /home/luke-jennings/Projects/ubuntu-manual/.bzr/checkout/dirstate
[22:15] <lifeless> we need to see what is locking it
[22:16] <ubuntujenkins> thanks very much I have one more question, if i do bzr commit but don't want to commit how do i get out safley?
[22:16] <lifeless> the easiest way is to let it finish, then do 'bzr uncommit'
[22:16] <ubuntujenkins> ok thank you i did not know bxr uncommit existed
[22:16] <lifeless> if bzr has popped up an editor, asking for a commit message
[22:17] <lifeless> then you can just give it an empty message and it will abort
[22:17] <ubuntujenkins> yep
[22:17] <lifeless> otherwise you can also just hit ctrl-C and it will stop the commit cleanly.
[22:17] <ubuntujenkins> cool
[22:18] <ubuntujenkins> thanks again
[22:21] <lifeless> kfogel: easiest test I know is: on your machine, make sure you can ssh in with keys; then edit your own authorized_keys to add the command, ssh in again
[22:27] <mathrick> hi
[22:27] <mathrick> http://pastebin.com/tAwdVyyL
[22:27] <mathrick> a baffling crash I got
[22:27] <mathrick> I've seen it before too
[22:27] <mathrick> it was a push to a new branch, too
[22:28] <mathrick> it doesn't happen when I go over sftp://
[22:43] <kfogel> lifeless: will try, thx
[22:46] <kfogel> lifeless: will test more later tonight, have to run right now.  Thanks for the time.  How much longer are you on?
[22:46] <lifeless> kfogel: I'm here all wekk
[22:46] <lifeless> boom-tish
[22:46] <kfogel> lifeless: I mean today?
[22:46] <lifeless> kfogel: its 0945 for me
[22:46] <kfogel> lifeless: okay :-)
[22:46] <lifeless> kfogel: I started before 7
[22:46] <kfogel> lifeless: "I'm here all week.  Try the veal, remember to tip your waiters."
[22:46] <kfogel> is the line I think :-)
[22:47] <lifeless> so, abour 5 hours working, and more depending on $variables
[22:47] <kfogel> lifeless: *nod* ok
[23:11] <igc> morning
[23:13] <mathrick> any eyeballs on that crash log I pasted?
[23:15] <GungaDin> Hi
[23:15] <GungaDin> How can I merge changes from a previous commit into the current version of a file?
[23:16] <mathrick> GungaDin: what do you mean?
[23:16] <lifeless> bzr merge -c commit filename
[23:16] <GungaDin> I have a file x.cpp and there's another version of a file 3 commits before...
[23:17] <mathrick> ah
[23:17] <GungaDin> I need to merge some of the changes in the earlier version into the current one.
[23:17] <mathrick> you probably want --interactive too if you only want some changes
[23:17] <lifeless> "bzr merge -c commit filename ." then
[23:18] <mathrick> lifeless: can you give two parameters to bzr merge?
[23:19] <mathrick> if so, it's not listed at all in bzr help merge
[23:19] <lifeless> oh, I mean
[23:19] <lifeless> "bzr merge -c commit ./filename"
[23:19] <mathrick> useful, I didn't know you could narrow it down to a path
[23:35] <fossrox> hi Everyone :)
[23:37] <dvheumen> hi
[23:55] <stewart> abentley, i've edited the branch.conf files where needed... and still getting exactly the same error :(