Re: [OE-core] [Openembedded-architecture] [yocto] Eclipse support dropped with immediate effect

[Scott Rifenbark]

Richard and Armin,

I am going to start pulling Eclipse from the docs today.  The changes won't
make the frozen rc build but the website docs will reflect reality.

Scott

On Thu, Apr 11, 2019 at 12:20 AM  wrote:

> On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote:
> >
> > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote:
> > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
> > > > On 4/9/19 8:52 PM, Richard Purdie wrote:
> > > > > I'm sorry to have to say this but the project is terminating
> > > > > its
> > > > > official eclipse plugin support with immediate effect.
> > > > Does this affect the stable branches as well?
> > > Yes, I think we'll just be removing the target from the autobuilder
> > > entirely.
> >
> > Have we every removed a feature from a release? Do we need to doc
> > this ?
>
> Its not so much remove as not release. No, we haven't and yes, we do
> need to document it in the release notes.
>
> Cheers,
>
> Richard
>
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW12'19

[Scott Rifenbark]

Hi,

Here is a "start" at publicly documenting QA... I started on this a while
back and got content from Richard only.  It would be good to have eyes on
this so it could be completed.  There are holes and stuff may have
changed.  If you want, please look it over and send me feedback.

See https://yoctoproject.org/docs/scott_temp/test-manual/test-manual.html

Thanks,
Scott

On Tue, Mar 19, 2019 at 8:53 AM  wrote:

> Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)
>
> Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019
>
>
>
> SWAT Team Rotation:
>
>- SWAT lead is currently: Armin
>- SWAT team rotation: Armin -> Paul on Mar. 23, 2019
>- SWAT team rotation: Paul -> Ross on Mar. 30, 2019
>- https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>
>
> Key Status/Updates:
>
>- M3 has not built yet however most major pieces are in place,
>including now, agreement on the new QA process. The delay is partly due to
>RP travel with others able to cover being unavailable for other reasons,
>combined with infrastructure issues.
>- The remaining questions for M3 are:
>   - Public documentation of the new QA process
>   - Upgrade for uninative for glibc 2.29
>   - Mesa upgrade? (unlikely given failures in testing)
>- The Yocto Project has updated to its new governance model which
>includes establishing a Technical Steering Committee (TSC) for Yocto
>Project. This is designed to complement  and work alongside the
>OpenEmbedded TSC. Three members of the YP TSC are selected by the Yocto
>Project governing board and those people are Ross Burton, Khem Raj and
>Richard Purdie. The remaining two seats will be elected by OpenEmbedded. It
>is intended the TSC will take over the release process, SWAT team, bug
>triage and feature planning/development for 2.8.
>- YP 2.5.3 continues to be blocked on autobuilder-helper changes for
>the stable branches and the resulttool changes in master to move to the new
>QA process.
>- There is discussion on the openembedded-architecture list about
>changes to the stable branch patch criteria to bring us more into line with
>current industry best practices and thinking.
>
>
>
> Planned Releases for YP 2.7:
>
>- YP 2.7 M3 Cutoff was Feb. 25, 2019
>- YP 2.7 M3 Release Target was Mar. 8, 2019
>- YP 2.7 M4 Cutoff is Apr. 1, 2019
>- YP 2.7 M4 Release Target is Apr. 26, 2019
>
>
>
> Planned upcoming dot releases:
>
>- YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
>- YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
>- YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.
>
>
>
> Tracking Metrics:
>
>- WDD 2432 (last week 2439) (
>https://wiki.yoctoproject.org/charts/combo.html)
>- Poky Patch Metrics
>   - Total patches found: 1526 (last week 1523)
>   - Patches in the Pending State: 656 (43%) [last week 657 (43%)]
>
>
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features
>
>
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>
>
> [If anyone has suggestions for other information you’d like to see on this
> weekly status update, let us know!]
>
>
>
> Thanks,
>
>
>
> *Stephen K. Jolley*
>
> *Yocto Project Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Information about non-traditional uses of the Yocto Project and OpenEmbedded

[Scott Rifenbark]

Sounds like good potential for a section or chapter in the user docs.

Scott

On Wed, Feb 27, 2019 at 12:01 PM Philip Balister 
wrote:

> During the last OpenEmbedded developer meeting, it became clear that
> people are using the Yocto project/OpenEmbedded in spaces outside what
> we think of as traditional embedded. Lieu Ta is working on a
> presentation for the Linux Foundation Leadership Summit and we would
> like to collect as many "unusual" applications are possible from
> companies we can publicly acknowledge. Unusual is edge, containers,
> desktop, etc. Or even really interesting embedded applications :)
>
> Please drop me an email (off list is fine) with enough info for us to
> add you to a slide and acknowledge your work.
>
> Thanks,
>
> Philip
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V4] default-distrovars: Drop DISTRO_FEATURES_LIBC

[Scott Rifenbark]

Hi,

DISTRO_FEATURES_DEFAULT appears in the YP reference manual.  I am going to
remove it for 2.7.

Scott

On Tue, Feb 26, 2019 at 10:03 AM Khem Raj  wrote:

> After eglibc was merged into glibc, Kconfig support was also dropped so
> these libc features therefore are not effective anymore and can be
> removed
>
> Signed-off-by: Khem Raj 
> ---
> v2:
> - Add ipv4 and ipv6 to default distro features, they are not libc
>   specific anyway
> - Remove DISTRO_FEATURES_DEFAULT as this is redundant now
>
> v3:
> - Remove the use of libc-* overrides in metadata
>
> v4:
> - Cleanup further to simplify variable assignments
>
>  meta/classes/image.bbclass|  5 -
>  meta/classes/libc-package.bbclass |  9 +++--
>  meta/conf/bitbake.conf|  4 ++--
>  .../distro/include/default-distrovars.inc | 11 +--
>  meta/conf/distro/include/tclibc-glibc.inc | 19 +--
>  meta/conf/local.conf.sample.extended  | 16 ++--
>  meta/recipes-core/glib-2.0/glib.inc   |  2 --
>  meta/recipes-core/glibc/glibc_2.29.bb |  3 +--
>  meta/recipes-core/libxml/libxml2_2.9.8.bb |  2 --
>  meta/recipes-devtools/mtools/mtools_4.0.19.bb |  2 --
>  .../findutils/findutils_4.6.0.bb  |  2 +-
>  meta/recipes-extended/shadow/shadow.inc   |  2 +-
>  meta/recipes-extended/shadow/shadow_4.6.bb|  2 +-
>  13 files changed, 17 insertions(+), 62 deletions(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 11927f39f5..276d0d31f4 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -176,11 +176,6 @@ IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
>
>  LINGUAS_INSTALL ?= "${@" ".join(map(lambda s: "locale-base-%s" % s,
> d.getVar('IMAGE_LINGUAS').split()))}"
>
> -python () {
> -if not bb.utils.contains('DISTRO_FEATURES', 'libc-charsets
> libc-locale-code libc-locales', True, False, d):
> -d.setVar('IMAGE_LINGUAS', '')
> -}
> -
>  # Prefer image, but use the fallback files for lookups if the image ones
>  # aren't yet available.
>  PSEUDO_PASSWD = "${IMAGE_ROOTFS}:${STAGING_DIR_NATIVE}"
> diff --git a/meta/classes/libc-package.bbclass
> b/meta/classes/libc-package.bbclass
> index 34c9151ae9..8859dad566 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -37,14 +37,11 @@ python __anonymous () {
>  d.setVar("DEPENDS", depends)
>  d.setVar("GLIBC_INTERNAL_USE_BINARY_LOCALE", "compile")
>  break
> -
> -# try to fix disable charsets/locales/locale-code compile fail
> -if bb.utils.contains('DISTRO_FEATURES', 'libc-charsets libc-locales
> libc-locale-code', True, False, d):
> -d.setVar('PACKAGE_NO_GCONV', '0')
> -else:
> -d.setVar('PACKAGE_NO_GCONV', '1')
>  }
>
> +# try to fix disable charsets/locales/locale-code compile fail
> +PACKAGE_NO_GCONV ?= "0"
> +
>  OVERRIDES_append = ":${TARGET_ARCH}-${TARGET_OS}"
>
>  locale_base_postinst_ontarget() {
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 435646a946..1c5369ec98 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -123,7 +123,7 @@ TUNE_ASARGS ??= ""
>  TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
>  LIBCEXTENSION ??= ""
>  ABIEXTENSION ??= ""
> -USE_NLS ??= "${@bb.utils.contains('DISTRO_FEATURES', 'libc-locale-code',
> 'yes', 'no', d)}"
> +USE_NLS ??= "yes"
>  SDKUSE_NLS ??= "yes"
>
>  TARGET_ARCH = "${TUNE_ARCH}"
> @@ -820,7 +820,7 @@ IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
>  # Native distro features (will always be used for -native, even if they
>  # are not enabled for target)
>  DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"
> -DISTRO_FEATURES_NATIVESDK ?= "x11 libc-charsets libc-locales
> libc-locale-code"
> +DISTRO_FEATURES_NATIVESDK ?= "x11"
>
>  # Normally target distro features will not be applied to native builds:
>  # Native distro features on this list will use the target feature value
> diff --git a/meta/conf/distro/include/default-distrovars.inc
> b/meta/conf/distro/include/default-distrovars.inc
> index 76edff6480..d57329ec17 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -10,16 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
>  LOCALE_UTF8_IS_DEFAULT ?= "1"
>  LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
>
> -DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 irda largefile
> pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11"
> -DISTRO_FEATURES_LIBC_DEFAULT ?= "ipv4 ipv6 libc-backtrace libc-big-macros
> libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
> -   libc-crypt-ufc libc-db-aliases
> libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
> -   libc-getlogin libc-idn
> libc-inet-anl libc-libm libc-locales libc-locale-code \
> -

Re: [OE-core] [PATCH] default-distrovars: Drop DISTRO_FEATURES_LIBC

[Scott Rifenbark]

Hi,

The DISTRO_FEATURES_LIBC variable appears in the YP reference manual.  Will
it be safe to remove this for the 2.7 release?

Scott

On Mon, Feb 25, 2019 at 11:00 AM Khem Raj  wrote:

> After eglibc was merged into glibc, Kconfig support was also dropped so
> these libc features therefore are not effective anymore and can be
> removed
>
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/distro/include/default-distrovars.inc | 10 +-
>  meta/conf/local.conf.sample.extended| 16 ++--
>  2 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/meta/conf/distro/include/default-distrovars.inc
> b/meta/conf/distro/include/default-distrovars.inc
> index 76edff6480..35da7f10e1 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -11,15 +11,7 @@ LOCALE_UTF8_IS_DEFAULT ?= "1"
>  LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
>
>  DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 irda largefile
> pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11"
> -DISTRO_FEATURES_LIBC_DEFAULT ?= "ipv4 ipv6 libc-backtrace libc-big-macros
> libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
> -   libc-crypt-ufc libc-db-aliases
> libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
> -   libc-getlogin libc-idn
> libc-inet-anl libc-libm libc-locales libc-locale-code \
> -   libc-memusage libc-nsswitch
> libc-rcmd libc-rtld-debug libc-spawn libc-streams \
> -   libc-utmp libc-utmpx libc-wordexp
> libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc \
> -   libc-posix-wchar-io"
> -DISTRO_FEATURES_LIBC ?= "${DISTRO_FEATURES_LIBC_DEFAULT}"
> -DISTRO_FEATURES_LIBC_class-nativesdk = "${DISTRO_FEATURES_LIBC_DEFAULT}"
> -DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}"
> +DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
>
>  IMAGE_FEATURES ?= ""
>
> diff --git a/meta/conf/local.conf.sample.extended
> b/meta/conf/local.conf.sample.extended
> index 010bf6ca6f..91e321047f 100644
> --- a/meta/conf/local.conf.sample.extended
> +++ b/meta/conf/local.conf.sample.extended
> @@ -24,22 +24,10 @@
>  # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j
> 4" would
>  # be appropriate for example.
>
> -
> -# glibc configurability is used to reduce minimal image's size.
> -# the all supported glibc options are listed in DISTRO_FEATURES_LIBC
> -# and disabled by default. Uncomment and copy the DISTRO_FEATURES_LIBC
> -# and DISTRO_FEATURES definitions to local.conf to enable the options.
> -#DISTRO_FEATURES_LIBC = "ipv6 libc-backtrace libc-big-macros libc-bsd
> libc-cxx-tests libc-catgets libc-charsets libc-crypt \
> -#   libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt
> libc-fmtmsg libc-fstab libc-ftraverse \
> -#   libc-getlogin libc-idn libc-inet libc-inet-anl libc-libm
> libc-locales libc-locale-code \
> -#   libc-memusage libc-nsswitch libc-rcmd libc-rtld-debug
> libc-spawn libc-streams \
> -#   libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar
> libc-posix-regexp libc-posix-regexp-glibc \
> -#   libc-posix-wchar-io"
> -
> -#DISTRO_FEATURES = "alsa bluetooth ext2 irda pcmcia usbgadget usbhost
> wifi nfs zeroconf pci ${DISTRO_FEATURES_LIBC}"
> +#DISTRO_FEATURES = "alsa bluetooth ext2 irda pcmcia usbgadget usbhost
> wifi nfs zeroconf pci"
>
>  # If you want to get an image based on directfb without x11, Please copy
> this variable to build/conf/local.conf
> -#DISTRO_FEATURES = "alsa argp bluetooth ext2 irda largefile pcmcia
> usbgadget usbhost wifi xattr nfs zeroconf pci 3g directfb
> ${DISTRO_FEATURES_LIBC}"
> +#DISTRO_FEATURES = "alsa argp bluetooth ext2 irda largefile pcmcia
> usbgadget usbhost wifi xattr nfs zeroconf pci 3g directfb"
>
>  # ENABLE_BINARY_LOCALE_GENERATION controls the generation of binary locale
>  # packages at build time using qemu-native. Disabling it (by setting it
> to 0)
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] opkg: add --ignore-recommends flag

[Scott Rifenbark]

On Thu, Feb 7, 2019 at 9:44 AM Alejandro Del Castillo <
alejandro.delcasti...@ni.com> wrote:

>
>
> On 2/7/19 11:36 AM, Scott Rifenbark wrote:
> > This change looks like it impacts documentation (i.e.
> >
> https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS.
>
> > When will this change go into effect?
>
> I believe it doesn't. It is refactoring the opkg implementation to
> leverage a new opkg feature (--add-ignore-recommends), which is a more
> robust implementation. Should be transparent to users.
>

Thank you for the clarification... I thought it might be a user option.


> > On Thu, Feb 7, 2019 at 7:58 AM Alejandro del Castillo
> > mailto:alejandro.delcasti...@ni.com>>
> wrote:
> >
> > To be used for BAD_RECOMMENDATIONS feature.
> >
> > Signed-off-by: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > ---
> >   ...pkg-add-add-ignore-recommends-option.patch | 259
> ++
> >   meta/recipes-devtools/opkg/opkg_0.4.0.bb
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__opkg-5F0.4.0.bb=DwMFaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=8hd_9vew95YIf_VIv2QHNu2EFnc3G2WZ5KA2Upnv5j8=JvgzuAyAoVrkeSZAdWZUuIsFWQ8okApbCk1iiF13CDc=>
>
> >  |   1 +
> >   2 files changed, 260 insertions(+)
> >   create mode 100644
> >
>  
> meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> >
> > diff --git
> >
>  
> a/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> >
>  
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> > new file mode 100644
> > index 00..47d1b3c37e
> > --- /dev/null
> > +++
> >
>  
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> > @@ -0,0 +1,259 @@
> > +From 64aa98646a17c299bf37af2975b98daf5d7d30b4 Mon Sep 17 00:00:00
> 2001
> > +From: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > +Date: Thu, 31 Jan 2019 18:16:08 -0600
> > +Subject: [PATCH] libopkg: add --add-ignore-recommends option
> > +
> > +Add option to ignore specific recommended packages. On the libsolv
> > +backed, this feature will only work on libsolv version > 0.7.2 [1].
> > +
> > +[1]
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openSUSE_libsolv_issues_254=DwIBaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=GObNHzFJpWpf_PripIrf-K2RhsktYdAUEieAJexXOKw=3G-meChUqClFggFPqsrAxIZBfLnRKIHm62Uuy1X6nQQ=
> > +
> > +Signed-off-by: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > +
> > +Upstream-Status: Accepted
> > +---
> > + libopkg/opkg_conf.c   |  2 +
> > + libopkg/opkg_conf.h   |  1 +
> > + .../solvers/internal/pkg_depends_internal.c   |  3 +-
> > + libopkg/solvers/libsolv/opkg_solver_libsolv.c | 21 ++-
> > + man/opkg.1.in
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__opkg.1.in=DwMFaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=8hd_9vew95YIf_VIv2QHNu2EFnc3G2WZ5KA2Upnv5j8=8yIWRVT6JV0YnkHzVgeo8pAkiFPM4xz8y9APvxobmhY=>
>
> > |  3 +
> > + src/opkg.c|  6 ++
> > + tests/Makefile|  1 +
> > + tests/core/43_add_ignore_recommends.py| 62
> +++
> > + 8 files changed, 97 insertions(+), 2 deletions(-)
> > + create mode 100755 tests/core/43_add_ignore_recommends.py
> > +
> > +diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
> > +index 06880a1..f2330cd 100644
> > +--- a/libopkg/opkg_conf.c
> >  b/libopkg/opkg_conf.c
> > +@@ -597,6 +597,7 @@ int opkg_conf_init(void)
> > + pkg_dest_list_init(_config->tmp_dest_list);
> > + nv_pair_list_init(_config->arch_list);
> > + str_list_init(_config->exclude_list);
> > ++str_list_init(_config->ignore_recommends_list);
> > +
> > + return 0;
> > + }
> > +@@ -938,6 +939,7 @@ void opkg_conf_deinit(void)
> > + pkg_dest_list_deinit(_config->pkg_dest_list);
> > + nv_pair_

Re: [OE-core] [PATCH 1/3] opkg: add --ignore-recommends flag

[Scott Rifenbark]

This change looks like it impacts documentation (i.e.
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS).
When will this change go into effect?

Scott

On Thu, Feb 7, 2019 at 7:58 AM Alejandro del Castillo <
alejandro.delcasti...@ni.com> wrote:

> To be used for BAD_RECOMMENDATIONS feature.
>
> Signed-off-by: Alejandro del Castillo 
> ---
>  ...pkg-add-add-ignore-recommends-option.patch | 259 ++
>  meta/recipes-devtools/opkg/opkg_0.4.0.bb  |   1 +
>  2 files changed, 260 insertions(+)
>  create mode 100644
> meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
>
> diff --git
> a/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> new file mode 100644
> index 00..47d1b3c37e
> --- /dev/null
> +++
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> @@ -0,0 +1,259 @@
> +From 64aa98646a17c299bf37af2975b98daf5d7d30b4 Mon Sep 17 00:00:00 2001
> +From: Alejandro del Castillo 
> +Date: Thu, 31 Jan 2019 18:16:08 -0600
> +Subject: [PATCH] libopkg: add --add-ignore-recommends option
> +
> +Add option to ignore specific recommended packages. On the libsolv
> +backed, this feature will only work on libsolv version > 0.7.2 [1].
> +
> +[1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openSUSE_libsolv_issues_254=DwIBaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=GObNHzFJpWpf_PripIrf-K2RhsktYdAUEieAJexXOKw=3G-meChUqClFggFPqsrAxIZBfLnRKIHm62Uuy1X6nQQ=
> +
> +Signed-off-by: Alejandro del Castillo 
> +
> +Upstream-Status: Accepted
> +---
> + libopkg/opkg_conf.c   |  2 +
> + libopkg/opkg_conf.h   |  1 +
> + .../solvers/internal/pkg_depends_internal.c   |  3 +-
> + libopkg/solvers/libsolv/opkg_solver_libsolv.c | 21 ++-
> + man/opkg.1.in |  3 +
> + src/opkg.c|  6 ++
> + tests/Makefile|  1 +
> + tests/core/43_add_ignore_recommends.py| 62 +++
> + 8 files changed, 97 insertions(+), 2 deletions(-)
> + create mode 100755 tests/core/43_add_ignore_recommends.py
> +
> +diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
> +index 06880a1..f2330cd 100644
> +--- a/libopkg/opkg_conf.c
>  b/libopkg/opkg_conf.c
> +@@ -597,6 +597,7 @@ int opkg_conf_init(void)
> + pkg_dest_list_init(_config->tmp_dest_list);
> + nv_pair_list_init(_config->arch_list);
> + str_list_init(_config->exclude_list);
> ++str_list_init(_config->ignore_recommends_list);
> +
> + return 0;
> + }
> +@@ -938,6 +939,7 @@ void opkg_conf_deinit(void)
> + pkg_dest_list_deinit(_config->pkg_dest_list);
> + nv_pair_list_deinit(_config->arch_list);
> + str_list_deinit(_config->exclude_list);
> ++str_list_deinit(_config->ignore_recommends_list);
> +
> + if (opkg_config->verbosity >= DEBUG) {
> + hash_print_stats(_config->pkg_hash);
> +diff --git a/libopkg/opkg_conf.h b/libopkg/opkg_conf.h
> +index eb56a29..316c500 100644
> +--- a/libopkg/opkg_conf.h
>  b/libopkg/opkg_conf.h
> +@@ -61,6 +61,7 @@ typedef struct opkg_conf {
> + pkg_dest_list_t tmp_dest_list;
> + nv_pair_list_t arch_list;
> + str_list_t exclude_list;
> ++str_list_t ignore_recommends_list;
> +
> + int restrict_to_default_dest;
> + pkg_dest_t *default_dest;
> +diff --git a/libopkg/solvers/internal/pkg_depends_internal.c
> b/libopkg/solvers/internal/pkg_depends_internal.c
> +index cd56d84..5deee70 100644
> +--- a/libopkg/solvers/internal/pkg_depends_internal.c
>  b/libopkg/solvers/internal/pkg_depends_internal.c
> +@@ -228,7 +228,8 @@ int pkg_hash_fetch_unsatisfied_dependencies(pkg_t
> *pkg,
> + || compound_depend->type == SUGGEST)
> + && (satisfying_pkg->state_want == SW_DEINSTALL
> + || satisfying_pkg->state_want == SW_PURGE
> +-|| opkg_config->no_install_recommends);
> ++|| opkg_config->no_install_recommends
> ++||
> str_list_contains(_config->ignore_recommends_list,
> satisfying_pkg->name));
> + if (ignore) {
> + opkg_msg(NOTICE,
> +  "%s: ignoring recommendation for "
> +diff --git a/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> b/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> +index 2b27e3a..403e07b 100644
> +--- a/libopkg/solvers/libsolv/opkg_solver_libsolv.c
>  b/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> +@@ -484,6 +484,7 @@ static void pkg2solvable(pkg_t *pkg, Solvable
> *solvable_out)
> + static void populate_installed_repo(libsolv_solver_t *libsolv_solver)
> + {
> + int i;
> ++Id what;
> +
> + 

Re: [OE-core] [thud] [PATCH] Ubuntu 16.10 is not LTS

[Scott Rifenbark]

Adrian,

Thanks for catching this.  I have updated the list of supported distros for
the 2.7 (master) version of the ref-manual.  I will make sure that the fix
is also in the 2.6.1 release that is pending and the published 2.6
ref-manual (thud branch).  See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#detailed-supported-distros
for the updated list and
https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros.


Thanks,
Scott

On Wed, Jan 30, 2019 at 1:38 AM Adrian Bunk  wrote:

> Signed-off-by: Adrian Bunk 
> ---
>  documentation/ref-manual/ref-system-requirements.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/ref-manual/ref-system-requirements.xml
> b/documentation/ref-manual/ref-system-requirements.xml
> index 69d4b4e726..500b2f8f39 100644
> --- a/documentation/ref-manual/ref-system-requirements.xml
> +++ b/documentation/ref-manual/ref-system-requirements.xml
> @@ -97,7 +97,7 @@
>  Ubuntu 15.04
>  Ubuntu 15.10 -->
>  Ubuntu 16.04 (LTS)
> -Ubuntu 16.10 (LTS)
> +Ubuntu 16.10
>  Ubuntu 17.04
>   2.11.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Help needed with ptest

[Scott Rifenbark]

Hmm... do we want to expand on the "running ptests" section in the
documentation to include some stuff about viewing and analyzing results?
We currently have this section here ...
https://yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#testing-packages-with-ptest

Scott

On Mon, Jan 28, 2019 at 3:39 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> We now have better data than ever before on the status of the project
> from a test results perspective. In particular we can now easily
> collect ptest data.
>
> I triggered the tests for qemux86-64 on the autobuilder yesterday, the
> results are published and you can see them with:
>
> wget
> https://autobuilder.yocto.io/pub/non-release/20190127-9/testresults/qemux86-64-ptest/testresults.json
>
> To show the raw logs you can quickly hack to make then more readable:
>
> cat testresults.json  | sed 's/\\n/\n/g'  > testresults1.json
>
> and there are numerous worrying things when you read them such as if
> you grep for "TIMEOUT:".
>
> I also have a suspicion that some ptest runners are exiting without
> cleaning up all processes resulting in corrupted output later in the
> logs too, I saw something like that locally, I think for perl. More
> investigation is needed for that.
>
> There are multiple areas that could do with help:
>
> a) investigate/fix the timeouts
> b) improve the test results tool Ee Peng has posted to include ptest
> processing tools:
>  i) view the logs
>  ii) compare the results
>  iii) highlight timeouts
>  iv) summarise durations
> c) Split logs into individual ptest runs instead of one block
> d) record the timings for the individual ptest blocks
> e) Add timeout status for tests into the json so we can explicitly test
> for it.
>
> I'd welcome help from anyone in any of the above areas, we probably
> need to create feature enhancement bugs for them.
>
> Cheers,
>
> Richard
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH 3/3] devtool: provide support for devtool menuconfig command.

