Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

Adding

PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
armv7ahf-neon-mx8mm"

to my machine config solved my problem but I am not sure if it belongs
there or not.

BR

Den ons 5 juni 2019 kl 14:44 skrev Måns Zigher :
>
> So it looks like I should include armv7ahf-neon-mx8mm to
> PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas?
>
> /Måns
>
> Den ons 5 juni 2019 kl 14:05 skrev Måns Zigher :
> >
> > Looking in the env dump I can see that meta-freescale is overwriting
> > the PACKAGE_ARCH in a alsa-lib_%.bbappend
> >
> > PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"
> >
> > /Måns
> >
> > Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher :
> > >
> > > So running bitbake -e lib32-alsa-lib I can see the following
> > >
> > > # $SSTATE_MANMACH [2 operations]
> > > #   set? 
> > > /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> > > # "${SSTATE_PKGARCH}"
> > > #   set sstate.bbclass:94
> > > [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> > > # "armv7ahf-neon-mx8mm"
> > > # pre-expansion value:
> > > #   "armv7ahf-neon-mx8mm"
> > > SSTATE_MANMACH="armv7ahf-neon-mx8mm"
> > >
> > > So first the SSTATE_MANMACH variable is set to
> > >
> > > SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
> > >
> > > at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
> > >
> > > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> > >
> > > The code that results in this looks like
> > >
> > > if bb.data.inherits_class('native', d):
> > > d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
> > > elif bb.data.inherits_class('crosssdk', d):
> > > d.setVar('SSTATE_PKGARCH',
> > > d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> > > elif bb.data.inherits_class('cross', d):
> > > d.setVar('SSTATE_PKGARCH', 
> > > d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> > > elif bb.data.inherits_class('nativesdk', d):
> > > d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> > > elif bb.data.inherits_class('cross-canadian', d):
> > >     d.setVar('SSTATE_PKGARCH', 
> > > d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
> > > elif bb.data.inherits_class('allarch', d) and
> > > d.getVar("PACKAGE_ARCH") == "all":
> > > d.setVar('SSTATE_PKGARCH', "allarch")
> > > else:
> > > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> > >
> > > So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> > > not get to that else statement.
> > >
> > > /Måns
> > >
> > > Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher :
> > > >
> > > > I have the following manifest files
> > > >
> > > > find . -name "manifest*-lib32-alsa-lib*"
> > > > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> > > >
> > > > but find_sstate_manifest called from package_manager
> > > >
> > > > ./meta/lib/oe/package_manager.py:615:manifest, d2 =
> > > > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > > > multilibs)
> > > > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > > > taskdata2, taskname, d, multilibcache):
> > > >
> > > > will only look for
> > > >
> > > > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > > > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> > > >
> > > > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > > > file since this is not added to any other package when building it for
> > > > lib32.
> > > >
> > > > /Måns
> > > >
> > > > Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher :
> > > > >
> > > > > I think this looks wrong
> > > > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > > > have not intentionally added li

Re: [yocto] How to set PACKAGE_EXTRA_ARCHS

[Måns Zigher]

Adding

PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
armv7ahf-neon-mx8mm"

To my machine config solved my problem but I am not sure if it belongs
here or not.

BR

Den tors 6 juni 2019 kl 10:02 skrev Måns Zigher :
>
> Hi,
>
> I am facing an issue described here
> https://lists.yoctoproject.org/pipermail/yocto/2019-June/045565.html.
> I have come to the conclusion that I need to add armv7ahf-neon-mx8mm
> to PACKAGE_EXTRA_ARCHS but it is not obvious how to do that based on
> what is stated in the reference manual
> https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-PACKAGE_EXTRA_ARCHS,
> at least not for me. I have gone through the existing usage of the
> PACKAGE_EXTRA_ARCHS in poky but in there it is always used in
> combination with tune so for example
>
> PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon  =
> "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"
>
> How can I make sure to get armv7ahf-neon-mx8mm added to the
> PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf,
> machine configuration?
>
> BR
> Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to set PACKAGE_EXTRA_ARCHS

[Måns Zigher]

Hi,

I am facing an issue described here
https://lists.yoctoproject.org/pipermail/yocto/2019-June/045565.html.
I have come to the conclusion that I need to add armv7ahf-neon-mx8mm
to PACKAGE_EXTRA_ARCHS but it is not obvious how to do that based on
what is stated in the reference manual
https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-PACKAGE_EXTRA_ARCHS,
at least not for me. I have gone through the existing usage of the
PACKAGE_EXTRA_ARCHS in poky but in there it is always used in
combination with tune so for example

PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon  =
"${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"

How can I make sure to get armv7ahf-neon-mx8mm added to the
PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf,
machine configuration?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

So it looks like I should include armv7ahf-neon-mx8mm to
PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas?

/Måns

Den ons 5 juni 2019 kl 14:05 skrev Måns Zigher :
>
> Looking in the env dump I can see that meta-freescale is overwriting
> the PACKAGE_ARCH in a alsa-lib_%.bbappend
>
> PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"
>
> /Måns
>
> Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher :
> >
> > So running bitbake -e lib32-alsa-lib I can see the following
> >
> > # $SSTATE_MANMACH [2 operations]
> > #   set? 
> > /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> > # "${SSTATE_PKGARCH}"
> > #   set sstate.bbclass:94
> > [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> > # "armv7ahf-neon-mx8mm"
> > # pre-expansion value:
> > #   "armv7ahf-neon-mx8mm"
> > SSTATE_MANMACH="armv7ahf-neon-mx8mm"
> >
> > So first the SSTATE_MANMACH variable is set to
> >
> > SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
> >
> > at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
> >
> > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> >
> > The code that results in this looks like
> >
> > if bb.data.inherits_class('native', d):
> > d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
> > elif bb.data.inherits_class('crosssdk', d):
> > d.setVar('SSTATE_PKGARCH',
> > d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> > elif bb.data.inherits_class('cross', d):
> > d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> > elif bb.data.inherits_class('nativesdk', d):
> > d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> > elif bb.data.inherits_class('cross-canadian', d):
> > d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
> > elif bb.data.inherits_class('allarch', d) and
> > d.getVar("PACKAGE_ARCH") == "all":
> > d.setVar('SSTATE_PKGARCH', "allarch")
> > else:
> > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> >
> > So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> > not get to that else statement.
> >
> > /Måns
> >
> > Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher :
> > >
> > > I have the following manifest files
> > >
> > > find . -name "manifest*-lib32-alsa-lib*"
> > > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> > >
> > > but find_sstate_manifest called from package_manager
> > >
> > > ./meta/lib/oe/package_manager.py:615:manifest, d2 =
> > > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > > multilibs)
> > > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > > taskdata2, taskname, d, multilibcache):
> > >
> > > will only look for
> > >
> > > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> > >
> > > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > > file since this is not added to any other package when building it for
> > > lib32.
> > >
> > > /Måns
> > >
> > > Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher :
> > > >
> > > > I think this looks wrong
> > > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > > > am not sure why it expects to find that?
> > > >
> > > > /Måns
> > > >
> > > > Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher :
> > > > >
> > > > > When checking the build for lib32-alsa-lib there is no rpm package 
> > > > > created
> > > > >
> > > > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-li

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

Looking in the env dump I can see that meta-freescale is overwriting
the PACKAGE_ARCH in a alsa-lib_%.bbappend

PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"

/Måns

Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher :
>
> So running bitbake -e lib32-alsa-lib I can see the following
>
> # $SSTATE_MANMACH [2 operations]
> #   set? 
> /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> # "${SSTATE_PKGARCH}"
> #   set sstate.bbclass:94
> [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> # "armv7ahf-neon-mx8mm"
> # pre-expansion value:
> #   "armv7ahf-neon-mx8mm"
> SSTATE_MANMACH="armv7ahf-neon-mx8mm"
>
> So first the SSTATE_MANMACH variable is set to
>
> SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
>
> at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
>
> d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
>
> The code that results in this looks like
>
> if bb.data.inherits_class('native', d):
> d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
> elif bb.data.inherits_class('crosssdk', d):
> d.setVar('SSTATE_PKGARCH',
> d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> elif bb.data.inherits_class('cross', d):
> d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> elif bb.data.inherits_class('nativesdk', d):
> d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> elif bb.data.inherits_class('cross-canadian', d):
> d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
> elif bb.data.inherits_class('allarch', d) and
> d.getVar("PACKAGE_ARCH") == "all":
> d.setVar('SSTATE_PKGARCH', "allarch")
> else:
> d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
>
> So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> not get to that else statement.
>
> /Måns
>
> Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher :
> >
> > I have the following manifest files
> >
> > find . -name "manifest*-lib32-alsa-lib*"
> > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> >
> > but find_sstate_manifest called from package_manager
> >
> > ./meta/lib/oe/package_manager.py:615:manifest, d2 =
> > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > multilibs)
> > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > taskdata2, taskname, d, multilibcache):
> >
> > will only look for
> >
> > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> >
> > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > file since this is not added to any other package when building it for
> > lib32.
> >
> > /Måns
> >
> > Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher :
> > >
> > > I think this looks wrong
> > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > > am not sure why it expects to find that?
> > >
> > > /Måns
> > >
> > > Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher :
> > > >
> > > > When checking the build for lib32-alsa-lib there is no rpm package 
> > > > created
> > > >
> > > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > >
> > > > it matches the alsa-lib build also when checking the list of packages 
> > > > by running
> > > >
> > > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > > list-pkg-files -p alsa-lib
> > > >
> > > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > > for this package? I would have thought that that should be the case?
> > > >
> > > > /Måns
> > > >
> > > >

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

So running bitbake -e lib32-alsa-lib I can see the following

# $SSTATE_MANMACH [2 operations]
#   set? 
/home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
# "${SSTATE_PKGARCH}"
#   set sstate.bbclass:94
[__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
# "armv7ahf-neon-mx8mm"
# pre-expansion value:
#   "armv7ahf-neon-mx8mm"
SSTATE_MANMACH="armv7ahf-neon-mx8mm"

So first the SSTATE_MANMACH variable is set to

SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

at line 54 in sstate.bbclass but then it will be overwritten at line 94 to

d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

The code that results in this looks like

if bb.data.inherits_class('native', d):
d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
elif bb.data.inherits_class('crosssdk', d):
d.setVar('SSTATE_PKGARCH',
d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross', d):
d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
elif bb.data.inherits_class('nativesdk', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross-canadian', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
elif bb.data.inherits_class('allarch', d) and
d.getVar("PACKAGE_ARCH") == "all":
d.setVar('SSTATE_PKGARCH', "allarch")
else:
d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
not get to that else statement.

/Måns

Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher :
>
> I have the following manifest files
>
> find . -name "manifest*-lib32-alsa-lib*"
> ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
>
> but find_sstate_manifest called from package_manager
>
> ./meta/lib/oe/package_manager.py:615:manifest, d2 =
> oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> multilibs)
> ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> taskdata2, taskname, d, multilibcache):
>
> will only look for
>
> manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
>
> I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> file since this is not added to any other package when building it for
> lib32.
>
> /Måns
>
> Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher :
> >
> > I think this looks wrong
> > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > am not sure why it expects to find that?
> >
> > /Måns
> >
> > Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher :
> > >
> > > When checking the build for lib32-alsa-lib there is no rpm package created
> > >
> > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > >
> > > it matches the alsa-lib build also when checking the list of packages by 
> > > running
> > >
> > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > list-pkg-files -p alsa-lib
> > >
> > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > for this package? I would have thought that that should be the case?
> > >
> > > /Måns
> > >
> > > Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher :
> > > >
> > > > Hi,
> > > >
> > > > I am trying to build an SDK where I have multilib enabled in my
> > > > local.conf but I am encountering this error message
> > > >
> > > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> &

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615:manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/Måns

Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher :
>
> I think this looks wrong
> "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> have not intentionally added lib32-alsa-lib to the nativesdk part so I
> am not sure why it expects to find that?
>
> /Måns
>
> Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher :
> >
> > When checking the build for lib32-alsa-lib there is no rpm package created
> >
> > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> >
> > it matches the alsa-lib build also when checking the list of packages by 
> > running
> >
> > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > list-pkg-files -p alsa-lib
> >
> > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > for this package? I would have thought that that should be the case?
> >
> > /Måns
> >
> > Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher :
> > >
> > > Hi,
> > >
> > > I am trying to build an SDK where I have multilib enabled in my
> > > local.conf but I am encountering this error message
> > >
> > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > (variant 'lib32')?
> > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > lib32-alsa-lib in
> > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > >
> > > I am currently using poky sumo could not see that anything have
> > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > go through the code in both
> > >
> > > ./poky/meta/lib/oe/package_manager.py
> > >
> > > and
> > >
> > > ./poky/meta/lib/oe/sstatesig.py
> > >
> > > to see if I could understand why there is no manifest file created for
> > > lib32-alsa-lib but without any luck. What task should I run to create
> > > the Manifest file? Any other pointers to where I should look to
> > > understand this issue is appreciated.
> > >
> > > BR
> > > Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher :
>
> When checking the build for lib32-alsa-lib there is no rpm package created
>
> deploy-rpms/armv7ahf_neon_mx8mm# ls
> lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
>
> it matches the alsa-lib build also when checking the list of packages by 
> running
>
> oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> list-pkg-files -p alsa-lib
>
> there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> for this package? I would have thought that that should be the case?
>
> /Måns
>
> Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher :
> >
> > Hi,
> >
> > I am trying to build an SDK where I have multilib enabled in my
> > local.conf but I am encountering this error message
> >
> > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > (variant 'lib32')?
> > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > lib32-alsa-lib in
> > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> >
> > I am currently using poky sumo could not see that anything have
> > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > go through the code in both
> >
> > ./poky/meta/lib/oe/package_manager.py
> >
> > and
> >
> > ./poky/meta/lib/oe/sstatesig.py
> >
> > to see if I could understand why there is no manifest file created for
> > lib32-alsa-lib but without any luck. What task should I run to create
> > the Manifest file? Any other pointers to where I should look to
> > understand this issue is appreciated.
> >
> > BR
> > Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher :
>
> Hi,
>
> I am trying to build an SDK where I have multilib enabled in my
> local.conf but I am encountering this error message
>
> WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> (variant 'lib32')?
> ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> lib32-alsa-lib in
> virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
>
> I am currently using poky sumo could not see that anything have
> changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> go through the code in both
>
> ./poky/meta/lib/oe/package_manager.py
>
> and
>
> ./poky/meta/lib/oe/sstatesig.py
>
> to see if I could understand why there is no manifest file created for
> lib32-alsa-lib but without any luck. What task should I run to create
> the Manifest file? Any other pointers to where I should look to
> understand this issue is appreciated.
>
> BR
> Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] fitImage kernel compression type

[Måns Zigher]

Have you looked at
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/kernel-fitimage.bbclass?
I cannot see that there is an option for determining the compression.
It appears as if it looks specifically for bin-file. I am no expert
regarding fitimage format so I cannot say what the best solution is.

/Måns

Den ons 5 juni 2019 kl 11:24 skrev Pierluigi Greto :
>
> Hello everyone,
>
> I'm building an fitImage and I would like to set the kernel compression
> type. Yocto is automatically creating the linux.bin but I cannot find
> any variable to specify the kernel compression type. I would like to
> have a gzip compressed kernel. Is possible to specify the compression
> type by using a variable? If not, there are other ways?
>
> Thank you,
> Pierluigi
>
> --
> ___
> 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] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

[Måns Zigher]

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target

[Måns Zigher]

Hi,

I found in cmake.bbclass

cmake \
  ${OECMAKE_GENERATOR_ARGS} \
  $oecmake_sitefile \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
  -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
  
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
d.  getVar('prefix'))} \
  -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
  -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'),
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev

so it looks all CMAKE_INSTALL paths are actually managed by cmake class.

/Måns

Den tis 28 maj 2019 kl 18:47 skrev Måns Zigher :
>
> Hi,
>
> Not really a Yocto question but I am trying to build an application
> using our SDK. We are using CMake to build and are using
> GNUInstallDIrs for managing our install paths. I thought
> GNUInstallDirs should have the detected that the SDK was a multilib
> which it dose in regards to finding packages since it will look for
> libraries under /usr/lib64 but when looking into GNUInstallDirs it
> will explicitly not try and detect if CMAKE_INSTALL_LIBDIR should be
> lib or lib64 when CMAKE_CROSSCOMPILING is set which it is when using
> the SDK. When building the same application in our image build it
> works as expected and GNUInstallDirs will detect that it is a multilib
> dir and install it under /usr/lib64. Could anyone point me to how we
> manage this in poky/OE so I could potentially copy that to our SDK
> build?
>
> BR
> Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target

[Måns Zigher]

Hi,

Not really a Yocto question but I am trying to build an application
using our SDK. We are using CMake to build and are using
GNUInstallDIrs for managing our install paths. I thought
GNUInstallDirs should have the detected that the SDK was a multilib
which it dose in regards to finding packages since it will look for
libraries under /usr/lib64 but when looking into GNUInstallDirs it
will explicitly not try and detect if CMAKE_INSTALL_LIBDIR should be
lib or lib64 when CMAKE_CROSSCOMPILING is set which it is when using
the SDK. When building the same application in our image build it
works as expected and GNUInstallDirs will detect that it is a multilib
dir and install it under /usr/lib64. Could anyone point me to how we
manage this in poky/OE so I could potentially copy that to our SDK
build?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to prevent dnf to check for dependencies during do_rootfs task

[Måns Zigher]

Hi,

I have a recipe where I am getting a set of binaries files from a third
party. These files are not well put together. For example they are linked
to none versioned so-files for example

 0x0001 (NEEDED) Shared library: [libnss3.so]
 0x0001 (NEEDED) Shared library: [libnssutil3.so]
 0x0001 (NEEDED) Shared library: [libnspr4.so]
 0x0001 (NEEDED) Shared library: [libffmpeg.so]
 0x0001 (NEEDED) Shared library: [libuuid.so]
 0x0001 (NEEDED) Shared library: [libasound.so]
 0x0001 (NEEDED) Shared library: [libmetrics.so]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libcutils.so]
 0x0001 (NEEDED) Shared library:
[libglibc_bridge.so]
 0x0001 (NEEDED) Shared library: [libcurl.so]

Some of these files are not supplied by the third party so for example
libuuid.so is not supplied by them and this causes some friction when using
rpm as the package. The dnf package manager will complain that nothing is
supplying libuuid.so which is correct. I have tried to solve this by
including libuuid.so.1 to the package and then create a link libuuid.so
that points to the libuuid.so.1 library but dnf is not satisfied with that.
I have made sure that the link is part of the package so it is not a mater
of getting it included in the dev package. Renaming libuuid.so.1 to
libuuid.so will not solve this problem because dnf checks the elf headers
and detects that the SONAME is libuuid.so.1. I have considered using
patchelf to modify the SONAME but at one point I get an error from the
linker so I don't think it is the best approach. When looking at rpmbuild I
can see that there is an option --no-deps so is there a way to supply these
flags when creating the rpm package? Or supply some flags to dnf to prevent
it from checking dependencies? Or are the only option  to get the third
party to supply something usable?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi guys,

I found the issue and dnf is doing exactly what it should. The problem is
the shared library

readelf -d libx_media_1.0.so


Dynamic section at offset 0xf31c8 contains 40 entries:
  TagType Name/Value

...
 0x000e (SONAME) Library soname: [
libx_media_1.0_wtf.so]

So the SONAME of the file is actually set to libx_media_1.0_wtf.so but the
file is named libx_media_1.0.so and the executable that is part of the
package is linked against libx_media_1.0.so also.
I manage to figure this out when I was going
through /tmp/work/path/to/xmedia/1.0-r43/pkgdata/shlibs2 and I noticed that
in xmedia.lst file actually did not include the libx_media_1.0.so but
libx_media_1.0_wtf.so.
Thanks for your efforts.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 13:01 skrev Måns Zigher :

> Hi,
>
> Yes I noticed it so I tried that out but without any success but I will
> investigate that also to see if change it can in another result.
>
> BR
> Måns Zigher
>
> Den ons 23 jan. 2019 kl 12:33 skrev Einar Vading :
>
>> This is a longshot but I am currently investigating an issue we have
>> with a packagegroup.
>>
>> I get a similar error but I can fix it by moving the package in my
>> RDEPENDS in the packagegroup.
>>
>> If you move your libx_media up or down in the packagegroup, does it help?
>>
>> For me i got:
>> Error:
>>   Problem: conflicting requests
>>   - nothing provides libserved-utilsoversion needed by
>> packagegroup-base-1.0-r0.0.noarch
>>
>> When I had:
>> RDEPENDS_${PN} = "\
>> libdomain-somelib \
>> libsomeotherlib \
>> served-util \
>> "
>>
>> But changing to:
>> RDEPENDS_${PN} = "\
>> libdomain-somelib \
>>     served-util \
>> libsomeotherlib \
>> "
>> Made it work.
>>
>> If you're down to trying anything you might as well try this =)
>>
>> // Einar
>>
>> On Wed, Jan 23, 2019 at 12:03 PM Måns Zigher 
>> wrote:
>> >
>> > I have toke the rpm file that was produced. I found the file under the
>> build directory under
>> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
>> I used the following commands
>> > 7z x x_media-1.0-r44.imx8mq.rpm
>> > 7z x x_media-1.0-r44.imx8mq.cpio
>> >
>> > The result from this gave me the file tree where I then could run
>> > file usr/lib/libx_media_1.0.so
>> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
>> version 1 (SYSV), dynamically linked, stripped
>> >
>> > So I believe that I have concluded that the rpm include the file that
>> dnf is complaining about. I don't understand why dnf thinks that this
>> dependency is not meet when it clearly is part of the package. I have added
>> verbose flags to the dnf call but dose not give any more information.
>> > I am not sure how I can proceed to find out what I have done wrong. The
>> recipe is a bit of a freak of nature because the binaries that I am
>> packaging is actually built using another toolchain but it is for the same
>> arch can dnf detect that?
>> >
>> > BR
>> > Måns Zigher
>> >
>> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher > >:
>> >>
>> >> Hi,
>> >>
>> >> I am struggling with a recipe which more or less just downloads
>> binaries and creating a package. We have previously been using ipkg but now
>> we have switched to rpm in our builds. One of the binaries in the packages
>> is a library let's call it libx_media_1.0.so. This library is part of
>> the package that the recipe is producing. The library is placed under
>> /usr/lib/. When building the image I am getting the following error
>> >>
>> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> >> .
>> >> ...
>> >> Error:
>> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires
>> x_media, but none of the providers can be installed
>> >>   - conflicting requests
>> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
>> x_media-1.0-r44.imx8mq
>> >>
>> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>> >>
>> >> Here is the output from running the command file on the library
>> >>
>> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
>> version 1 (SYSV), dynamically linked, stripped
>> >>
>> >> I have also verified that the library is part of the produced rpm so
>> that is not the issue.
>> >>
>> >> Dose anyone have any suggestion on how to debug this problem? Because
>> I am out of ideas
>> >>
>> >> BR
>> >> Måns Zigher
>> >
>> > --
>> > ___
>> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

Yes I noticed it so I tried that out but without any success but I will
investigate that also to see if change it can in another result.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 12:33 skrev Einar Vading :

> This is a longshot but I am currently investigating an issue we have
> with a packagegroup.
>
> I get a similar error but I can fix it by moving the package in my
> RDEPENDS in the packagegroup.
>
> If you move your libx_media up or down in the packagegroup, does it help?
>
> For me i got:
> Error:
>   Problem: conflicting requests
>   - nothing provides libserved-utilsoversion needed by
> packagegroup-base-1.0-r0.0.noarch
>
> When I had:
> RDEPENDS_${PN} = "\
> libdomain-somelib \
> libsomeotherlib \
> served-util \
> "
>
> But changing to:
> RDEPENDS_${PN} = "\
> libdomain-somelib \
> served-util \
> libsomeotherlib \
> "
> Made it work.
>
> If you're down to trying anything you might as well try this =)
>
> // Einar
>
> On Wed, Jan 23, 2019 at 12:03 PM Måns Zigher 
> wrote:
> >
> > I have toke the rpm file that was produced. I found the file under the
> build directory under
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
> I used the following commands
> > 7z x x_media-1.0-r44.imx8mq.rpm
> > 7z x x_media-1.0-r44.imx8mq.cpio
> >
> > The result from this gave me the file tree where I then could run
> > file usr/lib/libx_media_1.0.so
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > So I believe that I have concluded that the rpm include the file that
> dnf is complaining about. I don't understand why dnf thinks that this
> dependency is not meet when it clearly is part of the package. I have added
> verbose flags to the dnf call but dose not give any more information.
> > I am not sure how I can proceed to find out what I have done wrong. The
> recipe is a bit of a freak of nature because the binaries that I am
> packaging is actually built using another toolchain but it is for the same
> arch can dnf detect that?
> >
> > BR
> > Måns Zigher
> >
> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
> >>
> >> Hi,
> >>
> >> I am struggling with a recipe which more or less just downloads
> binaries and creating a package. We have previously been using ipkg but now
> we have switched to rpm in our builds. One of the binaries in the packages
> is a library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> >> .
> >> ...
> >> Error:
> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >>   - conflicting requests
> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >>
> >> Here is the output from running the command file on the library
> >>
> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >>
> >> I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >>
> >> Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >>
> >> BR
> >> Måns Zigher
> >
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

I am sorry but I cannot locate the .spec file. I tried searching for .spec
in the tmp/work but I could not find any .spec file. Do I have to build
with a flag to get this .spec file?

