[00:20] Gar, gnome-terminal just crashed. [00:21] spiv: uxterm FTW === mw is now known as mw|out [01:09] Terminator treats me right. [01:09] but then, terminal emulator religious wars have nearly as many victims as text editor conflicts. [01:10] Yeah. I mean, what's with all you freaks who don't just use xterm? :p [01:10] what's the "x" for? [01:10] :P [01:11] A beginning. Obviously :) [01:12] how linear. how pedestrian. ;) [01:13] Well, I don't own a bicycle, so... [01:13] terminator is nice [01:13] it needs less gnome widget embedding love though [01:29] I installed bzr via easy_install (1.8), when I try to branch (even with bzr itself -> bzr branch lp:bzr) I get: bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [01:29] HPSS calls: 1 [01:31] my ~/.bazaar/bazaar.conf only contains my launchpad name === sevenseeke1 is now known as sevenseeker_ [01:32] sevenseeker_: try an http url [01:33] sevenseeker_: like http://bazaar-vcs.org/bzr/bzr.dev [01:33] sevenseeker_: do you get "Permission denied (publickey)" as well? [01:34] hmmm, no I don't [01:35] although it is going veeeeery sloooooow [01:37] sevenseeker_: ok, if http is working and lp: isn't [01:37] sevenseeker_: then https:// is probably firewalled on your machine/network [01:37] hmmm, this is new [01:37] sevenseeker_: (or ssh: is firewalled, if you have done bzr lp-login) [01:38] I wonder if something updated that interferred [01:38] I greatly appreciate the help [01:40] ok, I checked with some https sites and I connect fine (through the web that is) [01:41] netstat -l isn't showing anything that I am aware of that would interfere either [01:42] sevenseeker_: try 'ssh bazaar.launchpad.net' [01:42] sevenseeker_: if that gives a network error (rather than an authorisation error) then you have a networking issue [01:42] just 'Permission denied (publickey).' [01:42] ok [01:43] your network is fine [01:43] now try ssh LPUSERNAME@bazaar.launchpad.net [01:44] same thing [01:44] ok [01:44] you haven't told lp your ssh key :> [01:44] lifeless: "ssh `bzr launchpad-login`@bazaar.launchpad.net" ;) [01:44] must have done that with another 'puter, I hope that is all it is :) [01:45] FWIW, I just bumped up the importance of https://bugs.launchpad.net/bzr/+bug/238776, which is the bug about how bzr's error messages in this case aren't as helpful as they could be. [01:45] Launchpad bug 238776 in bzr "Confusing error message if ssh login fails while using lp url" [High,Confirmed] [01:46] cool, thank you... registering now === spiv_ is now known as spiv [02:54] poolie_: I understood that a lot of bzr ops did things in a staging dir under .bzr/ and then rename()'d over into the final location (which would fail hard across file systems) [02:59] fullermd: splitting .bzr/ over mounts is not supported in any way [02:59] I mean to/from the WT. [02:59] fullermd: splitting a tree over mounts will also fail with tree transform which does lots of mv's [02:59] because it writes to .bzr/checkout/limbo and mv's from there [03:00] Yeah, 's what I thought. [03:00] (re bug 286268) [03:00] Launchpad bug 286268 in bzr "bzr commit removes files from unmounted folders" [Undecided,Invalid] https://launchpad.net/bugs/286268 [03:00] but perhaps mv on some platforms will work cross fs [03:00] by copying and rming [03:06] If I'm working with a partner, and he's branched the project and made changes, then to get those changes _I_ need to merge? [03:07] i.e. am I correct in saying that to work in the method, both people need ftp/ssh/.../ access to the other's computer? [03:07] s/the method/this method/ [03:07] Well, both people would need access to the other's branch. [03:08] right [03:08] That could as easily be a copy of your branch you push somewhere "as often as necessary", as your local copy of the branch. [03:08] fullermd, I don't follow you [03:09] Well, I could give you access to my system, and you could "bzr merge bzr+ssh://fullermd/home/fullermd/whatever" [03:09] is there a way for him to push his changes to me instead of me merging with him? [03:09] Or I could push a copy of my branch up to somewebserver, and you could "bzr merge http://somewebserver/whatever", or any other step around. [03:10] If you gave him write access he could push over your branch. That's usually not as good an idea for various reasons. [03:10] He could as above plunk a copy of his branch somewhere public [03:10] He could use 'bzr send' to email you a bundle of his changes which you could merge from as if it were a branch. [03:10] hmm [03:11] kingfishr: there are three ways he can give you his content: [03:11] - he can mail you a bundle [03:11] Depends on details of how you want to work and where the two of you can "meet up" logically. [03:11] - he can put them in a branch you can access (e.g. on http, or on launchpad, or on an NFS share somewhere, or on your machine somewhere) [03:12] - he can push them directly into a common branch (which requires a common branch you can both write to, just like cvs/svn) [03:13] * lamont wonders when bzr_1.8-1~$mumble will be available [03:13] ditto for bzrtools>1.7.0-1 [03:13] referring, of course, to https://edge.launchpad.net/~bzr/+archive [03:13] s/edge.// [03:13] stupid edge urls [03:13] lamont: poolie is working on it [03:13] cool [03:14] once it's there, I have a dance card to fill [03:14] let me give you more context: I'm working right next to a guy on a project, we're both making changes, and so far he's been merging changes from me via ftp. Now I need his changes. He'd have to set up a new user on ssh or something for me to merge his changes. [03:14] Basically, what's the easiest way for me to get his changes, if we're both feeling lazy? [03:15] Well, you've given him ftp access. Let him give you ftp access. [03:15] (or ssh, better; any opportunity to stamp out FTP is a good opportunity...) [03:15] kingfishr: 'bzr serve' in the directory he is working on [03:15] kingfishr: then 'bzr browse' followed by 'bzr merge ' [03:15] kingfishr: assuming you both have bzr-avahi installed [03:15] kingfishr: without bzr-avahi, its [03:16] 'bzr serve' [03:16] which reports a ip and url [03:16] then 'bzr merge bzr://his-ip/' [03:19] lifeless, awesome [03:20] fullermd: never forget adhocing :> [03:20] fullermd, yes, normally I'd use ssh over ftp but I already had an ftp server set up with correct permissions...again, being lazy [03:33] I tend to, because I never do it :p [03:34] Think the only time I ever used 'bzr serve' was in a bug filing... [03:34] fullermd: use bzr+ssh ? [03:40] ah, lifeless is probably right about tree transforms [03:41] it's arguably a bug if we don't fall back to copy&delete [03:42] I don't mean the SS, I mean "bzr serve" itself directly. [03:42] poolie_: well, arguably. OTOH its not exactly a common use case [03:43] right [04:19] The atomic link()'ing has the advantage that there can't be any half-formed files polluting the working tree. [04:19] (of course, the files can still be out of sync with each other, so whether that increment really matters is somewhat questionable) [04:39] 1.8 is in the ppa now === poolie_ is now known as poolie [05:21] Not sure if anyone is around... [05:22] But with the standalone bzr installer on windows, are bzr+ssh checkouts supposed to work out-of-box? [05:22] Or does something special need to be done? [05:36] abpend: They should work, I believe. [05:36] abpend: although it may depend on you having a working SSH client already installed? [06:33] poolie: Do you want to talk today? [06:34] abpend, spiv, it's meant to work without it [06:34] lifeless: only if you want to [06:34] poolie: briefly would be good [06:34] and i suppose you want a cooperative attitude too? [06:34] :) [06:52] gnight all [06:52] night! [07:14] hi all [07:21] * fullermd waves at vila. [07:34] * vila waves back ! [07:49] gnome-terminal has crashed for the second time today. [07:49] Not happy. [07:50] * gour uses urxvt [07:50] Really? [07:50] * AfC hasn't had gnome-terminal crash in years and years. [07:50] Hey, no fair! We already had the your-terminal-emulator-sucks discussion earlier on! [07:50] You can't double-dip. [07:51] today? [07:51] Less than 7 hours ago. [07:51] ahh, that's almost yesterday here ;) [07:51] 02:50 < fullermd> Hey, no fair! We already had the your-terminal-emulator-sucks discussion earlier on! [07:53] oops, sorry [07:54] For bonus points, I also had X crash today. [07:54] Has bzr eaten any of your repositories? [07:55] Nope. [07:55] * gour is learning python (reading DIP book) and wrapping his head around python's 'and-or trick' [07:56] bzr has given some scary errors that superficially looked like repo corruption on the repo my wife keeps her PhD thesis in, though. [07:56] But that's as close as it's got. [07:56] Well, just replace X and your terminal with bzr then! With that easily-extensible architecture, you should be able to bang up a plugin in no time flat! [07:57] fullermd: bzr vte? Scary thought. [07:57] Well, it'll take 10 times as long to start up as gnome-terminal, but it'll only be 3x slower once it's running. And the UI will be nicer. [07:59] * fullermd . o O ( bzr -geometry 80x25-58+49 -iconic [...] ) [08:00] Hello, I am bit confused about 'bzr update'. [08:01] AfC: I hadn't had gnome-terminal crash in a very long time either. It's a bit disorienting :) [08:01] alf_: any specific aspect of it, or just the command in general? [08:01] All it does is to update the working tree according to the branch information? [08:02] * fullermd nods at alf_. [08:02] * gour prefers working in DVCS env and uses pull [08:02] alf_: right (although that may involve doing a merge if there are local changes) [08:03] spiv: I am actually puzzled because when using it on a non-checkout branch it does nothing, it says all is up-to-date [08:04] Well, that's what it does in any branch when the working tree is up to date with the branch :) [08:05] So it only acts locally even though the remote branch may have diverged. [08:05] alf_: pull does an implicit update. So you're probably not used to thinking about it. [08:06] IT works on your working tree, and the branch it's a WT of. If that branch is local, it only acts locally; if the branch is somewhere else, it acts there too. [08:08] fullermd: Sorry, by remote branch I meant the mainline the local branch is the copy of. [08:09] So if I have a bound branch the 'local' branch information is actually the remote one and that is why it actually works like 'bzr pull'. [08:09] * fullermd drags "bound branch" out behind the woodshed and drops a load of buckshot into it. [08:10] When do you "bzr checkout bzr+ssh://wherever/" (or any other URL/path of course), you're making a new working tree on the branch at bzr+ssh://wherever/. So 'update' will involve updating that working tree to that branch. [08:11] When you have an all-in-one (e.g., the fruits of 'bzr init', or 'bzr branch foo'), the branch at the WT are colocated there, so update would update that WT to the branch sitting there. [08:11] Mostly, it's harder to get those out of sync. One way is by push'ing to the branch from somewhere else; that'll update the branch, but won't touch the WT, so it will then be outdated. [08:12] But the point of checkout's is to allow multiple WT's to share a single branch, like in CVCS, so it's much more common for the branch to move ahead of the WT. [08:13] Which is why, speaking very roughly, 'update' is mostly used with explicit 'checkout's. [08:16] OK, I got it, thanks. As a side note the === Verterok is now known as Verterok|off [08:19] 'bzr help update' documentation could use some clarification on the matter. [08:20] Probably. [08:26] I just realized that the branch/checkout pull/update thing totally makes sense. I used to think it was just an icky svn-ism. [08:27] That doesn't make it ideal, but at least I get it now. [08:30] Peng_: exactly my thoughts, too. Perhaps this conversation (or the gist of it) should be added somewhere in the wiki or the guide. [08:31] Well, it makes sense if you (a) concentrate on Checkout, Branch, and Repository, and keep track of which piece is where in your setup, and (b) shoot "bound branch" in the back of the head when it's not looking, and with it any concept of the special-ness of heavy checkouts... [08:32] It's when you get those implementation details in your mind that otherwise rather clear things start getting really muddy and special-case-looking. [08:33] I keep meaning to try and write up a good defense/exposition from that angle. I plan to as soon as I get caught up on some other things. 2063 is looking like a good year for it. [08:34] Eh, I didn't think about heavyweight checkouts. [08:34] Well, don't :] [08:35] I only understand it because of the implementation details. [08:35] I mean, of course I knew how to use branches and checkouts, but I didn't understand why the commands were different. [08:35] And now I do. :) [08:35] Update updates a working tree to match a branch. Pull updates a branch to match another branch. [08:35] (it also often updates a colocated working tree if one's there, but that's a side matter) [08:36] Colocated working tree? [08:36] It's not quite as simple as "branch->pull, checkout->update"; pull can make perfect sense used in a checkout, if that's what you're intending to do, and I use update in non-explicit-checkout trees all the time. [08:37] Yah, when you have a branch and WT sitting in the same place. [08:38] Oh. [08:38] I don't have a better term. "standalone branch/tree" already has meaning in opposition to "repository b/t". [08:39] I need to stop thinking about this. I understand it now, and if I think any more, I might confuse myself. [08:39] "tree" by itself is way too generic, though it's the component of the rest of out terms that refers to the construct. [08:39] (Psst, hg is simpler. :P ) [08:39] * Peng_ hides [08:39] Well, so is RCS :P [08:39] :) [08:39] And safer, too, 'cuz it has locks! [08:41] Really, what makes hg simpler here is that it doesn't let you separate the WT from the branch. [08:42] So, if you just edit bzr to remove 'checkout', it'll be just as simple :p [08:42] It doesn't exactly separate branch and repo as much either. [08:43] Kinda sucks all around, this bzr/hg/git thing, y'know? [08:43] They're so similar, you forget the differences, and cause yourself no end up pain working between them. [08:43] And they're so different, you forget how similar they are deep down and start ending up with invalid conclusions about relative capabilities. [08:43] bzr does lack a neat way to work with groups of branches. [08:44] On the other hand, we DO already have all this capability of working with the pieces independantly, which makes it conceptually much EASIER for us to add that feature, than for e.g. git to add the capbility to split up as we do. [08:44] We'd be 90% of the way there by having a WT and Repo colocated, with the Branch's elsewhere, that elsewhere being somewhere under .bzr/, with better support for sibling-pathing in various branch-referencing commands. [08:44] That's the main point of its UI that actually seems to be a bit weaker than some other systems, rather than just being more flexible :) [08:45] fullermd: well, looms give you something sort of like that, but with perhaps a bit too much policy builtin. [08:45] Eh. Looms give you a stack, not a set. [08:46] fullermd: but looms do demonstrate that such a thing isn't fundamentally hard to build. [08:46] Useful, but for different things. [08:46] The biggest stumbling point is, that, sibling-reference syntactic sugar aside, branches are named by location rather than name. That can make some things harder. You end up doing a lot of heuristics to make things in a multi-tree LOOK like they're using names locally. [08:48] And threads in a loom are like branches, except different. I think in designing multi-trees we need to try to avoid making a new branch-like object; it just adds more special cases and confusion. [08:48] Gotta just adjust how they can be referenced and moved around. [08:48] * fullermd has it all figured out... everything but the code to make it happen! [08:49] Yet another on my list of things to braindump in 2063 :p [09:47] Has anyone had trouble getting `bzr serve` to run as at bzr 1.8? [09:50] Not in a quick test (or in the various bzr+ssh'age I've done since the upgrade) [09:52] Hm. [09:52] Well, bug filed. I have no idea WTF, but I had to downgrade back to 1.7.1 [09:53] What bug? [09:54] (holy christ launchpad is slow) [09:54] Q: What is the difference between a merge and a pull? [09:54] fullermd: Here we are: https://bugs.launchpad.net/bzr/+bug/286871 [09:54] Launchpad bug 286871 in bzr "bzr serve doesn't" [Undecided,New] [09:54] Found it. [09:55] Note that it's blowing up AFTER trying to raise the error for failing to bind to the address/port. [09:55] fullermd: yeah, I saw that too [09:55] So the tuple out of range is a secondary failure. [09:55] But it shouldn't be having trouble binding [09:55] The real question is why can't it bind, and that wouldn't change 1.7.1->1.8 I wouldn't think. Weird. [09:55] Maybe you had a TIME_WAIT socket hanging around? [09:56] fullermd: I wouldn't have thought so either. [09:56] fullermd: I tried different ports [09:56] fullermd: so that's not it, [09:58] Got me, then. [09:58] Always a little disturbing, when something gets an error trying to give an error... [09:58] I can't duplicate it locally, of course, which makes it even more of a piss-off [09:58] Some sorta weird selinux-like thing screwing around with what it lets bind where? [09:59] {shrug} [09:59] If it works with 1.7... [09:59] Well, if the program/lib/whatever were in a different place... [09:59] Fair enough. But no, we don't run SE or any of that. [10:00] * fullermd is inclined to blame selinux for any fault on any linux system. Or most non-linux systems, for that matter... [10:00] fullermd: Ok, you've gone from being intelligent to talking shit. [10:01] Er, yeah. In about 1992. Try and keep up here :) [10:01] :) [10:14] night [12:08] AfC: Looks likely to be due to the change to allow bzr to bind to IPv6 addresses -- I've added a comment to the bug. [12:39] * lamont grumbles about bzrtools/dapper being ftbfs [12:44] A Bazaar icon suddenly appeared in my notification area [12:44] What am I supposed to do with it? [12:45] cyberix, it's part of bzr-gtk [12:47] Why do I need it? [12:49] I don't think you do [12:49] there's a bug open for that [13:14] spiv: I'll have a poke in the IPv6 direction in the morning. [14:39] anyone have a good guide as to using bzr to publish a website? [14:40] there's one on the wiki afaik === toytoy_ is now known as toytoy [14:45] Hi all. I want to add a new feature to bzr using a plugin, a feature that (I think) goes beyond the foresight of the designers. Is there a place in the .bzr/ tree that is safe for me to use? I want a guarantee that I'm not going to break anything and future updates to bzr aren't going to break because of my addition of a new file in .bzr/ . Essentially, I want a /usr/local/ inside .bzr/ . [14:46] CardinalFang, afaik you should be able to use anything under .bzr as long as it's not named {branch,repository,checkout}{,-format} [14:48] Even in 10 years? [14:49] CardinalFang, never say never [14:50] Instead, write specs that say "MUST". [14:50] CardinalFang, there's no mechanism to maintain who can use what [14:50] CardinalFang, s/maintain/determine/ [14:50] CardinalFang, bzr-svn sometimes uses a "svn" directory there, for example === mw|out is now known as mw [14:50] so probably best to just take some name that is unlikely to clash with anything else [14:52] Okay. May I suggest "plugin-local/%(plugin_project_name)s" ? [14:53] TBH that seems a bit overengineered to me, generally plugins don't have to write anything there [15:00] I just don't want bzr or another author stomping on my toes when I name something "attributes". [15:01] "plugin-local" is to protect bzr. project name is to protect me. [15:02] It doesn't prevent somebody else from creating a plugin named "attributes" [15:02] Your best bet probably is just to make sure the name is unique [15:04] My plugin is uniquely named. I'm referring to a file I want to create in .bzr/ . [15:04] Alright, i guess I got all I'm going to get. Thanks, j. [15:05] There's not really a good way to solve these things.. you need a central authority to control who gets to use what names or something :-) [15:07] CardinalFang: If you tell more you may get more, for a start what .bzr are you talking about ? The repo one (shared or not), the branch one (with or without tree), the tree one ? Do you expect that directory to propagated on pushes, updated on pull, can there be conflicts ? etc. Otherwise .bzr is private to bzr if you put something here, *you* are responsible for maintaining it and protecting it [15:09] The branch .bzr . It will /not/ be propagated on pulls or pushes (that's the point). I know it's private to Bazaar; I want a reserved space for plugin authors to use. [15:09] vila, ^ [15:11] There is no reserved space that I know of at that point, but an addition to the branch that doesn't propagate sounds strange... Are you sure it's not for the working tree ? [15:11] Yes, I'm sure. This is not versioned information. It /must not/ be. [15:13] Well, I can't provide advices in the dark, I've done my best with what you provided and my limited knowledge... The last thing I can mention is that you can specify some info in branch.conf and locations.conf that are related to branches [15:16] vila, Yes, thanks. De facto standards as good as de jure. I'll just do it and mention it in the wiki. [15:17] vila: ping [15:21] jam: pong [15:22] how's it going? [15:22] Were you able to merge my bzr-gtk patch without any problems? [15:22] * jam is still not sure why he isn't a part of the bzr-gtk developers, but it doesn't really matter in the end [15:22] yup :) bundle are smarter than I thought, your commit is now on trunk [15:23] because you didn't register there ? [15:24] jam, I wasn't aware you weren't part of the bzr-gtk developers at least :-) [15:24] well, I probably never tried [15:24] jam: It's quite paradoxical given that you're quite high in bzr stats output :) [15:24] for now, I'm happy enough with that :) [15:24] jelmer: same here :) [15:24] jam, you're not a member of the launchpad team or voting rights in bb? [15:24] vila: that's just because when I develop I commit a lot [15:24] jam: yeah, sure :) [15:24] jelmer: I'm not part of either [15:25] vila: I only developed the per-file commit code [15:25] and maybe some diff tweaking [15:25] jam: haaa, you're the one... We need to talk then :) [15:25] Probably my total lines of code is smaller than my total # of commits [15:28] What is the rationale of iter_changes_to_status() in diff.py and why not using tree.iter_changes more directly ? [15:28] Because it was private in this time ? [15:32] jam: Anyway, it sounds that iter_changes_to_status() traceback when invoked on trees with conflicts (or partially resolved conflicts) [15:34] In particular it seems to fail when invoked on contents conflicts, but I've yet to reduce the reproducible scenario [15:38] seeing file names ending in .OTHER.OTHER in bzr st output, added section, makes my eyes bleed [15:50] vila: I'm not really sure. My guess is that iter_changes_to_status is meant to build up the 'status' style listing which breaks things into added/removed/etc sections [15:51] rather than just spitting everything out as one-line changes [15:51] (consider 'bzr st' versus 'bzr st --short' [15:52] but gcommit presents them in their raw form and the columns (type, path) are not even sortable... [15:53] anyway, see https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/5 [15:53] Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Confirmed] [15:54] I wish direct links to comments had an obvious way back to the bug [15:54] james_w, I'll have a look at hiding that bzr-gtk icno when it's not used [15:54] jelmer: cool, thanks [16:01] jam: Exactly my thought a few hours ago, I ended up editing the url [16:01] vila: yeah, me too. Did you try my reproducible way? [16:01] It is pretty trivial to trigger with "bzr add foo; rm foo" [16:02] jam: eerk, where did you write that ? [16:02] vila: look at https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/4 [16:02] Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Confirmed] [16:02] or https://bugs.edge.launchpad.net/bzr-gtk/+bug/286834/comments/3 [16:02] (you want comment 3) [16:03] damn it, my page was already opened when you wrote that :-( [16:05] ok, then I may have a guess on what files trigger that, it seems to occur when repeatedly merging from a branch where, at the first merge, you said I don't want that file (or containing dir even) and then they keep coming back [16:06] jam: or something along those lines, [16:06] s/,// [16:07] at least the ones I got when doing 'bzr resolve --all' without solving the conflicts seem to match the pattern [16:07] so for 'bzr resolve --all' I would expect the merge to conflict on deleting a file [16:07] and after resolve --all it will have implicitly deleted the .OTHER file [16:07] so [16:08] touch foo [16:08] bzr add foo [16:08] bzr commit [16:08] bzr branch . ../other [16:08] bzr rm foo [16:08] bzr commit -m rm [16:08] cd ../other [16:08] echo mod >> foo [16:08] bzr commit -m "mod foo" [16:08] cd ../ths [16:08] bzr merge ../other [16:08] bzr resolve --all [16:08] bzr gcommit [16:10] jam: watch your language :) === fta_ is now known as fta [16:20] jam: works [16:21] vila: so I think the fundamental issue is needing a way to represent "added but missing" files [16:21] I would probably be fine with just a plain "missing" category [16:22] and ignore whether they were just added or have been around a while [16:22] addding a foo.OTHER file ? [16:22] kinds[1] is None and versioned[1] is True [16:22] vila: when you have a delete conflict, we add .OTHER [16:22] as a way to "restore the file" but indicate "it was deleted in this" [16:22] we need to put the modified content somewhere [16:22] I think abentley thought .OTHER was the best way to do it. [16:23] But *committing* that ? [16:23] I'm not sure that I have a strictly better solution [16:23] vila: that is why it is marked conflicted [16:23] It's likely a user error [16:23] so you can't commit until you do something to resolve it [16:23] (resolve --all, being a really big hammer) [16:24] I strongly suspect that a bzr resolve [--all] was issued in a hurry and that the intent is *not* to commit that file [16:25] Now 'bzr commit' does indeed commit it... obeying user orders... [16:32] jam: on second thought, I see your point about a missing section and indeed that seems to be the missing bit (ha ha) in iter_changes_to_status() [16:37] jam: thanks for the help, I'll fix it from there [16:37] vila: np [16:38] * vila runs to the school meeting [17:02] james_w, btw, how's your archive importing going, or is that on hold until intrepid? [17:03] it's going ok [17:03] I need to stop working on other things to get the final bits in place [17:03] the main two tasks are to document everything, and write the incremental importer that imports new uploads outside of bzr [17:38] if someone with upload privs to ~bzr wants to fix bzrtools/dapper, that'd be lovely. (sed -i s/central/support/ debian/{rules,control}; bump version, upload) [17:40] lamont: If you want to post that as something I could actually do with "patch" then I'll be happy to bump the branch [17:40] I'm currently on win32, though, so I can't rebuild the package [17:41] jam: I'll do that in a bit and poke you [17:45] jam: http://people.ubuntu.com/~lamont/bzrtools_1.8.0-1~bazaar~dapper2_source.changes et al [17:45] lamont: doesn't seem to be there yet [17:46] lamont: is there a subdir I'm missing? [17:46] with wget? shouldn't be [17:46] lamont: with Firefox atm [17:47] and wget also gives a 404 [17:47] 10:47:11 (52.29 MB/s) - `bzrtools_1.8.0-1~bazaar1~dapper2_source.changes' saved [899/899] [17:47] wget loves me [17:47] wget http://people.ubuntu.com/~lamont/bzrtools_1.8.0-1~bazaar1~dapper2_source.changes [17:47] the 1 works better than the 2 [17:47] ah, yeah. missing 1 on the bazaar bit [17:47] bad monte. [17:48] anyway, the .changes needs to be resigned, and the 3 files uploaded to the ppa (obviously) [17:50] lamont: well, I was hoping to have a patch that I could apply and 'bzr commit' first [17:50] oh. [17:50] meh [17:51] http://people.ubuntu.com/~lamont/bzrtools.diff [17:51] keep or don't keep the debian/changelog part of that. :-) === Verterok|off is now known as Verterok [19:24] are there any graph generators for bzr? Something to graph commits between certain dates [19:41] synic: there is something in bzrtools that may do what you want [19:44] synic: Does 'bzr viz' in bzr-gtk do what you want? [20:03] lamont: odd, when I go to apply your diff to ~bzr/bzrtools/packaging-dapper it already has the right values [20:03] I'm not sure what happened with Martin's packaging [20:03] jam: I was just going off the bzr repo packages... [20:03] so yeah [20:03] Isn't that the bzr repo ? [20:03] or you're saying that didn't make it into the .changes file, and you were just copying it? [20:29] There's some way to do external dependency branches in modern bzr versions, yeah? Like having one branch get checked out into a specific place when checking out another branch? [20:31] mkanat: That's been experimental for ages. [20:31] Is it even possible right now? [21:07] jam: visit https://edge.launchpad.net/~bzr/+archive and note the big red X at the bottom of the page... [21:07] the bits uploaded to the bzr ppa, are not the ones that build [21:07] (for dapper, bzrtools, that is) [21:13] vila: tu es là? [21:33] jam: the T_LONGLONG thing is probably a new-pyrex-old-python thing === jaypipes is now known as jay-dinner [22:19] * Linuturk starts playing with bzr as a document repository/backup solution [22:26] how well does bazaar handle non text files [22:26] ? [22:26] like images and office docs? [22:27] video and music files as well [22:27] things you'd find in your typical /home directory [22:27] I currently use unison to sync, but revision control might be a better method [22:28] depends on your definition of ""2Dhandle [22:29] hi [22:30]