[OE-core] [PATCH 3/6] lib/oe/patch: handle encoding differences in patch files
Paul Eggleton
paul.eggleton at linux.intel.com
Fri Jul 8 04:48:33 UTC 2016
On Wed, 06 Jul 2016 18:56:09 Khem Raj wrote:
> On Wed, Jul 6, 2016 at 6:45 PM, Paul Eggleton
> <paul.eggleton at linux.intel.com> wrote:
> > On Wed, 06 Jul 2016 17:40:03 Khem Raj wrote:
> >> On Wed, Jul 6, 2016 at 4:57 PM, Paul Eggleton
> >>
> >> <paul.eggleton at linux.intel.com> wrote:
> >> > With Python 3, the encoding of a file is significant; several recipes
> >> > in
> >> > OE-Core have patches which are not fully utf-8 decodable e.g. man,
> >> > lrzsz, and gstreamer1.0-libav, leading to errors when using devtool's
> >> > modify, upgrade or extract subcommands on these recipes. To work around
> >> > this, try reading the patch file as utf-8 first and if that fails try
> >> > latin-1 before giving up.
> >>
> >> while this makes devtool robust. I think it will also be a good
> >> opportunity to inform
> >> the user/developer of the utf-8 non compliant file and may be a hint
> >> on how to fix it if possible
> >
> > Sure, I could easily have it print a warning, but I'm not sure this is
> > going to be fixable for all cases. If the patch header is the source of
> > the non-UTF8 characters then it's easy, but what about if the code being
> > patched has non- UTF8 encoding? Surely in that case the patch has to
> > correspond?
>
> yes if the patch is patching a non UTF code for some reason then that
> may not be flagged.
I'm not about to dissect the patch in this context just to give a warning
though - either we succeed in decoding it or we don't. If we want to do so as
a test on incoming patches, we could, though I suspect we have bigger fish to
fry.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list