| === yofel_ is now known as yofel | ||
| poolie | hi all | 00:14 |
|---|---|---|
| === AuroraBorealis is now known as aurora|afk | ||
| === pjdc_ is now known as pjdc | ||
| vila | hi all ! | 06:19 |
| mgz | morning vila! | 06:24 |
| vila | mgz: hey ! | 06:24 |
| vila | mgz: I did comment on your mp but lp dropped my mail | 06:24 |
| vila | mgz: td;lr : please land whatever you can | 06:25 |
| vila | mgz: I share your curiosity about the consequences on pqm slowness | 06:25 |
| mgz | I will merge up to dev and see where I'm at. | 06:25 |
| vila | mgz: see my last comment on https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361 | 07:02 |
| mgz | vila: that branch should just land, but there does need to be a bug at least, and maybe a comment there | 07:04 |
| mgz | twas a comment, not a needsfixing | 07:05 |
| vila | mgz: can you file it and comment on the proposal ? | 07:05 |
| vila | yeah | 07:05 |
| vila | hmm | 07:05 |
| vila | mgz: is there an idiom we can use today that would avoid the mangling ? | 07:06 |
| vila | 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 |
| mgz | 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 |
| mgz | the logging module doesn't help much here | 07:08 |
| vila | hmm | 07:09 |
| vila | 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 |
| mgz | but it's going to two places | 07:10 |
| vila | oh my, right | 07:11 |
| mgz | one, a file where we should (but don't really) enforce a utf-8 encoding | 07:11 |
| mgz | and (possibly) one to the console | 07:11 |
| vila | so what ? define and use .format() instead of '%' and inject some path/url specifier in the format string ? | 07:12 |
| vila | 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:13 |
| mgz | this is where knowing it's a path/url and not just some string is useful | 07:14 |
| mgz | because then you can percent-escape and get a correct reference | 07:14 |
| vila | percent-escape == url-encoded ? | 07:15 |
| mgz | 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 |
| vila | right, I agree that this is the root cause | 07:15 |
| vila | and I'm not amused by the fact that jelmer used 'utf8' instead of fs encoding either ;) | 07:16 |
| mgz | it's correct for the log, and his terminal :) | 07:17 |
| jam | morning all | 07:23 |
| jam | mgz: its correct for how the api of trace.note() and trace.warning() are currently defined. | 07:25 |
| mgz | which is a bug. | 07:25 |
| jam | mgz: I don't disagree, but it is not his place to fix it here | 07:25 |
| jam | 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 |
| mgz | I don't think it is, but the line added will need changing when that bug is addressed. | 07:26 |
| jam | rather than trying to handle the 5-different possible-non-unicode encodings Windows has | 07:26 |
| jam | mgz: actually, if we just changed how trace.note/warning worked to have them write to the Windows Console Unicode api | 07:26 |
| jam | then utf-8 is just fine | 07:26 |
| jam | it can be trans-coded to UTF-16 losslessly | 07:27 |
| jam | which is where I'd *much* rather see the fix | 07:27 |
| vila | jam: hey ! | 07:52 |
| vila | jam: ping | 07:54 |
| jam | vila: /wave | 07:54 |
| vila | jam: what exactly do you require to approve this safety net is brittle patch to be approved without delaying it for weeks ? | 07:55 |
| jam | 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 |
| jam | I'm willing to hedge on it that sys.exit is the best we can get | 07:57 |
| jam | it isn't playing nicely as a test suite, but it works fine for "bzr selftest" | 07:58 |
| vila | but you objected on using it | 07:58 |
| jam | vila " doesn't require killing the running process" | 07:58 |
| jam | that would be sys.exit() | 07:58 |
| jam | if someone uses another test runner, it will die on them which could be rather surprising. | 07:58 |
| vila | you objected on using sys.exit(), I removed it, you object again | 07:58 |
| jam | 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 |
| jam | 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 |
| vila | doesn't apply to jelmer's case and for mthaddon's case we already have -1 | 07:59 |
| jam | so I'm a bit ambivalent about picking one | 07:59 |
| vila | then let's land self.fail() and continue discussing 'FatalError' so we progress on both fronts | 08:00 |
| jam | vila: if it doesn't apply to either case then why do we have a patch? | 08:00 |
| jam | vila: good enough | 08:00 |
| vila | both cases are addressed: we get a meaningful error, mthaddon's case is less well addressed but also highly unusual | 08:01 |
| jam | vila: ISTR that jelmer was surprised to have so many tests failing, but sure | 08:03 |
| vila | I think jelmer (and I and mthaddon) were all confused because the error was masked and as such made the diagnosis hard | 08:04 |
| vila | 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:04 |
| vila | 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:05 |
| vila | 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:07 |
| jam | 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 |
| vila | exactly | 08:08 |
| vila | so better separate the issues | 08:09 |
| vila | jam: do you mind voting on that proposal ? | 08:12 |
| jam | voted | 08:16 |
| jam | approve | 08:17 |
| Riddell | morning all | 08:17 |
| vila | jam: thanks ! | 08:17 |
| jam | morning Riddell | 08:18 |
| vila | Riddell: _o/ | 08:21 |
| === quicksil1er is now known as quicksilver | ||
| poolie | hello europa | 08:40 |
| vila | poolie: hellllo AU :) | 08:41 |
| jam | ih eiloop | 08:41 |
| poolie | hi maj | 08:41 |
| jam | (i couldn't easily write it upside down, so I wrote it backwards) | 08:41 |
| vila | :) | 08:42 |
| fullermd | Hello Ganymede? | 08:43 |
| poolie | vila, re bug 837926 | 09:06 |
| ubot5 | 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 |
| poolie | don't the subunit streams have enough data? | 09:06 |
| vila | poolie: only if you're the submitter | 09:08 |
| poolie | so this bug could be caused by logging the output? | 09:09 |
| poolie | *closed | 09:09 |
| vila | poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check/+merge/73492 is a simple and pragmatic way to address it | 09:09 |
| vila | 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 |
| poolie | if that's enough that's fine with me | 09:10 |
| poolie | hm | 09:10 |
| poolie | well, approved | 09:17 |
| vila | poolie: the '.bzr' invocation already redirects stderr, so I'm more comfortable with adding statements *around* its invocation that risking breaking it | 09:19 |
| vila | poolie: thanks for the review ! | 09:19 |
| poolie | then time $(SHELL) -c './bzr ... ' | 09:19 |
| poolie | but, ok, i see your point abotu risk | 09:19 |
| vila | poolie: re quoting, simple of double quotes ? (Can't remember which one is more likely to fail ;) | 09:20 |
| poolie | failing and non-failing quotes? :) | 09:22 |
| vila | bah, I'll just remove the brackets and go with double ones ;) | 09:23 |
| poolie | it seems to all be rediceted already | 09:23 |
| poolie | also, i thought we got rid of the separate run in ascii mode? | 09:23 |
| poolie | did that come back? perhaps that accounts for the slow down | 09:23 |
| vila | poolie: only for 2.0 | 09:24 |
| poolie | oh, i hadn't noticed this was into 2.0 | 09:24 |
| poolie | though you do say so | 09:24 |
| vila | gone in 2.1 | 09:24 |
| vila | 2.2 added subunit | 09:24 |
| poolie | i'm a bit skeptical about changing this in old series | 09:25 |
| vila | 2.3 added robustness | 09:25 |
| vila | poolie: I can start anywhere you want, I'm mostly interested by 2.3/2.4/trunk myself | 09:25 |
| poolie | so, changing this stuff has historically tended to throw up environment-dependent failures | 09:26 |
| poolie | therefore i wouldn't change it in a stable series without a really good reason | 09:26 |
| vila | right, me too, | 09:27 |
| poolie | what are you actually going to do with this? | 09:27 |
| vila | the effect should be seen when landing the patch itself, so either it works or it breaks | 09:27 |
| poolie | that hasn't always been true in the past | 09:27 |
| vila | sure, I don't mind starting at 2.4/trunk or even only trunk if you prefer | 09:28 |
| vila | the intent is to get timings and a poor-man's monitoring | 09:29 |
| poolie | i think just trunk | 09:29 |
| vila | ok | 09:29 |
| poolie | 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:30 |
| vila | yeah, I don't have any pre-conception | 09:31 |
| poolie | ok | 09:43 |
| poolie | so i wouldn't like to break anything just for kind of snooping-around investigation | 09:43 |
| poolie | sidnei sent me some tarmac/etc instructions which i hope to set up some time | 09:44 |
| vila | poolie: I'll stop and revert on first sign of an issue, I swear ;) | 09:44 |
| === Quintasan_ is now known as Quintasan | ||
| jam | vila: for the datestamp, would you want to use: `date "+%F %T"` ? It seems a bit easier to parse than just date | 09:58 |
| poolie | or date -I | 10:01 |
| poolie | sorry, -Isec | 10:01 |
| jam | that works, too | 10:01 |
| vila | jam: th... err, ok, we still have some time before pqm catches up ;) | 10:02 |
| jam | poolie: odd, 'man date' doesn't seem to report it, but 'date' supports it | 10:02 |
| vila | right, I was about to ask about portability :) | 10:02 |
| poolie | you have no mandate! i demand a new election. | 10:02 |
| fullermd | date: illegal option -- I | 10:02 |
| poolie | it is a gnu extension | 10:02 |
| vila | fullermd: does BSD use gnu date ? | 10:03 |
| vila | osx doesn't | 10:03 |
| Riddell | is there an equivalent in python of isinstance(foo, function) ? | 10:03 |
| poolie | is it a function? | 10:03 |
| ccxCZ | you have callable() | 10:04 |
| poolie | probably you want 'callable(foo)' | 10:04 |
| jam | Riddell: do you want something like callable() ? which has been deprecated | 10:04 |
| fullermd | Of course not! We ain't lettin' no commie control something as important as time! | 10:04 |
| poolie | :) | 10:04 |
| jam | note that a Class that implements __call__ is 'callable()' | 10:04 |
| jam | well, an object ... | 10:04 |
| poolie | so it depends on exactyl what you meaon | 10:05 |
| poolie | anyhow, i should stop | 10:05 |
| poolie | have a good day all | 10:05 |
| Riddell | jam: if it's deprecated what replaces it? | 10:05 |
| jam | have a good evening poolie | 10:05 |
| jam | Riddell: something about abstract base class Callable, let me see if I can find it | 10:05 |
| Riddell | docs don't say it's deprecated http://docs.python.org/library/functions.html#callable | 10:05 |
| vila | jam, poolie, fullermd : I think I'll stick with bare `date` , parsing can be addressed | 10:05 |
| ccxCZ | type(foo) == types.FunctionType | 10:06 |
| jam | Riddell: maybe it is deprecated only in py3 | 10:06 |
| ccxCZ | if you want to check for functions only ^ | 10:06 |
| jam | but it certainly exists in 2.7 so feel free to use it | 10:06 |
| jam | Riddell: http://docs.python.org/dev/whatsnew/3.2.html | 10:06 |
| jam | says that they restored it | 10:06 |
| jam | because they felt it was more readable than isinstance(x, collections.Callable) | 10:07 |
| vila | poolie: cu | 10:07 |
| jam | so I missed that part. And yes, it is not deprecated after all | 10:07 |
| Riddell | lovely, thanks | 10:07 |
| fullermd | vila: Well, if it's meant to be "parsed" by a human, plain output is at least as good as any other. | 10:07 |
| fullermd | For auto-parsing, epoch would be simplest probably. Ignoring the mess of nonmonotonicity/continuity of timekeeping in general anyway... | 10:09 |
| jam | fullermd: I still find -I easier to parse as a human when I'm trying to do something like *compare* the dates | 10:09 |
| poolie | thisi sa kludge; let's not overoptimize it | 10:09 |
| poolie | remember you have the option to just ask sysadmins to run experiments for you | 10:09 |
| jam | Especially if you have to wrap the months (though that shouldn't be a factor here) | 10:10 |
| jam | 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 |
| jam | and then "oh, in rev X things are a lot slower" | 10:10 |
| vila | 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:23 |
| jam | vila: still harder to think about, etc. Anyway, it isn't like it really matters, it was just a suggestion. | 10:24 |
| vila | jam: sure, but poolie preferred trunk only to lower the risks, I'd rather not add risks for portability | 10:25 |
| jam | I'm pretty sure +%F is portable | 10:25 |
| jam | it is -Isec that isn't | 10:25 |
| ccxCZ | %F doesn't seem to be in posix http://pubs.opengroup.org/onlinepubs/000095399/utilities/date.html | 10:29 |
| fullermd | It's part of strftime in C99 (though not C89) | 10:30 |
| jelmer | Riddell: hi | 10:40 |
| jelmer | 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:40 |
| Riddell | jelmer: it's better to request a sync | 10:41 |
| Riddell | assuming there's no changes to be made | 10:41 |
| jelmer | Riddell: Cool, thanks. | 10:42 |
| Riddell | I can do the sync if there's no freezes to care about, just need the bug number | 10:42 |
| jelmer | Riddell: that'd be great, I forgot you were an archive admin | 10:43 |
| vila | 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 |
| jelmer | Riddell: bug 831690 | 10:44 |
| ubot5 | 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:44 |
| jelmer | Riddell: I'll have a couple of others later today for the other bzr plugin FTBFS bugs, if that's okay. | 10:48 |
| jelmer | vila: will do :) | 10:48 |
| Riddell | sure | 10:48 |
| === nyuszika7h` is now known as nyuszika7h | ||
| doude | Hi, all. I try to log with my launchpad login on bzr: bzr lp-login nickname | 12:14 |
| doude | but I work behind a firewall, and I cannot contact launchpad on SSH port | 12:15 |
| doude | and now each bzr branch commands fail | 12:15 |
| doude | How I can unlogin to just clone some launchpad repository ? | 12:16 |
| vila | doude: you need to remove launchpad_username from bazaar.conf | 12:16 |
| vila | doude: do you have a bzr recent enough to run 'bzr config' ? | 12:16 |
| doude | vila: yes | 12:20 |
| jam | 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:20 |
| jam | 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 |
| vila | jam: ouch ;) | 12:21 |
| doude | vila: thanks a lot for your help | 12:21 |
| jam | fortunately 'mute' works, but volume itself doesn't | 12:21 |
| vila | doude: then bzr config --remove launchpad_username in your home dir should do | 12:21 |
| doude | vila: ok, it works | 12:22 |
| vila | wow, the garbage killed jam :-/ | 12:24 |
| doude | vila: Is it possible to log to launchpad if the SSH port is blocked ? by another way ? | 12:24 |
| vila | doude: short answer: no | 12:24 |
| vila | doude: there are various tricks to route ssh but that will need cooperation from the firewall admin in most cases | 12:25 |
| vila | jam is back \o/ death to the garbage ! ;) | 12:27 |
| jam | :) | 12:27 |
| doude | vila: ok | 12:28 |
| vila | doude: you can access lp in read-only mode without ssh though | 12:28 |
| doude | vila: ok | 12:29 |
| doude | bye bzr men | 12:29 |
| vila | doude: and if I remember correctly you can even make merge proposals via mail but I don't remember the details | 12:29 |
| vila | no fast enough :-} | 12:29 |
| vila | not | 12:29 |
| jelmer | jam: just to confirm, you were happy with my move-hashcache MP if I added a common base class for WT2 and WT3 ? | 12:32 |
| jam | jelmer: I think I approved it already, but if not, yes | 12:33 |
| jam | ah,I think I forgot to actually vote | 12:34 |
| jelmer | jam: yep, your last vote was needsinfo. anyway, thanks | 12:34 |
| jam | I just updated it | 12:37 |
| jelmer | I noticed, already sent it off to pqm :) | 12:39 |
| Peaker | hey, what's the difference between -c and -r in bzr merge? | 13:16 |
| Peaker | http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html doesn't make it clear | 13:16 |
| Peaker | oh, I just read that cherry-picks via "bzr merge" are not tracked by bzr :-( | 13:17 |
| Peaker | 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:18 |
| jelmer | Peaker: hi | 13:25 |
| jelmer | Peaker: unfortunately we don't really have either of those features either (yet) | 13:26 |
| jelmer | 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:27 |
| Peaker | 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:33 |
| Peaker | 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 |
| Peaker | (and they're all forced to share a working tree to work together on the problem) | 13:34 |
| Peaker | 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 |
| Peaker | 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:34 |
| Peaker | 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:35 |
| jelmer | Peaker: three way merges are relatively easy because there's really only three trees you have to care about | 13:43 |
| jelmer | Peaker: with cherrypicks you could have to consider all changesets in a repository | 13:44 |
| jelmer | 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:45 |
| Peaker | jelmer: I think darcs just makes merges scale badly :) | 13:49 |
| Peaker | 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 |
| Peaker | the only solution we have is to just merge extremely often so no divergence picks up | 13:50 |
| jelmer | Peaker: btw, I'm pretty sure bzr will pick up the revert in the case you mention | 13:54 |
| jelmer | Peaker: bzr does track per file history, unlike git, which just tracks content | 13:54 |
| Peaker | jelmer: but you do a 3-way merge here, no? | 13:56 |
| Peaker | 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 |
| jelmer | 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:57 |
| Peaker | so what would bzr do here? it would see the file changed in branch A, and then changed back, and consider it a conflict? | 13:58 |
| jelmer | Peaker: it should have enough info to create a conflict; I'm not sure if it actually creates one | 14:00 |
| Peaker | jelmer: git has the same info, of course, it is also a question of whether it looks at that info | 14:00 |
| jelmer | 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 |
| jelmer | it just finds the common base to use for the 3 way merge | 14:01 |
| jelmer | abentley: hi | 14:01 |
| Peaker | jelmer: ah, yes, perhaps | 14:01 |
| abentley | jelmer: hi. | 14:01 |
| Peaker | jelmer: though I think merge does scan history in various cases | 14:01 |
| jelmer | Peaker: it scans it to find the base for the three way merge | 14:02 |
| Peaker | jelmer: Well, that scan is per-file, so it had already encountered all of the version that changed it | 14:03 |
| jelmer | Peaker: finding the base for the merge? that can only be done based on the revision graph | 14:03 |
| Peaker | jelmer: yeah -- and when walking that graph, it sees whether that file changed in each of the revisions | 14:04 |
| jelmer | Peaker: it doesn't look at the files during that scan, just the revisions | 14:04 |
| Peaker | 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 |
| Peaker | 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:05 |
| jelmer | Peaker: it is fairly expensive because to know what file has changed you have to apply the rename/copy detection heuristics | 14:06 |
| jelmer | Peaker: to follow the changed files I mean | 14:07 |
| jelmer | 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:07 |
| jelmer | Peaker: bzr's merge doesn't generate a conflict either | 14:10 |
| vila | jelmer: care to have a look at https://code.launchpad.net/~vila/udd/806425-append-revs-only/+merge/73531 ? | 15:05 |
| jelmer | vila: sure | 15:09 |
| jblue | 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:09 |
| vila | jblue: 'bzr commit file1 file2' should just work | 15:11 |
| jblue | 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 |
| jblue | but also have a lot of files modified, and their locations are intermixed | 15:12 |
| jblue | so specifying them one by one is a bit tedious | 15:12 |
| vila | may be 'bzr qcommit' provides some help ? | 15:13 |
| vila | Did you get there after a merge or some heavy refactoring from an IDE ? | 15:14 |
| jblue | 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:14 |
| vila | but no file has been both removed and added right ? | 15:15 |
| jblue | 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:16 |
| vila | I meant, you didn't *rename* files by doing remove/add right ? | 15:17 |
| jblue | no | 15:17 |
| vila | ok, good | 15:17 |
| === jpds_ is now known as jpds | ||
| jelmer | vila: r=me | 15:26 |
| vila | jelmer: thanks, I'm deploying | 15:26 |
| vila | ha, damn, been interrupted and forgot to answer | 15:26 |
| vila | 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:27 |
| jelmer | vila: I mean, having a global variable that's set to True or False | 15:28 |
| vila | what for ? switch it back to True ? | 15:28 |
| jelmer | yeah | 15:29 |
| vila | 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:30 |
| vila | 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 |
| vila | so in the end, none of the actual calls should survive | 15:31 |
| vila | jelmer: or do you expect such a breakage that we want to come back to a_r_o=True ? | 15:31 |
| jelmer | vila: I'm not really bothered either way :) | 15:32 |
| vila | hmm, looks like lp has or had some transient issues... | 15:32 |
| gypsymauro | 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 |
| gypsymauro | any hint? | 15:32 |
| vila | gypsymauro: hi | 15:35 |
| jelmer | gypsymauro: I think "bzr diff -rbranch:/path/to/master/branch" should tell you what it would change | 15:35 |
| vila | what does 'bzr missing' says ? | 15:35 |
| gypsymauro | is says that I've two extra revision (and is true, i done some ci --local) | 15:37 |
| vila | any uncommitted changes ? | 15:38 |
| gypsymauro | the bzr diffs displays me 29645 lines.. | 15:38 |
| jelmer | gypsymauro: in that case it shouldn't change your working tree, although it will change your local commits to be pending merges | 15:39 |
| gypsymauro | vila: what do u mean? I committed locally, only this , how can I now commit to the remote repository? | 15:40 |
| jelmer | gypsymauro: if you run "bzr up" and then "bzr commit" that will commit your changes to the local repository | 15:41 |
| jelmer | argh | 15:41 |
| jelmer | s/local/remote/ | 15:41 |
| gypsymauro | jelmer: and this for sure doesn't change anything in my local repository? (the update term scares me :) | 15:48 |
| jelmer | 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:49 |
| jelmer | 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:50 |
| gypsymauro | jelmer: doh.. | 15:52 |
| gypsymauro | bzr conflicts | 15:52 |
| gypsymauro | 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:52 |
| gypsymauro | damn.. it creates a lot of .BASE .OTHER and .THIS file... | 15:53 |
| gypsymauro | it's a nightmare.. | 15:58 |
| jelmer | gypsymauro: ouch, that sucks :( | 15:59 |
| fullermd | I keep wishing we'll just squirrel ci --local away somewhere deep hidden... | 15:59 |
| jelmer | gypsymauro: you had local commits that added foo/bar ? | 15:59 |
| jelmer | fullermd: yeah, me too. I think we should just get rid of them. | 16:00 |
| gypsymauro | damn... | 16:00 |
| gypsymauro | if I recover from a backup my foo/bar? this resolves my conflicts? | 16:01 |
| gypsymauro | or I've to merge manually ? | 16:01 |
| jelmer | gypsymauro: I suspect "bzr resolve --take-other" might fix this for you, but I'm not entirely sure | 16:02 |
| vila | gypsymauro: sry was called elsewhere | 16:02 |
| === beuno is now known as beuno-lunch | ||
| vila | gypsymauro: if you have conflicts, a merge already occured (triggered by update) | 16:03 |
| gypsymauro | jelmer: uhm i suppose the .THIS version is the correct | 16:03 |
| vila | gypsymauro: how conflicts ? | 16:03 |
| vila | gypsymauro: how many conflicts ? | 16:03 |
| gypsymauro | vila: 47 | 16:03 |
| gypsymauro | wc -l | 16:04 |
| vila | hmm | 16:04 |
| vila | !paste | 16:04 |
| ubot5 | 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 |
| vila | gypsymauro: can you pastebin the output of 'bzr conflicts' ? | 16:04 |
| vila | gypsymauro: and 'bzr st' | 16:04 |
| gypsymauro | http://pastebin.com/TCYWVLy6 | 16:05 |
| gypsymauro | and http://pastebin.com/nWPRg99U | 16:06 |
| === deryck is now known as deryck[lunch] | ||
| jelmer | Riddell: still there? | 16:08 |
| jelmer | Riddell: another sync is bug 837956 | 16:08 |
| ubot5 | 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:08 |
| vila | gypsymauro: :-/ Looks like you added files that were also added remotely... | 16:09 |
| vila | gypsymauro: but you said 'bzr missing' only reported local revisions right ? | 16:09 |
| jelmer | 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 |
| jelmer | vila: I *think* | 16:10 |
| vila | jelmer: but we stop as soon as we get a conflict (or was it discussed but not implemented ?) | 16:10 |
| vila | gypsymauro: what bzr version are you using ? | 16:10 |
| jelmer | vila: sure, but he was up to date | 16:10 |
| fullermd | The usual cause of kerfufflage there is when you have uncommitted changes as _well_ as local commits. | 16:10 |
| vila | fullermd: I asked for uncommitted changes first ;) | 16:11 |
| fullermd | 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 |
| gypsymauro | Bazaar (bzr) 2.1.2 | 16:11 |
| vila | gypsymauro: ouch, OS/version ? | 16:11 |
| gypsymauro | debian squeeze | 16:12 |
| jelmer | Riddell: and I have a bzr upload waiting for approval | 16:13 |
| Riddell | jelmer: waiting where? | 16:13 |
| vila | gypsymauro: rrright, let's do it the old fashion way then | 16:13 |
| vila | gypsymauro: do you have the qbzr plugin installed ? | 16:14 |
| jelmer | Riddell: waiting for approval by an archive admin; looks like it was just rejected | 16:15 |
| ScottK | jelmer: I rejected 2ubuntu1. You just uploaded 3ubuntu1. | 16:15 |
| ScottK | At this point it needs to wait until after Oneiric Beta 1 is done. | 16:16 |
| jelmer | ScottK: ah, my mistake. Thanks! | 16:16 |
| ScottK | (I also pinged you on #ubuntu-devel about it ... | 16:16 |
| ScottK | ) | 16:16 |
| gypsymauro | vila: now yes :D | 16:17 |
| vila | gypsymauro: great, try 'bzr qlog' | 16:17 |
| jelmer | ScottK: yep, not sure why I missed that | 16:18 |
| gypsymauro | vila: ok | 16:18 |
| vila | 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 |
| gypsymauro | i've two light blue circles | 16:18 |
| vila | gypsymauro: 'bzr revno' ? | 16:19 |
| gypsymauro | ok the last is 14 | 16:19 |
| vila | do you see a 'pending merges' label ? | 16:19 |
| gypsymauro | yes | 16:19 |
| gypsymauro | 14.1.2 | 16:19 |
| gypsymauro | and another blue 14.1 | 16:20 |
| gypsymauro | 14.1.1 | 16:20 |
| vila | exellent, that's your local commits | 16:20 |
| gypsymauro | without the pending msg | 16:20 |
| gypsymauro | exactly | 16:20 |
| vila | justasec | 16:20 |
| vila | gypsymauro: roughly, we will create a branch from remote and 'merge ../with-conflicts -r14.1.2' | 16:22 |
| gypsymauro | vila: I'm in ur hands... take care about 2 weeks of work :) I've a backup btw | 16:25 |
| vila | gypsymauro: i.e.: in a new directory: bzr branch <remote> recover ; cd recover ; bzr merge <conflicts> -r14.1.2 | 16:26 |
| gypsymauro | vila: doing the first step | 16:29 |
| vila | gypsymauro: no worries, try (above the dir with conflicts) : bzr branch <conflicts> -r14.1.2 my-precious | 16:29 |
| gypsymauro | what do u mean with <conflicts> | 16:29 |
| vila | your checkout dir | 16:30 |
| gypsymauro | you mean where I've my precious sources? | 16:30 |
| vila | I call it <conflicts> to denote that's the one where the conflicts are *now* | 16:30 |
| vila | hehe, yeah, except you've committed them, so they are safe in a revision in the repo | 16:30 |
| gypsymauro | my local repo | 16:31 |
| vila | yes | 16:34 |
| fullermd | Wait, he's committed the conflicted merge? | 16:35 |
| vila | no | 16:35 |
| === deryck[lunch] is now known as deryck | ||
| fullermd | So how would the local commits (now pending merges) have a dotted revno available? | 16:35 |
| vila | can't commit with conflicts | 16:35 |
| fullermd | Wouldn't you need to go by revid? | 16:36 |
| vila | hlol, good point, we need the revids | 16:36 |
| vila | gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit | 16:37 |
| * fullermd is a cheenius sometimes. | 16:37 | |
| vila | fullermd: thanks for the heads-up | 16:38 |
| fullermd | vila: You'll get my bill in the mail ;p | 16:38 |
| vila | hehe, as usual, don't forget to bill for some more goats too, say half a dozen ? | 16:38 |
| gypsymauro | vila: ok now I try , and all that .THIS and .OTHER will disappears? | 16:45 |
| vila | gypsymauro: so you've got a copy of your remote branch ? | 16:45 |
| gypsymauro | yes | 16:45 |
| gypsymauro | I don e bzr branch <remote> recover ; cd recover ; | 16:46 |
| gypsymauro | steps | 16:46 |
| gypsymauro | now I'm doing that bzr merge <conflicts> -r14.1.2 | 16:46 |
| vila | go there and do 'bzr merge ../<conflicts -r<revid>' | 16:46 |
| vila | gypsymauro: as fullermd pointed out the revno is probably not available (qlog lied ;) | 16:46 |
| vila | so you need, | 16:46 |
| vila | gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit | 16:46 |
| gypsymauro | bzr: ERROR: Requested revision: u'14.1.2' does not exist in branch: | 16:48 |
| gypsymauro | doh... | 16:48 |
| vila | right, fullermd was :) | 16:48 |
| * fullermd buffs his nails and looks important. | 16:49 | |
| vila | gypsymauro: qlog *pretends* the revnos exist, but they don't until you commit | 16:49 |
| gypsymauro | I'm getting lost | 16:49 |
| vila | gypsymauro: just go back to qlog, select 14.1.2 and it should display a pane with some details on the revision | 16:50 |
| gypsymauro | which detail do u need? | 16:50 |
| vila | gypsymauro: one of them is the revid which is used internally and in some recovery contexts, normally you only deal with revnos (14.1.2 is a so-called dotted revno) | 16:51 |
| vila | gypsymauro: a revid is ugly, except it probably has your id/email in it so it's not that ugly ;) | 16:52 |
| gypsymauro | vila: it's something like email@....bla bla bla? | 16:52 |
| gypsymauro | ah ok | 16:52 |
| gypsymauro | so -rrevid? | 16:52 |
| vila | yup, pedantically -rrevid:email@bla bla bla | 16:52 |
| gypsymauro | All changes applied successfully. | 16:52 |
| vila | bzr st ? | 16:53 |
| vila | you should get something that looks like a summary of your two local commits | 16:53 |
| vila | ditto for 'bzr diff' | 16:53 |
| gypsymauro | vila: well where is applyed the merge? | 16:55 |
| vila | gypsymauro: what does 'bzr st' says ? It should finish with 'pending revisions' blah | 16:55 |
| vila | s/finish/ends/ | 16:56 |
| gypsymauro | I mean in the recover folder I've the old version of files | 16:56 |
| vila | you did the merge there right ? | 16:56 |
| gypsymauro | pending merge tips: (use -v to see all merge revisions) | 16:56 |
| gypsymauro | yes of course | 16:57 |
| vila | so you just merged the last 'commit --local' you did in <conflicts> | 16:57 |
| vila | gypsymauro: there was no uncommitted changes when did update in <conflicts> right ? | 16:57 |
| gypsymauro | no wait I didnt' made the last commit --local I tried to commit directly on the remote | 16:58 |
| vila | argh | 16:59 |
| vila | >< | 16:59 |
| gypsymauro | I forgot the --local command.. | 16:59 |
| gypsymauro | if I move all the .THIS file to the original file? | 16:59 |
| vila | the fatal trap :-( | 16:59 |
| sidnei | what's that really shiny github-like site for bzr hosting which i can never remember the name? | 17:00 |
| vila | well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS | 17:00 |
| vila | gypsymauro: well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS | 17:00 |
| gypsymauro | vila: is the .THIS | 17:01 |
| jelmer | sidnei: http://wiki.bazaar.canonical.com/Hosting | 17:01 |
| jelmer | sidnei: I'm not sure which one of those you mean | 17:01 |
| vila | gypsymauro: two choices from here | 17:02 |
| vila | gypsymauro: either you go back to <conflicts> and resolve the conflicts there OR | 17:02 |
| sidnei | jelmer, might be mergebox, but it does not look like what i remember | 17:02 |
| sidnei | the name i remember was codemaster or something | 17:02 |
| vila | gypsymauro: you go to recover and do: 'bzr revert --no-backup; bzr pull --overwrite -rrevid:<revid of 14.1.2>' | 17:03 |
| gypsymauro | vila: what does that? | 17:03 |
| gypsymauro | vila: uhm i think is better to resolve conflicts | 17:04 |
| vila | gypsymauro: the first one is going forward resolving the conflicts | 17:04 |
| gypsymauro | yeah yeah I mean the second | 17:04 |
| gypsymauro | but if is it what I suppose I prefer the second :) | 17:04 |
| gypsymauro | the first sorry | 17:04 |
| vila | gypsymauro: the second one is stepping back, restore your working tree as it was when you miss --local | 17:05 |
| vila | gypsymauro: it all depends on what the conflicts are which is hard for me to judge | 17:05 |
| gypsymauro | vila: just can you help me telling what to do when there is a . THIS .OTHER conflict? | 17:05 |
| jelmer | sidnei: mergebox isn't really shiny | 17:05 |
| gypsymauro | vila: I've to move the .THIS over the original file and then run bzr resolve myfile? | 17:06 |
| vila | gypsymauro: is there a conflict-type topic in 'bzr help topics' ? | 17:06 |
| vila | gypsymauro: that's the general idea, yes | 17:06 |
| jelmer | sidnei: it took me a while to hear about bzr.bz too, it's been there for a long time without anybody knowing | 17:06 |
| vila | gypsymauro: one by one (especially with bzr-2.1 where I don't remember which bugs were still there) | 17:07 |
| vila | gypsymauro: for the record, we have a new series every 6 months and 2.4.0 has just been released so 2.1 is 18 months old | 17:07 |
| gypsymauro | vila: ok, mv or cp? and then the generated files wil disappear? (.this .other..) | 17:07 |
| vila | gypsymauro: both should work | 17:08 |
| gypsymauro | doh... bzr: ERROR: Could not acquire lock | 17:09 |
| gypsymauro | /.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable | 17:09 |
| vila | gypsymauro: 'bzr break-lock' | 17:09 |
| vila | no wait ! | 17:09 |
| vila | quit qlog first | 17:09 |
| gypsymauro | who is locking that? I've nautilus plugin | 17:09 |
| vila | try again | 17:09 |
| vila | in 2.1, could be qlog, can't remember the details | 17:09 |
| sidnei | jelmer, it totally escapes me now, but i rememember poolie mentioning it in an email, which i can't find. hopefully im not dreaming. it definitely doesn't look like mergebox, unless they rebranded. | 17:10 |
| sidnei | for worse that is ;) | 17:10 |
| jelmer | sidnei: :) | 17:10 |
| gypsymauro | vila: tanx for all ur help :) last question | 17:12 |
| gypsymauro | how to solve the Conflict: can't delete foo/bar because it is not empty. Not deleting = | 17:12 |
| gypsymauro | ? | 17:12 |
| vila | right, so, what is inside foo.bar ? | 17:12 |
| gypsymauro | other folders | 17:13 |
| vila | gypsymauro: which are also involved in conflicts ? | 17:13 |
| === beuno-lunch is now known as beuno | ||
| jam | sidnei: sloecode? | 17:21 |
| jam | https://launchpad.net/sloecode | 17:21 |
| jam | not really a website, though | 17:21 |
| sidnei | jam, nope. the site i remember had a black background and some shiny polished metal like images, very apple-y. oh well :/ | 17:23 |
| jam | sidnei: I remember a pastebin sort of website | 17:26 |
| jam | sidnei: http://chopapp.com/# | 17:26 |
| jam | but it isn't bzr | 17:27 |
| jam | elliot just mentioned http://bzr.bz | 17:30 |
| vila | gypsymauro: so you're back on track ? | 17:31 |
| gypsymauro | I hope | 17:31 |
| gypsymauro | tank you vila | 17:31 |
| vila | gypsymauro: no you know why fullermd.... | 17:31 |
| gypsymauro | I'm sorry but my bzr skills ar so low :( I need to study it again! | 17:32 |
| vila | fullermd: I just can't believe you went out/in just around the time we needed to fix gypsymauro issues | 17:32 |
| gypsymauro | fullermd: :D | 17:32 |
| vila | fullermd: you're just faking those connections msgs right ? | 17:32 |
| gypsymauro | you are great guys | 17:32 |
| gypsymauro | tanx tanx tanx again | 17:32 |
| gypsymauro | really | 17:32 |
| gypsymauro | yuhu! | 17:32 |
| vila | gypsymauro: well, as fullermd was hinting, --local is.... unusual | 17:32 |
| fullermd | My spidey sense made me do it. | 17:32 |
| vila | gypsymauro: enjoy ! | 17:33 |
| vila | and on that positive note, I will join family for dinner ;) | 17:33 |
| fullermd | Need to me break something else so you can get out of that? ;) | 17:34 |
| vila | fullermd: so, just read the logs, you went out when he realized he... forgot --local... | 17:34 |
| TA1CZ | hello | 17:35 |
| TA1CZ | may I ask something about Bazaar explorer for windows. | 17:35 |
| TA1CZ | Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir | 17:36 |
| TA1CZ | Connected (version 2.0, client Twisted) | 17:36 |
| TA1CZ | bzr: ERROR: [Error 5] Access is denied: 'c:\\users\\user\\appdata\\local\\temp\\tmpiawygw.pag' | 17:36 |
| TA1CZ | I get this error... | 17:36 |
| jelmer | TA1CZ: pag rather than pack? | 17:37 |
| jam | TA1CZ, jelmer: I believe that is a failure of pageant | 17:37 |
| TA1CZ | is there any suggestion? | 17:37 |
| jam | try re-setting up putty | 17:37 |
| jam | or making sure your key is set up, etc. | 17:37 |
| jam | or just stop pageant entirely | 17:38 |
| TA1CZ | I used puttygen for generating the keys.. | 17:38 |
| TA1CZ | both private and public.. | 17:38 |
| jam | TA1CZ: the issue with $TEMP is usually while communicating to the local pageant server | 17:38 |
| jam | it doesn't really matter what the keys are | 17:38 |
| TA1CZ | the putty agent is also working on the right side of windows | 17:39 |
| TA1CZ | I added private.ppk key | 17:40 |
| jam | TA1CZ: try stopping the local putty agent for a bit | 17:40 |
| TA1CZ | o.k. | 17:40 |
| TA1CZ | Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir | 17:41 |
| TA1CZ | Connected (version 2.0, client Twisted) | 17:41 |
| TA1CZ | bzr: ERROR: Connection error: Unable to authenticate to SSH host as | 17:41 |
| TA1CZ | karen-denki@bazaar.launchpad.net | 17:41 |
| TA1CZ | supported auth types: ['publickey'] | 17:41 |
| TA1CZ | Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir | 17:41 |
| TA1CZ | Connected (version 2.0, client Twisted) | 17:41 |
| TA1CZ | bzr: ERROR: Connection error: Unable to authenticate to SSH host as | 17:41 |
| TA1CZ | myID@bazaar.launchpad.net | 17:41 |
| TA1CZ | supported auth types: ['publickey'] | 17:41 |
| jam | TA1CZ: is the user-id correct? | 17:41 |
| TA1CZ | the result is like this when I stop the agent! | 17:41 |
| jam | (just to start from the beginning) | 17:41 |
| TA1CZ | o.k. | 17:42 |
| jam | We can't auth via public-key because you don't have the key agent around, and putty uses a different key | 17:42 |
| jam | format by default | 17:42 |
| jam | .ppk vs id_rsa.pub | 17:42 |
| jam | however, start putty again | 17:42 |
| jam | and I think you might see a $TEMP failure | 17:42 |
| jam | unfortunately, I've seen this on one machine (our ec2 build host) only, and haven't been able to reproduce it | 17:42 |
| TA1CZ | which putty? | 17:42 |
| jam | on my home machine, etc. | 17:43 |
| jam | "pageant" | 17:43 |
| jam | I should have been clearer | 17:43 |
| TA1CZ | :( | 17:44 |
| jam | TA1CZ: it is failing with TEMP again? | 17:45 |
| jam | TA1CZ: what os version/ | 17:45 |
| jam | ? | 17:45 |
| TA1CZ | windows 7 | 17:45 |
| TA1CZ | so could you say step by step what should I must do is you dont mind? | 17:46 |
| TA1CZ | because I totally confused..:( | 17:46 |
| TA1CZ | is this relevant with authentication.conf? | 17:48 |
| jam | TA1CZ: not really. I think I can work out a workaround for you | 17:49 |
| jam | you need to run puttygen again | 17:49 |
| TA1CZ | o.k. now I am running puttygen | 17:49 |
| jam | (note, I'm discussing it from memory, and I'm not logged into Windows right now, but I'll do my best) | 17:49 |
| jam | you should be able to load the private.ppk that you created | 17:49 |
| vila | jam: nice mail about fdatasync, make check timing patch landed, first log rsync'ed, the stamps are lost in the noise but nothing a crude parser can't decipher, dinner time here but you'll got a parser first thing I touch this keyboard again ;) Unless you beat me to it that is :-p | 17:50 |
| * vila really goes to dinner now ;) | 17:50 | |
| jam | vila: for now, I'm focusing more on test cases individually. If I have 'pqm-stdout.gz' it has the subunit timestamp stream | 17:51 |
| jam | so 'date' doesn't really matter. | 17:51 |
| TA1CZ | o.k. when the putty gen is on the stage.. I load the private.ppk key by pressing Load button.. it is loaded. | 17:51 |
| vila | jam: great | 17:51 |
| jam | TA1CZ: Now you want to export the key into the "openssh" format | 17:51 |
| jam | which you've already done a bit of, since you uploaded the openssh public key form to launchpad | 17:51 |
| vila | jam: spurious spikes for tests have been encountered when dealing with socket leaks, cycle checks from mgz and so on, you may want to give a spin merging it into one of your born-to-not-land branches | 17:53 |
| jam | vila: could be interesting. But I believe Martin also indicated the machine is shared | 17:54 |
| jam | so if they're doing stuff at the same time, its gonna get whacky | 17:54 |
| jam | the test suite was 2.5hrs for a couple of runs, then 3.5 for the other times of the day | 17:54 |
| vila | jam: sure, primary cause, but 3x... | 17:54 |
| jam | vila: just the source of variability | 17:54 |
| jam | primary cause is still probably fdatasync, which is another failed log I'm looking at | 17:55 |
| jam | but there seems to be slightly more than that as a real cause, and then hard-to-measure-because-of-system variability | 17:55 |
| jam | 2.3 can finish as fast as 45min, but took 1:45 last night | 17:55 |
| jam | etc. | 17:55 |
| === med_out is now known as medberry | ||
| === medberry is now known as med_out | ||
| AuroraBorealis | does bzr hash files when it does a commit? | 23:17 |
| Peng | AuroraBorealis: Hash in what way? | 23:26 |
| AuroraBorealis | just wondering if this statement is true for bazaar as well | 23:26 |
| AuroraBorealis | context: kernel.org was compromised recently | 23:26 |
| Peng | It was? | 23:27 |
| AuroraBorealis | http://pastebin.com/8CKqBPQC | 23:27 |
| AuroraBorealis | yeah it was | 23:27 |
| AuroraBorealis | (see https://www.kernel.org/, first news item) | 23:28 |
| Peng | Yeah. | 23:28 |
| AuroraBorealis | so basically, can someone change something without bazaar knowing about it? | 23:28 |
| Peng | Bazaar doesn't uses hashes as revision IDs, but it does hash everything. | 23:28 |
| AuroraBorealis | so if someone did do that you would be able to detect it if you rechecked the repo or something | 23:28 |
| Peng | I'm not quite awake enough to think about this problem. | 23:29 |
| AuroraBorealis | xD | 23:30 |
| AuroraBorealis | i dont know enough about the actual structure of the repo itself to figure it out | 23:30 |
| Peng | It would most definitely be possile to verify it somehow, but I don't know how easily. | 23:30 |
| AuroraBorealis | isn't there a --recheck option | 23:32 |
| === micahg_ is now known as micahg | ||
| Peng | Yes. | 23:33 |
| mathrick | hiya | 23:34 |
| AuroraBorealis | would be an interesting test to see if someone could modify the repo and see if said recheck catches it. | 23:34 |
| mathrick | http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html#creating-your-own-copy-of-another-branch <-- why does it even talk about init-repo? | 23:34 |
| AuroraBorealis | as modifiying the repo malitiously would be bad. | 23:34 |
| mathrick | without explaining what it is and why it is there? | 23:34 |
| mathrick | that's really outside of the scope of a mini tutorial, IMHO, and should be removed | 23:34 |
| AuroraBorealis | file a bug about it | 23:35 |
| AuroraBorealis | it is probably overkill for said mini tutorial. | 23:36 |
| Peng | AuroraBorealis: "bzr check" would certainly find ordinary corruption, but a clever hacker would modify all the hashes, no? That would probably blow up pretty quickly as people with uncompromised copies of the repo interacted with it, but it's not something I have any knowledge about. | 23:37 |
| AuroraBorealis | well what that git comment said was that all the future commits require that all the previous commits are correct | 23:38 |
| AuroraBorealis | although i don't really know how that works, but another example is with bitcoin blocks, each block has the hash to the previous block, creating a 'chain', so you can't modify a block or else the hashes won't match up | 23:38 |
| Peng | But it can't actually verify that the hashes of all previous revisions are *correct* in every operation. | 23:41 |
| Peng | Can it? | 23:41 |
| AuroraBorealis | well true. | 23:41 |
| AuroraBorealis | if the person manages to maliciously modify commit 100 for example | 23:42 |
| AuroraBorealis | and manages to change the hashes for 1-99 then i guess it would be undetectable | 23:42 |
| AuroraBorealis | but i'm sure something else would break... | 23:42 |
| AuroraBorealis | like a merge would show it as a conflict | 23:43 |
| AuroraBorealis | and thats how bitcoin does it as well, is that its a p2p network, so you would have to get everyone to have the malicious block or else you would realize that its wrong | 23:44 |
| Peng | Might be an uncommonly-modified file. | 23:44 |
| Peng | Like I said, I'm too tired to think about this. | 23:44 |
| AuroraBorealis | xD | 23:44 |
| AuroraBorealis | well wake up | 23:44 |
| Peng | Worst case, even without any hashing, you can obviously do a diff between a questionable copy and a known-good copy. | 23:44 |
| AuroraBorealis | yeah, even if its uncommonly modified, if anyone had branched the good copy and tried to merge it back in, it would show up as a conflict | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!