Re: [yocto] Create uncompressed rootfs

[Andre McCurdy]

On Tue, Nov 3, 2015 at 3:54 AM, Anders Darander  wrote:
> * Andre McCurdy  [151103 11:34]:
>
>> On Mon, Nov 2, 2015 at 11:05 PM, Anders Darander  
>> wrote:
>> > * Andre McCurdy  [151102 20:35]:
>
>> >> See the "IMAGE_TYPES" variable for a list of rootfs types which are
>> >> supported. There's support for creating an uncompressed .tar file, but
>> >> I don't see any support for creating a rootfs directory under
>> >> tmp/deploy.
>
>> > No, the usual workflow here is to unpack the tar'ed rootfs at a suitable
>> > location.
>
>> Indeed. I don't think it's what Roberto was asking for though...
>
> Well, sure, that wasn't what Roberto explicitly was asking for, though
> that's a safer way to do what he's after...
>
> After all, if you never learn about best practises, you'll never know...
>
>> >> Depending on your work flow there are a few different solutions
>> >> though. You could extend
>> >> openembedded-core/meta/classes/image_types.bbclass to do what you want
>> >> (e.g. define a new image type or hack "IMAGE_CMD_tar" so that it also
>> >> untars rootfs.tar right after creating it).
>
>> > Well, there's some issues with this approach. In order to uncompress the
>> > tarball and be able to set owner, group, and permissions on all files,
>> > you need to untar the rootfs with root privileges. The same is true when
>> > it comes to creating device nodes.
>
>> Enabling CONFIG_DEVTMPFS in the kernel is pretty standard, so for most
>> people there are no device nodes in the rootfs tarfile and /dev is an
>> empty directory.
>
> Sure, devtmpfs is pretty much standard, though it could nonetheless be
> good to know about.
>
>> Extracting rootfs tarfiles as an unprivileged user has always worked
>> fine for me. Do you have a specific example where root privileges are
>> required?
>
> Well, everything that requires a specific user and permissions. When it
> comes to permissions it's likely most if you need to setuid or setgid on
> binaries / files / directories.
>
> When you unpack as an unpriviliged user, every file will belong to you.
>
> Thus, the recommended (and safe) way to do this, is to unpack as a
> priviliged user.

Yes, you're right. If you everything on the target runs as root then
losing setuid flags isn't going to matter much, but it could be a
problem if the target needs to support non-privileged users.

> Cheers,
> Anders
>
> --
> Anders Darander
> ChargeStorm AB / eStorm AB
> --
> ___
> 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] raspberry pi do rootfs

[Andrei Gherzan]

--
Andrei Gherzan

On Tue, Nov 3, 2015 at 5:47 AM, Raj Jar  wrote:

> I got this error when i do bitbake rpi-hwup-image
> I suspect error come from mcopy .
> how to recover this error
> MACHINE ?="raspberry pi"
>
>
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: Error: The image creation script
> '/home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/work/raspberrypi-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/temp/create_image.rpi-sdimg'
> returned 1:
> Creating filesystem with Boot partition 20480 KiB and RootFS 77824 KiB
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 7.4427e-05 s, 0.0 kB/s
> Model:  (file)
> Disk
> /home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/deploy/images/raspberrypi/rpi-hwup-image-raspberrypi-20151102024300.rootfs.rpi-sdimg:
> 105MB
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
> Disk Flags:
>
> Number  Start   End SizeType File system  Flags
>  1  4194kB  25.2MB  21.0MB  primary   boot, lba
>  2  25.2MB  105MB   79.7MB  primary
>
> mkfs.vfat 2.11 (12 Mar 2005)
> Disk full
>

Make some space for your build.


> WARNING:
> /home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/work/raspberrypi-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/temp/create_image.rpi-sdimg:1
> exit 1 from
>   mcopy -i
> /home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/work/raspberrypi-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/boot.img
> -s
> /home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/deploy/images/raspberrypi/Image-raspberrypi.bin
> ::kernel.img
>
> ERROR: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /home/raj/Projects/raspberry_pi/yacto/poky/raspberrypi_build/tmp/work/raspberrypi-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/temp/log.do_rootfs.13457
> ERROR: Task 7
> (/home/raj/Projects/raspberry_pi/yacto/poky/meta-raspberrypi/recipes-core/images/
> rpi-hwup-image.bb, do_rootfs) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1954 tasks of which 1953 didn't need to be
> rerun and 1 failed.
> No currently running tasks (1953 of 1955)
>
> Summary: 1 task failed:
>
> /home/raj/Projects/raspberry_pi/yacto/poky/meta-raspberrypi/recipes-core/images/
> rpi-hwup-image.bb, do_rootfs
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
>
>
>
> --
> ___
> 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] [dizzy branch] License list fails with rpm with package shared between two arch

[scerveau]

Dear all,

I'm having a machine A and a machine B.

This two machines are built against the same image class and in the same 
build folder.


But on machine A there is a recipe LAMBDA which is not include in 
machine B.
The package LAMBDA is shared in the same folder 
cortexa9hf_vfp_neon(Machine A and B use the same imx arch)


If i build machine A(everything is ok) and then machine B, during the 
last recipe execution image rootfs of machine B, a list of package is 
performed to build the license list with this missing package which 
finally fails saying that license folder does not exist. I guess the rpm 
package list  performed in poky/lib/oe/package_manager.py is not correct 
and should be done according to the image instead of the list of files 
in the folder cortexa9hf_vfp_neon.


I found a hack by putting my recipe LAMBDA dependent to my machine so 
the package is not in cortexa9hf_vfp_neon anymore.


If someone could help me on this issue, it would be very nice because i 
guess there is something wrong in yocto base tools.


BR.

Stephane






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

[yocto] yocto on zynq, How to configure kernel to include drivers

[Toby Gomersall]

I'm quite new to yocto so still have a lot to learn. I'm trying to
include the DMA drivers in my yocto build for a Zynq based on the
meta-xilinx layer (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/).

I thought I'd be able to add them in the kernel configuration
(menuconfig) by running (from within the build directory):

bitbake linux-xlnx -c kernel_configme -f
bitbake linux-xlnx -c menuconfig

I can't see the DMA drivers in menuconfig. However if I run menuconfig
within the linux-xlnx tree (which is referenced by the SRCURI) I can see
the DMA drivers. Is there some reason they're hidden in the build
menuconfig?

Thanks,
Toby




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

Re: [yocto] yocto on zynq, How to configure kernel to include drivers

[Philip Balister]

On 11/04/2015 08:35 AM, Toby Gomersall wrote:
> I'm quite new to yocto so still have a lot to learn. I'm trying to
> include the DMA drivers in my yocto build for a Zynq based on the
> meta-xilinx layer (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/).

You should try emailing this list for meta-xilinx specific issues.

https://lists.yoctoproject.org/listinfo/meta-xilinx

Philip

> 
> I thought I'd be able to add them in the kernel configuration
> (menuconfig) by running (from within the build directory):
> 
> bitbake linux-xlnx -c kernel_configme -f
> bitbake linux-xlnx -c menuconfig
> 
> I can't see the DMA drivers in menuconfig. However if I run menuconfig
> within the linux-xlnx tree (which is referenced by the SRCURI) I can see
> the DMA drivers. Is there some reason they're hidden in the build
> menuconfig?
> 
> Thanks,
> Toby
> 
> 
> 
> 



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

Re: [yocto] yocto on zynq, How to configure kernel to include drivers

[Toby Gomersall]

Hi,

We've tried building the linux-xlnx tree standalone and we have the DMA
drivers available to add in menuconfig but not when I build
core-image-minimal. I thought the full build would pick up the
linux-xlnx kernel and make the same options available. Is there
something I need to do to make them available?

Regards,
Toby

