Re: [yocto] [npm] duplicate code
Hi Jean-Marie, what work do you plan to do on npm and recipetool? I have start to rework the complete npm integration to synchronize it with other languages like python. I replace the bitbake npm fetch with the wget fetcher and download the npm tgz files direct. The idea is to handle every package as a separate recipe and move the package dependencies into the recipes. Therefore I parse the package.json and the npm server json to create a recipe. Regards Stefan Am 03.10.19 um 17:37 schrieb Jean-marie Lemetayer: Hi all, I am planning to do some work on npm and recipetool. I have seen that there is some duplicate code between bitbake/lib/bb/fetch2/npm.py and scripts/lib/recipetool/create_npm.py but there is some inconsistencies. Here is an example, the _parse_view() function which I patched recently has differ: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/npm.py#n157 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/recipetool/create_npm.py#n244 I think merging this "npm utility functions" is a good idea. But where ? I think about creating a new file: bitbake/lib/bb/npm_utils.py Or maybe use the existing bitbake/lib/bb/utils.py ? What do you think ? Jean-Marie LEMETAYER Enthusiast embedded systems engineer Savoir-faire Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Demos for the Yocto Project booth at ELCE in Lyon
Dear all, As usual, the Yocto Project will have a booth at the ELCE conference in Lyon later this month. While the booth is a great opportunity for everyone to get a new sticker of your favorite project ;-) we are also very excited when developers from our community get a chance to show off the fun and cool things they build thanks to the Yocto Project! If you want to bring any of your cool demo on the YP booth, please reply to Andreea (cc'd) and I so that we can plan and discuss any of the logistics! Also, don't forget that right after ELCE we are having our first Yocto Project Summit, with a very exciting schedule and great set of speakers. If you haven't done so already, please check out: https://www.yoctoproject.org/yocto-project-summit-2019/ cheers nico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel.bbclass do_bundle_initramfs did not work
Hi, It seems to me if both INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE are set it should generate initramfs, but I did not get. I set up in my image: INITRAMFS_IMAGE = "zImage-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" But it did not build zImage-initramfs, what I could be missing here? Thank you. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel.bbclass do_bundle_initramfs did not work
Hey JH, I had a similiar problem before. What branch and revision do you have checked out for your meta-layers ? Mine looks like the following and I get an initramfs built into my image: meta-yocto-bsp = "warrior:01b8a8b54bc569e5ef3f5e6fc6abcee365ab25d9" meta-intel = "warrior:6bd7b2edafe90e61a3a52cd089432080b82a7891" meta-qt5 = "warrior:2a5f9415e48a38f6f4eb0cf375737a2d8438e2fe" meta-mingw = "warrior:10695afe8cd406844e0d0dd868c11677e07557d4" meta-initramfs = "warrior:8d5dcd6522e9d15e68637b6d7dda0401f9bb91d0" Further more what happens if you build only an initramfs ? bitbake core-image-minimal-initramfs Any error messages ? If not, how is your initramfs called ? The issue *could* also be a misspelling in zImage-initramfs. Best regards Moritz On 04.10.19 13:26, JH wrote: Hi, It seems to me if both INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE are set it should generate initramfs, but I did not get. I set up in my image: INITRAMFS_IMAGE = "zImage-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" But it did not build zImage-initramfs, what I could be missing here? Thank you. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot use "LICENSE_CREATE_PACKAGE = 1" when building the image with mdns
I investigated a little bit.
Probably, I didn't understand your point.
The postinst script modifies nsswitch adding mdns and this is right, but
why is this interfering with the license create package?
If I remove the postinst I can build with license create package, however I
need this change to nsswitch.
Is it possibile to change the recipe of mdns to modify nsswitch without
interfering with license create package in another () { }?
Thanks
Il gio 3 ott 2019, 14:24 Stefano Cappa ha
scritto:
> I resend this email because it's not visible in yocto mailing list.
>
>
>
> Hi thank you for the answer.
>
> In my rootfs I have this nsswitch.conf:
> ---
> # /etc/nsswitch.conf
> #
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc' and `info' packages installed, try:
> # `info libc "Name Service Switch"' for information about this file.
>
> passwd: compat
> group: compat
> shadow: compat
>
> hosts: files myhostname mdns dns
> networks: files
>
> protocols: db files
> services: db files
> ethers: db files
> rpc:db files
>
> netgroup: nis
> ---
>
> I'm not familiar with this file.
> Also changing "hosts: files myhostname mdns dns" to "hosts: files
> mdns4_minimal [NOTFOUND=return] dns" (copied from a raspberry pi 3) I'm
> still having the same problem.
>
> What should I change to fix this issue?
>
>
>
>
> Il mar 1 ott 2019, 11:29 Stefano Cappa ha
> scritto:
>
>> Hi thank you for the answer.
>>
>> In my rootfs I have this nsswitch.conf:
>> ---
>> # /etc/nsswitch.conf
>> #
>> # Example configuration of GNU Name Service Switch functionality.
>> # If you have the `glibc-doc' and `info' packages installed, try:
>> # `info libc "Name Service Switch"' for information about this file.
>>
>> passwd: compat
>> group: compat
>> shadow: compat
>>
>> hosts: files myhostname mdns dns
>> networks: files
>>
>> protocols: db files
>> services: db files
>> ethers: db files
>> rpc:db files
>>
>> netgroup: nis
>> ---
>>
>> I'm not familiar with this file.
>> Also changing "hosts: files myhostname mdns dns" to "hosts: files
>> mdns4_minimal [NOTFOUND=return] dns" (copied from a raspberry pi 3) I'm
>> still having the same problem.
>>
>> What should I change to fix this issue?
>>
>>
>> Il lun 30 set 2019, 22:45 Khem Raj ha scritto:
>>
>>>
>>>
>>> On 9/30/19 8:17 AM, Stefano Cappa wrote:
>>> > I saw your last patch to upgrade mdns, so I'm sending this email also
>>> to
>>> > you to try to get help.
>>> >
>>> > mdns is working correctly, however, when I try to build my image with
>>> > "LICENSE_CREATE_PACKAGE = "1"" in my local.conf as described
>>> > here
>>> https://www.yoctoproject.org/docs/2.8/dev-manual/dev-manual.html#providing-license-text
>>> I
>>> > get this error message:
>>> >
>>> > ERROR: mydevice-image-1.0-r0 do_rootfs: Postinstall scriptlets of
>>> > ['mdns'] have failed. If the intention is to defer them to first boot,
>>> > then please place them into pkg_postinst_ontarget_${PN} ().
>>> > Deferring to first boot via 'exit 1' is no longer supported.
>>> > Details of the failure are in
>>> >
>>> /home/user/git/poky/build/tmp/work/mydevice1-image-poky-linux-gnueabi/mydevice-image/1.0-r0/temp/log.do_rootfs.
>>> > ERROR: mydevice-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>>> > ERROR: Logfile of failure stored in:
>>> >
>>> /home/user/git/poky/build/tmp/work/mydevice1-poky-linux-gnueabi/mydevice-image/1.0-r0/temp/log.do_rootfs.14586
>>> > ERROR: Task (MY CUSTOM LAYER
>>> > PATH/recipes-core/images/mydevice-image.bb:do_rootfs) failed with exit
>>> > code '1'
>>> > NOTE: Tasks Summary: Attempted 4871 tasks of which 4654 didn't need to
>>> > be rerun and 1 failed.
>>> >
>>> > Do you have a solution? Why is it happening?
>>> >
>>>
>>> see mdns recipe especially
>>>
>>> pkg_postinst_${PN} (), that function is not able to execute offline
>>> during build. It could be that nsswitch.conf does not exist in your
>>> image rootfs
>>>
>>> > thank u.
>>>
>>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [npm] duplicate code
Hi Stefan, I have recently worked on a yocto project using npm and I have seen some issues. I have solved a few but only for bitbake: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eecba41822e86b69ebdb9cbc8fbfd512ad9a47d7 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a34d0d539e5fdf341541fb628652d22289e80512 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e90cd2ed61b93ee7e290e7e592f1f0242ab5c281 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a35abe31dc23916fd06afdb3a5e22a81ef3df579 As I have more time now, I wanted to continue my work by fixing devtool / recipetool. I have also checked the bugzilla for issues that I could fix / that should be tested again: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10515 https://bugzilla.yoctoproject.org/show_bug.cgi?id=10760 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11028 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11029 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12534 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13415 I ended up with this todo list: - merge the duplicate code between bitbake and recipetool - fix the npm package name handling in recipetool - fix the npm package version handling in recipetool - fix the lockdown.json file generation in recipetool - create an example nodejs application to test all these cases - update the wiki using this example application: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM Finally, in my recent project, we were using angular (https://angular.io) for the front-end. I have planned to add the work done to support angular applications in yocto (angular.bbclass) and update recipetool to handle them. Your work sounds very interesting. The good point is that npm-shrinkwrap.json and lockdown.json files (which have generation issues btw) will no longer be required. But projects using npm can have a lot of dependencies (e.g. the angular example app have 1053 dependencies). Is recipetool will be handling the whole recipes creation in one time ? Is it possible to see your work ? A public fork would be nice. I would gladly help you / test your work / add my fixes if needed. Best regards, Jean-Marie Lemetayer - Mail original - De: "Stefan Herbrechtsmeier" À: "Yocto-mailing-list" Envoyé: Vendredi 4 Octobre 2019 08:53:10 Objet: Re: [yocto] [npm] duplicate code Hi Jean-Marie, what work do you plan to do on npm and recipetool? I have start to rework the complete npm integration to synchronize it with other languages like python. I replace the bitbake npm fetch with the wget fetcher and download the npm tgz files direct. The idea is to handle every package as a separate recipe and move the package dependencies into the recipes. Therefore I parse the package.json and the npm server json to create a recipe. Regards Stefan Am 03.10.19 um 17:37 schrieb Jean-marie Lemetayer: > Hi all, > > I am planning to do some work on npm and recipetool. > > I have seen that there is some duplicate code between > bitbake/lib/bb/fetch2/npm.py and scripts/lib/recipetool/create_npm.py but > there is some inconsistencies. > > Here is an example, the _parse_view() function which I patched recently has > differ: > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/npm.py#n157 > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/recipetool/create_npm.py#n244 > > I think merging this "npm utility functions" is a good idea. But where ? > > I think about creating a new file: bitbake/lib/bb/npm_utils.py > > Or maybe use the existing bitbake/lib/bb/utils.py ? > > What do you think ? > > > Jean-Marie LEMETAYER > Enthusiast embedded systems engineer > Savoir-faire Linux > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [npm] duplicate code
Hi Jean-Marie, Am 04.10.19 um 14:37 schrieb Jean-marie Lemetayer: > I have recently worked on a yocto project using npm and I have seen some issues. I have solved a few but only for bitbake: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=eecba41822e86b69ebdb9cbc8fbfd512ad9a47d7 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a34d0d539e5fdf341541fb628652d22289e80512 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e90cd2ed61b93ee7e290e7e592f1f0242ab5c281 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a35abe31dc23916fd06afdb3a5e22a81ef3df579 As I have more time now, I wanted to continue my work by fixing devtool / recipetool. I have also checked the bugzilla for issues that I could fix / that should be tested again: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10515 https://bugzilla.yoctoproject.org/show_bug.cgi?id=10760 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11028 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11029 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12534 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13415 I ended up with this todo list: - merge the duplicate code between bitbake and recipetool - fix the npm package name handling in recipetool - fix the npm package version handling in recipetool - fix the lockdown.json file generation in recipetool - create an example nodejs application to test all these cases - update the wiki using this example application: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM Finally, in my recent project, we were using angular (https://angular.io) for the front-end. I have planned to add the work done to support angular applications in yocto (angular.bbclass) and update recipetool to handle them. Do you want to build an angular application? In this case you have to produce a machine (independent) package via a native npm build because you need to run the angular compiler on the build machine. Your work sounds very interesting. The good point is that npm-shrinkwrap.json and lockdown.json files (which have generation issues btw) will no longer be required. But projects using npm can have a lot of dependencies (e.g. the angular example app have 1053 dependencies). A lot of dependencies are the problem at the moment. But many dependencies are not update frequently and my current solution assume that I can always use the latest version per major release version Is recipetool will be handling the whole recipes creation in one time ? That's the problem at the moment. I don't manage to build multiple recipes from one recipetool run. Therefore I have a two stage approach. I use recipetool to build exact one recipe. A second script generates a list of all dependencies and call recipetool per package if the recipe doesn't already exist. This works but the run time is very high. Is it possible to see your work ? A public fork would be nice. I would gladly help you / test your work / add my fixes if needed. I only have a unfinished Proof of Concept. If you like I could clean it up a bit and post it on github as a separate layer. Regards Stefan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot use "LICENSE_CREATE_PACKAGE = 1" when building the image with mdns
I fixed this issue in this way:
I modified the recipe replacing this:
--
pkg_postinst_${PN} () {
sed -e '/^hosts:/s/\s*\//' \
-e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2
mdns\3\4\5/' \
-i $D/etc/nsswitch.conf
}
pkg_prerm_${PN} () {
sed -e '/^hosts:/s/\s*\//' \
-e '/^hosts:/s/\s*mdns//' \
-i $D/etc/nsswitch.conf
}--
with this:
--
pkg_postinst_ontarget_${PN} () {
sed -e '/^hosts:/s/\s*\//' \
-e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2\3mdns
\4\5/' \
-i $D/etc/nsswitch.conf
}
pkg_prerm_ontarget_${PN} () {
sed -e '/^hosts:/s/\s*\//' \
-e '/^hosts:/s/\s*mdns//' \
-i $D/etc/nsswitch.conf
}
--
Basically, I added _ontarget_ as suggested by yocto error that says: "...
If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ()".
In this way I can build the final image with LICENSE_CREATE_PACKAGE=1. Why?
I don't know. I didn't understand why there was this error.
However, the final result on the device when my os is running is different,
because my nsswitch.conf changes from "hosts: files myhostname mdns dns"
to "hosts: files mdns myhostname dns". Why? I don't know, however I
changed the regex in sed from "\1\2 mdns\3\4\5" to "\1\2\3mdns \4\5" to
restore the original result.
Why is it happening? Honestly, I don't know the reason. My solution worked,
but since I don't know why, I want to ask to someone more expert about
nsswitch.conf and in particular about pkg_prerm_ and pkg_postinst_ because
I really don't understand why I cannot change nsswitch without those and
why without LICENSE_CREATE_PACKAGE they are working also without adding
ontarget_, but with LICENSE_CREATE_PACKAGE = 1 the ontarget_ is required.
Please, can someone help about this? Or at least add in CC someone with
more experience about these topics.
Thank you.
Il giorno ven 4 ott 2019 alle ore 14:26 Stefano Cappa <
stefano.cappa.k...@gmail.com> ha scritto:
> I investigated a little bit.
> Probably, I didn't understand your point.
>
> The postinst script modifies nsswitch adding mdns and this is right, but
> why is this interfering with the license create package?
>
> If I remove the postinst I can build with license create package, however
> I need this change to nsswitch.
>
> Is it possibile to change the recipe of mdns to modify nsswitch without
> interfering with license create package in another () { }?
>
> Thanks
>
>
>
> Il gio 3 ott 2019, 14:24 Stefano Cappa ha
> scritto:
>
>> I resend this email because it's not visible in yocto mailing list.
>>
>>
>>
>> Hi thank you for the answer.
>>
>> In my rootfs I have this nsswitch.conf:
>> ---
>> # /etc/nsswitch.conf
>> #
>> # Example configuration of GNU Name Service Switch functionality.
>> # If you have the `glibc-doc' and `info' packages installed, try:
>> # `info libc "Name Service Switch"' for information about this file.
>>
>> passwd: compat
>> group: compat
>> shadow: compat
>>
>> hosts: files myhostname mdns dns
>> networks: files
>>
>> protocols: db files
>> services: db files
>> ethers: db files
>> rpc:db files
>>
>> netgroup: nis
>> ---
>>
>> I'm not familiar with this file.
>> Also changing "hosts: files myhostname mdns dns" to "hosts: files
>> mdns4_minimal [NOTFOUND=return] dns" (copied from a raspberry pi 3) I'm
>> still having the same problem.
>>
>> What should I change to fix this issue?
>>
>>
>>
>>
>> Il mar 1 ott 2019, 11:29 Stefano Cappa ha
>> scritto:
>>
>>> Hi thank you for the answer.
>>>
>>> In my rootfs I have this nsswitch.conf:
>>> ---
>>> # /etc/nsswitch.conf
>>> #
>>> # Example configuration of GNU Name Service Switch functionality.
>>> # If you have the `glibc-doc' and `info' packages installed, try:
>>> # `info libc "Name Service Switch"' for information about this file.
>>>
>>> passwd: compat
>>> group: compat
>>> shadow: compat
>>>
>>> hosts: files myhostname mdns dns
>>> networks: files
>>>
>>> protocols: db files
>>> services: db files
>>> ethers: db files
>>> rpc:db files
>>>
>>> netgroup: nis
>>> ---
>>>
>>> I'm not familiar with this file.
>>> Also changing "hosts: files myhostname mdns dns" to "hosts: files
>>> mdns4_minimal [NOTFOUND=return] dns" (copied from a raspberry pi 3) I'm
>>> still having the same problem.
>>>
>>> What should I change to fix this issue?
>>>
>>>
>>> Il lun 30 set 2019, 22:45 Khem Raj ha scritto:
>>>
On 9/30/19 8:17 AM, Stefano Cappa wrote:
> I saw your last patch to upgrade mdns, so I'm s
Re: [yocto] Cannot use "LICENSE_CREATE_PACKAGE = 1" when building the image with mdns
Oh, another update to integrate the previous email.
Inside the source code of mDNSResponder (
https://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-878.260.1.tar.gz)
I found in "mDNSPosix/Makefile" this:
"
# Check the nsswitch.conf file.
# If 'mdns' does not already appear on the "hosts:" line, then add it right
before 'dns'
cp -f /etc/nsswitch.conf /etc/nsswitch.conf.pre-mdns
sed -e '/mdns/!s/^\(hosts:.*\)dns\(.*\)/\1mdns dns\2/'
/etc/nsswitch.conf.pre-mdns > /etc/nsswitch.conf
"
Probably, It's better to use this "sed -e
'/mdns/!s/^\(hosts:.*\)dns\(.*\)/\1mdns dns\2/' /etc/nsswitch.conf.pre-mdns
> /etc/nsswitch.conf" instead of the existing one.
What do you think?
Il giorno ven 4 ott 2019 alle ore 17:04 Stefano Cappa <
stefano.cappa.k...@gmail.com> ha scritto:
> I fixed this issue in this way:
>
> I modified the recipe replacing this:
> --
> pkg_postinst_${PN} () {
> sed -e '/^hosts:/s/\s*\//' \
> -e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2
> mdns\3\4\5/' \
> -i $D/etc/nsswitch.conf
> }
>
> pkg_prerm_${PN} () {
> sed -e '/^hosts:/s/\s*\//' \
> -e '/^hosts:/s/\s*mdns//' \
> -i $D/etc/nsswitch.conf
> }--
>
> with this:
> --
> pkg_postinst_ontarget_${PN} () {
> sed -e '/^hosts:/s/\s*\//' \
> -e 's/\(^hosts:.*\)\(\\)\(.*\)\(\\)\(.*\)/\1\2\3mdns
> \4\5/' \
> -i $D/etc/nsswitch.conf
> }
>
> pkg_prerm_ontarget_${PN} () {
> sed -e '/^hosts:/s/\s*\//' \
> -e '/^hosts:/s/\s*mdns//' \
> -i $D/etc/nsswitch.conf
> }
> --
>
>
> Basically, I added _ontarget_ as suggested by yocto error that says: "...
> If the intention is to defer them to first boot,
> > then please place them into pkg_postinst_ontarget_${PN} ()".
>
> In this way I can build the final image with LICENSE_CREATE_PACKAGE=1.
> Why? I don't know. I didn't understand why there was this error.
>
> However, the final result on the device when my os is running is
> different, because my nsswitch.conf changes from "hosts: files myhostname
> mdns dns" to "hosts: files mdns myhostname dns". Why? I don't know,
> however I changed the regex in sed from "\1\2 mdns\3\4\5" to "\1\2\3mdns
> \4\5" to restore the original result.
>
> Why is it happening? Honestly, I don't know the reason. My solution
> worked, but since I don't know why, I want to ask to someone more expert
> about nsswitch.conf and in particular about pkg_prerm_ and pkg_postinst_
> because I really don't understand why I cannot change nsswitch without
> those and why without LICENSE_CREATE_PACKAGE they are working also without
> adding ontarget_, but with LICENSE_CREATE_PACKAGE = 1 the ontarget_ is
> required.
>
> Please, can someone help about this? Or at least add in CC someone with
> more experience about these topics.
>
> Thank you.
>
>
> Il giorno ven 4 ott 2019 alle ore 14:26 Stefano Cappa <
> stefano.cappa.k...@gmail.com> ha scritto:
>
>> I investigated a little bit.
>> Probably, I didn't understand your point.
>>
>> The postinst script modifies nsswitch adding mdns and this is right, but
>> why is this interfering with the license create package?
>>
>> If I remove the postinst I can build with license create package, however
>> I need this change to nsswitch.
>>
>> Is it possibile to change the recipe of mdns to modify nsswitch without
>> interfering with license create package in another () { }?
>>
>> Thanks
>>
>>
>>
>> Il gio 3 ott 2019, 14:24 Stefano Cappa ha
>> scritto:
>>
>>> I resend this email because it's not visible in yocto mailing list.
>>>
>>>
>>>
>>> Hi thank you for the answer.
>>>
>>> In my rootfs I have this nsswitch.conf:
>>> ---
>>> # /etc/nsswitch.conf
>>> #
>>> # Example configuration of GNU Name Service Switch functionality.
>>> # If you have the `glibc-doc' and `info' packages installed, try:
>>> # `info libc "Name Service Switch"' for information about this file.
>>>
>>> passwd: compat
>>> group: compat
>>> shadow: compat
>>>
>>> hosts: files myhostname mdns dns
>>> networks: files
>>>
>>> protocols: db files
>>> services: db files
>>> ethers: db files
>>> rpc:db files
>>>
>>> netgroup: nis
>>> ---
>>>
>>> I'm not familiar with this file.
>>> Also changing "hosts: files myhostname mdns dns" to "hosts: files
>>> mdns4_minimal [NOTFOUND=return] dns" (copied from a raspberry pi 3) I'm
>>> still having the same problem.
>>>
>>> What should I change to fix this issue?
>>>
>>>
>>>
>>>
>>> Il mar 1 ott 2019, 11:29 Stefano Cappa
>>> ha scritto:
>>>
Hi thank you for the answer.
In my rootfs I have this nsswitch.conf:
---
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch f
[yocto] Building a out of tree kernel module on target system
Hello, I am trying to build an out of tree service module on a yocto raspberry pi image(target system). I am using yocto version warrior and my machine is Raspberrypi-cm3 Kernel version is 4.19.58 I was able to get the build directory by including IMAGE_INSTALL_append = " kernel-modules kernel-dev kernel-devsrc" After that, I saw a build directory on raspberrypi-image Now I am trying to compile my source file with the command *make* *ARCH*=arm *CROSS_COMPILE*=arm-poky-linux-gnueabi- *KSRC*="/lib/modules/4.19.58/source" -C /lib/modules/$(shell uname -r)/build *M=*/home/root/tsDriver modules After that I get an error saying *asm/bitsperlong.h*: no such file or directory Am I missing something in my make command? Regards, Shravan Singh (239) 243-0838 Blue Sparq, Inc. 928 NE 24th Lane unit 4 and 5. Cape Coral, FL 33993 IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH] These changes will add the metadata for product revision and epoch if present in the bitbake recipe.
Signed-off-by: Pranay Mankad
---
.../migrations/0042_recipe_property_addition.py | 20
layerindex/models.py | 2 ++
layerindex/update_layer.py | 2 ++
3 files changed, 24 insertions(+)
create mode 100644 layerindex/migrations/0042_recipe_property_addition.py
diff --git a/layerindex/migrations/0042_recipe_property_addition.py
b/layerindex/migrations/0042_recipe_property_addition.py
new file mode 100644
index 000..5583696
--- /dev/null
+++ b/layerindex/migrations/0042_recipe_property_addition.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.24 on 2019-09-24 21:34
+from __future__ import unicode_literals
+from django.db import migrations, models
+class Migration(migrations.Migration):
+dependencies = [
+('layerindex', '0041_recipe_configopts'),
+]
+operations = [
+migrations.AddField(
+model_name='recipe',
+name='pe',
+field=models.CharField(blank=True, max_length=100),
+),
+migrations.AddField(
+model_name='recipe',
+name='pr',
+field=models.CharField(blank=True, max_length=100),
+),
+]
diff --git a/layerindex/models.py b/layerindex/models.py
index 0ca7c06..332ba39 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -461,6 +461,8 @@ class Recipe(models.Model):
filepath = models.CharField(max_length=255, blank=True)
pn = models.CharField(max_length=100, blank=True)
pv = models.CharField(max_length=100, blank=True)
+pr = models.CharField(max_length=100, blank=True)
+pe = models.CharField(max_length=100, blank=True)
summary = models.CharField(max_length=200, blank=True)
description = models.TextField(blank=True)
section = models.CharField(max_length=100, blank=True)
diff --git a/layerindex/update_layer.py b/layerindex/update_layer.py
index 9dc395f..7131d70 100644
--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py
@@ -108,6 +108,8 @@ def update_recipe_file(tinfoil, data, path, recipe,
layerdir_start, repodir, sto
envdata.setVar('SRCPV', 'X')
recipe.pn = envdata.getVar("PN", True)
recipe.pv = envdata.getVar("PV", True)
+recipe.pr = envdata.getVar("PR", True) or ""
+recipe.pe = envdata.getVar("PE", True) or ""
recipe.summary = envdata.getVar("SUMMARY", True)
recipe.description = envdata.getVar("DESCRIPTION", True)
recipe.section = envdata.getVar("SECTION", True)
--
2.15.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH] Track PE and PR for recipes
This change is to report PE (epoch) and PR (release) values for recipes from
the bitbake cooker. These values will be reflected in the Rest API and will not
be exposed on the UI. The aim of this change is to enrich metadata availability
to consumers of the feed.
`
Signed-off-by: Pranay Mankad
---
.../migrations/0042_recipe_property_addition.py | 20
layerindex/models.py | 2 ++
layerindex/update_layer.py | 2 ++
3 files changed, 24 insertions(+)
create mode 100644 layerindex/migrations/0042_recipe_property_addition.py
diff --git a/layerindex/migrations/0042_recipe_property_addition.py
b/layerindex/migrations/0042_recipe_property_addition.py
new file mode 100644
index 000..5583696
--- /dev/null
+++ b/layerindex/migrations/0042_recipe_property_addition.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.24 on 2019-09-24 21:34
+from __future__ import unicode_literals
+from django.db import migrations, models
+class Migration(migrations.Migration):
+dependencies = [
+('layerindex', '0041_recipe_configopts'),
+]
+operations = [
+migrations.AddField(
+model_name='recipe',
+name='pe',
+field=models.CharField(blank=True, max_length=100),
+),
+migrations.AddField(
+model_name='recipe',
+name='pr',
+field=models.CharField(blank=True, max_length=100),
+),
+]
diff --git a/layerindex/models.py b/layerindex/models.py
index 0ca7c06..332ba39 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -461,6 +461,8 @@ class Recipe(models.Model):
filepath = models.CharField(max_length=255, blank=True)
pn = models.CharField(max_length=100, blank=True)
pv = models.CharField(max_length=100, blank=True)
+pr = models.CharField(max_length=100, blank=True)
+pe = models.CharField(max_length=100, blank=True)
summary = models.CharField(max_length=200, blank=True)
description = models.TextField(blank=True)
section = models.CharField(max_length=100, blank=True)
diff --git a/layerindex/update_layer.py b/layerindex/update_layer.py
index 9dc395f..7131d70 100644
--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py
@@ -108,6 +108,8 @@ def update_recipe_file(tinfoil, data, path, recipe,
layerdir_start, repodir, sto
envdata.setVar('SRCPV', 'X')
recipe.pn = envdata.getVar("PN", True)
recipe.pv = envdata.getVar("PV", True)
+recipe.pr = envdata.getVar("PR", True) or ""
+recipe.pe = envdata.getVar("PE", True) or ""
recipe.summary = envdata.getVar("SUMMARY", True)
recipe.description = envdata.getVar("DESCRIPTION", True)
recipe.section = envdata.getVar("SECTION", True)
--
2.15.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] sumo-2.5 build error with core-image-base ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
Hi scott/stefano,
Please provide your inputs to clear the below issue from yocto- sumo-2.5
branch( Compiling for iMx8) i am struggling since 2 weeks.
I am building yocto sumo 2.5 branch with below configuration (bblayers.conf
and local.conf are below the mail. please check ).
Below is the error details while doing Build$* bitbake core-image-base*
ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
/home/e866686/Imx8-Work/imx-yocto-bsp/build/tmp/work/x86_64-linux/e2fsprogs-native/1.43.8-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0 Output:
Applying patch remove.ldconfig.call.patch
can't find file to patch at input line 24
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|From b139e03ac2f72e644e547c7ee9b1514383af4d97 Mon Sep 17 00:00:00 2001
|From: Andrei Dinu
|Date: Wed, 30 Jan 2013 15:22:04 +0200
|Subject: [PATCH] When /etc/ld.so.cache is writeable by user running bitbake
| then it creates invalid cache (in my case libstdc++.so
| cannot be found after building zlib(-native) and I have to
| call touch */libstdc++.so && /sbin/ldconfig to fix it.
|
|So remove ldconfig call from make install-libs
|
|Patch authored by Martin Jansa.
|
|Upstream-Status: Inappropriate [disable feature]
|
|Signed-off-by: Scott Garman
|Signed-off-by: Andrei Dinu
|---
| lib/Makefile.elf-lib |3 ---
| 1 file changed, 3 deletions(-)
|diff --git a/lib/Makefile.elf-lib b/lib/Makefile.elf-lib
|index 78479d3..4a4a5ac 100644
|--- a/lib/Makefile.elf-lib
|+++ b/lib/Makefile.elf-lib
--
No file to patch. Skipping patch.
2 out of 2 hunks ignored
Patch remove.ldconfig.call.patch does not apply (enforce with -f)
ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in:
/home/e866686/Imx8-Work/imx-yocto-bsp/build/tmp/work/x86_64-linux/e2fsprogs-native/1.43.8-r0/temp/log.do_patch.30378
ERROR: Task
(virtual:native:/home/e866686/Imx8-Work/imx-yocto-bsp/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 504 tasks of which 501 didn't need to be
rerun and 1 failed.
configurations:
*build/conf/bblayers.conf*
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
'/../..')}"
BBFILES ?= ""
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-poky \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-multimedia \
\
${BSPDIR}/sources/meta-freescale \
${BSPDIR}/sources/meta-freescale-3rdparty \
${BSPDIR}/sources/meta-freescale-distro \
"
# i.MX Yocto Project Release layers
BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp "
BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-sdk "
BBLAYERS += " ${BSPDIR}/sources/meta-browser "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-gnome "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-networking "
#BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-iot-cloud"
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-python "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-filesystems "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-webserver "
BBLAYERS += " ${BSPDIR}/sources/meta-qt5 "
BBLAYERS += " ${BSPDIR}/sources/meta-selinux "
*build/conf/local.conf*
MACHINE ??= 'imx8mqevk'
DISTRO ?= 'fsl-imx-wayland'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
#DISTRO_FEATURES_remove = " sysvinit"
#DISTRO_FEATURES_append = " systemd"
#VIRTUAL-RUNTIME_init_manager = "systemd"
#DISTRO_FEATURES_BACKFILL_CONSIDERED = ""
#DISTRO_FEATURES_append += " alsa bluez5"
DISTRO_FEATURES_append = "acl xattr pam selinux"
# Srini : Lowered the version to make it compatible with ASTERISK VOIP
package commandline.
PREFERRED_VERSION_libedit = "2012*"
#PREFERRED_VERSION_refpolicy-minimum = "2.20151208"
#PREFERRED_VERSION_refpolicy = "2.20151208"
PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-standard"
IMAGE_INSTALL_append += " libedit"
IMAGE_INSTALL_append += " paho-mqtt-c"
IMAGE_INSTALL_append += " libxml2"
IMAGE_INSTALL_append += " iptables"
IMAGE_INSTALL_append += " lksctp-tools"
#IMAGE_INSTALL_append += " asterisk"
CORE_IMAGE_EXTRA_INSTALL += "python3 python3-pip"
#CORE_IMAGE_EXTRA_INSTALL += "packagegroup-cloud-azure"
IMAGE_INSTALL_append += "packagegroup-core-selinux"
# Light weight web server. Enabled Python
[yocto] meta-selinux warrior support
Hi, I am getting the below error when I am trying to integrate 'meta-selinux' into our yocto solution. This error also happens when I just build 'core-image-selinux' by including the required layers in warrior branch. Can anyone provide a fix for this.. local.conf contains the following lines: - DISTRO_FEATURES_append = " acl xattr pam selinux" PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls" - ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: meson failed ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: Function failed: do_configure (log file is located at /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545) ERROR: Logfile of failure stored in: /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545 Log data follows: | DEBUG: Executing shell function do_configure | NOTE: Executing meson -Ddtrace=false -Dfam=false -Dsystemtap=false -Dselinux=false -Dlibmount=true -Dman=false -Dselinux=disabled -Dinternal_pcre=false -Dinstalled_tests=false... | The Meson build system | Version: 0.49.2 | Source dir: | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2 | .58.3-r0/glib-2.58.3 Build dir: | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2 | .58.3-r0/build | Build type: native build | | meson.build:1:0: ERROR: Value disabled is not boolean (true or false). | | A full log can be found at | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2 | .58.3-r0/build/meson-logs/meson-log.txt | ERROR: meson failed Thanks, Raxesh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a out of tree kernel module on target system
On Fri, Oct 4, 2019 at 11:40 AM Shravan Singh wrote: > > Hello, > > I am trying to build an out of tree service module on a yocto raspberry pi > image(target system). > I am using yocto version warrior > and my machine is Raspberrypi-cm3 > Kernel version is 4.19.58 > > I was able to get the build directory by including > > IMAGE_INSTALL_append = " kernel-modules kernel-dev kernel-devsrc" > After that, I saw a build directory on raspberrypi-image > > Now I am trying to compile my source file with the command > > make ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- > KSRC="/lib/modules/4.19.58/source" -C /lib/modules/$(shell uname -r)/build > M=/home/root/tsDriver modules > > After that I get an error saying asm/bitsperlong.h: no such file or directory > > Am I missing something in my make command? You need to rebuild/regenerate some file on target (they can't be packaged). So have you gone to /usr/src/kernel and done a "make scripts prepare" ? Bruce > > > Regards, > Shravan Singh > (239) 243-0838 > > Blue Sparq, Inc. > 928 NE 24th Lane unit 4 and 5. > Cape Coral, FL 33993 > > IMPORTANT: The contents of this email and any attachments are confidential. > They are intended for the named recipient(s) only. If you have received this > email by mistake, please notify the sender immediately and do not disclose > the contents to anyone or make copies thereof. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] using BBMULTICONFIG to create a 32-bit rootfs, kernel, u-boot that also includes a 64-bit kernel, u-boot for NXP i.mx6/i.mx8
Hello, We're working on a Linux distro for two systems where one is based on NXP i.mx6(32-bit,armv7) and the other i.mx8(64-bit,armv8). I have two machine types defined in Yocto so individually I can build either one however our goal is to create a single distro that can run on both processors. So the idea is to use BBMULTICONFIG( https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBMULTICONFIG ) to build two separate images, 1) a 32-bit distro for an i.mx6 2) a 64-bit distro for an i.mx8 and then finally, take the 32-bit distro and add the 64-bit kernel+modules and u-boot. --- |--| || 32-bit rootfs|| |--| |- - | || 32-bit kernel | | 64-bit kernel || |- - | |- - | || 32-bit u-boot | | 64-bit u-boot || |- - | --- i.mx6solo i.mx8m mini We've already tried our existing 32-bit rootfs + 64-bit kernel/u-boot on the i.mx8 and the system runs. So in theory, it should just be a matter of getting yocto to assemble all the pieces together. I don't have much experience with BBMULTICONFIG so any ideas or comments on how to proceed would be appreciated. Thank you, Davis -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using BBMULTICONFIG to create a 32-bit rootfs, kernel, u-boot that also includes a 64-bit kernel, u-boot for NXP i.mx6/i.mx8
On Fri, Oct 4, 2019, 7:04 PM Davis Roman wrote: > Hello, > > We're working on a Linux distro for two systems where one is based on > NXP i.mx6(32-bit,armv7) and the other i.mx8(64-bit,armv8). > > I have two machine types defined in Yocto so individually I can build > either one however our goal is to create a single distro that can run on > both processors. > > So the idea is to use BBMULTICONFIG( > https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBMULTICONFIG > ) > to build two separate images, > > 1) a 32-bit distro for an i.mx6 > 2) a 64-bit distro for an i.mx8 > > and then finally, take the 32-bit distro and add the 64-bit kernel+modules > and u-boot. > > --- > |--| > || 32-bit rootfs|| > |--| > |- - | > || 32-bit kernel | | 64-bit kernel || > |- - | > |- - | > || 32-bit u-boot | | 64-bit u-boot || > |- - | > --- >i.mx6solo i.mx8m mini > > We've already tried our existing 32-bit rootfs + 64-bit kernel/u-boot on > the i.mx8 and the system runs. > So in theory, it should just be a matter of getting yocto to assemble all > the pieces together. > > I don't have much experience with BBMULTICONFIG so any ideas or comments > on how to proceed would be appreciated. > You are on the right track. Create two multiconfig files one for each machine, then user mcdepends ( https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#dev-enabling-multiple-configuration-build-dependencies) to pull the 64 bit kernel, etc. into the 32 bit image. BBMULTICONFIG is used in local.conf to select which multiconfigs you want to enable. In your case it would have to list both of the ones that you define. > Thank you, > > Davis > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
