Re: [yocto] download.yoctoproject.org - Certificate expired
hi Guilhem, On Sun, Oct 13, 2019 at 12:00 PM Guilhem Saurel wrote: > > Hi, > > The certificate installed on https://download.yoctoproject.org expired about 4 > days ago. Is anyone else experiencing the same issue? Is a new certificate > going > to be installed ? thanks for reporting the issue. We will be looking into it! > > Thanks, > Guilhem. > -- > ___ > 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] Kernel patches pulled from BSP definition file are not applied
> From: Bruce Ashfield
>
> On Fri, Oct 11, 2019 at 1:11 PM Diego Santa Cruz
> wrote:
> >
> > Can anyone provide some advice as to what would be the recommended way
> to apply kernel patches listed in a mybsp-patches.scc file for a BSP?
> >
>
> The way to do this, is to put your BSP definition file on the SRC_URI, and if
> you
> are including the standard/ktype or any of the other common kernel meta data
> files, you need to inhibit any included meta data from adding patches to the
> patch queue (since they are already applied to the kernel).
>
> As an example, here's a 'myqemux86-64.scc' file that I use as a test:
>
> ---
> define KMACHINE myqemux86-64
> define KARCH x86
> define KTYPE standard
>
> include ktypes/standard.scc nopatch
>
> patch foo.patch
> -
>
> When that is on the SRC_URI, it will be found as the BSP definition, and
> you'll get
> "foo.patch" in the patch queue .. but importantly *not* all of the patches
> that
> make up the ktypes/standard.scc (and includes). If you aren't using
> linux-yocto,
> or you aren't building on top of a kernel repository with integrated patches,
> then
> don't add the 'nopatch', since you'd want any found patches to be applied at
> build time.
I'm using linux-intel.
>
> I thought we had documented the nopatch directive in the yocto mega manual,
> but I just checked the kernel meta data section and I don't see it. I'll
> follow up
> and try to figure out where that documentation went ... and get it added if
> it is
> missing.
>
BTW, the existing documentation about nocfg under
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#kernel-types
is not very clear and from what I got from the spp tool's code the nocfg
directive is always inherited and the "inherit" keyword seems to be ignored.
There is also the "force" option to kconf which is not documented.
> Out of curiosity, how were you getting your BSP definition to be located by
> the
> do_metadata function (there are a few different ways) ?
> (since you need at least one .scc file or kernel-meta structure on the
> SRC_URI to
> get it added to the search path). If you were adding it to the SRC_URI
> directly
> and the patches weren't being applied, then that's a bug.
>
My explanation was probably a bit short. I'm using recipe-space metadata as
explained at
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#recipe-space-metadata,
although the explanation there is a bit short and I could not make it work
until I saw the working example in the meta-xilinx layer if I remember well.
I am using linux-intel (from the meta-intel layer), I have set
MACHINE="fukiran" (KMACHINE gets the same value) and I have this in my bbappend.
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://spx-intel-kmeta;type=kmeta;destsuffix=spx-intel-kmeta"
The recipe-space metadata tree is as follows
files/
`-- spx-intel-kmeta
|-- backports
| `-- drivers
| |-- 0001-tty-Add-NULL-TTY-driver.patch
| |-- null-tty.cfg
| `-- null-tty.scc
|-- bsp
| `-- spx-intel
| |-- 0001-platform-x86-spx-fukiran-info-new-driver-for-Spineti.patch
| |-- fukiran.cfg
| |-- fukiran-patches.scc
| |-- fukiran.scc
| `-- fukiran-standard.scc
|-- cfg
| `-- fs
| |-- squashfs.cfg
| `-- squashfs.scc
`-- features
|-- media
| |-- media-cec.cfg
| `-- media-cec.scc
`-- wifi
|-- atheros-10k-pci.cfg
`-- atheros-10k-pci.scc
The BSP definition file fukiran-standard.scc with the content below is thus
located automatically (I followed the best I can the instructions in the Yocto
docs to write the BSP definition file, although I did not quite get what is the
"branch" directive for, I guess it is used when composing a kernel repo tree).
# fukiran-standard.scc
#
# Standard ktype for Fukiran (Apollo Lake SoC).
#
define KMACHINE fukiran
define KARCH x86_64
define KTYPE standard
include ktypes/standard/standard.scc
branch fukiran
include bsp/intel-common/intel-common-drivers.scc
include bsp/intel-common/intel-corei7-64.scc
include fukiran.scc
And fukiran.scc is
kconf hardware fukiran.cfg
patch 0001-platform-x86-spx-fukiran-info-new-driver-for-Spineti.patch
include features/media/media-cec.scc
> A short description of what is happening behind the scenes. The kernel meta-
> data is used in two ways: to construct a new kernel repo from scratch (i.e.
> when
> I start a new reference kernel version, or when building on top of a non
> integrated repository) and to construct a configuration for the kernel.
> Patches
> and config data are kept together, so everything you need for a feature is in
> one
> place. When you are building, the meta data gathering routine is running in
> that
> 2nd mode. Hence why the BSP definition is not used for patching, but is only
> used to
[yocto] No SELinux security context (/etc/crontab)
Hi, I have enabled SELinux in my yocto project(warrior branch) but cron is not functioning because of some SELinux context isuue. I am using minimum SELinux policy. Here is the error from `/var/log/messages` Oct 9 04:50:01 panther2 cron.info crond[261]: ((null)) No SELinux security context (/etc/crontab) Oct 9 04:50:01 panther2 cron.info crond[261]: (root) FAILED (loading cron table) Here are some contexts for relevant files, root@panther2:~# ps -efZ | grep cron system_u:system_r:kernel_t:s0 root 464 1 0 04:54 ?00:00:00 /usr/sbin/crond -n root@panther2:~# ls -lZ /etc/crontab -rw---. 1 root root system_u:object_r:unconfined_t:s0 653 Oct 9 2019 /etc/crontab root@panther2:~# ls -lZ /usr/sbin/crond -rwxr-xr-x. 1 root root system_u:object_r:unlabeled_t:s0 68160 Oct 9 2019 /usr/sbin/crond Any help? Thanks !! Regards, Thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [OE-core][opkg-utils ] Bug 13528 : adding SPDX license identifier
Hi guys, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528 I'm about to work on that bug however most of the script in opkg-utils dir are un-licenced and there's no hint for me to decide what SPDX Identifier to add. The doubt concerns those script : makePackage opkg-build opkg-buildpackage opkg-compare-indexes opkg-diff opkg-extract-file opkg-graph-deps opkg-list-fields opkg-make-index opkg-show-deps opkg-unbuild opkg-update-index What license do you want them to carry ? Best regards, Yann CARDAILLAC -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to get kconfig-frontends package?
Hello! Thank you very much for helpful answer. So, we switch the source to this. *Matous Pokorny* Embedded System Developer *DataVision s.r.o.* Ukrajinska 2a 101 00 Praha 10 Czech Republic GSM: (+420) 723 280 471 matous.poko...@datavision.cz čt 10. 10. 2019 v 11:07 odesílatel Peter Kjellerstedt < peter.kjellerst...@axis.com> napsal: > I have been in contact with Yann E Morin, the maintainer of the > kconfig-frontends repository, and it turns out his server did not survive > their last move of house. However, he pointed out that he has published the > code to GitLab and recommended to use that repository instead: > https://gitlab.com/ymorin/kconfig-frontends > > > > I will send a patch to the openembedded-devel list to update the recipe to > use the GitLab repository. > > > > //Peter > > > > *From:* yocto-boun...@yoctoproject.org *On > Behalf Of *Matouš Pokorný > *Sent:* den 26 september 2019 14:02 > *To:* yocto@yoctoproject.org > *Subject:* [yocto] Where to get kconfig-frontends package? > > > > Hello! > > > > I come from NuttX RTOS project (nuttx.org), and we use Kconfig tool for > configuration. The toolchain build script gets kconfig-frontends source > code from the same server as Yocto (http://ymorin.is-a-geek.org). The > server is down for approx. one week and it caused the fail during the > toolchain building. Have you met this problem as well? We would like to > switch to another more reliable repository, but I read, the server's owner > is one of the Linux core developers. So the server is a kind of primary > source. Do you have a suggestion on how to solve this problem? I would like > to ask you for help because you know the Linux ecosystem and are in the > same situation as we are. > > > > Thank you. > > > > *Matous Pokorny* > > Embedded System Developer > > > > *DataVision s.r.o.* > > Ukrajinska 2a > > 101 00 Praha 10 > > Czech Republic > > > > GSM: (+420) 723 280 471 > > matous.poko...@datavision.cz > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Partitioning SD cards
Hello, I am working on a custom platform where U-Boot will be programmed into an SPI NOR flash device and the ext4 file systems will be in a removable microSD card. The Linux kernel itself will be stored in the /boot directory of the root file system. The customer wants the (16GB) microSD card formatted as 1GB to mount at / and the remaining 15GB mounted as /home. In the recipe for my image I have defined the following to try to create a suitable image for writing to the microSD card: IMAGE_FSTYPES_append = " wic" IMAGE_ROOTFS_SIZE = “1048576” The image file that is being created is bigger than 1GB even though the root file system is only a little over 450MB. Looking at the contents of what gets written to the microSD card this looks as though it is, in part, because it also includes the ~20MB “boot” partition containing the boot files. A couple of questions… How do I stop the wic generation process including the FAT formatted “boot” partition? What is the best strategy for partitioning / formatting / mounting the second partition as /home? Should it be part of the image build process or a one-time task run at first boot? -Andy. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-devel] [OE-core][opkg-utils ] Bug 13528 : adding SPDX license identifier
Hi, GPL-2.0-only was applied to script without previous Licences and GPL-2.0-or-later to those mentioning it, however I'm wondering if I should also add a SPDX id to the makefile ? Here's first attempt without identifier to the Makefile. Best regards, On Fri, Oct 11, 2019 at 6:45 PM wrote: > On Fri, 2019-10-11 at 15:54 +, Alejandro Del Castillo wrote: > > On 10/11/19 8:51 AM, Ycn aKaJoseph wrote: > > > Hi guys, > > > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528 > > > < > > > > https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528__;!fqWJcnlTkjM!8RtsWJXbDz_l063ZSVKrRMwvQ5KGdD0lk9aSjlUW9VHM2wufITJnBuIvovQxoT0yJXu-6Q$ > > > > > > > > > > I'm about to work on that bug however most of the script in opkg- > > > utils > > > dir are un-licenced and there's no hint for me to decide what SPDX > > > Identifier to add. > > > > thanks for doing this! > > > > > The doubt concerns those script : > > > makePackage > > > opkg-build > > > opkg-buildpackage > > > opkg-compare-indexes > > > opkg-diff > > > opkg-extract-file > > > opkg-graph-deps > > > opkg-list-fields > > > opkg-make-index > > > opkg-show-deps > > > opkg-unbuild > > > opkg-update-index > > > > > > What license do you want them to carry ? > > > > Looking at the commit history, opkg-graph-deps was authored by Haris > > Okanovic, and the rest by Richard Purdie (included them on the > > thread). > > > > My take on it: since opkg is licensed as GPLv2+, and the files that > > have a license in opkg-utils are GPLv2+, make sense to me to license > > the rest as GPLv2+ too. > > I didn't author these, they were imported from ipkg-utils which was > part of handhelds.org. I did modify things quite a bit during the > import. > > handhelds.org's CVS repos aren't there any more but I do have old > sources lying around locally. I have a snapshot of the CVS repo from > 20050930 and it has GPLv2 COPYING file (not 2+, just 2). > > I'd suggest we follow the original licensing of that and go with GPLv2. > > Cheers, > > Richard > > > > > From f660e59d0a1b80e4e7d206386577105a4465db2a Mon Sep 17 00:00:00 2001 From: Yann CARDAILLAC Date: Mon, 14 Oct 2019 14:15:03 +0200 Subject: [PATCH] add SPDX license identifiers Signed-off-by: Yann CARDAILLAC --- arfile.py| 1 + opkg-build | 2 +- opkg-buildpackage| 1 + opkg-compare-indexes | 1 + opkg-diff| 2 +- opkg-extract-file| 2 +- opkg-graph-deps | 1 + opkg-list-fields | 1 + opkg-make-index | 1 + opkg-show-deps | 1 + opkg-unbuild | 1 + opkg-update-index| 1 + opkg.py | 1 + update-alternatives | 1 + 14 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arfile.py b/arfile.py index 60edd9b..3b351d8 100644 --- a/arfile.py +++ b/arfile.py @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0-only """ arfile - A module to parse GNU ar archives. diff --git a/opkg-build b/opkg-build index 2517a2b..d09bbfe 100755 --- a/opkg-build +++ b/opkg-build @@ -1,5 +1,5 @@ #!/bin/sh - +# SPDX-License-Identifier: GPL-2.0-only : <<=cut =head1 NAME diff --git a/opkg-buildpackage b/opkg-buildpackage index b7c0e8c..9e00e42 100755 --- a/opkg-buildpackage +++ b/opkg-buildpackage @@ -1,4 +1,5 @@ #!/bin/sh +# SPDX-License-Identifier: GPL-2.0-only # # Author: Oliver Kurth # diff --git a/opkg-compare-indexes b/opkg-compare-indexes index b60d20a..45134e2 100755 --- a/opkg-compare-indexes +++ b/opkg-compare-indexes @@ -1,4 +1,5 @@ #!/usr/bin/env python +# SPDX-License-Identifier: GPL-2.0-only from __future__ import absolute_import from __future__ import print_function diff --git a/opkg-diff b/opkg-diff index bad0b3c..06e6020 100755 --- a/opkg-diff +++ b/opkg-diff @@ -1,5 +1,5 @@ #!/bin/sh - +# SPDX-License-Identifier: GPL-2.0-only pkg1=$1 dir1=`echo $pkg1 | sed s/.opk//` dir1=`basename $dir1` diff --git a/opkg-extract-file b/opkg-extract-file index 7c952ad..bc7c9bd 100755 --- a/opkg-extract-file +++ b/opkg-extract-file @@ -1,5 +1,5 @@ #!/bin/sh - +# SPDX-License-Identifier: GPL-2.0-only set -e if [ $# -lt 1 ]; then diff --git a/opkg-graph-deps b/opkg-graph-deps index 6653fd5..316057a 100755 --- a/opkg-graph-deps +++ b/opkg-graph-deps @@ -1,4 +1,5 @@ #!/usr/bin/env python +# SPDX-License-Identifier: GPL-2.0-only from __future__ import absolute_import from __future__ import print_function diff --git a/opkg-list-fields b/opkg-list-fields index 8a5a588..434f2ae 100755 --- a/opkg-list-fields +++ b/opkg-list-fields @@ -1,4 +1,5 @@ #!/usr/bin/env python +# SPDX-License-Identifier: GPL-2.0-only from __future__ import absolute_import from __future__ import print_function diff --git a/opkg-make-index b/opkg-make-index index 83e5160..6c6ecad 100755 --- a/opkg-make-index +++ b/opkg-make-index @@ -1,4 +1,5 @@ #!/usr/bin/env python +# SPDX-License-Identifier: GPL-2.0-only """ Utility to create opkg compatible indexes """ diff --git a/opkg-show-deps b/opkg-show-deps index 153f
Re: [yocto] Partitioning SD cards
Maciej wrote... How do I stop the wic generation process including the FAT formatted “boot” partition? This depends on the wic (.wks) file you are using. I have been using the default one (sdimage-bootpart.wks)? What is the best strategy for partitioning / formatting / mounting the second partition as /home? Should it be part of the image build process or a one-time task run at first boot? Use --exclude-path and --rootfs-dir flags in the .wks file. You can look at my example, where I extract one subdir from rootfs (/storage in this case) on a separate partition. https://github.com/3mdeb/meta-rte/blob/master/wic/sunxi-mmc-spl.wks I have created a “wic” directory in my custom layer and copied sdimage-bootpart.wks into it as sdimage-project.wks without making any changes but “wic list image” throws an error with the new .wks file: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 37: invalid start byte -Andy.-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Partitioning SD cards
On 14.10.2019 14:13, Andy Pont wrote: > Hello, > > I am working on a custom platform where U-Boot will be programmed into > an SPI NOR flash device and the ext4 file systems will be in a > removable microSD card. The Linux kernel itself will be stored in the > /boot directory of the root file system. > > The customer wants the (16GB) microSD card formatted as 1GB to mount > at / and the remaining 15GB mounted as /home. > > In the recipe for my image I have defined the following to try to > create a suitable image for writing to the microSD card: > > IMAGE_FSTYPES_append = " wic" > IMAGE_ROOTFS_SIZE = “1048576” > > The image file that is being created is bigger than 1GB even though > the root file system is only a little over 450MB. Looking at the > contents of what gets written to the microSD card this looks as though > it is, in part, because it also includes the ~20MB “boot” partition > containing the boot files. > > A couple of questions… > > How do I stop the wic generation process including the FAT formatted > “boot” partition? This depends on the wic (.wks) file you are using. > > What is the best strategy for partitioning / formatting / mounting the > second partition as /home? Should it be part of the image build > process or a one-time task run at first boot? Use --exclude-path and --rootfs-dir flags in the .wks file. You can look at my example, where I extract one subdir from rootfs (/storage in this case) on a separate partition. https://github.com/3mdeb/meta-rte/blob/master/wic/sunxi-mmc-spl.wks The rootfs parts should be named somewhere, like in distro config: https://github.com/3mdeb/meta-rte/blob/master/conf/distro/rte.conf#L50 > > -Andy. > > > -- Maciej Pijanowski Embedded Systems Engineer GPG: F1401D2E1CCB19EF https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Partitioning SD cards
I wrote... I have created a “wic” directory in my custom layer and copied sdimage-bootpart.wks into it as sdimage-project.wks without making any changes but “wic list image” throws an error with the new .wks file: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 37: invalid start byte Ignore that, I deleted the directory and tried again and it is OK now! -Andy. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No SELinux security context (/etc/crontab)
There SE Linux policy included in meta-selinux is just a starting point. It's expected that you will have to update/customize it. With that said, these types of issues, we will accept patches for them. --Mark On 10/10/19 5:06 AM, Oriya, Raxesh wrote: > Hi, > > > > I have enabled SELinux in my yocto project(warrior branch) but *cron *is not > functioning because of some SELinux context isuue. I am using *minimum* > SELinux > policy. Here is the error from `/var/log/messages` > > > > Oct 9 04:50:01 panther2 cron.info crond[261]: ((null)) No SELinux > security > context (/etc/crontab) > > Oct 9 04:50:01 panther2 cron.info crond[261]: (root) FAILED (loading cron > table) > > > > Here are some contexts for relevant files, > > > > root@panther2:~# ps -efZ | grep cron > > system_u:system_r:kernel_t:s0 root 464 1 0 04:54 ? > 00:00:00 > /usr/sbin/crond -n > > > > root@panther2:~# ls -lZ /etc/crontab > > -rw---. 1 root root system_u:object_r:unconfined_t:s0 653 Oct 9 2019 > /etc/crontab > > > > root@panther2:~# ls -lZ /usr/sbin/crond > > -rwxr-xr-x. 1 root root system_u:object_r:unlabeled_t:s0 68160 Oct 9 > 2019 > /usr/sbin/crond > > > > Any help? Thanks !! > > > > Regards, > > Thanks > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel patches pulled from BSP definition file are not applied
On Mon, Oct 14, 2019 at 5:50 AM Diego Santa Cruz
wrote:
>
> > From: Bruce Ashfield
> >
> > On Fri, Oct 11, 2019 at 1:11 PM Diego Santa Cruz
> > wrote:
> > >
>
> > > Can anyone provide some advice as to what would be the recommended way
> > to apply kernel patches listed in a mybsp-patches.scc file for a BSP?
> > >
> >
> > The way to do this, is to put your BSP definition file on the SRC_URI, and
> > if you
> > are including the standard/ktype or any of the other common kernel meta data
> > files, you need to inhibit any included meta data from adding patches to the
> > patch queue (since they are already applied to the kernel).
> >
> > As an example, here's a 'myqemux86-64.scc' file that I use as a test:
> >
> > ---
> > define KMACHINE myqemux86-64
> > define KARCH x86
> > define KTYPE standard
> >
> > include ktypes/standard.scc nopatch
> >
> > patch foo.patch
> > -
> >
> > When that is on the SRC_URI, it will be found as the BSP definition, and
> > you'll get
> > "foo.patch" in the patch queue .. but importantly *not* all of the patches
> > that
> > make up the ktypes/standard.scc (and includes). If you aren't using
> > linux-yocto,
> > or you aren't building on top of a kernel repository with integrated
> > patches, then
> > don't add the 'nopatch', since you'd want any found patches to be applied at
> > build time.
>
> I'm using linux-intel.
>
> >
> > I thought we had documented the nopatch directive in the yocto mega manual,
> > but I just checked the kernel meta data section and I don't see it. I'll
> > follow up
> > and try to figure out where that documentation went ... and get it added if
> > it is
> > missing.
> >
>
> BTW, the existing documentation about nocfg under
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#kernel-types
> is not very clear and from what I got from the spp tool's code the nocfg
> directive is always inherited and the "inherit" keyword seems to be ignored.
> There is also the "force" option to kconf which is not documented.
I've made a note to revisit the docs and get anything I missed updated/added.
>
> > Out of curiosity, how were you getting your BSP definition to be located by
> > the
> > do_metadata function (there are a few different ways) ?
> > (since you need at least one .scc file or kernel-meta structure on the
> > SRC_URI to
> > get it added to the search path). If you were adding it to the SRC_URI
> > directly
> > and the patches weren't being applied, then that's a bug.
> >
>
> My explanation was probably a bit short. I'm using recipe-space metadata as
> explained at
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#recipe-space-metadata,
> although the explanation there is a bit short and I could not make it work
> until I saw the working example in the meta-xilinx layer if I remember well.
>
> I am using linux-intel (from the meta-intel layer), I have set
> MACHINE="fukiran" (KMACHINE gets the same value) and I have this in my
> bbappend.
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI_append = "
> file://spx-intel-kmeta;type=kmeta;destsuffix=spx-intel-kmeta"
>
That's the best way to maintain a set of fragments and related
patches, so that's good!
> The recipe-space metadata tree is as follows
>
> files/
> `-- spx-intel-kmeta
> |-- backports
> | `-- drivers
> | |-- 0001-tty-Add-NULL-TTY-driver.patch
> | |-- null-tty.cfg
> | `-- null-tty.scc
> |-- bsp
> | `-- spx-intel
> | |--
> 0001-platform-x86-spx-fukiran-info-new-driver-for-Spineti.patch
> | |-- fukiran.cfg
> | |-- fukiran-patches.scc
> | |-- fukiran.scc
> | `-- fukiran-standard.scc
> |-- cfg
> | `-- fs
> | |-- squashfs.cfg
> | `-- squashfs.scc
> `-- features
> |-- media
> | |-- media-cec.cfg
> | `-- media-cec.scc
> `-- wifi
> |-- atheros-10k-pci.cfg
> `-- atheros-10k-pci.scc
>
> The BSP definition file fukiran-standard.scc with the content below is thus
> located automatically (I followed the best I can the instructions in the
> Yocto docs to write the BSP definition file, although I did not quite get
> what is the "branch" directive for, I guess it is used when composing a
> kernel repo tree).
You are correct. *if* it is in a .scc that is being applied without
patching inhibited the branch will be created. They are mainly used
when creating a tree from scratch, but can also be used when applying
a fragment from the SRC_URI (but since those patches are applied each
build, you don't really have to worry about co-existence of the
patches, so having a branch to contain them doesn't make a lot of
sense .. but it would delimit them for debugging, etc).
>
> # fukiran-standard.scc
> #
> # Standard ktype for Fukiran (Apollo Lake SoC).
> #
>
> define KMACHINE fukiran
> define KARCH x86_64
> define KTYPE sta
[yocto] NooB: qemu-native compile error during bitbake core-image-sato
Hello list, First time here so, hi there :-) I'm new to yocto but not new to linux. I'm following the Yocto Project Quick Build manual (https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html) on an Arch (Manjaro) machine (uname -r: 4.19.79-1-MANJARO). I know Manjaro is not an official supported distribution but I'm hopping on some help nevertheless. My build stops at: >> bitbake core-image-sato Build Configuration: BB_VERSION = "1.42.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "manjaro" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.7.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "my-yocto-2.7.1:38d5c8ea98cfa49825c473eba8984c12edf062be" WARNING: Your host glibc verson (2.30) is newer than that in uninative (2.29). Disabling uninative so that sstate is not corrupted. ERROR: qemu-native-3.1.0-r0 do_compile: oe_runmake failed ERROR: qemu-native-3.1.0-r0 do_compile: Function failed: do_compile (log file is located at poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259) ERROR: Logfile of failure stored in: poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259 One of the errors in the log.do_compile.1259 file (file attached): poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) OR poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/ioctls.h:223:9: error: ‘SIOCGSTAMPNS’ undeclared here (not in a function); did you mean ‘SIOCGSTAMP_OLD’? 223 | IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec))) I do not know enough to understand where this error comes from. But I suspect it may have to do with the warning I got just before the failure: Is there a way to tell the build system to ignore the newer version glibc? And use the 2.29 version. Or can someone help me to debug this error? Thanks, Robert. DEBUG: Executing shell function do_compile NOTE: make -j 2 LD=ld AR=ar OBJCOPY=objcopy LDFLAGS=-Lpoky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/usr/lib -Lpoky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/lib -Wl,--enable-new-dtags -Wl,-rpath-link,poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/lib -Wl,-rpath,poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/recipe-sysroot-native/lib -Wl,-O1 -fuse-ld=bfd CC aarch64-linux-user/linux-user/syscall.o CC arm-linux-user/linux-user/syscall.o poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) |^~ poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:184:13: note: in definition of macro ‘_syscall0’ 184 | static type name (void) \ | ^~~~ In file included from /usr/include/unistd.h:1170, from poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/include/qemu/osdep.h:90, from poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:20: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; |^~ poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) |^~ poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:184:13: note: in definition of macro ‘_syscall0’ 184 | static type name (void) \ | ^~~~ In file included from /usr/include/unistd.h:1170, from poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/include/qemu/osdep.h:90, from poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:20: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; |^~ poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/ioctls.h:222:9: error: ‘SIOCGSTAMP’ undeclared here
[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed
All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 300 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “2.8”, “2.9’, "2.99" and "Future", the more pressing/urgent issues being in "2.8" and then “2.9”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, *Stephen K. Jolley* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*:(208) 244-4460 * *Email*: *s jolley.yp...@gmail.com * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NooB: qemu-native compile error during bitbake core-image-sato
On 14/10/2019 17:20, p...@iae.nl wrote: Hello list, First time here so, hi there :-) I'm new to yocto but not new to linux. I'm following the Yocto Project Quick Build manual (https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html) on an Arch (Manjaro) machine (uname -r: 4.19.79-1-MANJARO). I know Manjaro is not an official supported distribution but I'm hopping on some help nevertheless. My build stops at: >> bitbake core-image-sato Build Configuration: BB_VERSION = "1.42.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "manjaro" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.7.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "my-yocto-2.7.1:38d5c8ea98cfa49825c473eba8984c12edf062be" WARNING: Your host glibc verson (2.30) is newer than that in uninative (2.29). Disabling uninative so that sstate is not corrupted. ERROR: qemu-native-3.1.0-r0 do_compile: oe_runmake failed ERROR: qemu-native-3.1.0-r0 do_compile: Function failed: do_compile (log file is located at poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259) ERROR: Logfile of failure stored in: poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259 One of the errors in the log.do_compile.1259 file (file attached): poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) OR poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/ioctls.h:223:9: error: ‘SIOCGSTAMPNS’ undeclared here (not in a function); did you mean ‘SIOCGSTAMP_OLD’? 223 | IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec))) I do not know enough to understand where this error comes from. But I suspect it may have to do with the warning I got just before the failure: Is there a way to tell the build system to ignore the newer version glibc? And use the 2.29 version. Or can someone help me to debug this error? You're trying to build an older qemu against a very new kernel. If you can, grab the warrior branch from git instead of using the 2.7.1 release as that has the fix in. Alternatively, cherry-pick this commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0570ef5a5e180f7504df970645d1fcce6310b828 Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web] Enabled zeus, not working...
I added the zeus branch on the layers.openembedded.org today and it's not showing up and being indexed. Any idea why? On my own personal layer index I did it and it worked fine. So it may be something related to the configuration. Below are the errors from the update log: Oct. 14, 2019, 7:13 p.m. openembedded-core zeus INFO: Collecting data for layer openembedded-core on branch zeus ERROR: error: pathspec 'origin/zeus' did not match any file(s) known to git. ERROR: Traceback (most recent call last): File "update_layer.py", line 370, in main (tinfoil, tempdir) = recipeparse.init_parser(settings, branch, bitbakepath, nocheckout=options.nocheckout, logger=logger) File "/opt/layerindex/layerindex/recipeparse.py", line 34, in init_parser utils.checkout_repo(bitbakepath, bitbake_ref, logger=logger) File "/opt/layerindex/layerindex/utils.py", line 246, in checkout_repo runcmd(['git', 'checkout', commit], repodir, logger=logger) File "/opt/layerindex/layerindex/utils.py", line 327, in runcmd raise e subprocess.CalledProcessError: Command '['git', 'checkout', 'origin/zeus']' returned non-zero exit status 1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NooB: qemu-native compile error during bitbake core-image-sato
On 14-10-2019 18:54, Ross Burton wrote: On 14/10/2019 17:20, p...@iae.nl wrote: Hello list, First time here so, hi there :-) I'm new to yocto but not new to linux. I'm following the Yocto Project Quick Build manual (https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html) on an Arch (Manjaro) machine (uname -r: 4.19.79-1-MANJARO). I know Manjaro is not an official supported distribution but I'm hopping on some help nevertheless. My build stops at: >> bitbake core-image-sato Build Configuration: BB_VERSION = "1.42.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "manjaro" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.7.1" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "my-yocto-2.7.1:38d5c8ea98cfa49825c473eba8984c12edf062be" WARNING: Your host glibc verson (2.30) is newer than that in uninative (2.29). Disabling uninative so that sstate is not corrupted. ERROR: qemu-native-3.1.0-r0 do_compile: oe_runmake failed ERROR: qemu-native-3.1.0-r0 do_compile: Function failed: do_compile (log file is located at poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259) ERROR: Logfile of failure stored in: poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/temp/log.do_compile.1259 One of the errors in the log.do_compile.1259 file (file attached): poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) OR poky/build/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/ioctls.h:223:9: error: ‘SIOCGSTAMPNS’ undeclared here (not in a function); did you mean ‘SIOCGSTAMP_OLD’? 223 | IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec))) I do not know enough to understand where this error comes from. But I suspect it may have to do with the warning I got just before the failure: Is there a way to tell the build system to ignore the newer version glibc? And use the 2.29 version. Or can someone help me to debug this error? You're trying to build an older qemu against a very new kernel. If you can, grab the warrior branch from git instead of using the 2.7.1 release as that has the fix in. Alternatively, cherry-pick this commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0570ef5a5e180f7504df970645d1fcce6310b828 Ross Thanks, it seams to work. That is, using the warrior branch. I'll also try the patch you suggested. For future reference, how could I have found this answer? I searched like crazy but never found any reference that qemu is "old" and my kernel is "new". Robert. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NooB: qemu-native compile error during bitbake core-image-sato
On 14/10/2019 22:32, myken wrote: For future reference, how could I have found this answer? I searched like crazy but never found any reference that qemu is "old" and my kernel is "new". By recognising where the failure was, knowing that glibc changed, and that qemu needs to be fixed, then finding the relevant fixes already existed in qemu. Running unsupported distros means discovering stuff like this. :) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web] Enabled zeus, not working...
Hi Mark On Tuesday, 15 October 2019 10:21:29 AM NZDT Mark Hatle wrote: > I added the zeus branch on the layers.openembedded.org today and it's not > showing up and being indexed. Any idea why? The bitbake branch wasn't correctly specified - it needed to be set to "1.44" (grabbed from https://wiki.yoctoproject.org/wiki/Releases if you don't have it in your head - I didn't ;). > On my own personal layer index I did it and it worked fine. So it may be > something related to the configuration. I guess it worked in your case because (based on your patch of the other day) you're picking bitbake out of a repo where zeus is a valid branch. FYI on layers.openembedded.org you also need to select the Python environment for the branch - python3 in this case. I've made both of these changes so it should index correctly the next time around. Cheers Paul -- Paul Eggleton Intel System Software Products -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web] Enabled zeus, not working...
On 10/14/19 5:08 PM, Paul Eggleton wrote: > Hi Mark > > On Tuesday, 15 October 2019 10:21:29 AM NZDT Mark Hatle wrote: >> I added the zeus branch on the layers.openembedded.org today and it's not >> showing up and being indexed. Any idea why? > > The bitbake branch wasn't correctly specified - it needed to be set to "1.44" > (grabbed from https://wiki.yoctoproject.org/wiki/Releases if you don't have > it > in your head - I didn't ;). > Great so it's my fault.. much easier to fix then an infrastructure issue. >> On my own personal layer index I did it and it worked fine. So it may be >> something related to the configuration. > > I guess it worked in your case because (based on your patch of the other day) > you're picking bitbake out of a repo where zeus is a valid branch. Yup, exactly.. it -happened- to work.. :) > FYI on layers.openembedded.org you also need to select the Python environment > for the branch - python3 in this case. > > I've made both of these changes so it should index correctly the next time > around. Ahh I thought python3 was now the default, and python2 was for the older systems. I read it backwards.. I'll try to remember in 6 months. :) (Part of the reason I included the mailing list here.) --Mark > Cheers > Paul > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] suricata: fix compile issue
cp: cannot stat
'/./tmp-glibc/work/core2-32-oe-linux/suricata/4.1.5-r0/rules': No such file
or directory
| WARNING: exit code 1 from a shell command.
Signed-off-by: Armin Kuster
---
recipes-ids/suricata/suricata_4.1.5.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/recipes-ids/suricata/suricata_4.1.5.bb
b/recipes-ids/suricata/suricata_4.1.5.bb
index cda1c87..e15a9a3 100644
--- a/recipes-ids/suricata/suricata_4.1.5.bb
+++ b/recipes-ids/suricata/suricata_4.1.5.bb
@@ -52,9 +52,6 @@ do_install_append () {
oe_runmake install-conf DESTDIR=${D}
-# mimic move of downloaded rules to e_sysconfrulesdir
-cp -rf ${WORKDIR}/rules ${D}${sysconfdir}/suricata
-
oe_runmake install-rules DESTDIR=${D}
install -d ${D}${sysconfdir}/suricata ${D}${sysconfdir}/default/volatiles
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] checksec: add missing rdepends to readelf
update test to check for depends
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/checksec.py | 1 +
recipes-security/checksec/checksec_2.1.0.bb | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/oeqa/runtime/cases/checksec.py
b/lib/oeqa/runtime/cases/checksec.py
index ff6d2f3..e46744c 100644
--- a/lib/oeqa/runtime/cases/checksec.py
+++ b/lib/oeqa/runtime/cases/checksec.py
@@ -24,6 +24,7 @@ class CheckSecTest(OERuntimeTestCase):
self.assertEqual(status, 0, msg = msg)
@OETestDepends(['checksec.CheckSecTest.test_checksec_xml'])
+@OEHasPackage(['binutils'])
def test_checksec_fortify(self):
status, output = self.target.run('checksec --fortify-proc 1')
match = re.search('FORTIFY_SOURCE support:', output)
diff --git a/recipes-security/checksec/checksec_2.1.0.bb
b/recipes-security/checksec/checksec_2.1.0.bb
index 5c6528e..b67c98b 100644
--- a/recipes-security/checksec/checksec_2.1.0.bb
+++ b/recipes-security/checksec/checksec_2.1.0.bb
@@ -16,4 +16,4 @@ do_install() {
install -m 0755 ${S}/checksec ${D}${bindir}
}
-RDEPENDS_${PN} = "bash openssl-bin"
+RDEPENDS_${PN} = "bash openssl-bin binutils"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Yocto] QA cycle report for yocto-3.0_rc2
Hello all, This is the full QA report for YP 3.0 RC2: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/3.0_RC2?h=intel-yocto-testresults === Summary No high milestone defects. Two new defects are found in this cycle, mpc8315e-rdb: the stap oeqa test causes OOM (BUG id:13594) and strace ptest failed (BUG id:13595). Verified (BUG id: 13555) === Bugs https://bugzilla.yoctoproject.org/show_bug.cgi?id=13595 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13594 Thanks & Regards, Sangeeta Jain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
