1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Thud community support

Armin Kuster
 

The Poky thud branch is now under 'Community support' and is seeking a
maintainer to continue supporting the following repos for the thud release:

bitbake, core, meta-yocto and yocto-docs.


There will be no more point releases.

see
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Maintainer_Procedures 
to get an idea on what is expected.

The one thing we (YP) don't know is if there will be AutoBuilder
resources available.  Please contact me or Richard regarding that statement.

If no one steps up by April 24th (six weeks -ish from now), Thud will be
moved to EOL status.

- Armin
Re: menuconf u-boot

Denys Dmytriyenko
 

What's u-boot-imx?

It's definitely not in openembedded-core, so there's no reason to cross-post
there.

If google doesn't help, it's recommended to post such specific questions to
the corresponding mailing list for the layer this recipe comes from.

If it's not clear where the recipe comes from, Layer Index can help:
https://layers.openembedded.org/

Thanks.

--
Denys

On Fri, Mar 13, 2020 at 08:15:17PM +1100, JH wrote:
Hi,

I tried to run bitbake -c menuconfig u-boot, it popped up a terminal
u-boot-imx configuration:

make: *** No rule make target 'menuconfig'. Stop.
Command failed.
Press any key to continue...

How can I run menuconfig u-boot?

Thank you.

Kind regards,

- jh
Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Denys Dmytriyenko
 

Why not use SRCREV?
Also, bitbake has its own mailing list.

Denys

On Thu, Mar 12, 2020 at 02:55:59PM +0100, Matthias Schoepfer via Lists.Yoctoproject.Org wrote:
Hi!

We have noticed the following issue: We keep the versions of out
software by means of tags on the git repositories, i.e. during the
build, somethings like git describe --tags gets called. In yocto,
our recipe of SomeLibrary might look then similar to this:

SRC_URI = "git://our.private.gitserver.org/git/SomeLibrary.git;tags=v${PV}"

When we build the image, and *then* apply a tag to HEAD, that was
already built before, it seems like the tags are not fetched (my
guess is git fetcher sees that origins HEAD and local HEAD have the
same hash and is fine with it).

The error is, that while the correct version is built, it will
report itself with a wrong version.

Is this a bug?

Regards,

Matthias

--
Dr.-Ing. Matthias Schöpfer
matthias.schoepfer@...
Re: Webcam Streaming

Khem Raj
 

On 3/12/20 5:42 PM, Andrés Jiménez wrote:
Hello,
I need to create an image that allows me to stream from a webcam connected to a raspberry3b to an external device (like a computer) via Wi-Fi, I can connect the computer and the raspberry via wifi but the directories added to the image for streaming and controlling the webcam were unsuccessful, I have tried with gstream. Is there any recipe for this case? Also I am using the pocky warrior version
maybe try vlc

Thanks
menuconf u-boot

JH
 

Hi,

I tried to run bitbake -c menuconfig u-boot, it popped up a terminal
u-boot-imx configuration:

make: *** No rule make target 'menuconfig'. Stop.
Command failed.
Press any key to continue...

How can I run menuconfig u-boot?

Thank you.

Kind regards,

- jh
Webcam Streaming

andjjimenez@...
 

Hello,

I need to create an image that allows me to stream from a webcam connected to a raspberry3b to an external device (like a computer) via Wi-Fi, I can connect the computer and the raspberry via wifi but the directories added to the image for streaming and controlling the webcam were unsuccessful, I have tried with gstream. Is there any recipe for this case? Also I am using the pocky warrior version
Thanks
Re: Getting kernel patch to work

Greg Wilson-Lindberg
 

Hi Denys,
I guess I have been rather blind when putting this together. That's what I get for not copying and pasting.

Thanks,
Greg

-----Original Message-----
From: Denys Dmytriyenko <denis@...>
Sent: Wednesday, March 11, 2020 4:55 PM
To: Greg Wilson-Lindberg <GWilson@...>
Cc: Anders Montonen <Anders.Montonen@...>; Yocto list discussion
<yocto@...>
Subject: Re: [yocto] Getting kernel patch to work

${} and not $()

On Wed, Mar 11, 2020 at 11:43:36PM +0000, Greg Wilson-Lindberg wrote:
Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried
both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:'
or '$(THISDIR)/files:') in the list of searched directories. I would think that I
should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-
suspend.patch"


Regards,
Greg


________________________________
From: yocto@... <yocto@...> on
behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work

Hi,

On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...>
wrote:

SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-
GWL.patch"