[Scott Rifenbark]

Hi,

This probably has documentation ramifications yes?  See
https://yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#ref-devtool-reference
.

Thanks,
Scott

On Wed, Dec 5, 2018 at 8:27 AM Sai Hari Chandana Kalluri <
chandana.kall...@xilinx.com> wrote:

> All packages that support the menuconfig task will be able to run devtool
> menuconfig command. This would allow the user to modify the current
> configure options and create a config fragment which can be added to a
> recipe using devtool finish.
>
> 1. The patch checks if devtool menuconfig command is called for a valid
> package.
> 2. It checks for oe-local-files dir within source and creates one
> if needed, this directory is needed to store the final generated config
> fragment so that devtool finish can update the recipe.
> 3. Menuconfig command is called for users to make necessary changes. After
> saving the changes, diffconfig command is run to generate the fragment.
>
> Syntax:
> devtool menuconfig 
>  Ex: devtool menuconfig linux-yocto
>
> The config fragment is saved as devtool-fragment.cfg within
> oe-local-files dir.
>
> Ex:
> /sources/linux-yocto/oe-local-files/devtool-fragment.cfg
>
> Run devtool finish to update the recipe by appending the config fragment
> to SRC_URI and place a copy of the fragment within the layer where the
> recipe resides.
> Ex: devtool finish linux-yocto meta
>
> [YOCTO #10416]
>
> Signed-off-by: Sai Hari Chandana Kalluri 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> ---
>  scripts/lib/devtool/menuconfig.py | 80
> +++
>  1 file changed, 80 insertions(+)
>  create mode 100644 scripts/lib/devtool/menuconfig.py
>
> diff --git a/scripts/lib/devtool/menuconfig.py
> b/scripts/lib/devtool/menuconfig.py
> new file mode 100644
> index 000..38133db
> --- /dev/null
> +++ b/scripts/lib/devtool/menuconfig.py
> @@ -0,0 +1,80 @@
> +# OpenEmbedded Development tool - menuconfig command plugin
> +#
> +# Copyright (C) 2018 Xilinx
> +# Written by: Chandana Kalluri 
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +
> +"""Devtool menuconfig plugin"""
> +
> +import os
> +import bb
> +import logging
> +import argparse
> +import re
> +import glob
> +from devtool import setup_tinfoil, parse_recipe, DevtoolError, standard,
> exec_build_env_command
> +
> +logger = logging.getLogger('devtool')
> +
> +def menuconfig(args, config, basepath, workspace):
> +"""Entry point for the devtool 'menuconfig' subcommand"""
> +
> +rd = ""
> +kconfigpath = ""
> +pn_src = ""
> +localfilesdir = ""
> +workspace_dir = ""
> +tinfoil = setup_tinfoil(basepath=basepath)
> +try:
> +  rd = parse_recipe(config, tinfoil, args.component, appends=True,
> filter_workspace=False)
> +  if not rd:
> + return 1
> +
> +  pn =  rd.getVar('PN', True)
> +  if pn not in workspace:
> + raise DevtoolError("Run devtool modify before calling menuconfig
> for %s" %pn)
> +
> +  if not rd.getVarFlag('do_menuconfig','task'):
> + raise DevtoolError("This package does not support menuconfig
> option")
> +
> +  workspace_dir = os.path.join(basepath,'workspace/sources')
> +  kconfigpath = rd.getVar('B')
> +  pn_src = os.path.join(workspace_dir,pn)
> +
> +  #add check to see if oe_local_files exists or not
> +  localfilesdir = os.path.join(pn_src,'oe-local-files')
> +  if not os.path.exists(localfilesdir):
> +  bb.utils.mkdirhier(localfilesdir)
> +  #Add gitignore to ensure source tree is clean
> +  gitignorefile = os.path.join(localfilesdir,'.gitignore')
> +  with open(gitignorefile, 'w') as f:
> +  f.write('# Ignore local files, by default. Remove this
> file if you want to commit the directory to Git\n')
> +  f.write('*\n')
> +
> +finally:
> +  tinfoil.shutdown()
> +
> +logger.info('Launching menuconfig')
> +exec_build_env_command(config.init_path, basepath, 'bitbake -c
> menuconfig %s' % pn, watch=True)
> +fragment = os.path.join(localfilesdir, 'devtool-fragment.cfg')
> +res = standard._create_kconfig_diff(pn_src,rd,fragment)
> +
> +return 0
> +
> +def register_commands(subparsers, context):
> +"""register devtool subcommands from this plugin"""
> +parser_menuconfig = 

Re: [OE-core] [PATCH] doc: drop some incorrect instructions

[Scott Rifenbark]

Ming,

I could not simply apply this patch.  I had to do some re-writing for
clarity.  Please look at this link to the updated section on the
image_types class and let me know if this is technically correct.

https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-classes-image_types

Thanks,
Scott

On Wed, Nov 14, 2018 at 11:06 AM  wrote:

> From: Ming Liu 
>
> image_types bbclass now is being inherited mandatorily in image.bbclass
> through the variable IMGCLASSES, and the users do not have to inherit
> it in their customized image type bbclass, or put it in IMAGE_CLASSES.
>
> Drop the incorrect descriptions, it's confusing the developers.
>
> Signed-off-by: Ming Liu 
> ---
>  documentation/ref-manual/ref-classes.xml | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-classes.xml
> b/documentation/ref-manual/ref-classes.xml
> index 24d7a0a..876e242 100644
> --- a/documentation/ref-manual/ref-classes.xml
> +++ b/documentation/ref-manual/ref-classes.xml
> @@ -1275,15 +1275,10 @@
>  
>
>  
> -By default, this class is enabled through the
> - linkend='var-IMAGE_CLASSES'>IMAGE_CLASSES
> -variable in
> +By default, this class is enabled mandatorily in
>   linkend='ref-classes-image'>image.bbclass.
>  If you define your own image types using a custom BitBake class
> and
> -then use IMAGE_CLASSES to enable it, the
> custom
> -class must either inherit image_types or
> -image_types must also appear in
> -IMAGE_CLASSES.
> +then use IMAGE_CLASSES to enable it.
>  
>
>  
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 2.6 migration guide

[Scott Rifenbark]

Peter,

Thanks
Scott

https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-openssl-changes
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-security-changes

On Fri, Nov 2, 2018 at 8:10 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> In “4.14.2. OpenSSL Changes”, change “both versions their dependency
> chains” to “both versions in their dependency chains”.
>
> In “4.14.4. Security Changes”, change “files” to “flags” (twice).
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org <
> openembedded-core-boun...@lists.openembedded.org> *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 30 oktober 2018 23:07
> *To:* Paul Eggleton 
> *Cc:* Yocto discussion list ; openembedded-core <
> openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 migration guide
>
>
>
> Paul,
>
>
>
> Thanks for sending.
>
>
>
> Contributors
>
>
>
> I have an initial section at
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
> which is based on Richard's input.  I am sure there are more items.
>
>
>
> Thanks,
>
> Scott
>
>
>
> On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] 2.6 migration guide

[Scott Rifenbark]

Got it, thanks.

On Wed, Oct 31, 2018 at 9:02 AM Bas Mevissen  wrote:

> On 2018-10-31 16:50, Scott Rifenbark wrote:
>
> > Can you tell me why "123456" is also not removed?  That string contains
> > instances of "123" and "456"
>
>
> Because it removes all occurrences of the list value "123" and not of
> value "123456" or any part of it. Otherwise, it would be impossible to
> use this function to only remove, say, "1" from a long list of numbers.
> (here 'value' is not limited to a number).
>
> -- Bas.
>
> >
> > Thanks,
> > Scott
> >
> > On Wed, Oct 31, 2018 at 12:15 AM Robert Berger
> >  wrote:
> >
> >> Hi Scott,
> >>
> >> On 31.10.18 00:06, Scott Rifenbark wrote:
> >>>
> >>> I have an initial section at
> >>>
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release
> ,
> >>> which is based on Richard's input.  I am sure there are more items.
> >>
> >> You might want to add a link to the bitbake manual or some example
> >> from
> >> there for the new functionality of _remove operator:
> >>
> >>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
> >>
> >> FOO = "123 456 789 123456 123 456 123 456"
> >> FOO_remove = "123"
> >> FOO_remove = "456"
> >>
> >> FOO is now: "  789 123456" instead of "789 123456"
> >>
> >>>
> >>> Thanks,
> >>> Scott
> >>
> >> Regards,
> >>
> >> Robert
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] 2.6 migration guide

[Scott Rifenbark]

Can you tell me why "123456" is also not removed?  That string contains
instances of "123" and "456"

Thanks,
Scott

On Wed, Oct 31, 2018 at 12:15 AM Robert Berger <
yocto.user.mailingl...@gmail.com> wrote:

> Hi Scott,
>
> On 31.10.18 00:06, Scott Rifenbark wrote:
> >
> > I have an initial section at
> >
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
>
> > which is based on Richard's input.  I am sure there are more items.
>
> You might want to add a link to the bitbake manual or some example from
> there for the new functionality of _remove operator:
>
>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
>
> FOO = "123 456 789 123456 123 456 123 456"
> FOO_remove = "123"
> FOO_remove = "456"
>
> FOO is now: "  789 123456" instead of "789 123456"
>
> >
> > Thanks,
> > Scott
>
> Regards,
>
> Robert
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] 2.6 migration guide

[Scott Rifenbark]

Thanks Robert...  I will do that.

Scott

On Wed, Oct 31, 2018 at 12:15 AM Robert Berger <
yocto.user.mailingl...@gmail.com> wrote:

> Hi Scott,
>
> On 31.10.18 00:06, Scott Rifenbark wrote:
> >
> > I have an initial section at
> >
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
>
> > which is based on Richard's input.  I am sure there are more items.
>
> You might want to add a link to the bitbake manual or some example from
> there for the new functionality of _remove operator:
>
>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
>
> FOO = "123 456 789 123456 123 456 123 456"
> FOO_remove = "123"
> FOO_remove = "456"
>
> FOO is now: "  789 123456" instead of "789 123456"
>
> >
> > Thanks,
> > Scott
>
> Regards,
>
> Robert
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 2.6 migration guide

[Scott Rifenbark]

Paul,

Thanks for sending.

Contributors

I have an initial section at
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
which is based on Richard's input.  I am sure there are more items.

Thanks,
Scott

On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton 
wrote:

> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] layer.conf: Add thud to LAYERSERIES_CORENAMES

[Scott Rifenbark]

Hi,

Manual updated for LAYERSERIES_COMPAT variable.  All examples use ENTITY
variables so as releases change the examples do not go stale.

Scott

On Mon, Sep 24, 2018 at 4:30 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> With the release approaching, add thud to LAYERSERIES_CORENAMES and update
> oe-core to use this release series. "sumo" will be removed during M4 in
> the next couple of weeks so people need to start updating their master
> layers in preperation for release.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/layer.conf | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 2cbe952801f..0728c51e5fd 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -7,12 +7,12 @@ BBFILE_COLLECTIONS += "core"
>  BBFILE_PATTERN_core = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_core = "5"
>
> -LAYERSERIES_CORENAMES = "sumo"
> +LAYERSERIES_CORENAMES = "sumo thud"
>
>  # This should only be incremented on significant changes that will
>  # cause compatibility issues with other layers
>  LAYERVERSION_core = "11"
> -LAYERSERIES_COMPAT_core = "sumo"
> +LAYERSERIES_COMPAT_core = "thud"
>
>  BBLAYERS_LAYERINDEX_NAME_core = "openembedded-core"
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 14/14] babeltrace: switch over to git

[Scott Rifenbark]

Obviously that class (devupstream.bbclass) is not in the YP reference
manual.  I will open a bug to document it.

Scott

On Fri, May 4, 2018 at 6:12 AM, Paulo Neves  wrote:

> On Fri, May 4, 2018 at 2:55 PM, Burton, Ross 
> wrote:
> > On 4 May 2018 at 13:46, Paulo Neves  wrote:
> >>
> >> I always wondered, what is the rationale for not always using the git
> >> repositories? If there is one why did we change for this specific
> >> recipe?
> >
> >
> > Tarballs are easier to mirror, smaller, have checksums to verify the
> > download at both fetch and unpack time, and often contain generated files
> > which otherwise require yet more tools to regenerate (for example, man
> pages
> > may require a documentation toolchain to build from git but will be
> included
> > in a tarball).
> In my case we have a requirement of using the git repositories because
> of the easiness with which we can make code bissections, as well as
> back porting.
>
> >>
> >> I ask this because I am in the process of creating a massive layer,
> >> whose only purpose is to have the software come from the git
> >> repository and not from the tarballs of the original poky recipes.
> >
> >
> > I certainly hope this is using devupstream.bbclass or similar and isn't a
> > giant copy/paste!
> Wow never heard/saw of this bbclass even, and looking at the mega
> manual there is not any reference to this class. Also from the look of
> the classcode I am not seeing how this can help us accomplish the
> goal. Can you point me to some docs or examples?
>
> > Ross
>
> The way we are doing the layer is, by bbappend, so there is not much
> copy paste, but tarbal/git replacement.
> There would be no problem if there would not be differences between
> released tarballs and git repositories, but specially in autotools
> projects, the bbappend requires much more trickery as you mentioned
>
> Paulo Neves
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Hi Peter,

Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
Project Reference Manual (see
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).
You can also see
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the commit in the yocto-docs repository.

Please look it over as I did a bit of modification for manual purposes.

Regards,
Scott

On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

>
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.pur...@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@
> linuxfoundation.org> wrote:
>
> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>
>
>
> Yes - please indicate any areas in the documentation you believe need
> updated, changed, or added.  I have been trying to bring things up-to-date
> in several manuals during the 2.5 process.  So, identifying areas in the
> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
> manuals use the following form for the URL:
>
>   yoctoproject.org/docs/2.5//.html
>
>   where  is
>
>brief-yoctoprojectqs
>
>bsp-guide
>
>overview-manual
>
>dev-manual
>
>sdk-manual
>
>profile-manual
>
>kernel-dev
>
>ref-manual
>
>toaster-manual
>
>bitbake-user-guide
>
> Thanks
>
> Scott
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-
> January/039787.html) at the end of January (last pinged a month ago) and
> it still has not made it into the manual AFAICT and it has not received any
> feedback.
>
> //Peter
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Peter,

Sorry I missed this.  My fault for not monitoring that mail list close
enough.  I will take a look at this and get back to you.

Regarding special processes for getting doc changes done.  Any form of
contact with me "should" work.  What you did should have been caught.  An
email directly to me will work.  A chat over #yocto over IRC will work.

Thanks,
Scott

On Thu, May 3, 2018, 1:29 AM Peter Kjellerstedt <peter.kjellerst...@axis.com>
wrote:

>
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.pur...@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>
>
>
> Yes - please indicate any areas in the documentation you believe need
> updated, changed, or added.  I have been trying to bring things up-to-date
> in several manuals during the 2.5 process.  So, identifying areas in the
> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
> manuals use the following form for the URL:
>
>   yoctoproject.org/docs/2.5//.html
>
>   where  is
>
>brief-yoctoprojectqs
>
>bsp-guide
>
>overview-manual
>
>dev-manual
>
>sdk-manual
>
>profile-manual
>
>kernel-dev
>
>ref-manual
>
>toaster-manual
>
>bitbake-user-guide
>
> Thanks
>
> Scott
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (
> https://lists.yoctoproject.org/pipermail/yocto/2018-January/039787.html)
> at the end of January (last pinged a month ago) and it still has not made
> it into the manual AFAICT and it has not received any feedback.
>
> //Peter
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Question about multi rootfs UIDs when using wic

[Scott Rifenbark]

Thanks Ricardo... that helps me.

Scott

On Wed, May 2, 2018 at 11:18 AM, Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Hi Scott
>
> In this case I believe that it is a bug in wic, for no reason the user
> id of bitbake should be leaked into the rootfs.
>
> Regards
>
> On Wed, May 2, 2018 at 6:44 PM, Scott Rifenbark <srifenb...@gmail.com>
> wrote:
> > Hi,
> >
> > I have a couple Wic-related areas in the Yocto documentation.  Wondering
> if
> > this affects documentation.  I don't particularly have sections
> dedicated to
> > using specific canned wic files such as the "directdisk-multi-rootfs"
> file.
> > However, if there is some mentioning or changing of the docs to help
> avoid
> > this I could see what I could do.
> >
> > The sections related to Wic are:
> >
> >*
> > https://www.yoctoproject.org/docs/2.5/dev-manual/dev-
> manual.html#creating-partitioned-images-using-wic
> >*
> > https://www.yoctoproject.org/docs/2.5/ref-manual/ref-
> manual.html#ref-kickstart
> >
> > Thanks,
> > Scott
> >
> > On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber
> > <v.vogelhu...@digitalendoscopy.de> wrote:
> >>
> >> Hi,
> >>
> >> I never got any response to my message (until now). So AFAIK I solved
> the
> >> problem with the following patch:
> >>
> >> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> >> index 84fe85d62b..66ab757aec 100644
> >> --- a/scripts/lib/wic/partition.py
> >> +++ b/scripts/lib/wic/partition.py
> >> @@ -204,15 +204,10 @@ class Partition():
> >>
> >>  Currently handles ext2/3/4, btrfs and vfat.
> >>  """
> >> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
> >> native_sysroot)
> >> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
> >> - "%s/../pseudo" %
> >> get_bitbake_var("IMAGE_ROOTFS"))
> >> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
> >> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> >> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
> >> self.rootfs_dir
> >> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
> >>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
> >> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
> >> -pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
> >> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
> >> -pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
> >>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
> >>
> >>  rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,
> >>
> >>
> >>
> >> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
> >>>
> >>> Hi
> >>>
> >>> I just got hit by this one. It is specially nasty because nfsroot
> >>> fails to boot if the uids are wrong.
> >>>
> >>> What is the status on this?
> >>>
> >>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
> >>> <v.vogelhu...@digitalendoscopy.de> wrote:
> >>>>
> >>>> I finally found out, what's the reason why the included recovery
> rootfs
> >>>> has
> >>>> the wrong UIDs, while the main image has the correct one. The reason
> >>>> seems
> >>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir
> of
> >>>> the
> >>>> main image in both cases.
> >>>> I debugged all the calls up to the environment setup in partition.py's
> >>>> prepare_rootfs method where a check for an existing
> PSEUDO_LOCALSTATEDIR
> >>>> environment variable is done. That seems to be the problem.
> >>>> Instead of using the correct value passed to the prepare_rootfs
> method,
> >>>> an
> >>>> existing ENV value is used that points to the state dir of the main
> >>>> image
> >>>> instead of the recovery one's. I guess the reason is that in
> >>>> bitbake.conf
> >>>> the PSEUDO_LOCALSTATEDIR is set to the image curren

Re: [OE-core] Question about multi rootfs UIDs when using wic

[Scott Rifenbark]

Hi,

I have a couple Wic-related areas in the Yocto documentation.  Wondering if
this affects documentation.  I don't particularly have sections dedicated
to using specific canned wic files such as the "directdisk-multi-rootfs"
file.  However, if there is some mentioning or changing of the docs to help
avoid this I could see what I could do.

The sections related to Wic are:

   *
https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
   *
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart

Thanks,
Scott

On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber <
v.vogelhu...@digitalendoscopy.de> wrote:

> Hi,
>
> I never got any response to my message (until now). So AFAIK I solved the
> problem with the following patch:
>
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 84fe85d62b..66ab757aec 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -204,15 +204,10 @@ class Partition():
>
>  Currently handles ext2/3/4, btrfs and vfat.
>  """
> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
> native_sysroot)
> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
> - "%s/../pseudo" %
> get_bitbake_var("IMAGE_ROOTFS"))
> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
> self.rootfs_dir
> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
> -pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
> -pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
>
>  rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,
>
>
>
> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
>
>> Hi
>>
>> I just got hit by this one. It is specially nasty because nfsroot
>> fails to boot if the uids are wrong.
>>
>> What is the status on this?
>>
>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
>>  wrote:
>>
>>> I finally found out, what's the reason why the included recovery rootfs
>>> has
>>> the wrong UIDs, while the main image has the correct one. The reason
>>> seems
>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of
>>> the
>>> main image in both cases.
>>> I debugged all the calls up to the environment setup in partition.py's
>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
>>> environment variable is done. That seems to be the problem.
>>> Instead of using the correct value passed to the prepare_rootfs method,
>>> an
>>> existing ENV value is used that points to the state dir of the main image
>>> instead of the recovery one's. I guess the reason is that in bitbake.conf
>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is
>>> the
>>> main image and not the recovery image only referenced by the main
>>> image). So
>>> because that environment variable is already set, the call to mkfs.ext4
>>> for
>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply
>>> the correct UID.
>>>
>>> Any ideas how to fix that? I tend to just remove the patch introduced by
>>> Ed
>>> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/
>>> )
>>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone
>>> agrees.
>>>
>>> On 19.01.2018 17:00, Volker Vogelhuber wrote:
>>>

 I'm currently trying to create a multi RootFS WIC image as mentioned in
 directdisk-multi-rootfs.wks. For that I have two image recipes. One that
 is creating only an ext4 image (image-recovery), and the second that is
 also
 creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for
 that. The WKS file for the second image is integrating the recovery
 image by
 specifying --rootfs-dir=image-recovery in it's part description.

 # primary / recovery image
 part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/
 mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700
 --overhead-factor=1.0
 part /recovery --source rootfs --rootfs-dir=image-recovery --fstype=ext4
 --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0

 The UIDs of the second rootfs (image-main) are correctly set to 0 within
 the file system when calling mkfs.ext4 during prepare_rootfs_ext. For
 the
 recovery rootfs the UID is always set to my own (host) one which is of
 course not valid for the image where that UID does not exist.
 I tried calling 

Re: [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>

Yes - please indicate any areas in the documentation you believe need
updated, changed, or added.  I have been trying to bring things up-to-date
in several manuals during the 2.5 process.  So, identifying areas in the
2.5 manual set would be very helpful.  To be sure you are viewing 2.5
manuals use the following form for the URL:

  yoctoproject.org/docs/2.5//.html

  where  is

   brief-yoctoprojectqs
   bsp-guide
   overview-manual
   dev-manual
   sdk-manual
   profile-manual
   kernel-dev
   ref-manual
   toaster-manual
   bitbake-user-guide

Thanks
Scott




>
> > In any even one thing that I'm wondering if is of interest, is
> > modifying the build process to build an eSDK which is used to build
> > everything else.  The advantage of this, in my view, is that it makes
> > it easier to do things like use GitHub+Travis integration on
> > individual recipes.
>
> I know people who've tried travis with OE and the challenge is the
> length of the builds and the data usage. I'm not sure that problem
> changes regardless of whether the eSDK or native sstate is used as the
> size would be comparable.
>
> > The biggest challenge for this type of per-recipe build is dealing
> > with dependencies, but I think it would be helpful to get rid of 3-
> > day+ world builds.
> >
> > At the very least having a 'standard' binary eSDK for external layers
> > to use for this purpose would helpful in my view.
>
> How would that differ from a specific version of OE-Core used for
> testing for which a known good set of sstate were available?
>
> > I'm interested in working on this, but I don't think I've got a good
> > enough handle on OE for making this a 2.6 goal from me.
> >
> > Thoughts?
>
> I like the idea of thinking more in this area and would certainly
> welcome help. I think the issue is more one of tools to generate a
> locked sstate which layers then reuse rather than anything eSDK
> specific. Its therefore partly a process problem of generating that
> specific config and sstate which others would reuse. You could do this
> from things that already exist, e.g. from the OE-Core milestone
> releases but its not something people have really adopted for testing
> of other layers.
>
> Certainly worth exploring but the devil is in the details.
>
> Also worth mentioning that build-appliance exists which is an image
> capable of "self hosting" builds. There are often specific patches
> applied to native tools and version requirements which mean that the
> -native recipes are often essential to the build though.
>
> Cheers,
>
> Richard
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

[Scott Rifenbark]

Thanks Richard

https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LAYERSERIES_COMPAT

Scott

On Fri, Apr 6, 2018 at 3:25 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Fri, 2018-04-06 at 11:16 -0700, Scott Rifenbark wrote:
> > We have this variable appearing in a couple manuals BTW.  If anyone
> > has any feedback on what is being said here I can update.
>
> Some small suggested tweaks:
>
> "Using the LAYERSERIES_COMPAT variable makes it clear when a given
> layer is unmaintained and untested with new releases of OE-Core. "
> ->
> "Using the LAYERSERIES_COMPAT variable allows the layer maintainer to
> indicate which combinations of the layer and OE-Core may be expected to
> work. It gives the system a way to detect when a layer has not been
> tested with new releases of OE-Core, for example if it had become
> unmaintained."
>
> "The OpenEmbedded build system, however, does not produce an error if
> the variable is not set."
> ->
> "The OpenEmbedded build system will warn if the variable is not set for
> any given layer"
>
> Cheers,
>
> Richard
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] LAYERSERIES

[Scott Rifenbark]

We have this variable appearing in a couple manuals BTW.  If anyone has any
feedback on what is being said here I can update.

Thanks,
Scott

https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LAYERSERIES_COMPAT
https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-your-own-layer



On Fri, Apr 6, 2018 at 8:29 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote:
> > A) Some layers only switch to an official branch name when the find a
> > reason to. E.g. branch "sumo" is created on openembedded-core but
> > meta-A keeps working on master unless an incompatible change is
> > created in openembedded-core that forces meta-A to create a "sumo"
> > branch.
> >
> > B) Other layers create official branches the moment they exist. E.g.
> > branch "sumo" is created on openembedded-core and meta-B instantly
> > creates a "sumo" branch to mark this point in time, and continues
> > working on master. If meta-B's "sumo" branch fails to build against
> > openembedded-core's "sumo" branch because an incompatible change is
> > made to openembedded-core's sumo branch, meta-B fixes the issue on
> > the sumo branch.
> >
> >
> > I can see how the change you've implemented will be very useful for
> > the A)
> > cases. Will it be needed for the B) cases? In other words, does the
> > code
> > you're adding implicitly assume:
> >
> >   LAYERSERIES_COMPAT_<...> = "layer"
> >
> > for any given "layer"?
>
> No, there is no implicit assumption.
>
> In both A) and B) cases the maintainer adds the new "codename" to the
> list of compatible layer series in LAYERSERIES_COMPAT_ for their
> layer. They can list multiple layers in there, e.g. "rocko sumo".
>
> The one annoying thing about all this is the layer maintainers do have
> to update layer.conf each time a new release codename comes out. I
> think that is a reasonable compromise to be able to give users a much
> better idea of which layers are compatible or incomaptible with their
> setup though. It means someone has looked at it and believes it will
> work with a given release series.
>
> Just to be clear, "layer" would never be a valid value there, it will
> always be the release/branch codenames.
>
> Cheers,
>
> Richard
>
>
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ref-manual: Update SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS

[Scott Rifenbark]

ok - I will fix it back in the manual.  Thanks

On Wed, Mar 28, 2018 at 1:15 PM, Joshua Watt <jpewhac...@gmail.com> wrote:

> I don't believe there are any plans to backport that feature to Rocko, so
> I think we probably don't want it in the documentation.
>
> On Wed, 2018-03-28 at 11:59 -0700, Scott Rifenbark wrote:
>
> oops... will it hurt it to be in Rocko?
>
>
> On Wed, Mar 28, 2018 at 11:57 AM, Joshua Watt <jpewhac...@gmail.com>
> wrote:
>
> Scott,
>
> This documentation update is not needed for Rocko, the corresponding code
> change is only on master. Sorry if there was some confusion
>
> Thanks,
> Joshua Watt
>
> On Wed, 2018-03-28 at 10:53 -0700, Scott Rifenbark wrote:
>
> Joshua,
>
> Thanks for the addition.  I have implemented the change.  You can see the
> change at https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.
> html#var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.  I will back-fill into the
> 'rocko' development branch of the manuals.
>
> Scott
>
> On Wed, Mar 21, 2018 at 1:33 PM, Joshua Watt <jpewhac...@gmail.com> wrote:
>
> Describes the new wildcard syntax
>
> Signed-off-by: Joshua Watt <jpewhac...@gmail.com>
> ---
>  documentation/ref-manual/ref-variables.xml | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 09eb9b9dfc7..58a58b0605e 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -12648,6 +12648,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  mplayer2.
>  
>
> +
> +The special token "*" may be
> used on
> +the left hand side of the dependency, which will
> match all
> +recipes except the one on the right hand side.
> +For example:
> +
> +SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
> +
> +
> +
> +
> +In this example, all recipes except
> +quilt-native will ignore task
> +signatures from the quilt-native
> recipe
> +when determining their task signatures.
> +
> +
>  
>  Use of this variable is one mechanism to remove
> dependencies
>  that affect task signatures and thus force rebuilds
> when a
> --
> 2.14.3
>
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ref-manual: Update SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS

[Scott Rifenbark]

oops... will it hurt it to be in Rocko?


On Wed, Mar 28, 2018 at 11:57 AM, Joshua Watt <jpewhac...@gmail.com> wrote:

> Scott,
>
> This documentation update is not needed for Rocko, the corresponding code
> change is only on master. Sorry if there was some confusion
>
> Thanks,
> Joshua Watt
>
> On Wed, 2018-03-28 at 10:53 -0700, Scott Rifenbark wrote:
>
> Joshua,
>
> Thanks for the addition.  I have implemented the change.  You can see the
> change at https://www.yoctoproject.org/docs/2.5/ref-manual/ref-
> manual.html#var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.  I will back-fill into
> the 'rocko' development branch of the manuals.
>
> Scott
>
> On Wed, Mar 21, 2018 at 1:33 PM, Joshua Watt <jpewhac...@gmail.com> wrote:
>
> Describes the new wildcard syntax
>
> Signed-off-by: Joshua Watt <jpewhac...@gmail.com>
> ---
>  documentation/ref-manual/ref-variables.xml | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 09eb9b9dfc7..58a58b0605e 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -12648,6 +12648,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  mplayer2.
>  
>
> +
> +The special token "*" may be
> used on
> +the left hand side of the dependency, which will
> match all
> +recipes except the one on the right hand side.
> +For example:
> +
> +SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
> +
> +
> +
> +
> +In this example, all recipes except
> +quilt-native will ignore task
> +signatures from the quilt-native
> recipe
> +when determining their task signatures.
> +
> +
>  
>  Use of this variable is one mechanism to remove
> dependencies
>  that affect task signatures and thus force rebuilds
> when a
> --
> 2.14.3
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ref-manual: Update SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS

[Scott Rifenbark]

Joshua,

Thanks for the addition.  I have implemented the change.  You can see the
change at
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.
I will back-fill into the 'rocko' development branch of the manuals.

Scott

On Wed, Mar 21, 2018 at 1:33 PM, Joshua Watt  wrote:

> Describes the new wildcard syntax
>
> Signed-off-by: Joshua Watt 
> ---
>  documentation/ref-manual/ref-variables.xml | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 09eb9b9dfc7..58a58b0605e 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -12648,6 +12648,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  mplayer2.
>  
>
> +
> +The special token "*" may be
> used on
> +the left hand side of the dependency, which will
> match all
> +recipes except the one on the right hand side.
> +For example:
> +
> +SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
> +
> +
> +
> +
> +In this example, all recipes except
> +quilt-native will ignore task
> +signatures from the quilt-native
> recipe
> +when determining their task signatures.
> +
> +
>  
>  Use of this variable is one mechanism to remove
> dependencies
>  that affect task signatures and thus force rebuilds
> when a
> --
> 2.14.3
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] image.bbclass: check INITRAMFS_MAXSIZE

[Scott Rifenbark]

Hi,

I noticed we do not document INITRAMFS_MAXSIZE in the ref-manual.  Should
we be?

Thanks,
Scott

On Mon, Jan 25, 2016 at 12:45 AM, Robert Yang 
wrote:

> Usually, the initramfs' maxsize can be 1/2 of ram size since modern
> kernel uses tmpfs as initramfs by dafault, and tmpfs allocates 1/2 of
> ram by default at boot time, which will be used to locate the initramfs.
>
> Set INITRAMFS_MAXSIZE to 131072K (128M) by default (ram 256M), the
> initramfs is small usually, for example, core-image-minimal-initramfs is
> about 21M (uncompressed, 17M * 1.3) by default, but if the user add a
> lot pkgs to initramfs, we can error and stop to let the user know ealier
> rather than fail to boot (e.g., OOM-killer) at boot time.
>
> Please see the bug for more info:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5963
>
> [YOCTO #5963]
>
> Signed-off-by: Robert Yang 
> ---
>  meta/classes/image.bbclass |   14 +-
>  meta/conf/bitbake.conf |6 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 3870516..30d1173 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -423,6 +423,9 @@ def get_rootfs_size(d):
>  rootfs_req_size = int(d.getVar('IMAGE_ROOTFS_SIZE', True))
>  rootfs_extra_space = eval(d.getVar('IMAGE_ROOTFS_EXTRA_SPACE', True))
>  rootfs_maxsize = d.getVar('IMAGE_ROOTFS_MAXSIZE', True)
> +image_fstypes = d.getVar('IMAGE_FSTYPES', True) or ''
> +initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES', True) or ''
> +initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE', True)
>
>  output = subprocess.check_output(['du', '-ks',
>d.getVar('IMAGE_ROOTFS', True)])
> @@ -443,8 +446,17 @@ def get_rootfs_size(d):
>  if rootfs_maxsize:
>  rootfs_maxsize_int = int(rootfs_maxsize)
>  if base_size > rootfs_maxsize_int:
> -bb.fatal("The rootfs size %d(K) overrides the max size %d(K)"
> % \
> +bb.fatal("The rootfs size %d(K) overrides
> IMAGE_ROOTFS_MAXSIZE: %d(K)" % \
>  (base_size, rootfs_maxsize_int))
> +
> +# Check the initramfs size against INITRAMFS_MAXSIZE (if set)
> +if image_fstypes == initramfs_fstypes != ''  and initramfs_maxsize:
> +initramfs_maxsize_int = int(initramfs_maxsize)
> +if base_size > initramfs_maxsize_int:
> +bb.error("The initramfs size %d(K) overrides
> INITRAMFS_MAXSIZE: %d(K)" % \
> +(base_size, initramfs_maxsize_int))
> +bb.error("You can set INITRAMFS_MAXSIZE a larger value.
> Usually, it should")
> +bb.fatal("be less than 1/2 of ram size, or you may fail to
> boot it.\n")
>  return base_size
>
>  python set_image_size () {
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 7451eb8..e80ee18 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -712,7 +712,13 @@ require conf/sanity.conf
>  DL_DIR ?= "${TOPDIR}/downloads"
>  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
>  IMAGE_FSTYPES ?= "tar.gz"
> +
>  INITRAMFS_FSTYPES ?= "cpio.gz"
> +# The maximum size in Kbytes for the generated initramfs image size.
> +# Usually, it should be less than 1/2 of ram size, or you may fail to
> +# boot it.
> +INITRAMFS_MAXSIZE ??= "131072"
> +
>  DEFAULT_TASK_PROVIDER ?= "packagegroup-base"
>  MACHINE_TASK_PROVIDER ?= "${DEFAULT_TASK_PROVIDER}"
>
> --
> 1.7.9.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core