On 04/11/15 13:47, Hecht, Martin (Silica) wrote:
> Hi Toby,
> 
> Please compare with http://www.wiki.xilinx.com/Linux+Drivers. Most of the DMA 
> drivers aren't mainlined by now. You need to add them by yourself currently.
> 
> Regards,
> Martin
> 
> 
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of Toby Gomersall
> Sent: Mittwoch, 4. November 2015 14:44
> To: yocto@yoctoproject.org
> Subject: [yocto] yocto on zynq, How to configure kernel to include drivers
> 
> I'm quite new to yocto so still have a lot to learn. I'm trying to include 
> the DMA drivers in my yocto build for a Zynq based on the meta-xilinx layer 
> (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/).
> 
> I thought I'd be able to add them in the kernel configuration
> (menuconfig) by running (from within the build directory):
> 
> bitbake linux-xlnx -c kernel_configme -f bitbake linux-xlnx -c menuconfig
> 
> I can't see the DMA drivers in menuconfig. However if I run menuconfig within 
> the linux-xlnx tree (which is referenced by the SRCURI) I can see the DMA 
> drivers. Is there some reason they're hidden in the build menuconfig?
> 
> Thanks,
> Toby
> 
> 



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

Re: [yocto] yocto on zynq, How to configure kernel to include drivers

[Nathan Rossi]

On Thu, Nov 5, 2015 at 12:20 AM, Toby Gomersall
 wrote:
> Hi,
>
> We've tried building the linux-xlnx tree standalone and we have the DMA
> drivers available to add in menuconfig but not when I build
> core-image-minimal. I thought the full build would pick up the
> linux-xlnx kernel and make the same options available. Is there
> something I need to do to make them available?

By default the linux-xlnx configs within meta-xilinx are close as
possible to mainline configuration. In this case the only Xilinx DMA
driver enabled by default is the VDMA driver as it is available both
in linux-xlnx and in mainline/linux-yocto. It has been done this way
to ensure users understanding that they are using a driver that may
disappear in future linux-xlnx versions or be changed for upstream
submission.

To configure these linux-xlnx only drivers, you can use the "-c
menuconfig" and have your changes made temporarily (The drivers are
under 'Device Drivers / DMA Engine support / Xilinx DMA Engines').

Or you can use the config fragment available in meta-xilinx by setting
KERNEL_FEATURES up with the fragment (the fragment enables a few of
linux-xlnx only drivers). Adding the following line to your machine's,
distro's your local .conf depending on your requirements:

KERNEL_FEATURES += "bsp/xilinx/xilinx-drivers-linux-xlnx.scc"

Just on a side note, there was a bug in the .scc file, I have just
fixed it in master (and fido). So you will need to pull to use this or
it will give you an error.

Regards,
Nathan

>
> Regards,
> Toby
>
> On 04/11/15 13:47, Hecht, Martin (Silica) wrote:
>> Hi Toby,
>>
>> Please compare with http://www.wiki.xilinx.com/Linux+Drivers. Most of the 
>> DMA drivers aren't mainlined by now. You need to add them by yourself 
>> currently.
>>
>> Regards,
>> Martin
>>
>>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
>> On Behalf Of Toby Gomersall
>> Sent: Mittwoch, 4. November 2015 14:44
>> To: yocto@yoctoproject.org
>> Subject: [yocto] yocto on zynq, How to configure kernel to include drivers
>>
>> I'm quite new to yocto so still have a lot to learn. I'm trying to include 
>> the DMA drivers in my yocto build for a Zynq based on the meta-xilinx layer 
>> (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/).
>>
>> I thought I'd be able to add them in the kernel configuration
>> (menuconfig) by running (from within the build directory):
>>
>> bitbake linux-xlnx -c kernel_configme -f bitbake linux-xlnx -c menuconfig
>>
>> I can't see the DMA drivers in menuconfig. However if I run menuconfig 
>> within the linux-xlnx tree (which is referenced by the SRCURI) I can see the 
>> DMA drivers. Is there some reason they're hidden in the build menuconfig?
>>
>> Thanks,
>> Toby
>>
>>
>
>
> --
> ___
> 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] [PATCH 1/1] Fix AARCH64_TLSDESC relocation conflict

[Vaneet Narang]

On 11/3/15 5:44 AM, Manjeet Pawar wrote:
>> This patch needs to be applied to 'cross_prelink_aarch64' branch.
>> It fixes tls1, tls2, tls4, tls5, tls6 test cases of prelink testsuite.
>> tls3 gets failed but this test case fails without prelink as well on AARCH64
>
>I'm still getting segfaults here.
>
>The way I am testing is building a Yocto Project (jethro) system
>core-image-base, and adding to it:
>"packagegroup-core-buildessential,libelf,elfutils-dev,binutils-staticdev,glibc-staticdev"
>
>The copying a checked out version of the prelink-cross repository with the
>prelink_cross_aarch64 branch checked out.
>
>On the target:
>
>autoreconf -if
>./configure
>make
>make -C testsuite check
>
>Most tests still fail, and all of the TLS tests result in a segfault.
>
>(I do have the 'aarch64/dl-machine.h: Fix load-address for prelink support'
>applied to my glibc.  Are there any other patches that may need to be applied?)
>
>--Mark
Hi Mark,

