| jelmer | mwhudson: looks like it; and an API breakage in dulwich as we currently use an integer offset | 00:00 |
|---|---|---|
| mwhudson | jelmer: you could use a float i guess, then you have a negative zero :-) | 00:01 |
| mwhudson | (not serious) | 00:01 |
| jelmer | actually, I think we might already be using a float | 00:01 |
| jelmer | mwhudson: can you perhaps re-review https://code.edge.launchpad.net/~lifeless/bzr-git/bug-526133/+merge/22986 ? | 00:04 |
| mwhudson | jelmer: i think i already merged it in fact | 00:04 |
| mwhudson | jelmer: the diff is empty, in any case | 00:05 |
| jelmer | mwhudson: oh | 00:05 |
| jelmer | mwhudson: ah, you're right | 00:06 |
| jelmer | I guess launchpad didn't pick that up because it was proposed for merging into lp:bzr-git | 00:06 |
| mwhudson | does anyone know where the | 00:43 |
| mwhudson | /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path | 00:43 |
| mwhudson | messages are coming from? | 00:43 |
| millun | hi | 00:43 |
| millun | is it ok if i add like 4000 .xml files (to a colocated branch) that i will never modify? | 00:44 |
| beuno | millun, what do you mean by "is it ok"? | 00:47 |
| millun | is it a good practice? :) | 00:47 |
| millun | the thing is that i don't know how to untick so many files in bzr gui app | 00:47 |
| igc | morning | 00:48 |
| millun | (at once) | 00:48 |
| lifeless | mwhudson: I smell eggs | 00:52 |
| spiv | Good morning. | 00:59 |
| lifeless | mornink! | 01:00 |
| spm | lifeless: I trust you also smell bacon with those eggs, and you merely left off that part of the description because: 1. it's implied and 2. you're in too big a hurry to eat the bacon and hence the additional description typing time cuts into the bacon eating time. ?? | 01:31 |
| cody-somerville | and... how do you smell cooked egg? | 01:40 |
| spm | cody-somerville: with your nose? :-) | 02:00 |
| abadger1999 | mwhudson: Got loggerhead working with mod_wsgi -- needed this patch https://bugs.launchpad.net/loggerhead/+bug/557737 | 02:01 |
| ubottu | Launchpad bug 557737 in loggerhead "Content length needs to be a byte string" [Undecided,New] | 02:01 |
| abadger1999 | The error from last night is some problem specific to firefox I haven't tracked it down yet but it's gone away for now. | 02:02 |
| lifeless | spm: no, python eggs. | 02:02 |
| mwhudson | abadger1999: ! | 02:03 |
| lifeless | wow | 02:03 |
| mwhudson | at least the fix is simple | 02:03 |
| lifeless | mwhudson: will you apply this ? | 02:03 |
| abadger1999 | yeah | 02:04 |
| mwhudson | lifeless: i can't see why not | 02:04 |
| lifeless | mwhudson: ok cool | 02:04 |
| lifeless | otherwise I would be happy to | 02:04 |
| mwhudson | lifeless: feel free | 02:05 |
| Peng | Rock paper scissors for who gets to land the trivial patch! | 02:05 |
| Peng | I pick paper. | 02:05 |
| abadger1999 | :-) | 02:05 |
| Peng | If someone else does it, don't forget --author. :D | 02:05 |
| Peng | And --fixes! I always forget --fixes... | 02:05 |
| Peng | Wait wait, lp:~toshio? Don't you have some other branch up for review from like...2008? :D | 02:06 |
| Peng | https://code.edge.launchpad.net/~toshio/loggerhead/mod_wsgi/+merge/1168 Yeah, 2008. Nice. | 02:07 |
| abadger1999 | Peng: yeah -- it's work on doing this same thing from a long time ago. | 02:07 |
| abadger1999 | Peng: Things have progressed on all fronts :-) This is the only byte string problem I found this time around. | 02:07 |
| Peng | Ah, right, it ran into Unicode issues and then got dropped. | 02:07 |
| Peng | abadger1999: Nice. | 02:07 |
| * abadger1999 crosses fingers | 02:08 | |
| Peng | Seriously, who's landing the patch? | 02:08 |
| lifeless | Its landed. | 02:09 |
| Peng | OK. | 02:09 |
| abadger1999 | Thanks! | 02:09 |
| Peng | Eh. Does Loggerhead use Fix Committed or Fix Released for this? | 02:11 |
| lifeless | Peng: In the absence of clear docs, it can get by with the bzr idioms. | 02:12 |
| Peng | :D | 02:13 |
| lifeless | besides which | 02:15 |
| lifeless | the solution for needing 'fix committed in trunk' is to release often. | 02:15 |
| Peng | Naw, releasing is silly. Just make users run from version control. | 02:16 |
| lifeless | it would be cool if pulling into bzrlib upgraded the bzrlib doing the pull as it pulled | 02:16 |
| Peng | And then you get bizarre API compatibility issues. I've had that happen. | 02:17 |
| Peng | I imagine reload()ing half of bzrlib would make a huge mess. | 02:18 |
| lifeless | don't forge the pyrex | 02:18 |
| spiv | Peng: reload() isn't sufficient on its own anywy | 02:19 |
| Peng | If you like pain, work on Loggerhead's caching or hpss optimization, not this. :P | 02:19 |
| Peng | (Or try wearing a corset. Sorry.) | 02:20 |
| mkanat | mwhudson: Did you see my question on the hang bug? | 02:21 |
| mwhudson | mkanat: yeah, but i don't have an answer for you | 02:21 |
| mkanat | mwhudson: Okay. | 02:21 |
| Peng | Eh? Link? | 02:21 |
| mkanat | mwhudson: BTW, part of my contract is a retainer for me to do bug-fixing on an hourly basis for other bugs. | 02:22 |
| Peng | (NMot that I'll have an answer either.) | 02:22 |
| lifeless | mkanat: cool | 02:22 |
| mkanat | mwhudson: I don't know if you have to run it by Francis or not, but personally I'm happy to look at and fix any bug. I know there are some that are hitting us pretty hard at Mozilla. | 02:22 |
| mkanat | lifeless: Cha. | 02:22 |
| mkanat | lifeless: Did you see the bzr bug I filed yesterday? | 02:22 |
| lifeless | possibly | 02:23 |
| mwhudson | mkanat: there have been a couple of further crashes, i should post them to the bug... | 02:23 |
| mkanat | lifeless: The one about CVS having better merging behavior than bzr. | 02:23 |
| lifeless | oh | 02:23 |
| lifeless | I saw it go by | 02:23 |
| lifeless | I haven't looked into it | 02:23 |
| lifeless | uhm | 02:23 |
| Peng | CVS does something better? Oh, that's terrible. | 02:23 |
| lifeless | is there a SSCCE with it ? | 02:23 |
| mkanat | lifeless: SSCCE? | 02:23 |
| mkanat | lifeless: Oh, yes. | 02:24 |
| lifeless | Peng: usually when we investigate merge issues it turns out to be a valid-conflict that cvs punts on | 02:24 |
| mkanat | lifeless: There's a series of commands that will reproduce it with the same content from both bzr and CVS. | 02:25 |
| lifeless | mkanat: have you tried --weave? | 02:25 |
| mkanat | lifeless: Yeah, I tried all three. | 02:25 |
| mkanat | lifeless: IIRC, there was 0 difference. | 02:25 |
| mkanat | lifeless: Okay, there's a tiny difference. 81 conflicts with LCA, 105 with merge3, and 108 with weave. | 02:27 |
| mkanat | Oh, though 83 with --weave --reprocess. | 02:27 |
| mkanat | (Same with --merge3 --reprocess.) | 02:27 |
| mkanat | Here's one of the "conflicts": http://pastebin.org/140807 | 02:28 |
| * spm waves hi to mkanat, passing thru | 02:29 | |
| mkanat | Hey spm. :-) | 02:29 |
| lifeless | mkanat: what was the base | 02:30 |
| lifeless | (--show-base) | 02:30 |
| mkanat | lifeless: The top one. | 02:30 |
| lifeless | no, thats orig | 02:31 |
| mkanat | lifeless: http://pastebin.org/140815 | 02:31 |
| lifeless | mkanat: so bzr saw two different inserts | 02:31 |
| mkanat | lifeless: Hmm, maybe it did. | 02:31 |
| lifeless | branch one went from "" to "foo\n" | 02:31 |
| lifeless | and branch two went from "" to "bar\n' | 02:31 |
| mkanat | lifeless: So why doesn't CVS conflict there? | 02:32 |
| lifeless | how are you doing the merge in CVS ? | 02:32 |
| mkanat | lifeless: cvs up -dP -rBUGZILLA-3_6-BRANCH | 02:32 |
| mkanat | lifeless: That particular conflict is from another nearly identical example to the one in the bug. | 02:32 |
| lifeless | ah | 02:32 |
| lifeless | its not a merge. | 02:32 |
| mkanat | lifeless: Right, it's an upgrade. But bzr behaves the same way with "bzr up" as it does with "bzr merge". | 02:33 |
| lifeless | right | 02:33 |
| lifeless | because its actually merging | 02:33 |
| lifeless | here is what CVS does: | 02:33 |
| * mkanat nods. | 02:33 | |
| lifeless | BASE == 'bzr revision-info' | 02:33 |
| lifeless | ORIG == current tree | 02:33 |
| lifeless | (or THIS == current tree) | 02:33 |
| lifeless | OTHER == -rBUGZILLA-3_6-BRANCH | 02:34 |
| lifeless | so the only things that can conflict with that invocation you are doing are *edits* against the current tree | 02:34 |
| lifeless | the equivalent command in bzr is 'bzr switch' | 02:34 |
| lifeless | (in terms of merge operations) | 02:34 |
| mkanat | lifeless: Ahhh. | 02:35 |
| lifeless | now | 02:35 |
| mkanat | lifeless: You're my hero. | 02:35 |
| lifeless | cvs up -dP -rBUGZILLA-TRUNK_3_6_BASE:BUGZILLA-3_6-BRANCH | 02:35 |
| lifeless | would do something close to bzr merge | 02:35 |
| lifeless | but you need to have a tag that represents the last merge between two CVS branches to be able to do that | 02:36 |
| lifeless | (which hno's most excellent merge scripts for cvs do) | 02:36 |
| * igc out for a few hours | 02:37 | |
| mkanat | lifeless: Oh, um, hmm. | 02:38 |
| mkanat | lifeless: Okay...I suppose I need to figure out how to, say, upgrade a customized Bugzilla 3.4 to Bugzilla 3.6 w/o the conflicts that naturally come from upgrading 3.4 to 3.6. | 02:39 |
| mkanat | lifeless: Ideally, some set of instructions simple enough that I could at some point provide them to clueless end users. | 02:39 |
| lifeless | mkanat: now, all of the above said, we can probably do better here | 02:39 |
| lifeless | in your specific case I mean | 02:39 |
| lifeless | if the conflicts are mostly of the pattern 'new left and new right differ and we always want new right' | 02:40 |
| lifeless | you could write a merge hook to do that automatically | 02:40 |
| mkanat | lifeless: I think it's probably "if both new right and new left try to insert a line, we want new right". | 02:42 |
| mkanat | But otherwise, we want conflicts. | 02:42 |
| lifeless | right | 02:43 |
| lifeless | so, you can (fairly easily) whip up a plugin to do that | 02:43 |
| lifeless | or even prompt per hunk | 02:43 |
| lifeless | mkanat: spiv or I are both familiar with that code and can help you out :) | 02:46 |
| mkanat | lifeless: Okay. :-) | 02:47 |
| mkanat | lifeless: It looks like, for what I want to do, I can also bundle up the customized revisions and merge the bundle into a branch of the newer branch. | 02:47 |
| lifeless | mkanat: yes | 02:47 |
| mkanat | lifeless: It's just going to be confusing to instruct people that they have to do something different depending on whether or not they've customized their local code. | 02:47 |
| lifeless | mkanat: looms might be a good fit for this too, for deployment/customisation separation | 02:48 |
| lifeless | mkanat: if they haven't customized, surely they can just bzr pull ? | 02:48 |
| mkanat | lifeless: Right, or switch. | 02:48 |
| mkanat | lifeless: But if they have, then there's a whole second set of instructions now. | 02:49 |
| mkanat | lifeless: And some people sometimes take over an existing Bugzilla installation and don't know that they've customized. | 02:49 |
| lifeless | ah | 02:50 |
| lifeless | so at least bzr will tell them 'cannot pull' | 02:50 |
| lifeless | :) | 02:50 |
| mkanat | lifeless: Yeah. | 02:50 |
| mkanat | lifeless: But switch would just switch them. | 02:50 |
| lifeless | well, I wouldn't document switch then | 02:51 |
| lifeless | the discussion about switch is most interesting in that it identifies the issue: CVS customisations are not comitted; bzr ones are. | 02:54 |
| mkanat | lifeless: Yeah. | 02:56 |
| mkanat | lifeless: Which is great, and a really nice advantage for us. | 02:56 |
| mkanat | lifeless: I think there's just not yet too much consideration for the "we have a custom local branch of this product and want to upgrade" in the bzr UI. | 02:56 |
| lifeless | a cherrypick merge / rebase on top of the next release should work. | 02:56 |
| mkanat | lifeless: Yeah, bundle/merge works the way that I want. | 02:57 |
| lifeless | Its *interesting* that you have customisations that are so extensive, and manage to conflict so thoroughly with the next release. | 02:57 |
| lifeless | mkanat: bundle won't make any difference to the merge | 02:57 |
| lifeless | mkanat: its the revision range operator - the cherrypick - that is changing what is going on | 02:57 |
| mkanat | lifeless: Yeah, I know, but the bundle worked because I bundled up only the customized revisions. | 02:58 |
| lifeless | mkanat: equally, cd 3.6; bzr merge ../3.4 -r customised..revisions | 02:58 |
| mkanat | lifeless: Except that I'd have to list a whole series of ranges. | 02:58 |
| mkanat | lifeless: Because the branch keeps merging in the upstream branch. | 02:59 |
| lifeless | mkanat: you had to for the bundle, didn't you ? | 02:59 |
| lifeless | mkanat: when you merge upstream, do you do cherrypicks ? | 02:59 |
| mkanat | lifeless: No, I did this: cd bmo-3.4; bzr bundle bzr://bzr.mozilla.org/bugzilla/3.4 > bmo.diff | 02:59 |
| mkanat | lifeless: No, just "bzr merge bzr://bzr.mozilla.org/bugzilla/3.4" | 02:59 |
| lifeless | mkanat: so this is very odd; I wonder if its a bad base selection | 03:00 |
| lifeless | what does bzr show-merge-base report ? | 03:00 |
| mkanat | lifeless: Does that need a plugin? | 03:00 |
| lifeless | no | 03:00 |
| mkanat | bzr: ERROR: unknown command "show-merge-base" | 03:00 |
| lifeless | though I may be misrememberign the command name | 03:00 |
| mkanat | lifeless: I understand why bzr thinks there are conflicts--we often check in slightly different patches to already-diverged branches. | 03:02 |
| lifeless | mkanat: If you have merged the original patch from trunk though | 03:03 |
| lifeless | even if you alter it as you merge | 03:03 |
| lifeless | it shouldn't later conflict | 03:03 |
| mkanat | lifeless: We don't, we check them in separately. | 03:03 |
| lifeless | mkanat: ah! | 03:03 |
| mkanat | lifeless: Also, we're an import from CVS. | 03:03 |
| mkanat | lifeless: So the importer couldn't have known. | 03:03 |
| lifeless | mkanat: if you can commit them once, then merge them around and edit as needed, bzr should do much better | 03:04 |
| mkanat | lifeless: "merge -c" doesn't seem to retain any revision info, though...does it? | 03:04 |
| lifeless | no | 03:04 |
| lifeless | you'd need to do full merges | 03:04 |
| mkanat | lifeless: So -r1..2 ? | 03:05 |
| lifeless | no, that == -c | 03:05 |
| mkanat | lifeless: Okay. But I'm talking about a single patch. | 03:05 |
| lifeless | 'bzr merge branch' | 03:05 |
| mkanat | lifeless: Yeah, we don't want to merge the trunk into a branch. | 03:05 |
| lifeless | yeah we have room to improve there | 03:06 |
| lifeless | mkanat: I thought you said earlier that you merge from the branch repeatedly ? | 03:06 |
| mkanat | lifeless: I think perhaps I should explain everything at once, to make it clearer. | 03:06 |
| mkanat | lifeless: Because I'm talking about two things-- (1) The Bugzilla development process (2) a local customized installation. | 03:06 |
| mkanat | lifeless: For the Bugzilla development process, at any time we have four or five supported branches, including the trunk. | 03:07 |
| mkanat | lifeless: The trunk and the last stable release both get bug fixes. | 03:07 |
| mkanat | lifeless: The older branches get security fixes only. | 03:07 |
| mkanat | lifeless: So, let's pretend there's a security fix that needs to be done for four branches, and it requires a slightly different patch for each. | 03:08 |
| mkanat | lifeless: That means that each patch gets attached to Bugzilla, gets reviewed, and then gets committed individually to each branch. | 03:08 |
| lifeless | mkanat: you can use 'daggy fixes' here | 03:08 |
| lifeless | commit it to the oldest branch | 03:09 |
| lifeless | merge that branch to the next oldest | 03:09 |
| lifeless | changing the patch as you merge, if needed. | 03:09 |
| lifeless | repeat forward | 03:09 |
| mkanat | lifeless: That won't work, either, because we already have 7000 revisions or so. | 03:09 |
| lifeless | mkanat: why not ? | 03:10 |
| mkanat | lifeless: So, for example, right now if I tired to merge 2.22 into 3.0 (both branches are frozen and dead), I'd get conflicts. | 03:10 |
| lifeless | oh, you need to seed it | 03:10 |
| lifeless | cd 3.0 | 03:10 |
| lifeless | bzr merge ../2.22 | 03:10 |
| lifeless | bzr revert . | 03:10 |
| lifeless | bzr st - will show you 2.22 being merged, no file content changes | 03:11 |
| mkanat | lifeless: Hmmm, interesting! | 03:11 |
| lifeless | bzr commit thast | 03:11 |
| lifeless | you may need to do a bzr resolve --all, if you had really pathological conflicts | 03:12 |
| mkanat | lifeless: I'll keep getting conflicts, though, because of things like "bump the version number for the next release". | 03:13 |
| mkanat | lifeless: That is, in the future. | 03:14 |
| pyMynx | can use an ssh key with bzr ? | 03:14 |
| mkanat | lifeless: I'll have to keep seeding the branches; it seems overly complicated. | 03:14 |
| pyMynx | please tell me I can ^^ | 03:14 |
| lifeless | pyMynx: you can | 03:14 |
| pyMynx | lifeless yay! | 03:14 |
| lifeless | mkanat: you don't need to do that process again; when you do a merge, you resolve any conflicts (they should be trivial as you note) and keep going. | 03:14 |
| mkanat | mwhudson: Thanks for those traces, they look much more helpful than the first one. | 03:25 |
| mwhudson | mkanat: i'm glad to hear it | 03:25 |
| mkanat | mwhudson: And those are all hangs, right? Somebody just did a kill -SEGV on it? | 03:25 |
| mwhudson | mkanat: hangs, yeah | 03:26 |
| mkanat | mwhudson: Great, thanks. | 03:26 |
| mwhudson | mkanat: the cores were made with gcore | 03:26 |
| mkanat | mwhudson: Okay. | 03:34 |
| mkanat | mwhudson: Any chance of getting logs from the same time as those traces? | 03:35 |
| mkanat | mwhudson: The first one looks like the server was just overloaded, the second one looks like it's not getting any connections. | 03:35 |
| mwhudson | mkanat: i'll have a rummage | 03:36 |
| mkanat | spm: Are you still around? I was wondering a bit about the setup of codebrowse. | 03:36 |
| spm | mkanat: sure am | 03:36 |
| mkanat | spm: Is there some proxy, like Apache or something, in front of loggerhead for codebrowse? | 03:36 |
| spm | yeah - saw your bug report on that - been meaning to reply, but the last couple of days have been a level of "AAAAAAAAAAAAAAAAAAAAAA" ness | 03:36 |
| spm | 'something' is a good describer.... | 03:37 |
| mkanat | spm: Hahaha, okay. :-) | 03:37 |
| mwhudson | mkanat: bazaar.launchpad.net runs apache | 03:37 |
| mwhudson | mkanat: a prg rewritemap sends certain requests via rewriterule [p] to another host, which runs loggerhead | 03:38 |
| mkanat | mwhudson: PRG RewriteMap? (Not familiar with the terms.) | 03:38 |
| mwhudson | loggerhead makes an xmlrpc call to find out the id of the branch being accessed, and accesses the branch over http at a url based on the id of the branch | 03:38 |
| mkanat | (I am familiar with a RewriteRule [P] though.) | 03:39 |
| spm | what mwh said; it's not a proxy - per-se; but bunches of rewrite rules | 03:39 |
| mwhudson | mkanat: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap | 03:40 |
| spm | no. I lie. it is a proxy. | 03:40 |
| mkanat | mwhudson: Okay. Does that xml-rpc call happen within Paste, or in some code outside of it? | 03:40 |
| mwhudson | mkanat: the section "External Rewriting Program" | 03:40 |
| mwhudson | mkanat: within paste | 03:40 |
| mkanat | Okay. And when you have one of these hangs, all you do is restart loggerhead on the loggerhead host and things work? | 03:40 |
| mwhudson | yeah | 03:40 |
| mwhudson | at least that's my understanding | 03:41 |
| mkanat | spm: Is that accurate? | 03:41 |
| spm | yup; only ever restart loggerhead | 03:41 |
| mkanat | Hmm, okay. | 03:41 |
| spm | well.. not loggerhead. codebounce; but you get the idea | 03:41 |
| mwhudson | mkanat: http://bazaar.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel/annotate/head%3A/launchpad_loggerhead/app.py#L169 <- xml-rpc call | 03:41 |
| mkanat | spm: codebounce? | 03:42 |
| spm | err *codebrowse* oops. slipup there :-P | 03:42 |
| spm | mkanat: at one point we were bouncing it so frequently it *earned* the label 'codebounce' vs it's true name of 'codebrowse' | 03:42 |
| mkanat | spm: lol | 03:42 |
| spm | something about sysadmins, small minds, and easily amused. probably. | 03:43 |
| mkanat | mwhudson: Okay, I will examine the trace more carefully to see if some of the Queue.get calls are actually in a deadlock. | 03:44 |
| mkanat | mwhudson: I might need to write a patch for Paste or Loggerhead to get more logging info; we'll see. | 03:45 |
| spm | mkanat: Oh, I should add. generally whenever we get a 'non responsive' alert; it's from the *local* check. ie, bypassing apache etc and talking directly to codebrowse. | 03:45 |
| mkanat | spm: Oh, hmm, thanks. | 03:45 |
| mwhudson | mkanat: sure thing | 03:45 |
| mwhudson | mkanat: core.14870 seems to be the lru_cache getting damaged bug | 03:47 |
| spm | mwhudson: I don't believe you've seen our other derogatory name for codebrowse? codebbbbbbbbbbounce (like the bbbbbbbbb Berrocca advert) fyi. :-) | 03:48 |
| mkanat | mwhudson: Okay. So that's bzr's issue and not ours, then, yeah? | 03:49 |
| mwhudson | mkanat: uncelar | 03:49 |
| mkanat | mwhudson: Okay. | 03:49 |
| mkanat | mwhudson: So the one where we're all in sem_wait is the one I'm working on. | 03:49 |
| mwhudson | mkanat: which time was that one?\ | 03:50 |
| mwhudson | mkanat: also in the launchpad-loggerhead glue is some magic that kills threads that have been inactive for 300 seconds | 03:51 |
| mkanat | mwhudson: So if you kill the thread that has the lock and it never releases the lock.... | 03:53 |
| mwhudson | mkanat: the kill appears as an exception being raised | 03:53 |
| mkanat | mwhudson: Okay. So provided that Queue.py is written properly, it should have a finally. | 03:53 |
| mwhudson | yeah, it doesn't cause a deadlock, just masses of exceptions | 04:00 |
| lifeless | spiv: do you know if vila had gotten anywhere on the 'merge deletes a directory with ignored files causes conflicts' case ? | 04:12 |
| spiv | lifeless: not sure, but not afaik | 04:17 |
| spiv | lifeless: hopefully the relevant bug report has the latest info | 04:18 |
| spiv | lifeless: it'd be lovely if he has, though :) | 04:18 |
| lifeless | and the other is a stable monotonic timescale. Of course then you'd | 04:20 |
| lifeless | bah | 04:28 |
| lifeless | middle button fail sorry | 04:28 |
| lifeless | ok this is weird | 05:50 |
| lifeless | mwhudson: :!bzr push | 05:50 |
| lifeless | Using saved push location: bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/apport | 05:50 |
| lifeless | bzr: ERROR: Cannot lock LockDir(lp-67241552:///~lifeless/bzr/apport/.bzr/branchlock): Transport operation not possible: readonly transport | 05:50 |
| mwhudson | lifeless: is it a mirrored branch? | 05:54 |
| lifeless | How can I tell ? | 05:54 |
| lifeless | ah, yes. | 05:54 |
| lifeless | thanks | 05:54 |
| lifeless | terribly confusing | 05:54 |
| === defn is now known as xmlrpc | ||
| mwhudson | there's a fairly recent bug report about that | 05:54 |
| === xmlrpc is now known as defn | ||
| Peng | Hehe. The first time someone ran into that, we almost woke up a losa. :D | 06:03 |
| igc | back | 06:26 |
| lifeless | spm: hey, is there a tool for sensibly benching LAN configurations ? | 07:10 |
| spm | lifeless: the general answer is "yes" - if at a cost; but more precisely - to do what? achieve what? | 07:11 |
| spm | as in lan layout configs? down at the switch h/w layers? | 07:11 |
| lifeless | I have a gigbit switch at home | 07:11 |
| lifeless | and two machines that have negotiated gig links | 07:11 |
| spm | but you're seeing 10mb/s throughtput? :-) | 07:11 |
| lifeless | but wgettting a 4GB file from one to the other is peakign at 24MB/s | 07:12 |
| lifeless | its writing to /dev/null | 07:12 |
| lifeless | and the file is in cache on the server (iotop shows no activity) | 07:12 |
| lifeless | therefore something is wrong | 07:12 |
| spm | +1 | 07:12 |
| lifeless | I should be able to push 100MB or so on such a full duplex connection | 07:13 |
| lifeless | now, I can go through a tedious checklist. | 07:13 |
| spm | http://en.wikipedia.org/wiki/Iperf is one istr using... (still chasing links/names) | 07:13 |
| lifeless | but I was wondering if, someone has written something to just 'figure it out'(tm) | 07:13 |
| spm | Ahh yes. via nlanr, they had a few funky tools. | 07:13 |
| spm | so the idea with iperf and friends is to minimise the whatsits right down to the bone - so *really* max the connection; bypassing eg apache/wget etc | 07:14 |
| lifeless | right | 07:14 |
| spm | I was getting just shy of theroretical max on a 100mbs network in '00 between a couple of sparc t1's. 78? 88? mbs. shrug. | 07:15 |
| spm | ... using iperf, or something very like it. | 07:15 |
| spm | the other possibility is to snarf the entire flow in tcpdump etc; and do an analysis of that; you may just be hitting tcp window maxes - or something silly/funky like that | 07:16 |
| spm | heh; or you have a crap switch ;-) | 07:16 |
| spm | might even be worth removing the switch and trying a cross over cable if iperf can't really zot it along. | 07:17 |
| spm | could also try; eg; ftp to an ftp daemon; and/or samba to flip some possibilities | 07:18 |
| spm | or nc... | 07:18 |
| spm | Actually - this'd be via your shiny new laptop? the network interface may be Gig, but hooked into the pcmcia bus or some sillyness down that path; I know my older laptop has woeful network connection speed compared to a stock desktop/card | 07:19 |
| lifeless | spm: yeah, I'll build up to that. | 07:22 |
| lifeless | no, its not my laptop; desktop hardware. asus mb | 07:22 |
| lifeless | mbs | 07:22 |
| spm | cool; if the network is on the m/b; try a card if you have a spare lying around. | 07:22 |
| lifeless | I don't ;) | 07:23 |
| spm | heh; I think I do; but that may be hard to easily borrow :-) | 07:23 |
| lifeless | [ 3] 0.0-10.0 sec 727 MBytes 609 Mbits/sec | 07:23 |
| lifeless | so, thats a lot better than wget is maanging | 07:23 |
| spm | schweeet! so nothing wrong with the switch or network h/w. | 07:24 |
| lifeless | well | 07:24 |
| lifeless | thats .7 of theoretical or so | 07:24 |
| spm | probably that crappy open-sores stuff. install windows and watch the problems fly fly fly away | 07:24 |
| lifeless | hah | 07:24 |
| lifeless | I want to be able to test bzr perf :) | 07:24 |
| fullermd | Most builtins on Asus are Realtek NIC's. So .7 is pretty good :p | 07:25 |
| lifeless | first step is to make sure that the wiring is good - which it seems to be | 07:25 |
| lifeless | next to figure out why wget is slow with apache2 | 07:25 |
| spm | actually this has all made me curious as to what I can get on my network.... | 07:25 |
| lifeless | hmm, default tcp buffer size is 85KB ? | 07:27 |
| spm | [ 3] 0.0-10.0 sec 539 MBytes 452 Mbits/sec <== sadness :-( | 07:27 |
| lifeless | hmm, I should play with jumbo frames | 07:28 |
| lifeless | spm: you had a tool to analyse window info didn't you? | 07:32 |
| spm | tcptrace + xplot for pretty graphs | 07:33 |
| spm | wireshark can do similar; but the above is still light years ahead | 07:33 |
| lifeless | this is interesting | 07:40 |
| lifeless | $ cat /proc/sys/net/ipv4/tcp_mem | 07:40 |
| lifeless | 88416 117888 176832 | 07:40 |
| lifeless | $ cat /proc/sys/net/ipv4/tcp_mem | 07:40 |
| lifeless | 573408 764544 1146816 | 07:40 |
| lifeless | the second, with the larger - better - setting, is lucid | 07:40 |
| lifeless | sorry | 07:40 |
| lifeless | is karmic. | 07:40 |
| lifeless | the first is lucidish | 07:40 |
| lifeless | ok, 85MB/sec | 07:58 |
| lifeless | had my gateway in the loop | 07:58 |
| lifeless | ok cool, my python server keeps up @ 85MB | 08:04 |
| lifeless | \o/ | 08:05 |
| lifeless | spm: thansk | 08:05 |
| spm | coolio; anytime etc :-) | 08:05 |
| lifeless | trafshow is interesting btw | 08:05 |
| lifeless | not brilliant | 08:05 |
| lifeless | but interesting | 08:05 |
| spm | yeah? not familar with one. | 08:20 |
| lifeless | apt-get install trafshow :P | 08:30 |
| spm | sush :-) | 08:34 |
| spiv | Oh, grr! | 09:02 |
| spiv | siginterrupt(signum, False) is reset everytime the signal is received. | 09:02 |
| bialix | spiv: hi | 09:07 |
| spiv | bialix: good evening | 09:07 |
| spiv | I'm about to finish up for the day. | 09:07 |
| bialix | spiv: I have a question which bothers me for a long time | 09:07 |
| spiv | So I'm extra annoyed to bump into another signal/EINTR issue! | 09:07 |
| bialix | why smart server returns to the client relpath to the shared repo root, but then client do upwalk search anyway? | 09:08 |
| spiv | bialix: because we haven't finished improving the client yet :) | 09:08 |
| bialix | spiv: sorry, I don't want to increase your temper | 09:09 |
| bialix | spiv: is it known bug? | 09:09 |
| spiv | Oh, that's fine, I'm not bothered at all :) | 09:09 |
| spiv | Yeah | 09:09 |
| * bialix wanna subscribe to it | 09:09 | |
| bialix | spiv: ok, thanks, you save me another year of bothering with this question :-) | 09:10 |
| spiv | Hmm, not sure if there's a bug number for it, but it's certainly an issue known to me and lifeless! | 09:10 |
| spiv | There might be | 09:10 |
| spiv | If there isn't you're welcome to file one :) | 09:10 |
| bialix | now I know kung-fu too | 09:10 |
| spiv | heh | 09:10 |
| bialix | ok, I'll file it | 09:10 |
| spiv | Basically, there's no convenient place in bzrlib at the moment to make use of the relpath info the smart server is returning there | 09:11 |
| spiv | We need to replace or improve the regular 'open' code path | 09:11 |
| bialix | I see | 09:11 |
| spiv | Which has historically been a bit fragile when touched. | 09:12 |
| spiv | I'd rather not duplicate it, because there's really quite a lot of code there for format detection etc. | 09:12 |
| spiv | Anyway, I'm done for the day. | 09:12 |
| spiv | Happy hacking! | 09:12 |
| bialix | gnight | 09:13 |
| bialix | spiv: https://bugs.launchpad.net/bzr/+bug/557915 | 09:16 |
| ubottu | Launchpad bug 557915 in bzr "smart server returns relpath to shared repo but client don't use it and do upwalk search anyway" [Low,Confirmed] | 09:16 |
| bialix | I've pasted our converstaion | 09:16 |
| spiv | bialix: thanks | 09:42 |
| igc | night spiv | 10:02 |
| thumper | hi people | 10:06 |
| thumper | I'm using bzrlib to commit to a working tree | 10:06 |
| thumper | and I'm specifying the committer | 10:06 |
| thumper | my .bazaar/bazaar.conf says create_signatures = always | 10:06 |
| thumper | but I don't want my script to use this | 10:07 |
| thumper | what should I set? | 10:07 |
| thumper | BZR_HOME env variable? | 10:07 |
| thumper | and how to I set it to just "something that isn't my home" ? | 10:07 |
| spiv | BZR_HOME=/dev/null works (with a warning) | 10:09 |
| thumper | what warning? | 10:09 |
| thumper | and does it matter from bzrlib? | 10:09 |
| spiv | failed to open trace file: [Errno 20] Not a directory: '/dev/null/.bzr.log' | 10:09 |
| thumper | perhaps I should use a tempdir instead | 10:10 |
| spiv | You could always use BZR_HOME=`mktemp -d` | 10:10 |
| thumper | spiv: this is from python code, so probably inserting into sys.environ | 10:11 |
| spiv | thumper: right | 10:12 |
| spiv | And probably by using the tempfile module rather than calling out to /bin/mktemp, too ;) | 10:13 |
| thumper | spiv: yeah, looking at that right now | 10:15 |
| bialix | BZR_LOG=/dev/null may helps to avoid warning | 10:32 |
| thumper | bialix: too late :) | 10:34 |
| thumper | although this might be easier | 10:35 |
| bialix | spiv: I like your branch name | 10:35 |
| bialix | :-) | 10:35 |
| thumper | /dev/null doesn't work on windows though does it? | 10:35 |
| bialix | thumper: on Windows one should use BZR_LOG=NUL | 10:35 |
| bialix | not sure if BZR_HOME=NUL will work though | 10:35 |
| thumper | bialix: yeah, so I'm going for the cross platform: tempfile.mkdtemp and atexit.register(shutil.rmtree...) | 10:36 |
| bialix | thumper: +1 from me | 10:36 |
| thumper | bialix: I'm getting close to actually getting wikkid working | 10:36 |
| bialix | wikkid ? | 10:37 |
| thumper | http://wikkid.info | 10:37 |
| thumper | should redirect to LP :) | 10:37 |
| bialix | does not work for me | 10:37 |
| thumper | really :( | 10:37 |
| thumper | what do you get? | 10:37 |
| thumper | works for me | 10:38 |
| bialix | it says: Firefox can't find the server www.wikkid.info | 10:38 |
| thumper | hmm... | 10:38 |
| thumper | weird, should work | 10:38 |
| thumper | that redirect is in place too | 10:38 |
| bialix | perhaps DNS issue? | 10:39 |
| thumper | perhaps | 10:39 |
| bialix | C:\Temp>ping wikkid.info | 10:39 |
| bialix | Ping request could not find host wikkid.info. Please check the name and try again. | 10:39 |
| bialix | :'-( | 10:39 |
| thumper | https://edge.launchpad.net/wikkid | 10:39 |
| bialix | wow! | 10:40 |
| thumper | I have many plans | 10:40 |
| thumper | some are getting there | 10:40 |
| bialix | it's my dream: to have bzr-based wiki and bug tracker | 10:40 |
| thumper | I want a wiki in launchpad | 10:40 |
| bialix | wiki in LP! YAY! | 10:40 |
| thumper | bialix: well, I'm not doing a bug tracker | 10:40 |
| james_w | thumper: you can pass a custom config to .commit() | 10:41 |
| bialix | thumper: that's ok | 10:41 |
| thumper | I'm designing wikkid with the intent of having it integrated into launchpad | 10:41 |
| bialix | thumper: so it will be zope-based? | 10:41 |
| thumper | but wikis are not a priority for LP | 10:41 |
| thumper | so I'm doing it in my own time | 10:41 |
| thumper | bialix: no paste | 10:41 |
| thumper | wsgi | 10:41 |
| bialix | ok | 10:41 |
| thumper | james_w: interesting | 10:42 |
| * bialix want to know all this cool things someday | 10:42 | |
| james_w | thumper: so you could just grab the branch config and override the signatures thing | 10:42 |
| thumper | james_w: I'm sure I'll get some people commenting on my bzr hackery in wikkid soon enough | 10:42 |
| james_w | or just use an empty config to get the defaults if you don't want anything from the environment | 10:43 |
| thumper | james_w: that may be even easier for me :) | 10:43 |
| spiv | bialix: :) | 10:47 |
| lifeless | thumper: publicity! | 10:49 |
| thumper | lifeless: :) | 10:49 |
| thumper | I'm having issues with smart_add | 10:50 |
| thumper | perhaps I should be more choosey | 10:50 |
| lifeless | well | 10:50 |
| lifeless | if you have temp files smart_add will break you ;) | 10:50 |
| lifeless | that said | 10:50 |
| lifeless | you can do tree.smart_add([relpath_to_tree]) and it should work | 10:50 |
| lifeless | the fact that you have to give the path to the tree is a bug - I forget the number | 10:51 |
| lifeless | its fugly | 10:51 |
| lifeless | very old partially fixed up API (used to be a standalone function poking at the internals) | 10:51 |
| thumper | ah | 10:51 |
| thumper | that might explain it | 10:51 |
| thumper | d | 10:51 |
| thumper | d'oh | 10:51 |
| thumper | I'm giving it ['.'] | 10:52 |
| thumper | which is the cwd | 10:52 |
| thumper | not the location of the tree | 10:52 |
| lifeless | yeah | 10:52 |
| lifeless | if you'd like to submit a patch to fix it, we'd love that. | 10:52 |
| thumper | lifeless: I honestly don't know where to start | 10:52 |
| thumper | well | 10:52 |
| thumper | I could probably stumble about for a while | 10:53 |
| lifeless | tree.bzrdir.base_transport.local_abspath('.') | 10:53 |
| thumper | base_transport or root_transport? | 10:54 |
| lifeless | root | 10:55 |
| lifeless | DWIMNWIS | 10:55 |
| thumper | :) | 10:56 |
| thumper | :( | 10:57 |
| thumper | still failing | 10:57 |
| thumper | bzrlib.errors.PathNotChild: Path "/" is not a child of path "/home/tim/src/wikkid/sandbox" | 10:58 |
| thumper | it seems to be calling smart_add now with the path shown on the end | 10:58 |
| thumper | this is the path of the working tree I'm editing | 10:59 |
| thumper | [canonical_relpath(base, p) for p in paths] blows up | 10:59 |
| thumper | perhaps I shouldn't use smart_add but use something else | 11:02 |
| thumper | ? | 11:02 |
| thumper | the reason i used smart_add was I didn't want to have to check the creation of all the subdirs | 11:02 |
| thumper | and adding them properly | 11:02 |
| lifeless | what is canonical_relpath ? | 11:07 |
| thumper | lifeless: a big picture captured with coloured error bits: http://people.canonical.com/~tim/wiki-error.png | 11:20 |
| thumper | lifeless: although I'm about to stop and watch House that we recorded on Tuesday | 11:21 |
| thumper | lifeless: I'll get back to this tomorrow maybe | 11:22 |
| lifeless | thumper: did you see my question about MAN's in NZ ? | 11:35 |
| lifeless | thumper: pass a list in | 11:36 |
| lifeless | thumper: not a single path | 11:36 |
| lifeless | your path is being interpreted as ['/', 'h', '.... | 11:36 |
| lelix | hi all | 12:05 |
| lelix | I'm going to convert a project from svn to bzr. Right now it is composed by a few distinct repositories, and I'm doing svn-import on each of them | 12:07 |
| jelmer | hi lelix | 12:07 |
| lelix | now I have a doubt on the resulting bzr repos | 12:08 |
| lelix | hi jelmer | 12:08 |
| maxb | What do you doubt? | 12:09 |
| lelix | I simply did "bzr svn-import https://.../repoX", and got two different "kind" of bzr repos: one contains two subdirs ("branches" and "trunk") that I assume are "branches" in bzr parlance | 12:09 |
| maxb | The "branches" directory is not a bzr branch. It is merely a container to match the svn naming scheme for branches | 12:10 |
| lelix | the other instead is "monolithic", that is, it does contain just a ".bzr" subdir, and checking it out I get the whole thing that is "/trunk", "/branches" and "/tags" | 12:10 |
| lelix | maxb: yes | 12:11 |
| maxb | The actual bzr branches are at "branches/FOO" | 12:11 |
| lelix | yes, it even told me that, so I could not do "bzr co .../repo1" but had to do "bzr co .../repo1/trunk" | 12:11 |
| maxb | If trunk/, tags/ branches/ are present *inside* a bzr checkout/branch, then the import has imported the wrong thing | 12:11 |
| lelix | yes, that's what seems happened | 12:12 |
| lelix | I see svn-import uses a "layout" option, I left the default "auto", and the import step told me "using repository layout trunk0" | 12:13 |
| lelix | but I fail to understand the difference between one kind and the other... it must be something different in the source repositories... | 12:14 |
| lelix | maybe I can "svn-import" just the svn "/trunk" instead of processing the whole repository? | 12:14 |
| * lelix tries | 12:15 | |
| jelmer | lelix: you can 'bzr branch' just the trunk | 12:15 |
| jelmer | lelix: svn-import is for importing multiple branches | 12:15 |
| lelix | jelmer: with the former, you mean I don't have to use svn-import at all, and just branch it out of svn? | 12:17 |
| jelmer | lelix: yep | 12:17 |
| * lelix leaves for lunch | 12:17 | |
| lelix | jelmer: thanks, I'll retry later | 12:18 |
| === radoe_ is now known as radoe | ||
| === salgado-afk is now known as salgado | ||
| lifeless | vila: two questions | 13:26 |
| lifeless | vila: did you get anywhere on the lost+found approach for conflicts deleting directories that contain ignored files? | 13:26 |
| lifeless | vila: and, if I wanted to do a POST, to an http url that I have a bzr transport connected too; is there a clean way? or the best unclean way? | 13:27 |
| lelix | just to understand: what determines the kind of thing I obtain with "bzr branch" wrt to working-tree? Doing a branch from a svnrepo I get a workingtree-less branch, while branching from there I get the working tree... | 14:06 |
| lelix | does the presence of the wtree imply some difference in the repo itself? | 14:07 |
| === nlisgo_ is now known as nlisgo | ||
| IslandUsurper | lelix, possibly. bzr repos can be set to use working trees or not by default. run `bzr info` on your destination branch to see if it tells you. | 14:16 |
| IslandUsurper | I doubt it has to do with bzr-svn or the svn repo | 14:17 |
| jelmer | lelix: you can create a working tree by running 'bzr co'; there is a setting in the repository that determines whether working trees are created by default | 14:18 |
| pyMynx | how can I get bzr to use a different python install? | 14:25 |
| SamB_XP | what OS? | 14:26 |
| SamB_XP | pyMynx: if you're on *nix, you can either change the #! line at the top of the bzr executable, or you can change which python install is invoked by /usr/bin/env python | 14:29 |
| SamB_XP | (or whatever it is at the top of your bzr executable -- I guess it might be something else ;-) | 14:30 |
| SamB_XP | but note that (a) bzrlib will have to be in that python's module path and (b) you may lose features if you switch major versons of Python without getting the extensions compiled for the major version you switch to | 14:32 |
| SamB_XP | pyMynx: so ... are you gonna say anything or not ? | 14:33 |
| lelix | jelmer, ok: but from the repository POV, does that make any difference? Or is that completely transparent in the operations one can do on it? Ideally, it seems that I can keep my "master" repos (the one linked to some kind of bug-tracker/repo-browser say) always as wtree-less repositories, right? | 14:42 |
| maxb | Yes, this is correct. Working trees are purely for doing development work in | 14:45 |
| lelix | thanks | 14:46 |
| pyMynx | SamB_XP: hey thanks very much! I think I fixed it by moving the bin path up in the PATH environment variable | 15:16 |
| pyMynx | SamB_XP: it always resets for some reason :( , I'm using CentOS btw | 15:17 |
| === masklinn_ is now known as masklinn | ||
| === deryck is now known as deryck[lunch] | ||
| === chex is now known as Chex | ||
| === salgado is now known as salgado-lunch | ||
| === radoe_ is now known as radoe | ||
| === deryck[lunch] is now known as deryck | ||
| johnjosephbachir | howdy | 17:59 |
| johnjosephbachir | anyone here know much about the --file-ids-from flag for the 'add' command? | 17:59 |
| === beuno is now known as beuno-lunch | ||
| maxb | johnjosephbachir: What about it? | 18:20 |
| johnjosephbachir | well, i used it when adding in some code from another repo (svn), thinking it might be helpful for merging in updates from that repo in the future. Now, i'm trying to merge in changes from another one of my own branches (on a directory above that dir in question), and bzr is very confused, thinking that the dir i added witih --file-ids-from needs to be deleted | 18:21 |
| johnjosephbachir | maxb: ^ | 18:21 |
| maxb | Does the dir in question exist in any of your branches, *except* by way of being added by that one addition you mentioned? | 18:23 |
| maxb | And when you say svn, do you mean a bzr-svn conversion? | 18:23 |
| johnjosephbachir | here's what i did. i have trunk, and branch-1 | 18:24 |
| johnjosephbachir | branch-1 is a branch of trunk, as you might imagine. inside of branch-1, i did this command: | 18:24 |
| johnjosephbachir | svn export http://svn.example.com/path/to/tag mydir | 18:25 |
| johnjosephbachir | bzr add --file-ids-from= http://svn.example.com/path/to/tag mydir | 18:26 |
| johnjosephbachir | and committed, and have been doing tons of development in both trunk and branch-1 since then | 18:26 |
| fullermd | I wouldn't --file-ids-from can do anything when pointed at a svn repo... | 18:26 |
| fullermd | (wouldn't think) | 18:26 |
| johnjosephbachir | now, when i do a merge, i get tons of errors, the first one being: | 18:27 |
| johnjosephbachir | "Conflict: can't delete mydir because it is not empty. Not deleting." | 18:27 |
| johnjosephbachir | maxb: ^ | 18:27 |
| johnjosephbachir | maxb / fullermd and i am fairly certain this problem is a result of my file-ids-from, for reasons i will be happy to explain if you would like me to (but it will take a while) | 18:28 |
| maxb | erm. And did the content of mydir correspond closely to the content of http://svn.example.com/path/to/tag ? | 18:28 |
| fullermd | I'm pretty sure you'd have to point at a bzr branch for file-ids-from to have any possible meaning. | 18:28 |
| johnjosephbachir | maxb: the contents were identical when added (note that it came directoy after an svn export) | 18:28 |
| maxb | I don't suppose this is a public project? It would be so much easier to see it breaking | 18:29 |
| johnjosephbachir | maxb: alas, no, but if you are available for consulting i can email you the repos in question | 18:29 |
| fullermd | At any rate, you could just check whether the two branches have the same file-id's. But I'd doubt it. | 18:30 |
| johnjosephbachir | fullermd: well the thing is, i don't actually want to do any operations on the foreign repo... so its state shouldn't matter for this operation | 18:31 |
| johnjosephbachir | (if i get what you mean) | 18:31 |
| fullermd | I don't. | 18:32 |
| johnjosephbachir | you don't wnat? | 18:32 |
| johnjosephbachir | *what? :) | 18:33 |
| fullermd | At any rate, if the file-id's of two branches don't match, you're not going to have any direct luck merging them (it's bad enough them not sharing ancestry) | 18:33 |
| johnjosephbachir | fullermd: i | 18:33 |
| fullermd | And using file-ids-from pointed at a SVN repo is almost certain not to make the two bzr branches match, if indeed it does anything at all. | 18:33 |
| johnjosephbachir | fullermd: i'm not trying to merge them. i'm truing to merge two of my own branches, one of which has a subdirectory based off of a foreign branch | 18:33 |
| johnjosephbachir | fullermd: got it. well, the dir in question doesn't exist at all in the branch i am merging in... so i'm not sure why it cares about it at all | 18:34 |
| fullermd | Did it ever? | 18:34 |
| johnjosephbachir | nope | 18:34 |
| johnjosephbachir | fullermd: is there a way to "normalize" my file-ids in my imported branch? i.e., clear out the result of using --file-ids-from, and let bzr make its own "normal" ids ? | 18:35 |
| johnjosephbachir | ' | 18:35 |
| johnjosephbachir | maxb: ping | 18:35 |
| maxb | johnjosephbachir: Empirically, --file-ids-from has no effect when given a remote svn repository | 18:35 |
| fullermd | I'm not sure that's a meaningful statement. I'm still of the SWAG belief that --file-ids-from=<something svn> is nugatory from the get-go. | 18:35 |
| fullermd | And if it weren't, letting bzr create its own random ones still wouldn't help you with merging down the line. | 18:36 |
| johnjosephbachir | okay, i'll tell you guys what else i've observed | 18:36 |
| maxb | I have tested fullermd's SWAG and it is correct. I disbelieve that --file-ids-from is the problem here | 18:37 |
| johnjosephbachir | so i tried this workaround. i tried first removing mydir in branch-1, committing that (let's say that's revision 10). then, i did the merge, with no problems. then i committed that merge. THEN, i tried to undo revision 10, with bzr merge -r10..9 , and i got this error: http://pastie.org/909742 | 18:39 |
| === salgado-lunch is now known as salgado | ||
| fullermd | You forgot to tell it a meaningful place to merge from (e.g., itself) | 18:40 |
| fullermd | I think you're succumbing to shotgunitis, here. | 18:40 |
| * johnjosephbachir tries it with a dot | 18:41 | |
| johnjosephbachir | WIN | 18:43 |
| johnjosephbachir | okay so, that worked, and is probably a good workaround, BUT: 1) we still don't know why the merge didn't work, and 2) i don't wnat to have to do this every time | 18:44 |
| johnjosephbachir | any ideas? maxb fullermd | 18:44 |
| johnjosephbachir | i would be happy to send either of you the branches and pay you to solve this problem, if you have the skills/time/interest | 18:45 |
| maxb | I don't think any further debugging is really possible without seeing the actual history. If this were svn, I'd ask for a 'svn log -v', but I don't know of any equivalent bzr view that actually shows file/dir add/del/move operations | 18:45 |
| maxb | I'm not doing paid consulting, but you've got me curious - if you want to send it to me, I'm happy to see if I can solve the conundrum | 18:46 |
| johnjosephbachir | maxb: cool, wanna pm me your email? | 18:47 |
| * maxb afk 5mins | 18:48 | |
| === beuno-lunch is now known as beuno | ||
| jam | maxb: bzr log -v doesn't give the equivalent? | 19:45 |
| sebi` | Hi, do i need to worry when including .bzr/ in distribution packages and branches? are there any sensitive information saved in there? | 19:56 |
| jam | sebi`: I would not include .bzr/ in dist packages, as it doesn't really make *sense* more than it would be bad | 19:58 |
| jam | you wouldn't include .svn, right? | 19:58 |
| jam | anyway, it could include the whole history of the project, but I don't see it including anything more sensitive than that | 19:58 |
| sebi` | I've never worked with svn before, so I can't really say If i would | 19:58 |
| jam | sebi`: generally VCS data is excluded from a .deb | 19:58 |
| sebi` | the history, including all revisions are publicly visible anyway, so I don't see a reason in hiding them | 19:59 |
| sebi` | okay | 19:59 |
| sebi` | so I can assume there are no sensitive information saved in there, such as passwords, login-names, etc? | 19:59 |
| jam | right, there shouldn't be anything sensitive | 20:00 |
| jam | the main thing is that if people wanted the history, they would ask for it | 20:00 |
| jam | if they are grabbing a .deb they don't want the history | 20:00 |
| IslandUsurper | and they would ask for it by using bzr | 20:00 |
| sebi` | okay, makes sense to me | 20:00 |
| jam | and it can significantly increase the size of the download | 20:01 |
| sebi` | woah you're right... .bzr is about 2.3M big right now | 20:01 |
| sebi` | didn't know it gets huge so fast | 20:01 |
| barry | hi folks. are there any windows/bzr experts around? i know next to nothing about windows, but have bzr explorer installed and have done 'bzr launchpad-login' but i'm getting hung up on ssh (maybe this is really a windows ssh problem) | 20:26 |
| jam | hey barry | 20:35 |
| jam | easiest 'fix' is to make sure you have Pageant installed, and that the ssh-key is properly shared with LP | 20:36 |
| jam | but 'it depends' on your ssh setup otherwise | 20:36 |
| jam | well, properly shared *and* properly loaded | 20:36 |
| barry | jam: pageant? is that a windows ssh client? | 20:37 |
| jam | pageant is part of the putty tools, and is an ssh-agent, not really an ssh client | 20:39 |
| barry | jam: gotcha, thanks! | 20:39 |
| jam | alternatively, you can use regular openssh style credentials, but need to have them in the right place on your path so we can find them | 20:39 |
| jam | $HOME/.ssh IIRC | 20:39 |
| jam | where $HOME is often C:\Users\username | 20:39 |
| jam | or C:\Documents and Settings\username | 20:39 |
| jam | depending on your Windows ver | 20:39 |
| barry | jam: windows 7 | 20:40 |
| jam | I haven't used 7 | 20:40 |
| jam | but I'm guessing C:\Users\<username> | 20:40 |
| jam | after Vista's style | 20:40 |
| jam | So I think if you copy your id_rsa and id_rsa.pub to C:\Users\barry\.ssh\id_rsa | 20:40 |
| jam | we can probably find it without pageant | 20:40 |
| barry | jam: cool, thanks. i'll give that a shot. it's boggling how little useful stuff windows actually comes with :) | 20:41 |
| jam | barry: installing cygwin usually helps, but yeah | 20:41 |
| barry | jam: yeah :) | 20:41 |
| jam | bare-bones OS vs OS + apps | 20:41 |
| jam | and no package manager | 20:41 |
| barry | "get a real os" is my usual response :) | 20:42 |
| barry | jam: otoh, explorer is pretty nice | 20:43 |
| jam | bzr explorer works on real OS's too | 20:44 |
| barry | yeah, but it's only windows that makes me all clickity clackity | 20:45 |
| mneptok | barry: your tap shoes don;t do that? | 21:16 |
| * mneptok is Fred to barry's Ginger | 21:16 | |
| barry | mneptok: i don't have red hair or taps, but i do have bells on my toes | 21:24 |
| mneptok | barry: i don't want to rmeinf you again not to arouse me during working hours. | 21:29 |
| mneptok | *remind | 21:29 |
| jam | vila: I thought you weren't working today. Why are you triaging bugs? :) | 21:46 |
| abadger1999 | Hey, I'm writing a proposal for Fedora EPEL to be able to upgrade the bzr package we have despite API compatibility changes. | 21:58 |
| abadger1999 | Can someone confirm whether bzr-2.1 can support all the repos that bzr-1.3 has? | 21:59 |
| Noldorin | hi jelmer | 21:59 |
| fullermd | You mean the formats? Sure. | 21:59 |
| jelmer | Noldorin: hi | 22:00 |
| Noldorin | jelmer: i see bzr-git has come along a bit. though i might give it another shot with github :) | 22:01 |
| Noldorin | (not sure if you remember me...) | 22:01 |
| jelmer | Noldorin: I remember :-) | 22:01 |
| Noldorin | :) | 22:01 |
| jelmer | Noldorin: I don't think anything has changed in the area you were seeing problems though | 22:01 |
| Noldorin | i'm working off bzr-git and dulwich trunks now | 22:01 |
| Noldorin | ah right | 22:01 |
| Noldorin | jelmer: still, i've cleaned up my system and my bazaar installation a bit too, so i'm sort of doing things afresh now | 22:02 |
| Noldorin | if you wouldn't mind providing a few pointers... | 22:02 |
| === salgado is now known as salgado-afk | ||
| lifeless | abadger1999: yes, 2.1 can read and write to a superset of 1.3 | 22:05 |
| abadger1999 | lifeless: Thanks! | 22:05 |
| Noldorin | jelmer: it says i need distutils for a start, now... | 22:06 |
| Noldorin | jelmer: oops, seems my system is still detecting an old python version, which explains | 22:08 |
| Noldorin | jelmer: sorry.... what was the trick to get dulwich being recognised by bzr-git after doing setup.py install? | 22:19 |
| jelmer | Noldorin: you can set PYTHONPATH I guess | 22:20 |
| Noldorin | jelmer: yeah, but to what, if i've installed it? | 22:21 |
| Noldorin | the source (pulled from the branch) lives in c:\lib\dulwich | 22:21 |
| jelmer | Noldorin: to the location in which it's been installed | 22:23 |
| Noldorin | jelmer: sorry, i'm still quite ignorant of python. all i know is that setup.py install ran and completed successfully... | 22:23 |
| jelmer | Noldorin: you should set the environment variable PYTHONPATH to the path of the directory that contains dulwich\__init__.py | 22:24 |
| Noldorin | jelmer: ok, so that's what i'm doing. is the separator in the PYHTONPATH the ; character? | 22:43 |
| jelmer | Noldorin: I think so | 22:44 |
| Noldorin | jelmer: ok, cheers. so it finds dulwich now, but i get this error: | 22:47 |
| Noldorin | C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+ | 22:47 |
| Noldorin | ssh://git@github.com/Noldorin/IRC.NET.git --no-strict | 22:47 |
| Noldorin | bzr: ERROR: [Error 2] The system cannot find the file specified | 22:47 |
| Noldorin | if i recall correctly, we never did figure out the required URL for github... hmm | 22:47 |
| barry | jam: or other folks. i don't know enough about how bzr explorer does its thing but i think it maybe causing spurious failures in the python test suite. i think we're seeing something similar to this: http://bugs.python.org/issue7443 | 22:49 |
| barry | jam: is it possible to "turn off" bzr explorer temporarily for that directory and all sub-directories? | 22:50 |
| jelmer | Noldorin: that URL is correct, I'm quite sure it is | 22:50 |
| Noldorin | ok good | 22:50 |
| Noldorin | but yes, this Error 2 is unexpected... | 22:51 |
| jam | barry: do you mean explorer or TortoiseBzr ? | 22:51 |
| jam | (explorer == gui standalone app, TortoiseBzr == Windows Explorer integration) | 22:51 |
| jam | AFAIK, not easy to disable per dir without just uninstalling it | 22:51 |
| jam | but I don't follow it very closely. | 22:52 |
| jelmer | Noldorin: somebody reported an error against Dulwich trunk the other day about atomic renames | 22:52 |
| Noldorin | jelmer: ah, you think this couldbe causing error 2? if so, should i maybe revert to a previous revision of dulwich? | 22:53 |
| barry | jam: probably tortoisebzr | 22:53 |
| lifeless | vila: ping ? | 22:54 |
| barry | jam: ah. don't really want to do that. maybe i can copy the directory elsewhere or mv the .bzr directory aside? | 22:55 |
| jam | barry: mv the .bzr aside would probably work | 22:55 |
| barry | jam: cool thanks. trying... | 22:55 |
| Noldorin | jelmer: looks like a windows style error anywya | 22:58 |
| lifeless | james_w: btw, multiprocessing is really slow | 22:58 |
| Noldorin | jelmer: i'm up for a little debugging of the source, if that helps you :) | 22:59 |
| james_w | lifeless: what do you mean? | 22:59 |
| lifeless | james_w: I benchmarked doing stuff with python's multiprocessing module a while back | 22:59 |
| jelmer | Noldorin: we need to find a good alternative to atomic renames on Windows | 23:00 |
| lifeless | james_w: it was only marginally faster than threads, and a lot slower than using a custom external helper | 23:00 |
| jelmer | Noldorin: you're on Windows < 7 I suspect? | 23:00 |
| jelmer | Noldorin: I wonder what C Git uses | 23:00 |
| Noldorin | jelmer: i'm on Windows 7 actually | 23:00 |
| Noldorin | yeah... | 23:00 |
| Noldorin | jelmer: if there's any testing we can do at the moment (for a temporary solution at least), that's cool though | 23:01 |
| Noldorin | having some devs on my project before git, and others prefer bzr is making things a pain heh! | 23:02 |
| Noldorin | some devs on my project prefer* | 23:02 |
| jelmer | Noldorin: you could revert back to older versions of dulwich and bzr-git | 23:03 |
| Noldorin | jelmer: ok, i will try that | 23:03 |
| Noldorin | which revision of each do you recommend? | 23:03 |
| jelmer | the latest release I guess | 23:04 |
| Noldorin | jelmer: how do i know what that is? | 23:04 |
| Noldorin | never mind, it's all tagged :) | 23:07 |
| jelmer | yep :-) | 23:09 |
| Noldorin | jelmer: same error i'm afraid | 23:10 |
| Noldorin | on the 0.5.0 release | 23:10 |
| jelmer | Hmm, I guess the GitFile changes made it into the 0.5.0 release as well | 23:11 |
| jelmer | I guess you'll need one of the 0.4.x releases then | 23:11 |
| Noldorin | ok | 23:11 |
| jelmer | I'm not sure if that's actually newer than last time you tried | 23:11 |
| Noldorin | jelmer: crazy. still exists in 0.4.3/0.4.1 | 23:14 |
| jelmer | are you sure you're running an older version? | 23:14 |
| Noldorin | yep | 23:15 |
| Noldorin | 'bzr plugins' says git 0.4.3 | 23:15 |
| jelmer | Noldorin: that doesn't mean it's an older version of dulwich | 23:15 |
| Noldorin | jelmer: yes i know, but i've checked my dulwich version too and rebuilt it :) | 23:15 |
| Noldorin | bzr revert -r xyz | 23:15 |
| Noldorin | python setup.py build | 23:15 |
| Noldorin | python setup.py install | 23:15 |
| Noldorin | and retest | 23:16 |
| Noldorin | jelmer: any ideas...? | 23:18 |
| Noldorin | otherwise i will just leave it for now heh | 23:18 |
| jelmer | Noldorin: sorry, no idea; I doubt there's much point in trying with such an old version anyway | 23:24 |
| jelmer | since it would be the same version as what you tried earlier | 23:24 |
| Noldorin | jelmer: indeed | 23:26 |
| Noldorin | jelmer: well, if/when you think it's worth trying again, do ping me please :) | 23:26 |
| jelmer | Noldorin: will do :-) | 23:30 |
| Noldorin | cheers | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
