[00:25] good evening, people. Is there any ftps plugin as yet ? (is this blueprint still actual ? https://blueprints.launchpad.net/bzr/+spec/tls-and-ssl-support) [00:27] caravel: we don't really work off of blueprints [00:28] caravel: I don't think ftps has been implemented, https is defintely supported - that blueprint is totally inaccurate. [00:28] lifeless: fair enough - thanks for your answer - that's about all I found on the subject really, googled a few times already over the past weeks [00:29] caravel: we support sftp which is: [00:29] - faster [00:29] - simpler [00:29] - more widespread than ftps [00:29] caravel: and we support https [00:29] and bzr+ssh, which we recommend [00:29] but unsupported by FileZilla Server -- which is extremely popular ;-) [00:30] I suggest you file a bug [00:31] the core dev team work largely off bug backlogs [00:31] rather than specs [00:31] we use spec when planning complex things with unpredictable interactions. [00:33] lifeless: I guess it's not a wide requirement anyway -- fedora 13 here, could I bazaar over some ftps mount transparently ? [00:33] (just a thought) [00:35] caravel: you should be able to push/pull over an ftps fuse mount, yes. [00:35] caravel: performance will be less than ideal though - pushing and pulling is dealing with a database afterall [00:37] lifeless: thanks - not looking for performance, rather trying to obtain from our web dev that he commits his code for himself, shares it, permit some backup... fuse should do, if bzr does't time out too fast ? [00:40] there is no real infrastucture, so the idea would be to usie a (temporary) lenny server... as a bzr client to sync code from his FZ/win over fuse/ftps. Arrhmm, can this make sense ? [00:44] I'd never heard of Filezilla before, but one of my clients yesterday had a problem with it's sftp implementation, whereas Nautilus's "connect to server" (via "SSH"/sftp) worked fine. === AfC1 is now known as AfC [00:46] the bane of my life [00:47] [11630.844206] iwlagn 0000:02:00.0: Microcode SW error detected. Restarting 0x2000000. [00:47] caravel: anyway [00:48] uhm, you can use any workstation - say yours - to run a bzr server on [00:48] if you're doing network mounting, good ol smb will interoperate happily with windows [00:48] I'm assuming your web dev is on windows [00:50] lifeless: Ugh--what kind of wireless card do you have? [00:51] 6000 series [00:51] lifeless: Hmm. I guess they're relatively new. [00:52] mkanat: arrandale [00:53] lifeless: Oh, yeah. [00:53] mkanat: whats worse though [00:53] mkanat: is that the kernel fails to reset some stuff when the microcode fails [00:53] so you have to rmmod + modprobe [00:53] fix is partly in maverick [00:53] the restart bug affects all iwl cards [00:54] lifeless: That's really obnoxious. I've had a laptop that that happens on. [00:54] but you have to have a firmware issue too for it to actually annoy you [00:54] :) [00:54] I've had it happen where, randomly, I start up and the card doesn't work, also. [00:56] lifeless: yes, he runs on windoz, there is no perpetual server online besides the production, hosted web server -- and some windoz machine at his place [00:57] bzr fits great with our needs because of its various topologies [00:58] each is in a different part of the country, rather poor and unreliable bandwidth. soon we'll get a couple of servers, but for now [00:59] I found easily LftpFS but it's read-only... anyway, getting waaaay off topic. My concern here was how bzr would handle this type of link [01:00] caravel: as a push/pull target fine [01:00] you can't work on a fuse fs directly though because they don't support OS locks properly [01:01] "OS locks" what do you mean ? [01:02] operating system locks [01:02] lifeless: ok I'm with you, but in my case, only one app will access the fuse link so it should not matter? [01:03] (bzr) [01:04] I'm cautious because while setting up passive and active ftp w(o encryption, I found bzr a bit "delicate" and quite far from the verbose mode. [01:05] opening a passive ftp to a badly (NAT & FZ ports) configured server, did hang bzr apparently [01:09] disclaimer: was running bzr's windoz client [01:12] as soon as the server & router config were rectified, it rocked but I had a few timeouts (while other FTP clients have just no issues) [01:25] lifeless: did you see https://bugs.launchpad.net/bugs/595473 ? [01:25] Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed] [01:27] can bazaar explorer / kde take advantage of kio (cf. kio-ftps) ? [01:27] It would be nice to find out the list of missing features PQM gets when doing 'bzr selftest'. [01:28] caravel: someone recently added a gio transport for bzr, I don't recall seeing the same for kio though. [01:35] spiv: thanks [01:36] * caravel finds it real hard to google about such a popular VCS's feature [01:51] poolie: cute way to make simple graphs: http://webnumbr.com/bzr-in-progress-bugs [01:57] hi spiv [01:57] spiv oh wow that's brilliant [02:00] poolie: yeah, it's very nifty [02:00] The API is cute too. [02:01] (Although the AJAX on bugs.launchpad.net/foo makes it awkward to actually get at the interesting numbers, you have to use the +bugtarget-portlet-bugfilters-stats URL) [03:07] spiv, hi [03:07] spiv, i wonder if you can use +text? [03:07] but i guess that would break it's xpath parsing [03:08] spiv, how could you have used read not recv if you tested it locally? [03:08] re bug 595473 [03:08] Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/595473 [03:08] Yeah, not sure. With that URL I still got to point and click on a cute table ;) [03:09] That half of the if/else is only used via SFTP (when faking a paramiko Channel, which is socket-like, for use with paramiko's SFTPClient) [03:09] So, I tested the bzr+ssh with and without paramiko locally [03:10] And trusted that the test suite would catch problems in SFTP if I broke that. Which it did, except on PQM for some reason. [03:11] I *guess* PQM is lacking paramiko... I wonder if it's lacking anything else. It would be nice to see the list of selftest "features" it doesn't have. [03:14] once subunit is working you should be able to get that out [03:14] of the list of skipped tests [03:14] hm [03:14] Well, in some ways the list of unavailable features is more useful. [03:15] Maybe babune could provide a matrix of feature vs. builder.... [03:15] i mean the skip messages should tell you which features they're missing [03:15] spiv, so in one place you used recv but in the other it was still read? [03:15] Oh, right, by implication. Yes. It's a bit harder to tell which out of hundreds of skips "should" skip. [03:16] perhaps we could use subunit tags or something [03:16] that reminds me [03:16] spm: ping [03:16] spm: in balleny, in the pqm bzr chroot, please do 'python2.4 -c import paramiko' [03:16] I was wondering [03:16] would it be useful to attach the stdout and stderr to all responses [03:16] not just failures [03:16] lifeless, i got stdout and err for a merge conflict failure [03:16] poolie: the group by stuff I'd like to do would collate the skips for you [03:16] poolie: was it ok ? [03:17] lifeless, the stderr seems to have lost all its newlines [03:17] ! [03:17] aside from that it's ok [03:17] poolie: not exactly. I added a new path to handle the fact that SSHSubprocessConnection now might either have a socket or two pipes as its underlying connection [03:18] poolie: and this object provides a "recv" method so that it can be used with SFTPClient; in that recv implementation in the "if I have a socket" code path I typoed "self._sock.read" rather than .recv. [03:19] lifeless: worked fine [03:19] spm: huh! [03:20] (pqm-amd64)pqm@balleny:~$ python2.4 -c "import paramiko" [03:20] (pqm-amd64)pqm@balleny:~$ [03:20] fwiw [03:20] ii python-paramiko 1.6.4-1.1 make SSH2 connections with python [03:21] lifeless: do you have a recent subunit trace from PQM? Does that show if that test is being skipped? [03:21] looking [03:22] spiv: what test. [03:23] Argh, vila didn't put it in the bug. /me scrolls back... [03:24] lifeless: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh [03:24] Hmm. [03:24] spm: does the chroot have openssh-client? [03:24] spiv: nope [03:24] Ah-hah. [03:24] :-) [03:25] I'm guessing that's a pls install? :-) [03:25] need an rt ? [03:25] So it would have fallen back to paramiko for SSH in that test, and thus not hit that code. [03:25] Huh. [03:25] lifeless: for the record, yes, but will get it installed in parallel [03:25] we should add that to the build-deps too, for the packaging, so that that test gets run. [03:25] spiv: tag, you're it. [03:25] lifeless: for the rt? [03:25] Yes, if thats ok :) [03:25] lifeless: sure [03:26] I've forwarded you the subunit trace btw [03:26] Thanks! [03:27] ah so you interactively tested only bzr+ssh, which doesn't call SSHSubprocessConnection.recv? [03:28] Right, because that's just for SFTP. [03:28] so it might be worth testing sftp interactively now? [03:28] I was aware that I was changing code used by the SFTP client, but assumed the test suite would cover me... [03:28] to check it performs as expected, and to use lsof to check it's actually got a socketpair? [03:28] mm so the good thing is that it does, but not on pqm [03:28] good on babune for catching it [03:29] Right. [03:29] spiv: lifeless: installed [03:29] spm: thanks! [03:29] (And by installing openssh-client on PQM, we're possibly shifting the coverage gap to the pure-paramiko codepath, although I think that's an inherently less risky one) [03:29] i guess we could add a specific test for recv that doesn't count on having sftp but that may not be worthwhile [03:30] hm [03:30] ideally the test suite would be such that adding dependencies only turns on new tests and doesn't remove any other coverage [03:30] ie if we have an external test we'd run both with paramiko and external [03:30] It would be nice to fix that gap (per_ssh_vendor tests?), but doesn't feel like a very high priority to me. [03:31] at least for some representative fraction [03:31] probably not [03:31] hm [03:31] things like this have happened before [03:31] meaning variation based on testing with or without paramiko [03:31] but it's probably not top of the stack [03:31] Right. [03:32] Really, things worked pretty well in this instance: babune caught the bug quickly, and it got fixed very quickly. [03:32] mm [03:32] that was good [03:32] Obviously far from ideal, but defense in depth is good :) [03:32] i don't think this is a catastrophe [03:33] but interesting to dig into [03:33] *in to [03:38] spm: RT filed, #39941 [03:38] spiv: ta [03:56] thanks & good night [04:20] jam: around at all? lazy object question for you [04:31] lifeless: what's up? [04:38] I was wondering if we had something that proxied after it loads [04:38] even though thats not the common case because of perf concerns [04:38] for formats that open disk resources it would be convenient [04:40] jam: ^ [04:41] lifeless: ScopeReplacer._should_proxy [04:41] ah [04:42] lifeless: might not be fine grained enough yet [04:42] so I mean [04:42] 'a lazy object proxy' [04:42] yes, its too broad. [04:42] hmm, I'm nearly done with a _LazyObjectGetter approach [04:42] I'll see how it looks, gimme 2 minutes [04:51] jam: http://pastebin.com/PHMrCSxk [04:52] jam: I think this looks ok, simple to use. [04:52] jam: what do you think [05:38] jam: I'll propose it, you can assess later :) [05:43] https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27903 [05:43] jam: to be clear, I don't care if you do/don't look at this in particular [05:44] jam: I'm just closing up the conversation I started with you about the lazy import facilies aspect of it. [06:29] How do I make bzr forget that I added a file, in my current working tree? [06:30] Ahh, figured it out. [06:33] mkanat: bzr revert file [06:33] mkanat: or bzr rm --keep [06:33] lifeless: Yeah, --keep --new was what I figured out. [06:33] (It was a bunch of files in a directory, some of which needed to stay.) [06:33] yeah [06:34] revert tries very hard to be safe [06:34] takes backups of stuff that isn't in a commit [06:34] etc === radoe_ is now known as radoe [07:28] hi all [07:31] hey [07:38] lifeless: hey ! Quick chat about looms ? [07:38] oui [07:39] :-) [07:40] lifeless: So, what do you have in mind about the merges in a loom (vague to not pre-suppose anything) ? [07:41] oh [07:41] so [07:41] change up-thread to skip a thread if no conflicts occur [07:41] and use the result (PreviewTree or whatever) of merging up to merge into the next thread, and so on. [07:42] when a conflict happens, annotate to find the thread that causes the conflict, and: [07:42] - if its trunk [thread 0], ignore all the other threads [07:43] - otherwise try the thread causing the conflict -> the thread we'd reach and if that works its conflicting due to the merge output [07:43] - etc - working down a list to refine the conflict [07:43] do a merge of only the threads involved in the conflict [07:44] so the number of merges will go way down, per thread [07:44] this will make merging a loom to a loom better [07:44] because common case if you don't touch a thread explicitly, it won't change revid [07:44] unlike today where it changes all over the place [07:45] oh also [07:45] do all merges for 'does it conflict' detection in memory [07:45] Hmm, I think I mostly got it but need to think a bit about it [07:45] so we're insulated from pyc file staleness and the like [07:49] on a related subject: how do *you* undo up-thread ? [07:50] revert and or revert-loom and or uncommit [07:50] well, up-thread --auto (yeah --auto is automatic now, but) [07:53] ha, revert-loom, missed that one. No uncommit-loom though [07:54] poolie, poolie, where are you ? [07:56] lifeless: ok, food for thought on that subject, thanks. That looks promising as it addresses my main problem there (commits that "partly" look useless) but I need to draw some picture to better understand it. [08:00] lifeless: about PQM, 2 things: [08:01] 1) Is news_merge configured now ? I suspect poolie couldn't land some patches because of that (and I had to merge locally a couple of mps too). [08:02] 2) I didn't get a failure email for submitting your broken branch (see my comment on the mp) [08:02] news_merge can't be configured on branches yet [08:02] so 1) no [08:02] nag spiv [08:02] oh, and 3) Do we plan to install update_copyright on pqm too ? [08:03] 2) see my comment in th e mp [08:03] 3) No plans that I know of, and I think it would be wrong anyway; pqm doesn't write code, coders do. [08:04] hmm, good point about 3 but my workflow with loom suffers from that: [08:05] since I have the plugin installed, merging bzr.dev triggers such updates and merging the threads up make the copyright update bubble up [08:05] for files I didn't touch myself [08:05] update_copyright sounds a bit too eager. [08:05] lifeless: well, I need another way to address that [08:05] spiv: Did you catch it proposing wrong updates ? [08:06] spiv: nagging: see lifeless remark above about configuring branches for news_merge (I don't get it though) [08:07] I haven't used it myself. [08:07] spiv: then what do you mean by eager there ? [08:07] vila: he means that it enabling news_merge ought to be something we can set in the branch, rather than setting in the PQM user's global conf [08:08] (Which especially makes sense if you consider that merging a branch that adds a NEWS entry generally should add it to the current release when merged by PQM) [08:09] ha, yeah, inserting in the right release would be nice, but a useful first step will be to have it work for bzr.dev [08:09] vila: triggering updates when you haven't changed the file sounds dubious to me [08:09] vila: e.g. what if a file in bzr.dev was reverted to a 2009 version for some reason. [08:10] So, "eager" in the sense it will sometimes trigger when it shouldn't. [08:10] its a bug in th eplugin [08:10] vila: I suggest you fix the plugin [08:10] commit knows that a file showing in 'bzr st' can be unchanged against one parent [08:10] spiv: its history will still mention a change in 2010 [08:10] so the plugin should never change copyright headers in that caase [08:10] its breaking the per-file merge graph too [08:12] meh, I fail to see what is breaked here, the copyright line is a line, its changes are recorded like any other line [08:12] broken [08:12] the line should only change when the file has been changed by the user [08:13] vila: per file merge graph convergence - you're familiar with it ? [08:14] the copyright changes converge, I can't imagine a conflict occuring there that can't be trivially resolved [08:14] you said [08:14] 19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging the threads up make the copyright update bubble up [08:14] 19:05 < vila> for files I didn't touch myself [08:14] that is the problem [08:14] if I change a file [08:14] and you bzr merge me [08:14] It's arguably close to embed VCS data into a file which is a Bad Idea, but these lines are there for lawyers anyway [08:14] and commit [08:14] then do per-file log of that file [08:15] your merge commit will not show up [08:15] if your update copyright plugin makes the file get edited in that commit [08:15] even if you haven't changed it [08:16] then it will fail on branches merged in different years [08:16] e.g. if I have a branch in december 2010 [08:16] no changes in 2011 to a given file [08:16] and you merge it in jan 2011 [08:16] update copyright should not (and for the laywers, perhaps 'must not') change the file [08:16] until you actually do something copyrightable to it [08:16] if you had this fixed, I don't think you'd have made the complaint [08:17] 19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging the threads up make the copyright update bubble up [08:17] 19:05 < vila> for files I didn't touch myself [08:17] above [08:17] It would be interesting to setup a project that kept the copyright line and licence boilerplate on disk via a content filter, and left the canonical texts free of them. [08:17] hmm, and changing the copyright line isn't copyrightable ? Quite possible [08:18] vila: its not a created work, its mere data [08:18] Oh, I bet you could create a work consisting of opyright lines [08:18] but as we use it [08:18] .. [08:18] no [08:18] vila: anyway, I don't really care. [08:18] vila: AFAICT fixing the bug I mention will fix the bug you mentioned. [08:18] vila: and you asked for a fix. [08:19] lifeless: I see your point, sounds reasonable is what I meant with my last remark [08:20] i.e. the plugin should only trigger if *I* introduce a change in the left-hand parent only [08:20] and for the record, jam wrote the plugin, not me :) [08:21] Doesn't mean I can't fix it either ;) [08:21] I think its intended to update if anyone changes the file [08:21] but it shouldn't detect an unedited merge as a change. [08:23] yup, it should restrict to the changes introduced by the committer, so yes, too eager [08:27] lifeless: regarding https://code.edge.launchpad.net/~vila/bzr/595587-fix-test-tariff/+merge/27859, you said: 'it would be nice to have just one list of such variables.' but what other list are you talking about ? And 'such variables' being 'variables that subprocess want to respect from the unless explicitly set otherwise (i.e. ignoring the resets in bt.TestCase._cleanEnvironment') ? [08:28] vila: well its all tied together right [08:28] there are variables we want to reset [08:28] there are ones we want to affect the test suite (except for tests that know better) [08:28] and so on [08:28] we seem to be adhocing it [08:28] so that when someone does something new - like the tarif - it needs manual adjustmnet [08:29] so you'd like that list to come from a method close to bt.TestCase._cleanEnvironment and documented ? [08:29] or attribute on bzrlib.tests [08:29] or something [08:29] yeah, or attribute, ok [08:29] I'd just like to remove the duplication [08:30] rather than N lists all slightly different [08:30] I'd like Y canonical lists that express the intent [08:30] N ==2 so far right or did I missed one ? [08:30] I think its much larger than that [08:31] IMBW [08:31] lifeless: ok, I'll try to look into that. No objection to make that in a different mp ? [08:32] oh, I thought that was clear [08:32] I just commented [08:32] I wasn't expecting it to be done :) [08:33] I wanted to make sure I understood your intent :) [08:33] I agree that we lack documentation about the impact of env vars, that sounds like a godd plan to address that [08:36] while you're here [08:36] abentleys branch to do more cleanups of ui factories [08:36] spiv: ^ vila; ^ [08:37] that branch seems stalled; I'm happy to change it in the direction I proposed; noone else seems to really have an opinion [08:37] I'd like one of you to express an opinion :) [08:39] lifeless: Hmm, I don't have an opinion on that :) [08:39] I'm happy to polish [08:39] But I don't want to make it worse ;) [08:40] I'm not sure how much of an issue calling clean_up twice or before initialize is likely to be in practice. [08:41] And other than a vague "yes it's nice to have less globals" feeling your suggestion doesn't feel significantly better or worse to me. [08:42] ok [08:42] well I'll tweak and land then [08:42] lifeless: I haven't looked deeply, but some holes in the implementation have been mentioned, I don't really care *how* they are addressed as long as they are. [08:42] as a second reviewer [08:42] But I did have "Needs Fixing" vote that should be addressed ;) [08:43] sure [10:29] heya bzr [10:29] vila: thanks for your help [10:29] bialix: you're welcome [10:30] :-) [10:32] hi there bialix, vila [10:32] good day poolie! [10:33] poolie: can I start working on --path-encoding option for diff? [10:33] hey poolie ! [10:33] your comment about true output encoding is puzzled me [10:41] bialix, so there's a couple of things basically [10:41] first, i don't understand when you would want the paths to be in a different encoding to other non-file-content output [10:42] second, i think i'd like to get to something about generally detecting whether we shoud use the terminal encoding or something else [10:43] bialix i didn't propose it for merge yet but https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option adds a general output_encoding option [10:43] maybe i should just propose that [10:45] bialix, https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option/+merge/27913 [11:09] Hi guys. I have a trunk with lots of commits. Some of these commits were project releases [11:09] I'd like to have a 'release' branch. Would it be possible to merge in from certain revisions to create the release 'tag' in the release branch? [11:10] I assume it's a case of creating the branch from an early revision, and then merging with -r x..y ? [11:11] poolie: sorry, I' afk for a while. bbl [11:12] np [11:12] CaMason, typically you'd just merge everything up to that point, ie -r x [11:12] or -r y [11:12] but aside from that, yes [11:13] or if you wanted you could just tag them within that main branch [11:13] if you've not already done so [11:22] poolie, yeah tagging was one option. We'd like to have a seperate release branch though [11:24] k, so then i'd suggest [11:24] tag them in the trunk [11:24] then merge across each tag and commit it [11:24] into the release branch [11:28] poolie: re: first, i don't understand when you would want the paths to be in a different encoding to other non-file-content output [11:29] poolie: on Windows filenames should be in ANSI encoding to be compatible with GNU patch, while terminal encoding is OEM [11:29] so if I want to save diff in a file, I want it to use ANSI encoding [11:30] but to me this is really the second point, that saving to a file needs a different encoding to the terminal [11:30] not that you want different encodings for the filenames vs the other content [11:30] the case of UCS-2 is illuminating i think [11:31] you would never want to mix ANSI and UCS-2 within the diff headres [11:33] for me this is the first point, because windows is 2-encodings system [11:33] ok [11:33] i have to go now [11:33] I don't understand your desire about UCS-2, but as discussion in my merge proposal reveals, this is exceptional case [11:34] ok [11:34] i'll try to explain it on email later [11:34] good night! [11:34] ok [11:34] good night and have a good weekend! [11:34] poolie: good night and good week-end ! [11:34] bialix: :) [11:34] vila: :-) === nlisgo_ is now known as nlisgo [13:30] hi all [13:31] I don't understand the '--no-trees' option that you can use to 'bzr init-repo' [13:31] I'm not sure when to use --trees and when to use --no-trees... so I guess I don't understand what a 'working tree' is? [13:37] marsilainen, working tree is the tree of files that you are using bzr on [13:37] ok, so when would I want --no-trees? [13:38] --no-trees is generally used in servers hosting bzr repos/branches where you don't want to waste disk space [13:38] right, but don't they need the tree of files in order to serve them? [13:38] in which case bzr will just create the .bzr folders [13:39] marsilainen, nope, because when you do a bzr branch it just needs the .bzr folder [13:39] so in the .bzr folders, are contained all the checked-in revisions of the files anyway? [13:39] yes, and they are efficiently compressed/packed there [13:39] ok [13:40] so if I'm serving the files up, it doesn't really matter whether I specify --trees or --no-trees I guess? [13:40] I think I understand now anyway, thanks [13:41]