[00:31] <mgz> okay, posting that for review before I go cross-eyed
[00:33] <mgz> the actual changes in the branch are simple and should fix nearly all the problems, the overall picture is just complicated
[00:35] <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:37] <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:39] <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:40] <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:41] <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:42] <mgz> but it should all be fixable at least
[00:43] <mgz> I think it just needs choosing what behaviour is wanted in a few corner cases,
[00:44] <mgz> the sort of branches anyone will use in practice should be fine already.
[07:06] <vila> hi all !
[07:38] <poolie> hi vila
[07:38] <poolie> nice report
[07:38] <poolie> oh no :)
[07:39] <vila> poolie: hehe
[07:39] <vila> poolie: you've been good at updating that topic for the past weeks ;)
[07:41] <poolie> that was really classy actually
[07:41] <poolie> i think i can manage it this week
[07:43] <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:53] <poolie> thanks
[07:54] <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:55] <vila> well, overriding that will be really unconvenient and error prone
[07:56] <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:57] <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:58] <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:59] <vila> no worries, I've noticed the various usages long ago and just attributed them to other editors
[08:01] <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:08] <Riddell> bonjour
[08:10] <vila> Riddell: hey !
[08:12] <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:13] <vila> jelmer: do we support bz2 on jubany ? (Shot in the dark)
[08:22] <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:23] <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:24] <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:25] <mthaddon> vila: ok, I'll let you know when we're ready for it - thx
[08:26] <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:32] <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:33] <poolie> just more on general principal than because i think the specific risk is very high
[08:34] <vila> hehe, ok, I'm glad you care about stable branches this way, I do too :)
[08:35] <poolie> :) if you think it's worthwhile it's ok
[08:35] <poolie> woo!
[08:37] <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:38] <poolie> i got some improvements to lp mail handling working
[08:38] <poolie> see that channel
[08:38] <vila> oh, ok, yeah, great !
[08:40] <vila> jelmer, poolie: http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates updated, I think only one of you can act from there
[08:41] <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:42] <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:43] <vila> poolie, jelmer: ok, I'll update releasing.txt and will announce it when it's available (ping me if I forget)
[08:44] <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)
[09:17] <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:24] <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:25] <vila> jelmer: 1.11ubuntu1~0.IS.8.04
[09:25] <jelmer> hmm
[09:27] <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:45] <jelmer> vila: I can't find much that could be related; did KDE perhaps change the way they create their tarballs?
[09:46] <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:47] <vila> poolie: you too !
[09:47] <jelmer> have fun poolie :)
[09:48] <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:49] <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:50] <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:51] <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:53] <jelmer> Riddell: forwarded
[09:55] <Riddell> I do wish PQM fail logs didn't include all the expected failures
[09:58] <jelmer> Riddell: it should be possible to add a subunit filter to filter them out
[10:19] <lifeless> in pqm even
[10:19] <lifeless> change the filter invocation
[10:50] <Riddell> who's our unicode expert?
[10:55] <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:56] <Riddell> this solves my problem but it doesn't look very elegant gettext(unicode(fmt, 'utf-8')).encode('utf-8')
[10:57] <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:58] <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:59] <jelmer> Riddell: it looks like our (de-facto) policy is to have _fmt contain utf-8
[11:00] <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:01] <Riddell> well the type is just str I think
[11:01] <jelmer> Riddell: some things in bzrlib.errors use unicode for their _fmt
[11:03] <Riddell> so that's unlike to work with my solution above
[11:04] <jelmer> Riddell: gettext requires a bytestring I guess?
[11:04] <jelmer> Riddell: in that case it seems most reasonable to:
[11:05] <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:06] <Riddell> yes
[11:06]  * jelmer hopes he is still making sense
[11:07] <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:09] <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:10] <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:20] <Riddell> jelmer: by utf8 you mean a str that contains utf8 bytes?
[11:22] <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:23] <vila> Riddell: 33	+from bzrlib import i18n, tests, errors, workingtree
[11:23] <vila> use multiple lines sorted to avoid conflicts ;)
[11:24] <vila> 56	+ err = str(e)
[11:24] <vila> Riddell: ask mgz, but I'm pretty sure he will object ;)
[11:25] <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:26] <vila> yeah
[11:26] <vila> because. among other things,  some paths may be involved when reporting an error
[11:28] <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:29] <vila> so it's not like you're alone in this boat
[11:31] <Breedlings> hi folks, I'm struggling with setting up .htaccess to limit access for checkouts. Can anyone advise please?
[11:41] <Riddell> https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 updated if anyone wishes to eye over again
[11:46] <jelmer> Riddell: we typically use .decode("utf-8") or safe_unicode to convert to utf8
[11:49] <jelmer> that's a minor nitpick; it'd be great if somebody could also have a look wrt the bigger picture
[11:53] <Riddell> ok safe_unicode now in
[12:25] <Quintasan> jelmer: Do we have git branch support in LP now?
[12:36] <jelmer> Quintasan: no, that branch has not yet landed
[12:45] <soren> jelmer: Is it far off, you think?
[13:02] <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:06] <jelmer> soren: it's ready, just waiting to land at this point
[13:07] <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:08] <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:09] <jelmer> davi_: Can you perhaps comment on the roundtripping bug with what you've found?
[13:09] <davi_> jelmer, sure
[13:12] <jelmer> s/if it doesn't/for it not to/
[13:50] <jelmer> Riddell: hmm
[13:51] <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:52] <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
[15:03] <vila> jelmer: The more I see you work on foreign plugins the more I think some of these plugins should land into core...
[15:04] <vila> jelmer: with optional dependencies may be...
[15:04] <vila> s/optional/soft/
[15:09] <jelmer> vila: I'm pretty happy with the current situation. What advantage would having them in core have?
[15:10] <vila> batteries included, less regressions when something change in core
[15:11] <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:12] <vila> yeah, that's why I said 'soft' dependencies
[15:12] <jelmer> that's not really "batteries included"
[15:13] <vila> yeah but I think you get what I meant ;)
[15:14] <vila> pycurl is such a  soft dependency for example, used if present
[15:15] <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:16] <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:17] <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:18] <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:19] <vila> I see
[15:19] <vila> and agree ;)
[15:24] <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:26] <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:27] <vila> wow
[15:28] <vila> hmm, we need to find an openSUSE maintainer :-/
[15:29] <fullermd> Jeez, git is a pain to use...
[15:29] <vila> fullermd: try bzr-git ;)
[16:47] <Riddell> vila: we need opensuse packages?
[16:47] <Riddell> I've done those before
[16:54] <vila> Riddell: `whohas bzr` says openSUSE carries 2.0.5...
[16:54] <Riddell> ** Talk on Bazzar Explorer in 5 minutes in #ubuntu-classroom
[16:55] <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:56] <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:57] <Riddell> what schedule mistake?
[17:07] <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.
[18:02] <nigelb> Riddell: Nice talk.
[18:02] <nigelb> LOVED your description of bzr :)
[18:05] <Riddell> thanks nigelb
[18:05] <Riddell> mgz: what problems do you think it has?
[18:08] <mgz> eg:
[18:08] <mgz> _fmt = 'Permission denied: "%(path)s"%(extra)s'
[18:09] <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:10] <mgz> the problem is the error module is pretty confused already, so it's hard to cleanly add in gettext
[18:12] <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:13] <mgz> currently _fmt is ascii (are there any exceptions?) so provided the inputs are only one or the other, we're fine
[18:14] <mgz> but if _fmt becomes some non-ascii utf-8 string from gettext, more things start breaking
[18:15] <mgz> so really you're exposing existing problems rather than creating new ones.
[18:16] <mgz> but using osutils.safe_unicode is just wrong ;)
[18:19] <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:20] <mgz> it's a check in the wrong place.
[18:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <mgz> then we break that error for anyone with LANG=C? doesn't seem worth it.
[18:31] <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:32] <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:33] <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:35] <jelmer> it would be neat if we could do it at byte-code compile time.. :)
[18:37] <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:38] <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:39] <Riddell> mgz: then this fails
[18:39] <Riddell> ./bzr selftest -s bzrlib.tests.test_errors.TestErrors.test_duplicate_record_name_error
[18:41] <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:42] <mgz> I'd make the exception decode the name.
[18:43] <mgz> -        self.name = name
[18:43] <mgz> +        self.name = name.decode("utf-8")
[18:43] <mgz> then the test would pass as written.
[18:44] <mgz> would be nice to delay that till the format step, but there's no simple way to do that.
[18:45] <Riddell> but aren't there other errors which will need the same?
[18:46] <mgz> probably, they're completely inconsistent at the moment.
[18:48] <mgz>     raise errors.DuplicateRecordNameError(name_tuple)
[18:48] <mgz> huh?
[18:48] <mgz> in bzrlib.pack  ...but... variable seems to be a string despite being having 'tuple' in the name
[18:49] <mgz> or, no, it is a tuple, that will something... gr...
[18:50] <mgz> Riddell: adding a test with an error _fmt string that's translated would be helpful I think...
[18:51] <mgz> maybe make the ZzzTranslations thing use more than just ascii?
[18:52] <mgz> then the test you added would fail.
[18:55] <Riddell> ok thanks mgz, I've got to go out now
[18:55] <mgz> bye! I'll write a few things in the mp.
[21:34] <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:35] <mgz> that certainly was an issue... there's a bug for it somewhere
[21:36] <mgz> bug 781140
[21:36] <aquarius_> aha
[21:37] <aquarius_> nice one :)
[22:05] <AuroraBorealis> so i'm trying out the 'sign always' thing in bzr where it uses my gpg key
[22:06] <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:07] <mwhudson> AuroraBorealis: it runs gpg
[22:07] <mwhudson> so if echo '' | gpg --clearsign works, probably bzr will to
[22:07] <mwhudson> o
[22:08] <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:23] <mwhudson> how can i make --show-base the default for merge ?
[22:23] <mwhudson> i guess an alias works
[23:32] <poolie> hi all
[23:40] <mgz> hey poolie.
[23:40] <poolie> hi there
[23:46] <mgz> confusing bug numbers... I thought launchpad just gave me the same thing twice
[23:47] <mgz> but it's 842223 and 842233