[00:05] morning [00:11] * fullermd waves at igc. [00:12] hi fullermd! [00:14] 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] fullermd: I certainly hope to get branch-specific rules into 2.2 [00:16] fullermd: what did you have in mind in particular? [00:17] Oh, just my standard low-level antsyness for $Keywords$. [00:18] 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] (of course, once we hit the latter, THEN we ferret out the other 15,278 things it really needs ;) [00:24] (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] hey got a bit of an odd theoretical question [00:26] Pilky: You're in luck! I've got an odd theoretical answer right on tap! [00:26] if I have a repo with a few branches in, the revisions are stored in the repo [00:26] In theory, yes. :D [00:26] and if I remove the branch by using standard file operations the revisions aren't lost [00:27] so theoretically would it be possible to then reconstruct that branch [00:27] Basically, yes. [00:27] cool [00:27] You lose branch-specific config bits, like the parent/push/etc branches, the nick, yada yada. [00:28] But all the history revisions are available. [00:28] those are minor details, it's the code that's important [00:28] 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] The "bzr heads" command from bzrtools will help you find them. (Check the help for the proper options.) [00:29] Then, init a branch in the repo, and do "bzr pull . -r revid:foo" with the ID you got from "heads". [00:30] 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] Tags will be lost, too, but presumably you can pull most of them from one of your other branches. [00:31] Oh, yeah, I forgot about that. That's probably the most likely source of a crippling (or at least maiming) loss. [00:31] Who ever deletes a branch with more than 1 or 2 unique tags, though? [00:32] ...Well, it's uncommon, at least. [00:32] well, even if you work alone, you should be pushing to a remote server frequently [00:32] Also you have backups, eh, ehh? :D [00:32] 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] Peng: heh I have local backups of everything, but I have my source remotely [00:33] Sounds like a good time for me to leave, and let YOU field them :p [00:34] 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] lol [00:34] I didn't mention tags! [00:34] you did! [00:34] Oh damn. [00:34] You just did! [00:35] Anyway, I really do have a little bit of stuff I need to do. See you soon! Probably! [00:35] heh as do i, that little bit of stuff being sleep [00:35] thanks for the answer! [00:58] Sleep? I have a _lot_ of that I need to do, but I'm not going to. :P [01:01] Sl... eep? I believe I've heard of this concept. I thought it was a myth. [01:02] It's a huge waste of time. I'm working on avoiding it. [01:02] 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] Hm. Do you think those two items are related? [01:04] ... 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] So maybe we're on the same page! [01:05] I have a pending merge, and also some other changes that I want [01:05] Oprah would like some changes, too. [01:05] She thinks my hair sucks. :( [01:05] 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] Wait, what are you trying to do? [01:06] You want to commit a merge without some of the changes that exist in the working tree? [01:06] yes. [01:07] 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] Oooooh, bound branches. [01:07] so, I updated, and ended up with a pending merge [01:07] I was wondering how you got into that situation. [01:08] Sorry, but I don't know the right way to get out of this situation.. [01:08] First, you remove commit --local... [01:08] Then you remove bound branches completely? >.> [01:09] well, it seems that shelve gets me through it. (done now.) [01:09] but I'm wondering if there's a less fiddly way. [01:09] 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] I've done no local commits. [01:10] (on this branch) [01:10] 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] If you didn't, you wouldn't get a pending merge from an update. [01:11] 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] even if you have no local commits, bzr up can still cause lots of annoying conflicts [01:12] (and trash your local changes) [01:12] 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] it is true [01:13] real unbound branches ftw [01:13] 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] also, I don' [01:14] also, I don't see what mess is created in history [01:14] haha [01:14] bignose: The difference is just a configuration variable. [01:15] 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] weird. [01:15] Well, the difference is conceptual, and doesn't formally exist in bzr-today. [01:16] fullermd: some people dispute that it exists [01:17] Yes, but their mothers were hamsters, and their fathers smelt of elderberries. [01:17] fullermd: is there anyone else here I can talk to? [01:18] No! Now, go away, or I shall confuse you a second time! [01:18] heh [01:18] bignose: whats the question ? [01:21] lifeless: about 40-50 lines back in this channel [01:22] lifeless: simply, is there a less-fiddly way to resolve local uncommitted changes combined with a pending merge from the remote repository? [01:23] bignose: just commit [01:24] bignose: bzr will know what was from the merge and what was your changes [01:24] because you've done an 'update' right? - bzr should have done a pivot for you [01:25] what's a pivot? [01:26] the problem I encountered was that I want to do partial commits [01:26] but Bazaar won't allow that while I have a pending merge. [01:27] (to answer the question: yes, I did ‘bzr update’, which is where the pending merge came from.) [01:28] ok, then you should shelve the stuff you aren't ready to commit, and then commit. [01:28] right. that worked. is there a less-fiddly way? say, to get just the merge committed? [01:28] or, ideally, to get the update done without resulting in a pending merge? [01:29] so the update only adds a pending merge if you have done disconnected commits [01:30] so one way is 'do not do disconnected commits' [01:30] never happened on this branch. [01:30] (or did it? can I tell?) [01:30] someone uncommitted then on trunk [01:30] either an uncommit, push --overwrite, or you did a 'local' or 'offline' commit [01:31] can that be detected after the repository is synchronised? [01:33] not really; log -n0 may give a hint [01:33] Mechanically? Not really. But by looking at the revision in the log, you can probably figure it out. [01:34] thanks for the help === khmarbaise_ is now known as khmarbaise [02:49] 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] what should permissions be to prevent this from happening [02:52] He needs to be able to write into that dir. [02:52] (and some others under .bzr; probably simplest to be able to write to _everything_ under .bzr) [02:55] 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] lamalex: My understanding is that (like most DVCS) Bazaar works on the assumption that there is a single owner of each repository. [02:55] bignose: not really [02:56] 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] spiv: so if I chgrp -R the repo, we should be ok? [02:56] 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] lamalex: On a filesystem with SysV semantics, you'll need g+s on the directories as well. [02:56] e.g. the Bazaar server; or the PQM; or an account used via SSH public key. [02:57] fullermd: merci [02:57] bignose: that's definitely not true at all [02:57] that's not even how launchpad works [02:57] Launchpad works by using FM technology. [02:58] fullermd: fairy munchkins? [02:58] :) [02:58] F.....lippin' Magic. [02:58] Is there a good bzr GUI client for SnowLeopard ? [03:00] You can't set a snow leopard loose in a bazaar. It would be chaos. [03:01] 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] ok, thanks [03:06] lamalex: there's quite a lot of infrastructure difference between “multi-user repository” versus “Launchpad” === JFo is now known as JFo-afk [03:09] Need coffee. [03:15] 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] ive googled and looed at the docs but I do not see how to do this [03:16] 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] Well, the general means of starting from scratch involves "rm -rf" and... well... starting from scratch. [03:19] i think that will just remove the branch, [03:20] i may have not even doen an init-repo, I may have just init'd a single dir [03:21] 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] info will tell you. [03:22] But if you have a repo separate from the branch, that just means "rm -rf" * 2 :> [03:22] i use several workstaitons and I have not reconciled where my repos will live [03:23] hi [03:23] ok, bzr info list root as being . which is good. And a push branch as my fileserver at home. [03:23] is there any way to read Bazaar commits from PHP? [03:24] let me look at bzr help info, thx for assist [03:25] 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] maybe this is more of a PHP question [03:26] system('bzr info') [03:26] ok [03:26] ? [03:26] :) [03:26] meoblast001: i'd probably run 'bzr log' in a subprocess with popen [03:26] and parse that [03:27] ok [03:28] lifeless: rereview https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079/+request-review pls? [03:29] 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] duh, merge. sorry for elementary questions [03:30] slestak: repos don't matter for workflow: all the affect is performance. [03:31] 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] slestak: thats fine, just do it [03:32] once you know how you're using it you can decide how to tune it [03:32] spiv: http://m.mysticgalaxies.com:8080/host/meoblast001/software/dontwant/bzr.php [03:32] that's the only problem :P [03:32] poolie: + if tests.CaseInsCasePresFilenameFeature.available(): [03:33] won't work too well [03:33] why? [03:33] meoblast001: well, a

 tag and HTML-escaping will help a lot :)
[03:33]  ah, probably
[03:33]  poolie: its already in tests :)
[03:33]  poolie: # new coding style is for feature instances to be lowercase
[03:33]  dunno if I'd bother with the comment
[03:33]  meoblast001: also, I think there's an xmloutput plugin
[03:34]  you can import a module from within itself
[03:34]  but it's a bit messy
[03:34]  meoblast001: so that you could do "bzr log --xml", which might be more convenient (or maybe not)
[03:34]  oh I see you have. I wish colourisation upon these diffs
[03:35]  meoblast001: https://launchpad.net/bzr-xmloutput
[03:35]  poolie: anyhow, I'd use the global name space rather than importing inside the feature. other than that , JFDI
[03:35]  i did that
[03:36]  just now.  i previously put it in features but then decided it was better next to its buddies
[03:36]  then +1
[03:36]  tell me, do you think my comment in make_canonical_tree is correct?
[03:37]  if i change it to use _convert_tree i do get some failures
[03:37]  this isn't actually guaranteed to return the class ?
[03:37]  it seems to be returning a workingtree
[03:37]  whereas this class also wants to test some revisiontrees
[03:38]  so per_tree is a bit stubby
[03:38]  but the intent of it is definitely to test more than working tree
[03:39]   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]  thanks spiv
[03:57]  * igc lunch
[03:58]  where?
[03:58]  * lifeless WANTS
[04:03]  Maybe he was suggesting himself AS lunch...
[04:05]  launch
[04:05]  lunchpad?
[04:05]  * fullermd . o O ( bzr pull lp:BLTandFries )
[04:35]  greetings
[05:23]  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]  good night all
[05:53]  fullermd: thats cruel man... oh I could so eat that
[07:44]  night all
[09:06]  aahh
[09:07]  admin!
[09:08]  jelmer: ping
[09:09]  jelmer: I'd like to ask a small favour: update the bzr-search packaging :)
[09:11]  someone remind me to unban him tomorrow
[09:14]  lifeless: thx
[09:19]  hello
[09:19]  if I want to stop receiving emails about bzr merge proposals, I have to leave ~bzr-core, right?
[10:00]  jml: I dunno
[10:00]  jml: perhaps you coul subscribe to the relevant branch directly and say 'dont mail me' in that subscription
[10:00]  jelmer: ping
[10:02]  lifeless, there's a thought. I'll try that.
[10:09]  jml: ping
[10:10]  meh
[10:10]  jelmer: ping
[10:33]  gug
[10:33]  can anybody point me to the details of the protocol used by bzr to discover remote changes?
[10:41]  tonfa: I think it uses Avahi.
[10:42]  jpds: he means the dag differnce finder, not location discovery
[10:43]  lifeless: is there any spec on/doc on what exactly smart-server does?
[11:05]  ronny: not really
[11:05]  ronny: there's some basic stuff in network-protocol.txt in the developer docs
[11:06]  ronny: but that's more about the basic RPC serialisation than what the RPCs do and how to use them
[11:06]  spiv: ok
[11:07]  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]  tonfa: oops, I should have been addressing you :)
[11:08]  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]  I see
[11:09]  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]  tonfa: the complete list of methods can be seen in the source in bzrlib/smart/request.py
[11:10]  tonfa: I'd very much like to improve the protocol docs, but there hasn't been much motivation to so far
[11:10]  I think I broke my bzr-svn cache :/
[11:10]  bzr: ERROR: exceptions.KeyError: 'No such TDB entry'
[11:10]  tonfa: if you'd like to provide that motivation, great :)
[11:10]  LeoNerd: whee!
[11:11]  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]  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]  spiv: btw we plan on adding early error returns for http in hg
[11:12]  tonfa: what do you mean by "early returns"?
[11:12]  You're talking about something to do with the finding the differences in the remote graph?
[11:13]  spiv: errors happening while streaming data,
[11:13]  Oh, right.
[11:13]  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]  Yeah.
[11:13]  so maybe if it works well for us you can do it too :)
[11:14]  The current bzr protocol allows that, I can't remember if the HTTP medium handles it appropriately or not.
[11:14]  Mid-stream failures are actually a fairly rare occurence for us!
[11:15]  for us too, it's just that we then don't show a meaningful error to the user
[11:16]  Yeah.  And they are usually "interesting" errors that you'd rather have some hint about :)
[11:16]  yes, instead of asking the user to launch wireshark
[11:16]  or looking at the server logs
[11:16]  which isn't always possible
[11:17]  spiv: how do you clone the bzr repo in one line? (ie what's the url)
[11:17]  it will be easier to browse the code if I have it locally
[11:18]  bzr clone lp:bzr seems to work
[11:21]  tonfa: in bzr, you clone branches, not repos (a confusing terminology difference vs. hg)
[11:22]  tonfa: the canonical form is 'bzr branch URL', but 'get' and 'clone' are aliases of 'branch'.
[11:23]  ok, so I still didn't do anything wrong :)
[11:23]  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]  I see
[11:24]  tonfa: oh,
[11:25]  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]  "hpss" stands for "high-performance smart server", our original jargon for this feature
[11:26]  Which will certainly give you a much more helpful picture than wireshark :)
[11:28]  indeed
=== salgado is now known as salgado-afk
[11:38]  we'
[11:39]  re nuking clone and get for branches I believe
[11:42]  lifeless: Well, so setup a munch proposal on lunchpad   :p
[11:43]  spiv: This iteration, I don't think so.  Seems I went through whatever we had before it.
[11:44]  spiv: looks like search_missing_revision_ids() was what I wanted
[11:48]  tonfa: yeah (although different operations use different codepaths sometimes, sometimes for good reasons sometimes not... :/ )
[11:49]  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]  tonfa: I'd be happy to compare notes with what you do in hg :)
[11:50]  But not tonight, it's getting late here.
[11:52]  Is the fallout from the last round of contributor agreement stuff expected to arrive soon?
[11:53]  spiv: ok, night'
[11:57]  fullermd: not sure, poolie is the one that would know
[11:58]  Mmp.  Well, I'd guess you'd know if it were expected in the next few days...
=== mrevell is now known as mrevell-lunch
[12:06]  fullermd: me?  Not likely, I'm essentially working part-time atm due to a newborn
[12:06]  Oh, I thought you were older than that   :)
[12:07]  Damn child labor laws...
[12:07]  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]  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]  Owell.
[12:12]  fullermd: yeah, I understand.  Unfortunately I really have no insight to offer :)
[12:14]  Hm.  irc.ubuntu.com is a CNAME for freenode, but isn't it still a little weird listing it in README?
[12:17]  spiv: 'k, sent.
[13:11]  morning all!
=== mrevell-lunch is now known as mrevell
=== jml is now known as jml-afk
=== jml-afk is now known as jml
[14:30]  can two completely unrelated projects live in the same shared repo?
[14:30]  quicksilver, yes
[14:30]  they just won't share revisions
[14:31]  good.
[14:31]  Can I somehow make bzr push push stuff up as g+w ?
[14:31]  my umask on that machine is actually 002
[14:32]  but newly pushed branches still go up as g-w
[14:32]  (using bzr+ssh, that is)
[14:36]  I remember some discussion years about about sftp ignoring umask
[14:36]  but that was considered to be a shortcoming of sftp
[14:37]  and I thought one of the good things about bzr+ssh was going to be fixing it.
[14:37]  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]  (I'd try putting a "touch /tmp/this-is-reached" in whatever script this is)
[14:38]  I don't know if bzr+ssh sets umask itself
[14:38]  but if whatever's setting your umask to 002 isn't reached that'd obviously cause this :)
[14:45]  that's true enough.
[14:45]  No, I'm not sure.
[14:49]  quicksilver: bzr preserves the +/-w based on the permissions of the directory.
[14:49]  sftp doesn't ignore umask; the problem there is that it refuses to set the set[ug]id bits.
[14:50]  fullermd: but the enclosing directory is drwxrwsr-x
[14:51]  fullermd: and new branches are getting pushed up as drwxr-sr-x
[14:51]  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]  setgid is being preserved, but not g+w
[14:51]  Oh, new branches.  Yes, bzr doesn't itself muck with perms on those.
[14:51]  right, new branches.
[14:52]  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]  Probably an issue with which [parts of] rc files the shell reads in interactive vs. batch environments.
[14:52]  No, the packs for the revs would get the right perms, but the branch files themselves will still wind up umask-based.
=== JFo-afk is now known as JFo
=== salgado-afk is now known as salgado
=== salgado is now known as salgado-brb
[16:35]  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]  I imagine the solution would be to shelve one change, then make the second and shelve that but I may be corrected.
[16:41]  If you were thinking it before the fact, you wouldn't need shelve at all  ;p
[16:41]  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]  It's not that I want to split it, as such
[16:42]  If you use  bzr diff --diff-options="-c 1"  then they're split OK
=== deryck is now known as deryck[lunch]
=== IslandUsurper is now known as IslandUsurper-af
=== deryck[lunch] is now known as deryck
=== radoe_ is now known as radoe
[18:42]  fullermd: re contributor agreement updates; i do expect it soon but it's unpredictable
[18:43]  NEAT!
[18:43]  bzr: ERROR: syntax error: line 1, column 0
=== IslandUsurper-af is now known as IslandUsurper
[18:58]  can't use a proxy, how do I get meaningful error message?
[19:10]  lost connection, somebody answered?
[19:10]  no
[19:10]  what is your question again? I'm not quite understanding it
[19:14]  I'm trying to use a proxy
[19:14]  so I can branch some code
[19:14]  But when trying to do so, bzr returns a cryptic error which I can't make sense of
[19:15]  can you post the error on pastebin?
[19:15]  !pastebin
[19:15]  For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[19:15]  I can't stay long (I have a meeting) but someone here can usually help if they can see the full error.
[19:16]  rubbs: http://paste.ubuntu.com/374922/
[19:17]  I don't know exactly *what* is not known
[19:17]  wget downloads fine
[19:17]  also using bzr alternatives like git and mercurial works
[19:17]  hmmm
[19:17]  I've tried to setup some proxy
[19:17]  in the bzr config files
=== salgado-brb is now known as salgado
[19:18]  but the bzr docs are hard to find
[19:18]  I can't find any mention of how you configure the proxy
[19:18]  so I'm doing guesswork
[19:18]  not sure how to help :(
[19:18]  any dev's in the house now?
[19:20]  oh... before I go, have you checked .bzr.log? it's usually in your home directory, or my documents if on windows.
[19:20]  that might give you more info, it can help others on here too.
[19:20]  oh
[19:20]  COOL
[19:20]  but I have to go. I'll be back in an hour or so.
[19:20]  it would be easier to use plain http url
[19:21]  I think the lp: directory service does some non-http API calls
[19:21]  luks: I've tried that and got a different error
[19:22]  luks: http://paste.ubuntu.com/374927/
[19:22]  http://bazaar.launchpad.net/~washort/ecru/trunk is the right url to use
[19:23]  same thing :(
[19:23]  http://paste.ubuntu.com/374930/
[19:23]  not code
[19:23]  bazaar
[19:23]  bazaar.launchpad.net
[19:23]  oh
[19:23]  that works!
[19:24]  luks: thanks
[19:24]  code.launchpad.net is the launchpad website
[19:24]  and it seems to force you to use https
[19:24]  which you can't do over a http proxy
[19:24]  https should work on my proxy
[19:24]  * nosklo tests
[19:25]  yeah, wget can use https just fine
[19:26]  wget https://code.launchpad.net/ecru # works
[19:26]  no idea then
[19:27]  I prefer to use direct http/bzr+ssh URLs for launchpad to avoid problems like this
[19:27]  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]  however wget https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format works
[19:28]  returns a file with "Bazaar-NG meta directory, format 1" in it
[19:28]  I don't know how http/https proxies work
[19:29]  but maybe bzr is doing something stupid like using http to talk to a https server
[19:29]  unfortunately I'm forced on this proxy in my company
[19:30]  do you have the https_proxy environment variable set?
[19:30]  yes
[19:31]  that's how wget works btw
[19:31]  if I remove the var, wget stops working
[19:31]  ah
[19:31]  (as I said, I don't know much about proxies, so just guessing)
[19:32]  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]  so I can ask on #python instead :)
[19:32]  jam might help :)
[19:33]  hi luks
[19:33]  hey
[19:33]  hi jam, luks
[19:33]  jam: I'm having some issue when using a https proxy with bzr, can you help me debug?
[19:33]  hey poolie, nice to see you so early again :)
[19:40]  Hm I think I figured out
[19:40]  reading the logs of the proxy server
[19:40]  bzr is sending some unprintable bytes instead of CONNECT
[19:41]  I think it is trying to talk SSL to the proxy (it's a http proxy that can handle https)
[19:41]  wget sends a CONNECT 443 first
[19:41]  nosklo: we have you provide the format
[19:41]  so https_proxy=http://proxy.com:PORT
[19:41]  etcc
[19:41]  etc
[19:41]  I did it
[19:44]  nosklo: you can also try running "bzr -Dhttp COMMAND" which should add some debugging information to ~/.bzr.log
[19:44]  which might help figure out when we are trying to connect, and how
[19:45]  also, what version of bzr?
[19:45]  I'm gathering the info...
[19:45]  1.13.1-1
[19:51]  http://paste.pocoo.org/show/177244/
[19:54]  well if you can, I would recommend upgrading to at least 2.0
[19:54]  I think we've had some recent work done on the proxy support
[19:54]  you can get it from our ppa
[19:55]  I will upgrade.
[19:55]  https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
[19:56]  I'm on jaunty :)
[19:56]  but okay
[19:56]  I would have thought jaunty had newer than 1.13...
[19:56]  but sure
[19:56]  same archive has hardy => lucid
[20:03]  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]  Ah; nevermind.  bzr upgrade worked, on a hunch.
=== webchick is now known as webchick|supper
[22:13]  poolie, hi
[22:15]  hi jelmer
[22:21]  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]  i agree with james_w, we should sync now
[22:24]  ok
[22:24]  jelmer: I can pull the trigger if it's just bzr
[22:24]  or if you tell me what else
[22:24]  you'll probably need some plugins too
[22:25]  james_w: all of the bzr world basically :-)
[22:25]  What's happening with 2.1 anyway?  I thought it was to be released yesterday or today...
[22:25]  just a list of source packages will do then
[22:26]  saves you filing all the bugs
[22:26]  it will be soon, i think jam was busy with somethig else
[22:27]  poolie, james_w: Yeah it was supposed to be yesterday or today, but today I got caught up with $OTHER
[22:28]  Ah, 'k.
[22:30]  james_w: oh, it actually seems like most things are already synced
[22:30]  (looking at http://qa.ubuntuwire.com/mdt/bazaar.html)
[22:31]  ah, I'd forgotten about that page
[22:31]  james_w: can you just sync bzr from experimental?
=== webchick|supper is now known as webchick
=== salgado is now known as salgado-afk
[22:33]  there's no bzrtools release to go with it>
[22:33]  i think there is?
[22:33]  There's a 2.1.0 out.
[22:34]  at least upstream, announced 5 feb
[22:36]  jelmer: do we not want that first?
[22:37]  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]  I'll upload a newer version of bzrtools to experimental as well.
[22:37]  thanks
[22:37]  any chance of a bzr-builddeb upload as well?
[22:38]  sure
[22:39]  I think the changelog entry needs some work though..
[22:40]  I'm writing it now :-)
[22:47]  jelmer: hi
[22:47]  jelmer: bzr-search :) please pretty please please.
[22:47]  lifeless, hey
[22:47]  lifeless, can you explain what you would like me to do to it exactly?
[22:47]  :-)
[22:47]  package a newer snapshot of trunk
[22:47]  the ~70 snapshot that is packaged is broken with CHK repos
[22:48]  its fixed in trunk, and we're getting lots of bugs from packaged-bzr-search users.
[22:48]  lifeless: revno 77 is the latest version packaged
[22:49]  at least according to my debian qa page
[22:49]  interesting
[22:49]  oh, I see - karmic.
[22:49]  So I think what I mean is 'sob, karmic is bust'
[22:50]  we could look at an SRU I guess
[22:53]  jelmer: lp:bzr-builddeb should be ok for an upload now
[22:53]  james_w: thanks
[22:53]  lifeless: ouch :-/
[22:54]  james_w: wow, that's a lot of bugs that are fix released now :-)
[22:55]  bzr-search | 1.7.0~bzr70-1 | karmic/universe | source, all
[22:55]  some have been fixed for ages, it's just not clear exactly what constitutes a release
[22:56]  james_w:   * Upload to lucid.
[22:56]  that's not quite true :-)
[22:57]  oh yeah :-)
[22:57]  + (indirectly)
[23:36]  james_w: the removal of the dependency on bzrtools isn't mentioned in changelog, did it make it into 2.3?
[23:43]  james_w: Looks like it, I'll update changelog
[23:49]  james_w: ping
[23:49]  james_w: I don't understand why import-upstream would delete stuff (re your calling it dhmake
[23:50]  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)