[00:01] jam: thanks [00:15] hi everybody! a friend told me that there should be a .dmg for the bzr 1.0 distro [00:16] I have found it here http://phanatic.hu/bzr/mac/, but it looks like it is only for Leopard [00:16] do you know if there is any packaged distro for Tiger? [00:16] tia [00:28] mindstorms: use MacPorts [00:29] mneptok: thanks. I am aware of this option, but I currently don't have XCode installed [00:30] so it would require me to pass through quite a few hops just to get bzr working on my sys :( [00:31] that's the reason I would have preferred a packaged distro (and considering there is one for Leopard I don't think it will be so difficult to get one) [00:31] mindstorms: you're not using bzr for source code management? [00:32] that's my intention indeed [00:32] because if that's your planned use case, it seems odd not to have XCode installed. [00:32] I [00:32] *shrug* [00:33] I am mostly developing on java [00:33] plus some perl/python/ruby [00:33] none requires xcode [00:33] ah. [00:34] so... I'll probably wait to 1/ either a packaged bzr will become available for Tiger [00:34] 2/ more things will require me to install XCode [00:34] i think 2 is a certainty [00:35] so far I've managed not to install it... so I'm pretty tough here [00:35] so frankly speaking i hope 1/ is the option ;-) [00:36] mindstorms, Tiger is the new one, right? [00:36] poolie: Leopard is [00:36] Tiger=10.4, Leopard=10.5 [00:37] poolie: Tiger is OSX.4, and prolly has a fairly old version of Python by default [00:37] I think it comes by default with 2.3 [00:37] mindstorms: and that will cause you to need XCode/MacPorts [00:37] but I'm currently using 2.5.1 [00:37] mindstorms: supplied by Apple in a sysyem update? [00:37] mneptok: I don't see any relationship between python version and xcode? [00:37] *system [00:38] nope... why would that be needed? [00:38] hiya, a question that arose on #gnome-hackers, can you do cvsimport without shutting down the repo? [00:38] the cvs repo [00:38] yes, i think so [00:38] mindstorms: if bzr requires a newer Python than Apple currently ships as part of the OS, XCode/MacPorts becomes necessary to get the newer Python [00:38] as in, while still being to commit while it's importing [00:38] mindstorms, how about just installing from the tarball? [00:39] and sync it afterwards [00:39] mneptok: I don't think you are correct about it [00:39] not every importer can do incremental syncs [00:39] mindstorms, i think what he's getting at is that [00:39] mathrick: I believe cscvs can do that. Not sure about other importers (like Tailer). [00:39] a dmg may be built assuming you're using the system python [00:40] Er, "Tailor" [00:40] if my environment is correctly setup, bzr should firstly find the configured python [00:40] mindstorms, how about just installing from the tarball? [00:40] i don't think that would need anything beyond a recent python? [00:40] poolie: there are quite a few dependencies [00:40] spiv: can you use it to migrate to bzr? [00:40] including the c library [00:41] that means that I would need to build it locally => I need to install XCode [00:41] which is what I was trying to avoid :) [00:41] mindstorms: and you trust "some guy who can make a .dmg" more than MacPorts to account for and solve such dependencies? ;) [00:41] mathrick: yes [00:41] why wouldn't I? [00:41] mindstorms: uh ... [00:41] mneptok, you're not totally helping here [00:42] mathrick: if it's a public CVS repository you could get Launchpad to try mirror it to bzr for you. [00:42] should I trust somebody and use bzr or just pay for whatever other thing I can pay for [00:42] poolie: i'm trying to understand the reticence in installing Apple's developer tools in order to use a developer tool. :) [00:42] so I don't thin it is a matter of trust that should be involved here [00:42] mneptok: it is simple 1GB + time [00:43] mindstorms, afaik the compiled extensions are optional [00:43] i agree it would be nice to have a dmg built for older systems [00:43] spiv: it's not [00:43] it's about a company repo [00:43] poolie: I think you might be right... because for those it is said: recommended [00:43] but i'm just trying to work out if there's anything else problematic about using the tarball? [00:44] they will make it faster [00:44] and launchpad or not, it doesn't really matter, if launchpad can do it, so can anyone else [00:44] I'm interested in the method, really [00:44] poolie: which is quite important, but I think I can live with it till somebody will create the dmg [00:44] mindstorms: why not try the tarball, and rm it if it misbehaves or does not play nicely under Tigert? [00:44] -t [00:45] mneptok: cause initially it was my understanding that there are some external dependencies [00:45] mindstorms, there was a recent thread about this [00:45] mathrick: launchpad uses cscvs under the hood for cvs->bzr [00:46] "improved installation experience" etc [00:46] mindstorms: right. but if they cause problems, only then remove. it may be that your use cases are addressed without relying on the functionality of compiled extensions. [00:46] poolie: it is not clear that those are optional in fact [00:46] I've rechecked the page here: http://bazaar-vcs.org/InstallationFaq [00:46] spiv: aha, cool [00:46] mindstorms, what page/file are you looking at? [00:46] ok [00:46] I thought cvscs was for Arch only [00:47] and those are listed as dependencies [00:47] mindstorms, so, in that thread [00:47] it looks like people concluded "if we make a Tiger dmg, it'd need to include python2.5" [00:48] i think the general expectation is that dmgs should be totally self contained [00:48] darn i'm tired [00:48] but you think we should do one which requires/assumes you already installed python? [00:48] that could make sense [00:48] cElementTree: it's been made part of the standard library in python 2.5 [00:48] stupid me.... and playing at 3am [00:49] np [00:49] poolie: I think out Tiger dmg should assume python 2.5 is already installed [00:49] poolie: I think the installer should just look for python in the path [00:49] s/out/our/ [00:49] and check the version [00:49] mathrick: https://launchpad.net/launchpad-cscvs/ [00:50] it looks I should probably be able to run it right from the distro [00:50] spiv: ah, nifty [00:50] as I'm only missing the python dependencies which i guess can be easily installed [00:51] poolie: IIRC, Apple installers can be made to require dependencies. so an installer could check for >py2.5.x [00:51] however, I do think that a packaged distro would make the user experience a hell lot nicer ;-) [00:52] * mneptok hasn't done any Apple .pkg stuffs in a loooong time [00:52] if you have python2.5 you should not need anything else. [00:52] i'm going to follow up to that thread [00:52] I think I've mentioned that I have the 2.5.1 installed [00:52] pm me your email address if you want me to cc you [00:54] thanks guys [00:57] bah. i guess dep-checking isn't handled by packagemaker - http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/packagemaker.1.html [00:57] we curses it. [01:01] * spiv -> lunch === mw is now known as mw|out [01:40] Hey, when is bzr 1.0 likely to show up in gutsy backports? [01:40] I should I just load the debs from hardy? [01:48] nope, hardy debs are no good on gutsy. [01:48] libc6 version dep not met. [01:48] oh well, building from source. [01:55] * igc lunch [01:56] oh, can I get coloured output from bazaar, too? [01:56] ie, bzr status, bzr log, etc. [01:56] makes things much more readable. [02:00] you can install bzrtools and get cdiff [02:01] well, that's good, but that's only for diffs [02:03] bob2: long time, no see. === BentBriar_ is now known as BentBriar === jamesh__ is now known as jamesh [05:45] New bug: #177080 in bzr "code coverage unclean" [Undecided,New] https://launchpad.net/bugs/177080 [07:03] * igc dinner [07:37] poolie: right, one itch scratched. (See my just-sent merge) [07:55] poolie: the error you got was because you used a lower version than ubuntu has. [07:56] and the "Signer has no rights?" [07:56] is that just a knock-on effect? [08:01] dunno === Dunearhp_ is now known as Dunearhp [12:26] hi :-) am I blind or doesn'T there yet exist a bzr 1.0 package (newer than rc1 ) in the gutsy apt source? [12:30] zerok: there's a 1.0 package in https://launchpad.net/~bzr/+archive now, but the bazaar-vcs.org archive hasn't been updated yet. [12:30] spiv, ah ok :) tnx :) [12:34] no guarantee the ppa will be updated regularly or anything though, AIUI poolie is just fiddling [12:34] YMMV [12:34] night [12:35] lifeless: g'night [12:58] strange ... now i've clearly modified a file but for some reason it doesn't show up with `bzr status` :-/ [13:02] O_o `diff` died ... [13:04] arghhhhh where is my code O_o [13:09] Are you ignoring it? Try `bzr ignored` [13:10] And regardless of what Bazaar thinks, your file and your modifications are your business. It won't touch the file on disk unless you a) `revert` or b) `merge`, but the former case leaves backups, and the latter reports conflicts, if present. [13:10] It's not dead, it's resting. [13:10] AfC, i'm currently not even sure anymore, where my files are ;) [13:10] had probably nothing to do with bzr :-) [13:10] fullermd: Indeed :) [13:11] somethign really weird was going on here ;) [14:08] I am fleshing out a plan to move from Subversion to bzr and was wondering if anyone had thoughts on how to handle a svn:externals situation [14:10] The project is a Rails website with a front and backend that share a common set of models, so inside /frontend/app/models is set to svn:external /backend/app/models, would I be able to make app/models into a 3rd bzr project and yet somehow still check it out into the proper place on the frontend and backend? [14:13] bzr: ERROR: bzrlib.errors.NoSuchRevision: Branch has no revision monty@inaugust.com-20071218140922-2p0p7z3s1i61eo7a [14:13] so, this may not be something I can do... [14:13] but I've got a bzr repository that's a collection of branches of an upstream svn repos [14:13] I created a branch in my bzr repos, which works fine [14:14] but I wanted to push the branch, thereby creating a branch upstream. [14:14] but that didn't so much seem to work - giving the above error [14:14] am I just trying too much? [14:14] jelmer: ^^ [14:16] alienzx: there is experimental support in Bazaar for a feature called by-reference nested-trees, which are similar to svn:externals [14:16] mtaylor, Try svn-push [14:16] rather than push [14:16] jelmer: ok [14:17] jelmer: btw, doing a normal push to an already existing svn repos has been working _beautifully_! [14:17] good to hear :-) [14:19] jelmer : thanks, I'd screw something up by checking out a bzr project within a subdirectory of another bzr project I take it? [14:19] without using nested-trees [14:19] alienzx, no, that should work [14:20] cool, guess I'll find out soon enough :) [14:22] jelmer: bzr svn-push worked. thanks! [14:29] jelmer: where do you push your bzr-svn commits to? I want to play with your memory leak improvements :) [14:37] spiv: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ === mw|out is now known as mw [14:52] jelmer: have you tried building bzr-svn on mac? [14:53] I'm trying while waiting for other things [14:53] i have [14:53] it was horrific [14:53] that's my impression as well [14:53] :( [14:53] Zindar: are you on ppc or intel? [14:53] intel [14:54] Zindar: i presume you mean "building a sufficiently patched copy of the subversion python bindings" [14:54] correct [14:54] i managed to get it to work on powerpc after a lot of swearing [14:54] how far along are you? [14:55] you need a very precise version of swig [14:55] make swig-py :) [14:55] I have 1.3.27 [14:55] that should work [14:55] and iirc to replace the version of libtool in the subversion tarball [14:55] OH [14:55] really? [14:55] why's that? [14:55] Zindar: one lazy option is to install ubuntu in parallels.... [14:55] Zindar: i don't remember [14:56] Zindar: what errors are you getting at the moment? [14:56] I get this strange thing in configure of svn... [14:56] checking for apr_int64_t Python/C API format string... rm: conftest.dSYM: is a directory [14:56] L [14:56] whisky tango foxtrot [14:56] hmm.. none really.. I get through the building of svn.. and install.... and swig-py-install as well [14:57] ugh, yeah won't be going down that path [14:57] :) [14:58] Zindar: and then what? [14:59] but I install in a specific build_root... then I set PYTHONPATH and LD_LIBRARY_PATH... [14:59] and then bzr-svn dies with "wrong version of bindings" or something [14:59] zindar: and this is subversion 1.5 or 1.4 patched? [15:00] 1.4 patched [15:01] it builds quite happily.. except the strange thing above.. but seems to build... [15:01] perhaps I'm not setting some path right [15:01] >>> import svn.delta [15:01] >>> hasattr(svn.delta, 'svn_delta_invoke_txdelta_window_handler') [15:01] False [15:02] right [15:02] svn.delta.__file__ ? [15:03] ?? [15:03] what is that? [15:03] that's what bzr-svn runs to verify correct svn bindings [15:03] are you sure you're importing the version of the bindings you think you are? [15:03] not 100% sure no.... [15:04] I'm a perl and ruby guy.. not python... [15:04] so run [15:04] import svn.delta [15:04] print svn.delta.__file__ [15:04] in a python prompt [15:04] ahh [15:04] great [15:04] no.. wrong one [15:04] hmm [15:05] ok... [15:05] got the right one [15:05] still False [15:06] :( [15:06] something that can happen here [15:06] it might be using the wrong compiled binary libraries I guess? [15:07] is that iirc the processing of the swig files can fail, but you can still build the bindings from the c files that are included in the tarball [15:07] ok [15:07] so maybe delete the built extensions in your build dir [15:07] and the c that's generated from the swig [15:07] and try again? [15:07] it's a long time ago that i fought with this :/ [15:08] :) [15:12] hmm.. I would expect to see "invoke_txdelta" somewhere in delta.py [15:12] wouldn't I? [15:13] it's in svn_delta.i... but not the svn/delta.py [16:02] In response to the bug report I filed yesterday in launchpad-bazaar, someone suggested that I downgrade to bzr 0.92. I'm currently running bzr 1.0rc3 and created a branch in the default format for that version. So do I need to do anything special with that branch when downgrading to 0.92? [16:04] MattCampbell, no, 0.92 supports the new pack format [16:04] (it's calles pack-0.92 after all :p) [16:05] Ooh, auto-pack of bzr.dev's repo just added an 800 KB pack, a 15 KB one, 200, and 240. [16:11] How likely is it that bzr 1.0 on the client side would be incompatible with a smart server running bzr 0.92? [16:15] MattCampbell, seems unlikely to me, but I can't say for sure, haven't played with smart server in a while [16:25] The error that I got when trying to commit to a branch on LP yesterday, for which I filed a bug in launchpad-bazaar, has led me to question the maturity of bzr. [16:26] which is why I'm asking so many questions now. [16:27] MattCampbell, as away :D [16:27] we've all been using it in all kinds of enviroments for a long time now [16:28] I presume you meant "ask away" [16:28] MattCampbell, would you have the bug numer around? [16:28] MattCampbell, ah, yes I did :D [16:28] we [16:28] "bug number" [16:29] keyboard hates me today [16:29] bug 176978 [16:29] bug #176978 [16:30] ubotu: bug #176978 [16:30] Launchpad bug 176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server" [Undecided,New] https://launchpad.net/bugs/176978 [16:30] slow today [16:30] I was trying to trigger a response from ubotu but didn't know the format. I'm really new here. [16:31] MattCampbell: I would have thought it would trigger from what you did [16:31] MattCampbell: that is a known bug in the 0.92 smart server [16:31] fixed in 1.0 [16:31] It should; that would only involve a slight regex tweak. [16:31] OK, then I guess I'll switch to sftp. [16:32] bug 161131 [16:32] Launchpad bug 161131 in bzr "dirstate file gets damaged by commit() in a merge when there are 2 deletes in a directory." [Critical,Fix released] https://launchpad.net/bugs/161131 [16:32] bug 176978 [16:32] Launchpad bug 176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server" [Undecided,New] https://launchpad.net/bugs/176978 [16:32] MattCampbell: maybe it just doesn't like you :) [16:32] I'm guessing it was actually just being slow [16:33] jam: Thanks for your help. Someone should close my bug as a duplicate. [16:33] I'm searching for it now [16:34] (I was just testing the bug tracker with the bug I mentioned first :) [16:34] MattCampbell: I'm not in launchpad-bazaar group, but I gave the link in the bug report [16:40] I guess I can set it to duplicated :) [16:46] New bug: #176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server (dup-of: 156546)" [Undecided,New] https://launchpad.net/bugs/176978 [16:48] huh? [16:48] Why did that one just get reported as a new bug? [16:49] MattCampbell: because 'bzr' bugs are reported here while 'launchpad-bazaar' ones are not [16:49] This is newly marked as a duplicate of a 'bzr' bug [16:49] It shouldn't really claim 'New bug:' though [17:36] so, would it be an incredibly stupid idea to run 'bzr init .' inside a directory mounted with davfs2 from a webdav server? [17:38] If you did that, then you'd have a working copy on the WebDAV server. Do you really want a shared working copy? [17:42] what I want is a versioned Zope 2 TTW website [17:43] (TTW is Zope-jargon for Though The Web, implying that you can edit it with a web browser) [17:44] bzr would be no good for that, because the TTW edits wouldn't be committed to the bzr branch. [17:44] mgedmin: you'd need to write a zope zodb hook to commit to the branch [17:45] mgedmin: but writing a bzr product for zope would probably be pretty cool [17:45] And doesn't Zope 2 have its own versioning? [17:45] it does [17:45] that's like saying vi is no good because it doesn't know how to commit [17:45] * mtaylor thinks vi is no good because it doesn't know how to commit :) [17:45] zope 2 built-in versioning is a silly toy [17:46] Doesn't emacs know how to commit? [17:46] Peng: yup [17:46] with bzr? [17:46] TTW edits would be just like vi/emacs edits in a working dir: changes you have to commit yourself [17:46] mgedmin: it is not VC, but it does mean that the hooks are already there in the Zope 2PC to commit on object save [17:46] mgedmin: well that would certainly be easier [17:46] MattCampbell: yes [17:46] how much power from the filesystem does bzr want? [17:47] MattCampbell: although it doesn't know how to do more complex things yet [17:47] e.g. does it work on stupid FAT fs'es? [17:47] bzr is cross-platform, so I assume it won't need hardlinks (or symlinks) [17:47] what about atomic renames? [17:57] mgedmin: bzr runs on stupid FAT fses i think [17:57] case insensitivity can throw some curve balls [18:08] mwhudson: correct [18:13] what's the idea for post-1.0 versioning? [18:13] Stable and unstable branch or just one development branch? [18:13] if the latter, what are the version numbers going to be, 1.X or 1.0.X ? [18:14] i think 1.1, 1.2, 1.3. not sure though [18:22] jelmer: in Martin's post he said "1.1 in January" [18:22] so I think the plan is to just keep doing 1.X releases [18:22] every month [18:58] ah, ok [19:12] hey, i have a text file i guess i would like to treat as binary his this option been already added to bzr? [19:13] Treat as binary? Why? [19:14] well it takes 1.5 GB of my ram to commit now and its only 40mb file [19:14] Ooh. [19:14] its a files of a 3d model [19:14] Treeform: sorry, there's nothing binary-specific yet [19:14] most models where not this bad [19:14] Why would treating it as binary help? [19:14] Peng, well png and jpg commit just fine [19:14] Treeform: there was talk about support for streaming though [19:14] and they are big too [19:14] yes that is what i found by googleing [19:14] Treeform: so it wouldn't be necessary to keep various versions of the full file in memory [19:15] well i realy dont need to keep it versioned per line [19:15] 3d program generates it [19:17] i just need to over write it every time just like it does images [19:33] Treeform: any chance you could help us figure out why we are taking 1.5GB to commit? [19:34] like, is there a way you could make that file public for us? [19:34] espec if you could have us see the .knit file (in case it is because of history as well as just the file itself) [19:34] 40MB => 1.5GB seems like we have a rather serious bug [19:34] ok its more like 1gb [19:35] it ate up my ram and moved into the swap [19:35] which made it super slow [19:35] jam ok i will upload the file [19:45] jam, its 79mb and its here if you wan http://affuniverse.com/artdepot/Treeform/fleetbox-full2.egg.zip [19:45] the file does that on add [19:45] i have no clue what it will do on merge [19:47] Treeform: and what version of bzr? [19:47] hmm... it is only 7.9MB :) [19:47] is this just 1 copy of the file? [19:47] not the history of it? [19:48] there is no history [19:48] i just bzr add and bzr commit [19:48] you have 1 copy and it took 1GB to commit it? [19:48] yep [19:48] its zip unzip the file [19:48] will do [19:49] it unzips to 78 mb [19:49] that seems really strange [19:49] maybe i am wrong my system almost lucked up during the commit [19:49] yah, I see 80M here [19:49] i could not tell what exacty it was but i guess its this file [19:49] I won't say you are wrong, but something really odd is going on if that is happening. [19:49] Also, what repository format are you using? [19:49] and bzr version [19:50] how would you look that up? [19:50] it is ~2.6M lines long [19:50] bzr --version [19:50] bzr info [19:50] info gives the format string [19:50] --version tells me about bzr [19:51] jam, http://dpaste.com/28430/ [19:51] i think i use the one in the ubutnu apt-get [19:53] Treeform: and what Ubuntu version? You can add the Bazaar repositories here: [19:53] http://bazaar-vcs.org/releases/debs/ [19:53] something like: deb http://bazaar-vcs.org/releases/debs/gutsy ./ [19:53] It would just be good to test with bazaar 1.0 [19:53] and also possibly test with --pack-0.92 [19:53] to see if that changes things [19:54] but i dont want to version files this big any ways [19:54] i want for it to just think of it as a binary file [19:54] well, we treat binary files in almost the same fashion [19:55] there are a couple places that are different [19:55] oh so you version parts of them? [19:55] but I'm hoping that by 1.0 we fixed some of what you are running into [19:55] Treeform: all files are "binary" that just happen to have some '\n' in them [19:55] at least at the lowest layer [19:56] hmm [19:56] 'bzr diff' knows not to display files that have NULL in them [19:56] hmm that sounds as a hack [19:56] did you try the file did it work for you? [19:57] and 'merge' knows to just overwrite the file, etc. [19:57] I just finished downloading, I'll let you know in a second (I'm running some timing tests, and don't want to interfere with it) [19:59] ok and i have upgraded [19:59] 1.0 [20:00] jam, so it will treat is as binary if a tack a null at the end? [20:00] only in the beginning 1024 bytes, iirc [20:01]