Re: [yocto] apt-get

[Burton, Ross]

(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  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 
> 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  wrote:
> >>
> >> Hello,
> >>
> >> Is there a way to add "apt-get" command (and package manager) in yocto ?
> >>
> >> Thank you,
> >> Ran
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

[Alan Martinovic]

>
> 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"

SRC_URI = "git://
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...?
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  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
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

[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 
.



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} 
 
\

           "


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//configs/ .. 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 
mailto:bruce.ashfi...@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 se

Re: [yocto] apt-get

[Ran Shalit]

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  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  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 
>> 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  wrote:
>> >>
>> >> Hello,
>> >>
>> >> Is there a way to add "apt-get" command (and package manager) in yocto
>> >> ?
>> >>
>> >> Thank you,
>> >> Ran
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] apt-get

[Burton, Ross]

What release?  Until recently we used smart not yum.

Ross

On 9 November 2017 at 14:56, Ran Shalit  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 
> 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  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 
> >> 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  wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> Is there a way to add "apt-get" command (and package manager) in
> yocto
> >> >> ?
> >> >>
> >> >> Thank you,
> >> >> Ran
> >> >> --
> >> >> ___
> >> >> yocto mailing list
> >> >> yocto@yoctoproject.org
> >> >> https://lists.yoctoproject.org/listinfo/yocto
> >> >
> >> >
> >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] apt-get

[Ran Shalit]

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  wrote:
> What release?  Until recently we used smart not yum.
>
> Ross
>
> On 9 November 2017 at 14:56, Ran Shalit  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 
>> 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  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 
>> >> 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  wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Is there a way to add "apt-get" command (and package manager) in
>> >> >> yocto
>> >> >> ?
>> >> >>
>> >> >> Thank you,
>> >> >> Ran
>> >> >> --
>> >> >> ___
>> >> >> yocto mailing list
>> >> >> yocto@yoctoproject.org
>> >> >> https://lists.yoctoproject.org/listinfo/yocto
>> >> >
>> >> >
>> >
>> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

[Alan Martinovic]

>
>  - 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//configs/ .. 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  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}
>> 
>> > 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/li
>> nux-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//configs/ .. 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.ashfi...@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 ?
>>
>>
>>
>>   

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

[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//configs/ .. 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 
mailto:bruce.ashfi...@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
 .


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}



>
\
            "


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//configs/ .. so make
sure that is the case with senic_defconfi

[yocto] Building snaps whilst building yocto

[Siegmund, Jan]

Hi all,

Is there already a class/template around which creates snaps from recipes 
whilst building yocto and/or afterwards using the SDK?


Thanks
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Layer index not updated

[Leonardo Sandoval]

On Thu, 9 Nov 2017 09:36:26 +0100
Andreas Müller  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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

[Alan Martinovic]

Sure.

The layer that will fetch all the other layers by running make:
https://github.com/getsenic/senic-os

The kernel source being used:
https://github.com/getsenic/senic-os-linux/tree/senic/4.13

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  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//configs/ .. 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.ashfi...@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
>>  .
>>
>>
>> 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}
>> 
>> > nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>
>> > nobranch=1;protocol=git;branch=${KBRANCH}
>> > 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/li
>> nux-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-seni
>> c-linux-gnueabi/linux-senic/4.13+gitAUTOI

Re: [yocto] yocto documentation: no content, no PDF?

[Leonardo Sandoval]

On Wed, 8 Nov 2017 16:30:39 +
"Burton, Ross"  wrote:

> On 8 November 2017 at 15:41, 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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Layer index not updated

[Paul Eggleton]

On Thursday, 9 November 2017 9:36:26 PM NZDT Andreas Müller wrote:
> 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 :)

I reported this to Michael a week or so ago but I think he's still battling an 
upgrade of the layer index code among other things. Michael, any updates?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][PATCH] trousers: allow overriding localstatedir mandir sysconfdir