BR
Måns Zigher

Den ons 23 jan. 2019 kl 12:07 skrev Alexander Kanavin <
alex.kana...@gmail.com>:

> One more thing: can you provide the .spec file that is generated
> during build and used to create .rpm packages? You will find it under
> tmp/work//x_media/
>
> Please try not to edit anything out of it.
>
> Alex
>
> On Wed, 23 Jan 2019 at 12:02, Måns Zigher  wrote:
> >
> > I have toke the rpm file that was produced. I found the file under the
> build directory under
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
> I used the following commands
> > 7z x x_media-1.0-r44.imx8mq.rpm
> > 7z x x_media-1.0-r44.imx8mq.cpio
> >
> > The result from this gave me the file tree where I then could run
> > file usr/lib/libx_media_1.0.so
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > So I believe that I have concluded that the rpm include the file that
> dnf is complaining about. I don't understand why dnf thinks that this
> dependency is not meet when it clearly is part of the package. I have added
> verbose flags to the dnf call but dose not give any more information.
> > I am not sure how I can proceed to find out what I have done wrong. The
> recipe is a bit of a freak of nature because the binaries that I am
> packaging is actually built using another toolchain but it is for the same
> arch can dnf detect that?
> >
> > BR
> > Måns Zigher
> >
> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
> >>
> >> Hi,
> >>
> >> I am struggling with a recipe which more or less just downloads
> binaries and creating a package. We have previously been using ipkg but now
> we have switched to rpm in our builds. One of the binaries in the packages
> is a library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> >> .
> >> ...
> >> Error:
> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >>   - conflicting requests
> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >>
> >> Here is the output from running the command file on the library
> >>
> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >>
> >> I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >>
> >> Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >>
> >> BR
> >> Måns Zigher
> >
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

I have toke the rpm file that was produced. I found the file under the
build directory under
tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
I used the following commands
7z x x_media-1.0-r44.imx8mq.rpm
7z x x_media-1.0-r44.imx8mq.cpio

The result from this gave me the file tree where I then could run
file usr/lib/libx_media_1.0.so

usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
version 1 (SYSV), dynamically linked, stripped

So I believe that I have concluded that the rpm include the file that dnf
is complaining about. I don't understand why dnf thinks that this
dependency is not meet when it clearly is part of the package. I have added
verbose flags to the dnf call but dose not give any more information.
I am not sure how I can proceed to find out what I have done wrong. The
recipe is a bit of a freak of nature because the binaries that I am
packaging is actually built using another toolchain but it is for the same
arch can dnf detect that?

BR
Måns Zigher

Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :

> Hi,
>
> I am struggling with a recipe which more or less just downloads binaries
> and creating a package. We have previously been using ipkg but now we have
> switched to rpm in our builds. One of the binaries in the packages is a
> library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
>
> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> .
> ...
> Error:
>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
>
> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>
> Here is the output from running the command file on the library
>
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
>
> I have also verified that the library is part of the produced rpm so that
> is not the issue.
>
> Dose anyone have any suggestion on how to debug this problem? Because I am
> out of ideas
>
> BR
> Måns Zigher
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

I have verified that the so-lib file is part of the rpm package and I am
using INSANE_SKIP where I have added dev-so but I am willing to try
anything right now so thanks. The so-files is not something I have control
of it is something that is delivered to us.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 10:12 skrev Einar Vading :

> I'm not sure this is your problem but if you don't version your
> so-libs you could get this since the .so (without version) is not
> shipped by default I think.
>
> Try putting this in your recipe:
> SOLIBS = ".so*"
> FILES_SOLIBSDEV = ""
> ERROR_QA_remove = "dev-so"
>
> If that works I think the proper solution is to give your so-lib a version.
>
> // Einar
>
> On Tue, Jan 22, 2019 at 6:00 PM Måns Zigher  wrote:
> >
> > Hi,
> >
> > I am struggling with a recipe which more or less just downloads binaries
> and creating a package. We have previously been using ipkg but now we have
> switched to rpm in our builds. One of the binaries in the packages is a
> library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >
> > ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> > .
> > ...
> > Error:
> >  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >   - conflicting requests
> >   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >
> > ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >
> > Here is the output from running the command file on the library
> >
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >
> > Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >
> > BR
> > Måns Zigher
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

I am struggling with a recipe which more or less just downloads binaries
and creating a package. We have previously been using ipkg but now we have
switched to rpm in our builds. One of the binaries in the packages is a
library let's call it libx_media_1.0.so. This library is part of the
package that the recipe is producing. The library is placed under
/usr/lib/. When building the image I am getting the following error

ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
.
...
Error:
 Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but
none of the providers can be installed
  - conflicting requests
  - nothing provides libx_media_1.0.so()(64bit) needed by
x_media-1.0-r44.imx8mq

ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs

Here is the output from running the command file on the library

usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
version 1 (SYSV), dynamically linked, stripped

I have also verified that the library is part of the produced rpm so that
is not the issue.

Dose anyone have any suggestion on how to debug this problem? Because I am
out of ideas

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

[Måns Zigher]

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even though
I am not so sure it is a workaround or not. The problem is fixed adding to
kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk
cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher :

> Hi,
>
> I am trying to add the kernel devsrc to the SDK but I am getting the
> following error
>
> Problem: conflicting requests
>   - nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk
>
> I have applied the following patch to try and fix this problem.
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2
>
> I have verified that it was applied and run kernel-devsrc works. The error
> is from do_populate_sdk and I am suspecting that the problem is related to
> me using rpm. I believe rpm might be to smart in this case detecting the
> dependency and resulting dnf from failing when running the task
> do_populate_sdk. Any suggestion on how to get forward on this error. I
> would like to run dnf manually to check any dependency of the kernel-devsrc
> rpm package but cannot figure out how.
>
> BR
> Måns Zigher
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [SDK] including kernel devsrc to the SDK failes

[Måns Zigher]

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
  - nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The error
is from do_populate_sdk and I am suspecting that the problem is related to
me using rpm. I believe rpm might be to smart in this case detecting the
dependency and resulting dnf from failing when running the task
do_populate_sdk. Any suggestion on how to get forward on this error. I
would like to run dnf manually to check any dependency of the kernel-devsrc
rpm package but cannot figure out how.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [qemu] How to use qemu in your testing cycle

[Måns Zigher]

Hi,

I am trying to wrap my head around how to incorporate qemu in our
test/development cycle. I am currently building machine genericx86-64
machine producing a SDK and a number of files. One of them are the
qemuboot.conf file but it have some path that is a relative path to the
work directory. I would like to be able to supply our application developer
a way to start a qemu instance and test out our application without having
them using bitbake. I assume this should be possible but not sure exactly
how to accomplish this? Any input would be appreciated so I can get started.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Måns Zigher]

Maybe update the documentation I think Andre McCurdy stated it clearly.
English is not my first language but maybe something like

"Depending on when a QA test is running it may or may not be disabled
per-package basis. For example "already-stripped" can only be applied on
INSANE_SKIP_${PN} while "dev-so" can be disabled per-package basis."

BR
Måns Zigher

Den ons 17 okt. 2018 kl 06:39 skrev Måns Zigher :

