[05:41] <wallyworld> often when doing a bzr switch to change to the working tree of a different branch, it says there are conflicts and copies a dir to foo.moved, but the files in that directory are only pyc files. should bzr be able to handle this better? ie know that pyc files are safe to delete and hence no conflict after all?
[05:42] <lifeless> there is a wishlist bug for this.
[05:43] <wallyworld> ah ok. thanks
[05:43] <wallyworld> been seeing the issue a lot lately with the branches i am working on
[05:43] <spiv> vila has been doing some work on this
[05:44] <wallyworld> excellent. look like it's all under control :-)
[05:48] <bob2> is that just due to some .pyc files being commited?
[05:52] <abcminiuser> Hey all
[05:52] <abcminiuser> I'm trying to make a public BZR mirror of a Subversion project of mine, for other's convenience
[05:52] <abcminiuser> So far I've used bzr-svn to fetch the Subversion contents
[05:52] <abcminiuser> And I'll push it to the public branch, but how can I make it fetch new subversion changes later on?
[05:53] <abcminiuser> Do I run bzr-svn again to update, or something else?
[05:54] <spiv> bob2: it's generally due to switch wanting to delete a versioned directory of .py files
[05:56] <spiv> bob2: but the directory contains (ignored) .pyc files, so it can't.  Then switch back to the branch with the dir and bzr will try to re-add the directory but can't because it already exists, and you get dir.moved etc.  tla's precious/junk distinction is one way to solve this.
[05:57] <spiv> Heh.
[06:25] <peitschie> abcminiuser: you will want to run bzr pull <svn url> most likely
[06:25] <peitschie> abcminiuser: is the bzr branch going to be getting commits independent of the svn branch?
[06:25] <abcminiuser> Not svn-import?
[06:25] <abcminiuser> No, straight mirror
[06:26] <peitschie> abcminiuser: if it's a straight mirror, then from your own checkout of the bzr-svn mirror, running bzr pull should do the trick :)... you don't need to re-import after the branch has been created
[06:28] <abcminiuser> Pushing it to Launchpad now, I'll do a test SVN change after that and see if my BZR mirror script works
[06:28] <abcminiuser> Thanks!
[06:42] <peitschie> abcminiuser: nps :)
[06:42] <abcminiuser> Mmmm, seems to work great
[06:42] <abcminiuser> Now I've got public SVN, GIT, HG and BZR mirrors
[07:51] <mkanat> <glob> the 4.0 installer now includes bzr :)
[07:51] <mkanat> So Windows users who install Bugzilla 4.0 will get bzr automatically. :-)
[07:52] <lifeless> :)
=== beaumonta is now known as abeaumont_
[12:40] <soren> I'm curious why bzr doesn't use setuptools?
[12:40] <soren> (or distribute for that matter)
[12:41] <maxb> It seems to me that plain old distutils is serving bzr's needs just fine
[12:46] <soren> maxb: I just see bits and pieces in bzr's setup.py that would be simpler with setuptools and wondered if there was any particular reason not to use it.
[12:47] <jelmer> hi Soren, Max
[12:47] <soren> ...mostly because I'm having to make a similiar decision for another project, and looking at what bzr does is usually a good way to learn what the right thing to do is.
[12:48] <jelmer> soren: I'm not sure what exactly the argument in Bazaar's case is, but I usually avoid setuptools because it's another dependency.
[12:48] <jelmer> soren: What functionality in particular does setuptools provide that bzr's setup.py reimplements at the moment?
[12:48] <soren> jelmer: For one, I find find_packages quite useful.
[12:49] <maxb> I'm a bit unclear on the whole setuptools/distribute fork mess and future maintenance situation, which makes me shy away from them
[12:50] <maxb> And I have found setuptools to be a mildly irksome extra dependency when installing python packages on older distros such as you tend to find on work servers
[12:51] <soren> My project depends on python 2.6 anyway, so older distros aren't much of a concern :)
[12:53] <soren> Do you guys have similar reservations about pkg_resources?
[12:53] <jelmer> soren: Yeah, find_packages() is quite convenient. I By itself I don't think it's worth the extra hassle for users to install another package though.
[12:53] <jelmer> Is distribute going to make it into the standard distribution?
[12:53] <soren> My crystall ball is out for repairs, I'm afraid.
[12:55] <jelmer> :-)
[12:57] <jelmer> soren: bzr doesn't have any external (mandatory) dependencies at the moment, so pkg_resources isn't really useful for us. I can see the benefits of it, especially in Windows environments where not every other python library is packaged
[12:58] <jelmer> Though I should say I have zero experience using pkg_resources.
[13:11] <soren> I'm not going to use it to manage external dependencies, actually. I was meaning to use it to have a reasonably portable way to get access to some files I ship (templates for various things). In Ubuntu packages, they're in /usr/share/nova, if people install it themselves, they might be in /usr/share/local/nova or perhaps even in an egg. On Windows, who knows where they have to go?
[13:11] <soren> ...and somehow I need to be able to read them from my python code.
[13:11] <soren> That seems to be a problem pkg_resources solves.
[13:12] <maxb> Doesn't pkg_resources entail dumping the resources into directories on sys.path?
[13:12] <soren> I'm not sure yet.
[13:13] <soren> I didn't bother looking to closely yet, since if bzr had good, philosophical reasons to not use pkg_resources, I woulnd't bother looking at it too deeply.
=== Ursinha-afk is now known as Ursinha
[13:47] <soren> maxb: From what I can tell, bzrlib's resource_string does the same thing (requires dump resources in sys.path).
[13:47] <soren> maxb: e.g. /usr/share/pyshared/bzrlib/help_topics/en/diverged-branches.txt
[13:47] <soren> Maybe it's my debian packaging background speaking, but it just feels so utterly wrong.
[13:48] <soren> lifeless: I'm sure you have an opinion on this?
[14:34] <soren> Does bzr support being distributed as an egg?
[14:36] <dash> soren: not sure why you'd want to
[14:38] <soren> dash: I don't. :)
[14:38] <soren> dash: I'm just curious, because if it does, there's some code I don't understand how will work in that environment.
[14:41] <maxb> soren: hmm.... actually how does launchpad run it? I think it might run it from an egg
[14:42] <maxb> Yes, I think it actually does
[14:43] <soren> How would I go about building such an egg? "python setup.py bdist_egg" just says "error: invalid command 'bdist_egg'"
[14:44] <soren> I'm specifically wondering how bzrlib.osutils.resource_string can work when the files live in a zip'ed egg.
[15:04] <lifeless> soren: ?
[15:04] <soren> lifeless: Let me dig up the context again.
[15:06] <soren> lifeless: Ah, yes, bzr puts stuff like help topics in the python path instead of in /usr/share/doc or whatnot. That seems utterly wrong to me, and I was wondering if you had an opinion on it.
[15:07] <lifeless> soren: python path is defined on windows; /usr/share/doc isn't.
[15:09] <soren> lifeless: That doesn't make me feel less dirty putting things there on Linux. Perhaps I've turned into a bit of a purist. I'm not sure.
[15:10] <soren> lifeless: Had it been anything other than bzr that did it, I would have considered it a bug. Now I'm not sure.
[15:17] <lifeless> soren: IIRC there really wasn't any simple answer
[15:18] <lifeless> soren: but if there is a defined protocol that we can use to make this work on win32/mac & [li|u]nix I'm sure folk would be happy to change.
[15:18] <lifeless> soren: the big thing though, is that the abstraction really shouldn't live in bzr : this is a problem many many many packages face.
[15:18] <soren> lifeless: I half started working on a utility function that would be able to use stuff embedded in an egg, or in sys.path or in /usr/share/project, but I lost my will to live halfway through.
[15:19] <soren> lifeless: pkg_resources wants to be that abstraction, but it relies on this non-python stuff being in the python path and it really rubs me the wrong way.
[15:21] <lifeless> soren: pkg_resources would be the place to fix it.
[15:21] <maxb> I suppose that Python has borrowed the concept from Java in some ways, where it is considered normal for resources to lie next to code
[15:22] <soren> Unfortunately, I'm in the Getting Stuff Done business, moreso than the Argue Over Every Little Pointless Detail business, so I'm just going to have to live with the status quo, I suppose.
[15:33] <lifeless> soren: you're going to die a little inside.
[15:33] <lifeless> soren: with every upload
[16:16] <Glenjamin> hi guys, i'm having trouble getting bzr-svn to make a bazaar branch from my svn server
[16:17] <Glenjamin> is there another approach I can take?
[16:18] <maxb> Glenjamin: give details so people can help! :-)
[16:18] <Glenjamin> halfway through loading revisions I get SSL negotiation failed: SSL error: parse tlsext
[16:18] <jelmer> Glenjamin: hmm, I've seen that one before
[16:18] <Glenjamin> although thinking about that error, it might not be related to bazaar
[16:19] <jelmer> IIRC it had to do with packets that were too big
[16:19] <jelmer> Glenjamin: can svn check out that revision without problems?
[16:19] <Glenjamin> yes, and bazaar will happily interact with that as a lightweight checkout
[16:20] <jelmer> Glenjamin: I don't mean the tip revision but the problematic revision
[16:20] <Glenjamin> oh, lemme try and figure out which one it is
[16:24] <Glenjamin> aha, managed to get that error from the svn client then
[16:24] <Glenjamin> must be server related
[16:37] <zyga> lifeless, could bzr homepage use canonical/ubuntu brand elements like many other ubuntu-affiliated sites do?
[16:54] <lifeless> thats a good question
[16:54] <lifeless> but not one I have an answer to
[16:54] <lifeless> plus its kindof complex, what with bzr being a GNU project too - its somewhat more standalone
[16:59] <zyga> lifeless, true but currently is showes a ubuntu-y affilitation in a bad (ugly) way
[17:00] <zyga> lifeless, perhaps using ubuntu community theme + smallish hints of canonical support would look nice
[17:00] <zyga> lifeless, another question is for bzr big brother, lauchpad
[17:00] <zyga> lifeless, is a theme change something to consider?
[17:04] <lifeless> zyga: jml will be discussing lp with the canonical design folk
[17:04] <lifeless> its really a very separate discussion to bzr
[17:04] <zyga> lifeless, who is jml?
[17:04]  * zyga remebers you mentioned that nick earlier
[17:05] <lifeless> LP product strategist
[17:05] <lifeless> aka product manager
[17:05] <lifeless> you might say that hes the 'what' guru for LP, and I'm the 'how'
[17:06] <Tak> but who are the where and the why?!
[17:06] <zyga> lifeless, thanks for the info, I look forward to changes in that regard
=== beuno-lunch is now known as beuno
[18:19] <gthorslund> lifeless: since you are the 'how', could you help me with some merges? got one for each of the bugs in https://bugs.launchpad.net/bzr-bisect . (but only one bug would end up being fixed, the other one just reproduced with a test case (or two))
[18:24] <lifeless> gthorslund: of launchpad, not bzr.
[18:25] <lifeless> gthorslund: however, I'm sure someone here can help you :)
[18:25] <lifeless> perhaps jelmer
[18:25] <gthorslund> lifeless: thx
[18:25]  * gthorslund looks around for jelmer 
[18:25]  * jelmer crawls out of his corner
[18:26] <jelmer> gthorslund: is there an official maintainer of bzr-bisect? I don't remember who originally wrote it.
[18:26] <jelmer> lifeless: you're up early!
[18:27] <lifeless> jelmer: this isn't early - 0730
[18:28] <jelmer> lifeless: Oh, ok - Sorry, I keep forgetting you're in NZ now
[18:28] <lifeless> :)
[18:28] <gthorslund> jelmer: can't find one. Jeff Licquia, Daniel Watkins, James Westby are in the log
[18:29] <jelmer> gthorslund: ah, I guess Jeff is the original author.
[18:29] <gthorslund> jelmer: Vincent Ladeuil fixed a minor bug for me once too
[18:29] <gthorslund> yes, he had first commits
[18:29] <jelmer> gthorslund: I'd be happy to do a review, can you add me to the MP as reviewer?
[18:33] <gthorslund> jelmer: done now for https://code.launchpad.net/~gthorslund/bzr-bisect/539937-subtree/+merge/39785
[18:33] <gthorslund> jelmer: https://code.launchpad.net/~gthorslund/bzr-bisect/538025-doc-script-exit-code is already approved by Martin Pool (but not merged)
=== zyga is now known as zyga-afk
=== Meths_ is now known as Meths
[19:20] <gthorslund> hi vila! I was about to annoy you a bit before, but since you where not here I annoyed lifeless instead who found jelmer for me in a corner :)
[19:21] <vila> gthorslund: hehe, I'm glad they helped you ;) I just arriving from a whole day car travel so I won't be here long not very effective either ;)
[19:22] <vila> ...but my tyop-fu is still strong ! s/I just/I'm just/ s/not very/nor very/
[19:23] <gthorslund> vila: I'll head out helping my daughter with some homework so I'll not annoy anyone much more now ;)
[19:23]  * fullermd hopes you drive better than you type...
[19:23] <vila> fullermd: no problem, I drive with my feet
[19:24] <fullermd> I always figured that was how you typed...
[19:26] <vila> :)
=== zyga-afk is now known as zyga
[22:02] <glyph> Normally if I mess up a commit message, I do 'bzr uncommit' and then do it again.  But I just noticed a wrong commit message that is about 5 revisions ago (although the revision is still not pushed).  How can I edit the log message?
[22:11] <gthorslund> glyph: don't think you can, but it could be a nice feature to allow it and keep versions for log messages too.
[22:28] <peitschie> mornin everyone :)
[22:28] <jbowtie> Morning.
[22:43] <jbowtie> I think my testing really did kill a Codeplex TFS server (TFS14)
[22:48] <jbowtie> Hmm. Or maybe CodePlex is just having infrastructure issues.
[22:49] <jelmer> 'evening
[22:49] <jelmer> jbowtie: Ah, you're trying bzr-tfs against codeplex?
[22:49] <jbowtie> jelmer: Yes, trunk has been working against it for the last couple of days.
[22:50] <jelmer> jbowtie, nice!
[22:52] <jbowtie> jelmer: Thought you'd be happy. But I seem to have killed one of their servers (or maybe they're just rebooting it?)
[22:52] <jbowtie> Yeah, it seems to be some of their infrastructure stuff, might just have to wait a few hours for them to get it sorted.
[22:52] <jelmer> jbowtie: oops..
[23:07] <losing> Anyone familiar with this error: "bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-208')] "
[23:07] <losing> happens after a bzr up
[23:08] <spiv> Good morning.
[23:08] <spiv> losing: which version of bzr?
[23:08] <losing> 2.1.1
[23:10] <losing> it's not the end of the world as that branch can be deleted and recreated, but I found it rather cryptic
[23:13] <spiv> Hmm, it *might* be fixed in a later release: there are some possibly related fixes in 2.1.3 / 2.2.1
[23:14] <spiv> So I'd try upgrading
[23:14] <spiv> If that doesn't fix it, please file a bug
[23:14] <losing> fantastic, thanks spiv