Alex,

Either do it voluntarily, either do not.

Do not complain, or brag about it.

We all understand Open Source rules, or we do not, do we???

Thank you,
Zoran Stojsavljevic
_______





On Sat, Oct 24, 2020 at 12:54 PM Zoran via lists.yoctoproject.org
<zoran.stojsavljevic=gmail.com@lists.yoctoproject.org> wrote:

I have absolutely no need for python2, I made this abundantly
clear when I created the meta-python2 layer.

WTH? Let me tell you how I really feel.

I have absolutely no need for python2, as well.

You are not paying me to do this. You cannot pay me enough
to do this. Period. Support yourself.

What is the amount of cash for you, you'll consider it enough to
do that???

Better... What is the real message behind this/yours "announcement"?

Thank you,
Zoran
_______

On Wed, Oct 21, 2020 at 2:48 AM Tim Orling <ticotimo@gmail.com> wrote:

I have absolutely no need for python2, I made this abundantly clear when I created the meta-python2 layer.

If you depend upon continuing support of python2 via the meta-python2 layer, this is your call to arms.

I was originally intending to abdicate any support after the 3.1 "dunfell" release, but managed to somehow continue supporting it into the crest of the 3.2 "gatesgarth" release.

I will stop all support and actively refuse lo respond to any emails and this layer will be dead and I have zero care in the world that it stops being useful. I do not use it. I do not depend upon it. You are not paying me to do this. You cannot pay me enough to do this. Period. Support yourself.

If this is not clear enough, I am happy to have a virtual video call with you that you will not like.

--moto-timo

I have absolutely no need for python2, I made this abundantly
clear when I created the meta-python2 layer.

WTH? Let me tell you how I really feel.

I have absolutely no need for python2, as well.

You are not paying me to do this. You cannot pay me enough
to do this. Period. Support yourself.

What is the amount of cash for you, you'll consider it enough to
do that???

Better... What is the real message behind this/yours "announcement"?

Thank you,
Zoran
_______

On Wed, Oct 21, 2020 at 2:48 AM Tim Orling <ticotimo@gmail.com> wrote:

I have absolutely no need for python2, I made this abundantly clear when I created the meta-python2 layer.

If you depend upon continuing support of python2 via the meta-python2 layer, this is your call to arms.

I was originally intending to abdicate any support after the 3.1 "dunfell" release, but managed to somehow continue supporting it into the crest of the 3.2 "gatesgarth" release.

I will stop all support and actively refuse lo respond to any emails and this layer will be dead and I have zero care in the world that it stops being useful. I do not use it. I do not depend upon it. You are not paying me to do this. You cannot pay me enough to do this. Period. Support yourself.

If this is not clear enough, I am happy to have a virtual video call with you that you will not like.

--moto-timo

Hi Maciej

Hi,

I have set of patches that I carry to support qemuppc64

https://github.com/YoeDistro/openembedded-core/commit/885104134403da36b9ecb47ced6423e183262392

https://github.com/YoeDistro/openembedded-core/commit/aa9797636a6039ede752a57b05f839ce641e3cfc

you can plant them on top of master oe-core or poky and
try out. I haven't built it in months so maybe a bit jaded.

Thanks. I've tried to continue my approach or to take yours config and adapt it.
I can get the machine to boot with certain parameters, but so far I was not able
to get the login prompt to spawn on the serial console.

Publishing some status update here, maybe it will be useful to someone.

Depending on the QEMU params, it either freezes after mounting rootfs (when the
login prompt should appear):

[    3.076659] udevd (79) used greatest stack depth: 10024 bytes left
[    3.092691] udevd[80]: starting eudev-3.2.9
[    5.186145] EXT4-fs (vda): re-mounted. Opts: (null)
[    5.186906] ext4 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
[    7.370678] urandom_read: 4 callbacks suppressed
[    7.370816] random: dd: uninitialized urandom read (512 bytes read)

or could even crash:

[    1.374644] Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized.
[    1.376651] hvc0: raw protocol on /ibm,opal/consoles/serial@0 (boot console)
[    1.377099] hvc0: No interrupts property, using OPAL event
[    1.380151] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.387642] printk: console [ttyS0] disabled
[    1.389410] BUG: Unable to handle kernel data access on read at 0xc00a0000000003e9
[    1.389927] Faulting instruction address: 0xc0000000008d79f4
[    1.390532] Oops: Kernel access of bad area, sig: 11 [#1]
[    1.390812] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
[    1.391331] Modules linked in:
[    1.391790] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.8.13-yocto-standard #1
[    1.392237] NIP:  c0000000008d79f4 LR: c0000000008d9cf8 CTR: c0000000008d7960
[    1.392696] REGS: c0000000723c2f70 TRAP: 0300   Not tainted  (5.8.13-yocto-standard)
[    1.393104] MSR:  9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE>  CR: 24000220  XER: 20040000
[    1.393714] CFAR: c0000000008d799c DAR: c00a0000000003e9 DSISR: 40000000 IRQMASK: 1
[    1.393714] GPR00: c0000000008d9cf8 c0000000723c3200 c000000001921f00 c00a0000000003e9
[    1.393714] GPR04: c00a000000000000 00000000000003ef c0000000017ac378 0000000000000000
[    1.393714] GPR08: 0000000000000000 c0000000019cab10 0000000031000040 00000000fffffffe
[    1.393714] GPR12: 0000000000000000 c00000007ffff280 c000000000012190 0000000000000000
[    1.393714] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    1.393714] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    1.393714] GPR24: 0000000000000000 c00000000125ad38 c000000001857140 0000000000000000
[    1.393714] GPR28: ffffffffffffffea c000000072d87908 0000000000000001 c000000001adab40
[    1.397765] NIP [c0000000008d79f4] io_serial_in+0x94/0x100
[    1.398104] LR [c0000000008d9cf8] serial8250_config_port+0x3b8/0x1240
[    1.398619] Call Trace:
[    1.398977] [c0000000723c3200] [0000000000000005] 0x5 (unreliable)
[    1.399428] [c0000000723c3230] [c0000000008d9970] serial8250_config_port+0x30/0x1240
[    1.399874] [c0000000723c32d0] [c0000000008d3570] uart_add_one_port+0x250/0x690
[    1.400311] [c0000000723c33e0] [c0000000008d5138] serial8250_register_8250_port+0x368/0x5a0
[    1.400767] [c0000000723c3470] [c0000000008d56fc] serial8250_probe+0x14c/0x1e0
[    1.401194] [c0000000723c37e0] [c000000000995d50] platform_drv_probe+0x60/0xf0
[    1.401603] [c0000000723c3860] [c00000000099208c] really_probe+0x12c/0x580
[    1.401976] [c0000000723c3910] [c000000000992808] driver_probe_device+0x88/0x120
[    1.402373] [c0000000723c3940] [c000000000992d2c] device_driver_attach+0x11c/0x130
[    1.402805] [c0000000723c3980] [c000000000992dec] __driver_attach+0xac/0x190
[    1.403185] [c0000000723c39d0] [c00000000098e868] bus_for_each_dev+0xa8/0x130
[    1.403564] [c0000000723c3a30] [c0000000009914b4] driver_attach+0x34/0x50
[    1.403935] [c0000000723c3a50] [c000000000990bd0] bus_add_driver+0x170/0x2b0
[    1.404329] [c0000000723c3ae0] [c000000000993fd4] driver_register+0xb4/0x1c0
[    1.404690] [c0000000723c3b50] [c000000000995c5c] __platform_driver_register+0x5c/0x70
[    1.405092] [c0000000723c3b70] [c0000000012cbed4] serial8250_init+0x16c/0x1d8
[    1.405454] [c0000000723c3c00] [c000000000011b30] do_one_initcall+0x60/0x2b0
[    1.405828] [c0000000723c3cd0] [c000000001284408] kernel_init_freeable+0x2e0/0x3a4
[    1.406199] [c0000000723c3db0] [c0000000000121b4] kernel_init+0x2c/0x158
[    1.406616] [c0000000723c3e20] [c00000000000d1a8] ret_from_kernel_thread+0x5c/0x74
[    1.407061] Instruction dump:
[    1.407492] 38210030 7fe3fb78 ebe1fff8 4e800020 60000000 60000000 60420000 3d22000b
[    1.407930] 39298c10 e8890000 7c632214 7c0004ac <8be30000> 0c1f0000 4c00012c 57ff063e
[    1.408889] ---[ end trace 57df7bc12c90327a ]---
[    1.409238]
[    2.410095] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[   12.174535161,3] Could not set special wakeup on 0:0: timeout waiting for SPECIAL_WKUP_DONE.
[    2.517929] Rebooting in 10 seconds..

When trying to modify your config, I needed to:
- remove the "-show-cursor" - deprecated option
- either remove the virtio serial console entries or change the
  virtio-serial-device to virtio-serial-pci due to the error:

qemu-system-ppc64: -device virtio-serial-device: No 'virtio-bus' bus found for device 'virtio-serial-device'

I have found some recent docs on running the qemuppc64 here:
https://github.com/legoater/qemu/wiki/PowerNV#running-qemu

Their example works fine. But when using artifacts from Yocto build, I fail to
spawn the login prompt. I have also noticed that they are using different image type
and tried building it as well, with the same results.

I have also updated my repo: https://github.com/3mdeb/meta-ppc64

On 10/22/20 10:11 AM, Maciej Pijanowski wrote:

Hello,

I need to build a development environment for ppc64 (POWER9).
I wanted to use Yocto to build ppc64 QEMU images. I'm starting with
big endian as I need to test out this one first.

I was surprised to see that there is no qemuppc64 target, so I have
just started my own here [1]. I want to use the POWER9 tune and POWER9
CPU in QEMU. It is already supported in recent QEMU as we have already
been running some firmware images.

I've been trying to find something about qemuppc64 and Yocto and found
just some old meta layer [2] and a thread on adding qemuppc64 support
to the linux-yocto [3]. The last part (yocto-kernel-cache) was merged and
is still there. There are some more unmerged patches in this regard
though [4].

Do you know what is the status there? I would be happy to help moving it
forward.

[1]
https://github.com/3mdeb/meta-ppc64/blob/master/conf/machine/qemuppc64.conf
[2] https://github.com/akuster/meta-qemu-bsps
[3]https://www.yoctoproject.org/pipermail/linux-yocto/2014-September/003184.html
[4]
https://patchwork.openembedded.org/project/oe-core/patches/?submitter=11275&state=&q=ppc64&archive=both&delegate=

-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com

This reverts commit d123606c4bef85c2436b40f51e47b602b7600c0b.

This change contains races as it will start poking into do_package task
directories from do_populate_sysroot. If we want to do this for native
recipes, we need to add guards around the package code and only make
this happen for native in populate_sysroot, not target in
populate_sysroot too. Backtrace from an example problem below:

ERROR: openssl-1.1.1g-r0 do_populate_sysroot: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:buildhistory_emit_pkghistory(d)
0003:
File: '/home/ross/Yocto/poky/meta/classes/buildhistory.bbclass', lineno: 319, function: buildhistory_emit_pkghistory
0315:
0316: write_pkghistory(pkginfo, d)
0317:
0318: # Create files-in-<package-name>.txt files containing a list of files of each recipe's package
*** 0319: bb.build.exec_func("buildhistory_list_pkg_files", d)
0320:}
0321:
0322:python buildhistory_emit_outputsigs() {
0323: if not "task" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
File: '/home/ross/Yocto/poky/bitbake/lib/bb/build.py', lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File: '/home/ross/Yocto/poky/bitbake/lib/bb/build.py', lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503: bb.process.run(cmd, shell=False, stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING: Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
File: '/home/ross/Yocto/poky/bitbake/lib/bb/process.py', lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0182:
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of '/yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/temp/run.buildhistory_list_pkg_files.4158804' failed with exit code 2:
/yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/temp/run.buildhistory_list_pkg_files.4158804: 183: cd: can't cd to /yocto/ross/build/tmp/work/neoversen1-poky-linux/openssl/1.1.1g-r0/packages-split/openssl-engines

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/classes/buildhistory.bbclass | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass b/meta/classes/buildhistory.bbclass
index 6d04d8cfb9b..7d5e3eb8fd6 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -90,7 +90,8 @@ buildhistory_emit_sysroot() {
python buildhistory_emit_pkghistory() {
if d.getVar('BB_CURRENTTASK') in ['populate_sysroot', 'populate_sysroot_setscene']:
bb.build.exec_func("buildhistory_emit_sysroot", d)
- elif not d.getVar('BB_CURRENTTASK') in ['packagedata', 'packagedata_setscene']:
+
+ if not d.getVar('BB_CURRENTTASK') in ['packagedata', 'packagedata_setscene']:
return 0

if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
@@ -228,9 +229,8 @@ python buildhistory_emit_pkghistory() {
break
except IOError as e:
if e.errno == errno.ENOENT:
- if not bb.data.inherits_class('native', d):
- # Probably a -cross recipe, just ignore
- return 0
+ # Probably a -cross recipe, just ignore
+ return 0
else:
raise

--
2.25.1

On 2020-10-22 10:46 a.m., Alex G. wrote:

On 10/15/20 9:46 AM, Alex G. via lists.yoctoproject.org wrote:

Hi,

I'm trying to write a recipe for a secure boot flow. It would look something like this:

     images {
         optee@1 { "path/to/tee.bin" }
         linux@2 { "path/to/zImage" }
         fdt@board { ... }
     }
     configurations {
         secure {
             kernel = "optee@1";
             loadables = "linux@2";
             fdt = "fdt@board";
         }
     }

Hi,
A quick follow-up. Was wondering if anyone has had to bundle OPTEE and linux before.
Alex

Hi Alex,

Not personally but a quick look in the layer index reveals meta-optee:


https://layers.openembedded.org/layerindex/branch/master/layer/meta-optee/

I hope that helps.
If you know of that layer, what's missing?

../Randy

I've tried to "inherit kernel-fitimage", but soon learned of a couple of limitations:
     * images: No way to add an optee binary
     * configurations: No way to add a "loadables"

Secondly, since this approach would use files from several packages, I think it would be better to have the recipe separate from the kernel build. Bot how would I use files from another recipe? All I could figure out was to first put them in ${DEPLOY_DIR_IMAGE}.

What would be the "correct" way to write such a recipe?

Alex

--
# Randy MacLeod
# Wind River Linux

On 10/22/20 2:36 PM, Martin Jansa wrote:

There were only a few changes needed between dunfell and gatesgarth to keep it building and I feel guilty for sending half of them - and pinging you on FB :).
I don't have interest in python2, but it's still used by quite a few components included in other layers are care about (e.g. qtwebengine in meta-qt5, chromium in meta-browser - https://bugs.chromium.org/p/chromium/issues/detail?id=942720 <https://bugs.chromium.org/p/chromium/issues/detail?id=942720> is still quite far from finished) and at LGE we maintain meta-ros https://github.com/ros/meta-ros <https://github.com/ros/meta-ros> which contains support for ROS 1 Melodic which is usually used with python2 and support ends May 2023 (together with Ubuntu Bionic it's usually used with: http://wiki.ros.org/Distributions <http://wiki.ros.org/Distributions> - just today I've separated meta-ros-python2 layer with python2 recipes which disappeared from oe-core in warrior and were never re-introduced in meta-python2 (like nose and numpy).
If you're looking for someone just keeping it buildable, then you can sign me up. If it gets more annoying to maintain in future we can also split it for pythonnative.bbclass and python recipe itself - to keep just the bare minimum of recipes which are actively being used without all the other junk.

minimum is better.

Cheers,
On Wed, Oct 21, 2020 at 2:48 AM Tim Orling <ticotimo@gmail.com <mailto:ticotimo@gmail.com>> wrote:
I have absolutely no need for python2, I made this abundantly clear
when I created the meta-python2 layer.
If you depend upon continuing support of python2 via the
meta-python2 layer, this is your call to arms.
I was originally intending to abdicate any support after the 3.1
"dunfell" release, but managed to somehow continue supporting it
into the crest of the 3.2 "gatesgarth" release.
I will stop all support and actively refuse lo respond to any emails
and this layer will be dead and I have zero care in the world that
it stops being useful. I do not use it. I do not depend upon it. You
are not paying me to do this. You cannot pay me enough to do this.
Period. Support yourself.
If this is not clear enough, I am happy to have a virtual video call
with you that you will not like.
--moto-timo

Hi Maciej

I have set of patches that I carry to support qemuppc64

https://github.com/YoeDistro/openembedded-core/commit/885104134403da36b9ecb47ced6423e183262392

https://github.com/YoeDistro/openembedded-core/commit/aa9797636a6039ede752a57b05f839ce641e3cfc

you can plant them on top of master oe-core or poky and
try out. I haven't built it in months so maybe a bit jaded.

Hello,

I need to build a development environment for ppc64 (POWER9).
I wanted to use Yocto to build ppc64 QEMU images. I'm starting with
big endian as I need to test out this one first.

I was surprised to see that there is no qemuppc64 target, so I have
just started my own here [1]. I want to use the POWER9 tune and POWER9
CPU in QEMU. It is already supported in recent QEMU as we have already
been running some firmware images.

I've been trying to find something about qemuppc64 and Yocto and found
just some old meta layer [2] and a thread on adding qemuppc64 support
to the linux-yocto [3]. The last part (yocto-kernel-cache) was merged and
is still there. There are some more unmerged patches in this regard
though [4].

Do you know what is the status there? I would be happy to help moving it
forward.

[1]
https://github.com/3mdeb/meta-ppc64/blob/master/conf/machine/qemuppc64.conf
[2] https://github.com/akuster/meta-qemu-bsps
[3]https://www.yoctoproject.org/pipermail/linux-yocto/2014-September/003184.html
[4]
https://patchwork.openembedded.org/project/oe-core/patches/?submitter=11275&;state=&q=ppc64&archive=both&delegate=

--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com

Hello everyone,

I am a newbie in Yocto.

I am using a custom board based on the sama5d3_xplained board,

Goal: Currently the Port Pins: PA30 and PA31 are I2C lines (I2C0 TWD0 and TWCK0), I would like to use them as UART Lines (UART1 RX and TX)

What I have done till now: Modified the at91-sama5d3_xplained.dts file

        Removed:     i2c0: i2c@f0014000 {
                                    pinctrl-0 = <&pinctrl_i2c0_pu>;
                                    status = "okay";
                            };

        Added:         uart1: serial@f8028000 {
                                status = "okay";
                            };


After the build process, I assumed that the output .dtb file will be modified. But it remained the same.

Is there something that I am missing out?

Pratham

On 10/15/20 9:46 AM, Alex G. via lists.yoctoproject.org wrote:

Hi,
I'm trying to write a recipe for a secure boot flow. It would look something like this:
    images {
        optee@1 { "path/to/tee.bin" }
        linux@2 { "path/to/zImage" }
        fdt@board { ... }
    }
    configurations {
        secure {
            kernel = "optee@1";
            loadables = "linux@2";
            fdt = "fdt@board";
        }
    }

Hi,

A quick follow-up. Was wondering if anyone has had to bundle OPTEE and linux before.

Alex

I've tried to "inherit kernel-fitimage", but soon learned of a couple of limitations:
    * images: No way to add an optee binary
    * configurations: No way to add a "loadables"
Secondly, since this approach would use files from several packages, I think it would be better to have the recipe separate from the kernel build. Bot how would I use files from another recipe? All I could figure out was to first put them in ${DEPLOY_DIR_IMAGE}.
What would be the "correct" way to write such a recipe?
Alex

Sent via BlackBerry Hub+ Inbox for Android


  Original Message  


From: marek.belisko@gmail.com
Sent: October 22, 2020 12:53
To: yocto@yoctoproject.org
Subject: [yocto] readonly rootfs -> make files writable


Hi,

I'm using the read-only rootfs feature on my system, but for some
packages which I'm integrating it makes trouble. I used volatile-binds
recipe to mount changes in overlayfs (on other partition) but after
reboot files are lost (when mount volatile directory). Another
approach which came to my mind is to symlink all files/dirs to other
partitions but to me it looks like overkill. Exists there some other
mechanism I can use to keep file preserved and still have readonly
rootfs functionality?

Thanks and BR,

Sounds like os-tree could be a good option here with immutable rootfs


marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Hi,

I'm using the read-only rootfs feature on my system, but for some
packages which I'm integrating it makes trouble. I used volatile-binds
recipe to mount changes in overlayfs (on other partition) but after
reboot files are lost (when mount volatile directory). Another
approach which came to my mind is to symlink all files/dirs to other
partitions but to me it looks like overkill. Exists there some other
mechanism I can use to keep file preserved and still have readonly
rootfs functionality?

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

On Wed, Oct 21, 2020 at 12:13 AM Naveen Saini
<naveen.kumar.saini@intel.com> wrote:

Qemu system does not passthroth RNG on x86 host.

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/qemu-cortex-m3.conf | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/machine/qemu-cortex-m3.conf b/conf/machine/qemu-cortex-m3.conf
index dd1ce56..3a50796 100644
--- a/conf/machine/qemu-cortex-m3.conf
+++ b/conf/machine/qemu-cortex-m3.conf
@@ -12,5 +12,6 @@ QB_SYSTEM_NAME = "qemu-system-arm"
QB_MACHINE = "-machine lm3s6965evb"
QB_OPT_APPEND = "-nographic -vga none"
QB_CPU = "-cpu cortex-m3"
+QB_RNG = ""

this looks fine.

ARCH_qemu-cortex-m3 = "arm"
--
2.17.1

Hi team ,

    I am assuming in local.conf we used  DISTRO ?=  "poky"  and DISTRO = "poky-sota-systemd"   both   thats why we are getting these error or what ?

mmm nope...

Build Configuration:
BB_VERSION           = "1.48.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "debian-10"
TARGET_SYS           = "x86_64-overc-linux"
MACHINE              = "intel-corei7-64"
DISTRO               = "overc"
DISTRO_VERSION       = "1.0"
TUNE_FEATURES        = "m64 corei7"
TARGET_FPU           = ""
meta                
meta-poky           
meta-yocto-bsp       = "master:4e4a302e37ac06543e9983773cdb4caf7728330d"
meta-oe             
meta-python         
meta-networking     
meta-filesystems    
meta-gnome          
meta-multimedia     
meta-xfce           
meta-perl            = "master:de8198b93f8e524ab2f64fd138185824a79b18e6"
meta-overc          
meta-cube            = "master:af81bc7ec63e96aa7816b523b75ad9f29f9dfcf0"
meta-selinux         = "master:6e1100d29aec118df2025c46c77f4c8aa8da4e76"
meta-security        = "master:e8c9e69c80ea2c525250e07db1024d8e34f1f0f8"
meta-virtualization  = "master:7a8167fa82621dd606260450b1e648e50a1d79ab"
meta-cloud-services  = "master:4f6cd1d6664ca1a51bdc742291fe4bf83ecf2a92"
meta-intel           = "master:0e4b3cb01735bdc5ebf50c547927f1f59b0248d2"

On Wed, Oct 21, 2020 at 10:30 AM Yocto <yocto@...> wrote:

On 10/20/20 8:06 PM, NIKHIL PATIL wrote:

I changed in local.conf (ostree related stuffs ), and put it for compilation , that time i got these error 

On Tue, Oct 20, 2020 at 6:49 AM Randy MacLeod <randy.macleod@...> wrote:

On 2020-10-18 6:41 a.m., NIKHIL PATIL wrote:
> Hi team ,
>        I am getting continuously dnf error, How we can resolve these .

Hi Nikhil,

What exact steps did you take before getting this error and
what build host are you using?

Are you able to build core-image-minimal using oe-core/master
and the default local.conf for qemux86-64?

../Randy

I can confirm that Ive also seen this trying to build in the Yocto build appliance I downloaded yesterday....

>
> core-image-sato-1.0-r0 do_rootfs: Could not invoke dnf. Command
> '/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> -y -c
> /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/dnf/dnf.conf
> --setopt=reposdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/yum.repos.d
> --repofrompath=oe-repo,/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
> --installroot=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs
> --setopt=logdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/temp
> -x packagegroup-core-apl-extra --nogpgcheck install autoconf-archive dnf
> gstreamer1.0-vaapi iqvlinux jhi kernel-modules libtcti-device0
> libtcti-device-dev libtcti-device-staticdev libtcti-socket0
> libtcti-socket-dev libtcti-socket-staticdev libsapi0 libsapi-dev
> libsapi-staticdev libva mesa-glxinfo libmraa1 nodejs
> packagegroup-base-extended packagegroup-core-audio-essential
> packagegroup-core-boot packagegroup-core-buildessential-extended
> packagegroup-core-graphics-essential packagegroup-core-ssh-dropbear
> packagegroup-core-tools-testapps packagegroup-core-x11-base
> packagegroup-core-x11-sato psplash rpm run-postinsts swig tpm2-abrmd
> usb-modeswitch usb-modeswitch-data va-intel wayland weston
> weston-examples xinit-env xserver-xorg locale-base-en-us
> locale-base-en-gb' returned 1:
> Added oe-repo repo from
> /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux