Re: [yocto] Pyro's uninative and libstdc++ symbols

[Richard Purdie]

On Fri, 2017-08-25 at 14:50 +0200, Raphael Kubo da Costa wrote:
> I've recently updated my host system to Fedora 26, which has GCC 7.
> 
> This seems to be causing some issues on Pyro, where I have a -native
> recipe that is built with my system's g++ and ends up generating a
> binary with the following symbol:
> 
>   DF *UND*    GLIBCXX_3.4.23
> std::basic_string, std::allocator
> >::basic_string(std::string const&, unsigned long,
> std::allocator const&)
> 
> GLIBCXX_3.4.23 is not part of Pyro's uninative's libstdc++, so when
> that
> binary is invoked in another (non-native) recipe as part of
> do_configure
> it fails to run:
> 
> gn: /data/src/yocto/poky/build/tmp/sysroots-uninative/x86_64-
> linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.23' not found
> (required by gn)
> 
> Is there anything I should be doing differently here?

We need to update the uninative version in pyro to the more recent
version in master. uninative works on the principle that it the same
version or newer than the host system and for older releases this
ceases to be the case unless we upgrade it.

Cheers,

Richard

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

[yocto] Building multiple FIT images with different initramfs images

[Andersen, Christian]

Hello,

we are using signed FIT images to establish a verified boot system. Now I try 
to generate multiple FIT images, where every image contains another initramfs. 
The idea is to use a signed FIT image (loaded via TFTP) including a special 
ramdisk in our production line. This ramdisk only contains the code to copy the 
rootfs onto our eMMC. Another FIT image (the default one) will be included in 
our rootfs and used in all other cases (in the field).

Currently Yocto (kernel-fitimage.bbclass) only supports the variable 
INITRAMFS_IMAGE (which as far as I know, has to be set in the machine config). 
So I am not able to build a second FIT image with another initramfs image.

I did some (ugly) hacking on kernel.bbclass and kernel-fitimage.bbclass and 
created a new variable INITRAMFS_IMAGES, which may contain one or more 
different initramfs images. Using this approach I am now able to build multiple 
FIT images for one machine, which contain different ramdisks.

What do you think about such a feature? Is it something which might be 
integrated into mainline YP/OE?

Regards
Christian


KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin 
Kinzl, Dipl.-Oec. Andreas Kostal

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

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Burton, Ross]

On 24 August 2017 at 15:34, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Do you agree to continue keeping DNF package (in
> .../meta/recipe_devtools/) for handling of .rpm type of packages in the
> future releases of YOCTO (it is, after all, much better and more mature
> tool that smartpm)?
>

For all future releases, forever?  Committing to that would be foolish.

We have no plans to move from DNF to something else.  Luckily Yocto is open
source so if in a few years time a stable and superior alternative to DNF
appears and we move to it, you can continue to maintain the DNF recipes
yourself.

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

[yocto] error in apt-key add

[yahia farghaly]

I am building a linux image using yocto which support deb package
manager(apt-get). I created the repo with packages and i want to authorize
this repo to my target machine. i followed these steps
 for that
purpose. I created the keyFile successfully for the server (host). and when
transfer this keyFile to my target and execute apt-key add keyFile, it
promotes me the error

> /usr/bin/apt-key: line 352: comm: command not found



i use yocto pyro 17.0.1 and i built for core-image-sato plus adding the
recipe gnupg which exist in meta/recipes-support/gnupg

Why this error ? and possible ways to fix it ?

-- 
Yahia Farghaly
Graduated from Faculty of Engineering - Electronics and Communications
Department at Cairo University.
Linkedin  - GitHub

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

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Zoran Stojsavljevic]

> For all future releases, forever?  Committing to that would be foolish.

Nothing is forever, you know this at the best. Seemed/seems that Canon Lake
(supposed to be Core 7, now it is Core 9. or Core 10, or One only knows...
You name it) supposed to be out in Q3 2016, but INTEL did not reach
yielding on 10nm EUV(L) yet... Even Moore's Law is not forever (which INTEL
committed to FOREVER)!? Committing to that (Moore's Law), would be foolish
(Present Time), after all. Don't you agree? ;-)

I have all the rights to make mistakes... In lieu of above written by
yourself! Don't you agree (after my comments)?

> We have no plans to move from DNF to something else.  Luckily Yocto is
open source so if in a few years time a stable and
> superior alternative to DNF appears and we move to it, you can continue
to maintain the DNF recipes yourself.

I must say, that here, in this paragraph, I read true Words of Wisdom. I
would like to thank you for that. :-)

Zoran
___

On Tue, Aug 29, 2017 at 6:31 PM, Burton, Ross  wrote:

