| vila | mathrick: file a bug and find jelmer ;) There is probably a text file you can edit somewhere which contains the windos path. | 00:02 |
|---|---|---|
| jelmer | mathrick: is this with the core bzr support for colocated branches, or with bzr-colo ? | 00:03 |
| mathrick | jelmer: I dunno, 2.5.1, created via bzr-explorer with "colocated workspace" option | 00:03 |
| jelmer | mathrick: ah, that's the bzr-colo plugin | 00:04 |
| jelmer | mathrick: please file a bug, but against the bzr-colo project on Launchpad | 00:04 |
| mathrick | is that really a bug in bzr-colo? | 00:05 |
| vila | jelmer: well dodged ;) | 00:05 |
| vila | mathrick: more or less | 00:05 |
| jelmer | vila: :-) | 00:05 |
| mathrick | OK, how should I describe it? Since I have no clue how that is a problem with bzr-colo and not bzr reconfigure for instance | 00:06 |
| vila | mathrick: zip is not a transport supported by bzr ;) So you run into some absolute paths that may be better handled as relative (but obviously are not (yet ?)) | 00:06 |
| vila | mathrick: what you explained here is good enough: zipped on windos, unpacked on linux | 00:07 |
| vila | mathrick: it may be interesting to see if the reverse breaks in the same way (zipped on linux, unzipped on windoz) | 00:08 |
| vila | dows | 00:08 |
| vila | damn tyops | 00:08 |
| mathrick | vila: I understand that, what I don't understand is how bzr-colo breaks things. Bzr reconfigure should be able to change that path | 00:09 |
| vila | mathrick: well, the point is that bzr-colo doesn't really break things, it assumes the working trees/branches/repos would stay on the same files system (roughly) | 00:10 |
| jelmer | mathrick: bzr-colo stores an absolute path to the colocated branch, rather than a relative one; bzr reconfigure tries to open the old branch when it reconfigures I think | 00:11 |
| mathrick | that is a problem with reconfigure then, no? | 00:11 |
| vila | mathrick: I suspect that there should be some way to bzr-colo push instead of zip/unzip that should work | 00:11 |
| mathrick | yes, there is | 00:11 |
| mathrick | I just didn't remember I made it collocated when I zipped | 00:12 |
| jelmer | mathrick: bzr-colo should be storing a relative path | 00:12 |
| vila | mathrick: bzr reconfigure assumes it starts with a "correct" context, it may be worth filing a different bug for that | 00:12 |
| jelmer | mathrick: you might be able to use --force to get reconfigure to ignore the old code | 00:12 |
| mathrick | ah, I didn't notice --force wasa thing | 00:13 |
| vila | jelmer: good point (dunno if this will work but it should ;) | 00:13 |
| mathrick | nope, --force only seems to influence potentially losing local changes | 00:14 |
| vila | but in this specific case, if the branch is required, it's hard to ignore it | 00:14 |
| vila | mathrick: you tried or you just read the --help ? | 00:14 |
| mathrick | tried | 00:15 |
| vila | thanks | 00:15 |
| vila | mathrick: did you try to grep for that path under .bzr ? | 00:15 |
| mathrick | no, but I expected to be able to change it by hand | 00:16 |
| mathrick | I was asking for the proper way | 00:16 |
| vila | mathrick: for this case, I doubt there is one (or that would be bzr-colo push) | 00:17 |
| fullermd | Pfft, proper. What fun is that? | 00:18 |
| vila | mathrick: but really, as jelmer said, bzr-colo should use a relative path (that may not be enough but should help anyway) | 00:18 |
| mathrick | vila: bzr-colo push is "how do I transport it properly?". But I didn't, and now my question is "how do I fix it?". Bzr reconfigure *should* be able to fix that, and I will file a bug too | 00:18 |
| vila | mathrick: worth a try, but if there is a single place where the branch path is defined and it's broken, bzr reconfigure can't guess the right one | 00:19 |
| mathrick | why not? bzr info tells me what the checkout thinks the source branch is. That is what bzr reconfigure is supposed to change; if it tries to open it before changing, it's kinda useless for fixing things | 00:20 |
| vila | mathrick: it can avoid opening it (it's broken after all) but what will it use instead of that broken path ? | 00:21 |
| mathrick | the one I give it in --bind-to? | 00:21 |
| vila | mathrick: oh, well done ! | 00:22 |
| vila | for this specific case indeed, not sure if the code will make it easy to implement but file-a-bug++ | 00:22 |
| mathrick | done, bug #1076809 and bug #1076810 | 00:24 |
| ubot5 | Launchpad bug 1076809 in bzr-colo "Copying collocated branches Windows and Linux broken by absolute paths" [Undecided,New] https://launchpad.net/bugs/1076809 | 00:24 |
| ubot5 | Launchpad bug 1076810 in Bazaar "bzr reconfigure can't fix dangling paths" [Undecided,New] https://launchpad.net/bugs/1076810 | 00:24 |
| vila | mathrick: thanks | 00:25 |
| mathrick | sure | 00:25 |
| vila | fullermd: linked a branch with reproducing failing tests for bug #1072513, one step closer to diagnosis ;-p | 00:55 |
| ubot5 | Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513 | 00:55 |
| vila | fullermd: you may want to look at the intermediate commits to see how I get there from your script (including revno 6515 where 'bzr test-script ./bzrlib/tests/blackbox/log_bug_1072513.sh --null-output' was passing) | 00:57 |
| vila | fullermd: the missing feature still being to be able to keep the built env to toy around manually with the results :-/ | 00:58 |
| vila | but at least the syntax should be copy/pastable enough for you to tweak | 00:59 |
| mgrandi | is there a preferred way to backup a repository to a file, or is just zipping the directory pretty much | 01:00 |
| vila | mgrandi: <cough> ask mathrick ;) | 01:00 |
| * mgrandi asks mathrick | 01:01 | |
| vila | mgrandi: if you really want a *backup* 'bzr push' should be the fastest | 01:01 |
| mgrandi | im just sending my code to someone, including the repo for archival purposes | 01:02 |
| vila | mgrandi: sorry, that a was a joke, mathrick just ran into an issue while zipping on windows and unzipping on linux (special setup where an absolute path has been recorded) | 01:02 |
| mgrandi | interesting o.o | 01:02 |
| vila | mgrandi: same os on the receiving side ? | 01:02 |
| mgrandi | stack overflow says this; http://stackoverflow.com/questions/1976857/bzr-create-tgz-file-containing-full-repository | 01:03 |
| mgrandi | might not be | 01:03 |
| vila | bzr send is safest | 01:03 |
| mgrandi | what does bzr send actually do? generate patch files? | 01:03 |
| mgrandi | so this just creates a series of patch files or something? | 01:04 |
| vila | mgrandi: almost, they are called merge directives and contains both the revisions and a human-readable patch | 01:04 |
| vila | mgrandi: it's not lossless as patches can, you get the real revisions | 01:04 |
| mgrandi | interesting, thanks | 01:05 |
| vila | mgrandi: the idea is that send accept a public url readable by both sides and create the delta between your branch and the public branch | 01:05 |
| vila | mgrandi: so it can be *far* smaller than zipping the whole repo (like the stackoverflow recipe suggests) | 01:06 |
| mgrandi | yeah, this isn't a problem here but i was just curious | 01:06 |
| vila | mgrandi: the recipe basically uses an empty branch as a starting point | 01:07 |
| mgrandi | so are there problems with zipping a bzr branch directory and then using it on a different os? | 01:07 |
| vila | mgrandi: not a bzr branch, a bzr-colo environment (plugin) | 01:07 |
| mgrandi | isn't that integrated into bzr now? | 01:08 |
| vila | there is wip about native colocated branches yes, that's different | 01:08 |
| mgrandi | but normal branches should be fine? besides the whole symlinks thing | 01:09 |
| mgrandi | that i still need to work on... | 01:09 |
| vila | yes | 01:09 |
| vila | but it's been a looong time since I did that myself, most of the machines I'm working on have ssh and bzr so it's easier to kust push ;) | 01:10 |
| vila | *just | 01:10 |
| fullermd | Obviously, the solution is that somebody needs to donate vila a machine without ssh or bzr on it, to force him to work on it :p | 01:11 |
| vila | fullermd: the last case was a windows vm where I managed to install ssh as a service anyway ;) | 01:12 |
| fullermd | I've probably got some OS/2 install media somewhere... | 01:12 |
| vila | fullermd: and if they don't have ssh but bzr, well, it's easy enough to pull instead of pushing ;-) | 01:12 |
| fullermd | vila: So, wait, you already fixed it, then re-broke it? I mean, if the test was passing, that means everything's good, right? :p | 01:14 |
| vila | hehe, that's where the test scripts shine: they can express failure more easily ;) | 01:17 |
| fullermd | 'druther they expressed success ;p | 01:19 |
| vila | tsk, tsk, they allow success to be *demonstrated*, that's TDD for you ;) | 01:21 |
| fullermd | I dunno, TDD sounds like something I'd discuss with my doctor in a hushed voice. | 01:22 |
| mgrandi | depends on who you ask. they really beat it into us at my school | 01:24 |
| mgrandi | =P | 01:24 |
| fullermd | Well, yes, I remember that from high school too, but... | 01:25 |
| mgrandi | unit test ALL THE THINGS | 01:25 |
| vila | Alzheimer, Pratchett and I.. what was it I wanted to say... | 01:26 |
| mgrandi | so vila, i just tried that recipe out, and it seems useless cause you can't merge the file back into an empty repo =/ | 01:26 |
| vila | ha yes, tests are good substitute for failing memory | 01:26 |
| jelmer | mgrandi: you can pull it into an empty repo though | 01:26 |
| * jelmer wonders if vila is in the US | 01:27 | |
| fullermd | I do wish I had regression tests for stuff at work. Sadly, I've never heard a good story for writing something useful considering the depth of stuff that breaks. | 01:27 |
| vila | jelmer: hehe, no ;) | 01:27 |
| jelmer | ... or just up late :-) | 01:27 |
| mgrandi | then the documentation for send is slightly out of date | 01:27 |
| vila | jelmer: yeah :-} Bad vila, go to sleep | 01:27 |
| mgrandi | `bzr send` creates a compact data set that, when applied using bzr merge, has the same effect as merging from the source branch. | 01:27 |
| fullermd | No, but using it to replicate whole histories is out of the scope of the docs. | 01:27 |
| mgrandi | well it should still be mentioned that pull can be used as well | 01:27 |
| fullermd | And it does; merging the source branch into a branch with no history will also fail ;p | 01:28 |
| mgrandi | 'using bzr merge or pull, has the same effect etc | 01:28 |
| vila | mgrandi: that's supposed to work, there may be a bug for *empty* branches (worth filing too, I thought we nailed down all the empty-branch-are-special ones...) | 01:29 |
| mgrandi | well it specifically gave a bug url when i tried to do it | 01:29 |
| vila | which one ? | 01:30 |
| mgrandi | bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562 | 01:30 |
| ubot5 | Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed] | 01:30 |
| mgrandi | dang 5 years, old bug | 01:31 |
| vila | helllo, someone remember the shortest workaround for that ? | 01:32 |
| vila | 'bzr init . ; bzr pull <merge-directive>' ? | 01:32 |
| mgrandi | well yeah thats what i did | 01:33 |
| vila | good, my job here is done ;) | 01:33 |
| mgrandi | is that merge into empty repo a particuarly hard bug? | 01:35 |
| fullermd | I've never been quite clear as to what it's even supposed to _mean_. | 01:36 |
| mgrandi | probably along the lines like, its trying to merge two histories but one doesn't exist so it breaks? | 01:36 |
| fullermd | Yeah, the whole point of merge is "take these two separate things and bring them together", so how's it even meaningful to talk about when there's only one thing? | 01:38 |
| vila | I think the issue is about root-ids (branches of the same project shares a unique id for their root) | 01:38 |
| mgrandi | well, it still seems to me that bzr should be smart about that, and if one history just doesn't exist, then just take the other one | 01:38 |
| vila | the first branch of a project gets a new root-id which is then duplicated | 01:38 |
| vila | mgrandi: devil is in the details | 01:39 |
| mgrandi | i imagine | 01:39 |
| vila | the fact that it's a corner case rarely encountered didn't help raise the bug importance | 01:39 |
| vila | most of the issues are probably already solved, time is lacking for that one | 01:40 |
| fullermd | Well, taking the other one is "pull" ;p | 01:41 |
| fullermd | If I wanted "merge" to sometimes silently do a "pull" instead, I'd use git... | 01:41 |
| mgrandi | haha. | 01:41 |
| mgrandi | maybe the error message should be updated to say 'try pull instead?" | 01:42 |
| gmarkall | i'm having trouble rebasing a branch. I'd like to rebase the last five revisions onto another branch, but i can't seem to work out how to tell bzr that's what i want to do - i only seem to be able to rebase "all but the last 5" with -r last:5. Is there a way to do this please? | 07:36 |
| bob2 | you mean you're using bzr-rewrite? | 07:37 |
| gmarkall | (if I don't specify a revision then bzr wants to rebase 54 revisions, which includes a lot of duplicate changes) | 07:37 |
| gmarkall | bob2: i think i am | 07:37 |
| gmarkall | bzr help rebase says "From: plugin "rewrite"" | 07:37 |
| lifeless | gmarkall: you might try -r -5:.. | 07:41 |
| gmarkall | lifeless: that gives me "Bzr has encountered an internal error..." - shall I submit a bug report? | 07:43 |
| lifeless | sure | 07:43 |
| fullermd | Without the colon, probably... | 07:43 |
| lifeless | oh heh, yes. | 07:43 |
| lifeless | EOUTOFPRACTICE | 07:43 |
| lifeless | gmarkall: -r -5.. | 07:43 |
| gmarkall | ah, that didn't crash bzr! :-) | 07:44 |
| === dpb_ is now known as Guest76575 | ||
| gmarkall | I managaed to get the crash down to a small example: https://bugs.launchpad.net/bzr/+bug/1076894 | 08:08 |
| ubot5 | Ubuntu bug 1076894 in Bazaar "Invalid arguments to rebase cause internal error" [Undecided,New] | 08:08 |
| gmarkall | I managed to choose the correct revisions with the syntax suggested by lifeless/fullermd - however, when i run with --dry-run, the commit ids that it shows are printed out-of-order - is that to be expected? | 08:10 |
| gmarkall | when i actually did the rebase, the commits were applied in the correct order | 08:16 |
| mgz | morning! | 09:03 |
| tbf__ | can i tell bzr to just commit the changes of a conflict free merge? | 09:06 |
| tbf__ | constantly forgetting that commit and then messing up stuff | 09:06 |
| tbf__ | (well, also lack the creativity to invent merge commit messages) | 09:07 |
| tbf__ | ok. why would "bzr diff ../parent" show changes that a plain "diff -ru ../parent" doesn't see? | 09:17 |
| === tbf__ is now known as tbf | ||
| tbf | apparently i still fundamentally fail in understanding things | 09:18 |
| mgz | tbf: could be lots of reasons for the diff not being the same, fundamentally those two commands look at different stuff | 09:27 |
| mgz | so, for instance, if the working tree of ../parent is not up to date, plain recursive diff will not see the later revisions | 09:28 |
| tbf | mgz, ../parent is up-to-date | 09:32 |
| tbf | mgz, at least the output of "bzr status" and "bzr diff" in ../parent is empty | 09:33 |
| tbf | mgz, seems i seriously fail to understand even the basics of bzr: http://nopaste.me/paste/111230873509cce1382789 | 09:35 |
| tbf | mgz, how can it be, that rev 334 contains changes from 316.1.64, while rev 333 is entirely empty? | 09:36 |
| tbf | 316.1.64 is the last commit in that merge | 09:37 |
| tbf | i'd only expect to see that change in 334 if i'd reverted 316.1.64 by accident while commiting 333 | 09:38 |
| mgz | ...that paste site is borked, gives 406 + error fallout based on UA string | 09:47 |
| mgz | tbf: from that log, I'm not sure what's suprising you | 09:48 |
| tbf | mgz, the output of "bzr diff -c 334 debian/control" entirely surprises me | 09:49 |
| mgz | the diff for -r331..332 is empty, but the log above stops at 332 so that might be right, and 316.1.64 was merged in 333 | 09:49 |
| mgz | tbf: that command isn't in the paste | 09:50 |
| tbf | mgz, line 51 | 09:50 |
| tbf | mgz, rev 333 already should have that change, but bzr shows it was applied again in 334 | 09:51 |
| mgz | I suspect you have some funny history | 09:51 |
| mgz | you remerged the same branch in 334? | 09:52 |
| tbf | mgz: forgot to commit a merge, shelved the mess. merged from parent again, unshelved. | 09:53 |
| tbf | expecting that only the really new changes would get applied | 09:53 |
| tbf | now bzr even crashes when accessing that branch | 09:54 |
| tbf | great. | 09:54 |
| mgz | okay, so the history and log/diff output is probably correct | 09:54 |
| tbf | apparently "bzr switch -r 333" was a stupid idea | 09:54 |
| tbf | mgz, how that? | 09:55 |
| mgz | r333 includes the merge, and the history of the other branch, but none of the actual changes | 09:55 |
| mgz | which you shelved, then committed in 334 | 09:55 |
| mgz | so, log tells you 333 merged stuff, but diff only sees the changes when you actually committed them in 334 | 09:56 |
| mgz | the best thing to get out of trouble here is just make a new branch from 332 and do the merge right this time | 09:56 |
| tbf | mgz: "r333 includes the merge, and the history of the other branch, but none of the actual changes" - this makes absolutely no sense to me. | 09:57 |
| tbf | maybe too much in git mind set. what stone i don't see? | 09:57 |
| mgz | you merged the history from the other branch | 09:57 |
| mgz | but left the actual text changes uncommitted | 09:57 |
| mgz | it's the same as doing that in git. | 09:57 |
| tbf | well. in git i usually rebase | 09:57 |
| tbf | and stay away from merges | 09:58 |
| tbf | too much vooodo | 09:58 |
| tbf | voodoo and magic | 09:58 |
| mgz | you like having a nice linear world view :) | 09:58 |
| tbf | mgz, yup :-) | 09:59 |
| mgz | anyway, the point of version control is you have the old stuff still | 09:59 |
| mgz | so you can just start from where you were originally and do it right, rather than trying to fix up the current state | 09:59 |
| tbf | mgz, sure. still at the point of merging a feature i don't care about the dirty details anymore | 10:00 |
| tbf | all that merging zig-zack and so on | 10:00 |
| mgz | look, it's easy, do this: | 10:01 |
| tbf | as long as i work on the features i highly appreciate having different branches and switching between them comparing them, letting them divert, pick changes and so on... | 10:02 |
| tbf | ...but once it is done. it is done. | 10:02 |
| mgz | cd .. && bzr branch -r332 old new && bzr merge -r 332.. -d new ../old | 10:04 |
| mgz | you then have a new branch, with the just the text changes you made in the last few revs ready to commit, and no hisotry to confuse you | 10:05 |
| mgz | you could bring in the original feature branch as a merge to make the history correct, but you probably don't care about that | 10:05 |
| mathrick | so how do install libraries needed by plugins in a standalone windows install? | 10:06 |
| mathrick | I thought it was $plugindir/lib/, but that doesn't seem to work | 10:06 |
| mgz | mathrick: what I did was use not use the windows standalone installers but the python ones and install all the plugins and bits I wanted via the normal setup.py method | 10:07 |
| mgz | there was a thing added for the standalone ones to look in another location for libs though | 10:08 |
| tbf | mgz, checking what this does... | 10:08 |
| mathrick | mgz: I tried that before, but it's a huge PITA really and never works quite as well as the standalone installer | 10:09 |
| mgz | mathrick: try | 10:10 |
| mgz | $ BZR_PDB=1 bzr assert-fail | 10:10 |
| mgz | (Pdb) sys.path | 10:10 |
| mgz | which will tell you where the installed bzr looks for stuff | 10:10 |
| mathrick | ah, good idea | 10:10 |
| mathrick | ah, so site-packages has been added | 10:11 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| lolek | hello all | 12:13 |
| lolek | a question, i've installed bzr-eclipse, and i'm looking for option: compare with latest from repository ... that is available when using svn but with bzr repo ? | 12:13 |
| lolek | hmm ok, forget the question, found it, but the is only: compare with latest from branch, what if i want to specify revision ? | 12:15 |
| jelmer | lolek: I don't think bzr-exclipse is anywhere near usable, is it? | 12:59 |
| lolek | well ... it is | 13:00 |
| lolek | :) | 13:00 |
| lolek | and oh one thing | 13:01 |
| lolek | regarding this: https://bugs.launchpad.net/bzr-svn/+bug/1076388, i've used svn:// when gave url :) | 13:01 |
| ubot5 | Ubuntu bug 1076388 in Bazaar Subversion Plugin "authentication.conf section does not match when port is given" [Undecided,New] | 13:01 |
| jelmer | lolek: not sure I follow? | 13:02 |
| lolek | oh.. sorry my fault... mind shortcut | 13:02 |
| lolek | forget ;d | 13:02 |
| mirtwo | TBF! | 13:04 |
| mirtwo | boah ist die welt klein | 13:04 |
| === mirtwo is now known as mirabilos|work | ||
| jelmer | lolek: sorry, me too :-) | 13:09 |
| lolek | mirabilos|work: could you please speak in english ? | 13:09 |
| mirabilos|work | yes | 13:09 |
| mirabilos|work | “the world is small” | 13:09 |
| lolek | thank You ;) | 13:10 |
| mirabilos|work | tbf was one of the first people I met on IRC, b̲e̲f̲o̲r̲e̲ I even spoke something resembling English | 13:10 |
| tbf | hey mirabilos|work | 13:13 |
| lolek | uhm | 13:14 |
| tbf | mirabilos|work, how long ago is this? 12 years? | 13:15 |
| mirabilos|work | something like that, yes | 13:15 |
| mirabilos|work | probably around 1999/2000 | 13:15 |
| lolek | a question, can i use this way of workflow for bzr and svn as centralized repo ? : http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html | 14:13 |
| lolek | i'm trying to figure out how bzr will deal with branches in folders on svn repo | 14:14 |
| lolek | of course if You have some suggestions or better aproach, i can consider that also | 14:16 |
| karni | Hello folks. I have a problem committing u1-servers. bzr really wants to sign with my mkarnicki@gmail.com key, while I want to sign with michal.karnicki@canonical.com | 14:31 |
| mgz | karni: see #launchpad | 14:32 |
| jelmer | karni: it should be using your whoami details to find the gpg key | 14:32 |
| karni | It's picking mkarnicki by default. How do I change that? I've tried overriding gpg_signing_key | 14:32 |
| karni | whoami says michal.karnicki@canonical.com, but it's not using that one | 14:32 |
| karni | mgz: I think they'll send me back to #bzr :( | 14:33 |
| mgz | probably :) | 14:33 |
| karni | To make matters more "fun", I can sign with @canonical.com a different project with no fuss. | 14:33 |
| karni | I don't see any specific configuration to that project in my locations.conf | 14:33 |
| karni | nor authentication.conf | 14:34 |
| mgz | karni, okay, looking at the code | 14:35 |
| karni | mgz: Thank you! | 14:35 |
| mgz | gpg_signing_key should be either "default" or suitable for passing to gpg -u | 14:36 |
| karni | FWIW I tried passing my canonical e-mail as well as key signature (that's what you call it?) to gpg_signing_key | 14:36 |
| mgz | if default, it looks at 'email' | 14:36 |
| karni | right. I can try that again. | 14:36 |
| karni | should I put it in ~/.bazaar/authentication.conf ? | 14:36 |
| mgz | karni: nope, just bazaar.conf I think | 14:37 |
| mgz | apart from by having a different `bzr whoami --branch` I don't see how different projects could get you different signing | 14:38 |
| karni | mgz: I think it had something to do with me signing it within lxc.. | 14:39 |
| karni | mgz: I did add it to authentication.conf, though | 14:39 |
| karni | mgz: I tried from my host machine, and it commited properly | 14:39 |
| karni | yeah, it's still trying to sign with mkarnicki@gmail.com within lxc | 14:40 |
| karni | mgz: I don't know how that works, but just so you guys know ↑ | 14:40 |
| mgz | but `bzr whoami` in lxc isn't that, and `gpg --clearsign -u ...@canonical.com` works? | 14:43 |
| mgz | possibly lxc hides some of your keys, or confuses the agent in some way? | 14:44 |
| mgz | karni: I can't find any key on your name on a gpg key server | 14:51 |
| karni | mgz: in lxc, bzr whoami is also: Michał Karnicki <michal.karnicki@canonical.com> | 14:52 |
| karni | So correct. | 14:52 |
| karni | mgz: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xF1044FC25FD638E7 | 14:53 |
| karni | mgz: I bet it's confusing the agent in some way | 14:53 |
| mgz | ah, you have an 'i' on the end I'd not registered | 14:54 |
| karni | :) | 14:55 |
| fullermd | You should vowel to be more careful with your spelling... | 14:58 |
| mgz | karni: when you ran just the gpg command inside lxc, did it also want to sign with the wrong key? | 15:00 |
| karni | I can check | 15:00 |
| mgz | fullermd: @ expands to eat all adjacent characters | 15:00 |
| mgz | *munch* *munch* | 15:01 |
| fullermd | Only to the right; you can see what's where the mouth is. | 15:01 |
| karni | mgz: gpg --sign desktop.png signs with mkarnicki, but -u michal.karnicki works to override and sign with the second key | 15:01 |
| lolek | ok, one more time with my question, i'd like to use this approach: http://doc.bazaar.canonical.com/beta/en/user-guide/svn_plugin.html#using-a-central-repository-mirror but want to use svn as central repository, my question is what problems should i consider ? | 15:10 |
| lolek | the problem is that i want to use that like this: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html, the second question is how bazar will work with branch in subdirectory on svn repo ? | 15:12 |
| jelmer | lolek: hi | 15:14 |
| jelmer | lolek: what do you mean with branch in subdirectory exactly? | 15:14 |
| jelmer | bzr-svn handles it fine if there is e.g. a branch named /trunk in the repository, and recognizes copies | 15:15 |
| mgz | karni: last thing to see is run `bzr config` in the branch, see if gpg_signing_key is set anywhere up the chain | 15:30 |
| karni | mgz: bzr: ERROR: unknown command "config" | 15:30 |
| jelmer | karni: your running a very old version of bzr | 15:31 |
| karni | Bazaar (bzr) 2.1.4 in lxc (LUCID), 2.5.1 on host OS | 15:32 |
| karni | This is because it's u1-servers branch, lucid was advised (although I hear it works on more current version) | 15:32 |
| iwata0303 | Hi. | 15:35 |
| iwata0303 | Does anyone know when bzr2.6b3 will come ? | 15:36 |
| jelmer | vila, mgz: ^ | 15:39 |
| lolek | jelmer: may i pm You ? | 15:40 |
| jelmer | lolek: sure | 15:41 |
| mgz | karni: that might also be an issue with gpg signing then. you can, on lucid, us the bzr ppa to restore sanity to the world. | 16:03 |
| karni | mgz: ah. I might try that. I'll stick with committing from host for now :) Thank you! | 16:03 |
| mgz | karni: ppa:bzr/ppa | 16:04 |
| mgz | iwata0303: ideally soon | 16:04 |
| iwata0303 | mgz: Thank you! | 16:05 |
| karni | mgz: Thank you, sir! | 16:05 |
| mgz | I'll send something to the list when I'm about to launch on working out how to do a release | 16:06 |
| mgz | hm.... the next couple of weekends are full, might need to find a weekday night | 16:06 |
| embersoaker | I merged and commited a branch in to trunk and then reverted it. Went back and changed my code in my branch and then when trying to merge again it won't let me. Is there a way to get trunk to forget that this branch was merged/conmitted before? or a way to force a commit? | 16:46 |
| mgz | you merge trunk back into your branch, revert the tree but not the merge marker (`bzr revert .` && bzr commit), then merge the branch back into trunk | 16:52 |
| mgz | basically, the feature branch needs to acknowledge the tree changes were not accepted on trunk, and have a new rev with the changes still present as well as trunk history so trunk knows to reapply them | 16:54 |
| mgz | embersoaker: ^that make sense to you? | 16:56 |
| embersoaker | yes | 16:58 |
| embersoaker | thank you | 16:58 |
| vila | mgz: I'll be in england next week, if connected the latency should be low ;) | 17:00 |
| mgz | oh ho ho, london? | 17:00 |
| mgz | all week? | 17:00 |
| vila | mgz: yup and yup | 17:00 |
| mgz | jelmer: ^ | 17:00 |
| jelmer | vila: where in England? | 17:01 |
| vila | london | 17:01 |
| * jelmer will be in London from Wed-Fri | 17:01 | |
| * SamB_MacG5 grumbles about how ad-hoc bzr's commands are ... | 17:05 | |
| vila | jelmer, mgz : I'll leave Friday afternoon, will need to check my schedule but... would be nice to have either lunch or dinner or something no ? | 17:24 |
| === deryck is now known as deryck[lunch] | ||
| jelmer | vila: yeah, that'd be great | 17:42 |
| fullermd | If I start swimming now, maybe I can meet you there... | 17:43 |
| vila | fullermd: be my guest ;) | 17:43 |
| * SamB_MacG5 is especially thinking that "bzr missing" should support most of the options of "bzr log", like -p ... | 18:35 | |
| fullermd | https://lists.ubuntu.com/archives/bazaar/2008q2/041074.html :p | 18:39 |
| === deryck[lunch] is now known as deryck | ||
| === yofel_ is now known as yofel | ||
| delinquentme_ | ls | 22:23 |
| delinquentme_ | derp! | 22:23 |
| delinquentme_ | I have config files ... I'd like a new user to be able to have access to a version of them ... but not mine ... | 22:24 |
| delinquentme_ | SO .. can I include files within a bzr repo which aren't VC'ed ? | 22:24 |
| fullermd | Well, you can PUT a file there and ignore it. Obviously bzr won't know anything about it, so you'd have to put it there (if it's important) any time you make a WT. | 22:31 |
| delinquentme_ | WT? | 22:32 |
| delinquentme_ | fullermd, ? | 22:32 |
| lifeless | working tree | 22:32 |
| fullermd | Oh, shucks. If I'd known lifeless was here, I'd have just hit 6 or 8 keys at random, and he'd interpret a correct answer out of it... | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!