[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