> On 24 August 2017 at 15:34, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Do you agree to continue keeping DNF package (in
>> .../meta/recipe_devtools/) for handling of .rpm type of packages in the
>> future releases of YOCTO (it is, after all, much better and more mature
>> tool that smartpm)?
>>
>
> For all future releases, forever?  Committing to that would be foolish.
>
> We have no plans to move from DNF to something else.  Luckily Yocto is
> open source so if in a few years time a stable and superior alternative to
> DNF appears and we move to it, you can continue to maintain the DNF recipes
> yourself.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Bare metal Ultibo with openjjpeg with TFTP Server & Remote shell

[Edward Vidal]

Hello All,This should work on either a RPi2B or RPi3BThe micro sd-card that I 
used was 8GB with 1 partition.A 4GB micro sd-card should work just as well.
Device     Boot Start     End Sectors Size Id Type/dev/sda1  *     2048 8390655 
8388608   4G  b W95 FAT32
https://github.com/develone/jpeg-2000-test/tree/master/bare-metal/openjp/sd-card
    these 5 files are needed on micro sd-card    bootcode.bin    fixup.dat    
MyBitmap.bmp This is a 2048 x 2048 lena in RGB format    start.elf    
kernel7.img This file was created with     Free Pascal Compiler FPC.
A monitor needs to be connected on the HDMI connector to display the 
bootprocess. The RJ-45 connector needs to be connected to network that 
providesDHCP and NTP services. If the RJ-45 is not connected it will take a 
bitlonger to boot and the TFTP & Remote shell will not be available.
This will require the transfer of files with USB apdater. 
         This is the latest version with a compression ratio of 125:1    
12583034 --> 100660    This will create the file test.j2k    tftp xx.xx.xx.xx   
 binary    get test.j2k    this md5sum should be    
c38b036fc5dbd84082f9490deb45c59e  test.j2k    running the test_tile_decoder     
~/t_ultibo/build/bin/test_tile_decoder 0 0 2048 2048 test.j2k    create 
test_wr.bmp    
https://github.com/develone/jpeg-2000-test/tree/master/bare-metal/openjp/decomp-sd-card
        Adding the files kernel7.img & t_1024_125r.j2k    to the sd-card.    
The file t_1024_125r.j2k on Raspbian    pi@raspberrypi3:~/t_ultibo/build/bin $ 
"./opj_compress -r 125 -i    ~/jpeg-2000-test/bare-metal/LibC/lena_rgb_1024.bmp 
-o t_1024_125r.j2k"    When rebooted the display will appear like 1024_1024.jpg 
   The file test_wr.bmp will be created on Ultibo RPi    Let me know if you 
have any questions.  I look forward to hearing your comments on this.I have 
tested with a compression of 400:1 which further reduces the image transfer to 
about a 0.1 sec. Edward Vidal Jr. e-mail devel...@sbcglobal.net 915-595-1613-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] building python3-posix-ipc on pyro

[Bill Randle]

I successfully built python3-posix-ipc_1.0.0 on morty several times
without error. When I tried to build it on pyro, using the exact same
bb file and source I get warnings which lead to incorrect behavior.
(Cross-compile for ARM.)

I know this recipe is not part of OE-Core, but I'm wondering if anyone
has tried to build it anyway or seen a similar problem.

This is my .bb file (loosely based on the recipe in meta-openstack,
which is for python2):

DESCRIPTION = "POSIX IPC primitives (semaphores, shared memory and
message queues) for Python"
HOMEPAGE = "http://semanchuk.com/philip/posix_ipc/";
SECTION = "devel/python"
LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://LICENSE;md5=d92bb5439aee694c0a87bfb51579e37b"

PR = "r0"

PYPI_PACKAGE = "posix_ipc"

SRC_URI[md5sum] = "85607a392087715ac3a3c7ded2492d06"
SRC_URI[sha256sum] =
"9c93070374ca672725575e5c9874930c8cde69367fb90378b2255e048e31efcb"

inherit pypi setuptools3

# RDEPENDS_default:
RDEPENDS_${PN} += " \
"
--

The head of the log.compile file on morty is:

DEBUG: Executing shell function do_compile
running build
running build_ext
building 'posix_ipc' extension
creating build
creating build/temp.linux-x86_64-3.5
--
While the head of log.do_compile on pyro looks like this:

DEBUG: Executing shell function do_compile
**
* Setup can't determine if it needs to link to the realtime libraries on your
* system, so it will default to 'no' which may not be correct.
*
* Please report this message and your operating system info to the package
* maintainer listed in the README file.
**
**
* Setup can't determine the value of PAGE_SIZE on your system, so it will
* default to 4096 which may not be correct.
*
* Please report this message and your operating system info to the package
* maintainer listed in the README file.
**
running build
running build_ext
building 'posix_ipc' extension
creating build
creating build/temp.linux-x86_64-3.5
--

Now the output on pyro totally makes sense when I look at setup.py
(which uses probe.py) because the probe function is trying to compile
a test file to see if librt is required or not. It's not surprising it
fails, since I'm building for ARM.

I can go in and patch the probe function so it returns Yes to indicate
librt is required, but my question why no error when building for
morty and what might have changed? As I said, the .bb file and the
source package are identical in both cases.

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