Re: [yocto] General Question: Device specific value store

[Morné Lamprecht]

On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
Is there a smart, recommended way to deal with device specific data (i.e.  
serial number, credentials for backend access, you name it), that is specific 
for *one* device, and hence does not belong into the rootfs. I know, that there 
are (safe) hardware stores for it, but what, if your device does not have one.


Not sure if I'm misunderstanding your question, but this should be part of your 
device commissioning process, i.e. like injecting specific security keys 
etc...so basically this will part of your image install / flash process, and not 
really part of the Yocto build process. The specifics of such a process would 
depend on your specific commissioning process.


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

[yocto] Failed Linux network getnameinfo

[JH]

Hi,

I can run following code in Ubuntu to print out the host address, but
I could not get host address (empty) in Yoctor imx6 build. That
function is POSIX compatible, what I could be missing?

struct sockaddr *addr; /* input */
socklen_t addrlen; /* input */
char hbuf[NI_MAXHOST];

if (getnameinfo(addr, addrlen, hbuf, sizeof(hbuf), NULL, 0, NI_NAMEREQD))
  printf("could not resolve hostname");
else
  printf("host=%s\n", hbuf);

Thank you.

Kind regards,

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

[yocto] Using AUTOREV in PV triggers FetchError

[Franz Forstmayr]

Hi,

i was using some simple recipes for kernel modules since rocko branch
successfully with AUTOREV and a release branch in my local gitlab
instance (over ssh). I was upgrading to thud these days, and now I'm
triggering some FetchErrors in recipes which are using AUTOREV.
My recipe looks like this:

inherit module

SRC_URI = "git://gitlab@gitlab.:protocol=ssh"

SRCREV = "${AUTOREV}"
PV = "1.0+git${SRCPV}"

S = "${WORKDIR}/git"

Is there something wrong with this?
Is there a better way than getting the last revision of my release branch?
Sometimes I get this error:

> WARNING: .../recipes-kernel/dma-proxy/dma-proxy_git.bb: Exception during 
> build_dependencies for WORKDIR   | ETA:  --:--:--
> WARNING: .../recipes-kernel/dma-proxy/dma-proxy_git.bb: Error during finalise 
> of .../recipes-kernel/dma-proxy/dma-proxy_git.bb
> ERROR: ExpansionError during parsing 
> .../recipes-kernel/dma-proxy/dma-proxy_git.bb 
> | ETA:  0:00:43
> Traceback (most recent call last):
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export PSEUDO_DISABLED=1; export 
> DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export 
> PATH="/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/layers/openembedded-core/scripts:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/bin/aarch64-poky-linux:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot/usr/bin/crossscripts:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/sbin:/home/ecs/Wor
 
kspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/sbin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/microblaze/lin/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/aarch64/l
 
in/aarch64-none/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/layers/poky/bitbake/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/hosttools";
 export HOME="/home/ecs"; git -c core.fsyncobjectfiles=0 ls-remote 
ssh://gitlab@blabla/Research_and_Development/RD_ECS/Drivers/dma-proxy.git  
failed with exit code 128, output:
> ssh_exchange_identification: Connection closed by remote host
> fatal: Could not read from remote repository.

> Please make sure you have the correct access rights
> and the repository exists.

> Summary: There were 2 WARNING messages shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.



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

[yocto] Remove include /usr/include/SDL2

[Mauro Ziliani]

Hi all.

I'm trying to compile kivy inside yocto for a 586 board.

The compilation fails because the i586-cc uses /usr/include and 
/usr/local/include paths as INCLUDEDIR (togheter with others paths)



How can avoid this?


I need /usr/include o /usr/local/include for other apps, but I don't 
like the /usr/include is involved in yocto



MZ

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

Re: [yocto] Remove include /usr/include/SDL2

[Burton, Ross]

The problem is that kivy is ignoring all of the attempts at telling it
to build in a sysroot and *still* looking in /usr.  This is a clear
cut bug in the kivy build system, so you'll have to look at that and
see how to fix it.

Ross

