Date   

Re: QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Adrian Bunk
 

On Mon, Mar 16, 2020 at 11:45:09AM +0000, Sangeeta Jain wrote:
...
Runtime auto test for following platforms:
...
6. MPC8315e-rdb
...
This platform has been removed from master, and is therefore not in M3.

Thanks,
Sangeeta
cu
Adrian


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

Matthias Schoepfer
 

Hi Alexander,

thanks for your message. I will try to explain my issue once again, since it still seems not clearly formulated. We build our images on CI (Jenkins). There, we have a shared download dir, so that we do not have to fetch all sources on every build. This gets shared for our "experimental" builds, that use latest git master HEAD (yes, evil AUTOREV) and our "stable" builds, where only tagged (i.e. no AUTOREV versions) are used. Our software uses the git tag to create a version. So, when on experimental, you might get something like:

# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.3-3 (gabcdef1)

What happens is, that people check their changes on the experimental build. After testing, it is considered for the next release, so they attach a version tag to the git repository and update the _<version>.bb accordingly. Now they build the image with the "stable" profile. But the hash "abcdef1" has not changed. Hence, although we pushed a new tag, yocto git fetcher does not update the cached download git, since git hashes match (same with SRCREV). Which means, even tough we have a recipe ourcoolsoftware_1.2.4.bb with SRCREV="abcdef1..." which will build the correct hash, our software checks the local repository, which is missing the last tag and will still be reporting a wrong version 1.2.3-3 for example.

If we were to do a
bitbake -c cleanall ourcoolsoftware && bitbake ourcoolimage

then we get
# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.4 (gabcdef1)

because we artificially force a complete fetch of the repository.

We usually do a clean build (no sstate / tmp / etc.) but we use the download dir, because we do not see why we would need to download gcc etc. every time. A workaround would be to bitbake -c cleanall our packages, but it seems hacky and prone to error (need to keep lists of our used software in at least two places). My question is therefore, if this is a "bug" and if we were to investigate this and propose a patch, if this could this be considered for merge, or if this behaviour is intentional and adding a fetch --tags would be considered harmful in any way.

Hope, I could bring my point across now.

Thanks and Regards,

Matthias

On 3/16/20 9:43 AM, Alexander Kanavin wrote:
'devtool upgrade' updates SRCREV to match the version tag that you specify:
devtool upgrade -V <tag>
If you omit -V, it will upgrade to the latest tag. It updates PV as well. Why is it unsuitable for you?
Alex
On Mon, 16 Mar 2020 at 09:35, Matthias Schöpfer <matthias.schoepfer@... <mailto:matthias.schoepfer@...>> wrote:
Hi Alexander,
does it solve the Problem of a SRCREV, that has been fetched (for
example for a _git testbuild) and now gets a tag applied and build with
the _<version> build. The problem is *not* that the yocto PV package is
wrong *nor* that the wrong version of the software gets build! The
problem is, that the tag does not get fetched and our software gets its
version from the git tags. Since this is very convenient to have the
version information in one place only, we will not change this.
Thanks and Regards,
   Matthias