It looks like you have a typo here, the last letter of SRC_URI isn't
capitalized.

-a
Re: SDKPATH: how to change?

Gabriele
 

Ciao Mauro,

you can change the directory during installation


More info with


Gabriele


On Thu, Mar 12, 2020 at 3:06 PM Mauro Ziliani <mauro@...> wrote:
Hi all

I work woth imx6dl-sabresd and Krogoth.

When I build the sdk ( -c populate_sdk) the final .sh file get the
installation path as

/opt/fsl-imx-x11 ...

So I think the path is build from ${DISTRO} var as

/opt/${DISTRO}


I need to produce 3 sdk with it own final path
/opt/fsl-imx-x11-dev1

/opt/fsl-imx-x11-dev2

/opt/fsl-imx-x11-dev3


The form should be

/opt/${DISTRO}-${MYDEVICE}

So I'd like to use a common .inc and change the MYDEVICE


But I don't find where the final sdk path is combined


Any idea?


MZ
SDKPATH: how to change?

Mauro Ziliani
 

Hi all

I work woth imx6dl-sabresd and Krogoth.

When I build the sdk ( -c populate_sdk) the final .sh file get the installation path as

/opt/fsl-imx-x11 ...

So I think the path is build from ${DISTRO} var as

/opt/${DISTRO}


I need to produce 3 sdk with it own final path
/opt/fsl-imx-x11-dev1

/opt/fsl-imx-x11-dev2

/opt/fsl-imx-x11-dev3


The form should be

/opt/${DISTRO}-${MYDEVICE}

So I'd like to use a common .inc and change the MYDEVICE


But I don't find where the final sdk path is combined


Any idea?


MZ
git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Matthias Schoepfer
 

Hi!

We have noticed the following issue: We keep the versions of out software by means of tags on the git repositories, i.e. during the build, somethings like git describe --tags gets called. In yocto, our recipe of SomeLibrary might look then similar to this:

SRC_URI = "git://our.private.gitserver.org/git/SomeLibrary.git;tags=v${PV}"

When we build the image, and *then* apply a tag to HEAD, that was already built before, it seems like the tags are not fetched (my guess is git fetcher sees that origins HEAD and local HEAD have the same hash and is fine with it).

The error is, that while the correct version is built, it will report itself with a wrong version.

Is this a bug?

Regards,

Matthias

--
Dr.-Ing. Matthias Schöpfer
matthias.schoepfer@...
Re: Getting kernel patch to work

Denys Dmytriyenko
 

${} and not $()

On Wed, Mar 11, 2020 at 11:43:36PM +0000, Greg Wilson-Lindberg wrote:
Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:' or '$(THISDIR)/files:') in the list of searched directories. I would think that I should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend.patch"


Regards,
Greg


________________________________
From: yocto@... <yocto@...> on behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work

Hi,

On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...> wrote:

SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-GWL.patch"
It looks like you have a typo here, the last letter of SRC_URI isn't capitalized.

-a
Re: Getting kernel patch to work

Greg Wilson-Lindberg
 

Hi Anders,

Good catch, thanks for seeing that.


I also realized that I was missing a FILESEXTRAPATHS_prepend. I have tried both:

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
and
FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

In both cases I don't see the expansion (i.e. I see '$(FILE_DIRNAME)/files:' or '$(THISDIR)/files:') in the list of searched directories. I would think that I should see the expanded directory path.

Here is the net beginning of my .bbappend file:

# additions to Kernel configuration

FILESEXTRAPATHS_prepend := "$(FILE_DIRNAME)/files:"
#FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"
SRC_URI+= "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend.patch"


Regards,
Greg

From: yocto@... <yocto@...> on behalf of Anders Montonen <Anders.Montonen@...>
Sent: Tuesday, March 10, 2020 11:07:33 PM
To: Yocto list discussion
Subject: Re: [yocto] Getting kernel patch to work
 
Hi,

> On 11 Mar 2020, at 1:57, Greg Wilson-Lindberg <GWilson@...> wrote:
>
> SRC_URi += "file://0001-drm-vc4-Keep-the-binner-BO-through-suspend-GWL.patch”

It looks like you have a typo here, the last letter of SRC_URI isn’t capitalized.

-a
Re: Splitting a recipe into multiple packages and inherit extrausers

Patrick Doyle <wpdster@...>
 

On Wed, Mar 11, 2020 at 1:26 PM Patrick Doyle via
Lists.Yoctoproject.Org <wpdster=gmail.com@...>
wrote:
I want the daemon to run as a non-root user, so I have "inherit
extrausers" in my recipe.

