| lifeless | jelmer: ping | 00:28 |
|---|---|---|
| * fullermd grumps about the wiki. | 00:38 | |
| lifeless | fullermd: thank you | 01:25 |
| fullermd | For which? | 01:25 |
| lifeless | fasces | 01:26 |
| fullermd | Ah. Well, I've been threatening to write out those thoughts for weeks. | 01:26 |
| lifeless | I imagine we all have ideas about this, and its good to be able to read others | 01:26 |
| fullermd | And today, it was either do that, or have to actually do some real work :) | 01:26 |
| fullermd | I wanted to get it out 'cuz I believe we can rework it as sheer gain, without hampering current workflows in the slightest. Unadulterated wins FTW. | 01:30 |
| fullermd | (plus, this gives us the chance to be the "Friendly, Flexible, Fascist VCS" 8-) | 01:47 |
| lifeless | groan | 01:49 |
| fullermd | Thank you, I'll be here all week. Try the veal! | 01:50 |
| lampliter | good evening. Trying to set up the bzr eclipse plug-in on Windows 7. When I installed the Windows bzr package, it says something about tortoise bzr but I can't seem to find it in the Windows Explorer | 02:15 |
| lampliter | what should I be looking for? | 02:16 |
| lampliter | doh found it | 02:18 |
| lampliter | anyone around who knows about the eclipse bzr plug-in? | 04:55 |
| lifeless | a little | 04:58 |
| yek401 | I'm at a loss with regard to 'bzr join --reference foo' | 05:01 |
| yek401 | is there a preferred format I should use, 2a, rich-root, etc? | 05:02 |
| lifeless | its not a supported feature yet, sorry. | 05:03 |
| yek401 | so that's it? I was ready to switch our team from svn to bazaar, but we rely on svn:externals | 05:03 |
| yek401 | If there's no way to duplicate externals functionality right now, I guess we can't use bzr | 05:04 |
| yek401 | any idea when it should show up? | 05:05 |
| lifeless | You could use config-manager, which various folk have used. Its manages a similar thing to externals. | 05:08 |
| lifeless | https://launchpad.net/config-manager | 05:08 |
| lifeless | its not as tightly integrated as nested trees will be once they are ready. | 05:09 |
| lampliter | sorry, I fell asleep | 05:09 |
| lampliter | I'm having trouble figuring out how to drag files a launch pad into an eclipse project | 05:11 |
| yek401 | well, I have a multi-part project, where each designer is working on a relatively sperate piece, but there are several resources that are shared across the project.. we handled these in externals.. is there a better way to handle that in bzr? | 05:11 |
| lifeless | so my first question is, are they really separate? | 05:11 |
| lifeless | or were you using externals as a way to emulate DVCS, which bzr has built-in. | 05:11 |
| lifeless | lampliter: sorry, I don't think I know enough to help you on that. | 05:12 |
| lifeless | verterok: do you know enough to help lampliter ? | 05:12 |
| lifeless | lampliter: verterok is the bzr-eclipse author; may not be around at the moment though | 05:12 |
| lampliter | it's okay. It seems like the integrated eclipse bzr fantasy may be a bit on the fantasy side | 05:13 |
| lampliter | I'm having so much not fun trying to integrate eclipse, Python, and speech recognition | 05:14 |
| yek401 | yes, truely seperate.. the design is actually a collection of integrated circuits.. one of the externals is the collection of technology files.. then there are a few core libraries, and then each desiner builds his or her own IC from those resources.. | 05:14 |
| lampliter | I just keep slogging away and it's like climbing a mountain. The top seem so close but it's always much further away than you think | 05:14 |
| lampliter | I think I better go to bed. I'm falling asleep way earlier than usual (midnight versus 2 a.m.) | 05:15 |
| lifeless | yek401: so there are two ways that should work well. One is just to start with the tech circuits, and each designer builds on that; they have a separate branch thats just the tech circuits, and commit to that to change the circuits | 05:15 |
| lifeless | yek401: alternatively, a config (config-manager) would easily combine the different components. | 05:16 |
| yek401 | hrm, 1) where do I read about how to use config-manager | 05:17 |
| lifeless | http://launchpad.net/config-manager | 05:18 |
| lifeless | I'll be back in a while, house stuff to do | 05:19 |
| yek401 | I don't mean to suggest that I'm daft, but where within that site is there a howto or description of the interface. | 05:19 |
| yek401 | ok, thanks for the help | 05:19 |
| lifeless | yek401: oh hm | 05:19 |
| lifeless | http://bazaar.launchpad.net/%7Elifeless/config-manager/trunk/annotate/head%3A/README | 05:20 |
| lifeless | and | 05:20 |
| lifeless | http://bazaar.launchpad.net/%7Elifeless/config-manager/trunk/annotate/head%3A/sample-config.txt | 05:21 |
| yek401 | great! thanks | 05:21 |
| yek401 | (didn't occur to check within the repo for that) | 05:21 |
| * lifeless is gone now | 05:22 | |
| jelmer | lifeless: pong | 08:37 |
| lifeless | hey | 08:37 |
| lifeless | welcome back | 08:37 |
| jelmer | hi! | 08:37 |
| lifeless | -> #subunit :) | 08:37 |
| jelmer | you've been busy I see :-) | 08:37 |
| lifeless | a tad | 08:37 |
| lifeless | jml: btw, did you find the torchwood cover? | 08:49 |
| maxb | According to specs/import-dsc in the bzr-builddeb source tree, incremental import support is basically not done yet. Should I even be attempting to use bzr-builddeb for anything than an initial import at this point? | 15:32 |
| MTeck | What causes point versions? Like 105.1.1 | 15:59 |
| MTeck | OH! | 16:00 |
| MTeck | Wrong channel for my sudden epiphany - still confused | 16:00 |
| fullermd | MTeck: That designates a revision that was brought into the branch via a merge. | 16:16 |
| MTeck | oh | 16:18 |
| MTeck | fullermd: so will it ever go away and go back to an integer? | 16:18 |
| fullermd | Possibly, if it ever ends up in the lefthand ancestry line of a future head rev. | 16:22 |
| MTeck | fullermd: ? | 16:22 |
| MTeck | you lost me at lefthand | 16:23 |
| fullermd | It's the opposite of righthand :) | 16:23 |
| MTeck | you lost me at "lefthand ancestry" :P | 16:23 |
| fullermd | How deep do you want to grok it? It's hard to answer that question without understanding exactly how the numbering comes about. | 16:24 |
| MTeck | .... I'm really really tired | 16:24 |
| MTeck | so.. if you explain it - I'll try to understand and reread it again tomorrow | 16:24 |
| MTeck | I'm up for knowledge though :) | 16:25 |
| fullermd | Theoretically, every time the head rev of the branch moves, all the numbers could change. | 16:25 |
| fullermd | In practice, that happens some time between "almost always" and "never", depending on exactly how your workflow... flows. Or whatever it is workflows do. | 16:25 |
| fullermd | OK. So, in a purely linear system (like CVS or SVN), numbering is easy, since every rev "comes from" the one before. | 16:26 |
| fullermd | I make a commit, that's 1. You make one, that's 2. I make one, that's 3. Etc. | 16:26 |
| MTeck | you used cvs and easy together? :S | 16:26 |
| fullermd | Sure. It's easy like that head cheerleader in high school :p | 16:27 |
| fullermd | And about as sane and sanitary. But anyway. | 16:27 |
| MTeck | :P | 16:27 |
| LarstiQ | oi, CVS has dotted file revnos | 16:27 |
| MTeck | ya, like DRUPAL-6--1-0 | 16:27 |
| LarstiQ | MTeck: that's a tag | 16:27 |
| LarstiQ | like 1.1.1.1 | 16:28 |
| MTeck | oh | 16:28 |
| fullermd | In a nonlinear system (like most DVCS's, though there's nothing _stopping_ a central system from being so), that's no longer the case. | 16:28 |
| fullermd | LarstiQ: Pfft. It's still linear going forward. Don't confuse the case :p | 16:28 |
| LarstiQ | sorry, sorry | 16:28 |
| fullermd | If we're both working based on a branch at say rev 10, and we both make a commit, now we both have 11. | 16:28 |
| * LarstiQ detaches | 16:28 | |
| fullermd | But our 11's have nothing to do with each other. | 16:29 |
| MTeck | fullermd: both users pull same branch you mean? | 16:29 |
| fullermd | So far no problem though, since if you're looking at my branch, we don't see, care, or even know about your 11 (and vice versa) | 16:29 |
| MTeck | or different branches entirely | 16:29 |
| fullermd | But when we try and merge the branches together, what can we do? We can't have TWO rev 11's. | 16:30 |
| fullermd | And it doesn't make sense (in bzr's opinion; hg does sorta this) to call one 12, since that implies that it's based on 11 (which it's not; neither of our revs is based on the others', they're both based on 11) | 16:30 |
| fullermd | So, we could have NO 12 at all, and call both something-implying-descent-from-11, and then have a 13 later. | 16:31 |
| fullermd | And various other even more confusing options. But they're confusing. | 16:31 |
| fullermd | So, if I merge your branch, your 11 is named something "off to the side". And that fits how I'll think of it; I didn't make it, I brought it in from somewhere else. | 16:32 |
| fullermd | Of course, the numbering doesn't actually come from that sort of question inside bzr; that's just how it appears. | 16:32 |
| fullermd | What actually happens is, revs don't inherently have numbers; if you run 'log --show-ids', you'll see the revision id's, which are long opaque strings. | 16:33 |
| fullermd | Those are associated with the rev forever; wherever you are, that string means that rev. | 16:33 |
| fullermd | Numbers are local to a given branch; a given rev can have many different numbers, depending on the structure of the branch its in. | 16:34 |
| fullermd | The way those are assigned depends on the shape of the ancestry of that branch, which always works backward from the head rev. | 16:34 |
| fullermd | A branch works by saying "THAT rev right there is my head", and that rev's parents, and its parents' parents, and their parents, and so on back to null, are part of the branch. | 16:35 |
| fullermd | If every rev had a single parent (like in the linear case above), that would be easy; you figure how many there are, and number backward from that. | 16:35 |
| fullermd | But when you merge, you create a rev with 2 parents; your last revision, and the [head] revision you merged in. | 16:36 |
| fullermd | (Technically, you can have any number of parents, because you could do multiple merges at once, but you practically never do, it's a bit more confusing, and it doesn't change the essentials of this analysis anyway) | 16:36 |
| MTeck | so far this is really really easy to follow | 16:37 |
| fullermd | In theory, merges are symmetric ("merge these two things together"), but socially and mentally we generally consider them asymmetric ("merge that into this") | 16:37 |
| stbuehler | bzr: ERROR: subvertpy.SubversionException: ('Svndiff contains a too-large window', 185001) | 16:38 |
| fullermd | So you don't, in mental modelling, "merge two branches together", you "merge that branch into this branch"; often in the sense of "merge Joe's branch into my branch". | 16:38 |
| stbuehler | can someone please tell me what that is...? | 16:38 |
| fullermd | stbuehler: You probably want to ask jelmer when he shows up; that's his pigeon. Or mail the list. | 16:39 |
| fullermd | MTeck: Now, merging has to create a new rev, since you're making a new state. And that rev has two parents; your branch's previous head, and the rev you merged. | 16:40 |
| fullermd | (in merging someone else's branch, you probably actually merge many revs, but you do that by merging its head, and thus implicitly pulling the ancestors of that head you don't already have. So you only have that previous head as a parent; the rest show up in the ancestry just like your previous history does, transitively through that head) | 16:40 |
| fullermd | So now, if we try and look back from the head to number, we have a branching; there are two paths backward from that. So which way do we follow to number? | 16:41 |
| MTeck | down | 16:42 |
| fullermd | We could pick one way at random, but that would be stupid. We can try and create some sort of linear projection, but then we end up with the problems described above; you end up with a '12' that isn't based on '11', etc. | 16:42 |
| fullermd | What bzr does is preserve and exploit the asymmetry described above. | 16:43 |
| fullermd | We preserve an ordering of the parents of a rev; the 'first' or 'left' (depending on how you look at things) parent of the merge rev you created is YOUR previous state, and the 2nd (and 3rd, 4th, if necessary) or right-side parents are those you merged. | 16:43 |
| fullermd | So at every branching in the history (we're looking backward remember, so in this sense that means "every rev with more than one parent"), we take the left-hand or first-parent path, when figuring stuff for numbering. | 16:44 |
| fullermd | And so the number of steps on THAT path, ignoring the right-side path, determines how many number we have. And the revs on that path are the ones that get the numbers. | 16:45 |
| fullermd | The upshot of that scheme is that the revs that get numbers, and are considered a branch's "main line" in bzr terms, are those that were "made on this branch"; e.g., those you made by 'commit', rather than those you acquired from elsewhere via 'merge'. | 16:46 |
| fullermd | (that definition is necessarily fuzzily and somewhat incomplete (and in some ways flat wrong), but it gives sort of a flavor of what's happening) | 16:46 |
| fullermd | Internally of course, all revs are equal, but UI-wise, it can be valuable to consider that sort of dichotomy for various reasons. So bzr chooses to present based on that. | 16:47 |
| fullermd | Now, we've used the monotonically-increasing integers for those revs on the left-hand path. What can we do for numbering those remaining revs? | 16:48 |
| fullermd | Well, we could just not number them, and use the revid string if we need to refer to them. | 16:48 |
| fullermd | We used to just do that (pre-0.13 I think?). Little ugly though; revids are long. | 16:48 |
| fullermd | Or we could give them numbers that aren't integers. That's where dotted revnos come from. | 16:49 |
| fullermd | At the moment, those numbers are generated by basing them from the 'mainline', integer revision they descend from. | 16:49 |
| fullermd | So if we have a branch with 10 revs, we both branch from it and create an 11, then I merge you. | 16:50 |
| fullermd | My history looks like: | 16:50 |
| fullermd | 1..10: The original 10 revs. | 16:50 |
| fullermd | 11: My 11. | 16:50 |
| fullermd | 12: Merge of your branch. | 16:50 |
| fullermd | 10.1.1: Your 11. | 16:50 |
| fullermd | If, at the same time I do that (before my 12 exists), you merge my branch, you end up with a similar numbering. | 16:50 |
| fullermd | Except your 11 is still 11, and my 11 is 10.1.1 in your branch. | 16:50 |
| fullermd | (it's not necessarily the _only_ way to assign those dotted numbers, but it's how we currently do it. Remember these aren't _stored_ or part of the rev, they're just derived on the fly, so we could change it easily) | 16:51 |
| fullermd | So, now we both have branches with 13 revs in the history (though on both cases, only 12 are on the mainline; the 13th is off to the side and gets a dotted revno) | 16:52 |
| fullermd | 12 of those 13 are common; it's only that last, number 12, that's different. | 16:52 |
| fullermd | And our rev 12's, while different revs, are probably much the same; we probably didn't have merge conflicts. So the files all look the same. | 16:52 |
| fullermd | Looking at the files, I probably couldn't tell whether I was in my branch or yours. | 16:53 |
| fullermd | So socially (not technically necessarily), we could choose to use my 12 or your 12 going forward with equal ease. But depending on which it was, a different rev would get the dotted number. | 16:53 |
| fullermd | Now, let's suppose you make a new 13 rev, and then a 14 merging my branch (which makes no file changes, but brings the history graphs together) | 16:54 |
| fullermd | My 12 (my version of the merge) ends up with a dotted number (10.1.2 I think, in the current scheme). | 16:55 |
| fullermd | (after all, it's "off to the side" in your perspective there) | 16:55 |
| fullermd | Now, I want to sync up with you. I could merge again, and I'd end up with a '13', and your 12, 13, and 14 'off to the side' with dotted numbers. | 16:55 |
| fullermd | But, since your history graph is a strict superset of mine, I could 'pull' instead, which basically turns my graph into a copy of yours. | 16:55 |
| fullermd | So now my head is your 14. | 16:56 |
| fullermd | The result, then, is since we have the same heads, we have all the same numbers. | 16:56 |
| fullermd | And my 11, which previously had an integer revno, now has a dotted. | 16:56 |
| fullermd | Your 11, which previous had a dotted (10.1.1), is now on my mainline, so it's no longer dotted. | 16:56 |
| fullermd | My head rev changed in a way that was strictly forward (it includes my previous head in its ancestry, and thus everything prior to that too), but the new head implies a different 'mainline' through its left path, so [some of] the revs get renumbered. | 16:57 |
| fullermd | If I move my head forward solely by 'commit', that will never happen; that's the commonish case in the bzr world, socially. | 16:58 |
| fullermd | MTeck: Put you to sleep yet? :p | 16:58 |
| MTeck | I've been enjoying it - but I am also tired :P | 16:58 |
| MTeck | I've been up for ~30hr actually | 16:59 |
| fullermd | Oh how I wish I could say I wasn't on a first-name basis with that state of being... | 16:59 |
| MTeck | I've understood every bit of this though | 16:59 |
| fullermd | So, you have the tools now to answer your question; if your branch's head rev moves in such a way that the left-hand path through the ancestry changes, revnos (integer and dotted) can change. | 17:00 |
| fullermd | In rough colloquial terms, that happens when your head moved to a rev somebody 'commit'd elsewhere, rather than one you 'commit' locally. | 17:01 |
| fullermd | Via you 'pull'ing some other branch, or another branch 'push'ing onto you. | 17:01 |
| fullermd | Merge will never do it (since merge doesn't create a new head, just changes in your working tree waiting for you to commit them) | 17:01 |
| MTeck | makes sense :) | 17:02 |
| fullermd | Commit will never do it, since the first/left parent of the new rev you commit is your previous head, so all that ancestry is unmoved. | 17:02 |
| fullermd | And while there are probably other ways to move your head than the above, that's pretty much it through the UI leaving extraordinary circumstances out. | 17:02 |
| fullermd | Of course, it's possible that that 'outside' head could _not_ change the numbering, if it doesn't change the left path. | 17:03 |
| fullermd | e.g., I have 10 revs, you branch from that and create an 11, and (without making any local changes), I 'pull' you. | 17:03 |
| fullermd | I have a new rev tacked on the end now, but everything that was previously on the mainline still is, so existing numbers weren't changed. | 17:03 |
| fullermd | There's a branch.conf setting you can make that will refuse changes that would change the left path. | 17:04 |
| fullermd | append_revisions_only, I think. | 17:04 |
| fullermd | You can set that on a branch, and then you can commit and pull into and push-onto all you want, but it will error out if the action would change the left path. | 17:05 |
| fullermd | That can be useful on branches like 'trunk', where you want the numbering (and the view of history) to remain stable. | 17:05 |
| fullermd | But again of course, this is all social; technically all that matters is questions like "is rev X in my ancestry". | 17:06 |
| fullermd | Other systems, like git or mtn, don't assign any meaning to left vs right or first vs later parents. | 17:07 |
| fullermd | And they don't have revnos, either. The two kinda tie together; revnos would be less useful if they changed all the time. | 17:07 |
| fullermd | [other theoretical discussions elided in favor of sleep] | 17:07 |
| MTeck | :P | 17:09 |
| MTeck | This was fun - but I think I agree | 17:09 |
| MTeck | thank's professor :) | 17:10 |
| fullermd | I'll give you a day or so to recover before the test ;p | 17:10 |
| MTeck | test :( | 17:10 |
| * MTeck turns white | 17:10 | |
| MTeck | in all honesty - I think I could do ok on the test (after the sleep recovery) | 17:10 |
| MTeck | heh - 1hr drive in front of me, then 1hr moving in, then sleep for ~4hr and then my gf will probably be around | 17:11 |
| MTeck | ya, it's time to take off - I need food somewhere too | 17:12 |
| MTeck | fullermd: thanks again | 17:12 |
| fullermd | MTeck: NP. Hope it helped :) | 17:13 |
| MTeck | helped a lot actually | 17:13 |
| MTeck | I'll catch you all later :) | 17:13 |
| kwk | Hi! When I install Bazaar on any of my windows machines (XP and Windows 7), the "new folder" function from the menu bar is broken in explorer. the "right click"->new->folder still works. Is this a known issue? | 17:41 |
| kwk | I searched the questions on launchpad for "new folder" but there's only one irrelevant answer | 17:43 |
| kwk | Ah, here's a solution, I guess: http://www.sevenforums.com/general-discussion/20656-new-folder-button-explorer-toolbar.html | 17:43 |
| kwk | It seems to be a problem of the installer, not the binaries. | 17:45 |
| kwk | anyways thanks for such an awesome tool | 17:52 |
| mtaylor | how do I prevent push from trying to stack? | 18:55 |
| _steven_ | does anyone know of a way to have bzr automatically add commit messages to a changelog upon commit? | 19:45 |
| verterok | _steven_: I'm not aware of a plugin that do that, but you can easily doit with post commit hook: e.g: http://stackoverflow.com/questions/43099/how-can-i-get-a-commit-message-from-a-bzr-post-commit-hook | 19:54 |
| _steven_ | if it's post commit, will that commit the newly updated changelog to the bzr branch? | 19:56 |
| _steven_ | or does that just update local files? | 19:56 |
| verterok | _steven_: as it's post commit, another commit is needed, but you can use a pre commit hook | 19:57 |
| verterok | _steven_: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks | 19:58 |
| _steven_ | verterok: thanks | 19:59 |
| verterok | _steven_: np | 19:59 |
| _steven_ | I'm surprised no one else has done this before and released a plugin | 20:01 |
| _steven_ | If I can get it to work properly, I may create a plugin | 20:02 |
| verterok | _steven_: there is a gnu changelog plugin, but don't work ^ that way | 20:02 |
| verterok | _steven_: if pre commit isn't enough to get this working, take a look to the extend_command hook ;) | 20:03 |
| _steven_ | I tried the gnu changelog plugin, it didn't seem to format things properly | 20:03 |
| _steven_ | or it's possible I just don't like gnu's changelog format :) | 20:04 |
| verterok | _steven_: I have a pre-commit lint plugin (it's hack, not a "plugin"), but you can get an idea of the use of extend_command hook | 20:05 |
| * verterok looks for the branch url | 20:05 | |
| verterok | _steven_: lp:~verterok/+junk/pre-commit-lint | 20:06 |
| _steven_ | verterok: thanks, I'll take a look | 20:06 |
| phinze | anyone here using bzr over a netcat bounce to get around firewalls? | 20:15 |
| phinze | i used to have it working great but on the latest version i'm getting trouble | 20:15 |
| phinze | i guess a related easier question would be: how do i get bzr to spit out as much ssh exchange data as it has? | 20:18 |
| phinze | ah nm looks like i have to debug the netcat bounce first; tried it manually and it's not working | 20:27 |
| lifeless | moin | 20:40 |
| === JaredWigmore is now known as JaredW | ||
| maxb | I've got a lot of directories corresponding to versions of a project that had no version control before - what's the best way to import them all into a branch? | 22:19 |
| lifeless | bzr import | 22:19 |
| lifeless | + for x in y | 22:20 |
| lifeless | maxb: is this the lp dependencies thing? | 22:20 |
| maxb | yes | 22:20 |
| lifeless | I just had a look for a branch of it, no sign | 22:33 |
| lifeless | sorrt | 22:33 |
| Blizzz | is it save to edit and copy files while `bzr commit` is running? | 22:34 |
| lifeless | if you're on windows, doing so can cause errors because of platform limits. On linux it should be ok as long as you don't move the tree around: but it is possible that commit will end up reading only part of the file if you save it at the wrong time. | 22:35 |
| lifeless | if your editor uses atomic replacements for files it should be totally safe. (Most editors don't). | 22:36 |
| Blizzz | lifeless: yes, linux here. is it depending on a specific stage, too? | 22:37 |
| lifeless | Blizzz: commit should only be a second or two long | 22:39 |
| Blizzz | lifeless: it usually is, but sometimes it takes up to some minutes | 22:39 |
| lifeless | are you committing to a local or remote branch? | 22:40 |
| Blizzz | perhaps i use it not properly? | 22:40 |
| Blizzz | bzr copies it to the remote server directly | 22:40 |
| lifeless | anyhowok | 22:40 |
| lifeless | ok | 22:40 |
| lifeless | when its copying it to the server its safe to edit locally | 22:40 |
| lifeless | what protocol are you connecting to the server with? | 22:41 |
| Blizzz | sftp | 22:41 |
| lifeless | that will be why it takes minutes every 10 commits | 22:41 |
| lifeless | it has to do database maintenance over the network | 22:41 |
| lifeless | if you can use bzr+ssh, it will be much faster | 22:41 |
| Blizzz | ok, i'll have a look :) | 22:41 |
| Blizzz | thank you so far | 22:42 |
| danbhfive1 | I can't seem to branch a launchpad project. I had forgotten the password to my ssh, so I wiped ~/.ssh and regenerated a key, added to launchpad. But, bzr branch lp:project sill gives me a permission denied error. | 22:49 |
| lifeless | danbhfive1: are you using the right username with launchpad ? | 22:50 |
| danbhfive1 | lifeless: I don't know, how do I check? | 22:50 |
| lifeless | whats your launchpad username | 22:50 |
| danbhfive1 | lifeless: danielhollocher | 22:51 |
| lifeless | if you do 'ssh danielhollocher@bazaar.launchpad.net echo' | 22:51 |
| lifeless | what happens | 22:51 |
| danbhfive1 | same error | 22:51 |
| lifeless | and the error is? | 22:52 |
| danbhfive1 | Agent admitted failure to sign using the key. \n Permission denied (publickey). | 22:52 |
| lifeless | hmm | 22:52 |
| lifeless | have you added the new key to your ssh agent, whatever one you are using? | 22:52 |
| danbhfive1 | I've been changing the keys a few times, since I forgot my password. Maybe I have to reboot? | 22:52 |
| lifeless | perhaps | 22:53 |
| danbhfive1 | ok, well, let me try that, even though it seems strange... | 22:54 |
| danbhfive | lifeless: thanks for your help. Turns out the reboot worked. I suppose maybe ssh needed restarting? I don't know, but thanks | 23:01 |
| lifeless | danbhfive: your ssh agent needed to know about the new key | 23:01 |
| lifeless | ssh-add, for instance in a command line agent | 23:01 |
| danbhfive | ah, cool | 23:02 |
| lifeless | fooding | 23:09 |
| lifeless | http://pqm.bazaar-vcs.org/ in progress | 23:10 |
| bob2 | spiffy | 23:53 |
| lifeless | bob2: wait till you see rev 200 of pqm deployed | 23:54 |
| lifeless | *thats* spiffy | 23:54 |
| igc | morning | 23:56 |
| lifeless | hi | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!