[04:41] hi. bzr is not working on me. from ~/.bzr.log : http://paste.pocoo.org/show/543402/ [04:41] bzr version is from debian testing [05:33] does bzr support "glob' syntax that git/hg do? (as in can i copy/paste their ignore files have) [05:43] AuroraBorealis: Yes, but not necessarily precisely the same syntax. bzr help ignore [05:43] k [05:45] I dunno about git, but converting hg should basically be a copy+paste, but you will need tweaks, if only taking out "syntax: glob". [05:46] http://stackoverflow.com/questions/4095696/mercurial-hgignore-for-visual-studio-2010-projects [05:46] so the [Bb]uild[Ll]og.* stuff will work if you just put RE: infront of it? [05:47] I guess. [05:48] there is 'bzr help patterns' which says yeah that works [06:22] damn, that's just really silly. "bzr branch somerepo" used to just work and now it gives what i think is an obscure error message. bzr: ERROR: Target directory "" already exists. [06:24] I'm 15% sure that's a bug that was fixed. [06:24] this is in debian testing [06:28] m3ga: branching a branch, or a repo ? [06:29] branch [06:29] hmm, thats gotta be a regression [06:29] * lifeless handwaves and blames bzr-colo prep work (jelmer :P) [06:29] 2.5.0dev6 in debian testing [06:36] *.log:6659032:2012-01-25 15:02:07: < jelmer> vila: no, that's not actually fixed yet but it's on my radar [06:37] thanks Peng. pity it already made its way into debian [07:29] hi all ! [07:33] I want a binary file to untrack. How to do that? [07:34] I have added that file in .bzrignore but still in bzr status I see that file appearing in modified: list [07:34] bzr rm --keep THING [07:35] you may also want to uncommit, if you just committed it, then recommit without it [07:37] poolie: I hope it won't remove the THING. Does --keep ensure that? [07:45] hariom: yes, that's what --keep does [08:02] hi vila [08:02] hey poolie ! [08:05] hi, how are you? [08:05] morning all [08:07] hi there [08:09] poolie: fine, was able to deploy pristine-tar and pbzip2 late yesterday, I'm looking at the fallouts but we're down to ~400 failures (some new ones have appeared as usual ;-}) [08:10] that's great [08:10] maybe i should follow up on the list [08:12] hey [08:25] you guys carry on, I'll fiddle here [08:44] hi all, "bzr pull" from a local git repository suddenly started failing for all my projects: bzr: ERROR: Error reading from 'refs/heads/'. [10:01] hghgnh lp downtime [10:10] jelmer: ping, pm [10:11] you should just pick a public channel vila :) [10:13] different subjects ;) Here, I'd like to mention I'll propose a merge to introduce 2.5b6 before we do 2.5.0 and that will mean retargeting the existing bugs [10:15] that is, as soon as lp is back [10:15] which seems to be the case already [10:18] yup, fdt is annoying because it's dt just when we're working, but it is at least f [10:30] halp, wat [10:30] Uncommit these revisions? ([y]es, [n]o): yes [10:30] bzr: ERROR: An inconsistent delta was supplied involving 'modules/geoip/templates/geoip.erb', 'geoip.erb-20110907035659-stu7uecbpgflsa0u-1' [10:30] reason: Unable to find block for this record. Was the parent added? [10:30] the uncommit appears to have taken - I'm now on $revno-1, but I'm scared by the ERROR message [10:32] like bug 910002 maybe? [10:32] Launchpad bug 910002 in Bazaar "uncommitting a dir rename causes InconsistentDelta error" [Undecided,New] https://launchpad.net/bugs/910002 [10:32] elmo: bzr version ? plugins ? [10:33] mgz: hmm, I do have a bunch of renames, but not of directories, but checking [10:33] that's a good bug report. [10:33] why's it still new... [10:33] vila: precise, so 2.5b5 - no funky plugins I know of [10:36] elmo: so, summary, don't be too scared because it's 'just' a dirstate error, which worst-case you can alwasy regenerate [10:37] but if you've got a slightly different from that existing bug, it would be good to add info there [10:38] jelmer: filed bug #924220 [10:38] Launchpad bug 924220 in Bazaar "ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220 [10:41] somewhat telling stat about the last few weeks, 2.5 is on r6465 but dev is only on r6456 [10:42] hm. that's a switch regression [10:42] mgz: should I be worried about 'inconsistent parents' in bzr check output? [10:43] `bzr switch -b existing_dir` now gives a LockDir error rather than just saying it already exists [10:45] elmo: well, to be safe you can do `bzr branch -r($revno-1) . ../new_tree` then copy over the changes [10:45] but no, probably. [10:45] mgz: ok [11:07] mgz: #910002 updated, thanks [11:08] elmo: thank you very much. [11:09] * mgz optimistically targets it [11:09] mgz: that indeed is a very nice bug report [11:09] so far the InconsistentDelta bug reports have all been very vague and hard to reproduce [11:10] I've put it on my queue to look at after the stuff needed for the freeze this week are done. [11:49] Most of my local Bazaar projects are set up in treeless repos where I use a checkout [11:50] I really want to try colo support, so I'm installing the nightly bzr [11:50] how do I start hacking on one of my existing projects (e.g. testtools) with colo? [11:53] hey jml [11:53] jml: "bzr switch -b colocated-branch-name" [11:54] I'd create a new testtools repo locally with colo on, then branch any works in progress into it [11:54] mgz: there's no need to enable colo anymore [11:54] as I think we discussed the other day, there's no easy migration tool from shared-treeless to colo currently [11:54] you can just do it in an existing branch [11:54] ah, I missed the nightly part. [11:58] interesting. [11:58] jelmer: and I can blame you if everything goes pear-shaped? [11:59] jml: well, there are still quite a few rough edges [11:59] but you won't lose any data [11:59] it's not a new repo format or anything like that [12:00] jelmer: sweet. [12:38] jelmer: so when I try "bzr switch -b new-branch-name" and then type "bzr branches", I only see '* (default)' listed [12:43] jml: are you in a lightweight checkout perhaps? [12:43] jelmer: I am. [12:43] hello [12:44] jml: That would explain it. "bzr switch" creates branches in your original directory, "bzr branches" lists branches in your current directory [12:44] hi Stavros [12:44] i'm trying to use bzr-git, i've installed dulwich and did "bzr branch lp:bzr-git .bazaar/config/plugins/git" but it's saying "unknown protocol" for git+ssh [12:44] Stavros: it should be in .bazaar/plugins/git, not .bazaar/config/plugins/git [12:44] jelmer: sorry, that's where it is [12:44] jelmer: it fails properly when i rename it to bzr-git [12:44] Stavros: does "bzr plugins" list it? [12:45] jelmer: is that a bug? should I be using a full & proper branch with tree instead? [12:45] ah, ** Unable to load plugin 'git'. It requested API version (2, 5, 0) of module jml: if you're using colocated branches, you should beu using a full and proper branch instead; there is no point in mixing shared repositories with treeless branches and colocated branches [12:45] Stavros: which version of bzr are you using? [12:46] jelmer: good point. [12:46] 2.4.2 [12:46] Stavros: that explains it, bzr-git trunk only works with bzr 2.5 [12:46] that's weird, i have the bzr ppa [12:46] Stavros: you probably want to use a release [12:46] oh [12:46] hm [12:46] do you have it tagged? [12:46] jelmer: huh, and I guess all that's needed when fetching a project for the first time is 'bzr branch ' and that will automatically work... that's actually a lot nicer than shared repos [12:46] Stavros: or the daily build of both bzr and bzr-git [12:46] i'll just use the release of bzr-git, thanks [12:46] jml: yep, exactly [12:47] how do we branch to tags again? it's been long since i used bzr, but it was the best [12:47] bzr revert tag:bzr-git-0.6.7? [12:47] hmm no [12:47] Stavros: bzr up -rtag:bzr-git-0.6.7 I think [12:47] that worked, thanks [12:48] Stavros: you ctually want 0.6.6 I think [12:48] jelmer: yep, that worked, thank you [12:48] hmm. [12:48] you might want to make the error messages a bit more descriptive :/ [12:48] also makes it a bit less cumbersome to write a command that shows branches with unmerged revisions. [12:49] ugh, I wish fewer projects I worked on used virtualenv... [12:49] jml: virtualenv is awesome, why don't you like it? [12:50] Stavros: we keep going back and forth on this; the reason the error messages are less intrusive is because people kept complaining about them. [12:50] Stavros: in a nutshell, because it requires too much network access. [12:50] jelmer: even something like "unsupported protocol, see 'bzr plugins' for details" would be nice [12:50] jml: ah [12:50] jml: you can use pip with freezing [12:51] bzr-git is amazing, oh how i love it [12:51] has bzr gotten significantly faster in the past year? i switched to git from it for the speed, but git is a mess [12:52] Stavros: yes, 2.5 will be a lot faster [12:52] fantastic [12:52] how stable is 2.5? [12:53] jelmer: after branch lp:testtools, 'bzr branches' says '* (default)', then if I switch -b new-branch, only that new-branch appears in the 'branches' listing. How do I get back to trunk? [12:53] Stavros: you should have gotten an error message about versioning when attempting to use git+ssh://. You didn't? [12:53] jml: "bzr switch -b trunk" [12:53] jml: The initial branch is unnamed, it's not named trunk [12:54] jelmer: no, the exact message is: bzr: ERROR: Unsupported protocol for url "git+ssh://git@github.com/skorokithakis/django-browserid.git" [12:54] jelmer: but if I'd started hacking on that new branch then I wouldn't be able to do that without first figuring out the revision on which I diverged, right? [12:55] Stavros: ah [12:55] jelmer: is https://bugs.launchpad.net/bzr/+bug/588020 righly a colocated bug? [12:55] Launchpad bug 588020 in Bazaar "tab completion should honour switch lookup path" [Wishlist,Confirmed] [12:55] Stavros: can you perhaps file a bug report about that? That's definitely a bug. [12:55] sure [12:55] with bzr or with bzr-git? [12:55] Stavros: bzr [12:56] jml: somewhat - it's an issue with sibling branches; that includes colocated branches but also "siblings" that happen to live in the same shared repository [12:56] jelmer: so I guess that unless you are some kind of weirdo you almost always want to do 'bzr switch -b trunk' after fetching a branch for the first time [12:57] do colocated branches shelve your uncommitted changes when switching yet? [12:57] jelmer: I see. I was about to file a bug for tab completion for colo branches but I think that bug covers it. [12:57] Stavros: no [12:57] ah :/ [12:57] Stavros: personally I wouldn't really want that behaviour, but I guess it might make sense for switch to have an option to do that. [12:58] jelmer: i would love it, instead of having to use different folders, if i could have a shelve per branch [12:58] that way i could switch my uncommitted changes around [12:58] I think shelves are per checkout at the moment though. [12:58] so it's not just a matter of running shelve before the switch, you would actually have to change the way shelves work. [12:59] there are arguments both ways on that [12:59] mgz: how do you mean? [12:59] jelmer: ah :/ [12:59] I find sometimes I'm glad my shelves are all on ./tree but sometimes they should be following ./feature-branch [13:00] mgz: for what Stavros is asking about, you would definitely have to have them per-branch though [13:00] jml: I think so too [13:00] what i want is colocated branches to contain my uncommitted changes, i don't really mind if this isn't implemented via shelves [13:00] it would just be nice if this were possible [13:01] right, it's different ways of working [13:01] Stavros: you don't want them all shelved onto the same shelve though [13:01] Stavros: is what I'm saying [13:01] I quite often just start off on trunk then switch when I know what to name the thing I'm hacking on [13:01] Stavros: you could always commit/uncommit before switching? [13:01] jelmer: oh, yes, probably not [13:01] jelmer: yeah, that's a solution [13:01] it'd be nice if it were done automatically [13:01] i might write a plugin to do it [13:02] commit with some special commit message, uncommit if the last commit matches the message when switching [13:03] I wouldn't want to do that automatically in the core, because it would really pollute the repository [13:03] but yeah, you could very well do that as a plugin [13:04] how hard is that to write, as someone very familiar with python but not at all with bzr plugins? [13:05] Stavros: I found it pretty easy [13:06] great, i'll give it a stab later today then [13:06] it'll just commit and uncommit, how hard can it be [13:06] although i guess it would break things if you push [13:06] hmm [13:06] Stavros: I found existing plugins and bzrlib/builtins.py to be the best places to start [13:06] jml: ah, i'll try that, thanks [13:06] i'll try to find a simple plugin and look at it [13:07] bzr-grep is pretty simple, iirc. [13:07] aha, i'll look at that then, thank you [13:15] vila, are you there [13:16] tricky question... [13:16] I'm having a late lunch and reading the backlog ;) [13:17] vila, one of my coworker just made a huge mistake :D [13:18] He removed a lot of files, in different commits, merged with more recent commits, then commited the merge and pushed again... [13:18] I need to undo all what he did, without touching other team members commits because they are good [13:18] But looking at the qlog, I can see its merges with subcommits -the good ones- [13:18] How can I just undo its modifications ? [13:19] (For example, the last commit is a good one, but the 4 previous are bad, then 5th back is good, and the 6 back is wrong... [13:20] So I would need to unco changes made in commit -2..-4, and -6 for example [13:20] jelmer: just to distract you further, have you got 30 seconds to check my thinking on [13:21] jelmer: feel free to revenge bug me about anything during the week [13:21] Merwin: same as yesterday, merge the reverse range of the revisions you want to undo, check the diff, commit, rinse and repeat for all ranges [13:22] vila, I'll try, thanks [13:22] vila, but the "good" commits are in merges, so I don't see them in bzr log [13:22] I just see my bad-coworker commits [13:22] mgz: +1, though you might want to always convert to a list in case iter_entries_by_dir returns a sequence rather than an iterator [13:23] but that loses the ability to only do the work for the first item [13:24] I guess for filter like this it's already done everything? [13:24] there's only one thing matching the given file-id [13:24] mgz: there is only one item, so I don't think that's a big deal :) [13:24] Merwin: use 'bzr log -n1 -l32' to view lower level commits (-n) [13:24] vila, removing a "parent" commit (a merge commiut) won't remove all its children ? [13:25] I guess an alternative spelling would be: for i in iter(): return i; raise [13:25] which is actually a bit neater... [13:25] yeah, that works too.. [13:25] * mgz uses that [13:26] Merwin: when you cherry-pick, you remove nothing [13:26] Merwin: actually when you merge you remove nothing either, cherry-picking a reversed range doesn't remove the revisions either it only applies the opposite change [13:28] mgz: being able to *move* a shelve would be really nice [13:28] hum [13:28] mgz: some revisions may need to be pulled too [13:32] vila: it would, but only if it was then available when switching back [13:32] mgz: err, not sure we're on the same page, I was thinking about an explicit command to move a shelve from one tree to another [13:34] vila, I can't male it work. The commit 350 is a "merge" commit. I want to keep all commits under it, but exclude modifications made by the guy. I try bzr merge -r 350..349 . but it seems that it cancels all subcommits [13:35] right, but needing to manually move it back again would be a little annoying too [13:36] Merwin: well, yes, 350..349 includes all children, you probably want something I can;t describe without seeing your history though ;) [13:43] Merwin: but you can address lower level commit by revno too, use their dotted representation that log -n1 will display [14:02] mgz: rubber stamp for https://code.launchpad.net/~vila/bzr/beta6/+merge/90869 ? [14:02] jelmer: see above and check your news entries :-p [14:03] jelmer: kidding, don't lose time on that ;) [14:03] jelmer: but I don't know if pqm will be as friendly ;) [14:07] ok vila I think I got what I wanted! In fact if I want to cherrypick only the modifications done between a bzr merge and a bzr commit, I have to do bzr merge -r350..XXX.YYY.ZZZ, with XXX.YYY.ZZZ being the last commit before the merge [14:07] Thanks for your help... again ;) [14:07] yup exactly [14:08] * vila wishes this can some sort of drap-and-drop operation from qlog or something... [14:08] s/can/can be/ [14:09] The GUI is too limite IMHO for these use cases :) [14:09] yup... for now ;) [14:10] vila: done [14:10] thanks [14:13] some of the pending bugs retargetted may want to be 2.5.0 again, but can see when the freeze happens which got done [14:15] oh, just a sec, I'll make the 2.5.0 milestone active again [14:16] done, feel free to retarget [14:16] and sorry for bug spam [14:17] jelmer, mgz : https://code.launchpad.net/~vila/bzr/920455-ssl-defaults/+merge/90693 should now be ready for final review [14:18] vila: looks like you still need a relative path for the installer versions [14:19] I need a path yes, why relative ? [14:19] and relative to what ? Oh, you mean relative to sys.executable for windows ? [14:20] but yes, the intent is to do two one-liners fixes when windows and osx installers have a proposal [14:20] just `os.path.join(os.path.dirname(sys.executable), "ca_bundle.crt")` or something wouldn't hurt [14:21] bzr_ca_bundle.txt ? Or is the executable already in a bzr-private directory ? [14:22] it's in "Program Files\Bazaar" or whatever on windows for the all in one installer, and Python26 etc otherwise [14:23] ok, done then. People that don't use the all-in-one installer are supposed technical-savvy enough to set it up themselves in bazaar.conf [14:24] there's no reason to prefix the name at any rate, there's nothing bzr specific about certs. [14:24] and pushed [14:26] and have you double checked that you do actually get the pretty error rather than random junk if a particular dir doesn't exist? [14:30] yup, it's explained in one of my comments with instructions to reproduce ;) [14:31] double-check welcome as I went to a lot of small changes trying to support 'optional' but I'm pretty sure I didn't break that in the end [14:32] i.e. the logic is: if you defined ssl.ca_certs, it should be valid. When we need it, we query the config, if it doesn't exist, we abort (you ask for verification, we need some valid path) [14:34] but required is the default, so they didn't ask as such, the initial branch had various nitpicking about the connection-to-https case needing to have a pretty message about disabling checking when it fails [14:34] I'll try out your branch downstairs in a bit [14:36] hi. being an plain cvs user, i am forced to import a subversion repo into a (new) bzr repo. is there a 5-minute howto in the man/info/web? thanks for hints [14:36] mgz: yup, indeed the tension is between 'required' being the default and ssl.ca_certs *not* providing a valid default ;) [14:38] * trebor_dki found http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ - but that is (to me) about using bzr as a svn (super-)client. [14:39] trebor_dki: the entire repository (all branches) or just a single branch? === tchan1 is now known as tchan [15:09] jelmer: (sorry for delay) - the entire repository [15:10] it is a move from svn to bzr [15:23] anyone have thoughts on how i could get libvirt importer fixed: http://package-import.ubuntu.com/status/libvirt.html#2011-05-26%2020:07:23.558315 [15:27] * trebor_dki found this: svnadmin dump -q path/to/my_svn_project > my_project_dump;; bzr svn-import my_project_dump new_path/to/my_project;; is this the way to migration? [15:29] jelmer: bzr-pqm r83 breaks lp-land, because it calls BranchConfig.get, which doesn't exist. [15:32] trebor_dki: you probably just want to call "bzr svnimport /path/to_my_svn_project project.bzr" [15:32] ehm, "bzr svn-import ..." (with a dash) === RenatoSilva is now known as Pikachu [15:48] vila: so, the current SSL config error handling is borked [15:49] I may be able to do something sane on the trace side when ssl.SSLError is raised, I then just need a suitable error for the config issue raised as well rather than the useless generic one [15:49] then the trace.note stuff in connect_to_origin can go, having been absorbed at a higher level [15:49] borked how ? In which case ? [15:50] see mp. [15:50] 'Bad value' sucks. [15:51] given we're breaking something that used to work, the message needs to be totally clear about how to fix the issue [15:52] `bzr help ssl.ca_certs` could do with being a lot more detailed too. [15:52] then move the trace you like into ca_cert_from_store *before* raising bad value [15:53] you can do that, just need to copy the block from `if ca_certs is None` below which I presume now never gets hit? [15:54] raising a custom error would still be nicest [15:54] hmm [15:55] yeah, `ca_certs = config_stack.get('ssl.ca_certs')` is validating the file rather than just leaving None or a non-existant name [15:55] at one point I wanted to add 'See bzr help %(option_name)s' ib ConfigValueError then the help can be used to provide more details [15:56] well, I wanted.. I did and then removed it because the strings were frozen (which may have been a bad idea) [15:57] these messages aren't translated anyway atm. [15:57] (they should be) [15:57] you see what I'm talking about in HTTPSConnection.connect_to_origin right? [16:00] the trace.note call right ? [16:01] there are two [16:01] they should kinda be combined really [16:01] but we need something for all kinds of validation errors, and the cert file missing is just a particular case of that [16:02] what's the easiest way of overriding a config default for a blackbox test? [16:02] having something try and connect to a https server with a default cert file that doesn't exist and asserting the error is useful would be good [16:03] +missing [16:03] there is one trace.call and two trace.warning calls [16:03] yeah, I tried a bit but resigned, there was no obvious way to test that ;_; [16:05] monkey patch opt_ssl_ca_certs to have a different default function? [16:05] yeah, I did that at one point to unit test when trying to support 'optional' [16:06] let's backtrack a bit [16:07] we want: 1) the default value to be good for 99% of the cases, having the all-in-one windows installer and the osx installer carry the certs cover that [16:07] 2) for the remaining windows/osx users, we want a clear error message [16:08] mentioning bzr help %(option_name)s and enhancing the help *and* keeping the trace.note and trace.warnings where they are ? [16:09] plus a bit of editing, wouldn't be too bad [16:09] mgz: by the way, we're not "breaking something that used to work", really, we fixed https for urllib that wasn't verifying ;) [16:09] though a little backwards compared to the error-then-advice approach trace.report_user_error has [16:10] the effect is breakage, it's good breakage, but I want to avoid hundreds of bug reports about an intended change [16:11] mentioning the default path is one thing config is doing right that the previous version didn't [16:11] yeah, me too, that's why I want to fix this asap but the current implementation is already known to not be the final one, we really want support from authentication.conf [16:12] err, why do you backwards ? We display the error mentioning the help, the advice in the help so it will displayed after the error too no ? [16:13] or do you want the help itself to be part of the error ? [16:13] nope. [16:13] I like the advice after [16:13] moving the trace calls around would mean it gets printed first, which is till okay. [16:14] *still [16:19] wgz: http://paste.ubuntu.com/824008/ === yofel_ is now known as yofel [16:24] vila: yeah, that kind of thing is nice. could also special case ConfigOptionValueError in trace, there are benefits both ways. [16:24] have we got a standard form of marking commands? I use backticks, but that may just be me. [16:26] I really want the advice about disabling right there in the error [16:26] and ideally not duplicated in several places. [16:26] no standard, some errors use double-quotes most use nothing [16:27] the problem is that we want a valid path, so config is the right place to check that, [16:27] hmm [16:28] but config users can't rely on config to actually ensure a path is correct [16:28] wgz: can you redo your test after changing 'error' to 'warning' for ssl.ca_certs ? [16:28] as they may be using the value later, and files can move etc. [16:29] ^sure [16:29] right, but at one point the config is queried and at *that* point the file should be in the right place [16:31] vila: http://paste.ubuntu.com/824030/ [16:31] that's more like what wget does, though still not *completely* perfect :) [16:32] perfect enough ? :-D [16:37] wgz: pushed [16:37] with some more minor tweaks [16:37] http://paste.ubuntu.com/824042/ [16:37] argh, crossed on wire ;) [16:37] None ?? [16:38] apparently. [16:38] err, and the meaning is ? [16:39] I'm built against a slightly newer openssl than default Python 2.7 config, but I doubt it's changed [16:39] there are two 'raise's there, I just edited to use only one, but we'll raise if we see 'None' [16:39] s/$/ anyway/ [16:39] None is just what I observed the errno is if we don't supply a string for ca_certs [16:40] the trace functions kinda suck, we need to get away from using them [16:40] but still use ssl.ca_reqs=required ? [16:41] grr, that's the case I was getting rid of by using error instead of warning ;_; [16:42] config just doesn't have enough context to give good errors [16:43] right, but we should not accept ca_reqs=required and ca_certs == None, no need to even try [16:44] yeah config does not have enough context but if we go too far from config we can't point to config anymore [16:44] anyway, I've distracted you enough, what you have will do for now and I can tweak later [16:45] wrapping both ConfigValueError and SSLError in a BzrError with extra stuff would work as well. [16:46] would then avoid the duplication in those two locations [16:47] hello, are Revision.message guaranteed to be unicode objects? [16:47] yes, with normal python caveats. [16:48] what do you mean? [16:49] wgz: as in: I push my latest changes and you'll pilot to safe harbor from there ? [16:50] python doesn't actually enforce types, so a misbehaving plugin could give you a Revision object where message is a byte string, or a tuple, or a Rabbit [16:50] wgz: this code *will* be revisited in the future anyway [16:50] or a Pony ? [16:50] a Pony would be too much to hope for. [16:50] wgz: oh right, bugs are bugs, I was more interested about the intent [16:50] vila: yes, land away. [16:50] thanks [16:51] Ponies aren't bugs. Unless they have 6 legs. Which would be awesome. [16:51] :D [16:51] eheh [16:51] Some sort of centaur? [16:52] That would be 5 legs. Traumatic amputation. He doesn't like talking about it. [16:59] wgz: err, the None bit is unclear, I'd rather not test e.errno at all so we always display the note (this except clause is fatal anyway and the only workaround is to set ssl.ca_reqs=noe) [16:59] vila: land what you have, not my changes [17:00] meh, AIUI, what I have will not do what we want on windows without a valid bundle O_o [17:01] wgz: please just do a final test with reno 6464 and I'll land it [17:15] that now shows both messages though vila [17:15] the rev before was okay. [17:16] or delete the `if ca_certs is None:` block above [17:18] wgz: will delete this block and land [17:18] cool. [17:25] * vila bangs head [17:25] I've landed the 2.5b6 change on bzr.dev [17:27] * wgz pats vila [17:27] I should have seen that too [17:30] lp-propose should default to the submit_branch location (which itself should default to parent_location if not set) [17:35] each time I look at the pqm page when the test_non_ascii are passing, I have a wtf moment thinking we're back to the time were the test suite was run twice on pqm :) [17:42] hi [17:44] i would like have a bzr repository on a server [17:44] it is a windows machine [17:45] probably smart server will be a good choice? [17:46] but how can I introduce some security, I mean something like ssh [17:46] is it possible to setup ssh on windows, or maybe there is some other way? [17:48] cob_olp: yes, cygwin's sshd supports Windows [17:48] cob_olp: ...there are certainly other approaches as well, ie. running over https [17:48] hmm [17:49] so maybe instead of cygwin ssh, the better choice will be in fact a virtual machine with linux? [17:51] because for https I will have to introduce some authentication [17:51] should I in such case put some password on my repository folder? [17:52] will bzr support such access? [17:58] cob_olp: yes, bzr supports kerberos and basic/digest auth [18:00] ok, thank you === mtaylor_ is now known as mtaylor [18:01] and what setup would you suggest on windows 2003 machine? [18:02] cob_olp: no idea, I haven't set up a https server on Windows [18:16]