[00:18] 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] Too scared to accept the commit because it's for work :) [00:19] backup the branches before you do it :o [00:21] 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:22] that seems right [00:22] just merge them [01:32] What are the last two numbers in this? Stage:Fetching revisions:Inserti.. 6664/961 [01:33] probably 'chunks' of data or something [01:33] AuroraBorealis: Yeah, just not sure what the units are. [01:35] objects [01:36] SERIES OF TUBES [01:36] lifeless: So why is the numerator larger than the denominator? [01:37] KombuchaKip: its not a fraction [01:37] lifeless: What's it mean? [01:37] yeah haha [01:37] seems like random mnumbers [01:37] total-needed / received[or sent if pushing] [01:38] lifeless: Shouldn't they have flipped it to make it more intuitive? [01:39] KombuchaKip: feel free to file a bug [01:39] lifeless: heh [01:39] lifeless: It's not really important. [01:39] sure, its still changable though :) [01:39] yeah i feel like they should add units at least [01:40] mm [01:43] Actually, I think the units are there, sorta. There's in the continuation of "Inserti...". [01:44] All you need is a 300 char wide term. === mwhudson_ is now known as mwhudson [06:13] <_thumper_> poolie: ping === _thumper_ is now known as thumper [06:21] I have a branch ‘bar’ branched from ‘trunk’. no additional revisions have yet been committed to ‘bar’. [06:22] now I realise that ‘trunk’ needs some more revisions from upstream; ‘cd ../trunk/ && bzr update’ [06:22] at this point, is there a difference between: [06:22] ‘cd ../ && rm -r bar/ && bzr branch trunk/ bar/’ [06:23] ‘cd ../bar/ && bzr pull ../trunk/’ [06:23] No. [06:23] nope. [06:23] okay. so at what point, and how, does ‘bar’ have its own history? [06:23] i would think bar would have its own history. [06:24] you updated trunk but bar didn't recieve that update [06:24] so trunk and bar are the same up to the point where you branched it [06:24] Define "own"? It has its own history, it just happens to (currently) be identical to trunk's. [06:24] except for the latest update [06:25] so if ‘bar’ gains additional revisions, then ‘trunk’ merges from ‘bar’ [06:25] at that point ‘bar’ and ‘trunk’ will contain the same revisions but different history, yes? [06:25] (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] (‘trunk’ will of course contain a merge commit) [06:26] if you commit anything to bar, trunk wont get it unless you merge it back into trunk [06:26] Right, so trunk contains all the same revisions *plus* that one merge revision. [06:26] yeah, once you merge it back [06:26] it will gain all the revisions that bar had [06:26] it contains them. is that identical to saying they have the same history? I thought not. [06:26] and then if you visualize it you will see the bar branch diverting [06:26] to the side then merging back [06:28] I almost never use ‘bzr pull’ and I'm trying to understand what effect it has, in terms of the above story. [06:28] 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] pull clones [06:28] bignose: ah, now for 'bzr pull' I can give an unqualified answer :) [06:28] bignose: it never generates a new revision, whereas merge+commit does [06:29] cause pull just clones whatever you are pulling [06:29] bignose: its primary use case is for when you have a branch you are maintaining as a mirror of another branch. [06:29] okay, so what will it do in the story above? i.e., ‘cd ../bar/ && bzr pull’ will do what to the history? [06:30] it will mirror the history of whatever you are pulling [06:30] and is it different if ‘bar’ is already divergent from ‘trunk’? [06:30] bar will still be diverged [06:30] wont effect it [06:30] bignose: a) check that bar and trunk haven't diverged (if they have it stops with an error) [06:31] spiv: so if ‘trunk’ has merged all revisions from ‘bar’, then ‘bar’ still won't be able to pull from ‘trunk’? [06:31] 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:32] another way of asking: is a branch still “diverged from trunk if trunk has merged from that other branch? [06:32] they are different but they have the same revisions [06:32] bignose: actually, it can, that case isn't divergence: trunk's tip includes all of bar's tip's history. [06:32] if oyu visualize it, it will be a different line [06:32] like when you first branched it, bar will go off to the side, when you merge it, the lines will merge [06:33] AuroraBorealis: so you're saying ‘pull’ *doesn't* mirror the history? [06:33] 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] i dunno what pull would do if you have already made changes. i would just update :> [06:34] AuroraBorealis: neither ‘trunk’ nor ‘bar’ are checkous from each other, so update would not transfer anything between them. [06:34] no but trunk is a checkout from like upstream right [06:34] if you made changes in trunk, then tried pulling from upstream again, i dunno what would happen [06:35] i thought pull and push make it an exact mirror of whatever. [06:35] bignose: perhaps I should have phrased step a as: a) check all of bar's history is included in trunk. [06:36] AuroraBorealis: that contradicts your “bar will still be diverged, wont effect it” [06:36] or I'm not understanding you. [06:36] uhhh [06:36] you branch from upstream [06:36] no [06:36] trunk is bound to upstream [06:36] not branched [06:36] well [06:36] it can be branched from upstream and bound [06:37] so same thing [06:37] so anyway, trunk is bound to upstream [06:37] you branch trunk [06:37] so now trunk upstream and bar are the same [06:37] but they are 3 seperate branches [06:37] bignose: it's pretty easy to make a couple of toy branches and experiment with what happens. [06:37] then you start making changes to bar [06:37] then it becomes its own thing [06:37] and then you merge it back into trunk [06:37] bignose: although I hope my description is adequately clear. [06:38] i dont know if they are the SAME now, but trunk will now have the revisions of bar [06:38] 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:39] Although I see I've basically just restated the contents of "bzr help pull" :) [06:40] xD [06:41] As far as "the same": if two branches have the same last revision, then by definition they have the same revision history. [06:41] so here is another question :o [06:41] spiv: I think your explanation is clear [06:41] 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] can you just delete bar now? [06:41] AuroraBorealis: you can always delete it ;) [06:42] AuroraBorealis: I think perhaps you're implying “their revisions are the same” is somehow an answer to my question; it's not [06:42] of course. [06:42] AuroraBorealis: but in that case you can delete it and not lose any revision history [06:42] but after you merge it you can get rid of the second branch and trunk will have everything? [06:42] kay [06:42] I know where the revisions go; I'm asking about how *else* the branches can differ :-) [06:42] and I think the answer is “their histories can differ even if they contain the same revisions” [06:43] AuroraBorealis: the only thing you lose is the association of "branch bar is at revision R" [06:43] i'm confused now :< [06:43] bignose: no [06:43] and (spiv, here's the crucial point) a ‘pull’ or ‘push’ will *alter* the history to be identical to the other branch. [06:43] yes? [06:43] bignose: a branch's history is (in modern formats) defined by the last revision [06:45] 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] umkay. [06:46] so my “alter the history to be identical to the other branch” is reduced to just “move the tip” [06:46] yes? [06:46] 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:47] 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] 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:48] 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] bignose: well, Arch had an essentially similar DAG :) [06:53] 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:54] so branches are independent of the actual revisions? [06:55] 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] ah ok [06:55] 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:56] 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] 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:57] kay [06:57] AuroraBorealis: so you'll still be able to examine old revisions with bzr explorer etc. [06:57] cool. just been using bzr linerally so far =P [06:57] haven't done any branching stuffs [07:00] AuroraBorealis: I'll note that when listening to future advice from you about operations between branches :-) [07:01] (seriously, thank you both for your help) [07:01] ive read the docs just haven't done any of it :> [07:45] hi guys ! [07:45] greetings. [08:31] morning vila [08:31] hey jam ! [08:32] jam: thanks for the windows installers !! [08:32] vila: well, not done yet. Looks like the last round lost paramiko ... [08:32] jam: and the bzr.dev stitching for mgz [08:32] *sigh* [08:32] thats why I was happy to offload the installers [08:32] I know [08:33] an installer specific test suite would be nice :-} [08:33] vila: yeah, I tried spinning up a base Windows vm, and seeing if it would install into that [08:34] but ran into troubles trying to get the admin password of a new install [08:34] I think I figured it out today [08:34] so I'll try that again [08:35] I thought jelmer said he was on vacations this week but he was still active yesterday and the day before... [08:35] he's not there anymore so maybe I got that right though [08:36] vila: I remember *poolie* saying he was away [08:36] not jelmer, but certainly could be [08:36] and not all of us are particularly good at staying away during "vacation" :) [08:37] hehe [08:37] right, poolie is on a bike AIUI, hard to have useful irc discussions from there ;) [08:38] vila: he has a smart phone [08:38] yeah, but one hand to hold the phone plus one hand to swipe/type don't leave enough hands to drive :) [08:39] vila: that's why you swype with your thumb [08:40] come-on-man get it together [08:40] and plus, don't you steer with your knees anyway? [08:40] hehe [08:41] * 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] Ubuntu bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] [08:53] vila: do you still want to do the standup today? [08:54] we can just chat in IRC if that will be easier [08:54] either is fine by me, spiv ? [08:56] good morning Bazaars [08:58] vila: hi, unfortunately I need to skip it this week (I've got to go pick up V) [08:59] spiv: have a nice evening, then [08:59] spiv: no worries, say hi to V ;) === hunger_ is now known as hunger [09:22] are bzr commits atomic? [09:22] i.e. if I rsync bzr trees around and happen to catch one mid-commit, what happens? time/space implosion? [09:23] time space implosion, definitely. [09:23] so they are atomic, but not safe for rsync [09:23] elmo: because rsync isn't atomic [09:23] well [09:24] bother [09:24] 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] well why do you need rsync [09:24] use bzr itself to sync itself between locations [09:24] we are at the moment [09:24] but we're looking at going from 3 trees to 25 trees [09:24] 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:25] and I'm worried about the speed of bzr pulling 25 trees over http [09:25] when most are no change [09:25] (we pull these every minute) [09:25] o.o [09:25] elmo: are they related tree or totally different ? [09:25] (I haven't done any benchmarks, my worried may be misplaced) [09:26] elmo: anyhow, if they are mostly no-change, I suggest benching [09:26] lifeless: very much related - I suspect you're going to tell me to use LWC [09:26] I'd expect ~0.7seconds each [09:26] elmo: LWC ? [09:26] I'm making terms up - too tired; the light weight host lots of branches cheaply thing [09:27] well you could [09:27] host lots of related branches, that is [09:27] light weight checkout [09:27] but in-dc, the 5 http requests to do a plain-http no-change pull should be pretty fast [09:27] lifeless: hmm, ok [09:27] that is root format, repo format, branch format, branch last-revision, done [09:28] Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.35 [09:29] ok, I should probably have done that first ;-) [09:34] *chuckle* [09:36] hmm, a little slow [09:36] :P [09:44] * soren prefers "thorough" [09:49] maxb: why is python 2.6.6-*3* required for bzr on maverick ? Or where do I find that ? [09:49] maxb: hmm, apt-get build-dep bzr would be more precise [09:50] vila: In which package version exactly are you seeing this? [09:50] maxb: sorry, the stable ppa one [09:51] 2.6.6-3 is the version of python-defaults in which dh_python2 was first considered ready for general use [09:51] It is thus the recommended Build-Depends for a package utilising dh_python2 [09:52] and this isn't blocking the package build ? [09:52] maxb: note that it's not blocking me to install a chroot but it seems weird [09:52] No, see https://launchpad.net/~bzr/+archive/builddeps/+packages [09:54] maxb: Ha ! [09:55] So I need to add this ppa to my chroots then right ? [09:58] hello everyone! what happened to bzr bisect? i remember installing it using apt-get some time ago, but i cannot find it anymore [10:01] maxb: almost, I got: dpkg: error processing /var/cache/apt/archives/python-backport-helper_1_all.deb (--unpack): [10:01] trying to overwrite '/usr/share/perl5/Debian/Debhelper/Sequence/python2.pm', which is also in package python 2.6.6-2ubuntu2 [10:02] Huh, guess it works fine in a clean chroot because the older python is never installed [10:02] ha, ok, I can do that :) [10:03] maxb: but you confirm I should add this ppa right ? [10:03] Depends, what are you trying to do? [10:03] maxb: build a chroot where I can run the test suite [10:04] I needed to add the bzr/ppa to get python-testtools [10:04] 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:07] Oh, wait, you're doing "apt-get build-dep bzr" with the bzr/ppa PPA involved? [10:07] Right, that'll give you false builddeps that you don't really want [10:07] yes, that's the trigger [10:07] They're special, and there just to facilitate PPA backports of unmodified Debian sources [10:08] so ? Should I just ignore the the Build-Depends error for 'apt-get build-dep bzr' ? [10:09] I think you should not use 'apt-get build-dep bzr' [10:09] :-/ [10:10] what should I use then ? [10:10] apt-get install some list of packages [10:11] makes my life harder, but anyway, where will I find an up-to-date python-testtools ? [10:11] 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] maxb: breaking apt-get build-dep bzr seems really unpleasant [10:12] There's an up to date python-testtools in the bzr/ppa [10:13] 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:14] 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:15] maxb: well, if I could use it to build the packages for the paa I wouldn't mind you know ;) [10:19] OK, so to recap: [10:20] 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] This saves a lot of work in maintaining small source modifications to every plugin package [10:20] I sent an email to the bazaar mailing list explaining some more of the details a while ago [10:22] 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:33] 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:34] 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:36] 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:37] I'm not entirely convinced there *is* an issue [10:39] 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] maxb: chroot rebuilt from scratch, seems to be working [10:40] maxb: so thanks for that already ;) [10:40] I think the process should be: [10:40] 1) Create chroot [10:40] 2) Add bzr/ppa to sources.list [10:40] 3) apt-get install python-{docutils,lzma,medusa,meliae,subunit,testtools} [10:40] done [10:41] Oh, python-dev too [10:41] hmm, bzr python-testtools seemed enough (so far) [10:42] If we need something more organized, we should probably use bzr-landing-dependencies [10:43] mwhahahah: make: command not found :) [10:43] apt-get install build-essential [10:48] maxb: how come I didn't need that for the natty chroot ? [10:48] maxb: and how could I find why a package has been installed / [10:48] ? [10:48] Did use use debootstrap --variant=buildd on natty but not maverick? [10:49] nope, no variant at all [10:50] 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:52] debhelper, triggered by the apt-get build-dep bzr in the natty chroot (where it worked) [10:53] right - well, there's no particular reason why you would want debhelper installed in a babune chroot afaik [10:57] well, I just installed aptitude so I'm not that strict about keeping them as minimal as possible [11:11] 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] vila: docutils no longer provides roman, you install it separately. [11:12] I filed a bug against sphinx and they pointed me in that direction [11:12] the real bug is that docutils should depend on roman, or sphinx should [11:14] oh, right, it's a python-docutils dep here [11:14] i.e. on maverick (and natty too) [11:47] hey [11:48] 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:51] didrocks: try bzr qblame [11:52] didrocks: oh wait, hmm, nothing purely gnome (before you mention it ;) [11:52] vila: ok, I'll install the qt bindings then [11:52] well, no worry, I can install them :-) [11:53] 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] "bzr qlog filename" works [11:53] vila: maxb: excellent, will use qbzr waiting for the gnome equivalent if gary wants to work on it :-) [11:53] vila: maxb: thanks! [11:54] maxb: wow... they never stop to surprise me ;) [11:54] yeah, bzr qlog was exactly what I was looking for :) [11:55] didrocks: so qblame will display the same graph history than qlog but only it (which may be exactly what you wanted) [11:56] vila: you mean, only history where there is still a line from a displayed revision? [11:57] the so-called per-file graph [11:57] 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] well, some kind of it, yeah :-) [11:57] qblame shows you that, below the annotations [11:58] bah, it's hard to describe a gui :) [11:58] vila: ok, so it's the full per-file graph! perfect then :-) [11:58] right, it's not that easy to describe [11:59] thanks [12:01] what's the machine called that does the UDD imports? I need to file the "install xz" rt ticket [12:03] jubany [12:03] vila: is there somewhere specific I need to tell them to install it? like in a chroot? [12:11] Riddell: You might want to wait on filing that RT. [12:11] uh oh [12:11] The importer codebase is sadly lacking in XZ support. [12:11] We might want to check that it won't do something stupid if the tooling is present [12:11] maxb: is it specific to the importer? does it just use dpkg-source -x ? [12:12] Ish. There's some interesting code in bzr-builddeb import_dsc.py (I think) that needs fixing [12:13] Riddell: no chroot there (bbiab, lunch time) [12:14] So, I'm a bit annoyed by the volume of Launchpad code review email that ~bzr gets [12:14] I'm contemplating sending an email to bazaar@ suggesting that ~bzr and ~bzr-core be unsubscribe from all branches [12:14] Does that sound silly to anyone? [12:15] by Launchpad code review e-mail you mean merge requests for bzr? [12:15] yes [12:16] (and all comments on all merge proposals) [12:16] I seem to remember we had a conversation on Friday about unsubscribing ~bzr from that and having people just subscribe themselves [12:17] That sounds like a sensible arrangement to me [12:18] didn't lp provides a mean to unsubscribe from such inherited subscriptions ? [12:19] 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:21] Well, it seems sufficiently plausible that it's worth me sending a proposal email. [12:47] lifeless: bug 788072 [12:47] Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,New] https://launchpad.net/bugs/788072 [13:09] 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:14] vila: and it's only on that one machine [13:14] personally, I'm more interested in making it stop doing that [13:14] than in actually isolating the bug [13:14] purging and reinstalling bzr and python-bzrlib does nothing [13:14] wow [13:15] circular import issue? [13:15] let's try to achieve the former (which should give us some data to fix the bug anyway) [13:17] lamont: can you try 'bzr -Derror ' to get a pdb prompt ? [13:18] james_w: occurring on a single machine ? [13:19] my guess is some other package in the namespace messing it up on that machine [13:19] lamont: oh, failed_to_load_extension in the traceback [13:19] bzr -Derror help [13:19] Traceback (most recent call last): [13:19] File "/usr/bin/bzr", line 102, in [13:19] import bzrlib [13:21] 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:22] lamont: the missing file is therefore bzrlib/_chunks_to_lines_pyx.so under... wherever bzr has been installed [13:24] find /usr -name _chunks_to_lines_pyx.so [13:24] /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so [13:24] /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so [13:24] lamont: but your traceback says usr/lib/python2.5/site-packages/bzrlib/__init__.py [13:24] missing/broken symlinks ? [13:27] interestingly, the same 2 files are the only output on a working machine [13:30] lamont: any symlink in /s usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ? [13:30] grr [13:30] lamont: any symlink in /usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ? [13:31] find /usr/lib/python2.5/site-packages/bzrlib/| wc -l [13:31] ^^ 33 lines where broken, 111 where working [13:31] sounds like a smoking gun [13:32] wow, smoking shotgun even [13:32] both machines are current on their packagelist [13:35] * vila scratches head [13:35] lamont: my local hardy uses 2.3.3 and python-bzrlib is installed under s usr/lib/python2.5/site-packages/bzrlib there [13:36] there is an almost empty /usr/lib/python2.5/site-packages/bzrlib containing only an empty benchmarks dir [13:37] Hello everybody [13:37] lamont: that seems to rules out bzr itself (and points to a packaging issue) no ? (Happy to continue to help otherwise) [13:38] caravel: _0/ [13:38] vila: except that the very same package works quite well on EVERY OTHER MACHINE I HAVE [13:38] and "reinstall the machine" seems a trifle drastically overkill [13:39] lamont: different install history for *this* machine maybe ? [13:39] in the end, it could be that python-support is b0rked in ways we don't yet understand [13:40] What's the recommended permission setup, for any ssh-based host ? Is the only choice, to use ACL ? [13:40] lamont: I didn't mention upgrading to 2.3.3. Not what you want right ? (Just checking) [13:40] caravel: using authorized_keys with a dedicated user on the server is far better [13:40] I was kind of thinking of making 2.4.0 the next upgrade [13:41] though if 2.3.3 is out, i suppose that's actually my next upgrade [13:42] it is [13:42] 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] lamont: but I can't guarantee it will fix the issue if something else is already broken there :-/ [13:42] vila: so sounds like "moreinfo, try 2.3.3" is the appropriate status for the bug [13:42] vila: I'm 99% sure it won't fix the issue [13:43] lamont: right, so no need to add noise by upgrading then [13:44] caravel: you lost me here, are you using bzr+ssh ? What kind of sharing are you trying to achieve ? [13:44] by 'bzr+ssh:' I mean as opposed to 'sftp:' in the URLs you use with bzr [13:45] thanks [13:46] 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] ( server in a Standard Ubuntu maverick ) [13:47] 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] vila: hah! :) [13:49] 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:50] 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] vila: ok thanks [13:50] but at one point in the past that was the shared belief [13:51] jam: Where do we lose the chmod bits with sftp ? ^ [13:54]