On Mon, 24 Jun 2019 at 18:32, Mauro Ziliani  wrote:
>
> Hi all.
>
> I'm trying to compile kivy inside yocto for a 586 board.
>
> The compilation fails because the i586-cc uses /usr/include and
> /usr/local/include paths as INCLUDEDIR (togheter with others paths)
>
>
> How can avoid this?
>
>
> I need /usr/include o /usr/local/include for other apps, but I don't
> like the /usr/include is involved in yocto
>
>
> MZ
>
> --
> ___
> 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] Are native packages dependencies listed in license.manifest?

[pierrelucbuhler]

Hi,

I’m currently working to remove all GPLv3 packages included in my image.

I was using the license manifest file to list the remaining GPLv3 packages to 
remove.

While I was trying to remove gdbm, I ecountered some native dependencies.

When I looked at the license.manifest file, gdbm was still listed.

So I was asking myself if I still had packages that depends/includes gdbm 
hidden somewhere or it’s because the license.manifest also list packages used 
on the build host even if they are not included in the image.

For example, if curl-native is used in a recipe will curl be listed in 
license.manifest even if curl is not in the image?




So in other words, does license.manifest also includes native packages or it 
only lists the packages that make up the image (included in the image)?




Thanks for the support,




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

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[sjolley.yp.pm]

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 283
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

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

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

Re: [yocto] Are native packages dependencies listed in license.manifest?

[Burton, Ross]

The image manifest lists what is being *distributed* so doesn't
include native dependencies.

Ross

On Mon, 24 Jun 2019 at 19:50,  wrote:
>
> Hi,
> I’m currently working to remove all GPLv3 packages included in my image.
> I was using the license manifest file to list the remaining GPLv3 packages to 
> remove.
> While I was trying to remove gdbm, I ecountered some native dependencies.
> When I looked at the license.manifest file, gdbm was still listed.
> So I was asking myself if I still had packages that depends/includes gdbm 
> hidden somewhere or it’s because the license.manifest also list packages used 
> on the build host even if they are not included in the image.
> For example, if curl-native is used in a recipe will curl be listed in 
> license.manifest even if curl is not in the image?
>
> So in other words, does license.manifest also includes native packages or it 
> only lists the packages that make up the image (included in the image)?
>
> Thanks for the support,
>
> PLB
>
> --
> ___
> 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] Dealing with line endings

[keith . derrick]

I am using an upstream repo with a mix of line endings.


In my recipe, I'm applying a patch with normalized line endings, as our meta 
layer repo has a .gitattributes with "text=auto" set.


The patch is failing due to "different line endings".


Can the git fetcher be configured to normalize line endings on unpack? I tried 
setting core.autocrlf in my global .gitconfig, but the fetcher/unpacker seems 
to ignore it.


Thanks

Keith

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

Re: [yocto] OPKG Spec

[Robert Joslyn]

On Sun, 2019-06-23 at 16:15 +0300, Adi Malca wrote:
> Hello,
> 
> I'm looking for the current official OPKG spec with spelling and case
> sensitive.
> For example:
> Package: 
> Version: 
> Description: 
> Section: 
> Priority: 
> Maintainer: 
> License: 
> Architecture: 
> OE: 
> Homepage:
> Depends: 
> Source: 
> Filename: 
> SHA1:
> SHA256:
> 
> Best Regards,
> Adi

I'm not sure if there is an official spec somewhere, but the structure
of the packages and server index files can be seen in the code. The
main opkg utility is here: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/

The helper scripts are also useful: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/

You can see the structure of the metadata you mention, including
spelling, capitalization, etc, here:
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c#n552

You can also see it here (perhaps more concisely):
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg.py#n491

The Packages and Packages.gz index files use these variables. For
example, this is what shows up in the index for busybox on one of my
builds:

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky 
MD5Sum: c0b45a09adec305b49153133a3392917
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

Packages can also use SHA256 rather than MD5.

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky 
SHA256sum:
3ca8d2dd79759fa34bf04a0ee97fef5e354d97da76b03672544f3c4eeef76ac9
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

I'm not sure if anyone has any package feeds built by Yocto publicly
available, but OpenWRT uses opkg as well, with public feeds available.
For example:
https://downloads.openwrt.org/releases/18.06.2/packages/aarch64_cortex-a53/base/


Robert

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