| cjmason | so, is this a good place to ask questions specifically about bzr-svn? | 01:01 |
|---|---|---|
| cjmason | specifically, if the cache format recently changed? | 01:03 |
| spiv | This is a good place, yeah. | 01:40 |
| === Adys_ is now known as Adys | ||
| === Ursinha-nom is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| parthm | i am trying to write a unittest which creates a file. however the file gets created in the dir where ./bzr selftest is run ( http://pastebin.com/Krchr7LA ) | 03:56 |
| parthm | so self.assertFalse(os.path.isfile(get_filename())) fails on the second run. how do i create the file in the temporary test dir? | 03:56 |
| spiv | parthm: base your test case from TestCaseInTempDir (or one of its subclasses) | 04:04 |
| spiv | Then when your test method is run the cwd should be the temp dir | 04:04 |
| parthm | spiv: ah. thanks. i will do that. | 04:05 |
| spiv | So do that and then simply make sure you write the file relative to the cwd. | 04:05 |
| * spiv is off for the day | 04:05 | |
| lifeless | moin | 04:26 |
| parthm | lifeless: hi | 04:28 |
| MTecknology | so... I just screwed up about an hours worth of work.. Is it possible to change the commit message for a whole lot of commits? | 04:29 |
| MTecknology | That's actually the only thing I screwed up | 04:29 |
| spm | uncommit, commit? | 04:30 |
| MTecknology | spm: can I uncommit a few changes and then apply the commit message to each commit that I just unrolled? | 04:31 |
| lifeless | if you haven't done a merge, yes, by shelving at each step | 04:32 |
| spm | maybe depending on how much faffing around you do; sure. at worst you create a diff up front for each commit since the busted and then reapply the lot. painful, there may be easier. | 04:32 |
| MTecknology | at some point I need to learn how to shelve.. | 04:33 |
| MTecknology | I should have tagged these as I went too | 04:34 |
| MTecknology | alrighty, thanks | 04:34 |
| m3ga | for bzr-git, what happens to tags in the git version? | 04:52 |
| m3ga | can i branch from and merge from a git tag? | 04:53 |
| parthm | i was curious about the deprecation policy of bzr api. if something gets marked "deprecated in 2.2" ... is it removed in 2.3, 2.4 or later? | 05:32 |
| parthm | i couldn't find this info in hacking.txt | 05:32 |
| lifeless | whenever its really annoting | 05:34 |
| parthm | so for e.g. re_compile_checked is deprecated_in((2, 2, 0)) ... will it be removed in 2.3? | 05:36 |
| lifeless | if its really annoying by then | 05:37 |
| lifeless | its an individual choice | 05:38 |
| lifeless | fast removal == leaner code, worse for plugin authors | 05:38 |
| lifeless | slow removal == fatter code, nicer for plugin authors | 05:38 |
| parthm | lifeless: so the preference is to keep it around for a few releases if its not a very annoying. ok. makes sense. thanks for clarifying. | 05:39 |
| mgz | ha, parthm | 05:59 |
| mgz | you free to be distracted? | 05:59 |
| parthm | mgz: hi | 06:00 |
| mgz | you've been messing with regexps, might you know the cause of these failures? | 06:00 |
| mgz | http://float.endofinternet.org/xmlbin/dev_r5355_non_per#bb.test_log.TestLogErrors.test_log_bad_message_re | 06:00 |
| mgz | http://float.endofinternet.org/xmlbin/dev_r5355_non_per#bt.test_globbing.TestGlobster.test_bad_pattern | 06:01 |
| parthm | mgz: re.compile is supposed to be lazy. looks like its not being lazy in this case. | 06:02 |
| parthm | i think i saw something similar even on linux and forced lazyness for a test case. let me dig that up. | 06:03 |
| mgz | you had a test problem recently with it becoming un-lazy part way through the run didn't you? | 06:03 |
| mgz | did you track that down? | 06:03 |
| mgz | ...you might be able to tell I'm a little overwhelmed by bzr email currently, I know bits of lots of what's going on but don't remember any of it clearly :) | 06:06 |
| parthm | :) | 06:06 |
| parthm | mgz: basically in lazy_regex we now catch re.error and throw errors.InvalidPattern instead. so in this case it looks like re.compile is compiling immediately. | 06:07 |
| parthm | hence, re.error is not caught and gets thrown instead of InvalidPattern. | 06:08 |
| mgz | okay, so I guessed the cause right, and you are the right person to bug about this as well? | 06:09 |
| parthm | mgz: i am unable to locate where if faced this issue (it was some test case). as it was just a test case i could get away with calling lazy_regex.install_lazy_compile() | 06:09 |
| parthm | :) | 06:09 |
| parthm | mgz: what platform is this on? | 06:09 |
| mgz | says at the top of the page :) | 06:10 |
| parthm | ahh :) | 06:10 |
| mgz | okay, so you fixed the symptom by making a test that needed laziness (re)install the lazy, but you didn't track down which case was unlazying and not cleaning up after itself? | 06:11 |
| parthm | mgz: yes. you can say that :P | 06:11 |
| parthm | mgz: test_osutils.TestReCompile.test_re_compile_checked_error | 06:12 |
| mgz | I see. | 06:13 |
| parthm | interestingly thats the only case for which i saw this problem and re_compile_checked function is deprecated so i seemed ok to do that. looks that all tests see this on win32. | 06:13 |
| * mgz bops parth on the head for cheating like that | 06:13 | |
| mgz | yeah, the platform varience does seem a bit odd | 06:14 |
| parthm | mgz: i can try to look into this. though i am not sure whats causing this ... could be lazy_regex or maybe something to do with the test suite. | 06:15 |
| mgz | I'm on it. | 06:15 |
| mgz | ah, okay, I understand this now. | 06:17 |
| parthm | mgz: its weird. i am interested in knowing whats causing this. thanks for looking into this. | 06:17 |
| * parthm needs to be more careful with his tests | 06:17 | |
| mgz | tests don't generally *require* lazy regexp | 06:17 |
| mgz | in fact, the test_lazy_regexp makes sure to clean up after itself | 06:17 |
| mgz | your nicer error messages thing *does* require laziness, which then means those tests you changed should do the same | 06:18 |
| parthm | mgz: are you saying that the test setup specifically disables laziness? | 06:19 |
| mgz | no, but previously no test actually needed it it seems | 06:20 |
| mgz | and as it gets turned *off* by test_lazy_regex that's a good thing | 06:20 |
| parthm | mgz: so test_lazy_regex turns if off but never turns it (lazyness) on again. | 06:21 |
| mgz | right, but that's not actually the problem | 06:21 |
| mgz | the problem is with your change, if selftest is run through the bzr script, it does: | 06:22 |
| mgz | # instruct bzrlib/__init__.py to install lazy_regex | 06:22 |
| mgz | sys._bzr_lazy_regex = True | 06:22 |
| mgz | but if it's *not* run through the bzr script, you've now got tests that fail because they silently assume the lazy | 06:22 |
| mgz | so, really both your changed tests and these old lazy ones should cope with either state cleanly | 06:23 |
| parthm | mgz: ah. maybe behavior of lazy_regex module should be lazy always unless the called explicitly disables laziness or calls _real_re_compile? | 06:25 |
| mgz | maybe just self.overrideAttr(re, "compile", lazy_regexp.lazy_compile) | 06:25 |
| mgz | in tests that need the lazy now. | 06:25 |
| parthm | mgz: updating the tests would definitely work but the module behavior being somewhat unpredictable in terms of laziness seems a little odd. | 06:26 |
| mgz | well, the problem is it's a monkey patch parth, the point is you can't really rely on it | 06:26 |
| mgz | currently, someone running the bzr script will have it, but someone importing bzrlib won't | 06:27 |
| mgz | so, I guess the remaining question is whether any of the bits of bzrlib code you've changed now break if re.compile is eager | 06:27 |
| FryGuy- | is the guy that did bzr-tfs in this channel? | 06:28 |
| parthm | mgz: i would think that if anyone is using g=Globster(patterns) ; g.match sequence directly would be impacted by this (won't get InvalidPattern) | 06:31 |
| mgz | so, should the Globster code be changed to use lazy_regex.lazy_compile directly? | 06:32 |
| parthm | mgz: won't it be better to just do this at bzrlib level. | 06:33 |
| mgz | you tell me! :) | 06:33 |
| parthm | mgz: i think it may be better have lazy behavior by default at bzrlib level. at the moment InvalidPattern gets raised only in globbing.py and lazy_regex.py but in case there is some other function there gets updated to handle this and give a custom message there may be a problem. | 06:38 |
| mgz | I'm trying changing bzrlib.globbing now | 06:38 |
| mgz | ...guess I ought to file a bug here, there are some non-obvious choices to be made | 06:40 |
| parthm | mgz: lazy_regex.LazyRegex._real_re_compile catches re.error and raises InvalidPattern. ... so anytime _real_re_compile is bypassed we will get this. | 06:41 |
| parthm | filing a bug sounds like a good idea | 06:41 |
| mgz | oh boy that's some bad naming | 06:42 |
| parthm | mgz: which one specifically :) | 06:42 |
| mgz | _real_re_compile is both a module global containing the real re.compile, and a method that thunks | 06:42 |
| parthm | mgz: ahh. yes. i noticed that. | 06:42 |
| mgz | I couldn't parse your sentence till I worked out you were talking about the *method* | 06:43 |
| parthm | mgz: maybe we should be monkey patch the non-lazy re.compile also to raise Invalid pattern. so irrespective of the lazyness status bzr always shows the clean error message. | 06:44 |
| mgz | meh, no. | 06:44 |
| mgz | I think we should make places in bzrlib that care use lazy_compile directly. | 06:44 |
| parthm | mgz: in that case i think doing it at bzrlib.globbing level may work fine. | 06:46 |
| mgz | the failure in bb.test_log is worrying me currently | 06:46 |
| mgz | where's the exception raised by the invalid pattern meant to be caught? | 06:47 |
| * parthm looks at the stack trace again and starts opening files | 06:48 | |
| mgz | I don't really understand how that exception is propogating at all, run_bzr should catch everything... | 06:50 |
| parthm | mgz: is laziness being set in this case? | 06:51 |
| mgz | no. it's the plain re.compile | 06:51 |
| mgz | sre_constants.error is a subclass of Exception, so it should get caught... | 06:53 |
| parthm | mgz: so run_bzr just logs the exception? is selftest failing in this case? | 06:54 |
| mgz | well, it should convert it to a failure return code, which that top line is expecting... | 06:55 |
| mgz | darn blackbox tests, pain to debug | 06:55 |
| mgz | ah, I see it. bzrlib.commands.run_bzr_catch_user_errors is pickier than run_bzr_catch_errors | 06:56 |
| mgz | might mean it's not a regression from your changes, I'll run these tests against a bigger history | 06:57 |
| parthm | mgz: ok. so would you be patching bzrlib.globbing for installing laziness? | 06:58 |
| mgz | I'm going to propose that, it's maybe not the smartest alternative though | 06:58 |
| mgz | okay, need to get these tests running then file bug, then commit changes | 06:59 |
| * mgz beavers | 06:59 | |
| parthm | mgz: thanks for looking into this. | 06:59 |
| mgz | okay, looking at the diff of r5339 now I get it. | 07:10 |
| vila | hi all ! | 07:10 |
| vila | mgz: hey | 07:10 |
| mgz | morning vila! | 07:11 |
| vila | mgz: why not: test passing, commit, file bug ? | 07:11 |
| vila | just curious | 07:11 |
| mgz | --fixes | 07:11 |
| vila | OIC | 07:11 |
| vila | I do: file bug, branch bug#, test, hack, test, commit :-P | 07:12 |
| mgz | right, I should have filed the bug a long time ago, but I thought this was a shallower issue than it was | 07:12 |
| mgz | like, change a couple of setup lines in some tests, rather than actual logic | 07:13 |
| vila | yeah, I have that bad habit to file bugs too late :-0 | 07:13 |
| * mwhudson is using a packs branch for a change | 07:22 | |
| mwhudson | some things have definitely gotten better :-) | 07:22 |
| mgz | oo, vila, vila: can you try Python 2.7 again? | 07:22 |
| vila | mgz: same branch ? | 07:22 |
| mgz | I left a note last night about what went wrong the first try | 07:23 |
| mgz | yeah, bzr is unchanged, need to fiddle with testtools though | 07:23 |
| vila | mgz: I just read that, but it's unclear about which *previous* testtools version you're talking about | 07:23 |
| mgz | move a closing bracket left a bit :) | 07:23 |
| mgz | ah, er, well, either 0.9.2 or the one line patch for the linked bug | 07:23 |
| vila | ok, one-liner aplied, launching a run | 07:28 |
| vila | hu ho | 07:28 |
| vila | I left 2 VMs running yesterday blocking the whole process :-/ | 07:30 |
| vila | mgz: here is yours: http://babune.ladeuil.net:24842/job/selftest-maverick/8 | 07:32 |
| vila | mgz: http://babune.ladeuil.net:24842/job/selftest-maverick/8/consoleFull shows some weird stuff, looks like subunit leaks in the wrong stream | 07:32 |
| vila | or testtools :-/ | 07:32 |
| vila | I wonder if my setup is a bit screwed when it comes to take source changes from the master to a slave... | 07:33 |
| vila | argh, yes | 07:33 |
| vila | or not | 07:33 |
| vila | python use .py if it finds it more recent than .pyc right ? Especially when it can't write the .pyc ? | 07:34 |
| mgz | right. | 07:34 |
| mgz | not just more recent, any mtime difference | 07:35 |
| vila | with the one embedded in the .pyc, ok | 07:35 |
| vila | mgz: the setup for slaves os to use testtools and subunit from an automounted read-only fs, I got weird results yesterday after an update, if the results are too weird for you run I may just re-try it before worrying | 07:39 |
| vila | mgz: it seems to be stucked anyway which qualifies as weird :) | 07:39 |
| mgz | yeah, give it another bash. | 07:39 |
| mgz | parthm: looking at this some more, I'm not really sure the bug I just filed is seperable from yours | 07:40 |
| vila | mgz: http://babune.ladeuil.net:24842/job/selftest-maverick/9/ | 07:40 |
| vila | hmm, still leaking | 07:40 |
| mgz | any fix I attempt here is going to be clashing with your follow up, and really the hard decide-y bits need to be done in the design of your error wrapper | 07:41 |
| mgz | vila: might be 2.7 related... there are a bunch of changes in unittest and logging, one of them might have upset something | 07:42 |
| vila | mgz: it seems that skipped tests only have their reason leaking | 07:42 |
| vila | or their log | 07:42 |
| vila | but definitely skipped only so far | 07:42 |
| parthm | mgz: yes. there is a fair amount of overlap. | 07:43 |
| mgz | I'll compare the exception class definitions | 07:43 |
| mgz | parthm: what you need to choose I think, is 1) what to use when you want an eager, user-error rasing re.compile like log needs, and 2) whether Globster should be raising from the constructor or from the method call if given invalid pattersn | 07:44 |
| vila | mgz: reason. log. traceback, the whole shebang, some excerpts here: http://paste.ubuntu.com/466825/ | 07:44 |
| mgz | gah, I can't multitask at all | 07:44 |
| vila | mgz: sorry for the very long lines :-/ | 07:44 |
| vila | mgz: sheesh, have some coffee :) | 07:45 |
| mgz | good advice :) | 07:45 |
| vila | mgz: and now it seems the whole stream is diverted somehow :-/ | 07:47 |
| vila | mgz: starting there: http://paste.ubuntu.com/466826/ | 07:48 |
| mgz | can we get subunit out of the mix for the moment? | 07:48 |
| mgz | doubt anyone has even tried it with 2.7 yet. | 07:48 |
| parthm | mgz: i would say the api user should be able to choose between lazy/eager compile. e.g. compile_p = lazy_regex.compile_lazy() vs compile_p = lazy_regex.compile() | 07:48 |
| parthm | e.g. the is_pattern_valid API introduced in https://code.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 requires eagerness | 07:49 |
| parthm | so it ends up doing p = re.compile() ; p.match( "") | 07:49 |
| parthm | i have seen the same pattern in re_compile_checked. | 07:49 |
| parthm | osutils.re_compiled_checked. | 07:50 |
| parthm | so, as a user one can be sure of lazy vs eager. | 07:50 |
| vila | argh, ff blowing up trying to catch up with the far-too-big stream :-. | 07:50 |
| vila | mgz: and finally the run aborted with: 'ERROR: Failed to archive test reports' which sounds fully related | 07:52 |
| vila | parthm: Are you ok with marking https://code.edge.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 WIP ? | 08:00 |
| parthm | vila: sure. | 08:02 |
| vila | parthm: thanks ! I've also added a comment there | 08:02 |
| parthm | vila: thanks for reviewing this. when you say 'regular keys' do you mean user lower case or something else? | 08:03 |
| vila | I mean strings instead of the indirection via symbols to get ints | 08:03 |
| parthm | vila: ah. ok. sounds like a good idea. i will do that. | 08:04 |
| vila | parthm: but more importantly, grouping the attributes instead of having several arrays/dicts all over the place | 08:04 |
| vila | parthm: some functions may still want to have some local dicts for special purposes though | 08:04 |
| parthm | vila: yes. i will try to clean that up ... maybe a string->tuple dict. | 08:05 |
| vila | or may be the key should become an attribute of an extended regexp object... I haven't dig the code enough to say | 08:05 |
| vila | parthm: yup string->tuple dict may be a good start and present things in a cleaner way | 08:05 |
| vila | and that may be enough, you'll see | 08:06 |
| parthm | vila: i agree with you point about making it easy for plugins to add their own pattern types. once this patch it done it may be possible to provide an api to do that. | 08:07 |
| vila | parthm: excellent, I wanted to do that for a long time but never managed to find the time :-/ | 08:08 |
| mgz | okay, coffee obtained. | 08:09 |
| vila | parthm: bzr-upload is such a plugin, so I'm not talking about an hypothetic (sp?) case here | 08:09 |
| parthm | vila: oh. thanks for letting me know. i wasn't aware that bzr-upload does this. i will look at it and try to understand the requirement better. | 08:10 |
| vila | parthm: the use case for bzr-upload is that we want to exclude some paths to be processed (substitute process by add for bzr, roughly) | 08:11 |
| parthm | vila: ok. | 08:12 |
| mgz | vila: not sure I see that marking the selftest 2.7 branch WIP was needed | 08:15 |
| poolie | hey there vila, mgz | 08:15 |
| vila | hey poolie | 08:15 |
| poolie | barry is talking in prague about 2.7 ! :) | 08:15 |
| poolie | one interesting change, deprecationwarning off by default | 08:15 |
| mgz | there seem to be various other 2.7 issues, but the only change wanted in response to jam's review is making an evil one liner more readable | 08:15 |
| vila | mgz: I explained it in a later comment: this can't be landed as is and requires some dependencies so I'd like that to be sorted out | 08:16 |
| vila | mgz: and switching to WIP makes it more obvious when a branch needs to be re-reviewed | 08:16 |
| mgz | it could be landed... it's just possibly not sufficient | 08:16 |
| vila | mgz: no, the run doesn't even finished cleanly | 08:17 |
| mgz | but... that's subunit! :) | 08:17 |
| vila | mgz: now if you can demonstrate it comes from testtools/subunit, I'd be happy to reconsider | 08:17 |
| vila | hehe, exactly my point ;) | 08:17 |
| vila | mgz: That's why I said: 'this is clearly going in the right direction' :) | 08:17 |
| mgz | poolie: is it the kind of talking that gets recorded anywhere? | 08:18 |
| vila | mgz: OMG no ! You should not even knows about it, we'll need to kill you now ! | 08:19 |
| poolie | hm i don't know | 08:19 |
| vila | joke aside, no, I don't think it's recorded, but it would be nice | 08:19 |
| poolie | it could be | 08:19 |
| poolie | i can ask him to put his slides up at least | 08:19 |
| vila | poolie: that would be awesome | 08:19 |
| mgz | vila: working out what to blame for that babune issue is why I was asking about if you could try a run without subunit | 08:20 |
| mgz | as in, just bzr selftest and pipe to a file or something | 08:20 |
| vila | mgz: marking it WIP doesn't mean I won't run as many times as you asked for | 08:20 |
| vila | mgz: I'm running you fix against testtools on all slaves currently, just to make sure | 08:21 |
| poolie | vila i was thinking perhaps the texinfo docs should say on the title page | 08:21 |
| poolie | "this was converted using a beta rst->texinfo converter, the links are wrong" | 08:21 |
| poolie | or something similar | 08:21 |
| poolie | to avoid roundtrips of people reporting it | 08:22 |
| vila | poolie: excellent | 08:22 |
| mgz | was just trying to understand the reasoning - if the branch was borked on 2.6 I'd not have questioned the flip, just wasn't sure if that was the case | 08:22 |
| poolie | and to put the blame on the convertor not us :) | 08:22 |
| mgz | the testtools change should be fine, but it's not the kind of thing that gets tickled unless there are failures | 08:22 |
| vila | poolie: on the other hand, we don't produce the '.info' files right now, so people can't see them, they have to create them from the '.texinfo' themselves | 08:23 |
| mgz | and the testtools suite *passes* on 2.7, but it does have holes so don't think I want to go as far as vouching for it... | 08:23 |
| vila | mgz: http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/console | 08:23 |
| vila | mgz: it's a bit unclear to decide if it's related | 08:23 |
| vila | but 'Ran 1892 tests in 52.523s' is worrying | 08:24 |
| mgz | urk, yeah, died part way through | 08:24 |
| vila | and the last test before that was.... : ERROR: bzrlib.tests.per_transport.TransportTests.test_put_file_unicode(FtpTransport,UnavailableFTPTestServer) | 08:24 |
| vila | hello unicode... | 08:24 |
| vila | _StringException: lost connection during test 'bzrlib.tests.per_transport.TransportTests.test_put_file_unicode(FtpTransport,UnavailableFTPTestServer)' | 08:24 |
| vila | mgz: the gentoo one succeeded though... | 08:25 |
| mgz | I'm NODEP on (FtpTransport,UnavailableFTPTestServer) locally | 08:26 |
| vila | mgz: and the freebsd one just succeeds too | 08:27 |
| vila | mgz: now that you mention it.... | 08:27 |
| vila | I would have swear hardy was NODEP too on ftp server... | 08:28 |
| vila | mgz: right, hardy is NODEP too | 08:29 |
| vila | mgz: that won't be the first time NODEP and SKIP have a common failure mode | 08:30 |
| mgz | okay, I could understand a problem there for 2.7 but this is back to default python, right? | 08:30 |
| vila | right | 08:30 |
| vila | but with your patch on testtools (may be unrelated but the window is quite narrow: I updated testttols/subunit yesterday so I'm running trunk for both) | 08:31 |
| mgz | grepping the last hardy success log seems to have "... ok" though for that test | 08:32 |
| mgz | shouldn't it print nodep if it's lacking it? | 08:32 |
| vila | mgz: because a fake server is provided to trigger a skip... err, wait | 08:32 |
| vila | hmm, from memory, there is a trick there | 08:33 |
| vila | something like TestSkipped raised during setUp, I'm pretty sure I fixed something in the past but testtools may behave differently | 08:34 |
| mgz | karmic failed the same way. | 08:34 |
| mgz | so, something real is clearly borked. | 08:34 |
| vila | bad bad bad | 08:34 |
| vila | re-trying hardy | 08:35 |
| mgz | poolie: test regression present for you too, which I also need to file a bug for | 08:45 |
| mgz | http://float.endofinternet.org/bzrcst/clasregr/5191 | 08:45 |
| mgz | http://float.endofinternet.org/bzrcst/clasregr/5192 | 08:45 |
| mgz | http://float.endofinternet.org/bzrcst/clasregr/5228 | 08:46 |
| mgz | it's confusing, but related to renaming fancy_rename and directories | 08:46 |
| vila | mgz: what is the problem with http://float.endofinternet.org/bzrcst/clasregr/5191 ? | 08:47 |
| mgz | that's the known-good | 08:47 |
| vila | ha ok :) | 08:47 |
| mgz | flick between that and the one after to see the coloured dots change :) | 08:48 |
| vila | mgz: hardy succeeded on retry... \o/ or >-/ ? | 08:48 |
| mgz | >_< | 08:48 |
| vila | lol | 08:48 |
| poolie | am i being trolled by ben? | 08:49 |
| mgz | on the list? /me reads | 08:50 |
| mgz | ...yes | 08:50 |
| poolie | it annoys me that his proposed patch was deleting whitespace | 08:50 |
| poolie | i realize people need to get a toe in the water but that is the smallest possible toenail sliver | 08:50 |
| poolie | thanks mgz | 08:51 |
| poolie | vila i'll try to let you land the texinfo thing today | 08:53 |
| vila | poolie: ok, I will look at adding a warning about the links in a few minutes (but I'm a bit worried about fallouts for tests) | 08:53 |
| mgz | I take is os.rename(existing_dir_a, existing_dir_b) on nix just fails neatly? | 08:53 |
| poolie | i think it renames it to a/b | 08:54 |
| mgz | because fancy rename really gets its knickers in a twist on this... | 08:54 |
| poolie | vila how about if you put the build product on the web somewhere? | 08:56 |
| poolie | preferably even as .info? | 08:56 |
| poolie | you're worried about test fallout if we land the texinfo change? | 08:56 |
| vila | poolie: no, fallouts if had a generated boilerplate | 08:57 |
| vila | poolie: no, fallouts if I had a generated boilerplate | 08:57 |
| vila | meh | 08:57 |
| poolie | really?ok | 08:57 |
| vila | poolie: no, fallouts if I add a generated boilerplate | 08:57 |
| poolie | it's just an idea | 08:57 |
| vila | hehe, I had already implemented ignoring a boilerplate, so that should be trivial if the generated boilerplate is readable in the end result | 08:59 |
| vila | poolie: done, only one test needed to have the boilerplate duplicated which is perfect since it will fail when we remove it | 09:03 |
| poolie | mgz i'm kinda tired today but i don't understand which rev caused which regression | 09:03 |
| mgz | ah, sorry, I'm still trying to work out the right behaviour with directory renaming to file the bug | 09:04 |
| mgz | <poolie> i think it renames it to a/b <- not even that... seems that a just replaces b *if* b is empty, otherwise fails with errno 39 | 09:04 |
| mgz | r5192 is the regression, but it's not totally obvious what the right fix is from the diff | 09:05 |
| mgz | hence trying to file a bug that makes sense | 09:05 |
| mgz | and I got you to change a lot of 5192 already which complicates things, but I missed these tests till now | 09:06 |
| * mgz not doing job of being annoying well enough | 09:06 | |
| vila | mgz: it's a tough job :) | 09:08 |
| poolie | really babune should be doing it | 09:09 |
| vila | poolie: that's what I said :) | 09:09 |
| poolie | machines can be much more annoying than most humans ever can | 09:09 |
| poolie | underline fail | 09:09 |
| mgz | okay, looking at the *right* diff this time, maybe it is just os.rename->osutils.rename fallout | 09:10 |
| poolie | wow that's a while ago | 09:12 |
| poolie | I was wondering what i changed in rename recently | 09:12 |
| mgz | see, very lax. | 09:12 |
| mgz | at least I got round to looking my test output before the release though :) | 09:13 |
| poolie | ouch | 09:13 |
| poolie | well, thanks | 09:13 |
| poolie | the difference in rename behaviour is annoying | 09:13 |
| poolie | maybe we should explicitly specify what behaviour we want | 09:13 |
| poolie | like rename(target_exists='error') | 09:14 |
| mgz | it's annoying, in this case, os.rename(a, b) could just be os.remove(b); os.rename(a, b) and would do roughly what nix does | 09:16 |
| mgz | but trying the renaming dance means it breaks down horribly | 09:16 |
| poolie | oh, especially for case changes | 09:16 |
| poolie | i suggest the kwarg because having it vary depending on whether you call transport.rename, os.rename, osutils.rename would be insane | 09:17 |
| poolie | vila istm this sphinx code does not really belong in bzrlib | 09:17 |
| vila | poolie: the main problem is that I'm not confident enough (yet) that we won't need special cases, so I'd like to have a fully working solution before proposing the texinfo builder/writer upstream | 09:19 |
| vila | poolie: and then there is the problem of having the right sphinx deployed | 09:19 |
| poolie | mm it may be the most pragmatic thing | 09:19 |
| vila | poolie: one worthy goal might be to separate the docs from the core so we better control how to produce them (possibly on babune) for every platform/distro | 09:20 |
| vila | poolie: but we are not there yet, one important pre-requisite step being to switch to sphinx officially (and really :) | 09:20 |
| vila | poolie: 'most pragmatic' being starting in bzr-core or submitting upstream ? | 09:21 |
| vila | poolie: also, I'd like to add more sphinx related tests so knowing how to write builder/writer is a good path towards this goal | 09:22 |
| vila | poolie: tests like: did we get all our references right ? (identifying internal and external references for example) | 09:23 |
| vila | poolie: we currently don't use the right kind of references for that and we already have wrong references | 09:23 |
| vila | poolie: it's very easy to mistype a reference... | 09:24 |
| * vila is a typo expert | 09:25 | |
| poolie | in the bzr tree seems pragmatic | 09:26 |
| poolie | checking internal links would be cool | 09:26 |
| poolie | so, do it! | 09:26 |
| poolie | can you do two followons for me? | 09:26 |
| poolie | put the rendered .info file on the lp download site | 09:26 |
| poolie | and blog about it, with a link | 09:27 |
| poolie | done | 09:27 |
| vila | I was about to write an email with the script I use to produce the info fileSSSS | 09:27 |
| vila | poolie: 223 files are produced today | 09:28 |
| vila | poolie: and that's only for the english version | 09:28 |
| poolie | sheesh, 223 info files? | 09:29 |
| poolie | i don't remember them normally being that many | 09:29 |
| vila | poolie: I want to group them into bigger info files but this is blocked by 1) a full switch to sphinx 2) being able to translate the refernces correctly since this require defining a layout | 09:29 |
| vila | poolie: so a reference to a source document can be translated into a reference to the target document which has a different path that the source should not be aware of | 09:30 |
| vila | poolie: we currently use references to the produced .html files (and there should be ~223 of them) | 09:31 |
| vila | poolie: that's why I want to land this branch first or the submission will become un-readable with all these reference fixes | 09:31 |
| mgz | okay, filed bug 608096 | 09:35 |
| ubot5 | Launchpad bug 608096 in Bazaar "Windows transform regression with directory renaming (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/608096 | 09:35 |
| mgz | should probably be targetted at 2.2 but I'll leave that for now, as it looks like a pain to fix in the Right Way | 09:36 |
| mgz | anyone seen this for 2.2 trunk? | 10:28 |
| mgz | TypeError: create_workingtree() got an unexpected keyword argument 'accelerator_tree' | 10:28 |
| mgz | wait, no, that's my old bzr, probably a long-fixed bug | 10:29 |
| poolie | i think so | 10:32 |
| poolie | igc says hi to everyone | 10:55 |
| mgz | hey igc. | 11:00 |
| mgz | ...trying to update my bzr.dev branch on my old nix box to test this change has set loose the OOM reaper... | 11:00 |
| mgz | will it work out bzr it to blame, or will it just keep killing apache repeatedly... | 11:01 |
| poolie | mgz i wouldn't count on it, it's not all that smart IME | 11:04 |
| poolie | vila, so shall i submit that? | 11:04 |
| vila | poolie: what ? | 11:05 |
| poolie | the texinfo branch | 11:06 |
| vila | I submitted it after your approval, I'm finishing an email explaining how to generate the info files | 11:08 |
| vila | AAAAARGH | 11:09 |
| vila | pqm doesn't support looms :-( | 11:09 |
| mgz | okay, this is like, my fourth attempt to use bzr to get this code on my nix box. one restart later, now using http transport and avoiding smartness like the plague | 11:11 |
| mgz | if this one dies, I'm using frekin' rsync | 11:11 |
| vila | mgz: you're not trying to update bzr using itself right ? | 11:12 |
| mgz | nope, it's just an old box. | 11:12 |
| mgz | %CPU %MEM TIME+ COMMAND | 11:14 |
| mgz | 99.3 62.3 4:09.16 bzr | 11:14 |
| mgz | made it! | 11:15 |
| lifeless | vila: it just needs a newer package | 11:17 |
| === FryGuy_ is now known as FryGuy- | ||
| lifeless | vila: release looms! get jelmer to do a package update and file an RT. (these are not serialised) | 11:18 |
| jelmer | lifeless, EAMBIGUOUS: "release looms" | 11:20 |
| mgz | just spent something ridiculous like two hours confirming that a change I was pretty sure was safe on nix actually is | 11:23 |
| mgz | next time I need to remember to not use smart protocols, or pick a faster box | 11:24 |
| vila | mgz: where is the smart server ? | 11:27 |
| mgz | I tried it both ways. | 11:27 |
| vila | mgz: :-/ | 11:28 |
| parthm | vila: anytime you have a spare moment https://code.launchpad.net/~parthm/bzr/300062-2.2-bad-pattern-error-part-2/+merge/29949 no hurry. | 11:28 |
| mgz | hm, was exagerating, only one hour | 11:31 |
| mgz | anyway, merge proposal up now, so can leave in peace. | 11:31 |
| lifeless | jelmer: 'do a release of loom trunk' | 11:32 |
| jelmer | lifeless: ah, ok :-) I thought "release looms" sounded a bit dark... | 11:34 |
| maxb | Hrm. bzr-builder's source tree contains a plugins directory containing a builder symlink to .. | 11:45 |
| maxb | This makes it impossible to use bzr multi-pull :-( | 11:45 |
| jelmer | maxb, several plugins do, bzr-svn and bzr-git create such a directory as well | 11:46 |
| maxb | builder's is actually checked into bzr | 11:46 |
| maxb | Maybe I should teach multi-pull to avoid infinite recursion | 11:47 |
| jelmer | that'd be awesome, it's the only reason I don't use it at the moment | 11:47 |
| maxb | jelmer: btw, is https://code.edge.launchpad.net/~maxb/bzr-svn/fetch-svn-rev-info-progress-bar on your list for when you get time to review? | 11:48 |
| jelmer | maxb: Somewhat. I'm a bit hesitant to change that code without tests, as we've gotten it wrong a couple of times in the past. | 11:50 |
| maxb | On the plus side, it's only a progress bar :-) | 11:50 |
| spiv | jml: btw, please talk to poolie if you have any opinions on goodness/badness of maintaining NEWS as file fragments | 11:57 |
| parthm | mgz: ping | 12:18 |
| jam | hi vila, just figured I'd say hello while we're still in the same TZ before you leave | 13:35 |
| vila | jam: hi :-D | 13:37 |
| === Ursinha-afk is now known as Ursinha | ||
| mgz | parthm: pong, though I've lunch coming up in a bit | 13:57 |
| === Ursinha is now known as Ursinha-brb | ||
| mgz | parthm: one thing we've not explictly stated on the re.compile front so far - what we're worrying about only really matters for patterns supplied by the user | 13:59 |
| mgz | so, though there are a lot of instances of re.compile most of those have constant str patterns that are known valid, so either lazy or eager works fine | 14:00 |
| === Daviey_ is now known as Daviey | ||
| LaserJock | is it possible to downgrade the format of a shared repo? | 15:56 |
| jelmer | LaserJock: Yes, provided the target format has all the features required to hold the repository's data | 15:57 |
| LaserJock | jelmer: k, do you know what this format is: "repository: Packs containing knits without subtree support" | 15:59 |
| LaserJock | I'm trying to get rid of these annoying upgrade notices when I pull from LP | 15:59 |
| LaserJock | it looks like it doesn't like me using 2a for the repo format | 16:00 |
| jelmer | LaserJock: it's not possible to just upgrade the remote repository to 2a as well? | 16:00 |
| jelmer | I would recommend that as 2a is significantly faster and smaller than older formats. | 16:01 |
| LaserJock | jelmer: sure, but I don't own any of these | 16:01 |
| LaserJock | I'd rather not go hunting down random people asking for them to upgrade their repos | 16:01 |
| LaserJock | is there any command that would set up the repo+branch just as it is on LP? | 16:02 |
| jelmer | LaserJock: no, we don't have anything like that. | 16:02 |
| LaserJock | k | 16:03 |
| maxb | jelmer: btw, the current lp:bzr-svn does not work - the name atomicfile is referenced but not imported. | 16:03 |
| jelmer | LaserJock: I think "Packs containing knits without subtree support" means pack-0.92 though | 16:03 |
| LaserJock | ah, OK | 16:04 |
| jelmer | maxb: Fixed! | 16:04 |
| jelmer | maxb: (I already had a fix for that locally) | 16:04 |
| maxb | I like this response time :-) | 16:04 |
| LaserJock | darn, it won't let me go from 2a to pack-0.92, oh well, I'll just rebranch | 16:05 |
| jelmer | LaserJock: Yeah, 2a has rich roots which are not supported by pack-0.92 | 16:06 |
| jelmer | LaserJock: There is an option somewhere to make the warning go away | 16:07 |
| LaserJock | jelmer: oh yeah? that'd be useful too :-) | 16:07 |
| === Ursinha-brb is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| m4n1sh | can anyone tell me what all options bzr serve --protocol=ARG takes | 19:14 |
| maxb | Is anyone else noticing that progress bars are not cleanly being cleared from the terminal in 2.2beta? | 20:10 |
| === davidstrauss_ is now known as davidstrauss | ||
| rellis | Hi everyone. I'm seeing this email from the bzr-email-notifier. Anyone know how to fix? NameMapper.NotFound: cannot find 'branch_name' | 20:59 |
| rellis | seeing this message* | 21:00 |
| maxb | Is there any incantation for "copy one file from another branch, including file-id" ? | 21:31 |
| jelmer | maxb, there is "bzr add --file-ids-from" | 21:40 |
| fullermd | You can [ab]use merge. | 21:43 |
| === BasicPRO is now known as BasicOSX | ||
| idnar | hmm, I should make an alias for "bzr merge -r before:ancestor:trunk.. branch" | 22:45 |
| === Meths_ is now known as Meths | ||
| === Ursinha is now known as Ursinha-dinner | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!