Merge lp:~jameinel/bzr-builddeb/unicode-author-508251 into lp:bzr-builddeb
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Merged at revision: | not available | ||||
| Proposed branch: | lp:~jameinel/bzr-builddeb/unicode-author-508251 | ||||
| Merge into: | lp:bzr-builddeb | ||||
| Diff against target: |
195 lines (+90/-8) 3 files modified
import_dsc.py (+2/-1) tests/test_util.py (+63/-0) util.py (+25/-7) |
||||
| To merge this branch: | bzr merge lp:~jameinel/bzr-builddeb/unicode-author-508251 | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Bzr-builddeb-hackers | 2010-02-18 | Pending | |
|
Review via email:
|
|||
| John A Meinel (jameinel) wrote : | # |
| James Westby (james-w) wrote : | # |
On Thu, 18 Feb 2010 22:17:12 -0000, John A Meinel <email address hidden> wrote:
> This is a basic fix for bug #508251. Specifically it:
Thanks.
> 1) Tries to decode using utf-8, if that fails it falls back to iso-8859-1. For now it also mutters the string it failed to decode. (might get a bit noisy, but it would let you know if there are issues with a given import.)
It will still cause failures if it can't be decoded in
iso-8859-1 either, is that what we want at this stage?
> 4) I also made sure to run this locally against 'gnome-panel' which was one of the failing imports. It has certainly gotten a lot farther, and I've check that it has run into a few of these mixed-encoding sections. Note that this assumes that each changelog block uses a constant encoding (for the purposes of commit message), but that actually seems reasonable. As dapper/
Thanks, I'll apply this once you tell me that this test didn't discover
any problems with the change (it obviously isn't blocked on any other
issues that might be found.)
Thanks,
James
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Westby wrote:
> On Thu, 18 Feb 2010 22:17:12 -0000, John A Meinel <email address hidden> wrote:
>> This is a basic fix for bug #508251. Specifically it:
>
> Thanks.
>
>> 1) Tries to decode using utf-8, if that fails it falls back to iso-8859-1. For now it also mutters the string it failed to decode. (might get a bit noisy, but it would let you know if there are issues with a given import.)
>
> It will still cause failures if it can't be decoded in
> iso-8859-1 either, is that what we want at this stage?
iso-8859-1 can decode all possible 8-bit sequences. Possibly
incorrectly, but all bits have a Unicode code point from iso-8859-1.
>
>> 4) I also made sure to run this locally against 'gnome-panel' which was one of the failing imports. It has certainly gotten a lot farther, and I've check that it has run into a few of these mixed-encoding sections. Note that this assumes that each changelog block uses a constant encoding (for the purposes of commit message), but that actually seems reasonable. As dapper/
>
> Thanks, I'll apply this once you tell me that this test didn't discover
> any problems with the change (it obviously isn't blocked on any other
> issues that might be found.)
>
> Thanks,
>
> James
>
The import succeeded. I don't have a way to tell the fidelity of the
result, etc.
I'm slightly concerned that a new import will give different results to
an old import (based on now finding an author that wasn't found before).
But I don't think the import system uses deterministic ids, so it should
be fine.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
YGoAnA9m45Pg/
=gAnd
-----END PGP SIGNATURE-----
| James Westby (james-w) wrote : | # |
On Fri, 19 Feb 2010 08:40:47 -0600, John Arbash Meinel <email address hidden> wrote:
> iso-8859-1 can decode all possible 8-bit sequences. Possibly
> incorrectly, but all bits have a Unicode code point from iso-8859-1.
Ok, so we'll have nonsense on occaision, but no failures. Sounds
reasonable to me.
> The import succeeded. I don't have a way to tell the fidelity of the
> result, etc.
> I'm slightly concerned that a new import will give different results to
> an old import (based on now finding an author that wasn't found before).
> But I don't think the import system uses deterministic ids, so it should
> be fine.
It doesn't use deterministic ids. I don't think it matters much that
there will be differences, there's not a lot we can do about that.
Thanks,
James
| James Westby (james-w) wrote : | # |
Oh, I'll merge this once I've finished the change I'm currently working
on.
Thanks,
James

This is a basic fix for bug #508251. Specifically it:
1) Tries to decode using utf-8, if that fails it falls back to iso-8859-1. For now it also mutters the string it failed to decode. (might get a bit noisy, but it would let you know if there are issues with a given import.)
2) Applies this to both author decoding *and* to the commit message. I think the author stuff hid the fact that the commit message was also broken. Basically, find_extra_authors decodes everything before bzr was going to get a chance at it. And bzr was always decoding 'message' as bzrlib. user_encoding, which I assume was always utf-8 for the import machine. Arguably it was succeeding 'by accident', rather than by design.
3) Changes 'find_thanks()' to allow names to start with a Unicode character, rather than requiring strictly A-Z. If you want, I can bring back "author[ 0].isupper( )" or something like that. Looking at the regex, if I said "Thanks to my cat" it seems reasonable to have 'deb-thanks': ['my cat'] even though it wasn't "Mr Cat". The "Thanks to" and "thank you" seem to be a decent filter, without having to worry about the exact name. If you want this changed to something else, just let me know.
I can restore the original behavior and change the tests, but it seemed reasonable to allow non-ascii as the first letter of someone's name. Given this changelog entry:
- Translators: Vital Khilko (be), Vladimir Petkov (bg), Hendrik
Brandt (de), Kostas Papadimas (el), Adam Weinberger (en_CA), Francisco
Javier F. Serrador (es), Ilkka Tuohela (fi), Ignacio Casal Quinteiro
(gl), Ankit Patel (gu), Luca Ferretti (it), Takeshi AIHANA (ja),
Žygimantas Beručka (lt), Øivind Hoel (nb), Reinout van Schouwen (nl),
Øivind Hoel (no), Evandro Fernandes Giovanini (pt_BR), Слободан Д.
Средојевић (sr), Theppitak Karoonboonyanan (th), Clytie Siddall (vi),
Funda Wang (zh_CN)
At least 3 of those people have non-ascii first letters (Žygimantas, Øivind, etc)
4) I also made sure to run this locally against 'gnome-panel' which was one of the failing imports. It has certainly gotten a lot farther, and I've check that it has run into a few of these mixed-encoding sections. Note that this assumes that each changelog block uses a constant encoding (for the purposes of commit message), but that actually seems reasonable. As dapper/ debian/ changelog switches back and forth from iso-8859-1 in some blocks to utf-8 in other blocks.