> Thank you for the clarification that helps
>
> BR
> Måns Zigher
>
> Den ons 17 okt. 2018 kl 00:36 skrev Andre McCurdy :
>
>> On Tue, Oct 16, 2018 at 6:47 AM, Burton, Ross 
>> wrote:
>> > It's only already-stripped that needs to be on PN, because the
>> > stripping happens before packaging.  When already-stripped files,
>> > there are no packages yet.
>> >
>> > Ross
>> > On Tue, 16 Oct 2018 at 14:22, Måns Zigher 
>> wrote:
>> >>
>> >> Ok so it is not supported to have the already-stripped on a package
>> level? I cannot set it on PN because I have some so-files that is already
>> stripped and others that is not so that was why I wanted to create a
>> package for the already-stripped so-files and use the already-stripped on
>> that package. Anyway thanks for the help I ended up creating a new recipe
>> for the already-stripped so-files. But is all the INSANE_SKIP flags only
>> supported for PN? I think I have seen dev-so used on an package level?
>>
>> The key point is when the QA test is run. In the case of
>> "already-stripped", the test is run as part of split_and_strip_files()
>> in package.bbclass, ie as part of the normal stripping process. As
>> Ross mentions, it's therefore run before the build output is split
>> into packages.
>>
>> The "dev-so" QA test is run as part of do_package_qa() in
>> insane.bbclass and can be disabled on a per-package basis.
>>
>> As far as I know, there's no documentation to say which QA tests can
>> be disabled on a per-package basis and which can not. If you want to
>> be sure you need to read the source. Start by grepping for the QA test
>> you are interested in and also for "package_qa_handle_error" (which is
>> the function which is called when a QA test fails). Those two together
>> should help locate the place where the QA test is run... and from that
>> you can inspect the code to see if/how INSANE_SKIP is applied. For
>> example, in the case of "already-stripped", the test is run from
>> split_and_strip_files() and only INSANE_SKIP_${PN} is checked:
>>
>>
>> http://git.openembedded.org/openembedded-core/tree/meta/classes/package.bbclass?h=sumo#n1010
>>
>> (In this case, the code could perhaps be even clearer if checking
>> whether "already-stripped" is found in INSANE_SKIP_${PN} was done once
>> at the start of the function, rather than being determining again and
>> again for each file inside the "for every elf file" loop).
>>
>> >> BR
>> >> Måns Zigher
>> >>
>> >> Den mån 15 okt. 2018 kl 22:23 skrev Burton, Ross <
>> ross.bur...@intel.com>:
>> >>>
>> >>> Ah yes, of course.  Stripping happens *before* package splitting, so
>> >>> it doesn't make sense to have it set on PN-package1.  Just set it on
>> >>> PN and it should work.
>> >>>
>> >>> Ross
>> >>> On Mon, 15 Oct 2018 at 08:18, Måns Zigher 
>> wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > Sorry I see now that there is a typo. What I mean is that in the
>> default package I am not suing INSANE_SKIP but for packag1 I need
>> already-stripped
>> >>> >
>> >>> > INSANE_SKIP_${PN}-package1 = " \
>> >>> > dev-so \
>> >>> > already-stripped \
>> >>> > "
>> >>> >
>> >>> > But I continuously get the error that they are already-stripped. So
>> is it supposed to work because I don't understand  the code in the
>> package.bbclass since it looks like it is only checking for
>> already-stripped in ${PN} and not ${PN}-package1?
>> >>> >
>> >>> > BR
>> >>> > Måns Zigher
>> >>> >
>> >>> >
>> >>> >
>> >>> > Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross <
>> ross.bur...@intel.com>:
>> >>> >>
>> >>> >> On Thu, 11 Oct 2018 at 18:14, Måns Zigher 
>> wrote:
>> >>> >> > I have been struggling with a problem where I need to create a
>> package in a recipe and set already-stripped for that package. The package
>> in question is not the the default one so I am trying to set it by using
>> >>> >> >
>> >>> >> > INSANE_SKIP_${PN} += " \
>> >>> >> > dev-so \
>> >>> >> > already-stripped \
>> >>> >> > "
>> >>> >>
>> >>> >> You say no the default one, but PN is "the default" one, so that's
>> >>> >> probably why that doesn't work.
>> >>> >>
>> >>> >> Ross
>> > --
>> > ___
>> > 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] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Måns Zigher]

Thank you for the clarification that helps

BR
Måns Zigher

Den ons 17 okt. 2018 kl 00:36 skrev Andre McCurdy :

> On Tue, Oct 16, 2018 at 6:47 AM, Burton, Ross 
> wrote:
> > It's only already-stripped that needs to be on PN, because the
> > stripping happens before packaging.  When already-stripped files,
> > there are no packages yet.
> >
> > Ross
> > On Tue, 16 Oct 2018 at 14:22, Måns Zigher  wrote:
> >>
> >> Ok so it is not supported to have the already-stripped on a package
> level? I cannot set it on PN because I have some so-files that is already
> stripped and others that is not so that was why I wanted to create a
> package for the already-stripped so-files and use the already-stripped on
> that package. Anyway thanks for the help I ended up creating a new recipe
> for the already-stripped so-files. But is all the INSANE_SKIP flags only
> supported for PN? I think I have seen dev-so used on an package level?
>
> The key point is when the QA test is run. In the case of
> "already-stripped", the test is run as part of split_and_strip_files()
> in package.bbclass, ie as part of the normal stripping process. As
> Ross mentions, it's therefore run before the build output is split
> into packages.
>
> The "dev-so" QA test is run as part of do_package_qa() in
> insane.bbclass and can be disabled on a per-package basis.
>
> As far as I know, there's no documentation to say which QA tests can
> be disabled on a per-package basis and which can not. If you want to
> be sure you need to read the source. Start by grepping for the QA test
> you are interested in and also for "package_qa_handle_error" (which is
> the function which is called when a QA test fails). Those two together
> should help locate the place where the QA test is run... and from that
> you can inspect the code to see if/how INSANE_SKIP is applied. For
> example, in the case of "already-stripped", the test is run from
> split_and_strip_files() and only INSANE_SKIP_${PN} is checked:
>
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/package.bbclass?h=sumo#n1010
>
> (In this case, the code could perhaps be even clearer if checking
> whether "already-stripped" is found in INSANE_SKIP_${PN} was done once
> at the start of the function, rather than being determining again and
> again for each file inside the "for every elf file" loop).
>
> >> BR
> >> Måns Zigher
> >>
> >> Den mån 15 okt. 2018 kl 22:23 skrev Burton, Ross  >:
> >>>
> >>> Ah yes, of course.  Stripping happens *before* package splitting, so
> >>> it doesn't make sense to have it set on PN-package1.  Just set it on
> >>> PN and it should work.
> >>>
> >>> Ross
> >>> On Mon, 15 Oct 2018 at 08:18, Måns Zigher 
> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Sorry I see now that there is a typo. What I mean is that in the
> default package I am not suing INSANE_SKIP but for packag1 I need
> already-stripped
> >>> >
> >>> > INSANE_SKIP_${PN}-package1 = " \
> >>> > dev-so \
> >>> > already-stripped \
> >>> > "
> >>> >
> >>> > But I continuously get the error that they are already-stripped. So
> is it supposed to work because I don't understand  the code in the
> package.bbclass since it looks like it is only checking for
> already-stripped in ${PN} and not ${PN}-package1?
> >>> >
> >>> > BR
> >>> > Måns Zigher
> >>> >
> >>> >
> >>> >
> >>> > Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross <
> ross.bur...@intel.com>:
> >>> >>
> >>> >> On Thu, 11 Oct 2018 at 18:14, Måns Zigher 
> wrote:
> >>> >> > I have been struggling with a problem where I need to create a
> package in a recipe and set already-stripped for that package. The package
> in question is not the the default one so I am trying to set it by using
> >>> >> >
> >>> >> > INSANE_SKIP_${PN} += " \
> >>> >> > dev-so \
> >>> >> > already-stripped \
> >>> >> > "
> >>> >>
> >>> >> You say no the default one, but PN is "the default" one, so that's
> >>> >> probably why that doesn't work.
> >>> >>
> >>> >> Ross
> > --
> > ___
> > 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] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Måns Zigher]

Ok so it is not supported to have the already-stripped on a package level?
I cannot set it on PN because I have some so-files that is already stripped
and others that is not so that was why I wanted to create a package for the
already-stripped so-files and use the already-stripped on that package.
Anyway thanks for the help I ended up creating a new recipe for the
already-stripped so-files. But is all the INSANE_SKIP flags only supported
for PN? I think I have seen dev-so used on an package level?

BR
Måns Zigher

Den mån 15 okt. 2018 kl 22:23 skrev Burton, Ross :

> Ah yes, of course.  Stripping happens *before* package splitting, so
> it doesn't make sense to have it set on PN-package1.  Just set it on
> PN and it should work.
>
> Ross
> On Mon, 15 Oct 2018 at 08:18, Måns Zigher  wrote:
> >
> > Hi,
> >
> > Sorry I see now that there is a typo. What I mean is that in the default
> package I am not suing INSANE_SKIP but for packag1 I need already-stripped
> >
> > INSANE_SKIP_${PN}-package1 = " \
> > dev-so \
> > already-stripped \
> > "
> >
> > But I continuously get the error that they are already-stripped. So is
> it supposed to work because I don't understand  the code in the
> package.bbclass since it looks like it is only checking for
> already-stripped in ${PN} and not ${PN}-package1?
> >
> > BR
> > Måns Zigher
> >
> >
> >
> > Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross  >:
> >>
> >> On Thu, 11 Oct 2018 at 18:14, Måns Zigher 
> wrote:
> >> > I have been struggling with a problem where I need to create a
> package in a recipe and set already-stripped for that package. The package
> in question is not the the default one so I am trying to set it by using
> >> >
> >> > INSANE_SKIP_${PN} += " \
> >> > dev-so \
> >> > already-stripped \
> >> > "
> >>
> >> You say no the default one, but PN is "the default" one, so that's
> >> probably why that doesn't work.
> >>
> >> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Måns Zigher]

Hi,

Sorry I see now that there is a typo. What I mean is that in the default
package I am not suing INSANE_SKIP but for packag1 I need already-stripped

INSANE_SKIP_${PN}-package1 = " \
dev-so \
already-stripped \
"

But I continuously get the error that they are already-stripped. So is it
supposed to work because I don't understand  the code in the
package.bbclass since it looks like it is only checking for
already-stripped in ${PN} and not ${PN}-package1?

BR
Måns Zigher



Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross :

> On Thu, 11 Oct 2018 at 18:14, Måns Zigher  wrote:
> > I have been struggling with a problem where I need to create a package
> in a recipe and set already-stripped for that package. The package in
> question is not the the default one so I am trying to set it by using
> >
> > INSANE_SKIP_${PN} += " \
> > dev-so \
> > already-stripped \
> > "
>
> You say no the default one, but PN is "the default" one, so that's
> probably why that doesn't work.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Måns Zigher]

Hi,

I have been struggling with a problem where I need to create a package in a
recipe and set already-stripped for that package. The package in question
is not the the default one so I am trying to set it by using

INSANE_SKIP_${PN} += " \
dev-so \
already-stripped \
"

But the result is like it ignore is it. The only way to get it to work is
if I include the file in the default package and set already-stripped to
INSANE_SKIP_${PN}. When looking at the code at package.bbclass this seems
to be correct

if 'already-stripped' in (d.getVar('INSANE_SKIP_' + pn) or "").split():

Is this really the way it should work. I mean dev-so can be set per package
in a recipe but is it not supported to set already-stripped per package? I
am running rocko but could not set that this have be updated in sumo. The
documentation doesn't describe this limitation either.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Måns Zigher]

Hi,

Thanks for your reply. A colleague found

OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH"

and it seems to work. Do you have any comment using this?

Br
Måns Zigher

On Thu, Sep 6, 2018, 13:52 Alexander Kanavin  wrote:

> Sadly, Yocto is not well equippped to deal with projects that download
> stuff from the internet as a part of the build process. I'd say if
> it's just one project, write a separate recipe for it, and build it
> via that. Then install into the original recipe's sysroot or build dir
> as needed, and make sure the project doesn't attempt to download it
> anymore.
>
> Alex
>
> 2018-09-06 13:05 GMT+02:00 Måns Zigher :
> > Hi,
> >
> > I have a cmake project that is making use of ExternalProject_Add. The
> > external project will make use of git clone to pull down the project. The
> > problem that I am seeing is that the do_configure will fail because it
> > cannot find git which is not part of the sysroot the reason for git not
> > being part the sysroot is that git-native is included in ASSUME_PROVIDED
> > which prevent me from getting it into the sysroot and when running
> > do_configure it will only look for it in the sysroot and not on the host
> if
> > I am not mistaken? What would the best way be to proceed to solve this
> > problem?
> >
> > BR
> > Måns Zigher
> >
> > --
> > ___
> > 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] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Måns Zigher]

Hi,

I have a cmake project that is making use of ExternalProject_Add. The
external project will make use of git clone to pull down the project. The
problem that I am seeing is that the do_configure will fail because it
cannot find git which is not part of the sysroot the reason for git not
being part the sysroot is that git-native is included in ASSUME_PROVIDED
which prevent me from getting it into the sysroot and when running
do_configure it will only look for it in the sysroot and not on the host if
I am not mistaken? What would the best way be to proceed to solve this
problem?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] busybox: adding task to run before do_configure

[Måns Zigher]

Hi,

Thanks for your answer. So this is a simplified implementation so you are
right. I have based my implementation on a class used for kernel you can
find the original implementation here
https://github.com/resin-os/meta-resin/blob/master/meta-resin-common/classes/kernel-resin.bbclass.
I am not sure I understand it fully but the error is not reproducible
there. You can modify the config in two ways you can define areas to modify
in the config but you can also define a new config to base it on and I
thought that the deptasks was need to make sure that configured is called
again. But maybe you are right there is no reason for it. But I am
still curious how it can affect the staging part of install task since it
is not affecting the kernel and I am not doing anything in the tasks.

BR
Mans Zigher

2018-06-25 20:03 GMT+02:00 Burton, Ross :

> AFAIK, you don't need the deptasks as the before/after statements will
> insert the task in the right place.
>
> Ross
>
> On 25 June 2018 at 18:59, Måns Zigher  wrote:
> > Hi,
> >
> > I have created this simple class file
> >
> > python do_busybox_foo() {
> > bb.warn("BUSYBOX: foo task!")
> > }
> > addtask busybox_foo after do_configure before do_compile
> > do_busybox_foo[deptask] += "do_configure"
> >
> > do_compile[deptask] += "do_busybox_foo"
> >
> > And created a busybox_%.bbappend inherit this class. When running this I
> am
> > seeing the following error
> >
> > WARNING: busybox-1.24.1-r0 do_busybox_foo: BUSYBOX: foo task!
> > ERROR: busybox-1.24.1-r0 do_install: Error executing a python function in
> > exec_python_func() autogenerated:
> >
> > The stack trace of python calls that resulted in this exception/failure
> was:
> > File: 'exec_python_func() autogenerated', lineno: 2, function: 
> >  0001:
> >  *** 0002:extend_recipe_sysroot(d)
> >  0003:
> > File: '/home/user/workdir/layers/poky/meta/classes/staging.bbclass',
> lineno:
> > 565, function: extend_recipe_sysroot
> >  0561:dest = newmanifest[l]
> >  0562:if l.endswith("/"):
> >  0563:staging_copydir(l, targetdir, dest,
> > seendirs)
> >  0564:continue
> >  *** 0565:staging_copyfile(l, targetdir, dest,
> > postinsts, seendirs)
> >  0566:
> >  0567:bb.note("Installed into sysroot: %s" % str(msg_adding))
> >  0568:bb.note("Skipping as already exists in sysroot: %s" %
> > str(msg_exists))
> >  0569:
> > File: '/home/user/workdir/layers/poky/meta/classes/staging.bbclass',
> lineno:
> > 151, function: staging_copyfile
> >  0147:os.symlink(linkto, dest)
> >  0148:#bb.warn(c)
> >  0149:else:
> >  0150:try:
> >  *** 0151:os.link(c, dest)
> >  0152:except OSError as err:
> >  0153:if err.errno == errno.EXDEV:
> >  0154:bb.utils.copyfile(c, dest)
> >  0155:else:
> > Exception: FileExistsError: [Errno 17] File exists:
> > '/home/user/workdir/build/tmp/sysroots-components/
> cortexa7hf-neon/glibc-initial/usr/include/time.h'
> > ->
> > '/home/user/workdir/build/tmp/work/cortexa7hf-neon-target-
> linux-gnueabi/busybox/1.24.1-r0/recipe-sysroot/usr/include/time.h'
> >
> > ERROR: busybox-1.24.1-r0 do_install: Function failed:
> extend_recipe_sysroot
> > ERROR: Logfile of failure stored in:
> > /home/user/workdir/build/tmp/work/cortexa7hf-neon-target-
> linux-gnueabi/busybox/1.24.1-r0/temp/log.do_install.30635
> > ERROR: Task
> > (/home/user/workdir/layers/poky/meta/recipes-core/
> busybox/busybox_1.24.1.bb:do_install)
> > failed with exit code '1'
> >
> > I have tried to debug this because I cannot understand why it affects the
> > staging in the install task. By removing the do_busybox_foo[deptask] I
> > prevent this error. Any advise would be appreciated.
> >
> > BR
> > Måns Zigher
> >
> > --
> > ___
> > 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] busybox: adding task to run before do_configure

[Måns Zigher]

Hi,

I have created this simple class file

python do_busybox_foo() {
bb.warn("BUSYBOX: foo task!")
}
addtask busybox_foo after do_configure before do_compile
do_busybox_foo[deptask] += "do_configure"

do_compile[deptask] += "do_busybox_foo"

And created a busybox_%.bbappend inherit this class. When running this I am
seeing the following error

WARNING: busybox-1.24.1-r0 do_busybox_foo: BUSYBOX: foo task!

ERROR: busybox-1.24.1-r0 do_install: Error executing a python function in
exec_python_func() autogenerated:


The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 

 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/home/user/workdir/layers/poky/meta/classes/staging.bbclass',
lineno: 565, function: extend_recipe_sysroot

 0561:dest = newmanifest[l]
 0562:if l.endswith("/"):
 0563:staging_copydir(l, targetdir, dest,
seendirs)
 0564:continue
 *** 0565:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
 0566:
 0567:bb.note("Installed into sysroot: %s" % str(msg_adding))

 0568:bb.note("Skipping as already exists in sysroot: %s" %
str(msg_exists))
 0569:
File: '/home/user/workdir/layers/poky/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile

 0147:os.symlink(linkto, dest)
 0148:#bb.warn(c)
 0149:else:
 0150:try:
 *** 0151:os.link(c, dest)
 0152:except OSError as err:
 0153:if err.errno == errno.EXDEV:
 0154:bb.utils.copyfile(c, dest)

 0155:else:
Exception: FileExistsError: [Errno 17] File exists:
'/home/user/workdir/build/tmp/sysroots-components/cortexa7hf-neon/glibc-initial/usr/include/time.h'
->
'/home/user/workdir/build/tmp/work/cortexa7hf-neon-target-linux-gnueabi/busybox/1.24.1-r0/recipe-sysroot/usr/include/time.h'

ERROR: busybox-1.24.1-r0 do_install: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/home/user/workdir/build/tmp/work/cortexa7hf-neon-target-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_install.30635

ERROR: Task
(/home/user/workdir/layers/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_install)
failed with exit code '1'

I have tried to debug this because I cannot understand why it affects the
staging in the install task. By removing the do_busybox_foo[deptask] I
prevent this error. Any advise would be appreciated.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Måns Zigher]

Hi,

I am building with the SDK (not extensible) but it is also built as a
recipe when building an image. The recipe is inheriting cmake but it is
only in the image build that I am experiencing this problem which I
shouldn't since the cmake_do_configure should be called. I will try and run
bitbake -e on the recepie to see if I get any clear if the
cmake_do_configure is part of it or not.

Thanks for your time I appreciate it.

Br
Mans Zigher


On Wed, Apr 18, 2018, 22:47 Dennis Menschel <mensche...@posteo.de> wrote:

> Hi Mans,
>
> Am 18.04.2018 um 06:56 schrieb Måns Zigher:
> > Hi Dennis,
> >
> > This makes me a bot confused in cmake_do_configure we have
> >
> >   -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
> >   ${EXTRA_OECMAKE} \
> >   -Wno-dev
> >
> > I would think that I am using this cmake_do_configure so then the
> > -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?
> >
> > BR
> > Mans Zigher
>
> if you use "devtool build" from the extensible SDK to build a recipe
> that inherits cmake.bbclass, then the function cmake_do_configure() will
> be called implicitly.
>
> But if you manually compile a cmake project with the SDK, then that
> function won't be used. If your SDK contains the package
> nativesdk-cmake, then the SDK contains the following file:
>
>   $OECORE_NATIVE_SYSROOT/environment-setup.d/cmake.sh
>
> This file will be sourced along with the rest of the SDK and set an
> alias for cmake with an SDK-specific toolchain file.
>
> To verify if the option CMAKE_NO_SYSTEM_FROM_IMPORTED has been set by
> cmake, you can check if the file CMakeCache.txt (in the build directory)
> contains an entry for CMAKE_NO_SYSTEM_FROM_IMPORTED. An alternative way
> is to inspect the configuration via ccmake after calling cmake.
>
> Best regards,
> Dennis
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Måns Zigher]

Hi Dennis,

This makes me a bot confused in cmake_do_configure we have

  -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev

I would think that I am using this cmake_do_configure so then the
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?

BR
Mans Zigher

2018-04-17 20:31 GMT+02:00 Måns Zigher <mans.zig...@gmail.com>:

> Hi,
>
> I actually managed to locate the problem to the cmake project where it
> added include_directories(SYSTEM which then is translated into -isystem
> this call was not included when building in the SDK so that explained why
> this was only triggered when building with bitbake. Thanks for the tip I
> will try it out and see what "cmake_do_configure()" can offer.
>
> Br
> Mans Zigher
>
>
> On Tue, Apr 17, 2018, 19:57 Dennis Menschel <mensche...@posteo.de> wrote:
>
>> Hi Mans,
>>
>> Am 17.04.2018 um 13:15 schrieb Måns Zigher:
>> > Hi all,
>> >
>> > Have anyone experienced this error message before?
>> >
>> > c++/7.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or
>> > directory
>> > |  #include_next 
>> > |^~
>> >
>> > I am not seeing this error when cross compiling using the sdk. I can see
>> > in the output that the -isystem is added which when googling the error
>> > appears to be a problem when cross compiling. Since the sdk works I am
>> > guessing this flag is added by OE/poky. Any pointers on how to go
>> > forward is appreciated.
>> >
>> > BR
>> > Mans Zigher
>>
>> if I recall correctly, the problem can be circumvented by adding the
>> option "-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1" when invoking cmake.
>>
>> You can find a reference in the function "cmake_do_configure()" located
>> inside "poky/meta/classes/cmake.bbclass"
>>
>> Best regards,
>> Dennis
>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Måns Zigher]

Hi,

I actually managed to locate the problem to the cmake project where it
added include_directories(SYSTEM which then is translated into -isystem
this call was not included when building in the SDK so that explained why
this was only triggered when building with bitbake. Thanks for the tip I
will try it out and see what "cmake_do_configure()" can offer.

Br
Mans Zigher


On Tue, Apr 17, 2018, 19:57 Dennis Menschel <mensche...@posteo.de> wrote:

> Hi Mans,
>
> Am 17.04.2018 um 13:15 schrieb Måns Zigher:
> > Hi all,
> >
> > Have anyone experienced this error message before?
> >
> > c++/7.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or
> > directory
> > |  #include_next 
> > |^~
> >
> > I am not seeing this error when cross compiling using the sdk. I can see
> > in the output that the -isystem is added which when googling the error
> > appears to be a problem when cross compiling. Since the sdk works I am
> > guessing this flag is added by OE/poky. Any pointers on how to go
> > forward is appreciated.
> >
> > BR
> > Mans Zigher
>
> if I recall correctly, the problem can be circumvented by adding the
> option "-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1" when invoking cmake.
>
> You can find a reference in the function "cmake_do_configure()" located
> inside "poky/meta/classes/cmake.bbclass"
>
> Best regards,
> Dennis
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Måns Zigher]

Hi all,

Have anyone experienced this error message before?

c++/7.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
>
> |  #include_next 
>
>
>
> |^~
>
>


I am not seeing this error when cross compiling using the sdk. I can see in
the output that the -isystem is added which when googling the error appears
to be a problem when cross compiling. Since the sdk works I am guessing
this flag is added by OE/poky. Any pointers on how to go forward is
appreciated.

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

Re: [yocto] Is the a reason for adding the + to SRCPV?

[Måns Zigher]

Hi,

Thanks for your help. It is a cmake project in which they have specified a
custom command calling gdbus-codegen. It definitely looks like they are
passing the absolute path to it thanks for the help I think I can solve
that.

Br
Mans Zigher

On Apr 11, 2018 15:50, "Burton, Ross" <ross.bur...@intel.com> wrote:

There is no "dbus codegen".  dbus-glib has a code generator but that
doesn't write include guards like that, so it must be something else.
gdbus-codegen appears to be doing the right thing to unless it breaks
if you pass it an absolute path?


Ross


On 11 April 2018 at 10:12, Måns Zigher <mans.zig...@gmail.com> wrote:
> I believe dbus codegen is the tools generating the code.
>
> Br
> Mans Zigher
>
> On Tue, Apr 10, 2018, 14:44 Burton, Ross <ross.bur...@intel.com> wrote:
>>
>> What tool is generating the code?  It probably shouldn't be using the
>> full path of the header...
>>
>> Ross
>>
>> On 10 April 2018 at 09:29, Måns Zigher <mans.zig...@gmail.com> wrote:
>> > Hi,
>> >
>> > I am having some problems with one of my recipes when using the SRCPV
>> > the
>> > get_srcrev is returning "AUTOINC+" + rev. This will cause problem in my
>> > compile because I am using dbus codegen and it looks like the
>> > auto-generated
>> > code cannot handle the + sign in the paths. Is there a reason for this
+
>> > sign. The generated code that causes my build to fail looks like this
>> >
>> > #ifndef
>> >
>> >
___HOME_EXTZIG_WORKSPACE_MOZART_MOZART_WORKSPACE_BUILDS_MOZART_RASPBERRYPI_BUILD_TMP_WORK_CORTEXA7HF_NEON_VFPV4_MOZART_LINUX_GNUEABI_MOZART_DAEMON_1_0_GITAUTOINC+8FD4C803AE_R3_GIT_SRC_LIBS_MOZART_BLE_SETUP_CODEGEN_ORG_BLUEZ_LE_ADVERTISEMENT_INTERFACE_H__
>> >
>> > Currently the only way for me to get the build to work is not use the
>> > SRCPV.
>> > Could it actually be a better way then using the + sign or is there a
>> > logical requirement for it?
>> >
>> > BR
>> > Mans Zigher
>> >
>> > --
>> > ___
>> > 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] Is the a reason for adding the + to SRCPV?

