[00:12] <igc> hi all
[00:13] <igc> hi goneri, lifeless
[00:13] <igc> goneri: I'll take a look today (hopefully)
[00:57] <goneri> igc: thanks, this bug is a blocker for git-bzr inclusion in Debian
[00:58] <igc> goneri: ah - ok. Thanks for the patch and for hassling me
[00:59] <goneri> igc: my pleasure :)
[01:00] <gus1> So I just upgraded to jaunty ppa bzr (from normal jaunty bzr) and my stacked bzr-svn repo is complaining with "ERROR: SvnRepository(...) is not compatible with KnitPackRepository(...) different serializers".   Is that some known problem?
[01:03] <lifeless> gus1: I don't think stacking bzr on svn has ever really worked
[01:04] <gus1> :(  it ~worked on the previous version.  Now I have to downgrade before I can retrieve a simple diff.
[01:05] <gus1> upstream has a large svn repo so a non-stacked branch is unfeasible.
[01:06] <lifeless> uhm
[01:06] <lifeless> file a bug in bzr-svn then
[01:06] <lifeless> if you could
[01:06] <gus1> somewhere in launchpad?
[01:06] <lifeless> yes :)
[01:06] <gus1> will do.
[01:46] <AfC> lifeless: you said "2a now default" but is bzr.dev itself in 2a?
[01:46] <AfC> lifeless: I just did a `bzr pull` on that branch and was surprised it worked.
[01:46] <james_w> no, 2a is default
[01:46] <AfC> (I was expecting it to: 1. fail, then I'd 2. upgrade, then 3. pull would pass)
[01:46] <james_w> bzr.dev doesn't use its own default yet
[01:47] <AfC> hm
[01:47] <lifeless> we haven't migrated yet is all.
[01:47] <lifeless> we want to be dogfooding
[01:47] <lifeless> but its orthogonal to getting bugs related to doing a 2.0 release done.
[01:50] <AfC> hm
[01:50] <AfC> sorry, not sure I buy that.
[01:50] <AfC> but that's your call, of course.
[01:51] <lifeless> there is a bug; its assigned to LarstiQ; you're welcome to comment on it
[01:51] <AfC> There are certainly many many other things in your lovely work besides repository format iteration.
[01:52] <AfC> Mind, I feel the same way about you guys not using bzr://
[01:52] <lifeless> we use the smart server every day
[01:52] <lifeless> but there is the same gap between dev and deployment
[01:52] <AfC> lifeless: you mean bzr+ssh://
[01:52] <AfC> lifeless: I'm talking about bzr in daemon mode.
[01:52] <lifeless> using bzr:// specifically - well, it doesn't meet our use cases :)
[01:53] <lifeless> bbiab
[01:53] <AfC> see ya
[02:09] <lifeless> back
[04:08]  * igc lunch
[07:36] <vila> hi all
[07:36]  * vila pesters about kernel updates (at least against the daily ones :-)
[07:38] <vila> lifeless: if you're still around, I'd like a little chat about .progress(), I found *one* way to make it work with --parallel, but I'm not sure it's correct
[07:40] <lifeless> SET -> CUR? yes, its correct.
[07:41] <vila> no, not that part
[07:41] <vila> I had to implement .progress in testtools and that's where I'm unclear about whether testtools can have a subunit dependency..
[07:42] <lifeless> optional I guess
[07:42] <vila> http://paste.ubuntu.com/255578/
[07:43] <vila> of course that '0' should be subunit.PROGRESS_SET
[07:43] <vila> so more context: testresult modification is for ThreadsafeForwardingResult
[07:44] <lifeless> yes
[07:44] <vila> and testsuite is for ConcurrentTestSuite
[07:44] <vila> or...
[07:44] <lifeless> the change to init isn't needed
[07:44] <lifeless> erm
[07:45] <lifeless> it is, sorry.
[07:45] <lifeless> but if we're doing it right
[07:45] <lifeless> I would just implement progress()
[07:45] <lifeless> rather than counting can calling
[07:45] <lifeless> *counting and calling*
[07:45] <vila> ThreadsafeForwardingResult should become an attribute of ConccurrentTestSuite so that bzr can override it and just defines .progress there...
[07:45] <lifeless> huh?
[07:46] <lifeless> I think you're smoking something at this point
[07:46] <vila> the root problem is that TFS don't implement .progress
[07:46] <lifeless> TFR should combine progress data
[07:46] <vila> :-D
[07:46] <lifeless> CTS shouldn't need to do anything
[07:46] <lifeless> neither call progress nor implement it
[07:47] <vila> some one has to relay the calls
[07:47] <lifeless> yes, the result object
[07:47] <vila> that's TFR
[07:48] <vila> then someone has to SET the number of tests
[07:48] <lifeless> no
[07:48] <lifeless> thats what the individual results do back in bzr
[07:48] <vila> show them :)
[07:48] <lifeless> and why I asked you to insert the decorator before the CTS decorator
[07:49] <lifeless> and the result objects show them, which is why TFR has to combine and forward
[07:50] <vila> still doesn't work... except if all TestInOtherProcess do the call, all setting the same nb tests, it worked, but is a bit ugly
[07:50] <vila> ha, well, wait a minute, I need to explain more
[07:51] <vila> I change the way --parallel=fork works to get a better balancing
[07:51] <vila> but now, instead of creating n slices of the test suite upfront, I create the slices on demand,
[07:52] <vila> so the TIOP objects doesn't know anymore how many tests there will be (in total), they learn about them one slice at a time
[07:54] <vila> lifeless: so there is no more point where a single test.run(result) is called which knows about the whole test suite, there are 'concurrency' not one, so either they all call progress(nb_test, SET) or CTS calls it once
[07:55] <vila> Does that make sense ?
[07:55] <lifeless> what drives demand?
[07:56] <vila> displaying [1234/6801 in 19s] instead of [1234 in 19s]
[07:58] <lifeless> yes, but what drives your on demand slicing thing
[07:58] <vila> 30% less execution time for a full run ?
[07:59] <lifeless> _the logic vila_
[08:00] <vila> ha, TesttInOtherProcess now start a new process for a given slice, all TIOP objects synchronize on a semaphore to get slices out of the test suite
[08:01] <lifeless> whats a slice
[08:01] <vila> tests[first:last]
[08:01] <lifeless> is tests flat?
[08:01] <vila> yes
[08:02] <vila> well, flatten by tests = list(iter_suite_tests(suite))
[08:02] <lifeless> so you know the count
[08:02] <vila> yes
[08:02] <lifeless> how many TIOP's are there?
[08:02] <vila> osutils.local_concurrency
[08:03] <lifeless> ok
[08:03] <lifeless> so, does the thing that creates TIOPs know the count?
[08:03] <vila> yes, but not the result object
[08:04] <vila> yes, but it doesn't know not the result object
[08:04] <vila> yes, but it doesn't know the result object
[08:04] <vila> it's in fork_for_tests
[08:04] <lifeless> which creates the suite
[08:04] <lifeless> you should decorate the suite
[08:04] <lifeless> erm
[08:04] <lifeless> no
[08:05] <lifeless> you want to decorate the suite, and decorate the result that the suite is run with
[08:05] <lifeless> the first decorator will issue the count you know
[08:05] <lifeless> the second will eat progress() calls so that the external counts are not passed forward
[08:06] <vila> right, except that the result is TFR, created by CTS hence I can't decorate it, looks like we are on the same page now
[08:07] <lifeless> you don't need to decorate tfr
[08:07] <vila> you just said so ...
[08:08] <lifeless> no, I said you need to decorate the result you're run with
[08:08] <lifeless> you'll end up with
[08:08] <lifeless> BzrTestResult <- ProgressHider <- TFR
[08:09] <vila> You mean BZRTransformingResult ? And what is ProgressHider ? The misterious culprit ?
[08:12] <lifeless> yes
[08:12] <lifeless> you need:
[08:12] <lifeless> a test result filter to stop progress data from children
[08:13] <lifeless> thats all
[08:14] <vila> wow, you're telling me that to have progress reporting I need to stop progress data, let me have one more coffee :)
[08:15] <lifeless> yes, because you want to do a global optimisation (your TIOPs)
[08:16] <vila> ok, that means I may have been on the right path, yesterday but failed to realize it,
[08:16] <vila> I think I will make a first submission without the progress part and add it in another submission, to make things clearer
[08:28] <poolie> hi vila
[08:28] <vila> hi poolie !
[09:21] <benchik> hello
[09:22] <benchik> i'm trying to bzr merge but i get : bzr: ERROR: No location specified or remembered
[09:22] <benchik> please help
[09:22] <LarstiQ> benchik: what do you want to merge from?
[09:22] <LarstiQ> benchik: `bzr merge location/to/branch/to/merge/from`
[09:22] <benchik> LarstiQ: the cwd
[09:23] <LarstiQ> benchik: ok, what do you want to merge in to the cwd?
[09:24] <benchik> LarstiQ: i always did bzr merge from a dir where i have the sourcecode and it worked, today it doesn'
[09:24] <benchik> t
[09:25] <LarstiQ> benchik: that must have been a different dir
[09:25] <benchik> nope
[09:25] <LarstiQ> benchik: as the message mentions, `bzr merge` either takes a location to merge into your current branch, or it takes the remembered location
[09:25] <LarstiQ> benchik: which in this case is not set
[09:26] <benchik> LarstiQ: it was set before. don't know what happened
[09:27] <benchik> LarstiQ: ok i gave it the full path and it worked but i wonder why did it forget the path
[09:28] <LarstiQ> benchik: possible reasons: 1) it got removed from .bzr/branch/branch.conf 2) it got removed from ~/.bazaar/locations.conf, 3) harddisk failure
[09:28] <LarstiQ> benchik: or 4) this is not the branch you think it i
[09:28] <LarstiQ> s
[09:28] <benchik> i think it's the former few
[09:30]  * igc dinner
[09:48] <vila> hey LarstiQ !
[09:48] <LarstiQ> hey vila :)
[10:06] <matkor> Hi, I get bzr internal error( 1.8 and 1.15) when try added files having enter in their name like: antique^J.py
[10:06] <matkor> when trying to commit such added files to be strict
[10:10] <matkor> should I report it as bug ?
[10:10] <LarstiQ> matkor: yes
[10:24] <poolie> matkor: i think it's a known bug
[10:24] <poolie> you should be able to find it then
[10:24] <poolie> sorry
[10:32] <matkor> poolie: Yes, I found it .. so not reporting again, can I somehow bump its priority ? - seems it's lasting for a long time now ...
[10:37] <poolie> you can click 'affects me too' or comment on it
[10:41] <moldy> hi
[11:27] <moldy> how do i make bzr forget the submit branch?
[11:35] <moldy> ah, never mind
[14:26] <vila> morning jam :)
[14:26] <jam> morning vila
[14:26] <jam> I'm a little slow today, have a mild fever
[14:27] <vila> ow
[14:27] <lifeless> jam: rest up
[14:27] <lifeless> health++
[14:29] <jam> lifeless: thanks.
[14:29] <vila> jam: just a small question: am I correct in reading plugin.get_standard_plugin_path that windows has no concept of "site" plugins ? Only bzrlib/plugins and $HOME/plugins right ?
[14:29] <jam> what are you still doing up?
[14:29] <jam> vila: correct
[14:29] <vila> jam: good, go rest now :)
[14:30] <vila> jam: or land 1.19-kg-sorted, whatever is better for your morale :D
[14:32] <lifeless> jam: just finished raiding
[14:33] <jam> lifeless: ah, I hope it went well. I assume you guys are in ToC?
[14:34] <lifeless> tonight was a ulduar run, but yeah, wehave toc full cleared so far each week
[14:37] <vila> toc ?
[14:38] <jam> vila: Trial of Champions, IIRC. The current last-raid in World of Warcraft
[14:38] <vila> haa, ok :)
[14:40]  * lifeless sleeps
[14:40] <vila> nothing related to cObsessive-Compulsive Disorder  (aka toc in french :-)
[15:20] <igc> night all
[16:03] <kiko> hey, is there anyone around that knows a bit of bzr-git?
[16:03] <kiko> http://launchpadlibrarian.net/30506243/windmill-trunk-log.txt
[16:14] <james_w> kiko: hey, rockstar filed that one as bug 414918
[16:14] <james_w> doesn't help you much though
[16:15] <rockstar> kiko, I'm not sure why it's failing, but I suspect it might have been a revision generated by an old git
[16:31] <saedelaere> hi
[16:32] <saedelaere> is there something like cia.vc that can be used with bazaar? i have a bazaar repo at sourceforge.net. Whenever someone makes a commit i want a message send to my irc channel.
[16:34] <LarstiQ> saedelaere: there is a cia plugin
[16:34] <saedelaere> and does this plugin work with sourceforge?
[16:35] <LarstiQ> I have no idea on what sf does
[16:38] <saedelaere> ok thanks
[16:38] <saedelaere> perhaps i can get it to work
[16:40] <LarstiQ> saedelaere: you can trigger it locally instead of on sf
[16:43] <saedelaere> http://people.samba.org/bzr/jelmer/bzr-cia/trunk/
[16:43] <saedelaere> damn the directory is empty
[16:55] <luks> it's a bzr branch :)
[16:56] <luks> I thought anybody using bzr has to be used to empty directories :)
[17:41] <saedelaere> lol ok now i see :)
[18:04] <vila> wow, who said downloads were hard to find at https://edge.launchpad.net/bzr ? :-D
[18:04] <beuno> vila, I did
[18:04] <beuno> and I fixed it!
[18:04] <beuno> :)
[18:05] <vila> beuno: woohoo, that's a change for sure :-)
[18:21] <mtaylor> lifeless: you still awake?
[18:22] <mtaylor> oh, hrm, probably not
[18:22] <mtaylor> anybody around who can point me to info on subtree support stuff?
[18:28] <vila> mtaylor: try abentley-lunch (after his lunch that is :)
[18:29] <mtaylor> vila: sweet. thanks
[18:30] <mtaylor> abentley-lunch: whenever you aren't eating lunch...
[18:30] <vila> mtaylor: as appetizer read: http://bazaar-vcs.org/NestedTreesDesign
[19:26] <abentley> mtaylor: The subtree stuff is not ready for use yet.
[21:30] <lifeless> moin
[21:41] <hno> Is there an easy command for making a branch for the current uncommitted changes? I.e. working on something which felt quick at start and realizing it was much larger and needs a branch of it's own for a while?
[21:42] <hno> I know shelve/unshelve but it's not quite the same thing..
[21:42] <LarstiQ> hno: you can try a combination of bzr branch . ../feature; cd ../feature; bzr merge --uncommitted ../trunk
[21:44] <lifeless> hno: so you're already writing some code
[21:44] <lifeless> hno: and you want to turn it into a branch?
[21:44] <hno> LarstiQ: Thanks.. could obviously be improved a bit..
[21:44] <hno> lifeless: Yes.
[21:44] <lifeless> bzr switch -b ../newbranch
[21:46] <hno> lifeless: bzr: ERROR: no such option: -b
[21:46] <lifeless> well, you have something to look forward too in a newwer bzr:)
[21:47] <hno> lifeless: 1.18?
[21:50] <hno> lifeless: Hmm.. ChangeLog says -b was added in 1.17, but I am using 1.17..
[21:51] <lifeless> could be a plugin intercerpting it
[21:52] <hno> lifeless: Only plugin I have is bzrtools I think..
[21:52] <LarstiQ> lifeless: or a misattribution
[21:52] <lifeless> try bzr help --no-plugins switch
[21:52] <hno> lifeless: Not mentioned.
[21:53] <lifeless> ok
[21:53] <lifeless> docs are wrong then :(
[21:53] <lifeless> where do you see 1.17 mentioned for it?
[21:55] <fullermd> It's under the 1.17 heading in NEWS.
[21:55] <lifeless> ugh
[21:56] <hno> Why is there a 1.17 heading in the middle of NEWS for 1.18rc1?
[22:04] <lifeless> hno: is 1.17 repeated?
[22:06] <Noldorin> hi lifeless
[22:07] <lifeless> hi Noldorin
[22:07] <Noldorin> lifeless: i got a reply back from the server admin
[22:08] <Noldorin> http://pastebin.ca/1535577
[22:09] <Noldorin> i instructed him to attempt pushing a bzr repo
[22:09] <Noldorin> but he seemed to ignore that :S
[22:09] <lifeless> its definitely not operating normally for win2003 server
[22:10] <Noldorin> heh
[22:10] <Noldorin> yeah
[22:10] <Noldorin> but the thing is, a simple rename does work fine
[22:10] <lifeless> we have other users using that platform without the issues you've reported
[22:10] <Noldorin> so it's clearly the sequence of commands that causes the problem
[22:10] <Noldorin> yeah
[22:10] <Noldorin> i know
[22:10] <lifeless> here's what I'd do
[22:10] <lifeless> there is a built in ftp client in windows
[22:11] <lifeless> if you start cmd.exe
[22:11] <lifeless> then type 'ftp'
[22:11] <Noldorin> yeah. there's one in windows explorer too
[22:11] <Noldorin> ok
[22:11] <lifeless> you could use the trace we made to create a series of commands
[22:11] <lifeless> put that in a text document
[22:11] <lifeless> then paste it into that window
[22:11] <lifeless> and the ftp client will run them
[22:12] <lifeless> I would include every command
[22:12] <Noldorin> yeah, that's what i was going to suggest to
[22:12] <lifeless> and the commands that put files - you'll need to create files on disk locally that you can put up
[22:12] <Noldorin> so i'll attempt that right now
[22:12] <Noldorin> maybe that will be clearer to the admin as well
[22:15] <Noldorin> lifeless: should i use the dhtransport log for a push using the unmodified bzr program?
[22:15] <lifeless> Noldorin: that would make sense to me
[22:15] <Noldorin> ok
[22:15] <lifeless> skip the chmods as it happens without them
[22:15] <Noldorin> yeah
[22:16] <Noldorin> and i'll just replicate the appropiate filesystem structure for the repo to test
[22:29] <hno> lifeless: seems so, with some changes and a different heading than what's used in 1.17... Would pull up a launchpad diff url if launchpad worked proper...
[22:29] <lifeless> :(
[22:33] <hno> launchpad worked some minutes ago, but now I just get redirected to the main page when trying to browse revisions from https://code.launchpad.net/~bzr-pqm/bzr/1.18
[22:34]  * Noldorin gets confused
[22:35]  * hno is often confused, but right now mostly tired.
[22:35] <Noldorin> heh
[22:35] <Noldorin> i'm probably confused mainly because i'm tired
[22:36] <Noldorin> and because windows ftp servers are god awful
[22:37] <hno> Are they? Last time I accessed one I din't have to notice apart from slightly different directory listing than usual..
[22:38] <Noldorin> well my one is at least
[22:38] <Noldorin> lifeless will verify that :)
[22:38] <Noldorin> lifeless: any chance i could give you an ftp login to my server so you could try a few things out? (i.e. reproducing the issue manually)
[22:39] <Noldorin> i just feel like we're spending more time than we should with me pestering you about what i need to do next...
[22:40] <lifeless> hno: we have one that claims a rename worked but prevents renaming a different dir to the original path
[22:40] <lifeless> mv foo bar
[22:40] <lifeless> mv quux foo *boom*
[22:40] <lifeless> but the first command doesn't error, and you can even rm bar/gam; rmd bar before the second mv
[22:42] <Noldorin> lifeless: judging by the log, bzr doesn't seem to be understanding the error messages the ftp server replies with
[22:44] <denys> I am working on a STARTTLS-type extension for bzr:// (to complement my bzrs:// merge proposal) --- it is easy on the client side, but on the server side requests are executed at a level that knows nothing about the socket used.  I am unsure how to proceed (elegantly).  any suggestions?
[22:45] <lifeless> Noldorin: the server is giving an error?
[22:45] <lifeless> Noldorin: could you put your test case and the output you get in the bug please ;)
[22:45] <Noldorin> well if you look at the -dtransport log, bzr complains about not being able to parse the server error response
[22:45] <Noldorin> the one i showed you last time
[22:45] <lifeless> Noldorin: hmm, I didn't see that.
[22:46] <lifeless> Noldorin: we should still be treating it as an error ...
[22:48] <Noldorin> yeah..
[22:48] <Noldorin> you see it now?
[23:04] <poolie> denys: hm it's a good question
[23:04] <poolie> i would say that although it's a higher level, there probably is an object chain that you can walk back up to the medium
[23:05] <poolie> or if not, it might be tasteful to add one
[23:05] <denys> poolie: not from the request
[23:05] <poolie> jam, are you still around? want to catch up?
[23:05] <lifeless> denys: I'd be inclined to do TLS by just opening with an SSL handshake
[23:05] <poolie> i mean it is inherently a kind of inversion of control, to have a higher-level command affect the layer it's running across
[23:05] <lifeless> the server can decide that it doesn't look like a normal handshake and switch to it.
[23:05] <poolie> lifeless: just have the server say 'oh that looks like ssl'?
[23:06] <lifeless> yes
[23:06] <lifeless> they aren't confusable AFAIK :)
[23:06] <poolie> mm
[23:06] <poolie> that could be cleaner
[23:06] <poolie> iirc you disliked the idea of it just detecting http in the same way though?
[23:07] <lifeless> HTTP clients don't know how to handle an older version of our server
[23:07] <lifeless> browsers specifically
[23:07] <denys> I thought it would be nice to negotiate the encryption wanted/supported
[23:07] <lifeless> denys: doesn't SSL do that itself?
[23:08] <lifeless> denys: also, any negotiation done in cleartext can't be trusted, it could be attacked to get a lower level via MITM
[23:08] <denys> lifeless: no. there are different incompatible SSL and tthen there TSL and then there is what ever they'll invent next
[23:08] <lifeless> poolie: I do have mixed feelings about multiple protocols on one socket in general; but not 'its always bad' or 'its always good' :)
[23:09] <denys> lifeless: that's a point I have been worrying about
[23:10] <denys> my plan was to start with the lowest common denonminator
[23:10] <denys> add negitiation latter if wanted
[23:12] <denys> the lowest common denominator is already in my ssl patch - I just want to make it opportunistic
[23:13] <denys> I have code to make the decision in authentication.conf
[23:19] <denys> the point is that you can contact a regular bzr server and then cause it to upgrade the encryption level to whatever level you prefer,   server authentication can be added on top of that for python 1.6.
[23:20] <poolie> right, getting to native authentication would be great
[23:20] <poolie> and
[23:20] <poolie> well, now actually
[23:20] <poolie> to be a bit more specific
[23:20] <poolie> authentication and encryption that don't rely on OS accounts or setting up a separate server or client would be great
[23:21] <poolie> that doesn't necessarily mean it needs to be within the bzr protocol
[23:21] <denys> that's what I want
[23:21] <poolie> perhaps we should do both of them by acting as an ssh client and server?
[23:21] <denys> I want to explore te
[23:21] <denys> the bzr server option
[23:22] <denys> many admins will never agree to give external ssh accounts
[23:23] <denys> not in french universities anyway :-(
[23:23] <poolie> i'm suggesting that you run
[23:23] <poolie> 'bzr serve --ssh'
[23:23] <poolie> and it listens on some port
[23:24] <poolie> and authenticates you against a bzr-specific database of accounts and keys or passwords
[23:24] <poolie> using paramiko
[23:25] <denys> I don't want to do something this specific.  I prefer to setup a framework where arbitrary authentication methods can be setup.
[23:27] <Noldorin> lifeless: so would an ftp login to my server be of some use to you?
[23:27] <Noldorin> just for a bit of testing
[23:27] <denys> a bit like PAM, but simple instead
[23:28] <poolie> ok
[23:28] <poolie> you realize there's some scope for that within ssh?
[23:28] <poolie> i'm just thinking: there's already a protocol that lets you negotiate encryption and authentication
[23:29] <poolie> maybe we should use it
[23:29] <lifeless> denys: a custom ssh server will perform better than https; theres less restrictions and overhead in the way we work over it
[23:30] <poolie> i think he's running bzr+ssl
[23:30] <poolie> a la stunnel
[23:30] <lifeless> oh hmm
[23:30] <lifeless> that should be equivalent
[23:30] <denys> yes, but ssh needs an account on the target machine and some admins will NEVER allow it.  I want another degree of freedom.
[23:30] <lifeless> denys: ssh doesn't ;)
[23:31] <lifeless> denys: launchpads ssh server doesn't use local accounts, nor would what poolie suggested
[23:31] <poolie> denys: the thing is: OpenSSH requires an OS account
[23:31] <lifeless> "opensshd" uses the system account db, but there are pure python ssh servere implementations
[23:31] <poolie> jinx
[23:32] <denys> you need some account, and then you play games with different connections
[23:32] <poolie> well
[23:32] <denys> that's never going to fly for me
[23:32] <poolie> actually i don't think we're understanding each other
[23:33] <poolie> what you're talking about is, I think: I have one account on a server, I start a process there listening on a port, then people can connect to it, authenticate, and do stuff?
[23:33] <denys> I have been working 3 years to get some sort of external VCS access for our univ.  It's really difficult to get things through the administrative hurdles.
[23:34] <poolie> i'm suggesting just the same architecture except that the protocol encoding would be that specified by the SSH protocol
[23:34] <Noldorin> lifeless: ?
[23:35] <lifeless> Noldorin: ?
[23:35] <Noldorin> lifeless: see my previous message :)
[23:35] <lifeless> Noldorin: I'm still very focused on our 2.0 release; I doubt I'll have time to personally test this for a few weeks.
[23:36] <lifeless> Noldorin: I can keep giving you guidance, but for now thats about it.
[23:36] <Noldorin> ok, fair enough
[23:36] <poolie> denys: do you see what i mean?
[23:37] <poolie> i really do want to support your case of having sysadmins who aren't going to help
[23:37] <denys> poolie: this is not helping me.  I would like to know how to plug an encryption upgrade command into the bzr server.
[23:37] <poolie> i think you should do that by making connections from the request object up to the medium
[23:38] <poolie> and then you can call along them from the request handler to say 'start encrypting now'
[23:38] <poolie> but i'm kind of confused because i don't understand why that doesn't help
[23:38] <poolie> the thing about running the ssh protocol
[23:39] <Noldorin> lifeless: was wondering if i could get bzr to print out the exact ftp commands used in its log
[23:39] <denys> it doesn't help because the request object has NO references to anything above.
[23:39] <lifeless> Noldorin: edit ftp/__init__.py
[23:40] <lifeless> denys: poolie: I think you're talking past each other
[23:40] <denys> there is the do method and that's is
[23:40] <poolie> Noldorin: if you do that and make it turn on by -Dftp (see debug_flags) that would be nice to merge
[23:40] <poolie> lifeless: i think so too :-(
[23:40] <lifeless> denys: I think you're talking about where to write some specific code.
[23:40] <denys> lifeless: probably
[23:40] <Noldorin> poolie: could do :)
[23:40] <lifeless> poolie: I think you're talking about the design for getting encryption hooked into bzr's server without needing OS configuration
[23:41] <poolie> yes, i am
[23:41] <denys> poolie: you should approve my ssl patch then ;-)
[23:41] <poolie> well, i'm trying to answer the first one too, or assure denys that's also possible
[23:44] <lifeless> my take on this is:
[23:44] <lifeless> denys: you can probably write an upgrade command for the smart server, but it may be a bit ugly. It would be cleaner to do encryption right up-front if possible. Poolie wants to talk about how that might look.
[23:45] <denys> lifeless: I have already done encryption up front - see my proposal on lp
[23:45] <lifeless> yup, which is getting reviewed and polished ;)
[23:45] <denys> I wanted to also provide an upgrade path for a more traditional connection
[23:46] <lifeless> denys: what does that offer over the ssl support ?
[23:47] <denys> you can connect to a normal bzr server and demand an ecnryption upgrade - same advantages as STARTTLS for other protocols
[23:48] <lifeless> denys: I don't really get the advantage; you connect to a port and you get encryption, either way.
[23:48] <denys> its the same port!
[23:48] <fullermd> For one thing, it saves having to juggle multiple ports.
[23:49] <lifeless> denys: you don't need an upgrade command to do it on the same port
[23:52] <denys> lifeless: maybe not. but it seemed simplest to me, with a possibility to negotiate the type of encryption.
[23:53] <lifeless> we've just recently had a mammoth thread on the squid dev list about upgrade: and websockets
[23:53] <lifeless> simple often isn't ;)
[23:53] <lifeless> anyhow
[23:54] <poolie> it seems potentially insecure
[23:54] <poolie> easy to make a mistake about whether you really got a strong connection
[23:54] <lifeless> so conceptual issues with having such a command:
[23:55] <lifeless>  - how will it behave in half duplex connections?
[23:55] <lifeless>    that is, if done on an http smart server, will it work, or claim to work and break, or just break?
[23:55] <poolie> igc: did you move some of the doc files into _static?
[23:56] <poolie> i think that might account for the broken links just posted about
[23:56] <lifeless>  - what happens to the framing for the end of the current request/response? How do we make sure the wire is clean/we don't have any noise in the link
[23:56] <denys> I think you guys are asking the wrong questions. there is a basic level of encryption: that's what available portably in python. higher levels could then be negotiated.
[23:59] <poolie> hm
[23:59] <poolie> what question do you think we're asking?
[23:59] <poolie> it's true that ssl (usually) ships with python and paramiko does not