Re: [yocto] How to share a directory between an x86_64 host and a Yocto Dunfell guest? #bitbake #imx8 #poky #qemu #ubuntu #yocto

https://wiki.qemu.org/Documentation/9psetup might help. On Thu, Jan 4, 2024 at 3:50 PM Myles Dear wrote: > > Hello, > > I successfully built my Yocto Poky 3.1.30 binary on my x86_64 build host > (running Ubuntu 20.04.6 LTS) and launched via QEMU. So far so good. > > I now wish to share a host

[yocto] How to share a directory between an x86_64 host and a Yocto Dunfell guest? #bitbake #imx8 #poky #qemu #ubuntu #yocto

Hello, I successfully built my Yocto Poky 3.1.30 binary on my x86_64 build host (running Ubuntu 20.04.6 LTS) and launched via QEMU.  So far so good. I now wish to share a host directory with my guest OS, but hit a limitation that neither the 9pnet nor the 9pnet_virtio drivers required for

Re: [yocto] Update the yocto dunfell to latest version

On Sun, Dec 17, 2023 at 11:37 PM MOHAMMED HASSAN wrote: > > Hi guys, > Can you suggest some resources for me to update to the latest yocto dunfell > version. Currently I am using dunfell 3.1.11 and want to update to 3.1.29. > What could be the consequences? This will be relativ

[yocto] Update the yocto dunfell to latest version

Hi guys, Can you suggest some resources for me to update to the latest yocto dunfell version. Currently I am using dunfell 3.1.11 and want to update to 3.1.29. What could be the consequences? Also If I manually update the nodejs folder to the latest one will it fetch the latest nodejs files

Re: [yocto] [dunfell][PATCH] pypi.bbclass: Set CVE_PRODUCT to PYPI_PACKAGE

This patch should go to openembedded-c...@lists.openembedded.org . Thanks, Ross > On 15 May 2023, at 11:55, Sanjaykumar kantibhai Chitroda -X (schitrod - > E-INFO CHIPS INC at Cisco) via lists.yoctoproject.org > wrote: > > From: Alex Kiernan

[yocto] [dunfell][PATCH] pypi.bbclass: Set CVE_PRODUCT to PYPI_PACKAGE

From: Alex Kiernan The CVE product name for PyPI packages is (usually) the same as the PyPI package name (and not our recipe name), so use that as the default. Signed-off-by: Alex Kiernan Signed-off-by: Alex Kiernan Signed-off-by: Richard Purdie (cherry picked from commit

Re: [yocto] #dunfell

A ticket has been open for backporting the fix: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14971 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58644): https://lists.yoctoproject.org/g/yocto/message/58644 Mute This Topic:

Re: [yocto] #dunfell

On Thu, Nov 3, 2022 at 11:38 PM, Zoran wrote: > > >>> - for imageType in ${KERNEL_IMAGETYPES} ; do > >>> + for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do > > Interesting... What is the difference between variables > ${KERNEL_IMAGETYPES} and ${KERNEL_IMAGETYPE_FOR_MAKE} ? > In my setup I

Re: [yocto] #dunfell

>>> - for imageType in ${KERNEL_IMAGETYPES} ; do >>> + for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do Interesting... What is the difference between variables ${KERNEL_IMAGETYPES} and ${KERNEL_IMAGETYPE_FOR_MAKE} ? Zee ___ On Thu, Nov 3, 2022 at 5:24 PM Frederic Martinsons wrote: > >

[yocto] #dunfell

Hello, I'm currently migrating our system from warrior to dunfell and I have an issue on fitImage support for aarch64 architecture. We use KERNEL_IMAGETYPE = "fitImage" and INITRAMFS_IMAGE_BUNDLE = "1" in our configuration and the kernel do_deploy steps failed on not finding the initramfs file:

Re: [yocto] #yocto #dunfell

Thanks... will give it a try. From: Ross Burton Sent: Tuesday, September 20, 2022 11:38 AM To: Monsees, Steven C (US) ; yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #dunfell External Email Alert This email has been sent from an account outside of the BAE Systems network. Please

Re: [yocto] #yocto #dunfell

