| lifeless | I'd like a python2to2and3 | 00:00 |
|---|---|---|
| lifeless | jam: ^ | 00:00 |
| lifeless | mgz: ok, I'm looking at trunk failures now | 00:00 |
| lifeless | mgz: while you're fixing shiftjis | 00:01 |
| lifeless | mgz: care to being in that __init__ guard I sketched, too ? | 00:01 |
| mgz | yup, will do. want the straight up must-be-unicode version? | 00:02 |
| lifeless | yeah | 00:02 |
| jam | lifeless: /me is long overdue for leaving | 00:02 |
| jam | Maybe i'll chat later | 00:02 |
| lifeless | I think that that is what my analysis said would wokr | 00:02 |
| lifeless | jam: ok, catch you around | 00:02 |
| lifeless | oh, and don't get me started on what PQM is going to need to test 2.4 *and* 3 | 00:03 |
| lifeless | shudder | 00:04 |
| lifeless | babune ftw | 00:04 |
| lifeless | ok, the detailsProvided stuff is james_w's patch | 00:04 |
| james_w | not py3k compatible? | 00:05 |
| lifeless | james_w: nope, and I didn't even think to try, it looked like such a no-brainer | 00:05 |
| lifeless | james_w: have a look at the pastebin, ignore the two shiftjis failures | 00:05 |
| james_w | lifeless: did you see my testr MP? (I'm not sure whether MPs actually reach the people I want them to) | 00:07 |
| lifeless | james_w: yes; uhm | 00:07 |
| lifeless | I was tired | 00:07 |
| lifeless | so, I don't want to block you; but there is a bug open about that command already | 00:07 |
| james_w | np, just wanted to know it was in a queue somewhere | 00:07 |
| lifeless | I'd like to fix both | 00:07 |
| james_w | the bug opened by me? | 00:07 |
| lifeless | the bug thats open is that default_test_id_list is handled oddl | 00:07 |
| lifeless | by me | 00:07 |
| lifeless | I want to be able to say, in .testr.conf for loom | 00:08 |
| lifeless | I want to be able to describe the default tests to run | 00:08 |
| lifeless | and IDOPTION to expand default_test_id_list via the normal IDOPTION expansion | 00:08 |
| lifeless | or somethin | 00:09 |
| lifeless | anyhow, that use case and yours are very tightly coupled | 00:09 |
| james_w | ok | 00:09 |
| lifeless | and I think your simply-bail approach conflicts with what I want which is kindof to filter more tightly | 00:09 |
| lifeless | but still keep the original filter | 00:10 |
| lifeless | actually, thats it - in english | 00:10 |
| james_w | bug 531666 ? | 00:11 |
| ubot5 | Launchpad bug 531666 in Testrepository "IDOPTION needs exploring (affected: 1, heat: 2)" [Medium,Triaged] https://launchpad.net/bugs/531666 | 00:11 |
| lifeless | I want to be able to say, for a bzr plugin 'this is how you trigger the default set of tests for the plugin', 'this is how you run a human reduced set for the plugin', 'this is how you run a precise list' and (probably) 'this is how you turn off testr managing the list of tests' | 00:11 |
| james_w | makes sense | 00:12 |
| lifeless | -- foo bar baz | 00:13 |
| lifeless | is already supported I think | 00:13 |
| lifeless | which isn't enough to turn off supplied by default parameters. | 00:14 |
| lifeless | anyhow - thats where I'm at, if you wanted to bring all that together that would be awesome | 00:14 |
| lifeless | if not | 00:14 |
| lifeless | I'll happily take something that fits clearly into that space, which I don't think your current patch does | 00:14 |
| lifeless | james_w: ah iteritems | 00:15 |
| mgz | lifeless: test fix and __init__ method pushed | 00:15 |
| james_w | it's probably near impossible to come up with good names for the options in the config | 00:15 |
| james_w | lifeless: it's gone in 3? | 00:15 |
| lifeless | james_w: yes | 00:16 |
| james_w | those tests have very poor failure modes, I found that when I was writing the code | 00:16 |
| lifeless | james_w: just use items() in 2.x code everywhere | 00:16 |
| lifeless | yeah | 00:16 |
| lifeless | I noticed ;) | 00:16 |
| james_w | natural given what they are doing, but... | 00:16 |
| lifeless | ewll | 00:16 |
| lifeless | can be improved | 00:16 |
| james_w | ok, want an MP for that, or can you just JFDI, as I'm about to head to bed | 00:16 |
| lifeless | some of the hook stuff added snice the core was written could make bits better already | 00:17 |
| lifeless | james_w: for 3.1? JFDI'd already | 00:17 |
| james_w | thanks | 00:17 |
| lifeless | no prob | 00:17 |
| lifeless | I should have caught that at merge time - mea culpa | 00:17 |
| lifeless | sleep well | 00:17 |
| james_w | thanks | 00:18 |
| james_w | night all | 00:18 |
| mgz | are well all passing happy now? | 00:20 |
| james_w | lifeless: for testr, I don't get where my patch is different to the behaviour it has now for $IDOPTION. I think this is because I've never really understood the options for .testr.conf and just cargo-culted. I think it's a problem area as many people will struggle to understand it, but I don't have good ideas for fixing it right now. | 00:20 |
| lifeless | james_w: I will look more closely; probably while at pycon I'll get some personal time | 00:23 |
| lifeless | james_w: I have a backlog at the moment - subunit patches, this unicode stuff in testtools - so not obviously right-or-wrong stuff gets queued a little | 00:24 |
| lifeless | mgz: yes, clean bill of health on 3.x | 00:24 |
| lifeless | and on 2 | 00:24 |
| mkanat | jam: I'm on now, if you wanted to debug the meliae stuff. | 00:30 |
| lifeless | mgz: btw testtools also sorts its NEWS file within sections | 00:32 |
| mgz | ah, oh, hadn't noticed | 00:32 |
| mgz | everything was beginning with T | 00:32 |
| lifeless | and P and J :P | 00:32 |
| mgz | and... J is before P! | 00:32 |
| mgz | so it's already mis-sorted | 00:32 |
| lifeless | yes, but thats me failing. | 00:33 |
| lifeless | :> | 00:33 |
| lifeless | mgz: so, you've changed the copyright on a file | 00:34 |
| lifeless | mgz: which is ok - you're contributing this as MIT ? | 00:34 |
| mgz | I did, it seems like the copyright assignment thing isn't happening to me, and the year needed updating anyway | 00:34 |
| mgz | but I certainly submit as-per the licence | 00:35 |
| lifeless | great | 00:35 |
| lifeless | __all__ should be sorted too, just like imports | 00:35 |
| lifeless | (I'm doing this as I note things) | 00:35 |
| mgz | (with minor worries about Python licence derivation) | 00:35 |
| lifeless | bah, it is, diff confused me | 00:36 |
| mgz | ah, there might be one import line that's missorted I spotted the other day and forgot to fix | 00:36 |
| lifeless | is ascii(foo) safe on arbitrart objects | 00:36 |
| mgz | seems to be | 00:37 |
| mgz | >>> ascii(object()) | 00:37 |
| mgz | '<object object at 0x00C39298>' | 00:37 |
| lifeless | that is scary | 00:37 |
| lifeless | scary scary scary | 00:37 |
| lifeless | tell me about this hunk | 00:37 |
| lifeless | def _u(s): | 00:38 |
| lifeless | - return unicode(s, "latin-1") | 00:38 |
| lifeless | + """Use _u('\u1234') over u'\u1234' to avoid Python 3 syntax error""" | 00:38 |
| lifeless | + return (s.replace("\\", "\\\\").replace("\\\\u", "\\u") | 00:38 |
| lifeless | + .replace("\\\\U", "\\U").decode("unicode-escape")) | 00:38 |
| mgz | ehehe, yeah | 00:38 |
| mgz | this is where just using u"" would be soooo nice | 00:38 |
| mgz | I reason that that code is correct as follows | 00:39 |
| mgz | input is an arbitrary bytestring | 00:39 |
| mgz | we double escape the escape character | 00:39 |
| mgz | we then roll that back for the two kinds of unicode escape | 00:39 |
| mgz | so, we now have a string with no escape sequences, except unicode ones | 00:40 |
| lifeless | so this is the 'string is unicode==False' case | 00:40 |
| lifeless | perhaps the docstring means 'to avoid Python 2 syntax errors' ? | 00:41 |
| mgz | yeah, and it's only for testing-testing code | 00:41 |
| mgz | no, the problem is you can't just use u"\u1234" in Python 3 | 00:41 |
| mgz | so the only 2+3 source compatible way to use unicode is... never to use unicode escapes in literals | 00:42 |
| lifeless | your example seems to be a noop | 00:42 |
| lifeless | which leave me horribly confused. | 00:42 |
| mgz | _u('\u1234') -> u'\u1234' (2) or -> '\u1234' (3) | 00:43 |
| mgz | it is horribly confusing, which I blame on the porting strategy | 00:43 |
| lifeless | so the old _u didn't honour unicode escapes | 00:44 |
| lifeless | it required a latin-1 [the file encoding] encoded unicode string | 00:44 |
| mgz | nope, it basically didn't work for anything but the bottom 256 codepoints | 00:44 |
| mgz | right. | 00:44 |
| lifeless | so your doc string really means | 00:45 |
| lifeless | 'manually handle unicode escapes provided in the string because we cannot use the 'u' prefix on python 3. | 00:46 |
| lifeless | ' | 00:46 |
| mgz | It's test-instructional, "do this or you break Python 3" | 00:46 |
| mgz | yeah. | 00:46 |
| lifeless | well, we need _u() out side of tests | 00:46 |
| lifeless | so it I think its worth having it be _good_ | 00:47 |
| mgz | well, it's not currently used outside tests, but if you can word the hack better go for it. | 00:47 |
| mgz | most of testtools can rely on Python 2 upcasting ascii str to unicode | 00:48 |
| mgz | and never use unicode literals | 00:48 |
| lifeless | def _u(s): | 00:50 |
| lifeless | - return unicode(s, "latin-1") | 00:50 |
| lifeless | + """Implement a function version of the 'u' prefix. | 00:50 |
| lifeless | + | 00:50 |
| lifeless | + This is needed becayse the u prefix isn't usable in python3. | 00:50 |
| lifeless | + | 00:50 |
| lifeless | + To migrate code that was written as u'\u1234' in Python 2 to 2+3 change | 00:50 |
| lifeless | + it to be _u('\u1234'). The Python 3 interpreter will decode it | 00:50 |
| lifeless | + appropriately and the no-op _u for Python 3 lets it through, in Python | 00:50 |
| lifeless | + 2 we then call unicode-escape in the _u function. | 00:50 |
| lifeless | + """ | 00:50 |
| lifeless | + # The double replace mangling going on prepares the string for | 00:50 |
| lifeless | + # unicode-escape - \foo is preserved, \u and \U are decoded. | 00:51 |
| lifeless | + return (s.replace("\\", "\\\\").replace("\\\\u", "\\u") | 00:51 |
| lifeless | + .replace("\\\\U", "\\U").decode("unicode-escape")) | 00:51 |
| lifeless | mgz: we can't rely on upcasting, because it can go so horribly wrong. | 00:51 |
| lifeless | I'm going to make that a __literal and use it for _u in both 2 and 3 | 00:52 |
| mgz | hehe, yeah, that docstring covers it. one of the reasons I didn't write it initally was because it would end up five times bigger than the code | 00:52 |
| mgz | nitpick: you don't need 'Implement' at the start | 00:52 |
| lifeless | true | 00:53 |
| mgz | anyway, this is a poster child for where 2to3 works better than source-compat (there are cases in the reverse as well) | 00:54 |
| lifeless | pep 257 needs a refresh for3 | 00:56 |
| mgz | XXX Mention docstrings of 2.2 properties <- if that's not done yet, might be a while coming | 00:56 |
| lifeless | yeah | 00:57 |
| lifeless | gutworth probably should see this changed version | 00:58 |
| lifeless | what about | 00:59 |
| lifeless | + # GZ 2010-06-16: Python 3 StringIO ends up here, but probably needs | 00:59 |
| lifeless | + # different handling as it doesn't want bytestrings | 00:59 |
| mgz | no code is actually passing a StringIO object into that function (unless some testtools user has replaced sys.stdout with one prior to using the test runner), so it's a drawback, but not an exercised one | 01:00 |
| lifeless | and I don't quite understand what the sys.version_info block that makes a new stream of the same class, actually does. | 01:00 |
| lifeless | mgz: runner or result ? | 01:00 |
| mgz | TestToolsTestRunner | 01:01 |
| lifeless | mgz: so it doesn't matter right now, but when pqm does to 3 | 01:01 |
| lifeless | it uses subunit | 01:01 |
| lifeless | which uses testtools | 01:01 |
| lifeless | and it formats into a stringio for handing off to email | 01:01 |
| lifeless | :> | 01:01 |
| lifeless | Will you follow up later on this ? | 01:02 |
| mgz | the new stream of the same class thing is in lieu of just doing `stream.errors = "replace"` | 01:02 |
| mgz | ^yup, there are still some things to poke here, I've got some expectedfailures and a skipped test | 01:03 |
| mgz | generally, # GZ comments are things that I intend to delete when I fix them | 01:05 |
| lifeless | right | 01:08 |
| lifeless | I was checking you were planning on continuing to scratch | 01:09 |
| lifeless | that this was a stepping stone not a result | 01:09 |
| lifeless | this worries me | 01:09 |
| lifeless | +def _exception_to_text(evalue): | 01:09 |
| lifeless | ,,, | 01:09 |
| lifeless | + except: | 01:09 |
| lifeless | + pass | 01:09 |
| lifeless | why not be a little more precise ? | 01:10 |
| mgz | it's bad, but it's what traceback._some_str does | 01:10 |
| mgz | I have a shelve thingy which adds an `isbaseexception` function and reraises those | 01:11 |
| mgz | but behaviour on Python 3 will still be, KeyboardInterrupt during Exception.__str__? eat it. | 01:11 |
| lifeless | list = ['Traceback (most recent call last):\n'] | 01:12 |
| lifeless | -> | 01:12 |
| lifeless | list = [_u('Traceback (most recent call last):\n')] | 01:12 |
| mgz | gets upcast safely, it's fine. | 01:12 |
| lifeless | I have two reasons for doing that | 01:12 |
| lifeless | firstly, because if there *is* a bug that lets things go wrong, it won't help as it is | 01:13 |
| lifeless | secondly, I want to be able to look at a string and go 'its not a function parameter to control behaviour' -> must have _b or _u | 01:13 |
| lifeless | mgz: also, naughty | 01:15 |
| lifeless | bytes is a classname | 01:15 |
| mgz | ha. habit, I often use that. | 01:15 |
| mgz | at least it wasn't added as a keyword in 3 | 01:16 |
| lifeless | me too, I'm trying to fix myself | 01:16 |
| lifeless | list = [] is a bit weird too | 01:16 |
| mgz | I do see the value in clearly documenting what should be a unicode object, but as we've just seen _u is not overhead-free | 01:16 |
| lifeless | performance wise ? | 01:16 |
| mgz | ^blame the traceback module, I'd love to have a less-weird way to write out all the logic in this function | 01:17 |
| lifeless | oh, and 2 lines of VWS between functions please | 01:18 |
| lifeless | PEP8 | 01:18 |
| mgz | wasn't that just classes? | 01:18 |
| lifeless | top level 'things' | 01:18 |
| lifeless | Separate top-level function and class definitions with two blank lines. | 01:19 |
| lifeless | methods are single lines | 01:19 |
| lifeless | look under "Blank Lines' in the pep | 01:19 |
| mgz | so it does. | 01:19 |
| mgz | I've been doing one line between related-but-not-class-method functions | 01:20 |
| lifeless | its ok | 01:20 |
| lifeless | I'm not terribly concerned, fixing where I notice, and signalling back to get better input in future ;) | 01:21 |
| lifeless | I'm not convinced that: | 01:22 |
| lifeless | + else: | 01:22 |
| lifeless | + # For Python 2, need to decode components of traceback according to | 01:22 |
| lifeless | .. | 01:22 |
| lifeless | + del __F, __M, __f, __g, __m | 01:22 |
| lifeless | is shorter than copying the method. | 01:22 |
| mgz | it's not. | 01:22 |
| mgz | that import sorting thing I mentioned, testtools/content.py - changed TestResult to import from testtools not unittest, but didn't then sort it right | 01:22 |
| lifeless | done | 01:22 |
| mgz | ^one of the reasons I didn't copy the method was though we can doing MIT->Python to put testtools things in core, I was unsure how far we could do Python->MIT | 01:23 |
| lifeless | it looks like its *just* shorter | 01:23 |
| lifeless | than 2.7 | 01:23 |
| lifeless | oh, fairly safely I should think | 01:23 |
| lifeless | I'll let it in | 01:24 |
| mgz | well, I doubt anyone will actually care, but I didn't want to create problems | 01:24 |
| lifeless | jml: ^ if you go blind, blame me and w'ell pull it out | 01:24 |
| lifeless | mgz: very considerate. | 01:24 |
| lifeless | (seriously) | 01:24 |
| lifeless | uhm | 01:25 |
| lifeless | your 3.1 _StringException has no __str__ now | 01:25 |
| lifeless | is that deliberate? | 01:26 |
| mgz | yup. | 01:26 |
| lifeless | *blink* why ? | 01:26 |
| mgz | the Exception.__str__ method does the right thing. | 01:26 |
| mgz | unless we *intend* to pass extra arguments then ignore them | 01:26 |
| lifeless | no, thats fine, citation needed ;) | 01:26 |
| lifeless | I'll add | 01:26 |
| lifeless | more style things | 01:28 |
| lifeless | class foo | 01:28 |
| lifeless | """docs""" | 01:28 |
| lifeless | \n | 01:28 |
| lifeless | def stuff | 01:28 |
| mgz | where's that? | 01:29 |
| lifeless | test_compat | 01:30 |
| lifeless | should _disabled_test_string_exception be a skip ? | 01:30 |
| mgz | ah yes, whoopsie. | 01:30 |
| mgz | it's fine as a no-run, I intend to fix... whatever bug number that was... soonish | 01:31 |
| lifeless | its a shame we need temp files | 01:33 |
| lifeless | rather than just calling into compile() | 01:33 |
| lifeless | I guess there are dragons there | 01:33 |
| lifeless | but I can live with the slower test suite | 01:34 |
| lifeless | landed | 01:34 |
| mgz | temp files are a clean-ish way of doing this, and not too much of a slowdown | 01:34 |
| lifeless | i absolute times, no, but relative it was shocking :) | 01:34 |
| lifeless | now | 01:35 |
| lifeless | -> #subunit | 01:35 |
| mgz | heh, yes, perhaps I'm too used to bzr tests building whole working trees each test | 01:35 |
| lifeless | also undesirable | 01:37 |
| lifeless | but a little harder to fix comprehensively | 01:37 |
| mgz | I'll add looking at making some of them just use compile to my list | 01:38 |
| lifeless | idle priority | 01:39 |
| lifeless | its not a functional issue | 01:39 |
| mgz | the ones where it most needs a directory system are the filesystem encoding ones and now reading back for syntax errors, the rest might be avoidable without hurting coverage | 01:39 |
| poolie | hi all | 01:41 |
| mgz | hey poolie. | 01:41 |
| lifeless | morning poolie | 01:49 |
| poolie | hi lifeless | 01:51 |
| lifeless | I think I started one of those long threads we dread this morning :) - sorry ! [python 3] | 01:52 |
| poolie | mm, i've seen worse :) | 01:52 |
| lifeless | its only just beginning :> | 01:52 |
| mgz | it doesn't help that you started everyone off confused about what the goal was | 01:52 |
| poolie | i actually looked at running with -3 a while ago when i added http://doc.bazaar.canonical.com/bzr.dev/developers/code-style.html#python-versions to the docs | 01:52 |
| lifeless | mgz: if you're going to accidentally start a long confused thread, do it well! | 01:53 |
| mgz | had you put "I think source-compatible is the way to go, not 2to3, because..." at the top, would have saved six or so messages | 01:53 |
| lifeless | ah, thats where the python version is documented | 01:53 |
| lifeless | I filed a bug that is mostly-fixed already; neat. | 01:53 |
| lifeless | however we don't expose that to our users yet, I don't think. | 01:54 |
| lifeless | mgz: well, hindsight | 01:54 |
| mgz | indeed. | 01:54 |
| mgz | blast, no more pending pqm patches with commit messages, can't test feed-pqm change lets me enter my email password on the terminal | 01:55 |
| lifeless | mgz: pastebinit ? | 01:59 |
| mgz | !pastebin | 02:00 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 02:00 |
| mgz | http://paste.ubuntu.com/453676/ | 02:00 |
| mgz | something along those lines? | 02:01 |
| lifeless | hah, cute | 02:03 |
| lifeless | yes | 02:03 |
| jam | mgz: except you now also need to catch the returned object and call obj.__exit__() | 02:03 |
| jam | hi lifeless | 02:03 |
| lifeless | yea | 02:04 |
| lifeless | per my mail to the list and the initialize docstring in trunk | 02:04 |
| lifeless | poolie: I'm popping up to rangiora to drop stuff that needs to be looked after while we're in .au | 02:05 |
| lifeless | poolie: I'll be 2-3mumble hours | 02:05 |
| lifeless | poolie: if there is anything urgent, lets do it now, otherwise see you in a bit | 02:06 |
| lifeless | mgz: you can play with ~lifeless/bzr/encoding-option/+merge/28126 | 02:07 |
| mgz | have to set a commit message on it? | 02:08 |
| poolie | lifeless: ok np | 02:08 |
| poolie | you could do some bug triage if you run out of patches | 02:09 |
| mgz | okay, that seems to work. | 02:13 |
| lifeless | poolie: sure thing, I wish I could do that via mail | 02:15 |
| poolie | .. and you could if i finished the dkim thing and got it deployed? | 02:15 |
| lifeless | poolie: I think its deeper than that | 02:19 |
| lifeless | poolie: because I use google apps | 02:19 |
| lifeless | not gmail per se | 02:19 |
| poolie | oh and they don't sign it | 02:19 |
| poolie | ok | 02:19 |
| lifeless | so I need to also find out how to make them sign that | 02:19 |
| poolie | you could gpg sign it | 02:19 |
| lifeless | If I switch back to evo | 02:19 |
| lifeless | using the google imap service | 02:20 |
| lifeless | that will work | 02:20 |
| lifeless | Or if I use firefox rather than chrome there is some magical gmail gpg extension I found but haven't used. | 02:20 |
| lifeless | its all a bit of a mess | 02:20 |
| lifeless | I have a deeper question | 02:20 |
| lifeless | 'why do we care so much' | 02:21 |
| lifeless | whats the risk | 02:21 |
| lifeless | for setting a bit on an email | 02:21 |
| lifeless | or the approved flag on an MP | 02:21 |
| lifeless | the 'queue to PQM' one I would worry more | 02:21 |
| lifeless | and 'do stuff with builders' | 02:21 |
| poolie | i agree | 02:22 |
| lifeless | if someone forges something | 02:22 |
| lifeless | rollback the change - make *that* a secured, but possible operation. | 02:22 |
| lifeless | and blacklist em | 02:22 |
| poolie | adding pointless comments to bugs is roughly as disruptive as changing their state | 02:23 |
| lifeless | *possibly* whitelist google/yahoo/msn email providers as being rasonably authoritative etc | 02:23 |
| lifeless | anyhow, must go, and we're in complete agreement here I think ;) | 02:23 |
| lifeless | sorry, got sucked into replying | 02:42 |
| lifeless | *now I go* | 02:42 |
| poolie | mgz, thanks for the hydrazine patch | 02:49 |
| mgz | getting it setup and working wasn't as bad as Alexander was fearing the other day | 02:50 |
| mgz | ...I really should be getting to bed though ;) | 02:51 |
| poolie | mgz if i'd done it i probably would have just required 2.2 | 03:20 |
| poolie | it's a pretty nerdy tool | 03:20 |
| * fullermd blinks. | 03:21 | |
| fullermd | Monkeypatch the compiler to twist the syntax on older interpreter versions?! | 03:21 |
| fullermd | Did I miss the decision to rewrite in Perl? :p | 03:21 |
| === parthm_ is now known as parthm | ||
| === replicant is now known as hazmat | ||
| lifeless_ | back | 06:25 |
| === lifeless_ is now known as lifeless | ||
| lifeless | mmm deep winter - totally dark here, now | 07:08 |
| poolie | thanks to russel for the light relief :) | 07:08 |
| lifeless | ;) | 07:08 |
| lifeless | I'm going to get fully packed, taxi or whatever organised | 07:11 |
| lifeless | then do some bugs for us | 07:11 |
| lifeless | it looks like the hotel wifi is a 3g dongle | 07:12 |
| poolie | hm | 07:12 |
| lifeless | so I might visit you as much as you are comfy with | 07:12 |
| poolie | as in, they give you a dongle | 07:12 |
| lifeless | yeah | 07:12 |
| poolie | or they have one thing shared for everyone | 07:12 |
| lifeless | they give out a dongle | 07:13 |
| poolie | i've seen worse | 07:13 |
| lifeless | indeed | 07:13 |
| lifeless | spiv: I get asked about python3 2-3 times a month, in various fora | 07:19 |
| === davidstrauss_ is now known as davidstrauss | ||
| spiv | lifeless: interesting! | 07:27 |
| lifeless | I think so | 07:43 |
| lifeless | Its usually phrased as 'when do you think bzr will be python 3 ready' | 07:44 |
| lifeless | and I usually say 'some years' | 07:44 |
| lifeless | and explain the issues | 07:44 |
| poolie | is this more of a question about py3 or about bzr? :) | 07:44 |
| lifeless | I don't know | 07:44 |
| lifeless | its a good question to ask | 07:44 |
| lifeless | some of the folk are python-heads | 07:44 |
| poolie | mine, or theirs? | 07:44 |
| spiv | Why do they care, I wonder? Are they interested in using bzrlib? | 07:44 |
| spiv | Or do they routinely ask which version gcc was used to compile their kernel too? ;) | 07:45 |
| lifeless | poolie: I think its a good question to ask about whether they are asking because of python 3 interests, or bzr interests. | 07:45 |
| poolie | mm | 07:45 |
| poolie | it reminds me a bit of ipv6 | 07:45 |
| poolie | it will probably happen faster | 07:45 |
| lifeless | poolie: and see, its been a smashing success! | 07:45 |
| poolie | but my impression was that most people were doing it for the sake of doing it | 07:46 |
| lifeless | there are, I think, broadly three groups | 07:46 |
| lifeless | of questions, not people | 07:46 |
| lifeless | mmm | 07:46 |
| lifeless | motivations for questions | 07:46 |
| lifeless | one set turns up when talking about performance | 07:46 |
| lifeless | for instance, allison randall was one of the recent folk to ask about bzr python3 readiness | 07:47 |
| lifeless | she of pynie, python-3-on-parrot fame | 07:47 |
| lifeless | and she was saying that pynie is something like 10 times faster | 07:47 |
| poolie | ? | 07:47 |
| lifeless | another set is the pure ecosystem stuff | 07:47 |
| poolie | nm, i didn't think it was that much faster | 07:48 |
| lifeless | folk interested in python3 readiness in a general sense, or in what we think of python3 - 'oh, you can't use it yet? why not? ...' | 07:48 |
| poolie | perhaps on some microbenchmark | 07:48 |
| lifeless | poolie: perhaps; I don't know. | 07:48 |
| lifeless | poolie: can't really assess though at the moment ;) | 07:48 |
| lifeless | and thirdly, yes there are folk querying whether they can use python3 to do their thing, and know thye want bzrlib (or vice versa, have python3 investment, want to know if bzrlib works for them) | 07:49 |
| vila | hi all | 07:51 |
| poolie | hi there vila | 07:53 |
| poolie | lifeless: for me the deadline is when ubuntu decides to make 3 the only option, or the default | 07:54 |
| poolie | i don't think they will remove 2 for a while | 07:54 |
| lifeless | poolie: I'm sure they won't | 07:54 |
| poolie | but it might become the default soon | 07:54 |
| lifeless | if barry has anything to do with it :) | 07:54 |
| lifeless | poolie: so, I'm going to land https://code.edge.launchpad.net/~lifeless/bzr/encoding-option/+merge/28126 - my tweaked version; ok ? [asking as per your please-dont-land-my-stuff request] | 07:55 |
| poolie | yes, thanks | 07:55 |
| lifeless | https://code.edge.launchpad.net/bzr/+merges really wants an 'any unmerged-unrejected' status option | 07:57 |
| lifeless | or a set of checkboxes rather than a dropdown | 07:57 |
| lifeless | what do you think ? | 07:57 |
| * poolie looks | 07:58 | |
| * poolie used bzr builddeb in mild anger today | 08:04 | |
| lifeless | mgz: when you get up; if you could comment on https://code.edge.launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806 - that might be nice. If the approach is sensible it seems a small effort to put it in the right place. | 08:08 |
| lifeless | poolie: mentioning it here because the audience is slightly smaller than the list | 08:26 |
| poolie | which bit? | 08:27 |
| lifeless | poolie: one thing you seem to be not acking in the py3 thread, is the 'fact|rumour|well established myth' that 2to3 is really '2.6to3' | 08:27 |
| poolie | oh ok | 08:27 |
| lifeless | If you have acked that, I'm sorry for mentioning it. | 08:27 |
| poolie | no, i didn't specifically | 08:28 |
| poolie | the only specific cases turned out not to be true | 08:28 |
| poolie | otoh i'm quite prepared to believe there are some cases that are problematic | 08:28 |
| lifeless | ok, cool | 08:30 |
| lifeless | I mention this because it affects the range of options in a very significant way | 08:30 |
| lifeless | but, enough said | 08:30 |
| lifeless | we're in broad agreement on initial steps | 08:30 |
| poolie | in looking at the changes that 2to3 makes | 08:32 |
| poolie | i can't see anything where the 2.x version is both relevant to us and not available in 2.4 | 08:33 |
| poolie | i may very well be wrong | 08:33 |
| poolie | if it turns out not to work, we'll have to try something else | 08:33 |
| lifeless | I filed this - https://bugs.edge.launchpad.net/launchpad-code/+bug/597431 | 08:36 |
| ubot5 | Launchpad bug 597431 in Launchpad Bazaar Integration "cannot set/remove prerequisite branch after creation of merge proposal (dup-of: 596796)" [Undecided,New] | 08:36 |
| ubot5 | Launchpad bug 596796 in Launchpad Bazaar Integration "Can't add an pre-req branch to an existing MP (affected: 2, heat: 95)" [Undecided,Invalid] | 08:36 |
| lifeless | which was apparently a dup of an invalid bug | 08:37 |
| lifeless | which was filed separately | 08:37 |
| lifeless | I'm a bit concerned that good intentions are leading to a pretty crufty UI | 08:37 |
| lifeless | so I'm calling this to your attention to get another opinion | 08:37 |
| lifeless | another case of the 'drop 2.5 and below' meme as related to py3 compat - I'm trying to hunt it down. http://lucumr.pocoo.org/2008/12/7/porting-to-python-3:-dos-and-donts | 08:38 |
| poolie | mm there's another one "python3 is a ghetto" | 08:39 |
| poolie | that the recommended way of using 2to3 is going to encourage people to stay there | 08:40 |
| lifeless | Terry Reedy claims on http://www.pubbs.net/200901/python/13302-2to3-help.html that his understanding is that 2to3 can convert 2.5->3.0 but not in a way that keeps working on 2.5, but it can do that if you start with 2.6. | 08:46 |
| lifeless | which seems confused. | 08:46 |
| lifeless | anyway | 08:46 |
| lifeless | enough of this | 08:46 |
| lifeless | poolie: if you had a comment about that bug, that would be nice. | 08:47 |
| poolie | that might be part of the confusion | 08:48 |
| poolie | i don't intend to feed the output into py2.4 | 08:48 |
| poolie | heh | 08:49 |
| poolie | that transcript is pretty funny | 08:49 |
| lifeless | yeah | 08:49 |
| lifeless | I was about to close it up top | 08:49 |
| lifeless | but didn't | 08:49 |
| spiv | I'd be amazed if people thought a "2to3" tool is intended to produce output suitable for 2! But I could just be easily amazed :) | 08:49 |
| poolie | > If you want to do a one-time conversion, then 2.5 to 3.0 is fine. | 08:49 |
| poolie | that's my understanding too | 08:49 |
| poolie | uh, considering he starts out by typing shell commands into the python prompt, the bar is pretty low | 08:50 |
| poolie | what a time sync | 08:52 |
| poolie | *sink | 08:52 |
| lifeless | yes. I blame guido. | 08:52 |
| poolie | actually i meant the profusion of misguided advice | 08:58 |
| poolie | re https://code.edge.launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806 | 08:58 |
| poolie | i can believe there's a bug there | 08:58 |
| poolie | the patch itself is a bit weird | 08:58 |
| poolie | it would be nice to see some reproduction instructions | 08:59 |
| lifeless | yeah | 08:59 |
| lifeless | I hope mgz can shed light on it | 08:59 |
| lifeless | as he has all the equipment | 08:59 |
| lifeless | and I know his shiftjis encoding works :) | 08:59 |
| poolie | re prerequisite branches | 09:00 |
| poolie | there is a difference between "this builds on X" and "this supersedes X" | 09:00 |
| poolie | i think prereqs are meant to express the first | 09:00 |
| poolie | people might of course forget to add the prereq when they create the mp | 09:00 |
| poolie | so it would be nice to be forgiving and let them change it later | 09:01 |
| poolie | aaron seems to have the approach that mps should be locked after creation | 09:02 |
| poolie | which seems a bit weird | 09:02 |
| lifeless | right, adding a prereq for our use case discussed recently is a hack | 09:02 |
| lifeless | -but- | 09:02 |
| lifeless | you may realise that you have two things after the fact | 09:03 |
| lifeless | and split them up | 09:03 |
| lifeless | or as you say just make a mistake | 09:03 |
| poolie | right | 09:03 |
| lifeless | Aaron links through to a bug that says precisely that things should be locked, citing an unexplained security concern. | 09:03 |
| poolie | istm that there is a rule "mps should not change drastically while they're under consideration" | 09:03 |
| spiv | Well, I guess changing the pre-req should also change the diff to review. | 09:03 |
| poolie | and "you should be clear what the vote applies to" | 09:03 |
| lifeless | spiv: so does 'push' :> | 09:04 |
| poolie | but the first should be enforced by humans more than code | 09:04 |
| lifeless | spiv: and neither email the reviewers. | 09:04 |
| poolie | and perhaps they should only be locked at the moment they're queued | 09:04 |
| lifeless | poolie: yes, thats my stance | 09:04 |
| spiv | Specifically, you could have a pre-req that hides some revisions that add bad code. | 09:04 |
| spiv | But, you can do that already | 09:04 |
| lifeless | poolie: thank you for the second opinion | 09:04 |
| spiv | So I don't quite follow abentley's concern either. | 09:04 |
| lifeless | spiv: right; in fact with a prereq you would say 'cannot queue, pre-req X is not approved to queue' | 09:05 |
| spiv | Right. | 09:05 |
| spiv | Hmm, so a scenario that is sort of plausible is initially having a pre-req on a MP that hides some bad revisions. Then reviewers review the good parts and approve, then the MP is modified to remove the pre-req and stays apparently approved. | 09:06 |
| spiv | But if you take a "once overall status is approved the MP is locked" approach then changing the pre-req like that would at worst knock it out of approved. | 09:07 |
| lifeless | whats the weather like in sdyney atm | 09:07 |
| lifeless | spiv: agreed | 09:07 |
| spiv | Weather applet says 14C, rain showers ;) | 09:08 |
| lifeless | so please do subscribe to the bug | 09:08 |
| spiv | Which sounds about right to me. | 09:08 |
| lifeless | and help me tease this apart | 09:08 |
| poolie | accurate | 09:08 |
| poolie | quite wet here | 09:08 |
| lifeless | I'd hate for us to have a lot of machinery and complexity driving an odd user experience | 09:08 |
| spiv | Well, I'll let abentley explain his concern first, rather than distract the bug itself with my speculation about his concern. | 09:08 |
| lifeless | urls changing | 09:08 |
| lifeless | etc | 09:08 |
| lifeless | spiv: sure | 09:08 |
| poolie | i suspect we need some use cases or something at a higher level than bugs | 09:09 |
| poolie | changing user model is hard to negotiate through bugs | 09:09 |
| * spiv makes sure he is subscribed to that bug | 09:09 | |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| vila | lifeless: loom test failure, reno 115 for loom and bzr.dev revno 5317: AttributeError: 'RemoteBranch' object has no attribute '_set_last_loom' | 09:29 |
| lifeless | vila: what test ? | 09:29 |
| vila | lifeless: paste coming just a sec | 09:30 |
| vila | lifeless: http://paste.ubuntu.com/453808/ | 09:30 |
| vila | argh, forget the noise at the beginning, look at the last run | 09:31 |
| lifeless | I see it too | 09:31 |
| lifeless | is it new ? | 09:32 |
| vila | lifeless: starting at line 65 with BZR_PLUGIN_PATH=-site BZR_PLUGINS_AT=loom@${HOME}/.bazaar/plugins/loom ./bzr selftest -s bt.per_branch -s bt.per_interbranch | 09:32 |
| vila | bzr selftest: /home/vila/src/bzr/trunk/bzr | 09:32 |
| lifeless | vila: happy to fix it tomorrow | 09:33 |
| vila | lifeless: I encounter it yesterday but I thought I was out of date, so pretty new finally (after your patch for interbranch anyway) | 09:33 |
| vila | lifeless: ok, want a bug ? | 09:33 |
| lifeless | meh | 09:33 |
| lifeless | no need | 09:33 |
| vila | cool | 09:33 |
| mgz | poolie: ha! press ganged to hydrazine. sorry I went to bed before I could do the push. | 09:34 |
| vila | not ablocker but pretty annoying as working *in* a loom requires that the plugin is active or the test suite fails (for 'bzr version' tests or something that needs to use the current bzr src branch) | 09:34 |
| mgz | poolie: I know it's a dev tool, but as my main bzr is still pre-2.2 and lifeless has only *just* changed the init mechanism again, I had motivation to cover all angles | 09:35 |
| vila | lifeless: so whether or not I activate the plugin I can't get clean runs :-/ | 09:35 |
| poolie | mgz no problem at all | 09:35 |
| poolie | if someone's using it with pre-2.2 i'm quite happy to add the support | 09:35 |
| mgz | lifeless: I'd forgotten about that branch, but was thinking of that sort of approach just the other day when doing bzr-grep stuff for parthm | 09:36 |
| mgz | doing colour for windows, and doing the kind of console size change detection that vila nearly killed us all with means you need a console handle | 09:37 |
| mgz | so was going to find some time to investigate doing a custon ui object based on the win console stuff | 09:37 |
| vila | mgz: thanks for the credit !!! :-P | 09:37 |
| mgz | :D | 09:37 |
| mgz | would be something like having a curses of TextUIFactory | 09:38 |
| lifeless | vila: its important to me that loom work | 09:38 |
| lifeless | vila: this week is pp week, so a different focus | 09:38 |
| lifeless | vila: but that will be very shallow | 09:38 |
| lifeless | vila: there will be a missing unwrap_branch or similar | 09:39 |
| vila | lifeless: sure, no worries, I've got a workaround: http://paste.ubuntu.com/453812/ | 09:39 |
| vila | lifeless: may be not the right solution but unblocks me | 09:39 |
| lifeless | vila: loom side of the fix pushed. | 09:43 |
| lifeless | vila: you get to fix the bzr test :P | 09:43 |
| vila | Ha ! I hadn't thought about that one: paramiko use threads internally, exceptions can occur there but *can't* be caught... | 09:43 |
| poolie | wow, "Mojibake" leads into a world of distraction :) | 09:44 |
| vila | lifeless: you rock ! ... let me look | 09:44 |
| lifeless | poolie: distractapedia ? | 09:45 |
| poolie | mm | 09:45 |
| mgz | lifeless: so, the basic idea of the lovesyao/ branch seems reasonable to me, but the duplicating bits from ctypes.wintypes, not checking for errors, replacing std streams, and putting it in the bzr script are all wrong | 09:45 |
| lifeless | mgz: ok, thats progress - thanks. | 09:46 |
| mgz | for instance, apply that patch, then try and redirect bzr output to file, get nothing | 09:47 |
| Mez | hmmles... | 09:47 |
| Mez | bzr packaging is dodgy in lucid. | 09:47 |
| Mez | I've installed under ubuntu-minimal - and it's throwing errors about missing _md5 in hashlib | 09:48 |
| Mez | ah, actually, this is hardy :( | 09:48 |
| lifeless | Mez: python-minimal isn't supported by anything - the package description says so :) | 09:51 |
| poolie | mgz: i agree | 09:52 |
| Mez | lifeless: *shrugs* then maybe ubuntu-minimal shouldnt use it. | 09:53 |
| lifeless | I agree | 09:53 |
| Mez | I can't even do-release-upgrade with it | 09:53 |
| mgz | if there's another surge of interest about getting colour in core, I'll bump trying out a winconsole based ui factory up my list of fun things to try | 09:54 |
| Mez | what's the correct package for python? | 09:54 |
| lifeless | mgz: I was just trawling stale patches | 09:54 |
| lifeless | Mez: python | 09:54 |
| Mez | which is apparently already installed... | 09:55 |
| mgz | it was a timely reminder, I punted on looking at it a few weeks back on bzr-grep | 09:55 |
| lifeless | or python2.5 / python2.6 etc | 09:55 |
| lifeless | Mez: thats interesting | 09:55 |
| Mez | ImportError: no module named _md5 | 09:56 |
| jpds | 1/11 | 09:56 |
| vila | lifeless: meh, your fix is even more work for me than my workaround and looks suspicously hard to fix :-) So I think I'll stay with my workaround :) | 10:01 |
| poolie | vila, re configs | 10:01 |
| poolie | i think the thing to do is to lock for the whole transaction but not make it too long | 10:02 |
| poolie | we might need to look into what bzr-svn is writing into those files | 10:02 |
| vila | for context: bug #525571 | 10:03 |
| ubot5 | Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 6, heat: 45)" [High,Triaged] https://launchpad.net/bugs/525571 | 10:03 |
| lifeless | vila: your workaround fails to write a loom file | 10:04 |
| lifeless | vila: it creates corrupt looms and will really hurt you | 10:04 |
| lifeless | vila: so I recommend you don't. | 10:04 |
| lifeless | vila: to fix it, the bzr test just needs to relax a little. | 10:04 |
| vila | lifeless: only if there are no threads right ? | 10:04 |
| lifeless | vila: no, your workaround simply fails to write it. | 10:04 |
| lifeless | vila: possibly it writes it in some cases, I'm tired. | 10:05 |
| lifeless | vila: anyhow, definitely not mergable, because an empty loom is still meant to have a valid loom file. | 10:05 |
| vila | lifeless: sure, but I can't afford a failing test suite *right now* and for a couple of hours, so I'll stick with that, I'll check the loom state very thoroughly meanwhile | 10:06 |
| spiv | I think the right fix is to add a _ensure_real helper to the Inter object for _set_loom_state, like it does for other things already. | 10:21 |
| spiv | Although that may trip some HPSS call count assertions. | 10:22 |
| lifeless | spiv: thats what unwrap branch is and does | 10:23 |
| spiv | lifeless: yeah, that's the one | 10:23 |
| lifeless | spiv: and the failure vila references is the extra get | 10:23 |
| spiv | Ah, good. For some values of "good" :) | 10:24 |
| lifeless | 'yes we have no bananas' | 10:24 |
| poolie | heh, i just had a cute failure in lp code | 10:47 |
| poolie | or bug, rather | 10:47 |
| poolie | self.assertTrue(principal.person.preferredemail.email, 'foo.bar@canonical.com') | 10:47 |
| poolie | obvious once you see it | 10:47 |
| poolie | not so great that it passes | 10:47 |
| mgz | should be assertEqual? | 10:49 |
| poolie | it should | 10:49 |
| === radoe_ is now known as radoe | ||
| exarkun | bzr: ERROR: [Error 145] The directory is not empty: u'C:/Users/exarkun/twistedbot/windows7-64-py2.6-select/Twisted/.bzr/checkout/limbo/new-7/words' | 13:20 |
| exarkun | When running "bzr checkout svn://...." | 13:21 |
| spiv | exarkun: ooh, wacky | 13:28 |
| spiv | exarkun: bug report, please :/ | 13:28 |
| spiv | exarkun: often problems with temporary files on Windows are related to virus scanners keeping files open at inconvenient moments, interfering with attempts to delete or even rename them... possibly that's involved here? | 13:30 |
| exarkun | Maybe if there's something that comes with Windows 7, I don't know | 13:30 |
| exarkun | I don't think there's anything extra installed | 13:30 |
| spiv | (.bzr/checkout/limbo is a temporary directory for assembling files for the checkout) | 13:31 |
| spiv | That's what I feared :/ | 13:31 |
| spiv | Make sure to include the traceback from the .bzr.log, hopefully it will provide an extra clue. | 13:32 |
| exarkun | That would involve being able to get files off of a Windows machine... I have no idea how to do that. | 13:33 |
| spiv | :( | 13:34 |
| spiv | Perhaps add -Derror to the command line the build slave runs? | 13:34 |
| spiv | That will cause bzr to always dump a traceback if it exits with an error code.\ | 13:35 |
| exarkun | Can't add arbitrary arguments to bzr command lines without modifying buildbot slave code | 13:35 |
| spiv | vila: remember that paramiko bug? https://code.edge.launchpad.net/~spiv/+archive/packaging-test | 13:36 |
| spiv | exarkun: oh right, it's all software. Everything is terrible :( | 13:36 |
| spiv | vila: please install that on your lucid build slave | 13:37 |
| spiv | vila: and undo whatever hack you did to hide the corresponding test failure | 13:37 |
| vila | spiv: will look into it ! | 13:40 |
| vila | spiv: the hack was just to blacklist the test with -x :-) | 13:40 |
| vila | spiv: so I can just add this ppa to my /etc/apt/sources.list right ? Would a newer version packaged for lucid override that in due time ? | 13:42 |
| spiv | vila: apt-add-repository ppa:spiv/packaging-test | 13:43 |
| vila | yeah, better, it adds the key too right ? | 13:43 |
| spiv | vila: a newer version in lucid should override it if I didn't screw up the version on my package, yes :) | 13:43 |
| spiv | Right. | 13:43 |
| * vila boots the slave | 13:44 | |
| vila | spiv: it gets flagged as not authenticated :-/ | 13:46 |
| vila | spiv: not a problem for me but you may want to investigate | 13:46 |
| spiv | oh boo. | 13:46 |
| maxb | spiv: Likely just Launchpad taking a bit of time to generate the key | 13:56 |
| vila | spiv: test suite passing on lucid, test whitelisted again :) Well done | 13:58 |
| spiv | vila: suite, I mean, sweet! Thanks :) | 13:59 |
| spiv | maxb: well, luckily I'm unlikely to care about it tonight | 13:59 |
| maxb | spiv: It has fixed itself already | 13:59 |
| spiv | maxb: so if the problem fixes itself by magic then that's great :) | 13:59 |
| vila | spiv: if you're bored, on hadry, we know have repeated failure for http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/testReport/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ :-P | 14:00 |
| spiv | maxb: excellent :) | 14:00 |
| vila | hardly hadry, most probably hardy | 14:00 |
| spiv | vila: bored? Unlikely :) | 14:00 |
| vila | :-D | 14:00 |
| spiv | vila: but in case *you* are... https://bugs.edge.launchpad.net/bzr/+bug/522637 | 14:00 |
| ubot5 | Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 10, heat: 54)" [High,Confirmed] | 14:00 |
| vila | spiv: I thought you were so happy to reproduce that one locally ? | 14:01 |
| spiv | vila: I'm happy, but also haven't yet had the time to dig into it at all | 14:01 |
| vila | but bored, me ? I wish :) | 14:01 |
| rbriggsatuiowa | will a successful pull look the same as a merge + commit in the bzr history? | 14:31 |
| spiv | rbriggsatuiowa: not quite | 14:32 |
| spiv | merge + commit makes a new revision, with two parent revisions: your prev revision, the merged revision. | 14:33 |
| spiv | Whereas with a successful pull your local branch is simply updated to have its latest revision be the same as the latest revision as you are pulling from. No new revisions are created that didn't already exist. | 14:34 |
| rbriggsatuiowa | spiv: so pull revision history will be slightly more readable? | 14:35 |
| spiv | In either case, the full history that you had previously and that the other branch will both be present. | 14:35 |
| spiv | Depends on what you think makes a history readable :) | 14:35 |
| spiv | And perhaps on which tools you use to look at the history. | 14:35 |
| === oubiwann is now known as oubiwann-away | ||
| spiv | By default "bzr log" will only show "mainline" revisions, so a revision that merged 10 revs from another branch only takes up one entry. | 14:36 |
| spiv | Or maybe you'd rather look at history with a GUI like "bzr qlog"... | 14:37 |
| rbriggsatuiowa | spiv: looking at what --include-merges looks like for both ... | 14:37 |
| spiv | There's not one right answer, it's a matter of what works for you :) | 14:37 |
| spiv | If you have time to experiment a little, then I recommend doing that and see what you like. | 14:38 |
| rbriggsatuiowa | spiv: I like the idea of pull slightly better - I'm trying to script some stuff out and pull seems nice in that if they haven't diverged I can just pull in - otherwise I'll bring the two branches up manually | 14:38 |
| spiv | Otherwise, "pull when you can and merge when you can't" is likely to be a good default for you. | 14:39 |
| rbriggsatuiowa | spiv: sweet - thanks for your help | 14:39 |
| spiv | You're welcome. | 14:39 |
| === nlisgo_ is now known as nlisgo | ||
| exarkun | I'm not sure I understand what this is showing me, <http://pastebin.com/h3cb0fyL>, particularly wrt _zippath.py | 15:10 |
| exarkun | I think that should be a rename from zippath.py, not an add | 15:10 |
| exarkun | Hm. It seems to be because when I did "bzr up-thread" I ended up with a pending merge for some reason. | 15:14 |
| exarkun | But I didn't do anything that should require merging, I just added a new file | 15:15 |
| spiv | If the thread you are in has revisions not in the next thread, and you do up-thread, then it does that merge | 15:18 |
| exarkun | I wish it were more visible :( | 15:19 |
| spiv | The behaviour of up-thread in bzr-loom trunk has changed recently to make this a little more automatic, and I think more improvements are planned to cut down unnecessary merges. | 15:19 |
| spiv | File a bug, lifeless has been spending some time polishing looms recently. | 15:19 |
| exarkun | everything else related to looms is really awesome, though | 15:21 |
| jam | spiv: what are you still doing up? :) | 15:25 |
| jam | morning vila | 15:26 |
| vila | morning jam ! | 15:26 |
| vila | exarkun: you may want to look at --auto or even upgrade to the loom trunk (which requires bzr.dev currently though) where --auto is now the default | 15:28 |
| vila | exarkun: with the latests version I intensively use 'bzr switch' and 'bzr up-thread [thread]' to work on the right thread when needed | 15:28 |
| vila | latest versionS | 15:29 |
| exarkun | Hmm 'bzr switch' | 15:29 |
| vila | jam: did you read the IRC logs from a couple of days ago (I think it was this week) where we discussed the update_copyright bug that update the copyright line without checking if the current committer is really the one doing the change ? | 15:30 |
| jam | vila: I did not, but I don't really care :) | 15:30 |
| vila | jam: which is the case I encounter when using looms and pulling new changes from bzr.dev and merging via up-thread | 15:31 |
| jam | the point is to get the copyright lines correct | 15:31 |
| jam | it doesn't matter if *vila* changed the file | 15:31 |
| jam | it still needs an updated copyright line | 15:31 |
| jam | vila: that behavior is ~ intentional | 15:31 |
| vila | jam: right, you need to read the logs for different points of view :) | 15:31 |
| jam | vila: so... the only reason I don't update every file from the beginning, is because a file that is not otherwise modified, shouldn't end up modified just to update the copyright | 15:34 |
| jam | otherwise | 15:34 |
| jam | if the person had set the right copyright date | 15:34 |
| jam | *when they modified the file* | 15:34 |
| jam | then my plugin would be a no-op | 15:34 |
| jam | otherwise, the copyright line is *currently wrong and should be fixed* | 15:35 |
| vila | by who ? | 15:35 |
| jam | now, there are cases where somebody did the modification in 2005, and you are just now merging it | 15:35 |
| jam | vila: does it matter who updates it? | 15:35 |
| jam | as long as the line is corret | 15:35 |
| jam | correct | 15:35 |
| spiv | jam: I'm not really awake | 15:35 |
| jam | spiv: kisses to little Vincent | 15:35 |
| jam | spiv: and sleep well | 15:36 |
| vila | lifeless argued that pqm shouldn't be the one hence update_copyright shouldn't be installed there | 15:36 |
| spiv | jam: but if I were, I'd say "but what about someone that makes a commit when their system clock is in the wrong year?" :P | 15:36 |
| jam | spiv: it would still get recorded in bzr with the wrong year | 15:37 |
| vila | by extension, someone *merging* a change shouldn't update the copyright line either | 15:37 |
| jam | and update-copyright will then spit out the wrong year at a later time anyway | 15:37 |
| jam | having the wrong year is going to give wrong info for all sorts of reasons | 15:37 |
| spiv | jam: other idea I had recently: | 15:37 |
| jam | vila: so... if you merge bzr.dev, the code is currently wrong (because some copyright headers haven't been updated) | 15:37 |
| jam | it is certainly possible that we should just spin on bzr.dev and get it right | 15:37 |
| spiv | jam: it would be cute to keep copyright out of the files in the repo, and use content filters to add it to trees. | 15:37 |
| jam | rather than having your merges do it | 15:37 |
| jam | however | 15:38 |
| jam | you should still get *convergence* | 15:38 |
| vila | jam: I'm already sold on convergence you know :) | 15:38 |
| spiv | jam: thanks for the kind wishes | 15:39 |
| spiv | g'night all! | 15:39 |
| vila | I'd just mention the discussion about making the plugin less eager which will only *slow* down the convergence :) | 15:39 |
| jam | spiv: content filters would be interesting, I don't fully understand why you're required to have Copyright header in every file, etc. | 15:39 |
| jam | vila: I disagree | 15:39 |
| jam | the plugin shouldn't be touching much if someone has already run it | 15:40 |
| vila | jam: but if you want to review https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28306, convergence will happen faster :-P | 15:40 |
| jam | if you really want it, write a patch that includes an iter_changes() against all parents but the first, and omit files that seem changed in the first, are not actually according to the latter. | 15:40 |
| vila | jam: well, fixing that bug could certainly rally more users and converge faster then :) | 15:40 |
| jam | vila: meh | 15:41 |
| jam | I think the current semantics are correct | 15:41 |
| jam | I can't force an update in the branch you merged *from* | 15:41 |
| jam | so I might as well do it in the one you merged *to* | 15:41 |
| jam | vila: your diff is not ready yet | 15:41 |
| vila | jam: you can start by reading the commit messages :) | 15:42 |
| vila | teasing you :) | 15:42 |
| jam | vila: *way* to verbose | 15:42 |
| jam | your commit comments are 4 screens | 15:42 |
| jam | (and poorly wrapped for some reason) | 15:42 |
| vila | urgh, damn lp | 15:43 |
| jam | ahh, if I make my screen full-width | 15:43 |
| jam | it gets slightly better | 15:43 |
| jam | it seems there is a column forcing early wrapping | 15:43 |
| jam | which is pretty ugly. | 15:43 |
| vila | indeed, 80 columns ftw ! | 15:43 |
| jam | vila: tbh, I find your style of log messages to be overly verbose. | 15:48 |
| jam | and hard to read | 15:48 |
| jam | I would rather more of a summary, and less of a line-by-line what changed | 15:48 |
| jam | maybe that's just me | 15:48 |
| jam | (having the filenames also makes it harder to read, because I have to mentally filter out stuff) | 15:48 |
| jam | Then again, if I ever go back years later, maybe I'd rather the extra detail | 15:49 |
| vila | that's the gnu ChangLog style and we are a GNU project :-) Just focus of the first paragraph which is generally a summary | 15:49 |
| vila | It's part of my workflow and help verify my commits and it often helped catch typos or errors, | 15:50 |
| jam | vila: well, if launchpad formatted the page correctly, it might be easier. I assume things are indented, etc, appropriately? | 15:50 |
| vila | it also triggers some last minute fixes which were wrong though :) | 15:50 |
| vila | they are wrapped to fit the 80 (surely less) on word boundaries which isn't always ideal when long identifiers are present. | 15:51 |
| vila | But overall since we have a hierarchical history in bzr.dev you rarely encounter them unless you dig for a specific point, and in this case *I* am happy to find the details ;) | 15:52 |
| jam | sure | 15:54 |
| jam | but I do try to read your logs sometimes, and am often put off from doing so | 15:54 |
| jam | just letting you know | 15:54 |
| jam | you certainly don't have to change | 15:54 |
| jam | *more* commits with terser info might work better :) | 15:54 |
| vila | yup, I keep trying :) | 15:55 |
| jam | it certainly is an argument for per-file commit messages | 15:55 |
| JoshBrown | When branching, where do you normally put the new branch relative to the main branch? | 16:34 |
| vila | JoshBrown: it depends of your workflow, but I never put a branch *inside* another branch, | 16:38 |
| vila | JoshBrown: if you intend to work on many branches for the same project, you want to use a shared repository, | 16:38 |
| vila | JoshBrown: from there, you're free to define any hierarchy *under* the shared repo, | 16:38 |
| vila | JoshBrown: if you have a few branches, just put them there, if you have more, group them into some topic folder (bugs, experimental, cleanup, whatever), | 16:39 |
| vila | JoshBrown: when a branch use a shared repo, bzr will walk up the file system hierarchy to find the repo, so use any intermediate level you see fit | 16:40 |
| JoshBrown | Thanks, I wondered what a repo was, and that answers my question perfectly :) | 16:42 |
| vila | JoshBrown: a repo is where all the revisions are stored, a branch is merely a pointer to the tip (the most recent revision) | 16:43 |
| jam | vila: I don't know what you did, but the diff *still* isn't available | 16:44 |
| vila | JoshBrown: a so-called "stand alone" branch has its own private repo, you can use 'bzr reconfigure' to change | 16:44 |
| vila | jam: *I* did as usual, blame lp :) I've noticed the diff wasn't still there but really nothing different from my side I can think of, I even exported my loom to ensure I'm dealing with regular branches | 16:45 |
| vila | jam: just clicked the resubmit button... | 16:46 |
| vila | I just... | 16:46 |
| JoshBrown | vila: Ahh, I thought bazaar was 'distributed' as in every branch was completely separate. Now you've explained it, it makes way more sense. Thanks! | 16:46 |
| jam | vila: well, now you're *really* going to piss lp off :) | 16:46 |
| vila | jam: :) | 16:47 |
| vila | JoshBrown: being distributed doesn't forbid sharing locally :) | 16:47 |
| JoshBrown | vila: Yeah, I see that now - I'm glad bazaar isn't as wasteful as I thought. | 16:49 |
| === nlisgo_ is now known as nlisgo | ||
| === beuno is now known as beuno-lunch | ||
| Phoenixz | I have an open source project on launchpad. I use this project as a framework for another project at the company where I work for. Now, I don't want to mix the stuff from this company in the open source project, but every now and then, this implementation here makes me find bugs in the open source framework. I fix them in this project, and I want to merge the fixes back to the open source project, but WITHOUT the company specific implementation.. | 17:44 |
| Phoenixz | I figured I'd just do a merge from the company project to the open source project, remove the company specific stuff, and commit, push back.. I did that and it looks okay to me | 17:45 |
| Phoenixz | but now when I do a push to launchpad, it starts sending megabytes of data to launchpad (the company project has various large images).. What went wrong here? | 17:45 |
| Phoenixz | The WT looks good, has only the framework + its fixes.. when using bzr ls, I also only see the correct files, even in older revisions.. | 17:48 |
| Phoenixz | So where do these megabytes of data come from if I can't find them in my repo, and AFAIK, they never got in there in the first place? | 17:49 |
| jam | vila: quick question, is GnuChangeLog specific that everything is left aligned? It seems to me that you should be indenting | 17:57 |
| jam | I'll also note that "bzr log --gnu-changelog" puts the file content *before* the summary | 17:57 |
| vila | jam: I'm unclear on that since bzr log indent again so I de-dent before committing... | 17:58 |
| jam | not sure who is wrong | 17:58 |
| vila | wow, I'll need to have a look at that... | 17:58 |
| jam | vila: http://paste.ubuntu.com/454019/ | 17:59 |
| jam | as an example of what would be nicer *to me* | 17:59 |
| vila | hmm, so --gnu-changelog outputs exactly what I have in my ChangeLog files (which I use as buffers before committing) | 17:59 |
| jam | vila: 'bzr log --gnu-changelog -v' | 18:00 |
| jam | the --verbose is necessary to get the list of files | 18:00 |
| jam | look more at bzr.dev than your log | 18:00 |
| jam | since you already format specifically | 18:00 |
| jam | http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs | 18:01 |
| jam | shows pretty clearly that you *don't* indent a subsection | 18:01 |
| jam | shame | 18:01 |
| vila | I see, no, it's different, hmm, interesting issue, -gnu-changelog try to simulate the fact that someone have entered a single comment for *all* files, which indeed totally fail in my case since I entered comments for each file | 18:02 |
| vila | jam: no shame, that's because it's colorized in all good editors so you don't need indentations :-P | 18:02 |
| jam | of course, the overall ChangeLog design is very lisp-ish with its choice of () on *everything* | 18:03 |
| vila | but there seem to be far too may empty lines there | 18:03 |
| jam | vila: 'bzr log | vim' isn't colorized at all | 18:03 |
| jam | I *can* end up doing "set ft=changelog" which does help a fair bit | 18:03 |
| jam | though basically by allowing me to ignore everything that I mentioned is too verbose | 18:04 |
| jam | (it shows in blue, and I can just skip over all of it easily) | 18:04 |
| vila | bzr log --gnu-changelog -n0 -l18 -v > ChangeLog-2 C-x C-f ChangeLog-2 ... colorized :) | 18:04 |
| === beuno-lunch is now known as beuno | ||
| jam | sure, but C-x C-f ... | 18:05 |
| jam | and/or explicit naming of the content | 18:05 |
| vila | available in all good editors I said... oh come on, I just did the simplest here, let see... | 18:05 |
| jam | I'll also note that it borks all the other entries | 18:06 |
| jam | (mbp) test that kerberos isn't loaded (Martin Pool) shows up as all-blue | 18:06 |
| jam | (note no --gnu-changelog) | 18:06 |
| vila | C-SPC M-| bzr log --gnu-changelog -n0 -l18 -v M-x change-log-mode | 18:06 |
| jam | anyway, I can do something like that to make it easier to read your stuff | 18:06 |
| vila | cool :) | 18:06 |
| jam | I don't really feel that I *like* it | 18:06 |
| jam | but at least I don't just auto-skip everything you've writetn | 18:07 |
| jam | written | 18:07 |
| vila | ha, some perl motto applies here: be strict in what you produce but tolerant in what you accept, | 18:07 |
| vila | let's both medidate on that :-) | 18:07 |
| vila | (i.e. I'll try to to more commits and less verbose ones :) | 18:08 |
| vila | yeah toto my dear friend, NOT, to do | 18:08 |
| jam | vila: I've found that being tolerant in what you accept leads to people being loose in what they generate. Witness HTML non-strictness and 'bug-compatible' behavior :) | 18:09 |
| vila | hehe | 18:09 |
| vila | yeah GIGO: Garbage In Garbage Out | 18:09 |
| vila | I found the above a bit derogatory and lately I'm more inclined to call it: Better Input Means Better Output | 18:10 |
| vila | dunno, the acronym sounds sexier... | 18:10 |
| === oubiwann-away is now known as oubiwann | ||
| jam | :) | 18:16 |
| jam | vila: also note our failure to roundtrip revisions with '\r' in them which broke some mysql revs, etc. | 18:16 |
| jam | anyway | 18:17 |
| jam | I mostly wanted to let you know that I do find your log messages hard to read, and they don't really play nicely with other tools (like launchpad). | 18:17 |
| jam | I think there is a reasonable request to make per-file commit messages more fully supported | 18:17 |
| jam | in which case you can do the formatting such that --gnu-changelog output gives you what you really want | 18:18 |
| jam | and we could do something like a commit --file importer | 18:18 |
| jam | that could convert ChangeLog formatting into the appropriate bzr internal structure | 18:18 |
| jam | vila: oh, and 2+hrs later, still no dif | 18:19 |
| jam | diff | 18:19 |
| jam | definitely something broken | 18:19 |
| vila | yup, I had a vague plan for that | 18:19 |
| vila | yes, I raised the issue in #launchpad-code but no answer :-/ | 18:19 |
| vila | and that's the same for my other threads too, | 18:20 |
| vila | but lp seems to suffer from some problems too so that may just be a transient issue... | 18:21 |
| jam | vila: you shouldn't be working now anyway, thanks for at least putting up with my gripes :) | 18:23 |
| vila | noted, I'll finish submitting my threads hoping for lp to finally update the diffs... (only 2 left) | 18:24 |
| jam | so, I don't think your changes to osutils are really correct | 18:25 |
| jam | in that we just do "foo = ntpath.foo" anyway | 18:25 |
| jam | and I *think* you might have regressed some of the shutil stuff | 18:25 |
| jam | where we could have lazily imported rmtree | 18:25 |
| jam | and not triggered an import of shutil until someone actually calls rmtree | 18:25 |
| jam | (that might not be in lazy form, though) | 18:26 |
| jam | I remember working on that, I don't know what the current state is | 18:26 |
| vila | jam: hmm, then we'll need to define proper wrappers to delay the import instead of relying on symbol aliasing | 18:31 |
| vila | or finally cleanup osutils.... | 18:31 |
| jam | vila: what is wrong with lazy_import as a wrapper here, given that it... works | 18:32 |
| jam | just comment that specific one with why we do it | 18:32 |
| jam | you *can* add a "def rmtree(*args, **kwargs): return shutil.rmtree(*args, **kwargs)" | 18:32 |
| jam | but it seems a bit pessimistic | 18:33 |
| jam | if it makes you feel better, you can do it, though | 18:33 |
| jam | certainly in that file, lazy-importing something whose attribute you access is certainly a loss | 18:33 |
| jam | for readability, and probably even runtime (as you have at least 1 indirection that you always pay) | 18:33 |
| vila | I don't remember why I fixed that one this way, probably because I didn't understood the intent, I can revert that as well adding a 'lazily' in the comment to clarify | 18:34 |
| jam | vila: so most of the "from transport import get_transport" changes to "transport.get_transport" changes seem fine (though monkey-patching a function in the test suite at that level is a bit ugly.) | 18:34 |
| jam | I don't fully understand the http protocol stuff | 18:35 |
| jam | and especially why it is mixed in with these other changes | 18:35 |
| vila | because it cleans up some bugs in the parametrisation without really changing anything else | 18:36 |
| vila | well, bugs about not respecting the parametrisation will be more correct | 18:36 |
| vila | the http protocol is the parameter that decides which server should be used | 18:36 |
| vila | 1.0 no threads for requests, 1.1 a thread by request (well really a connection) | 18:37 |
| jam | vila: I find test_http.load_tests() very hard to read. It is often unclear to me what tests are being multiplexed | 18:38 |
| jam | (x, y = split_suite_by_condition() is x or y the one that matched) | 18:38 |
| jam | and why are we splitting and multiplexing these one way, and these another | 18:38 |
| jam | a comment is probably warranted | 18:38 |
| jam | # TestHTTPTransportRegistration should be tested against all transports, but all other tests should only be parameterized by protocol | 18:39 |
| jam | or something like that | 18:39 |
| jam | or maybe just clarifying | 18:39 |
| jam | # some tests test the transport implementation, so we multiply for urllib and pycurl | 18:39 |
| jam | # other tests only parameterize on HTTP 1.0 vs 1.1 | 18:40 |
| jam | maybe it is just me, but doing it all via isinstance checks seems bad form | 18:40 |
| jam | versus, say creating a per_http_transport and per_http_protocol files | 18:40 |
| jam | you don't have to do it | 18:41 |
| jam | just observations about my confusion trying to read (and in the future support) this code | 18:41 |
| exarkun | I made a loom, and then I pushed, and then I recorded, and then I pushed again and nothing happened. | 18:41 |
| vila | isinstance() makes load_tests() simpler since many test classes can inherit from a base with common parameters | 18:42 |
| exarkun | So now my loom is permanently available only in my one working copy? | 18:42 |
| jam | exarkun: I don't know the specifics, but possibly doing one more commit + record + push will make a difference | 18:42 |
| vila | exarkun: a related bug has been fixed really recently about that | 18:42 |
| jam | vila: so it would probably take at least 1hr for me to actually understand load_tests | 18:43 |
| jam | if not longer | 18:43 |
| jam | I don't know if we could do better | 18:43 |
| jam | but as it stands, it is pretty bad | 18:43 |
| jam | That doesn't even count understanding *why* the tests are split as such, just to figure out "ok, *these* tests are parameterized *this* way" | 18:43 |
| jam | I *think* splitting it such that all tests in a single file are parameterized identically would help | 18:44 |
| jam | but I know there is a fair amount of 'chaining' (some get X, some get X & Y, some get XYZ, etc) | 18:44 |
| jam | at least the tests are reasonably fast :) | 18:45 |
| jam | (without pycurl, 414 tests in 14s) | 18:45 |
| vila | nah, split extract the relevant tests for each kind of parametrization, there are several layers but roughly that's pycurl/urllib http-1.0/1.1 then there are the various auth ones... hmm, yeah 2.000 lines already, wow I didn't realize that... | 18:45 |
| vila | jam: hehe, and there are some TODO at the top of the file :) | 18:47 |
| jam | well at a minimum it should have a 'per_' in the name | 18:47 |
| jam | since that is how we identify interface testing | 18:47 |
| vila | yup | 18:47 |
| vila | I'm about to finish, can you copy/paste all of that in the review or should I search my log tomorrow ? | 18:48 |
| jam | vila: anyway, looks fine to land | 18:48 |
| jam | you didn't introduce the test_http bogosity (in this patch at least :) | 18:48 |
| jam | I'll file a bug | 18:48 |
| vila | hehe not in this patch, but I'm certainly responsible for load_tests() there :-) | 18:48 |
| jam | *dammit* | 18:49 |
| vila | and I keep using it as the most complex parametrization function to copy from :-) | 18:49 |
| jam | hit ^L to go to the URL bar in Firefox, but was in Pidgin so it destroyed my backlog | 18:49 |
| vila | AAArgh | 18:49 |
| jam | *me* really doesn't like ^L in pidgin | 18:49 |
| jam | (used to bite me a lot more when I had to hit ^L in gvim to refresh because of display bugs) | 18:50 |
| vila | remind me of C-w closing windows instead of cutting the selection :-/ | 18:50 |
| jam | vila: do you know how often irclogs.ubuntu.com updates? | 18:51 |
| vila | no, but I'd say hourly | 18:51 |
| jam | http://irclogs.ubuntu.com/2010/06/23/%23bzr.txt is missing the last hour or 2 | 18:51 |
| exarkun | I did another commit, then a record, then a push. But it made no difference. :/ | 18:52 |
| vila | jam: http://paste.ubuntu.com/454047/ is that enough ? | 18:53 |
| jam | I think bug 597791 is a reasonable summary without it | 18:53 |
| ubot5 | Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed] https://launchpad.net/bugs/597791 | 18:54 |
| jam | I don't really like the summary line, but meh | 18:54 |
| jam | vila: what is your merge proposal page | 18:54 |
| vila | which one ? >-/ | 18:55 |
| jam | found it | 18:56 |
| jam | https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28315 | 18:56 |
| jam | anyway, | 18:56 |
| jam | BB:tweak | 18:56 |
| jam | needs osutils fixed, but everything else looks ok | 18:56 |
| jam | vila: so reading through http://irclogs.ubuntu.com/2010/06/18/%23bzr.html | 18:59 |
| jam | there is, indeed, a small whole that lifeless is correct about | 18:59 |
| jam | however | 18:59 |
| jam | it is a fairly small edge case, in that the chance of landing something that requires no actual changes years after it was originally done is small (but not 0) | 19:00 |
| jam | a bigger issue | 19:00 |
| jam | is that he seems to feel that if he didn't get the copyright line correct, then I shouldn't make it correct | 19:00 |
| jam | and I disagree | 19:00 |
| jam | and changing that line requires *someone* to commit a change | 19:00 |
| jam | which affects that line | 19:00 |
| jam | (if you base it purely on the history of the content changes) | 19:01 |
| jam | so unless you update the plugin to say "only include copyright years for file content that is not in a comment" | 19:01 |
| jam | or some other such thing, I think it is a rather good approximation of correctness | 19:01 |
| jam | which is *far* better than what we have done manually | 19:02 |
| jam | (so yes, it may get some edge cases wrong, we currently get the *bulk* of cases wrong doing it manually) | 19:02 |
| jam | ugh, lifeless is not logged in to read this in his backlog | 19:05 |
| vila | right, I think the issue was about me asking to install it on pqm which was a bit too much :) | 19:08 |
| jam | vila: I disagree, and I'm posting to the mailing list about it | 19:08 |
| vila | I'm off now, it's way too late and family is waiting, see you | 19:08 |
| vila | jam: cool | 19:08 |
| jam | Peng: any chance you could help me a bit with bug #441125? | 19:26 |
| ubot5 | Launchpad bug 441125 in Bazaar "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq') (affected: 1, heat: 15)" [High,Confirmed] https://launchpad.net/bugs/441125 | 19:26 |
| maxb | What could possibly cause a pack to be in obsolete_packs but still listed in pack-names? | 20:29 |
| jelmer | maxb: XFS? | 20:31 |
| jelmer | maxb: (just guessing) | 20:32 |
| maxb | ... on launchpad | 20:32 |
| jelmer | no idea in that case | 20:32 |
| jam | maxb: there were some bugs about concurrent updates and autopacking, etc. The ones I know of were fixed, and I didn't think they included that failure | 20:59 |
| jelmer | 'evening jam | 21:00 |
| jam | maxb: http://tinyurl.com/27nb3jj | 21:01 |
| jam | is a search on Launchpad that might help | 21:01 |
| poolie | good morning | 23:40 |
| * jelmer waves | 23:43 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!