Date   

Re: yocto documentation: no content, no PDF?

Leonardo Sandoval
 

On Wed, 8 Nov 2017 16:30:39 +0000
"Burton, Ross" <ross.burton@...> wrote:

On 8 November 2017 at 15:41, Jerry Lian <jerry.lian@...> wrote:

Just wondering:
* As an active project, why yocto documentation does not provide a content
(better be clickable)?
The megamanual (Complete Documentation) doesn't have a top-level table of
contents as that basically exists to search globally. The real docs (such
as Tasks Manual) have a top level table of contents.

* Or PDF format for easy printing.
Try running

make pdf DOC=ref-manual


(then drink so coffee and wait) After it, the pdf manual is there. There are other manuals as well, this is just an example cmd.

Leo


That would be massive. The source is in git as docbook so it's fairly
simple to generate a PDF.



Ross


Re: KBUILD_DEFCONFIG_KMACHINE not used anywhere

Alan
 

Sure.

The layer that will fetch all the other layers by running make:

Things like the KBUILD_DEFCONFIG that you are trying to use, are
that extra level of processing that weren't needed/wanted in the
core part.

Alrighty, think I'm getting it now.

do_kernel_configme has more processing and logic to deal with
kernel config fragments and wasn't something that was desired to be
imposed on all build (but I do have a streamlined version that moves
the logic into the core class now .. that will be out for review
shortly).

Cool, would like to see how the discussion will go.


On Thu, Nov 9, 2017 at 4:59 PM, Bruce Ashfield <bruce.ashfield@...> wrote:
On 11/09/2017 10:53 AM, Alan Martinovic wrote:
      - what branch/release of yocto are you using ?


Morty

    - can you try just using: KBUILD_DEFCONFIG="senic_defconfig"


Yup, same error.

    .. and finally, the KBUILD_DEFCONFIG processing is meant to pick
    up in-tree defconfigs for use in the build, so whatever you reference
    must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
    sure that is the case with senic_defconfig.


Yup, it's in there.


    You can always add the defconfig directly to the SRC_URI as well
    (i.e. copy it into your layer and call it 'defconfig' and add it
    to the SRC_URI like any other element.


Yup, am using that as a workaround .

What is the difference between do_kernel_configme and do_configure?

do configure is the existing/traditional/common/simple kernel.bbclass
way to copy a defconfig and make sure it gets into the build.

do_kernel_configme has more processing and logic to deal with
kernel config fragments and wasn't something that was desired to be
imposed on all build (but I do have a streamlined version that moves
the logic into the core class now .. that will be out for review
shortly).

Things like the KBUILD_DEFCONFIG that you are trying to use, are
that extra level of processing that weren't needed/wanted in the
core part.

Not quite clear on why both exist.
I ask because I originally wanted to override do_configure as a fix,
and it seems that wouldn't have helped because it fails at do_kernel_configme.

Are the recipes / kernel tree something I can find ? If I can just
launch a build, I'm sure I can point out what is wrong pretty
quickly.

Bruce



On Thu, Nov 9, 2017 at 3:13 PM, Bruce Ashfield <bruce.ashfield@... <mailto:bruce.ashfield@windriver.com>> wrote:

    On 2017-11-09 8:11 AM, Alan Martinovic wrote:

             What is your kernel recipe ? Something you wrote, or something
             from a vendor ?


        Something I inherited.
        It does seem to have been based on linux-yocto-custom.bb
        <http://linux-yocto-custom.bb> <http://linux-yocto-custom.bb>.


        SECTION = "kernel"
        DESCRIPTION = "Mainline Linux kernel"
        LICENSE = "GPLv2"
        LIC_FILES_CHKSUM =
        "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

        COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"

        inherit kernel
        require recipes-kernel/linux/linux-yocto.inc

        KBRANCH = "senic/4.13"
        SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"

        PV = "4.13+git${SRCPV}"
        S = "${WORKDIR}/git"

        KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"

        SRC_URI =
        "git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}
        <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>
        <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}
        <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>>

        \
                    "


        Running it with:

        bitbake -v linux-senic


        It fails with:

        ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
        do_kernel_configme: Could not configure senic-hub-beta-standard
        ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
        do_kernel_configme: Function failed: do_kernel_configme (log
        file is located at /home/alan/senic-o
        s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)

        ERROR: Logfile of failure stored in:
        /home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
        18af-r0/temp/log.do_kernel_configme.5641


        Not sure when "-standard" got appended...?


    That's just part of the localversion processing in the bbclass, so
    no worries there.

        A more exact error seems to be:

        linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: +
        configs=[ERROR]: no configuration queue found in outdir
        (.kernel-meta)

        Could it be expecting a "linux-yocto style" with the meta branches?


    Nope. Well, you do need some sort of configuration available, but it
    doesn't have to be in that format.

    That error is indicating that no configuration was found (no defconfig
    or fragments).

    A couple more questions, and I can probably sort this out.

    - what branch/release of yocto are you using ?
    - can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

    For that second one, I'm wondering if the variable expansion is not
    working with the machine override.

    .. and finally, the KBUILD_DEFCONFIG processing is meant to pick
    up in-tree defconfigs for use in the build, so whatever you reference
    must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
    sure that is the case with senic_defconfig.

    You can always add the defconfig directly to the SRC_URI as well
    (i.e. copy it into your layer and call it 'defconfig' and add it
    to the SRC_URI like any other element.

    Bruce




        On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield
        <bruce.ashfield@...
        <mailto:bruce.ashfield@windriver.com>
        <mailto:bruce.ashfield@windriver.com

        <mailto:bruce.ashfield@windriver.com>>> wrote:

             On 11/07/2017 08:46 AM, Alan Martinovic wrote:

                 Hi,
                 I'm trying to get yocto to build the kernel with an in-tree
                 defconfig.
                 For that I found references to the variable
                 KBUILD_DEFCONFIG_KMACHINE.

                 However, I've been experiencing that the kernel is
        being built with
                 some default defconfig, and not the in-tree one that
        came with the
                 kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.

                 I've looked through all yocto sources for where the
                 KBUILD_DEFCONFIG_KMACHINE is actually used, and found
        it only in my
                 kernel recipe. So I decided to dissect my recipe.


             What is your kernel recipe ? Something you wrote, or something
             from a vendor ?



                 There is a:

                 inherit kernel

                 in my recipe for which, besides others, defines how the
        kernel
                 config
                 will be selected.
                 Looking at the sources of
        oe/meta/classes/kernel.bbclass exposes how
                 the kernel configuration happens:

                 kernel_do_configure() {
                           # fixes extra + in /lib/modules/2.6.37+
                           # $ scripts/setlocalversion . => +
                           # $ make kernelversion => 2.6.37
                           # $ make kernelrelease => 2.6.37+
                           touch ${B}/.scmversion ${S}/.scmversion

                           if [ "${S}" != "${B}" ] && [ -f
        "${S}/.config" ] && [ ! -f
                 "${B}/.config" ]; then
                                   mv "${S}/.config" "${B}/.config"
                           fi

                           # Copy defconfig to .config if .config does
        not exist.
                 This allows
                           # recipes to manage the .config themselves in
                 do_configure_prepend().
                           if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
                 "${B}/.config" ]; then
                                   cp "${WORKDIR}/defconfig" "${B}/.config"
                           fi

                           ${KERNEL_CONFIG_COMMAND}
                 }


                 I'm planning a workaround by overriding the
        do_configure in my
                 recipe
                 to select the correct defconfig from the kernel. It
        does seem
                 however
                 like the KBUILD_DEFCONFIG_KMACHINE is exactly here to
        not have to do
                 the workarounds.

                 Anyone has experiences with successfully using
                 KBUILD_DEFCONFIG_KMACHINE?
                 Is it a specific poky feature (I'm not using poky but
        specific open
                 embedded layers and bitbake)?

             That is a feature of kernel-yocto, so if your recipe is
        inheriting
             kernel-yocto you can use what you are looking for.

             But note, in the documentation you are referencing you have
        to replace
             KMACHINE with your actual machine .. not use the string
        KMACHINE.

             i.e. in your recipe (or bbappend)

             # for cases where the KMACHINE (KERNEL MACHINE) and bitbake
             # machine match, just do this:
             KMACHINE=$MACHINE

             KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"

             i.e. it is just a standard bitbake variable with a machine
        OVERRIDE
             to make it specific to the machine you are building.

             Bruce



                 Be Well,
                 Alan

                 Ref.
        https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
        <https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>
                        <https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
        <https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>>