On 3/15/20 5:02 PM, Alexander Kanavin wrote:
> On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via
> Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org>
<http://Lists.Yoctoproject.Org>
> <matthias.schoepfer=googlemail.com@...
<mailto:googlemail.com@...>
> <mailto:googlemail.com@...
<mailto:googlemail.com@...>>> wrote:
>
>     2) It allows for very convenient bump of versions. We develop a
>     product,
>     so, version bumps are on daily or weekly basis. All that is
needed
>     is to
>     rename the .bb file. No need to edit SRCREV.
>
>
> You can trivially script SRCREV updates ('devtool upgrade'/'devtool
> finish'). The disadvantage of using tags is that you lose
> reproducibility, as tags can be moved or deleted, and so I wouldn't
> encourage this practice.
>
> Alex
--
Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...
<mailto:matthias.schoepfer@...>
--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...


QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, March 19.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of pokybuild@...
Sent: Monday, 16 March, 2020 5:40 PM
To: yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>;
Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>;
richard.purdie@...; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: [yocto] QA notification for completed autobuilder build
(yocto-
3.1_M3.rc1)


A build flagged for QA (yocto-3.1_M3.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1


Build hash information:

bitbake: e67dfa4a4d0d63e4752655f25367582e5a95f1da
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 60773e8496370d821309e00f2c312128a130c22b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 61d80b07bcfa4adf5f1feb2904fec0a8d09c89f6
poky: 6f02caa39985fb89d9ad49e1f788a9a8dd6e12d7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



Re: QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, March 19.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of pokybuild@...
Sent: Monday, 16 March, 2020 5:40 PM
To: yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>;
richard.purdie@...; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1_M3.rc1)


A build flagged for QA (yocto-3.1_M3.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1


Build hash information:

bitbake: e67dfa4a4d0d63e4752655f25367582e5a95f1da
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 60773e8496370d821309e00f2c312128a130c22b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 61d80b07bcfa4adf5f1feb2904fec0a8d09c89f6
poky: 6f02caa39985fb89d9ad49e1f788a9a8dd6e12d7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



[yocto-autobuilder2][PATCH] config: Fix giturl for meta-virtualization Layer

Aaron Chan
 

From: Aaron Chan <aaron.chun.yew.chan@...>

Signed-off-by: Aaron Chan <aaron.chun.yew.chan@...>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 6d629f1..b1e2c05 100644
--- a/config.py
+++ b/config.py
@@ -39,7 +39,7 @@ repos = {
"meta-mingw": ["git://git.yoctoproject.org/meta-mingw", "master"],
"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"],
"meta-openembedded": ["git://git.openembedded.org/meta-openembedded", "master"],
- "meta-virtualization": ["git://git.openembedded.org/meta-openembedded", "master"]
+ "meta-virtualization": ["git://git.yoctoproject.org/meta-virtualization", "master"]
}

trigger_builders_wait_shared = [
--
2.21.0.windows.1


[PATCH] config: Fix giturl for meta-virtualization Layer

Aaron Chan
 

From: Aaron Chan <aaron.chun.yew.chan@...>

Signed-off-by: Aaron Chan <aaron.chun.yew.chan@...>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 6d629f1..b1e2c05 100644
--- a/config.py
+++ b/config.py
@@ -39,7 +39,7 @@ repos = {
"meta-mingw": ["git://git.yoctoproject.org/meta-mingw", "master"],
"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"],
"meta-openembedded": ["git://git.openembedded.org/meta-openembedded", "master"],
- "meta-virtualization": ["git://git.openembedded.org/meta-openembedded", "master"]
+ "meta-virtualization": ["git://git.yoctoproject.org/meta-virtualization", "master"]
}

trigger_builders_wait_shared = [
--
2.21.0.windows.1


QA notification for completed autobuilder build (yocto-3.1_M3.rc1)

pokybuild@...
 

A build flagged for QA (yocto-3.1_M3.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1


Build hash information:

bitbake: e67dfa4a4d0d63e4752655f25367582e5a95f1da
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 60773e8496370d821309e00f2c312128a130c22b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 61d80b07bcfa4adf5f1feb2904fec0a8d09c89f6
poky: 6f02caa39985fb89d9ad49e1f788a9a8dd6e12d7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


systemd: Freezing execution in intel ATOM processor

raxeshkumar.oriya@ncr.com
 

We have a legacy device with following configurations:

 

Chipset Architecture : Intel NM10 express

OS : Yocto warrior

CPU : Atom D2250 Dual Core

Volatile Memory : 2GB DDR3

CPU core : 4

 


I have generated 64-bit core-image-sato and run on my device but *systemd* freezes execution with SIGILL (as shown below). I have set MACHINE to “intel-corei7-64”.

systemd[1]: Set hostname to <panther1>.

traps: systemd[1] trap invalid opcode ip:7f257b9b8bd7 sp:7ffe7bc63090 error:0 in libsystemd-shared-241.so[7f257b8b4000+12f000]

systemd[1]: Caught <ILL>, core dump failed (child 77, code=killed, status=4/ILL).

systemd[1]: Freezing execution.

 


  PLEASE NOTE, THE ISSUE IS NOT OBSERVED WITH 32-BIT IMAGE(where MACHINE is set to “intel-core2-32”).

 

From @Peter Cordes,

… Obviously the assembly instruction that faulted would be more relevant than the source code. If your GCC compiled with anything that -march=native doesn't include, your binaries can include instructions that your CPU doesn't support. https://ark.intel.com/content/www/us/en/ark/products/65470/intel-atom-processor-d2550-1m-cache-1-86-ghz.html says your CPU only supports up to SSSE3, and thus not popcnt or SSE4.1 which GCC certainly can use when optimizing / auto-vectorizing pure C code. (SSE4.2 doesn't tend to get used automatically, unless you count popcnt as part of that.) So that easily accounts for GCC emitting code that will SIGILL on your machine. BTW, if you're cross-compiling, you need -march=atom not native…

 

I tried with “-march=atom” but build fails with “unable to find CPU model 'atom'”. I also tried other ways(like changing DEFAULTTUNE, passing -msse3 parameter etc) but got compilation issues and nothing worked out.

 

My queries:

  • Is intel-corei7-64 machine expected to run on intel Atom based processor?
  • Is there any specific BSP provided by Intel for Atom based processor which can be used to generate 64-bits sato image?
  • Any suggestion on how 64-bit sato image can be run smoothly on Atom processor?

 

 


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

Alexander Kanavin
 

'devtool upgrade' updates SRCREV to match the version tag that you specify:

devtool upgrade -V <tag>

If you omit -V, it will upgrade to the latest tag. It updates PV as well. Why is it unsuitable for you?

Alex


On Mon, 16 Mar 2020 at 09:35, Matthias Schöpfer <matthias.schoepfer@...> wrote:
Hi Alexander,

does it solve the Problem of a SRCREV, that has been fetched (for
example for a _git testbuild) and now gets a tag applied and build with
the _<version> build. The problem is *not* that the yocto PV package is
wrong *nor* that the wrong version of the software gets build! The
problem is, that the tag does not get fetched and our software gets its
version from the git tags. Since this is very convenient to have the
version information in one place only, we will not change this.

Thanks and Regards,

   Matthias

On 3/15/20 5:02 PM, Alexander Kanavin wrote:
> On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via
> Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org>
> <matthias.schoepfer=googlemail.com@...
> <mailto:googlemail.com@...>> wrote:
>
>     2) It allows for very convenient bump of versions. We develop a
>     product,
>     so, version bumps are on daily or weekly basis. All that is needed
>     is to
>     rename the .bb file. No need to edit SRCREV.
>
>
> You can trivially script SRCREV updates ('devtool upgrade'/'devtool
> finish'). The disadvantage of using tags is that you lose
> reproducibility, as tags can be moved or deleted, and so I wouldn't
> encourage this practice.
>
> Alex


--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...


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

Matthias Schoepfer
 

Hi Alexander,

does it solve the Problem of a SRCREV, that has been fetched (for example for a _git testbuild) and now gets a tag applied and build with the _<version> build. The problem is *not* that the yocto PV package is wrong *nor* that the wrong version of the software gets build! The problem is, that the tag does not get fetched and our software gets its version from the git tags. Since this is very convenient to have the version information in one place only, we will not change this.

Thanks and Regards,

Matthias

On 3/15/20 5:02 PM, Alexander Kanavin wrote:
On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org> <matthias.schoepfer=googlemail.com@... <mailto:googlemail.com@...>> wrote:
2) It allows for very convenient bump of versions. We develop a
product,
so, version bumps are on daily or weekly basis. All that is needed
is to
rename the .bb file. No need to edit SRCREV.
You can trivially script SRCREV updates ('devtool upgrade'/'devtool finish'). The disadvantage of using tags is that you lose reproducibility, as tags can be moved or deleted, and so I wouldn't encourage this practice.
Alex
--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...


Auto Login using systeminit #yocto

Amrun Nisha.R
 

Hi,

I want to add a feature "autologin" to the core-image-base. I created a new layer for auto login as "meta-autologin" in the poky and added some sample script to run in the auto login. When I build the image and run in the imx8 board, it is not able to run in the systeminit function. It is not able to create rc0, rc1, rc2 folders. But, the autologin script is placed in the /etc/init.d/autologin. Is there any other way to add this autologin to run in the systeminit function in etc. 


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

Alexander Kanavin
 

On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via Lists.Yoctoproject.Org <matthias.schoepfer=googlemail.com@...> wrote:
2) It allows for very convenient bump of versions. We develop a product,
so, version bumps are on daily or weekly basis. All that is needed is to
rename the .bb file. No need to edit SRCREV.

You can trivially script SRCREV updates ('devtool upgrade'/'devtool finish'). The disadvantage of using tags is that you lose reproducibility, as tags can be moved or deleted, and so I wouldn't encourage this practice.

Alex


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

Matthias Schoepfer
 

Hi Denys,

On 3/13/20 5:29 PM, Denys Dmytriyenko wrote:
Why not use SRCREV?
Also, bitbake has its own mailing list.
1) Would SRCREV not be affected by this as well? When the same hash is read, then no update of the repository (esp. the tags) is done. Or can you be sure this is not the case?

