| mgz | okay, posting that for review before I go cross-eyed | 00:31 |
|---|---|---|
| mgz | the actual changes in the branch are simple and should fix nearly all the problems, the overall picture is just complicated | 00:33 |
| mgz | and whoops, I totally forgot earlier dulwich isn't managed on launchpad, just realised merge proposal was asking vcs imports to look at it | 00:35 |
| jelmer | mgz: the mp has been merged | 00:37 |
| mgz | hey, you magically did the right thing despite the fact I'm an idiot! | 00:37 |
| jelmer | mgz: thanks for looking into that colo bug | 00:39 |
| mgz | ...I take it you did it manually by somehow reading my mind, or does launchpad help out? | 00:39 |
| jelmer | mgz: launchpad doesn't help out, especially as I use dpush on dulwich | 00:40 |
| jelmer | mgz: for bzr-svn pushes (which have roundtripping) it does recognize merges properly | 00:40 |
| mgz | ^some of the colo thing I think is just going to be messy because you're trying to layer an extra external thing onto urls | 00:41 |
| mgz | but it should all be fixable at least | 00:42 |
| mgz | I think it just needs choosing what behaviour is wanted in a few corner cases, | 00:43 |
| mgz | the sort of branches anyone will use in practice should be fine already. | 00:44 |
| === mwhudson_ is now known as mwhudson | ||
| vila | hi all ! | 07:06 |
| poolie | hi vila | 07:38 |
| poolie | nice report | 07:38 |
| poolie | oh no :) | 07:38 |
| vila | poolie: hehe | 07:39 |
| vila | poolie: you've been good at updating that topic for the past weeks ;) | 07:39 |
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | ||
| poolie | that was really classy actually | 07:41 |
| poolie | i think i can manage it this week | 07:41 |
| vila | poolie: try https://code.launchpad.net/~vila/udd/819910-file-mp/+merge/73927 for an easy one (it's already deployed which is... well it is ;) | 07:43 |
| poolie | thanks | 07:53 |
| poolie | fwiw i really prefer just 4-char indents for paramter continuations | 07:54 |
| vila | fwiw I just type enter and let my editor do the Right Thing ;) | 07:54 |
| poolie | or not :) | 07:54 |
| vila | well, overriding that will be really unconvenient and error prone | 07:55 |
| vila | I almost never do indentation mistakes because I just follow the mode... | 07:56 |
| poolie | well, i strongly suspect there's a variable to control it | 07:56 |
| poolie | but it's not a big deal at all | 07:56 |
| poolie | it just stood out since it was ½ the diff :) | 07:57 |
| vila | hehe | 07:57 |
| vila | the 4 spaces indent *is* used if the line is truncated after the opening brace | 07:57 |
| poolie | oh, i see | 07:58 |
| vila | and overall, I think it makes a lot of sense: either you put *all* parameters on the following line or you align them | 07:58 |
| poolie | i think lp's style guide asks for that | 07:58 |
| poolie | ours doesn't, so i'm not saying you're wrong | 07:58 |
| vila | no worries, I've noticed the various usages long ago and just attributed them to other editors | 07:59 |
| vila | poolie: oh, just looked at the mp, yeah, unfortunate and useless here :-/ | 08:01 |
| vila | poolie: left over from a more involved attempt | 08:01 |
| vila | poolie: I generally revert them but forgot that one | 08:01 |
| vila | no big deal, just explaining | 08:01 |
| === Quintasan_ is now known as Quintasan | ||
| Riddell | bonjour | 08:08 |
| vila | Riddell: hey ! | 08:10 |
| vila | Riddell: we just a got a storm of PristineTarError on the package importer ( http://package-import.ubuntu.com/status/73aaec3da59a46ab68e18ea8c195a6e7.html) all of them related to kde: any obvious cause to your eyes ? | 08:12 |
| vila | jelmer: do we support bz2 on jubany ? (Shot in the dark) | 08:13 |
| vila | poolie: did you talked to mthaddon ? The new pqm was ready to deploy last Friday but I deferred to you (targeting today) while the queue was purging (Friday) | 08:22 |
| poolie | no, i haven't talked to him since friday | 08:23 |
| vila | poolie: given the config, I think we can use --parallel=fork and ask for /tmp to be tmpfs mounted, that should give us something around 5 mins to land a patch (hopefully) | 08:23 |
| mthaddon | I'm planning to put it live today | 08:23 |
| vila | hehe, excellent :) | 08:23 |
| vila | mthaddon: so, can /tmp be tmpfs mounted ? | 08:23 |
| mthaddon | vila: I'd like to have a successful run first, then we can do that, yep | 08:24 |
| vila | great | 08:24 |
| vila | mthaddon: just ask if you need me to trigger such a run | 08:24 |
| mthaddon | vila: ok, I'll let you know when we're ready for it - thx | 08:25 |
| vila | poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check-trunk/+merge/73500 didn't cause problems and provides a limited but useful view, are you ok to deploy the moral equivalent for all branches ? If nothing else, it will provide some fuel for the new pqm tests | 08:26 |
| poolie | oh hi mthaddon | 08:32 |
| mthaddon | o/ | 08:32 |
| poolie | that's great, thankyou | 08:32 |
| poolie | vila, i still have qualms about doing test-futzing things in stable branches | 08:32 |
| poolie | 2.4 is ok | 08:32 |
| poolie | just more on general principal than because i think the specific risk is very high | 08:33 |
| vila | hehe, ok, I'm glad you care about stable branches this way, I do too :) | 08:34 |
| poolie | :) if you think it's worthwhile it's ok | 08:35 |
| poolie | woo! | 08:35 |
| vila | poolie: the fundamental reason I want that on all branches (including stable ones) is that it will give us hard data about regressions. | 08:37 |
| vila | poolie: what was this 'woo' for ? | 08:37 |
| poolie | i got some improvements to lp mail handling working | 08:38 |
| poolie | see that channel | 08:38 |
| vila | oh, ok, yeah, great ! | 08:38 |
| vila | jelmer, poolie: http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates updated, I think only one of you can act from there | 08:40 |
| vila | jelmer, poolie : also, in the freeze announcement I said I will officially announce the release tomorrow, but thinking again about it, it doesn't really make sense | 08:41 |
| poolie | specifically 2.2.5? | 08:41 |
| vila | jelmer, poolie : people interested in SRUs just get them via updates, telling them about it via mail... doesn't seem to match | 08:41 |
| poolie | because it's only useful to people tracking 2.2, ro more specifically on maverick? | 08:41 |
| vila | yeah, 2.2.5 | 08:41 |
| poolie | yeah | 08:41 |
| poolie | i think it's useful there be something they can read about it | 08:42 |
| poolie | but it's important it be in context so people tracking trunk or 2.4 are not confused | 08:42 |
| vila | poolie, jelmer: ok, I'll update releasing.txt and will announce it when it's available (ping me if I forget) | 08:43 |
| vila | poolie: on my RM plate this week: freeze 2.4.1 (2.5b1 will be next week) (https://launchpad.net/bzr/+milestones for the overview) | 08:44 |
| Riddell | vila: I don't know I'm afraid, when I try it locally pristine tar works fine | 09:17 |
| vila | Riddell: ok, thanks | 09:17 |
| Riddell | using .bz2 can't be the issue, plenty packages use that | 09:17 |
| jelmer | vila: what pristine-tar version is on jubany? | 09:24 |
| jelmer | pristine-tar 1.03 fixed a bzip2 issue when the bz2 compressor was changed | 09:24 |
| vila | jelmer: 1.11ubuntu1~0.IS.8.04 | 09:25 |
| jelmer | hmm | 09:25 |
| vila | jelmer: may be unrelated, I was surprised mainly by all failures occurring being for kde and was wondering if something changed there recently | 09:27 |
| jelmer | vila: I can't find much that could be related; did KDE perhaps change the way they create their tarballs? | 09:45 |
| poolie | ok guys i'm off to squash | 09:46 |
| poolie | have a good day | 09:46 |
| vila | jelmer: thanks for looking, I'll dig later to better understand the issue and let you know (cleaning up my plate from other stuff right now) | 09:46 |
| vila | poolie: you too ! | 09:47 |
| jelmer | have fun poolie :) | 09:47 |
| vila | jelmer: I started using https://code.launchpad.net/~vila/udd/analyze-log-imports/+merge/74057 to get a better understanding on when imports succeed and where they come from (ubuntu/debian) | 09:48 |
| vila | jelmer: the vast majority todat are from debian (sid, wheezy) may be that's where something occurred recently | 09:49 |
| jelmer | vila: are you sure it's bz2 files, not xz files? | 09:49 |
| Riddell | jelmer: did you get PQM error messages from https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 and https://code.launchpad.net/~jr/bzr/i18n-topic-help/+merge/73653 ? | 09:49 |
| vila | jelmer: no, not sure, just read the p-i web site so far | 09:49 |
| jelmer | Riddell: ah, yep. Let me see if I can find them and forward to you. | 09:50 |
| vila | Riddell, jelmer : In case you missed it, mthaddon should be very close to provide the new pqm | 09:50 |
| Riddell | the pqm queue is empty, the perfect time to do a switcheroo | 09:51 |
| vila | Riddell, jelmer : So send one submission at a time so you can use the new one sooner ;) | 09:51 |
| jelmer | hehe | 09:51 |
| jelmer | Riddell: forwarded | 09:53 |
| Riddell | I do wish PQM fail logs didn't include all the expected failures | 09:55 |
| jelmer | Riddell: it should be possible to add a subunit filter to filter them out | 09:58 |
| lifeless | in pqm even | 10:19 |
| lifeless | change the filter invocation | 10:19 |
| Riddell | who's our unicode expert? | 10:50 |
| jelmer | Riddell: probably jam, though any of us know a fair bit about it | 10:55 |
| jelmer | Riddell: oh, jam and mgz I guess | 10:55 |
| Riddell | this solves my problem but it doesn't look very elegant gettext(unicode(fmt, 'utf-8')).encode('utf-8') | 10:56 |
| Riddell | and is probably incorrect if not using utf-8 | 10:57 |
| jelmer | Riddell: I think generally we try to make sure we know what the encoding is of things we handle :) | 10:57 |
| jelmer | Riddell: where does fmt come from?\ | 10:57 |
| Riddell | it's https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 and fmt is the error string | 10:58 |
| Riddell | and bzrlib.tests.test_errors.TestErrors.test_duplicate_record_name_error is the test case I need to fix | 10:58 |
| jelmer | Riddell: it looks like our (de-facto) policy is to have _fmt contain utf-8 | 10:59 |
| jelmer | hmm, though there are a few exceptions | 11:00 |
| jelmer | Riddell: perhaps check the type and raise a deprecationwarning if _fmt has a different type than what you expect | 11:00 |
| Riddell | well the type is just str I think | 11:01 |
| jelmer | Riddell: some things in bzrlib.errors use unicode for their _fmt | 11:01 |
| Riddell | so that's unlike to work with my solution above | 11:03 |
| jelmer | Riddell: gettext requires a bytestring I guess? | 11:04 |
| jelmer | Riddell: in that case it seems most reasonable to: | 11:04 |
| jelmer | check if type(fmt) == unicode, and if it is, convert to utf-8 (perhaps after printing a deprecation warning) | 11:05 |
| jelmer | after that, simply passing fmt to gettext | 11:05 |
| jelmer | hmm, I guess it's the other way around | 11:05 |
| Riddell | yes | 11:06 |
| * jelmer hopes he is still making sense | 11:06 | |
| jelmer | Riddell: either way, your solution looks reasonable though we'd probably have to make sure to cope with the situation where a fmt is passed in that has type "unicode" | 11:07 |
| Riddell | so if it's a str() convert to unicode, if it's unicode issue deprecation warning and pass to gettext direct? | 11:07 |
| jelmer | Riddell: Yeah, that seems the most reasonable to me. The only thing I'm not sure about is whether we want fmt to be unicode or utf8 by default | 11:09 |
| jelmer | Riddell: we seem to've gone for utf8 in a lot of places though, and that's what we do for almost all _fmt strings at the moment | 11:10 |
| jelmer | vila, jam: ^ | 11:10 |
| Riddell | jelmer: by utf8 you mean a str that contains utf8 bytes? | 11:20 |
| vila | jelmer: the ~consensus is to: 1) wait as long as possible before encoding 2) default to utf8 is nothing better is known | 11:22 |
| vila | that doesn't really answer the decoding though | 11:22 |
| vila | Riddell: 33+from bzrlib import i18n, tests, errors, workingtree | 11:23 |
| vila | use multiple lines sorted to avoid conflicts ;) | 11:23 |
| vila | 56+ err = str(e) | 11:24 |
| vila | Riddell: ask mgz, but I'm pretty sure he will object ;) | 11:24 |
| vila | Riddell: unicode issues make my head spin, I know mgz have spend quite some time to get things right in the subunit/testtools python2.4 -> 3.x to notably, so I'll defer to him there | 11:25 |
| Riddell | vila: object to str(e) ? | 11:25 |
| vila | yeah | 11:26 |
| vila | because. among other things, some paths may be involved when reporting an error | 11:26 |
| vila | Riddell: Oh, and don't feel bad, http://package-import.ubuntu.com/status/ mentions 58 + 10 + 5 + 2 (and probably some I miss) failures related to UnicodeError... | 11:28 |
| vila | so it's not like you're alone in this boat | 11:29 |
| Breedlings | hi folks, I'm struggling with setting up .htaccess to limit access for checkouts. Can anyone advise please? | 11:31 |
| Riddell | https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 updated if anyone wishes to eye over again | 11:41 |
| jelmer | Riddell: we typically use .decode("utf-8") or safe_unicode to convert to utf8 | 11:46 |
| jelmer | that's a minor nitpick; it'd be great if somebody could also have a look wrt the bigger picture | 11:49 |
| Riddell | ok safe_unicode now in | 11:53 |
| Quintasan | jelmer: Do we have git branch support in LP now? | 12:25 |
| jelmer | Quintasan: no, that branch has not yet landed | 12:36 |
| soren | jelmer: Is it far off, you think? | 12:45 |
| davi_ | jelmer, hi, had some limited success with round tripping support. mostly works, but there are a couple of issues. subsequents pushes (-r N) to the repository fails with exception, but pull from the git repository works. another thing is that partial pushes attempt to get all tags, which is bound to fail. should i report bugs for these? | 13:02 |
| jelmer | soren: it's ready, just waiting to land at this point | 13:06 |
| jelmer | soren: we've also just updated to bzr 2.4 so I'd like to make sure that's all working without problems before landing the colocated branch work | 13:07 |
| soren | jelmer: So.. Less than a month's time? | 13:07 |
| jelmer | soren: definitely. | 13:08 |
| soren | Cool beans. | 13:08 |
| jelmer | soren: well, I should know to never make promises like that. But really weird things would have to happen if it doesn't land within a month. | 13:08 |
| jelmer | davi_: Can you perhaps comment on the roundtripping bug with what you've found? | 13:09 |
| davi_ | jelmer, sure | 13:09 |
| jelmer | s/if it doesn't/for it not to/ | 13:12 |
| jelmer | Riddell: hmm | 13:50 |
| jelmer | Riddell: I just realized, one of the things we'll have to take into account when translating errors is how this interacts with errors sent by remote servers | 13:51 |
| Riddell | jelmer: mm | 13:52 |
| Riddell | I can do some tests | 13:52 |
| Riddell | but first I need to write this app developer week talk | 13:52 |
| vila | jelmer: The more I see you work on foreign plugins the more I think some of these plugins should land into core... | 15:03 |
| vila | jelmer: with optional dependencies may be... | 15:04 |
| vila | s/optional/soft/ | 15:04 |
| jelmer | vila: I'm pretty happy with the current situation. What advantage would having them in core have? | 15:09 |
| vila | batteries included, less regressions when something change in core | 15:10 |
| jelmer | vila: we can't really do batteries included as we can't reasonably ship the dependencies of the foreign plugins | 15:11 |
| vila | it may also help to refine the core design by exposing the plugin needs | 15:11 |
| jelmer | vila: unless you want to ship copies of the apache libraries, svn libraries and subvertpy for bzr-svn, the mercurial source code for bzr-hg and dulwich for bzr-git :) | 15:11 |
| vila | yeah, that's why I said 'soft' dependencies | 15:12 |
| jelmer | that's not really "batteries included" | 15:12 |
| vila | yeah but I think you get what I meant ;) | 15:13 |
| vila | pycurl is such a soft dependency for example, used if present | 15:14 |
| jelmer | vila: I'm not sure what shipping the foreign plugins really adds in that case, as the user will still have to install e.g. python-subvertpy | 15:15 |
| vila | but if you don't support the idea, never mind, there are arguments both ways | 15:15 |
| vila | sure, but that can be addressed with a friendly warning, etc | 15:16 |
| jelmer | vila: for now it's not really possible anyway, as the plugins don't pass the bzr.dev testsuite | 15:16 |
| vila | your status.net remark about pull <git> ; push <svn> made me think about it | 15:16 |
| vila | jelmer: yup, I know | 15:16 |
| vila | jelmer: the counter-argument is that the work you're doing right now can't be done if they were part of core | 15:17 |
| vila | hmm | 15:18 |
| vila | well "can" be done but probably not as cleanly | 15:18 |
| jelmer | vila: I like the idea of making it easier for end users to use the foreign plugins, but I don't think that necessarily means including them in the core | 15:18 |
| vila | I see | 15:19 |
| vila | and agree ;) | 15:19 |
| jelmer | vila: I think it's already fairly easy to get the foreign plugins installed on a Linux system. We seem to do alright for bzr-svn on Windows and Mac. bzr-git isn't included in the windows installer. Not sure about bzr-git on Mac. | 15:24 |
| vila | ...and no idea about other distros | 15:24 |
| vila | I see no mention of git in the mac installers | 15:26 |
| jelmer | vila: do you know about "whohas" ? | 15:26 |
| vila | no, is that a command, an IRC nick, something else ? | 15:26 |
| jelmer | vila: It's a command, from the "whohas" package in Ubuntu | 15:26 |
| jelmer | vila: try "whohas bzr" | 15:26 |
| vila | wow | 15:27 |
| vila | hmm, we need to find an openSUSE maintainer :-/ | 15:28 |
| fullermd | Jeez, git is a pain to use... | 15:29 |
| vila | fullermd: try bzr-git ;) | 15:29 |
| === beuno is now known as beuno-lunch | ||
| Riddell | vila: we need opensuse packages? | 16:47 |
| Riddell | I've done those before | 16:47 |
| vila | Riddell: `whohas bzr` says openSUSE carries 2.0.5... | 16:54 |
| Riddell | ** Talk on Bazzar Explorer in 5 minutes in #ubuntu-classroom | 16:54 |
| mgz | hm, Riddell's gettext on errors branch is a fun set of problems. | 16:55 |
| Riddell | uh oh | 16:55 |
| nigelb | Riddell: ping | 16:55 |
| Riddell | nigelb: hi | 16:56 |
| nigelb | All set? (sorry about the schedule mistake) | 16:56 |
| nigelb | Could you join #ubuntu-classroom-backstage as well, in case something goes wrong, or you need help :) | 16:56 |
| Riddell | what schedule mistake? | 16:57 |
| nigelb | "it gives the full power of tools like git but it's understandable to people other than Linus" -- I'm always going to use this when I talk about bzr. | 17:07 |
| === beuno-lunch is now known as beuno | ||
| nigelb | Riddell: Nice talk. | 18:02 |
| nigelb | LOVED your description of bzr :) | 18:02 |
| Riddell | thanks nigelb | 18:05 |
| Riddell | mgz: what problems do you think it has? | 18:05 |
| mgz | eg: | 18:08 |
| mgz | _fmt = 'Permission denied: "%(path)s"%(extra)s' | 18:08 |
| mgz | return gettext(unicode_fmt).encode('utf-8') | 18:09 |
| mgz | 'Lupa ev\xc3\xa4tty: "%(path)s"%(extra)s' % {'path':u'.', 'extra':''} | 18:09 |
| mgz | try evalling the last line. | 18:09 |
| mgz | the problem is the error module is pretty confused already, so it's hard to cleanly add in gettext | 18:10 |
| mgz | basically, mixing str and unicode types breaks when non-ascii is involved, and some things we want to use with errors are bytes, and some (like paths) are unicode | 18:12 |
| mgz | currently _fmt is ascii (are there any exceptions?) so provided the inputs are only one or the other, we're fine | 18:13 |
| mgz | but if _fmt becomes some non-ascii utf-8 string from gettext, more things start breaking | 18:14 |
| mgz | so really you're exposing existing problems rather than creating new ones. | 18:15 |
| mgz | but using osutils.safe_unicode is just wrong ;) | 18:16 |
| Riddell | mgz: why is it wrong? | 18:19 |
| mgz | because if you don't know the type of the input, you can't safely handle it | 18:19 |
| mgz | it's a check in the wrong place. | 18:20 |
| mgz | one thing I don't completely understand is the preferred input for gettext-the-python-module | 18:24 |
| Riddell | mgz: it might not have one | 18:24 |
| Riddell | generally it's going to expect just ascii characters | 18:25 |
| mgz | and it will always return unicode? | 18:25 |
| mgz | gettext proper has the normal mess of encodings | 18:25 |
| Riddell | yes it returns unicode strings | 18:26 |
| jelmer | mgz: what's wrong with using safe_unicode if we know the input is going to be utf8 or unicode ? | 18:26 |
| mgz | jelmer: we very seldom do, and when we actually do, that's just a bad api - pick one or the other | 18:27 |
| jelmer | mgz: sure, I agree we should pick one or another but we can consider one deprecated, which I think Riddell's patch does | 18:27 |
| mgz | the common case is often utf-8 or ascii, but should really be looking at LC_MESSAGES or similar environmental settings | 18:27 |
| jelmer | mgz: this is about the contents of BzrError._fmt, which would be set by a programmer. I think we require utf8 or unicode there. | 18:28 |
| mgz | I don't see why we can't just require ascii. | 18:28 |
| mgz | and write a test to that effect. | 18:29 |
| jelmer | mgz: what if we ever need to use a non-ascii character in a format string? | 18:29 |
| mgz | then we break that error for anyone with LANG=C? doesn't seem worth it. | 18:30 |
| mgz | I don't understand from that branch (having not followed naoki's changes that closely) is how we're getting all the _fmt strings out for translation, I guess it's a seperate step? | 18:31 |
| Riddell | yes that's hidden in export_pot.py | 18:31 |
| Riddell | which is a funny way to do it compared to just using gettext() around all the strings | 18:32 |
| mgz | it's a side-effect of Python I guess. | 18:32 |
| mgz | we don't want to do the translation at byte-code compile time | 18:33 |
| mgz | wait, wrongly phrased | 18:33 |
| mgz | class definition time. | 18:33 |
| jelmer | it would be neat if we could do it at byte-code compile time.. :) | 18:35 |
| mgz | Riddell: okay, so the only thing I think that really needs fixing before landing is | 18:37 |
| mgz | + return gettext(unicode_fmt).encode('utf-8') | 18:37 |
| mgz | remove the encode. | 18:37 |
| mgz | there's no problem with _fmt being unicode there, calling str() on an exception encodes to utf-8 anyway, and mixing a utf-8 translation and unicode path would be common and break everything | 18:38 |
| Riddell | mgz: then this fails | 18:39 |
| Riddell | ./bzr selftest -s bzrlib.tests.test_errors.TestErrors.test_duplicate_record_name_error | 18:39 |
| mgz | that's not suprising, but fixing that one error is easier than fixing every error that includes a path | 18:41 |
| Riddell | but the test looks valid to me | 18:41 |
| mgz | I'd make the exception decode the name. | 18:42 |
| mgz | - self.name = name | 18:43 |
| mgz | + self.name = name.decode("utf-8") | 18:43 |
| mgz | then the test would pass as written. | 18:43 |
| mgz | would be nice to delay that till the format step, but there's no simple way to do that. | 18:44 |
| Riddell | but aren't there other errors which will need the same? | 18:45 |
| mgz | probably, they're completely inconsistent at the moment. | 18:46 |
| mgz | raise errors.DuplicateRecordNameError(name_tuple) | 18:48 |
| mgz | huh? | 18:48 |
| === nyuszika7h is now known as evilnyuszika7h | ||
| mgz | in bzrlib.pack ...but... variable seems to be a string despite being having 'tuple' in the name | 18:48 |
| mgz | or, no, it is a tuple, that will something... gr... | 18:49 |
| mgz | Riddell: adding a test with an error _fmt string that's translated would be helpful I think... | 18:50 |
| mgz | maybe make the ZzzTranslations thing use more than just ascii? | 18:51 |
| mgz | then the test you added would fail. | 18:52 |
| Riddell | ok thanks mgz, I've got to go out now | 18:55 |
| mgz | bye! I'll write a few things in the mp. | 18:55 |
| === yofel_ is now known as yofel | ||
| === evilnyuszika7h is now known as nyuszika7h | ||
| === nyuszika7h is now known as [nyuszika7h] | ||
| === [nyuszika7h] is now known as nyuszika7h | ||
| aquarius_ | in Ubuntu, /usr/share/pyshared/bzrlib/tests/ftp_server/pyftpdlib_based.py contains a test for bzr that uses pyftpdlib, but... pyftpdlib doesn't seem to be packaged? | 21:34 |
| mgz | that certainly was an issue... there's a bug for it somewhere | 21:35 |
| mgz | bug 781140 | 21:36 |
| ubot5 | Launchpad bug 781140 in Bazaar "Missing test coverage for FTPTransport, needs pyftplib" [Medium,Fix released] https://launchpad.net/bugs/781140 | 21:36 |
| aquarius_ | aha | 21:36 |
| aquarius_ | nice one :) | 21:37 |
| AuroraBorealis | so i'm trying out the 'sign always' thing in bzr where it uses my gpg key | 22:05 |
| AuroraBorealis | but where is it finding my gpg key? i haven't told it where it is and it keeps saying my passphrase is incorrect | 22:06 |
| mwhudson | AuroraBorealis: it runs gpg | 22:07 |
| mwhudson | so if echo '' | gpg --clearsign works, probably bzr will to | 22:07 |
| mwhudson | o | 22:07 |
| AuroraBorealis | well im on windows so i have not set it up really | 22:08 |
| AuroraBorealis | and i have no idea how to set it up to use my key | 22:08 |
| AuroraBorealis | but it somehow is using my key | 22:08 |
| mwhudson | how can i make --show-base the default for merge ? | 22:23 |
| mwhudson | i guess an alias works | 22:23 |
| poolie | hi all | 23:32 |
| mgz | hey poolie. | 23:40 |
| poolie | hi there | 23:40 |
| mgz | confusing bug numbers... I thought launchpad just gave me the same thing twice | 23:46 |
| mgz | but it's 842223 and 842233 | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!