Apart from fixing load-address changes, I have done one more change in 
_dl_tlsdesc_undefweak function 
of loader to handle AARCH64_TLSDESC relocation type. Samething I have mentioned 
in patch description of 
[PATCH 1/1] prelink: AARCH64 support added. This is kind of a quick fix, so I 
am open to suggestion regarding proper fix.

Change done in _dl_tlsdesc_undefweak
--- a/ports/sysdeps/aarch64/dl-tlsdesc.S
+++ b/ports/sysdeps/aarch64/dl-tlsdesc.S
@@ -98,7 +98,6 @@ _dl_tlsdesc_undefweak:
cfi_adjust_cfa_offset(16)
ldr x0, [x0, #8]
mrs x1, tpidr_el0
-   sub x0, x0, x1
ldr x1, [sp], #16
cfi_adjust_cfa_offset(16)
RET


Reason for this change: 
To handle AARCH64_TLSDESC, I have referred  below patch which state create a 
conflict for TLSDESC.
[yocto] [prelink-cross][PATCH] Always create a conflict for R_ARM_TLS_DESC 
relocs. 
http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_aarch64&id=faa069deec99bf61418d0bab831c83d7c1b797ca

I have done the same implementation for AARCH64.  Loader handles 
AARCH64_TLSDESC conflict as below.
case R_AARCH64_TLSDESC:

if (! sym)
  {
td->arg = (void*)reloc->r_addend;
td->entry = _dl_tlsdesc_undefweak;
  }
 
After this change, all the access to __thread variable will end up calling 
_dl_tlsdesc_undefweak function. 
_dl_tlsdesc_undefweak returns addend minus  thread pointer but access to 
__thread expects only addend as per assembly. 
So removed subtraction operation from code.

Example of simple __thread variable getting accessed in shared library.
__thread int i = 10;
dummy() {
printf("Value of i %d \n",i);
}

Objdump of above code:
088c :
 890:   d53bd041mrs x1, tpidr_el0   // Read coprocessor register for thread 
pointer. x1 will contain thread pointer
 894:   9080adrpx0, 1 <__FRAME_END__+0xf628>
 898:   f9462802ldr x2, [x0,#3152]  // Read .got.plt section to fetch 
address of tls handler (_dl_tlsdesc_undefweak)
 89c:   91314000add x0, x0, #0xc50
 8a0:   d63f0040blr x2   // Function call to _dl_tlsdesc_undefweak, after 
fuction call x0 will contain addend - thread pointer
 8a4:   910003fdmov x29, sp
 8a8:   9002adrpx2, 0 
 8ac:   a8c17bfdldp x29, x30, [sp],#16
 8b0:   b8606821ldr w1, [x1,x0] // Access to x0 (addend - thread pointer) + 
x1 (thread pointer). Access to addend will result seg fault
 8b4:   91234040add x0, x2, #0x8d0
 8b8:   17aab   760 

So change done in loader to make _dl_tlsdesc_undefweak return only addend.

Thanks & Regards,
Vaneet Narang
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto on zynq, How to configure kernel to include drivers

[Hecht, Martin (Silica)]

Hi Toby,

Please compare with http://www.wiki.xilinx.com/Linux+Drivers. Most of the DMA 
drivers aren't mainlined by now. You need to add them by yourself currently.

Regards,
Martin


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Toby Gomersall
Sent: Mittwoch, 4. November 2015 14:44
To: yocto@yoctoproject.org
Subject: [yocto] yocto on zynq, How to configure kernel to include drivers

I'm quite new to yocto so still have a lot to learn. I'm trying to include the 
DMA drivers in my yocto build for a Zynq based on the meta-xilinx layer 
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/).

I thought I'd be able to add them in the kernel configuration
(menuconfig) by running (from within the build directory):

bitbake linux-xlnx -c kernel_configme -f bitbake linux-xlnx -c menuconfig

I can't see the DMA drivers in menuconfig. However if I run menuconfig within 
the linux-xlnx tree (which is referenced by the SRCURI) I can see the DMA 
drivers. Is there some reason they're hidden in the build menuconfig?

Thanks,
Toby


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

[yocto] Trying to build tools for Cortex A9 Dora failure on Ubuntu 15 using gcc 5.2

[Jeff Waller]

There are probably a number of things wrong including some configuration errors 
I’ve made being that
I’m just getting started.  My ultimate goal is to cross-compile tools to 
augment the OS running on a
3DR Solo drone, here’s the doc on linux binary builds as you can see it’s 
minimal, but I’ve read elsewhere
that the processor is Cortex-A9 based at least, and it looks like it’s poky 1.5 
which I think is
Dora

http://dev.3dr.com/advanced-linux.html 

Like I said, I’m just getting started and totally new at this, so I’m pretty 
much following the Yocto
Linux guide

http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html 


But am getting build errors, Now I do recognize this as a possible problem, and 
maybe need to use ubuntu
14 instead.  

jeffw@chill:~/src/poky/build$ bitbake core-image-sato
WARNING: Host distribution "Ubuntu-15.10" has not been validated with this 
version of the build system; you may possibly experience unexpected failures. 
It is recommended that you use a tested distribution.


Summary: 5 tasks failed:
  
virtual:native:/home/jeffw/src/poky/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb,
 do_compile
  
virtual:native:/home/jeffw/src/poky/meta/recipes-support/libgpg-error/libgpg-error_1.12.bb,
 do_compile
  virtual:native:/home/jeffw/src/poky/meta/recipes-core/ncurses/ncurses_5.9.bb, 
do_compile
  /home/jeffw/src/poky/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb, 
do_compile
  
virtual:native:/home/jeffw/src/poky/meta/recipes-devtools/binutils/binutils_2.23.2.bb,
 do_compile


But I think rather that ubuntu being the problemI think many (perhaps all?) of 
these errors are due to gcc 5.2

specifically:


jeffw@chill:~/src/poky/build$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) 


The pseudo failure:

 pseudo_util.c:101:29: error: initializer element is not constant
|   static size_t unload_len = strlen(unload);
|  ^
| Makefile:121: recipe for target 'pseudo_util.o' failed


For libgpg this looks like a syntax error or maybe there’s a define that does 
not exist?:

| ./mkerrcodes.h:134:5: error: expected expression before ',' token
|{ , "GPG_ERR_EXFULL" },
|  ^
| Makefile:1043: recipe for target 'mkerrcodes' failed
| make[2]: *** [mkerrcodes] Error 1

ncurses fail:

 In file included from 
/home/jeffw/src/poky/build/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/curses.priv.h:283:0,
|  from ../ncurses/lib_gen.c:19:
| _19066.c:835:15: error: expected ')' before 'int'
| ../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo'
|  #define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen)


Localdef:

 argp-help.c:(.text+0x1e00): multiple definition of `argp_fmtstream_write'
| argp-fmtstream.o:argp-fmtstream.c:(.text+0x7a0): first defined here
| argp-help.o: In function `argp_fmtstream_puts':
| argp-help.c:(.text+0x1e50): multiple definition of `argp_fmtstream_puts'
| argp-fmtstream.o:argp-fmtstream.c:(.text+0x860): first defined here
etc…


And finally binutils:

| 
/home/jeffw/src/poky/build/tmp/work/x86_64-linux/binutils-native/2.23.2-r4/binutils-2.23.2/bfd/elf64-alpha.c:3588:11:
 error: switch condition has boolean value [-Werror=switch-bool]
|switch (!dynamic && !info->link_info->shared)
|^








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

[yocto] Unable to modify patch files in u-boot recipe - quilt applies direct from layer files

[Chris Hallinan]

Hi,

I was trying to "patch a patch" in a u-boot recipe using standard
bbappends technique.  I added a task before do_patch after do_unpack
to munge the patch that was broken.  Here is what seems to happen:

do_unpack:
copies all the patch files from the metadata layer into ${WORKDIR}

do_fix_patch (my additional task)
uses sed or patch to apply a local fix to a broken patch in ${WORKDIR}

do_patch
creates a subdirectory in ${S} called "patches", and puts links to
the actual files in the layer and uses those links back to the layer
files to apply the patches.

It seems quilt is using the actual layer files instead of the ones in
${WORKDIR}??

This seems odd and somehow wrong.  We copy the layer files into
WORKDIR, and the unsuspecting user (me) thinks those are the files
that do_patch will use.

This one took me some time (and help) to figure out!

Comments?  Is this a bug?  halfway in the middle of some architectural
changes?  Expected behavior?

My workaround was to simply replace the entire patch.

-Chris

-- 
Life is like Linux - it never stands still.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trying to build tools for Cortex A9 Dora failure on Ubuntu 15 using gcc 5.2

[Philip Balister]

On 11/04/2015 01:08 PM, Jeff Waller wrote:
> There are probably a number of things wrong including some configuration 
> errors I’ve made being that
> I’m just getting started.  My ultimate goal is to cross-compile tools to 
> augment the OS running on a
> 3DR Solo drone, here’s the doc on linux binary builds as you can see it’s 
> minimal, but I’ve read elsewhere
> that the processor is Cortex-A9 based at least, and it looks like it’s poky 
> 1.5 which I think is
> Dora

Only recently could we do builds on gcc5 machines. The -native recipes
are built with host gcc and not everything would build without patches.

I'd build a vm with an "older" Linux distro and build there.

Philip

> 
> http://dev.3dr.com/advanced-linux.html 
> 
> 
> Like I said, I’m just getting started and totally new at this, so I’m pretty 
> much following the Yocto
> Linux guide
> 
> http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html 
> 
> 
> But am getting build errors, Now I do recognize this as a possible problem, 
> and maybe need to use ubuntu
> 14 instead.  
> 
> jeffw@chill:~/src/poky/build$ bitbake core-image-sato
> WARNING: Host distribution "Ubuntu-15.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> 
> 
> Summary: 5 tasks failed:
>   
> virtual:native:/home/jeffw/src/poky/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb,
>  do_compile
>   
> virtual:native:/home/jeffw/src/poky/meta/recipes-support/libgpg-error/libgpg-error_1.12.bb,
>  do_compile
>   
> virtual:native:/home/jeffw/src/poky/meta/recipes-core/ncurses/ncurses_5.9.bb, 
> do_compile
>   
> /home/jeffw/src/poky/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb, 
> do_compile
>   
> virtual:native:/home/jeffw/src/poky/meta/recipes-devtools/binutils/binutils_2.23.2.bb,
>  do_compile
> 
> 
> But I think rather that ubuntu being the problemI think many (perhaps all?) 
> of these errors are due to gcc 5.2
> 
> specifically:
> 
> 
> jeffw@chill:~/src/poky/build$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-5 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-multiarch --disable-werror --with-arc
h-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) 
> 
> 
> The pseudo failure:
> 
>  pseudo_util.c:101:29: error: initializer element is not constant
> |   static size_t unload_len = strlen(unload);
> |  ^
> | Makefile:121: recipe for target 'pseudo_util.o' failed
> 
> 
> For libgpg this looks like a syntax error or maybe there’s a define that does 
> not exist?:
> 
> | ./mkerrcodes.h:134:5: error: expected expression before ',' token
> |{ , "GPG_ERR_EXFULL" },
> |  ^
> | Makefile:1043: recipe for target 'mkerrcodes' failed
> | make[2]: *** [mkerrcodes] Error 1
> 
> ncurses fail:
> 
>  In file included from 
> /home/jeffw/src/poky/build/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/curses.priv.h:283:0,
> |  from ../ncurses/lib_gen.c:19:
> | _19066.c:835:15: error: expected ')' before 'int'
> | ../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo'
> |  #define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen)
> 
> 
> Localdef:
> 
>  argp-help.c:(.text+0x1e00): multiple definition of `argp_fmtstream_write'
> | argp-fmtstream.o:argp-fmtstream.c:(.text+0x7a0): first defined here
> | argp-help.o: In function `argp_fmtstream_puts':
> | argp-help.c:(.text+0x1e50): multiple definition of `argp_fmtstream_puts'
> | argp-fmtstream.o:argp-fmtstream.c:(.text+0x860): first defined here
> etc…
> 
>

[yocto] [PATCH] maintainers: mass reassign and cleanup

[Ross Burton]

Remove several people who no longer should be considered owners of recipes,
reassign more to the new distro team, add new recipes and prune removed ones.

Signed-off-by: Ross Burton 
---
 meta-yocto/conf/distro/include/maintainers.inc | 701 +
 1 file changed, 352 insertions(+), 349 deletions(-)

diff --git a/meta-yocto/conf/distro/include/maintainers.inc 
b/meta-yocto/conf/distro/include/maintainers.inc
index df8b647..7838954 100644
--- a/meta-yocto/conf/distro/include/maintainers.inc
+++ b/meta-yocto/conf/distro/include/maintainers.inc
@@ -28,87 +28,90 @@
 # Please keep this list in alphabetical order.
 #
 RECIPE_MAINTAINER_pn-acl = "Chen Qi "
-RECIPE_MAINTAINER_pn-acpid = "Aníbal Limón "
-RECIPE_MAINTAINER_pn-adt-installer = "Jessica Zhang "
+RECIPE_MAINTAINER_pn-acpid = "Maxin B. John "
+RECIPE_MAINTAINER_pn-adt-installer = "Randy Witt 
"
 RECIPE_MAINTAINER_pn-adwaita-icon-theme = "Jussi Kukkonen 
