Re: [yocto] coreutils postinstall warning
On Mon, Aug 20, 2018 at 8:16 AM Seth Bollinger wrote:
> Hello All,
>
> We've been seeing the following warning for a while now. Is this expected?
>
> WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> Please place them into pkg_postinst_ontarget_${PN} ().
>
> From what I can see, it's being caused by update-alternatives. Is there a
> workaround for this?
>
I'll answer my own question since it may be of value to someone else.
coreutils, util-linux and busybox all provide overlapping utilities. Most
are covered by update alternatives, some are not. If you have enabled one
of those in busybox, then update alternatives will fail trying to make the
symbolic link. As I understand it (from the warning message) is that
failing the postinst step used to be a way to ask to be executed at target
runtime. The solution is to have only one package provide the conflicting
utility (or add alternatives to all packages that provide the utility).
Here's an example error message:
update-alternatives: Error: not linking
/home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
to /bin/busybox.nosuid since
/home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
exists and is not a link
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Whitelist gdbserver
Thanks! I searched for "whitelist" in the documentation, but it didn't list anything about whitelisting a package even though I knew it was possible. (libidn was being whitelisted.) Also, it turns out I had to whitelist "gdb" not just "gdbserver", because gdbserver is part of the gdb recipe. Thanks again, Jeremy -Original Message- From: Andre McCurdy Sent: Thursday, September 13, 2018 4:51 PM To: Jeremy Overesch Cc: yocto@yoctoproject.org Subject: Re: [yocto] Whitelist gdbserver On Thu, Sep 13, 2018 at 8:42 AM, Jeremy Overesch wrote: > HI all, > > I’m attempting to whitelist gdbserver just for SDK purposes, while keeping > all other GPLv3 code as incompatible (therefore unbuilt). However, > everything I’ve tried still results in gdbserver being removed from my SDK > and therefore failing to build. > > In my local.conf, I have the following line: > > INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 AGPLv3" > > Through the yocto documentation > (https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#license-flag-matching), > it appears that adding the following *should* work, yet it doesn’t: I think you are mixing up "LICENSE" and "LICENSE_FLAGS". The two don't really work together. It's partly explained in: https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-LICENSE_FLAGS See the LICENSE_FLAGS comment which says "This value is independent of LICENSE and is typically used to mark recipes that might require additional licenses in order to be used in a commercial product. For more information, see the "Enabling Commercially Licensed Recipes" section." To whitelist a recipe which is being excluded due to INCOMPATIBLE_LICENSE, use WHITELIST_GPL-3.0. For example for gdbserver, try the following: WHITELIST_GPL-3.0 += "gdbserver" This message (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. If you are not the intended recipient of this message, you are hereby notified that you must delete the message without disseminating, copying or taking any action in reliance upon it. If you have received this message in error, please notify the sender via return e-mail. Thank you. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] coreutils postinstall warning
On Fri, Sep 14, 2018 at 07:38:49AM -0500, Seth Bollinger wrote:
> On Mon, Aug 20, 2018 at 8:16 AM Seth Bollinger wrote:
>
> > Hello All,
> >
> > We've been seeing the following warning for a while now. Is this expected?
> >
> > WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> > scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> > Please place them into pkg_postinst_ontarget_${PN} ().
> >
> > From what I can see, it's being caused by update-alternatives. Is there a
> > workaround for this?
> >
>
> I'll answer my own question since it may be of value to someone else.
>
> coreutils, util-linux and busybox all provide overlapping utilities. Most
> are covered by update alternatives, some are not. If you have enabled one
> of those in busybox, then update alternatives will fail trying to make the
> symbolic link. As I understand it (from the warning message) is that
> failing the postinst step used to be a way to ask to be executed at target
> runtime. The solution is to have only one package provide the conflicting
> utility (or add alternatives to all packages that provide the utility).
Using u-a for all conflicting binaries is the preferred option.
For example there was fix for nice provided by coreutils merged
recently:
http://git.openembedded.org/openembedded-core/commit/?id=57b1b20abca7d6821e99802147b93f4f577cfad0
or setfattr in attr:
http://git.openembedded.org/openembedded-core/commit/?id=d633633f3d83467fe1f946c57e2e75e0e774ec7e
busybox have a lot of available applets and people tend to
enable/disable them in their own defconfigs quite often, removing
something from util-linux or coreutils would break it for people who
disabled the same in busybox defconfig and vice versa, u-a on the other
hand will work reasonably for everybody.
If you have conflict with unshare, just send a patch. I will do the same
with printenv for coreutils which I have in .bbappend for way too long.
Regards,
>
> Here's an example error message:
> update-alternatives: Error: not linking
> /home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
> to /bin/busybox.nosuid since
> /home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
> exists and is not a link
>
> Seth
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
On Fri, Sep 14, 2018 at 1:20 AM, Dudziak Krzysztof wrote: > Thanks for feedback from you. > >> If you use BBCLASSEXTEND (ie "the second method") then that recipe naming >> rule doesn't apply. > Looks like section's 6.83 current structure wouldn't reflect this fact well. > Warning is placed directly below > one-sentence and indented text describing to BBCLASSEXTEND-case Yes, I agree. That part of the documentation could certainly be improved. > krzysiek > > -Original Message- > From: Andre McCurdy [mailto:armccu...@gmail.com] > Sent: Friday, 14. September 2018 01:05 > To: Dudziak Krzysztof > Cc: Burton, Ross ; yocto@yoctoproject.org > Subject: Re: [yocto] inheriting native.bbclass explicitly > > On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof > wrote: >> Current release's reference manual issues in native.bbclass chapter a >> warning: >> "When creating a recipe, you must follow this naming convention: >> native-myrecipe.bb >> Not doing so can lead to subtle problems because code exists that depends on >> the naming convention." > > Looks like a mistake in the documentation. Native only recipes (ie recipes > which use "inherit native" rather than BBCLASSEXTEND) should have "-native" > as a suffix, not "native-" as a prefix. > >> Jethro release manual does not point it out. >> Is this warning really out of relevance for certain past releases e.g. >> Jethro? >> >> Abstracting from question raised above how following two fit all together: >> "When creating a recipe, you must follow this naming convention: >> native-myrecipe.bb" >> and >> " The advantage of the second method is that you do not need to have >> two separate recipes " (2.5.1 Release Reference Manual) > > If you use BBCLASSEXTEND (ie "the second method") then that recipe naming > rule doesn't apply. ie a recipe using BBCLASSEXTEND should not have a > "-native" suffix. > >> krzysiek >> >> -Original Message- >> From: Burton, Ross [mailto:ross.bur...@intel.com] >> Sent: Thursday, 13. September 2018 14:00 >> To: Dudziak Krzysztof >> Cc: yocto@yoctoproject.org >> Subject: Re: [yocto] inheriting native.bbclass explicitly >> >> On 13 September 2018 at 12:39, Dudziak Krzysztof >> wrote: >>> Thanks for hints. >>> I don't want to have this package on target system. >>> You sound like inheriting explicitly had some major drawback of wide scope. >> >> It won't be included in the image unless you add it to the image. >> >> Ross >> >> This message and any attachments are intended solely for the addressees and >> may contain confidential information. Any unauthorized use or disclosure, >> either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable for >> the message if altered, changed or falsified. If you are not the intended >> recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this transmission >> free from viruses, the sender will not be liable for damages caused by a >> transmitted virus. >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis >> ts.yoctoproject.org%2Flistinfo%2Fyocto&data=02%7C01%7CKrzysztof.Du >> dziak%40gemalto.com%7Ced60588df01e4484015c08d619cd5ee6%7C37d0a9db7c464 >> 096bfe31add5b495d6d%7C1%7C0%7C636724767194372674&sdata=8GXUXT5abR3 >> BHWxhzbCf0bbYxYqpU7x6r0ZXbQt7clw%3D&reserved=0 > > This message and any attachments are intended solely for the addressees and > may contain confidential information. Any unauthorized use or disclosure, > either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission free > from viruses, the sender will not be liable for damages caused by a > transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into say and ubuntu image running there? If not, then you'll need VB docs not YP docs. If ubuntu works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into say and ubuntu image running there? If not, then you'll need VB docs not YP docs. If ubuntu works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into an ubuntu image as a test? If not, then you'll need VB docs not YP docs. If ubuntu in VB works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
Thanks for feedback from you. > If you use BBCLASSEXTEND (ie "the second method") then that recipe naming > rule doesn't apply. Looks like section's 6.83 current structure wouldn't reflect this fact well. Warning is placed directly below one-sentence and indented text describing to BBCLASSEXTEND-case krzysiek -Original Message- From: Andre McCurdy [mailto:armccu...@gmail.com] Sent: Friday, 14. September 2018 01:05 To: Dudziak Krzysztof Cc: Burton, Ross ; yocto@yoctoproject.org Subject: Re: [yocto] inheriting native.bbclass explicitly On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof wrote: > Current release's reference manual issues in native.bbclass chapter a warning: > "When creating a recipe, you must follow this naming convention: > native-myrecipe.bb > Not doing so can lead to subtle problems because code exists that depends on > the naming convention." Looks like a mistake in the documentation. Native only recipes (ie recipes which use "inherit native" rather than BBCLASSEXTEND) should have "-native" as a suffix, not "native-" as a prefix. > Jethro release manual does not point it out. > Is this warning really out of relevance for certain past releases e.g. Jethro? > > Abstracting from question raised above how following two fit all together: > "When creating a recipe, you must follow this naming convention: > native-myrecipe.bb" > and > " The advantage of the second method is that you do not need to have > two separate recipes " (2.5.1 Release Reference Manual) If you use BBCLASSEXTEND (ie "the second method") then that recipe naming rule doesn't apply. ie a recipe using BBCLASSEXTEND should not have a "-native" suffix. > krzysiek > > -Original Message- > From: Burton, Ross [mailto:ross.bur...@intel.com] > Sent: Thursday, 13. September 2018 14:00 > To: Dudziak Krzysztof > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] inheriting native.bbclass explicitly > > On 13 September 2018 at 12:39, Dudziak Krzysztof > wrote: >> Thanks for hints. >> I don't want to have this package on target system. >> You sound like inheriting explicitly had some major drawback of wide scope. > > It won't be included in the image unless you add it to the image. > > Ross > > This message and any attachments are intended solely for the addressees and > may contain confidential information. Any unauthorized use or disclosure, > either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission free > from viruses, the sender will not be liable for damages caused by a > transmitted virus. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > ts.yoctoproject.org%2Flistinfo%2Fyocto&data=02%7C01%7CKrzysztof.Du > dziak%40gemalto.com%7Ced60588df01e4484015c08d619cd5ee6%7C37d0a9db7c464 > 096bfe31add5b495d6d%7C1%7C0%7C636724767194372674&sdata=8GXUXT5abR3 > BHWxhzbCf0bbYxYqpU7x6r0ZXbQt7clw%3D&reserved=0 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
