=== yofel_ is now known as yofel [00:14] hi all === AuroraBorealis is now known as aurora|afk === pjdc_ is now known as pjdc [06:19] hi all ! [06:24] morning vila! [06:24] mgz: hey ! [06:24] mgz: I did comment on your mp but lp dropped my mail [06:25] mgz: td;lr : please land whatever you can [06:25] mgz: I share your curiosity about the consequences on pqm slowness [06:25] I will merge up to dev and see where I'm at. [07:02] mgz: see my last comment on https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361 [07:04] vila: that branch should just land, but there does need to be a bug at least, and maybe a comment there [07:05] twas a comment, not a needsfixing [07:05] mgz: can you file it and comment on the proposal ? [07:05] yeah [07:05] hmm [07:06] mgz: is there an idiom we can use today that would avoid the mangling ? [07:08] mgz: because this patch calls trace.warning twice, but the second call hides the path shuffling into a method that already contains a semi related FIXME (config.Store.external_url) [07:08] delay as long as possible, and keep the actual objects around to stringify when there's an output stream for them to go to [07:08] the logging module doesn't help much here [07:09] hmm [07:10] we are calling trace.warning to output *now*, so basically you're saying that trace itself should provide some way to encode the path/urls properly ? [07:10] but it's going to two places [07:11] oh my, right [07:11] one, a file where we should (but don't really) enforce a utf-8 encoding [07:11] and (possibly) one to the console [07:12] so what ? define and use .format() instead of '%' and inject some path/url specifier in the format string ? [07:13] and will that be enough to cover cases where the fs encoding and the terminal encoding can't both provide a meaningful representation of the path ? [07:14] this is where knowing it's a path/url and not just some string is useful [07:14] because then you can percent-escape and get a correct reference [07:15] percent-escape == url-encoded ? [07:15] if you've already stringified and just have the message to output, there's no safe transform you can do to get a correct path back again [07:15] right, I agree that this is the root cause [07:16] and I'm not amused by the fact that jelmer used 'utf8' instead of fs encoding either ;) [07:17] it's correct for the log, and his terminal :) [07:23] morning all [07:25] mgz: its correct for how the api of trace.note() and trace.warning() are currently defined. [07:25] which is a bug. [07:25] mgz: I don't disagree, but it is not his place to fix it here [07:26] I've *personally* decided not to focus on the issue, because I think if you really wanted to help windows users, you'd be better of polishing something like bzr-explorer [07:26] I don't think it is, but the line added will need changing when that bug is addressed. [07:26] rather than trying to handle the 5-different possible-non-unicode encodings Windows has [07:26] mgz: actually, if we just changed how trace.note/warning worked to have them write to the Windows Console Unicode api [07:26] then utf-8 is just fine [07:27] it can be trans-coded to UTF-16 losslessly [07:27] which is where I'd *much* rather see the fix [07:52] jam: hey ! [07:54] jam: ping [07:54] vila: /wave [07:55] jam: what exactly do you require to approve this safety net is brittle patch to be approved without delaying it for weeks ? [07:57] vila: I thought I was clear about what I would like to see, a way to stop the test suite if a critical piece of infrastructure fails, that doesn't require us to kill the running process [07:57] I'm willing to hedge on it that sys.exit is the best we can get [07:58] it isn't playing nicely as a test suite, but it works fine for "bzr selftest" [07:58] but you objected on using it [07:58] vila " doesn't require killing the running process" [07:58] that would be sys.exit() [07:58] if someone uses another test runner, it will die on them which could be rather surprising. [07:58] you objected on using sys.exit(), I removed it, you object again [07:59] vila: #1) The original point is that we don't want 20k tests failing in the same way, right? Otherwise we would have left it at the status quo [07:59] I'm not trying to go in circles. I do have a position I would like to see, all of the alternatives seem sub-optimal for different reasons [07:59] doesn't apply to jelmer's case and for mthaddon's case we already have -1 [07:59] so I'm a bit ambivalent about picking one [08:00] then let's land self.fail() and continue discussing 'FatalError' so we progress on both fronts [08:00] vila: if it doesn't apply to either case then why do we have a patch? [08:00] vila: good enough [08:01] both cases are addressed: we get a meaningful error, mthaddon's case is less well addressed but also highly unusual [08:03] vila: ISTR that jelmer was surprised to have so many tests failing, but sure [08:04] I think jelmer (and I and mthaddon) were all confused because the error was masked and as such made the diagnosis hard [08:04] the root of mthaddon case was: running as a user not declared in /etc/passwd. OMG ! How the hell do you end up in such a mess on a posix system ? [08:05] the root of jelmer case was: you pretend to be root, yet, you don't have rights to even read files in your home dir. wtf ? [08:07] jam: I totally see your point about FatalError, but we are playing tricks by handling a shared resource without telling the runner already, detangling that when a 10lines fix is available ? Worth the time ? [08:08] vila: well, I was hoping it wouldn't be a lot of time by asking people who knew more about it. Unfortunately, one just got engaged and the other is going to have a baby RSN [08:08] exactly [08:09] so better separate the issues [08:12] jam: do you mind voting on that proposal ? [08:16] voted [08:17] approve [08:17] morning all [08:17] jam: thanks ! [08:18] morning Riddell [08:21] Riddell: _o/ === quicksil1er is now known as quicksilver [08:40] hello europa [08:41] poolie: hellllo AU :) [08:41] ih eiloop [08:41] hi maj [08:41] (i couldn't easily write it upside down, so I wrote it backwards) [08:42] :) [08:43] Hello Ganymede? [09:06] vila, re bug 837926 [09:06] Launchpad bug 837926 in Bazaar "needs a way to get precise timings on pqm landings" [Medium,In progress] https://launchpad.net/bugs/837926 [09:06] don't the subunit streams have enough data? [09:08] poolie: only if you're the submitter [09:09] so this bug could be caused by logging the output? [09:09] *closed [09:09] poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check/+merge/73492 is a simple and pragmatic way to address it [09:10] poolie: I don't want to dive into solutions that requires modifying pqm or anything else, I just want a couple of `date` in the log files (which are already mirrored on chinstrap [09:10] if that's enough that's fine with me [09:10] hm [09:17] well, approved [09:19] poolie: the '.bzr' invocation already redirects stderr, so I'm more comfortable with adding statements *around* its invocation that risking breaking it [09:19] poolie: thanks for the review ! [09:19] then time $(SHELL) -c './bzr ... ' [09:19] but, ok, i see your point abotu risk [09:20] poolie: re quoting, simple of double quotes ? (Can't remember which one is more likely to fail ;) [09:22] failing and non-failing quotes? :) [09:23] bah, I'll just remove the brackets and go with double ones ;) [09:23] it seems to all be rediceted already [09:23] also, i thought we got rid of the separate run in ascii mode? [09:23] did that come back? perhaps that accounts for the slow down [09:24] poolie: only for 2.0 [09:24] oh, i hadn't noticed this was into 2.0 [09:24] though you do say so [09:24] gone in 2.1 [09:24] 2.2 added subunit [09:25] i'm a bit skeptical about changing this in old series [09:25] 2.3 added robustness [09:25] poolie: I can start anywhere you want, I'm mostly interested by 2.3/2.4/trunk myself [09:26] so, changing this stuff has historically tended to throw up environment-dependent failures [09:26] therefore i wouldn't change it in a stable series without a really good reason [09:27] right, me too, [09:27] what are you actually going to do with this? [09:27] the effect should be seen when landing the patch itself, so either it works or it breaks [09:27] that hasn't always been true in the past [09:28] sure, I don't mind starting at 2.4/trunk or even only trunk if you prefer [09:29] the intent is to get timings and a poor-man's monitoring [09:29] i think just trunk [09:29] ok [09:30] so are you hoping to find out that eg it's consistently slower, or it's very variable from one revision to the next, that sort of thing? [09:31] yeah, I don't have any pre-conception [09:43] ok [09:43] so i wouldn't like to break anything just for kind of snooping-around investigation [09:44] sidnei sent me some tarmac/etc instructions which i hope to set up some time [09:44] poolie: I'll stop and revert on first sign of an issue, I swear ;) === Quintasan_ is now known as Quintasan [09:58] vila: for the datestamp, would you want to use: `date "+%F %T"` ? It seems a bit easier to parse than just date [10:01] or date -I [10:01] sorry, -Isec [10:01] that works, too [10:02] jam: th... err, ok, we still have some time before pqm catches up ;) [10:02] poolie: odd, 'man date' doesn't seem to report it, but 'date' supports it [10:02] right, I was about to ask about portability :) [10:02] you have no mandate! i demand a new election. [10:02] date: illegal option -- I [10:02] it is a gnu extension [10:03] fullermd: does BSD use gnu date ? [10:03] osx doesn't [10:03] is there an equivalent in python of isinstance(foo, function) ? [10:03] is it a function? [10:04] you have callable() [10:04] probably you want 'callable(foo)' [10:04] Riddell: do you want something like callable() ? which has been deprecated [10:04] Of course not! We ain't lettin' no commie control something as important as time! [10:04] :) [10:04] note that a Class that implements __call__ is 'callable()' [10:04] well, an object ... [10:05] so it depends on exactyl what you meaon [10:05] anyhow, i should stop [10:05] have a good day all [10:05] jam: if it's deprecated what replaces it? [10:05] have a good evening poolie [10:05] Riddell: something about abstract base class Callable, let me see if I can find it [10:05] docs don't say it's deprecated http://docs.python.org/library/functions.html#callable [10:05] jam, poolie, fullermd : I think I'll stick with bare `date` , parsing can be addressed [10:06] type(foo) == types.FunctionType [10:06] Riddell: maybe it is deprecated only in py3 [10:06] if you want to check for functions only ^ [10:06] but it certainly exists in 2.7 so feel free to use it [10:06] Riddell: http://docs.python.org/dev/whatsnew/3.2.html [10:06] says that they restored it [10:07] because they felt it was more readable than isinstance(x, collections.Callable) [10:07] poolie: cu [10:07] so I missed that part. And yes, it is not deprecated after all [10:07] lovely, thanks [10:07] vila: Well, if it's meant to be "parsed" by a human, plain output is at least as good as any other. [10:09] For auto-parsing, epoch would be simplest probably. Ignoring the mess of nonmonotonicity/continuity of timekeeping in general anyway... [10:09] fullermd: I still find -I easier to parse as a human when I'm trying to do something like *compare* the dates [10:09] thisi sa kludge; let's not overoptimize it [10:09] remember you have the option to just ask sysadmins to run experiments for you [10:10] Especially if you have to wrap the months (though that shouldn't be a factor here) [10:10] poolie: well, I've been pqm-submitting branches that are known-broken which works fine. But for the historical record, it would have been nice to have the datestamps [10:10] and then "oh, in rev X things are a lot slower" [10:23] jam: python -c 'import datetime; print datetime.datetime.strptime("Wed Aug 31 12:16:18 CEST 2011", "%a %b %d %H:%M:%S %Z %Y")' [10:24] vila: still harder to think about, etc. Anyway, it isn't like it really matters, it was just a suggestion. [10:25] jam: sure, but poolie preferred trunk only to lower the risks, I'd rather not add risks for portability [10:25] I'm pretty sure +%F is portable [10:25] it is -Isec that isn't [10:29] %F doesn't seem to be in posix http://pubs.opengroup.org/onlinepubs/000095399/utilities/date.html [10:30] It's part of strftime in C99 (though not C89) [10:40] Riddell: hi [10:40] is it common practice for uploaders to request syncs from Debian, or is it also ok if I just re-upload packages directly to Ubuntu, by myself? [10:41] jelmer: it's better to request a sync [10:41] assuming there's no changes to be made [10:42] Riddell: Cool, thanks. [10:42] I can do the sync if there's no freezes to care about, just need the bug number [10:43] Riddell: that'd be great, I forgot you were an archive admin [10:44] jelmer: will be afk (lunch), let me know if/when bzr-2.4.0 is deployed on jubany, and thanks for doing it ;) [10:44] Riddell: bug 831690 [10:44] Launchpad bug 831690 in bzr-gtk (Ubuntu) "Sync bzr-gtk 0.100.0+bzr734-2 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/831690 [10:48] Riddell: I'll have a couple of others later today for the other bzr plugin FTBFS bugs, if that's okay. [10:48] vila: will do :) [10:48] sure === nyuszika7h` is now known as nyuszika7h [12:14] Hi, all. I try to log with my launchpad login on bzr: bzr lp-login nickname [12:15] but I work behind a firewall, and I cannot contact launchpad on SSH port [12:15] and now each bzr branch commands fail [12:16] How I can unlogin to just clone some launchpad repository ? [12:16] doude: you need to remove launchpad_username from bazaar.conf [12:16] doude: do you have a bzr recent enough to run 'bzr config' ? [12:20] vila: yes [12:20] ugh. just accidentally passed a .gz stream to subunit, and it decided the whole thing should be "passthrough", which meant it sent 600kB of garbage to the terminal, which got the system bell *really* excited [12:21] if the bell is 3s long, and system-bell is 1/255 of the chars, I estimate it will take 2 hours for it to stop beeping [12:21] jam: ouch ;) [12:21] vila: thanks a lot for your help [12:21] fortunately 'mute' works, but volume itself doesn't [12:21] doude: then bzr config --remove launchpad_username in your home dir should do [12:22] vila: ok, it works [12:24] wow, the garbage killed jam :-/ [12:24] vila: Is it possible to log to launchpad if the SSH port is blocked ? by another way ? [12:24] doude: short answer: no [12:25] doude: there are various tricks to route ssh but that will need cooperation from the firewall admin in most cases [12:27] jam is back \o/ death to the garbage ! ;) [12:27] :) [12:28] vila: ok [12:28] doude: you can access lp in read-only mode without ssh though [12:29] vila: ok [12:29] bye bzr men [12:29] doude: and if I remember correctly you can even make merge proposals via mail but I don't remember the details [12:29] no fast enough :-} [12:29] not [12:32] jam: just to confirm, you were happy with my move-hashcache MP if I added a common base class for WT2 and WT3 ? [12:33] jelmer: I think I approved it already, but if not, yes [12:34] ah,I think I forgot to actually vote [12:34] jam: yep, your last vote was needsinfo. anyway, thanks [12:37] I just updated it [12:39] I noticed, already sent it off to pqm :) [13:16] hey, what's the difference between -c and -r in bzr merge? [13:16] http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html doesn't make it clear [13:17] oh, I just read that cherry-picks via "bzr merge" are not tracked by bzr :-( [13:18] I was wondering whether my current gripe with git (cherry-picks don't track the history, merges force non-modular resolution of all conflicts at the same time) was solved by bzr [13:25] Peaker: hi [13:26] Peaker: unfortunately we don't really have either of those features either (yet) [13:27] we would like to support both, in particular tracking cherry pick merges, but it's a hard problem to solve if you want to get it right. [13:33] jelmer: well, we're using git, and I noticed some serious problems -- for example: if you have two branches, A, and B. You cherry-pick a bad commit A->B. Now you revert the bad commit only in A. Then you merge A and B -- you will get the bad commit again, because a 3-way merge considers (bad+revert = 0 < bad) [13:34] also, a "merge" in a large project that involves many people is pretty horrible -- conflict resolution requires the expertise of many different people! [13:34] (and they're all forced to share a working tree to work together on the problem) [13:34] and the conflict resolutions are later very hard to view in isolation, because merge diffs are hard to view (relative to which parent?) [13:34] So my conclusion is that cherry-picks are really the right way to move work around -- but without their metadata being tracked, it works horribly [13:35] I think darcs has the right model of "cherry picks" are the only way to move work around and are tracked.. but it has performance issues [13:43] Peaker: three way merges are relatively easy because there's really only three trees you have to care about [13:44] Peaker: with cherrypicks you could have to consider all changesets in a repository [13:45] it would be relatively easy to track cherrypick merges in bzr (in revision properties, for example) but using that information intelligently and without making merge scale badly is the hard bit [13:49] jelmer: I think darcs just makes merges scale badly :) [13:50] but I'm thinking it might be worth it... We're getting horrible horrible merges, and cherry-picking everything means we lose all DVCS tracking of everything [13:50] the only solution we have is to just merge extremely often so no divergence picks up [13:54] Peaker: btw, I'm pretty sure bzr will pick up the revert in the case you mention [13:54] Peaker: bzr does track per file history, unlike git, which just tracks content [13:56] jelmer: but you do a 3-way merge here, no? [13:57] the per-file history here is that in branch A, the file had changed, and then changed back, so sum of all changes = 0. In branch B, it just changed. So the sum = change. 3-way merge of 0 and change = change, no? [13:57] Peaker: bzr doesn't look at the checksum to see if a file has changed. It keeps track of what revision it was last changed. [13:58] so what would bzr do here? it would see the file changed in branch A, and then changed back, and consider it a conflict? [14:00] Peaker: it should have enough info to create a conflict; I'm not sure if it actually creates one [14:00] jelmer: git has the same info, of course, it is also a question of whether it looks at that info [14:01] Peaker: git doesn't know what revision a file last changed in, unless it's going to scan history (which it doesn't) [14:01] it just finds the common base to use for the 3 way merge [14:01] abentley: hi [14:01] jelmer: ah, yes, perhaps [14:01] jelmer: hi. [14:01] jelmer: though I think merge does scan history in various cases [14:02] Peaker: it scans it to find the base for the three way merge [14:03] jelmer: Well, that scan is per-file, so it had already encountered all of the version that changed it [14:03] Peaker: finding the base for the merge? that can only be done based on the revision graph [14:04] jelmer: yeah -- and when walking that graph, it sees whether that file changed in each of the revisions [14:04] Peaker: it doesn't look at the files during that scan, just the revisions [14:05] jelmer: I'm pretty sure it does the 3-way merge basis lookup on a per-file basis, according to the debug prints visible when encountering conflicts. But I'm not entirely sure [14:05] and if it does that -- it should not be expensive to see whether the file changed or not, in those revs, if it didn't already [14:06] Peaker: it is fairly expensive because to know what file has changed you have to apply the rename/copy detection heuristics [14:07] Peaker: to follow the changed files I mean [14:07] as far as I understand it it uses the revision graph to find the base revision, and then applies the heuristics between just the base revision and the other/this trees [14:10] Peaker: bzr's merge doesn't generate a conflict either [15:05] jelmer: care to have a look at https://code.launchpad.net/~vila/udd/806425-append-revs-only/+merge/73531 ? [15:09] vila: sure [15:09] Q: is there a way to commit/operate on a specific set of changes after a 'bzr status'? For example, if bzr status shows removed, modified, and unknown files, and I want to work only with the removed files, is there some way to specify that? [15:11] jblue: 'bzr commit file1 file2' should just work [15:12] it does, but was looking for a method working with that set, in an instance where I have a lot of files being removed. [15:12] but also have a lot of files modified, and their locations are intermixed [15:12] so specifying them one by one is a bit tedious [15:13] may be 'bzr qcommit' provides some help ? [15:14] Did you get there after a merge or some heavy refactoring from an IDE ? [15:14] heavy refactoring.. basically several files have been removed, modified, and added, and I'd like to do the removal first, then work with the others [15:15] but no file has been both removed and added right ? [15:16] well it was, but I quickly saw that was going to be a headache, so I've reverted, and am doing the removal first [15:17] I meant, you didn't *rename* files by doing remove/add right ? [15:17] no [15:17] ok, good === jpds_ is now known as jpds [15:26] vila: r=me [15:26] jelmer: thanks, I'm deploying [15:26] ha, damn, been interrupted and forgot to answer [15:27] jelmer: my understanding is that a_r_o should only be applied in *some* cases so having a global switch doesn't make sense at this point [15:28] vila: I mean, having a global variable that's set to True or False [15:28] what for ? switch it back to True ? [15:29] yeah [15:30] AIUI, using it for local branches is just a Bad Idea, so after some checking I will probably just get rid of the calls themselves [15:31] for the lp branches, AIUI again, the rules are not well understood yet so we probably end up replacing the calls by some more logic [15:31] so in the end, none of the actual calls should survive [15:31] jelmer: or do you expect such a breakage that we want to come back to a_r_o=True ? [15:32] vila: I'm not really bothered either way :) [15:32] hmm, looks like lp has or had some transient issues... [15:32] I've some mess in my repo and if I try to do a ci it says: bzr: ERROR: Bound branch BzrBranch7('file:///....') is out of date with master branch BzrBranch7, To commit to master branch, run update and then commit. but I want to be sure that nothing in my working directory will be changed.. I'm sure my current version is the correct version [15:32] any hint? [15:35] gypsymauro: hi [15:35] gypsymauro: I think "bzr diff -rbranch:/path/to/master/branch" should tell you what it would change [15:35] what does 'bzr missing' says ? [15:37] is says that I've two extra revision (and is true, i done some ci --local) [15:38] any uncommitted changes ? [15:38] the bzr diffs displays me 29645 lines.. [15:39] gypsymauro: in that case it shouldn't change your working tree, although it will change your local commits to be pending merges [15:40] vila: what do u mean? I committed locally, only this , how can I now commit to the remote repository? [15:41] gypsymauro: if you run "bzr up" and then "bzr commit" that will commit your changes to the local repository [15:41] argh [15:41] s/local/remote/ [15:48] jelmer: and this for sure doesn't change anything in my local repository? (the update term scares me :) [15:49] gypsymauro: it will update bzr metadata in the local tree - it will change your two local commits to be pending merges, and your branch tip to match that of the remote branch [15:50] gypsymauro: if the remote branch doesn't have any extra revisions (as "bzr missing" seems to indicate) then it shouldn't change any of the files in your tree [15:52] jelmer: doh.. [15:52] bzr conflicts [15:52] Conflict: can't delete foo/bar because it is not empty. Not deleting. Conflict because foo/bar is not versioned, but has versioned children. Versioned directory. [15:53] damn.. it creates a lot of .BASE .OTHER and .THIS file... [15:58] it's a nightmare.. [15:59] gypsymauro: ouch, that sucks :( [15:59] I keep wishing we'll just squirrel ci --local away somewhere deep hidden... [15:59] gypsymauro: you had local commits that added foo/bar ? [16:00] fullermd: yeah, me too. I think we should just get rid of them. [16:00] damn... [16:01] if I recover from a backup my foo/bar? this resolves my conflicts? [16:01] or I've to merge manually ? [16:02] gypsymauro: I suspect "bzr resolve --take-other" might fix this for you, but I'm not entirely sure [16:02] gypsymauro: sry was called elsewhere === beuno is now known as beuno-lunch [16:03] gypsymauro: if you have conflicts, a merge already occured (triggered by update) [16:03] jelmer: uhm i suppose the .THIS version is the correct [16:03] gypsymauro: how conflicts ? [16:03] gypsymauro: how many conflicts ? [16:03] vila: 47 [16:04] wc -l [16:04] hmm [16:04] !paste [16:04] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [16:04] gypsymauro: can you pastebin the output of 'bzr conflicts' ? [16:04] gypsymauro: and 'bzr st' [16:05] http://pastebin.com/TCYWVLy6 [16:06] and http://pastebin.com/nWPRg99U === deryck is now known as deryck[lunch] [16:08] Riddell: still there? [16:08] Riddell: another sync is bug 837956 [16:08] Launchpad bug 837956 in bzr-dbus (Ubuntu) "Sync bzr-dbus 0.1~bzr51-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/837956 [16:09] gypsymauro: :-/ Looks like you added files that were also added remotely... [16:09] gypsymauro: but you said 'bzr missing' only reported local revisions right ? [16:10] vila: the problem is that update works in two phases; first it updates to the remote branch, then it merges in the local commits again [16:10] vila: I *think* [16:10] jelmer: but we stop as soon as we get a conflict (or was it discussed but not implemented ?) [16:10] gypsymauro: what bzr version are you using ? [16:10] vila: sure, but he was up to date [16:10] The usual cause of kerfufflage there is when you have uncommitted changes as _well_ as local commits. [16:11] fullermd: I asked for uncommitted changes first ;) [16:11] I thought we added some guard on that, but maybe we didn't. I dunno, I stay too far away from those dragons to remember :p [16:11] Bazaar (bzr) 2.1.2 [16:11] gypsymauro: ouch, OS/version ? [16:12] debian squeeze [16:13] Riddell: and I have a bzr upload waiting for approval [16:13] jelmer: waiting where? [16:13] gypsymauro: rrright, let's do it the old fashion way then [16:14] gypsymauro: do you have the qbzr plugin installed ? [16:15] Riddell: waiting for approval by an archive admin; looks like it was just rejected [16:15] jelmer: I rejected 2ubuntu1. You just uploaded 3ubuntu1. [16:16] At this point it needs to wait until after Oneiric Beta 1 is done. [16:16] ScottK: ah, my mistake. Thanks! [16:16] (I also pinged you on #ubuntu-devel about it ... [16:16] ) [16:17] vila: now yes :D [16:17] gypsymauro: great, try 'bzr qlog' [16:18] ScottK: yep, not sure why I missed that [16:18] vila: ok [16:18] gypsymauro: we need to find the last revision committed locally (we'll need the revision on your remote branch to, but this one will be easy to get) [16:18] i've two light blue circles [16:19] gypsymauro: 'bzr revno' ? [16:19] ok the last is 14 [16:19] do you see a 'pending merges' label ? [16:19] yes [16:19] 14.1.2 [16:20] and another blue 14.1 [16:20] 14.1.1 [16:20] exellent, that's your local commits [16:20] without the pending msg [16:20] exactly [16:20] justasec [16:22] gypsymauro: roughly, we will create a branch from remote and 'merge ../with-conflicts -r14.1.2' [16:25] vila: I'm in ur hands... take care about 2 weeks of work :) I've a backup btw [16:26] gypsymauro: i.e.: in a new directory: bzr branch recover ; cd recover ; bzr merge -r14.1.2 [16:29] vila: doing the first step [16:29] gypsymauro: no worries, try (above the dir with conflicts) : bzr branch -r14.1.2 my-precious [16:29] what do u mean with [16:30] your checkout dir [16:30]