[akuster808]

merged.


not sure if I sent our a confirmation email.

Thanks,

armin


On 11/01/2017 04:59 AM, André Draszik wrote:
> From: André Draszik 
>
> It is currently impossible to override localstatedir,
> mandir and sysconfdir during ./configure, because they
> are being overriden unconditionally.
>
> With this patch it is now possible to set above
> locations as needed.
>
> Signed-off-by: André Draszik 
> ---
>  ...-override-localstatedir-mandir-sysconfdir.patch | 68 
> ++
>  meta-tpm/recipes-tpm/trousers/trousers_git.bb  |  1 +
>  2 files changed, 69 insertions(+)
>  create mode 100644 
> meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
>
> diff --git 
> a/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
>  
> b/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
> new file mode 100644
> index 000..7b3cc77
> --- /dev/null
> +++ 
> b/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
> @@ -0,0 +1,68 @@
> +From 3396fc7a184293c23135161f034802062f7f3816 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
> +Date: Wed, 1 Nov 2017 11:41:48 +
> +Subject: [PATCH] build: don't override --localstatedir --mandir --sysconfdir
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +It is currently impossible to override localstatedir,
> +mandir and sysconfdir during ./configure, because they
> +are being overriden unconditionally because of they
> +way trousers is built using rpmbuild.
> +
> +If they need massaging for rpmbuild, the values should
> +be specified inside the spec file, not in ./configure
> +and thereby overriding user-requested values.
> +
> +With this patch it is now possible to set above
> +locations as needed. The .spec file is being modified
> +as well so as to restore previous behaviour.
> +
> +Signed-off-by: André Draszik 
> +---
> +Upstream-Status: Submitted 
> [https://sourceforge.net/p/trousers/mailman/message/36099290/]
> +Signed-off-by: André Draszik 
> + configure.ac  | 11 ++-
> + dist/trousers.spec.in |  2 +-
> + 2 files changed, 3 insertions(+), 10 deletions(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index b9626af..7fe5f8e 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -376,16 +376,9 @@ CFLAGS="$CFLAGS -I../include \
> + KERNEL_VERSION=`uname -r`
> + AC_SUBST(CFLAGS)
> + 
> +-# When we build the rpms, prefix will be /usr. This'll do some things that 
> make sense,
> +-# like put our sbin stuff in /usr/sbin and our library in /usr/lib. It'll 
> do some other
> +-# things that don't make sense like put our config file in /usr/etc. So, 
> I'll just hack
> +-# it here. If the --prefix option isn't specified during configure, let it 
> all go to
> ++# If the --prefix option isn't specified during configure, let it all go to
> + # /usr/local, even /usr/local/etc. :-P
> +-if test x"${prefix}" = x"/usr"; then
> +-sysconfdir="/etc"
> +-localstatedir="/var"
> +-mandir="/usr/share/man"
> +-elif test x"${prefix}" = x"NONE"; then
> ++if test x"${prefix}" = x"NONE"; then
> + localstatedir="/usr/local/var"
> + fi
> + 
> +diff --git a/dist/trousers.spec.in b/dist/trousers.spec.in
> +index b298b0e..10ef178 100644
> +--- a/dist/trousers.spec.in
>  b/dist/trousers.spec.in
> +@@ -45,7 +45,7 @@ applications.
> + 
> + %build
> + %{?arch64:export PKG_CONFIG_PATH=%{pkgconfig_path}:$PKG_CONFIG_PATH}
> +-./configure --prefix=/usr --libdir=%{_libdir}
> ++./configure --prefix=/usr --libdir=%{_libdir} --sysconfdir=/etc 
> --localstatedir=/var --mandir=/usr/share/man
> + make
> + 
> + %clean
> +-- 
> +2.15.0.rc1
> +
> diff --git a/meta-tpm/recipes-tpm/trousers/trousers_git.bb 
> b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
> index 352374c..e9f838e 100644
> --- a/meta-tpm/recipes-tpm/trousers/trousers_git.bb
> +++ b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
> @@ -15,6 +15,7 @@ SRC_URI = " \
>   file://trousers-udev.rules \
>   file://tcsd.service \
>  file://get-user-ps-path-use-POSIX-getpwent-instead-of-getpwe.patch \
> +
> file://0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch \
>   "
>  
>  S = "${WORKDIR}/git"

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] [RFC] stable branch naming scheme

[akuster808]

Any more comments?


I started to use stable/{branch}-next in all the contrib repos. Poky
will be constructed from oe-contrib repos.


thanks for all the feedback.

regards,

Armin


On 11/06/2017 10:14 AM, akuster808 wrote:
>
>
>
> On 11/06/2017 08:43 AM, Denys Dmytriyenko wrote:
>> On Fri, Nov 03, 2017 at 09:20:43AM -0700, akuster808 wrote:
>>> Hello,
>>>
>>> The problem I hope to solve is that a Maintainer can stage changes in
>>> any branch in the contrib repos making it difficult for folks to track
>>> their back port requests. The also makes it harder to automate any kind
>>> of build automation.
>>>
>>> I would like to propose a contrib naming scheme for the stable release
>>> branches. I am thinking of the following:
>>>
>>> stable/{version}-next or {special char}_stable/{version}-next.
>>>
>>>    "version" is either the code name or numeric like in bitbake.
>>>
>>>    "special char" would be used to have these branches at the top of th
>>> list, if we wont that.
>> I like this branch unification!
>>
>> I know we discussed this at OEDEM and there was some convenience reason 
>> given, 
>> but can we also standardize on the tree? I.e. openembedded-core-contrib vs. 
>> poky-contrib?
>
> The current Poky maintenance process talks about deconstructing
> "stable-next":
> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Stable_branch_maintainers
>  
> # Split out any bitbake changes and send them to the bitbake-devel
> mailing list (marking them with the appropriate stable version in the
> subject line e.g. [1.20])
> # Split out OE-Core changes and create an openembedded-core-contrib
> branch containing them; send the cover letter only (marking it as such
> in the subject) to the openembedded-core mailing list.
> The above has been happening via  a script Richard runs.  I personally
> think it the workflow should be for OE -> Yocto. This does add more
> work for the maintainer but is cleaner.  I did ask Richard to create
> bitbake-contrib for this purpose but am lazy as he uses his script ; )
>
> The reason I choose "stable/" branching is that the "-next" branches
> are out of sync and not being used correctly or not defined on their
> purpose. another subject for another time.
>
> - armin
>
>>> We can apply this to all OE / Yocto repos that have stable branch
>>> maintenance process.
>>>
>>> If we standardize on a naming scheme, We can then document this so
>>> contributers can monitor their requests more easily. The community can
>>> see what changes are being backport.  This will enable the possibility
>>> to automate builds, etc. 
>>>
>>> let me know what you think.
>>>
>>> Kind regards,
>>>
>>> Armin
>>>
>>>
>>>
>>> ___
>>> Openembedded-architecture mailing list
>>> openembedded-architect...@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dpkg --print-architecture returns wrong result

[John Rama]

>> However, when checking with following commands, it tells armel.
>> # dpkg --print-architecture
>> armel
>> 
>> I think "dpkg --print-architecture" returns wrong result. 

I debugged further on this problem.
"dpkg --print-architecture" is just returns "ARCHITECTURE" which is defined by 
configure script. 
In configure script, ARCHITECTURE is defined as followings.

dpkg_arch=$($srcdir/run-script $PERL scripts/dpkg-architecture.pl -t$host 
-qDEB_HOST_ARCH 2>/dev/null)
where $host is arm-poky-linux-gnueabi.

When running dpkg-architecture.pl, I see following warning.

$ scripts/dpkg-architecture.pl -t arm-poky-linux-gnueabi -qDEB_TARGET_ARCH
dpkg-architecture.pl: warning: default GNU system type arm-linux-gnueabi for 
Debian arch armel does not match specified GNU system type 
arm-poky-linux-gnueabi
armel

Does -t "arm-poky-linux-gnueabi" is appropriate ?
Or arm-poky-linux-gnueabi is correct, but the behavior of dpkg-architecture.pl 
is wrong ?

Any feedback is highly appreciated.

John

On 2017/11/08 20:11, John Rama wrote:
> 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:armhf1.1.0-r0   
>  armhfALSA sound library
> ii  alsa-conf-base:armhf   1.1.0-r0   
>  armhfALSA sound library
> ii  alsa-lib:armhf 1.1.0-r0   
>  armhfALSA 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
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto git repositories, shallow clone, uploadpack.allowReachableSHA1InWant

