| === medberry is now known as med_out | ||
| === AuroraBorealis is now known as aurora\sc | ||
| === aurora\sc is now known as AuroraBorealis | ||
| === poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | ||
| poolie | hi vila? | 06:33 |
|---|---|---|
| jam | morning all | 06:50 |
| poolie | hi jam | 06:56 |
| mgz | morning! | 07:00 |
| poolie | hi gz | 07:02 |
| AuroraBorealis | hiya | 07:05 |
| poolie | hi AuroraBorealis | 07:06 |
| mgz | AuroraBorealis: did you see the various bugs I filed on Sunday for the meliae issues you had? | 07:06 |
| AuroraBorealis | i saw the email, were the links in that? | 07:07 |
| mgz | I think I mentioned the bug numbers, was going to subscribe you to all of them but wasn't sure you'd want the bugspam | 07:09 |
| AuroraBorealis | nah its fine | 07:09 |
| AuroraBorealis | subscribe away~ | 07:09 |
| mgz | I will do so :) | 07:10 |
| AuroraBorealis | and looking at that link you sent me for the win7 sdk | 07:11 |
| AuroraBorealis | it seems to be for net framework 3.5 instead of 4 | 07:11 |
| AuroraBorealis | cause i reinstalled the other one i used and it did not give me the 64 bit libs | 07:11 |
| mgz | hm, maybe it has to be the 3.5 one? | 07:14 |
| mgz | you can probably just install that as well. | 07:14 |
| mgz | I unticked the samples and doc options and it was only 400MB or so | 07:14 |
| AuroraBorealis | yeah | 07:14 |
| AuroraBorealis | i'm installing it | 07:14 |
| AuroraBorealis | if this works, then chalk up another for "why i hate developing anything in windows" | 07:14 |
| mgz | yeah, that was a very annoying diversion | 07:15 |
| mgz | when you get that working, try `import random; from meliae.scanner import dump_all_referenced; with file("_random_module.json", "w") as f: dump_all_referenced(f, random._random)` | 07:23 |
| mgz | as that was one of the objects that was a dead end in the dump you sent me and prevented it being loaded | 07:24 |
| AuroraBorealis | ok | 07:24 |
| AuroraBorealis | will work on it | 07:24 |
| AuroraBorealis | fffuuuasdfjklasdfjklasdfjklsdfjklsdfjkl;sdfajk | 07:44 |
| AuroraBorealis | Installation of the "Application Verifier" product has reported the following error: Fatal error during installation. | 07:44 |
| mgz | heh. is that an optional component you can just not install? | 07:45 |
| AuroraBorealis | lets see if it is | 07:46 |
| jelmer | mgz: we'll need to tweak your fix for unicode changelogs in bzr-builddeb | 08:17 |
| jelmer | mgz: python-debian's changelog is unicode in newer versions but bytestrings in older versions, it seems | 08:18 |
| poolie | hi jelmer | 08:21 |
| jelmer | hi poolie | 08:21 |
| mgz | jelmer: ha. so, we do need ugly fallback code after all. | 08:45 |
| mgz | I take it previously no encoding was specified in the rules at all, so there's no actual way of decoding them? | 08:46 |
| jelmer | mgz: yep | 08:48 |
| jelmer | mgz: though the convention is to have them in utf8 | 08:48 |
| mgz | okay, so potentially we can just do .decode('utf-8', 'replace') so we don't error out. | 08:49 |
| mgz | or decode, catch the error, give a warning, and decode ascii-replace | 08:50 |
| jelmer | mgz: I don't think we should do any replacement, we should just keep the existing text as is | 08:51 |
| jelmer | mgz: and encode the commit message before appending it instead | 08:51 |
| mgz | well, replace is an encoding. given random bytes, we need to do some kind of munging to get them in a bzr commit message. | 08:52 |
| mgz | without a specified encoding it's a choice between: asking the user, guessing, or munging | 08:53 |
| mgz | and as the rules now state that the file must be utf-8, getting people to fix their changelogs seems reasonable | 08:55 |
| mgz | jelmer: is there a bug report, or have you just run across a changelog file that failed? | 09:00 |
| jelmer | mgz: http://people.canonical.com/~jelmer/recipe-status/bzr.html | 09:00 |
| mgz | thanks! | 09:01 |
| mgz | hm, that ftb looks like a C locale thing, the test needs a requires UnicodeFilenameFeature | 09:02 |
| mgz | ...though there are a bunch of other issues as well on lucid | 09:04 |
| jelmer | mgz: succeeds on oneiric though | 09:12 |
| jelmer | mgz: (otp with poolie) | 09:13 |
| mgz | yup, I'll bug you after the call | 09:18 |
| mgz | (I get a different error with LANG=C so I'm guessing the difference is the debian changelog package version, the older one is borked) | 09:20 |
| === beuno is now known as beuno-lunch | ||
| quicksilver | On the rare occasions I have to rollback a merge, I find myself rewriting history because otherwise I won't be able to merge it again later when it's fixed | 13:42 |
| quicksilver | is that right? | 13:42 |
| jam | lifeless: are you around? I'm trying to use testscenarios with nosetests, and I'm getting a weird assertion error from nose | 13:45 |
| jam | mgz: ^^ maybe you've played with testscenarios while you're playing with the other stuff? | 13:45 |
| mgz | I have... but not nose. | 13:47 |
| mgz | what's the traceback? | 13:47 |
| jam | mgz: http://paste.ubuntu.com/706709/ | 13:47 |
| jam | well, full traceback, just a sec | 13:47 |
| jam | http://paste.ubuntu.com/706711/ | 13:48 |
| jam | It looks like testscenarios is creating a new instance, and nose's ResultProxy is asserting that it has the same instance | 13:48 |
| mgz | yes. | 13:48 |
| mgz | that's exactly what it looks like. | 13:48 |
| mgz | I don't see an easy way around that, you have to duplicate tests for scenarios | 13:50 |
| jam | mgz: ResultProxy.assertMyTest has "The test I was called with must be my .test or my .tests's .test, or my .test.test's .case" | 13:50 |
| mgz | if you can arrange for the multiplication to happen before nose gets a sniff of the tests, that might work | 13:50 |
| jam | Sounds like you can add the '.test' attribute | 13:50 |
| mgz | that may be okay as a hack-around, if none of your tests already have a 'test' attribute | 13:51 |
| jam | nope | 13:52 |
| jam | at least my initial poke at it didn't work | 13:52 |
| mgz | you'll need to write a test loader then I guess, so nose only sees the suite after the scenarios have been handled | 13:52 |
| jam | yeah, looks like | 13:53 |
| jam | mgz: do you know if nosetests supports the 'load_tests' api? | 13:54 |
| jam | (not bzr's, but python's ) | 13:54 |
| jam | and does that work on py2.6... guess I'll have to keep trying | 13:54 |
| === beuno-lunch is now known as beuno | ||
| mgz | it should, but that's a 2.7 change iirc | 13:55 |
| jam | http://docs.python.org/library/unittest.html#load-tests-protocol | 13:57 |
| jam | mgz: It looks like it calls 'load_tests' but it is assuming it is a test suite | 13:57 |
| jam | and doesn't pass it any parameters | 13:57 |
| jam | it just treats it as yet-another-test | 13:57 |
| mgz | yeah, that's the 2.7 api change I think | 13:57 |
| mgz | unittest implemented something slightly different from all the existing load_test type things that were floating around already | 13:59 |
| jam | mgz: ugh, the whole reason to use nosetests was so i didn't have to write my own test loader... | 14:05 |
| jam | well, test runner + loader + everything else | 14:05 |
| jam | mgz: it looks like "python -m testtools.run discover" will work as long as you have py 2.7 or the 'discover' package available. | 14:15 |
| mgz | yup, that sounds like a better bet | 14:25 |
| mgz | testtools can also work without discover with minimal boilerplate | 14:28 |
| mgz | basically import your modules in a test_suite function in __init__.py and use an existing TestLoader | 14:29 |
| jam | mgz: of course, now I have to figure out how I went from 119 tests to 144 tests... | 14:39 |
| mgz | more tests, that's a good thing! :) | 14:39 |
| mgz | (because scenarios are working?) | 14:39 |
| jam | mgz: I was using mixins before, and had 119 tests | 14:40 |
| jam | I'm switching to scenarios for the same number of permutations | 14:40 |
| jam | and "-v" for verbose doesn't actually do anything... | 14:40 |
| jam | It might be scenarios doing it differently, because in the pre-scenario code 'py -m testtools.run discover' also gives 119 | 14:41 |
| jam | but without -v, I don't know *what* extra tests are running | 14:41 |
| jam | :( | 14:41 |
| jam | jml: poke about "testtools.run" | 14:42 |
| jam | Is '-v' supposed to list the tests like unittest does? | 14:42 |
| jml | jam: don't know, sorry. | 14:42 |
| jam | because: py -m testtools.run discover -v | 14:42 |
| jam | looks identical to without -v | 14:42 |
| mgz | pretty sure testtools' TestResult doesn't have a verbosity concept | 14:44 |
| mgz | would be nice if it did the same thing as bzrlib | 14:44 |
| jam | mgz: the TestResult doesn't, the TestRunner does. | 14:45 |
| jam | I've found the issue: | 14:45 |
| jam | TestToolsTestRunner is a stand-in for unittest.runner.TextTestRunner | 14:45 |
| jam | and TestToolsTestRunner doesn't support verbosity | 14:45 |
| jam | of course, testtools code is actually broken because it accesses a "runner.TextTestRunner" variable, but never imports 'runner'... | 14:46 |
| mgz | the runner only passes the verbosity param on to the result I believe | 14:49 |
| mgz | but did you try --list instead? | 14:49 |
| mgz | would tell you what tests you gained. | 14:49 |
| jam | mgz: to make matters worse, it is also trying to pass other flags like 'buffer' and failfast | 14:52 |
| jam | which aren't supported by py2.6's unittest.TextTestRunner | 14:52 |
| jam | so this is the hackaround that works: $ py -c "import sys; from testtools import run; import unittest; prog = run.TestProgram(testRunner=unittest.TextTestRun | 14:52 |
| jam | ner(verbosity=2), stdout=sys.stdout)" discover | 14:52 |
| jam | mgz: '--list' takes an argument... ? | 14:53 |
| jam | which is extra weird | 14:54 |
| jam | as I don't see code actually requesting a value | 14:54 |
| jam | and I can pass anything for the value | 14:54 |
| mgz | jam: the discover version shouldn't.. | 14:54 |
| mgz | the non-discover version needs a suite name | 14:55 |
| jam | mgz: http://paste.ubuntu.com/706758/ | 14:55 |
| jam | you tell that to my testtools | 14:55 |
| mgz | it sounds like you have the potential of many bugs to file | 14:55 |
| jam | or even: http://paste.ubuntu.com/706760/ | 14:55 |
| mgz | ...yup, I get the same with 2.7 | 14:56 |
| jam | mgz: yeah, the issue is they have OptParse | 14:57 |
| jam | which defaults to taking an argument | 14:58 |
| jam | unless you set "action=store_true" sort of thing | 14:58 |
| jam | uhg | 14:58 |
| jam | ugh | 14:58 |
| jam | --list doesn't do scenario multiplication | 14:58 |
| jam | because that is done in 'run()' | 14:58 |
| mgz | >_< | 14:59 |
| mgz | it works in bzr selftest... | 15:00 |
| jam | I think that's 4 or 5 bugs | 15:02 |
| jam | mgz: we don't use TestWithScenarios | 15:02 |
| jam | we implemented it ourself. | 15:02 |
| mgz | clearly bzr did it better. | 15:03 |
| === zyga is now known as zyga-afk | ||
| hrw | hi | 15:20 |
| hrw | can someone help with 'bzr dailydeb'? | 15:21 |
| === med_out is now known as medberry | ||
| jelmer | hrw, hi | 15:22 |
| jelmer | hrw, sure, what about it? | 15:22 |
| hrw | jelmer: is there a way to tell bzr to not try to update with lp? lp:gcc-linaro is huge repo so each attempt of 'bzr dailydeb recipe .' (where . == bzr copy of lp:gcc-linaro) takes ~1h of bzr work and then fail due to some bugs | 15:23 |
| jelmer | hrw: if you run it inside of a shared repository it shouldn't have to fetch from Launchpad again each time | 15:25 |
| jelmer | hrw, alternatively, you can specify /path/to/gcc-linaro rather than lp:gcc-linaro | 15:25 |
| hrw | jelmer: local repo was fetched wth 'bzr pull lp:gcc-linaro' and thats all | 15:26 |
| hrw | I am not a fan of bzr so my knowledge of when repo is 'shared repo' and when not == null | 15:26 |
| jelmer | hrw: try "touch .bzr/repository/shared-storage" | 15:28 |
| hrw | the 'Finding revisions' part of bzr is fun - takes several minutes on 1 commit branch | 15:28 |
| mgz | jelmer: I've just proposed a bzr-builddeb change that should greenify my problem test from earlier | 15:29 |
| jelmer | mgz, thanks, I'll have a look | 15:30 |
| === gcerquant_ is now known as gcerquant | ||
| mgz | also, is touching a magic file really the best way? o_O | 15:32 |
| mgz | I guess maybe using bzr reconfigure would be two commands | 15:32 |
| mgz | okay, I'm about to push the testcase cleanup branch. watch out for falling chickens. | 15:35 |
| hrw | Merging '/home/hrw/devel/canonical/2011-oneiric/ci/code-bzr/gcc-linaro/' in to './gcc-linaro-native-{{debupstream-base}}-{revno}-{revno:packaging}'. 212kB 1kB/s \ Finding revisions | 15:35 |
| hrw | where it is trying to find revisions? in 'ci/code-bzr/gcc-linaro' bzr branch? | 15:36 |
| hrw | or in a branch to which it merges? | 15:36 |
| === deryck is now known as deryck[lunch] | ||
| jelmer_ | mgz: still there | 15:59 |
| jelmer_ | mgz: ? | 15:59 |
| jelmer_ | mgz: With your patch, that test fails for me on oneiric | 15:59 |
| jelmer_ | mgz: I wonder if we should just open('debian/changelog', 'w').write("""...""") to make things simpler | 16:00 |
| kirkland | does this error message look familiar? | 16:00 |
| kirkland | bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) | 16:00 |
| kirkland | for full python traceback, see https://launchpadlibrarian.net/82565565/cloud-init-output.log | 16:01 |
| jelmer_ | kirkland: you're interrupting a discussion about that very issue | 16:01 |
| jelmer_ | :) | 16:01 |
| kirkland | jelmer_: :-) is this affecting bzr in 11.10 in general? | 16:01 |
| kirkland | jelmer_: if so, is there a bug i can link to? | 16:01 |
| jelmer_ | kirkland: it's an issue with bzr-builddeb automatically determining a commit message from a debian changelog message which contains non-ascii characters | 16:01 |
| kirkland | Daviey: ^ | 16:02 |
| kirkland | jelmer_: is there a bug #? | 16:02 |
| jelmer_ | kirkland: lp:bzr-builddeb should have a fix, but that fix regressed on pre-oneiric | 16:02 |
| jelmer_ | kirkland: bug 853664 | 16:02 |
| ubot5 | Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664 | 16:02 |
| kirkland | jelmer_: okay, so i think this is manifesting itself in a strange way for us... | 16:03 |
| kirkland | jelmer_: are you familiar with etckeeper? | 16:03 |
| kirkland | jelmer_: we're trying to install/use etckeeper on Ubuntu Orchestra installed servers, to maintain /etc in bzr automatically | 16:03 |
| kirkland | jelmer: subsequent package installation is failing, as etckeeper is failing to commit some changes | 16:04 |
| kirkland | jelmer_: digging through it, it looks to me like it's this bug | 16:04 |
| jelmer_ | oh, that'd be odd | 16:04 |
| kirkland | jelmer_: can you have a look at that log and confirm? | 16:04 |
| kirkland | jelmer_: see https://launchpadlibrarian.net/82565565/cloud-init-output.log | 16:04 |
| jelmer_ | kirkland: ok, that's definitely a different issue | 16:05 |
| mgz | kirkland: sec, I'll link you to the right bug for that one | 16:05 |
| jelmer_ | kirkland: It seems like the file system encoding is not set to UTF-8, is that right? | 16:05 |
| mgz | jelmer_: how annoying, there's some incomptabile change in debian.changelog then... but my version works with *both* | 16:06 |
| jelmer_ | mgz: there indeed is an incompatible change in debian.changelog.. | 16:06 |
| mgz | jelmer_: what's the traceback on oneiric? | 16:06 |
| kirkland | jelmer_: I'm not sure -- how would i tell that? | 16:06 |
| jelmer_ | mgz: I've pasted it to the MP | 16:07 |
| jelmer_ | kirkland: is it supposed to be a standard Ubuntu system? If so, then the fsenc should be UTF8 (from the logs, it looks like it's not) | 16:07 |
| jelmer_ | kirkland: we use Python's sys.getfilesystemencoding() to determine the encoding, let me have a look at what Python uses | 16:08 |
| mgz | kirkland: you want bug 715547 | 16:08 |
| ubot5 | Launchpad bug 715547 in Bazaar ""bzr add" crashed: UnicodeDecodeError in smart_add with ascii codec" [Medium,Confirmed] https://launchpad.net/bugs/715547 | 16:08 |
| kirkland | mgz: ah, thanks. that bug is a bit older | 16:08 |
| mgz | particularly comment 7 there | 16:08 |
| jelmer_ | mgz: in this specific case the file system encoding isn't UTF8 | 16:09 |
| mgz | your problem is you're running without a locale that has a particular encoding set, but have filenames that aren't just ascii | 16:09 |
| mgz | there's an etckeeper specific bug along the same lines. | 16:11 |
| kirkland | mgz: how do i check my fsenc? | 16:16 |
| jam | mgz: I think stuff like testtools and testscenarios was inspired by "look at all this neat stuff we have in 'bzr selftest', lets try to make it generic so other people can use it". | 16:19 |
| jam | but since it isn't one unified code base, and it is trying to interoperate with unittest/nosetests/py.test, etc | 16:20 |
| jam | and then there are the licensing issues | 16:20 |
| jam | like bzrlib is gpl, but these should be BSD-ish | 16:20 |
| jam | etc. | 16:20 |
| jam | I know I tried to pull some of the progress bar stuff into (I think subunit), but robert was worried about the licensing clashes. | 16:20 |
| mgz | jam: that's a good point. | 16:20 |
| mgz | kirkland: what is calling the bzr commands that gave the output you pasted? | 16:21 |
| mgz | kirkland: basically that needs to run in a defined locale, so with LANG/LC_ALL set to something appropriate | 16:22 |
| jelmer_ | mgz: 'python -c 'import sys; sys.getfilesystemencoding()' | 16:29 |
| kirkland | mgz: do you think it would be sufficient in etckeeper itself to [ -n "$LANG" ] || LANG=en_US.UTF-8 | 16:30 |
| mgz | well, that'd work | 16:31 |
| jelmer_ | kirkland: aren't ubuntu systems supposed to be UTF8 by default? | 16:33 |
| jelmer_ | kirkland: as a workaround, setting LANG=en_US.UTF-8 should work but I think the core issue is elsewhere | 16:34 |
| kirkland | jelmer: interactive shells -- yes | 16:37 |
| kirkland | jelmer_: I suspect the problem is that these are non-interactive shells | 16:38 |
| kirkland | jelmer_: one bug report is about cron, which runs with a *very* minimal env | 16:38 |
| kirkland | jelmer_: the other one is juju, same thing | 16:38 |
| mgz | I don't really see why there shouldn't be an encoding set even in those sorts of situations | 16:39 |
| jelmer_ | kirkland: even if it's non-interactive, Python should not return anything but UTF8 for the filesystem encoding | 16:39 |
| mgz | LANG and LC_MESSAGES and such like I guess I can see if we pretend unix is still a multi-user system with accounts using different languages | 16:39 |
| jelmer_ | I can understand if it's something non-UTF8 for the terminal encoding | 16:39 |
| mgz | jelmer_: it goes off the unix locale, which is all it has to work with | 16:41 |
| jelmer_ | mgz: but if the filesystem is always utf8 on Ubuntu, it should use that fact and always return utf-8 | 16:46 |
| mgz | posix doesn't give python a way of knowing that's what python wants. | 16:47 |
| mgz | *ubuntu | 16:48 |
| mgz | right, I need to go, I think I should be third time lucky on the builddeb mp | 16:48 |
| jelmer_ | mgz: why not? the choice has been made for Ubuntu that the fs is UTF8 AFAIK | 16:49 |
| mgz | sure, but what should python do to tell that? I guess you could argue for a build-time patch. | 16:50 |
| jelmer_ | mgz: that's what I had in mind | 16:50 |
| jelmer_ | Python already hardcodes the fs encoding to mbcs for windows and utf8 for apple | 16:51 |
| mgz | right, really is cake time now | 16:53 |
| === zyga-afk is now known as zyga | ||
| === deryck[lunch] is now known as deryck | ||
| === medberry is now known as med_out | ||
| lifeless | jam: nosetests is pretty evil | 18:51 |
| === zyga is now known as zyga-brb | ||
| === med_out is now known as medberry | ||
| === yofel_ is now known as yofel | ||
| hrw | hi | 21:19 |
| hrw | stupid(?) question: why it is taking so long when bzr is branching from local dir to other local dir? "cp -a" is faster then bzr | 21:20 |
| james_w | bzr is also doing integrity checks | 21:21 |
| hrw | james_w: ~400MB copy takes 5 minutes ;( | 21:23 |
| hrw | but it is much faster then doing it with sources at launchpad - then it is 1h | 21:23 |
| hrw | anyway - 13 minutes for 'bzr dailydeb' to generate source pacakge I consider fine enough. will do local tests and once it will work I will give it for launchpad to try | 21:26 |
| hrw | have anice rest of day | 21:26 |
| poolie | hi all | 22:15 |
| james_w | hi poolie | 22:17 |
| poolie | hrw: maybe you should do 'bzr init-repo DIR' which will avoid copying when you branch inside that directory | 22:21 |
| poolie | jelmer_, wgz, jam, emacs are seeing a connection drop exactly 1h after it started | 23:16 |
| poolie | is there any way this could be connected to a timeout in bzr? | 23:16 |
| === medberry is now known as med_out | ||
| mwhudson | there's an hour timeout in lp for idle connections | 23:17 |
| poolie | done in twisted ssh? | 23:18 |
| poolie | this is on savannah | 23:18 |
| mwhudson | yeah | 23:19 |
| mwhudson | ah ok | 23:19 |
| poolie | in this case it's not idle - of course it might be getting detected as idle | 23:19 |
| jelmer_ | g'morning poolie, mwhudson | 23:29 |
| jelmer_ | poolie: has this always happened or after the deployment of a newer bzr on the server/client side? | 23:29 |
| spiv | poolie: AFAIK there's no timeout like that in bzr | 23:33 |
| poolie | hi jelmer, spiv | 23:33 |
| poolie | they've only mentioned it recently | 23:33 |
| poolie | "what changed" is always a good question | 23:33 |
| mwhudson | maybe they're running the site being somelike like my old netgear router :-) | 23:40 |
| mwhudson | *behind | 23:40 |
| mwhudson | (long lived tcp connection? what would you want one of *those* for?) | 23:40 |
| poolie | with openfirmware, of course :) | 23:40 |
| mwhudson | ah ture | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!