"
-RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen 
"
-RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen 
"
-RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen 
"
-RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen 
"
-RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen 
"
-RECIPE_MAINTAINER_pn-apmd = "Cristian Iorga "
+RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-apmd = "Maxin B. John "
 RECIPE_MAINTAINER_pn-apr = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-apt = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-aspell = "Alejandro Hernandez 
"
-RECIPE_MAINTAINER_pn-atk = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-at = "Chen Qi "
 RECIPE_MAINTAINER_pn-at-spi2-atk = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-at-spi2-core = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-atk = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-attr = "Chen Qi "
-RECIPE_MAINTAINER_pn-augeas = "Paul Eggleton "
+RECIPE_MAINTAINER_pn-augeas = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-autoconf = "Robert Yang "
-RECIPE_MAINTAINER_pn-autogen = "Robert Yang "
+RECIPE_MAINTAINER_pn-autogen-native = "Robert Yang "
 RECIPE_MAINTAINER_pn-automake = "Robert Yang "
-RECIPE_MAINTAINER_pn-avahi-ui = "Paul Eggleton "
-RECIPE_MAINTAINER_pn-avahi = "Paul Eggleton "
-RECIPE_MAINTAINER_pn-babeltrace = "Ross Burton "
+RECIPE_MAINTAINER_pn-avahi = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-avahi-ui = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-base-files = "Ross Burton "
 RECIPE_MAINTAINER_pn-base-passwd = "Ross Burton "
 RECIPE_MAINTAINER_pn-bash = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-bc = "Alejandro Hernandez 
"
-RECIPE_MAINTAINER_pn-bdwgc = "Richard Purdie 
"
+RECIPE_MAINTAINER_pn-bdwgc = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-beecrypt = "Chen Qi "
-RECIPE_MAINTAINER_pn-bigreqsproto = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-bigreqsproto = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-bind = "Kai Kang "
 RECIPE_MAINTAINER_pn-binutils = "Robert Yang "
 RECIPE_MAINTAINER_pn-bison = "Chen Qi "
-RECIPE_MAINTAINER_pn-blktool = "Paul Eggleton "
-RECIPE_MAINTAINER_pn-blktrace = "Tom Zanussi "
-RECIPE_MAINTAINER_pn-bluez5 = "Cristian Iorga "
-RECIPE_MAINTAINER_pn-boost = "Ross Burton "
-RECIPE_MAINTAINER_pn-btrfs-tools = "Richard Purdie 
"
+RECIPE_MAINTAINER_pn-bjam-native = "Alexander Kanavin 
"
+RECIPE_MAINTAINER_pn-blktool = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-blktrace = "Alexander Kanavin 
"
+RECIPE_MAINTAINER_pn-bluez5 = "Maxin B. John "
+RECIPE_MAINTAINER_pn-boost = "Alexander Kanavin "
+RECIPE_MAINTAINER_pn-btrfs-tools = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-build-appliance-image = "Cristian Iorga 
"
 RECIPE_MAINTAINER_pn-build-compare = "Randy Witt 
