[00:05] <igc> morning
[00:11]  * fullermd waves at igc.
[00:12] <igc> hi fullermd!
[00:14] <fullermd> igc: I was curious, in this post-2.1 (or almost-so) world, whether content filter stuff was perking up toward the top of people's stacks.
[00:16] <igc> fullermd: I certainly hope to get branch-specific rules into 2.2
[00:16] <igc> fullermd: what did you have in mind in particular?
[00:17] <fullermd> Oh, just my standard low-level antsyness for $Keywords$.
[00:18] <fullermd> The branch-specific rules and that collapsing bug are the only things I know offhand keeping it in "PoC curiosity" rather than "Try it on for real use".
[00:19] <fullermd> (of course, once we hit the latter, THEN we ferret out the other 15,278 things it really needs   ;)
[00:24] <fullermd> (if the answer is "nahgonna'appen this cycle", that's reasonable; just trying to keep up-to-date on my mental sense of where it falls on the List)
[00:25] <Pilky> hey got a bit of an odd theoretical question
[00:26] <fullermd> Pilky: You're in luck!  I've got an odd theoretical answer right on tap!
[00:26] <Pilky> if I have a repo with a few branches in, the revisions are stored in the repo
[00:26] <Peng> In theory, yes. :D
[00:26] <Pilky> and if I remove the branch by using standard file operations the revisions aren't lost
[00:27] <Pilky> so theoretically would it be possible to then reconstruct that branch
[00:27] <fullermd> Basically, yes.
[00:27] <Pilky> cool
[00:27] <fullermd> You lose branch-specific config bits, like the parent/push/etc branches, the nick, yada yada.
[00:28] <fullermd> But all the history revisions are available.
[00:28] <Pilky> those are minor details, it's the code that's important
[00:28] <Pilky> but yeah it just made me think after reading this blog post: http://rentzsch.tumblr.com/post/384353696/time-machine-your-version-control-safety-net
[00:28] <Peng> The "bzr heads" command from bzrtools will help you find them. (Check the help for the proper options.)
[00:29] <Peng> Then, init a branch in the repo, and do "bzr pull . -r revid:foo" with the ID you got from "heads".
[00:30] <fullermd> Yeah.  There may be cases where that config is necessarily and irreplacable, but I have a very hard time even fabricating such a situation.
[00:30] <Peng> Tags will be lost, too, but presumably you can pull most of them from one of your other branches.
[00:31] <fullermd> Oh, yeah, I forgot about that.  That's probably the most likely source of a crippling (or at least maiming) loss.
[00:31] <Peng> Who ever deletes a branch with more than 1 or 2 unique tags, though?
[00:32] <Peng> ...Well, it's uncommon, at least.
[00:32] <Pilky> well, even if you work alone, you should be pushing to a remote server frequently
[00:32] <Peng> Also you have backups, eh, ehh? :D
[00:32] <fullermd> Peng: Well, nobody, BEFORE.  Now that you've said it, 6 people will show up in the next few hours asking how to recover from it.
[00:33] <Pilky> Peng: heh I have local backups of everything, but I have my source remotely
[00:33] <fullermd> Sounds like a good time for me to leave, and let YOU field them   :p
[00:34] <Peng> fullermd: Nah, I have stuff to do. (Or at least I'll find something!) Let's foist them on Pilky, he brought it up. :D
[00:34] <Pilky> lol
[00:34] <Pilky> I didn't mention tags!
[00:34] <Pilky> you did!
[00:34] <Peng> Oh damn.
[00:34] <fullermd> You just did!
[00:35] <Peng> Anyway, I really do have a little bit of stuff I need to do. See you soon! Probably!
[00:35] <Pilky> heh as do i, that little bit of stuff being sleep
[00:35] <Pilky> thanks for the answer!
[00:58] <Peng> Sleep? I have a _lot_ of that I need to do, but I'm not going to. :P
[01:01] <fullermd> Sl...  eep?  I believe I've heard of this concept.  I thought it was a myth.
[01:02] <Peng> It's a huge waste of time. I'm working on avoiding it.
[01:02] <Peng> I keep seeing Oprah Winfrey in my wall, and I can't really do math anymore, but overall I think it's going well!
[01:04] <fullermd> Hm.  Do you think those two items are related?
[01:04] <fullermd> ...  actually, I'm not even sure which two items I'm asking about, and every permutation I can think of is more interesting than the last.
[01:05] <fullermd> So maybe we're on the same page!
[01:05] <bignose> I have a pending merge, and also some other changes that I want
[01:05] <Peng> Oprah would like some changes, too.
[01:05] <Peng> She thinks my hair sucks. :(
[01:05] <bignose> is the right way to proceed to ‘bzr shelve --all ; bzr commit --message "Merged" ; bzr unshelve --all’? or is there a better way?
[01:05] <Peng> Wait, what are you trying to do?
[01:06] <Peng> You want to commit a merge without some of the changes that exist in the working tree?
[01:06] <bignose> yes.
[01:07] <bignose> I got the merge because I tried to commit my changes, but it failed because the repository was not up-to-date in this bound branch
[01:07] <Peng> Oooooh, bound branches.
[01:07] <bignose> so, I updated, and ended up with a pending merge
[01:07] <Peng> I was wondering how you got into that situation.
[01:08] <Peng> Sorry, but I don't know the right way to get out of this situation..
[01:08] <fullermd> First, you remove commit --local...
[01:08] <Peng> Then you remove bound branches completely? >.>
[01:09] <bignose> well, it seems that shelve gets me through it. (done now.)
[01:09] <bignose> but I'm wondering if there's a less fiddly way.
[01:09] <fullermd> In a way, you're a bit screwed.  You can do OK with local commits, and you can do OK with uncommitted changes, but both at once is Bad Juju.
[01:09] <bignose> I've done no local commits.
[01:10] <bignose> (on this branch)
[01:10] <fullermd> And that shelve won't really _solve_ it.  It'll make a pretty sizable mess in history, since you're committing a merge in which you undo all the changes, and then another commit where you redo all of them.
[01:10] <fullermd> If you didn't, you wouldn't get a pending merge from an update.
[01:11] <maxb> By the same logic that 'bzr merge' will require --force if there are modifications, presumably the same ought to apply to 'bzr update' in a bound branch scenario
[01:12] <bob2> even if you have no local commits, bzr up can still cause lots of annoying conflicts
[01:12] <bob2> (and trash your local changes)
[01:12] <fullermd> Yes, but only of one set of changes.  With local commits, and uncommitted changes, you're in the same position as local changes + merge --force; you've got two things inextricably intermingled.
[01:12] <bob2> it is true
[01:13] <bob2> real unbound branches ftw
[01:13] <fullermd> Well, I don't much care about bound branches, but you can have my heavy checkouts when you pry them from my cold dead hands   :p
[01:14]  * bignose doesn't understand the difference between “heavy checkout” versus “bound branch”
[01:14] <bignose> also, I don'
[01:14] <bignose> also, I don't see what mess is created in history
[01:14] <bob2> haha
[01:14] <mkanat> bignose: The difference is just a configuration variable.
[01:15] <bignose> hmm. what I see in history is that the merge made a change, and the same change is then part of the local changes I've committed after the merge.
[01:15] <bignose> weird.
[01:15] <fullermd> Well, the difference is conceptual, and doesn't formally exist in bzr-today.
[01:16] <lifeless> fullermd: some people dispute that it exists
[01:17] <fullermd> Yes, but their mothers were hamsters, and their fathers smelt of elderberries.
[01:17] <bignose> fullermd: is there anyone else here I can talk to?
[01:18] <fullermd> No!  Now, go away, or I shall confuse you a second time!
[01:18] <bignose> heh
[01:18] <lifeless> bignose: whats the question ?
[01:21] <bignose> lifeless: about 40-50 lines back in this channel
[01:22] <bignose> lifeless: simply, is there a less-fiddly way to resolve local uncommitted changes combined with a pending merge from the remote repository?
[01:23] <lifeless> bignose: just commit
[01:24] <lifeless> bignose: bzr will know what was from the merge and what was your changes
[01:24] <lifeless> because you've done an 'update' right? - bzr should have done a pivot for you
[01:25] <bignose> what's a pivot?
[01:26] <bignose> the problem I encountered was that I want to do partial commits
[01:26] <bignose> but Bazaar won't allow that while I have a pending merge.
[01:27] <bignose> (to answer the question: yes, I did ‘bzr update’, which is where the pending merge came from.)
[01:28] <lifeless> ok, then you should shelve the stuff you aren't ready to commit, and then commit.
[01:28] <bignose> right. that worked. is there a less-fiddly way? say, to get just the merge committed?
[01:28] <bignose> or, ideally, to get the update done without resulting in a pending merge?
[01:29] <lifeless> so the update only adds a pending merge if you have done disconnected commits
[01:30] <lifeless> so one way is 'do not do disconnected commits'
[01:30] <bignose> never happened on this branch.
[01:30] <bignose> (or did it? can I tell?)
[01:30] <lifeless> someone uncommitted then on trunk
[01:30] <lifeless> either an uncommit, push --overwrite, or you did a 'local' or 'offline' commit
[01:31] <bignose> can that be detected after the repository is synchronised?
[01:33] <lifeless> not really; log -n0 may give a hint
[01:33] <fullermd> Mechanically?  Not really.  But by looking at the revision in the log, you can probably figure it out.
[01:34] <bignose> thanks for the help
[02:49] <lamalex> Hi, can someone help me figure out why one of my co-developers is getting this error when he pushes to what (should be) a shared branch? bzr: ERROR: Cannot lock LockDir(chroot-24202192:///var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock): Permission denied: "/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp": [Errno 13] Permission denied: '/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp'
[02:50] <lamalex> what should permissions be to prevent this from happening
[02:52] <fullermd> He needs to be able to write into that dir.
[02:52] <fullermd> (and some others under .bzr; probably simplest to be able to write to _everything_ under .bzr)
[02:55] <spiv> lamalex: as fullermd says; they need filesystem write permissions.  You may want to have a 'bzrrepo' group that owns all files/directories in that repo to help with that.
[02:55] <bignose> lamalex: My understanding is that (like most DVCS) Bazaar works on the assumption that there is a single owner of each repository.
[02:55] <spiv> bignose: not really
[02:56] <bignose> so, for a repository to be shared with multiple users, there should be a single account that owns the repository; and some mediator to allow other users to act as that user.
[02:56] <lamalex> spiv: so if I chgrp -R the repo, we should be ok?
[02:56] <spiv> Bazaar is perfectly happy for multiple users to be able to write to the repo, but you do need to arrange the filesystem permissions to allow that, which probably means a common group and maybe also setting a sticky bit on the group perms so new directories are owned by that shared group.
[02:56] <fullermd> lamalex: On a filesystem with SysV semantics, you'll need g+s on the directories as well.
[02:56] <bignose> e.g. the Bazaar server; or the PQM; or an account used via SSH public key.
[02:57] <lamalex> fullermd: merci
[02:57] <lamalex> bignose: that's definitely not true at all
[02:57] <lamalex> that's not even how launchpad works
[02:57] <fullermd> Launchpad works by using FM technology.
[02:58] <spiv> fullermd: fairy munchkins?
[02:58] <lamalex> :)
[02:58] <fullermd> F.....lippin' Magic.
[02:58] <Buginator> Is there a good bzr GUI client for SnowLeopard ?
[03:00] <fullermd> You can't set a snow leopard loose in a bazaar.  It would be chaos.
[03:01] <fullermd> Buginator: Explorer and/or qbzr are the general answers on most platforms.  AFAIK they work on OS X, though I don't know how hard they are to get installed.
[03:03] <Buginator> ok, thanks
[03:06] <bignose> lamalex: there's quite a lot of infrastructure difference between “multi-user repository” versus “Launchpad”
[03:09] <spiv> Need coffee.
[03:15] <slestak> hey guys.  i was just tinkering with bzr before trying to use it for real, and I would liek to start my repo over from nil
[03:15] <slestak> ive googled and looed at the docs but I do not see how to do this
[03:16] <slestak> for instance, i had my eol settings in a state i do not want them longterm, so I think I have crlf stored in the repo.
[03:18] <fullermd> Well, the general means of starting from scratch involves "rm -rf" and...  well...   starting from scratch.
[03:19] <slestak> i think that will just remove the branch,
[03:20] <slestak> i may have not even doen an init-repo, I may have just init'd a single dir
[03:21] <slestak> how can one tell the difference between a repo that holds branches and a dir in your projects folder that is just a branch of a remote project you were hacking on?
[03:21] <fullermd> info will tell you.
[03:22] <fullermd> But if you have a repo separate from the branch, that just means "rm -rf" * 2   :>
[03:22] <slestak> i use several workstaitons and I have not reconciled where my repos will live
[03:23] <meoblast001> hi
[03:23] <slestak> ok, bzr info list root as being . which is good.  And a push branch as my fileserver at home.
[03:23] <meoblast001> is there any way to read Bazaar commits from PHP?
[03:24] <slestak> let me look at bzr help info, thx for assist
[03:25] <spiv> meoblast001: not that I know of, the format is pretty complex so it would take a fair bit of effort to write the PHP to decode it.
[03:25] <meoblast001> maybe this is more of a PHP question
[03:26] <lifeless> system('bzr info')
[03:26] <meoblast001> ok
[03:26] <lifeless> ?
[03:26] <lifeless> :)
[03:26] <poolie> meoblast001: i'd probably run 'bzr log' in a subprocess with popen
[03:26] <poolie> and parse that
[03:27] <meoblast001> ok
[03:28] <poolie> lifeless: rereview https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079/+request-review pls?
[03:29] <slestak> if I have a project that is a proof of concept, but could grow large in the future, is it commonr to refactor branches from one repo to another?
[03:30] <slestak> duh, merge.  sorry for elementary questions
[03:30] <lifeless> slestak: repos don't matter for workflow: all the affect is performance.
[03:31] <slestak> lifeless: ive been really in analysis paralysis about project dir setup.  i have a mix of personal and work machines and projects.  I work on all of them on all the machines
[03:31] <lifeless> slestak: thats fine, just do it
[03:32] <lifeless> once you know how you're using it you can decide how to tune it
[03:32] <meoblast001> spiv: http://m.mysticgalaxies.com:8080/host/meoblast001/software/dontwant/bzr.php
[03:32] <meoblast001> that's the only problem :P
[03:32] <lifeless> poolie: + if tests.CaseInsCasePresFilenameFeature.available():
[03:33] <lifeless> won't work too well
[03:33] <poolie> why?
[03:33] <spiv> meoblast001: well, a <pre> tag and HTML-escaping will help a lot :)
[03:33] <meoblast001> ah, probably
[03:33] <lifeless> poolie: its already in tests :)
[03:33] <lifeless> poolie: # new coding style is for feature instances to be lowercase
[03:33] <lifeless> dunno if I'd bother with the comment
[03:33] <spiv> meoblast001: also, I think there's an xmloutput plugin
[03:34] <poolie> you can import a module from within itself
[03:34] <poolie> but it's a bit messy
[03:34] <spiv> meoblast001: so that you could do "bzr log --xml", which might be more convenient (or maybe not)
[03:34] <lifeless> oh I see you have. I wish colourisation upon these diffs
[03:35] <spiv> meoblast001: https://launchpad.net/bzr-xmloutput
[03:35] <lifeless> poolie: anyhow, I'd use the global name space rather than importing inside the feature. other than that , JFDI
[03:35] <poolie> i did that
[03:36] <poolie> just now.  i previously put it in features but then decided it was better next to its buddies
[03:36] <lifeless> then +1
[03:36] <poolie> tell me, do you think my comment in make_canonical_tree is correct?
[03:37] <poolie> if i change it to use _convert_tree i do get some failures
[03:37] <lifeless> this isn't actually guaranteed to return the class ?
[03:37] <poolie> it seems to be returning a workingtree
[03:37] <poolie> whereas this class also wants to test some revisiontrees
[03:38] <lifeless> so per_tree is a bit stubby
[03:38] <lifeless> but the intent of it is definitely to test more than working tree
[03:39] <lifeless>  Ihaven't seen make_canonical_tree before, I'd guess someone adding a helper that is either meant to be _convert_tree'd, or that wasn't really following the intent.
[03:40] <meoblast001> thanks spiv
[03:57]  * igc lunch
[03:58] <lifeless> where?
[03:58]  * lifeless WANTS
[04:03] <fullermd> Maybe he was suggesting himself AS lunch...
[04:05] <idnar> launch
[04:05] <idnar> lunchpad?
[04:05]  * fullermd . o O ( bzr pull lp:BLTandFries )
[04:35] <dOxxx> greetings
[05:23] <spiv> fullermd: hmm, have you signed the contributors agreement?  I have a feeling that you probably have, but don't see your name in the LP team.
[05:42] <dOxxx> good night all
[05:53] <lifeless> fullermd: thats cruel man... oh I could so eat that
[07:44] <igc> night all
[09:06] <gerard_> aahh
[09:07] <gerard_> admin!
[09:08] <lifeless> jelmer: ping
[09:09] <lifeless> jelmer: I'd like to ask a small favour: update the bzr-search packaging :)
[09:11] <lifeless> someone remind me to unban him tomorrow
[09:14] <gerard_> lifeless: thx
[09:19] <jml> hello
[09:19] <jml> if I want to stop receiving emails about bzr merge proposals, I have to leave ~bzr-core, right?
[10:00] <lifeless> jml: I dunno
[10:00] <lifeless> jml: perhaps you coul subscribe to the relevant branch directly and say 'dont mail me' in that subscription
[10:00] <lifeless> jelmer: ping
[10:02] <jml> lifeless, there's a thought. I'll try that.
[10:09] <lifeless> jml: ping
[10:10] <lifeless> meh
[10:10] <lifeless> jelmer: ping
[10:33] <tonfa> gug
[10:33] <tonfa> can anybody point me to the details of the protocol used by bzr to discover remote changes?
[10:41] <jpds> tonfa: I think it uses Avahi.
[10:42] <ronny> jpds: he means the dag differnce finder, not location discovery
[10:43] <ronny> lifeless: is there any spec on/doc on what exactly smart-server does?
[11:05] <spiv> ronny: not really
[11:05] <spiv> ronny: there's some basic stuff in network-protocol.txt in the developer docs
[11:06] <spiv> ronny: but that's more about the basic RPC serialisation than what the RPCs do and how to use them
[11:06] <tonfa> spiv: ok
[11:07] <spiv> ronny: the individual RPCs are implemented in bzrlib/smart/*.py, and mostly have terse docstrings explaining what they do, e.g. http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.smart.repository.SmartServerRepositoryGetParentMap.html#do_repository_request
[11:07] <spiv> tonfa: oops, I should have been addressing you :)
[11:08] <spiv> tonfa: I'd be quite happy to answer questions here (if I'm around, probably not for much longer tonight) or on the mailing list
[11:08] <tonfa> I see
[11:09] <spiv> tonfa: the RPC API assumes a fair bit of familiarity with bzrlib, really.  e.g. the Repository.get_parent_map RPC essentially works the way bzrlib.Repository.get_parent_map does.
[11:09] <spiv> tonfa: the complete list of methods can be seen in the source in bzrlib/smart/request.py
[11:10] <spiv> tonfa: I'd very much like to improve the protocol docs, but there hasn't been much motivation to so far
[11:10] <LeoNerd> I think I broke my bzr-svn cache :/
[11:10] <LeoNerd> bzr: ERROR: exceptions.KeyError: 'No such TDB entry'
[11:10] <spiv> tonfa: if you'd like to provide that motivation, great :)
[11:10] <spiv> LeoNerd: whee!
[11:11] <LeoNerd> I ctrl-C'ed it once because I ran "bzr st" instead of "svn st" by mistake, and didnt' want it to spend 5 minutes now pulling new revs... ever since then it's been broken
[11:11] <spiv> tonfa: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/smart/request.py#L489 is where the RPC registrations start
[11:11] <tonfa> spiv: btw we plan on adding early error returns for http in hg
[11:12] <spiv> tonfa: what do you mean by "early returns"?
[11:12] <spiv> You're talking about something to do with the finding the differences in the remote graph?
[11:13] <tonfa> spiv: errors happening while streaming data,
[11:13] <spiv> Oh, right.
[11:13] <tonfa> there's a discussion about that at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/doc/developers/network-protocol.txt
[11:13] <spiv> Yeah.
[11:13] <tonfa> so maybe if it works well for us you can do it too :)
[11:14] <spiv> The current bzr protocol allows that, I can't remember if the HTTP medium handles it appropriately or not.
[11:14] <spiv> Mid-stream failures are actually a fairly rare occurence for us!
[11:15] <tonfa> for us too, it's just that we then don't show a meaningful error to the user
[11:16] <spiv> Yeah.  And they are usually "interesting" errors that you'd rather have some hint about :)
[11:16] <tonfa> yes, instead of asking the user to launch wireshark
[11:16] <tonfa> or looking at the server logs
[11:16] <tonfa> which isn't always possible
[11:17] <tonfa> spiv: how do you clone the bzr repo in one line? (ie what's the url)
[11:17] <tonfa> it will be easier to browse the code if I have it locally
[11:18] <tonfa> bzr clone lp:bzr seems to work
[11:21] <spiv> tonfa: in bzr, you clone branches, not repos (a confusing terminology difference vs. hg)
[11:22] <spiv> tonfa: the canonical form is 'bzr branch URL', but 'get' and 'clone' are aliases of 'branch'.
[11:23] <tonfa> ok, so I still didn't do anything wrong :)
[11:23] <spiv> tonfa: so, that command is fine.  Note that Launchpad doesn't yet provide the smart server over HTTP, so you'll need to run provide an SSH key to Launchpad and use 'bzr lp-login' to make lp:bzr fully efficient :)
[11:23] <tonfa> I see
[11:24] <spiv> tonfa: oh,
[11:25] <spiv> tonfa: if you add -Dhpss to your command line (or debug_flags = hpss to your ~/.bazaar/bazaar.conf), then your ~/.bzr.log will show much of the smart protocol conversation
[11:25] <spiv> "hpss" stands for "high-performance smart server", our original jargon for this feature
[11:26] <spiv> Which will certainly give you a much more helpful picture than wireshark :)
[11:28] <tonfa> indeed
[11:38] <lifeless> we'
[11:39] <lifeless> re nuking clone and get for branches I believe
[11:42] <fullermd> lifeless: Well, so setup a munch proposal on lunchpad   :p
[11:43] <fullermd> spiv: This iteration, I don't think so.  Seems I went through whatever we had before it.
[11:44] <tonfa> spiv: looks like search_missing_revision_ids() was what I wanted
[11:48] <spiv> tonfa: yeah (although different operations use different codepaths sometimes, sometimes for good reasons sometimes not... :/ )
[11:49] <spiv> tonfa: we have some plans to make some relatively cheap improvements to search_missing_revision_ids, but we haven't gotten around to implementing them yet
[11:49] <spiv> tonfa: I'd be happy to compare notes with what you do in hg :)
[11:50] <spiv> But not tonight, it's getting late here.
[11:52] <fullermd> Is the fallout from the last round of contributor agreement stuff expected to arrive soon?
[11:53] <tonfa> spiv: ok, night'
[11:57] <spiv> fullermd: not sure, poolie is the one that would know
[11:58] <fullermd> Mmp.  Well, I'd guess you'd know if it were expected in the next few days...
[12:06] <spiv> fullermd: me?  Not likely, I'm essentially working part-time atm due to a newborn
[12:06] <fullermd> Oh, I thought you were older than that   :)
[12:07] <fullermd> Damn child labor laws...
[12:07] <spiv> fullermd: and I'd be superfluous to that discussion anyway, poolie understands all the requirements
[12:08]  * spiv submits a merge proposal and goes to bed
[12:08] <fullermd> Well, I was just thinking if it were about to show up, I'd hold off for it instead of sending in the current one.
[12:09] <fullermd> Owell.
[12:12] <spiv> fullermd: yeah, I understand.  Unfortunately I really have no insight to offer :)
[12:14] <fullermd> Hm.  irc.ubuntu.com is a CNAME for freenode, but isn't it still a little weird listing it in README?
[12:17] <fullermd> spiv: 'k, sent.
[13:11] <rubbs> morning all!
[14:30] <quicksilver> can two completely unrelated projects live in the same shared repo?
[14:30] <beuno> quicksilver, yes
[14:30] <beuno> they just won't share revisions
[14:31] <quicksilver> good.
[14:31] <quicksilver> Can I somehow make bzr push push stuff up as g+w ?
[14:31] <quicksilver> my umask on that machine is actually 002
[14:32] <quicksilver> but newly pushed branches still go up as g-w
[14:32] <quicksilver> (using bzr+ssh, that is)
[14:36] <quicksilver> I remember some discussion years about about sftp ignoring umask
[14:36] <quicksilver> but that was considered to be a shortcoming of sftp
[14:37] <quicksilver> and I thought one of the good things about bzr+ssh was going to be fixing it.
[14:37] <mzz> hmm! I haven't actually done this recently, but are you sure the shell startup script that sets your umask actually gets run if you use bzr+ssh?
[14:37] <mzz> (I'd try putting a "touch /tmp/this-is-reached" in whatever script this is)
[14:38] <mzz> I don't know if bzr+ssh sets umask itself
[14:38] <mzz> but if whatever's setting your umask to 002 isn't reached that'd obviously cause this :)
[14:45] <quicksilver> that's true enough.
[14:45] <quicksilver> No, I'm not sure.
[14:49] <fullermd> quicksilver: bzr preserves the +/-w based on the permissions of the directory.
[14:49] <fullermd> sftp doesn't ignore umask; the problem there is that it refuses to set the set[ug]id bits.
[14:50] <quicksilver> fullermd: but the enclosing directory is drwxrwsr-x
[14:51] <quicksilver> fullermd: and new branches are getting pushed up as drwxr-sr-x
[14:51] <fullermd> There's some uncertainty as to which directory it bases on.  It might be .bzr itself, or .bzr/repository, rather than the packs/ directory.
[14:51] <quicksilver> setgid is being preserved, but not g+w
[14:51] <fullermd> Oh, new branches.  Yes, bzr doesn't itself muck with perms on those.
[14:51] <quicksilver> right, new branches.
[14:52] <quicksilver> although perhaps your implication is that if we switch this to a shared repo, which we are about to do anyway, this problem will go away?
[14:52] <fullermd> Probably an issue with which [parts of] rc files the shell reads in interactive vs. batch environments.
[14:52] <fullermd> No, the packs for the revs would get the right perms, but the branch files themselves will still wind up umask-based.
[16:35] <LeoNerd> Is there a way to alter the number of lines of context 'bzr shelve' uses? I have two unrelated changes in one file that are just close enough that they come out as one diff chunk... I'd like it to be two
[16:39] <Meths> I imagine the solution would be to shelve one change, then make the second and shelve that but I may be corrected.
[16:41] <fullermd> If you were thinking it before the fact, you wouldn't need shelve at all  ;p
[16:41] <fullermd> AFAIK there's no way to split patch hunks in shelve.  There's some 'edit'-ish functionality, but I don't know how easy it would be to fake up what you want.
[16:42] <LeoNerd> It's not that I want to split it, as such
[16:42] <LeoNerd> If you use  bzr diff --diff-options="-c 1"  then they're split OK
[18:42] <poolie> fullermd: re contributor agreement updates; i do expect it soon but it's unpredictable
[18:43] <mtaylor> NEAT!
[18:43] <mtaylor> bzr: ERROR: syntax error: line 1, column 0
[18:58] <nosklo> can't use a proxy, how do I get meaningful error message?
[19:10] <nosklo> lost connection, somebody answered?
[19:10] <rubbs> no
[19:10] <rubbs> what is your question again? I'm not quite understanding it
[19:14] <nosklo> I'm trying to use a proxy
[19:14] <nosklo> so I can branch some code
[19:14] <nosklo> But when trying to do so, bzr returns a cryptic error which I can't make sense of
[19:15] <rubbs> can you post the error on pastebin?
[19:15] <rubbs> !pastebin
[19:15] <rubbs> I can't stay long (I have a meeting) but someone here can usually help if they can see the full error.
[19:16] <nosklo> rubbs: http://paste.ubuntu.com/374922/
[19:17] <nosklo> I don't know exactly *what* is not known
[19:17] <nosklo> wget downloads fine
[19:17] <nosklo> also using bzr alternatives like git and mercurial works
[19:17] <rubbs> hmmm
[19:17] <nosklo> I've tried to setup some proxy
[19:17] <nosklo> in the bzr config files
[19:18] <nosklo> but the bzr docs are hard to find
[19:18] <nosklo> I can't find any mention of how you configure the proxy
[19:18] <nosklo> so I'm doing guesswork
[19:18] <rubbs> not sure how to help :(
[19:18] <rubbs> any dev's in the house now?
[19:20] <rubbs> oh... before I go, have you checked .bzr.log? it's usually in your home directory, or my documents if on windows.
[19:20] <rubbs> that might give you more info, it can help others on here too.
[19:20] <nosklo> oh
[19:20] <nosklo> COOL
[19:20] <rubbs> but I have to go. I'll be back in an hour or so.
[19:20] <luks> it would be easier to use plain http url
[19:21] <luks> I think the lp: directory service does some non-http API calls
[19:21] <nosklo> luks: I've tried that and got a different error
[19:22] <nosklo> luks: http://paste.ubuntu.com/374927/
[19:22] <luks> http://bazaar.launchpad.net/~washort/ecru/trunk is the right url to use
[19:23] <nosklo> same thing :(
[19:23] <nosklo> http://paste.ubuntu.com/374930/
[19:23] <luks> not code
[19:23] <luks> bazaar
[19:23] <luks> bazaar.launchpad.net
[19:23] <nosklo> oh
[19:23] <nosklo> that works!
[19:24] <nosklo> luks: thanks
[19:24] <luks> code.launchpad.net is the launchpad website
[19:24] <luks> and it seems to force you to use https
[19:24] <luks> which you can't do over a http proxy
[19:24] <nosklo> https should work on my proxy
[19:24]  * nosklo tests
[19:25] <nosklo> yeah, wget can use https just fine
[19:26] <nosklo> wget https://code.launchpad.net/ecru # works
[19:26] <luks> no idea then
[19:27] <luks> I prefer to use direct http/bzr+ssh URLs for launchpad to avoid problems like this
[19:27] <nosklo> the error on .bzr.log is InvalidHttpResponse: Invalid http response for https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format: Unable to handle http code 502: Proxy Error ( The parameter is incorrect.  )
[19:28] <nosklo> however wget https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format works
[19:28] <nosklo> returns a file with "Bazaar-NG meta directory, format 1" in it
[19:28] <luks> I don't know how http/https proxies work
[19:29] <luks> but maybe bzr is doing something stupid like using http to talk to a https server
[19:29] <nosklo> unfortunately I'm forced on this proxy in my company
[19:30] <luks> do you have the https_proxy environment variable set?
[19:30] <nosklo> yes
[19:31] <nosklo> that's how wget works btw
[19:31] <nosklo> if I remove the var, wget stops working
[19:31] <luks> ah
[19:31] <luks> (as I said, I don't know much about proxies, so just guessing)
[19:32] <nosklo> me neither, but I'm trying to debug bzr anyway :) I'm trying to read the source code and reproduce the error on python
[19:32] <nosklo> so I can ask on #python instead :)
[19:32] <luks> jam might help :)
[19:33] <jam> hi luks
[19:33] <luks> hey
[19:33] <poolie> hi jam, luks
[19:33] <nosklo> jam: I'm having some issue when using a https proxy with bzr, can you help me debug?
[19:33] <jam> hey poolie, nice to see you so early again :)
[19:40] <nosklo> Hm I think I figured out
[19:40] <nosklo> reading the logs of the proxy server
[19:40] <nosklo> bzr is sending some unprintable bytes instead of CONNECT
[19:41] <nosklo> I think it is trying to talk SSL to the proxy (it's a http proxy that can handle https)
[19:41] <nosklo> wget sends a CONNECT 443 first
[19:41] <jam> nosklo: we have you provide the format
[19:41] <jam> so https_proxy=http://proxy.com:PORT
[19:41] <jam> etcc
[19:41] <jam> etc
[19:41] <nosklo> I did it
[19:44] <jam> nosklo: you can also try running "bzr -Dhttp COMMAND" which should add some debugging information to ~/.bzr.log
[19:44] <jam> which might help figure out when we are trying to connect, and how
[19:45] <jam> also, what version of bzr?
[19:45] <nosklo> I'm gathering the info...
[19:45] <nosklo> 1.13.1-1
[19:51] <nosklo> http://paste.pocoo.org/show/177244/
[19:54] <jam> well if you can, I would recommend upgrading to at least 2.0
[19:54] <jam> I think we've had some recent work done on the proxy support
[19:54] <jam> you can get it from our ppa
[19:55] <nosklo> I will upgrade.
[19:55] <jam> https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
[19:56] <nosklo> I'm on jaunty :)
[19:56] <nosklo> but okay
[19:56] <jam> I would have thought jaunty had newer than 1.13...
[19:56] <jam> but sure
[19:56] <jam> same archive has hardy => lucid
[20:03] <KhaZ> Hello: I'm having an issue pushing to a remote repository - it says they're not compatible due to rich root support.  How can I fix this?
[20:04] <KhaZ> Ah; nevermind.  bzr upgrade worked, on a hunch.
[22:13] <jelmer> poolie, hi
[22:15] <poolie> hi jelmer
[22:21] <jelmer> poolie: Should I request a sync of 2.1rc2 to lucid yet or would you prefer to wait until 2.1 itself is out?
[22:23] <poolie> i agree with james_w, we should sync now
[22:24] <jelmer> ok
[22:24] <james_w> jelmer: I can pull the trigger if it's just bzr
[22:24] <james_w> or if you tell me what else
[22:24] <poolie> you'll probably need some plugins too
[22:25] <jelmer> james_w: all of the bzr world basically :-)
[22:25] <fullermd> What's happening with 2.1 anyway?  I thought it was to be released yesterday or today...
[22:25] <james_w> just a list of source packages will do then
[22:26] <james_w> saves you filing all the bugs
[22:26] <poolie> it will be soon, i think jam was busy with somethig else
[22:27] <jam> poolie, james_w: Yeah it was supposed to be yesterday or today, but today I got caught up with $OTHER
[22:28] <fullermd> Ah, 'k.
[22:30] <jelmer> james_w: oh, it actually seems like most things are already synced
[22:30] <jelmer> (looking at http://qa.ubuntuwire.com/mdt/bazaar.html)
[22:31] <james_w> ah, I'd forgotten about that page
[22:31] <jelmer> james_w: can you just sync bzr from experimental?
[22:33] <james_w> there's no bzrtools release to go with it>
[22:33] <poolie> i think there is?
[22:33] <fullermd> There's a 2.1.0 out.
[22:34] <poolie> at least upstream, announced 5 feb
[22:36] <james_w> jelmer: do we not want that first?
[22:37] <jelmer> james_w: hmm, that's a good point. I guess I'm not running the packaged version on my debian box, otherwise I would've noticed
[22:37] <jelmer> I'll upload a newer version of bzrtools to experimental as well.
[22:37] <james_w> thanks
[22:37] <james_w> any chance of a bzr-builddeb upload as well?
[22:38] <jelmer> sure
[22:39] <jelmer> I think the changelog entry needs some work though..
[22:40] <james_w> I'm writing it now :-)
[22:47] <lifeless> jelmer: hi
[22:47] <lifeless> jelmer: bzr-search :) please pretty please please.
[22:47] <jelmer> lifeless, hey
[22:47] <jelmer> lifeless, can you explain what you would like me to do to it exactly?
[22:47] <jelmer> :-)
[22:47] <lifeless> package a newer snapshot of trunk
[22:47] <lifeless> the ~70 snapshot that is packaged is broken with CHK repos
[22:48] <lifeless> its fixed in trunk, and we're getting lots of bugs from packaged-bzr-search users.
[22:48] <jelmer> lifeless: revno 77 is the latest version packaged
[22:49] <jelmer> at least according to my debian qa page
[22:49] <lifeless> interesting
[22:49] <lifeless> oh, I see - karmic.
[22:49] <lifeless> So I think what I mean is 'sob, karmic is bust'
[22:50] <lifeless> we could look at an SRU I guess
[22:53] <james_w> jelmer: lp:bzr-builddeb should be ok for an upload now
[22:53] <jelmer> james_w: thanks
[22:53] <jelmer> lifeless: ouch :-/
[22:54] <jelmer> james_w: wow, that's a lot of bugs that are fix released now :-)
[22:55] <lifeless> bzr-search | 1.7.0~bzr70-1 | karmic/universe | source, all
[22:55] <james_w> some have been fixed for ages, it's just not clear exactly what constitutes a release
[22:56] <jelmer> james_w:   * Upload to lucid.
[22:56] <jelmer> that's not quite true :-)
[22:57] <james_w> oh yeah :-)
[22:57] <james_w> + (indirectly)
[23:36] <jelmer> james_w: the removal of the dependency on bzrtools isn't mentioned in changelog, did it make it into 2.3?
[23:43] <jelmer> james_w: Looks like it, I'll update changelog
[23:49] <lifeless> james_w: ping
[23:49] <lifeless> james_w: I don't understand why import-upstream would delete stuff (re your calling it dhmake
[23:50] <lifeless> james_w: in fact, bzrtools already has a tarball import; I guess I'd like to see that tarball import do the pristine tar stuff and then builddeb could lose that code altogether (or move it from both into core)