*Hi Jérémy,*

*I have successfully submitted the backport patch for the wrynose branch to
the list.*


*Thanks a lot!**Prabhudasu*


On Tue, Jun 9, 2026 at 1:15 PM Jeremy Rosen <[email protected]> wrote:

> Hello Prabhudasu
>
> I could not find an equivalent patch for wrynose (though I did find one
> for master)
> Please submit to wrynose and ping this mail once this is done
>
> thx a lot
> Jérémy
> On Mon Jun 1, 2026 at 2:10 AM CEST, Prabhudasu Vatala via
> lists.openembedded.org wrote:
> > Correct spelling errors in the machine include README documentation
> > for both ARM and x86 architectures to improve clarity.
> >
> > ARM changes:
> > - Fix TUNE_PKGACH -> TUNE_PKGARCH.
> > - Fix "definiton" -> "definition".
> > - Fix "Curently" -> "Currently".
> > - Fix "specificed" -> "specified".
> >
> > x86 changes:
> > - Fix "define" -> "defined".
> > - Fix "to to" duplication.
> >
> > Signed-off-by: Prabhudasu Vatala <[email protected]>
> > ---
> >  meta/conf/machine/include/arm/README | 6 +++---
> >  meta/conf/machine/include/x86/README | 4 ++--
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/arm/README
> b/meta/conf/machine/include/arm/README
> > index c5637798e6..bccbb1bdee 100644
> > --- a/meta/conf/machine/include/arm/README
> > +++ b/meta/conf/machine/include/arm/README
> > @@ -10,7 +10,7 @@ of the existence of the "bigendian" feature in a given
> tune.
> >
> >  A small set of ARM specific variables have been defined to allow
> >  TUNE_PKGARCH to be automatically defined.  Optimized tunings must NOT
> > -change the definiton of TUNE_PKGARCH.  TUNE_PKGACH:tune-<tune> will be
> > +change the definition of TUNE_PKGARCH.  TUNE_PKGARCH:tune-<tune> will
> be
> >  ignored.  The format of the package arch is enforced by the TUNE_PKGARCH
> >  default.  The format must be of the form:
> >  <armversion>[t][e][hf][b][-vfp][-neon]
> > @@ -22,14 +22,14 @@ ARMPKGARCH - This is the core package arch component
> specified by each
> >  tuning.  This is the primary identifier of a tuning.  Usual values are:
> >  arm, armv4, armv5, armv6, armv7a, etc.
> >
> > -ARMPKGSFX_THUMB - This is the thumb specific suffix.  Curently it is
> > +ARMPKGSFX_THUMB - This is the thumb specific suffix.  Currently it is
> >  defined in feature-arm-thumb.inc.
> >
> >  ARMPKGSFX_DSP - This is the DSP specific suffix.  Currently this is set
> >  to 'e' when on armv5 and the dsp feature is enabled.
> >
> >  ARMPKGSFX_EABI - This is the eabi specific suffix.  There are currently
> > -two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.
> > +two defined ABIs specified, standard EABI and Hard Float (VFP) EABI.
> >  When the callconvention-hard is enabled, "hf" is specified, otherwise
> it
> >  is blank.
> >
> > diff --git a/meta/conf/machine/include/x86/README
> b/meta/conf/machine/include/x86/README
> > index 05aee533a7..f0a1882d81 100644
> > --- a/meta/conf/machine/include/x86/README
> > +++ b/meta/conf/machine/include/x86/README
> > @@ -4,7 +4,7 @@
> >  Most of the items for the X86 architectures are defined in the single
> >  arch-x86 file.
> >
> > -Three ABIs are define, m32, mx32 and m64.
> > +Three ABIs are defined, m32, mx32 and m64.
> >
> >  The following is the list of X86 specific variables:
> >
> > @@ -17,7 +17,7 @@ The TUNE_PKGARCH is defined as follows:
> >  TUNE_PKGARCH = ${TUNE_PKGARCH:tune-${DEFAULTTUNE}}
> >
> >  The package architecture for 32-bit targets is historical and generally
> > -set to to match the core compatible processor type, i.e. i386.
> > +set to match the core compatible processor type, i.e. i386.
> >
> >  For 64-bit architectures, the architecture is expected to end in '_64'.
> >
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#238799): 
https://lists.openembedded.org/g/openembedded-core/message/238799
Mute This Topic: https://lists.openembedded.org/mt/119585447/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to