[00:54] <kbulgrien> $ bzr status --no-recurse
[00:54] <kbulgrien> bzr: ERROR: no such option: --no-recurse
[00:54] <kbulgrien> $ bzr status --no-recurse
[00:54] <kbulgrien> bzr: ERROR: no such option: --no-recurse
[00:55] <kbulgrien> jelmer: no
[00:55] <kbulgrien> $ bzr status --no-recurse
[00:55] <kbulgrien> bzr: ERROR: no such option: --no-recurse
[00:55] <jelmer> kbulgrien: I get the point, no need to repeat it three times :)
[00:55] <kbulgrien> mistake
[00:55] <kbulgrien> sorry
[00:55] <jelmer> kbulgrien: I must be mistaken, I thought bzr status had a --no-recurse option too
[00:56] <kbulgrien> was scrolled up and thought middle click wasn't pasting.
[00:57] <kbulgrien> well, it gets annoyed when there is read-only stuff... haven't figured out if it bails or simply reports problem, but --no-recurse would avoid that.
[00:58] <jelmer> kbulgrien: what kind of read-only stuff? bzr status shouldn't write to any files in the working tree
[00:58] <kbulgrien> weigon sure comes and goes a lot
[00:58] <jelmer> yeah
[00:58] <jelmer> weigon: ayt?
[00:59] <kbulgrien> well, again, regarding ro stuff, its stuff that is probably atypical of what most people do.
[01:00] <kbulgrien> I'm just changing what I used to do with another vcs over to bzr.
[01:00] <jelmer> kbulgrien: how is bzr complaining though/
[01:00] <kbulgrien> $ bzr status *
[01:00] <kbulgrien> bzr: ERROR: [Errno 13] Permission denied: '/etc/shorewall/hosts'
[01:01] <jelmer> kbulgrien: ah, not readable at all
[01:01] <jelmer> that's different from readonly :)
[01:01] <kbulgrien> probably another reason I need to look at etc keeper if I am going to use bzr for this
[01:02] <kbulgrien> yeah, punchy. sorry.  been working in the yard all day. am beat.
[01:02] <jelmer> kbulgrien: and .bzr/ is readable?
[01:02] <kbulgrien> yes
[01:03] <jelmer> kbulgrien: why isn't /etc/shorewall/hosts not openable in tha tcase?
[01:03] <jelmer> presumably it has the same data as /etc/shorewall/hosts
[01:03] <kbulgrien> because I am not root
[01:04] <jelmer> kbulgrien: but why is .bzr/ readable for non-root in that case?
[01:04] <jelmer> kbulgrien: presumably that would allow you to get at data that is otherwise only accessible for root
[01:04] <kbulgrien> sudo
[01:04] <kbulgrien> I only use it when absolutely necessary
[01:05] <kbulgrien> so for controlling those files I sudo, otherwise I work as sysadmin user.
[01:05] <kbulgrien> That's fine for everything else, but a pain when checking status.
[01:05] <kbulgrien> It's ok... as long as it isn'
[01:05] <kbulgrien> t bailing out.
[01:06] <kbulgrien> But then I'd guess if it wasn't bailing out it would have showed all the stuff.
[01:06] <jelmer> kbulgrien: why is that file not readable then though?
[01:07] <kbulgrien> all /etc/shorewall is rw root.
[01:07] <kbulgrien> I was wanting status in /etc, not etc/shorewall.
[01:07] <kbulgrien> I didn't need sudo in /etc
[01:08] <kbulgrien> So I didn't use it, but then it recursed and apparently is bailing out on the unreadable.
[01:08] <jelmer> kbulgrien: why is it not readable for regular users I mean? Presumably they can get at its contents from .bzr/ anyway.
[01:08] <jelmer> lifeless: ping
[01:08] <lifeless> hmm?
[01:09] <kbulgrien> bzr is operator.root 770, so no, regular users can't get to it.
[01:09] <jelmer> lifeless: can you perhaps ban weigon, he isn't responding and has been reconnecting every two or three minutes for the last day or so
[01:09] <jelmer> kbulgrien: then how do you expect 'bzr status' to work as regular user? It needs to access .bzr/
[01:10] <kbulgrien> I'm tempted to say forget it, but, I expect to have to do some magic to check status of /etc/shorewall.
[01:11] <kbulgrien> I have a little bitty front-end script that does the magic - when I need it.
[01:11] <kbulgrien> My point was that all I wanted to do was check status of /etc, not everything underneath etc.
[01:11] <kbulgrien> There is no way to limit bzr status to what I want to do so I don't have to use the magic unnecessasrily
[01:12] <jelmer> kbulgrien: that's bug 287880
[01:12] <kbulgrien> ok
[01:12] <kbulgrien> I need to get more acquainted with launchpad
[01:12] <jelmer> I think the permissions is a different issue though, but I don't really understand what you're trying to do
[01:13] <kbulgrien> I'm version controlling "my" edits in an OS.  someone told me I should use etckeeper for that, but I've been doing things this way for years with CVS.
[01:14] <kbulgrien> So that's what I tried doing when I decided to jump over to bzr.
[01:14] <kbulgrien> The frontend for bzr is tiny compared to the frontend for cvs.
[01:14] <kbulgrien> It was also giving me a practical at-home experience with bzr to learn it.
[01:15] <kbulgrien> I have to get comfortable with it on my own before I push it up at work.
[01:15] <kbulgrien> I don' t have an bzr projects at home at the moment, other than minor server stuff.
[01:16] <kbulgrien> I realize my usecase is very odd.
[01:16] <jelmer> kbulgrien: I don't think your usecase is very odd - I'm using etckeeper too
[01:16] <kbulgrien> I just haven't tried etckeeper.
[01:17] <jelmer> kbulgrien: my /etc/.bzr/ is (intentionally) not accessible by non-root, since it versions some files that I don't want non-root users on my system to be able to access
[01:17] <kbulgrien> I fell into doing things the way I had always done them with cvs.
[01:17] <kbulgrien> I didn't even realize etckeeper was a vcs frontend until someone on here told me to look at it.
[01:17] <jelmer> kbulgrien: I think one of the differences with CVS is that CVS has a single file with the data on each versioned file. Bazaar stores information on multiple files together in single files (a pack)
[01:18] <kbulgrien> yes.  when I am doing os stuff, I have user is special.
[01:18] <kbulgrien> I never do os config as my regular user.
[01:18] <kbulgrien> I cannot even sudo with my regular user.
[01:19] <jelmer> kbulgrien: can that os config user access /etc/shorewall/hosts ?
[01:19] <kbulgrien> So this user is non-root, so his repo and sandboxes are not accessible to anyone else.
[01:19] <kbulgrien> only by sudo
[01:20] <kbulgrien> my front end script stats the file, gets perms, saves them, tweaks perms so bzr can do what it wants, then puts everything back, so bzr can run non-root too.
[01:20] <jelmer> kbulgrien: that sounds like a race condition waiting to happen?
[01:20] <kbulgrien> not when I am the only admin, eh?
[01:20] <fullermd> Waiting?   :p
[01:22] <kbulgrien> sure, its technically an exposure as it lowers perm tightness, but again, this user is not normal.
[01:22] <kbulgrien> all it needs is group root accessible.  other users aren't group root.
[01:22] <jelmer> kbulgrien: in that case, why doesn't your script tweak the permissions of /etc/shorewall/hosts?
[01:22] <kbulgrien> If I was working on etc/shorewall I would have used it.
[01:23] <kbulgrien> but I was trying to get status of say /etc/* for changes, so didn't need the frontend.
[01:23] <kbulgrien> It would get very messy to recurse and tweak perms for stuff like that when I didn't want to do it.
[01:23] <kbulgrien> That would be a disaster waiting to happen.
[01:24] <kbulgrien> The only problem is that I cannot avoid recurse.
[01:24] <jelmer> kbulgrien: unlike CVS, bzr versions directories too though. so if you run 'bzr status shorewall' it will recurse into that directory
[01:25] <jelmer> kbulgrien: I think (but am not sure) if you 'bzr status FILE'  it won't access the other files in the directory
[01:25] <kbulgrien> sure.
[01:25] <kbulgrien> agreed
[01:25] <kbulgrien> so I tried bzr status .
[01:26] <kbulgrien> I guess I could go find . -type f -maxdepth 1 -exec bzr status, but that seems unreasonable.
[01:26] <fullermd> Well, since bzr versions directories, I'd half expect a non-recursive status of '.' to have to touch shorewall too (not shorewall/foo necessary, but the inode of the dir at least)
[01:26] <jelmer> kbulgrien: if you give it a directory it will report the status for that directory recursively
[01:27] <kbulgrien> yes
[01:27] <kbulgrien> I was grasping at straws and am new to bzr
[01:28] <kbulgrien> I was amazed that there was no limit recursion option.
[01:29] <kbulgrien> ie. cvs recurses. but cvs has a limit recursion option.  its not the recursion that I mind.
[01:29] <kbulgrien> It would be odd for it not to recurse.
[01:31] <kbulgrien> I limit recursion a lot when I use cvs.
[01:32] <kbulgrien> Probably because I use partial checkouts a lot.  something else that I guess bzr doesn't support.
[01:33] <kbulgrien> Not being able to do partial checkouts is something I am not sure how to work around at work.
[01:34] <jelmer> kbulgrien: there are 'views', which give you some of the properties of partial checkouts
[01:35]  * jelmer gets some sleep.. clock just went from 1:59 to 3 here :)
[01:35] <kbulgrien> ok
[01:35] <kbulgrien> thanks, btw
[04:33]  * kbulgrien thinks it would be nice to be able to define a view in a "reverse" mode.  By specifying things that are NOT wanted.
[04:34] <kbulgrien> Some times the list of things you do not want to see is a lot smaller than what you do want to see.
[04:36] <fullermd> Mmph.  Views are totally not a useful substitute for partial checkouts.
[04:37] <kbulgrien> well, that is a given IMO
[04:37] <kbulgrien> I am having a hard time thinking about using a vcs without partial checkouts.
[04:39] <kbulgrien> At work, we use a big repo for a product.  S/W guys don't want to see the massive VHDL area, Tool 1 guys don't want to have to deal with Tool x stuff, but we want to be able to tag the whole project easily.
[04:40] <kbulgrien> Tool n has source files that can be 100's mb XML.  one guy works with that.  the other 10 shouldn't have to have that checked out and updated, status'd, etc.
[04:41] <kbulgrien> I wanted to convert over to bzr, but that looks daunting without partial checkouts.
[04:42] <kbulgrien> I think I heard something about externals... might have to look into that as a possibility
[04:42] <fullermd> There are not ungood reasons why 80% of the time, you don't really want partial checkouts.  And other as-good-or-better solutions to the remaining 10%.
[04:43] <fullermd> So that completely covers the...   uh...  wait.  It's been a long time since I took math, but..
[04:43] <kbulgrien> :-)
[04:49] <kbulgrien> I think it is a bug that bzr status doesn't return status just because it cannot read a file it tries to return status on.  It should report the problem and keep going IMO.
[04:53] <fullermd> That does open up the possibility of a tidal wave of spam.
[04:53] <fullermd> Of course, that could probably equally well be labelled as giving a silly answer to a silly question...
[05:31]  * kbulgrien thinks bzr status IS a tidal wave of SPAM.  I see no good reason for bzr status to give status for the WHOLE branch by default.
[05:32] <lifeless> kbulgrien: what should be the default ?
[05:32] <kbulgrien> I never (actually I suppose almost never) want status on the whole branch when I ask for status below the top of the branch.
[05:33] <kbulgrien> default should be status at current dir and below... a NORMAL recurse
[05:33] <kbulgrien> when I bzr commit a low level, it does not commit the WHOLE branch.
[05:34] <kbulgrien> (does it?)
[05:34]  * kbulgrien is a newb.  I might not have actually tried that.
[05:37] <kbulgrien> I guess bzr status . is a reasonable habit to get into, but I still don't like the default.
[05:37] <kbulgrien> I guess I can see some people might like the default in some sense.
[05:39] <kbulgrien> I say normal, like rm -rf doesn't wipe out / unless I am in root.
[05:40] <kbulgrien> This is a default that differs from the norm of most command line tools.
[06:57] <j605> hi
[06:59] <j605> i was trying to checkout a project, but i get an error. Permission denied(Public Key). I am running the command as an administrator(using sudo). Is there a way around it?
[07:40] <j605> figured it out, had to copy my .ssh directory to /root :)
[14:46] <fullermd> kbulgrien: Actually, it _does_ commit the whole tree...
[14:47] <fullermd> kbulgrien: 's a change that took me a while to get used to coming from CVS, but I was happy for it.
[14:50] <Peng> /1/14
[22:37] <poolie> hi all