Re: [OE-core] [PATCH][PYRO] linux-firmware: Add reference to iwlwifi-8000C firmware

[Wold, Saul]

On Wed, 2018-02-07 at 10:53 +0530, avinash.reddy.pall...@intel.com
wrote:
> From: Avinash Reddy Palleti 
> 
> Adding reference to iwlwifi-8000c firmware which was removed
> erroneously in
> commit  3e4b382c0c687a76f824cd84b478c4f778e15e3e
> 
Blame me!


> Signed-off-by: Avinash Reddy Palleti  >
Acked-by: Saul Wold 
> ---
>  meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index ff60d30..3a2148d 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -247,7 +247,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-iwlwifi-6050-4 ${PN}-iwlwifi-6050-5 \
>   ${PN}-iwlwifi-7260 \
>   ${PN}-iwlwifi-7265 \
> - ${PN}-iwlwifi-7265d ${PN}-iwlwifi-8265 \
> + ${PN}-iwlwifi-7265d ${PN}-iwlwifi-8000c ${PN}-iwlwifi-
> 8265 \
>   ${PN}-iwlwifi-misc \
>   ${PN}-ibt-license ${PN}-ibt ${PN}-ibt-misc \
>   ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 ${PN}-
> ibt-hw-37-8 \
> @@ -619,6 +619,7 @@ FILES_${PN}-iwlwifi-6050-5 =
> "${nonarch_base_libdir}/firmware/iwlwifi-6050-5.uco
>  FILES_${PN}-iwlwifi-7260   =
> "${nonarch_base_libdir}/firmware/iwlwifi-7260-*.ucode"
>  FILES_${PN}-iwlwifi-7265   =
> "${nonarch_base_libdir}/firmware/iwlwifi-7265-*.ucode"
>  FILES_${PN}-iwlwifi-7265d   =
> "${nonarch_base_libdir}/firmware/iwlwifi-7265D-*.ucode"
> +FILES_${PN}-iwlwifi-8000c   =
> "${nonarch_base_libdir}/firmware/iwlwifi-8000C-*.ucode"
>  FILES_${PN}-iwlwifi-8265   =
> "${nonarch_base_libdir}/firmware/iwlwifi-8265-*.ucode"
>  FILES_${PN}-iwlwifi-misc   =
> "${nonarch_base_libdir}/firmware/iwlwifi-*.ucode"
>  
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/8] linux-yocto-dev: update to v4.15+

[Wold, Saul]

On Thu, 2017-12-07 at 05:30 -0500, Bruce Ashfield wrote:
> 
> 
> On Wed, Dec 6, 2017 at 11:28 AM, Burton, Ross 
> wrote:
> > The amended commit has mismatching commit log and patch (target
> > elfutils is in the commit log but not the patch), and doesn't
> > mention installing target elfutils if they want it.
> > 
> 
> 
> I fixed up the commit log on that patch to match the actual code.
> 
> As it turns out, I don't see the need to install target elfutils
> anymore, so I didn't
> include anything about that in the log.
> 
> We still have some lttng build issues with the -dev kernel (due to
> objtool being
> required and the openssl headers required for making the scripts),
> and those
> are being worked on separately. Having this updated linux-yocto-dev
> recipe
> in the tree gets the kernel building and booting and enables us to
> work through
> the other issues more quickly (not to meention, I've already pushed
> 4.15-rc2 to
> the actual kernel tree, so you get that from a build regardless).
> 
With Regards to the objtool, I was also seeing and issue with kernel-
devsrc, and objtool/.debug showing up in the devsrc packages-split.  I
am trying to get a solid set of steps that reproduces this.  The
strange thing was I did not see the .debug files in the kernel build
area or even in the kernel-devsrc/image directory but it was strangely
showed up in packages-split and failed a QA check.

Sau!

> Cheers,
> 
> Bruc
> 
> 
>  
> > Ross
> > 
> > On 4 December 2017 at 17:43, Bruce Ashfield  > er.com> wrote:
> > > On 2017-12-04 12:39 PM, Richard Purdie wrote:
> > > > On Mon, 2017-12-04 at 12:24 -0500, Bruce Ashfield wrote:
> > > > > On 2017-12-04 11:38 AM, Khem Raj wrote:
> > > > > > On Mon, Dec 4, 2017 at 7:39 AM, Bruce Ashfield
> > > > > >  wrote:
> > > > > > > Outside of the normal patch refreshes and boot issues,
> > > > > > > there are
> > > > > > > new
> > > > > > > build time tools within the kernel that required the
> > > > > > > following
> > > > > > > dependencies:
> > > > > > > 
> > > > > > > For ORC_UNWINDER support in x86-64:
> > > > > > > 
> > > > > > >DEPENDS += "${@bb.utils.contains('ARCH', 'x86',
> > > > > > > 'elfutils-
> > > > > > > native elfutils', '', d)}"
> > > > > > > 
> > > > > >  do we need both target and host elfutils
> > > > > > 
> > > > >  Yup. There were references to both. Some had to run for
> > > > > hostcc
> > > > > and others in the target arch.
> > > > > 
> > > >  
> > > > Just for reference this is pretty bad for performance as it
> > > > delays the
> > > > kernel compile until some substantial parts of userspace build.
> > > > 
> > > > 
> > >  
> > > On a second look, I can likely turn off the target part, if
> > > someone
> > > wants it, they can always install the package (or it could be a
> > > rdepends).
> > > 
> > > I'll amend the commit and leave it on that branch with just the
> > > DEPENDS on the -native version.
> > > 
> > > > Is ORC_UNWINDER useful and commonly used?
> > > > 
> > >  
> > > The upstream kernel commit turned it on by default, I turned it
> > > off in
> > > the kernel-cache, but I wanted to make sure the dependency was
> > > in place.
> > > 
> > > The commit series from Josh Poimboeuf all lead to it being on as
> > > the default choice (even with a slight overhead).
> > > 
> > > Bruce
> > > 
> > > 
> > > > 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
> > 
> 
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] install*.sh: add short sleep after parted commands

[Wold, Saul]

Much better!

Sau!

On Tue, 2017-11-21 at 15:02 -0800, California Sullivan wrote:
> I wasn't able to install to my Optane SSD due to the following error:
> 
> Formatting /dev/nvme0n1p1 to vfat...
> mkfs.fat 4.1 (2017-01-24)
> mkfs.vfat: unable to open /dev/nvme0n1p1: No such file or directory
> Target install-efi failed
> 
> A couple lines later I see:
> 
> [10.265401]  nvme0n1: p1 p2 p3
> 
> Then looking at the device itself after booting from a USB stick:
> 
> root@intel-corei7-64: ~# ls /dev/nvme0n1*
> /dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3
> 
> So it looks like the parted commands return before the device node is
> actually created.
> 
> Work around this issue by waiting for device nodes for a short
> duration.
> 
> Signed-off-by: California Sullivan 
> ---
> v2: sleep conditionally for up to three seconds instead of one second
> unconditionally. This makes it so if the device nodes are available
> immediately, people don't have to wait, but a system has up to three
> seconds to create them before failing. 
> 
>  meta/recipes-core/initrdscripts/files/init-install-efi.sh | 7
> +++
>  meta/recipes-core/initrdscripts/files/init-install.sh | 7
> +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-
> efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> index 5ad3a60..706418f 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -186,6 +186,13 @@ parted ${device} mkpart swap linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +echo "Waiting for device nodes..."
> +C=0
> +while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap
> ]; do
> +C=$(( C + 1 ))
> +sleep 1
> +done
> +
>  echo "Formatting $bootfs to vfat..."
>  mkfs.vfat $bootfs
>  
> diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
> b/meta/recipes-core/initrdscripts/files/init-install.sh
> index 1cac806..dade059 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install.sh
> @@ -211,6 +211,13 @@ parted ${device} mkpart $pname linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +echo "Waiting for device nodes..."
> +C=0
> +while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap
> ]; do
> +C=$(( C + 1 ))
> +sleep 1
> +done
> +
>  echo "Formatting $bootfs to ext3..."
>  mkfs.ext3 $bootfs
>  
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW47’17

[Wold, Saul]

On Tue, 2017-11-21 at 11:09 +, Richard Purdie wrote:
> On Mon, 2017-11-20 at 20:22 -0500, Randy MacLeod wrote:
> > On 2017-11-20 10:36 AM, Jolley, Stephen K wrote:
> > > Current Dev Position: YP 2.5 Planning and M1 development
> > > Next Deadline: YP 2.5 M1 cut off of 12/4/17
> > >  
> > > SWAT team rotation: Juro -> Paul on Nov.17, 2017.
> > > SWAT team rotation: Paul -> Todor on Nov. 24, 2017.
> > > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
> > >  
> > > Key Status/Updates:
> > > ·There is no real change to the status from last week. We
> > > continue to suffer intermittent build failures and are continuing
> > > to attempt to debug these.
> > > ·Currently open issues are:
> > 
> >  
> > Some US-based people may be on holiday later this week so I'm
> > offering 
> > help from the frozen Northland and more importantly from the team
> > in
> > Beijing. ;-)
> > 
> > > o   qemuppc continues to demonstrate random hangs in boot  in
> > > userspace
> > 
> >  
> > Is we can create a defect for this and point / copy the wiki notes
> > into it, that
> > would help.
> >https://wiki.yoctoproject.org/wiki/Qemuppc_Boot_Hangs
> > 
> > I think I had asked Chi to see if he could reproduce this a week or
> > two ago.
> > When the lack of entropy problem was identified and fix, many
> > people
> > thought
> > this hang went away as well. Chi can you read the wiki report and
> > see
> > if you
> > can add anything to them?
> 
> Good news is that the qemuppc issue has been identified as a bug in
> qemu ppc locking which breaks timer interrupt handling. I've posted
> on
> the qemu mailing list asking for help in verifying what I think is
> happening.
> 
> I have a patch ready to merge which should address this one, just
> cleaning up my environment and doing some further stress testing.
> 
This is great news hopefully you will hear back from the qemu ML
verifying your patch.

> [There is a defect somewhere for this btw, I created the wiki as it
> was
> a better place to dump and update information as we learnt what it
> is/is not without having to follow a train of thought updating in the
> bugzilla].
> 
> > > o   Issues with 4.13.10 host kernels booting kvm x86 guests on
> > > Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
> > > helps)
> > 
> >  
> > Robert, can you test Fedora 26. It would help to have a defect open
> > with steps to reproduce or
> > something about the typical workflow/ build time/ day of the week/
> > phase of the moon. 
> 
> FWIW we have noticed that the choice of kernel timers seems to vary
> in
> the x86_64 boots but not with a pattern that matches the hangs.
> 
> > > o   nfs inode count for the sstate/dldir share appears to break
> > > periodically causing the disk monitor to halt the builds (bug
> > > 12267)
> > 
> >  
> > Likely specific to the AB server so no plans to do anything for
> > this
> > bug.
> 
> Agreed, this one is our infrastructure somehow :(. We have a
> workaround
> in -next for this at least.
> 
> > > o   a perf build race (bug 12302)
> > 
> >   I'll take a look to:
> >  - see if I can duplicate the bug on a fast build host
> >  - check upstream to see if the bug is known/fixed
> >  - see if I can spot a race in the build rules.
> 
> Sounds good, thanks!
> 
> > > o   An ext filesystem creation/sizing issue (bug 12304)
> > 
> >  
> > Saul, Are you around this week? Do you have any additional
> > information before
> > leaving for Thanksgiving?
> > 
> > Jackie, 
> > Can you look at the code around the image creation and try to
> > reproduce this one?
> 
> Saul hasn't been able to reproduce. I've asked at the minimum we add
> better logging so if/when this happens again, we can debug it
> properly

Patch sent which provides some additional debugging information to the
log files, ideally, this will be saved with the bug next time this
issue occurs.

Sau!

> next time. I did also wonder about fuzzing the image size code,
> writing
> some code which puts in all possible input values and checks the
> sanity
> of the resulting image size. Its the kind of problem a computer can
> probably brute force. Anyone interested in trying that?
> 
> Cheers,
> 
> Richard
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][morty] gnu-efi: Fix missing space in _append line

[Wold, Saul]

Wrong list, this is for meta-intel, sorry.

Sau!

On Mon, 2017-11-20 at 11:00 -0800, Saul Wold wrote:
> [YOCTO #12366]
> 
> Signed-off-by: Saul Wold 
> ---
> 
> This is only in Morty, so no master then backport option
> 
>  common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
> b/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
> index 1e9cfda..da08432 100644
> --- a/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
> +++ b/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
> @@ -1,3 +1,3 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/gnu-efi:"
> -SRC_URI_append_intel-x86-common = "file://0001-Add-GUID-for-SMBIOS-
> 3-entry-point-structure.patch"
> +SRC_URI_append_intel-x86-common = " file://0001-Add-GUID-for-SMBIOS-
> 3-entry-point-structure.patch"
>  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
> -- 
> 2.13.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v9] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Fri, 2017-11-10 at 15:51 -0600, Haris Okanovic wrote:
> No problem! Thanks for all the good feedback. I think we shook out
> most 
> of the gremlins in the last few months.
> 
Thanks again for your patience !

> Let me know if you need help with boot loader integration.
> 
Funny you should mention that, there is another bug recently opened
about supporting multiple kernels for at least grub* and systemd-boot.

I have some ideas about using the existing bbclasses and extending the
LABELS variable automagically.  We also have some plans for make the
bootfs be created in a more generic install fashion, rather then the
additional do_deploy() function, this is an early WIP.

If you have any ideas or work already, we would be happy to use it.

Sau!


> -- Haris
> 
> 
> On 11/08/2017 04:20 PM, Wold, Saul wrote:
> > 
> > Haris,
> > 
> > Thanks for your patience on this process.  This version works well,
> > now
> > I have the extra work of getting these kernel known to systemd-
> > boot!
> > 
> > Acked-by below!
> > 
> > Sau!
> > 
> > On Tue, 2017-11-07 at 12:40 -0600, Haris Okanovic wrote:
> > > Some distros may want to provide alternate kernel "flavors" via
> > > feeds
> > > or
> > > within bootable images. For example, readily available builds
> > > which
> > > provide certain diagnostic features can enable developers and
> > > testers
> > > to
> > > more quickly resolve issues by avoiding lengthy kernel builds.
> > > 
> > > This change allows for building multiple flavors of the kernel
> > > and
> > > module packages by templatizing kernel package names via a new
> > > KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to
> > > the
> > > old
> > > name of "kernel", but can be overridden by certain recipes
> > > providing
> > > alternate kernel flavors.
> > > 
> > > To maintain compatibility, recipes providing alternate kernel
> > > flavors
> > > cannot be the "preferred provider" for virtual/kernel. This is
> > > because
> > > OE puts the preferred provider's build and source at
> > > "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> > > "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> > > "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes
> > > using
> > > the
> > > default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> > > build
> > > in the old location and may be preferred provider -- while
> > > recipes
> > > using
> > > all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> > > don't
> > > provide "virtual/kernel".
> > > 
> > > Testing:
> > >   1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"`
> > >  to local.conf so that linux-yocto-tiny may build alongside
> > >  the main kernel (linux-yocto).
> > >   2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> > > flavors.
> > >   3. Verified image and modules IPKs exist for both:
> > >  tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> > >  tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-
> > > tiny
> > >   4. Verified linux-yocto is the "preferred provider", and was
> > > built
> > > in
> > >  shared directory: tmp-glibc/work-shared/qemux86/kernel-*
> > >   5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base =
> > > "tiny-
> > > linux"`
> > >  to local.conf to install both kernel flavors in core-image-
> > > base.
> > >   6. `bitbake core-image-base` to build an image.
> > >   7. Verified image contains two bzImage's under /boot/, with
> > >  "yocto-standard" (linux-yocto recipe) selected to boot via
> > > symlink.
> > > 
> > > Discussion threads:
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openemb
> > > edded.org_pipermail_openembedded-2Dcore_2015-
> > > 2DDecemb=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA
> > > =8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=Po_g6d_nUSqHTshbn-
> > > ZaBXenlH_4CQklz7Csmi7u70A=cJkppECRP9FwMwrmn-
> > > tbJfRpffqbPbeRXS1uCu5JsB0=
> > > er/thread.html#114122
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openemb
> > > edded.org_pipermail_openembedded-2Dcore_2017-
> &g

Re: [OE-core] [PATCH v9] kernel: Add support for multiple kernel packages

[Wold, Saul]

Haris,

Thanks for your patience on this process.  This version works well, now
I have the extra work of getting these kernel known to systemd-boot!

Acked-by below!

Sau!

On Tue, 2017-11-07 at 12:40 -0600, Haris Okanovic wrote:
> Some distros may want to provide alternate kernel "flavors" via feeds
> or
> within bootable images. For example, readily available builds which
> provide certain diagnostic features can enable developers and testers
> to
> more quickly resolve issues by avoiding lengthy kernel builds.
> 
> This change allows for building multiple flavors of the kernel and
> module packages by templatizing kernel package names via a new
> KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
> old
> name of "kernel", but can be overridden by certain recipes providing
> alternate kernel flavors.
> 
> To maintain compatibility, recipes providing alternate kernel flavors
> cannot be the "preferred provider" for virtual/kernel. This is
> because
> OE puts the preferred provider's build and source at
> "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
> the
> default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> build
> in the old location and may be preferred provider -- while recipes
> using
> all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> don't
> provide "virtual/kernel".
> 
> Testing:
>  1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"`
> to local.conf so that linux-yocto-tiny may build alongside
> the main kernel (linux-yocto).
>  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> flavors.
>  3. Verified image and modules IPKs exist for both:
> tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
>  4. Verified linux-yocto is the "preferred provider", and was built
> in
> shared directory: tmp-glibc/work-shared/qemux86/kernel-*
>  5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-
> linux"`
> to local.conf to install both kernel flavors in core-image-base.
>  6. `bitbake core-image-base` to build an image.
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" (linux-yocto recipe) selected to boot via
> symlink.
> 
> Discussion threads:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
> er/thread.html#114122
> http://lists.openembedded.org/pipermail/openembedded-core/2017-July/t
> hread.html#139130
> 
> [YOCTO #11363]
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> Signed-off-by: Gratian Crisan 
> Signed-off-by: Haris Okanovic 
> Coauthored-by: Gratian Crisan 
> Coauthored-by: Haris Okanovic 
> Coauthored-by: Josh Hernstrom 

Acked-by: Saul Wold 

Sau!

> ---
> [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
> the
> "work" directory in alternate kernel builds, instead of "work-
> shared",
> so
> that the two builds don't clobber each other.
> 
> [PATCH v3] An updated version of this change rebased onto the current
> OE-core master. Changes:
>  - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
>kernel builds, since alternate kernels aren't the
>PREFERRED_PROVIDER for virtual/kernel by definition.
>  - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.
> 
> [PATCH v4] Another rebase onto master; no functional change.
> Improved description and testing steps.
> 
> [PATCH v5]
>  - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
>  - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions
> 
> [PATCH v6] Add KERNEL_PACKAGE_NAME to kernel-module-split.bbclass for
> module recipes; fixes lttng-modules build.
> 
> [PATCH v7] Remove second definition of KERNEL_PACKAGE_NAME from
> kernel-module-split.bbclass; apply a default in two places where
> KERNEL_PACKAGE_NAME is referenced.
> 
> [PATCH v8] Rebase onto current master and more fixups.
>  - kernel-devicetree.bbclass: Fixup package names
>  - depmodwrapper-cross: don't error when called from alt kernel
> recipes
>  - kernel.bbclass: Don't install /boot/image symlink in alt recipes
> 
> [PATCH v9]
>  - Add feature tracking tag
>  - Update testing section to define vars in local.conf
>  - Add KERNEL_PACKAGE_NAME check to *-rt recipes
> 
> https://github.com/harisokanovic/openembedded-core/tree/dev/hokanovi/
> multi-kernel-packages-v9
> ---
>  meta/classes/kernel-devicetree.bbclass |   8 +-
>  meta/classes/kernel-module-split.bbclass   |   9 +-
>  meta/classes/kernel.bbclass| 114
> +
>  meta/conf/documentation.conf   |   1 +
>  .../recipes-kernel/kmod/depmodwrapper-cross_1.0.bb |  14 +--
>  

Re: [OE-core] linux-firmware fetcher warnings

[Wold, Saul]

On Tue, 2017-10-31 at 14:35 -0700, Andre McCurdy wrote:
> The linux-firmware recipe is currently trying to fetch
> iwlwifi-8000C-19.ucode which according to:
> 
>   https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/15792
> 81
> 
> is an unreleased firmware image from a unofficial fork of the main
> linux-firmware repo. The "iwlwifi-8000C-19.ucode" file isn't found in
> the current master branch of the iwlwifi linux-firmware repo (and
> doesn't seem to be there in the history either...).
> 
Yeah seems like it got rebased away :-(!

> The mystery firmware image was added to the linux-firmware recipe by:
> 
>   http://git.openembedded.org/openembedded-core/commit/?id=8b3d3ac84f
> 787bf4ecccdcbcb97f2dac56acd45c
> 
> Is this firmware still required? If so, should SRC_URI be updated to
> fetch it directly from downloads.yoctoproject.org?

I will do some research, it was needed for some hardware when it was
put into the meta-intel and then later we moved it into OE-Core.

Sau!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] go-runtime: prevent host leakage into target objects

[Wold, Saul]

On Fri, 2017-09-29 at 14:15 +, Matt Madison wrote:
> When building for a target whose architecture matches
> the build host's, the second pass through make.bash
> to build the shareable runtime would also overwrite
> the target's static cgo library with host-compatibile
> binaries.
> 
> Fix this by running the host-side build once and
> target-only passes of make.bash twice, for static
> and shareable.  This ensures that what gets installed
> is target-compatible.
> 
> [YOCTO #12136]
> 
This does not appear to actually fix the bug mentioned here, I just
found the failure again with intel-corei7-64 (from meta-intel) and then
confirmed that it fails with qemux86-64 and genericx86-64 when using
TCLIBC = "musl"

Can you please verify and test with MUSL.

Thanks
   Sau!


> Signed-off-by: Matt Madison 
> ---
>  meta/recipes-devtools/go/go-runtime.inc | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-devtools/go/go-runtime.inc b/meta/recipes-
> devtools/go/go-runtime.inc
> index 934d1aa..bd26e2e 100644
> --- a/meta/recipes-devtools/go/go-runtime.inc
> +++ b/meta/recipes-devtools/go/go-runtime.inc
> @@ -23,9 +23,13 @@ do_compile() {
>   rm -rf ${GOBIN} ${B}/pkg
>   mkdir ${GOBIN}
>   cd src
> - GO_FLAGS="" ./make.bash
> + ./make.bash --host-only
> + cp ${B}/pkg/tool/${BUILD_GOTUPLE}/go_bootstrap ${B}
> + rm -rf ${B}/pkg/${TARGET_GOTUPLE}
> + ./make.bash --target-only
>   if [ -n "${GO_DYNLINK}" ]; then
> - GO_FLAGS="-buildmode=shared" GO_LDFLAGS="-extldflags 
> \"${LDFLAGS}\"" ./make.bash
> + cp ${B}/go_bootstrap ${B}/pkg/tool/${BUILD_GOTUPLE}
> + GO_FLAGS="-buildmode=shared" GO_LDFLAGS="-extldflags 
> \"${LDFLAGS}\"" ./make.bash --target-only
>   fi
>   cd ${B}
>  }
> @@ -41,8 +45,9 @@ do_install() {
>   rm -rf ${D}${libdir}/go/pkg/obj
>   rm -rf ${D}${libdir}/go/pkg/bootstrap
>   find src -mindepth 1 -maxdepth 1 -type d | while read
> srcdir; do
> - [ "$srcdir" = "./cmd" ] || cp --
> preserve=mode,timestamps -R $srcdir ${D}${libdir}/go/src/
> + cp --preserve=mode,timestamps -R $srcdir
> ${D}${libdir}/go/src/
>   done
> + rm -f ${D}${libdir}/go/src/cmd/dist/dist
>  }
>  
>  # Remove test binaries that cannot be relocated
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] systemtap: Bump SRCREV for 4.12 Linux kernel support

[Wold, Saul]

On Tue, 2017-09-05 at 13:22 -0700, Saul Wold wrote:
> This SRCREV bump brings in support for the 4.12 Linux Kernel, this
> kernel
> also has some newer CONFIG settings. The newer DEBUG_INFO and
> DEBUG_INFO_DWARF4
> settings can be used with systemtap to get the full information.  We
> do not
> normally enabled these for a 'production' (standard) kernel, but can
> be
> enabled via menuconfig.
> 
> Signed-off-by: Saul Wold 
Put a hold on this patch, I found an issue with a partial failure
during the install phase which did not cause an error to be thrown so
it completed!

Sau!

> ---
>  meta/recipes-kernel/systemtap/systemtap_git.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc
> b/meta/recipes-kernel/systemtap/systemtap_git.inc
> index a6aedd38a6..ea2d2c0d1d 100644
> --- a/meta/recipes-kernel/systemtap/systemtap_git.inc
> +++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
> @@ -1,6 +1,6 @@
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> -SRCREV = "b8ea350dc13adb6190d9044a5b80110a4c441270"
> +SRCREV = "45d0e7a09a15a21078d0ebf2db5175ed9e87014e"
>  PV = "3.1"
>  
>  SRC_URI = "git://sourceware.org/git/systemtap.git \
> -- 
> 2.11.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v6] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Mon, 2017-08-14 at 16:29 -0500, Haris Okanovic wrote:
> Some distros may want to provide alternate kernel "flavors" via feeds
> or
> within bootable images. For example, readily available builds which
> provide certain diagnostic features can enable developers and testers
> to
> more quickly resolve issues by avoiding lengthy kernel builds.
> 
> This change allows for building multiple flavors of the kernel and
> module packages by templatizing kernel package names via a new
> KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
> old
> name of "kernel", but can be overridden by certain recipes providing
> alternate kernel flavors.
> 
> To maintain compatibility, recipes providing alternate kernel flavors
> cannot be the "preferred provider" for virtual/kernel. This is
> because
> OE puts the preferred provider's build and source at
> "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
> the
> default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> build
> in the old location and may be preferred provider -- while recipes
> using
> all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> don't
> provide "virtual/kernel".
> 
> Testing:
>  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> linux-yocto-tiny_4.9.bb so that it may build alongside
> the main kernel.
>  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> flavors.
>  3. Verified image and modules IPKs exist for both:
> tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
>  4. Verified linux-yocto is the "preferred provider", and was built
> in
> shared directory: tmp-glibc/work-shared/qemux86/kernel-*
>  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> core-image-base.bb to include both kernel flavors.
>  6. `bitbake core-image-base` to build an image.
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" selected to boot via symlink.
> 
> Discussion threads:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
> er/thread.html#114122
> http://lists.openembedded.org/pipermail/openembedded-core/2017-July/t
> hread.html#139130
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> Signed-off-by: Gratian Crisan 
> Signed-off-by: Haris Okanovic 
> Coauthored-by: Gratian Crisan 
> Coauthored-by: Haris Okanovic 
> Coauthored-by: Josh Hernstrom 
> ---
> [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
> the
> "work" directory in alternate kernel builds, instead of "work-
> shared",
> so
> that the two builds don't clobber each other.
> 
> [PATCH v3] An updated version of this change rebased onto the current
> OE-core master. Changes:
>  - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
>    kernel builds, since alternate kernels aren't the
>    PREFERRED_PROVIDER for virtual/kernel by definition.
>  - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.
> 
> [PATCH v4] Another rebase onto master; no functional change.
> Improved description and testing steps.
> 
> [PATCH v5]
>  - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
>  - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions
> 
> [PATCH v6] Add KERNEL_PACKAGE_NAME to kernel-module-split.bbclass for
> module recipes; fixes lttng-modules build.
> 
> https://github.com/harisokanovic/openembedded-core/tree/dev/hokanovi/
> multi-kernel-packages-v6
> ---
>  meta/classes/kernel-module-split.bbclass  |  14 +++-
>  meta/classes/kernel.bbclass   | 114 +++-
> --
>  meta/conf/documentation.conf  |   1 +
>  meta/recipes-kernel/linux/linux-dtb.inc   |   2 +-
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  5 files changed, 86 insertions(+), 47 deletions(-)
> 
> diff --git a/meta/classes/kernel-module-split.bbclass
> b/meta/classes/kernel-module-split.bbclass
> index 1035525dac..59f19f3de2 100644
> --- a/meta/classes/kernel-module-split.bbclass
> +++ b/meta/classes/kernel-module-split.bbclass
> @@ -30,7 +30,12 @@ do_install_append() {
>  
>  PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
>  
> -KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
> +# Default KERNEL_PACKAGE_NAME should match kernel.bbclass
> +# Redefined here since some recipes only build modules and therefore
> +# don't consume kernel.bbclass to get this default.
> +KERNEL_PACKAGE_NAME ??= "kernel"
> +
> +KERNEL_MODULES_META_PACKAGE ?= "${KERNEL_PACKAGE_NAME}-modules"
>  
Sorry, I missed that you sent this on Monday when I replied to your
"thoughts?" question from V5.

I think we should really be checking if KERNEL_PACKAGE_NAME is set
already when you use it and 

Re: [OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Mon, 2017-08-14 at 16:29 -0500, Haris Okanovic wrote:
> 
> On 08/08/2017 05:33 PM, Wold, Saul wrote:
> > 
> > On Tue, 2017-08-08 at 10:30 -0500, Haris Okanovic wrote:
> > > 
> > > Some distros may want to provide alternate kernel "flavors" via
> > > feeds
> > > or
> > > within bootable images. For example, readily available builds
> > > which
> > > provide certain diagnostic features can enable developers and
> > > testers
> > > to
> > > more quickly resolve issues by avoiding lengthy kernel builds.
> > > 
> > > This change allows for building multiple flavors of the kernel
> > > and
> > > module packages by templatizing kernel package names via a new
> > > KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to
> > > the
> > > old
> > > name of "kernel", but can be overridden by certain recipes
> > > providing
> > > alternate kernel flavors.
> > > 
> > > To maintain compatibility, recipes providing alternate kernel
> > > flavors
> > > cannot be the "preferred provider" for virtual/kernel. This is
> > > because
> > > OE puts the preferred provider's build and source at
> > > "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> > > "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> > > "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes
> > > using
> > > the
> > > default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> > > build
> > > in the old location and may be preferred provider -- while
> > > recipes
> > > using
> > > all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> > > don't
> > > provide "virtual/kernel".
> > > 
> > > Testing:
> > >   1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> > >  linux-yocto-tiny_4.9.bb so that it may build alongside
> > >  the main kernel.
> > >   2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> > > flavors.
> > >   3. Verified image and modules IPKs exist for both:
> > >  tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> > >  tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-
> > > tiny
> > >   4. Verified linux-yocto is the "preferred provider", and was
> > > built
> > > in
> > >  shared directory: tmp-glibc/work-shared/qemux86/kernel-*
> > >   5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> > >  core-image-base.bb to include both kernel flavors.
> > >   6. `bitbake core-image-base` to build an image.
> > >   7. Verified image contains two bzImage's under /boot/, with
> > >  "yocto-standard" selected to boot via symlink.
> > > 
> > Thank you for continuing to work on this.  I did a simple test of
> > building a single kernel and lttng-modules without your change and
> > then
> > added this patch and tried lttng-modules with no additional changes
> > to
> > my local.conf, just regular single kernel workflow.
> > 
> > I got the following issue:
> > 
> > ERROR: lttng-modules-2.9.3-r0 do_package: Error executing a python
> > function in exec_python_func() autogenerated:
> > 
> > The stack trace of python calls that resulted in this
> > exception/failure
> > was:
> > File: 'exec_python_func() autogenerated', lineno: 2, function:
> > 
> >   0001:
> >   *** 0002:split_kernel_module_packages(d)
> >   0003:
> > File: '/srv/sdb/releases/master/meta/classes/kernel-module-
> > split.bbclass', lineno: 139, function: split_kernel_module_packages
> >   0135:module_regex = '^(.*)\.k?o$'
> >   0136:
> >   0137:module_pattern_prefix =
> > d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
> >   0138:module_pattern_suffix =
> > d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
> >   *** 0139:module_pattern = module_pattern_prefix +
> > kernel_package_name + '-module-%s' + module_pattern_suffix
> >   0140:
> >   0141:postinst = d.getVar('pkg_postinst_modules')
> >   0142:postrm = d.getVar('pkg_postrm_modules')
> >   0143:
> > Exception: TypeError: Can't convert 'NoneType' object to str
> > implicitly
> > 
> > ERROR: lttng-modules-2.9.3-r0 do_package: Function failed:
> > split_kernel_module_packages

Re: [OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Tue, 2017-08-08 at 10:30 -0500, Haris Okanovic wrote:
> Some distros may want to provide alternate kernel "flavors" via feeds
> or
> within bootable images. For example, readily available builds which
> provide certain diagnostic features can enable developers and testers
> to
> more quickly resolve issues by avoiding lengthy kernel builds.
> 
> This change allows for building multiple flavors of the kernel and
> module packages by templatizing kernel package names via a new
> KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
> old
> name of "kernel", but can be overridden by certain recipes providing
> alternate kernel flavors.
> 
> To maintain compatibility, recipes providing alternate kernel flavors
> cannot be the "preferred provider" for virtual/kernel. This is
> because
> OE puts the preferred provider's build and source at
> "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
> the
> default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> build
> in the old location and may be preferred provider -- while recipes
> using
> all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> don't
> provide "virtual/kernel".
> 
> Testing:
>  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> linux-yocto-tiny_4.9.bb so that it may build alongside
> the main kernel.
>  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> flavors.
>  3. Verified image and modules IPKs exist for both:
> tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
>  4. Verified linux-yocto is the "preferred provider", and was built
> in
> shared directory: tmp-glibc/work-shared/qemux86/kernel-*
>  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> core-image-base.bb to include both kernel flavors.
>  6. `bitbake core-image-base` to build an image.
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" selected to boot via symlink.
> 
Thank you for continuing to work on this.  I did a simple test of
building a single kernel and lttng-modules without your change and then
added this patch and tried lttng-modules with no additional changes to
my local.conf, just regular single kernel workflow.

I got the following issue:

ERROR: lttng-modules-2.9.3-r0 do_package: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:split_kernel_module_packages(d)
 0003:
File: '/srv/sdb/releases/master/meta/classes/kernel-module-
split.bbclass', lineno: 139, function: split_kernel_module_packages
 0135:module_regex = '^(.*)\.k?o$'
 0136:
 0137:module_pattern_prefix =
d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 0138:module_pattern_suffix =
d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 *** 0139:module_pattern = module_pattern_prefix +
kernel_package_name + '-module-%s' + module_pattern_suffix
 0140:
 0141:postinst = d.getVar('pkg_postinst_modules')
 0142:postrm = d.getVar('pkg_postrm_modules')
 0143:
Exception: TypeError: Can't convert 'NoneType' object to str implicitly

ERROR: lttng-modules-2.9.3-r0 do_package: Function failed:
split_kernel_module_packages
ERROR: Logfile of failure stored in:
/srv/sdb/releases/master/builds/corei7/tmp/work/genericx86_64-poky-
linux/lttng-modules/2.9.3-r0/temp/log.do_package.80115
NOTE: recipe lttng-modules-2.9.3-r0: task do_package: Failed

I believe the problem is that I tried to build lttng-modules standalone
and so the kernel.bbclass does not get involved to set the
KERNEL_PACKAGE_NAME default.

I see that your procedure above works for.

Thanks again for your work, sorry I am finding interesting issues
still.

Sau!


> Discussion thread:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
> er/thread.html#114122
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> Signed-off-by: Gratian Crisan 
> Signed-off-by: Haris Okanovic 
> Coauthored-by: Gratian Crisan 
> Coauthored-by: Haris Okanovic 
> Coauthored-by: Josh Hernstrom 
> ---
> [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
> the
> "work" directory in alternate kernel builds, instead of "work-
> shared",
> so
> that the two builds don't clobber each other.
> 
> [PATCH v3] An updated version of this change rebased onto the current
> OE-core master. Changes:
>  - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
>    kernel builds, since alternate kernels aren't the
>    PREFERRED_PROVIDER for virtual/kernel by definition.
>  - Remove 

Re: [OE-core] [PATCH] image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types

[Wold, Saul]

On Tue, 2017-07-25 at 15:58 -0400, Tom Rini wrote:
> The vmdk/vdi/qcow2 IMAGE_FSTYPEs predate wic.  As such, they provide
> some similar underlying functionality in order to produce a "disk"
> image
> that in turn can be converted into different formats that various
> hypervisor types work with.  They do not however provide the ability
> for
> other disk image types to be converted into these same output types.
> Furthermore, they are less flexible than what wic does provide.  This
> drops the old style vmdk/vdi/qcow2 types and re-introduces them under
> the CONVERSION_CMD framework.  The equivalent of vmdk is now wic.vmdk
> and so forth for the other types.
> 
I like this also!  Strong work!

Would this allow us to further collapse the live-vm-common.bbclass back
to just image-live.bbclass.  I know that the magic mapping that happens
in set_live_vm_vars() has caused confusion in the past and removing
that mapping would be pretty awesome.

I am still looking at Ed's GenericEFI work in hopes of creating an
bootfs image via recipes (similar to rootfs images) that WIC can
consume directly rather than fashioning it out of a bbclass.  Then we
might even be able to get rid of image-live.bbclass also!

Sau!

> Signed-off-by: Tom Rini 
> ---
> This depends on my previous series to correct chaining compression
> support.  I had attempted to keep the vmdk/vdi/qcow2 IMAGE_FSTYPES
> for
> compatibility sake using IMAGE_TYPEDEP_vmdk = "wic" and introducing
> an
> oe_qemuimg function to run to do the conversion.  This was working,
> but
> I could not get it to have the symlinks created automatically.  At
> this
> timeI think it makes most sense to not hide that the underlying disk
> content has changed at least slightly from the old vmdk type to the
> new
> type and that we can simply handle this change in documentation.  As
> such, if there's agreement about dropping the types I'll include some
> documentation changes in the next version.
> 
>  meta/classes/image-vm.bbclass  | 171 -
> 
>  meta/classes/image.bbclass |   3 -
>  meta/classes/image_types.bbclass   |  12 +-
>  .../images/build-appliance-image_15.0.0.bb |   6 +-
>  4 files changed, 10 insertions(+), 182 deletions(-)
>  delete mode 100644 meta/classes/image-vm.bbclass
> 
> diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-
> vm.bbclass
> deleted file mode 100644
> index b52df9f..000
> --- a/meta/classes/image-vm.bbclass
> +++ /dev/null
> @@ -1,171 +0,0 @@
> -# image-vm.bbclass
> -# (loosly based off image-live.bbclass Copyright (C) 2004, Advanced
> Micro Devices, Inc.)
> -#
> -# Create an image which can be placed directly onto a harddisk using
> dd and then
> -# booted.
> -#
> -# This uses syslinux. extlinux would have been nice but required the
> ext2/3
> -# partition to be mounted. grub requires to run itself as part of
> the install
> -# process.
> -#
> -# The end result is a 512 boot sector populated with an MBR and
> partition table
> -# followed by an msdos fat16 partition containing syslinux and a
> linux kernel
> -# completed by the ext2/3 rootfs.
> -#
> -# We have to push the msdos parition table size > 16MB so fat 16 is
> used as parted
> -# won't touch fat12 partitions.
> -
> -inherit live-vm-common
> -
> -do_bootdirectdisk[depends] += "dosfstools-native:do_populate_sysroot 
> \
> -   virtual/kernel:do_deploy \
> -   syslinux:do_populate_sysroot \
> -   syslinux-native:do_populate_sysroot \
> -   parted-native:do_populate_sysroot \
> -   mtools-native:do_populate_sysroot \
> -   ${PN}:do_image_${VM_ROOTFS_TYPE} \
> -   "
> -
> -IMAGE_TYPEDEP_vmdk = "${VM_ROOTFS_TYPE}"
> -IMAGE_TYPEDEP_vdi = "${VM_ROOTFS_TYPE}"
> -IMAGE_TYPEDEP_qcow2 = "${VM_ROOTFS_TYPE}"
> -IMAGE_TYPEDEP_hdddirect = "${VM_ROOTFS_TYPE}"
> -IMAGE_TYPES_MASKED += "vmdk vdi qcow2 hdddirect"
> -
> -VM_ROOTFS_TYPE ?= "ext4"
> -ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}"
> -
> -# Used by bootloader
> -LABELS_VM ?= "boot"
> -ROOT_VM ?= "root=/dev/sda2"
> -# Using an initramfs is optional. Enable it by setting
> INITRD_IMAGE_VM.
> -INITRD_IMAGE_VM ?= ""
> -INITRD_VM ?= "${@'${IMGDEPLOYDIR}/${INITRD_IMAGE_VM}-
> ${MACHINE}.cpio.gz' if '${INITRD_IMAGE_VM}' else ''}"
> -do_bootdirectdisk[depends] +=
> "${@'${INITRD_IMAGE_VM}:do_image_complete' if '${INITRD_IMAGE_VM}'
> else ''}"
> -
> -BOOTDD_VOLUME_ID   ?= "boot"
> -BOOTDD_EXTRA_SPACE ?= "16384"
> -
> -DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
> -DISK_SIGNATURE[vardepsexclude] = "DISK_SIGNATURE_GENERATED"
> -
> -build_boot_dd() {
> - HDDDIR="${S}/hdd/boot"
> - HDDIMG="${S}/hdd.image"
> - IMAGE=${IMGDEPLOYDIR}/${IMAGE_NAME}.hdddirect
> -
> - populate_kernel $HDDDIR
> -
> - if [ 

Re: [OE-core] [PATCH v4] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Tue, 2017-07-18 at 08:34 -0500, Haris Okanovic wrote:
> 
> On 07/17/2017 03:31 PM, Wold, Saul wrote:
> > 
> > On Wed, 2017-07-05 at 12:33 -0500, Haris Okanovic wrote:
> > > 
> > > Some distros may want to provide alternate kernel "flavors" via
> > > feeds
> > > or
> > > within bootable images. For example, readily available builds
> > > which
> > > provide certain diagnostic features can enable developers and
> > > testers
> > > to
> > > more quickly resolve issues by avoiding lengthy kernel builds.
> > > 
> > > This change allows for building multiple flavors of the kernel
> > > and
> > > module packages by templatizing kernel package names via a new
> > > KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to
> > > the
> > > old
> > > name of "kernel", but can be overridden by certain recipes
> > > providing
> > > alternate kernel flavors.
> > > 
> > > To maintain compatibility, recipes providing alternate kernel
> > > flavors
> > > cannot be the "preferred provider" for virtual/kernel. This is
> > > because
> > > OE puts the preferred provider's build and source at
> > > "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> > > "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> > > "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes
> > > using
> > > the
> > > default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> > > build
> > > in the old location and may be preferred provider -- while
> > > recipes
> > > using
> > > all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> > > don't
> > > provide "virtual/kernel".
> > > 
> > > Testing:
> > >   1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> > >  linux-yocto-tiny_4.9.bb so that it may build alongside
> > >  the main kernel.
> > >   2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> > > flavors.
> > >   3. Verified image and modules IPKs exist for both:
> > >  tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> > >  tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-
> > > tiny
> > >   4. Verified linux-yocto is the "preferred provider", and was
> > > built
> > > in
> > >  shared directory: tmp-glibc/work-shared/qemux86/kernel-*
> > >   5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> > >  core-image-base.bb to include both kernel flavors.
> > >   6. `bitbake core-image-base` to build an image.
> > >   7. Verified image contains two bzImage's under /boot/, with
> > >  "yocto-standard" selected to boot via symlink.
> > > 
> > > Discussion thread:
> > > http://lists.openembedded.org/pipermail/openembedded-core/2015-De
> > > cemb
> > > er/thread.html#114122
> > > 
> > > Signed-off-by: Ioan-Adrian Ratiu <adrian.ra...@ni.com>
> > > Signed-off-by: Gratian Crisan <gratian.cri...@ni.com>
> > > Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
> > > Coauthored-by: Gratian Crisan <gratian.cri...@ni.com>
> > > Coauthored-by: Haris Okanovic <haris.okano...@ni.com>
> > > Coauthored-by: Josh Hernstrom <josh.hernst...@ni.com>
> > > ---
> > > [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR
> > > to
> > > the
> > > "work" directory in alternate kernel builds, instead of "work-
> > > shared",
> > > so
> > > that the two builds don't clobber each other.
> > > 
> > > [PATCH v3] An updated version of this change rebased onto the
> > > current
> > > OE-core master. Changes:
> > >   * Remove PREFERRED_PROVIDER check in linux-yocto.inc in
> > > alternate
> > > kernel builds, since alternate kernels aren't the
> > > PREFERRED_PROVIDER for virtual/kernel by definition.
> > >   * Remove "virtual/kernel" from PROVIDES in alternate kernel
> > > builds.
> > > 
> > > [PATCH v4] Another rebase onto master; no functional change.
> > > Improved description and testing steps.
> > 
> > So I finally had a chance to get back to this and test build with
> > it, I
> > saw the following WARNING,

Re: [OE-core] [PATCH v4] kernel: Add support for multiple kernel packages

[Wold, Saul]

On Wed, 2017-07-05 at 12:33 -0500, Haris Okanovic wrote:
> Some distros may want to provide alternate kernel "flavors" via feeds
> or
> within bootable images. For example, readily available builds which
> provide certain diagnostic features can enable developers and testers
> to
> more quickly resolve issues by avoiding lengthy kernel builds.
> 
> This change allows for building multiple flavors of the kernel and
> module packages by templatizing kernel package names via a new
> KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
> old
> name of "kernel", but can be overridden by certain recipes providing
> alternate kernel flavors.
> 
> To maintain compatibility, recipes providing alternate kernel flavors
> cannot be the "preferred provider" for virtual/kernel. This is
> because
> OE puts the preferred provider's build and source at
> "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
> the
> default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> build
> in the old location and may be preferred provider -- while recipes
> using
> all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> don't
> provide "virtual/kernel".
> 
> Testing:
>  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> linux-yocto-tiny_4.9.bb so that it may build alongside
> the main kernel.
>  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> flavors.
>  3. Verified image and modules IPKs exist for both:
> tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
>  4. Verified linux-yocto is the "preferred provider", and was built
> in
> shared directory: tmp-glibc/work-shared/qemux86/kernel-*
>  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> core-image-base.bb to include both kernel flavors.
>  6. `bitbake core-image-base` to build an image.
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" selected to boot via symlink.
> 
> Discussion thread:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
> er/thread.html#114122
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> Signed-off-by: Gratian Crisan 
> Signed-off-by: Haris Okanovic 
> Coauthored-by: Gratian Crisan 
> Coauthored-by: Haris Okanovic 
> Coauthored-by: Josh Hernstrom 
> ---
> [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
> the
> "work" directory in alternate kernel builds, instead of "work-
> shared",
> so
> that the two builds don't clobber each other.
> 
> [PATCH v3] An updated version of this change rebased onto the current
> OE-core master. Changes:
>  * Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
>    kernel builds, since alternate kernels aren't the
>    PREFERRED_PROVIDER for virtual/kernel by definition.
>  * Remove "virtual/kernel" from PROVIDES in alternate kernel builds.
> 
> [PATCH v4] Another rebase onto master; no functional change.
> Improved description and testing steps.

So I finally had a chance to get back to this and test build with it, I
saw the following WARNING, which lead to the ERROR:

WARNING: Variable key FILES_${PN}-dev (${includedir} ${FILES_SOLIBSDEV}
${libdir}/*.la ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig
${datadir}/aclocal ${base_libdir}/*.o ${libdir}/${BPN}/*.la
${base_libdir}/*.la) replaces original key FILES_linux-yocto-dev
(/boot/System.map* /boot/Module.symvers* /boot/config*
${KERNEL_SRC_PATH}
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build).
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: QA Issue: linux-yocto: Files/directories were installed but
not shipped in any package:
  /boot/System.map-4.10.17-yocto-standard
  /boot/Module.symvers-4.10.17-yocto-standard
  /boot/config-4.10.17-yocto-standard
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install.
linux-yocto: 3 installed and not shipped files. [installed-vs-shipped]
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: Fatal QA errors found, failing task.
ERROR: linux-yocto-4.10.17+gitAUTOINC+e92bd55409_6648a34e00-r0
do_package: Function failed: do_package

Something seems to be causing the FILES_linux-yocto-dev info to be
overridden, I have not tracked down the culprit yet.

Sau!

> ---
>  meta/classes/kernel-module-split.bbclass  |  9 ++--
>  meta/classes/kernel.bbclass   | 85 ++---
> --
>  meta/conf/documentation.conf  |  1 +
>  meta/recipes-kernel/linux/linux-dtb.inc   |  2 +-
>  meta/recipes-kernel/linux/linux-yocto.inc |  2 +-
>  5 files changed, 59 

Re: [OE-core] [PATCH v3] pkg-config-native: allow kernel to be build with esdk

[Wold, Saul]

Ping, I believe I have addressed the issues with this, are there still
some concerns or issues with this patch?

On Tue, 2017-06-27 at 16:35 -0700, Saul Wold wrote:
> When the kernel's menuconfig target is called while using the esdk or
> an
> esdk-based container, the pkg-config info that is found is not
> correct.
> The pkg-config info is for the target, but we need the eSDK's
> information
> in order to build the host based menuconfig.
> 
> The new pkg-config-native script checks both that it's in SDK and
> being
> called from the check-lxdialog script in order to limit the scope of
> when
> the pkg-config automagically switches to pkg-config-native.
> 
> The pkg-config-esdk is only installed as pkg-config inside the eSDK,
> which
> is why we use the sstate post install script and check for if we are
> in the
> esdk environment.
> 
> Added an SDK_ARCH conversion to handle older 32bit installs since I
> now
> use the ARCH based name for pkg-config
> 
> [YOCTO #11155]
> 
> Signed-off-by: Saul Wold 
> ---
>  .../pkgconfig/pkgconfig/pkg-config-esdk.in | 24
> ++
>  .../pkgconfig/pkgconfig/pkg-config-native.in   |  2 +-
>  meta/recipes-devtools/pkgconfig/pkgconfig_git.bb   | 17
> +++
>  3 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/pkgconfig/pkgconfig/pkg-
> config-esdk.in
> 
> diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-
> esdk.in b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-
> esdk.in
> new file mode 100644
> index 000..948cc7a
> --- /dev/null
> +++ b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-esdk.in
> @@ -0,0 +1,24 @@
> +#! /bin/sh
> +
> +# Orignal pkg-config-native action when called as pkg-config-native
> +# NO Change here
> +if [ "pkg-config-native" = "`basename $0`" ] ; then
> + PKG_CONFIG_PATH="@PATH_NATIVE@"
> + PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
> + unset PKG_CONFIG_SYSROOT_DIR
> +else
> + # in this case we are in the esdk
> + if [ "$OE_SKIP_SDK_CHECK" = "1" ] ; then
> + parentpid=`ps -o ppid= -p $$`
> + parentpid_info=`ps -wo comm= -o args= -p $parentpid`
> +
> + # check if we are being called from  the kernel's
> make menuconfig
> + if ( echo $parentpid_info | grep -q check-lxdialog )
> ; then
> + PKG_CONFIG_PATH="@PATH_NATIVE@"
> + PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
> + unset PKG_CONFIG_SYSROOT_DIR
> + fi
> + fi
> +fi
> +
> +@SDK_ARCH@-pc-linux-gnu-pkg-config "$@"
> diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-
> native.in b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-
> native.in
> index 5e44bb4..3490d24 100644
> --- a/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
> +++ b/meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in
> @@ -4,4 +4,4 @@ PKG_CONFIG_PATH="@PATH_NATIVE@"
>  PKG_CONFIG_LIBDIR="@LIBDIR_NATIVE@"
>  unset PKG_CONFIG_SYSROOT_DIR
>  
> -pkg-config "$@"
> +@SDK_ARCH@-pc-linux-gnu-pkg-config "$@"
> diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
> b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
> index e634021..980c613 100644
> --- a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
> +++ b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
> @@ -12,6 +12,7 @@ SRCREV = "edf8e6f0ea77ede073f07bff0d2ae1fc7a38103b"
>  PV = "0.29.2+git${SRCPV}"
>  
>  SRC_URI = "git://anongit.freedesktop.org/pkg-config \
> +   file://pkg-config-esdk.in \
> file://pkg-config-native.in \
> file://fix-glib-configure-libtool-usage.patch \
> file://0001-glib-gettext.m4-Update-AM_GLIB_GNU_GETTEXT-
> to-match-.patch \
> @@ -52,6 +53,22 @@ RPROVIDES_${PN} += "pkgconfig(pkg-config)"
>  do_install_append_class-native () {
>  sed -e "s|@PATH_NATIVE@|${PKG_CONFIG_PATH}|" \
>  -e "s|@LIBDIR_NATIVE@|${PKG_CONFIG_LIBDIR}|" \
> +-e "s|@SDK_ARCH@|${SDK_ARCH}|" \
>  < ${WORKDIR}/pkg-config-native.in > ${B}/pkg-config-native
>  install -m755 ${B}/pkg-config-native ${D}${bindir}/pkg-config-
> native
> +sed -e "s|@PATH_NATIVE@|${PKG_CONFIG_PATH}|" \
> +-e "s|@LIBDIR_NATIVE@|${PKG_CONFIG_LIBDIR}|" \
> +-e "s|@SDK_ARCH@|${SDK_ARCH}|" \
> +< ${WORKDIR}/pkg-config-esdk.in > ${B}/pkg-config-esdk
> +install -m755 ${B}/pkg-config-esdk ${D}${bindir}/pkg-config-esdk
> +}
> +
> +PKGCONFIGBIN =
> "${COMPONENTS_DIR}/${BUILD_ARCH}/${PN}/${bindir_native}"
> +
> +pkgconfig_sstate_postinst () {
> + if [ "$OE_SKIP_SDK_CHECK" = "1" -a "${BB_CURRENTTASK}" =
> "populate_sysroot" -o "${BB_CURRENTTASK}" =
> "populate_sysroot_setscene" ] ; then
> + rm -rf ${PKGCONFIGBIN}/pkg-config
> + lnr ${PKGCONFIGBIN}/pkg-config-esdk
> ${PKGCONFIGBIN}/pkg-config
> + fi
>  }
> +SSTATEPOSTINSTFUNCS += "pkgconfig_sstate_postinst"
> -- 
> 2.7.5
> 
-- 

Re: [OE-core] [PATCH 7/7] libffi: Support musl-x32 build

[Wold, Saul]

On Wed, 2017-07-05 at 16:56 -0700, swee.aun.k...@intel.com wrote:
> From: sweeaun 
> 
> Upstream-Status: Pending.
The Upstream-Status needs to be in the .patch file, not in the main
patch commit.

See below

> Added target musl-x32 in configure.ac to support musl-x32 build in
> libffi.
> 
> Signed-off-by: sweeaun 
> ---
>  .../0001-libffi-Support-musl-x32-build.patch   | 29
> ++
>  meta/recipes-support/libffi/libffi_3.2.1.bb|  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 meta/recipes-support/libffi/libffi/0001-libffi-
> Support-musl-x32-build.patch
> 
> diff --git a/meta/recipes-support/libffi/libffi/0001-libffi-Support-
> musl-x32-build.patch b/meta/recipes-support/libffi/libffi/0001-
> libffi-Support-musl-x32-build.patch
> new file mode 100644
> index 000..971a543
> --- /dev/null
> +++ b/meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-
> x32-build.patch
> @@ -0,0 +1,29 @@
> +From 62ac8214b3e8b368bd9365a6920b081aa0125671 Mon Sep 17 00:00:00
> 2001
> +From: sweeaun 
> +Date: Mon, 3 Jul 2017 13:23:31 -0700
> +Subject: [PATCH] libffi: Support musl x32 build
> +
> +Support libffi build with target musl-x32.
> +
Upstream-Status goes here

Sau!

> +Signed-off-by: sweeaun 
> +---
> + configure.ac | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/configure.ac b/configure.ac
> +index a7bf5ee..f4e101d 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -180,6 +180,9 @@ case "$host" in
> + *-gnux32)
> +   TARGET=X86_64
> +   ;;
> ++*-muslx32)
> ++  TARGET=X86_64
> ++  ;;
> + *)
> +   TARGET=X86
> +   ;;
> +-- 
> +2.7.4
> +
> diff --git a/meta/recipes-support/libffi/libffi_3.2.1.bb
> b/meta/recipes-support/libffi/libffi_3.2.1.bb
> index 43eee8e..2a3f4b7 100644
> --- a/meta/recipes-support/libffi/libffi_3.2.1.bb
> +++ b/meta/recipes-support/libffi/libffi_3.2.1.bb
> @@ -13,6 +13,7 @@ SRC_URI = "ftp://sourceware.org/pub/libffi/${BP}.ta
> r.gz \
> file://not-win32.patch \
>      file://0001-mips-Use-compiler-internal-define-for-
> linux.patch \
> file://0001-mips-fix-MIPS-softfloat-build-issue.patch \
> +   file://0001-libffi-Support-musl-x32-build.patch \
>      "
>  
>  SRC_URI[md5sum] = "83b89587607e3eb65c70d361f13bab43"
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][pyro] mkelfimage: Fix broken patch when building native

[Wold, Saul]

Armin,

This should be a 2.3.1 candidate, it's now merged in master

Sau!


On Mon, 2017-06-05 at 15:47 -0700, Saul Wold wrote:
> A change occured about a year ago that broke the native build, fix
> that patch
> 
> [YOCTO #11590]
> 
> Signed-off-by: Saul Wold 
> ---
>  .../mkelfimage/mkelfimage/fix-makefile-to-find-libz.patch | 15
> +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage/fix-
> makefile-to-find-libz.patch b/meta/recipes-
> devtools/mkelfimage/mkelfimage/fix-makefile-to-find-libz.patch
> index 756a65c..be54754 100644
> --- a/meta/recipes-devtools/mkelfimage/mkelfimage/fix-makefile-to-
> find-libz.patch
> +++ b/meta/recipes-devtools/mkelfimage/mkelfimage/fix-makefile-to-
> find-libz.patch
> @@ -3,8 +3,11 @@ Let makefile find libz and zlib.h by CFLAGS and
> LDFLAGS.
>  Signed-off-by: Hongxu Jia 
>  Upstream-Status: Pending
>  ---
> + configure.ac | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
>  diff --git a/configure.ac b/configure.ac
> -index d1acc36..6f865b0 100644
> +index 0f2ac72..f9099a2 100644
>  --- a/configure.ac
>  +++ b/configure.ac
>  @@ -62,7 +62,7 @@ AC_CHECK_PROG([RPM],   rpm,   rpm,   [], [$PATH])
> @@ -16,15 +19,15 @@ index d1acc36..6f865b0 100644
>   
>   dnl Find the default programs
>   if test "with_default" != no ; then
> -@@ -175,7 +175,7 @@ fi
> - 
> +@@ -176,7 +176,7 @@ fi
>   dnl ---Output variables...
>   
> --HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS)"
> -+HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS) $CFLAGS"
> + CFLAGS="${CFLAGS:--O2} -Wall \$(CPPFLAGS)"
> +-HOST_CFLAGS="${HOST_CFLAGS:--O2} -Wall \$(HOST_CPPFLAGS)"
> ++HOST_CFLAGS="${HOST_CFLAGS:--O2} -Wall \$(HOST_CPPFLAGS) $CFLAGS"
>   
>   dnl TODO: figure out how to set these appropriately for compilers
> other than gcc
>   I386_CFLAGS="$I386_CFLAGS -Os -ffreestanding -Wall -W -Wno-format
> \$(I386_CPPFLAGS)"
>  -- 
> -1.7.10.4
> +2.7.4
>  
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/7] i#10073: generic EFI for wic

[Wold, Saul]

On Wed, 2017-05-17 at 13:47 +, Ed Bartosh wrote:
> Hi,
> 
> This patchset is an implementation of generic EFI approach for wic
> images.
> 
> Instead of introducing yet another wic plugin it uses existing APIs
> from
> EFI_PROVIDER classes to populate ${WORKDIR}/bootfs directory with EFI
> artifacts
> and bootloader configuration. This directory can be used by wic
> rootfs plugin
> to put into boot partition of the image.
> 
> Example kickstart file and 2 test cases were added to wic test suite
> to better
> illustrate the approach.
> 
> I personally like this approach much better than duplicating oe image
> creation
> functionality in wic plugins. This way we can have the code in one
> place and
> bootloaders can be configured the same way for oe and wic images.
> 

Ed,

I have been looking at this set of changes over the last few days, and
while I like the basic approach, I don't think it goes far enough.  I
am looking at how one would create a generic bootfs via a DEPLOY_DIR
and an image-bootfs.bb type of recipe that does the bootfs construction
instead of the existing systemd-boot or grub-efi bbclass construction.

This will allow for more flexibility in creating labels for
bootloaders, different types of boot loaders without having to create
classes.  We should then be able to construct the equivlant of hddimg
or iso images via a recipe that depends on the various do_deploy()
tasks of the images dependent items (syslinux, grub, virtual/kernel)
and configuration.

I think we are still too locked into prepare_wic_build() calling
build_efi_cfg and efi_bootfs_populate, which means wic still needs
knowledge of the boot loaders instead of just having a recipe populate
a bootfs partition and wic creating the partition and copying files
into it.

Maybe I am missing something, so please correct me if I am wrong.  I
have an example of what I am thinking of in contrib/sgw/wic_wip

Thanks

Sau!


> Changes in v2:
>  - added patch: fixed default value of GRUB_ROOT
>  - fixed typo in commit message: timage_types_wic > image_types_wic
> 
> Changes in v3:
>  - scheduled do_prepare_wic_build as earlier as possible
> 
> Changes in v4:
>  - fixed build on platforms that don't support EFI
>  - fixed non-gpl3 build
>  - fixed build failure in systemd-boot code caused by rescheduled
>    do_populate_bootfs to run earlier
> 
> The following changes since commit
> 920e1592fba8fd714b8fdf87f9792ebfa3377793:
> 
>   selftest: fix test_unsupported_subcommand test case (2017-05-17
> 13:35:28 +)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib ed/wic/wip
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/wic/wip
> 
> Ed Bartosh (7):
>   systemd-boot: create output dir if it doesn't exist
>   efi: add efi_bootfs_populate API
>   image_types_wic: add do_populate_bootfs task
>   image_types_wic: merged 2 tasks
>   oe-selftest: add wic tests for generic EFI
>   grub-efi: fixed default value of GRUB_ROOT
>   image_types_wic: schedule prepare_wic_build correctly
> 
>  meta-selftest/wic/test_generic_efi.wks.in |  9 
>  meta/classes/grub-efi.bbclass | 14 +++--
>  meta/classes/image_types_wic.bbclass  | 85
> +++
>  meta/classes/systemd-boot.bbclass |  8 +++
>  meta/lib/oeqa/selftest/wic.py | 36 +
>  5 files changed, 126 insertions(+), 26 deletions(-)
>  create mode 100644 meta-selftest/wic/test_generic_efi.wks.in
> 
> -- 
> Regards,
> Ed
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 7/7] image_types_wic: schedule prepare_wic_build correctly

[Wold, Saul]

On Wed, 2017-05-17 at 13:47 +, Ed Bartosh wrote:
> Scheduled prepare_wic_build only if wic build enabled.
> Added dependencies to kernel and efi bootloader deploy
> tasks only if EFI is enabled.
> 
> This should fix build failure on machines without
> EFI functionality.
> 
> Signed-off-by: Ed Bartosh 
> ---
>  meta/classes/image_types_wic.bbclass | 27 ++--
> ---
>  1 file changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/meta/classes/image_types_wic.bbclass
> b/meta/classes/image_types_wic.bbclass
> index d8430e49ac..3b73261d5e 100644
> --- a/meta/classes/image_types_wic.bbclass
> +++ b/meta/classes/image_types_wic.bbclass
> @@ -69,6 +69,11 @@ python () {
>  # file in process_wks_template as well, so just put
> it in
>  # a variable and let the metadata deal with the
> deps.
>  d.setVar('_WKS_TEMPLATE', body)
> +
> +bb.build.addtask('do_prepare_wic_build', 'do_image_wic',
> None, d)
> +if d.getVar('EFI_CLASS'):
> +d.appendVarFlag('do_prepare_wic_build', 'depends',
> +'%s%s:do_deploy 
> virtual/kernel:do_deploy' % (d.getVar('MLPREFIX'),
> d.getVar('EFI_CLASS')))

Ed, 
Have you tested this with any layers?  I tied recently with meta-
intel and tripped over an issue with the rmc-boot not having an actual
target for the EFI_CLASS to have a deploy task caused a failure.

Sau!

>  }
>  
>  #
> @@ -139,19 +144,15 @@ python do_prepare_wic_build() {
>  with open(wks_file, 'w') as f:
>  f.write(template_body)
>  
> -if d.getVar('USING_WIC'):
> -# Generate parition UUID
> -from uuid import uuid4
> -partuuid = str(uuid4())
> -d.setVar("ROOTFS_PARTUUID", partuuid)
> +# Generate parition UUID
> +from uuid import uuid4
> +partuuid = str(uuid4())
> +d.setVar("ROOTFS_PARTUUID", partuuid)
>  
> -if d.getVar("EFI_CLASS"):
> -populate_bootfs(partuuid)
> +if d.getVar("EFI_CLASS"):
> +populate_bootfs(partuuid)
>  
> -template = d.getVar("_WKS_TEMPLATE")
> -if template:
> -write_wks_template(template, d.getVar('WKS_FULL_PATH'))
> +template = d.getVar("_WKS_TEMPLATE")
> +if template:
> +write_wks_template(template, d.getVar('WKS_FULL_PATH'))
>  }
> -
> -addtask do_prepare_wic_build before do_image_wic
> -do_prepare_wic_build[depends] =
> "${MLPREFIX}${EFI_PROVIDER}:do_deploy virtual/kernel:do_deploy"
> -- 
> 2.12.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 0/3] Set linux-firmware to correct license

[Wold, Saul]

On Wed, 2017-04-12 at 16:25 +0100, Richard Purdie wrote:
> On Sun, 2017-04-09 at 18:58 -0700, wei.tee...@intel.com wrote:
> > 
> > From: "Ng, Wei Tee" 
> > 
> > This is the revised version to fix the ipk packaging error as
> > below:
> > ERROR: linux-firmware-1_0.0+gitAUTOINC+b14134583c-r0
> > do_package_write_ipk: Function failed: do_package_ipk
> > 
> > These patches is to update the SRCREV of linux-firmware to the
> > latest
> > HEAD
> > and set the license file explicitly for linux-firmware-carl9170 to
> > GPL-2.
> > This also targeted to solve the Bugzilla ID 11090.
> > 
> > The SRCREV for linux-firmware was updated to the latest in order to
> > include the GPL-2 license file. The netronome firmware was removed
> > until rpm packaging issue is resolved.
> >  
> > This configuration are build and tested for ipk, rpm and deb
> > packaging.
> >  
> > Please review and provide feedback if you have any.
> 
> We can't upgrade this recipe at this point in the release unless
> there
> is a pressing reason to. You don't list any reason at all for the
> upgrade here so I can only assume there isn't one. This patch and the
> ones that depend on it will therefore have to wait for 2.4.
> 
Richard,

I would like to advocate that this is similar to the kernel, there are
new firmware packages available for new hardware and if we want to be
supporting leading edge hardware, we need to have the latest versions
of linux-firmware.

This is what I consider a leaf recipe, it does not directly affect
other and is therefore fairly safe to take the latest version.

Please consider this for 2.3, thanks!

Sau!

> Cheers,
> 
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] native.bbclass: populate native recipe with it's files

[Wold, Saul]

Drop this, apparently Richard already applied this and I was looking at
an older master branch when I sent this.

Sau!

On Thu, 2017-03-02 at 15:25 -0800, Saul Wold wrote:
> This allows a native package's recipe-sysroot-native to be populated
> with
> that packages native image files.  This in turns allows it to be used
> by
> scripts or other tools without creating un-necessary DEPENDS.
> 
> An example of this is systemtap-native and the crosstap script.
> 
> Signed-off-by: Saul Wold 
> ---
> v2: removed the "before do_build"
>  meta/classes/native.bbclass | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/native.bbclass
> b/meta/classes/native.bbclass
> index ec91fc3..6becf82 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -174,6 +174,11 @@ python native_virtclass_handler () {
>  addhandler native_virtclass_handler
>  native_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>  
> +python do_addto_recipe_sysroot () {
> +bb.build.exec_func("extend_recipe_sysroot", d)
> +}
> +addtask addto_recipe_sysroot after do_populate_sysroot
> +
>  inherit nopackages
>  
>  do_packagedata[stamp-extra-info] = ""
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] kernel.bbclass: Make sanity check opt-out and provide easy opt-out

[Wold, Saul]

This should also be applied Morty please

Sau!

On Thu, 2017-02-09 at 15:55 -0800, California Sullivan wrote:
> Having no opt-out method and adding the task to linux-yocto.inc was
> causing issues. For example, linux-yocto-dev would often fail because
> it uses AUTOINC with no way to dynamically change the PV.
> 
> Add a variable to turn off the sanity check to easily opt out.
> Add the task to the kernel build by default so that it is not both
> opt-in and opt out.
> Set the opt-out variable in linux-yocto-dev, fixing the issue with
> AUTOINC.
> 
> Signed-off-by: California Sullivan 
> ---
>  meta/classes/kernel.bbclass  | 8 +++-
>  meta/recipes-kernel/linux/linux-yocto-dev.bb | 1 +
>  meta/recipes-kernel/linux/linux-yocto.inc| 1 -
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass
> b/meta/classes/kernel.bbclass
> index f462b2f..3968d8b 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -325,6 +325,10 @@ do_install[prefuncs] += "package_get_auto_pr"
>  
>  # Must be ran no earlier than after do_kernel_checkout or else
> Makefile won't be in ${S}/Makefile
>  do_kernel_version_sanity_check() {
> + if [ "x${KERNEL_VERSION_SANITY_SKIP}" = "x1" ]; then
> + exit 0
> + fi
> +
>   # The Makefile determines the kernel version shown at
> runtime
>   # Don't use KERNEL_VERSION because the headers it grabs the
> version from aren't generated until do_compile
>   VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ *//)
> @@ -348,11 +352,13 @@ do_kernel_version_sanity_check() {
>   reg="${reg}${EXTRAVERSION}"
>  
>   if [ -z `echo ${PV} | grep -E "${reg}"` ]; then
> - bbfatal "Package Version (${PV}) does not match of
> kernel being built (${vers}). Please update the PV variable to match
> the kernel source."
> + bbfatal "Package Version (${PV}) does not match of
> kernel being built (${vers}). Please update the PV variable to match
> the kernel source or set KERNEL_VERSION_SANITY_SKIP=\"1\" in your
> recipe."
>   fi
>   exit 0
>  }
>  
> +addtask kernel_version_sanity_check after do_kernel_metadata
> do_kernel_checkout before do_compile
> +
>  addtask shared_workdir after do_compile before
> do_compile_kernelmodules
>  addtask shared_workdir_setscene
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> index 0cda553..1410954 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> @@ -43,3 +43,4 @@ KERNEL_FEATURES_append_qemux86=" cfg/sound.scc
> cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
>  KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES",
> "mx32", " cfg/x32.scc", "" ,d)}"
>  
> +KERNEL_VERSION_SANITY_SKIP = "1"
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 556546f..3ea3e40 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -64,7 +64,6 @@ do_install_append(){
>  }
>  
>  # extra tasks
> -addtask kernel_version_sanity_check after do_kernel_metadata
> do_kernel_checkout before do_compile
>  addtask kernel_link_images after do_compile before do_strip
>  addtask validate_branches before do_patch after do_kernel_checkout
>  addtask kernel_configcheck after do_configure before do_compile
> -- 
> 2.5.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/16] gnu-efi: build 64-bit for x32

[Wold, Saul]

On Thu, 2017-01-05 at 12:46 -0700, Christopher Larson wrote:
> From: Christopher Larson 
> 
> We're targeting the x86_64 EFI ABI.
> 
Chris, 

Firstly, thanks for all the x32 patches!

I tried to build gnu-efi for x32 via genericx86-64 and still got a
failure about missing the gnu/stubs-64.h. I am building pure x32, is it
possibly you build x32 in a TMPDIR that already had a 64bit build?

There is a generated stubs-x32.h, but not the required -64 variant.

Can you confirm this builds correctly?

Thanks

Sau!

> Signed-off-by: Christopher Larson 
> ---
>  meta/recipes-bsp/gnu-efi/gnu-efi_3.0.4.bb | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.4.bb
> b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.4.bb
> index 9ddc4ba..e55ab7f 100644
> --- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.4.bb
> +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.4.bb
> @@ -52,3 +52,12 @@ BBCLASSEXTEND = "native"
>  # CFLAGS += -mno-mmx -mno-sse
>  # So also remove -mfpmath=sse from TUNE_CCARGS
>  TUNE_CCARGS_remove = "-mfpmath=sse"
> +
> +python () {
> +ccargs = d.getVar('TUNE_CCARGS', True).split()
> +if '-mx32' in ccargs:
> +# use x86_64 EFI ABI
> +ccargs.remove('-mx32')
> +ccargs.append('-m64')
> +d.setVar('TUNE_CCARGS', ' '.join(ccargs))
> +}
> -- 
> 2.8.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nfs-utils: remove -f exports from nfsserver

[Wold, Saul]

On Thu, 2016-12-22 at 16:07 -0800, Saul Wold wrote:
> The upstream project remove that option as it was quote:
> It is completely ineffective.
> 
Ross: Ping

Sau!

> [YOCTO #10843]
> 
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
> b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
> index 7ed93a5..d5e9c38 100644
> --- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
> @@ -40,7 +40,7 @@ test "$NFS_SERVERS" != "" && test "$NFS_SERVERS"
> -gt 0 && test "$NFS_SERVERS" -l
>  #mountd
>  start_mountd(){
>   echo -n 'starting mountd: '
> - start-stop-daemon --start --exec "$NFS_MOUNTD" -- "-f
> /etc/exports $@"
> + start-stop-daemon --start --exec "$NFS_MOUNTD" -- "$@"
>   echo done
>  }
>  stop_mountd(){
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/2] gummiboot: Remove/change gummiboot references with systemd-boot

[Wold, Saul]

Ping!  Unfortunately this missed M1, but can we get it into M2 Early
please.

Thanks
  Sau!


On Wed, 2016-11-30 at 12:00 -0600, Alejandro Hernandez wrote:
> After systemd-boot was introduced, its been tested for a while with
> no major
> issues being found until now, this patch completely replaces all
> gummiboot
> instances with systemd-boot ones, taking the next step into cleaning
> up systemd-boot/gummiboot.
> 
> [YOCTO #10332]
> 
> Signed-off-by: Alejandro Hernandez  om>
> ---
>  meta/classes/fs-uuid.bbclass   |  2 +-
>  meta/classes/systemd-boot.bbclass  |  4 +---
>  meta/conf/distro/include/distro_alias.inc  |  2 +-
>  meta/lib/oeqa/controllers/masterimage.py   |  4 ++--
>  meta/lib/oeqa/selftest/wic.py  |  6 ++---
>  meta/recipes-bsp/systemd-boot/systemd-boot.bb  |  2 +-
>  .../initrdscripts/files/init-install-efi-testfs.sh | 12 +-
>  .../initrdscripts/files/init-install-efi.sh| 12 +-
>  scripts/contrib/mkefidisk.sh   | 26 +++-
> --
>  scripts/lib/wic/plugins/source/bootimg-efi.py  | 22 +---
> --
>  10 files changed, 44 insertions(+), 48 deletions(-)
> 
> diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-
> uuid.bbclass
> index bd2613c..1d5d0c3 100644
> --- a/meta/classes/fs-uuid.bbclass
> +++ b/meta/classes/fs-uuid.bbclass
> @@ -13,7 +13,7 @@ def get_rootfs_uuid(d):
>  bb.fatal('Could not determine filesystem UUID of %s' % rootfs)
>  
>  # Replace the special <> inside a string (like the
> -# root= APPEND string in a syslinux.cfg or gummiboot entry) with the
> +# root= APPEND string in a syslinux.cfg or systemd-boot entry) with
> the
>  # actual UUID of the rootfs. Does nothing if the special string
>  # is not used.
>  def replace_rootfs_uuid(d, string):
> diff --git a/meta/classes/systemd-boot.bbclass
> b/meta/classes/systemd-boot.bbclass
> index 05244c7..3398218 100644
> --- a/meta/classes/systemd-boot.bbclass
> +++ b/meta/classes/systemd-boot.bbclass
> @@ -4,9 +4,7 @@
>  
>  # systemd-boot.bbclass - The "systemd-boot" is essentially the
> gummiboot merged into systemd.
>  #The original standalone gummiboot project
> is dead without any more
> -#maintenance. As a start point, we replace
> all gummitboot occurrences
> -#with systemd-boot in gummiboot.bbclass to
> have a base version of this
> -#systemd-boot.bbclass.
> +#maintenance.
>  #
>  # Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live
> images instead of grub-efi
>  # (images built by image-live.bbclass or image-vm.bbclass)
> diff --git a/meta/conf/distro/include/distro_alias.inc
> b/meta/conf/distro/include/distro_alias.inc
> index 10efb09..9c82854 100644
> --- a/meta/conf/distro/include/distro_alias.inc
> +++ b/meta/conf/distro/include/distro_alias.inc
> @@ -135,7 +135,7 @@ DISTRO_PN_ALIAS_pn-gtk-doc = "Fedora=gtk-doc
> Ubuntu=gtk-doc"
>  DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-
> engines Ubuntu=gtk2-engines Mandriva=gtk-engines2 Debian=gtk2-
> engines"
>  DISTRO_PN_ALIAS_pn-gtk-sato-engine = "OpenedHand"
>  DISTRO_PN_ALIAS_pn-gtk-icon-utils-native = "OSPDT"
> -DISTRO_PN_ALIAS_pn-gummiboot = "Debian=gummiboot Fedora=gummiboot"
> +DISTRO_PN_ALIAS_pn-systemd-boot = "Ubuntu=systemd-boot
> Fedora=systemd-boot"
>  DISTRO_PN_ALIAS_pn-hello-mod = "OE-Core"
>  DISTRO_PN_ALIAS_pn-hostap-conf = "OE-Core"
>  DISTRO_PN_ALIAS_pn-hwlatdetect = "OSPDT"
> diff --git a/meta/lib/oeqa/controllers/masterimage.py
> b/meta/lib/oeqa/controllers/masterimage.py
> index 9ce3bf8..7fcbb6d 100644
> --- a/meta/lib/oeqa/controllers/masterimage.py
> +++ b/meta/lib/oeqa/controllers/masterimage.py
> @@ -159,10 +159,10 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget,
> metaclass=ABCMeta
>  self.power_cycle(self.connection)
>  
>  
> -class GummibootTarget(MasterImageHardwareTarget):
> +class SystemdbootTarget(MasterImageHardwareTarget):
>  
>  def __init__(self, d):
> -super(GummibootTarget, self).__init__(d)
> +super(SystemdbootTarget, self).__init__(d)
>  # this the value we need to set in the LoaderEntryOneShot
> EFI variable
>  # so the system boots the 'test' bootloader label and not
> the default
>  # The first four bytes are EFI bits, and the rest is an utf-
> 16le string
> diff --git a/meta/lib/oeqa/selftest/wic.py
> b/meta/lib/oeqa/selftest/wic.py
> index faac11e..61081cc 100644
> --- a/meta/lib/oeqa/selftest/wic.py
> +++ b/meta/lib/oeqa/selftest/wic.py
> @@ -243,9 +243,9 @@ class Wic(oeSelfTest):
>  self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" %
> image)))
>  
>  @testcase(1349)
> -def test_mkgummidisk(self):
> -"""Test creation of mkgummidisk image"""
> -image = "mkgummidisk"
> +

Re: [OE-core] [PATCH][master][krogoth] archiver: fix gcc-source handling

[Wold, Saul]

This has been merged to master ping for Krogoth

Sau!

On Mon, 2016-10-10 at 11:32 -0700, Saul Wold wrote:
> 
> The source archiver was not handling the gcc-source target correctly,
> since it uses the
> work-shared directory, we don't want to unpack and patch it twice,
> just as the comments
> say, but the code was not there to check for the gcc-source target.
> 
> [YOCTO #10265]
> 
> Signed-off-by: Saul Wold 
> ---
> 
>  meta/classes/archiver.bbclass | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/archiver.bbclass
> b/meta/classes/archiver.bbclass
> index 1d8e863..9239983 100644
> --- a/meta/classes/archiver.bbclass
> +++ b/meta/classes/archiver.bbclass
> @@ -303,9 +303,10 @@ python do_unpack_and_patch() {
>  return
>  ar_outdir = d.getVar('ARCHIVER_OUTDIR', True)
>  ar_workdir = d.getVar('ARCHIVER_WORKDIR', True)
> +pn = d.getVar('PN', True)
>  
>  # The kernel class functions require it to be on work-shared, so
> we dont change WORKDIR
> -if not bb.data.inherits_class('kernel-yocto', d):
> +if not (bb.data.inherits_class('kernel-yocto', d) or
> pn.startswith('gcc-source')):
>  # Change the WORKDIR to make do_unpack do_patch run in
> another dir.
>  d.setVar('WORKDIR', ar_workdir)
>  
> @@ -323,7 +324,7 @@ python do_unpack_and_patch() {
>  oe.path.copytree(src, src_orig)
>  
>  # Make sure gcc and kernel sources are patched only once
> -if not ((d.getVar('SRC_URI', True) == "" or
> bb.data.inherits_class('kernel-yocto', d))):
> +if not (d.getVar('SRC_URI', True) == "" or
> (bb.data.inherits_class('kernel-yocto', d) or pn.startswith('gcc-
> source'))):
>  bb.build.exec_func('do_patch', d)
>  
>  # Create the patches
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core