Re: [yocto] conflicting requests error while building SDK

[ChenQi]

This is the current RDEPENDS setting in kernel-devsrc.bb recipe:

RDEPENDS_${PN} = "bc python flex bison ${TCLIBC}-utils"
# 4.15+ needs these next two RDEPENDS
RDEPENDS_${PN} += "openssl-dev util-linux"
# and x86 needs a bit more for 4.15+
RDEPENDS_${PN} += "${@bb.utils.contains('ARCH', 'x86', 'elfutils', '', d)}"

I think you need to update the RDEPENDS to "bc python flex bison 
${TCLIBC}-utils" for the sumo branch?
Could you please try it out and do some testing followed by a patch if 
all work out well?


Best Regards,
Chen Qi

On 10/18/2018 11:50 PM, Mohammad, Jamal M wrote:


Hi Guys,

I got the following conflicting requests error while building SDK

I am using sumo branch , and generic core-intel-i7-64 machine 
configuration.


Running the following command: bitbake -c populate_sdk core-image-minimal

Fails at the last step with the following error.

ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Could not invoke 
dnf. Command 
'/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/dnf 
-y -c 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux/etc/dnf/dnf.conf 
--setopt=reposdir=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux/etc/yum.repos.d 
--repofrompath=oe-repo,/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/oe-sdk-repo 
--installroot=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux 
--setopt=logdir=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/temp 
--nogpgcheck install lib32-dpkg lib32-libstdc++6 
lib32-packagegroup-core-standalone-sdk-target lib32-libx11-6 
lib32-ncurses lib32-libgcc1 lib32-libgnutls30 lib32-libfreetype6 
lib32-libc6 run-postinsts libgnutls30 dpkg kernel-devsrc 
packagegroup-core-standalone-sdk-target packagegroup-core-boot 
target-sdk-provides-dummy' returned 1:


Added oe-repo repo from 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/oe-sdk-repo


Last metadata expiration check: 0:00:02 ago on Thu 18 Oct 2018 
01:12:30 PM UTC.


Error:

 Problem: conflicting requests

  - nothing provides /usr/bin/python needed by 
kernel-devsrc-1.0-r0.intel_corei7_64


ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Function failed: 
do_populate_sdk


ERROR: Logfile of failure stored in: 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk.11307


ERROR: Task 
(/home/jamal/repotest1/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk) 
failed with exit code '1'


I found similar error in yocto mailing list, but unable to 
understand.. Can you please help me to resolve this issue.. Thanks for 
your time


https://lists.yoctoproject.org/pipermail/yocto/2018-February/039941.html

I have /usr/bin/python in my system

Thanks and Regards,

Jamal,

NCR Corporation





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

[yocto] [meta-security][PATCH] suricata: fix QA error

[Armin Kuster]

ollected errors:
 * check_data_file_clashes: Package suricata wants to install file 
.../1.0-r0/rootfs/var/run
But that file is already provided by package  * base-files

Signed-off-by: Armin Kuster 
---
 recipes-security/suricata/suricata_4.0.5.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-security/suricata/suricata_4.0.5.bb 
b/recipes-security/suricata/suricata_4.0.5.bb
index b30e9c5..90b4638 100644
--- a/recipes-security/suricata/suricata_4.0.5.bb
+++ b/recipes-security/suricata/suricata_4.0.5.bb
@@ -69,6 +69,10 @@ do_install_append () {
  -e s:/bin/kill:${base_bindir}/kill:g \
  -e s:/usr/lib:${libdir}:g \
  ${WORKDIR}/suricata.service > 
${D}${systemd_unitdir}/system/suricata.service
+
+# Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+
 }
 
 pkg_postinst_ontarget_${PN} () {
@@ -80,7 +84,7 @@ fi
 SYSTEMD_PACKAGES = "${PN}"
 
 PACKAGES =+ "${PN}-socketcontrol"
-FILES_${PN} += "${systemd_unitdir} /run"
+FILES_${PN} += "${systemd_unitdir}"
 FILES_${PN}-socketcontrol = "${bindir}/suricatasc ${PYTHON_SITEPACKAGES_DIR}"
 
 CONFFILES_${PN} = "${sysconfdir}/suricata/suricata.yaml"
-- 
2.7.4

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

Re: [yocto] modify a recipe file - proftpd

[Khem Raj]

On Thu, Oct 18, 2018 at 2:10 PM Zolee K  wrote:
>
> Hehttp://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-daemons/proftpd/proftpd_1.3.6.bb?h=master#n99llo,
>
> I'm very new to the Yocto Project and I got a Barix module that is to be 
> developped with Yocto.
> I managed to insert the desired programs into the linux image (nano, rsync, 
> mc, proftpd, vlc) by modifying a recipe file but now I'd like to make some 
> changes. I thought I would start with modifying the proftpd.conf file.
>
> As I read the manuals it is clear to me that the best way to do this to make 
> .append files.
>
> I created my own proftpd.conf file, modified it a bit, example I only renamed 
> the default server name. After that I modified the bb recipe file's sources 
> section this way:
>
> SRC_URI = "ftp://ftp.proftpd.org/distrib/source/${BPN}-${PV}.tar.gz \
> file://proftpd.conf \
> file://basic.conf.patch \
> file://proftpd-basic.init \
> file://default \
> file://close-RequireValidShell-check.patch \
> file://contrib.patch \
> file://build_fixup.patch \
> file://proftpd.service \
> "
> The red one is a new file among the other patch files however my slight 
> changes will not bitbake. The proftpd is going to be in the image, but with a 
> its default proftpd.conf file. It looks like my config file never gets 
> inserted in the target.
>
> Could you please help me out how should I start with this proftpd 
> customisation?
>

so you can have sed ops to do the needed tweaks in existing conf flile
in the bbappend e.g.
do_install_append () {

sed .
}

see here

http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-daemons/proftpd/proftpd_1.3.6.bb?h=master#n99



> Thanks,
>
> Zoli
> --
> ___
> 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] [selinux] sumo compilation

[Stefano Cappa]

Thank you

Il gio 18 ott 2018, 22:48 Sinan Kaya  ha scritto:

> On 10/18/2018 3:08 PM, Joe MacDonald wrote:
> >> Sorry, I thought it had been created.  I'm going to be traveling the
> >> next few days to ELC-E, but I will try to get to it if someone else
> >> does not first.
> > Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
> > sorted out.
>
> thanks.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] modify a recipe file - proftpd

[Zolee K]

Hello,

I'm very new to the Yocto Project and I got a Barix module that is to be
developped with Yocto.
I managed to insert the desired programs into the linux image (nano, rsync,
mc, proftpd, vlc) by modifying a recipe file but now I'd like to make some
changes. I thought I would start with modifying the proftpd.conf file.

As I read the manuals it is clear to me that the best way to do this to
make .append files.

I created my own proftpd.conf file, modified it a bit, example I only
renamed the default server name. After that I modified the bb recipe file's
sources section this way:

SRC_URI = "ftp://ftp.proftpd.org/distrib/source/${BPN}-${PV}.tar.gz \
file://proftpd.conf \
file://basic.conf.patch \
file://proftpd-basic.init \
file://default \
file://close-RequireValidShell-check.patch \
file://contrib.patch \
file://build_fixup.patch \
file://proftpd.service \
"
The red one is a new file among the other patch files however my slight
changes will not bitbake. The proftpd is going to be in the image, but with
a its default proftpd.conf file. It looks like my config file never gets
inserted in the target.

Could you please help me out how should I start with this proftpd
customisation?

Thanks,

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

Re: [yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

> Paul Eggleton  wrote on 10/18/2018 
12:30:07 PM:
>
> I think we would *like* this to be possible, from what I can tell I 
think the 
> issue is that the copies of the library in the sysroots of other 
dependent 
> recipes aren't being updated. The eSDK (and devtool) were originally 
written 
> when there weren't recipe-specific sysroots, and this stuff was a bit 
simpler.
> 
> Moving back to the full build system won't automatically fix this, 
though it 
> does make workarounds possible - you'd need to rebuild the dependent 
recipes 
> to get their sysroots updated.
> 
> Cheers,
> Paul
> ... snip ...

I put together a devtool plugin to almost do what I want:

> from devtool import exec_build_env_command, DevtoolError
> 
> def sdk_sysroot(args, config, basepath, workspace):
> """Entry point for the devtool sdk-sysroot command"""
> 
> try:
> exec_build_env_command(config.init_path, basepath, 'bitbake 
build-sysroots', watch=True)
> except bb.process.ExecutionError as e:
> raise DevtoolError('Failed to bitbake build-sysroots:\n%s' % 
(str(e)))
> 
> def register_commands(subparsers, context):
> """Register devtool subcommands from the sdk plugin"""
> if context.fixed_setup:
> parser_sdk_sysroot = subparsers.add_parser(
> 'sdk-sysroot',
> help='Update the SDK sysroot',
> description='Updates the SDK sysroot so that changes made to 
recipes in the workspace will be available,',
> group='sdk')
> parser_sdk_sysroot.set_defaults(func=sdk_sysroot)

This allows me to "devtool modify ", edit the code, 
"devtool build ", "devtool sdk-sysroot", and use the new 
code from the dependent recipe immediately.

This makes me wonder if "bitbake build-sysroots" should not be a part of 
"devtool build", like it is for "devtool sdk-install" (where I stole it 
from).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [selinux] sumo compilation

[Sinan Kaya]

On 10/18/2018 3:08 PM, Joe MacDonald wrote:

Sorry, I thought it had been created.  I'm going to be traveling the
next few days to ELC-E, but I will try to get to it if someone else
does not first.

Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
sorted out.


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

Re: [yocto] [selinux] sumo compilation

[Joe MacDonald]

[Re: [yocto] [selinux] sumo compilation] On 18.10.18 (Thu 11:00) Mark Hatle 
wrote:

> On 10/18/18 9:49 AM, Sinan Kaya wrote:
> > CC'ing the selinux maintainers:
> > 
> > I was told that using the master branch and reverting the e2fs change
> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
> >  
> > works on sumo.
> > 
> > Stefano's suggestion unfortunately didn't work.
> > 
> > Maybe, it is time to create the sumo branch?
> 
> Sorry, I thought it had been created.  I'm going to be traveling the
> next few days to ELC-E, but I will try to get to it if someone else
> does not first.

Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
sorted out.

-J.

> 
> --Mark
> 
> > On 10/18/2018 9:48 AM, Steve Scott wrote:
> >> I did not try it on sumo.
> >>
> >>   
> >>
> >> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
> >> Sent: Wednesday, October 17, 2018 11:15 PM
> >> To: ssc...@san.rr.com
> >> Cc: Sinan Kaya ; yocto@yoctoproject.org
> >> Subject: Re: [yocto] [selinux] sumo compilation
> >>
> >>   
> >>
> >> Exactly the same issue since September.
> >>
> >>   
> >>
> >> Here is my discussion 
> >> https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. 
> >> With that trick did you find a solution also on sumo?
> >>
> >>   
> >>
> >> Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > 
> >> ha scritto:
> >>
> >>
> >> It was broken in rocko too. I added this to local.conf to workaround the 
> >> problem:
> >>
> >> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> >>
> >> -steve
> >>
> >>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
> >>> Hi,
> >>>
> >>> We realized today that SELinux does not compile on sumo branch.
> >>>
> >>> Is it possible for someone to branch the last working version to a sumo 
> >>> branch?
> >>>
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> >>>
> >>> NOTE: Running task 352 of 2707
> >>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
> >>>   :do_patch)
> >>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> >>> NOTE: Running task 1413 of 2707
> >>> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
> >>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> >>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt 
> >>> --quiltrc
> >>> Applying patch misc_create_inode.c-label_rootfs.patch
> >>> patching file misc/create_inode.c
> >>> Hunk #1 FAILED at 979.
> >>> Hunk #2 FAILED at 987.
> >>>
> >>> Sinan
> >>> -- 
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org 
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>
> > 
> 


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

> Alexander Kanavin  wrote on 10/18/2018 11:30:17 
AM:
>
> I don’t think esdk is designed for this kind of ‘full stack’ 
> development. You can go back to working directly with yocto layers, 
> and skip the esdk altogether. Devtool will work exactly same (minus 
> the sdk specific commands).
> 
> Alex

I'm trying to get the developers away from using bitbake and devtool to 
build their code, as those tools have overhead and don't easily allow the 
developers to iterate quickly or allow them to run other make targets for 
unit testing, etc. I really want the developers at the "make" level for 
the majority of their time. When it comes time for recipes and image 
creation, then they'll use devtool.

> > On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
> > 
> > My team recently started using the eSDK for day-to-day development. 
> > Previously, they were using the bitbake command to build, which works, 
but 
> > has overhead. Yesterday three different people came up to me a 
question 
> > about workflow with the eSDK, and they all had to do with dependent 
> > recipes in the eSDK.
> > 
> > For example, a developer would sit down to make something new that 
relies 
> > on a library provided by a recipe in the eSDK. So they "devtool 
> > sdk-install needed-library", and get to work. While working, they 
> > discover, I need to add something to this library I depend on so that 
it 
> > does what I want in the way I want. So they "devtool modify 
> > needed-library" and change the source of that library to do what they 
> > want, and build that library using its build system (CMake or 
Autotools). 
> > Then they return to working on the new something and find that none of 

> > their changes to the library they depend on are available. 
> > 
> > At this point, they are lost. They just start trying things to make it 

> > work, like "devtool build needed-library", which successfully 
completes, 
> > but doesn't help. Some people also try to use the build system of the 
> > library they modified to install it into the machine sysroot of the 
eSDK 
> > with a command like, "make install 
> > DESTDIR=/tmp/sysroots/", and that actually does 
help. 
> > They can now use the changes they made to the library in the new 
something 
> > they are working on. However, when they use the "devtool sdk-install" 
> > command again, their changes to the needed library that they installed 

> > into the machine sysroot are reverted.
> > 
> > So--what is the workflow they are supposed to use? 
> > 
> > Pushing the changes to the library upstream, updating the recipe, and 
> > waiting for a new eSDK is not practical given that the developers may 
have 
> > to iterate on the changes to the library quite a bit before they get 
it 
> > just right for their new something.
> > 
> > Is there a way to update the eSDK sysroots with recipes that are in 
the 
> > workspace? Could "devtool build" also update the eSDK sysroots? Or is 
> > there a different way to get this done?
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://urldefense.proofpoint.com/v2/url?
> u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwIFaQ=-
> _uRSsrpJskZgEkGwdW-
> sXvhn_FXVaEGsm0EI46qilk=GBJubmJUwwrr1B4TJFRqESMrRsDipvY66vPwm4-
> gtNQ=-
> 
C-70rjnGksaogzIkgE5MdoY3IfA3x62MZVOwbZmw4c=T5PxZ3bNB429M76sWwBqgrtMsMhB-
> kz1BXkdY8hOIRY=

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

Re: [yocto] Working on Dependent Recipes in eSDK

[Paul Eggleton]

I think we would *like* this to be possible, from what I can tell I think the 
issue is that the copies of the library in the sysroots of other dependent 
recipes aren't being updated. The eSDK (and devtool) were originally written 
when there weren't recipe-specific sysroots, and this stuff was a bit simpler.

Moving back to the full build system won't automatically fix this, though it 
does make workarounds possible - you'd need to rebuild the dependent recipes 
to get their sysroots updated.

Cheers,
Paul

On Friday, 19 October 2018 7:30:17 AM NZDT Alexander Kanavin wrote:
> I don’t think esdk is designed for this kind of ‘full stack’ development.
> You can go back to working directly with yocto layers, and skip the esdk
> altogether. Devtool will work exactly same (minus the sdk specific
> commands).
> 
> Alex
> 
> > On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
> > 
> > My team recently started using the eSDK for day-to-day development. 
> > Previously, they were using the bitbake command to build, which works, but 
> > has overhead. Yesterday three different people came up to me a question 
> > about workflow with the eSDK, and they all had to do with dependent 
> > recipes in the eSDK.
> > 
> > For example, a developer would sit down to make something new that relies 
> > on a library provided by a recipe in the eSDK. So they "devtool 
> > sdk-install needed-library", and get to work. While working, they 
> > discover, I need to add something to this library I depend on so that it 
> > does what I want in the way I want. So they "devtool modify 
> > needed-library" and change the source of that library to do what they 
> > want, and build that library using its build system (CMake or Autotools). 
> > Then they return to working on the new something and find that none of 
> > their changes to the library they depend on are available. 
> > 
> > At this point, they are lost. They just start trying things to make it 
> > work, like "devtool build needed-library", which successfully completes, 
> > but doesn't help. Some people also try to use the build system of the 
> > library they modified to install it into the machine sysroot of the eSDK 
> > with a command like, "make install 
> > DESTDIR=/tmp/sysroots/", and that actually does help. 
> > They can now use the changes they made to the library in the new something 
> > they are working on. However, when they use the "devtool sdk-install" 
> > command again, their changes to the needed library that they installed 
> > into the machine sysroot are reverted.
> > 
> > So--what is the workflow they are supposed to use? 
> > 
> > Pushing the changes to the library upstream, updating the recipe, and 
> > waiting for a new eSDK is not practical given that the developers may have 
> > to iterate on the changes to the library quite a bit before they get it 
> > just right for their new something.
> > 
> > Is there a way to update the eSDK sysroots with recipes that are in the 
> > workspace? Could "devtool build" also update the eSDK sysroots? Or is 
> > there a different way to get this done?
> 


-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] Working on Dependent Recipes in eSDK

[Alexander Kanavin]

I don’t think esdk is designed for this kind of ‘full stack’ development. You 
can go back to working directly with yocto layers, and skip the esdk 
altogether. Devtool will work exactly same (minus the sdk specific commands).

Alex

> On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
> 
> My team recently started using the eSDK for day-to-day development. 
> Previously, they were using the bitbake command to build, which works, but 
> has overhead. Yesterday three different people came up to me a question 
> about workflow with the eSDK, and they all had to do with dependent 
> recipes in the eSDK.
> 
> For example, a developer would sit down to make something new that relies 
> on a library provided by a recipe in the eSDK. So they "devtool 
> sdk-install needed-library", and get to work. While working, they 
> discover, I need to add something to this library I depend on so that it 
> does what I want in the way I want. So they "devtool modify 
> needed-library" and change the source of that library to do what they 
> want, and build that library using its build system (CMake or Autotools). 
> Then they return to working on the new something and find that none of 
> their changes to the library they depend on are available. 
> 
> At this point, they are lost. They just start trying things to make it 
> work, like "devtool build needed-library", which successfully completes, 
> but doesn't help. Some people also try to use the build system of the 
> library they modified to install it into the machine sysroot of the eSDK 
> with a command like, "make install 
> DESTDIR=/tmp/sysroots/", and that actually does help. 
> They can now use the changes they made to the library in the new something 
> they are working on. However, when they use the "devtool sdk-install" 
> command again, their changes to the needed library that they installed 
> into the machine sysroot are reverted.
> 
> So--what is the workflow they are supposed to use? 
> 
> Pushing the changes to the library upstream, updating the recipe, and 
> waiting for a new eSDK is not practical given that the developers may have 
> to iterate on the changes to the library quite a bit before they get it 
> just right for their new something.
> 
> Is there a way to update the eSDK sysroots with recipes that are in the 
> workspace? Could "devtool build" also update the eSDK sysroots? Or is 
> there a different way to get this done?
> -- 
> ___
> 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] Working on Dependent Recipes in eSDK

[Aaron_Wright]

My team recently started using the eSDK for day-to-day development. 
Previously, they were using the bitbake command to build, which works, but 
has overhead. Yesterday three different people came up to me a question 
about workflow with the eSDK, and they all had to do with dependent 
recipes in the eSDK.

For example, a developer would sit down to make something new that relies 
on a library provided by a recipe in the eSDK. So they "devtool 
sdk-install needed-library", and get to work. While working, they 
discover, I need to add something to this library I depend on so that it 
does what I want in the way I want. So they "devtool modify 
needed-library" and change the source of that library to do what they 
want, and build that library using its build system (CMake or Autotools). 
Then they return to working on the new something and find that none of 
their changes to the library they depend on are available. 

At this point, they are lost. They just start trying things to make it 
work, like "devtool build needed-library", which successfully completes, 
but doesn't help. Some people also try to use the build system of the 
library they modified to install it into the machine sysroot of the eSDK 
with a command like, "make install 
DESTDIR=/tmp/sysroots/", and that actually does help. 
They can now use the changes they made to the library in the new something 
they are working on. However, when they use the "devtool sdk-install" 
command again, their changes to the needed library that they installed 
into the machine sysroot are reverted.

So--what is the workflow they are supposed to use? 

Pushing the changes to the library upstream, updating the recipe, and 
waiting for a new eSDK is not practical given that the developers may have 
to iterate on the changes to the library quite a bit before they get it 
just right for their new something.

Is there a way to update the eSDK sysroots with recipes that are in the 
workspace? Could "devtool build" also update the eSDK sysroots? Or is 
there a different way to get this done?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] conflicting requests error while building SDK

[Mohammad, Jamal M]

Hi Guys,

I got the following conflicting requests error while building SDK

I am using sumo branch , and generic core-intel-i7-64 machine configuration.

Running the following command: bitbake -c populate_sdk core-image-minimal

Fails at the last step with the following error.

ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Could not invoke dnf. Command 
'/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/dnf
 -y -c 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux/etc/dnf/dnf.conf
 
--setopt=reposdir=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux/etc/yum.repos.d
 
--repofrompath=oe-repo,/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/oe-sdk-repo
 
--installroot=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/2.5/sysroots/corei7-64-poky-linux
 
--setopt=logdir=/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/temp
 --nogpgcheck install lib32-dpkg lib32-libstdc++6 
lib32-packagegroup-core-standalone-sdk-target lib32-libx11-6 lib32-ncurses 
lib32-libgcc1 lib32-libgnutls30 lib32-libfreetype6 lib32-libc6 run-postinsts 
libgnutls30 dpkg kernel-devsrc packagegroup-core-standalone-sdk-target 
packagegroup-core-boot target-sdk-provides-dummy' returned 1:
Added oe-repo repo from 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/oe-sdk-repo
Last metadata expiration check: 0:00:02 ago on Thu 18 Oct 2018 01:12:30 PM UTC.
Error:
 Problem: conflicting requests
  - nothing provides /usr/bin/python needed by 
kernel-devsrc-1.0-r0.intel_corei7_64

ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Function failed: 
do_populate_sdk
ERROR: Logfile of failure stored in: 
/home/jamal/repotest1/yocto_intel_build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk.11307
ERROR: Task 
(/home/jamal/repotest1/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk)
 failed with exit code '1'

I found similar error in yocto mailing list, but unable to understand.. Can you 
please help me to resolve this issue.. Thanks for your time


https://lists.yoctoproject.org/pipermail/yocto/2018-February/039941.html



I have /usr/bin/python in my system
Thanks and Regards,
Jamal,
NCR Corporation

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

Re: [yocto] [selinux] sumo compilation

[Sinan Kaya]

Thanks Steve,

We'll give it a try.

On 10/18/2018 11:46 AM, Steve Scott wrote:

You may also need
 PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-standard"
in local.conf.

-steve


-Original Message-
From: Sinan Kaya [mailto:ok...@kernel.org]
Sent: Thursday, October 18, 2018 8:06 AM
To: ssc...@san.rr.com; 'Stefano Cappa' 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation

Sorry for confusing names, not enough coffee yet...

I was trying to say that Steve's suggestion to use

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

didn't work on sumo branch.

On 10/18/2018 10:49 AM, Sinan Kaya wrote:

CC'ing the selinux maintainers:

I was told that using the master branch and reverting the e2fs change
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78e
ca8242ea5397c4dc0654d62244453b4260151)
works on sumo.

Stefano's suggestion unfortunately didn't work.

Maybe, it is time to create the sumo branch?

On 10/18/2018 9:48 AM, Steve Scott wrote:

I did not try it on sumo.


From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation


Exactly the same issue since September.


Here is my discussion
https://lists.yoctoproject.org/pipermail/yocto/2018-

September/042711.html.

With that trick did you find a solution also on sumo?


Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha
scritto:


It was broken in rocko too. I added this to local.conf to workaround the

problem:


PREFERRED_VERSION_refpolicy-standard = "2.20170204"

-steve

 Sinan Kaya mailto:ok...@kernel.org> > wrote:

Hi,

We realized today that SELinux does not compile on sumo branch.

Is it possible for someone to branch the last working version to a sumo

branch?


http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/

NOTE: Running task 352 of 2707
(virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fspr
ogs_1.43.8.bb  :do_patch)
NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
NOTE: Running task 1413 of 2707
(/sources/poky/meta/recipes-

devtools/e2fsprogs/e2fsprogs_1.43.8.bb:d

o_patch)
NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt
--quiltrc Applying patch misc_create_inode.c-label_rootfs.patch
patching file misc/create_inode.c
Hunk #1 FAILED at 979.
Hunk #2 FAILED at 987.

Sinan
--
___
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] [selinux] sumo compilation

[Mark Hatle]

On 10/18/18 9:49 AM, Sinan Kaya wrote:
> CC'ing the selinux maintainers:
> 
> I was told that using the master branch and reverting the e2fs change
> (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
>  
> works on sumo.
> 
> Stefano's suggestion unfortunately didn't work.
> 
> Maybe, it is time to create the sumo branch?

Sorry, I thought it had been created.  I'm going to be traveling the next few
days to ELC-E, but I will try to get to it if someone else does not first.

--Mark

> On 10/18/2018 9:48 AM, Steve Scott wrote:
>> I did not try it on sumo.
>>
>>   
>>
>> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
>> Sent: Wednesday, October 17, 2018 11:15 PM
>> To: ssc...@san.rr.com
>> Cc: Sinan Kaya ; yocto@yoctoproject.org
>> Subject: Re: [yocto] [selinux] sumo compilation
>>
>>   
>>
>> Exactly the same issue since September.
>>
>>   
>>
>> Here is my discussion 
>> https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. 
>> With that trick did you find a solution also on sumo?
>>
>>   
>>
>> Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha 
>> scritto:
>>
>>
>> It was broken in rocko too. I added this to local.conf to workaround the 
>> problem:
>>
>> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
>>
>> -steve
>>
>>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
>>> Hi,
>>>
>>> We realized today that SELinux does not compile on sumo branch.
>>>
>>> Is it possible for someone to branch the last working version to a sumo 
>>> branch?
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
>>>
>>> NOTE: Running task 352 of 2707
>>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
>>>   :do_patch)
>>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
>>> NOTE: Running task 1413 of 2707
>>> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
>>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
>>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
>>> Applying patch misc_create_inode.c-label_rootfs.patch
>>> patching file misc/create_inode.c
>>> Hunk #1 FAILED at 979.
>>> Hunk #2 FAILED at 987.
>>>
>>> Sinan
>>> -- 
>>> ___
>>> 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] Busybox_1.23.2 fails at do_compile on Poky-Sumo

[Khem Raj]

Always send the Build Configuration that bitbake prints on top of
build. So someone can get some additional information about your build
to help you better.
On Thu, Oct 18, 2018 at 1:03 AM Dhanush K.S  wrote:
>
> Hello Yocto,
>
> I'm currently building an image with the busybox_1.23.2.bb recipe included, 
> using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a 
> CentOS host building images for the target ARM cortexa8. This busybox recipe 
> is placed in another custom layer. Though this recipe compiles without errors 
> in Poky-Fido, in Poky-Sumo I get compilation errors due to missing header 
> files. I have pasted a part of the log.do.compile file with the error.
>
> # merged configuration written to .config (needs make)
> #
> NOTE: make -j 2 LD=arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon 
> -mfloat-abi=hard -mcpu=cortex-a8 
> --sysroot=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/recipe-sysroot
>  V=1 ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- SKIP_STRIP=y 
> busybox_unstripped
> rm -f .kernelrelease
> echo 1.23.2 > .kernelrelease
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/gen_build_files.sh
>  
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
>  
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
> make -f 
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/Makefile
>  silentoldconfig
> make -f scripts/Makefile.build obj=scripts/basic
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/gen_build_files.sh
>  
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
>  
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
> mkdir -p include
> make -f scripts/Makefile.build obj=scripts/kconfig silentoldconfig
> scripts/kconfig/conf -s Config.in
> #
> # using defaults found in .config
> #
> make -C 
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
>  KBUILD_SRC= .kernelrelease
> rm -f .kernelrelease
> echo 1.23.2 > .kernelrelease
> make -f scripts/Makefile.build obj=scripts/basic
> make -f scripts/Makefile.build obj=applets
>   scripts/basic/split-include include/autoconf.h include/config
>   gcc -Wp,-MD,applets/.usage.d  -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer  -Iinclude -Iinclude -o applets/usage applets/usage.c
>   gcc -Wp,-MD,applets/.applet_tables.d  -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer   -o applets/applet_tables applets/applet_tables.c
>   
> /opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/mkconfigs
>  include/bbconfigopts.h include/bbconfigopts_bz2.h
> make -f scripts/Makefile.build obj=scripts
>   applets/usage_compressed include/usage_compressed.h applets
>   applets/applet_tables include/applet_tables.h include/NUM_APPLETS.h
>   gcc -Wp,-MD,applets/.usage_pod.d  -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer  -Iinclude -Iinclude -o applets/usage_pod 
> applets/usage_pod.c
>   arm-poky-linux-gnueabi-gcc -Wp,-MD,applets/.applets.o.d   -std=gnu99 
> -Iinclude -Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG 
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
> -D"BB_VER=KBUILD_STR(1.23.2)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wshadow 
> -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter 
> -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations 
> -Wno-format-security -Wdeclaration-after-statement -Wold-style-definition 
> -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections 
> -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc 
> -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 
> -fno-unwind-tables -fno-asynchronous-unwind-tables -Os -O2 -pipe -g 
> -feliminate-unused-debug-types 
> -fdebug-prefix-map=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0=/usr/src/debug/busybox/1.23.2-r0
>  
> 

Re: [yocto] [selinux] sumo compilation

[Steve Scott]

You may also need
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-standard"
in local.conf. 

-steve

> -Original Message-
> From: Sinan Kaya [mailto:ok...@kernel.org]
> Sent: Thursday, October 18, 2018 8:06 AM
> To: ssc...@san.rr.com; 'Stefano Cappa' 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] [selinux] sumo compilation
> 
> Sorry for confusing names, not enough coffee yet...
> 
> I was trying to say that Steve's suggestion to use
> 
> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> 
> didn't work on sumo branch.
> 
> On 10/18/2018 10:49 AM, Sinan Kaya wrote:
> > CC'ing the selinux maintainers:
> >
> > I was told that using the master branch and reverting the e2fs change
> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78e
> > ca8242ea5397c4dc0654d62244453b4260151)
> > works on sumo.
> >
> > Stefano's suggestion unfortunately didn't work.
> >
> > Maybe, it is time to create the sumo branch?
> >
> > On 10/18/2018 9:48 AM, Steve Scott wrote:
> >> I did not try it on sumo.
> >>
> >>
> >> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
> >> Sent: Wednesday, October 17, 2018 11:15 PM
> >> To: ssc...@san.rr.com
> >> Cc: Sinan Kaya ; yocto@yoctoproject.org
> >> Subject: Re: [yocto] [selinux] sumo compilation
> >>
> >>
> >> Exactly the same issue since September.
> >>
> >>
> >> Here is my discussion
> >> https://lists.yoctoproject.org/pipermail/yocto/2018-
> September/042711.html.
> >> With that trick did you find a solution also on sumo?
> >>
> >>
> >> Il gio 18 ott 2018, 01:42  >>  > ha
> >> scritto:
> >>
> >>
> >> It was broken in rocko too. I added this to local.conf to workaround the
> problem:
> >>
> >> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> >>
> >> -steve
> >>
> >>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
> >>> Hi,
> >>>
> >>> We realized today that SELinux does not compile on sumo branch.
> >>>
> >>> Is it possible for someone to branch the last working version to a sumo
> branch?
> >>>
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> >>>
> >>> NOTE: Running task 352 of 2707
> >>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fspr
> >>> ogs_1.43.8.bb  :do_patch)
> >>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> >>> NOTE: Running task 1413 of 2707
> >>> (/sources/poky/meta/recipes-
> devtools/e2fsprogs/e2fsprogs_1.43.8.bb:d
> >>> o_patch)
> >>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> >>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt
> >>> --quiltrc Applying patch misc_create_inode.c-label_rootfs.patch
> >>> patching file misc/create_inode.c
> >>> Hunk #1 FAILED at 979.
> >>> Hunk #2 FAILED at 987.
> >>>
> >>> Sinan
> >>> --
> >>> ___
> >>> 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] [meta-virtualization][PATCH] libvirt: remove qemu from PACKAGECONFIG for mips n32 and n64

[Bruce Ashfield]

Wrong mailing list. Use meta-virtualization for these patches.

I'm cross posting this there, for the archives.

I've grabbed and merged this change (but could easily have missed
it, since it was the wrong list and I wasn't directly copied).

Bruce

On 10/15/18 9:45 PM, kai.k...@windriver.com wrote:

From: Kai Kang 

PACKAGECONFIG 'qemu' causes libvirt depends on package qemu. But qemu
is not compatible with mips n32 and n64. So remove 'qemu' from
PACKAGECONFIG for mips n32 and n64.

Signed-off-by: Kai Kang 
Signed-off-by: Mark Hatle 
---
  recipes-extended/libvirt/libvirt_4.7.0.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/recipes-extended/libvirt/libvirt_4.7.0.bb 
b/recipes-extended/libvirt/libvirt_4.7.0.bb
index 47275ae..a1175f5 100644
--- a/recipes-extended/libvirt/libvirt_4.7.0.bb
+++ b/recipes-extended/libvirt/libvirt_4.7.0.bb
@@ -186,6 +186,10 @@ PACKAGECONFIG ??= "qemu yajl uml openvz vmware vbox esx 
iproute2 lxc test \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'polkit', 
'', d)} \
"
  
+# qemu is NOT compatible with mips64

+PACKAGECONFIG_remove_mipsarchn32 = "qemu"
+PACKAGECONFIG_remove_mipsarchn64 = "qemu"
+
  # enable,disable,depends,rdepends
  #
  PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"



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

Re: [yocto] [selinux] sumo compilation

[Sinan Kaya]

Sorry for confusing names, not enough coffee yet...

I was trying to say that Steve's suggestion to use

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

didn't work on sumo branch.

On 10/18/2018 10:49 AM, Sinan Kaya wrote:

CC'ing the selinux maintainers:

I was told that using the master branch and reverting the e2fs change
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151) 
works on sumo.


Stefano's suggestion unfortunately didn't work.

Maybe, it is time to create the sumo branch?

On 10/18/2018 9:48 AM, Steve Scott wrote:

I did not try it on sumo.


From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation


Exactly the same issue since September.


Here is my discussion 
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. 
With that trick did you find a solution also on sumo?



Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha 
scritto:



It was broken in rocko too. I added this to local.conf to workaround the 
problem:

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

-steve

 Sinan Kaya mailto:ok...@kernel.org> > wrote:

Hi,

We realized today that SELinux does not compile on sumo branch.

Is it possible for someone to branch the last working version to a sumo branch?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/

NOTE: Running task 352 of 2707
(virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb 
 :do_patch)

NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
NOTE: Running task 1413 of 2707
(/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
Applying patch misc_create_inode.c-label_rootfs.patch
patching file misc/create_inode.c
Hunk #1 FAILED at 979.
Hunk #2 FAILED at 987.

Sinan
--
___
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] [selinux] sumo compilation

[Sinan Kaya]

CC'ing the selinux maintainers:

I was told that using the master branch and reverting the e2fs change
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151) 
works on sumo.


Stefano's suggestion unfortunately didn't work.

Maybe, it is time to create the sumo branch?

On 10/18/2018 9:48 AM, Steve Scott wrote:

I did not try it on sumo.

  


From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation

  


Exactly the same issue since September.

  


Here is my discussion 
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. With 
that trick did you find a solution also on sumo?

  


Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha 
scritto:


It was broken in rocko too. I added this to local.conf to workaround the 
problem:

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

-steve

 Sinan Kaya mailto:ok...@kernel.org> > wrote:

Hi,

We realized today that SELinux does not compile on sumo branch.

Is it possible for someone to branch the last working version to a sumo branch?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/

NOTE: Running task 352 of 2707
(virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb 
 :do_patch)
NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
NOTE: Running task 1413 of 2707
(/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
Applying patch misc_create_inode.c-label_rootfs.patch
patching file misc/create_inode.c
Hunk #1 FAILED at 979.
Hunk #2 FAILED at 987.

Sinan
--
___
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] [selinux] sumo compilation

[Steve Scott]

I did not try it on sumo. 

 

From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com] 
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation

 

Exactly the same issue since September. 

 

Here is my discussion 
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. With 
that trick did you find a solution also on sumo? 

 

Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha 
scritto:


It was broken in rocko too. I added this to local.conf to workaround the 
problem:

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

-steve

 Sinan Kaya mailto:ok...@kernel.org> > wrote: 
> Hi,
> 
> We realized today that SELinux does not compile on sumo branch.
> 
> Is it possible for someone to branch the last working version to a sumo 
> branch?
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> 
> NOTE: Running task 352 of 2707 
> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
>   :do_patch)
> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> NOTE: Running task 1413 of 2707 
> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
> Applying patch misc_create_inode.c-label_rootfs.patch
> patching file misc/create_inode.c
> Hunk #1 FAILED at 979.
> Hunk #2 FAILED at 987.
> 
> Sinan
> -- 
> ___
> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [linux-yocto/linux-yocto-dev 4.18][PATCH] perf arm64: Fix generate system call table failed with /tmp mounted with noexec

[Hongxu Jia]

On 2018年10月18日 21:20, Bruce Ashfield wrote:

I tried to apply this to 4.18, but the commit which creates
the issue is only in 4.19+

commit 2b5882435606c209ebc052230f03505ea477a252
Author: Kim Phillips 
Date:   Fri Jul 6 16:34:43 2018 -0500

    perf arm64: Generate system call table from asm/unistd.h


% git tag --contains 2b5882435606c209ebc052230f03505ea477a252
v4.19-rc1
v4.19-rc2
v4.19-rc3
v4.19-rc4
v4.19-rc5
v4.19-rc6
v4.19-rc7
v4.19-rc8

So I'll merge this to linux-yocto-dev, but the other linux-yocto
variants should be unaffected.



Got it, thanks for the affected check, and I've submitted the fix to 
upstream

mailing list linux-perf-us...@vger.kernel.org

//Hongxu


Bruce

On 10/18/18 5:12 AM, Hongxu Jia wrote:

Which /tmp mounted with noexec, generate system call table failed.
[snip]
|perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl:
/tmp/create-table-6VGPSt: Permission denied
[snip]

Add variable TMPDIR as prefix dir of the temporary file, if it is set,
replace default /tmp

Fixes: 2b5882435606 ("perf arm64: Generate system call table from 
asm/unistd.h")


Signed-off-by: Hongxu Jia 
---
  tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl 
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl

index 2dbb8cad..c88fd32 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -23,7 +23,7 @@ create_table_from_c()
  {
  local sc nr last_sc
  -    create_table_exe=`mktemp /tmp/create-table-XX`
+    create_table_exe=`mktemp ${TMPDIR:-/tmp}/create-table-XX`
    {






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

Re: [linux-yocto] [linux-yocto/linux-yocto-dev 4.18][PATCH] perf arm64: Fix generate system call table failed with /tmp mounted with noexec

[Bruce Ashfield]

I tried to apply this to 4.18, but the commit which creates
the issue is only in 4.19+

commit 2b5882435606c209ebc052230f03505ea477a252
Author: Kim Phillips 
Date:   Fri Jul 6 16:34:43 2018 -0500

perf arm64: Generate system call table from asm/unistd.h


% git tag --contains 2b5882435606c209ebc052230f03505ea477a252
v4.19-rc1
v4.19-rc2
v4.19-rc3
v4.19-rc4
v4.19-rc5
v4.19-rc6
v4.19-rc7
v4.19-rc8

So I'll merge this to linux-yocto-dev, but the other linux-yocto
variants should be unaffected.

Bruce

On 10/18/18 5:12 AM, Hongxu Jia wrote:

Which /tmp mounted with noexec, generate system call table failed.
[snip]
|perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl:
/tmp/create-table-6VGPSt: Permission denied
[snip]

Add variable TMPDIR as prefix dir of the temporary file, if it is set,
replace default /tmp

Fixes: 2b5882435606 ("perf arm64: Generate system call table from asm/unistd.h")

Signed-off-by: Hongxu Jia 
---
  tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl 
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index 2dbb8cad..c88fd32 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -23,7 +23,7 @@ create_table_from_c()
  {
local sc nr last_sc
  
-	create_table_exe=`mktemp /tmp/create-table-XX`

+   create_table_exe=`mktemp ${TMPDIR:-/tmp}/create-table-XX`
  
  	{
  



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

Re: [yocto] Sumo distro problem with dhcp packet?

[Zoran Stojsavljevic]

Hello Kosta,

> I suggest trying other reference image.
> For example, core-image-minimal.

As said, I have tried instead core-image-base ==>> core-image-minimal
one on the target platform, which is BBB. To my surprise it is in
there (in the minimal initramfs)!

Since the eth0 IP address upon sumo booting is all wrong, I have
tested the BBB dhclient command as:
# ifconfig eth0 down
# dhclient eth0 -v

And it works perfectly, brings eth0 up, sets the correct IP address,
and then goes for lease with dhcpd on the another side.

So, what is here catch 22 (why base image does not have dhclient, and
minimal does)?

Thank you,
Zoran
___
On Wed, Oct 17, 2018 at 10:44 AM Kosta Zertsekel
 wrote:
>
> I suggest trying other reference image.
>
> For example, core-image-minimal.
>
> If it does not help, then core-image-full-cmdline.
>
> Let's get the working reference first with one of these images.
>
>
> --- Kosta Z.
>
> 
> From: Zoran Stojsavljevic 
> Sent: Wednesday, 17 October 2018 11:37:38
> To: Kosta Zertsekel; Yocto Project
> Subject: Re: [yocto] Sumo distro problem with dhcp packet?
>
> Hello Kosta and others,
>
> I am a bit behind on a schedule on this one. Albeit I followed the
> advise, This does work for compiling and adding all these packages to
> the ROOTFS. I see that after I added all them, I see the
> initramfs.tar.xz expanded in
> ...poky/build/tmp/deploy/image/beagleboneblack/ directory.
>
> But after I do the testing with initramfs, with all these packages
> added. I do not find anything in the ROOTFS even what it should be
> lookalike DHCP.
>
> After trying # which dhclient, or # which dhcp-client, or # which
> dhcp... It finds nothing!
>
> Then, the next step was to find /etc/dhcp/ or similar. There is
> nothing lookalike dhcp/ or dhcp* in /etc, which shows that these lines
> in dhcp.inc recipe are not executed:
>
> do_install_append () {
>install -d ${D}${sysconfdir}/init.d
>install -d ${D}${sysconfdir}/default
>install -d ${D}${sysconfdir}/dhcp
>install -m 0755 ${WORKDIR}/init-relay 
> ${D}${sysconfdir}/init.d/dhcp-relay
>install -m 0644 ${WORKDIR}/default-relay
> ${D}${sysconfdir}/default/dhcp-relay
>install -m 0755 ${WORKDIR}/init-server
> ${D}${sysconfdir}/init.d/dhcp-server
>install -m 0644 ${WORKDIR}/default-server
> ${D}${sysconfdir}/default/dhcp-server
>
>rm -f ${D}${sysconfdir}/dhclient.conf*
>rm -f ${D}${sysconfdir}/dhcpd.conf*
>
> In addition, when I execute: $ bitbake -c cleanall dhcp, it says that
> it executes thee tasks, and none of them are actually executed (0
> executed).
>
> I also recompiled form scratch the whole sumo BBB build, but this did
> NOT solve the problem.
>
> Any hint how I should proceed?
>
> Thank you,
> Zoran
> ___
>
> On Thu, Oct 11, 2018 at 1:40 PM Zoran Stojsavljevic
>  wrote:
> >
> > Hello Kosta,
> >
> > > For example, you can do the below:
> > > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server 
> > > cmake... "
> >
> > I added to this example dhcp-relay, just to test the whole build, and
> > it does work. Actually, I need only dhcp-client for the target (since
> > I have dhcp-server on the ETH interface on the opposite (VM) side).
> >
> > Thank you for the help!
> > Zoran
> > ___
> > On Wed, Oct 10, 2018 at 5:57 PM Kosta Zertsekel
> >  wrote:
> > >
> > > You need to take a look at the available dhcp packages
> > > for dhcp recipe here:
> > > https://git.yoctoproject.org/clean/cgit.cgi/poky/tree/meta/recipes-connectivity/dhcp/dhcp.inc#n100
> > >
> > > PACKAGES += "dhcp-libs dhcp-server dhcp-server-config dhcp-client 
> > > dhcp-relay dhcp-omshell"
> > >
> > > For example, you can do the below:
> > > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp-client dhcp-server 
> > > cmake... "
> > >
> > > Thanks,
> > > --- Kosta Z
> > > 
> > > From: yocto-boun...@yoctoproject.org  on 
> > > behalf of Zoran Stojsavljevic 
> > > Sent: Wednesday, 10 October 2018 16:29:05
> > > To: Yocto Project
> > > Subject: [yocto] Sumo distro problem with dhcp packet?
> > >
> > > Hello.
> > >
> > > I need on my test initramfs YOCTO image to add dhcp package (both dhcp 
> > > server and client).
> > >
> > > For the beginning, I traced it, where it is:
> > > .../poky/meta/recipes-connectivity/dchp
> > >
> > > and decided to test it adding it to ...poky/build/conf/local.conf for the 
> > > starters:
> > > CORE_IMAGE_EXTRA_INSTALL_append = "openssh dhcp cmake... "
> > >
> > > But it produced the following error:
> > > [user@fedora28-ssd conf]$ bitbake -k core-image-base
> > >
> > >[snap]
> > >
> > > ERROR: Nothing RPROVIDES 'dhcp' (but 
> > > /home/user/projects2/beaglebone-black/sumo/poky/meta/recipes-core/images/core-image-base.bb
> > >  RDEPENDS on or otherwise requires it)
> > > NOTE: Runtime target 'dhcp' is unbuildable, removing...
> > > Missing or unbuildable dependency chain was: ['dhcp']
> > > ERROR: Nothing 

Re: [yocto] archiver.bbclass: do_dumpdata - shell format

[Tomasz Dziendzielski]

>I suspect the proper solution is to treat the -e output as shell-like
>From the bitbake/lib/bb/data.py:
"""Emits all items in the data store in a format such that it can be
sourced by a shell."""
so if you say it's shell-like, not shell, shouldn't we replace that to
"""Emits all items in the data store in a shell-like format"""?
If it cannot be sourced the statement "can be sourced by a shell" should be
removed.

>parse it with a proper parser.
So is there any proper parser to source this?

Best regards,
Tomasz Dziendzielski

czw., 18 paź 2018 o 11:51 Burton, Ross  napisał(a):

> Well, as you've discovered, bitbake variables can have names that are
> invalid in shell.  I suspect the proper solution is to treat the -e
> output as shell-like, and parse it with a proper parser.
>
> Ross
> On Thu, 18 Oct 2018 at 09:56, Tomasz Dziendzielski
>  wrote:
> >
> > So what is the proper solution?
> >
> > Best regards,
> > Tomasz Dziendzielski
> >
> > wt., 16 paź 2018 o 16:00 Tomasz Dziendzielski <
> tomasz.dziendziel...@gmail.com> napisał(a):
> >>
> >> Yes, I want to source the data files. I'm trying to adapt devtool the
> way it's creating the workspace, then I'm sourcing a script with all the
> necessary variables and then interactively run commands by hand.
> >> I was thinking about the devshell but in devshell variables like ${S},
> ${B} are not set and developers would need to set it manually. Or maybe
> this is where we should do the change and inject exporting that variables
> in devshell?
> >>
> >> >it's shell-like but not actually shell.
> >> So we should not state that this can be sourced by a shell. It's stated
> in bitbake/lib/bb/data.py few times.
> >> Or fix it and make it possible to source.
> >>
> >> Best regards,
> >> Tomasz Dziendzielski
> >>
> >> wt., 16 paź 2018 o 15:00 Burton, Ross 
> napisał(a):
> >>>
> >>> Do you actually want to source the data files, and if so why?  As with
> >>> the bitbake -e output, it's shell-like but not actually shell.
> >>>
> >>> Ross
> >>> On Tue, 16 Oct 2018 at 13:44, Tomasz Dziendzielski
> >>>  wrote:
> >>> >
> >>> > Hi,
> >>> > when using archiver.bbclass the do_dumpdata task is using
> bb.data.emit_env function, which should emit variables "in a format such
> that it can be sourced by a shell.".
> >>> > The problem is that the *-showdata.dump file can't be properly
> sourced, because variables are not in a correct format.
> >>> >
> >>> > There are many lines like:
> >>> > PREFERRED_PROVIDER_virtual/fakeroot-native="pseudo-native"
> >>> > The variables with slash are considered to be a directory and the
> ones with dash are considered to be a command.
> >>> > Also shell cannot properly set the variables like FOO_machine.
> >>> >
> >>> > Should it be sourced with some specific shell or is that function
> wrong and should be fixed?
> >>> >
> >>> > Best regards,
> >>> > Tomasz Dziendzielski
> >>> > --
> >>> > ___
> >>> > 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] archiver.bbclass: do_dumpdata - shell format

[Burton, Ross]

Well, as you've discovered, bitbake variables can have names that are
invalid in shell.  I suspect the proper solution is to treat the -e
output as shell-like, and parse it with a proper parser.

Ross
On Thu, 18 Oct 2018 at 09:56, Tomasz Dziendzielski
 wrote:
>
> So what is the proper solution?
>
> Best regards,
> Tomasz Dziendzielski
>
> wt., 16 paź 2018 o 16:00 Tomasz Dziendzielski 
>  napisał(a):
>>
>> Yes, I want to source the data files. I'm trying to adapt devtool the way 
>> it's creating the workspace, then I'm sourcing a script with all the 
>> necessary variables and then interactively run commands by hand.
>> I was thinking about the devshell but in devshell variables like ${S}, ${B} 
>> are not set and developers would need to set it manually. Or maybe this is 
>> where we should do the change and inject exporting that variables in 
>> devshell?
>>
>> >it's shell-like but not actually shell.
>> So we should not state that this can be sourced by a shell. It's stated in 
>> bitbake/lib/bb/data.py few times.
>> Or fix it and make it possible to source.
>>
>> Best regards,
>> Tomasz Dziendzielski
>>
>> wt., 16 paź 2018 o 15:00 Burton, Ross  napisał(a):
>>>
>>> Do you actually want to source the data files, and if so why?  As with
>>> the bitbake -e output, it's shell-like but not actually shell.
>>>
>>> Ross
>>> On Tue, 16 Oct 2018 at 13:44, Tomasz Dziendzielski
>>>  wrote:
>>> >
>>> > Hi,
>>> > when using archiver.bbclass the do_dumpdata task is using 
>>> > bb.data.emit_env function, which should emit variables "in a format such 
>>> > that it can be sourced by a shell.".
>>> > The problem is that the *-showdata.dump file can't be properly sourced, 
>>> > because variables are not in a correct format.
>>> >
>>> > There are many lines like:
>>> > PREFERRED_PROVIDER_virtual/fakeroot-native="pseudo-native"
>>> > The variables with slash are considered to be a directory and the ones 
>>> > with dash are considered to be a command.
>>> > Also shell cannot properly set the variables like FOO_machine.
>>> >
>>> > Should it be sourced with some specific shell or is that function wrong 
>>> > and should be fixed?
>>> >
>>> > Best regards,
>>> > Tomasz Dziendzielski
>>> > --
>>> > ___
>>> > yocto mailing list
>>> > yocto@yoctoproject.org
>>> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [linux-yocto/linux-yocto-dev 4.18][PATCH] perf arm64: Fix generate system call table failed with /tmp mounted with noexec

[Hongxu Jia]

Which /tmp mounted with noexec, generate system call table failed.
[snip]
|perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl:
/tmp/create-table-6VGPSt: Permission denied
[snip]

Add variable TMPDIR as prefix dir of the temporary file, if it is set,
replace default /tmp

Fixes: 2b5882435606 ("perf arm64: Generate system call table from asm/unistd.h")

Signed-off-by: Hongxu Jia 
---
 tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl 
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index 2dbb8cad..c88fd32 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -23,7 +23,7 @@ create_table_from_c()
 {
local sc nr last_sc
 
-   create_table_exe=`mktemp /tmp/create-table-XX`
+   create_table_exe=`mktemp ${TMPDIR:-/tmp}/create-table-XX`
 
{
 
-- 
2.7.4

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

Re: [yocto] archiver.bbclass: do_dumpdata - shell format

[Tomasz Dziendzielski]

So what is the proper solution?

Best regards,
Tomasz Dziendzielski

wt., 16 paź 2018 o 16:00 Tomasz Dziendzielski <
tomasz.dziendziel...@gmail.com> napisał(a):

> Yes, I want to source the data files. I'm trying to adapt devtool the way
> it's creating the workspace, then I'm sourcing a script with all the
> necessary variables and then interactively run commands by hand.
> I was thinking about the devshell but in devshell variables like ${S},
> ${B} are not set and developers would need to set it manually. Or maybe
> this is where we should do the change and inject exporting that variables
> in devshell?
>
> >it's shell-like but not actually shell.
> So we should not state that this can be sourced by a shell. It's stated in
> bitbake/lib/bb/data.py few times.
> Or fix it and make it possible to source.
>
> Best regards,
> Tomasz Dziendzielski
>
> wt., 16 paź 2018 o 15:00 Burton, Ross  napisał(a):
>
>> Do you actually want to source the data files, and if so why?  As with
>> the bitbake -e output, it's shell-like but not actually shell.
>>
>> Ross
>> On Tue, 16 Oct 2018 at 13:44, Tomasz Dziendzielski
>>  wrote:
>> >
>> > Hi,
>> > when using archiver.bbclass the do_dumpdata task is using
>> bb.data.emit_env function, which should emit variables "in a format such
>> that it can be sourced by a shell.".
>> > The problem is that the *-showdata.dump file can't be properly sourced,
>> because variables are not in a correct format.
>> >
>> > There are many lines like:
>> > PREFERRED_PROVIDER_virtual/fakeroot-native="pseudo-native"
>> > The variables with slash are considered to be a directory and the ones
>> with dash are considered to be a command.
>> > Also shell cannot properly set the variables like FOO_machine.
>> >
>> > Should it be sourced with some specific shell or is that function wrong
>> and should be fixed?
>> >
>> > Best regards,
>> > Tomasz Dziendzielski
>> > --
>> > ___
>> > 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_1.23.2 fails at do_compile on Poky-Sumo

[Dhanush K.S]

Hello Yocto,

I'm currently building an image with the busybox_1.23.2.bb recipe included,
using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a
CentOS host building images for the target ARM cortexa8. This busybox
recipe is placed in another custom layer. Though this recipe compiles
without errors in Poky-Fido, in Poky-Sumo I get compilation errors due to
missing header files. I have pasted a part of the log.do.compile file with
the error.

*# merged configuration written to .config (needs make)*
*#*
*NOTE: make -j 2 LD=arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a8
--sysroot=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/recipe-sysroot
V=1 ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- SKIP_STRIP=y
busybox_unstripped*
*rm -f .kernelrelease*
*echo 1.23.2 > .kernelrelease*
*/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/gen_build_files.sh
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2*
*make -f
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/Makefile
silentoldconfig*
*make -f scripts/Makefile.build obj=scripts/basic*
*/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/gen_build_files.sh
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2*
*mkdir -p include*
*make -f scripts/Makefile.build obj=scripts/kconfig silentoldconfig*
*scripts/kconfig/conf -s Config.in*
*#*
*# using defaults found in .config*
*#*
*make -C
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2
KBUILD_SRC= .kernelrelease*
*rm -f .kernelrelease*
*echo 1.23.2 > .kernelrelease*
*make -f scripts/Makefile.build obj=scripts/basic*
*make -f scripts/Makefile.build obj=applets*
*  scripts/basic/split-include include/autoconf.h include/config*
*  gcc -Wp,-MD,applets/.usage.d  -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer  -Iinclude -Iinclude -o applets/usage
applets/usage.c  *
*  gcc -Wp,-MD,applets/.applet_tables.d  -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer   -o applets/applet_tables
applets/applet_tables.c  *
*
/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/scripts/mkconfigs
include/bbconfigopts.h include/bbconfigopts_bz2.h*
*make -f scripts/Makefile.build obj=scripts*
*  applets/usage_compressed include/usage_compressed.h applets*
*  applets/applet_tables include/applet_tables.h include/NUM_APPLETS.h*
*  gcc -Wp,-MD,applets/.usage_pod.d  -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer  -Iinclude -Iinclude -o applets/usage_pod
applets/usage_pod.c  *
*  arm-poky-linux-gnueabi-gcc -Wp,-MD,applets/.applets.o.d   -std=gnu99
-Iinclude -Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D"BB_VER=KBUILD_STR(1.23.2)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wshadow
-Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter
-Wunused-function -Wunused-value -Wmissing-prototypes
-Wmissing-declarations -Wno-format-security -Wdeclaration-after-statement
-Wold-style-definition -fno-builtin-strlen -finline-limit=0
-fomit-frame-pointer -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -static-libgcc
-falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1
-fno-unwind-tables -fno-asynchronous-unwind-tables -Os -O2 -pipe -g
-feliminate-unused-debug-types
-fdebug-prefix-map=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0=/usr/src/debug/busybox/1.23.2-r0
-fdebug-prefix-map=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/recipe-sysroot=
-fdebug-prefix-map=/opt/ac500/yocto/branches/DEVEL_nextYocto/yocto/build_arm-cortex-a8/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/busybox/1.23.2-r0/recipe-sysroot-native=
-mtune=cortex-a8  -O2 -pipe -g -feliminate-unused-debug-types

[yocto] [PATCH][meta-mingw] mingw32-common: only export WINDRES/RC for SDK build

[changqing.li]

From: Changqing Li 

Fix below problem:
MACHINE=intel-x86-64
SDKMACHINE = "i686-mingw32"
bitbake freetype

do_compile failed with below error:
x86_64-wrs-linux-libtool: compile:  x86_64-wrs-linux-windres
--include-dir=work/corei7-64-wrs-linux/freetype/2.9.1-r0/recipe-sysroot/usr/include
/work/corei7-64-wrs-linux/freetype/2.9.1-r0/freetype-2.9.1/src/base/ftver.rc
-o work/corei7-64-wrs-linux/freetype/2.9.1-r0/build/.libs/ftver.o
work/corei7-64-wrs-linux/freetype/2.9.1-r0/build//x86_64-wrs-linux-libtool:
line 1752: x86_64-wrs-linux-windres: command not found

we don't want to use windres for target build, only export WINDRES/RC when build
SDK. SDK_OS = "mingw32", so use this override to fix it.

Signed-off-by: Changqing Li 
---
 conf/machine-sdk/include/mingw32-common.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index 07b103a..92bd184 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -28,8 +28,11 @@ SDKPKGSUFFIX = "nativesdk-mingw32"
 
 MACHINEOVERRIDES .= ":sdkmingw32"
 
-export WINDRES = "${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}"
-export RC = "${WINDRES}"
+WINDRES_mingw32 = "${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}"
+RC_mingw32 = "${WINDRES}"
+
+export WINDRES
+export RC
 
 BB_HASHBASE_WHITELIST_append = " WINDRES RC"
 
-- 
2.7.4

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

Re: [yocto] [selinux] sumo compilation

[Stefano Cappa]

Exactly the same issue since September.

Here is my discussion
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html.
With that trick did you find a solution also on sumo?


Il gio 18 ott 2018, 01:42  ha scritto:

>
> It was broken in rocko too. I added this to local.conf to workaround the
> problem:
>
> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
>
> -steve
>
>  Sinan Kaya  wrote:
> > Hi,
> >
> > We realized today that SELinux does not compile on sumo branch.
> >
> > Is it possible for someone to branch the last working version to a sumo
> branch?
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> >
> > NOTE: Running task 352 of 2707
> > (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/
> e2fsprogs_1.43.8.bb:do_patch)
> > NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> > NOTE: Running task 1413 of 2707
> > (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:
> do_patch)
> > NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> > ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt
> --quiltrc
> > Applying patch misc_create_inode.c-label_rootfs.patch
> > patching file misc/create_inode.c
> > Hunk #1 FAILED at 979.
> > Hunk #2 FAILED at 987.
> >
> > Sinan
> > --
> > ___
> > 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto