[01:08] splorf [01:08] mwh@grond:trunk$ cd /home/mwh/canonical/repos/bzr-git/trunk [01:08] mwh@grond:trunk$ python setup.py sdist [01:08] running sdist [01:08] warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) [01:08] error: .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/ [01:08] .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git: Too many levels of symbolic links [01:09] (something to do with the test suite i think...) [01:09] rotfl [01:09] Whee! [01:10] mwhudson: yeah, 'make check' creates an empty directory .plugins and a symlink to .. in that (to point BZR_PLUGIN_PATH at) [01:26] spiv, how are you today, and what are you up to? [01:26] for myself i'm going to do a bit more mail and then perhaps try the startup time test i've been wanting to do [01:27] poolie: which one is that? [01:28] making some assertions about the output of 'python -v bzr st' [02:04] Drat, missed poolie. [02:06] back [03:20] afk for a few hours - bbl hopefully [06:34] jelmer: hi? [06:36] spiv: hi? did you send that mail about ubuntu stories? [06:36] poolie: working on that atm [06:37] kthx [06:41] EOD for me === weigon_ is now known as weigon [06:58] hi all [06:59] hi vila [07:15] hello vila [08:06] lifeless: KnownFailure are still failures for --parallel=fork --subunit so bug #419776 is not fixed ? [08:06] Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,Confirmed] https://launchpad.net/bugs/419776 [08:07] lifeless: that's with: your fix and trunk version for subunit and testtools [08:10] vila: try now, rev 25 of testtools [08:13] lifeless: trying [08:17] spivvo? [08:23] lifeless: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit | subunit-stats [08:24] lifeless: Failed tests: 38 [08:24] with revno 25 [08:27] vila: *interesting* [08:27] vila: name one of the tests please [08:29] bzrlib.tests.per_repository.test_fetch.TestFetchSameRepository.test_fetch_into_smart_with_ghost(RepositoryFormat5) [08:29] bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks(fcntl) [08:30] BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit -s bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks | subunit-stats [08:30] Failed tests: 1 [08:43] anyone have used the win32-symlink plugin ? it doesn't behave like the msys ln command [09:11] is there a list of exit values of the bzr commit command? [09:12] vila: works for me [09:12] lifeless: argh [09:12] vila: possibly the expectedFailure support improvements in my protocol branch of subunit [09:13] TigerP: i think it's in the manpage [09:13] lifeless: sounds quite probable :-) url ? [09:13] lp:~lifeless/subunit/protocol ? [09:14] lifeless: indeed, works for me with that branch, can you merge it on subunit's trunk ? [09:16] poolie: I can only see exit codes of the bzr diff command [09:16] vila: I'll submit it for review [09:17] vila: oh [09:17] vila: actually, try this [09:18] vila: just delete BzrTransformingResult [09:18] and use subunit release [09:18] that should work, I think. === gdmfsob is now known as mishok13 [09:20] lifeless: yup, works ! [09:20] lifeless: can you update lp:~lifeless/bzr/subunit and resubmit then ? [09:21] vila: this branch is for --subunit, not --parallel, primarily. [09:21] lifeless: *you* linked it to bug #419776 :-) [09:21] Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,Confirmed] https://launchpad.net/bugs/419776 [09:21] vila: as you have fast test environment, perhaps you could delete BzrTransformingResult completely, and its tests. [09:21] vila: yes, with a comment that perhaps more work was needed ;) [09:22] wow, I missed that comment ! [09:22] ok, I thought it was linked to indicate it fixed the issue, I'll assign it to myself and fix it after having approve your patch [09:23] vila: anyhow, I know the current branch passes all tests. [09:23] So I'd like to review and land that before making other changes that need a full test run [09:25] lifeless: I had reviewed and was ready to approve but thought I tested for that bug first, I'll approve now [09:25] lifeless: approved [09:30] lifeless: please land asap so I can submit the fix for deleting BZRTransformingResult ;) [09:32] vila: pushing up now [09:33] lifeless: ? Pushing what ? [09:33] lifeless: if I could pull working versions what do you need to push ? [09:34] or did you mean pqm-submitting ? [09:35] err. wait I was too fast, that does work ! [09:35] err. wait I was too fast, that doesn't work ! [09:36] vila: to -integration, where I pqm submit from [09:36] ok, approved anyway, my objection was about fixing the bug so irrelevant [09:39] lifeless: deleting BTR works only with your subunit-protocol branch, so I'll wait for that to land before submitting the fix fr bug #419776 [09:39] Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,In progress] https://launchpad.net/bugs/419776 [09:39] vila: huh? [09:39] vila: what happens with subunit release? [09:40] KnownFailure is seen as a failure [09:40] but BTR does that [09:40] its BTR's fault ;) [09:43] yes and no, with subunit release KnownFailure is seen as a failure with or without BTR :) [09:43] testing [09:44] and with your subunit branch it works with and without BTR :) But I'd love to get rid of BTR anyway. [09:47] vila: so, 0.0.2 TestProtocolClient has no addExpectedFailure [09:47] so that should be degrading to success in _do_known_failure [09:51] lifeless: lost in the indirection via AutoTimingTestResultDecorator ? [09:52] ah yes [09:52] thats a policy change in subunit [09:53] to degrade more gracefully [09:53] I can do a separate branch for that [09:53] -protocol- isn't fully baked yet [09:53] ha :-/ [09:53] Wire changes are tricky [09:53] certainly [09:54] I'm not complaining, just trying to understand the migration path [09:54] on the other hand 419776 is not blocking so there isn't an urgency either [09:55] vila: how isn't it blocking ? :) [09:56] well, it blocks subunit usage, not --parallel=fork usage :-p [10:02] vila: I want to get stdout/warnings/log capturing working in testtools [10:02] vila: and the bzr log stuff using the same PAI [10:02] *API* [10:03] you mean log as in trace.py, not bzr log the command right ? [10:05] I mean as in printErrorList [10:06] ha ok [10:08] lifeless: that's the missing part for making your subunit protocol fully baked ? [10:08] s/protocol/& branch/ [10:08] it will show that I've closed the loop in a tolerable way [10:08] I also need t-i-p by-in [10:10] t-i-p ? [10:10] testing-in-python [10:11] ECONTEXT :-/ [10:11] its a mailing list [10:11] haaa, you need approval there ? [10:14] social not technical [10:14] buy-in, not approval [10:15] yes, that what I meant. [10:15] if I have t-i-p buy-in its a good indicator for an eventual PEP and API changes in Python itself [11:10] anyone know why bzr was removing from ohloh? [11:27] jml: no idea :-/ Where did you see that ? [11:29] ohh, I see https://www.ohloh.net/p/bzr is gone https://www.ohloh.net/p/bazaar is there [11:37] fullermd: around ? [12:20] hi all === weigon_ is now known as weigon [12:36] bialix: hi [12:36] hi igc [12:38] bialix: could I ask a favour? [12:38] bialix: we have new translations I'd like to get into Explorer ... [12:38] and then tag it as 0.9.0 [12:39] you want import? [12:39] I'd like that to go out with the 2.1.0beta2 installer jam is packaging today [12:39] bialix: I was planning to do it but I'm really tired [12:39] (started chemo again today) :-( [12:39] ok, I'll do it now [12:39] sad to hear this [12:39] bialix: mega thanks [12:40] bialix: I put out a plea for more translations on the weekend to launchpad-users and the response was *awesome* [12:40] * bialix also has mixed feelings about today poolie's mail [12:40] bialix: so you'll notice a few more [12:41] bialix: I've responsed to that thread btw [12:41] igc: I'll just import them, have no time to review [12:41] bialix: that should be ok. All I wanted was ... [12:41] yeah, a bit more :-) [12:42] (1) import of transations [12:42] (2) tag as 0.9.0 [12:42] (3) jam to package 0.9.0 in 2.1.0b2. [12:42] I think 2.0.2 should stick with 0.8.3 of explorer [12:43] import may take half hour or couple of hours. it depends how fast lp will react [12:43] igc: according to garyvdm mail in qbzr ML I think bzr 2.0.x should stick with latest stable releases [12:43] bialix: right [12:43] so 0.8.3 is ok [12:44] bialix: I hope all is going well work wise - I hear you're flat out right now [12:44] bialix: if there's no questions, I'll say good night [12:44] flat out? [12:44] busy [12:45] yep, night Ian, I'll tag it for you [12:45] thanks [12:45] night all === loxs_wrk is now known as loxs === fenris__ is now known as ejat [13:16] igc: done. [13:34] igc, do you know if there's an agenda for the bzr sprint? [13:35] * jml missed the "night all" [13:35] sleep well, I'll send an email [14:02] jml: apart from the focus defined on the wiki, not that I know of [14:08] morning all [14:09] hi jam [14:15] bialix: thanks for tagging bzr-explorer 0.9.0 [14:15] jam: :-) [14:16] jam: garyvdm has planned to release qbzr 0.16 but it seems he's not finished it. use qbzr 0.15 for 2.1.0b2 please [14:16] well, he's got a couple of hours :) but yeah [14:16] I'll use whatever is available [14:16] I'm going to be pushing for a faster "gone gold" to "official release" this time [14:16] * bialix has wanted to release 0.15.1 but... [14:17] jam: will be nice to speed up this process, really ;-) [14:18] well, I did some 'pre-build' work last week [14:18] so hopefully the build process for the windows installers is smoothed out [14:51] morning jam [14:51] hey vila [14:52] jam: care to recheck https://code.edge.launchpad.net/~vila/bzr/186920-lp-proxy/+merge/14238 [14:52] ? [14:52] jam: I can summarize here if you want [14:53] james_w`: ping, sorry for friday, I had more reading to do than I thought :) [14:53] vila: hi, np [14:53] vila: a quick summary would be nice [14:55] jam: I took your remarks into account. There was an additional glitch that is now fixed and Gordon Tyler confirmed it now works in all his setups [14:55] so a quick question about http://bazaar.launchpad.net/~vila/bzr/186920-lp-proxy/revision/4782 [14:55] jam: the remaining question is where to land (in addition to bzr.dev), you and I seem to agree for 2.1 [14:55] What happens if you were trying to use a non-standard https port? [14:56] before ? [14:56] vila: so you have the comment that "self.port" is always None, and so you grab the port attribute from whether you are using http or https [14:56] however, what if I was trying to go through my proxy to get to something like: [14:56] http://babune.ladeuil.net:26862/waterfall [14:56] You don't have to fix this to land the code, btw [14:57] I'm just probing to see if I understand what is going on [14:57] the comment is about urllib2.Request being brain-damaged and always using host = 'xxx:nn' instead of host ='xxx' and port = 'nn' [14:58] i.e. self.port is *never* used so alwats None [14:59] this is trappy because HTTPConnection objects cleanly separate host and port [15:00] there is a grey area about the proxy behavior *without* that patch regarding what port were used... but only for the CONNECT request, all other cases are ok (AFAIK) === mtrudel_ is now known as cyphermox [15:00] vila: doesn't CONNECT have to go to the same port as the rest of the requests? [15:01] (to be clear, I approve your patch, but I'd like to keep chatting to understand) [15:01] it *has* to, it weren't for CONNECT [15:01] all other requests ended up calling HTTPConnection.connect() which handle the default port, the last part of the patch is mimicking that for CONNECT [15:02] because CONNECT is like connect expect it obviously wasn't (as fullermd would put it I think :) [15:02] vila: so how does that work when connecting to a non-standard port? [15:04] jam: port is not None in that case and is propagated correctly [15:05] self.proxied_host = '%s:%s' % (self.get_host(), conn_class.default_port) [15:05] There is no "port" in that statement [15:05] hmm, does ftp dumb transport unable to read part of file? [15:05] bialix: So there is a "resume" sort of command in ftp [15:05] which I believe means you can start in the middle [15:05] I don't know how to set it up, or what the command is, etc. [15:06] Just that I've seen it happen before [15:06] I wouldn't be surprised if we don't properly support that in bzrlib [15:06] working with bzr over ftp is so slow [15:07] bialix: FTPTransport doesn't seem to implement readv, which means it uses the base implementation [15:07] which is get+seek [15:07] which is, certainly, going to download the whole file [15:07] or bzr do something wrong, there is one pack ~3MB in ftp repo and bzr trying to download much more than that [15:07] and then do it for each request [15:08] f*** [15:08] bialix: 3MB for every readv() request [15:08] FTPTransport should either implement partial reading, or download to temp files and do it from there [15:08] * bialix wonders why not cache already downloaded data [15:08] because nobody who cared enough to work with FTP put in the time to do so [15:09] right [15:09] I prefer to not care too, but I have not found any decent and cheap way to have private repos [15:11] jam: hmm, you're right, there is still something wrong here :-/ I need a more complex setup to test it (i.e. an https server on a non-standard port) [15:12] vila: anyway, it is good enough for now [15:12] you should be able to test with an http server on a non-standard port [15:12] such as babune.net :) [15:12] jam: no [15:13] CONNECT is called for https only [15:13] really? [15:14] ok I guess [15:15] that's how you established the ssl wrapping if using an http proxy for example [15:16] what if you were using an SSL proxy to a non SSL host? [15:16] anyway, I've voiced my observation, and the code is still far better than what we have today [15:16] so please land it in bzr.dev [15:16] if you want, you could land it in 2.1.0b2 if you hurry [15:19] jam: If I target 2.1.0, it will come back soon in bzr.dev right? [15:20] vila: Once I get around to releasing, I'll be 'merging up' everything [15:20] so it will be done today [15:21] (2.0.2 => 2.1.0b2, 2.0.2 => 2.0.x, 2.1.0b2 => bzr.dev, 2.0.x => bzr.dev) [15:21] not necessarily in that order, but approximately so [15:21] 2 integration branches is... a bit of overhead for RMs [15:21] jam: sorry, I'm confused, should I target bzr.dev or lp:~bzr-pqm/bzr/2.1.0 or both ? Ha ok, so I'll target 2.1.0 [15:21] vila: 2.1.0b2 [15:21] 2.1.0 does not exist [15:22] merge-up is painful because of the number of combinations to take care of [15:24] meh, why 2.1.0b2 and not 2.1.0 ? The later can be used for all releases leading to 2.1... Still confused >-/ [15:26] vila: every release gets its own branch [15:26] so you can later "bzr branch lp:~bzr-pqm/bzr/x.y.z.b" [15:26] we *could* do it differently [15:26] so far, we have chosen not to [15:28] rats, I branched too late to merge cleanly :-/ [15:29] huh ? Only for NEWS >-/ [15:31] oooh, no, the bug fixes were part of 2.0.2... [15:31] wow, weird conflict [15:31] yeah, there is some 'unknown' as to whether bug fixes in 2.0.2 should be repeated in 2.1.0b2 [15:31] for now, I've said no [15:31] others have said yes [15:31] but I don't like seeing them twice [15:31] and we're always releasing a 2.0.x at the same time as 2.1.0x [15:32] I believe lifeless originally posited that they would have different release schedules [15:32] ok ok, RM priviledge :-) I haven't seen the physical consequences yet :-) [15:32] and thus we may release one without the other [15:32] and thus we should have the bug comments listed [15:34] as long as you merge things in a coherent way, your way is good enough, you may add a note that 2.1.0b2 includes the fixes for 2.0.2 for completeness [15:34] vila: so are you targetting 2.1.0b2 ? [15:34] vila: it is in the summary [15:34] if you didn't read it [15:34] make sure it is there [15:34] because I thought I did [15:34] It is ! [15:34] Good, we agree then :) [15:34] vila: so I should clarify slightly... we need a separate 2.0.x branch from a 2.0 branch, so that once the branch is split off, we can still land updates into 2.0 [15:35] just like we need a separate release branch for at least 2.1.0 so that we can keep landing in trunk [15:35] (bzr.dev) [15:35] we *could* have a single '2.0-releases' or something like that [15:35] and then match that with a 2.1.0-releases [15:35] however, once 2.1.0 is final, we will then need 2.1-releases, etc. [15:35] that's how I organized my integration branches, 2.0, 2.1, etc [15:35] for now, we just have 1 branch per release [15:36] and not worry about what would be clustered with what [15:36] I currently have "lp" and "lps" for stable targets versus dev targets [15:37] bialix: i would think that "bzr serve" would be the easiest to set up, and provide ~ the same security as ftp [15:37] * vila runs to dentist [15:38] jam: pqm'ed, I'll be back soon [15:41] vila: I don't see it on pqm [15:58] Peng: looks like I reproduced your earlier failure: bug #471193 [15:58] Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,In progress] https://launchpad.net/bugs/471193 [15:58] I'm trying to sort it out now [15:58] I'm a bit surprised we don't run into this more often since I've been using bzr.dev for a while and doing bzr up/bzr pull regularly... [16:02] vila: I'd like to chat about possible fixes if you get a chance [16:08] huho, pqm acting again ? [16:11] vila: your patch is there now [16:11] do you have any time to chat about bug #471193 w/ me? [16:12] Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,In progress] https://launchpad.net/bugs/471193 [16:13] jam: sure, that's clearly a red-button case [16:13] vila: so I can fix it in a variety of ways [16:14] I can make the chk map code not require StaticTuples [16:14] either by changing the internals not to fail [16:14] or by wrapping more locations with "StaticTuple.from_sequence(key)" [16:14] In my ideal world, all keys in memory would be ST [16:14] so I've been trying to push the 'from_sequence' code higher in the stack [16:15] so it doesn't have to be reproduced everywhere [16:15] It isn't terribly expensive, but it is a couple of function calls [16:15] the higher in the stack they are, the less we care [16:15] alternatively, I can fix *this* bug by changing either the code that reads from Remote [16:15] (such as _benencode.decode_as_tuples) [16:15] to cast into StaticTuple earlier [16:16] or I can change BTreeBuilder [16:16] to cast into StaticTuple [16:17] so, the bug shows that the test suite is incomplete, as long as you can reproduce it with a test, you will increase the robustness [16:17] the worrying thing is: can you revert some changes to avoid the issue ? [16:17] jam: setup bzr serve on my hosting? [16:18] and why nobody running bzr.dev encoutered it sooner ? [16:18] bialix: I was mostly doing a jab that ftp is not very secure [16:18] jam: Huh! I thought my original failure was just because I had forgotten to recompile the extensions? [16:18] jam: I do a lot of bzr+ssh pulls too, so I'm surprised I haven't run into this one, either. [16:18] jam: I know it's not very well secure but it's ok for me [16:18] Peng, vila: I have very little clue why this wouldn't be deterministically failing for everyone repeatedly... [16:18] bzr serve --alow-writes is not secure at all [16:18] perhaps it has to do with the chk_map cache [16:19] it is possible that the chk_map page cache is intercepting the calls and returning the contents differently than hitting the BTreeBuilder [16:19] so only 'big-enough' pulls that overflow the cache are caught [16:19] however, _read_nodes_from_store doesn't *use* that cache at all... [16:20] so that doesn't seem to be the answer [16:20] quick, easy, switching between branches on bzr. How do I do it? [16:20] hexmode: 'bzr switch' ? [16:20] depends on how you have your branches/working trees laid out [16:20] jam: are you sure you're not running into a running-pull-with-pulled-code issue ? [16:20] vila: "pull with pulled code" ? [16:21] I think I know what you mean, and this dir has no tree [16:21] just a branch [16:21] jam: so, I've modified code in my current checkout/branch/whatever [16:21] jam: if you talk about cache with me then I should say that I'm still using pack-0.92 / 1.9 formats [16:21] vila: and I can step through the code and see the problem [16:21] jam: so you can reproduce it at will ? [16:21] and want to switch back to the pristine source, but still have my changes available. [16:21] vila: on *this* branch it reproduces every time [16:21] I haven't tried switch yet. [16:21] as the pull fails to complete [16:21] jam: in a branch where your extensions are up to date ? [16:21] hexmode: perhaps 'bzr shelve' if you want to revert to pristine [16:21] ha, the pull fials... [16:22] jam: k, reading the docs [16:22] vila: I've diagnosed the specific steps in the bug, and it is fully reproducible [16:22] the BTreeBuilder has a tuple() key [16:22] and when yo ucall "get_record_stream()" the record.key attribute is that same tuple [16:22] what I meant was: 'bzr pull' in my bzr.dev branch, i.e. the code is updated while running [16:22] vila: sure, that's what I thought, and no, that isn't happening here [16:22] jam: ok [16:22] I'm updating a tree-less branch of 2.0.2 [16:23] with a bzr.dev bzr ? [16:23] vila: yse [16:23] yes [16:23] hexmode: 'bzr shelve' will revert your changes to the previous commit, and put them 'on a shelf' to be restored later with "bzr unshelve" [16:24] jam: right, just saw that, but was thinking of a way to maintain it: i.e. branches, not temp shelves [16:24] hexmode: it also depends what you mean by "pristine source", is that a different branch, or the previous commit on this branch [16:24] jam: I think shelve will do for now, though [16:25] hexmode: I can go into deeper config to make multiple branches a bit easier to work with, but it does take a bit of explaining [16:25] jam: maybe later. Was looking at help for bzr switch: where can I find out about lightweight vs heavyweight checkouts? [16:26] hexmode: you might try 'bzr help checkouts' [16:26] jam: excellent. thanks [16:27] jam: I just pulled in my 2.0 branch without trouble :-/ [16:27] vila: so it will depend explicitly on the data stream [16:28] specifically, you 1 have to pull from bzr+ssh [16:28] 2 it has to try to read a page from the newly created btree [16:28] I do (AFAICS) [16:28] confirmed by .bzr.log [16:29] so it needs to transfer a chk page from the source, which it then needs to verify [16:29] what revno are you at when pulling ? [16:29] 4696 [16:29] note, though, that it will probably depend what pages are in your local repo already [16:30] yeah... [16:30] jam, vila: does one still should write tests for each bugfix? e.g. for fixing https://bugs.launchpad.net/bzr/+bug/389648 there is need only to add Hooks.__init__(self) to some derived classes constructors... [16:30] Ubuntu bug 389648 in bzr "internal error on bzr hooks" [Medium,Confirmed] [16:30] bzr shelve: I'm in love [16:31] vila: I feel like I understand the bug, I'm just trying to get a feel for the fix [16:31] specifically, do I make the code *stricter* everywhere [16:31] or *more relaxed* [16:31] do I push to require StaticTuples in BTreeBuilder [16:31] or do I relax requiring StaticTuples in chk_map === james_w` is now known as james_w [16:31] and to what degree ... [16:31] jam: I'm from the more stricter school by default :-) And you said you want ST everywhere. BUT, [16:32] you're also the RM and you want to release today [16:32] vila: So I *think* that for performance and memory minimal that pushing ST everywhere is ideal [16:32] So I'd say, relax for today, it's a beta, and dig that asap in bzr.dev [16:32] There is always the "transition" phase [16:32] and wondering about when is good-enough [16:32] vila: ok, I'll create a 'relax' patch in about 10 min [16:33] if you can review it, it would be nice [16:33] the decisions IMHO is about is that bug likely to hit people ? You seem to think it's quite hard to reproduce, so. [16:34] I sure will [16:34] jam: could you replace the check with a upcast ? [16:36] vila: of course I can cast it, the point is how strict to be [16:37] casting random tuples => StaticTuples makes memory consumption worse [16:37] as now you have 2 objects representing the same thing [16:37] so you *want* the caller to do the cast [16:37] I'm doing a quick "assert when a debug flag is set" patch [16:37] and cast [16:37]