[Måns Zigher]

I believe dbus codegen is the tools generating the code.

Br
Mans Zigher

On Tue, Apr 10, 2018, 14:44 Burton, Ross <ross.bur...@intel.com> wrote:

> What tool is generating the code?  It probably shouldn't be using the
> full path of the header...
>
> Ross
>
> On 10 April 2018 at 09:29, Måns Zigher <mans.zig...@gmail.com> wrote:
> > Hi,
> >
> > I am having some problems with one of my recipes when using the SRCPV the
> > get_srcrev is returning "AUTOINC+" + rev. This will cause problem in my
> > compile because I am using dbus codegen and it looks like the
> auto-generated
> > code cannot handle the + sign in the paths. Is there a reason for this +
> > sign. The generated code that causes my build to fail looks like this
> >
> > #ifndef
> >
> ___HOME_EXTZIG_WORKSPACE_MOZART_MOZART_WORKSPACE_BUILDS_MOZART_RASPBERRYPI_BUILD_TMP_WORK_CORTEXA7HF_NEON_VFPV4_MOZART_LINUX_GNUEABI_MOZART_DAEMON_1_0_GITAUTOINC+8FD4C803AE_R3_GIT_SRC_LIBS_MOZART_BLE_SETUP_CODEGEN_ORG_BLUEZ_LE_ADVERTISEMENT_INTERFACE_H__
> >
> > Currently the only way for me to get the build to work is not use the
> SRCPV.
> > Could it actually be a better way then using the + sign or is there a
> > logical requirement for it?
> >
> > BR
> > Mans Zigher
> >
> > --
> > ___
> > 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] Is the a reason for adding the + to SRCPV?

[Måns Zigher]

Hi,

I am having some problems with one of my recipes when using the SRCPV the
get_srcrev is returning "AUTOINC+" + rev. This will cause problem in my
compile because I am using dbus codegen and it looks like the
auto-generated code cannot handle the + sign in the paths. Is there a
reason for this + sign. The generated code that causes my build to fail
looks like this

#ifndef
___HOME_EXTZIG_WORKSPACE_MOZART_MOZART_WORKSPACE_BUILDS_MOZART_RASPBERRYPI_BUILD_TMP_WORK_CORTEXA7HF_NEON_VFPV4_MOZART_LINUX_GNUEABI_MOZART_DAEMON_1_0_GITAUTOINC+8FD4C803AE_R3_GIT_SRC_LIBS_MOZART_BLE_SETUP_CODEGEN_ORG_BLUEZ_LE_ADVERTISEMENT_INTERFACE_H__

Currently the only way for me to get the build to work is not use the
SRCPV. Could it actually be a better way then using the + sign or is there
a logical requirement for it?

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

[yocto] [Yocto] What is the preferred way to add build data to os-release

[Måns Zigher]

Hi,

I see a lot of systems making use of the /etc/os-release where they put in
build information like sha, build numbers and version numbers. When doing
that you will encounter basehash errors and taskhash errors from bitbake in
my experience (or I might be doing something wrong). To remove these errors
adjustments needs to be taken on the os-release recipe.  These adjustments
will likely result in re-generating rootfs everytime. Is this really what
is the preferred way of doing things? If not, what is the preferred way of
getting build data included in the os-release?

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

Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting

[Måns Zigher]

Hi,

Thanks I will do that. But I have other layers that depend on the rocko of
meta-raspberrypi so I believe I will have to use the rocko at some point
but for testing I will try Morty. What is the reason for using Morty do you
know? Is rocko unstable?

BR
Mans Zigher

2018-03-28 14:38 GMT+02:00 Sherif Omran <sherifomran2...@gmail.com>:

> Please use Morty, it works fine.
>
> On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher <mans.zig...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I am using the meta-raspberrypi layer in my build currently on the rocko
>> branch. When powering on the rpi3 Model B+ the power led turns red then
>> when the green led is turned on the red is turned off and nothing is
>> booting the green continues to flash sporadically. My build works fine on
>> rpi 3 but not on Model B+. When running raspbian on Model 3 it works fine
>> so it is not a power supply issue nor an sdcard issue. Right now I cannot
>> use the master branch of meta-raspberrypi because of some patch issues but
>> is the rocko branch not supporting rpi 3 on model B+?
>>
>> BR
>> Mans Zigher
>>
>> --
>> ___
>> 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] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting

[Måns Zigher]

Hi,

I am using the meta-raspberrypi layer in my build currently on the rocko
branch. When powering on the rpi3 Model B+ the power led turns red then
when the green led is turned on the red is turned off and nothing is
booting the green continues to flash sporadically. My build works fine on
rpi 3 but not on Model B+. When running raspbian on Model 3 it works fine
so it is not a power supply issue nor an sdcard issue. Right now I cannot
use the master branch of meta-raspberrypi because of some patch issues but
is the rocko branch not supporting rpi 3 on model B+?

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

Re: [yocto] how to add pulseaudio

[Måns Zigher]

I am no expert but basically the DISTRO_FEATURES is normally used to inform
recipes about what kind of feature you would like to have. A recipe based
on the DISTRO_FEATURES can then include take action on certain
DISTRO_FEATURES. In the yocto ref manual you can read

"In most cases, the presence or absence of a feature in DISTRO_FEATURES is
translated to the appropriate option supplied to the configure script
during the do_configure

task
for recipes that optionally support the feature"

Since pulseaudio is not by default shipped by the Yocto Project metadata I
guess you have included some other meta layer to get this feature. But to
me it looks like you have included pulseaudio in the wrong place it should
be included in the IMAGE_INSTALL_append. If supported you should include
just pulseaudio in the DISTRO_FEATURES_append if that is supported as a
DISTRO_FEATURE in your build to inform recipes about it so that if
supported the pulsaudio support is included. I suggest to try

DISTRO_FEATURES_append += " ext2 pam usbhost ${DISTRO_FEATURES_LIBC}
pulseaudio"
IMAGE_INSTALL_append += " python dbus gconf glib-2.0 pulseaudio
pulseaudio-module-dbus-protocol pulseaudio-module-bluetooth"

A DISTRO_FEATURES is not necessarily mapped to a package so based on that
the pulseaudio-module-dbus-protocol pulseaudio-module-bluetooth looks
strange to be included in the DISTRO_FEATURES_append since those looks like
packages and not a feature. Also I believe that you still need include
pulseaudio in IMAGE_INSTALL_append since it not necessarily mapped to
package but I could be wrong since bitbake and OE surprises me all the time
on what it can figure out on it's own.

BR
Mans Zigher

2018-03-26 22:17 GMT+02:00 Sherif Omran :

> hello
>
> i am trying to add pulse audio to an image but i don't get pulse audio
> being installed in the image
>
> I am using the following
> DISTRO_FEATURES_append += " ext2 pam usbhost ${DISTRO_FEATURES_LIBC}
> pulseaudio pulseaudio-module-dbus-protocol pulseaudio-module-bluetooth"
> IMAGE_INSTALL_append += " python dbus gconf glib-2.0"
>
> what am i doing wrong?
>
> --
> ___
> 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] question on how to include package to the SDK

[Måns Zigher]

Hi,

I have package that require protobuf and the compiler protoc. I have
included the following

DEPENDS += " protobuf protobuf-native"

and

RDEPENDS_${PN} += " protobuf"

The build works as intended the problem now is that the protoc is not
included in the SDK. In the Yocto ref manual I found the following
description for TOOLCHAIN_HOST_TASK

"This variable lists packages the OpenEmbedded build system uses when
building an SDK, which contains a cross-development environment. The
packages specified by this variable are part of the toolchain set that runs
on the SDKMACHINE
,
and each package should usually have the prefix nativesdk-."

So I have also in by image bb-file included the following

TOOLCHAIN_HOST_TASK += " nativesdk-protobuf"

The build passed without any errors but the protoc is still not included in
the native sdk is included in the target part. I would really appreciate if
you could en-light me on this topic on how to include a package in the sdk.

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

[yocto] do_compile, the basehash value changed from...

[Måns Zigher]

Hi,

I am seeing the following error

os-release.bb.do_compile, the basehash value changed from
b66b4812ebcc321e17478af74dc47349 to 5a21625fe0f3f42b68a1b06498b804a9. The
metadata is not deterministic and this needs to be fixed.

It appears from nowhere and I need to clean the sstate and tmp to get it to
disappear. I can build several times and then from nowhere it appears.
Where should I look to solve this? Any ideas?

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