"
 RECIPE_MAINTAINER_pn-builder = "Cristian Iorga "
+RECIPE_MAINTAINER_pn-buildtools-tarball = "Cristian Iorga 
"
 RECIPE_MAINTAINER_pn-busybox = "Chen Qi "
 RECIPE_MAINTAINER_pn-byacc = "Chen Qi "
 RECIPE_MAINTAINER_pn-bzip2 = "Chen Qi "
-RECIPE_MAINTAINER_pn-ca-certificates = "Ross Burton "
+RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-cairo = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-calibrateproto = "Jussi Kukkonen 
"
 RECIPE_MAINTAINER_pn-ccache = "Wenzong Fan "
-RECIPE_MAINTAINER_pn-cdrtools = "Paul Eggleton "
+RECIPE_MAINTAINER_pn-cdrtools-native = "Jussi Kukkonen 
"
 RECIPE_MAINTAINER_pn-chkconfig = "Wenzong Fan "
 RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Wenzong Fan 
"
-RECIPE_MAINTAINER_pn-chrpath = "Paul Eggleton "
+RECIPE_MAINTAINER_pn-chrpath = "Jussi Kukkonen "
+RECIPE_MAINTAINER_pn-clutter-1.0 = "Jussi Kukkonen "
 RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Jussi Kukkonen 
"
 RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Jussi K

Re: [yocto] Unable to modify patch files in u-boot recipe - quilt applies direct from layer files

[Khem Raj]

> On Nov 4, 2015, at 11:57 AM, Chris Hallinan  wrote:
> 
> Hi,
> 
> I was trying to "patch a patch" in a u-boot recipe using standard
> bbappends technique.  I added a task before do_patch after do_unpack
> to munge the patch that was broken.  Here is what seems to happen:
> 
> do_unpack:
>copies all the patch files from the metadata layer into ${WORKDIR}
> 
> do_fix_patch (my additional task)
>uses sed or patch to apply a local fix to a broken patch in ${WORKDIR}
> 
> do_patch
>creates a subdirectory in ${S} called "patches", and puts links to
> the actual files in the layer and uses those links back to the layer
> files to apply the patches.
> 
> It seems quilt is using the actual layer files instead of the ones in
> ${WORKDIR}??
> 
> This seems odd and somehow wrong.  We copy the layer files into
> WORKDIR, and the unsuspecting user (me) thinks those are the files
> that do_patch will use.
> 
> This one took me some time (and help) to figure out!
> 
> Comments?  Is this a bug?  halfway in the middle of some architectural
> changes?  Expected behavior?

while what you are doing is quite questionable. You seem to have a point. Most 
probably
copy of the files in workdir should be removed from happening.

> 
> My workaround was to simply replace the entire patch.

you should use the quilt workflow and edit/refresh the patch once and copy it 
back to metadata once for all yes.

> 
> -Chris
> 
> --
> Life is like Linux - it never stands still.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sdcard image does not get updated when I clean u-boot

[Roberto]

Hi All,

 

I have just noticed that if I execute

bitbake u-boot -c clean

 

and then

bitbake fsl-image-x11 

 

The u-boot file in tmp/deploy/images// gets updated, but the .sdcard
image file does not get updated.

 

How can I generate the new .sdcard image file that contains the new u-boot
image file?

 

Regards,

Roberto.

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

Re: [yocto] sdcard image does not get updated when I clean u-boot

[Khem Raj]

> On Nov 4, 2015, at 7:32 PM, Roberto  wrote:
> 
> Hi All,
> 
> I have just noticed that if I execute
> bitbake u-boot –c clean
> 
> and then
> bitbake fsl-image-x11
> 
> The u-boot file in tmp/deploy/images// gets updated, but the .sdcard 
> image file does not get updated.
> 
> How can I generate the new .sdcard image file that contains the new u-boot 
> image file?

you can set the relevant task which is generating the .sdcard image as nostamp 
task


> 
> Regards,
> Roberto.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto