Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

Please keep the thread on list and avoid pm.

as I said you need

1. Write a recipe for your package
2. in do_install of the recipe you want to mention where it should be 
placed e.g.


install -D -m 0755  ${D}${bindir}/

would put it in /usr/bin on target when this package is included in image

3. Include the package in image via IMAGE_INSTALL



On 5/23/19 10:13 PM, Tg, Harish wrote:

Hi Raj,
 Another question I have is where do I place my custom "ubiattach" 
command. Also I am not sure from where does the yocto builds the rootfs /usr/bin 
components. Where do they copied from?

Thanks,
Harish.

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, May 24, 2019 7:07 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95



On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
   I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we do not 
have a database for mapping. Maybe it is a good thing to have

for your problem ubiattach is provided by mtd-utils-ubifs which is built from 
mtd-utils recipe. I found it via above tool

% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of
yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoprojec
t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAf
VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YY
Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

 1. GPLv3 package present in rootfs (virendra kumar thakur)
 2. Building single package as image, respecting dependencies
(Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part -- An HTML attachment was
scrubbed...
URL:


--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
VIRTUAL-RUNTIME_dev_manager = ""
VIRTUAL-RUNTIME_login_manager = ""
VIRTUAL-RUNTIME_init_manager = ""
VIRTUAL-RUNTIME_initscripts = ""

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

That could be done by writing a recipe to build and/or package your 
version. So look how to write a new recipe, if its prebuilt you just 
might be able to package it using do_install() step in your recipe


and then add that package to IMAGE_INSTALL

see 
https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles


especially section  "Build an example package based on a remote source 
archive"



On 5/23/19 9:58 PM, Tg, Harish wrote:

Hi Raj,
  My ubiattach is separate one which works for our project. Its not 
part of ubifs package. I need to place that in /usr/bin rootfs image. Also I 
couldn’t find the place where I need to copy this ubiattach command. You can 
take this as custom ubiattach command. I could locate local.conf but there is 
no IMAGE_INSTALL_append in it. I do not have clear idea. Please clarify.

Thanks,
Harish.

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, May 24, 2019 7:07 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95



On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
   I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we do not 
have a database for mapping. Maybe it is a good thing to have

for your problem ubiattach is provided by mtd-utils-ubifs which is built from 
mtd-utils recipe. I found it via above tool

% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of
yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoprojec
t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAf
VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YY
Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

 1. GPLv3 package present in rootfs (virendra kumar thakur)
 2. Building single package as image, respecting dependencies
(Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part -- An HTML attachment was
scrubbed...
URL:


--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Tg, Harish]

Hi Raj,
 My ubiattach is separate one which works for our project. Its not 
part of ubifs package. I need to place that in /usr/bin rootfs image. Also I 
couldn’t find the place where I need to copy this ubiattach command. You can 
take this as custom ubiattach command. I could locate local.conf but there is 
no IMAGE_INSTALL_append in it. I do not have clear idea. Please clarify.

Thanks,
Harish.

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Friday, May 24, 2019 7:07 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95



On 5/23/19 5:59 AM, Tg, Harish wrote:
> Hi,
>   I have a question. How to add commands like "ubiattach" to /usr/bin of 
> rootfs image. I struggling with the recipes. I do not want to write my own 
> recipe but I need to edit some recipe and add the command. Which is the 
> place? I am using yocto for my project on TI platform and Linux.
> Kindly help.
> 

There is oe-pkgdata-util which can help to map files to recipes but we do not 
have a database for mapping. Maybe it is a good thing to have

for your problem ubiattach is provided by mtd-utils-ubifs which is built from 
mtd-utils recipe. I found it via above tool

% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf
> 
> Thanks,
> Harish.
> 
> -Original Message-
> From: yocto-boun...@yoctoproject.org 
> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of 
> yocto-requ...@yoctoproject.org
> Sent: Wednesday, May 22, 2019 6:57 PM
> To: yocto@yoctoproject.org
> Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95
> 
> Send yocto mailing list submissions to
>   yocto@yoctoproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoprojec
> t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAf
> VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YY
> Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
> or, via email, send a message with subject or body 'help' to
>   yocto-requ...@yoctoproject.org
> 
> You can reach the person managing the list at
>   yocto-ow...@yoctoproject.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
> 1. GPLv3 package present in rootfs (virendra kumar thakur)
> 2. Building single package as image, respecting dependencies
>(Norman Stetter)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 22 May 2019 18:55:45 +0530
> From: virendra kumar thakur 
> To: yocto@yoctoproject.org
> Subject: [yocto] GPLv3 package present in rootfs
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hello team,
> 
> I want to remove some GPLv3 package from rootfs, but it is still present.
> 
> I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"
> 
> still some package gnutls, libidn2, libassuan, are added into rootfs.
> -- next part -- An HTML attachment was 
> scrubbed...
> URL: 
>  t.org_pipermail_yocto_attachments_20190522_fb9ebe67_attachment-2D0001.
> html=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQys
> OP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=BBPanVh
> jmdOQaYXZFeb4RWi9MdRpGYBFLmqihDeSAds=>
> 
> --
> 
> Message: 2
> Date: Wed, 22 May 2019 12:36:18 +
> From: Norman Stetter 
> To: "yocto@yoctoproject.org" 
> Subject: [yocto] Building single package as image, respecting
>   dependencies
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi there,
> 
> I am currently working on a minimal CLI only system.
> The image is based on 'core-image-base' using sysvinit and busybox.
> To reduce image size and boot time, I removed as many packages as possible. 
> For some application cases I will need python3 though.
> My idea was to have python3 as some kind of add-on in a squashfs image, that 
> can be mounted only when needed.
> 
> So I tried to build an image only containing the python3 package, but as 
> little as possible otherwise, like this:
> 
> inherit image
> IMAGE_FSTYPES = "squashfs-xz"
> DEFAULT_TASK_PROVIDER = ""
> DISTRO_EXTRA_RDEPENDS = ""
> DISTRO_FEATURES = ""
> POKY_DEFAULT_EXTRA_RDEPENDS = ""
> IMAGE_FEATURES = ""
> IMAGE_LINGUAS = ""
> CORE_IMAGE_BASE_INSTALL = ""
> RDEPENDS_${PN} = ""
> PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
> VIRTUAL-RUNTIME_dev_manager = ""
> VIRTUAL-RUNTIME_login_manager = ""
> VIRTUAL-RUNTIME_init_manager = ""
> VIRTUAL-RUNTIME_initscripts = ""
> 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Khem Raj]

On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:

 > I think this is a fair suggestion. Having prebuilt kernel available
 > that contains the configuration and header files used in the build is
 > all that is required for external modules to build in addition to
 > toolchain, so maybe its worth a try to create such a package and then
 > have kernel-source separated out which can be installed on top if one
 > needs

I am man of experimental try-outs. So, in order to see how big kernel is,
I did the following:
Fedora 29 (which I am using as a host) with kernel-headers (NOT full
kernel source tree):
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
/usr/src/kernels/5.0.16-200.fc29.x86_64
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
/*102124    . <<=== ~95MB*/

Kernel.org kernel 5.0.6, the full kernel source tree size:
[vuser@fedora29-ssd linux-5.0.6]$ pwd
/home/vuser/projects/kernel.org/linux-5.0.6 
[vuser@fedora29-ssd linux-5.0.6]$ du --summarize
/*960592    . <<=== ~900MB*/

These are ballpark numbers. You can draw conclusions for yourselves!

It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
and initramfs for testing purposes, in speaks for itself.



yes thats what I was expecting too. Anything smaller helps.



(I am aware that YOCTO kernels are less/smaller in size, but how smaller?)



Not in source. The binaries may be


Zoran
___


On Fri, May 24, 2019 at 3:00 AM Khem Raj > wrote:




On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
 > After some tests (and I had other problems to take care of, as well),
 > here is the following:
 >
 >> These have all been discussed off an on over the past 5 years.
 >> I can't get at bugzilla right now, but all the details are
logged in cases.
 >> A survey of all the distros, their kernel package, etc, were all
looked at.
 >> We had to balance the traditional packaging with some new concepts
 >> and landed with what we have now.
 >
 > I tried several tests. This is my final conclusion (two cases):
 >

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
 >
 > The kernel issue is described here: there is need to have the YOCTO
 > minimum configuration with the kernel setup:
 > [1] The entire kernel source code in:
 > /usr/src/kernel/`uname-r`/
 > [2] The header files in: /usr/src/kernel/`uname-r`/ directory structures>
 >
 > Point [1] is achieved with the following local.config file:
 >

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
 >
 > Namely, with the following snippets in the local.conf:
 > TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
 > packagegroup-core-buildessential kernel-devsrc"
 > KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
 > packagegroup-core-buildessential kernel-devsrc"
 > KERNEL_DEV_MODULE = "kernel-modules"
 > CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
 > ${KERNEL_DEV_TOOLS} \
 > systemtap \
 > "
 >
 > Problem with this approach is that such a kernel makes the rootfs too
 > big and impractical:
 > -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
 > core-image-minimal-beaglebone.rootfs.tar.xz
 >
 > The main issue is point [2]: how to achieve it?
 > The suggestion is to introduce the new package in YOCTO kernel,
 > called: kernel-headers
 > The OBVIOUS benefit is that it will serve to the purpose of building
 > modules out of the tree on the target with
 > minimal mpact to rootfs!

I think this is a fair suggestion. Having prebuilt kernel available
that contains the configuration and header files used in the build is
all that is required for external modules to build in addition to
toolchain, so maybe its worth a try to create such a package and then
have kernel-source separated out which can be installed on top if one
needs

 >
 > Thank you,
 > Zoran Stojsavljevic
 > ___
 >
 > On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
 > mailto:bruce.ashfi...@gmail.com>> wrote:
 >>
 >>
 >>
 >> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic
mailto:zoran.stojsavlje...@gmail.com>> wrote:
 >>>
  The core-image-kernel-dev image is how I do all my on target
  testing when I introduce a new reference kernel for a release.
 >>>
 >>> Maybe you are correct. Maybe I should use/add in my local.conf
the following:
 >>>
 >>> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
 >>> packagegroup-core-buildessential kernel-devsrc"
 >>> KERNEL_DEV_MODULE ?= "kernel-modules"
 >>> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
 >>>                               ${KERNEL_DEV_TOOLS} \
 >>>                               systemtap \
 

Re: [yocto] PN is uppercase

[Tim Orling]

On Thu, May 23, 2019 at 4:55 PM Khem Raj  wrote:

>
>
> On 5/21/19 12:50 AM, Ralf Spiwoks wrote:
> > Hi Ross,
> >
> > Thanks for your email. I am realising that I have not replied to your
> > email earlier. Sorry. I guess it was partly because your answer put
> > me slightly off. On the one hand, I thought that as a general approach,
> > Linux was case sensitive, unlike its big rival Windows, and I was not
> > aware  of package managers which would explicitly forbid uppercase
> > package names. I find the approach of allowing only lowercase package
> > names quite limiting, and frankly a drawback for using Yocto
> >
> > On the other hand I have a few tens of packages to maintain, which
> > have uppercase letters in the package names and which did work with
> > Yocto in previous versions. So, because of a new convention we would
> > have to rework some of the packages or ignore the warning messages.
> > And until we find the effort for reworking those package recipes we
> > will stay with the latter option.
>
> The package name rules are not new, they have been with OE/YP forever
> so it should have failed always. Similar to debian see
>
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields
>

We had to pick a convention. Debian is well documented, conservative and
well thought out. My first contributions to OpenEmbedded many years ago
didn’t follow Debian naming, were rejected on V1 and I embarked on a new
learning curve. I’ve embraced it and never looked back.


> >
> > Thanks for your patience and your explanations. Cheers,
> >
> > Ralf.
> >
> > On 4/2/19 1:54 PM, Burton, Ross wrote:
> >> On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  wrote:
> >>> TWO questions:
> >>>
> >>> 1) Are those two issues related?
> >>
> >> Probably not, unless you're trying to use a mixed-case override.
> >>
> >>> 2) What is the logic behind allowing only lower case package names?
> >>> This is to me
> >>>  a serious restriction on the use of Yocto.
> >>
> >> Two reasons: some package managers forbid packages with uppercase
> >> names; and for performance reasons overrides are lowercase and as
> >> package names are often embedded in overrides this implies that
> >> package names need to be lowercase.
> >>
> >> What's the problem with using lowercase names?
> >>
> >> Ross
> >>
> --
> ___
> 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] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

> I think this is a fair suggestion. Having prebuilt kernel available
> that contains the configuration and header files used in the build is
> all that is required for external modules to build in addition to
> toolchain, so maybe its worth a try to create such a package and then
> have kernel-source separated out which can be installed on top if one
> needs

I am man of experimental try-outs. So, in order to see how big kernel is,
I did the following:
Fedora 29 (which I am using as a host) with kernel-headers (NOT full
kernel source tree):
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
/usr/src/kernels/5.0.16-200.fc29.x86_64
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
*102124. <<=== ~95MB*

