Re: [yocto] defconfig file (or fragment files) not used

[Vincent Daanen]

Hi,

On 03/30/2018, Bruce Ashfield wrote
>
> Is this using master of oe-core ? Is this a setup that I can configure and 
> build here ?
> 
> If I can easily reproduce it, I can offer better suggestions.

I'm using rocko version
Do you need more info to help me ?

Thanks

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

[yocto] EFL : Status, WIP, interest...

[Stefano Babic]

Hi,

I would like to know which is the status and the interest about EFL and
Enlightment. I found the old Takashi's thread :

https://lists.yoctoproject.org/pipermail/yocto/2017-February/034588.html

I have seen that Takashi did already a lot of work starting a
meta-efl-rebuilding (maybe to be added to http://layers.openembedded.org
?). This allows to build EFL and Enlightment, I tested the EFL image and
I have crash when Enlightment is started - some work should be done.
Anyway, I think it could be great to have a further graphic environment
into OE, in cases QT could not be used and/or other frameworks are not
suitable for embedded.

Takashi, can you tell me some notes about the current status and what
you think it should be done ? Do you plan to maintain this layer or you
stop with it ? I am sure this are topic interesting for other OE's users..

Thanks,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Glibc fetch error inside proxy

[Chanho Park]

Hi,

Since the glibc revision has been moved to 2.26(d300041c), I couldn’t fetch
the glibc source properly. It seemed the glibc repository has a problem
when cloning it inside http proxy. According to the mirrors.bbclass, the
mirror of the glibc can be downloaded by
http://downloads.yoctoproject.org/mirror/sources. My question is when the
mirror can be updated to particular version.

Best Regards,
Chanho Park
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] defconfig file (or fragment files) not used

[Bruce Ashfield]

On 2018-04-04 5:58 AM, Vincent Daanen wrote:

Hi,

On 03/30/2018, Bruce Ashfield wrote


Is this using master of oe-core ? Is this a setup that I can configure and 
build here ?

If I can easily reproduce it, I can offer better suggestions.


I'm using rocko version
Do you need more info to help me ?


Yes, I need your layers, configurations, etc.

Bruce



Thanks

Vincent



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

[yocto] Kernel configuration patches not persisting?

[Giordon Stark]

Hi all,

I have a custom board with custom kernel config changes. Because of that, I
append the u-boot recipe as well:

https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend


with my machine.h and defconfig files here:
https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/u-boot/files/gfex-prototype4


I find that when I make a change in the defconfig, such as "
CONFIG_CPU_IDLE=n", bitbake properly recompiles all the necessary
components... however, when I look at the running kernel configuration:

root@gfex-prototype4:~# cat /proc/config.gz | gunzip > run.config
root@gfex-prototype4:~# vi run.config
root@gfex-prototype4:~# cat run.config | grep CONFIG_CPU_IDLE
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y

it seems my change still wasn't propagated? I looked at the instructions
here (
https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration)
but I'm not sure I want to duplicate my defconfig file into a second
location to bbappend the linux-yocto.

Have I done something wrong? Am I missing something else?

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

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Chris Elledge]

Thanks for the feedback. I rolled back binutils to 2.28.0 by copying the
yocto-2.3.3 binutils recipe directory into my custom layer. That has
resolved the issue.

I can confirm that binutils 2.29.0 also has the problem. I went from
yocto-2.3 to 2.4.2 so I hadn't tried binutils 2.29.0 previously. There are
also reports that openssl and libavcodec are broken when targeting an ARM
Thumb2 platform with binutils 2.29.*

-Chris

On Mon, Apr 2, 2018 at 7:14 PM, Andre McCurdy  wrote:

> On Mon, Apr 2, 2018 at 1:15 PM, Chris Elledge
>  wrote:
> > I recently upgraded my Yocto based project to Yocto 2.4.2, and I
> encountered
> > a problem when building my custom kernel for an AT91 SAMA5D3X platform.
> I've
> > been using an ARM Thumb2 kernel for a while successfully until this
> release.
> > It appears that the issue stems from the change to binutils version
> 2.29.1.
> >
> > Here's a good description of the problem:
> > https://patchwork.kernel.org/patch/10072695/
> >
> > I tried out their test script, and it flagged the arm-poky-linux-gnueabi-
> > toolchain built by Yocto 2.4.2 as being buggy. Has anyone else
> encountered
> > this problem and figured out a way around it without disabling Thumb
> > compilation of the kernel?
>
> Thanks for bringing up this issue. Reading through the various bug
> reports etc it not clear what the fix should be. Upstream binutils has
> not reverted the change and the upstream kernel still appears to rely
> on the pre-2.29.1 binutils behaviour.
>
> The simplest solution for OE 2.4 would seem to be to revert the change
> in binutils (rev e645cf4, which was added very close to the 2.29.1
> release).
>
> Longer term, it looks like the kernel will have to be updated to work
> with the most recent versions of binutils. A possible approach for
> that is hinted at in the kernel patch you provided a link for, ie
> update the "badr" macro in arch/arm/include/asm/assembler.h to OR the
> sym address with 1 instead of adding 1. e.g. something like changing:
>
>   #ifdef CONFIG_THUMB2_KERNEL
>   adr\c \rd, \sym + 1
>   #else
>
> to
>
>   #ifdef CONFIG_THUMB2_KERNEL
>   adr\c \rd, \sym
>   orr\c \rd, \rd, #1
>   #else
>
> The fact that it doesn't seem to have been fixed that way in the
> upstream kernel suggests that the kernel developers may be hoping to
> find a better solution though (ie one which avoids adding an extra
> instruction in the syscall fast path).
>
> So, without some more guidance from either upstream project, the best
> solution isn't clear. Perhaps you could try reverting the binutils
> change to get you up and running again in the short term and then ask
> on the ARM kernel mailing lists what the solution for Thumb2 with
> binutils >= 2.29.1 is expected to be?
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel configuration patches not persisting?

[Stephano Cetola]

On 4/4/18 7:48 AM, Giordon Stark wrote:
> Hi all,
> 
> I have a custom board with custom kernel config changes. Because of
> that, I append the u-boot recipe as well:
> 
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend
>  
> 
> with my machine.h and defconfig files
> here: 
> https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/u-boot/files/gfex-prototype4
>  
> 
> I find that when I make a change in the defconfig, such as
> "CONFIG_CPU_IDLE=n", bitbake properly recompiles all the necessary
> components... however, when I look at the running kernel configuration:
> 
> root@gfex-prototype4:~# cat /proc/config.gz | gunzip > run.config
> root@gfex-prototype4:~# vi run.config
> root@gfex-prototype4:~# cat run.config | grep CONFIG_CPU_IDLE
> CONFIG_CPU_IDLE=y
> # CONFIG_CPU_IDLE_GOV_LADDER is not set
> CONFIG_CPU_IDLE_GOV_MENU=y
> 
> it seems my change still wasn't propagated? I looked at the instructions
> here
> (https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration)
> but I'm not sure I want to duplicate my defconfig file into a second
> location to bbappend the linux-yocto.
> 
> Have I done something wrong? Am I missing something else?
> 
> Giordon
> -- 
> Giordon Stark

Hey Giordon,

It looks like you're confusing two topics: u-boot and kernel configuration.

Both u-boot and the kernel use kconfig. This can confuse folks that are
new to bootloader/kernel work.

Looking at your layer, you're actually interested in changing the
kernel's configuration rather than u-boot. For example, on the
gfex-prototype4 defconfig, you set ARCH_ZYNQMP, which is a kernel config
for the Xilinx Zynq boards. You probably want to add a bbappend for your
kernel and add the defconfig to that recipe.

Cheers,
Stephano

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

Re: [yocto] Kernel configuration patches not persisting?

[Giordon Stark]

Hi Stephano,

I see. A large part of this confusion probably comes from the fact that
they're both using kconfig indeed. ARCH_ZYNQMP is actually used by the
u-boot-xlnx as well (maybe that makes things even more confusing).

Do both u-boot and linux-yocto accept kernel fragments? Is a kernel config
fragment detected by bitbake as a file ending in *.cfg and a full config as
a file called "defconfig"? This distinction isn't super clear in the manual.

In the meantime, I will add a bbappend and a kernel config fragment to
recipes-kernel/linux/ and report back.

G

On Wed, Apr 4, 2018 at 10:32 AM Stephano Cetola <
stephano.cet...@linux.intel.com> wrote:

> On 4/4/18 7:48 AM, Giordon Stark wrote:
> > Hi all,
> >
> > I have a custom board with custom kernel config changes. Because of
> > that, I append the u-boot recipe as well:
> >
> >
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend
>
> >
> > with my machine.h and defconfig files
> > here:
> https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/u-boot/files/gfex-prototype4
>
> >
> > I find that when I make a change in the defconfig, such as
> > "CONFIG_CPU_IDLE=n", bitbake properly recompiles all the necessary
> > components... however, when I look at the running kernel configuration:
> >
> > root@gfex-prototype4:~# cat /proc/config.gz | gunzip > run.config
> > root@gfex-prototype4:~# vi run.config
> > root@gfex-prototype4:~# cat run.config | grep CONFIG_CPU_IDLE
> > CONFIG_CPU_IDLE=y
> > # CONFIG_CPU_IDLE_GOV_LADDER is not set
> > CONFIG_CPU_IDLE_GOV_MENU=y
> >
> > it seems my change still wasn't propagated? I looked at the instructions
> > here
> > (
> https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration
> )
> > but I'm not sure I want to duplicate my defconfig file into a second
> > location to bbappend the linux-yocto.
> >
> > Have I done something wrong? Am I missing something else?
> >
> > Giordon
> > --
> > Giordon Stark
>
> Hey Giordon,
>
> It looks like you're confusing two topics: u-boot and kernel configuration.
>
> Both u-boot and the kernel use kconfig. This can confuse folks that are
> new to bootloader/kernel work.
>
> Looking at your layer, you're actually interested in changing the
> kernel's configuration rather than u-boot. For example, on the
> gfex-prototype4 defconfig, you set ARCH_ZYNQMP, which is a kernel config
> for the Xilinx Zynq boards. You probably want to add a bbappend for your
> kernel and add the defconfig to that recipe.
>
> Cheers,
> Stephano
>
> --
Giordon Stark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Setting a custom hostname using git revisions?

[Giordon Stark]

Hi all,

I looked at the bitbake manual, but if I have a custom layer that's checked
out at a specific revision, how can I access the variable containing the
revision to embed it into the hostname variable?

I would want to append the hostname variable in:
recipes-core/base-files/base-files_%.bbappend which is currently set to
"${MACHINE}".

Instead, I would like something along the lines of
"${MACHINE}-${LAYER_REV}".

Thanks,

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

Re: [yocto] Kernel configuration patches not persisting?

[Stephano Cetola]

On 4/4/18 8:39 AM, Giordon Stark wrote:
> Hi Stephano,
> 
> I see. A large part of this confusion probably comes from the fact that
> they're both using kconfig indeed. ARCH_ZYNQMP is actually used by the
> u-boot-xlnx as well (maybe that makes things even more confusing).
> 
> Do both u-boot and linux-yocto accept kernel fragments? Is a kernel
> config fragment detected by bitbake as a file ending in *.cfg and a full
> config as a file called "defconfig"? This distinction isn't super clear
> in the manual.

linux-yocto supports using the .cfg to add configuration fragments for
different targets or for multiple configurations on the same target. You
can check out meta/classes/kernel-yocto.bbclass to see how this is done.

The u-boot recipe is much simpler and any changes to the configuration
is probably going to be added in your u-boot tree
(configs/[MACHINE]_defconfig). At least that's how I've done it in the past.

I know that Freescale uses UBOOT_CONFIG for their boards, but I've never
looked into doing this for a custom board.

> 
> In the meantime, I will add a bbappend and a kernel config fragment to
> recipes-kernel/linux/ and report back.

Sounds good!

--S

> 
> G
> 
> On Wed, Apr 4, 2018 at 10:32 AM Stephano Cetola
>  > wrote:
> 
> On 4/4/18 7:48 AM, Giordon Stark wrote:
> > Hi all,
> >
> > I have a custom board with custom kernel config changes. Because of
> > that, I append the u-boot recipe as well:
> >
> >
> 
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend
>  
> >
> > with my machine.h and defconfig files
> >
> here: 
> https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/u-boot/files/gfex-prototype4
>  
> >
> > I find that when I make a change in the defconfig, such as
> > "CONFIG_CPU_IDLE=n", bitbake properly recompiles all the necessary
> > components... however, when I look at the running kernel
> configuration:
> >
> > root@gfex-prototype4:~# cat /proc/config.gz | gunzip > run.config
> > root@gfex-prototype4:~# vi run.config
> > root@gfex-prototype4:~# cat run.config | grep CONFIG_CPU_IDLE
> > CONFIG_CPU_IDLE=y
> > # CONFIG_CPU_IDLE_GOV_LADDER is not set
> > CONFIG_CPU_IDLE_GOV_MENU=y
> >
> > it seems my change still wasn't propagated? I looked at the
> instructions
> > here
> >
> 
> (https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration)
> > but I'm not sure I want to duplicate my defconfig file into a second
> > location to bbappend the linux-yocto.
> >
> > Have I done something wrong? Am I missing something else?
> >
> > Giordon
> > --
> > Giordon Stark
> 
> Hey Giordon,
> 
> It looks like you're confusing two topics: u-boot and kernel
> configuration.
> 
> Both u-boot and the kernel use kconfig. This can confuse folks that are
> new to bootloader/kernel work.
> 
> Looking at your layer, you're actually interested in changing the
> kernel's configuration rather than u-boot. For example, on the
> gfex-prototype4 defconfig, you set ARCH_ZYNQMP, which is a kernel config
> for the Xilinx Zynq boards. You probably want to add a bbappend for your
> kernel and add the defconfig to that recipe.
> 
> Cheers,
> Stephano
> 
> -- 
> Giordon Stark

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

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Wed, Apr 4, 2018 at 8:06 AM, Chris Elledge
 wrote:
> Thanks for the feedback. I rolled back binutils to 2.28.0 by copying the
> yocto-2.3.3 binutils recipe directory into my custom layer. That has
> resolved the issue.
>
> I can confirm that binutils 2.29.0 also has the problem. I went from
> yocto-2.3 to 2.4.2 so I hadn't tried binutils 2.29.0 previously. There are
> also reports that openssl and libavcodec are broken when targeting an ARM
> Thumb2 platform with binutils 2.29.*

Yes, that makes sense. The binutils change is in both 2.29.0 and
2.29.1 (and also in 2.30.0).

The next useful experiment would be to stay with binutils 2.29.1 and
apply a patch to revert the one particular commit which caused the
change in behaviour:

  
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=e645cf40b111daef4518a58547de577eb9379ccb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Setting a custom hostname using git revisions?

[Stephano Cetola]

On 4/4/18 8:48 AM, Giordon Stark wrote:
> Hi all,
> 
> I looked at the bitbake manual, but if I have a custom layer that's
> checked out at a specific revision, how can I access the variable
> containing the revision to embed it into the hostname variable?
> 
> I would want to append the hostname variable in:
> recipes-core/base-files/base-files_%.bbappend which is currently set to
> "${MACHINE}".
> 
> Instead, I would like something along the lines of
> "${MACHINE}-${LAYER_REV}".
> 
> Thanks,
> 
> Giordon
> -- 
> Giordon Stark
> 
> 

This is pretty tricky. I'd use a python function inside your recipe.

You can get the layers like this:

layers = (bb.data.getVar("BBLAYERS", d, 1) or "").split()

Then if you have a look at the metadata_scm.bbclass, you can use some of
the functions in there:

base_get_metadata_git_branch
base_get_metadata_git_revision

Add some logic and you should be able to pull the revision information
you care about out of that data.

Cheers,
Stephano


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

[yocto] QEMU package list verification

[Aditya Tayade]

Hi ,
Please refer to my below steps to understand how OS components are included in 
the Qemu image for Yocto 2.5

1) Build core-image-sato for yocto 2.5 ( DISTRO_VERSION = 2.4+snapshot-20180402)
2) I used the bitbake-layers show-recipes to list down the packages .
3) Verify whether the packages are part of the image root fs
4) I use command find ./ -name**

