[00:05] jamesh: thanksgiving ... tab-completion [00:27] tab-completion? being python it can probably use optcomplete and get it for free [00:27] assuming it uses optparse [00:28] moin all [00:30] sabdfl, hi [00:30] howdy poolie [00:30] sabdfl, if you're free i'd like to talk to you later [00:31] sure === abentle1 is now known as abentley [00:45] floam: we derive from it [00:46] Oh, bundle is a hidden command? Why? Because of send? [00:46] floam: but we have subcommands and stuff [00:46] Peng: yes [00:46] now just make completions for fish.. [00:46] (yes, I'm a weirdo) === mw is now known as mw|out [01:17] lifeless: ping [01:18] lifeless: unping === thumper is now known as thumper_laptop === thumper` is now known as thumper [02:25] thumper: ? [03:30] Hmm. I just noticed that a couple small branches of mine haven't been converted to packs yet. And I messed up their shared repo situation. [03:32] Hello! Bzr is great, all hail bzr.. But.. there's this feature I noticed on the darcs wiki which looks pretty neat: http://wiki.darcs.net/DarcsWiki/SpontaneousBranches ... in bzr is there a way to merge in a bunch of patches that all have a log message starting with a common identifier eg: RT#3242 ? [03:33] at the moment I'm sort of doing: bzr log -m "9036" [03:33] to get the revision numbers, and then merging the patches in manually.. [03:36] Well, you shouldn't use patches. [03:37] Hmm, I don't think you can do that. [03:45] Sorry perhaps my terminilogy is off.. er s/patches/bundles/ ? [03:45] *terminology! [03:46] alla, how is this solved in Darcs? [03:46] If you mean bundles, then okay. [03:46] I don't think you can do that with bzr. [03:47] I don't think that's even compatible with bzr. [03:48] Well to my mind the way to solve it would be to extend the revisionspec to include matches against log file messages.. but I don't know squat :D [03:48] alla, you could get the revision numbers from log and then cherrypick-merge them [03:48] Oh. [03:48] it won't be as slick as on darcs, because they just treat branches as a bag of patches [03:48] alla, that might be interesting [03:48] you could write a python script to merge them all [03:48] What I was just talking about was with exactly what bzr was talking about. [03:49] Not what you were talking about. [03:50] poolie: is cherrypick-merge a special plugin/functionality? Or does that just refer to the process of merging with revision numbers? [03:58] i seem to have badly locked my central server repo [03:58] bzr break-lock works, but then the next invocation of bzr complains about another lock [03:58] sabdfl: Packs? [03:58] this server has 0.17 [03:58] nope [03:58] Oh. [03:59] Shouldn't hurt to upgrade. [03:59] not my server [03:59] * beuno used to delete the lock/ dirs manually when 0.17 locked itself that way [03:59] bzr+ssh? [04:00] beuno: how do i do that? [04:00] oh, heck, didn't see the time, got to run [04:00] thanks for any help typed here! [04:01] sabdfl, if you've got ssh, you should be able to delete the folders inside .bzr [04:01] hmmm.. is there a way to merge in multiple revisions in one go..? Something like bzr merge ../somerepo/ -r 3..4,10..12 [04:01] ah, np, good evening/morning :D [04:01] Which would give you revision 4, 11 and 12 I guess. [04:01] Because subsequent merges, require subsequent commits... [04:02] Where are a bzr merge ../somerepo/ -r 10..12 .. pulls two revisions over, but only requires one commit. [04:03] alla, you want to merge each revision individually? because otherwise, normal merging will bring in all of the revisions [04:03] beuno: Yes individually.. cherry picking only the relevant changesets across. [04:05] Ie, if there are 10 changeset (10 commits) in the branch, and I want to only grab the changesets with revision numbers: 3, 6, 8, then from what I can see I need to perform three separate merges and three separate commits. [04:05] Whereas ideally, I would perform 1 merge consisting of three changesets, and 1 commit. [04:06] Ideally with Bazaar, I guess you should change your workflow to not use so many cherrypicks. [04:06] alla, you could use PQM to solve that [04:07] alla, http://bazaar-vcs.org/PatchQueueManager [04:08] (the workflow, maybe not the specific case) [04:10] and/or something like bunddle buggy: http://bundlebuggy.aaronbentley.com/ [04:43] sabdfl: bzr break-lock centra-server-url [05:20] beuno: I don't think my workflow / use case is particularly exceptional. I just want to merge in a bunch of changes from a fellow developers branch. Ie pull over the relevant changesets into my branch, and merge them in. [05:32] hi all [05:32] While pushing my branch to bzr in launchpad I am getting an error like this: [05:32] No handlers could be found for logger "bzr" [05:32] Is this related to https://bugs.edge.launchpad.net/bzr/+bug/152746 [05:32] Launchpad bug 152746 in launchpad-bazaar "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [High,In progress] [05:34] any work around for this problem ? [05:37] baijum: you can replace bzr+ssh with sftp for now/ [05:40] lifeless, with sftp, I am getting an error like this: [05:40] bzr: ERROR: Can't rename /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/6cwjx3rh21.tmp to /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/held already exists [05:49] baijum: thats probably due to hitting ctrl-C on the previous operation [05:49] baijum: bzr break-lock sftp://.... will fix that [05:52] lifeless, thank you very much, that worked ! [05:52] lifeless, Can I switch back to bzr+ssh later ? [05:54] probably right now if you like [05:56] lifeless, thanks ! [06:12] lifeless: i've done that a couple of times [06:12] both remotely, and locally on the server [06:13] Hi, is there a way to merge in multiple non-sequential revisions in one go..? Something like bzr merge ../somerepo/ -r 3..4,10..14 [06:14] sabdfl: is it devpad, or bazaar.lp.net ? [06:14] alla: no; but you can do 'bzr merge ../somebranch/ -r 3..4'; 'bzr bzr ../somebranch/ -r 10..14 --force' [06:19] lifeless: devpad [06:19] Gaack! [06:19] what branch is giving you trouble ? [06:19] I'm frequently getting "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." when trying to bzr upgrade. [06:20] In this case, it was switching from dirstate-tags to dirstate to see what would happen. [06:21] Peng: I don't think we have a downgrader written for that; there is nearly no reason to do so. [06:22] lifeless: my /code/mark/launchpad/project-news branch [06:23] It was after reading a mailing list message in the rich-root thread that said "Our framework for conversion doesn't handle the case of "might be compatible, depending on features used" very well.". [06:23] I was curious what the error would be. [06:23] Peng: dirstate and dirstate-tags both have the same repository format; you can't trigger what aaron talks about between the two [06:24] ... [06:24] Peng: you'd need knit3 and knit, for instance, but don't have knit3 exposed as its not supported yet [06:24] They're a different branch format? [06:24] dirstate and dirstate-tags differ only in branch format [06:25] sabdfl: ls project-news/.bzr/branch/lock/held -ld [06:25] drwxr-sr-x 2 mark lpteam 4096 2007-11-21 03:53 project-news/.bzr/branch/lock/held [06:25] sabdfl: its definately held; and your repository isn't locked [06:25] held? [06:26] nothing should be accessing that branch/repo right now [06:26] sabdfl: when you break-lock, does it error ? [06:26] no, it asks me twice, i say y both times [06:26] the next operation says it can't get the lock [06:26] rinse and repeat [06:27] lifeless: If they're a different branch format, why does it just mention the repository format in the error, then? It gives me the impression that it only checked the repository and not the branch or working tree. [06:27] i have a flaky connection from here (:-)) and had to ^C a push earlier [06:27] btw, what's /var/lib/misc/passwd.db and why does bzr try to access it? [06:29] sabdfl: Google says "[PAM] [c]aches name service directories (passwd and group) locally in /var/lib/misc/passwd.db and /var/lib/misc/group.db." [06:31] Hmm. I guess it's just a UI issue with the error message. [06:31] sabdfl: getent [06:31] sabdfl: I would guess that is. [06:31] sabdfl: please break-lock, and don't do anything else. Tell me when you've done so. [06:32] locally on the machine, or remotely? [06:32] give bzr the remote url [06:32] as in, do what you have been doing so far [06:32] i did it locally [06:34] lifeless: My desire is to be able to merge in multiple non-sequential changesets that are functionally related. The changes will conflict when running the second merge with --force. [06:35] alla: it will only conflict if it would have conflicted in a single command [06:35] Has anyone else observed `bzr serve` instances leaving connections in CLOSE_WAIT for a *long* time? [06:35] lifeless: ok maybe I didn't test it right. [06:39] AfC: I don't think so; jml is son leave and he'd know for sure from the supermirror [06:40] lifeless: want a bug report for the observation? I only noticed because (obviously) we get low traffic and it's really obvious... [06:40] AfC: please === dholmster is now known as dholm [06:44] Launchpad is borked. I'll try to do it later. [06:44] AfC: thanks [06:44] AfC: borked how ? [06:44] +filebug reporting error page [07:45] Is this a bug?: If the revision that you specify to merge, occurs after the point of divergence then the actual changesets seem to get lost. For example: [07:45] Say you had two branches that diverged at revision 300. Then both branches had another say ten different commits added to them both. [07:45] If I'm in one branch and I run: `bzr merge ../otherbranch -r 305..306`, then run `bzr status`, it does _not_ report that there are pending merges awaiting commit. [07:45] Whereas if I had run the merge command from the point of divergance: `bzr merge ../otherbranch -r 300..306`,then `bzr status` reports pending merges. bzr ver 0.92.0 [07:50] bbiab [07:50] alla: this is documented I believe on our cherrypicking web page. [07:50] alla: basically, we allow you to *do* cherrypicks, but not to *record* them. We will be fixing this in the future, hopefully shortly after correcting our network performance. [07:52] How is network performance going to be improved. I mean, what are you planning to do? [07:57] two main things [07:58] streaming push and pull fine tuning [07:58] in hpss, this is largely there but not all the way [07:58] the network performance seems not too bad to me anymore, with the newest type of storage [07:58] secondly, the negotiation to decide what is being pushed/pulled will be tuned [07:58] worst part for me is waiting for SSH to connect === jamesh_ is now known as jamesh [07:58] reduce round trips [07:58] send relevant data, that sort of thing [07:59] and then a second time, to update. takes 3-4 seconds usually just to establish a connection typically [08:03] lifeless: Ok cool. Thanks for the info. [08:50] New bug: #164288 in bzr "bzr serve leaves connections in CLOSE_WAIT a *long* time" [Undecided,New] https://launchpad.net/bugs/164288 [10:07] Yuck. Pushing a 1.6 KB pack on a 100 KB repo took like 20 seconds. Whee round-trips. [10:42] can someone confirms that james_w here is james westby in RL, I want to get in touch with him [10:47] vila: yes [10:47] dato: thanks === cprov-away is now known as cprov [11:18] Peng: interesting; we try to optimise out round trips by reading 64KB at a time; did something else happen? how many packs do you have in the repo? was there a progress bar and what did it say was happening ? [11:18] * lifeless sleeps [11:21] lifeless: There were about 4 remote packs, the largest 20 KB and the rest about 2. [11:21] lifeless: Several more local packs from things I've uncommitted. [11:23] lifeless: No progress bar. [12:13] hello :-) [12:13] there is somebody ? [12:13] how does it work ? [12:17] hello [12:18] fgsd [12:23] theSoftMan: just ask your question, and if somebody who knows the answer is around, they will answer you. [12:25] ok thanks ( it's the first time i use an irc chat ) [12:25] my question is : [12:25] what GUI can i use for bazaar on windows system ? [12:26] what's the most user friendly ? [12:26] like the winCVS program then i use actually. === mrevell is now known as mrevell-lunch [12:52] theSoftMan: i hear that QBzr is ok [12:53] (don't use a gui for bazaar or windows myself, so take this with a pinch of salt) [12:53] * mwhudson files bug 164324 [12:53] Launchpad bug 164324 in bzr "pushing to non-ascii url breaks both with bzr+ssh and sftp" [Undecided,New] https://launchpad.net/bugs/164324 [13:00] New bug: #164324 in bzr "pushing to non-ascii url breaks both with bzr+ssh and sftp" [Undecided,New] https://launchpad.net/bugs/164324 === mw|out is now known as mw === mrevell-lunch is now known as mrevell [13:34] thanks for answering... i see the last version was released on november 2007, i try it immediatly [13:38] Bazaar has pretty frequent releases. [13:40] Usually just about monthly. [14:09] hey schierbeck [14:12] hi jelmer :) [14:14] jelmer, am i the only one who thinks that the development of bzr-gtk has come to an abrupt halt? [14:15] it's been more than a week since the last new revision in trunk, despite there being so much work to do... [14:15] nope :-) I'm busy with some other things at the moment, don't have time to look into bzr-gtk [14:15] jelmer: what about phanatic? [14:16] the same appears to be the case for Szilveszter [14:16] do you have some open merge requests? [14:16] abentley: ping [14:16] well, the menubar branch for starters [14:16] it contains a lot of improvements [14:16] and i have other branches based on that [14:17] but i never seemed to get a definitive answer on whether it was approved or not [14:20] schierbeck: Can you bring it up on the mailing list again? [14:21] I'll see if I can get bundlebuggy for bzr-gtk back up [14:22] New bzr user switching from svn. Single developer on multiple machines.On svn I stored the main repository on a server and did checkouts. Can the same accomplished with bzr's shared repository, but without losing the ease of local branching? [14:22] Hi all [14:22] For once, I'm not coming to report a bug :-) [14:22] jelmer: okay [14:22] hey Lo-lan-do [14:23] hi panosl [14:23] I'm looking for insights about rebasing. [14:23] If I rebase a branch of mine, and some people have branched off it, will then encounter problems? [14:23] panosl: If I understand you correctly, yes. [14:24] Lo-lan-do, bzr will consider your branch to have diverged [14:24] so they'll have to "bzr pull --overwrite" [14:24] jelmer: Hm. And if they did commits on their branch, they'll have to rebase too, right? [14:25] yes === cprov is now known as cprov-lunch [14:25] Okay. I'll probably reserve my rebasing to local, temporary branches then. [14:25] Thanks! [14:25] Also, I need to thank you again for bzr-svn: I haven't had a problem with if for weeks :-) [14:26] cool, that's great to hear :-) [14:26] jelmer: a project has already branched. If I want to move that a shared repository, can I do so without it having prior knowledge that is was branched? Since i will do a checkout from each machine after that point. [14:26] Although the setup isn't quite simple: I work in lightweight checkouts of branches stored in a shared repo, one of which is bound to the upstream SVN repo [14:27] But "cd ~/debian/gforge-trunk ; bzr pull ../gforge-sid" does exactly the right thing, and that's very very nice. [14:28] panosl: Shared repositories are just a storage optimization - they don't change what you can or can't do with a branch [14:30] Ah, question: is there a way to have "bzr missing" use --line by default? [14:30] Lo-lan-do, you can define a new alias [14:30] something like "[ALIASES]\nmissing=missing --line\n" in ~/.bazaar/bazaar.conf [14:31] schierbeck: also, garyvdm seems to have disappeared :-/ [14:33] Yay :-) [15:24] Hey guys. I have a general question regarding some source code from bzr. For communication over ssh, If i launch it with serve --inetd, it uses pipes exclusively right? Otherwise, it opens up a socket for its communication. Is that correct? === cprov-lunch is now known as cprov === mrevell is now known as mrevell-afk === mrevell-afk is now known as mrevell [17:24] lifeless, sabdfl: I'm pretty sure I know what is happening. You are trying to push over bzr+ssh to a locked location. This starts a bzr process, which starts attempting a lock. You ^C and run break-lock, which breaks the original lock [17:24] but the process is still there [17:24] and sees that now it can grab the lock [17:24] and then immediately stops [17:24] so you actually need to "bzr break-lock" 2 times [17:24] once to clean up the really stale lock [17:25] and a second after the process you spawned realizes it [17:25] Does this have to do with pushing packs over bzr+ssh? [17:25] the process would clean itself p after about 5 minutes [17:25] Peng: no, pushing knits [17:25] Peng: the bug with packs is something else entirely [17:25] Okay. [17:25] though if we fixed the current pack problem [17:25] we would then run into this as well [17:25] Nice. [17:25] with the caveat that packs don't need to hold the lock as long [17:26] so it would be harder to trigger [17:26] Oh. So it's not like you knock down one brick wall and run straight into another. It isn't always triggered. [17:27] Peng: correct [17:27] this only happens if you try to push to a branch which is already locked [17:27] it then takes 5 minutes [17:27] or 2 break-lock commands to clean it up [17:28] (5 minutes + 1 break-lock, or 2 break-locks) [17:44] Committing revision 4 to "/etc/". [17:44] modified postfix/main.cf [17:44] Committed revision 4. [17:44] when did bzr become that verbose? and is it staying that way? [17:45] elmo: Which part are you talking about? The location line, or the status line(s)? [17:45] (Or both) [17:45] Odd_Bloke: it's till me twice it's committing/committed to revision 4. I suppose I'm mostly talking about the first line, which is new (to me and/or 0.92) [17:46] It's reasonably new, though I can't remember exactly which version it was introduced in (as I tend to track bzr.dev). [17:51] 0.92, I think. Maybe 0.91. [17:55] New bug: #164370 in bzr-eclipse "first 5 lines are missing from old version in diffview" [Undecided,New] https://launchpad.net/bugs/164370 [18:17] Hey guys. I have a general question regarding some source code from bzr. For communication over ssh, If i launch it with serve --inetd, it uses pipes exclusively right? Otherwise, it opens up a socket for its communication. Is that correct? === cprov is now known as cprov-away [18:31] yay for running "bzr selftest" instead of "./bzr selftest" [18:32] * mwhudson reads abentley's latest mail with interest [18:33] abentley: interesting how the TransformPreview tests you sent me fail with "AttributeError: 'PreviewTree' object has no attribute 'inventory'" [18:33] abentley: thanks a lot for that mail, by the way [18:43] abentley: have there been schema upgrades for bundlebuggy recently? [18:43] abentley: I'm getting the following error: [18:43] raise exceptions.InvalidRequestError("This SchemaItem is not connected to any Engine or Connection.") [18:43] sqlalchemy.exceptions.InvalidRequestError: This SchemaItem is not connected to any Engine or Connection. [18:43] * jelmer isn't quite teh turbogears guru [18:44] Oh, BB is TurboGears too? [18:47] yup [19:24] Peng: interesting [19:25] What is? Slow pushing? [19:35] Hmm. "bzr send -o foo" == "bzr bundle >foo"? [19:36] * Peng has fun with locations.conf. [19:38] jelmer: have you looked at the signing features of bzr? [19:38] schierbeck: yes [19:39] i'm trying to implement a ui for it, but it seems i'm only able to get the raw signature text [19:39] it'd be nice with some helper methods... [19:40] like signature_is_valid() [19:40] are such helpers planned? [19:41] they are planned, but nobody has worked on them yet [19:41] hi coffeedude [19:41] I think there should be a spec or two up on launchpad [19:41] all hands was frenetic, I haven't fixed that bug yet sorry. [19:41] jelmer: darned! [19:41] schierbeck: Would love it if you worked on validation [19:42] lifeless: i've been looking at PyMe, which is mentioned on the bzr wiki, but it seems overly complicated [19:42] there may be better bindings now [19:42] I think jamesh wrote something [19:42] perhaps i should ask him, then [19:43] schierbeck, https://blueprints.edge.launchpad.net/bzr/+spec/bzr-gpg-keysigning [19:43] i can't seem to find any good bindings [19:43] :) [19:43] options [19:43] http://py-gnupg.sourceforge.net/ [19:44] http://www.amk.ca/python/code/gpg [19:44] I looked at one for pqm that was quite nice [19:44] can't remember the name though [19:47] i've looked at both solutions, but neither seem perfect [19:48] pyme [19:48] and obviously :) [19:49] lifeless: hey. Busy channels today. Didn't see you pop up. [19:51] http://www.amk.ca/files/python/GPG.txt seems promising [19:51] at least it's simple [19:52] i think i'll hook it up directly with the ui -- if it works well, i'll send in a patch to bzr [19:53] Is this error known, or is there something wedged in my python setup ? http://pastebin.com/m7f87cd35 [19:55] woei: That's definitely a bug, one way or another [19:57] are you sure revision 1 contains that particular file? [19:58] I've also had python core dump when using bzr gannotate, so I suspect it's not completely bzr's fault: http://pastebin.com/m6ceb218f [19:59] jelmer: when doing bzr -ci, it said 'added bar/baz\nCommitted revision 1.' So I'd reckon it should be there [20:00] the identity of the file has changed though [20:00] coffeedude: :) [20:00] I guess this is why the svn folks have "peg_revision" [20:00] woei: the file bar/baz in r1 is not the same file as bar/baz in r3 [20:01] bazaar tries to find revision 1 of the file bar/baz in r3 [20:01] jelmer: you mean you can't delete a file, add it (or another file with the same name) later and then get back at the contents of the first file ? [20:01] woei: you totally can [20:01] jelmer: thats an internal error, not NoSuchFile [20:02] lifeless: yes, I think the bug is that the error is unclear [20:02] lifeless: it shouldn't mention the file ids [20:02] jelmer: and look at the inventory [20:02] baz', parent_id='bar-20071121194931-1hkhbeykywwxmvhz-1', [20:02] bar', parent_id='TREE_ROOT' [20:02] bar/baz is there [20:02] jelmer: users won't see that error [20:02] this is something different [20:03] hmmok [20:03] jelmer: though I *may* be wrong [20:03] jelmer: we normally search out for all file ids in all the trees given [20:04] would the trackback in ~/.bzr.log be of any help ? [20:04] woei: looking still more closely; "baz-20071121195029-sf17yppaiamx4ul0-1" != 'baz-20071121194944-ypbqg5bh6okxs8fc-1' [20:05] woei: so jelmer's initial comment is probably the right answer; this is a genuine bug [20:05] woei: could you please file a bug [20:05] woei: that pastebin is enough [20:05] trackback: http://pastebin.com/m797641e5 [20:05] ok, I'll file a bug on launchpad [20:09] jelmer: okay, i've got a working implementation [20:09] http://bazaar.launchpad.net/~dasch/bzr-gtk/signatures [20:10] lifeless: would this be a start? [20:11] schierbeck: I think this is a start [20:11] schierbeck: but it would be nice if you could also show the key id [20:11] trust level, etc [20:11] i'm thinking that we could add a more comprehensive description below the first paragraph [20:12] jelmer: yeah, i'll look into it [20:12] I can now create a key with uid that matches your email address [20:13] and it will the revision has a signature [20:13] there are two key things to validating signatures [20:13] 1) is the signer the author [20:13] - you want a trust level from gpg that is high enough to assert this. baz has all the code to do this, written for gpgme. [20:14] 2) is the author authorised to push code to that branch [20:14] we already discussed a little bit of this on the bzr-gtk list [20:15] going for just (1) first would be the easiest thing to do, and all the required things for that are already present in bzr core [20:15] - this requires mapping identity to policy; doesn't really apply when checking revisions you are merging from etc, its mainly a policy thing for fetch, but it could be expanded etc [20:15] yes, agreed [20:15] (except for some utility functions for checking signatures, etc) [20:18] jelmer: this is by no means ready for the public -- i'm incrementally making it secure [20:19] jelmer, lifeless: could i get you guys to sign your future commits to bzr and bzr-gtk? [20:19] schierbeck, do you know 'bzr sign-my-commits' ? [20:20] jelmer, i do, but i would like other signatures, besides my own [20:20] and i'm too lazy to set up a test branch with 'fake' signatures [20:20] schierbeck, If you need an example, bzr-svn has most revisions signed [20:20] New bug: #164395 in bzr "Unclear error message instead of NoSuchFile" [Undecided,New] https://launchpad.net/bugs/164395 [20:20] i'd like to have some test data when making the ui [20:20] jelmer: great [20:22] schierbeck: most of mine should be signed already [20:22] I think I've signed most of my revisions for bzr-gtk [20:22] and all pqm's should be signed [20:22] but there's no way to push signatures atm afaik [20:27] lifeless: did you say that bzr already had support for some of these things? [20:27] hmm ? [20:27] schierbeck: no, baz - the previous incarnation of bazaar [20:28] shoot [20:28] can it be easily ported? [20:29] its in C [20:29] and it uses gpgme [20:29] but it might be useful for inspiration, or not. [20:32] lifeless: well, there is PyMe, although i haven't quite figured out how to use it for our purposes [20:32] the implementation i added seems to work pretty well -- we could customize it for bzr [20:33] that is, the one from http://www.amk.ca/files/python/GPG.txt [20:33] I'm not trying to tell you how to do it [20:33] I was just letting you know what prior art I know of [20:33] i don't mind inspiration at all :) [20:34] i haven't used gpg much, so some things are not obvious to me [20:38] is anyone able to do http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html [20:38] i tried the tutorial but ran into a few errors [20:40] komputes: could you pastebin them somewhere ? [20:40] will do [20:41] does any of you guys know how to deal with custom icons in the application? [20:41] i guess they need to be installed in a special place and stuff [20:43] *do [20:54] lifeless, http://pastebin.com/m15942a13 [20:55] what is the recommend way of setting up the bzr server? using the dedicated ot bzr over ssh? [20:55] bzr+ssh is the most secure [20:57] komputes: ah! [20:57] komputes: so, do you have an sftp account at gmail.com [20:57] ? [20:58] komputes: you need an sftp server running and an account on it, to push to sftp somewhere. [20:59] Jug: ssh works well for me. [21:00] its also the simplest. [21:03] lifeless, tutorial on that? [21:03] i dunno does gmail do sftop? [21:03] sftp [21:04] do i need an acct for ssh? [21:05] no, gmail does not do sftp :) [21:38] komputes: well you need a server to push to; if you don't have one already you can use a free hosting service like launchpad [22:27] morning poolie [22:27] hello [22:27] is it still the case that we don't have dapper debs? [22:28]