2) It allows for very convenient bump of versions. We develop a product, so, version bumps are on daily or weekly basis. All that is needed is to rename the .bb file. No need to edit SRCREV.

3) I am sorry if I used the wrong mailing list for this. I will repost on the other list as well.

Regards,

  Matthias


Invitation: Yocto Project Technical Team Meeting @ Monthly from 8am to 9am on the third Tuesday (PDT) (yocto@yoctoproject.org)

Rudolf J Streif
 

You have been invited to the following event.

Yocto Project Technical Team Meeting

When
Monthly from 8am to 9am on the third Tuesday Pacific Time - Los Angeles
Where
Zoom Meeting: https://zoom.us/j/990892712 (map)
Joining info
Join Hangouts Meet
Join by phone
+1 414-439-0065 (PIN: 843669626)
Calendar
yocto@...
Who
Rudolf Streif - organizer
theyoctoproject@...
Rudolf J Streif
stephen.k.jolley@...
yocto@...
sjolley.yp.pm@...
We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

Bridge is with Zoom at: https://zoom.us/j/990892712

Technical Meeting Minutes at: https://drive.google.com/open?id=1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg

YP 2.8 Planning Ideas at: https://drive.google.com/open?id=1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU

Going (yocto@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account yocto@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Re: How to create a btrfs snapshot in the rootfs image (during build)?

Gmane Admin
 

Self answering below.

Op 22-02-2020 om 16:06 schreef Ferry Toth:
Hi all,

I am able to generate a rootfs image of type btrfs.
Btrfs supports subvolumes, for instance with name @.

Using subvolumes instead of partitions allow more efficient use of
the emmc compared to separate partitions. And it allows multiple versions of the rootfs in the same pool.

Manually I can create a subvolume (on the host) by loop mounting the
btrfs image and taking the snapshot. Something like this:
mkdir tmp
sudo mount edison-image.btrfs tmp
sudo btrfs subvolume snapshot tmp tmp/@

and then remove all dir's in root except @.

mount and btrfs operations need root permissions AFAIK. Is there any
way to add these to the recipe?

Up to now I found I can use udisksctl to mount the image as ordinary user.

However, to create a snapshot it appears I need to own the root directory and for that would need an option like mke2fs -E root_owner.

As that doesn't exist, the only workaround I find is to create an ext4 partition with -E root_owner and then convert to btrfs.

Is there really no better way?

There is 2nd thing I want to achieve:
Btrfs can send / receive these snapshots allowing over-the-air-updates.

For this I need to:
sudo btrfs subvolume snapshot -r tmp/@ tmp/@ota
sudo btrfs send tmp/@ota > edison-image.snapshot

And then later manually (with the device having mounted btrfs on /mnt):

cat edison-image.snapshot | ssh root@edison "btrfs receive /mnt"
ssh root@edison "btrfs property set -ts /mnt/@ota ro false"

How do I automated the first steps in yocto?

Ferry


Re: [OE-core] [yocto] menuconf u-boot

Andrey Zhizhikin <andrey.z@...>
 

On Fri, Mar 13, 2020 at 7:15 PM Denys Dmytriyenko <denis@...> wrote:

On Fri, Mar 13, 2020 at 07:07:34PM +0100, Andrey Zhizhikin wrote:
JH,

Please refer to my replies to Denys, cross-posting to unrelated lists
is generally not a good idea.

On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko <denis@...> wrote:

What's u-boot-imx?
This is U-Boot fork for NXP devices (former Freescale),
This was a rhetorical question - no answer was required.
That was mainly addressed to JH. :)



which is not maintained by OE-Core.
Exactly my point.


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.
The correct mailing list would be meta-freescale@... and
JH already had some questions posted there.


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:
It is not clear which yocto branch/machine you're trying to build
here. If you provide more details - then there is a bigger chance that
people would step in to assist you.


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

How can I run menuconfig u-boot?
I've tried it now on the [master] branch of yocto for imx8mmevk
machine - it is building OK and I have the menuconfig from u-boot-imx.
Hence, please refer to my point above regarding more pre-information
on the issue.


Thank you.

Kind regards,

- jh
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@...
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Regards,
Andrey.


--
Regards,
Andrey.


Re: [OE-core] [yocto] menuconf u-boot

Denys Dmytriyenko
 

On Fri, Mar 13, 2020 at 07:07:34PM +0100, Andrey Zhizhikin wrote:
JH,

Please refer to my replies to Denys, cross-posting to unrelated lists
is generally not a good idea.

On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko <denis@...> wrote:

What's u-boot-imx?
This is U-Boot fork for NXP devices (former Freescale),
This was a rhetorical question - no answer was required.


which is not maintained by OE-Core.
Exactly my point.


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.
The correct mailing list would be meta-freescale@... and
JH already had some questions posted there.


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:
It is not clear which yocto branch/machine you're trying to build
here. If you provide more details - then there is a bigger chance that
people would step in to assist you.


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

How can I run menuconfig u-boot?
I've tried it now on the [master] branch of yocto for imx8mmevk
machine - it is building OK and I have the menuconfig from u-boot-imx.
Hence, please refer to my point above regarding more pre-information
on the issue.


Thank you.

Kind regards,

- jh
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@...
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Regards,
Andrey.


Re: [OE-core] [yocto] menuconf u-boot

Andrey Zhizhikin <andrey.z@...>
 

JH,

Please refer to my replies to Denys, cross-posting to unrelated lists
is generally not a good idea.

On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko <denis@...> wrote:

What's u-boot-imx?
This is U-Boot fork for NXP devices (former Freescale), which is not
maintained by OE-Core.


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.
The correct mailing list would be meta-freescale@... and
JH already had some questions posted there.


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:
It is not clear which yocto branch/machine you're trying to build
here. If you provide more details - then there is a bigger chance that
people would step in to assist you.


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

How can I run menuconfig u-boot?
I've tried it now on the [master] branch of yocto for imx8mmevk
machine - it is building OK and I have the menuconfig from u-boot-imx.
Hence, please refer to my point above regarding more pre-information
on the issue.


Thank you.

Kind regards,

- jh
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@...
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Regards,
Andrey.


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

9021 - 9040 of 57790