If above command returns **.so or 
/var/lib/dnf/yumdb/*/** then i consider the the package 
successfully added to rootfs.
If not then i consider the package not present in the rootfs.

4) I found some packages not present in the rootfs that are listed in the step 
2 . I assume that by default meta, meta-poky and meta-yocto-bsp layers are part 
of yocto 2.5 so  all the packages present in these layers should be present in 
QEMU as well.

If my assumption is correct how do we ensure that all the packges of the layers 
meta, meta-poky and meta-yocto-bsp layers are present in the qemu root fs ?

Regards,
Aditya Tayade


This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ERROR: problem:package openssh-7.6p1-r0.i586 conflicts with dropbear provided by dropbear-2017.75-r0.i586

[Aditya Tayade]

Hi,


I trying to build core-image-sato using yocto 2.5 with new package openssh.


Added openssh entry in the local.conf file as follows:

IMAGE_INSTALL_append = "openssh"


But facing some conflicts error. Please refer attached log file for more 
information.


Could you please help to resolve the issue. I need to use use openssh for ssh 
rather than dropbear.



Regards,

Aditya Tayade

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
ERROR: core-image-sato-1.0-r0 do_rootfs: Could not invoke dnf. Command 
'/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/dnf
 -y -c 
/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/rootfs/etc/dnf/dnf.conf
 
--setopt=reposdir=/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/rootfs/etc/yum.repos.d
 
--repofrompath=oe-repo,/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
 
--installroot=/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/rootfs
 
--setopt=logdir=/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/temp
 --nogpgcheck install locale-base-en-us locale-base-en-gb os-release automake 
mosquitto gdb libsamplerate0 libfribidi0 liburcu ltrace libatomic-ops cmake 
devmem2 libgif7 krb5 rpm libtinyxml2-5 python-dbus bison libtool kbd 
kernel-devsrc tcpdump opkg-arch-config libsqlite0 strongswan asio hdparm acpid 
vlan python-pygobject coreutils mmc-utils eglinfo-fb gnu-config libdnet 
run-postinsts fbset-modes libacpi0 kexec-tools polkit ebtables gperftools 
nftables dnf libaio1 libyaml-0-2 mesa libical smartmontools openssh icu lz4 
libjson-c3 opkg-utils git boost i2c-tools bridge-utils ccache 
packagegroup-base-extended lsof autofs mtools linux-firmware perf lrzsz 
packagegroup-core-boot libprotobuf15 findutils curl 
packagegroup-core-ssh-dropbear packagegroup-core-x11-sato gcc-sanitizers ppp 
libfuse2 canutils gettext libnewt0.52 mozjs libatasmart4 udisks2 psplash 
libqrencode4 packagegroup-core-x11-base opkg libxslt lighttpd libdbus-glib-1-2 
libgudev-1.0-0 libnftnl7 dbus-1 libusb-0.1-4 lua lttng-ust libsocketcan2 nano 
libcgroup libssh2-1 libcheck iw mailx pseudo hello' returned 1:
Added oe-repo repo from 
/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
Last metadata expiration check: 0:00:01 ago on Mon 02 Apr 2018 09:20:12 AM UTC.
Error: 
 Problem: package packagegroup-core-ssh-dropbear-1.0-r1.noarch requires 
dropbear, but none of the providers can be installed
  - package openssh-7.6p1-r0.i586 conflicts with dropbear provided by 
dropbear-2017.75-r0.i586
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

ERROR: core-image-sato-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/aditya/mywork/poky/build-hello/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/temp/log.do_rootfs.4050
ERROR: Task 
(/home/aditya/mywork/poky/meta/recipes-sato/images/core-image-sato.bb:do_rootfs)
 failed with exit code '1'


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

Re: [yocto] [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Daniel Stone]

Hi Trevor,

On 2 April 2018 at 23:09, Trevor Woerner  wrote:
> On Mon 2018-04-02 @ 11:46:39 PM, Andreas Müller wrote:
>> > to my conf/local.conf has glmark2-es2 running, and chromium-x11 is running
>> > accelerated out-of-the-box (i.e. I don't have to install the egl/gles
>> > libraries it builds itself).
>> Cool - have not seen it running without issues for very long time...
>
> Yes, this is a very nice side effect of your digging into this apparently
> un-related issue! :-)
>
> In my own layers I had a .bbappend that was copying the chromium-built
> egl/gles libraries to the target, but it doesn't look like this is needed
> anymore. I posted complete information here (as part of an issue you had
> originally opened):
>
> 
> https://github.com/OSSystems/meta-browser/pull/82#issuecomment-353528110

Right, you shouldn't need that at all. It's unlikely to do any good.
If it does solve anything, we'd love to hear about what so we can try
to fix it, like with this one.

>> > I'm re-building my rpi3-64 image to see if things are better there too 
>> > under
>> > vc4.
>> You'll let me know I guess...
>
> Absolutely! But, you know chromium... I'll need an hour or two... ;-)
> (my image has chromium, glmark2, mesa-demos, directfb, directfb-examples, Qt,
> and a bunch of Qt demos. sadly, the directfb examples always work, it's
> everything else that's a coin-toss!! haha)

Right, Weston/etc would've worked fine as well: this is solely broken
on X11 with DRI3 disabled.

>> > I guess the patch is to address some of the other things you were seeing?
>> No - after enabling dri3 all I tested so far was perfectly fine. But
>> maybe other graphic drivers are affected.
>
> Now I'm confused: is the patch needed?

Yes and no. It only affects DRI2. Merging the patch fixes DRI2. Using
DRI3 avoids the problem altogether, and is better to be doing anyway.
If the recipes are going to continue to offer the option to disable
DRI3 and go DRI2-only with X11, then making sure that's fixed is
prudent. But the default should very definitely be DRI3.

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

Re: [yocto] ERROR: problem:package openssh-7.6p1-r0.i586 conflicts with dropbear provided by dropbear-2017.75-r0.i586

[Sandeep G.R]

Add this to local.conf

PACKAGE_EXCLUDE += " packagegroup-core-ssh-dropbear"

*Thanks,*
*Sandeep*


On Mon, Apr 2, 2018 at 4:38 AM, Aditya Tayade 
wrote:

> Hi,
>
>
> I trying to build core-image-sato using yocto 2.5 with new package openssh.
>
>
> Added openssh entry in the local.conf file as follows:
>
> IMAGE_INSTALL_append = "openssh"
>
>
> But facing some conflicts error. Please refer attached log file for more
> information.
>
>
> Could you please help to resolve the issue. I need to use use openssh for
> ssh rather than dropbear.
>
>
>
> Regards,
>
> Aditya Tayade
> This message contains information that may be privileged or confidential
> and is the property of the KPIT Technologies Ltd. It is intended only for
> the person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to read, print, retain copy, disseminate,
> distribute, or use this message or any part thereof. If you receive this
> message in error, please notify the sender immediately and delete all
> copies of this message. KPIT Technologies Ltd. does not accept any
> liability for virus infected mails.
>
> --
> ___
> 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] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Wed, Apr 4, 2018 at 9:14 AM, Andre McCurdy  wrote:
> On Wed, Apr 4, 2018 at 8:06 AM, Chris Elledge
>  wrote:
>> Thanks for the feedback. I rolled back binutils to 2.28.0 by copying the
>> yocto-2.3.3 binutils recipe directory into my custom layer. That has
>> resolved the issue.
>>
>> I can confirm that binutils 2.29.0 also has the problem. I went from
>> yocto-2.3 to 2.4.2 so I hadn't tried binutils 2.29.0 previously. There are
>> also reports that openssl and libavcodec are broken when targeting an ARM
>> Thumb2 platform with binutils 2.29.*
>
> Yes, that makes sense. The binutils change is in both 2.29.0 and
> 2.29.1 (and also in 2.30.0).
>
> The next useful experiment would be to stay with binutils 2.29.1 and
> apply a patch to revert the one particular commit which caused the
> change in behaviour:
>
>   
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=e645cf40b111daef4518a58547de577eb9379ccb

The experiment of patching the kernel would also be useful, since I
would guess that the final solution from upstream will involve a
change to the kernel rather than reverting the change to binutils.

Changing "+ 1" to "| 1" in the badr macro would be a universal
solution for all versions of binutils, but for a quick test with
binutils 2.29.1 you could simply remove the "+ 1" from the
CONFIG_THUMB2_KERNEL case (ie make the ARM and Thumb2 versions of the
macro identical).

  
https://github.com/torvalds/linux/blob/master/arch/arm/include/asm/assembler.h#L197
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Khem Raj]

On Mon, Apr 2, 2018 at 4:14 PM, Andre McCurdy  wrote:
> On Mon, Apr 2, 2018 at 1:15 PM, Chris Elledge
>  wrote:
>> I recently upgraded my Yocto based project to Yocto 2.4.2, and I encountered
>> a problem when building my custom kernel for an AT91 SAMA5D3X platform. I've
>> been using an ARM Thumb2 kernel for a while successfully until this release.
>> It appears that the issue stems from the change to binutils version 2.29.1.
>>
>> Here's a good description of the problem:
>> https://patchwork.kernel.org/patch/10072695/
>>
>> I tried out their test script, and it flagged the arm-poky-linux-gnueabi-
>> toolchain built by Yocto 2.4.2 as being buggy. Has anyone else encountered
>> this problem and figured out a way around it without disabling Thumb
>> compilation of the kernel?
>
> Thanks for bringing up this issue. Reading through the various bug
> reports etc it not clear what the fix should be. Upstream binutils has
> not reverted the change and the upstream kernel still appears to rely
> on the pre-2.29.1 binutils behaviour.
>
> The simplest solution for OE 2.4 would seem to be to revert the change
> in binutils (rev e645cf4, which was added very close to the 2.29.1
> release).

We should not apply this in upstream OE, but in general carrying such
a solution locally
is fine.

>
> Longer term, it looks like the kernel will have to be updated to work
> with the most recent versions of binutils. A possible approach for
> that is hinted at in the kernel patch you provided a link for, ie
> update the "badr" macro in arch/arm/include/asm/assembler.h to OR the
> sym address with 1 instead of adding 1. e.g. something like changing:
>
>   #ifdef CONFIG_THUMB2_KERNEL
>   adr\c \rd, \sym + 1
>   #else
>
> to
>
>   #ifdef CONFIG_THUMB2_KERNEL
>   adr\c \rd, \sym
>   orr\c \rd, \rd, #1
>   #else
>

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=52a86f843b6dee1de9977293da9786649b146b05

should have fixed ADR pseudo instruction so adding +1 is taken care of
in newer gas. I think doing a
orr is a safe bet to ensure that it works with all versions of gas+ld.

> The fact that it doesn't seem to have been fixed that way in the
> upstream kernel suggests that the kernel developers may be hoping to
> find a better solution though (ie one which avoids adding an extra
> instruction in the syscall fast path).
>
> So, without some more guidance from either upstream project, the best
> solution isn't clear. Perhaps you could try reverting the binutils
> change to get you up and running again in the short term and then ask
> on the ARM kernel mailing lists what the solution for Thumb2 with
> binutils >= 2.29.1 is expected to be?
> --
> ___
> 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] Setting a custom hostname using git revisions?

[Stephano Cetola]

On 4/4/18 9:13 AM, Stephano Cetola wrote:
> On 4/4/18 8:48 AM, Giordon Stark wrote:
>> Hi all,
>>
>> I looked at the bitbake manual, but if I have a custom layer that's
>> checked out at a specific revision, how can I access the variable
>> containing the revision to embed it into the hostname variable?
>>
>> I would want to append the hostname variable in:
>> recipes-core/base-files/base-files_%.bbappend which is currently set to
>> "${MACHINE}".
>>
>> Instead, I would like something along the lines of
>> "${MACHINE}-${LAYER_REV}".
>>
>> Thanks,
>>
>> Giordon
>> -- 
>> Giordon Stark
>>
>>
> 
> This is pretty tricky. I'd use a python function inside your recipe.
> 
> You can get the layers like this:
> 
> layers = (bb.data.getVar("BBLAYERS", d, 1) or "").split()
> 
> Then if you have a look at the metadata_scm.bbclass, you can use some of
> the functions in there:
> 
> base_get_metadata_git_branch
> base_get_metadata_git_revision
> 
> Add some logic and you should be able to pull the revision information
> you care about out of that data.
> 
> Cheers,
> Stephano
> 
> 
A rather elaborate example of how to get the revision number can be seen
here:

https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image-buildinfo.bbclass

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