Re: Layer index not updated

Leonardo Sandoval
 

On Thu, 9 Nov 2017 09:36:26 +0100
Andreas Müller <schnitzeltony@...> wrote:

Hi,

did not find any heads up here so: Layer index stopped updating ~1,5 month.
Low priority - this is just notification & thanks in advance for taking
care :)
Do you mind filing a bug so it can be tracked better?

[1] https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Layer%20Index


Andreas


Re: KBUILD_DEFCONFIG_KMACHINE not used anywhere

Bruce Ashfield <bruce.ashfield@...>
 

On 11/09/2017 10:53 AM, Alan Martinovic wrote:
 - what branch/release of yocto are you using ?
Morty
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"
Yup, same error.
.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
sure that is the case with senic_defconfig.
Yup, it's in there.
You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.
Yup, am using that as a workaround .
What is the difference between do_kernel_configme and do_configure?
do configure is the existing/traditional/common/simple kernel.bbclass
way to copy a defconfig and make sure it gets into the build.

do_kernel_configme has more processing and logic to deal with
kernel config fragments and wasn't something that was desired to be
imposed on all build (but I do have a streamlined version that moves
the logic into the core class now .. that will be out for review
shortly).

Things like the KBUILD_DEFCONFIG that you are trying to use, are
that extra level of processing that weren't needed/wanted in the
core part.

Not quite clear on why both exist.
I ask because I originally wanted to override do_configure as a fix,
and it seems that wouldn't have helped because it fails at do_kernel_configme.
Are the recipes / kernel tree something I can find ? If I can just
launch a build, I'm sure I can point out what is wrong pretty
quickly.

Bruce

On Thu, Nov 9, 2017 at 3:13 PM, Bruce Ashfield <bruce.ashfield@... <mailto:bruce.ashfield@...>> wrote:
On 2017-11-09 8:11 AM, Alan Martinovic wrote:
    What is your kernel recipe ? Something you wrote, or something
    from a vendor ?
Something I inherited.
It does seem to have been based on linux-yocto-custom.bb
<http://linux-yocto-custom.bb> <http://linux-yocto-custom.bb>.
SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"
PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"
KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"
SRC_URI =
"git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}
<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>
<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}
<http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>>
\
           "
Running it with:
bitbake -v linux-senic
It fails with:
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
do_kernel_configme: Could not configure senic-hub-beta-standard
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0
do_kernel_configme: Function failed: do_kernel_configme (log
file is located at /home/alan/senic-o
s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)
ERROR: Logfile of failure stored in:
/home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
18af-r0/temp/log.do_kernel_configme.5641
Not sure when "-standard" got appended...?
That's just part of the localversion processing in the bbclass, so
no worries there.
A more exact error seems to be:
linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: +
configs=[ERROR]: no configuration queue found in outdir
(.kernel-meta)
Could it be expecting a "linux-yocto style" with the meta branches?
Nope. Well, you do need some sort of configuration available, but it
doesn't have to be in that format.
That error is indicating that no configuration was found (no defconfig
or fragments).
A couple more questions, and I can probably sort this out.
- what branch/release of yocto are you using ?
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"
For that second one, I'm wondering if the variable expansion is not
working with the machine override.
.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
sure that is the case with senic_defconfig.
You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.
Bruce
On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield
<bruce.ashfield@...
<mailto:bruce.ashfield@...>
<mailto:bruce.ashfield@...
<mailto:bruce.ashfield@...>>> wrote:
    On 11/07/2017 08:46 AM, Alan Martinovic wrote:
        Hi,
        I'm trying to get yocto to build the kernel with an in-tree
        defconfig.
        For that I found references to the variable
        KBUILD_DEFCONFIG_KMACHINE.
        However, I've been experiencing that the kernel is
being built with
        some default defconfig, and not the in-tree one that
came with the
        kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.
        I've looked through all yocto sources for where the
        KBUILD_DEFCONFIG_KMACHINE is actually used, and found
it only in my
        kernel recipe. So I decided to dissect my recipe.
    What is your kernel recipe ? Something you wrote, or something
    from a vendor ?
        There is a:
        inherit kernel
        in my recipe for which, besides others, defines how the
kernel
        config
        will be selected.
        Looking at the sources of
oe/meta/classes/kernel.bbclass exposes how
        the kernel configuration happens:
        kernel_do_configure() {
                  # fixes extra + in /lib/modules/2.6.37+
                  # $ scripts/setlocalversion . => +
                  # $ make kernelversion => 2.6.37
                  # $ make kernelrelease => 2.6.37+
                  touch ${B}/.scmversion ${S}/.scmversion
                  if [ "${S}" != "${B}" ] && [ -f
"${S}/.config" ] && [ ! -f
        "${B}/.config" ]; then
                          mv "${S}/.config" "${B}/.config"
                  fi
                  # Copy defconfig to .config if .config does
not exist.
        This allows
                  # recipes to manage the .config themselves in
        do_configure_prepend().
                  if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
        "${B}/.config" ]; then
                          cp "${WORKDIR}/defconfig" "${B}/.config"
                  fi
                  ${KERNEL_CONFIG_COMMAND}
        }
        I'm planning a workaround by overriding the
do_configure in my
        recipe
        to select the correct defconfig from the kernel. It
does seem
        however
        like the KBUILD_DEFCONFIG_KMACHINE is exactly here to
not have to do
        the workarounds.
        Anyone has experiences with successfully using
        KBUILD_DEFCONFIG_KMACHINE?
        Is it a specific poky feature (I'm not using poky but
specific open
        embedded layers and bitbake)?
    That is a feature of kernel-yocto, so if your recipe is
inheriting
    kernel-yocto you can use what you are looking for.
    But note, in the documentation you are referencing you have
to replace
    KMACHINE with your actual machine .. not use the string
KMACHINE.
    i.e. in your recipe (or bbappend)
    # for cases where the KMACHINE (KERNEL MACHINE) and bitbake
    # machine match, just do this:
    KMACHINE=$MACHINE
    KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"
    i.e. it is just a standard bitbake variable with a machine
OVERRIDE
    to make it specific to the machine you are building.
    Bruce
        Be Well,
        Alan
        Ref.
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
<https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>
<https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
<https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>>


Re: KBUILD_DEFCONFIG_KMACHINE not used anywhere

Alan
 

 - what branch/release of yocto are you using ?

Morty
 
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

Yup, same error.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
sure that is the case with senic_defconfig.

Yup, it's in there.


You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.

Yup, am using that as a workaround . 

What is the difference between do_kernel_configme and do_configure?
Not quite clear on why both exist.
I ask because I originally wanted to override do_configure as a fix,
and it seems that wouldn't have helped because it fails at do_kernel_configme.
 

On Thu, Nov 9, 2017 at 3:13 PM, Bruce Ashfield <bruce.ashfield@...> wrote:
On 2017-11-09 8:11 AM, Alan Martinovic wrote:
    What is your kernel recipe ? Something you wrote, or something
    from a vendor ?


Something I inherited.
It does seem to have been based on linux-yocto-custom.bb <http://linux-yocto-custom.bb>.


SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"

PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"

KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"

SRC_URI = "git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH} <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}> \
           "


Running it with:

bitbake -v linux-senic


It fails with:

ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Could not configure senic-hub-beta-standard
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Function failed: do_kernel_configme (log file is located at /home/alan/senic-o
s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)
ERROR: Logfile of failure stored in: /home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
18af-r0/temp/log.do_kernel_configme.5641


Not sure when "-standard" got appended...?

That's just part of the localversion processing in the bbclass, so
no worries there.

A more exact error seems to be:

linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: + configs=[ERROR]: no configuration queue found in outdir (.kernel-meta)

Could it be expecting a "linux-yocto style" with the meta branches?


Nope. Well, you do need some sort of configuration available, but it
doesn't have to be in that format.

That error is indicating that no configuration was found (no defconfig
or fragments).

A couple more questions, and I can probably sort this out.

- what branch/release of yocto are you using ?
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

For that second one, I'm wondering if the variable expansion is not
working with the machine override.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
sure that is the case with senic_defconfig.

You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.

Bruce




On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield <bruce.ashfield@... <mailto:bruce.ashfield@windriver.com>> wrote:

    On 11/07/2017 08:46 AM, Alan Martinovic wrote:

        Hi,
        I'm trying to get yocto to build the kernel with an in-tree
        defconfig.
        For that I found references to the variable
        KBUILD_DEFCONFIG_KMACHINE.

        However, I've been experiencing that the kernel is being built with
        some default defconfig, and not the in-tree one that came with the
        kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.

        I've looked through all yocto sources for where the
        KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
        kernel recipe. So I decided to dissect my recipe.


    What is your kernel recipe ? Something you wrote, or something
    from a vendor ?



        There is a:

        inherit kernel

        in my recipe for which, besides others, defines how the kernel
        config
        will be selected.
        Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
        the kernel configuration happens:

        kernel_do_configure() {
                  # fixes extra + in /lib/modules/2.6.37+
                  # $ scripts/setlocalversion . => +
                  # $ make kernelversion => 2.6.37
                  # $ make kernelrelease => 2.6.37+
                  touch ${B}/.scmversion ${S}/.scmversion

                  if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
        "${B}/.config" ]; then
                          mv "${S}/.config" "${B}/.config"
                  fi

                  # Copy defconfig to .config if .config does not exist.
        This allows
                  # recipes to manage the .config themselves in
        do_configure_prepend().
                  if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
        "${B}/.config" ]; then
                          cp "${WORKDIR}/defconfig" "${B}/.config"
                  fi

                  ${KERNEL_CONFIG_COMMAND}
        }


        I'm planning a workaround by overriding the do_configure in my
        recipe
        to select the correct defconfig from the kernel. It does seem
        however
        like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
        the workarounds.

        Anyone has experiences with successfully using
        KBUILD_DEFCONFIG_KMACHINE?
        Is it a specific poky feature (I'm not using poky but specific open
        embedded layers and bitbake)?

    That is a feature of kernel-yocto, so if your recipe is inheriting
    kernel-yocto you can use what you are looking for.

    But note, in the documentation you are referencing you have to replace
    KMACHINE with your actual machine .. not use the string KMACHINE.

    i.e. in your recipe (or bbappend)

    # for cases where the KMACHINE (KERNEL MACHINE) and bitbake
    # machine match, just do this:
    KMACHINE=$MACHINE

    KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"

    i.e. it is just a standard bitbake variable with a machine OVERRIDE
    to make it specific to the machine you are building.

    Bruce



        Be Well,
        Alan

        Ref.
        https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
        <https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>






Re: apt-get

Ran Shalit <ranshalit@...>
 

I now see that I have smart:
root@lec-imx6:~# smart
Usage: smart command [options] [arguments]

I was not familiar with "smart" command before, so that is good enough.

The image is based on fsl-image-qt5 image (lec-imx6 from adlink)

Thanks,
Ran

On Thu, Nov 9, 2017 at 5:01 PM, Burton, Ross <ross.burton@...> wrote:
What release? Until recently we used smart not yum.

Ross

On 9 November 2017 at 14:56, Ran Shalit <ranshalit@...> wrote:

I've added in local.conf both:
PACKAGE_CLASSES = "package_rpm"
IMAGE_FEATURES += "package-management"

Yet, I don't have yum command, only rpm command.

Regards,
Ran

On Thu, Nov 9, 2017 at 1:25 PM, Burton, Ross <ross.burton@...>
wrote:
(adding yocto@ back to CC)

I don't know where you saw that but that is very wrong.

Set PACKAGE_CLASSES to the package manager that you want to use. If you
want to use opkg, then PACKAGE_CLASSES should be package_ipk (historical
naming). If you want opkg to be present in the images ensure
IMAGE_FEATURES
contains package-management.

PACKAGE_CLASSES controls what package formats are generated, and
multiple
are supported for flexibility and testing purposes. For real world use
there's no need to have more than one. The first entry is the package
type
that is actually used in the rootfs generation.

package-management needs to be in IMAGE_FEATURES to both get the tools
installed (opkg in your case, apt-get for dpkg, yum for rpm) and to keep
the
package management database on the disk. By removing package-management
from IMAGE_FEATURES all traces of the package manager will be removed
from
the rootfs, which is useful if you don't want to support on-target use
of
the package manager.

Ross

On 9 November 2017 at 06:45, Ran Shalit <ranshalit@...> wrote:

Hi,

We also consider using opkg.

Now, I have some confusion as to how to install opkg.
I see in some documentation that it should be installed as following:

PACKAGE_CLASSES ?= "package_rpm package_ipk"
IMAGE_INSTALL_append = " opkg "

Does it mean there are 2 package managers active ?
How can we know which of them is active ?


If "?=" means that it shall be defined only if not defined previously,
so if it is already defined as package_rpm , it might not install
package_ipk?
Doesn't it mean that "opkg" might be installed without the required
package_ipk ?

Thank you,
Ran

On Wed, Nov 8, 2017 at 9:26 PM, Burton, Ross <ross.burton@...>
wrote:
Set PACKAGE_CLASSES to package_deb, and then ensure IMAGE_FEATURES
includes
package-management.

Ross

On 8 November 2017 at 19:16, Ran Shalit <ranshalit@...> wrote:

Hello,

Is there a way to add "apt-get" command (and package manager) in
yocto
?

Thank you,
Ran
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: apt-get

Burton, Ross <ross.burton@...>
 

What release?  Until recently we used smart not yum.

Ross

On 9 November 2017 at 14:56, Ran Shalit <ranshalit@...> wrote:
I've added in local.conf both:
PACKAGE_CLASSES = "package_rpm"
IMAGE_FEATURES += "package-management"

Yet, I don't have yum command, only rpm command.

Regards,
Ran

On Thu, Nov 9, 2017 at 1:25 PM, Burton, Ross <ross.burton@...> wrote:
> (adding yocto@ back to CC)
>
> I don't know where you saw that but that is very wrong.
>
> Set PACKAGE_CLASSES to the package manager that you want to use.  If you
> want to use opkg, then PACKAGE_CLASSES should be package_ipk (historical
> naming).  If you want opkg to be present in the images ensure IMAGE_FEATURES
> contains package-management.
>
> PACKAGE_CLASSES controls what package formats are generated, and multiple
> are supported for flexibility and testing purposes.  For real world use
> there's no need to have more than one.  The first entry is the package type
> that is actually used in the rootfs generation.
>
> package-management needs to be in IMAGE_FEATURES to both get the tools
> installed (opkg in your case, apt-get for dpkg, yum for rpm) and to keep the
> package management database on the disk.  By removing package-management
> from IMAGE_FEATURES all traces of the package manager will be removed from
> the rootfs, which is useful if you don't want to support on-target use of
> the package manager.
>
> Ross
>
> On 9 November 2017 at 06:45, Ran Shalit <ranshalit@...> wrote:
>>
>> Hi,
>>
>> We also consider using opkg.
>>
>> Now, I have some confusion as to how to install opkg.
>> I see in some documentation that it should be installed as following:
>>
>> PACKAGE_CLASSES ?= "package_rpm package_ipk"
>> IMAGE_INSTALL_append = " opkg "
>>
>> Does it mean there are 2 package managers active ?
>> How can we know which of them is active ?
>>
>>
>> If "?=" means that it shall be defined only if not defined previously,
>> so if it is already defined as  package_rpm , it might not install
>> package_ipk?
>> Doesn't it mean that "opkg" might be installed without the required
>> package_ipk ?
>>
>> Thank you,
>> Ran
>>
>> On Wed, Nov 8, 2017 at 9:26 PM, Burton, Ross <ross.burton@...>
>> wrote:
>> > Set PACKAGE_CLASSES to package_deb, and then ensure IMAGE_FEATURES
>> > includes
>> > package-management.
>> >
>> > Ross
>> >
>> > On 8 November 2017 at 19:16, Ran Shalit <ranshalit@...> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Is there a way to add "apt-get" command (and package manager) in yocto
>> >> ?
>> >>
>> >> Thank you,
>> >> Ran
>> >> --
>> >> _______________________________________________
>> >> yocto mailing list
>> >> yocto@...
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>
>


Re: apt-get

Ran Shalit <ranshalit@...>
 

I've added in local.conf both:
PACKAGE_CLASSES = "package_rpm"
IMAGE_FEATURES += "package-management"

Yet, I don't have yum command, only rpm command.

Regards,
Ran

On Thu, Nov 9, 2017 at 1:25 PM, Burton, Ross <ross.burton@...> wrote:
(adding yocto@ back to CC)

I don't know where you saw that but that is very wrong.

Set PACKAGE_CLASSES to the package manager that you want to use. If you
want to use opkg, then PACKAGE_CLASSES should be package_ipk (historical
naming). If you want opkg to be present in the images ensure IMAGE_FEATURES
contains package-management.

PACKAGE_CLASSES controls what package formats are generated, and multiple
are supported for flexibility and testing purposes. For real world use
there's no need to have more than one. The first entry is the package type
that is actually used in the rootfs generation.

package-management needs to be in IMAGE_FEATURES to both get the tools
installed (opkg in your case, apt-get for dpkg, yum for rpm) and to keep the
package management database on the disk. By removing package-management
from IMAGE_FEATURES all traces of the package manager will be removed from
the rootfs, which is useful if you don't want to support on-target use of
the package manager.

Ross

On 9 November 2017 at 06:45, Ran Shalit <ranshalit@...> wrote:

Hi,

We also consider using opkg.

Now, I have some confusion as to how to install opkg.
I see in some documentation that it should be installed as following:

PACKAGE_CLASSES ?= "package_rpm package_ipk"
IMAGE_INSTALL_append = " opkg "

Does it mean there are 2 package managers active ?
How can we know which of them is active ?


If "?=" means that it shall be defined only if not defined previously,
so if it is already defined as package_rpm , it might not install
package_ipk?
Doesn't it mean that "opkg" might be installed without the required
package_ipk ?

Thank you,
Ran

On Wed, Nov 8, 2017 at 9:26 PM, Burton, Ross <ross.burton@...>
wrote:
Set PACKAGE_CLASSES to package_deb, and then ensure IMAGE_FEATURES
includes
package-management.

Ross

On 8 November 2017 at 19:16, Ran Shalit <ranshalit@...> wrote:

Hello,

Is there a way to add "apt-get" command (and package manager) in yocto
?

Thank you,
Ran
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: KBUILD_DEFCONFIG_KMACHINE not used anywhere

Bruce Ashfield <bruce.ashfield@...>
 

On 2017-11-09 8:11 AM, Alan Martinovic wrote:
What is your kernel recipe ? Something you wrote, or something
from a vendor ?
Something I inherited.
It does seem to have been based on linux-yocto-custom.bb <http://linux-yocto-custom.bb>.
SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"
PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"
KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"
SRC_URI = "git://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH} <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=${KBRANCH}> \
          "
Running it with:
bitbake -v linux-senic
It fails with:
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Could not configure senic-hub-beta-standard
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Function failed: do_kernel_configme (log file is located at /home/alan/senic-o
s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641) ERROR: Logfile of failure stored in: /home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
18af-r0/temp/log.do_kernel_configme.5641
Not sure when "-standard" got appended...?
That's just part of the localversion processing in the bbclass, so
no worries there.

A more exact error seems to be:
linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: + configs=[ERROR]: no configuration queue found in outdir (.kernel-meta)
Could it be expecting a "linux-yocto style" with the meta branches?
Nope. Well, you do need some sort of configuration available, but it
doesn't have to be in that format.

That error is indicating that no configuration was found (no defconfig
or fragments).

A couple more questions, and I can probably sort this out.

- what branch/release of yocto are you using ?
- can you try just using: KBUILD_DEFCONFIG="senic_defconfig"

For that second one, I'm wondering if the variable expansion is not
working with the machine override.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
up in-tree defconfigs for use in the build, so whatever you reference
must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
sure that is the case with senic_defconfig.

You can always add the defconfig directly to the SRC_URI as well
(i.e. copy it into your layer and call it 'defconfig' and add it
to the SRC_URI like any other element.

Bruce

On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield <bruce.ashfield@... <mailto:bruce.ashfield@...>> wrote:
On 11/07/2017 08:46 AM, Alan Martinovic wrote:
Hi,
I'm trying to get yocto to build the kernel with an in-tree
defconfig.
For that I found references to the variable
KBUILD_DEFCONFIG_KMACHINE.
However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.
I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.
What is your kernel recipe ? Something you wrote, or something
from a vendor ?
There is a:
inherit kernel
in my recipe for which, besides others, defines how the kernel
config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:
kernel_do_configure() {
         # fixes extra + in /lib/modules/2.6.37+
         # $ scripts/setlocalversion . => +
         # $ make kernelversion => 2.6.37
         # $ make kernelrelease => 2.6.37+
         touch ${B}/.scmversion ${S}/.scmversion
         if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
                 mv "${S}/.config" "${B}/.config"
         fi
         # Copy defconfig to .config if .config does not exist.
This allows
         # recipes to manage the .config themselves in
do_configure_prepend().
         if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
"${B}/.config" ]; then
                 cp "${WORKDIR}/defconfig" "${B}/.config"
         fi
         ${KERNEL_CONFIG_COMMAND}
}
I'm planning a workaround by overriding the do_configure in my
recipe
to select the correct defconfig from the kernel. It does seem
however
like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
the workarounds.
Anyone has experiences with successfully using
KBUILD_DEFCONFIG_KMACHINE?
Is it a specific poky feature (I'm not using poky but specific open
embedded layers and bitbake)?
That is a feature of kernel-yocto, so if your recipe is inheriting
kernel-yocto you can use what you are looking for.
But note, in the documentation you are referencing you have to replace
KMACHINE with your actual machine .. not use the string KMACHINE.
i.e. in your recipe (or bbappend)
# for cases where the KMACHINE (KERNEL MACHINE) and bitbake
# machine match, just do this:
KMACHINE=$MACHINE
KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"
i.e. it is just a standard bitbake variable with a machine OVERRIDE
to make it specific to the machine you are building.
Bruce
Be Well,
Alan
Ref.
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
<https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file>


Re: KBUILD_DEFCONFIG_KMACHINE not used anywhere

Alan
 

What is your kernel recipe ? Something you wrote, or something
from a vendor ?

Something I inherited.
It does seem to have been based on linux-yocto-custom.bb.


SECTION = "kernel"
DESCRIPTION = "Mainline Linux kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

KBRANCH = "senic/4.13"
SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"

PV = "4.13+git${SRCPV}"
S = "${WORKDIR}/git"

KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"

          "


Running it with:

bitbake -v linux-senic


It fails with:

ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Could not configure senic-hub-beta-standard                                   
ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: Function failed: do_kernel_configme (log file is located at /home/alan/senic-o
s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)              
ERROR: Logfile of failure stored in: /home/alan/senic-os/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.13+gitAUTOINC+e469b2
18af-r0/temp/log.do_kernel_configme.5641


Not sure when "-standard" got appended...?
A more exact error seems to be:

linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: + configs=[ERROR]: no configuration queue found in outdir (.kernel-meta)             

Could it be expecting a "linux-yocto style" with the meta branches?




On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield <bruce.ashfield@...> wrote:
On 11/07/2017 08:46 AM, Alan Martinovic wrote:
Hi,
I'm trying to get yocto to build the kernel with an in-tree defconfig.
For that I found references to the variable KBUILD_DEFCONFIG_KMACHINE.

However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.

I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.

What is your kernel recipe ? Something you wrote, or something
from a vendor ?



There is a:

inherit kernel

in my recipe for which, besides others, defines how the kernel config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:

kernel_do_configure() {
         # fixes extra + in /lib/modules/2.6.37+
         # $ scripts/setlocalversion . => +
         # $ make kernelversion => 2.6.37
         # $ make kernelrelease => 2.6.37+
         touch ${B}/.scmversion ${S}/.scmversion

         if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
                 mv "${S}/.config" "${B}/.config"
         fi

         # Copy defconfig to .config if .config does not exist. This allows
         # recipes to manage the .config themselves in do_configure_prepend().
         if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
                 cp "${WORKDIR}/defconfig" "${B}/.config"
         fi

         ${KERNEL_CONFIG_COMMAND}
}


I'm planning a workaround by overriding the do_configure in my recipe
to select the correct defconfig from the kernel. It does seem however
like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
the workarounds.

Anyone has experiences with successfully using KBUILD_DEFCONFIG_KMACHINE?
Is it a specific poky feature (I'm not using poky but specific open
embedded layers and bitbake)?
That is a feature of kernel-yocto, so if your recipe is inheriting
kernel-yocto you can use what you are looking for.

But note, in the documentation you are referencing you have to replace
KMACHINE with your actual machine .. not use the string KMACHINE.

i.e. in your recipe (or bbappend)

# for cases where the KMACHINE (KERNEL MACHINE) and bitbake
# machine match, just do this:
KMACHINE=$MACHINE

KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"

i.e. it is just a standard bitbake variable with a machine OVERRIDE
to make it specific to the machine you are building.

Bruce


Re: apt-get

Burton, Ross <ross.burton@...>
 

(adding yocto@ back to CC)

I don't know where you saw that but that is very wrong.

Set PACKAGE_CLASSES to the package manager that you want to use.  If you want to use opkg, then PACKAGE_CLASSES should be package_ipk (historical naming).  If you want opkg to be present in the images ensure IMAGE_FEATURES contains package-management.

PACKAGE_CLASSES controls what package formats are generated, and multiple are supported for flexibility and testing purposes.  For real world use there's no need to have more than one.  The first entry is the package type that is actually used in the rootfs generation.

package-management needs to be in IMAGE_FEATURES to both get the tools installed (opkg in your case, apt-get for dpkg, yum for rpm) and to keep the package management database on the disk.  By removing package-management from IMAGE_FEATURES all traces of the package manager will be removed from the rootfs, which is useful if you don't want to support on-target use of the package manager.

Ross

On 9 November 2017 at 06:45, Ran Shalit <ranshalit@...> wrote:
Hi,

We also consider using opkg.

Now, I have some confusion as to how to install opkg.
I see in some documentation that it should be installed as following:

PACKAGE_CLASSES ?= "package_rpm package_ipk"
IMAGE_INSTALL_append = " opkg "

Does it mean there are 2 package managers active ?
How can we know which of them is active ?


If "?=" means that it shall be defined only if not defined previously,
so if it is already defined as  package_rpm , it might not install
package_ipk?
Doesn't it mean that "opkg" might be installed without the required
package_ipk ?

Thank you,
Ran

On Wed, Nov 8, 2017 at 9:26 PM, Burton, Ross <ross.burton@...> wrote:
> Set PACKAGE_CLASSES to package_deb, and then ensure IMAGE_FEATURES includes
> package-management.
>
> Ross
>
> On 8 November 2017 at 19:16, Ran Shalit <ranshalit@...> wrote:
>>
>> Hello,
>>
>> Is there a way to add "apt-get" command (and package manager) in yocto ?
>>
>> Thank you,
>> Ran
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@...
>> https://lists.yoctoproject.org/listinfo/yocto
>
>


Layer index not updated

Andreas Müller
 

Hi,

did not find any heads up here so: Layer index stopped updating ~1,5 month. Low priority - this is just notification & thanks in advance for taking care :)

Andreas


[meta-gplv2][PATCH] gnutls: update 3.3.27 -> 3.3.28

Andre McCurdy <armccurdy@...>
 

* Version 3.3.28 (released 2017-07-04)

** libgnutls: Fixed issue when rehandshaking without a client certificate in
a session which initially used one. Reported by Frantisek Sumsal.

** libgnutls: fix issue in RSA-PSK client callback which resulted in no username
being sent to the peer. Patch by Nicolas Dufresne.

** libgnutls: no longer parse the ResponseID field of the status response
TLS extension. The field is not used by GnuTLS nor is made available to
calling applications. That addresses a null pointer dereference on server
side caused by packets containing the ResponseID field. Reported
by Hubert Kario. [GNUTLS-SA-2017-4]

** libgnutls: Handle specially HSMs which request explicit authentication.
There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key
operation. Detect that state and try to login.

** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs.
That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag
a login will be forced. This improves operation on certain Safenet HSMs.

** libgnutls: do not set leading zeros when copying integers on HSMs.
PKCS#11 defines integers as unsigned having most significant byte
first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by
some HSMs which do not accept an integer with a leading zero. This
improves operation with certain Atos HSMs.

** libgnutls: Backported PKCS#11 key generation functionality for DSA keys.

** libgnutls: Improve check for /dev/urandom uniqueness. Ensure that when
gnutls_global_init() is called for a second time that /dev/urandom is
re-opened when the inode or device ID has changed.

** API and ABI modifications:
No changes since last version.

Signed-off-by: Andre McCurdy <armccurdy@...>
---
recipes-support/gnutls/gnutls.inc | 9 ++++-----
recipes-support/gnutls/gnutls_3.3.27.bb | 17 -----------------
recipes-support/gnutls/gnutls_3.3.28.bb | 8 ++++++++
3 files changed, 12 insertions(+), 22 deletions(-)
delete mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
create mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb

diff --git a/recipes-support/gnutls/gnutls.inc b/recipes-support/gnutls/gnutls.inc
index 4a5c3df..4cf375f 100644
--- a/recipes-support/gnutls/gnutls.inc
+++ b/recipes-support/gnutls/gnutls.inc
@@ -8,9 +8,8 @@ LICENSE_${PN}-xx = "LGPLv2.1+"
LICENSE_${PN}-bin = "GPLv3+"
LICENSE_${PN}-openssl = "GPLv3+"

-LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
- file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
- file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+ file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"

DEPENDS = "nettle gmp virtual/libiconv"
DEPENDS_append_libc-musl = " argp-standalone"
@@ -21,9 +20,8 @@ SRC_URI = "ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz"

inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc

-PACKAGECONFIG ??= "libidn zlib"
+PACKAGECONFIG ??= "zlib"

-PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
PACKAGECONFIG[libtasn1] = "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
@@ -31,6 +29,7 @@ PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"

EXTRA_OECONF = " \
--enable-doc \
+ --disable-crywrap \
--disable-libdane \
--disable-guile \
--disable-rpath \
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb b/recipes-support/gnutls/gnutls_3.3.27.bb
deleted file mode 100644
index a1dcdb5..0000000
--- a/recipes-support/gnutls/gnutls_3.3.27.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-require gnutls.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
- file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
-
-SRC_URI += " \
- file://configure.ac-fix-sed-command.patch \
- file://use-pkg-config-to-locate-zlib.patch \
-"
-SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
-SRC_URI[sha256sum] = "8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
-
-# This version doesn't support this option added in newer gnutls
-# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed unrecognised options: --with-idn [unknown-configure-option]
-PACKAGECONFIG[libidn] = ""
-# but it still has the libidn dependency, without this option
-EXTRA_OECONF += "--disable-crywrap"
diff --git a/recipes-support/gnutls/gnutls_3.3.28.bb b/recipes-support/gnutls/gnutls_3.3.28.bb
new file mode 100644
index 0000000..1b23369
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.28.bb
@@ -0,0 +1,8 @@
+require gnutls.inc
+
+SRC_URI += " \
+ file://configure.ac-fix-sed-command.patch \
+ file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "e19718d97cee5279edf3f3b9318f926c"
+SRC_URI[sha256sum] = "608f63441abc209c5bd5f61e35f2b6128c22e06fa2ad6248a08d8a643feeb807"
--
1.9.1


Re: use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain

Chen Qi
 

If I understand it correctly, you are talking about using native components directly for SDK.
If you are using all the same machine with the same OS, you could use native components directly, maybe with a little modification.
But in fact, the host where SDK is installed might be different from the host where SDK is built.
Check the SDKMACHINE variable.

Best Regards,
Chen Qi

On 11/07/2017 11:09 PM, Zhen LiWei wrote:

Hi, I am working on a yocto 2.0 based distro and we usually populate_sdk and use the toolchain included in SDK.

 

But we also like to check the SDK into a SVN repo, and checkout it anywhere, and use it away right where it is checked out. And since the nativesdk binaries are based on a different glibc than native, and have the “dynamic loader” path hardcoded in them, I have to patch the toolchain binaries’ .interp secion to point to a common place, and update the loader into that common place automatically in some way. Other than this, things work very good for us.

 

Then I was thinking: is it a good practice, to use the native/cross toolchain directly from the tmp/sysroots/x86_64-native folder. I tried and succeeded, by just moving the sysroot to where the checked-out nativesdk toolchain was.

 

An extra bonus about this is that we got a more populated sysroot for native platform too, for example a openssl dev package at the same version as that on target, that we can actually use to make the native platform a closer-to-target dev env for some “workbench” build.

 

However I’m still wondering: is there any thing negative about this style? One thing known is that the SDK-using host need to be similar to the SDK-building host, but that is not an issue for us. But anything else, guys?





dpkg --print-architecture returns wrong result

John Rama <john.rama01@...>
 

Hi, Yocto specialists

I've built the whole system with deb package,
and trying to use package feed feature of yocto.

When try trying to install some package from target, I faced following error.

# apt-get install fontconfig-utils
....
package architecture (armhf) does not match system (armel)
....

When checking the install package of the target system, everything is armhf architecture.
# dpkg -l
...
||/ Name Version Architecture Description
+++-==============================================-===========================-============-===========================================================================================
ii alsa-conf:armhf 1.1.0-r0 armhf ALSA sound library
ii alsa-conf-base:armhf 1.1.0-r0 armhf ALSA sound library
ii alsa-lib:armhf 1.1.0-r0 armhf ALSA sound library
...

However, when checking with following commands, it tells armel.
# dpkg --print-architecture
armel

I think "dpkg --print-architecture" returns wrong result.

I'm using toolchain "arm-poky-linux-gnueabi-gcc" and result of dumpmachine option is as followings.
$ arm-poky-linux-gnueabi-gcc -dumpmachine
arm-poky-linux-gnueabi

I have no idea how to tell yocto to configure the target system correctly.
Any feedback is highly appreciated.

Kind Regards,
Jonh Rama


Re: [layerindex-web][patch v3 1/1] recipes.html: Require keyword for recipe search

Mark Hatle <mark.hatle@...>
 

On 11/8/17 1:08 PM, Paul Eggleton wrote:
On Thursday, 9 November 2017 4:42:50 AM NZDT Mark Hatle wrote:
On 11/7/17 8:43 PM, Paul Eggleton wrote:
On Wednesday, 8 November 2017 11:47:49 AM NZDT Mark Hatle wrote:
On 11/7/17 4:31 PM, Amanda Brindle wrote:
Use JavaScript to check if the search box for recipe search is
empty before querying the database. This will prevent the "502
Bad Gateway" error that occurs when the query takes too long due
to the large list of recipes. Since there are so many recipes
spread across the layers in the OE index, there's no point in
allowing a user to search without a keyword in order to browse
the list; it simply isn't digestible as a whole.

Add a browse button for the Machines, Classes, and Distros pages.
There are reasons to view all of the recipes, machines, classes, distros,
etc. (Not necessarily good reasons, but I know people do it.)

If the query is too long, it would be better to figure out a way to get a
partial response and formulate the first page based on partial
responses... having a multipage response that the user can look at.
I'm willing to be proven wrong, but unfortunately it looks to me like this
will require major re-engineering to sort out for a fairly weak use case.
If you consider this important, would you be able to look into making it
work?
I suspect much of the display engine probably needs a rework as the contents
of the layer index have grown. I can't promise anything, but I'll see if I
can find anyone who can work on it.
Could be yes, thanks.

For recipes, the use-case is very weak. I have talked with people though
who have just wanted a list of what is available (one big list). Primarily
so they can compare what is available to some magic spec sheet they are
looking at.
If that's the use case though we should provide a proper export capability,
because comparing big lists manually 50 items at a time isn't how you'd best
support that. Theoretically the API could be used there but an explicit export
function would be more accessible.
For my own uses, I export this using the restapi. So it can certainly be
exported easily enough and processed externally. (Of course, few people know
about the restapi or how to use it.)

For the Machines, Distros pages.. people do want a full list here, as they
simply won't know what is available or what something is called. The scope
of the machines and distros of course is nowhere near the scope for the full
recipe list.
Right, and this patch doesn't remove the ability to browse those - in fact it
makes it easier to do so by adding an explicit browse button, so I think we're
OK there.
I misunderstood that. I though the machine/distro would be restricted like recipes.

Cheers,
Paul


Re: apt-get

Burton, Ross <ross.burton@...>
 

Set PACKAGE_CLASSES to package_deb, and then ensure IMAGE_FEATURES includes package-management.

Ross

On 8 November 2017 at 19:16, Ran Shalit <ranshalit@...> wrote:
Hello,

Is there a way to add "apt-get" command (and package manager) in yocto ?

Thank you,
Ran
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


apt-get

Ran Shalit <ranshalit@...>
 

Hello,

Is there a way to add "apt-get" command (and package manager) in yocto ?

Thank you,
Ran


Re: Yocto problem for Ryzen-7 cpu

Ayoub Zaki <ayoub.zaki@...>
 

On 08.11.2017 20:07, Jerry Lian wrote:
(weird, yocto mails to me blocked by my gmail, treated as spam?)

Anyway, just change to Ubuntu-17, run first build, succeed with no failures, good sign!
Will run more and see.
Glad to read that you solved your problem :-)

You are Welcome!






On Wed, Nov 8, 2017 at 12:06 PM, Jerry Lian <jerry.lian@... <mailto:jerry.lian@...>> wrote:

(my Gmail does not accept new message for same subject? so I open
a new thread)

So bad: I do use Ryzen-7.
will Ubuntu-17 or latest Debian fix the problem?





--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub.zaki@...
Homepage : https://embexus.com
VAT No. : DE313902634


Re: [layerindex-web][patch v3 1/1] recipes.html: Require keyword for recipe search

Paul Eggleton
 

On Thursday, 9 November 2017 4:42:50 AM NZDT Mark Hatle wrote:
On 11/7/17 8:43 PM, Paul Eggleton wrote:
On Wednesday, 8 November 2017 11:47:49 AM NZDT Mark Hatle wrote:
On 11/7/17 4:31 PM, Amanda Brindle wrote:
Use JavaScript to check if the search box for recipe search is
empty before querying the database. This will prevent the "502
Bad Gateway" error that occurs when the query takes too long due
to the large list of recipes. Since there are so many recipes
spread across the layers in the OE index, there's no point in
allowing a user to search without a keyword in order to browse
the list; it simply isn't digestible as a whole.

Add a browse button for the Machines, Classes, and Distros pages.
There are reasons to view all of the recipes, machines, classes, distros,
etc. (Not necessarily good reasons, but I know people do it.)

If the query is too long, it would be better to figure out a way to get a
partial response and formulate the first page based on partial
responses... having a multipage response that the user can look at.
I'm willing to be proven wrong, but unfortunately it looks to me like this
will require major re-engineering to sort out for a fairly weak use case.
If you consider this important, would you be able to look into making it
work?
I suspect much of the display engine probably needs a rework as the contents
of the layer index have grown. I can't promise anything, but I'll see if I
can find anyone who can work on it.
Could be yes, thanks.

For recipes, the use-case is very weak. I have talked with people though
who have just wanted a list of what is available (one big list). Primarily
so they can compare what is available to some magic spec sheet they are
looking at.
If that's the use case though we should provide a proper export capability,
because comparing big lists manually 50 items at a time isn't how you'd best
support that. Theoretically the API could be used there but an explicit export
function would be more accessible.

For the Machines, Distros pages.. people do want a full list here, as they
simply won't know what is available or what something is called. The scope
of the machines and distros of course is nowhere near the scope for the full
recipe list.
Right, and this patch doesn't remove the ability to browse those - in fact it
makes it easier to do so by adding an explicit browse button, so I think we're
OK there.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

19021 - 19040 of 57758