[00:00] <Odd_Bloke> jelmer: Are they general changes, or bzr-git specific ones?  (i.e. will they be forwarded upstream?)
[00:00] <a7p> bpeterson, and you do get the progress bar?
[00:00] <bpeterson> yes
[00:00] <a7p> something really seems to be messed up here ...
[00:00] <a7p> :(
[00:01] <jelmer> Odd_Bloke, they're generic
[00:01] <bpeterson> as in [                          ] Transferring ?
[00:03] <Odd_Bloke> jelmer: Do you think it's worth getting the package uploaded and waiting for the patches to make it into mainstream (as bzr-git isn't production-ready yet anyway), or would you prefer them to be included in the packaging and forwarded upstream that way?
[00:03] <a7p> bpeterson, exactly, that's the thing I am talking about.
[00:03] <bpeterson> a7p: it's not doing anything if that's what you mean
[00:05] <a7p> not even [ .. ] get's displayed here ...
[00:05]  * a7p will read the manual and come back in a few minutes
[00:05] <bpeterson> maybe your terminal is messed up
[00:07] <a7p> works fine with anything else ... and I did not change anything from the defaults ...
[00:07] <a7p> but nevertheless, likley ..
[00:08] <a7p> -v also gives me nothing
[00:08] <a7p> ahhh ...
[00:09] <jelmer> Odd_Bloke, I don't think it's worth bothering to include them in the package atm
[00:10] <Odd_Bloke> jelmer: OK, that makes my life easier for the time being. :)
[00:16] <bpeterson> a7p: the branch complete successfully for me
[00:18] <a7p> bpeterson, okay, thanks for your help ... something really seems to be messed up with my MacOS installation ...
[00:20] <Odd_Bloke> jelmer: If you have time, I'd appreciate you giving the package a quick once over, as it's the first package I've created from scratch. :)
[00:20] <jelmer> Odd_Bloke, is there a bzr branch I could review ? (-:
[00:21] <Odd_Bloke> jelmer: I haven't made the jump to using bzr to version my packages.
[00:21] <Odd_Bloke> (So no. ;) )
[01:04] <a7p> mmm ... does not work in xterm either ... so I guess I can exclude terminal-compatibility problems.
[01:12] <Verterok> hi
[01:12] <Verterok> a7p: are you still having problems with bzr-eclipse branch?
[01:17] <Verterok> a7p: I'm upgrading the branch to packs ATM
[01:29] <a7p> Verterok, I'll give it another try
[01:29] <a7p> Verterok, but my MacOS-bzr installation seems to be at least partial guilty ..
[01:30] <Verterok> a7p: it's still upgrading, I'll let you know when it's done
[01:30] <a7p> Verterok, thank you very much.
[01:30] <Verterok> a7p: are using the Tiger DMG?
[01:30] <a7p> no, Leopard
[01:31] <Verterok> a7p: I asked, because I'm the maintainer of  the Tiger DMG :)
[01:32] <a7p> sorry, do not have a tiger at hand.
[01:32] <a7p> Verterok, but your bzr displays the progress bar, doesn't it?
[01:34] <Verterok> a7p: it did the last time I tested it (I'm using bzr.dev ATM)
[01:34] <Verterok> a7p: did you upgraded bzr from a previous dmg install?
[01:35] <a7p> Verterok, nope, fresh install ..
[01:37] <a7p> Verterok, strange the progressbar ist displayed when I co with --lightweight ...
[01:38] <a7p> I'll give the trunk a try, see if my problem is fixed there.
[01:39] <Verterok> a7p: maybe it's a knit<->packs problem (I'll digg the reported bugs)
[01:47] <Odd_Bloke> Is there any chance I could get http://blog.daniel-watkins.co.uk/tags/Planet%20Bazaar?flav=rss added to Planet Bazaar?
[01:51] <jelmer> Odd_Bloke, please mail poolie
[01:56] <awmcclain> I have a remote, read-only SVN repo. I've created a bzr branch from it, made changes, and checked them in. Now, I want to use bzr diff to make a patch of all the changes I've checked in against the HEAD revision of the svn repo; how do I do that?
[01:58] <Odd_Bloke> jelmer: Will do.
[01:58] <Odd_Bloke> Thanks. :)
[01:58] <a7p> Verterok, just gave 1.6b4 a try - it works fine
[01:58] <Verterok> a7p: great to know
[01:58] <a7p> Verterok, am able to checkout bzr-eclipse and the progress-bar gets displayed.
[01:59]  * Verterok wonders if it's time to build a 1.6bx DMG for tiger
[01:59] <Verterok> a7p: the upgrade to packs is still running :P
[02:02] <jelmer> awmcclain, bzr diff -rbranch:svn://....
[02:02] <a7p> thought so, got a warning from the new bzr.
[02:02] <a7p> so, thanks for your help and the trunk-hint ... have to sleep now
[02:03] <awmcclain> jelmer: Ah, of course. Thank you. When you branch off of an svn repo, does it save the original path anywhere?
[02:03] <jelmer> awmcclain: .bzr/branch/branch.conf should contain the original url
[02:03] <awmcclain> Hrm, empty.
[02:04] <a7p> one more thing *g* ... should I file a bug for the nonexitant progress bar and the knit fail of bzr 1.5?
[02:04] <awmcclain> Nm
[02:04] <awmcclain> i'll just look it up again
[02:06] <awmcclain> jelmer: Any way to see what SVN revno I originally branched from?
[02:10] <Verterok> a7p: I assume it'll be marked as fixed, but do it anyway if you think it should be there for ccurrent 1.5 users :)
[02:13] <a7p> okay.
[02:13] <a7p> gn8
[02:15] <jelmer> awmcclain; in newer versions of bzr-svn, the revno is listed in "bzr log"
[03:43] <rocky> is there anything similar to psvn.el for bzr/emacs ?
[03:44] <bob2> does vc-bzr.el count?
[03:45] <rocky> not really ;)
[03:46] <bob2> vc in recentish emacs cvs (or bzr;) has apparently incirporated incorporated some psvn features
[04:04] <rocky> weird... anyone using DVC because i have no idea where to begin with it
[04:17] <mtaylor> rocky: ?
[04:17] <rocky> nvm ;)
[04:17] <rocky> decided i'll stick with cmdline bzr until i get familiar enough with it
[04:18] <mtaylor> fair enough
[04:47] <ToyKeeper> rocky: Bzr has lots of good documentation, plus built-in help.  'bzr help' or 'bzr help commands' is a good place to start.  :)
[07:42] <Ryan52> Can I combine 2 commits somehow?
[07:44] <bob2> you could branch from before the first one, then merge them in together
[07:44] <Ryan52> then will there be no way to tell that it was ever 2 separate commits?
[07:44] <Ryan52> (that's what I'm trying to get...)
[07:44] <bob2> no
[07:46] <luks> if they are the last commits on the branch, you can just uncommit twice and then commit
[07:49]  * Ryan52 will try that next time
[07:49] <Ryan52> thanks
[08:17] <markh> is anyone able to help me diagnose why bzr-svn says "not a branch" for a URL that svn is working fine with?
[08:31] <dwt> Hey guys, I'm having a problem compiling the bzr-svn exgtension on mac os x
[08:31] <dwt> because I't complains that my svn libraries are not fat
[08:31] <dwt> but instead thing (only for i368)
[08:32] <dwt> but I couldn't find a way to teach setup.py to only build i368 binaries
[08:32] <dwt> as a result of this, bzr now always segfaults when loading
[08:32] <dwt> which makes it a bit hard to use...
[08:35] <bob2> markh: is bzr-svn working in general?
[08:36] <markh> bob2: I'm not sure to be honest
[08:36] <markh> I'm trying to find out :)
[08:37] <markh> I'm on windows, but there are no obvious deps missing.
[08:37] <bob2> bzr selftest -s bzrlib.plugins.svn
[08:38] <markh> ouch - "exceptions.ImportError: cannot import name make_file_knit"
[08:38] <markh> hrm
[08:39] <bob2> are you using bzr.dev?
[08:40] <markh> yeah, about a week or so old
[08:41] <bob2> and which version of bzrsvn?
[08:42] <markh> latest I could find - 0.4.10 - but it complains about being too old
[08:42] <bob2> get the bzr-svn 0.4 branch
[08:42] <bob2> I'm pretty sure bzr.dev generally requries dev bzr-svn
[08:43] <markh> ok cool, thanks.  I'm actually trying to package windows binaries, so was trying to stick to "known" versions when I could - I'll give that a go.
[08:43] <bob2> then you'd want bzr 1.5 and bzr-svn 0.4.whatever
[08:44] <markh> trying to package ready for 1.6 ;)
[08:45] <markh> and include the current state of tortoise which I'm working on. I'm hoping to be able to include the svn plugin as a convenience.
[08:45] <markh> and trying to learn how it working in the meantime :)
[08:49] <bob2> you want 0.4.11, which is unreleased
[08:49] <bob2> so 0.4 trunk
[10:01] <dwt> Ping.... can anyone help me with my bzr-svn compile problem?
[10:02] <bob2> !sunday
[10:02] <ubottu> Sorry, I don't know anything about sunday
[10:04] <dwt> bob2: so thats the problem... nobody in. :)
[10:04] <dwt> ?
[10:08] <bob2> it's the weekend, yo'll have better luck during the week or asking on the list
[10:10] <dwt> ah well, probably.
[10:11] <dwt> Thanks for the answer bob2!
[10:15] <AnMaster> well I'm in but I never used bzr-svn
[10:15] <LarstiQ> dwt: I have never seen that error.
[10:16] <LarstiQ> dwt: so I'm not sure what exactly the problem is, could you elaborate on it a bit?
[10:16] <dwt> LarstiQ: Well, I'l paste a complete build log if you like - maybe I'm hunting for completely the wrong thing
[10:16] <LarstiQ> dwt: sure, I can try and look at that.
[10:16] <dwt> uhm, which paste is preffered here?
[10:16] <LarstiQ> dwt: your libsvn is i386 only?
[10:17] <LarstiQ> ubottu: paste?
[10:17] <ubottu> Sorry, I don't know anything about paste?
[10:17] <dwt> jup, installed via fink
[10:17] <LarstiQ> dwt: I don't really care, use rafb.net/paste/ myself
[10:17] <dwt> thx
[10:18] <dwt> http://rafb.net/p/XJZq9w38.html
[10:21] <LarstiQ> I see.
[10:21] <dwt> its a bit strange really, if I look at the backtrace of the crash
[10:21] <dwt> it looks like its really the libsvn that has the error
[10:21] <LarstiQ> dwt: I'd be interested to know where setup.py gets its gcc line from, notably the -arch ppc
[10:21] <dwt> http://rafb.net/p/p4boYu29.html
[10:21] <dwt> yeah, me too.
[10:21] <dwt> :)
[10:22] <dwt> the setup.py file itself doesn't contain a thing in this direction, sadly.
[10:22] <dwt> So it probably is something from distutils.extension
[10:23] <LarstiQ> dwt: what does apr-config give you?
[10:23] <LarstiQ> dwt: apr-config --cflags  I guess
[10:23] <dwt> -g -02
[10:23] <dwt> :/
[10:24] <LarstiQ> ok, that's not it then
[10:25] <LarstiQ> dwt: can you print the repos SvnExtension extra_compile_args?
[10:25] <dwt> just a second
[10:27] <dwt> looks innocent too:
[10:27] <dwt> kwargs: {'libraries': ['svn_client-1', 'svn_subr-1'], 'extra_link_args': ['-L/sw/lib', '-lapr-0'], 'library_dirs': ['/usr/lib'], 'include_dirs': ['/sw/include/apr-0', '/usr/include/subversion-1']}
[10:28]  * LarstiQ dives further into distutils
[10:29] <dwt> is there a way to get those out after distutil did it's magic with them?
[10:30] <LarstiQ> dwt: to test if it is really the fatness of the lib, you can rerun the gcc commands yourself, without -arch ppc
[10:31]  * dwt slaps his head
[10:31] <dwt> why didn't I think of that before?
[10:31]  * LarstiQ still searches on for distutils knowledge
[10:31] <dwt> I'l try that
[10:31] <LarstiQ> dwt: it's early? :)
[10:31] <dwt> true...
[10:32] <dwt> LarstiQ: I did have a nice breakfirst with self-baked bread before though.
[10:32] <dwt> :)
[10:33] <LarstiQ> dwt: also, try: from distutils.sysconfig import get_config_vars; get_config_vars()['CFLAGS']
[10:33] <LarstiQ> dwt: ooh
[10:34]  * LarstiQ skipped breakfast today since he is going to a Nepalese restaurant for lunch in half an hour (and I got up at 11.00)
[10:35] <dwt> :)
[10:35] <dwt> LarstiQ: Well, no luck there either:
[10:35] <dwt> Get Config Vars: -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE
[10:36] <dwt> not even in any of the config vars. :/
[10:39] <LarstiQ> ah, but that does mean it is gcc $CFLAGS -arch stuff etc
[10:41] <dwt> LarstiQ: Sorry, I don't follow...
[10:41] <dwt> ah
[10:41] <dwt> got it
[10:41] <dwt> still unsure where it comes from though
[10:42]  * LarstiQ plods on
[10:49] <LarstiQ> dwt: hmm
[10:49] <LarstiQ> dwt: do you have $CFLAGS set in your env?
[10:50] <dwt> LarstiQ: well, not at all: echo $CFLAGS
[10:50]  * dwt returns nothing
[10:50]  * dwt is currently looking at the distutils source of Extension.py
[10:52] <LarstiQ> dwt: I'm looking at syconfig.py customize_compiler()
[10:53] <LarstiQ> dwt: how about CCSHARED?
[10:53] <dwt> the environment variable?
[10:53] <dwt> no env of that name here
[10:53] <LarstiQ> yes
[10:53] <LarstiQ> hmkay
[10:54] <LarstiQ> dwt: does it still segfault if you build thin by hand?
[10:54]  * LarstiQ starts rounding up to leave the house
[10:54] <dwt> damn, I'm not done with that yet
[10:54] <dwt> I'l hurry
[10:56] <bob2> not using distcc or ccontrol or anything?
[10:58] <dwt> bob2: Not that I know of
[10:58] <dwt> LarstiQ: Compiling it by hand, it still segfaults
[10:58] <dwt> not sure thogh that distutil isn't doing any more commands it doesn't show on the shell
[10:59] <LarstiQ> right
[10:59]  * LarstiQ runs off
[10:59] <LarstiQ> dwt: maybe jelmer has an idea
[10:59] <dwt> He probably has. :)
[10:59] <dwt> Thanks a lot for your help though!
[11:00] <dwt> jelmer: you don't happen to be around?
[11:18] <_amanica_> jelmer: Is the loggerhead and bzr-gtk bundles supposed to show up in bundle buggy?
[11:20] <_amanica_> because I know that bundle buggy can now support multiple projects, but I'm not sure how one is supposed to know from the frontend which bundles are for which project..
[11:29] <jelmer> dwt, Hi
[11:29] <jelmer> dwt, I'm around but I have no idea about Mac OS X
[11:30] <dwt> jelmer: well, first Thanks for answeing
[11:30] <dwt> and second: after investigating this a bit it doesn't seem so much like a problem of building fat binaries vs thin binaries
[11:30] <dwt> burt more like maybe a bug in the bindings
[11:30] <dwt> which causes a null pointer to be used
[11:31] <dwt> jelmer: Maybe you could have a look at the stacktrace after a crash? http://rafb.net/p/p4boYu29.html
[11:31] <dwt> I had a look at initrepos in repos.c - and it did look innocent to me - but I don't know the subversion libraries at all
[11:32] <dwt> so maybe you can see something there
[11:35] <jelmer> dwt: not sure what could be buggy there
[11:36] <jelmer> dwt, so it could indeed be a local issue
[11:37] <dwt> maybe my svn libraries are buggy?
[11:37] <dwt> I'm still on 1.5.0 something
[11:37] <dwt> and not on 1.5.1
[11:37] <dwt> Do you know anything there?
[11:40] <jelmer> dwt, not sure, it seems strange this sort of bug would end up in a release
[11:40] <jelmer> dwt, I would suspect it's related to Mac OS X
[11:40] <dwt> ok, thanks a bunch
[11:40] <dwt> I'l look into this more
[11:40] <dwt> if I see something I'l report it back here
=== pbor is now known as pbor|afk
=== davi_ is now known as davi
[15:44] <mrZeby> hi all
[15:44] <mrZeby> there is somebody here ?
[15:47] <mrZeby> somebady read me ?
[15:49] <bob2> hello
[15:51] <mrZeby> hello bob2 thanks for answering... i just would to be sure my irc client run correctly :-) have a nice day.
[16:22] <nico-inattendu> Hi, i m a almost newbie on bazaar i try to set up a Distributed development workflow. And i ahave som e questions on the usage? and when to make commits. In the example given in tutorial http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#distributed-development , a branch mirror is created , then each modifications are made in new branches ( features branch). But i don't understand  what action to do when a modification is d
[16:23] <bob2> (truncated after "modification isd")
[16:44] <luks> anyway what's causing this: bzr: ERROR: Directory not empty: "/srv/bazaar.launchpad.net/push-branches/00/00/1d/59/.bzr/repository/lock/lzvfsm4v4t.tmp": [Errno 39] Directory not empty ?
[16:44] <luks> on bzr push
[16:44] <luks> oh, nevermind, it's probably a new "repository locked" message
[17:18] <Peng_> Is it possible to convert a lightweight checkout to a stacked branch?
[17:23] <bob2> reconfigure?
[17:23] <Peng_> Really? Where do you set what it's stached on?
[17:23] <Peng_> stacked*
[17:28] <jelmer> Peng_: i would imagine it would create a new branch that is stacked on the branch your lightweight checkout is using
[17:37] <Peng_> I'm just not seeing this.
[17:38] <Peng_> "bzr reconfigure --tree" obviously turns it into an independent branch. Where do you tell it to stack?
[17:39] <Peng_> Oh, right, isn't stacking on rich-roots broken anyway?
[17:42] <jelmer> Peng_: I would imagine it to be possible to use a --stacked argument to reconfigure
[17:42] <jelmer> not sure if such a argument is there yet though
[17:43] <Peng_> jelmer: There isn't one in the help
[17:44] <Peng_> Yeah, there isn't one.
[17:50] <Peng_> Is it supposed to be possible to run "bzr branch --stacked some_rich_root_pack_url"?
=== BasicTheProgram is now known as BasicOSX
=== BasicOSX is now known as Basic
[18:00] <jelmer> Peng_: yes
[18:07] <Peng_> I think there's a bug open about it?
[20:17] <Peng_> jelmer: Is it just me, or is "bzr log" not showing the svn revisions anymore?
[20:17] <jelmer> Peng_, I think it's you :-)
[20:18] <jelmer> Peng_, you mean the "svn revno" entries in bzr log, right?
[20:18] <Peng_> :(
[20:18] <Peng_> jelmer: Yes.
[20:18] <Peng_> Great, it works on one branch, but not another.
[20:19] <Peng_> In fact, it works on one branch of the project, but not another.
[20:19] <Peng_> jelmer: It doesn't show it on new revisions I just pulled, but it does on older revisions.
[20:19] <jelmer> Peng_, it doesn't list them for revisions that have been created with bzr
[20:20] <Peng_> jelmer: They weren't.
[20:20] <jelmer> Peng_, does "bzr log --show-ids" show svn-v3: revids?
[20:20] <Peng_> jelmer: No.
[20:21]  * Peng_ blinks.
[20:21] <jelmer> are you sure that branch was created with bzr-svn?
[20:21] <Peng_> Yes...
[20:22] <Peng_> I've had the branch for months, and I frequently "bzr pull" new revisions from svn.
[20:22] <jelmer> what do the revids look ?
[20:22] <Peng_> Like normal bzr revids.
[20:24] <jelmer> that would suggest the branch you pull from is either a regular bzr branch or the revisions in svn were created with bzr
[20:24] <Peng_> Ahh.
[20:24] <jelmer> or perhaps it's not a bzr-svn branch but a launchpad import ?
[20:24] <Peng_> The developers are transitioning to bzr-svn, so that's probably it.
[20:24] <jelmer> ahh
[20:25] <jelmer> it's not possible to retain the svn revno for that sort of revision since revisions are immutable
[20:26] <Peng_> Yeah, they were made using bzr.
[20:26] <Peng_> Thanks. :)
[20:37] <awilkins> markh: bzr-svn win32?
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
[21:44] <awilkins> markh: ping?
=== abentley1 is now known as abentley
[23:55] <poolie> hello all