Suppose I only wanted to create that extra user iff the package
containing the daemon was included in the image. Is this possible?
How?
Apparently, the answer is that I should use "inherit adduser" instead
of "inherit extrausers". See
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-classes-useradd.

--wpd
Re: EXTRA_OECMAKE options are ignored #sdk #yocto

Khem Raj
 

On 3/11/20 3:37 AM, Armando Hernandez wrote:
Hi,
I built an eSDK.
Now I'm using devtool add to create a hello world recipe.
Once the recipe was in place, I added some cmake optoins via EXTRA_OECMAKE in htis way:
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE=BOTH \
 -CMAKE_FIND_ROOT_PATH=/home/user/SDK/sysroots/x86_64-pokysdk-linux \
                   "
Now, the problem is that after running devtool  build test-hello (where test-hello is my recipe as you might have assumed), these variables are overwritten with other values.
How can I successfully pass the correct cmake options via EXTRA_OECMAKE on the recipe?

please post your recipe
Splitting a recipe into multiple packages and inherit extrausers

Patrick Doyle <wpdster@...>
 

I may be overthinking/overtweaking this but...

I have a recipe with that creates a number of executables, one of
which is a daemon.

I have split that daemon off into its own separate package using the
PACKAGES =+ "${PN]-blah-blah-blah" construct.

I want the daemon to run as a non-root user, so I have "inherit
extrausers" in my recipe.

Suppose I only wanted to create that extra user iff the package
containing the daemon was included in the image. Is this possible?
How?

--wpd
Re: Uboot NetBoot IMX8

Trevor
 

Hi Nicolas,


Thanks!

Extracting as root did the trick, I was extracting using the desktop extracter before.

I didnt end up adding fsid=root option because that caused it not to mount at all for some reason.

Thanks,
Trevor




From: yocto@... <yocto@...> on behalf of Nicolas Jeker <n.jeker@...>
Sent: Wednesday, March 11, 2020, 1:43 AM
To: yocto@...
Subject: Re: [yocto] Uboot NetBoot IMX8

On Wed, 2020-03-11 at 00:39 +0000, Trevor wrote:
> > Mar 11 00:21:16 b2qt-b9-imx8mq mount[2611]: mount: only root can
> > use "--types" option (effective UID is 1000)
>
>
> The mount error seems prevalent across all the errors.  somehow UID
> is 1000 when it should be 0 during boot?

By googling the error message I found a thread where somebody has the
same question, but I wouldn't recommend following the advice there
(running the yocto build as root). How do you extract the root
filesystem to your NFS directory? Maybe something is wrong there and
the files get extracted with UID 1000 as owner. For reference, I use
this command which seems to work fine:

sudo tar --strip-components=1 -C /srv/nfs/rootfs -xf images/apalis-
imx6-mainline/Apalis-iMX6-Mainline_Image.rootfs.tar.xz

Also check that there are no setuid/setgid bits set.

> On the Host side, here are the /etc/exports options for NFS:
>  *(rw,sync,insecure,no_subtree_check,no_root_squash)

I'm using pretty much the same NFS options, the only difference I could
spot is an additional 'fsid=root' in my exports which is NFSv4
specific.
Re: Should changing a task in the .bb file cause the task to be rerun?

Sean McKay
 

I actually went on vacation right after I sent that message. (Thank you for your incredibly quick reply, by the way!)
Once I get back late next week, I'll try to see how reproducible it is in our environment and if so, what the minimum steps are to do so.

Thanks!
-Sean

~Sean
Sent from my phone. Please forgive terseness and typos!

From: Mikko.Rapeli@... <Mikko.Rapeli@...>
Sent: Wednesday, March 11, 2020 12:45:21 PM
To: richard.purdie@... <richard.purdie@...>
Cc: McKay, Sean <sean.mckay@...>; yocto@... <yocto@...>
Subject: Re: [yocto] Should changing a task in the .bb file cause the task to be rerun?
 
On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
> On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
> > On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
> > > On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
> > > > This is probably a fairly short question (I hope):
> > > > I’m working on a branch based on zeus. I found a bug in the way that
> > > > one of our recipes was handling something during do_configure (which
> > > > caused an error to pop up in a do_compile task). When I modified the
> > > > do_configure task (do_configure_append, actually) to behave properly
> > > > (which involved changing the actual commands run in that function)
> > > > and reran bitbake -c compile <recipe>, the do_configure task wasn’t
> > > > rerun despite the change to the function’s code.
> > > > 
> > > > Is it safe to assume this means we’ve done something to mess up the
> > > > way our system is processing things? Or is that expected behavior
> > >
> > > Its not expected behaviour and yes, it sounds like something is messed
> > > up...
> >
> > This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
> > 3.0 zeus.
> >
> > That's why I always write:
> >
> > $ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe
> >
> > when debugging changes in recipes to_compile and other dependent tasks.
> > I'm also cleaning up sstate to be sure it's not corrupt or filled with
> > somehow bad data.
>
> This is bad and shouldn't be happening. Can anyone provide some
> examples I can look at?
>
> You shouldn't ever need to run cleansstate in particular. If you have
> to, there is another underlying bug that should get fixed.

Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.

-Mikko
Re: Should changing a task in the .bb file cause the task to be rerun?

Robert P. J. Day
 

Quoting Mikko Rapeli <mikko.rapeli@...>:

On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
This is probably a fairly short question (I hope):
I’m working on a branch based on zeus. I found a bug in the way that
one of our recipes was handling something during do_configure (which
caused an error to pop up in a do_compile task). When I modified the
do_configure task (do_configure_append, actually) to behave properly
(which involved changing the actual commands run in that function)
and reran bitbake -c compile <recipe>, the do_configure task wasn’t
rerun despite the change to the function’s code.

Is it safe to assume this means we’ve done something to mess up the
way our system is processing things? Or is that expected behavior
Its not expected behaviour and yes, it sounds like something is messed
up...
This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
3.0 zeus.

That's why I always write:

$ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c
compile recipe

when debugging changes in recipes to_compile and other dependent tasks.
I'm also cleaning up sstate to be sure it's not corrupt or filled with
somehow bad data.
This is bad and shouldn't be happening. Can anyone provide some
examples I can look at?

You shouldn't ever need to run cleansstate in particular. If you have
to, there is another underlying bug that should get fixed.
Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.
Have you verified with "bitbake -e" that the configure task was really
appended to WRT the build? That's the first thing I would check.

rday
Re: Should changing a task in the .bb file cause the task to be rerun?

Mikko Rapeli
 

On Tue, Mar 10, 2020 at 11:37:55AM +0000, Richard Purdie wrote:
On Tue, 2020-03-10 at 11:33 +0000, Mikko.Rapeli@... wrote:
On Fri, Feb 28, 2020 at 11:25:59PM +0000, Richard Purdie wrote:
On Fri, 2020-02-28 at 22:51 +0000, Sean McKay wrote:
This is probably a fairly short question (I hope):
I’m working on a branch based on zeus. I found a bug in the way that
one of our recipes was handling something during do_configure (which
caused an error to pop up in a do_compile task). When I modified the
do_configure task (do_configure_append, actually) to behave properly
(which involved changing the actual commands run in that function)
and reran bitbake -c compile <recipe>, the do_configure task wasn’t
rerun despite the change to the function’s code.

Is it safe to assume this means we’ve done something to mess up the
way our system is processing things? Or is that expected behavior
Its not expected behaviour and yes, it sounds like something is messed
up...
This is what I've come to expect with yocto 2.0 jethro, 2.5 sumo and
3.0 zeus.

That's why I always write:

$ bitbake -c clean recipe && bitbake -c cleansstate && bitbake -c compile recipe

when debugging changes in recipes to_compile and other dependent tasks.
I'm also cleaning up sstate to be sure it's not corrupt or filled with
somehow bad data.
This is bad and shouldn't be happening. Can anyone provide some
examples I can look at?

You shouldn't ever need to run cleansstate in particular. If you have
to, there is another underlying bug that should get fixed.
Sadly custom bbclasses and BSP layers have this effect on my builds and I
can't fully trust local incremental builds. Hence I clean sstate cache
often.

-Mikko
EXTRA_OECMAKE options are ignored #sdk #yocto

Armando Hernandez
 

Hi,

I built an eSDK.
Now I'm using devtool add to create a hello world recipe.
Once the recipe was in place, I added some cmake optoins via EXTRA_OECMAKE in htis way:
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE=BOTH \
                   -CMAKE_FIND_ROOT_PATH=/home/user/SDK/sysroots/x86_64-pokysdk-linux \
                   "

Now, the problem is that after running devtool  build test-hello (where test-hello is my recipe as you might have assumed), these variables are overwritten with other values.

How can I successfully pass the correct cmake options via EXTRA_OECMAKE on the recipe?
9021 - 9040 of 57772