Kernel.org kernel 5.0.6, the full kernel source tree size:
[vuser@fedora29-ssd linux-5.0.6]$ pwd
/home/vuser/projects/kernel.org/linux-5.0.6
[vuser@fedora29-ssd linux-5.0.6]$ du --summarize
*960592. <<=== ~900MB*

These are ballpark numbers. You can draw conclusions for yourselves!

It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
and initramfs for testing purposes, in speaks for itself.

(I am aware that YOCTO kernels are less/smaller in size, but how smaller?)

Zoran
___


On Fri, May 24, 2019 at 3:00 AM Khem Raj  wrote:

>
>
> On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
> > After some tests (and I had other problems to take care of, as well),
> > here is the following:
> >
> >> These have all been discussed off an on over the past 5 years.
> >> I can't get at bugzilla right now, but all the details are logged in
> cases.
> >> A survey of all the distros, their kernel package, etc, were all looked
> at.
> >> We had to balance the traditional packaging with some new concepts
> >> and landed with what we have now.
> >
> > I tried several tests. This is my final conclusion (two cases):
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
> >
> > The kernel issue is described here: there is need to have the YOCTO
> > minimum configuration with the kernel setup:
> > [1] The entire kernel source code in:
> > /usr/src/kernel/`uname-r`/
> > [2] The header files in: /usr/src/kernel/`uname-r`/ > directory structures>
> >
> > Point [1] is achieved with the following local.config file:
> >
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
> >
> > Namely, with the following snippets in the local.conf:
> > TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
> > packagegroup-core-buildessential kernel-devsrc"
> > KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
> > packagegroup-core-buildessential kernel-devsrc"
> > KERNEL_DEV_MODULE = "kernel-modules"
> > CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> > ${KERNEL_DEV_TOOLS} \
> > systemtap \
> > "
> >
> > Problem with this approach is that such a kernel makes the rootfs too
> > big and impractical:
> > -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
> > core-image-minimal-beaglebone.rootfs.tar.xz
> >
> > The main issue is point [2]: how to achieve it?
> > The suggestion is to introduce the new package in YOCTO kernel,
> > called: kernel-headers
> > The OBVIOUS benefit is that it will serve to the purpose of building
> > modules out of the tree on the target with
> > minimal mpact to rootfs!
>
> I think this is a fair suggestion. Having prebuilt kernel available
> that contains the configuration and header files used in the build is
> all that is required for external modules to build in addition to
> toolchain, so maybe its worth a try to create such a package and then
> have kernel-source separated out which can be installed on top if one
> needs
>
> >
> > Thank you,
> > Zoran Stojsavljevic
> > ___
> >
> > On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
> >  wrote:
> >>
> >>
> >>
> >> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> >>>
>  The core-image-kernel-dev image is how I do all my on target
>  testing when I introduce a new reference kernel for a release.
> >>>
> >>> Maybe you are correct. Maybe I should use/add in my local.conf the
> following:
> >>>
> >>> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
> >>> packagegroup-core-buildessential kernel-devsrc"
> >>> KERNEL_DEV_MODULE ?= "kernel-modules"
> >>> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> >>>   ${KERNEL_DEV_TOOLS} \
> >>>   systemtap \
> >>>  "
> >>> I need to try these... Maybe this addendum will solve the $1 mio USD
> problem?!
> >>>
>  And IIRC the autobuilders are using a sato based image (Richard
>  could confirm more easily that I could what image type the
>  autobuilders are using for hello-world on target module tests).
> >>>
> >>> I am just advertising something more simple. To have mandatory
> >>> /lib/modules/`uname -r` directory. And introduce few more packages, as

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/23/19 7:53 PM, Shane Peelar wrote:
Any of them on the system pretty much, and yes they are also built with 
-fno-plt.


OK, I think its better to them conditionally check for .plt section,
can you describe more of whats going on when sections are checked.



On Thu, May 23, 2019 at 9:59 PM Khem Raj > wrote:




On 5/23/19 8:05 AM, Shane Peelar wrote:
 > Hi Everyone @ the Yocto project,
 >
 > I'm Shane Peelar, a PhD Candidate at the University of Windsor.
 > I'm writing to you about prelink-cross, as part of the Yocto project.
 > Specifically, I'm looking at using it with executables built using
 > `-fno-plt` under GCC.
 > I wasn't quite sure where to send this email to, so I figured I'd
try
 > here.  If there's a better place to send this, please let me know.
 >
 > Right now, prelink-cross seems to fail an assertion in
arch-x86_64.c,
 > line 421, when
 > using it with an executable built with `-fno-plt`:
 >
 > ...
 > assert (i < dso->ehdr.e_shnum)
 > ...
 >
 > This snippet seems to be looking for the ".plt" section and,
since it
 > can't find it, the assertion fires.  This makes sense because in
 > `-fno-plt` executables, the `.plt` section is missing entirely.
 > I'm not an expert on ELF stuff, although I am learning quickly.  It
 > looks like
 > this code wants to write into GOT[1] the address of ".plt" + 0x16 --
 > since ".plt" doesn't
 > exist, does it make sense to just change this assert to an if
statement
 > like so:
 >
 > ...
 >        if (i < dso->ehdr.e_shnum)
 >        { ... }
 > ...
 >
 > and skip over that part?  Or is this a real error condition for
 > prelink-cross and it really should not continue?  The executable in
 > question is also non-PIE, if that makes a difference.
 >

what shared libs is this linking to ? are they also built with
-fno-plt ?

 > Thanks for your time,
 > Shane
 >


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

[linux-yocto] v4.18.x - stable updates comprising v4.18.39

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.38 release.

There are about 180 commits here, based on commits chosen from what were
used in the 4.19.39/40/41 stable releases -- so another "batch" release,
if you will.  I don't think any one subsystem is over-represented, so we
can count this as a "normal" stable release case.

Since there isn't anything else news-worthy to report, I'll remind
people once again that these updates will most likely draw to a close
in a few months, so 4.18.x users should start planning accordingly.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.39 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

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

Re: [yocto] prelink-cross with -fno-plt

[Shane Peelar]

Any of them on the system pretty much, and yes they are also built with
-fno-plt.

On Thu, May 23, 2019 at 9:59 PM Khem Raj  wrote:

>
>
> On 5/23/19 8:05 AM, Shane Peelar wrote:
> > Hi Everyone @ the Yocto project,
> >
> > I'm Shane Peelar, a PhD Candidate at the University of Windsor.
> > I'm writing to you about prelink-cross, as part of the Yocto project.
> > Specifically, I'm looking at using it with executables built using
> > `-fno-plt` under GCC.
> > I wasn't quite sure where to send this email to, so I figured I'd try
> > here.  If there's a better place to send this, please let me know.
> >
> > Right now, prelink-cross seems to fail an assertion in arch-x86_64.c,
> > line 421, when
> > using it with an executable built with `-fno-plt`:
> >
> > ...
> > assert (i < dso->ehdr.e_shnum)
> > ...
> >
> > This snippet seems to be looking for the ".plt" section and, since it
> > can't find it, the assertion fires.  This makes sense because in
> > `-fno-plt` executables, the `.plt` section is missing entirely.
> > I'm not an expert on ELF stuff, although I am learning quickly.  It
> > looks like
> > this code wants to write into GOT[1] the address of ".plt" + 0x16 --
> > since ".plt" doesn't
> > exist, does it make sense to just change this assert to an if statement
> > like so:
> >
> > ...
> >if (i < dso->ehdr.e_shnum)
> >{ ... }
> > ...
> >
> > and skip over that part?  Or is this a real error condition for
> > prelink-cross and it really should not continue?  The executable in
> > question is also non-PIE, if that makes a difference.
> >
>
> what shared libs is this linking to ? are they also built with -fno-plt ?
>
> > Thanks for your time,
> > Shane
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem adding a user

[Khem Raj]

On 5/23/19 1:40 PM, Rudolf Streif wrote:

Greg,

It eluded me earlier but in both instances the variable containing the 
password does not seem to be expanded.


First version without the single quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "
results in:

NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p sakura]

and with the quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "
results in:
NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p '' sakura]

It looks as if the variable SAKURA_PASS is not set at all. I looked at 
your scribe.bb  recipe you attached earlier but I 
could not find any reason why the variable is not set. Is there a chance 
that it is overridden somewhere elase?





This is correct with one small nit that we need to escape some 
characters which has special meaning for shell. e.g. $


e.g. in local.conf something like below

INHERIT += "extrausers"

EXTRA_USERS_PARAMS += "\
useradd sakura; \
usermod -p '\$1\$QVO3K6Ii\$fvkoDKnlzz3d5uVoL7KcM0' sakura; \
"

might work as you expect.


:rjs


On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:


Rudolf,

Here is the first half of the file,  the whole file is over the 500k
limit of free pastebin:

https://pastebin.com/UcnKebce


And here is the 2nd half of the file:

https://pastebin.com/9117tdUU


Greg


*From:* Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
*Sent:* Wednesday, May 22, 2019 12:42:40 PM
*To:* Greg Wilson-Lindberg
*Cc:* Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Greg,
Can you share the logfile via Pastebin?
:rjs

On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:

Rudolf,

Something else is happening to me. I changed to this in the
image recipe:

SAKURA_USER = "sakura"

SAKURA_PASSWD = "Distracted"
SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "

deleting all of the commented out lines, and I get this in the
log file:


/scribe/1.0-r0/rootfs -p '' sakura]


nothing between the single quotes. It's acting like SAKURA_PASS
is not defined.

This is only happening when I'm trying the MD5 password.


Greg


*From:* Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
*Sent:* Tuesday, May 21, 2019 5:37:23 AM
*To:* Greg Wilson-Lindberg
*Cc:* Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Greg,

usermod does not work for the MD5 algorithm with the explicit
password hash as it contains the $ field delimiters which are
interpreted by the shell executing the usermod command. Use
single quotes around the password hash:

usermod -p '${SAKURA_PASS}' ${SAKURA_USER};

:rjs

On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:

Hi Rudolf,

I've had more time to work with this and I'm still having problems 
getting
everything to work properly. I've attached the image recipe recipe 
that I'm
using so I don't leave any thing out that may be relevant.

When I build with a password that is no more more than 8 characters 
long
and no non-alphabetic characters:

SAKURA_PASSWD = "Distract"
SAKURA_PASS = "WRsDFfg1BsrDM"

everything works correctly.

I first tried that using the `openssl ...` form, and then I tried 
the
-1, MD5 BSD form and had problems, so I changed to doing the openssl
on the command line and making sure that I don't have any characters
that display as '.' or '/'. Again, if I don't do more than 8 
characters
and no special characters everything works.

When I changed to using 'Ds$tr@ct' it stopped working. The build 
finishes
and the log file shows the usermod being exectued correctly:

NOTE: scribe: Performing usermod with [-R 

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/23/19 8:05 AM, Shane Peelar wrote:

Hi Everyone @ the Yocto project,

I'm Shane Peelar, a PhD Candidate at the University of Windsor.
I'm writing to you about prelink-cross, as part of the Yocto project.
Specifically, I'm looking at using it with executables built using 
`-fno-plt` under GCC.
I wasn't quite sure where to send this email to, so I figured I'd try 
here.  If there's a better place to send this, please let me know.


Right now, prelink-cross seems to fail an assertion in arch-x86_64.c, 
line 421, when

using it with an executable built with `-fno-plt`:

...
assert (i < dso->ehdr.e_shnum)
...

This snippet seems to be looking for the ".plt" section and, since it 
can't find it, the assertion fires.  This makes sense because in 
`-fno-plt` executables, the `.plt` section is missing entirely.
I'm not an expert on ELF stuff, although I am learning quickly.  It 
looks like
this code wants to write into GOT[1] the address of ".plt" + 0x16 -- 
since ".plt" doesn't
exist, does it make sense to just change this assert to an if statement 
like so:


...
       if (i < dso->ehdr.e_shnum)
       { ... }
...

and skip over that part?  Or is this a real error condition for 
prelink-cross and it really should not continue?  The executable in 
question is also non-PIE, if that makes a difference.




what shared libs is this linking to ? are they also built with -fno-plt ?


Thanks for your time,
Shane


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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
  I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we 
do not have a database for mapping. Maybe it is a good thing to have


for your problem ubiattach is provided by mtd-utils-ubifs which is built 
from mtd-utils recipe. I found it via above tool


% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs
mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

1. GPLv3 package present in rootfs (virendra kumar thakur)
2. Building single package as image, respecting dependencies
   (Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
VIRTUAL-RUNTIME_dev_manager = ""
VIRTUAL-RUNTIME_login_manager = ""
VIRTUAL-RUNTIME_init_manager = ""
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_keymaps = ""
VIRTUAL-RUNTIME_base-utils = ""
PREFERRED_PROVIDER_virtual/base-utils = ""

IMAGE_INSTALL = "python3"

But like this I can only manually exclude packages I already have in my main OS 
image. Some packages can't be excluded at all, as python3 depends on them and 
won't build if they are excluded.

Is there a way to have dependencies between images? So I could have the 
python-image build know which dependencies are already built into my OS image 
and therefore not include them itself?

Or would it be better to avoid building a second image and rather build 
'python3' with my OS-image, adding it to PACKAGE_EXCLUDE and from within this 
build process pack all python3 files into an image? If I were to pursue this 
method, any suggestions on how to separate the python3 files from the rest of 
my rootfs, including 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Khem Raj]

On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:

After some tests (and I had other problems to take care of, as well),
here is the following:


These have all been discussed off an on over the past 5 years.
I can't get at bugzilla right now, but all the details are logged in cases.
A survey of all the distros, their kernel package, etc, were all looked at.
We had to balance the traditional packaging with some new concepts
and landed with what we have now.


I tried several tests. This is my final conclusion (two cases):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt

The kernel issue is described here: there is need to have the YOCTO
minimum configuration with the kernel setup:
[1] The entire kernel source code in:
/usr/src/kernel/`uname-r`/
[2] The header files in: /usr/src/kernel/`uname-r`/

Point [1] is achieved with the following local.config file:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf

Namely, with the following snippets in the local.conf:
TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE = "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
${KERNEL_DEV_TOOLS} \
systemtap \
"

Problem with this approach is that such a kernel makes the rootfs too
big and impractical:
-rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
core-image-minimal-beaglebone.rootfs.tar.xz

The main issue is point [2]: how to achieve it?
The suggestion is to introduce the new package in YOCTO kernel,
called: kernel-headers
The OBVIOUS benefit is that it will serve to the purpose of building
modules out of the tree on the target with
minimal mpact to rootfs!


I think this is a fair suggestion. Having prebuilt kernel available
that contains the configuration and header files used in the build is 
all that is required for external modules to build in addition to 
toolchain, so maybe its worth a try to create such a package and then 
have kernel-source separated out which can be installed on top if one

needs



Thank you,
Zoran Stojsavljevic
___

On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
 wrote:




On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic 
 wrote:



The core-image-kernel-dev image is how I do all my on target
testing when I introduce a new reference kernel for a release.


Maybe you are correct. Maybe I should use/add in my local.conf the following:

KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE ?= "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
  ${KERNEL_DEV_TOOLS} \
  systemtap \
 "
I need to try these... Maybe this addendum will solve the $1 mio USD problem?!


And IIRC the autobuilders are using a sato based image (Richard
could confirm more easily that I could what image type the
autobuilders are using for hello-world on target module tests).


I am just advertising something more simple. To have mandatory
/lib/modules/`uname -r` directory. And introduce few more packages, as
Fedora distro, for example, has: kernel-headers (assuming YOCTO
rootfs, the following will be installed: /usr/src/kernel/`uname
-r`/. This also makes addition of
/lib/modules/`uname -r`/build file (which is soft link to
usr/src/kernel/`uname -r`).



These have all been discussed off an on over the past 5 years. I can't get at 
bugzilla right now, but all the details are logged in cases. A survey of all 
the distros, their kernel package, etc, were all looked at. We had to balance 
the traditional packaging with some new concepts and landed with what we have 
now.




Or kernel-devel package. Then, the whole current kernel source code
will be introduced, and also support for it.



There's a case for this one as well, I'll probably have it done for the fall 
release. But our devsrc used to pretty much be the full source it has now been 
pruned down to something more manageable.  There are definitely some cases for 
having the full source on the target again, and it will be a separate package, 
just not the minimal one to build out of tree modules, etc.






SDK building with such a support is good/cool. But sometimes, before
introducing SDK, some tests should be done on target. NO need to
optionally include built-in layer hello-world driver example. Since I
(or you name the person) have own test drivers, which will be imported
out of tree, externally, to the target test bed!



I never use the SDK myself, so you are not alone in not going to it first. 
Hopefully I'll get some new patches out in the coming month before summer 
holidays really kick in.

Bruce




Just thinking loud...

Zoran
___

On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield  wrote:




On Wed, May 

Re: [yocto] [Yocto] RPI WiFi not loading module

[Khem Raj]

On 5/23/19 2:14 AM, Jonas Andersson wrote:

Hi

I have problem to get my WiFi working on boot on Raspberry Pi 3.

The problem is that wlan0 interface not showing up, if I manually 
run modprobe brcmfmac it works.


To try to "force" the load of brcmfmac i added it to 
KERNEL_MODULE_AUTOLOAD and that generated an file 
in /etc/modules-load.d/ -> brcmfmac.conf but it is still not loaded.


I use systemd an to my understanding systemd-modules-load.service is 
handling module auto load, but that file is missing and I cant see how 
to include it in my build.


Building thud version and I have added the following to my image recipe:

DISTRO_FEATURES_append = " wifi"

IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base 
module-init-tools"


IMAGE_INSTALL_append = "\
     linux-firmware-rpidistro-bcm43430 \
     linux-firmware-rpidistro-bcm43455 \
     bluez-firmware-rpidistro-bcm43430a1-hcd \
     bluez-firmware-rpidistro-bcm4345c0-hcd \
  "
Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf 
file and that work when I manually loads the module.




I wonder if something like this will help you
https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd


Best regards
Jonas


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

Re: [yocto] Fwd: /usr/share/common-license package/recipeinfo contains GPLv3 info

[Khem Raj]

On 5/23/19 2:42 AM, virendra kumar thakur wrote:



Hello team,

I am trying to build yocto image without GPLv3 package, I have added 
below things in local.conf and enable meta-gplv2 layer.


INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0" in local.conf.


Can you try adding GPLv3+ to INCOMPATIBLE_LICENSE and see if that helps ?



After verifying from package.manifest and license.manifest file in 
build/tmp/deploy/license/ directory I observe that no GPLv3 package is 
present in rootfs.


But I can see in 
rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo


LICENSE: GPLV2+ + +
PR: r0
PV : 1.8.4

Is present..

My doubt is why any GPLv3 is present in common-license directory?

From: "Burton, Ross" mailto:ross.bur...@intel.com>>
To: virendra kumar thakur >
Cc: Yocto-mailing-list >

Subject: Re: [yocto] GPLv3 package present in rootfs

On Wed, 22 May 2019 at 06:26, virendra kumar thakur
mailto:coolvee...@gmail.com>> wrote:

still some package gnutls, libidn2, libassuan, are added into rootfs.


Randomly picking libassuan:

LICENSE_${PN} = "LGPLv2.1+"

The library itself is LGPL-2.  Have you verified the *package*
licenses for what is actually going into the image?

Ross





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

Re: [yocto] PN is uppercase

[Khem Raj]

On 5/21/19 12:50 AM, Ralf Spiwoks wrote:

Hi Ross,

Thanks for your email. I am realising that I have not replied to your
email earlier. Sorry. I guess it was partly because your answer put
me slightly off. On the one hand, I thought that as a general approach,
Linux was case sensitive, unlike its big rival Windows, and I was not
aware  of package managers which would explicitly forbid uppercase
package names. I find the approach of allowing only lowercase package
names quite limiting, and frankly a drawback for using Yocto

On the other hand I have a few tens of packages to maintain, which
have uppercase letters in the package names and which did work with
Yocto in previous versions. So, because of a new convention we would
have to rework some of the packages or ignore the warning messages.
And until we find the effort for reworking those package recipes we
will stay with the latter option.


The package name rules are not new, they have been with OE/YP forever
so it should have failed always. Similar to debian see

https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields



Thanks for your patience and your explanations. Cheers,

Ralf.

On 4/2/19 1:54 PM, Burton, Ross wrote:

On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  wrote:

TWO questions:

1) Are those two issues related?


Probably not, unless you're trying to use a mixed-case override.

2) What is the logic behind allowing only lower case package names? 
This is to me

 a serious restriction on the use of Yocto.


Two reasons: some package managers forbid packages with uppercase
names; and for performance reasons overrides are lowercase and as
package names are often embedded in overrides this implies that
package names need to be lowercase.

What's the problem with using lowercase names?

Ross


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

Re: [yocto] problem adding a user

[Greg Wilson-Lindberg]

Hi Leon & Rudolf,

I first changed to SAKURA1_1PASS, with no change in symptoms, I then deleted 
the spaces, again not change.

Next I just copied the hash into the usermod line:


usermod -p '$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0' ${SAKURA_USER}; \


And again I get nothing in the output just the adjacent single quotes " '' ". 
Something is removing the encoded hash.


Greg


From: Leon Woestenberg 
Sent: Thursday, May 23, 2019 2:44:04 PM
To: Rudolf Streif
Cc: Greg Wilson-Lindberg; Yocto list discussion
Subject: Re: [yocto] problem adding a user

Hello Rudolf, Greg,

On Thu, 23 May 2019 at 22:43, Rudolf Streif 
mailto:rudolf.str...@ibeeto.com>> wrote:

It eluded me earlier but in both instances the variable containing the password 
does not seem to be expanded.

Could it be the spaces around the = equal sign must be removed?

https://unix.stackexchange.com/questions/258727/spaces-in-variable-assignments-in-shell-scripts

Regards, Leon


First version without the single quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:


NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p sakura]

and with the quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:
NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p '' sakura]

It looks as if the variable SAKURA_PASS is not set at all. I looked at your 
scribe.bb recipe you attached earlier but I could not find 
any reason why the variable is not set. Is there a chance that it is overridden 
somewhere elase?

:rjs

On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:

Rudolf,

Here is the first half of the file,  the whole file is over the 500k limit of 
free pastebin:

https://pastebin.com/UcnKebce


And here is the 2nd half of the file:

https://pastebin.com/9117tdUU


Greg


From: Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
Sent: Wednesday, May 22, 2019 12:42:40 PM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] problem adding a user

Greg,
Can you share the logfile via Pastebin?
:rjs

On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:

Rudolf,

Something else is happening to me. I changed to this in the image recipe:

SAKURA_USER = "sakura"

SAKURA_PASSWD = "Distracted"
SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"

deleting all of the commented out lines, and I get this in the log file:


/scribe/1.0-r0/rootfs -p '' sakura]


nothing between the single quotes. It's acting like SAKURA_PASS is not defined.

This is only happening when I'm trying the MD5 password.


Greg


From: Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
Sent: Tuesday, May 21, 2019 5:37:23 AM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] problem adding a user

Greg,

usermod does not work for the MD5 algorithm with the explicit password hash as 
it contains the $ field delimiters which are interpreted by the shell executing 
the usermod command. Use single quotes around the password hash:

usermod -p '${SAKURA_PASS}' ${SAKURA_USER};

:rjs

On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:

Hi Rudolf,

I've had more time to work with this and I'm still having problems getting
everything to work properly. I've attached the image recipe recipe that I'm
using so I don't leave any thing out that may be relevant.

When I build with a password that is no more more than 8 characters long
and no non-alphabetic characters:

SAKURA_PASSWD = "Distract"
SAKURA_PASS = "WRsDFfg1BsrDM"


everything works correctly.

I first tried that using the `openssl ...` form, and then I tried the
-1, MD5 BSD form and had problems, so I changed to doing the openssl
on the command line and making sure that I don't have any characters
that display as '.' or '/'. Again, if I don't do more than 8 characters
and no special characters everything works.

When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
and the log file shows the usermod being exectued correctly:

NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p kyNsrvS0elMWU sakura]
NOTE: scribe: 

Re: [yocto] Rocko broke down

[Khem Raj]

On 5/18/19 12:56 AM, Ari-Pekka Sihvonen wrote:
I am developing system using raspberry and made a pull on every yocto 
metas. Chen I baked the Image there was a major problem. My system did 
not read config.txt and cmdline.txt anymore. So the resulting Image was 
totally unusable. Lucily I had a copy of yocto tree so I could go on 
building images. Has something changed on rocko branch.




you have to be more specific here, maybe provide more step by step
what you did and what does not work


Regads
AP Sihvonen

Sent from my Huawei phone


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

Re: [yocto] problem adding a user

[Leon Woestenberg]

Hello Rudolf, Greg,

On Thu, 23 May 2019 at 22:43, Rudolf Streif 
wrote:

>
> It eluded me earlier but in both instances the variable containing the
> password does not seem to be expanded.
>

Could it be the spaces around the = equal sign must be removed?

https://unix.stackexchange.com/questions/258727/spaces-in-variable-assignments-in-shell-scripts

Regards, Leon


> First version without the single quotes:
>
> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>
> EXTRA_USERS_PARAMS = "\
> usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
> usermod -a -G sudo,dialout ${SAKURA_USER}; \
> "
> results in:
>
> NOTE: scribe: Performing usermod with [-R 
> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>  -p sakura]
>
> and with the quotes:
>
> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>
> EXTRA_USERS_PARAMS = "\
> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
> usermod -a -G sudo,dialout ${SAKURA_USER}; \
> "
> results in:
> NOTE: scribe: Performing usermod with [-R 
> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>  -p '' sakura]
>
> It looks as if the variable SAKURA_PASS is not set at all. I looked at your 
> scribe.bb recipe you attached earlier but I could not find any reason why the 
> variable is not set. Is there a chance that it is overridden somewhere elase?
>
> :rjs
>
>
> On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
> wrote:
>
>> Rudolf,
>>
>> Here is the first half of the file,  the whole file is over the 500k
>> limit of free pastebin:
>>
>> https://pastebin.com/UcnKebce
>>
>>
>> And here is the 2nd half of the file:
>>
>> https://pastebin.com/9117tdUU
>>
>>
>> Greg
>> --
>> *From:* Rudolf Streif 
>> *Sent:* Wednesday, May 22, 2019 12:42:40 PM
>> *To:* Greg Wilson-Lindberg
>> *Cc:* Yocto list discussion
>> *Subject:* Re: [yocto] problem adding a user
>>
>> Greg,
>> Can you share the logfile via Pastebin?
>> :rjs
>>
>> On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg <
>> gwil...@sakuraus.com> wrote:
>>
>>> Rudolf,
>>>
>>> Something else is happening to me. I changed to this in the image recipe:
>>>
>>> SAKURA_USER = "sakura"
>>>
>>> SAKURA_PASSWD = "Distracted"
>>> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>>>
>>> EXTRA_USERS_PARAMS = "\
>>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
>>> usermod -a -G sudo,dialout ${SAKURA_USER}; \
>>> "
>>>
>>> deleting all of the commented out lines, and I get this in the log file:
>>>
>>>
>>> /scribe/1.0-r0/rootfs -p '' sakura]
>>>
>>>
>>> nothing between the single quotes. It's acting like SAKURA_PASS is not
>>> defined.
>>>
>>> This is only happening when I'm trying the MD5 password.
>>>
>>>
>>> Greg
>>> --
>>> *From:* Rudolf Streif 
>>> *Sent:* Tuesday, May 21, 2019 5:37:23 AM
>>> *To:* Greg Wilson-Lindberg
>>> *Cc:* Yocto list discussion
>>> *Subject:* Re: [yocto] problem adding a user
>>>
>>> Greg,
>>>
>>> usermod does not work for the MD5 algorithm with the explicit password
>>> hash as it contains the $ field delimiters which are interpreted by the
>>> shell executing the usermod command. Use single quotes around the password
>>> hash:
>>>
>>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
>>>
>>> :rjs
>>>
>>> On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
>>> wrote:
>>>
 Hi Rudolf,

 I've had more time to work with this and I'm still having problems getting
 everything to work properly. I've attached the image recipe recipe that I'm
 using so I don't leave any thing out that may be relevant.

 When I build with a password that is no more more than 8 characters long
 and no non-alphabetic characters:

 SAKURA_PASSWD = "Distract"
 SAKURA_PASS = "WRsDFfg1BsrDM"

 everything works correctly.

 I first tried that using the `openssl ...` form, and then I tried the
 -1, MD5 BSD form and had problems, so I changed to doing the openssl
 on the command line and making sure that I don't have any characters
 that display as '.' or '/'. Again, if I don't do more than 8 characters
 and no special characters everything works.

 When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
 and the log file shows the usermod being exectued correctly:

 NOTE: scribe: Performing usermod with [-R 
 /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
  -p kyNsrvS0elMWU sakura]
 NOTE: scribe: Performing usermod with [-R 
 /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
  -a -G sudo,dialout sakura]

 But when I try to sign in it doesn't work.

 I then tried the 10 character password 'Distracted', the build 

[yocto] [opkg-utils][PATCH] opkg-list-fields: fix to print the fields again

[Martin Jansa]

* printing opkg.Package directly doesn't return anything useful now
  

* we need to call Package.print() function and specify which checksums
  to print, we can include both md5 and sha256 for opkg-list-fields

* it was changed in this commit:
  commit 601d691dd80ef494aef069017edc5bf80aa883a1
  Author: Alejandro del Castillo 
  Date:   Wed Dec 19 11:40:15 2018 -0600

opkg-make-index: add sha256sum support

  which replaced the modified __str__ function with print(self, checksum)

Signed-off-by: Martin Jansa 
---
 opkg-list-fields | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/opkg-list-fields b/opkg-list-fields
index c14a90f..8a5a588 100755
--- a/opkg-list-fields
+++ b/opkg-list-fields
@@ -11,5 +11,4 @@ def usage():
 if (len(sys.argv) < 2):
  usage()
 
-print(opkg.Package(sys.argv[1]))
-
+print(opkg.Package(sys.argv[1]).print(('md5','sha256')))
-- 
2.17.1

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

Re: [yocto] problem adding a user

[Rudolf Streif]

Greg,

It eluded me earlier but in both instances the variable containing the
password does not seem to be expanded.

First version without the single quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:

NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p sakura]

and with the quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
results in:
NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p '' sakura]

It looks as if the variable SAKURA_PASS is not set at all. I looked at
your scribe.bb recipe you attached earlier but I could not find any
reason why the variable is not set. Is there a chance that it is
overridden somewhere elase?

:rjs


On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
wrote:

> Rudolf,
>
> Here is the first half of the file,  the whole file is over the 500k limit
> of free pastebin:
>
> https://pastebin.com/UcnKebce
>
>
> And here is the 2nd half of the file:
>
> https://pastebin.com/9117tdUU
>
>
> Greg
> --
> *From:* Rudolf Streif 
> *Sent:* Wednesday, May 22, 2019 12:42:40 PM
> *To:* Greg Wilson-Lindberg
> *Cc:* Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
> Greg,
> Can you share the logfile via Pastebin?
> :rjs
>
> On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg <
> gwil...@sakuraus.com> wrote:
>
>> Rudolf,
>>
>> Something else is happening to me. I changed to this in the image recipe:
>>
>> SAKURA_USER = "sakura"
>>
>> SAKURA_PASSWD = "Distracted"
>> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>>
>> EXTRA_USERS_PARAMS = "\
>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
>> usermod -a -G sudo,dialout ${SAKURA_USER}; \
>> "
>>
>> deleting all of the commented out lines, and I get this in the log file:
>>
>>
>> /scribe/1.0-r0/rootfs -p '' sakura]
>>
>>
>> nothing between the single quotes. It's acting like SAKURA_PASS is not
>> defined.
>>
>> This is only happening when I'm trying the MD5 password.
>>
>>
>> Greg
>> --
>> *From:* Rudolf Streif 
>> *Sent:* Tuesday, May 21, 2019 5:37:23 AM
>> *To:* Greg Wilson-Lindberg
>> *Cc:* Yocto list discussion
>> *Subject:* Re: [yocto] problem adding a user
>>
>> Greg,
>>
>> usermod does not work for the MD5 algorithm with the explicit password
>> hash as it contains the $ field delimiters which are interpreted by the
>> shell executing the usermod command. Use single quotes around the password
>> hash:
>>
>> usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
>>
>> :rjs
>>
>> On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg 
>> wrote:
>>
>>> Hi Rudolf,
>>>
>>> I've had more time to work with this and I'm still having problems getting
>>> everything to work properly. I've attached the image recipe recipe that I'm
>>> using so I don't leave any thing out that may be relevant.
>>>
>>> When I build with a password that is no more more than 8 characters long
>>> and no non-alphabetic characters:
>>>
>>> SAKURA_PASSWD = "Distract"
>>> SAKURA_PASS = "WRsDFfg1BsrDM"
>>>
>>> everything works correctly.
>>>
>>> I first tried that using the `openssl ...` form, and then I tried the
>>> -1, MD5 BSD form and had problems, so I changed to doing the openssl
>>> on the command line and making sure that I don't have any characters
>>> that display as '.' or '/'. Again, if I don't do more than 8 characters
>>> and no special characters everything works.
>>>
>>> When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
>>> and the log file shows the usermod being exectued correctly:
>>>
>>> NOTE: scribe: Performing usermod with [-R 
>>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>>  -p kyNsrvS0elMWU sakura]
>>> NOTE: scribe: Performing usermod with [-R 
>>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>>  -a -G sudo,dialout sakura]
>>>
>>> But when I try to sign in it doesn't work.
>>>
>>> I then tried the 10 character password 'Distracted', the build fails:
>>>
>>> NOTE: scribe: Performing usermod with [-R 
>>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>>>  -p sakura]
>>> Usage: usermod [options] LOGIN
>>>
>>> Options:
>>>   -c, --comment COMMENT new value of the GECOS field
>>>   -d, --home HOME_DIR   new home directory for the user account
>>>   -e, --expiredate EXPIRE_DATE 

Re: [yocto] distrodata documentation in 2.7 Mega Manual

[Scott Rifenbark]

Paul & Alexander,

I have updated the YP doc set for the removal of the three classes.
Changes apply to the 2.7 and "master" (2.8)
trees.  You see the effects in:

 * https://yoctoproject.org/docs/2.7/mega-manual/mega-manual.html
 * https://yoctoproject.org/docs/2.8/mega-manual/mega-manual.html

Thanks for pointing these out and for the added explanations.

Scott

On Thu, May 23, 2019 at 2:23 AM Alexander Kanavin 
wrote:

> On Thu, 23 May 2019 at 02:22, Scott Rifenbark 
> wrote:
> >  * In dev-manual's "Using the Auto Upgrade Helper (AUH)" section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#gs-using-the-auto-upgrade-helper:
> Step 5 talks about making configurations in the local.conf file.  First
> thing is to enable "distrodata" by inheriting the class.  Do we have an
> equivalent for this now that the class is gone?
>
> This is no longer necessary, you can remove the step.
>
> > * in ref-manual's "do_distrodata" task section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-distrodata:
> Does this task disappear as well?  Or, is there an equivalent?
>
> There is no equivalent, you can remove the sectrion.
>
> > * In ref-manual's "do_checkpkg" task section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-checkpkg:
> This task was included as part of the distrodata.bbclass.  How do we
> address the do_checkpkg task section now?
>
> The equivalent functionality is provided by running devtool - 'devtool
> latest-version' for one recipe, 'devtool check-upgrade-status' for
> several (or all).
>
> > * In the UPSTREAM_CHECK_GETTAGREGEX variable description in the
> ref-manual glossary -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_GITTAGREGEX:
> How do we change this?
> > * in the UPSTREAM_CHECK_REGEX variable description also in the glossary
> -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_REGEX:
> How do we change this?
> > * in the UPSTREAM_CHECK_URI variable description also int he glossary -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_URI:
> How do we change this?
>
> All three should refer to the equivalent replacement (see above)
> provided by devtool.
>
> Alex
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 12:20 PM Andrei Gherzan  wrote:

>
> On 23/05/2019 17.11, Bruce Ashfield wrote:
>
>
>
> On Thu, May 23, 2019 at 11:24 AM Andrei Gherzan  wrote:
>
>> On 23/05/2019 16.10, Bruce Ashfield wrote:
>>
>>
>>
>> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan 
>> wrote:
>>
>>>
>>> On 23/05/2019 15.39, Bruce Ashfield wrote:
>>>
>>>
>>>
>>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield <
>>> bruce.ashfi...@gmail.com> wrote:
>>>


 On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan 
 wrote:

> Hello,
>
> This might have been discussed before. I couldn't find a relevant
> thread, but if it is so, just link me to it.
>
> Since thud, more specific since
>
> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
> Author: Bruce Ashfield 
> Date:   Sat Aug 18 22:50:44 2018 -0400
> kernel-devsrc: restructure for out of tree (and on target) module
> builds
>
> ... we switched from a recipe that was deploying the entire source code
> to one that provides mainly the kernel headers (but not only). This
> change broke people expectations of this recipe while the description
> is
> also confusing: "Development source linux kernel. When built, this
> recipe packages the \source of the preferred virtual/kernel provider
> and
> makes it available for full kernel \development or external module
> builds".
>
> If size is not a problem (which can be the case when you compile on a
> builder for example and deploy only a OOT kernel module through other
> means), the full kernel source was a painless experience where things
> like
>
> commit a9471601fedd1f5087304eaa5fd39b98ae220313
> Author: Bruce Ashfield 
> Date:   Thu Aug 30 09:45:41 2018 -0400
> kernel-devsrc: fix arm/arm64 target module build
>
> ... would not appear. I understand the size impact on target and for
> those cases, continuously maintaining this recipe with new
> files/resources needed from the kernel, makes sense. So my proposal is
> to have two recipes, for example kernel-devsrc and kernel-fullsrc
> (kernel-src etc.) so people can choose what they need/want
> deploying/using. Or even have another devsrc provider. I'm open to any
> implementation detail. I'd just want to have an option for a full
> kernel
> source recipe.
>

 This is already planned, and hidden in bugzilla somewhere. I'll have
 some new kernel packaging
 options available for the fall release.

>>>
>>> It looks like the bugs that I was using for development were finally
>>> moved to resolved (they were a bit old, and contained collected information
>>> on various kernel packaging options .. my searching of bugzilla isn't
>>> turning it up at the moment). So I just created a new bug to track the
>>> development for 2.8.
>>>
>>> The issue with the multiple kernel source providers is really about test
>>> cycles. The smaller devsrc is for on-target module development and builds
>>> against the exported uapi headers, and that is what the nightly / automated
>>> tests will use. We had issues with both the amount of time it took to
>>> package the entire source, and the amount of space that it took up on the
>>> images. Hence the creation of devsrc.
>>>
>>> With new kernel-source and kernel-headers packages (the working names),
>>> they are really provided as references to the running kernel, and will
>>> largely be an exercise left up to the developer to use them as they want.
>>>
>>> Right. So is there anything that holds us from creating two recipes -
>>> one for what we currently have and one for what we used to have pre-thud -
>>> find some pretty names and start from that? I'm asking just in case I'm
>>> missing any internal architecture discussions or so.
>>>
>>
>> In some other non-core layer ? Sure :D The pre-thud copying of the kernel
>> source was a disaster and needed to be killed with fire, as it was. It was
>> all special cases and I commonly needed to fight with it. What you see in
>> the current devsrc is not an invention from Yocto, it is based on the
>> redhat spec files, and also (a bit) on some of the debian packaging of
>> minimal source.
>>
>> I am aware of all the other distros having the similar approach (and they
>> do this dance for disk space optimization) but I don't understand what were
>> all the special cases you had to fight against? The recipe was barely
>> touched in years. For example there is only one commit on it in 2017.
>>
>
> There were corner cases popping up with architectures and the newer
> kernels. I had inflight changes that were tweaking the nasty find commands,
> etc, trying to get everything we needed, minimize the time spent copying
> and avoiding QA errors due to cross arch artifacts popping in. Let's just
> say, I'm not copying and pruning the same way in a plainer "kernel-source"
> package. Since it isn't installed by 

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Andrei Gherzan]

On 23/05/2019 17.11, Bruce Ashfield wrote:
>
>
> On Thu, May 23, 2019 at 11:24 AM Andrei Gherzan  > wrote:
>
> On 23/05/2019 16.10, Bruce Ashfield wrote:
>>
>>
>> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan
>> mailto:and...@gherzan.ro>> wrote:
>>
>>
>> On 23/05/2019 15.39, Bruce Ashfield wrote:
>>>
>>>
>>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield
>>> mailto:bruce.ashfi...@gmail.com>>
>>> wrote:
>>>
>>>
>>>
>>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan
>>> mailto:and...@gherzan.ro>> wrote:
>>>
>>> Hello,
>>>
>>> This might have been discussed before. I couldn't
>>> find a relevant
>>> thread, but if it is so, just link me to it.
>>>
>>> Since thud, more specific since
>>>
>>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>>> Author: Bruce Ashfield >> >
>>> Date:   Sat Aug 18 22:50:44 2018 -0400
>>>     kernel-devsrc: restructure for out of tree (and
>>> on target) module builds
>>>
>>> ... we switched from a recipe that was deploying the
>>> entire source code
>>> to one that provides mainly the kernel headers (but
>>> not only). This
>>> change broke people expectations of this recipe
>>> while the description is
>>> also confusing: "Development source linux kernel.
>>> When built, this
>>> recipe packages the \source of the preferred
>>> virtual/kernel provider and
>>> makes it available for full kernel \development or
>>> external module builds".
>>>
>>> If size is not a problem (which can be the case when
>>> you compile on a
>>> builder for example and deploy only a OOT kernel
>>> module through other
>>> means), the full kernel source was a painless
>>> experience where things like
>>>
>>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>>> Author: Bruce Ashfield >> >
>>> Date:   Thu Aug 30 09:45:41 2018 -0400
>>>     kernel-devsrc: fix arm/arm64 target module build
>>>
>>> ... would not appear. I understand the size impact
>>> on target and for
>>> those cases, continuously maintaining this recipe
>>> with new
>>> files/resources needed from the kernel, makes sense.
>>> So my proposal is
>>> to have two recipes, for example kernel-devsrc and
>>> kernel-fullsrc
>>> (kernel-src etc.) so people can choose what they
>>> need/want
>>> deploying/using. Or even have another devsrc
>>> provider. I'm open to any
>>> implementation detail. I'd just want to have an
>>> option for a full kernel
>>> source recipe.
>>>
>>>
>>> This is already planned, and hidden in bugzilla
>>> somewhere. I'll have some new kernel packaging
>>> options available for the fall release.
>>>
>>>
>>> It looks like the bugs that I was using for development were
>>> finally moved to resolved (they were a bit old, and
>>> contained collected information on various kernel packaging
>>> options .. my searching of bugzilla isn't turning it up at
>>> the moment). So I just created a new bug to track the
>>> development for 2.8.
>>>
>>> The issue with the multiple kernel source providers is
>>> really about test cycles. The smaller devsrc is for
>>> on-target module development and builds against the exported
>>> uapi headers, and that is what the nightly / automated tests
>>> will use. We had issues with both the amount of time it took
>>> to package the entire source, and the amount of space that
>>> it took up on the images. Hence the creation of devsrc.
>>>
>>> With new kernel-source and kernel-headers packages (the
>>> working names), they are really provided as references to
>>> the running kernel, and will largely be an exercise left up
>>> to the developer to use them as they want.
>>
>> Right. So is there anything that holds us from creating two
>> recipes - one for what we currently have and one for what we
>> used to have pre-thud - find some pretty names and start from
>> that? I'm asking just in case I'm missing any internal
>> architecture discussions or so.
>>
>>
>>   

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 11:24 AM Andrei Gherzan  wrote:

> On 23/05/2019 16.10, Bruce Ashfield wrote:
>
>
>
> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan  wrote:
>
>>
>> On 23/05/2019 15.39, Bruce Ashfield wrote:
>>
>>
>>
>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield 
>> wrote:
>>
>>>
>>>
>>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan 
>>> wrote:
>>>
 Hello,

 This might have been discussed before. I couldn't find a relevant
 thread, but if it is so, just link me to it.

 Since thud, more specific since

 commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
 Author: Bruce Ashfield 
 Date:   Sat Aug 18 22:50:44 2018 -0400
 kernel-devsrc: restructure for out of tree (and on target) module
 builds

 ... we switched from a recipe that was deploying the entire source code
 to one that provides mainly the kernel headers (but not only). This
 change broke people expectations of this recipe while the description is
 also confusing: "Development source linux kernel. When built, this
 recipe packages the \source of the preferred virtual/kernel provider and
 makes it available for full kernel \development or external module
 builds".

 If size is not a problem (which can be the case when you compile on a
 builder for example and deploy only a OOT kernel module through other
 means), the full kernel source was a painless experience where things
 like

 commit a9471601fedd1f5087304eaa5fd39b98ae220313
 Author: Bruce Ashfield 
 Date:   Thu Aug 30 09:45:41 2018 -0400
 kernel-devsrc: fix arm/arm64 target module build

 ... would not appear. I understand the size impact on target and for
 those cases, continuously maintaining this recipe with new
 files/resources needed from the kernel, makes sense. So my proposal is
 to have two recipes, for example kernel-devsrc and kernel-fullsrc
 (kernel-src etc.) so people can choose what they need/want
 deploying/using. Or even have another devsrc provider. I'm open to any
 implementation detail. I'd just want to have an option for a full kernel
 source recipe.

>>>
>>> This is already planned, and hidden in bugzilla somewhere. I'll have
>>> some new kernel packaging
>>> options available for the fall release.
>>>
>>
>> It looks like the bugs that I was using for development were finally
>> moved to resolved (they were a bit old, and contained collected information
>> on various kernel packaging options .. my searching of bugzilla isn't
>> turning it up at the moment). So I just created a new bug to track the
>> development for 2.8.
>>
>> The issue with the multiple kernel source providers is really about test
>> cycles. The smaller devsrc is for on-target module development and builds
>> against the exported uapi headers, and that is what the nightly / automated
>> tests will use. We had issues with both the amount of time it took to
>> package the entire source, and the amount of space that it took up on the
>> images. Hence the creation of devsrc.
>>
>> With new kernel-source and kernel-headers packages (the working names),
>> they are really provided as references to the running kernel, and will
>> largely be an exercise left up to the developer to use them as they want.
>>
>> Right. So is there anything that holds us from creating two recipes - one
>> for what we currently have and one for what we used to have pre-thud - find
>> some pretty names and start from that? I'm asking just in case I'm missing
>> any internal architecture discussions or so.
>>
>
> In some other non-core layer ? Sure :D The pre-thud copying of the kernel
> source was a disaster and needed to be killed with fire, as it was. It was
> all special cases and I commonly needed to fight with it. What you see in
> the current devsrc is not an invention from Yocto, it is based on the
> redhat spec files, and also (a bit) on some of the debian packaging of
> minimal source.
>
> I am aware of all the other distros having the similar approach (and they
> do this dance for disk space optimization) but I don't understand what were
> all the special cases you had to fight against? The recipe was barely
> touched in years. For example there is only one commit on it in 2017.
>

There were corner cases popping up with architectures and the newer
kernels. I had inflight changes that were tweaking the nasty find commands,
etc, trying to get everything we needed, minimize the time spent copying
and avoiding QA errors due to cross arch artifacts popping in. Let's just
say, I'm not copying and pruning the same way in a plainer "kernel-source"
package. Since it isn't installed by default, and is opt-in, it doesn't
have to be quite so careful on those fronts.



>
> So no, I'd rather not restore the mess that was the pre-thud devsrc in any
> form.
>
>
>> And about test cycles, I'm not sure I understand why having a provider vs
>> having two separate 

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Andrei Gherzan]

On 23/05/2019 16.10, Bruce Ashfield wrote:
>
>
> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan  > wrote:
>
>
> On 23/05/2019 15.39, Bruce Ashfield wrote:
>>
>>
>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield
>> mailto:bruce.ashfi...@gmail.com>> wrote:
>>
>>
>>
>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan
>> mailto:and...@gherzan.ro>> wrote:
>>
>> Hello,
>>
>> This might have been discussed before. I couldn't find a
>> relevant
>> thread, but if it is so, just link me to it.
>>
>> Since thud, more specific since
>>
>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>> Author: Bruce Ashfield > >
>> Date:   Sat Aug 18 22:50:44 2018 -0400
>>     kernel-devsrc: restructure for out of tree (and on
>> target) module builds
>>
>> ... we switched from a recipe that was deploying the
>> entire source code
>> to one that provides mainly the kernel headers (but not
>> only). This
>> change broke people expectations of this recipe while the
>> description is
>> also confusing: "Development source linux kernel. When
>> built, this
>> recipe packages the \source of the preferred
>> virtual/kernel provider and
>> makes it available for full kernel \development or
>> external module builds".
>>
>> If size is not a problem (which can be the case when you
>> compile on a
>> builder for example and deploy only a OOT kernel module
>> through other
>> means), the full kernel source was a painless experience
>> where things like
>>
>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>> Author: Bruce Ashfield > >
>> Date:   Thu Aug 30 09:45:41 2018 -0400
>>     kernel-devsrc: fix arm/arm64 target module build
>>
>> ... would not appear. I understand the size impact on
>> target and for
>> those cases, continuously maintaining this recipe with new
>> files/resources needed from the kernel, makes sense. So
>> my proposal is
>> to have two recipes, for example kernel-devsrc and
>> kernel-fullsrc
>> (kernel-src etc.) so people can choose what they need/want
>> deploying/using. Or even have another devsrc provider.
>> I'm open to any
>> implementation detail. I'd just want to have an option
>> for a full kernel
>> source recipe.
>>
>>
>> This is already planned, and hidden in bugzilla somewhere.
>> I'll have some new kernel packaging
>> options available for the fall release.
>>
>>
>> It looks like the bugs that I was using for development were
>> finally moved to resolved (they were a bit old, and contained
>> collected information on various kernel packaging options .. my
>> searching of bugzilla isn't turning it up at the moment). So I
>> just created a new bug to track the development for 2.8.
>>
>> The issue with the multiple kernel source providers is really
>> about test cycles. The smaller devsrc is for on-target module
>> development and builds against the exported uapi headers, and
>> that is what the nightly / automated tests will use. We had
>> issues with both the amount of time it took to package the entire
>> source, and the amount of space that it took up on the images.
>> Hence the creation of devsrc.
>>
>> With new kernel-source and kernel-headers packages (the working
>> names), they are really provided as references to the running
>> kernel, and will largely be an exercise left up to the developer
>> to use them as they want.
>
> Right. So is there anything that holds us from creating two
> recipes - one for what we currently have and one for what we used
> to have pre-thud - find some pretty names and start from that? I'm
> asking just in case I'm missing any internal architecture
> discussions or so.
>
>
> In some other non-core layer ? Sure :D The pre-thud copying of the
> kernel source was a disaster and needed to be killed with fire, as it
> was. It was all special cases and I commonly needed to fight with it.
> What you see in the current devsrc is not an invention from Yocto, it
> is based on the redhat spec files, and also (a bit) on some of the
> debian packaging of minimal source.

I am aware of all the other distros having the similar approach (and
they do this dance for disk space optimization) but I don't understand
what were all the special cases you had to fight against? The recipe was
barely touched in 

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan  wrote:

>
> On 23/05/2019 15.39, Bruce Ashfield wrote:
>
>
>
> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield 
> wrote:
>
>>
>>
>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  wrote:
>>
>>> Hello,
>>>
>>> This might have been discussed before. I couldn't find a relevant
>>> thread, but if it is so, just link me to it.
>>>
>>> Since thud, more specific since
>>>
>>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>>> Author: Bruce Ashfield 
>>> Date:   Sat Aug 18 22:50:44 2018 -0400
>>> kernel-devsrc: restructure for out of tree (and on target) module
>>> builds
>>>
>>> ... we switched from a recipe that was deploying the entire source code
>>> to one that provides mainly the kernel headers (but not only). This
>>> change broke people expectations of this recipe while the description is
>>> also confusing: "Development source linux kernel. When built, this
>>> recipe packages the \source of the preferred virtual/kernel provider and
>>> makes it available for full kernel \development or external module
>>> builds".
>>>
>>> If size is not a problem (which can be the case when you compile on a
>>> builder for example and deploy only a OOT kernel module through other
>>> means), the full kernel source was a painless experience where things
>>> like
>>>
>>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>>> Author: Bruce Ashfield 
>>> Date:   Thu Aug 30 09:45:41 2018 -0400
>>> kernel-devsrc: fix arm/arm64 target module build
>>>
>>> ... would not appear. I understand the size impact on target and for
>>> those cases, continuously maintaining this recipe with new
>>> files/resources needed from the kernel, makes sense. So my proposal is
>>> to have two recipes, for example kernel-devsrc and kernel-fullsrc
>>> (kernel-src etc.) so people can choose what they need/want
>>> deploying/using. Or even have another devsrc provider. I'm open to any
>>> implementation detail. I'd just want to have an option for a full kernel
>>> source recipe.
>>>
>>
>> This is already planned, and hidden in bugzilla somewhere. I'll have some
>> new kernel packaging
>> options available for the fall release.
>>
>
> It looks like the bugs that I was using for development were finally moved
> to resolved (they were a bit old, and contained collected information on
> various kernel packaging options .. my searching of bugzilla isn't turning
> it up at the moment). So I just created a new bug to track the development
> for 2.8.
>
> The issue with the multiple kernel source providers is really about test
> cycles. The smaller devsrc is for on-target module development and builds
> against the exported uapi headers, and that is what the nightly / automated
> tests will use. We had issues with both the amount of time it took to
> package the entire source, and the amount of space that it took up on the
> images. Hence the creation of devsrc.
>
> With new kernel-source and kernel-headers packages (the working names),
> they are really provided as references to the running kernel, and will
> largely be an exercise left up to the developer to use them as they want.
>
> Right. So is there anything that holds us from creating two recipes - one
> for what we currently have and one for what we used to have pre-thud - find
> some pretty names and start from that? I'm asking just in case I'm missing
> any internal architecture discussions or so.
>

In some other non-core layer ? Sure :D The pre-thud copying of the kernel
source was a disaster and needed to be killed with fire, as it was. It was
all special cases and I commonly needed to fight with it. What you see in
the current devsrc is not an invention from Yocto, it is based on the
redhat spec files, and also (a bit) on some of the debian packaging of
minimal source.

So no, I'd rather not restore the mess that was the pre-thud devsrc in any
form.


> And about test cycles, I'm not sure I understand why having a provider vs
> having two separate recipes impact automated tests. In both cases you will
> select whatever you want to test - by using a specific recipe or by setting
> a preferred provider (I don't have a strong opinion here but I was just
> curious about the time impact on automated tests).
>

If it goes into core, we would need to run a full set of tests against it
to make sure that it supported development tasks. That would mean on target
kernel module builds, as well as potential some new cases given that the
full source is available (i.e. kernel rebuild). We already do that for
kernel-devrsc, adding multiple providers of something similar means that
we'd then have to test the multiple providers against all the
architectures, across the actively supported reference kernels in any given
release .. something always breaks, so then I'm on the hook for sorting
through all the issues (devsrc was not bug free in its previous form).
Given the amount of test cycles available, that's not necessarily a trivial
thing to add. In the end, 

[yocto] prelink-cross with -fno-plt

[Shane Peelar]

Hi Everyone @ the Yocto project,

I'm Shane Peelar, a PhD Candidate at the University of Windsor.
I'm writing to you about prelink-cross, as part of the Yocto project.
Specifically, I'm looking at using it with executables built using
`-fno-plt` under GCC.
I wasn't quite sure where to send this email to, so I figured I'd try
here.  If there's a better place to send this, please let me know.

Right now, prelink-cross seems to fail an assertion in arch-x86_64.c, line
421, when
using it with an executable built with `-fno-plt`:

...
assert (i < dso->ehdr.e_shnum)
...

This snippet seems to be looking for the ".plt" section and, since it can't
find it, the assertion fires.  This makes sense because in `-fno-plt`
executables, the `.plt` section is missing entirely.
I'm not an expert on ELF stuff, although I am learning quickly.  It looks
like
this code wants to write into GOT[1] the address of ".plt" + 0x16 -- since
".plt" doesn't
exist, does it make sense to just change this assert to an if statement
like so:

...
  if (i < dso->ehdr.e_shnum)
  { ... }
...

and skip over that part?  Or is this a real error condition for
prelink-cross and it really should not continue?  The executable in
question is also non-PIE, if that makes a difference.

Thanks for your time,
Shane
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Andrei Gherzan]

On 23/05/2019 15.39, Bruce Ashfield wrote:
>
>
> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield
> mailto:bruce.ashfi...@gmail.com>> wrote:
>
>
>
> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  > wrote:
>
> Hello,
>
> This might have been discussed before. I couldn't find a relevant
> thread, but if it is so, just link me to it.
>
> Since thud, more specific since
>
> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
> Author: Bruce Ashfield  >
> Date:   Sat Aug 18 22:50:44 2018 -0400
>     kernel-devsrc: restructure for out of tree (and on target)
> module builds
>
> ... we switched from a recipe that was deploying the entire
> source code
> to one that provides mainly the kernel headers (but not only).
> This
> change broke people expectations of this recipe while the
> description is
> also confusing: "Development source linux kernel. When built, this
> recipe packages the \source of the preferred virtual/kernel
> provider and
> makes it available for full kernel \development or external
> module builds".
>
> If size is not a problem (which can be the case when you
> compile on a
> builder for example and deploy only a OOT kernel module
> through other
> means), the full kernel source was a painless experience where
> things like
>
> commit a9471601fedd1f5087304eaa5fd39b98ae220313
> Author: Bruce Ashfield  >
> Date:   Thu Aug 30 09:45:41 2018 -0400
>     kernel-devsrc: fix arm/arm64 target module build
>
> ... would not appear. I understand the size impact on target
> and for
> those cases, continuously maintaining this recipe with new
> files/resources needed from the kernel, makes sense. So my
> proposal is
> to have two recipes, for example kernel-devsrc and kernel-fullsrc
> (kernel-src etc.) so people can choose what they need/want
> deploying/using. Or even have another devsrc provider. I'm
> open to any
> implementation detail. I'd just want to have an option for a
> full kernel
> source recipe.
>
>
> This is already planned, and hidden in bugzilla somewhere. I'll
> have some new kernel packaging
> options available for the fall release.
>
>
> It looks like the bugs that I was using for development were finally
> moved to resolved (they were a bit old, and contained collected
> information on various kernel packaging options .. my searching of
> bugzilla isn't turning it up at the moment). So I just created a new
> bug to track the development for 2.8.
>
> The issue with the multiple kernel source providers is really about
> test cycles. The smaller devsrc is for on-target module development
> and builds against the exported uapi headers, and that is what the
> nightly / automated tests will use. We had issues with both the amount
> of time it took to package the entire source, and the amount of space
> that it took up on the images. Hence the creation of devsrc.
>
> With new kernel-source and kernel-headers packages (the working
> names), they are really provided as references to the running kernel,
> and will largely be an exercise left up to the developer to use them
> as they want.

Right. So is there anything that holds us from creating two recipes -
one for what we currently have and one for what we used to have pre-thud
- find some pretty names and start from that? I'm asking just in case
I'm missing any internal architecture discussions or so.

And about test cycles, I'm not sure I understand why having a provider
vs having two separate recipes impact automated tests. In both cases you
will select whatever you want to test - by using a specific recipe or by
setting a preferred provider (I don't have a strong opinion here but I
was just curious about the time impact on automated tests).

Replying to the other email (this thread was forked). We have maintained
a similar kernel headers approach for a couple of years now. And many
times we found ourselves in the situation where something had to be
added/removed/checked - that was either kernel fork specific or
something that was added due to kernel updates. And this loop of fixes
here and there was obviously completely resolved by just using the "old"
kernel-devsrc which always had "everything" in. A good example is commit
a9471601fedd1f5087304eaa5fd39b98ae220313 I'm mentioning above. This kind
of stuff will always be needed - or at least in our experience was a
pretty often loop (when you try to support one kernel headers recipe
against tens of BSPs, you'll need cases, quirks and so on).

Regards,

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

-- 

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 10:39 AM Andrei Gherzan  wrote:

> On 23/05/2019 15.32, Bruce Ashfield wrote:
>
>
>
> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  wrote:
>
>> Hello,
>>
>> This might have been discussed before. I couldn't find a relevant
>> thread, but if it is so, just link me to it.
>>
>> Since thud, more specific since
>>
>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>> Author: Bruce Ashfield 
>> Date:   Sat Aug 18 22:50:44 2018 -0400
>> kernel-devsrc: restructure for out of tree (and on target) module
>> builds
>>
>> ... we switched from a recipe that was deploying the entire source code
>> to one that provides mainly the kernel headers (but not only). This
>> change broke people expectations of this recipe while the description is
>> also confusing: "Development source linux kernel. When built, this
>> recipe packages the \source of the preferred virtual/kernel provider and
>> makes it available for full kernel \development or external module
>> builds".
>>
>> If size is not a problem (which can be the case when you compile on a
>> builder for example and deploy only a OOT kernel module through other
>> means), the full kernel source was a painless experience where things like
>>
>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>> Author: Bruce Ashfield 
>> Date:   Thu Aug 30 09:45:41 2018 -0400
>> kernel-devsrc: fix arm/arm64 target module build
>>
>> ... would not appear. I understand the size impact on target and for
>> those cases, continuously maintaining this recipe with new
>> files/resources needed from the kernel, makes sense. So my proposal is
>> to have two recipes, for example kernel-devsrc and kernel-fullsrc
>> (kernel-src etc.) so people can choose what they need/want
>> deploying/using. Or even have another devsrc provider. I'm open to any
>> implementation detail. I'd just want to have an option for a full kernel
>> source recipe.
>>
>
> This is already planned, and hidden in bugzilla somewhere. I'll have some
> new kernel packaging
> options available for the fall release.
>
> Nice to hear that. Can you share more details on that because we plan to
> implement it for BalenaOS and would be a waste to redo what you already
> have or do it in different ways and reset afterwards.
>

The best place for that is in the bugzilla, I (re)created bug 13360 and
will start moving the details into that (they are scattered around).

Can you elaborate on the use case that is broken with devsrc ? I'd also
like to make changes to that package to support more common workflows if
we've missed them. Feel free to add them to the bug, that way I won't lose
track of them again.

Bruce



> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Andrei Gherzan]

On 23/05/2019 15.32, Bruce Ashfield wrote:
>
>
> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  > wrote:
>
> Hello,
>
> This might have been discussed before. I couldn't find a relevant
> thread, but if it is so, just link me to it.
>
> Since thud, more specific since
>
> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
> Author: Bruce Ashfield  >
> Date:   Sat Aug 18 22:50:44 2018 -0400
>     kernel-devsrc: restructure for out of tree (and on target)
> module builds
>
> ... we switched from a recipe that was deploying the entire source
> code
> to one that provides mainly the kernel headers (but not only). This
> change broke people expectations of this recipe while the
> description is
> also confusing: "Development source linux kernel. When built, this
> recipe packages the \source of the preferred virtual/kernel
> provider and
> makes it available for full kernel \development or external module
> builds".
>
> If size is not a problem (which can be the case when you compile on a
> builder for example and deploy only a OOT kernel module through other
> means), the full kernel source was a painless experience where
> things like
>
> commit a9471601fedd1f5087304eaa5fd39b98ae220313
> Author: Bruce Ashfield  >
> Date:   Thu Aug 30 09:45:41 2018 -0400
>     kernel-devsrc: fix arm/arm64 target module build
>
> ... would not appear. I understand the size impact on target and for
> those cases, continuously maintaining this recipe with new
> files/resources needed from the kernel, makes sense. So my proposal is
> to have two recipes, for example kernel-devsrc and kernel-fullsrc
> (kernel-src etc.) so people can choose what they need/want
> deploying/using. Or even have another devsrc provider. I'm open to any
> implementation detail. I'd just want to have an option for a full
> kernel
> source recipe.
>
>
> This is already planned, and hidden in bugzilla somewhere. I'll have
> some new kernel packaging
> options available for the fall release.
Nice to hear that. Can you share more details on that because we plan to
implement it for BalenaOS and would be a waste to redo what you already
have or do it in different ways and reset afterwards.

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

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

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield 
wrote:

>
>
> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  wrote:
>
>> Hello,
>>
>> This might have been discussed before. I couldn't find a relevant
>> thread, but if it is so, just link me to it.
>>
>> Since thud, more specific since
>>
>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>> Author: Bruce Ashfield 
>> Date:   Sat Aug 18 22:50:44 2018 -0400
>> kernel-devsrc: restructure for out of tree (and on target) module
>> builds
>>
>> ... we switched from a recipe that was deploying the entire source code
>> to one that provides mainly the kernel headers (but not only). This
>> change broke people expectations of this recipe while the description is
>> also confusing: "Development source linux kernel. When built, this
>> recipe packages the \source of the preferred virtual/kernel provider and
>> makes it available for full kernel \development or external module
>> builds".
>>
>> If size is not a problem (which can be the case when you compile on a
>> builder for example and deploy only a OOT kernel module through other
>> means), the full kernel source was a painless experience where things like
>>
>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>> Author: Bruce Ashfield 
>> Date:   Thu Aug 30 09:45:41 2018 -0400
>> kernel-devsrc: fix arm/arm64 target module build
>>
>> ... would not appear. I understand the size impact on target and for
>> those cases, continuously maintaining this recipe with new
>> files/resources needed from the kernel, makes sense. So my proposal is
>> to have two recipes, for example kernel-devsrc and kernel-fullsrc
>> (kernel-src etc.) so people can choose what they need/want
>> deploying/using. Or even have another devsrc provider. I'm open to any
>> implementation detail. I'd just want to have an option for a full kernel
>> source recipe.
>>
>
> This is already planned, and hidden in bugzilla somewhere. I'll have some
> new kernel packaging
> options available for the fall release.
>

It looks like the bugs that I was using for development were finally moved
to resolved (they were a bit old, and contained collected information on
various kernel packaging options .. my searching of bugzilla isn't turning
it up at the moment). So I just created a new bug to track the development
for 2.8.

The issue with the multiple kernel source providers is really about test
cycles. The smaller devsrc is for on-target module development and builds
against the exported uapi headers, and that is what the nightly / automated
tests will use. We had issues with both the amount of time it took to
package the entire source, and the amount of space that it took up on the
images. Hence the creation of devsrc.

With new kernel-source and kernel-headers packages (the working names),
they are really provided as references to the running kernel, and will
largely be an exercise left up to the developer to use them as they want.

Cheers,

Bruce



>
> Bruce
>
>
>
>>
>> Regards,
>>
>> --
>> Andrei Gherzan
>> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-devsrc used to be full source - not the case since thud

[Bruce Ashfield]

On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan  wrote:

> Hello,
>
> This might have been discussed before. I couldn't find a relevant
> thread, but if it is so, just link me to it.
>
> Since thud, more specific since
>
> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
> Author: Bruce Ashfield 
> Date:   Sat Aug 18 22:50:44 2018 -0400
> kernel-devsrc: restructure for out of tree (and on target) module
> builds
>
> ... we switched from a recipe that was deploying the entire source code
> to one that provides mainly the kernel headers (but not only). This
> change broke people expectations of this recipe while the description is
> also confusing: "Development source linux kernel. When built, this
> recipe packages the \source of the preferred virtual/kernel provider and
> makes it available for full kernel \development or external module builds".
>
> If size is not a problem (which can be the case when you compile on a
> builder for example and deploy only a OOT kernel module through other
> means), the full kernel source was a painless experience where things like
>
> commit a9471601fedd1f5087304eaa5fd39b98ae220313
> Author: Bruce Ashfield 
> Date:   Thu Aug 30 09:45:41 2018 -0400
> kernel-devsrc: fix arm/arm64 target module build
>
> ... would not appear. I understand the size impact on target and for
> those cases, continuously maintaining this recipe with new
> files/resources needed from the kernel, makes sense. So my proposal is
> to have two recipes, for example kernel-devsrc and kernel-fullsrc
> (kernel-src etc.) so people can choose what they need/want
> deploying/using. Or even have another devsrc provider. I'm open to any
> implementation detail. I'd just want to have an option for a full kernel
> source recipe.
>

This is already planned, and hidden in bugzilla somewhere. I'll have some
new kernel packaging
options available for the fall release.

Bruce



>
> Regards,
>
> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] kernel-devsrc used to be full source - not the case since thud

[Andrei Gherzan]

Hello,

This might have been discussed before. I couldn't find a relevant
thread, but if it is so, just link me to it.

Since thud, more specific since

commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
Author: Bruce Ashfield 
Date:   Sat Aug 18 22:50:44 2018 -0400
    kernel-devsrc: restructure for out of tree (and on target) module builds

... we switched from a recipe that was deploying the entire source code
to one that provides mainly the kernel headers (but not only). This
change broke people expectations of this recipe while the description is
also confusing: "Development source linux kernel. When built, this
recipe packages the \source of the preferred virtual/kernel provider and
makes it available for full kernel \development or external module builds".

If size is not a problem (which can be the case when you compile on a
builder for example and deploy only a OOT kernel module through other
means), the full kernel source was a painless experience where things like

commit a9471601fedd1f5087304eaa5fd39b98ae220313
Author: Bruce Ashfield 
Date:   Thu Aug 30 09:45:41 2018 -0400
    kernel-devsrc: fix arm/arm64 target module build

... would not appear. I understand the size impact on target and for
those cases, continuously maintaining this recipe with new
files/resources needed from the kernel, makes sense. So my proposal is
to have two recipes, for example kernel-devsrc and kernel-fullsrc
(kernel-src etc.) so people can choose what they need/want
deploying/using. Or even have another devsrc provider. I'm open to any
implementation detail. I'd just want to have an option for a full kernel
source recipe.

Regards,

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

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

Re: [yocto] Building single package as image, respecting dependencies

[Burton, Ross]

On Thu, 23 May 2019 at 13:46, Norman Stetter 
wrote:

> That seems to be a misunderstanding. I want to keep the OS image as small
> as possible to reduce boot time. We only use python for some test
> scenarios, so it doesn’t have to be included in the OS image. I did some
> measurements and including python3 in the OS image increased the boot time
> by over 30%. So the idea is to have it separately, and only mount it, when
> needed.
>

What filesystem are you using?  I wasn't aware of any modern file systems
where the number of files installed affected mount performance.

Could you just build two images and have a 'normal' image and a 'test
image'?  This is basically what the tools-testapps image feature is for.

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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Tg, Harish]

Hi,
 I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own 
recipe but I need to edit some recipe and add the command. Which is the place? 
I am using yocto for my project on TI platform and Linux.
Kindly help.


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

   1. GPLv3 package present in rootfs (virendra kumar thakur)
   2. Building single package as image, respecting dependencies
  (Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
VIRTUAL-RUNTIME_dev_manager = ""
VIRTUAL-RUNTIME_login_manager = ""
VIRTUAL-RUNTIME_init_manager = ""
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_keymaps = ""
VIRTUAL-RUNTIME_base-utils = ""
PREFERRED_PROVIDER_virtual/base-utils = ""

IMAGE_INSTALL = "python3"

But like this I can only manually exclude packages I already have in my main OS 
image. Some packages can't be excluded at all, as python3 depends on them and 
won't build if they are excluded.

Is there a way to have dependencies between images? So I could have the 
python-image build know which dependencies are already built into my OS image 
and therefore not include them itself?

Or would it be better to avoid building a second image and rather build 
'python3' with my OS-image, adding it to PACKAGE_EXCLUDE and from within this 
build process pack all python3 files into an image? If I were to pursue this 
method, any suggestions on how to separate the python3 files from the rest of 
my rootfs, including the necessary dependencies?

Any advice and idea is much appreciated.

Mit freundlichen Gr??en / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH

21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com

Re: [yocto] Building single package as image, respecting dependencies

[Norman Stetter]

Hi Ross,

thanks for clarifying that there are no dependencies between images.


Von: Burton, Ross [mailto:ross.bur...@intel.com]
Gesendet: Thursday, May 23, 2019 2:15 PM
An: Norman Stetter 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Building single package as image, respecting dependencies

On Wed, 22 May 2019 at 14:28, Norman Stetter 
mailto:norman.stet...@garz-fricke.com>> wrote:
Is there a way to have dependencies between images? So I could have the 
python-image build know which dependencies are already built into my OS image 
and therefore not include them itself?

No.  An image is a self-contained file system.  About 50% of your image recipe 
isn't helping your goal of an image that contains a single package.

What should be improved to achieve my goal of containing only the python3 
package and as little dependencies as possible?

I have to query your assumptions though: if you're going to have python3 in a 
filessytem that you mount when required, how are you saving space?


That seems to be a misunderstanding. I want to keep the OS image as small as 
possible to reduce boot time. We only use python for some test scenarios, so it 
doesn’t have to be included in the OS image. I did some measurements and 
including python3 in the OS image increased the boot time by over 30%. So the 
idea is to have it separately, and only mount it, when needed.


Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH

21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
[cid:image001.jpg@01D51176.36275C60]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun


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

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Bruce Ashfield]

On Thu, May 23, 2019 at 6:32 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> After some tests (and I had other problems to take care of, as well),
> here is the following:
>
> > These have all been discussed off an on over the past 5 years.
> > I can't get at bugzilla right now, but all the details are logged in
> cases.
> > A survey of all the distros, their kernel package, etc, were all looked
> at.
> > We had to balance the traditional packaging with some new concepts
> > and landed with what we have now.
>
> I tried several tests. This is my final conclusion (two cases):
>
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
>
> The kernel issue is described here: there is need to have the YOCTO
> minimum configuration with the kernel setup:
> [1] The entire kernel source code in:
> /usr/src/kernel/`uname-r`/
> [2] The header files in: /usr/src/kernel/`uname-r`/ directory structures>
>
> Point [1] is achieved with the following local.config file:
>
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
>
> Namely, with the following snippets in the local.conf:
> TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
> packagegroup-core-buildessential kernel-devsrc"
> KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
> packagegroup-core-buildessential kernel-devsrc"
> KERNEL_DEV_MODULE = "kernel-modules"
> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> ${KERNEL_DEV_TOOLS} \
> systemtap \
> "
>
> Problem with this approach is that such a kernel makes the rootfs too
> big and impractical:
> -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
> core-image-minimal-beaglebone.rootfs.tar.xz
>
> The main issue is point [2]: how to achieve it?
> The suggestion is to introduce the new package in YOCTO kernel,
> called: kernel-headers
> The OBVIOUS benefit is that it will serve to the purpose of building
> modules out of the tree on the target with
> minimal mpact to rootfs!
>

There are already 2.8 development items for some new, optional kernel
packages. One for source and one for headers.
So in the coming months, things will be different.

That being said, they are optional. I might be misreading, but what exactly
are you trying to build that requires that specific structure ? We are both
rebuilding the entire kernel and out of tree modules all the time with the
existing structure/path of the on-target installs.

kernel-devsrc itself is a small package (size wise), so it shouldn't be the
cause of your expanded rootfs footprint.

Bruce



>
> Thank you,
> Zoran Stojsavljevic
> ___
>
> On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
>  wrote:
> >
> >
> >
> > On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> >>
> >> > The core-image-kernel-dev image is how I do all my on target
> >> > testing when I introduce a new reference kernel for a release.
> >>
> >> Maybe you are correct. Maybe I should use/add in my local.conf the
> following:
> >>
> >> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
> >> packagegroup-core-buildessential kernel-devsrc"
> >> KERNEL_DEV_MODULE ?= "kernel-modules"
> >> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
> >>  ${KERNEL_DEV_TOOLS} \
> >>  systemtap \
> >> "
> >> I need to try these... Maybe this addendum will solve the $1 mio USD
> problem?!
> >>
> >> > And IIRC the autobuilders are using a sato based image (Richard
> >> > could confirm more easily that I could what image type the
> >> > autobuilders are using for hello-world on target module tests).
> >>
> >> I am just advertising something more simple. To have mandatory
> >> /lib/modules/`uname -r` directory. And introduce few more packages, as
> >> Fedora distro, for example, has: kernel-headers (assuming YOCTO
> >> rootfs, the following will be installed: /usr/src/kernel/`uname
> >> -r`/. This also makes addition of
> >> /lib/modules/`uname -r`/build file (which is soft link to
> >> usr/src/kernel/`uname -r`).
> >
> >
> > These have all been discussed off an on over the past 5 years. I can't
> get at bugzilla right now, but all the details are logged in cases. A
> survey of all the distros, their kernel package, etc, were all looked at.
> We had to balance the traditional packaging with some new concepts and
> landed with what we have now.
> >
> >
> >>
> >> Or kernel-devel package. Then, the whole current kernel source code
> >> will be introduced, and also support for it.
> >
> >
> > There's a case for this one as well, I'll probably have it done for the
> fall release. But our devsrc used to pretty much be the full source it has
> now been pruned down to something more manageable.  There are definitely
> some cases for having the full source on the target again, and it will be a
> separate package, just not the minimal one to build out of tree modules,
> etc.
> >
> >
> >
> >>
> 

Re: [yocto] PN is uppercase

[Ralf Spiwoks]

Hi Ross,

Thanks for your email. I am realising that I have not replied to your
email earlier. Sorry. I guess it was partly because your answer put
me slightly off. On the one hand, I thought that as a general approach,
Linux was case sensitive, unlike its big rival Windows, and I was not
aware  of package managers which would explicitly forbid uppercase
package names. I find the approach of allowing only lowercase package
names quite limiting, and frankly a drawback for using Yocto

On the other hand I have a few tens of packages to maintain, which
have uppercase letters in the package names and which did work with
Yocto in previous versions. So, because of a new convention we would
have to rework some of the packages or ignore the warning messages.
And until we find the effort for reworking those package recipes we
will stay with the latter option.

Thanks for your patience and your explanations. Cheers,

Ralf.

On 4/2/19 1:54 PM, Burton, Ross wrote:

On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  wrote:

TWO questions:

1) Are those two issues related?


Probably not, unless you're trying to use a mixed-case override.


2) What is the logic behind allowing only lower case package names? This is to 
me
 a serious restriction on the use of Yocto.


Two reasons: some package managers forbid packages with uppercase
names; and for performance reasons overrides are lowercase and as
package names are often embedded in overrides this implies that
package names need to be lowercase.

What's the problem with using lowercase names?

Ross


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

[yocto] Rocko broke down

[Ari-Pekka Sihvonen]

I am developing system using raspberry and made a pull on every yocto metas. Chen I baked the Image there was a major problem. My system did not read config.txt and cmdline.txt anymore. So the resulting Image was totally unusable. Lucily I had a copy of yocto tree so I could go on building images. Has something changed on rocko branch.RegadsAP SihvonenSent from my Huawei phone-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building single package as image, respecting dependencies

[Burton, Ross]

On Wed, 22 May 2019 at 14:28, Norman Stetter 
wrote:

> Is there a way to have dependencies between images? So I could have the
> python-image build know which dependencies are already built into my OS
> image and therefore not include them itself?
>

No.  An image is a self-contained file system.  About 50% of your image
recipe isn't helping your goal of an image that contains a single package.

I have to query your assumptions though: if you're going to have python3 in
a filessytem that you mount when required, how are you saving space?

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

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Zoran Stojsavljevic]

After some tests (and I had other problems to take care of, as well),
here is the following:

> These have all been discussed off an on over the past 5 years.
> I can't get at bugzilla right now, but all the details are logged in cases.
> A survey of all the distros, their kernel package, etc, were all looked at.
> We had to balance the traditional packaging with some new concepts
> and landed with what we have now.

I tried several tests. This is my final conclusion (two cases):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt

The kernel issue is described here: there is need to have the YOCTO
minimum configuration with the kernel setup:
[1] The entire kernel source code in:
/usr/src/kernel/`uname-r`/
[2] The header files in: /usr/src/kernel/`uname-r`/

Point [1] is achieved with the following local.config file:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf

Namely, with the following snippets in the local.conf:
TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE = "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
${KERNEL_DEV_TOOLS} \
systemtap \
"

Problem with this approach is that such a kernel makes the rootfs too
big and impractical:
-rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
core-image-minimal-beaglebone.rootfs.tar.xz

The main issue is point [2]: how to achieve it?
The suggestion is to introduce the new package in YOCTO kernel,
called: kernel-headers
The OBVIOUS benefit is that it will serve to the purpose of building
modules out of the tree on the target with
minimal mpact to rootfs!

Thank you,
Zoran Stojsavljevic
___

On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
 wrote:
>
>
>
> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic 
>  wrote:
>>
>> > The core-image-kernel-dev image is how I do all my on target
>> > testing when I introduce a new reference kernel for a release.
>>
>> Maybe you are correct. Maybe I should use/add in my local.conf the following:
>>
>> KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
>> packagegroup-core-buildessential kernel-devsrc"
>> KERNEL_DEV_MODULE ?= "kernel-modules"
>> CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
>>  ${KERNEL_DEV_TOOLS} \
>>  systemtap \
>> "
>> I need to try these... Maybe this addendum will solve the $1 mio USD 
>> problem?!
>>
>> > And IIRC the autobuilders are using a sato based image (Richard
>> > could confirm more easily that I could what image type the
>> > autobuilders are using for hello-world on target module tests).
>>
>> I am just advertising something more simple. To have mandatory
>> /lib/modules/`uname -r` directory. And introduce few more packages, as
>> Fedora distro, for example, has: kernel-headers (assuming YOCTO
>> rootfs, the following will be installed: /usr/src/kernel/`uname
>> -r`/. This also makes addition of
>> /lib/modules/`uname -r`/build file (which is soft link to
>> usr/src/kernel/`uname -r`).
>
>
> These have all been discussed off an on over the past 5 years. I can't get at 
> bugzilla right now, but all the details are logged in cases. A survey of all 
> the distros, their kernel package, etc, were all looked at. We had to balance 
> the traditional packaging with some new concepts and landed with what we have 
> now.
>
>
>>
>> Or kernel-devel package. Then, the whole current kernel source code
>> will be introduced, and also support for it.
>
>
> There's a case for this one as well, I'll probably have it done for the fall 
> release. But our devsrc used to pretty much be the full source it has now 
> been pruned down to something more manageable.  There are definitely some 
> cases for having the full source on the target again, and it will be a 
> separate package, just not the minimal one to build out of tree modules, etc.
>
>
>
>>
>>
>> SDK building with such a support is good/cool. But sometimes, before
>> introducing SDK, some tests should be done on target. NO need to
>> optionally include built-in layer hello-world driver example. Since I
>> (or you name the person) have own test drivers, which will be imported
>> out of tree, externally, to the target test bed!
>>
>
> I never use the SDK myself, so you are not alone in not going to it first. 
> Hopefully I'll get some new patches out in the coming month before summer 
> holidays really kick in.
>
> Bruce
>
>
>>
>> Just thinking loud...
>>
>> Zoran
>> ___
>>
>> On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield  
>> wrote:
>> >
>> >
>> >
>> > On Wed, May 15, 2019 at 3:44 AM Zoran Stojsavljevic 
>> >  wrote:
>> >>
>> >> > That's correct. That command only adds the kernel source and
>> >> > build infrastructure to the SDK, not to your target image. You'd still
>> >> > 

Re: [yocto] [Yocto] RPI WiFi not loading module

[Belisko Marek]

Hi,

On Thu, May 23, 2019 at 11:15 AM Jonas Andersson
 wrote:
>
> Hi
>
> I have problem to get my WiFi working on boot on Raspberry Pi 3.
for rpi issues I would suggest to open ticket on meta-raspberrypi
github with stated which yocto branch and other details. Thanks.
>
> The problem is that wlan0 interface not showing up, if I manually run 
> modprobe brcmfmac it works.
>
> To try to "force" the load of brcmfmac i added it to KERNEL_MODULE_AUTOLOAD 
> and that generated an file in /etc/modules-load.d/ -> brcmfmac.conf but it is 
> still not loaded.
>
> I use systemd an to my understanding systemd-modules-load.service is handling 
> module auto load, but that file is missing and I cant see how to include it 
> in my build.
>
> Building thud version and I have added the following to my image recipe:
>
> DISTRO_FEATURES_append = " wifi"
>
> IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base 
> module-init-tools"
>
> IMAGE_INSTALL_append = "\
> linux-firmware-rpidistro-bcm43430 \
> linux-firmware-rpidistro-bcm43455 \
> bluez-firmware-rpidistro-bcm43430a1-hcd \
> bluez-firmware-rpidistro-bcm4345c0-hcd \
>  "
> Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf file 
> and that work when I manually loads the module.
>
> Best regards
> Jonas
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

[linux-yocto] [linux-yocto-rt v5.0/standard/preempt-rt/base][PATCH 1/1] genirq: invoke kthread_cancel_work_sync on RT kernel to aviod compile error

[Liwei Song]

fix following compile error:

kernel/irq/manage.c:388:20: error: passing argument 1 of 'cancel_work_sync' 
from incompatible pointer type

The compile error was got with CONFIG_PREEMPT_RT_BASE enabled,
On RT kernel work_struct was replaced by kthread_work, so here
we should use kthread_cancel_work_sync() instead of cancel_work_sync()
to fix it.

Signed-off-by: Liwei Song 
---
 kernel/irq/manage.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index f72bd3a357da..143f87bbff48 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -385,7 +385,11 @@ irq_set_affinity_notifier(unsigned int irq, struct 
irq_affinity_notify *notify)
raw_spin_unlock_irqrestore(>lock, flags);
 
if (old_notify) {
+#ifdef CONFIG_PREEMPT_RT_BASE
+   kthread_cancel_work_sync(_notify->work);
+#else
cancel_work_sync(_notify->work);
+#endif
kref_put(_notify->kref, old_notify->release);
}
 
-- 
2.18.1

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

[yocto] Fwd: /usr/share/common-license package/recipeinfo contains GPLv3 info

[virendra kumar thakur]

Hello team,

I am trying to build yocto image without GPLv3 package, I have added below
things in local.conf and enable meta-gplv2 layer.

INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0" in local.conf.

After verifying from package.manifest and license.manifest file in
build/tmp/deploy/license/ directory I observe that no GPLv3 package is
present in rootfs.

But I can see in
rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo

LICENSE: GPLV2+ + +
PR: r0
PV : 1.8.4

Is present..

My doubt is why any GPLv3 is present in common-license directory?

From: "Burton, Ross" 
To: virendra kumar thakur 
Cc: Yocto-mailing-list 
Subject: Re: [yocto] GPLv3 package present in rootfs

On Wed, 22 May 2019 at 06:26, virendra kumar thakur
 wrote:
> still some package gnutls, libidn2, libassuan, are added into rootfs.

Randomly picking libassuan:

LICENSE_${PN} = "LGPLv2.1+"

The library itself is LGPL-2.  Have you verified the *package*
licenses for what is actually going into the image?

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

Re: [yocto] distrodata documentation in 2.7 Mega Manual

[Alexander Kanavin]

On Thu, 23 May 2019 at 02:22, Scott Rifenbark  wrote:
>  * In dev-manual's "Using the Auto Upgrade Helper (AUH)" section - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#gs-using-the-auto-upgrade-helper:
>  Step 5 talks about making configurations in the local.conf file.  First 
> thing is to enable "distrodata" by inheriting the class.  Do we have an 
> equivalent for this now that the class is gone?

This is no longer necessary, you can remove the step.

> * in ref-manual's "do_distrodata" task section - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-distrodata:
>  Does this task disappear as well?  Or, is there an equivalent?

There is no equivalent, you can remove the sectrion.

> * In ref-manual's "do_checkpkg" task section - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-checkpkg:
>  This task was included as part of the distrodata.bbclass.  How do we address 
> the do_checkpkg task section now?

The equivalent functionality is provided by running devtool - 'devtool
latest-version' for one recipe, 'devtool check-upgrade-status' for
several (or all).

> * In the UPSTREAM_CHECK_GETTAGREGEX variable description in the ref-manual 
> glossary - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_GITTAGREGEX:
>  How do we change this?
> * in the UPSTREAM_CHECK_REGEX variable description also in the glossary - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_REGEX:
>  How do we change this?
> * in the UPSTREAM_CHECK_URI variable description also int he glossary - 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_URI:
>  How do we change this?

All three should refer to the equivalent replacement (see above)
provided by devtool.

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

[yocto] [Yocto] RPI WiFi not loading module

[Jonas Andersson]

Hi

I have problem to get my WiFi working on boot on Raspberry Pi 3.

The problem is that wlan0 interface not showing up, if I manually
run modprobe brcmfmac it works.

To try to "force" the load of brcmfmac i added it to KERNEL_MODULE_AUTOLOAD and
that generated an file in /etc/modules-load.d/ -> brcmfmac.conf but it is
still not loaded.

I use systemd an to my understanding systemd-modules-load.service is
handling module auto load, but that file is missing and I cant see how to
include it in my build.

Building thud version and I have added the following to my image recipe:

DISTRO_FEATURES_append = " wifi"

IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base
module-init-tools"

IMAGE_INSTALL_append = "\
linux-firmware-rpidistro-bcm43430 \
linux-firmware-rpidistro-bcm43455 \
bluez-firmware-rpidistro-bcm43430a1-hcd \
bluez-firmware-rpidistro-bcm4345c0-hcd \
 "
Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf
file and that work when I manually loads the module.

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