[Craig McQueen]

I'm using git submodule to set up a Yocto build using the various layers 
required for my project. I see that recent git has the ability to specify that 
a submodule repository should be a "shallow" clone.

However, when I tried it with meta-mono, I got an error "server does not allow 
request for unadvertised object".

It appears that for such a shallow clone of a specified commit to work, the 
repository must enable uploadpack.allowReachableSHA1InWant.

Could this option be enabled for all Yocto git repositories? This would 
potentially save a lot of time and download bandwidth for everyone.

-- 
Craig McQueen

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto git repositories, shallow clone, uploadpack.allowReachableSHA1InWant

[Tim Orling]

Adding Michael Halstead.

> On Nov 9, 2017, at 6:03 PM, Craig McQueen  
> wrote:
> 
> I'm using git submodule to set up a Yocto build using the various layers 
> required for my project. I see that recent git has the ability to specify 
> that a submodule repository should be a "shallow" clone.
> 
> However, when I tried it with meta-mono, I got an error "server does not 
> allow request for unadvertised object".
> 
> It appears that for such a shallow clone of a specified commit to work, the 
> repository must enable uploadpack.allowReachableSHA1InWant.
> 
> Could this option be enabled for all Yocto git repositories? This would 
> potentially save a lot of time and download bandwidth for everyone.
> 
> -- 
> Craig McQueen
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] export command in bitbake

[Zoran Stojsavljevic]

Hello to all YOCTO users,

I have one (I should say naive) question considering/querying environment
variables, initially set with bitbake scripts.

I have both python (2.7.14) and python3.6 (3.6.2). But, as far as I can
see/say, both interpreters do NOT support export declaration (supported
with /bin/bash). In other words, every child shell will (with export
declaration on certain variables) inherit parent's environment.

[user@192 conf]$ python
Python 2.7.14 (default, Nov  2 2017, 18:42:05)
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
[user@192 conf]$ python3.6
Python 3.6.2 (default, Oct  2 2017, 16:51:32)
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
[user@192 conf]$

Now, I see that bitbake (written in python language) supports export. From
here:
...poky/meta/conf/bitbake.conf

Excerpt from the file:
# Path prefixes
export base_prefix = ""
export prefix = "/usr"
export exec_prefix = "${prefix}"

root_prefix = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge',
'${exec_prefix}', '${base_prefix}', d)}"

# Base paths
export base_bindir = "${root_prefix}/bin"
export base_sbindir = "${root_prefix}/sbin"
export base_libdir = "${root_prefix}/${baselib}"
export nonarch_base_libdir = "${root_prefix}/lib"

I assume this file: ...poky/meta/conf/bitbake.conf mandatory executes when
I source the oe-init-build-env file. Command: . oe-init-build-env

After that I would like to access these environment variables from the
/bin/bash, and query them, but it seems that this is NOT possible?!

I need advise here: how I can query bitbake environment variables set by .
oe-init-build-env, using /bin/bash? Or should I use some special written
python procedure to do this?

Help required/needed!?

I hope what I write here does make sense, does'n it?

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