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