=== kiko is now known as kiko-afk [00:12] hi all [00:13] hi goneri, lifeless [00:13] goneri: I'll take a look today (hopefully) === nadavoid is now known as nadavoid_afk [00:57] igc: thanks, this bug is a blocker for git-bzr inclusion in Debian [00:58] goneri: ah - ok. Thanks for the patch and for hassling me [00:59] igc: my pleasure :) [01:00] 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] gus1: I don't think stacking bzr on svn has ever really worked [01:04] :( it ~worked on the previous version. Now I have to downgrade before I can retrieve a simple diff. [01:05] upstream has a large svn repo so a non-stacked branch is unfeasible. [01:06] uhm [01:06] file a bug in bzr-svn then [01:06] if you could [01:06] somewhere in launchpad? [01:06] yes :) [01:06] will do. [01:46] lifeless: you said "2a now default" but is bzr.dev itself in 2a? [01:46] lifeless: I just did a `bzr pull` on that branch and was surprised it worked. [01:46] no, 2a is default [01:46] (I was expecting it to: 1. fail, then I'd 2. upgrade, then 3. pull would pass) [01:46] bzr.dev doesn't use its own default yet [01:47] hm [01:47] we haven't migrated yet is all. [01:47] we want to be dogfooding [01:47] but its orthogonal to getting bugs related to doing a 2.0 release done. [01:50] hm [01:50] sorry, not sure I buy that. [01:50] but that's your call, of course. [01:51] there is a bug; its assigned to LarstiQ; you're welcome to comment on it [01:51] There are certainly many many other things in your lovely work besides repository format iteration. [01:52] Mind, I feel the same way about you guys not using bzr:// [01:52] we use the smart server every day [01:52] but there is the same gap between dev and deployment [01:52] lifeless: you mean bzr+ssh:// [01:52] lifeless: I'm talking about bzr in daemon mode. [01:52] using bzr:// specifically - well, it doesn't meet our use cases :) [01:53] bbiab [01:53] see ya [02:09] back === AfC1 is now known as AfC === cprov is now known as cprov-zzz === timchen119 is now known as nasloc__ [04:08] * igc lunch [07:36] hi all [07:36] * vila pesters about kernel updates (at least against the daily ones :-) [07:38] 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] SET -> CUR? yes, its correct. [07:41] no, not that part [07:41] I had to implement .progress in testtools and that's where I'm unclear about whether testtools can have a subunit dependency.. [07:42] optional I guess [07:42] http://paste.ubuntu.com/255578/ [07:43] of course that '0' should be subunit.PROGRESS_SET [07:43] so more context: testresult modification is for ThreadsafeForwardingResult [07:44] yes [07:44] and testsuite is for ConcurrentTestSuite [07:44] or... [07:44] the change to init isn't needed [07:44] erm [07:45] it is, sorry. [07:45] but if we're doing it right [07:45] I would just implement progress() [07:45] rather than counting can calling [07:45] *counting and calling* [07:45] ThreadsafeForwardingResult should become an attribute of ConccurrentTestSuite so that bzr can override it and just defines .progress there... [07:45] huh? [07:46] I think you're smoking something at this point [07:46] the root problem is that TFS don't implement .progress [07:46] TFR should combine progress data [07:46] :-D [07:46] CTS shouldn't need to do anything [07:46] neither call progress nor implement it [07:47] some one has to relay the calls [07:47] yes, the result object [07:47] that's TFR [07:48] then someone has to SET the number of tests [07:48] no [07:48] thats what the individual results do back in bzr [07:48] show them :) [07:48] and why I asked you to insert the decorator before the CTS decorator [07:49] and the result objects show them, which is why TFR has to combine and forward [07:50] 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] ha, well, wait a minute, I need to explain more [07:51] I change the way --parallel=fork works to get a better balancing [07:51] but now, instead of creating n slices of the test suite upfront, I create the slices on demand, [07:52] 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] 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] Does that make sense ? [07:55] what drives demand? [07:56] displaying [1234/6801 in 19s] instead of [1234 in 19s] [07:58] yes, but what drives your on demand slicing thing [07:58] 30% less execution time for a full run ? [07:59] _the logic vila_ [08:00] 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] whats a slice [08:01] tests[first:last] [08:01] is tests flat? [08:01] yes [08:02] well, flatten by tests = list(iter_suite_tests(suite)) [08:02] so you know the count [08:02] yes [08:02] how many TIOP's are there? [08:02] osutils.local_concurrency [08:03] ok [08:03] so, does the thing that creates TIOPs know the count? [08:03] yes, but not the result object [08:04] yes, but it doesn't know not the result object [08:04] yes, but it doesn't know the result object [08:04] it's in fork_for_tests [08:04] which creates the suite [08:04] you should decorate the suite [08:04] erm [08:04] no [08:05] you want to decorate the suite, and decorate the result that the suite is run with [08:05] the first decorator will issue the count you know [08:05] the second will eat progress() calls so that the external counts are not passed forward [08:06] 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] you don't need to decorate tfr [08:07] you just said so ... [08:08] no, I said you need to decorate the result you're run with [08:08] you'll end up with [08:08] BzrTestResult <- ProgressHider <- TFR [08:09] You mean BZRTransformingResult ? And what is ProgressHider ? The misterious culprit ? === Toksyury1l is now known as Toksyuryel [08:12] yes [08:12] you need: [08:12] a test result filter to stop progress data from children [08:13] thats all [08:14] wow, you're telling me that to have progress reporting I need to stop progress data, let me have one more coffee :) [08:15] yes, because you want to do a global optimisation (your TIOPs) [08:16] ok, that means I may have been on the right path, yesterday but failed to realize it, [08:16] I think I will make a first submission without the progress part and add it in another submission, to make things clearer [08:28] hi vila [08:28] hi poolie ! [09:21] hello [09:22] i'm trying to bzr merge but i get : bzr: ERROR: No location specified or remembered [09:22] please help [09:22] benchik: what do you want to merge from? [09:22] benchik: `bzr merge location/to/branch/to/merge/from` [09:22] LarstiQ: the cwd [09:23] benchik: ok, what do you want to merge in to the cwd? [09:24] LarstiQ: i always did bzr merge from a dir where i have the sourcecode and it worked, today it doesn' [09:24] t [09:25] benchik: that must have been a different dir [09:25] nope [09:25] 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] benchik: which in this case is not set [09:26] LarstiQ: it was set before. don't know what happened [09:27] LarstiQ: ok i gave it the full path and it worked but i wonder why did it forget the path [09:28] 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] benchik: or 4) this is not the branch you think it i [09:28] s [09:28] i think it's the former few [09:30] * igc dinner [09:48] hey LarstiQ ! [09:48] hey vila :) [10:06] 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] when trying to commit such added files to be strict [10:10] should I report it as bug ? [10:10] matkor: yes [10:24] matkor: i think it's a known bug [10:24] you should be able to find it then [10:24] sorry [10:32] 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] you can click 'affects me too' or comment on it [10:41] hi [11:27] how do i make bzr forget the submit branch? [11:35] ah, never mind === beuno_ is now known as beuno === kiko-afk is now known as kiko [14:26] morning jam :) [14:26] morning vila [14:26] I'm a little slow today, have a mild fever [14:27] ow [14:27] jam: rest up [14:27] health++ [14:29] lifeless: thanks. [14:29] 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] what are you still doing up? [14:29] vila: correct [14:29] jam: good, go rest now :) [14:30] jam: or land 1.19-kg-sorted, whatever is better for your morale :D [14:32] jam: just finished raiding [14:33] lifeless: ah, I hope it went well. I assume you guys are in ToC? [14:34] tonight was a ulduar run, but yeah, wehave toc full cleared so far each week [14:37] toc ? [14:38] vila: Trial of Champions, IIRC. The current last-raid in World of Warcraft [14:38] haa, ok :) [14:40] * lifeless sleeps [14:40] nothing related to cObsessive-Compulsive Disorder (aka toc in french :-) === nekohayo_ is now known as nekohayo [15:20] night all [16:03] hey, is there anyone around that knows a bit of bzr-git? [16:03] http://launchpadlibrarian.net/30506243/windmill-trunk-log.txt [16:14] kiko: hey, rockstar filed that one as bug 414918 [16:14] Launchpad bug 414918 in bzr-git "Pitivi import fails" [Undecided,New] https://launchpad.net/bugs/414918 [16:14] doesn't help you much though [16:15] 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] hi [16:32] 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. === beuno is now known as beuno-lunch [16:34] saedelaere: there is a cia plugin [16:34] and does this plugin work with sourceforge? [16:35] I have no idea on what sf does [16:38] ok thanks [16:38] perhaps i can get it to work [16:40] saedelaere: you can trigger it locally instead of on sf [16:43] http://people.samba.org/bzr/jelmer/bzr-cia/trunk/ [16:43] damn the directory is empty [16:55] it's a bzr branch :) [16:56] I thought anybody using bzr has to be used to empty directories :) [17:41] lol ok now i see :) === beuno-lunch is now known as beuno === abentley is now known as abentley-lunch === EdwinGrubbs is now known as Edwin-lunch [18:04] wow, who said downloads were hard to find at https://edge.launchpad.net/bzr ? :-D [18:04] vila, I did [18:04] and I fixed it! [18:04] :) [18:05] beuno: woohoo, that's a change for sure :-) === Noldorin_ is now known as Noldorin [18:21] lifeless: you still awake? [18:22] oh, hrm, probably not [18:22] anybody around who can point me to info on subtree support stuff? [18:28] mtaylor: try abentley-lunch (after his lunch that is :) [18:29] vila: sweet. thanks [18:30] abentley-lunch: whenever you aren't eating lunch... [18:30] mtaylor: as appetizer read: http://bazaar-vcs.org/NestedTreesDesign === abentley-lunch is now known as abentley [19:26] mtaylor: The subtree stuff is not ready for use yet. === Edwin-lunch is now known as EdwinGrubbs [21:30] moin [21:41] 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] I know shelve/unshelve but it's not quite the same thing.. [21:42] hno: you can try a combination of bzr branch . ../feature; cd ../feature; bzr merge --uncommitted ../trunk [21:44] hno: so you're already writing some code [21:44] hno: and you want to turn it into a branch? [21:44] LarstiQ: Thanks.. could obviously be improved a bit.. [21:44] lifeless: Yes. [21:44] bzr switch -b ../newbranch [21:46] lifeless: bzr: ERROR: no such option: -b [21:46] well, you have something to look forward too in a newwer bzr:) [21:47] lifeless: 1.18? [21:50] lifeless: Hmm.. ChangeLog says -b was added in 1.17, but I am using 1.17.. [21:51] could be a plugin intercerpting it [21:52] lifeless: Only plugin I have is bzrtools I think.. [21:52] lifeless: or a misattribution [21:52] try bzr help --no-plugins switch [21:52] lifeless: Not mentioned. [21:53] ok [21:53] docs are wrong then :( [21:53] where do you see 1.17 mentioned for it? [21:55] It's under the 1.17 heading in NEWS. [21:55] ugh [21:56] Why is there a 1.17 heading in the middle of NEWS for 1.18rc1? === cprov is now known as cprov-afk [22:04] hno: is 1.17 repeated? [22:06] hi lifeless [22:07] hi Noldorin [22:07] lifeless: i got a reply back from the server admin [22:08] http://pastebin.ca/1535577 [22:09] i instructed him to attempt pushing a bzr repo [22:09] but he seemed to ignore that :S [22:09] its definitely not operating normally for win2003 server [22:10] heh [22:10] yeah [22:10] but the thing is, a simple rename does work fine [22:10] we have other users using that platform without the issues you've reported [22:10] so it's clearly the sequence of commands that causes the problem [22:10] yeah [22:10] i know [22:10] here's what I'd do [22:10] there is a built in ftp client in windows [22:11] if you start cmd.exe [22:11] then type 'ftp' [22:11] yeah. there's one in windows explorer too [22:11] ok [22:11] you could use the trace we made to create a series of commands [22:11] put that in a text document [22:11] then paste it into that window [22:11] and the ftp client will run them [22:12] I would include every command [22:12] yeah, that's what i was going to suggest to [22:12] and the commands that put files - you'll need to create files on disk locally that you can put up [22:12] so i'll attempt that right now [22:12] maybe that will be clearer to the admin as well [22:15] lifeless: should i use the dhtransport log for a push using the unmodified bzr program? [22:15] Noldorin: that would make sense to me [22:15] ok [22:15] skip the chmods as it happens without them [22:15] yeah [22:16] and i'll just replicate the appropiate filesystem structure for the repo to test [22:29] 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] :( [22:33] 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] heh [22:35] i'm probably confused mainly because i'm tired [22:36] and because windows ftp servers are god awful [22:37] Are they? Last time I accessed one I din't have to notice apart from slightly different directory listing than usual.. [22:38] well my one is at least [22:38] lifeless will verify that :) [22:38] 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] 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] hno: we have one that claims a rename worked but prevents renaming a different dir to the original path [22:40] mv foo bar [22:40] mv quux foo *boom* [22:40] but the first command doesn't error, and you can even rm bar/gam; rmd bar before the second mv [22:42] lifeless: judging by the log, bzr doesn't seem to be understanding the error messages the ftp server replies with [22:44] 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] Noldorin: the server is giving an error? [22:45] Noldorin: could you put your test case and the output you get in the bug please ;) [22:45] well if you look at the -dtransport log, bzr complains about not being able to parse the server error response [22:45] the one i showed you last time [22:45] Noldorin: hmm, I didn't see that. [22:46] Noldorin: we should still be treating it as an error ... [22:48] yeah.. [22:48] you see it now? === kiko is now known as kiko-afk [23:04] denys: hm it's a good question [23:04] 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] or if not, it might be tasteful to add one [23:05] poolie: not from the request [23:05] jam, are you still around? want to catch up? [23:05] denys: I'd be inclined to do TLS by just opening with an SSL handshake [23:05] 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] the server can decide that it doesn't look like a normal handshake and switch to it. [23:05] lifeless: just have the server say 'oh that looks like ssl'? [23:06] yes [23:06] they aren't confusable AFAIK :) [23:06] mm [23:06] that could be cleaner [23:06] iirc you disliked the idea of it just detecting http in the same way though? [23:07] HTTP clients don't know how to handle an older version of our server [23:07] browsers specifically [23:07] I thought it would be nice to negotiate the encryption wanted/supported [23:07] denys: doesn't SSL do that itself? [23:08] denys: also, any negotiation done in cleartext can't be trusted, it could be attacked to get a lower level via MITM [23:08] lifeless: no. there are different incompatible SSL and tthen there TSL and then there is what ever they'll invent next [23:08] 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] lifeless: that's a point I have been worrying about [23:10] my plan was to start with the lowest common denonminator [23:10] add negitiation latter if wanted [23:12] the lowest common denominator is already in my ssl patch - I just want to make it opportunistic [23:13] I have code to make the decision in authentication.conf [23:19] 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] right, getting to native authentication would be great [23:20] and [23:20] well, now actually [23:20] to be a bit more specific [23:20] authentication and encryption that don't rely on OS accounts or setting up a separate server or client would be great [23:21] that doesn't necessarily mean it needs to be within the bzr protocol [23:21] that's what I want [23:21] perhaps we should do both of them by acting as an ssh client and server? [23:21] I want to explore te [23:21] the bzr server option [23:22] many admins will never agree to give external ssh accounts [23:23] not in french universities anyway :-( [23:23] i'm suggesting that you run [23:23] 'bzr serve --ssh' [23:23] and it listens on some port [23:24] and authenticates you against a bzr-specific database of accounts and keys or passwords [23:24] using paramiko [23:25] I don't want to do something this specific. I prefer to setup a framework where arbitrary authentication methods can be setup. [23:27] lifeless: so would an ftp login to my server be of some use to you? [23:27] just for a bit of testing [23:27] a bit like PAM, but simple instead [23:28] ok [23:28] you realize there's some scope for that within ssh? [23:28] i'm just thinking: there's already a protocol that lets you negotiate encryption and authentication [23:29] maybe we should use it [23:29] denys: a custom ssh server will perform better than https; theres less restrictions and overhead in the way we work over it [23:30] i think he's running bzr+ssl [23:30] a la stunnel [23:30] oh hmm [23:30] that should be equivalent [23:30] 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] denys: ssh doesn't ;) [23:31] denys: launchpads ssh server doesn't use local accounts, nor would what poolie suggested [23:31] denys: the thing is: OpenSSH requires an OS account [23:31] "opensshd" uses the system account db, but there are pure python ssh servere implementations [23:31] jinx [23:32] you need some account, and then you play games with different connections [23:32] well [23:32] that's never going to fly for me [23:32] actually i don't think we're understanding each other [23:33] 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] 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] i'm suggesting just the same architecture except that the protocol encoding would be that specified by the SSH protocol [23:34] lifeless: ? [23:35] Noldorin: ? [23:35] lifeless: see my previous message :) [23:35] 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] Noldorin: I can keep giving you guidance, but for now thats about it. [23:36] ok, fair enough [23:36] denys: do you see what i mean? [23:37] i really do want to support your case of having sysadmins who aren't going to help [23:37] poolie: this is not helping me. I would like to know how to plug an encryption upgrade command into the bzr server. [23:37] i think you should do that by making connections from the request object up to the medium [23:38] and then you can call along them from the request handler to say 'start encrypting now' [23:38] but i'm kind of confused because i don't understand why that doesn't help [23:38] the thing about running the ssh protocol [23:39] lifeless: was wondering if i could get bzr to print out the exact ftp commands used in its log [23:39] it doesn't help because the request object has NO references to anything above. [23:39] Noldorin: edit ftp/__init__.py [23:40] denys: poolie: I think you're talking past each other [23:40] there is the do method and that's is [23:40] Noldorin: if you do that and make it turn on by -Dftp (see debug_flags) that would be nice to merge [23:40] lifeless: i think so too :-( [23:40] denys: I think you're talking about where to write some specific code. [23:40] lifeless: probably [23:40] poolie: could do :) [23:40] poolie: I think you're talking about the design for getting encryption hooked into bzr's server without needing OS configuration [23:41] yes, i am [23:41] poolie: you should approve my ssl patch then ;-) [23:41] well, i'm trying to answer the first one too, or assure denys that's also possible [23:44] my take on this is: [23:44] 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] lifeless: I have already done encryption up front - see my proposal on lp [23:45] yup, which is getting reviewed and polished ;) [23:45] I wanted to also provide an upgrade path for a more traditional connection [23:46] denys: what does that offer over the ssl support ? [23:47]