| ls3_ | Hello. If a branch diverges, all I need to do a bzr merge; bzr commit; and accept the commit, right? That applies changes to my local setup only? | 00:18 |
|---|---|---|
| ls3_ | Too scared to accept the commit because it's for work :) | 00:18 |
| AuroraBorealis | backup the branches before you do it :o | 00:19 |
| ls3_ | It's just one completely unrelated file and my unrelated file.. Last time it happened I just checked out the branch and re-applied my change. But would like to know the correct way | 00:21 |
| AuroraBorealis | that seems right | 00:22 |
| AuroraBorealis | just merge them | 00:22 |
| KombuchaKip | What are the last two numbers in this? Stage:Fetching revisions:Inserti.. 6664/961 | 01:32 |
| AuroraBorealis | probably 'chunks' of data or something | 01:33 |
| KombuchaKip | AuroraBorealis: Yeah, just not sure what the units are. | 01:33 |
| lifeless | objects | 01:35 |
| AuroraBorealis | SERIES OF TUBES | 01:36 |
| KombuchaKip | lifeless: So why is the numerator larger than the denominator? | 01:36 |
| lifeless | KombuchaKip: its not a fraction | 01:37 |
| KombuchaKip | lifeless: What's it mean? | 01:37 |
| AuroraBorealis | yeah haha | 01:37 |
| AuroraBorealis | seems like random mnumbers | 01:37 |
| lifeless | total-needed / received[or sent if pushing] | 01:37 |
| KombuchaKip | lifeless: Shouldn't they have flipped it to make it more intuitive? | 01:38 |
| lifeless | KombuchaKip: feel free to file a bug | 01:39 |
| KombuchaKip | lifeless: heh | 01:39 |
| KombuchaKip | lifeless: It's not really important. | 01:39 |
| lifeless | sure, its still changable though :) | 01:39 |
| AuroraBorealis | yeah i feel like they should add units at least | 01:39 |
| KombuchaKip | mm | 01:40 |
| fullermd | Actually, I think the units are there, sorta. There's in the continuation of "Inserti...". | 01:43 |
| fullermd | All you need is a 300 char wide term. | 01:44 |
| === mwhudson_ is now known as mwhudson | ||
| _thumper_ | poolie: ping | 06:13 |
| === _thumper_ is now known as thumper | ||
| bignose | I have a branch ‘bar’ branched from ‘trunk’. no additional revisions have yet been committed to ‘bar’. | 06:21 |
| bignose | now I realise that ‘trunk’ needs some more revisions from upstream; ‘cd ../trunk/ && bzr update’ | 06:22 |
| bignose | at this point, is there a difference between: | 06:22 |
| bignose | ‘cd ../ && rm -r bar/ && bzr branch trunk/ bar/’ | 06:22 |
| bignose | ‘cd ../bar/ && bzr pull ../trunk/’ | 06:23 |
| spiv | No. | 06:23 |
| AuroraBorealis | nope. | 06:23 |
| bignose | okay. so at what point, and how, does ‘bar’ have its own history? | 06:23 |
| AuroraBorealis | i would think bar would have its own history. | 06:23 |
| AuroraBorealis | you updated trunk but bar didn't recieve that update | 06:24 |
| AuroraBorealis | so trunk and bar are the same up to the point where you branched it | 06:24 |
| spiv | Define "own"? It has its own history, it just happens to (currently) be identical to trunk's. | 06:24 |
| AuroraBorealis | except for the latest update | 06:24 |
| bignose | so if ‘bar’ gains additional revisions, then ‘trunk’ merges from ‘bar’ | 06:25 |
| bignose | at that point ‘bar’ and ‘trunk’ will contain the same revisions but different history, yes? | 06:25 |
| spiv | (Where "currently" refers to "after you 'bzr pull' as described above. Before that it obviously has its own history that happens to be a subset of current trunk/upstream.) | 06:25 |
| bignose | (‘trunk’ will of course contain a merge commit) | 06:25 |
| AuroraBorealis | if you commit anything to bar, trunk wont get it unless you merge it back into trunk | 06:26 |
| spiv | Right, so trunk contains all the same revisions *plus* that one merge revision. | 06:26 |
| AuroraBorealis | yeah, once you merge it back | 06:26 |
| AuroraBorealis | it will gain all the revisions that bar had | 06:26 |
| bignose | it contains them. is that identical to saying they have the same history? I thought not. | 06:26 |
| AuroraBorealis | and then if you visualize it you will see the bar branch diverting | 06:26 |
| AuroraBorealis | to the side then merging back | 06:26 |
| bignose | I almost never use ‘bzr pull’ and I'm trying to understand what effect it has, in terms of the above story. | 06:28 |
| spiv | bignose: no, I'd say the history is different, but not in an important way for many purposes. (Different people have different expectations about the word "history", hence my qualified answer) | 06:28 |
| AuroraBorealis | pull clones | 06:28 |
| spiv | bignose: ah, now for 'bzr pull' I can give an unqualified answer :) | 06:28 |
| spiv | bignose: it never generates a new revision, whereas merge+commit does | 06:28 |
| AuroraBorealis | cause pull just clones whatever you are pulling | 06:29 |
| spiv | bignose: its primary use case is for when you have a branch you are maintaining as a mirror of another branch. | 06:29 |
| bignose | okay, so what will it do in the story above? i.e., ‘cd ../bar/ && bzr pull’ will do what to the history? | 06:29 |
| AuroraBorealis | it will mirror the history of whatever you are pulling | 06:30 |
| bignose | and is it different if ‘bar’ is already divergent from ‘trunk’? | 06:30 |
| AuroraBorealis | bar will still be diverged | 06:30 |
| AuroraBorealis | wont effect it | 06:30 |
| spiv | bignose: a) check that bar and trunk haven't diverged (if they have it stops with an error) | 06:30 |
| bignose | spiv: so if ‘trunk’ has merged all revisions from ‘bar’, then ‘bar’ still won't be able to pull from ‘trunk’? | 06:31 |
| spiv | bignose: b) add the newer revisions from trunk to bar (copy the missing revs into its repository, then set bar's tip to trunk's tip) | 06:31 |
| bignose | another way of asking: is a branch still “diverged from trunk if trunk has merged from that other branch? | 06:32 |
| AuroraBorealis | they are different but they have the same revisions | 06:32 |
| spiv | bignose: actually, it can, that case isn't divergence: trunk's tip includes all of bar's tip's history. | 06:32 |
| AuroraBorealis | if oyu visualize it, it will be a different line | 06:32 |
| AuroraBorealis | like when you first branched it, bar will go off to the side, when you merge it, the lines will merge | 06:32 |
| bignose | AuroraBorealis: so you're saying ‘pull’ *doesn't* mirror the history? | 06:33 |
| spiv | bignose: but that pull would change the mainline revnos on bar. If you have append_revisions_only set in the branch.conf that would disallow that pull. | 06:33 |
| AuroraBorealis | i dunno what pull would do if you have already made changes. i would just update :> | 06:33 |
| bignose | AuroraBorealis: neither ‘trunk’ nor ‘bar’ are checkous from each other, so update would not transfer anything between them. | 06:34 |
| AuroraBorealis | no but trunk is a checkout from like upstream right | 06:34 |
| AuroraBorealis | if you made changes in trunk, then tried pulling from upstream again, i dunno what would happen | 06:34 |
| AuroraBorealis | i thought pull and push make it an exact mirror of whatever. | 06:35 |
| spiv | bignose: perhaps I should have phrased step a as: a) check all of bar's history is included in trunk. | 06:35 |
| bignose | AuroraBorealis: that contradicts your “bar will still be diverged, wont effect it” | 06:36 |
| bignose | or I'm not understanding you. | 06:36 |
| AuroraBorealis | uhhh | 06:36 |
| AuroraBorealis | you branch from upstream | 06:36 |
| bignose | no | 06:36 |
| bignose | trunk is bound to upstream | 06:36 |
| bignose | not branched | 06:36 |
| AuroraBorealis | well | 06:36 |
| AuroraBorealis | it can be branched from upstream and bound | 06:36 |
| AuroraBorealis | so same thing | 06:37 |
| AuroraBorealis | so anyway, trunk is bound to upstream | 06:37 |
| AuroraBorealis | you branch trunk | 06:37 |
| AuroraBorealis | so now trunk upstream and bar are the same | 06:37 |
| AuroraBorealis | but they are 3 seperate branches | 06:37 |
| spiv | bignose: it's pretty easy to make a couple of toy branches and experiment with what happens. | 06:37 |
| AuroraBorealis | then you start making changes to bar | 06:37 |
| AuroraBorealis | then it becomes its own thing | 06:37 |
| AuroraBorealis | and then you merge it back into trunk | 06:37 |
| spiv | bignose: although I hope my description is adequately clear. | 06:37 |
| AuroraBorealis | i dont know if they are the SAME now, but trunk will now have the revisions of bar | 06:38 |
| AuroraBorealis | and if you visualize it in bazaar explorer, you will see where you branched and created bar, and when bar merged back into trunk | 06:38 |
| spiv | Although I see I've basically just restated the contents of "bzr help pull" :) | 06:39 |
| AuroraBorealis | xD | 06:40 |
| spiv | As far as "the same": if two branches have the same last revision, then by definition they have the same revision history. | 06:41 |
| AuroraBorealis | so here is another question :o | 06:41 |
| bignose | spiv: I think your explanation is clear | 06:41 |
| AuroraBorealis | taken his example, you have a trunk branch, you branch it off into bar, do stuff to bar then merge it back into trunk | 06:41 |
| AuroraBorealis | can you just delete bar now? | 06:41 |
| spiv | AuroraBorealis: you can always delete it ;) | 06:41 |
| bignose | AuroraBorealis: I think perhaps you're implying “their revisions are the same” is somehow an answer to my question; it's not | 06:42 |
| AuroraBorealis | of course. | 06:42 |
| spiv | AuroraBorealis: but in that case you can delete it and not lose any revision history | 06:42 |
| AuroraBorealis | but after you merge it you can get rid of the second branch and trunk will have everything? | 06:42 |
| AuroraBorealis | kay | 06:42 |
| bignose | I know where the revisions go; I'm asking about how *else* the branches can differ :-) | 06:42 |
| bignose | and I think the answer is “their histories can differ even if they contain the same revisions” | 06:42 |
| spiv | AuroraBorealis: the only thing you lose is the association of "branch bar is at revision R" | 06:43 |
| AuroraBorealis | i'm confused now :< | 06:43 |
| spiv | bignose: no | 06:43 |
| bignose | and (spiv, here's the crucial point) a ‘pull’ or ‘push’ will *alter* the history to be identical to the other branch. | 06:43 |
| bignose | yes? | 06:43 |
| spiv | bignose: a branch's history is (in modern formats) defined by the last revision | 06:43 |
| spiv | bignose: because revisions reference their list of parents, that single revision transitively includes the whole history. And because revisions are immutable and globally unique that means if two branches have the same last revision, they have the same history. | 06:45 |
| bignose | umkay. | 06:45 |
| bignose | so my “alter the history to be identical to the other branch” is reduced to just “move the tip” | 06:46 |
| bignose | yes? | 06:46 |
| spiv | bignose: so, “their histories can differ even if they contain the same revisions” is not true unless you mean something different by one or more of those words than what we usually mean | 06:46 |
| spiv | bignose: yes. And, without using --overwrite, push and pull only allow the tip to move to include a superset of what's already there. | 06:47 |
| bignose | I'm not clear on the DAG new world order :-) so I'm trying to fit it into my learned-DVCS-from-GNU-Arch brain. | 06:47 |
| spiv | bignose: and with append_revisions_only=True set in the config, it also restricts the move of tip to only allow moves that keep existing left-hand revisions where they are (i.e. so mainline revnos are preserved) | 06:48 |
| spiv | bignose: well, Arch had an essentially similar DAG :) | 06:48 |
| spiv | AuroraBorealis: to clarify, a branch is basically just: a pointer to its last revision, plus some other bits (maybe some tags, maybe some branch.conf settings, maybe a colocated repository for holding a copy of the actual revision data) | 06:53 |
| AuroraBorealis | so branches are independent of the actual revisions? | 06:54 |
| spiv | By “actual revisions” you mean the bytes on disk holding the commit messages and changes to files, that sort of stuff? If so, yes. | 06:55 |
| AuroraBorealis | ah ok | 06:55 |
| AuroraBorealis | so like if you merge a branch to a trunk branch, you can delete the branch you merged because you don't need that 'pointer' anymore, and the revision data is still there | 06:55 |
| spiv | Look up the docs on shared repositories (e.g. bzr init-repo). “Shared” in the sense of shared between multiple branches. We call the bit that holds the actual revisions a repository. | 06:56 |
| spiv | AuroraBorealis: Right, it'll be copied into trunk's repository (assuming it's not sharing one with the other branch, in which case it'd already have them of course). | 06:56 |
| AuroraBorealis | kay | 06:57 |
| spiv | AuroraBorealis: so you'll still be able to examine old revisions with bzr explorer etc. | 06:57 |
| AuroraBorealis | cool. just been using bzr linerally so far =P | 06:57 |
| AuroraBorealis | haven't done any branching stuffs | 06:57 |
| bignose | AuroraBorealis: I'll note that when listening to future advice from you about operations between branches :-) | 07:00 |
| bignose | (seriously, thank you both for your help) | 07:01 |
| AuroraBorealis | ive read the docs just haven't done any of it :> | 07:01 |
| vila | hi guys ! | 07:45 |
| AuroraBorealis | greetings. | 07:45 |
| jam | morning vila | 08:31 |
| vila | hey jam ! | 08:31 |
| vila | jam: thanks for the windows installers !! | 08:32 |
| jam | vila: well, not done yet. Looks like the last round lost paramiko ... | 08:32 |
| vila | jam: and the bzr.dev stitching for mgz | 08:32 |
| jam | *sigh* | 08:32 |
| jam | thats why I was happy to offload the installers | 08:32 |
| vila | I know | 08:32 |
| vila | an installer specific test suite would be nice :-} | 08:33 |
| jam | vila: yeah, I tried spinning up a base Windows vm, and seeing if it would install into that | 08:33 |
| jam | but ran into troubles trying to get the admin password of a new install | 08:34 |
| jam | I think I figured it out today | 08:34 |
| jam | so I'll try that again | 08:34 |
| vila | I thought jelmer said he was on vacations this week but he was still active yesterday and the day before... | 08:35 |
| vila | he's not there anymore so maybe I got that right though | 08:35 |
| jam | vila: I remember *poolie* saying he was away | 08:36 |
| jam | not jelmer, but certainly could be | 08:36 |
| jam | and not all of us are particularly good at staying away during "vacation" :) | 08:36 |
| vila | hehe | 08:37 |
| vila | right, poolie is on a bike AIUI, hard to have useful irc discussions from there ;) | 08:37 |
| jam | vila: he has a smart phone | 08:38 |
| vila | yeah, but one hand to hold the phone plus one hand to swipe/type don't leave enough hands to drive :) | 08:38 |
| jam | vila: that's why you swype with your thumb | 08:39 |
| jam | come-on-man get it together | 08:40 |
| jam | and plus, don't you steer with your knees anyway? | 08:40 |
| vila | hehe | 08:40 |
| * maxb has written a small essay about various UDD failures of the NoSuchTag class on https://bugs.launchpad.net/udd/+bug/494481 - thoughts on how best to proceeed from there welcome | 08:41 | |
| ubot5 | Ubuntu bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] | 08:41 |
| jam | vila: do you still want to do the standup today? | 08:53 |
| jam | we can just chat in IRC if that will be easier | 08:54 |
| vila | either is fine by me, spiv ? | 08:54 |
| Riddell | good morning Bazaars | 08:56 |
| spiv | vila: hi, unfortunately I need to skip it this week (I've got to go pick up V) | 08:58 |
| jam | spiv: have a nice evening, then | 08:59 |
| vila | spiv: no worries, say hi to V ;) | 08:59 |
| === hunger_ is now known as hunger | ||
| elmo | are bzr commits atomic? | 09:22 |
| elmo | i.e. if I rsync bzr trees around and happen to catch one mid-commit, what happens? time/space implosion? | 09:22 |
| AuroraBorealis | time space implosion, definitely. | 09:23 |
| lifeless | so they are atomic, but not safe for rsync | 09:23 |
| lifeless | elmo: because rsync isn't atomic | 09:23 |
| elmo | well | 09:23 |
| elmo | bother | 09:24 |
| lifeless | elmo: more precisely the bzr commit does one action to make the commit visible and all its actions leading up to that are safe to be lost | 09:24 |
| AuroraBorealis | well why do you need rsync | 09:24 |
| AuroraBorealis | use bzr itself to sync itself between locations | 09:24 |
| elmo | we are at the moment | 09:24 |
| elmo | but we're looking at going from 3 trees to 25 trees | 09:24 |
| lifeless | elmo: the problem is that rsync doesn't guarantee that it get either all / none of those changes, and can thus either grab the core metadata file without new referenced files | 09:24 |
| elmo | and I'm worried about the speed of bzr pulling 25 trees over http | 09:25 |
| elmo | when most are no change | 09:25 |
| elmo | (we pull these every minute) | 09:25 |
| AuroraBorealis | o.o | 09:25 |
| lifeless | elmo: are they related tree or totally different ? | 09:25 |
| elmo | (I haven't done any benchmarks, my worried may be misplaced) | 09:25 |
| lifeless | elmo: anyhow, if they are mostly no-change, I suggest benching | 09:26 |
| elmo | lifeless: very much related - I suspect you're going to tell me to use LWC | 09:26 |
| lifeless | I'd expect ~0.7seconds each | 09:26 |
| lifeless | elmo: LWC ? | 09:26 |
| elmo | I'm making terms up - too tired; the light weight host lots of branches cheaply thing | 09:26 |
| lifeless | well you could | 09:27 |
| elmo | host lots of related branches, that is | 09:27 |
| AuroraBorealis | light weight checkout | 09:27 |
| lifeless | but in-dc, the 5 http requests to do a plain-http no-change pull should be pretty fast | 09:27 |
| elmo | lifeless: hmm, ok | 09:27 |
| lifeless | that is root format, repo format, branch format, branch last-revision, done | 09:27 |
| elmo | Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.35 | 09:28 |
| elmo | ok, I should probably have done that first ;-) | 09:29 |
| soren | *chuckle* | 09:34 |
| lifeless | hmm, a little slow | 09:36 |
| lifeless | :P | 09:36 |
| * soren prefers "thorough" | 09:44 | |
| vila | maxb: why is python 2.6.6-*3* required for bzr on maverick ? Or where do I find that ? | 09:49 |
| vila | maxb: hmm, apt-get build-dep bzr would be more precise | 09:49 |
| maxb | vila: In which package version exactly are you seeing this? | 09:50 |
| vila | maxb: sorry, the stable ppa one | 09:50 |
| maxb | 2.6.6-3 is the version of python-defaults in which dh_python2 was first considered ready for general use | 09:51 |
| maxb | It is thus the recommended Build-Depends for a package utilising dh_python2 | 09:51 |
| vila | and this isn't blocking the package build ? | 09:52 |
| vila | maxb: note that it's not blocking me to install a chroot but it seems weird | 09:52 |
| maxb | No, see https://launchpad.net/~bzr/+archive/builddeps/+packages | 09:52 |
| vila | maxb: Ha ! | 09:54 |
| vila | So I need to add this ppa to my chroots then right ? | 09:55 |
| htorque | hello everyone! what happened to bzr bisect? i remember installing it using apt-get some time ago, but i cannot find it anymore | 09:58 |
| vila | maxb: almost, I got: dpkg: error processing /var/cache/apt/archives/python-backport-helper_1_all.deb (--unpack): | 10:01 |
| vila | trying to overwrite '/usr/share/perl5/Debian/Debhelper/Sequence/python2.pm', which is also in package python 2.6.6-2ubuntu2 | 10:01 |
| maxb | Huh, guess it works fine in a clean chroot because the older python is never installed | 10:02 |
| vila | ha, ok, I can do that :) | 10:02 |
| vila | maxb: but you confirm I should add this ppa right ? | 10:03 |
| maxb | Depends, what are you trying to do? | 10:03 |
| vila | maxb: build a chroot where I can run the test suite | 10:03 |
| vila | I needed to add the bzr/ppa to get python-testtools | 10:04 |
| maxb | Then, no, I don't think you should be needing any of that stuff - you should only need python-backport-helper if you are trying to redo the debian package build as the ppa does it | 10:04 |
| maxb | Oh, wait, you're doing "apt-get build-dep bzr" with the bzr/ppa PPA involved? | 10:07 |
| maxb | Right, that'll give you false builddeps that you don't really want | 10:07 |
| vila | yes, that's the trigger | 10:07 |
| maxb | They're special, and there just to facilitate PPA backports of unmodified Debian sources | 10:07 |
| vila | so ? Should I just ignore the the Build-Depends error for 'apt-get build-dep bzr' ? | 10:08 |
| maxb | I think you should not use 'apt-get build-dep bzr' | 10:09 |
| vila | :-/ | 10:09 |
| vila | what should I use then ? | 10:10 |
| maxb | apt-get install some list of packages | 10:10 |
| vila | makes my life harder, but anyway, where will I find an up-to-date python-testtools ? | 10:11 |
| maxb | The Build-Depends header in the package is a reasonable guide, but you only want the upstream packages, not the debian package building infrastructure packages | 10:11 |
| lifeless | maxb: breaking apt-get build-dep bzr seems really unpleasant | 10:11 |
| maxb | There's an up to date python-testtools in the bzr/ppa | 10:12 |
| vila | hmm, so I keep the bzr-ppa and just install the dependencies without mentioning the additional constraints on the versions (like build-dep does) ? | 10:13 |
| maxb | lifeless: It's not broken, per se. Those are the packages you need to build the bzr source package in the PPA. But vila is trying to build a testsuite chroot, so only needs stuff to do with the upstream build system | 10:14 |
| vila | maxb: well, if I could use it to build the packages for the paa I wouldn't mind you know ;) | 10:15 |
| maxb | OK, so to recap: | 10:19 |
| maxb | The ~bzr PPAs use a bit of interesting hackery to permit no-source-change backports of unmodified Debian source packages even to distroseries that do not have dh_python2 | 10:20 |
| maxb | This saves a lot of work in maintaining small source modifications to every plugin package | 10:20 |
| maxb | I sent an email to the bazaar mailing list explaining some more of the details a while ago | 10:20 |
| maxb | You probably don't want the modified packages that facilitate this build approach in any other scenario that the PPA build itself, which is why they are in the bzr/builddeps PPA, which is not intended for use outside of special build environments | 10:22 |
| vila | right, so I'll try to re-recreate from scratch installing bzr and python-testtools with the bzr/ppa but without bzr/builddeps and let you know | 10:33 |
| vila | but I'll probably come back later (not today) to the point where I want to also use the same chroots to test ppa builds... | 10:34 |
| vila | maxb: I'm fine with interesting hackery as long as it doesn't blow up at the most inconvenient time ;) So it may be worth investigating the issue anyway no ? Unless you already know it's too much work | 10:36 |
| maxb | I'm not entirely convinced there *is* an issue | 10:37 |
| vila | maxb: hehe, there is at least one: *I* don't understand why I can't just use 'apt-get build-dep bzr' (I mean, I understand it doesn't work, but not the fine points nor whether this could be addressed to make it work for me ;) | 10:39 |
| vila | maxb: chroot rebuilt from scratch, seems to be working | 10:39 |
| vila | maxb: so thanks for that already ;) | 10:40 |
| maxb | I think the process should be: | 10:40 |
| maxb | 1) Create chroot | 10:40 |
| maxb | 2) Add bzr/ppa to sources.list | 10:40 |
| maxb | 3) apt-get install python-{docutils,lzma,medusa,meliae,subunit,testtools} | 10:40 |
| maxb | done | 10:40 |
| maxb | Oh, python-dev too | 10:41 |
| vila | hmm, bzr python-testtools seemed enough (so far) | 10:41 |
| maxb | If we need something more organized, we should probably use bzr-landing-dependencies | 10:42 |
| vila | mwhahahah: make: command not found :) | 10:43 |
| maxb | apt-get install build-essential | 10:43 |
| vila | maxb: how come I didn't need that for the natty chroot ? | 10:48 |
| vila | maxb: and how could I find why a package has been installed / | 10:48 |
| vila | ? | 10:48 |
| maxb | Did use use debootstrap --variant=buildd on natty but not maverick? | 10:48 |
| vila | nope, no variant at all | 10:49 |
| maxb | There's no way to find out why a package was installed. You can ask aptitude what dependencies are currently keeping it installed. aptitude why pkgname | 10:50 |
| vila | debhelper, triggered by the apt-get build-dep bzr in the natty chroot (where it worked) | 10:52 |
| maxb | right - well, there's no particular reason why you would want debhelper installed in a babune chroot afaik | 10:53 |
| vila | well, I just installed aptitude so I'm not that strict about keeping them as minimal as possible | 10:57 |
| vila | jam: I just saw python-roman being installed, didn't you encounter a related issue on windows ? (As in a missing file which may be exactly what this package provides) | 11:11 |
| jam | vila: docutils no longer provides roman, you install it separately. | 11:11 |
| jam | I filed a bug against sphinx and they pointed me in that direction | 11:12 |
| jam | the real bug is that docutils should depend on roman, or sphinx should | 11:12 |
| vila | oh, right, it's a python-docutils dep here | 11:14 |
| vila | i.e. on maverick (and natty too) | 11:14 |
| didrocks | hey | 11:47 |
| didrocks | I have a very stupid question… is it possible to have some kind of graphical file history (like bzr visualise), but just for one file? | 11:48 |
| vila | didrocks: try bzr qblame | 11:51 |
| vila | didrocks: oh wait, hmm, nothing purely gnome (before you mention it ;) | 11:52 |
| didrocks | vila: ok, I'll install the qt bindings then | 11:52 |
| didrocks | well, no worry, I can install them :-) | 11:52 |
| vila | didrocks: note that gary is very keen about sharing code between qbzr and bzr-gtk so we should get there at one point | 11:53 |
| maxb | "bzr qlog filename" works | 11:53 |
| didrocks | vila: maxb: excellent, will use qbzr waiting for the gnome equivalent if gary wants to work on it :-) | 11:53 |
| didrocks | vila: maxb: thanks! | 11:53 |
| vila | maxb: wow... they never stop to surprise me ;) | 11:54 |
| didrocks | yeah, bzr qlog was exactly what I was looking for :) | 11:54 |
| vila | didrocks: so qblame will display the same graph history than qlog <file> but only it (which may be exactly what you wanted) | 11:55 |
| didrocks | vila: you mean, only history where there is still a line from a displayed revision? | 11:56 |
| vila | the so-called per-file graph | 11:57 |
| didrocks | but bzr qlog will show me the full history of the file, even if the revision is not present anymore at all (there is no more line from that revision remaining) | 11:57 |
| didrocks | well, some kind of it, yeah :-) | 11:57 |
| vila | qblame shows you that, below the annotations | 11:57 |
| vila | bah, it's hard to describe a gui :) | 11:58 |
| didrocks | vila: ok, so it's the full per-file graph! perfect then :-) | 11:58 |
| didrocks | right, it's not that easy to describe | 11:58 |
| didrocks | thanks | 11:59 |
| Riddell | what's the machine called that does the UDD imports? I need to file the "install xz" rt ticket | 12:01 |
| vila | jubany | 12:03 |
| Riddell | vila: is there somewhere specific I need to tell them to install it? like in a chroot? | 12:03 |
| maxb | Riddell: You might want to wait on filing that RT. | 12:11 |
| Riddell | uh oh | 12:11 |
| maxb | The importer codebase is sadly lacking in XZ support. | 12:11 |
| maxb | We might want to check that it won't do something stupid if the tooling is present | 12:11 |
| Riddell | maxb: is it specific to the importer? does it just use dpkg-source -x ? | 12:11 |
| maxb | Ish. There's some interesting code in bzr-builddeb import_dsc.py (I think) that needs fixing | 12:12 |
| vila | Riddell: no chroot there (bbiab, lunch time) | 12:13 |
| maxb | So, I'm a bit annoyed by the volume of Launchpad code review email that ~bzr gets | 12:14 |
| maxb | I'm contemplating sending an email to bazaar@ suggesting that ~bzr and ~bzr-core be unsubscribe from all branches | 12:14 |
| maxb | Does that sound silly to anyone? | 12:14 |
| Riddell | by Launchpad code review e-mail you mean merge requests for bzr? | 12:15 |
| maxb | yes | 12:15 |
| maxb | (and all comments on all merge proposals) | 12:16 |
| Riddell | I seem to remember we had a conversation on Friday about unsubscribing ~bzr from that and having people just subscribe themselves | 12:16 |
| maxb | That sounds like a sensible arrangement to me | 12:17 |
| vila | didn't lp provides a mean to unsubscribe from such inherited subscriptions ? | 12:18 |
| maxb | I thought it did, but it doesn't seem to be working. And, in any case, I'm not convinced that it makes sense to email everyone about everything by default. | 12:19 |
| maxb | Well, it seems sufficiently plausible that it's worth me sending a proposal email. | 12:21 |
| lamont | lifeless: bug 788072 | 12:47 |
| ubot5 | Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,New] https://launchpad.net/bugs/788072 | 12:47 |
| vila | lamont: eeerk, sounds like a weird packaging issue, there is no way we can even run tests without bzrlib.trace and we run the tests while building the package AFAIK (slight doubt for 2.3 but I'm pretty sure we started to do that for 2.2) | 13:09 |
| lamont | vila: and it's only on that one machine | 13:14 |
| lamont | personally, I'm more interested in making it stop doing that | 13:14 |
| lamont | than in actually isolating the bug | 13:14 |
| lamont | purging and reinstalling bzr and python-bzrlib does nothing | 13:14 |
| vila | wow | 13:14 |
| james_w | circular import issue? | 13:15 |
| vila | let's try to achieve the former (which should give us some data to fix the bug anyway) | 13:15 |
| vila | lamont: can you try 'bzr -Derror <whatever command you used>' to get a pdb prompt ? | 13:17 |
| vila | james_w: occurring on a single machine ? | 13:18 |
| james_w | my guess is some other package in the namespace messing it up on that machine | 13:19 |
| vila | lamont: oh, failed_to_load_extension in the traceback | 13:19 |
| lamont | bzr -Derror help | 13:19 |
| lamont | Traceback (most recent call last): | 13:19 |
| lamont | File "/usr/bin/bzr", line 102, in <module> | 13:19 |
| lamont | import bzrlib | 13:19 |
| vila | ok, trying to load bzrlib._chunks_to_lines_pyx, so you have two issues, the root one being that we don't find the extension | 13:21 |
| vila | lamont: the missing file is therefore bzrlib/_chunks_to_lines_pyx.so under... wherever bzr has been installed | 13:22 |
| lamont | find /usr -name _chunks_to_lines_pyx.so | 13:24 |
| lamont | /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so | 13:24 |
| lamont | /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so | 13:24 |
| vila | lamont: but your traceback says usr/lib/python2.5/site-packages/bzrlib/__init__.py | 13:24 |
| vila | missing/broken symlinks ? | 13:24 |
| lamont | interestingly, the same 2 files are the only output on a working machine | 13:27 |
| vila | lamont: any symlink in /s usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ? | 13:30 |
| vila | grr | 13:30 |
| vila | lamont: any symlink in /usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ? | 13:30 |
| lamont | find /usr/lib/python2.5/site-packages/bzrlib/| wc -l | 13:31 |
| lamont | ^^ 33 lines where broken, 111 where working | 13:31 |
| lamont | sounds like a smoking gun | 13:31 |
| vila | wow, smoking shotgun even | 13:32 |
| lamont | both machines are current on their packagelist | 13:32 |
| * vila scratches head | 13:35 | |
| vila | lamont: my local hardy uses 2.3.3 and python-bzrlib is installed under s usr/lib/python2.5/site-packages/bzrlib there | 13:35 |
| vila | there is an almost empty /usr/lib/python2.5/site-packages/bzrlib containing only an empty benchmarks dir | 13:36 |
| caravel | Hello everybody | 13:37 |
| vila | lamont: that seems to rules out bzr itself (and points to a packaging issue) no ? (Happy to continue to help otherwise) | 13:37 |
| vila | caravel: _0/ | 13:38 |
| lamont | vila: except that the very same package works quite well on EVERY OTHER MACHINE I HAVE | 13:38 |
| lamont | and "reinstall the machine" seems a trifle drastically overkill | 13:38 |
| vila | lamont: different install history for *this* machine maybe ? | 13:39 |
| lamont | in the end, it could be that python-support is b0rked in ways we don't yet understand | 13:39 |
| caravel | What's the recommended permission setup, for any ssh-based host ? Is the only choice, to use ACL ? | 13:40 |
| vila | lamont: I didn't mention upgrading to 2.3.3. Not what you want right ? (Just checking) | 13:40 |
| vila | caravel: using authorized_keys with a dedicated user on the server is far better | 13:40 |
| lamont | I was kind of thinking of making 2.4.0 the next upgrade | 13:40 |
| lamont | though if 2.3.3 is out, i suppose that's actually my next upgrade | 13:41 |
| vila | it is | 13:42 |
| caravel | vila: key or password is not the issue here I believe, and each bzr client user, has a dedicated user already. This is my point : I failed to obtain something that works : I tried the sticky bis without success | 13:42 |
| vila | lamont: but I can't guarantee it will fix the issue if something else is already broken there :-/ | 13:42 |
| lamont | vila: so sounds like "moreinfo, try 2.3.3" is the appropriate status for the bug | 13:42 |
| lamont | vila: I'm 99% sure it won't fix the issue | 13:42 |
| vila | lamont: right, so no need to add noise by upgrading then | 13:43 |
| vila | caravel: you lost me here, are you using bzr+ssh ? What kind of sharing are you trying to achieve ? | 13:44 |
| vila | by 'bzr+ssh:' I mean as opposed to 'sftp:' in the URLs you use with bzr | 13:44 |
| lamont | thanks | 13:45 |
| caravel | vila: we have two groups of users, two branches and need different permissions (one brach is trunk essentially, the other is for contribs, the second user group must read.only the truck and write to contrib). So far we are using sftp://and will eventually use bzr+ssh but to my understanding this makes no difference on the server side (each user can connect over ssh also) | 13:46 |
| caravel | ( server in a Standard Ubuntu maverick ) | 13:46 |
| vila | caravel: the main difference is that the sftp server filters the mode bits while bzr+ssh executes locally and should better deal with that | 13:47 |
| caravel | vila: hah! :) | 13:47 |
| caravel | vila: thanks, I'll give it a go - but what do you mean by "the sftp server filters the mode bits" ? sftp server is standard openssh module here | 13:49 |
| vila | caravel: yup, that's the one I'm referring to (I don't remember the details though so I may be slightly wrong) | 13:50 |
| caravel | vila: ok thanks | 13:50 |
| vila | but at one point in the past that was the shared belief | 13:50 |
| vila | jam: Where do we lose the chmod bits with sftp ? ^ | 13:51 |
| caravel | My second question is : is this possible to push a repo to a remote eg. sftp area, in such a way that the latest version of all files exist *not only* within the .bzr folder ? We want to (read-only) access the pushed repo using either bzr client, but *also* over sftp when no access to history is requred | 13:54 |
| caravel | (bzr client might not be avail/installed everywhere, purpose is code review) | 13:55 |
| vila | caravel: either bzr-push-and-update or bzr-upload would satisfy that (check their docs for your exact needs) | 13:59 |
| caravel | vila: thanks, I knew I had missed something :) | 13:59 |
| vila | caravel: the former will maintain the working tree up-to-date while the later will upload *only* the working tree but not the .bzr directory | 14:00 |
| caravel | vila: but these aren't avail in tortoise interface, only cli, right ? | 14:00 |
| * caravel hasn't got a windoz to check | 14:00 | |
| vila | caravel: no idea, I don't use tortoise (and only rarely windows) | 14:01 |
| vila | caravel: should be pretty easy to add support for them to tortoise though, file a bug / | 14:01 |
| vila | ? | 14:02 |
| caravel | vila: when I was vnc'ing their workstations, I didn't see these options | 14:02 |
| caravel | vila: well, ok but they need something that works... last week :) | 14:03 |
| vila | oh cool, we can think a bit about it before replying then :) | 14:03 |
| caravel | tortoisebzr context menu isn't hackable, besides editing source code and recompiling ? | 14:04 |
| vila | no idea | 14:04 |
| caravel | hmmmm - thanks a lot for your help vila, much appreciated | 14:05 |
| vila | bzr-upload can be configured to trigger automatically though | 14:05 |
| caravel | vila: not bzr-push-and-update ? | 14:06 |
| vila | may be even both of them can be installed and configured on the server (I never did that myself though) | 14:06 |
| vila | hmm, not sure, but it seems to me that just installing the plugin will just do the right thing if the remote branch can be accessed with either sftp or bzr+ssh, worth a try | 14:08 |
| jam | vila: setgid gets stripped by openssh IIRC | 14:27 |
| vila | jam: thanks, that was my guess too, so on the server side | 14:27 |
| jam | vila: yes | 14:27 |
| jam | so it has setgid, we then issue chmod(2775) or whatever, and then it gets stripped of setgid | 14:27 |
| jam | so, for example, we are trying to change 2777 to 2755 or whatever, it ends up 755 | 14:28 |
| vila | jam: http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/ the last two failures should be obvious for you ? | 14:35 |
| jam | vila: obvious as in blame vila? | 14:35 |
| vila | really ? | 14:36 |
| jam | vila: for running an old windows, I think | 14:36 |
| vila | xp ? | 14:36 |
| jam | no, I'm just harassing you. | 14:36 |
| vila | isn't it a "can't open a file already opened" ? | 14:36 |
| vila | ha :) | 14:36 |
| jam | I could have sworn I wrote and tested those on windows | 14:36 |
| jam | vila: can't open because we locked it in another instance | 14:37 |
| vila | but the third one is for me ;) | 14:37 |
| jam | you can open a file twice, but not if it has been locked, I think | 14:37 |
| vila | jam: so just skip on windows or fix the test ? | 14:37 |
| jam | vila: I'm seeing if I can fix it | 14:38 |
| vila | jam: so, I've blacklisted one more test on babune and now we're seeing failures that occurred in the last... ~month | 14:40 |
| vila | jam: first and second failures seems weird too: permission denied on a .pack file ? huh ? | 14:41 |
| jam | vila: I have an update for "worth_saving_limit" which passes here | 14:44 |
| vila | jam: do you have a public branch for that ? (And do you want a bug # for it ? (I'm filing bugs for the other)) | 14:44 |
| jam | vila: no need for a bug, I'm proposing it now | 14:45 |
| vila | k | 14:45 |
| vila | I've filed bug #788130 for the .pack file | 14:45 |
| ubot5 | Launchpad bug 788130 in Bazaar "test_branch_local_remote failure on windows: permission denied on .pack file" [High,Confirmed] https://launchpad.net/bugs/788130 | 14:45 |
| jam | vila: https://code.launchpad.net/~jameinel/bzr/2.4-dirstate-test-on-win32/+merge/62298 | 14:46 |
| jam | vila: for this http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.test_config/TestLocationMatcher/test_file_urls_are_normalized/ | 14:47 |
| jam | /dir/subdir is, indeed, illegal on windows | 14:47 |
| jam | so probably just change the test to add "C:" or whatever | 14:47 |
| vila | probably shallow, yeah | 14:47 |
| jam | http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.commands.test_commit/TestCommitWithBoundBranch/test_commit_mine_modified/ seems more complex | 14:47 |
| jam | in the first code path, we are getting an abort | 14:48 |
| jam | because we thought we had a write stream that we are closing. | 14:48 |
| jam | but maybe that is just fallout from the other failure | 14:48 |
| vila | jam: filed bug #788131 as I'm already in the middle of mole whacking/yak shaving | 14:48 |
| ubot5 | Launchpad bug 788131 in Bazaar "TestLocationMatcher.test_file_urls_are_normalized failure on windows" [Medium,Confirmed] https://launchpad.net/bugs/788131 | 14:48 |
| jam | vila: commit_mine_modified passes here | 14:49 |
| jam | so it could be a timing thing | 14:49 |
| vila | <shudder> | 14:51 |
| jam | vila: running 10 times in a row all the tests in that module, no failures | 14:53 |
| vila | jam: I can confirm there is no virus scanner on this slave ;) | 14:54 |
| vila | jam: approved | 14:57 |
| jam | Riddell: did you need a review for "unescaped-backslash" that seems trivial enough to land | 15:01 |
| Riddell | jam: I self approved, but I feed-pqm tells me that launchpad staging is getting a code update so I can't submit it yet | 15:02 |
| jam | Riddell: I think you need a newer hydrazine | 15:03 |
| vila | eeerk, why would staging be involved there ? | 15:03 |
| jam | launchpadlib changed the signature of their connection | 15:03 |
| jam | and that caused hydrazine to start connecting to staging | 15:03 |
| Riddell | it's a bug that maxb was looking at last week | 15:03 |
| jam | Riddell: are you using packaged hydrazine or a branch? | 15:04 |
| jam | If you pull the latest hydrazine trunk, it should work correctly. | 15:04 |
| Riddell | packaged | 15:04 |
| Riddell | ok I'll do that | 15:04 |
| jam | but I went ahead and submitted it, since I was there | 15:04 |
| Riddell | thanks | 15:05 |
| maxb | Where is hydrazine packaged? | 15:06 |
| Riddell | maxb: it's in a ppa | 15:06 |
| Riddell | @hydrazine-core | 15:06 |
| Riddell | ~hydrazine-core | 15:06 |
| Riddell | but it's out of date, there's only packages for maverick | 15:06 |
| maxb | Hm | 15:06 |
| maxb | Hydrazine feels like the kind of thing that everyone should just run from the branch all the time | 15:07 |
| maxb | But if we have the PPA, it should be kept up to date | 15:07 |
| Riddell | packaged by elliot murphy back in June 2010 | 15:08 |
| jam | maxb: daily builds! | 15:12 |
| Riddell | ooh, good idea | 15:12 |
| maxb | Tempting | 15:12 |
| caravel | jam: thanks for the setgid explanation (that one was for me) -- is it only while using its sftp mod ? or just any ssh use of openssh ? | 16:05 |
| vila | jam: AFAIK https tests are passing fine on babune, I'm not sure I understand the context were you see them failing, is it with bzr.exe from the installer ? | 16:57 |
| vila | jam: in this case you may be running into an old bug where the ssl certs should be taken into account by setup, so may be it's the same bug under a different use case | 16:58 |
| vila | jam: see PKG_DATA in setup.py | 16:58 |
| vila | jam: otherwise some other piece is missing like telling... whatever server/client to use the right path to access them (but I fail to see how that could be compatible with the tests passing on babune ;) | 17:00 |
| lifeless | vila: I think its a lazy import race reporting extension loading fail | 18:58 |
| === BasicPRO is now known as BasicOSX | ||
| caravel | jam: what you mentioned about openssh, is this applicable to sftp only or also to bzr+ssh ? | 19:16 |
| jam | caravel: sftp only | 19:16 |
| workthrick | hiya | 19:17 |
| workthrick | $ bzr dpush git+ssh://git@github.com/mathrick/cl-cairo2.git | 19:17 |
| workthrick | Permission denied (publickey). | 19:17 |
| workthrick | bzr: ERROR: The remote server unexpectedly closed the connection. | 19:17 |
| workthrick | I checked, and the key I'm using is properly setup, I can login using putty | 19:17 |
| AuroraBorealis | i had this problem where it was using a bad version of ssh. | 19:17 |
| workthrick | I also know that bzr uses paramiko + pageant properly for other connections | 19:17 |
| workthrick | (ie. sftp://) | 19:17 |
| workthrick | is there a possibility that dpush and/or git+ssh:// are somehow not using paramiko? | 19:18 |
| workthrick | hmm, actually I can see they aren't, since paramiko is very noise on connecting | 19:18 |
| caravel | jam: thanks alot. And using sftp, is the only way around, to use ACL, then ? | 19:18 |
| workthrick | but why? | 19:18 |
| AuroraBorealis | i installed git on windows | 19:18 |
| AuroraBorealis | and it put like a weird version of ssh.exe in its folder | 19:18 |
| workthrick | I don't want to touch git, especially on windows | 19:18 |
| AuroraBorealis | and that was in the path, so bzr was using that instead of its own | 19:18 |
| workthrick | ah, ok | 19:18 |
| AuroraBorealis | so suddenly bzr wasn't working with ssh stuff | 19:19 |
| AuroraBorealis | so see if there is any other ssh'es in your path? :o | 19:19 |
| workthrick | AuroraBorealis: I can still connect over sftp://, it just doesn't respect BZR_SSH for dpush somehow | 19:19 |
| AuroraBorealis | hmm. ive never used dpush so i dunno :< | 19:19 |
| workthrick | you have to if you want to push to git | 19:20 |
| jam | workthrick: bug #670035 | 19:21 |
| ubot5 | Launchpad bug 670035 in Dulwich "git+ssh doesn't work on Windows" [Medium,Triaged] https://launchpad.net/bugs/670035 | 19:21 |
| jam | caravel: I believe if the permissions are already correct, we don't chmod | 19:22 |
| jam | so if you set umask, etc, it might just work for you | 19:22 |
| AuroraBorealis | hmm =/ | 19:22 |
| jam | which you can do in an sftp wrapper | 19:22 |
| jam | caravel: http://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions | 19:22 |
| caravel | jam: thanks (umask isn't an option here, it's only for a given space) | 19:22 |
| caravel | jam: ok - I see (reading) | 19:23 |
| caravel | jam: well no, we can't do that :( unless defining distinct users just for bzr -- and we don't want this. I'm a bit surprised since I was expectig that to be a very common need, but found it hard to find some info | 19:26 |
| caravel | so I'll try the acl route -- but that one is fine, right jam ? | 19:27 |
| workthrick | jam: ah, I see | 19:27 |
| jam | caravel: I haven't tried it | 19:27 |
| jam | http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/index.html | 19:27 |
| workthrick | that's a pity, but I can probably work around it | 19:27 |
| jam | generally we recommend away from sftp once you can, because it really doesn't scale well | 19:28 |
| jam | once the project is big, the performance goes way down | 19:28 |
| jam | it is better than ftp, but that isn't saying much | 19:28 |
| AuroraBorealis | there is also little to no documentation on the smart server =/ | 19:30 |
| workthrick | jam: any idea why paramiko doesn't get used here? I don't know how the transport stacking works in bzr | 19:31 |
| jam | workthrick: I don't know. Presumably the low levels of dulwich don't use bzr transports | 19:39 |
| workthrick | ok, so I solved it by transplanting ~/.ssh from linux, only to hit bug #626341 | 19:43 |
| ubot5 | Launchpad bug 626341 in Bazaar Git Plugin ""ValueError: too many values to unpack" when pushing to github" [High,Fix released] https://launchpad.net/bugs/626341 | 19:43 |
| * workthrick sighs | 19:43 | |
| AuroraBorealis | well it says fix released? | 19:44 |
| workthrick | yes, but I need to update, which probably means upgrading bzr, which is a royal PITA on windows | 19:44 |
| workthrick | because I'm running the non-standalone version | 19:45 |
| caravel | jam: ok, I understand. But say that one want to setup, as well as the bzr thing, a functional sftp *anyway* on the same machine (for basic file sharing), with multiple groups etc. Then ACL is a must, then sftp might be used okay, right ? Or would you do that differently ? | 19:45 |
| AuroraBorealis | cant you just use the installer? | 19:45 |
| caravel | (I meant : then sftp might be used okay for bzr also, right ?) | 19:46 |
| * caravel wonders if *anyone* is using bzr and sftp with the same openssh instance (??) | 19:47 | |
| * fullermd killed off using sftp with bzr with great glee when bzr+ssh became a possibility... | 19:48 | |
| LeoNerd | I only did that when it was actually faster to do so :P | 19:48 |
| LeoNerd | My Celeron 333 server was -waaaaay- faster at running sftp, that it didn't matter the extra roundtrips and bandwidth | 19:49 |
| * caravel meant : is *anyone* using bzr+ssh as well as standard sftp, using the same openssh instance ? :) | 19:49 | |
| caravel | (i.e. standard sftp client) | 19:49 |
| fullermd | I don't use sftp much; easier to scp or rsync mostly. But I've used it occasionally. Not sure what cross-impact it might have on bzr+ssh though. | 19:51 |
| caravel | I mean, if standard sftp requires acl for multiple user groups, and if acl permits the use of bzr over sftp also, THEN, yes, bzr+ssh is still better, but not strictly mandatory (or do I get this entirely wrong ?) | 19:52 |
| * fullermd suspects there's background in scrollback he hasn't read. | 19:52 | |
| fullermd | I always just assume bzr+ssh is mandatory, really. sftp is an available emergency fallback, whose use means "something is wrong". | 19:52 |
| caravel | Defining this thing to the opposite : with multiple branches on the same "ssh space", without acl THEN sftp is simply not an option, right ? | 19:53 |
| fullermd | Of course, the setgid issue with sftp-server wouldn't affect me anyway. | 19:53 |
| LeoNerd | I found that on a slow server, sftp is faster, generally, because the server's sftp server is nicely C code, whereas having to spin up python and bzr to run the server, slowed it down | 19:54 |
| fullermd | Well, the load isn't spinning up python, it's that the server is doing something other than "read from disk; write to network". | 19:55 |
| maxb | It needs to be a pretty slow server and a pretty fast network connection for sftp to win out | 19:56 |
| workthrick | AuroraBorealis: no, since I wanted to use bzr-git, and that needs dulwhich | 19:56 |
| * caravel hasn't found any hint in the documentation about such limitation : I understand this is not really a bzr issue, but still : one -- like me :-) might have thought « okay, we need sftp anyway, so the quickest way to get that bzr running will be that one ». [...] | 19:56 | |
| AuroraBorealis | ah. | 19:56 |
| workthrick | I have since learnt you can use _lib inside the plugin's dir for that, so I might try that next time | 19:56 |
| workthrick | but now I just switched to linux, upgraded its bzr, and pushed from there | 19:57 |
| * workthrick hugs the VM | 19:57 | |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === mwhudson_ is now known as mwhudson | ||
| mgz | vila: saying bb:tweak to riddell is a little perverse even if you explain what you mean by it | 21:58 |
| vila | hmm, why ? I thought he needed to learn the acronym as I don't think we;ll stop using it. No ? | 22:00 |
| vila | mgz: by the way, I was about to switch back to lazy_hook_test_cleanup_785054 which made my eyes bleed earlier today ;-D | 22:01 |
| mgz | it seems mostly useful to people who've actually used bundle buggy in the past. | 22:01 |
| vila | mgz: right. | 22:02 |
| mgz | ^yeah... I think I just need to step through in a debugger or something to work out what the hell is going on | 22:02 |
| vila | I'll ask him here tomorrow to make sure he understand what I meant | 22:02 |
| mgz | testtools is a pain to follow in pdb though, it's got so many layers of helpers calling helpers | 22:02 |
| vila | but why not just use overrideAttr and forget about _restoreHooks ? | 22:03 |
| mgz | changing the hook cleanup method completely is a good idea. | 22:04 |
| vila | oh, and what makes it hard to review is that tests are failing so I don't know which failures I should really expect 8-) | 22:04 |
| mgz | I'm just not sure what the current code is actually doing, which makes me a little scared of replacing it. | 22:04 |
| vila | AFAIK it removes all hooks for the duration of the test, | 22:05 |
| vila | except for the ones that should really be left there :D | 22:05 |
| mgz | the tests are nicely commented as to which ones are failing, the why is the hard bit. | 22:05 |
| vila | ok, let me try again | 22:06 |
| vila | ./bzr selftest -s bt.test_selftest.TestHookIsolation -> 6 tests, 3 failures | 22:07 |
| vila | expected ? | 22:07 |
| mgz | yup, though I don't know why for the test_*_artificial cases | 22:08 |
| mgz | the hooks.known_hooks logic is saving the locks hooks even when the lazy restoration code is doing the wrong thing. | 22:09 |
| vila | starting with test_dict__lazy_hooks_restored | 22:11 |
| vila | you're already protected there so the failure doesn't surprise me | 22:11 |
| vila | err, wait | 22:12 |
| vila | :) | 22:12 |
| mgz | that one fails because the cleanup added for lazy hooks is wrong, but the confusing aspect is test_lazy_hooks_unregistered_lock does *not* fail | 22:12 |
| mgz | even though the cleanup for lazy hooks is wrong | 22:13 |
| mgz | because the hooks in the known_hooks list are covered by the old hooks cleanup code anyway | 22:14 |
| vila | why and where should test_lazy_hooks_unregistered_lock fail ? | 22:16 |
| mgz | because the code added in _restoreHooks for lazy hooks doesn't set self._preserved_lazy_hooks back to the correct place | 22:17 |
| vila | because it should call the hook that you think should still be there ? | 22:17 |
| mgz | what's the reasoning for the way the current hooks test isolation code is written? | 22:21 |
| mgz | why not just blow them all away for the context of a test? | 22:22 |
| mgz | (and optionally re-add the essential ones) | 22:22 |
| vila | 1) no idea | 22:22 |
| vila | 2) that's what I was aking you :) | 22:22 |
| vila | well for 1), I think it predates overrideAttr and was not recognized as a possible call site that could use it | 22:25 |
| vila | err, wait a minute, why is iter_parent_objects() used twice ?? | 22:27 |
| mgz | first is to get the current hooks, then to set a blank factory on the hook point | 22:29 |
| mgz | if I have the terminology right | 22:29 |
| mgz | also, it's somewhat confused by the behaviour changing with the adding of lazy hooks | 22:29 |
| mgz | I'm still not certain what's stored as attributes on Hook classes and what's in that _lazy_hooks dict | 22:30 |
| mgz | I think the intention is everything's now in the one dict. | 22:31 |
| mgz | which should mean it's safe to simplify the test isolation | 22:31 |
| vila | what's blank factory ? | 22:32 |
| mgz | but I don't understand why the two failing tests aren't working | 22:32 |
| mgz | ^a hook class by the look of it | 22:33 |
| vila | but why do you say blank ? Looks like the real thing to me | 22:34 |
| mgz | as in, with no callbacks set | 22:35 |
| mgz | though this is complicated by the api change, I really don't know what's going on now | 22:36 |
| vila | ha, right, yes, blank factory, ok got it | 22:39 |
| vila | so in effect, this reset all the hooks indeed | 22:41 |
| vila | this guarantees that you will always get a result when querying the registry, but start afresh without any hook points | 22:41 |
| vila | a two-level dict if you prefer so we can't just do self.overrideAttr(hooks, 'known_hooks', KnownHooksRegistry()) | 22:42 |
| mgz | right. | 22:43 |
| mgz | and I'm not clear on what 'known_hooks' consitutes. are all usabled hooks nessersarily found there? | 22:44 |
| mgz | because otherwise it looks like we're only protecting the basic bzrlib hooks and not any added by plugins etc | 22:45 |
| vila | err, plugins we are getting rid of the hook points, only bzrlib defines hooks AFAIK (and if I get the names right ;) | 22:50 |
| vila | meh s/plugins// | 22:51 |
| vila | so there is a single hook point that is preserved: the smart request one to check the server jail | 22:52 |
| mgz | okay then, if _builtin_known_hooks is intended to be exhastive, I think I can just delete the _lazy_hooks dictionary overriding, and the two *_artificial tests | 22:53 |
| vila | I'm pretty sure _builtin_known_hooks is exhaustive | 22:55 |
| vila | at least as far as testing bzrlib goes | 22:55 |
| vila | and I always considered that to test a hook point you *had* to install it during the test | 22:56 |
| mgz | so what I'm doing with _TestingHooks in those tests is just bogus because it's not named in _builtin_known_hooks? | 23:00 |
| vila | haaa, could be, you don't even register it no ? | 23:01 |
| mgz | I call install_named_hook or install_lazy_named_hook | 23:02 |
| vila | ghaa, right, I think a lot of confusion is coming from hook/hookpoint and not even respecting that in all method names | 23:02 |
| vila | but that's one level below | 23:02 |
| vila | you've just defined a Hook that is not protected and inside that you add hookpoints | 23:03 |
| vila | it's not a two-level dict, it's a two-level registry | 23:08 |
| vila | this may be worth refactoring for clarity but the compatibility issues might be... interesting | 23:10 |
| vila | mgz: I'm crashing :-/ | 23:12 |
| mgz | sleep! | 23:13 |
| vila | mgz: did this discussion clarify things a bit ? (It did for me at least but I'm not fresh enough to explain it properly I fear) | 23:13 |
| mgz | I think so. | 23:14 |
| vila | the lazy_hooks are really hookpoints I think and don't require as much care (single level) | 23:15 |
| * vila off | 23:16 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!