lists.yoctoproject.org Date: Tuesday, 20 September 2022 at 16:05 To: Monsees, Steven C (US) , yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #dunfell Any hints or ideas on what I might be doing wrong would be appreciated… From: yocto@lists.yoctoproject.org On Behalf Of Monsees

Re: [yocto] #yocto #dunfell

Any hints or ideas on what I might be doing wrong would be appreciated… From: yocto@lists.yoctoproject.org On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org Sent: Monday, September 19, 2022 2:22 PM To: yocto@lists.yoctoproject.org Subject: [yocto] #yocto #dunfell External Email

[yocto] #yocto #dunfell

I am seeing an error when I attempt to apply a patch, and could use some clarification or way to resolve... Am doing something wrong in patch creation ? What is meant by : "Patch console.patch does not apply (enforce with -f)" ? How can I best resolve this issue ? I edited a file in the

[yocto] Help required for the Bluetooth USB dongle with yocto Dunfell #dunfell

Hi.. There Hope all are doing well I'm playing with the TP-Link Bluetooth dongle For the instance, i have enabled all necessary drivers from the menuconfig Not only that, but i have also manually added the firmware as per the few suggestions in rootfs of the yocto images Those firmware are

Re: [yocto] [meta-yocto][dunfell][PATCH] linux-yocto/5.4: update genericx86* machines to v5.4.205

Hi Steve I think this was sent to the wrong list. Can you include this in your queue please? Thanks, Anuj On Tue, 2022-08-16 at 20:20 +0530, Rajesh Dangi wrote: > Signed-off-by: Rajesh Dangi > --- >  .../recipes-kernel/linux/linux-yocto_5.4.bbappend | 8 -- > -- >  1 file changed,

Re: [yocto] #yocto #dunfell #qemux86-64

Thank you, and I am looking at kirkstone... -Original Message- From: Khem Raj Sent: Wednesday, August 31, 2022 12:38 PM To: Monsees, Steven C (US) ; Alexander Kanavin Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #dunfell #qemux86-64 On 8/31/22 4:36 AM, Monsees, Steven

Re: [yocto] #yocto #dunfell #qemux86-64

: [yocto] #yocto #dunfell #qemux86-64 External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information

Re: [yocto] #yocto #dunfell #qemux86-64

o@lists.yoctoproject.org > Subject: Re: [yocto] #yocto #dunfell #qemux86-64 > > External Email Alert > > This email has been sent from an account outside of the BAE Systems network. > > Please treat the email with caution, especially if you are requested > to cli

Re: [yocto] #yocto #dunfell #qemux86-64

esday, August 31, 2022 7:42 AM > To: Monsees, Steven C (US) > Cc: yocto@lists.yoctoproject.org > Subject: Re: [yocto] #yocto #dunfell #qemux86-64 > > External Email Alert > > This email has been sent from an account outside of the BAE Systems network. > > Please treat the ema

Re: [yocto] #yocto #dunfell #qemux86-64

question, does this issue exist in kirkstone-4.0.2 ? > > Thanks, > Steve > > -Original Message- > From: Alexander Kanavin > Sent: Wednesday, August 31, 2022 7:42 AM > To: Monsees, Steven C (US) > Cc: yocto@lists.yoctoproject.org > Subject: Re: [yocto] #yocto

Re: [yocto] #yocto #dunfell #qemux86-64

One final question, does this issue exist in kirkstone-4.0.2 ? Thanks, Steve -Original Message- From: Alexander Kanavin Sent: Wednesday, August 31, 2022 7:42 AM To: Monsees, Steven C (US) Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #dunfell #qemux86-64 External

Re: [yocto] #yocto #dunfell #qemux86-64

> To: Monsees, Steven C (US) > Cc: yocto@lists.yoctoproject.org > Subject: Re: [yocto] #yocto #dunfell #qemux86-64 > > External Email Alert > > This email has been sent from an account outside of the BAE Systems network. > > Please treat the email with caution, especially if you are r

Re: [yocto] #yocto #dunfell #qemux86-64

, 2022 7:23 AM To: Monsees, Steven C (US) Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto #dunfell #qemux86-64 External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested

Re: [yocto] #yocto #dunfell #qemux86-64

sing ? > > (2)Is there something I need to pre-configure for these builds to run > properly ? > > (3)How might I resolve this issue ? > > > > 06:57 smonsees@yix490016 > /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min>runqemu &g

[yocto] #yocto #dunfell #qemux86-64

?, and is there another release I should be using ? (2)Is there something I need to pre-configure for these builds to run properly ? (3)How might I resolve this issue ? 06:57 smonsees@yix490016 /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min>runqemu qemux86-64 runq

[yocto] [meta-yocto][dunfell][PATCH] linux-yocto/5.4: update genericx86* machines to v5.4.205

Signed-off-by: Rajesh Dangi --- .../recipes-kernel/linux/linux-yocto_5.4.bbappend | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.4.bbappend index

Re: [yocto] Custom YOCTO meta-layer building on Ubuntu 20 but Not in Ubuntu 18.Why? #dunfell #yocto #dunfell

on Ubuntu versions. As i just started YOCTO(dunfell) few weeks before, I am a noob in YOCTO . Please help on the above issue -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57608): https://lists.yoctoproject.org/g/yocto/message/57608 Mute This Topic

[yocto] Custom YOCTO meta-layer building on Ubuntu 20 but Not in Ubuntu 18.Why? #dunfell #yocto #dunfell

adding custom layers the above problem arises. And the errors which are coming is from the meta layer inside poky for the gcc9.3 package. Is there anything to be taken care for making custom layer independent on Ubuntu versions. As i just started YOCTO(dunfell) few weeks before, I am a noob in YOCTO

Re: [yocto] dunfell do_image_wic error

Sorry for missing information I get this error when I do bitbake core-image-minimal MZ On 04/07/22 21:17, Mauro Ziliani wrote: Hi all. I update dunfell to last version. But now I get a python exception error on do_image_wic task | Traceback (most recent call last): |   File

[yocto] dunfell do_image_wic error

Hi all. I update dunfell to last version. But now I get a python exception error on do_image_wic task | Traceback (most recent call last): |   File "/home/yocto/sources/poky/scripts/lib/wic/filemap.py", line 457, in get_mapped_ranges | first_prev, last_prev = next(iterator) |

Re: [yocto] [dunfell][PATCH] openssl: update from 1.1.1n to 1.1.1o

On Wed, May 18, 2022 at 12:14 AM Daniel Karlsson wrote: > > This update fixes CVE-2022-1292. Hi Daniel, I've already taken a patch for this update and it is in the set sent out for review yesterday: https://lists.openembedded.org/g/openembedded-core/message/165788 In the future if you want to

[yocto] [dunfell][PATCH] openssl: update from 1.1.1n to 1.1.1o

This update fixes CVE-2022-1292. Signed-off-by: Daniel Karlsson --- .../openssl/{openssl_1.1.1n.bb => openssl_1.1.1o.bb}| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-connectivity/openssl/{openssl_1.1.1n.bb => openssl_1.1.1o.bb} (98%) diff --git

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

On Fri, 14 Jan 2022 at 12:41, Zoltan Boszormenyi via lists.yoctoproject.org wrote: > It would also help if recipes staying on the same version > but adding patches for e.g. CVE fixes should increase their > PR value so their rebuilt versions can be put into a package repo. > > Throwing away the

Re: [yocto] Question of Yocto dunfell LTS period

On Fri, 2022-01-14 at 07:14 +, Matthias Klein wrote: > Hello together, > > I would like to add a question to the topic: > > Why was the LTS period for dunfell extended? > Can we expect the same for kirstone? The project members agreed to fun an extension to the lifetime of dunfell from 2

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

Funny you mention PR. It would also help if recipes staying on the same version but adding patches for e.g. CVE fixes should increase their PR value so their rebuilt versions can be put into a package repo. Throwing away the buildroot (as suggested any time some obscure build error happens) and

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

Actually, I think this was some kind of missed PR opportunity. Regular distros, such as RHEL, Debian and everyone else, are constantly trotting out their support windows as the reason to hand them the job of making products, so we could counter that better perhaps. Alex On Fri, 14 Jan 2022 at

Re: [yocto] Question of Yocto dunfell LTS period

Gesendet: Freitag, 14. Januar 2022 02:14 An: yocto@lists.yoctoproject.org; openembedded-c...@lists.openembedded.org Cc: richard.pur...@linuxfoundation.org; st...@sakoman.com Betreff: [yocto] Question of Yocto dunfell LTS period Dear folks, I found the lts period of Yocto dunfell has been extended

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

On 1/14/22 2:36 AM, Jate Sujjavanich wrote: > I received the answer to this question in IRC on 10/29/2021. > > 16:06 >   > I saw a wiki edit that said dunfell's LTS period is now through April > 2024, but I've seen no announcements.

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

out the project advocacy side of things :( Let this email serve as a little advocacy. -Jate S. On Thu, Jan 13, 2022 at 8:14 PM Chanho Park via lists.openembedded.org wrote: > Dear folks, > > I found the lts period of Yocto dunfell has been extended from 2022.04 to > 2024.04[1]. >

[yocto] Question of Yocto dunfell LTS period

Dear folks, I found the lts period of Yocto dunfell has been extended from 2022.04 to 2024.04[1]. AFAIK, a Yocto LTS version has 2 years period. I tried to find any notice regarding this but I just found Richard's e-mail[2] in last year. Can I find any thread or notice regarding this extension

Re: [yocto] [dunfell] hidden files/folders in WORKDIR

On 2021-12-15 2:22 p.m., Joel Winarske wrote: I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work". Is this a feature or a bug? I think it's an oversight that doesn't affect many people. The rm_work code for WORKDIR

[yocto] [dunfell] hidden files/folders in WORKDIR

I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work". Is this a feature or a bug? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55595):

[yocto] #dunfell #qt5 #raspberrypi #sdk #linux

Hello everybody, I come today to try to solve my problem. I am building a bsp and sdk for a raspberry pi (MACHINE = raspberrypi4-64) in the form of a compute module. I'm trying to compile this app: https://github.com/YvesBas/Tadarida-D/tree/master/sources for the raspberry pi). I know that in

Re: [yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

1 at 5:26 PM To: Darcy Watkins Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure Most likely expired Let's Encrypt certificate (which salsa.debian.org<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsals

Re: [yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

and then it should be fine. On Thu, Nov 4, 2021 at 1:20 AM Darcy Watkins wrote: > Hi, > > > > After syncup of Yocto dunfell, I get the following error: > > > > dwatkins@carmd-ed-n11377-docker-dwatkins_apollo17:64bit build $ bitbake > ca-certificates -

[yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

Hi, After syncup of Yocto dunfell, I get the following error: dwatkins@carmd-ed-n11377-docker-dwatkins_apollo17:64bit build $ bitbake ca-certificates -c fetch Loading cache: 100

Re: [yocto] Dunfell: problem with kernel-module install and libkmod.so

On Fri, 15 Oct 2021 20:03:52 + "Patrick Boettcher" wrote: >Hi list, > >I'm facing an issue with a BSP I created using dunfell (up-to-date on >poky and oe). I'm using a stable kernel and u-boot 2021.07 from denx's >mainline-stable-layer. It was a problem of DDR memory configuration and

Re: [yocto] dunfell: pkgconfig-native build fails in existing Yocto BSP

Hello Richard, Thanks for the quick help! Best regards, Matthias -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55145): https://lists.yoctoproject.org/g/yocto/message/55145 Mute This Topic: https://lists.yoctoproject.org/mt/86571641/21656 Group

Re: [yocto] dunfell: pkgconfig-native build fails in existing Yocto BSP

On Mon, 2021-10-25 at 06:50 +, Matthias Klein wrote: > Hello, > > our dunfell based yocto no longer builds in the pkgconfig-native section. I > tried it in an Ubuntu 18.04 and Debian 10 Docker container. > The build always aborts as follows: > > checking thread related cflags...

Re: [yocto] dunfell: pkgconfig-native build fails in existing Yocto BSP

Hello, We also have the same issue with similar in-docker builds, a workaround for the issue is mentioned here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14519 until the fix is backported to dunfell. Best Regards, Ahmed Hossam -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages

[yocto] dunfell: pkgconfig-native build fails in existing Yocto BSP

Hello, our dunfell based yocto no longer builds in the pkgconfig-native section. I tried it in an Ubuntu 18.04 and Debian 10 Docker container. The build always aborts as follows: checking thread related cflags... -D_REENTRANT | checking for pthread_create/pthread_join... no | checking for

[yocto] Dunfell: problem with kernel-module install and libkmod.so

Hi list, I'm facing an issue with a BSP I created using dunfell (up-to-date on poky and oe). I'm using a stable kernel and u-boot 2021.07 from denx's mainline-stable-layer. I stripped down my machine.conf and basically the boot is working fine. Was working fine. When finally I created a

Re: [yocto] #dunfell Path to sources in debugfs

Hi, I`m trying to debug without connection to target at all. This are the examples of what I`m running: # gdb-multiarch b2010_rootfs/usr/bin/noah-heatsystem var/volatile/crash/core.noah.565 (gdb) set sysroot b2010_rootfs/ (gdb) set substitute-path /usr/src/debug b2010/usr/src/debug things

Re: [yocto] #dunfell Path to sources in debugfs

Hi, I can see this on Qt builds as well. I doubt Qt can have such strange behavior left unnoticed for a long time. The part is missing is " *include/QtCore* " -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54976):

Re: [yocto] #dunfell Path to sources in debugfs

Hi, My comments are inline. On 05/10/2021 17:04, bohdan.shubenok@sigma.software wrote: Hi all, I`m trying to debug coredump generated on embedded system running dunfel. Just to clarify your user space applications crashes and you try to see why? In other words you would like to load the

Re: [yocto] #dunfell Path to sources in debugfs

On 10/5/21 7:04 AM, bohdan.shubenok@sigma.software wrote: Hi all, I`m trying to debug coredump generated on embedded system running dunfel. The issue I`m facing is with the source files path in "-dbg.rootfs" archive and within dedug portion of a package. When loaded in QtCreator some

[yocto] #yocto #dunfell Console Standard input dirty without "tools-sdk" image feature

Using dunfell 3.1.8 Will post this inquiry while doing my own investigation. When outputting to the debug console that involves standard input(ex. busctl, systemctl status), the output seems misaligned and dirty. But I noticed this can be easily fixed by adding to the "tools-sdk" to the

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

Hello to everyone, Mguentner fixed the cmake issue: https://github.com/mguentner/cannelloni/issues/35 With this patch: https://github.com/mguentner/cannelloni/commit/125a7c72e4bcbbf580aeb6ee03e25ed0540be217 So I also reinstated the old cannelloni recipe with:

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

Hello Joel, Thank you for the tips. Really helpful, appreciated very much. I spent some time this morning investigating this issue, and to find the culprit. Here are my findings, which resulted in a cannelloni.bb recipe change (according to what you wrote). The fix submitted is in recipe:

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

Hi Zoran, Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it. Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling.

[yocto] Problem with YOCTO Dunfell and host Fedora 33

Hello Yocto developers, I have few problems running the following self proprietary script from one of my public git repos: https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh I recall that last time I used the script (I used then Fedora 31), the ./yocto setup dunfell

[yocto] [dunfell] Remove hwclock #dunfell #yocto

Hi, I would like to remove hwclock from the rootfs cause we don't have an RTC. Maybe later I'll replace it with fake-hwclock. I'm using dunfell with IPK packages and I tried to add the following settings in my image settings file (not all at the same time) but none of them removed hwclock. *

Re: [yocto] dunfell: regression linux-fimware installed in rootfs in actual dunfell master

On Thu, Mar 11, 2021 at 11:44 AM Marek Belisko wrote: > > Hi, > > I've bumped from poky dunfell: dunfell-23.0.6 to actual dunfell branch > and I have an problem that all linux-firmware packages are installed > in my rootfs (even I have in IMAGE_INSTALL only > linux-firmware-bcm43430). Any ideas?

[yocto] dunfell: regression linux-fimware installed in rootfs in actual dunfell master

Hi, I've bumped from poky dunfell: dunfell-23.0.6 to actual dunfell branch and I have an problem that all linux-firmware packages are installed in my rootfs (even I have in IMAGE_INSTALL only linux-firmware-bcm43430). Any ideas? In the commit log I saw that linux-firmware package was bumped.

Re: [yocto] Dunfell, nodejs and typescript - short experience report

Hi Simon, thank you - in my current solution I don't use npm bbclass at all. I basically use npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json;dev=True this will downloadall npm stuff including angular because of dev=True to $S/node_modules do_compile () { #    build frontend chmod -R a+w

Re: [yocto] Dunfell, nodejs and typescript - short experience report

Sure, please find the bbclass file attached to this mail. All it does is to inherit npm and overwrite configure with an extended copy . Meanwhile, I saw another issue popping up: It seems that multiple indirect dependencies to a package with different versions create inconsitent license

Re: [yocto] Dunfell, nodejs and typescript - short experience report

Hi Simon, I'm dealing actually with the same problem. Would you like to share your  "configure in my own subclass"? I'm also thinking there is a need for a bbclass which actually is not using gyp, instead it should be able to "npm run build". There is alsa a patch for speeding up npm npmsw

Re: [yocto] Dunfell, nodejs and typescript - short experience report

Hi, Am 12.02.21 um 11:12 schrieb Josef Holzmayr: Howdy! Thanks for sharing, a few comments inline. Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl : I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge

[yocto] Dunfell, nodejs and typescript - short experience report

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few

[yocto] [Meta-Java] Error while installing jamvm #yocto #dunfell

Hi, I have download meta-java layer and added to the conf/bblayer.conf file, then added jamvm to conf/local.conf file and ran bitbake command, but I got this error as "Nothing RPROVIDES 'jamvm' (but /home/bl-docker/rity/src/poky/../meta-mediatek-bsp/recipes-core/images/mtk-image.bb RDEPENDS

[yocto] [dunfell][PATCH v2 3/3] bitbake: fetch/git: download LFS content too during do_fetch

From: Matt Hoosier Insert an explicit pass to fetch all blobs needed by Git LFS, during the fetch() function. This avoids the default behavior of Git LFS to wait until 'git checkout' to begin downloading the blobs pointed to by LFS records. Network access is not allowed at that point in the

[yocto] [dunfell][PATCH v2 2/3] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

From: Mauro Queirós Function "contains_lfs" was only looking at the master branch when searching for LFS content. LFS may be configured in specific branches only, so we need to use the correct branch. (Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22) Signed-off-by: Mauro Queiros

[yocto] [dunfell][PATCH v2 1/3] bitbake: git.py: skip smudging if lfs=0 is set

From: Mauro Queirós Git-LFS objects were being fetched even when lfs=0 was not set. This patch disables LFS smudging when lfs=0. That way, only the LFS pointers are downloaded during checkout. (Bitbake rev: 646d86df7de774255246a3d7051c308e43eb257d) Signed-off-by: Mauro Queiros Signed-off-by:

[yocto] [dunfell][PATCH 2/2] bitbake: fetch/git: download LFS content too during do_fetch

From: Matt Hoosier Insert an explicit pass to fetch all blobs needed by Git LFS, during the fetch() function. This avoids the default behavior of Git LFS to wait until 'git checkout' to begin downloading the blobs pointed to by LFS records. Network access is not allowed at that point in the

[yocto] [dunfell][PATCH 1/2] bitbake: git.py: Use the correct branch to check if the repository has LFS objects.

From: Mauro Queirós Function "contains_lfs" was only looking at the master branch when searching for LFS content. LFS may be configured in specific branches only, so we need to use the correct branch. (Bitbake rev: 4fa67c2af830035a1ddedc14592ee25a15ebff22) Signed-off-by: Mauro Queiros

[yocto] pyqt5 in yocto dunfell version #dunfell #pyqt5

Hello everyone, I'm trying the dunfell version of yocto, to migrate from zeus to dunfell. I added the layer "meta-qt5", "meta-python2", "meta-openembedded". The problem I meet follows: In zeus version, I installed pyqt5 in my rootfs (recipe name is: python3-pyqt5). Actually, I tested the

[yocto] Dunfell :: Recipe fixes to install Webmin 1.962 and fix Perl CGI

Hello all: Just a quick email to submit to the group. I needed to build a distro to include Webmin. The version that comes with OpenEmbedded (webmin 1.850) in meta-webserver/recipes-webadmin/webmin is kind of an old release, and there were issues with the build. Below is a new recipe:

[yocto] dunfell actual package.bbclass causing problems after commit #dunfell

this commit 087a099c288c6bedf368c8756d998172b02b50ad package: get_package_mapping: avoid dependency mapping if renamed package provides original name is causing this problem: NOTE: recipe intronix-introndplus-initramfs-1.0-r0: task do_rootfs: Started ERROR: intronix-introndplus-initramfs-1.0-r0

Re: [yocto] How to integrate kernel-module in yocto-dunfell? #yocto #dunfell #apt #tx2 #kernel

On Thu, Sep 3, 2020 at 8:56 AM wrote: > > Hi Khem, thanks for your reply! Now I am a bit confused. Marek has sent me > another recipe: Shared recipe should be the same as one from meta-oe :). So you can include it in your image and it should be build then. > > LICENSE = "GPLv2" > >

Re: [yocto] How to integrate kernel-module in yocto-dunfell? #yocto #dunfell #apt #tx2 #kernel

Hi Khem, thanks for your reply! Now I am a bit confused. Marek has send me another recipe: > > > > LICENSE = "GPLv2" > > > > LIC_FILES_CHKSUM = " file://COPYING;md5=72d977d697c3c05830fdff00a7448931 " > > > > > SRCREV = "6003f9997587e6a563cebf1f246bcd0eb6deff3d" > > > > PV =

Re: [yocto] How to integrate kernel-module in yocto-dunfell? #yocto #dunfell #apt #tx2 #kernel

On Wed, Sep 2, 2020 at 4:32 AM Marek Belisko wrote: > > On Wed, Sep 2, 2020 at 1:13 PM wrote: > > > > Hey community, > > > > I'm trying to use this library [can-isotp][1] on a Jetson TX2 Board. The > > version of the running OS is: 0.0.8 (dunfell). > > > > From the docs of the library I get the

Re: [yocto] How to integrate kernel-module in yocto-dunfell? #yocto #dunfell #apt #tx2 #kernel

On Wed, Sep 2, 2020 at 1:13 PM wrote: > > Hey community, > > I'm trying to use this library [can-isotp][1] on a Jetson TX2 Board. The > version of the running OS is: 0.0.8 (dunfell). > > From the docs of the library I get the following instructions: > > ``` > > DOWNLOAD and BUILD > > 1. Download

[yocto] How to integrate kernel-module in yocto-dunfell? #yocto #dunfell #apt #tx2 #kernel

Hey community, I'm trying to use this library [can-isotp][1] on a Jetson TX2 Board. The version of the running OS is: 0.0.8 (dunfell). >From the docs of the library I get the following instructions: ``` DOWNLOAD and BUILD 1. Download repository and enter the repositories root directory

Re: [yocto] Information about Yocto Dunfell components version #dunfell

On Tue, 1 Sep 2020 at 11:25, Josef Holzmayr-Khosh Amoz wrote: > > Insert the package names into > http://layers.openembedded.org/layerindex/branch/dunfell/recipes and see for > yourself :) > > Greetz > > Am Di., 1. Sept. 2020 um 12:22 Uhr schrieb Yocto_user > : >> >> Hi All, >> >> I read the

Re: Private: Re: [yocto] Information about Yocto Dunfell components version #dunfell

Well if it's not there, then it's not there. If something is not provided by a recipe, then it obviously has no defined version. Please note though that package/recipe names are not directly comparable between distributions like Ubuntu and the Yocto project ecosystem, as the names might differ

Re: [yocto] Information about Yocto Dunfell components version #dunfell

Insert the package names into http://layers.openembedded.org/layerindex/branch/dunfell/recipes and see for yourself :) Greetz Am Di., 1. Sept. 2020 um 12:22 Uhr schrieb Yocto_user < avinashyadav9...@gmail.com>: > Hi All, > > I read the Dunfell release notes but couldn't find the version detail

[yocto] Information about Yocto Dunfell components version #dunfell

Hi All, I read the Dunfell release notes but couldn't find the version detail of following components: bzip2 cairo faad2 fontconfig freetype gdkpixbuf libav libffi libjpeg libogg libpng libtiff libvorbis libxcursor openexr openssl pango pixman stb-image swscale theora x264 zlib Please give

[yocto] dunfell: what would cause "ERROR: Nothing PROVIDES 'coreutils-native'."?

migrating from zeus to dunfell and, suddenly, some "ndisc"-related recipes no longer build with: ERROR: Nothing PROVIDES 'coreutils-native'. the offending recipe is from meta-networking/recipes-support, ndisc6_git.bb, clearly at the line: DEPENDS = "coreutils-native" whereupon "git blame"

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Sat, 1 Aug 2020, 15:19 Sumit Garg, wrote: > On Sat, 1 Aug 2020 at 19:40, Sumit Garg via lists.yoctoproject.org > wrote: > > > > On Sat, 1 Aug 2020 at 14:57, Ryan Harkin wrote: > > > > > > > > > > > > On Sat, 1 Aug 2020 at 10:09, Ryan Harkin > wrote: > > >> > > >> Hi Khem, > > >> > > >> On

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Sat, 1 Aug 2020 at 19:40, Sumit Garg via lists.yoctoproject.org wrote: > > On Sat, 1 Aug 2020 at 14:57, Ryan Harkin wrote: > > > > > > > > On Sat, 1 Aug 2020 at 10:09, Ryan Harkin wrote: > >> > >> Hi Khem, > >> > >> On Fri, 31 Jul 2020, 21:58 Khem Raj, wrote: > >>> > >>> On Fri, Jul 31,

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Sat, 1 Aug 2020 at 14:57, Ryan Harkin wrote: > > > > On Sat, 1 Aug 2020 at 10:09, Ryan Harkin wrote: >> >> Hi Khem, >> >> On Fri, 31 Jul 2020, 21:58 Khem Raj, wrote: >>> >>> On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin wrote: >>> > >>> > Hello, >>> > >>> > I'm migrating from Warrior to

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Sat, 1 Aug 2020 at 14:42, Ryan Harkin wrote: > > Hi Sumit, > > On Sat, 1 Aug 2020, 07:51 Sumit Garg, wrote: >> >> Hi Ryan, >> >> On Fri, 31 Jul 2020 at 21:05, Ryan Harkin wrote: >> > >> > Hello, >> > >> > I'm migrating from Warrior to Dunfell and I'm getting a curious build >> > failure in

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Sat, 1 Aug 2020 at 10:09, Ryan Harkin wrote: > Hi Khem, > > On Fri, 31 Jul 2020, 21:58 Khem Raj, wrote: > >> On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin >> wrote: >> > >> > Hello, >> > >> > I'm migrating from Warrior to Dunfell and I'm getting a curious build >> failure in gcc-sanitizers.

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

Hi Sumit, On Sat, 1 Aug 2020, 07:51 Sumit Garg, wrote: > Hi Ryan, > > On Fri, 31 Jul 2020 at 21:05, Ryan Harkin wrote: > > > > Hello, > > > > I'm migrating from Warrior to Dunfell and I'm getting a curious build > failure in gcc-sanitizers. > > > > Here's the full gory detail: > >

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

Hi Khem, On Fri, 31 Jul 2020, 21:58 Khem Raj, wrote: > On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin > wrote: > > > > Hello, > > > > I'm migrating from Warrior to Dunfell and I'm getting a curious build > failure in gcc-sanitizers. > > > > Here's the full gory detail: > >

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

Hi Ryan, On Fri, 31 Jul 2020 at 21:05, Ryan Harkin wrote: > > Hello, > > I'm migrating from Warrior to Dunfell and I'm getting a curious build failure > in gcc-sanitizers. > > Here's the full gory detail: > https://pastebin.ubuntu.com/p/nh4cDKMvgS/ > > However, the main error is this: > > |

Re: [yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin wrote: > > Hello, > > I'm migrating from Warrior to Dunfell and I'm getting a curious build failure > in gcc-sanitizers. > > Here's the full gory detail: > https://pastebin.ubuntu.com/p/nh4cDKMvgS/ > > However, the main error is this: > > | In file

[yocto] dunfell gcc-sanitizers-arm-8.3 fails to build

Hello, I'm migrating from Warrior to Dunfell and I'm getting a curious build failure in gcc-sanitizers. Here's the full gory detail: https://pastebin.ubuntu.com/p/nh4cDKMvgS/ However, the main error is this: | In file included from

[yocto] Yocto Dunfell: package.class --> dwarfsrcfiles

Hello, thanks for the reply and the useful hints concerning our questions! After a debug session, it came out, that the *.a archive doesn't contain only *.o files, but also one *.c file. That was missed during the first analysis. Interestingly enough, the error came out only with the Dunfell

  1   2   >