[00:04] <der|> I've used bzr without any problems so far when adding/pushing on linux. I'm using bzr on windows now, and 90% of the time,when I add or push to a repository, I get this message: "Unable to obtain lock file....", it's on a point that it's annoying, is there any way to fix that problem ?
[00:07] <igc> morning
[00:10] <meoblast001> hi
[00:11] <meoblast001> i'm having a problem with fast-import
[00:11] <meoblast001> http://pastebin.com/d449f0c4d
[00:12] <spiv> igc: ^
[00:12] <meoblast001> spiv: does igc do fast-import?
[00:13] <spiv> meoblast001: yeah
[00:13] <igc> meoblast001: which version of bzr and bzr-fastimport?
[00:13] <meoblast001> 2.0 of bzr
[00:13] <meoblast001> let me check the bzr-fastimport version
[00:14] <meoblast001> dang it, i can't figure this out
[00:14] <igc> meoblast001: bzr plugins
[00:14] <meoblast001> igc: how do i get fast import version?
[00:14] <igc> should tell you
[00:14] <meoblast001> fastimport 0.9.0dev
[00:15] <igc> meoblast001: ok, so it's reasonably recent
[00:15] <igc> meoblast001: did you install it from apt? or are you running from a branch?
[00:15] <meoblast001> branch
[00:16] <meoblast001> i believe
[00:16] <igc> meoblast001: ok, so try this ...
[00:16] <meoblast001> igc: i exported my project, modified a few mistakes i made at commit 1, updating the sizes as i went
[00:16] <igc> cd ~/.bazaar/plugins/fastimport
[00:16] <meoblast001> i removed 9 characters from each file
[00:16] <meoblast001> and if i did my math right, i subtracted 9 from each file's size
[00:16] <igc> bzr revno
[00:17] <meoblast001> 243
[00:17] <igc> ok, 263 is the latest, so
[00:17] <igc> bzr pull
[00:17] <igc> meoblast001: ^
[00:17] <meoblast001> ok
[00:18] <meoblast001> don't think that will help, but what will it hurt
[00:18] <meoblast001> ok, updated to 261
[00:18] <meoblast001> igc: maybe you need to bzr push ;)
[00:19] <igc> meoblast001: if the problem is still there, raise a bug please and I'll take a look later today
[00:20] <meoblast001> i might be the problem
[00:20] <meoblast001> is it possible i did math wrong?
[00:21] <spiv> meoblast001: that doesn't look like the sort of error I'd expect if you did
[00:21] <meoblast001> oh :/
[00:21] <spiv> meoblast001: I could be wrong, of course :)
[00:21] <meoblast001> should i re fast-export and try again?
[00:22] <meoblast001> i wrote a program a while ago that automates these changes
[00:22] <meoblast001> let me see if i can find it
[00:22] <meoblast001> yuck, C++
[00:22] <meoblast001> i thought i did it in C
[00:31] <meoblast001> spiv: igc: i redid the import and it worked
[00:39] <spiv> meoblast001: hooray :)
[00:58] <zsquareplusc> is it possible to fix a bug number entered with --fixes later? (i.e. many commits later)
[00:58] <poolie> zsquareplusc: not as such
[00:59] <poolie> only by uncommitting and redoing things
[00:59] <poolie> which is probably not worth it
[00:59] <poolie> is this on lp or elsewhere?
[00:59] <zsquareplusc> someone mistyped a bug number back in july. he remeved the related bug in the launchpad interface, but now it apears again. maybe th they rescanned the branch
[01:03] <zsquareplusc> it would be good if it were possible the edit the comments/metadata for such cases...
[01:19] <igc> poolie: I'm reviewing https://code.edge.launchpad.net/~mbp/bzr/remove-logging/+merge/15306
[01:20] <igc> poolie: does it require a bump of the bzrlib API version?
[01:20] <igc> I'm thining about the constructor changes for TextUIFactory() mentioned in NEWS
[01:21] <poolie> igc, it is an api bump
[01:21] <poolie> are we measuring apis per 2.1beta?
[01:22] <igc> poolie: wasn't sure, just wondering
[01:23] <igc> poolie: I haven't looked over the policy lately
[01:24] <poolie> i think the six month cycle probably makes api versions redundant
[01:24] <spiv> I think we were just going to have a 2.1 API, rather than per-beta.
[01:24] <poolie> because between betas there are no guarantees, in a stable series there will be no changes, and between series there are guaranteed to be changes
[01:30] <spiv> Yeah.
[02:11] <igc> spiv: care to land https://code.edge.launchpad.net/~spiv/bzr/hardlink-2a-408193/+merge/15591?
[02:12] <spiv> igc: will do shortly :)
[02:12] <igc> spiv: thanks :-)
[02:14] <poolie> igc: the sysadmins started on the web server cleanup etc
[02:57] <neoTheCat> newbie here... if i have a centralized repository, and i went to have a long bath (e.g. documents/programming/guides/...", but i want the leaf directories to be it's own revision, what's the best way to set this up?
[02:58] <neoTheCat> i setup "documents" as the repos, but i am not to sure the best "bzr" way to do it without causing myself problems down the road
[03:17] <gutworth> do bzr ini multiple times
[03:17] <gutworth> bzr init I mean
[03:28]  * igc lunch
[03:30] <neoTheCat> gutworth: do a bzr init on each dir in the tree, or just the ones i want to have seperate revisions for?
[03:33] <gutworth> neoTheCat: just the ones you want separate revisions for
[03:33] <gutworth> they'll be different branches
[03:33] <neoTheCat> gutworth: thank you very much.
[05:46] <mrooney> hello all, my push was interrupted by a network disconnection, so I tried pushing again and it said there was a lock
[05:46] <mrooney> so I ran the command it supplied, but that gives me an unsupported protocol error
[05:50] <mrooney> okay, I fixed it by changing the syntax of the command based on https://answers.edge.launchpad.net/launchpad-code/+question/74032, but, why does it give the wrong command?
[05:52] <spiv> mrooney: because of a bzr bug, just a sec I'll find the number
[05:53] <spiv> mrooney: bug 250451
[05:54] <spiv> mrooney: the bug comments have the gory details
[05:55] <mrooney> spiv: ah neato, thanks for pointing me to the bug!
[06:40] <poolie> spiv, hi
[06:40] <spiv> poolie: good afternoon
[06:44] <poolie> how are you?
[06:44] <poolie> i was just thinking about the lp: anonymous case
[06:44] <poolie> because it also came up in this spurious comparison to hg
[06:45] <spiv> Pretty good, I'm digging into the per-file merge hook bug/feature atm.
[06:45] <spiv> What's your current thoughts on the lp: anonymous case?
[06:45] <poolie> i'd do whichever option is easiest to implement on the lp side
[06:46] <spiv> I'm inclined a bit towards doing it via anonymous ssh, but I think that's partly because I know off the top of my which bits to hack on to make that happen.
[06:46] <poolie> also, i'd think about getting rid of the lp: xmlrpc and just mechanically transform the url
[06:46] <poolie> then the server can redirect if the branch should be taken from elsewhere
[06:46] <poolie> however, that would be a loss of capability a way to send that is actually written
[06:46] <spiv> Redirect via HTTP or a branch ref?
[06:47] <spiv> The server could simply alias, too.
[06:47] <poolie> i was wondering if you'd like to hack on that to keep your hand in
[06:47] <poolie> right, any of them
[06:47] <poolie> there is the case of say redirecting to http under heavy load
[06:47] <poolie> not sure if this is important enough to worry about
[06:49] <spiv> I am tempted to hack on that.
[06:49] <spiv> In some ways I think bzr+ssh is the less risky option too, because the WSGI glue isn't as battle tested.
[06:49] <spiv> I have some fears about its memory consumption.
[06:49] <poolie> oh my other thought is that it would be interesting to break down the time to get an initial branch of some small project
[06:49] <poolie> the whole thing from start to finish
[06:50] <poolie> including dns, xmlrpc, ssh startup, etc
[06:50] <spiv> The big downside for bzr+ssh for small projects is the 5+ seconds of SSH handshake overhead.
[06:50] <poolie> it may be that we should recommend some ssh settings to cut down on that
[06:50] <poolie> right, or it may be that the best case for ssh is still noticeably slow
[06:51] <spiv> I think multiple round-trips is pretty unavoidable for SSH handshakes without the fiddly persistent connections feature.
[06:51] <spiv> Which is sufficiently fiddly that I don't even use it.
[06:52] <spiv> So I think that this would be a potentially big point in favour of hpss-over-http instead.
[06:54] <poolie> right
[06:54] <poolie> hm
[06:55] <poolie> is it really 5s?
[06:58] <poolie> well, 4.5s for me
[06:58] <poolie> probably speed of light bounded
[07:08] <spiv> poolie: hmm, yeah, 4.2s for me I guess.
[07:08] <poolie> so perhaps that invalidates this bug
[07:08] <poolie> well
[07:08] <poolie> at least deprioritizes it
[07:08] <spiv> Yeah.
[07:08] <poolie> if you could do it in a trivial patch, it'd be worth having at least for testing purposes
[07:09] <poolie> and it will be an improvement over http
[07:09] <poolie> but not so clearly so
[07:09] <poolie> for example http is faster for bzr info
[07:14] <poolie> lifeless: when james_w says "updated package targeted to -proposed" just what does that mean?
[07:15] <poolie> actually -> #ubuntu-motu
[07:39] <vila> hi all
[07:39] <mwhudson> spiv, poolie: i think we can easily run bzr+http on a separate box from the main code host
[07:39] <poolie> hi vila
[07:39] <mwhudson> which will at least mean that memory gobbling will not affect other services
[07:40] <poolie> vila, good luck piloting
[07:40] <poolie> ok
[07:40] <mwhudson> vila: good morning
[07:40] <poolie> mwhudson: wbn to have metrics in place from the begining
[07:40] <vila> poolie: thanks !
[07:40] <mwhudson> poolie: which ones did you have in mind?
[07:40] <poolie> hm
[07:41] <poolie> number of connections, number of crashes, number of distinct ips
[07:41] <poolie> something like that
[07:41] <mwhudson> i don't know much about sensible bzr+http deployment, would process per connection make sense?
[07:41] <mwhudson> poolie: for bzr+http, apache logs can probably give us most of that
[07:42] <poolie> yes
[07:42] <spiv> mwhudson: "connection" isn't a directly applicable concept for HTTP
[07:42] <mwhudson> spiv: even bzr+http?
[07:42] <mwhudson> it's _really easy_ for us to handle the .bzr/smart requests separately
[07:42] <spiv> mwhudson: I mean, at some level there are sockets.
[07:43] <spiv> And a one-to-one mapping of processes to those probably would work well...
[07:43] <spiv> But configuring that via Apache or whatever when there's HTTP in the middle might not be simple.
[07:45] <mwhudson> spiv: there are forking wsgi servers i think?
[07:45] <spiv> mwhudson: quite possibly
[07:45] <spiv> mwhudson: basically it's 'research required', I think
[07:46] <spiv> mwhudson: I'm sure it's possible, but the exact software and config to do it wel  isn't immediately obvious to me
[07:46] <mwhudson> i guess this is an argument for just putting "4133: bzr lp-serve --inet anonymous" in /etc/inetd.conf or whatever
[07:46] <spiv> mwhudson: yeah.
[07:47] <spiv> mwhudson: incidentally, someone should do something about the ~anonymous user ;)
[07:47] <mwhudson> spiv: like our friendly losa spm?
[07:48] <spiv> mwhudson: quite probably
[07:58] <spm> do we have a bonefide account as ~anony?
[07:58] <spm> ha. yes.
[08:23] <mohit> hey guys
[08:23] <mohit> How do I prevent a repository from accidentally being pushed to?
[08:24] <mohit> Does bzr provide any such functionality, or I have to change the file permissions on the OS to achieve the result?
[08:24] <spiv> mohit: in what context?
[08:25] <spiv> mohit: file permissions in the OS is often a good answer
[08:25] <mohit> I have a "LIVE" repository, which powers production systems
[08:25] <mohit> all the development branches are spun from it
[08:25] <mohit> I dont want anyone to accidentally push to production
[08:26] <mohit> Okay
[08:26] <mohit> there is no way bzr provides such "lock" or something?
[08:26] <mohit> changing chmod on main trunk is something I am awry of
[08:26] <spiv> It sounds perhaps like you want chown rather than chmod
[08:27] <spiv> But either could work, and would be fine.
[08:27] <spiv> bzr itself doesn't do access control.
[08:30] <mohit> okay
[08:30]  * igc dinner
[08:42] <mohit> thanks a lot man
[08:43] <mohit> spiv, You are awesome! :-)
[10:19] <bialix> hello
[10:19] <jelmer> 'morning bialix
[10:19] <bialix> good day jelmer!
[14:35] <The_User> Hi! I try to use BzrGit, so  I installed dulwich, but I still get: "no module named git.remote", how to install this module?
[14:37] <jelmer> The_User, hi
[14:37] <jelmer> The_User, how did you install bzr-git?
[14:37] <The_User> I guess I have to run setup.py? what would be the correct prefix?
[14:39] <jelmer> put it in ~/.bazaar/plugins/git
[14:40] <The_User> ah got it, had to remove the original dir from ~/.bazaar/plugins
[14:40] <The_User> thanks
[14:58] <TakWork> hm, is there a way to add available statuses to a launchpad project‽
[15:06] <jelmer> TakWork, bug statusses you mean?
[15:06] <TakWork> yes
[15:06] <TakWork> basically, I was wanting NEEDINFO
[15:07] <jelmer> we usually use incomplete for that
[15:10] <TakWork> ah, ok
[15:10] <TakWork> I didn't want the reporter to feel chastised ;-)
[15:10] <rubbs> Usually, if you report Invalid, you want to tell the user why. If you say you need more info, then they probably won't feel chastised, even if you mark it as invalid
[15:12] <TakWork> it's our first user - I don't want to scare him off :-D
[15:13] <rubbs> fair enough.
[15:13] <rubbs> Maybe keep status the same (*new*) and then ask for information. If it's more like a conversation, they are less scared (*as a somewhat new user to bug filing myself *)
[15:13] <TakWork> yeah, that's what I did
[15:14] <rubbs> but there is no exact science
[15:14] <rubbs> I think that's a good idea then.
[15:27] <TakWork> jelmer: could you update your md-bzr addin repo from trunk, pretty please?
[16:23] <neoTheCat> hello.  i asked a question yesterday, and it was answered, but i have a followup.  if i have a long directory structure, the root being a repo, and i want the leaf to be different revisions.
[16:23] <neoTheCat> do i need to init every directory level or just the leaf nodes?  because i am having trouble doing a "bzr push"
[16:56] <gioele> neoTheCat: bzr init-repo on the root, then bzr init of each leaf directory
[16:58] <neoTheCat> gioele: thanks
[18:52] <mwhudson> in mooloolaba the question was asked "what can bazaar do to make launchpad's job easier"
[18:53] <mwhudson> right now, i would really really really really like bounded memory consumption for bzr serve processes
[19:00] <elmo> I second mwhudson's request.  with cherries on top.
[19:01] <mwhudson> elmo: good evenin
[19:01] <mwhudson> g
[19:53] <tsmith> hey
[19:53] <tsmith> how am I supposed to get bzr-svn working in Cygwin??????
[19:55] <flvr8> hey all, the eclipse update site for the eclipse plugin seems to have a config issue. is there anybody around who can give it a kick
[19:56] <tsmith> are you talking about how it NEVER saves bzr config changes?
[19:59] <flvr8> no, it's just not working.... "No repository found at http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/" when I try to add as an update site
[19:59] <flvr8> so there must be a config file missing, permissions issue, or similar
[20:00] <tsmith> o that's been dead for ages
[20:00] <tsmith> i'll get you the one i used
[20:00] <flvr8> ah ok
[20:00] <tsmith> if you figure out how to get bzr-svn for cygwin, let me know lol
[20:01] <flvr8> it's still referenced on the bazaar wiki
[20:01] <tsmith> can you edit the wiki?
[20:02] <flvr8> yeah, looks like i can...what's the right site?
[20:02] <tsmith> alright you read, flvr8 ?
[20:02] <tsmith> http://verterok.com.ar/bzr-eclipse/update-site/
[20:03] <flvr8> ah yeah, that's listed there already as "development snapshots". would prefer to stick with "stable" (at least for the non bleeding-edge ppl on my team)
[20:03] <flvr8> http://bazaar-vcs.org/BzrEclipse/Installation
[20:03] <tsmith> yeah see, they pulled it
[20:04] <tsmith> http://74.125.113.132/search?q=cache:uxRjqo09d88J:bazaar-vcs.org/releases/3rd-party/bzr-eclipse/+http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/&cd=1&hl=en&ct=clnk&gl=us
[20:04] <tsmith> it existed as late as mid-Nov 09
[20:04] <verterok> flvr8: Hi, I'll check with a sysadmin why the "stable" update site isn't working
[20:04] <tsmith> http://74.125.113.132/search?q=cache:3AJYGPdkifgJ:https://bugs.launchpad.net/bugs/492400+http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/&cd=4&hl=en&ct=clnk&gl=us
[20:04] <verterok> flvr8: in the meantime, try using the one at verterok.com.ar
[20:04] <tsmith> there's the bug report
[20:04] <flvr8> cool
[20:05] <tsmith> people in here don't reall seem to care, to be honest
[20:05] <tsmith> everyone just tells you to use the dev builds
[20:13] <bialix> tsmith: care about what?
[20:14] <tsmith> bialix, that the link to the stable eclipse bzr plugin listed on the wiki has been broken for ~16 days
[20:15] <bialix> your wordings a bit sharp
[20:16] <tsmith> well, to be honest, i was basing my opinion based on the responses of a very few individuals on this channel that may have been trolls.
[20:17] <bialix> I'm sure verterok is the one who really care
[20:17] <bialix> because he's author
[20:17] <verterok> bialix: :)
[20:17] <bialix> I was close?
[20:18] <verterok> bialix: yeap
[20:18] <tsmith> it definitely was not verterok
[20:18] <bialix> :-)
[20:20] <verterok> tsmith, flvr8: looks like some wiki config was changed and it's hidding the releases/3rd-party path
[20:20] <daneoverton> hey everyone, i'm getting this error when trying to checkout:
[20:21] <daneoverton> bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
[20:21] <jelmer> daneoverton, what version of bzr are you using?
[20:21] <mkanat> daneoverton: That sounds pretty clear to me.
[20:22] <daneoverton> yeah, i guess i need to update, but is there a command for that or do i need to download it
[20:22] <tsmith> does bzr-svn for cygwin exist?
[20:23] <jam> tsmith: not sure, though I would highly recommend avoiding cygwin
[20:23] <jam> (it is about 2-5x slower than native code)
[20:23] <jam> I personally run native bzr from a cygwin shell without any major problems
[20:24] <tsmith> bzr for win32 run in cygwin FREEZES for many seconds
[20:24] <tsmith> how many seconds? like 60-90
[20:24] <tsmith> sometimes 10 min
[20:24] <jam> hm...
[20:24] <jam> you could try Ctrl+Break and see what is going on
[20:24] <jam> if it is actually frozen
[20:24] <jam> I don't think I've experienced that
[20:24] <tsmith> it took bzr win32 FIFTEEN MINUTES to remove a simple lock
[20:25] <jam> 'to remove' ?
[20:25] <jam> do you mean 'bzr break-lock' or it was doing something that took 15min before the lock was done?
[20:26] <mkanat> daneoverton: You'll have to download it.
[20:26] <bialix> hello jam
[20:26] <tsmith> bzr break-lock on c:\ took 15 min
[20:26] <daneoverton> k, that's what i'm doing, thanks!
[20:27] <tsmith> when i did the exact same operation using cygwin bzr, it took less than a second
[20:28] <bialix> tsmith: there was a bug related to operations on drive root
[20:28] <tsmith> well it was in c:\www\projectname
[20:28] <bialix> do you have antivirus?
[20:28] <jam> tsmith: well, if cygwin gives you better experience, go for it. My personal experience has been significantly different
[20:29] <tsmith> yes
[20:30] <bialix> tsmith: I'm not sure how cygwin avoids crazy checks from antivirus, but that's it
[20:32] <bialix> tsmith: maybe you need to add bzr to list of "good" applications, or something like that
[20:53] <lifeless> win 38
[20:57] <Peng> \i/
[20:57] <Peng> \o/ I can't type today.
[20:57]  * bialix fears to ask what is 38
[20:58] <Peng> #launchpad-dev for me. :D
[20:58] <Peng> How topical!
[21:02] <mkanat> Peng: Maybe \i/ is a submarine as seen from behind.
[21:02] <mkanat> In a narrow channel.
[21:02] <lifeless> #drizzle
[21:02] <Peng> mkanat: OK, I'll go with that.
[22:48] <igc> morning
[22:49] <mwhudson> spiv: can you think of a way to get different lp-serve processes to log to different files?
[22:49] <mwhudson> spiv: i.e. not all jumbled up in ~/.bzr.log
[22:49] <mwhudson> ~/.bzr.log.$pid might work ok for us
[22:55] <spiv> mwhudson: yeah.  You can probably get roughly that by calling bzrlib.trace.push_log_file(...)
[22:56] <mwhudson> spiv: ok cool
[22:57] <spiv> mwhudson: or mv .bzr.log .bzr.log.$pid after the process starts ;)
[23:01] <bialix> hi igc
[23:02] <igc> bialix: hi!
[23:02] <spiv> mwhudson: It might not be crazy to add support for an environment var like BZR_LOG_PATH='~/.bzr.log.%(pid)s'
[23:02] <spiv> mwhudson: a cruder solution would be to change $BZR_HOME...
[23:03] <mwhudson> the bzrlib.trace approach is probably fine for us
[23:04] <bialix> spiv: what's wrong with BZR_LOG?
[23:04] <spiv> Oh, right, that already exists.  It doesn't have any room for parameterisation though.
[23:05] <spiv> bialix: mwhudson has many bzr processes running simultaneously, and would like them to have separate log files.
[23:05] <bialix> well, ues
[23:05] <bialix> understand
[23:07] <spiv> mwhudson: so all you need is to replace the 'bzr' executable with a wrapper that does "os.environ['BZR_LOG'] = 'bzr.log.%s' % os.getpid()" first ;)
[23:09] <spiv> mwhudson: another alternative would be to set it in the SSH daemon to bzr.log.$id(sock_object)
[23:11] <mwhudson> spiv: it would be nice to be able to map "process using megawads of ram" to the log file
[23:12] <spiv> mwhudson: trace.mutter('my PID is: %d', os.getpid())  ;)
[23:12] <spiv> mwhudson: but sure, push_log_file sounds like a pretty good answer.
[23:12]  * spiv hmms
[23:12] <mwhudson> spiv: feel free to put any of these ideas in a branch ;-)
[23:13] <spiv> mwhudson: it's a shame actually that Twisted's spawnProcess doesn't have a pre-exec hook.
[23:14] <spiv> mwhudson: because otherwise you could use that.  Well, you could monkeypatch os.execvpe, but that's not quite the same...
[23:14] <mwhudson> spiv: yes, i kinda wanted that for something else the other day too
[23:15] <spiv> mwhudson: did you file a ticket on Twisted trac for that, or shall I do that now?
[23:15] <mwhudson> spiv: i did not
[23:15]  * mwhudson lunches
[23:26] <bialix> igc: ping
[23:27] <igc> hi bialix
[23:27] <bialix> hi
[23:27] <spiv> mwhudson: twisted ticket #4159
[23:27] <bialix> some thoughts about your new suggestion feature for qpush
[23:27] <bialix> igc: when I've cloned branch from server, made changes, commit and then run qpush, it auto-suggests me parent location
[23:28] <bialix> igc: is it intended change in your patch or side effect?
[23:29] <igc> bialix: not intended
[23:29] <igc> bialix: I only suggested when the parent's parent was on LP so perhaps your subsequent tweak introduced that?
[23:30] <bialix> igc: but it is. I'm still not sure is it should be fixes
[23:30] <bialix> *fixed
[23:30]  * bialix checks
[23:35] <bialix> igc: it seems I found, return '' need to be de-indented
[23:39] <igc> bialix: I resolved that merge wrt qrun categories btw - just pushed new version
[23:40] <bialix> igc: thanks, I'll look and merge