| Noldorin | jelmer, doesn't like the upgrade :-( | 00:07 |
|---|---|---|
| jelmer_ | Noldorin, which upgrade? | 00:07 |
| Noldorin | jelmer, to newest bzr-git/dulwich | 00:07 |
| Noldorin | Unable to load plugin u'git' from u'C:/Program Files (x86)/Bazaar/plugins' | 00:07 |
| Noldorin | bzr: ERROR: exceptions.KeyError: "Key 'git' already registered" | 00:07 |
| jelmer_ | Noldorin, the bzr log file should have more information | 00:08 |
| Noldorin | oh wait; randomly working now hmm | 00:09 |
| Noldorin | bzr doesn't like symlinks in program files :O | 00:09 |
| Noldorin | jelmer, so a bit more playing around seems to reveal that this problem is due to the fact parent directories are not actually created (added to the git database?) before they get used | 00:12 |
| fullermd | git doesn't track directories period, neh? | 00:13 |
| Noldorin | fullermd, hmm, maybe that's the problem then? | 00:14 |
| Kamping_Kaiser | no it doesn't | 00:14 |
| fullermd | Noldorin: With git? One of them anyway ;) | 00:15 |
| Noldorin | fullermd, no with this bug jelmer and i are discussing about bzr-git :-) | 00:15 |
| Noldorin | fullermd, though i agree, it's a problem with git too hah | 00:15 |
| Noldorin | jelmer, thoughts? | 00:17 |
| jelmer_ | Noldorin, I'm looking | 00:20 |
| Noldorin | ok :-) | 00:20 |
| Noldorin | right, so it's definitely one of the renames into tests/ failing... | 00:33 |
| Noldorin | *continues debugging* | 00:34 |
| * jelmer_ writes a testcase | 00:35 | |
| yshavit | hi alll, I'm trying to use bzrlib (from python), but I keep getting an unsupported protocol exception. I'm using the remote_branch_url example from http://wiki.bazaar.canonical.com/BzrLib, straight copy-paste. bzrlib.version_info=(2, 4, 0, 'final', 0). Any ideas? | 00:44 |
| Noldorin | jelmer_, the minimal mergeset that creates the issue is tests/IrcDotNet/ and tests/TraceAndTestImpactSettings.tracesettings | 00:46 |
| Noldorin | there are probably other equivalent minimals | 00:46 |
| jelmer_ | yshavit: that example lacks this code: "from bzrlib.plugin import load_plugins; load_plugins()" | 00:47 |
| jelmer_ | Noldorin, thanks | 00:48 |
| yshavit | jelmer_: thanks! is there someone I should email about that? | 00:48 |
| jelmer_ | yshavit, I'm updating the page | 00:49 |
| yshavit | jelmer_: even better. Thanks for the quick help. | 00:50 |
| Noldorin | jelmer, sure. just some more playing around tells me (and trying to create new test branches which i dpush) that it's a highly order-dependent issue | 00:50 |
| Noldorin | jelmer, if you're digging through the code right now, i'll be here ready to assist :-) | 00:51 |
| Noldorin | (just not sure if there's much more i can do by *myself*) | 00:51 |
| jelmer_ | Noldorin, thanks | 00:55 |
| Noldorin | jelmer, will be here watching TV for the next 2 hours about, so feel free to ping me with progress at any time then | 00:56 |
| jelmer_ | heh, ok | 00:56 |
| jelmer_ | I might get some sleep soon and look closer into this tomorrow | 00:56 |
| Noldorin | jelmer, heh okay, sure. i will be around tomorrow too | 00:57 |
| Noldorin | we are both in European time zones i suppose? | 00:57 |
| yshavit | jelmer_: is there any page that's somewhere between that front page and the autogenerated pydocs? A tutorial-type thing? I can't find one on google. | 00:58 |
| jelmer_ | yshavit, for the API? Not really. I generally just look at the tests in bzr itself for inspiration | 00:59 |
| jelmer_ | what are you trying to do? | 00:59 |
| yshavit | jelmer: ah, okay | 00:59 |
| yshavit | jelmer_: for now, just merge. I've got the branch branched locally (through bzrlib) | 00:59 |
| yshavit | jelmer_: but in the larger scope, I'm also trying to teach myself how to fish :) | 01:00 |
| Noldorin | jelmer, well, feel free to ping me tomorrow after about 1pm, if that works for you better... | 01:12 |
| poolie | hi all | 05:12 |
| === maxb_ is now known as maxb | ||
| poolie | hi vila | 06:10 |
| vila | hey poolie, hi all :) | 06:22 |
| vila | jelmer: do we need to follow https://wiki.ubuntu.com/FreezeExceptionProcess for 2.4.1 on oneiric or is there some shortcut since we don't " introduce a new upstream version with new features and/or ABI/API changes" ? | 06:31 |
| poolie | <jelmer> zzzzzz | 06:31 |
| poolie | ;) | 06:31 |
| vila | :) | 06:31 |
| vila | jelmer, poolie: I think we qualify for "FeatureFreeze for bugfix-only updates" which says "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it." | 06:33 |
| vila | poolie: by the way, can *you* upload ? | 06:33 |
| poolie | i probably can, yes | 06:33 |
| poolie | since you said it was already up i just wanted to understand the situation | 06:33 |
| vila | that was a rhetoric question, AIUI jelmer should already have the branch/package ready for that | 06:34 |
| poolie | i'm not sure if it's more appropriate to request a sync or to merge and upload | 06:34 |
| poolie | ok | 06:34 |
| vila | poolie: justasec, searching the IRC log | 06:34 |
| vila | of course xchat history threshold is just where it shouldn't | 06:35 |
| poolie | vila, so that "biweekly meetings" thread is quite relevant to our discussion last night | 06:35 |
| vila | Sep 13 17:30:51 <jelmer>vila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building.. | 06:36 |
| poolie | oh ok, cool | 06:36 |
| vila | poolie: which thread ?!?!?! | 06:36 |
| poolie | on udd | 06:37 |
| poolie | you are subscribed? | 06:37 |
| vila | AFAIK, yes | 06:37 |
| vila | ubuntu-devel@lists.u.c right ? | 06:38 |
| poolie | no, https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel | 06:38 |
| vila | right, both end up in the same mailbox here | 06:39 |
| poolie | ok | 06:40 |
| vila | ... wth, I have a filter for it but I'm not subscribed ??? | 06:40 |
| poolie | vila, i wouldn't say bug 849715 is a really high priority unless it's trivial | 06:41 |
| vila | damn, yes I am subscribed | 06:41 |
| ubot5 | Launchpad bug 849715 in bzr Upload plugin "fails when upload_location becomes unreachable and doesn't provide an escape path" [High,Confirmed] https://launchpad.net/bugs/849715 | 06:41 |
| poolie | classic case of of course per-project priority vs team priority | 06:41 |
| vila | poolie: high in the plugin context and yes it's trivial | 06:41 |
| vila | I agree it's not high in the team context | 06:42 |
| poolie | so you've got it? | 06:42 |
| poolie | i mean, got the mail from the udd list? | 06:42 |
| vila | yup | 06:42 |
| vila | marked as read | 06:42 |
| vila | except for james's one which I didn't recognize as matching your reference | 06:43 |
| vila | ok, read, I see your point, and I can only repeat that having goals bigger than bugs but smaller than strategic goals will help | 06:44 |
| vila | huh, did james_w moved from UTC+1 tz to UTC-4 tz ? | 06:46 |
| bradm | hi | 06:48 |
| poolie | yes, to canada | 06:48 |
| bradm | so, bug#788072 | 06:48 |
| bradm | we've got two servers being bitten by it now | 06:49 |
| poolie | bradm, does it consistently fail? | 06:49 |
| vila | oooooh | 06:49 |
| poolie | did something on this machine change when it started happeing? | 06:49 |
| bradm | poolie: seems to be consistent | 06:49 |
| bradm | I can't say if anything changed, its a lp builder so I don't know what else has been going on | 06:50 |
| vila | bug #788072 | 06:50 |
| ubot5 | Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,Incomplete] https://launchpad.net/bugs/788072 | 06:50 |
| bradm | there's been general package upgrades, I don't usually use these machines all that often so I can't say when it started | 06:50 |
| poolie | how urgent is it to fix this? | 06:50 |
| poolie | we could change it so that it at least doesn't mask the error | 06:50 |
| poolie | if we try a fix, would you be able to run bzr eg from a branch to see if it fails the same way | 06:51 |
| bradm | I think its breaking our use of puppet on the boxes, since we've got etc in bzr | 06:51 |
| poolie | for that matter, can you see if it works the same way with the latest bzr 2.3 from the ppa? | 06:51 |
| bradm | I can certainly try some stuff | 06:51 |
| vila | bradm: AIUI, we have never been able to reproduce it and my last debug attempts with lamont pretty much convinced me it was a weird local install issue | 06:52 |
| poolie | vila, in the standup yesterday you said something about making udd robust about lp downtime | 06:53 |
| bradm | vila: fwiw, I don't know if we can rule that out, since these are both lp buildds, its possible there's something local | 06:53 |
| vila | poolie: yup, that's my targets for today | 06:53 |
| poolie | i guess that's https://bugs.launchpad.net/udd/+bug/795321 assigned to jr, not obviously started | 06:53 |
| ubot5 | Ubuntu bug 795321 in Launchpad itself "udd importer should make tea while launchpad is down" [High,Triaged] | 06:53 |
| vila | bradm: oh, new context then ! Can you add that to the bug ? | 06:53 |
| vila | poolie: yup | 06:53 |
| poolie | i'm not sure that increasing the parallelism is all that important at the moment compared to some specific failures | 06:54 |
| bradm | this is interesting, one of them is bzr 3.2.1 | 06:54 |
| bradm | er, 2.3.1 even | 06:54 |
| bradm | silly fingers | 06:54 |
| vila | poolie: you mean bug #724893 ? | 06:55 |
| ubot5 | Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893 | 06:55 |
| bradm | and the other is 2.3.3 | 06:55 |
| vila | poolie: the issue here is not to increase parallelism but that this bug can happen *now* triggered by any tweak anywhere | 06:55 |
| poolie | ok | 06:56 |
| poolie | does that show up as an actual import failure? | 06:56 |
| poolie | if so we should be able to measure how many suffer from it | 06:56 |
| vila | poolie: what ? bug #724893 ? | 06:56 |
| ubot5 | Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Critical,Confirmed] https://launchpad.net/bugs/724893 | 06:56 |
| poolie | yes, that | 06:56 |
| jam | morning all | 06:57 |
| vila | poolie: it's not package specific at all, it's a bug in the design and we are lucky that it doesn't trigger more often | 06:57 |
| poolie | let's finish with bradm first | 06:57 |
| poolie | bradm, that's worth adding too | 06:57 |
| poolie | so the short story is, if we have something we think will help, you can deploy and test it? | 06:57 |
| bradm | poolie: I'd say so, given that the existing bzr stuff is busted | 06:57 |
| poolie | ok | 06:58 |
| poolie | i assigned it to the team | 06:58 |
| poolie | hi jam | 06:58 |
| bradm | just added a comment about the 2nd server and them being lp buildds | 06:59 |
| poolie | vila, i know it's not caused by the particular package, but my question is whether the import logs will tell us how often it occurs | 06:59 |
| poolie | if it's not actually often, it doesn't need to be critical | 06:59 |
| vila | ok, I resign, downgrade it to low if you wish, the day we'll encounter it because some totally unrelated optimization make the imports faster... we'll marked it critical | 07:00 |
| poolie | i'm just trying to understand the situation | 07:01 |
| vila | poolie: both mass_import and import_package want to update a db, as of today, there is no contention because imports are slow enough | 07:02 |
| vila | increasing parallelism (as I did as an experiment) revealed the bug and made it obvious | 07:02 |
| vila | but the bug is there nevertheless | 07:02 |
| jam | My 2c, if we don't have to stop everything and work on it, it isn't "Critical", it can be "High", it can be in our "bugs to work on next" list, but that doesn't make it *Critical*. | 07:03 |
| vila | I don't think we still have the logs for the last debian massive import where this occured | 07:03 |
| jam | I don't think anyone has said it isn't a bug | 07:03 |
| jam | or worth fixing, etc. | 07:03 |
| vila | jam: you already said that in the comment and I disagreed and still do | 07:04 |
| jam | vila: then why aren't you working on it *right now*, if it is critical | 07:04 |
| jam | ? | 07:04 |
| poolie | vila, jam said what? | 07:04 |
| jam | If *you* feel it is critical, then certainly it should trump the config stuff you are doing, etc. | 07:04 |
| jam | poolie: I said I didn't feel the bug was "Critical" | 07:04 |
| jam | vila: I'm not trying to start the argument again. But that is what Critical is supposed to mean. At least in my understanding. | 07:05 |
| jam | "This bug should be fixed before all High priority bugs" | 07:05 |
| poolie | jam, that is what critical ought to mean | 07:05 |
| poolie | in fact "even ahead of other work that's already in progress" | 07:05 |
| vila | to me it means a bug that can break the whole package importer | 07:05 |
| poolie | we haven't always been great about doing it but we shouldn't dilute it ay further | 07:05 |
| vila | and that needs to be fixed to resurrect it | 07:05 |
| bradm | poolie: anyway, let me know if you need any more info, or have something for us to try | 07:09 |
| vila | jam: I didn't start working on it because: 1) you pointed me to wal which is more complicated than a file-based locking, 2) as mentioned repeatedly this doesn't occur *yet* and I see nothing in the pipe that will trigger it (once 2.4 (and its optimizations) is deployed on jubany, I may reconsider) | 07:10 |
| poolie | bradm, ok, i will, i'm not personally going to start on it now | 07:11 |
| poolie | vila, il'l see if i can get your config things unblocked soon | 07:11 |
| bradm | poolie: no worries | 07:11 |
| poolie | oneiric's borked, biab | 07:11 |
| vila | jam: I'd appreciate if you could make more constructive suggestions about config instead of considering a pet project, there are numerous, real and deep issues around this area | 07:11 |
| bradm | poolie: looks like this bug has been around for a bit and it seems to only be hitting 2 servers, so its not ultra high priority | 07:13 |
| poolie | ok | 07:13 |
| poolie | it would be nice to know why only those two | 07:13 |
| poolie | if you know when the problem started perhaps you can attach the dpkg.log | 07:13 |
| bradm | poolie: the server I'm seeing started within the last day or so I'm guessing from some puppet stuff | 07:15 |
| bradm | poolie: but the last thing in dpkg.log was apache stuff about 2 weeks ago | 07:16 |
| poolie | halp! puppet! | 07:16 |
| vila | bradm: why are those builds still using bzr < 2.3.4 (not strictly related but well, who knows, may be some upgrade went wrong) | 07:16 |
| bradm | vila: I don't know, but they're fully up to date according to the current sources.list on them | 07:17 |
| vila | bradm: 8-/ no -updates there ? | 07:17 |
| bradm | another random lp buildd has 2.3.1 as well | 07:18 |
| vila | err wait, what ubuntu release are they based on ? | 07:18 |
| bradm | vila: hardy | 07:18 |
| vila | ha, ok, thanks | 07:18 |
| vila | hmm, I think jelmer has backported 2.4 for hardy-cat recently | 07:19 |
| bradm | these definately have hardy-cat on them | 07:19 |
| vila | or is it jelmer_ :) | 07:19 |
| bradm | interesting, and hardy-cat-buildd | 07:19 |
| vila | dunno about that last one but I'm pretty sure jelmer is already trying to address some buildd issues so I think he targeted the right one | 07:20 |
| bradm | vila: if there is a hardy-cat versoin of 2.4 its not on our servers | 07:20 |
| bradm | vila: I do see lucid-cat 2.4 | 07:20 |
| vila | bradm: https://launchpad.net/~canonical-bazaar/+archive/cat-proposed IIUC | 07:21 |
| bradm | vila: interesting - I don't know the mechanics by which that makes it into our hardy-cat suites, lamont would know more I'd say | 07:22 |
| vila | right, so let's postpone that part of the discussion for when jelmer and lamont are around | 07:23 |
| bradm | for sure | 07:23 |
| bradm | I'm just a lowly GSA seeing a problem on one server ;) | 07:23 |
| vila | bradm: sure, thanks for chiming in here | 07:23 |
| bradm | no worries, let me know if you need more info or anything | 07:24 |
| vila | bradm: do you have a direct access to one of the failing servers to try some diagnosis ? | 07:24 |
| bradm | vila: sure | 07:24 |
| bradm | vila: I'll be EODing shortly, but I can do some stuff | 07:24 |
| vila | bradm: no problem, start reading the comments in bug #788072 and see if you can follow the proposed steps starting in comment #2 | 07:25 |
| ubot5 | Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Medium,Confirmed] https://launchpad.net/bugs/788072 | 07:25 |
| bradm | vila: BZR_PDB=1 bzr st looks the same as bzr st | 07:27 |
| vila | bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH | 07:27 |
| bradm | vila: I can't get anything from bzr version or bzr plugins -v other than the error | 07:27 |
| vila | good, you're in the right context then (hopefully) | 07:28 |
| vila | bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH | 07:28 |
| vila | bradm: python -V (just to be sure) | 07:28 |
| bradm | $ python -V | 07:29 |
| bradm | Python 2.5.2 | 07:29 |
| vila | ok | 07:29 |
| vila | bradm: and the python import above ? | 07:29 |
| bradm | $ PYTHONPATH=/var/lib/python-support/python2.5 python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' | 07:30 |
| bradm | /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so | 07:30 |
| * vila blinks | 07:30 | |
| vila | and if you remove the PYTHONPATH ? | 07:30 |
| bradm | $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' | 07:30 |
| bradm | Traceback (most recent call last): | 07:30 |
| bradm | File "<string>", line 1, in <module> | 07:30 |
| bradm | ImportError: No module named _chunks_to_lines_pyx | 07:30 |
| bradm | $ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' | 07:30 |
| bradm | Traceback (most recent call last): | 07:30 |
| bradm | File "<string>", line 1, in <module> | 07:31 |
| bradm | ImportError: No module named _chunks_to_lines_pyx | 07:31 |
| vila | that's the issue, the install is broken | 07:31 |
| vila | well | 07:31 |
| vila | the install and the context are not what bzr is expected may be more accurate and less offensive ;) | 07:31 |
| bradm | awesome, I can poke some other servers to see the difference tomorrow | 07:32 |
| vila | bradm: find / -name _chunks_to_lines_pyx.so -print ? Or something equivalent | 07:32 |
| vila | bradm: but if you can relate this missing files with failing servers, yeah, that would narrow down the problem space | 07:32 |
| bradm | $ sudo find / -name _chunks_to_lines_pyx.so -print | 07:33 |
| bradm | /var/lib/python-support/python2.4/bzrlib/_chunks_to_lines_pyx.so | 07:33 |
| bradm | /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so | 07:33 |
| bradm | /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so | 07:33 |
| bradm | /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so | 07:33 |
| bradm | interesting, similar on another working server except it doesn't have a /var/lib/python-support/python2.4/bzrlib | 07:34 |
| vila | if it has python-2.5 we don't care | 07:34 |
| bradm | right, since we're using python 2.5 | 07:34 |
| vila | but the /var/lib/python-support part... I'm not sure we ever search there, let me check | 07:34 |
| bradm | oho, interesting | 07:35 |
| bradm | on a working server: | 07:36 |
| bradm | $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' | 07:36 |
| bradm | /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so | 07:36 |
| vila | python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()' | 07:36 |
| bradm | $ python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()' | 07:36 |
| bradm | /usr/lib/python2.5/site-packages | 07:36 |
| bradm | same on a working system | 07:37 |
| vila | on a failing server ? ha, rats | 07:37 |
| bradm | okey, I've got a 4 year old boy wanting some attention, I'll have to take this up again tomorrow | 07:38 |
| vila | bradm: ok, no worries, that may be something in this area, some missing symlink here or there, hard to guess | 07:38 |
| vila | bradm: take care of your boy :) | 07:39 |
| bradm | vila: will do - thanks for the help, its given me somewhere to look :) | 07:39 |
| poolie | vila, i'm reading the stacks patch now | 07:41 |
| vila | poolie: \o/ | 07:44 |
| poolie | vila, i answered | 08:08 |
| poolie | can you tell me: why a registry? | 08:08 |
| vila | poolie: 1) you asked for it :) 2) it simplifies many issues including centralizing the way to get a stack, overriding by a plugin, etc | 08:10 |
| vila | it doesn't address (yet) more convenient ways to build stacks (more on that soon, but roughly a stack is already a list of tuples (store, section_matcher(context)) plus one optional mutable store, to reach one read/write by store we need to centralize the way stores are acquired so they can be shared, the stack registry is a first step | 08:12 |
| vila | poolie: i.e. it's harder to track all stores if everybody build stacks at call sites instead of using a registry | 08:12 |
| vila | poolie: we've been there (no registry) in other areas and always ended up fixing the issues by introducing a registry, | 08:13 |
| vila | the only exception I can think of is transports but we already encountered issues that a registry could address (replacing or behind transport.get_transport) | 08:14 |
| poolie | why is a registry better for that than just having named functions? | 08:18 |
| vila | poolie: because we all agree it was better when we start using registries ? | 08:19 |
| vila | started | 08:20 |
| poolie | uh | 08:20 |
| poolie | i don't think it's just universally better | 08:20 |
| poolie | it solves some particular problems | 08:20 |
| poolie | it's not obvious to me those problems exist in this case | 08:20 |
| poolie | i don't think people ought to build the stacks inline, but the simplest solution to that seems to be to have functions that build them | 08:21 |
| poolie | vila? | 08:24 |
| vila | poolie: searching the relevant mp | 08:24 |
| poolie | i need to stop soon | 08:27 |
| poolie | can we just talk? | 08:27 |
| vila | ok | 08:28 |
| poolie | here is fine | 08:28 |
| vila | I can't find it back, but *I* don't care about whether we use a registry or named functions at this point, I seem to recall that you suggested a registry for stacks in some discussion so I took that route | 08:29 |
| mwhudson | does accessing branches with bzr+ssh://user:pass@host/ type urls work in the way one might hope? | 08:29 |
| === lool- is now known as lool | ||
| vila | along this route I indeed found that a registry was addressing some issues so I followed up on this route | 08:30 |
| vila | from a pure syntactic point of view, as explained in the cover letter, this makes sense too, | 08:31 |
| vila | so this proposal is only about introducing the registry | 08:31 |
| vila | it doesn't show *how* it helps addressing the other issues to keep it small | 08:32 |
| poolie | ok | 08:32 |
| poolie | what are the issues? | 08:32 |
| jam | mwhudson: yes | 08:33 |
| vila | single point of access to control which stack is returned for a single context (this became a blocker when jelmer mentioned that subversion.conf was already implementing some additional feature that requires more flexibility when building branch stacks) | 08:33 |
| vila | this can addressed differently but since this is now needed *and* that a stack registry provides *one* way to address it, I just went ahead | 08:34 |
| vila | s/can/can be/ | 08:34 |
| mwhudson | jam: thanks | 08:34 |
| vila | single point of access to control which stores are used so they can be shared, | 08:34 |
| jam | mwhudson: of course, it leaves your password in bash history, kills babies, etc. :) | 08:35 |
| mwhudson | jam: yeah yeay | 08:35 |
| poolie | is this to say that bzr-svn wants to hook into the creation of some stacks? | 08:35 |
| vila | yes | 08:35 |
| mwhudson | jam: you can use authorization.conf too right? | 08:35 |
| jam | mwhudson: You might look at authentication.conf, but I'm pretty sure it doesn't support passwords for ssh | 08:35 |
| poolie | so one other possible way to do this would be for it to override Branch.get_config? | 08:35 |
| jam | since we figure "you already have ssh/config to set up a key" | 08:35 |
| jam | which is more secure anyway | 08:35 |
| vila | otherwise migrating the branch options to the new config scheme will break the UUID default values for options | 08:35 |
| mwhudson | jam: is there a chance that a user:pass in a url might end up in a traceback or other console output? | 08:36 |
| mwhudson | jam: presumably that's fixable though | 08:36 |
| jam | mwhudson: I *believe* we are good about omitting :pass from anything we log | 08:36 |
| vila | poolie: yes, but that makes it harder to migrate the options | 08:36 |
| vila | poolie: and also harder to control which stores are used | 08:36 |
| jam | mwhudson: http://paste.ubuntu.com/688966/ | 08:37 |
| jam | "does not appear in base" means it doesn't show up in stuff like tracebacks | 08:37 |
| mwhudson | jam: ah nice | 08:37 |
| jam | we strip it from the URL, and then hide it around as necessary | 08:38 |
| vila | poolie: s/harder/different/ if you prefer but the proposal is an incremental progress in *one* direction | 08:38 |
| poolie | wull | 08:39 |
| poolie | *well, it's adding some complexity | 08:39 |
| vila | which one ? | 08:39 |
| poolie | it's reasonable to ask why it's there | 08:39 |
| vila | for who ? | 08:39 |
| poolie | adding a registry rather than just having functions | 08:40 |
| poolie | so the point of a registry is, in short, so that plugins can control how stacks are created for some particular purposes? | 08:40 |
| vila | but you objected (rightly) that these functions are not good examples of how to build stacks and indeed they don't address the issues I mentioned above | 08:41 |
| poolie | which issues? | 08:41 |
| vila | taking command line overrides into account needs a central place, not requiring eveybody to modify these functions | 08:41 |
| vila | "which issues?" : overriding by plugins, centralizing store access | 08:42 |
| poolie | couldn't handling command line options be done by just saying there's a global stack, which most others build upon, that includes per-command options? | 08:43 |
| vila | I never talked about per-command options, | 08:44 |
| poolie | i meant per-process | 08:44 |
| poolie | command line overides | 08:44 |
| vila | can you elaborate about build upon > | 08:44 |
| vila | can you elaborate about build upon ? | 08:44 |
| vila | to me it means having helpers to create the appropriate list of (stores, section_matcher(context)) | 08:45 |
| poolie | basically just that branch_stack() should return stack(BranchStore(branch), LocationStore(), global_stack()) | 08:45 |
| vila | and one central place to ensure the command-line overrides always dominate | 08:45 |
| poolie | then global_stack can include system-wide, per-user, and command-line parts | 08:46 |
| vila | wrong | 08:46 |
| vila | command-line overrides should come first | 08:46 |
| poolie | ok, i see | 08:46 |
| poolie | that's true | 08:46 |
| poolie | how does a registry help with this? | 08:46 |
| vila | or do you want stacks to be able to be build recursively ? | 08:46 |
| vila | it provides this central point | 08:46 |
| vila | place | 08:46 |
| poolie | but how is it more central than the config module holding some functions? | 08:47 |
| vila | (I think recursive stacks are neat, but introduce complexity for users as well as devs so I'm more against than for) | 08:48 |
| vila | some functions all implementing the same rules ? | 08:48 |
| vila | but, it's not *more* central, it's just *as* central | 08:49 |
| vila | and again, it's just one way, there are others, this one just seem to be the easiest and fastest... | 08:49 |
| _arch | Hi | 08:49 |
| vila | poolie: what is this added complexity you're seeing there ? | 08:50 |
| vila | even get_config() or get_config_stack() are still possible, they are just implemented by querying the registry, | 08:50 |
| vila | how is that complex ? | 08:50 |
| poolie | it's basically just one more level of indirection to go through the registry | 08:50 |
| poolie | it's not enormously complex, i just don't think you're communicating why it's helpful | 08:51 |
| poolie | it's not obvious to me how it's going to help with plugins | 08:51 |
| poolie | i assume the point of having it is to enable things from plugins? | 08:51 |
| poolie | perhaps one way to move this along would be for you to give some illustrative cases of what plugins want to do with this and how they would do it through the registry? | 08:52 |
| _arch | I have a problem: During commit, I want to inject my new revision number to each modified file | 08:53 |
| poolie | hi _arch, you want http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html | 08:53 |
| _arch | I checked that out but I'm not sure if it helps. The $Revision-Id$ has a bunch of stuff I don't want apparently. | 08:53 |
| vila | poolie: how will plugins implement command-line overrides ? | 08:54 |
| poolie | vila i'd probably just do that in the core | 08:54 |
| vila | poolie: do you want them to explicitly change their stack builder ? | 08:54 |
| vila | poolie: but how will they get the feature from the core ? | 08:55 |
| _arch | So I figured I'll try to write a quick start_commit hook myself which injects the revno to the modified files | 08:55 |
| vila | poolie: how would you output the help associated with a stack ? | 08:55 |
| _arch | however I seem to have absolutely no clue of where to begin :) | 08:55 |
| vila | poolie: how would support the plugin specific configs with 'bzr config' ? | 08:55 |
| poolie | vila, i'm interested in the answers but i'm also suggesting that if in future you explain some cases like this in the mp, it might be better understood | 08:55 |
| vila | that doesn't match my understanding of small piece easy to propose :-/ | 08:56 |
| poolie | " but how will they get the feature from the core ?" - i'm not sure what you mean, but if you mean "how will they see values from the command line", i'd expect that all of the *_stack() functions will return a stack that looks at the command line | 08:57 |
| vila | I'm not addressing rewriting 'bzr config' for now | 08:57 |
| vila | poolie: indeed, that puts the responsibility on the plugin authors | 08:57 |
| poolie | i'm not sure if there needs to be help for a stack or whether that needs to be exposed to the user as such | 08:57 |
| vila | you should do this and this and don't forget this, instead of: register your stack | 08:57 |
| poolie | i would not expect it needs any plugin changes | 08:57 |
| vila | ... | 08:58 |
| poolie | " doesn't match my understanding of small piece easy to propose "-- i think generally, saying "previously, you couldn't do X. now, it works like so" is pretty helpful to establishing the change is worthwhile | 08:58 |
| poolie | that can be either in the mp or in a bug | 08:58 |
| vila | but we have no idea today that plugins implement config files, nor do we have any way to know they do | 08:58 |
| poolie | _arch, are you saying the problem is that bzr-keywords just puts in too much text? like the revision id and you just want the number? | 09:00 |
| _arch | yeah | 09:00 |
| poolie | maybe then the easiest thing is to just add another option to bzr-keywords? | 09:00 |
| poolie | you should be able to just go off the existing code | 09:00 |
| _arch | Hmm, true. I'll check that out, thanks | 09:01 |
| poolie | if you fix it, please push up a branch so we can merge it | 09:01 |
| poolie | ask here if you need any help | 09:01 |
| poolie | vila, that might be true we don't know whether plugins are looking at config files but i don't see why it's actually a problem | 09:01 |
| _arch | Right I'll check out the source and see if I can make something out of it. | 09:01 |
| vila | poolie: no, I said *we* don't know that plugins use their own config files and/or if they introduce new features for our own config files | 09:02 |
| poolie | ok | 09:03 |
| poolie | is this a bug? | 09:03 |
| vila | and if jelmer didn't mention that subversion.conf use [UUID] sections I would have break it by migrating the branch options | 09:03 |
| vila | bug #832036 | 09:03 |
| ubot5 | Launchpad bug 832036 in Bazaar "Needs a config stack registry" [High,In progress] https://launchpad.net/bugs/832036 | 09:03 |
| vila | we're running into circles | 09:04 |
| poolie | yeah, but that's basically the same problem | 09:04 |
| poolie | that bug does not describe an actual problem | 09:04 |
| vila | ok, we don't have problems | 09:04 |
| vila | better un-migrate the global options and forget about that | 09:05 |
| poolie | is that sarcasm? | 09:05 |
| vila | obviously I'm not able to explain the issues in a way we can agree upon | 09:06 |
| poolie | :/ | 09:06 |
| poolie | sorry | 09:06 |
| vila | no, it's just that I suck at this particular point and therefore cannot progress, so it's wasted time | 09:07 |
| poolie | ok | 09:07 |
| poolie | let's shelve this until it's clear it's solving a pressing problem for plugins | 09:07 |
| poolie | does it block anything else? | 09:07 |
| vila | https://bugs.launchpad.net/bzr/+bugs?field.tag=config i.e. 40 bugs, plus all the ones I failed to file | 09:08 |
| poolie | i think 832036 is a good example of a bad bug, because it specifies a solution, not a problem | 09:09 |
| poolie | are you saying this blocks all those bugs? | 09:09 |
| poolie | i have some trouble believing it | 09:09 |
| vila | oh, there are surely alternate ways to address them, someone just have to analyze them and find a relevant fix | 09:10 |
| poolie | ok so of those bugs | 09:11 |
| poolie | the one i care most about is 832042 | 09:11 |
| vila | is that sarcasm ? | 09:12 |
| poolie | nup, it's true | 09:12 |
| poolie | well, more precisely | 09:12 |
| poolie | if these changes have a performance impact, i care about fixing it | 09:12 |
| vila | yes they do have one and I've added -Econfig_stats to track progress | 09:13 |
| poolie | istm an easy way to fix 832042 would be to just create the config stacks early on in the object they correspond to | 09:13 |
| poolie | the global-ish ones which have no obvious owner can go onto the library_state | 09:14 |
| vila | you need a central place to share the stores (not mentioning how it interacts with library_state) | 09:14 |
| poolie | hm | 09:17 |
| poolie | i think you can either have them on library_state, or inherited from one object to another | 09:18 |
| poolie | it seems pretty possible | 09:18 |
| poolie | i'v closed 832036 and i pushed down some of the others | 09:19 |
| vila | then we should also revert all stack related stuff or it will make it harder to address these bugs | 09:21 |
| poolie | i don't see how that really follows | 09:22 |
| poolie | i think the stacks are just fine | 09:22 |
| vila | you don't want to address sharing both stores and config files don't you ? Nor maintain both get() and get_user_option() and get_xxx APIs right ? | 09:23 |
| poolie | i don't really understand the question | 09:25 |
| poolie | i do need to stop | 09:25 |
| poolie | i'm sorry this is frustrating | 09:26 |
| vila | I mean, I don't mind getting rid of this stuff if we can't agree upon, but in this case that's a non-sense to keep it because it means we have a fragmented API and this is definitely something that makes it harder to fix the remaining bugs | 09:26 |
| poolie | if you can think more about actual "X doesn't work as it should" bugs rather than what you want to write, i think that will help communicate it | 09:26 |
| vila | that's what the devnotes doc was about :-/ | 09:27 |
| vila | ha, I have some bugs mentioned with the corresponding issues in my uncommitted version | 09:28 |
| poolie | hm, so | 09:28 |
| poolie | i can see there's something in there about plugins wanting to add new files | 09:29 |
| poolie | i think for a particular mp just pointing to configuration.txt is not enough, because the specific connection is not clear | 09:30 |
| vila | see also the part about not being able to delete some options ? | 09:30 |
| vila | or the already existing fragmentation in the API ? | 09:30 |
| poolie | i really do not see how the registry would help with deprecating options | 09:31 |
| vila | the stack registry ? unrelated, | 09:31 |
| poolie | i think if you filed a bug saying "there is no way to gracefully deprecate an option" we can agree on whether that's true, whether it's important, and then on whether a particular mp is a decent way to solve it | 09:31 |
| vila | but the option registry can be used to say one option deprecates another one (or vice versa) | 09:31 |
| poolie | right | 09:32 |
| poolie | so | 09:32 |
| vila | far from the top of my TODO list | 09:32 |
| _arch | poolie: have you used the keywords plugin? Am I supposed to add the keyword template (like, $Revision-Id$) to each of my files? | 09:32 |
| poolie | _arch, i haven't used it recently, but yes, add it where you want the text to come out | 09:32 |
| poolie | vila, ok, so, i'm -1 on the registry until the reason is clear | 09:32 |
| poolie | i think it would overall be most excited about you doing bug 795321 or maybe bug 832042 | 09:33 |
| ubot5 | Launchpad bug 795321 in Ubuntu Distributed Development "udd importer should make tea while launchpad is down" [High,In progress] https://launchpad.net/bugs/795321 | 09:33 |
| ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 09:33 |
| poolie | or bug 836782, which is just pushing #is perhaps | 09:33 |
| ubot5 | Launchpad bug 836782 in Ubuntu Distributed Development "bzr-builddeb requires dpkg-dev >= 1.15.7" [High,In progress] https://launchpad.net/bugs/836782 | 09:33 |
| poolie | or rebuilding it? | 09:33 |
| _arch | poolie: and once the file is pushed the keyword is going to be replaced by whatever it's supposed to be? i.e, in place of $Revision-Id$, there's going to be the revid? | 09:33 |
| poolie | i think it will be expanded within the keyword | 09:34 |
| poolie | ok, good night all | 09:35 |
| _arch | Right, there's something wrong then :) | 09:35 |
| _arch | thanks | 09:35 |
| Riddell | jelmer: how long does it take for a package to move from debian incoming to unstable? | 09:43 |
| jelmer | Riddell: it happens several times a day (if it doesn't have to go through NEW) | 09:45 |
| Riddell | hmm those bzr packages are still there (according to the incoming.d.o and packages.d.o websites) | 09:45 |
| jelmer | Riddell: http://packages.debian.org/sid/bzr-explorer already has 1.2.1-1 | 09:46 |
| Riddell | you're right, http://packages.debian.org/search?keywords=bzr-explorer is slacking | 09:47 |
| Riddell | or maybe it's my browser cache | 09:47 |
| Riddell | weird | 09:47 |
| Riddell | jelmer: I'll sync bzr-explorer and qbzr, and make the necessary changes to bzr to upload that | 09:50 |
| jelmer | Riddell: I was about to do an upload of bzr to oneiric too | 09:51 |
| Riddell | go ahead then | 09:52 |
| Riddell | jelmer: | 09:53 |
| jelmer | Riddell: thanks | 09:54 |
| Riddell | is there a reason why printing text in builting.py is often done with self.outf.write() rather than note() ? | 09:57 |
| vila | Riddell: the FIXME in trace.note are probably part of the answer | 10:33 |
| * Riddell discovers bzr rocks | 10:50 | |
| Riddell | that'll keep our translators amused finding suitable localised equivalents :) | 10:51 |
| jam | Riddell: self.outf.write goes to stdout and is in terminal encoding. note() I think goes to stderr and is officially UTF-8 encoded. Further note() also goes to .bzr.log | 11:08 |
| Riddell | hmm, so use of note() in commands might break if you're not using a utf-8 language? | 11:18 |
| Riddell | what is the "cannot import name info" message I get all the time? | 11:18 |
| Riddell | oh it's a plugin at fault | 11:19 |
| jelmer | Riddell: ~/.bzr.log is your friend :) | 11:22 |
| jam | Riddell: .bzr.log and -Derror | 11:43 |
| === zyga is now known as zyga-food | ||
| jam | mgz: ping | 13:34 |
| mgz | pong-to-avoid-what-I-should-be-doing | 13:34 |
| jam | mgz: I just upgraded bzr and did "bzr st" outside of a working tree | 13:36 |
| jam | and got the giant-explosion of IndexError. | 13:36 |
| mgz | traceback in the message you just put on the lp:~gz/bzr/root_drive_file_url_841322 mp implies the branch didn't land correctly | 13:36 |
| mgz | File "C:\dev\bzr\bzr.dev\bzrlib\urlutils.py", line 391, in | 13:36 |
| mgz | _win32_extract_drive_letter | 13:36 |
| mgz | if len(path) < 3 or path[2] not in ':|' or path[3] != '/': | 13:36 |
| mgz | IndexError: string index out of range | 13:36 |
| mgz | that's still `< 3` not `< 4` | 13:36 |
| mgz | double check the branch is at the right revision? | 13:37 |
| jam | mgz: I'm at 6125.. Looks like update *didn't* | 13:38 |
| jam | bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_on | 13:38 |
| jam | ly setting on branch "C:/dev/bzr/bzr.dev/". | 13:38 |
| jam | how did we manage that? | 13:38 |
| jam | mgz: so it looks like my branch is out-of-date. | 13:39 |
| jam | Sorry for the noise. I'll poke at the other stuff | 13:39 |
| mgz | ugh, not sure, don't think I have that setting on so pull works here | 13:40 |
| jam | mgz: looks like discrepancy between PQMs | 13:41 |
| jam | specifically, 'bzr.dev's rev 6124 is now by "Patch Queue Manager" instead of "Canonical.com Patch Queue Manager" | 13:42 |
| jam | so it seems we landed (and I pulled) 2 revisions on the old PQM, which are now gone from history in the new PQM | 13:42 |
| jam | vila, poolie, jelmer: ^^ Did you see this? | 13:42 |
| jam | http://paste.ubuntu.com/689201/ | 13:43 |
| jam | I'm a little concerned that we lost revisions, but I guess if a plain "bzr pull" works, then we shouldn't have. | 13:43 |
| vila | jam: yes, mentioned a couple of days ago, occurred during the migration to the new pqm, was considered minor enough to deal with it | 13:44 |
| vila | jam: you have append_revisions_only set locally ? | 13:44 |
| vila | jam: pqm doesn't | 13:44 |
| jam | vila: Yes, I have it set here | 13:44 |
| vila | jam: again see log for discussions about why we considered not doing that | 13:45 |
| jam | that way I don't screw stuff up locally | 13:45 |
| jam | vila: irc log? | 13:45 |
| vila | yup | 13:45 |
| vila | around pqm migration, I raised the issue as soon as I discover it on bzr.dev | 13:45 |
| jam | vila: so we did already merge them into the actual trunk. I was trying to look at the changes, and didn't specifically see it. | 13:46 |
| vila | jam: yes, the first succesful submission based on the trunk pushed by the old pqm carried all the diffs | 13:47 |
| jam | vila: I'm fine with the solution, I just wanted to make sure we didn't lose anything. so good enough. | 13:48 |
| vila | jam: nothing has been lost bar the cleaner history | 13:48 |
| jam | vila: yeah. no problem. I often start my day by running "bzr up" but not actually reading the output. So I didn't see that it wasn't updating. | 13:49 |
| vila | jam: yeah, same reaction here, I even blew the whistle before checking, but I did not check very deeply given that this didn't seem necessary (I was lucky enough to do a 'bzr missing' at the right time) | 13:49 |
| jam | I did 'bzr missing' but wasn't 100% sure it wasn't lying :) | 13:49 |
| jam | mgz: so in the end, Yay for you! I don't get the traceback anymore. :) | 13:56 |
| mgz | good good :) | 13:56 |
| blackarchon | hi all! | 14:07 |
| blackarchon | I just posted bug 850004, is it maybe already solved in trunk? | 14:09 |
| ubot5 | Launchpad bug 850004 in Bazaar "Problem with non-ASCII letters" [Undecided,New] https://launchpad.net/bugs/850004 | 14:09 |
| mgz | that sounds like a bug for me. | 14:12 |
| blackarchon | 2.4.0 was entirely broken, and 2.4.1 seems also broken :( | 14:13 |
| mgz | there's nothing obviously wrong from your log or traceback | 14:14 |
| mgz | does S:/v5_x/projects/10074_YYY-Lüftersteuerung/.bzr/repository/pack-names actually exist? | 14:16 |
| mgz | and if not, which is the first parent directory that does? | 14:17 |
| blackarchon | yes, it exists | 14:17 |
| blackarchon | well the letter ü is (according to the log) sometimes coded in a wrong way, this may propably be the reason for this error | 14:18 |
| mgz | it's right in all the bits in that bug, and the error isn't related to non-ascii characters, so I think that may be a red herring | 14:19 |
| mgz | blackarchon: paste me the output of `dir S:/v5_x/projects/10074_YYY-Lüftersteuerung/.bzr/repository/pack-names` run in the cmd prompt please? | 14:20 |
| mgz | !paste | 14:20 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 14:20 |
| blackarchon | mgz: http://paste.ubuntu.com/689235/ | 14:23 |
| === zyga-food is now known as zyga | ||
| mgz | okay, fun. I'll try and repo here. | 14:24 |
| blackarchon | note I have to use \ instead of / | 14:24 |
| mgz | one last thing for you to try, run the command bzr-explorer is passing, but at the command line | 14:25 |
| blackarchon | I should run "bzr explorer S:/v5_x/projects/10074_YYY-Lüftersteuerung" on the command line? | 14:26 |
| Noldorin | hi jelmer | 14:26 |
| jelmer | hi Noldorin | 14:27 |
| Noldorin | any progress on the issue? :-) | 14:27 |
| mgz | blackarchon: so, `bzr commit -m "Vor 2. Wegschicken zu Hr. xxx" YYY-Lüftersteuerung.sch` | 14:27 |
| jelmer | Noldorin: sorry, been distracted with other things so far | 14:27 |
| Noldorin | jelmer, no prob | 14:27 |
| jelmer | it's high on my todo list though | 14:27 |
| Noldorin | jelmer, just thought i'd let you know i'm here to assist you when ready :-) | 14:27 |
| Noldorin | sure | 14:27 |
| blackarchon | mgz: If i run "bzr explorer S:/v5_x/projects/10074_YYY-Lüftersteuerung" | 14:29 |
| blackarchon | I get an error | 14:29 |
| blackarchon | unable to change to <path> - closing page | 14:30 |
| mgz | paste me that, then try the command I suggested? | 14:30 |
| blackarchon | mgz: sorry, my fault - the command was fine | 14:31 |
| blackarchon | just had a typo | 14:31 |
| mgz | I hope you're not having to retype Lüftersteuerung each time :) | 14:32 |
| blackarchon | mgz: http://paste.ubuntu.com/689241/ | 14:34 |
| mgz | interesting. do `bzr add YYY-Lüftersteuerung.sch` too? | 14:36 |
| blackarchon | why should adding a file help if it is already added? | 14:36 |
| mgz | it's not clear what the state of the branch is, it might be there really isn't anything to do. | 14:37 |
| mgz | if you were committing in bzr-explorer, and it gave you an error, I was presuming you had outstanding changes that still needed to be comitted. | 14:38 |
| blackarchon | ok - well, the problem is that committing seems to work. at the moment, I have 6 revisions in this standalone tree. But I also get these errors while committing. | 14:39 |
| mgz | that's wrong I guess, either you already did that or reverted them, or bzr left things in a funny state. | 14:39 |
| mgz | okay. | 14:40 |
| blackarchon | so it seems to do something right, but not all. | 14:40 |
| mgz | can you make a new change of some kind to that file, try the commit from the command line (you can always uncommit after trying) and see if you get the same error? | 14:40 |
| blackarchon | ok | 14:40 |
| mgz | it looks like this may just be an problem in the explorer commit reporting code. | 14:42 |
| blackarchon | this went fine without an error on the command line | 14:43 |
| mgz | great, thanks for testing all of that, will help me try and reproduce it locally. | 14:44 |
| blackarchon | but there seems to remain a little discrepancy in umlaut handling: http://paste.ubuntu.com/689250/ | 14:45 |
| blackarchon | is this really not a problem? | 14:45 |
| mgz | yes, that does look funny but is actually correct. | 14:45 |
| blackarchon | ok :) | 14:45 |
| blackarchon | and thanks for your time! :) | 14:46 |
| mgz | some parts of the code use a unicode string where ü is u'\xfc' and some use a utf-8 byte string where it's '\xc3\xbc' | 14:46 |
| blackarchon | well this seems like a problematic approach | 14:47 |
| mgz | it is, but I think your bug is a different problem. | 14:48 |
| blackarchon | ok | 14:50 |
| davi_ | jelmer, hi, can you fix bzr-git trunk to work with dulwich 0.8.0? current trunk attempts to import HttpGitClient which i think is not implemented in dulwich 0.8 | 14:52 |
| === mtaylor_ is now known as mtaylor | ||
| Riddell | vila: is https://code.launchpad.net/~jr/bzr/i18n-unoverride-no-i18n-tests/+merge/75181 ok now? | 15:00 |
| vila | Riddell: didn't I approve it already ? | 15:02 |
| vila | oh no, | 15:03 |
| vila | Riddell: gha the diff makes no sense (not enough context), let me review that locally | 15:06 |
| vila | Riddell: ok ,so, this is better. One thing that comes to mind reading the patch though is that there are two idioms to test i18n: either you allow installing one or you install one without asking | 15:23 |
| systemclient | how can I export a repo with multiple branches to git? | 15:24 |
| vila | Riddell: and I don't really understand what the two TestInstall tests do. Are they just smoke tests ? | 15:24 |
| vila | Riddell: shouldn't test_custom_languages fails if there is no translations avaiable for nl:fy ? | 15:25 |
| Riddell | vila: I don't know, I didn't write those tests | 15:26 |
| Riddell | vila: yes the two ways to test i18n are documented with this merge proposal | 15:27 |
| vila | Riddell: oh, so sorry, they are indeed documented | 15:28 |
| vila | Riddell: alright, so, TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples | 15:30 |
| Riddell | vila: how about adding this to the end? self.assertTrue(isinstance(i18n._translations, i18n._gettext.GNUTranslations) ? | 15:32 |
| vila | Riddell: for the TestInstall ones ? | 15:32 |
| Riddell | yes | 15:32 |
| vila | sounds good ! | 15:32 |
| mgz | Riddell: can use assertIsInstance there. | 15:33 |
| vila | Riddell: does that mean that i18n.install('nl:fy') succeeds even if the translations are not available ? | 15:34 |
| vila | Riddell: if that's true, yeah, that will make the test intent clearer (and mgz remark applies too ;) | 15:34 |
| Riddell | I'm not sure, investigating | 15:38 |
| Riddell | vila: it'll produce a NullTranslation always, only if the language is there will is make a GNUTranslation | 15:42 |
| Riddell | so I've pushed a change to test for NullTranslation | 15:43 |
| vila | Riddell: ha ha, won't that break if that translation *is* available ? Or should you have a test for a known always available translation and one for a known never available one ? | 15:43 |
| Riddell | no because GNUTranslations inherits from NullTranslations | 15:44 |
| vila | ok, but mgz mentioned assertIsInstance (provided by testtools maybe ?) | 15:44 |
| vila | Riddell: and TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples | 15:45 |
| vila | bah copying my tyops now :-/ | 15:45 |
| vila | Riddell: assertIsInstance is provided by TestCase (not testtools) | 15:46 |
| vila | Riddell: and will give a better error message than assertTrue(isinstance(...)) | 15:46 |
| Riddell | vila: pushed | 15:49 |
| Noldorin | jelmer, had LP support for collocated branches arrived yet? | 16:02 |
| Noldorin | i knwo 2.5b1 is being released tomorrow | 16:02 |
| Noldorin | which has support | 16:03 |
| === BasicPRO is now known as BasicOSX | ||
| === davi` is now known as Guest14971 | ||
| Noldorin | jelmer, let me know if you want me to send you my powershell script... | 16:22 |
| Noldorin | for testing the issue | 16:22 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| lamalex | hey bzr folks- need some help | 17:14 |
| lamalex | (i'm tying my question- don't hassle me about asking to ask) | 17:14 |
| lamalex | i've got a branch which i want to merge into my trunk, but i want to squash the history of the old branch, as to basically not have it | 17:15 |
| fullermd | Aw, man, you take all the fun out of it... | 17:15 |
| lamalex | :) | 17:15 |
| lamalex | there is some private info in the history i don't want exposed to the world | 17:15 |
| Noldorin | lamalex, a normal merge does that | 17:15 |
| Noldorin | just make sure it doesn't pull | 17:16 |
| fullermd | You could merge, revert --forget-merges to dump the intermediate revs, then commit. | 17:16 |
| lamalex | Noldorin, but can't i go and do a bzr log -n0 and see the history of the branch? | 17:16 |
| lamalex | fullermd, ah ha, that sounds like a sane way | 17:16 |
| lamalex | i was trying to do a bzr diff > and then patch it | 17:16 |
| fullermd | Oh no. What will taht do to my reputation? | 17:16 |
| lamalex | but there are all kinds of renamed files and whatnot | 17:16 |
| lamalex | it was messy | 17:16 |
| Noldorin | lamalex, oh, i forgot about that | 17:17 |
| Noldorin | lamalex, fullermd has a decent solution :-) | 17:17 |
| lamalex | indeed | 17:17 |
| lamalex | oh my god that worked perfectly | 17:18 |
| lamalex | fullermd, you're a genius | 17:18 |
| Noldorin | bzr send --no-bundle may also work | 17:19 |
| Noldorin | i'm not sure though | 17:19 |
| lamalex | fullermd, do you work for canonical btw? | 17:19 |
| * fullermd buffs his nails on his shirt and looks haughtily down on everyone. | 17:19 | |
| fullermd | Oh, no. They'd make me run Linux and code in Python. Who wants that? | 17:19 |
| lamalex | ha | 17:21 |
| lamalex | zing | 17:21 |
| lamalex | isn't it odd, some people /like/ coding in python | 17:21 |
| * lamalex shudders | 17:21 | |
| Noldorin | many, in fact :-P | 17:22 |
| fullermd | Stockholm syndrome is a terrible thing :( | 17:22 |
| Noldorin | some people like coding in obj-c | 17:22 |
| Noldorin | which is even worse | 17:22 |
| fullermd | It could be worse though. I know a guy who LIKES COBOL. | 17:22 |
| fullermd | He has such scornful pity for the poor fools who don't like it, too. It's incredible to watch. | 17:23 |
| vila | fullermd: you imply he's still alive ? | 17:28 |
| fullermd | Well, I dunno if you'd classify COBOL programmers as "alive" in any meaningful sense... | 17:28 |
| vila | well, zombies walk but they don't TALK | 17:29 |
| * fullermd _wishes_ he didn't talk... | 17:29 | |
| vila | on the other hand, I heard you could do subroutines and even pass parameters in COBOL these days... | 17:29 |
| fullermd | He's actually so far off in his own world, it's impossible to argue with him about anything. | 17:30 |
| vila | and did they fix the compiler saying: 'You miss a period here, it's a fatal error, but I will assume there is one so I can show your all your other errors' ? | 17:30 |
| fullermd | He can actually say, with a straight face, that COBOL is totally relevant because it's kept up with the times, since it has all the modern bells and whistles like (I'm not making this up) while and for loops. | 17:31 |
| vila | that also reminds me of this guy writing perl scripts to generate visual basic that inject data in excel documents... | 17:32 |
| vila | fortunately I only *heard* about him | 17:32 |
| fullermd | I use a perl script to generate my window manager config on the fly... | 17:32 |
| vila | fullermd: pff, you miss the vb part, too easy, doesn't count | 17:33 |
| fullermd | At one time I had perl in my shell rc file too. Only has sed and awk now, though. | 17:33 |
| fullermd | (at this point of course we x-ref the classic Know Your Sysadmin :p) | 17:34 |
| vila | :) | 17:38 |
| Noldorin | hi jelmer | 19:15 |
| poolie | hi | 20:27 |
| GRiD | hi poolie | 20:27 |
| GRiD | are you up early? :) | 20:28 |
| poolie | i am | 20:29 |
| poolie | how are you? | 20:30 |
| GRiD | good thanks. saw you had the flu, over i hope? | 20:31 |
| poolie | yes, fine now | 20:31 |
| GRiD | cool. we're just about to get into that season here, not looking forward to that... | 20:33 |
| abentley | poolie: Didja know Martin Poole is a character on a Canadian TV show? http://www.imdb.com/character/ch0184436/ | 21:04 |
| poolie | i did not | 21:06 |
| abentley | poolie: it was rather bizarre watching for me. | 21:06 |
| poolie | statik, hi? | 21:19 |
| statik | hi poolie | 21:19 |
| Noldorin | jelmer, hey | 21:40 |
| jelmer | Noldorin: hi | 22:00 |
| Noldorin | how's it going..? | 22:00 |
| jelmer | Noldorin: it's alright | 22:11 |
| jelmer | how are you? | 22:11 |
| Noldorin | good good | 22:11 |
| jelmer | g'morning poolie, statik | 22:11 |
| Noldorin | haven't had chance to do much more investigating | 22:11 |
| Noldorin | jelmer, how about you? | 22:11 |
| jelmer | Noldorin: been busy with other things all day too | 22:11 |
| jelmer | I'm going to have a look now, but might fall asleep before I have a chance to... | 22:11 |
| poolie | hi jelmer | 22:12 |
| poolie | well, it's a great day to bisect intermittent kernel bugs | 22:12 |
| poolie | but i think i will anyhow | 22:12 |
| jelmer | poolie: check out revision, recompile kernel, reboot, repeat? | 22:13 |
| poolie | yeah | 22:13 |
| poolie | i'm going to start just with the various sub-versions of packaged kernels | 22:13 |
| poolie | for bug 833479 fwiw | 22:16 |
| ubot5 | Launchpad bug 833479 in linux (Ubuntu) "e1000e connection drops out" [High,Incomplete] https://launchpad.net/bugs/833479 | 22:16 |
| poolie | jelmer, can i just confirm you started the process for 2.4.1 into oneiric? | 22:18 |
| jelmer | poolie: yep - the package built fine, it's just waiting to be uploaded now | 22:19 |
| poolie | great | 22:19 |
| poolie | that was really pretty smooth | 22:19 |
| Noldorin | jelmer, ok sounds good :-) | 22:19 |
| Noldorin | jelmer, looking forward to the 2.5b1 release tomorrow too | 22:19 |
| Noldorin | jelmer, something tells me the fix is going to be very small....just difficult to figure out | 22:26 |
| jelmer | Noldorin: I think the fix will be trivial once we have a test that reproduces the issue | 22:26 |
| Noldorin | jelmer, you were away earlier today, but i offered to send you my powershell script... | 22:29 |
| Noldorin | if you like | 22:29 |
| Noldorin | but you know how to reproduce it anyway i think | 22:29 |
| jelmer | Noldorin: thanks, but I don't have powershell here (Linux) | 22:29 |
| jelmer | unless your script reproduces the issue in less revisions that the original branch? | 22:30 |
| Noldorin | jelmer, afriad not. everything happens at r47... | 22:31 |
| jelmer | it should still happen with the contents of r46 and the problematic changes | 22:31 |
| Noldorin | that's what i mean yeah | 22:33 |
| Noldorin | my script shows that | 22:33 |
| Noldorin | we discussed it yesterday :-) | 22:33 |
| jelmer | Noldorin: I mean, if you commit the entire set of contents of r46 in a new branch as r1 and then make the same problematic changes that triggered the bug in your r47 | 22:35 |
| jelmer | anyway, time for some sleep. g'night | 22:37 |
| poolie | night | 22:42 |
| poolie | GRiD, hi? | 23:53 |
| GRiD | hi | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!