How to remove a package from a build

How to remove a package from a build

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

We've our own non-yocto openssl that we want to use.  At the moment, we're using "sato" image, rather than "minimal" and includes its openssl that is out-of-date.  What is the best way to exclude it from our image (and from sysroots)?


We have thought about two ideas -


  1.  Use smaller image like core-image-base, or core-image-full-cmdline (but not -minimal that may remove too much functionality).
  2.  Use INSTALL_IMAGE_remove += " openssl"


Would either one work?  Also, how do I follow the .bb files etc (e.g. starting from the one for sato) to trace down which sub-package includes openssl?


Thanks,

Raymond

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Any Linux/Yocto Image Installer (for target system)

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Is there any installer that I could download along with the .hddimg (or .iso) image to the RAM, invoke the installer, so we could have a bootable image installed on a SSD?


History:

I can already create USB live image with dd and .hddimg.  I could also dd the .hddimg onto SSD and make it bootable.  The problem is that I need multiple partitions on my 250MB SSD, some reserved for other purposes.


I find that when booting up with USB running SysLinux, I could install GRUB, vmlinuz, along with boot.img and core.img under /boot directory, and the rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I could resize the largest partition after installation to do what I want.


Is there a way to do this manually, possibly with a utility or a shell script?


Thanks,

Raymond

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]

Re: Any Linux/Yocto Image Installer (for target system)

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

I tried poky/scripts/contrib/mkefidisk.sh. It showed promised as 3 primary partitions are created on my SSD instead of just 1 when I used dd to write .hddimg. However, I ran into a number of failures when I ran this script:


  1.  mktemp fails, as the .sh uses 3 "X" instead of 6 "X" as temporary directory suffix.
  2.  Failures that look like this:  udevd[1140]: inotify_add_watch(6, /dev/sda1, 10) failed: No such file or directory".


My SSD is mounted as /dev/sda, while at the time I've a USB as boot device to boot the system up.  When I activate the SSD image, I have this USB device removed first, so SSD should come up as /dev/sda.  Yet, boot fails, with a blank screen.


Any idea what might have gone wrong?


________________________________
From: Raymond Yeung <rksyeung@hotmail.com>
Sent: Friday, July 6, 2018 2:52 PM
To: yocto@yoctoproject.org
Subject: Any Linux/Yocto Image Installer (for target system)


Is there any installer that I could download along with the .hddimg (or .iso) image to the RAM, invoke the installer, so we could have a bootable image installed on a SSD?


History:

I can already create USB live image with dd and .hddimg.  I could also dd the .hddimg onto SSD and make it bootable.  The problem is that I need multiple partitions on my 250MB SSD, some reserved for other purposes.


I find that when booting up with USB running SysLinux, I could install GRUB, vmlinuz, along with boot.img and core.img under /boot directory, and the rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I could resize the largest partition after installation to do what I want.


Is there a way to do this manually, possibly with a utility or a shell script?


Thanks,

Raymond

[-- Attachment #2: Type: text/html, Size: 3918 bytes --]

Re: Any Linux/Yocto Image Installer (for target system)

[Burton, Ross]

The easiest thing would be to edit the installer script that goes into
the hddimg to create your extra partitions and whatever else you want
done.

Ross

On 6 July 2018 at 22:52, Raymond Yeung <rksyeung@hotmail.com> wrote:
> Is there any installer that I could download along with the .hddimg (or
> .iso) image to the RAM, invoke the installer, so we could have a bootable
> image installed on a SSD?
>
>
> History:
>
> I can already create USB live image with dd and .hddimg.  I could also dd
> the .hddimg onto SSD and make it bootable.  The problem is that I need
> multiple partitions on my 250MB SSD, some reserved for other purposes.
>
>
> I find that when booting up with USB running SysLinux, I could install GRUB,
> vmlinuz, along with boot.img and core.img under /boot directory, and the
> rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I
> could resize the largest partition after installation to do what I want.
>
>
> Is there a way to do this manually, possibly with a utility or a shell
> script?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Any Linux/Yocto Image Installer (for target system)

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

This brings up the next logical question - where is the installer?  I'd already done a grep and looked into the volume of output.  You could ask why don't I read the code.  Yes, only if I know what I'm reading is the "correct" file/code.  Otherwise, I could be spending a lot of time reading a lot of unrelated codes.


If I did "dd" of .hddimg to SSD, there's only 1 partition.  If I could locate where the logic is that generates this .hddimg file, perhaps I could figure out how it creates its single partition, and perhaps add one or more partitions to it as well.


________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: Saturday, July 7, 2018 3:39 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Any Linux/Yocto Image Installer (for target system)

The easiest thing would be to edit the installer script that goes into
the hddimg to create your extra partitions and whatever else you want
done.

Ross

On 6 July 2018 at 22:52, Raymond Yeung <rksyeung@hotmail.com> wrote:
> Is there any installer that I could download along with the .hddimg (or
> .iso) image to the RAM, invoke the installer, so we could have a bootable
> image installed on a SSD?
>
>
> History:
>
> I can already create USB live image with dd and .hddimg.  I could also dd
> the .hddimg onto SSD and make it bootable.  The problem is that I need
> multiple partitions on my 250MB SSD, some reserved for other purposes.
>
>
> I find that when booting up with USB running SysLinux, I could install GRUB,
> vmlinuz, along with boot.img and core.img under /boot directory, and the
> rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I
> could resize the largest partition after installation to do what I want.
>
>
> Is there a way to do this manually, possibly with a utility or a shell
> script?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. Subscribe before posting to bypass moderation.



>

[-- Attachment #2: Type: text/html, Size: 5627 bytes --]

Re: Any Linux/Yocto Image Installer (for target system)

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

The relevant recipes are in meta/recipes-core/initrdscripts/.

Ross

On 9 July 2018 at 04:10, Raymond Yeung <rksyeung@hotmail.com> wrote:

> This brings up the next logical question - where is the installer?  I'd
> already done a grep and looked into the volume of output.  You could ask
> why don't I read the code.  Yes, only if I know what I'm reading is the
> "correct" file/code.  Otherwise, I could be spending a lot of time reading
> a lot of unrelated codes.
>
>
> If I did "dd" of .hddimg to SSD, there's only 1 partition.  If I could
> locate where the logic is that generates this .hddimg file, perhaps I could
> figure out how it creates its single partition, and perhaps add one or more
> partitions to it as well.
>
>
> ------------------------------
> *From:* Burton, Ross <ross.burton@intel.com>
> *Sent:* Saturday, July 7, 2018 3:39 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Any Linux/Yocto Image Installer (for target system)
>
> The easiest thing would be to edit the installer script that goes into
> the hddimg to create your extra partitions and whatever else you want
> done.
>
> Ross
>
> On 6 July 2018 at 22:52, Raymond Yeung <rksyeung@hotmail.com> wrote:
> > Is there any installer that I could download along with the .hddimg (or
> > .iso) image to the RAM, invoke the installer, so we could have a bootable
> > image installed on a SSD?
> >
> >
> > History:
> >
> > I can already create USB live image with dd and .hddimg.  I could also dd
> > the .hddimg onto SSD and make it bootable.  The problem is that I need
> > multiple partitions on my 250MB SSD, some reserved for other purposes.
> >
> >
> > I find that when booting up with USB running SysLinux, I could install
> GRUB,
> > vmlinuz, along with boot.img and core.img under /boot directory, and the
> > rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe
> I
> > could resize the largest partition after installation to do what I want.
> >
> >
> > Is there a way to do this manually, possibly with a utility or a shell
> > script?
> >
> >
> > Thanks,
> >
> > Raymond
> >
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> yocto Info Page <https://lists.yoctoproject.org/listinfo/yocto>
> lists.yoctoproject.org
> Discussion of all things about the Yocto Project. Read our Community
> Guidelines or learn more about how to participate in other community
> discussions. Subscribe before posting to bypass moderation.
>
>
> >
>

[-- Attachment #2: Type: text/html, Size: 6333 bytes --]

Re: Any Linux/Yocto Image Installer (for target system)

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]

Thanks Ross.  I found init-install.sh that I could relate to run-time installation offered at BOOT time.  And I'd used it to install image on SSD from USB drive.


Would you or anyone know where the script that formats/generates .hddimg?  I'd like to see if we could customize the layout of this image to multiple partitions.  The reason I'm thinking this way is that our real H/W (vs. the evaluation platform I've been using) doesn't support USB port, thus no run-time installer.


________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: Monday, July 9, 2018 2:02 AM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Any Linux/Yocto Image Installer (for target system)

The relevant recipes are in meta/recipes-core/initrdscripts/.

Ross

On 9 July 2018 at 04:10, Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>> wrote:

This brings up the next logical question - where is the installer?  I'd already done a grep and looked into the volume of output.  You could ask why don't I read the code.  Yes, only if I know what I'm reading is the "correct" file/code.  Otherwise, I could be spending a lot of time reading a lot of unrelated codes.


If I did "dd" of .hddimg to SSD, there's only 1 partition.  If I could locate where the logic is that generates this .hddimg file, perhaps I could figure out how it creates its single partition, and perhaps add one or more partitions to it as well.


________________________________
From: Burton, Ross <ross.burton@intel.com<mailto:ross.burton@intel.com>>
Sent: Saturday, July 7, 2018 3:39 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] Any Linux/Yocto Image Installer (for target system)

The easiest thing would be to edit the installer script that goes into
the hddimg to create your extra partitions and whatever else you want
done.

Ross

On 6 July 2018 at 22:52, Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>> wrote:
> Is there any installer that I could download along with the .hddimg (or
> .iso) image to the RAM, invoke the installer, so we could have a bootable
> image installed on a SSD?
>
>
> History:
>
> I can already create USB live image with dd and .hddimg.  I could also dd
> the .hddimg onto SSD and make it bootable.  The problem is that I need
> multiple partitions on my 250MB SSD, some reserved for other purposes.
>
>
> I find that when booting up with USB running SysLinux, I could install GRUB,
> vmlinuz, along with boot.img and core.img under /boot directory, and the
> rootFs under root (i.e. '/') directory.  That's 4 partitions.  I believe I
> could resize the largest partition after installation to do what I want.
>
>
> Is there a way to do this manually, possibly with a utility or a shell
> script?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org<http://lists.yoctoproject.org>
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. Subscribe before posting to bypass moderation.



>


[-- Attachment #2: Type: text/html, Size: 8378 bytes --]

Re: Any Linux/Yocto Image Installer (for target system)

[Hongxu Jia]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On 2018年07月07日 05:52, Raymond Yeung wrote:
>
> Is there any installer that I could download along with the .hddimg 
> (or .iso) image to the RAM, invoke the installer, so we could have a 
> bootable image installed on a SSD?
>
>

Sorry for replying late

There is a target installer meta-anaconda in yocto, which is
derived from fedora's installer (anaconda)

Here is the README:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-anaconda/tree/README

//Hongxu


> History:
>
> I can already create USB live image with dd and .hddimg.  I could also 
> dd the .hddimg onto SSD and make it bootable.  The problem is that I 
> need multiple partitions on my 250MB SSD, some reserved for other 
> purposes.
>
>
> I find that when booting up with USB running SysLinux, I could install 
> GRUB, vmlinuz, along with boot.img and core.img under /boot directory, 
> and the rootFs under root (i.e. '/') directory.  That's 4 partitions. 
>  I believe I could resize the largest partition after installation to 
> do what I want.
>
>
> Is there a way to do this manually, possibly with a utility or a shell 
> script?
>
>
> Thanks,
>
> Raymond
>
>
>


[-- Attachment #2: Type: text/html, Size: 3525 bytes --]

How to remove openssl from sysroots

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

I've changed the subject heading to make it more specific to our problem.  Hopefully this generates some responses.


It has been blocking us for close to one week now.  We want to use our 3rd party vendor openssl, not the one that comes with the source.  Apparently, even with "minimal" instead of "base" or "sato" cannot exclude it.


Any idea [e.g. how do we systematically find out how it's included now, and possibly what other packages/recipes we may also need to remove due to dependency]?


Thanks,

Raymond


________________________________
From: Raymond Yeung <rksyeung@hotmail.com>
Sent: Monday, July 2, 2018 11:05 PM
To: yocto@yoctoproject.org
Subject: How to remove a package from a build


We've our own non-yocto openssl that we want to use.  At the moment, we're using "sato" image, rather than "minimal" and includes its openssl that is out-of-date.  What is the best way to exclude it from our image (and from sysroots)?


We have thought about two ideas -


  1.  Use smaller image like core-image-base, or core-image-full-cmdline (but not -minimal that may remove too much functionality).
  2.  Use INSTALL_IMAGE_remove += " openssl"


Would either one work?  Also, how do I follow the .bb files etc (e.g. starting from the one for sato) to trace down which sub-package includes openssl?


Thanks,

Raymond

[-- Attachment #2: Type: text/html, Size: 3222 bytes --]

Re: How to remove openssl from sysroots

[Burton, Ross]

Presumably you've a recipe for the vendor openssl.  If it has the same
name but is a different version then just set PREFERRED_VERSION.  If
it has a different name too, it should PROVIDE openssl and you can
just set PREFERRED_PROVIDER.

If it doesn't do either of those things, then it is broken.

Ross

On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com> wrote:
> I've changed the subject heading to make it more specific to our problem.
> Hopefully this generates some responses.
>
>
> It has been blocking us for close to one week now.  We want to use our 3rd
> party vendor openssl, not the one that comes with the source.  Apparently,
> even with "minimal" instead of "base" or "sato" cannot exclude it.
>
>
> Any idea [e.g. how do we systematically find out how it's included now, and
> possibly what other packages/recipes we may also need to remove due to
> dependency]?
>
>
> Thanks,
>
> Raymond
>
>
>
> ________________________________
> From: Raymond Yeung <rksyeung@hotmail.com>
> Sent: Monday, July 2, 2018 11:05 PM
> To: yocto@yoctoproject.org
> Subject: How to remove a package from a build
>
>
> We've our own non-yocto openssl that we want to use.  At the moment, we're
> using "sato" image, rather than "minimal" and includes its openssl that is
> out-of-date.  What is the best way to exclude it from our image (and from
> sysroots)?
>
>
> We have thought about two ideas -
>
>
> Use smaller image like core-image-base, or core-image-full-cmdline (but not
> -minimal that may remove too much functionality).
> Use INSTALL_IMAGE_remove += " openssl"
>
>
> Would either one work?  Also, how do I follow the .bb files etc (e.g.
> starting from the one for sato) to trace down which sub-package includes
> openssl?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: How to remove openssl from sysroots

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

We have a shell script that builds openssl.  It uses the native makefiles from the open source project.  There's no  recipe.  I suppose we define a recipe for this out-of-tree sources.


Still, if we could yank out embedded openssl easily, that would be the best.


Raymond


________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: Saturday, July 7, 2018 3:41 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to remove openssl from sysroots

Presumably you've a recipe for the vendor openssl.  If it has the same
name but is a different version then just set PREFERRED_VERSION.  If
it has a different name too, it should PROVIDE openssl and you can
just set PREFERRED_PROVIDER.

If it doesn't do either of those things, then it is broken.

Ross

On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com> wrote:
> I've changed the subject heading to make it more specific to our problem.
> Hopefully this generates some responses.
>
>
> It has been blocking us for close to one week now.  We want to use our 3rd
> party vendor openssl, not the one that comes with the source.  Apparently,
> even with "minimal" instead of "base" or "sato" cannot exclude it.
>
>
> Any idea [e.g. how do we systematically find out how it's included now, and
> possibly what other packages/recipes we may also need to remove due to
> dependency]?
>
>
> Thanks,
>
> Raymond
>
>
>
> ________________________________
> From: Raymond Yeung <rksyeung@hotmail.com>
> Sent: Monday, July 2, 2018 11:05 PM
> To: yocto@yoctoproject.org
> Subject: How to remove a package from a build
>
>
> We've our own non-yocto openssl that we want to use.  At the moment, we're
> using "sato" image, rather than "minimal" and includes its openssl that is
> out-of-date.  What is the best way to exclude it from our image (and from
> sysroots)?
>
>
> We have thought about two ideas -
>
>
> Use smaller image like core-image-base, or core-image-full-cmdline (but not
> -minimal that may remove too much functionality).
> Use INSTALL_IMAGE_remove += " openssl"
>
>
> Would either one work?  Also, how do I follow the .bb files etc (e.g.
> starting from the one for sato) to trace down which sub-package includes
> openssl?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. Subscribe before posting to bypass moderation.



>

[-- Attachment #2: Type: text/html, Size: 6374 bytes --]

Re: How to remove openssl from sysroots

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]

I strongly recommend you just write a recipe that builds openssl as you
wish, instead of building it out of the build system and somehow getting it
into the images.  The problem is that how do you intend to build software
against openssl if it can't link to the one in oe-core (as you don't want
it) or your custom one (because it doesn't exist yet).

The workaround - which is horrible - would be to use a rootfs postprocess
hook to forcibly remove the openssl packages from the rootfs, and then drop
in your own files.

Ross

On 8 July 2018 at 07:14, Raymond Yeung <rksyeung@hotmail.com> wrote:

> We have a shell script that builds openssl.  It uses the native makefiles
> from the open source project.  There's no  recipe.  I suppose we define a
> recipe for this out-of-tree sources.
>
>
> Still, if we could yank out embedded openssl easily, that would be the
> best.
>
>
> Raymond
>
>
> ------------------------------
> *From:* Burton, Ross <ross.burton@intel.com>
> *Sent:* Saturday, July 7, 2018 3:41 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] How to remove openssl from sysroots
>
> Presumably you've a recipe for the vendor openssl.  If it has the same
> name but is a different version then just set PREFERRED_VERSION.  If
> it has a different name too, it should PROVIDE openssl and you can
> just set PREFERRED_PROVIDER.
>
> If it doesn't do either of those things, then it is broken.
>
> Ross
>
> On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com> wrote:
> > I've changed the subject heading to make it more specific to our problem.
> > Hopefully this generates some responses.
> >
> >
> > It has been blocking us for close to one week now.  We want to use our
> 3rd
> > party vendor openssl, not the one that comes with the source.
> Apparently,
> > even with "minimal" instead of "base" or "sato" cannot exclude it.
> >
> >
> > Any idea [e.g. how do we systematically find out how it's included now,
> and
> > possibly what other packages/recipes we may also need to remove due to
> > dependency]?
> >
> >
> > Thanks,
> >
> > Raymond
> >
> >
> >
> > ________________________________
> > From: Raymond Yeung <rksyeung@hotmail.com>
> > Sent: Monday, July 2, 2018 11:05 PM
> > To: yocto@yoctoproject.org
> > Subject: How to remove a package from a build
> >
> >
> > We've our own non-yocto openssl that we want to use.  At the moment,
> we're
> > using "sato" image, rather than "minimal" and includes its openssl that
> is
> > out-of-date.  What is the best way to exclude it from our image (and from
> > sysroots)?
> >
> >
> > We have thought about two ideas -
> >
> >
> > Use smaller image like core-image-base, or core-image-full-cmdline (but
> not
> > -minimal that may remove too much functionality).
> > Use INSTALL_IMAGE_remove += " openssl"
> >
> >
> > Would either one work?  Also, how do I follow the .bb files etc (e.g.
> > starting from the one for sato) to trace down which sub-package includes
> > openssl?
> >
> >
> > Thanks,
> >
> > Raymond
> >
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> yocto Info Page <https://lists.yoctoproject.org/listinfo/yocto>
> lists.yoctoproject.org
> Discussion of all things about the Yocto Project. Read our Community
> Guidelines or learn more about how to participate in other community
> discussions. Subscribe before posting to bypass moderation.
>
>
> >
>

[-- Attachment #2: Type: text/html, Size: 7661 bytes --]

Re: How to remove openssl from sysroots

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 5374 bytes --]


+ yocto mailing list.

________________________________
From: Raymond Yeung <rksyeung@hotmail.com>
Sent: Sunday, July 8, 2018 5:31 PM
To: Burton, Ross
Subject: Re: [yocto] How to remove openssl from sysroots


We're not going to integrate everything into one homogeneous package.  Poky and BSP would be together.  Then, we've application codes that we'd build in the same old way with SCONs the way we do before.  The two parts would link together.


And we do have a number of 3rd party vendor packages beside openssl.  Currently, the issue with openssl is that, we run into build issue with the version we got in 2016 release.  See this:




In file included from /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/evp.h:66:0,

                 from src/infra/utils/obf/cv_obfuscate.c:20:

/volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/opensslconf.h:41:36: fatal error: openssl/opensslconf-32.h: No such file or directory

We plan to use 64-bit kernel, and 32-bit applications.  Perhaps that explains the issue above.  We don't want to spend a lot of effort doing porting simply because we adopt Yocto.  So ideally, if we could remove what's in Yocto, we could integrate our apps with our own openssl; no changes, including upgrade, would be needed.  We'd upgrade when we're ready.

Another question from my team is why the "minimal" package includes connectivity, which includes openssl?

Raymond

________________________________
From: Burton, Ross <ross.burton@intel.com>
Sent: Sunday, July 8, 2018 1:06 AM
To: Raymond Yeung
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] How to remove openssl from sysroots

I strongly recommend you just write a recipe that builds openssl as you wish, instead of building it out of the build system and somehow getting it into the images.  The problem is that how do you intend to build software against openssl if it can't link to the one in oe-core (as you don't want it) or your custom one (because it doesn't exist yet).

The workaround - which is horrible - would be to use a rootfs postprocess hook to forcibly remove the openssl packages from the rootfs, and then drop in your own files.

Ross

On 8 July 2018 at 07:14, Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>> wrote:

We have a shell script that builds openssl.  It uses the native makefiles from the open source project.  There's no  recipe.  I suppose we define a recipe for this out-of-tree sources.


Still, if we could yank out embedded openssl easily, that would be the best.


Raymond


________________________________
From: Burton, Ross <ross.burton@intel.com<mailto:ross.burton@intel.com>>
Sent: Saturday, July 7, 2018 3:41 PM
To: Raymond Yeung
Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] How to remove openssl from sysroots

Presumably you've a recipe for the vendor openssl.  If it has the same
name but is a different version then just set PREFERRED_VERSION.  If
it has a different name too, it should PROVIDE openssl and you can
just set PREFERRED_PROVIDER.

If it doesn't do either of those things, then it is broken.

Ross

On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>> wrote:
> I've changed the subject heading to make it more specific to our problem.
> Hopefully this generates some responses.
>
>
> It has been blocking us for close to one week now.  We want to use our 3rd
> party vendor openssl, not the one that comes with the source.  Apparently,
> even with "minimal" instead of "base" or "sato" cannot exclude it.
>
>
> Any idea [e.g. how do we systematically find out how it's included now, and
> possibly what other packages/recipes we may also need to remove due to
> dependency]?
>
>
> Thanks,
>
> Raymond
>
>
>
> ________________________________
> From: Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>>
> Sent: Monday, July 2, 2018 11:05 PM
> To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> Subject: How to remove a package from a build
>
>
> We've our own non-yocto openssl that we want to use.  At the moment, we're
> using "sato" image, rather than "minimal" and includes its openssl that is
> out-of-date.  What is the best way to exclude it from our image (and from
> sysroots)?
>
>
> We have thought about two ideas -
>
>
> Use smaller image like core-image-base, or core-image-full-cmdline (but not
> -minimal that may remove too much functionality).
> Use INSTALL_IMAGE_remove += " openssl"
>
>
> Would either one work?  Also, how do I follow the .bb files etc (e.g.
> starting from the one for sato) to trace down which sub-package includes
> openssl?
>
>
> Thanks,
>
> Raymond
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org<http://lists.yoctoproject.org>
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. Subscribe before posting to bypass moderation.



>


[-- Attachment #2: Type: text/html, Size: 14375 bytes --]

Re: How to remove openssl from sysroots

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 6232 bytes --]

Just fix the build issue. Look into how opensslconf.h gets created and
where the -32 suffix comes from and why the included file is absent.

Seriously - that is less effort than trying to make Yocto do what it really
was not designed for, and certainly takes less than one week to resolve.

Also, you do not have to use core-image-minimal or -sato, or any of the
standard images, if they pull in things that you do not want. Write your
own image recipe, and specify there precisely what you want.

Alex

2018-07-09 2:32 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com>:

>
> + yocto mailing list.
>
> ------------------------------
> *From:* Raymond Yeung <rksyeung@hotmail.com>
> *Sent:* Sunday, July 8, 2018 5:31 PM
> *To:* Burton, Ross
> *Subject:* Re: [yocto] How to remove openssl from sysroots
>
>
> We're not going to integrate everything into one homogeneous package.
> Poky and BSP would be together.  Then, we've application codes that we'd
> build in the same old way with SCONs the way we do before.  The two parts
> would link together.
>
>
> And we do have a number of 3rd party vendor packages beside openssl.
> Currently, the issue with openssl is that, we run into build issue with the
> version we got in 2016 release.  See this:
>
>
>
>
> In file included from /volume/tools/x86_64_linux.
> x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/evp.h:66:0,
>
>                  from src/infra/utils/obf/cv_obfuscate.c:20:
>
> /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-
> 64-poky-linux/usr/include/openssl/opensslconf.h:41:36: fatal error:
> openssl/opensslconf-32.h: No such file or directory
>
> We plan to use 64-bit kernel, and 32-bit applications.  Perhaps that
> explains the issue above.  We don't want to spend a lot of effort doing
> porting simply because we adopt Yocto.  So ideally, if we could remove
> what's in Yocto, we could integrate our apps with our own openssl; no
> changes, including upgrade, would be needed.  We'd upgrade when we're
> ready.
>
> Another question from my team is why the "minimal" package includes
> connectivity, which includes openssl?
>
> Raymond
>
> ------------------------------
> *From:* Burton, Ross <ross.burton@intel.com>
> *Sent:* Sunday, July 8, 2018 1:06 AM
>
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] How to remove openssl from sysroots
>
> I strongly recommend you just write a recipe that builds openssl as you
> wish, instead of building it out of the build system and somehow getting it
> into the images.  The problem is that how do you intend to build software
> against openssl if it can't link to the one in oe-core (as you don't want
> it) or your custom one (because it doesn't exist yet).
>
> The workaround - which is horrible - would be to use a rootfs postprocess
> hook to forcibly remove the openssl packages from the rootfs, and then drop
> in your own files.
>
> Ross
>
> On 8 July 2018 at 07:14, Raymond Yeung <rksyeung@hotmail.com> wrote:
>
> We have a shell script that builds openssl.  It uses the native makefiles
> from the open source project.  There's no  recipe.  I suppose we define a
> recipe for this out-of-tree sources.
>
>
> Still, if we could yank out embedded openssl easily, that would be the
> best.
>
>
> Raymond
>
>
> ------------------------------
> *From:* Burton, Ross <ross.burton@intel.com>
> *Sent:* Saturday, July 7, 2018 3:41 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] How to remove openssl from sysroots
>
> Presumably you've a recipe for the vendor openssl.  If it has the same
> name but is a different version then just set PREFERRED_VERSION.  If
> it has a different name too, it should PROVIDE openssl and you can
> just set PREFERRED_PROVIDER.
>
> If it doesn't do either of those things, then it is broken.
>
> Ross
>
> On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com> wrote:
> > I've changed the subject heading to make it more specific to our problem.
> > Hopefully this generates some responses.
> >
> >
> > It has been blocking us for close to one week now.  We want to use our
> 3rd
> > party vendor openssl, not the one that comes with the source.
> Apparently,
> > even with "minimal" instead of "base" or "sato" cannot exclude it.
> >
> >
> > Any idea [e.g. how do we systematically find out how it's included now,
> and
> > possibly what other packages/recipes we may also need to remove due to
> > dependency]?
> >
> >
> > Thanks,
> >
> > Raymond
> >
> >
> >
> > ________________________________
> > From: Raymond Yeung <rksyeung@hotmail.com>
> > Sent: Monday, July 2, 2018 11:05 PM
> > To: yocto@yoctoproject.org
> > Subject: How to remove a package from a build
> >
> >
> > We've our own non-yocto openssl that we want to use.  At the moment,
> we're
> > using "sato" image, rather than "minimal" and includes its openssl that
> is
> > out-of-date.  What is the best way to exclude it from our image (and from
> > sysroots)?
> >
> >
> > We have thought about two ideas -
> >
> >
> > Use smaller image like core-image-base, or core-image-full-cmdline (but
> not
> > -minimal that may remove too much functionality).
> > Use INSTALL_IMAGE_remove += " openssl"
> >
> >
> > Would either one work?  Also, how do I follow the .bb files etc (e.g.
> > starting from the one for sato) to trace down which sub-package includes
> > openssl?
> >
> >
> > Thanks,
> >
> > Raymond
> >
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> yocto Info Page <https://lists.yoctoproject.org/listinfo/yocto>
> lists.yoctoproject.org
> Discussion of all things about the Yocto Project. Read our Community
> Guidelines or learn more about how to participate in other community
> discussions. Subscribe before posting to bypass moderation.
>
>
> >
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

[-- Attachment #2: Type: text/html, Size: 15980 bytes --]

Re: How to remove openssl from sysroots

[Raymond Yeung]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

You may have missed one of my emails (still included here below) w.r.t. where the issue came from.  It's coming from application code outside of Yocto that is built as 32-bit apps, while Poky/BSP are built in 64-bit.


________________________________
From: Alexander Kanavin <alex.kanavin@gmail.com>
Sent: Monday, July 9, 2018 7:31 AM
To: Raymond Yeung
Cc: Burton, Ross; yocto@yoctoproject.org
Subject: Re: [yocto] How to remove openssl from sysroots

Just fix the build issue. Look into how opensslconf.h gets created and where the -32 suffix comes from and why the included file is absent.

Seriously - that is less effort than trying to make Yocto do what it really was not designed for, and certainly takes less than one week to resolve.

Also, you do not have to use core-image-minimal or -sato, or any of the standard images, if they pull in things that you do not want. Write your own image recipe, and specify there precisely what you want.

Alex

2018-07-09 2:32 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>>:


+ yocto mailing list.

________________________________
From: Raymond Yeung <rksyeung@hotmail.com<mailto:rksyeung@hotmail.com>>
Sent: Sunday, July 8, 2018 5:31 PM
To: Burton, Ross
Subject: Re: [yocto] How to remove openssl from sysroots


We're not going to integrate everything into one homogeneous package.  Poky and BSP would be together.  Then, we've application codes that we'd build in the same old way with SCONs the way we do before.  The two parts would link together.


And we do have a number of 3rd party vendor packages beside openssl.  Currently, the issue with openssl is that, we run into build issue with the version we got in 2016 release.  See this:




In file included from /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/evp.h:66:0,

                 from src/infra/utils/obf/cv_obfuscate.c:20:

/volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/opensslconf.h:41:36: fatal error: openssl/opensslconf-32.h: No such file or directory

We plan to use 64-bit kernel, and 32-bit applications.  Perhaps that explains the issue above.  We don't want to spend a lot of effort doing porting simply because we adopt Yocto.  So ideally, if we could remove what's in Yocto, we could integrate our apps with our own openssl; no changes, including upgrade, would be needed.  We'd upgrade when we're ready.

Another question from my team is why the "minimal" package includes connectivity, which includes openssl?

Raymond




[-- Attachment #2: Type: text/html, Size: 7650 bytes --]

Re: How to remove openssl from sysroots

[Alexander Kanavin]

The error message you've provided is caused by an openssl header
referring to another header file that doesn't exist. It does not come
from application code, but is due to openssl being incorrectly
configured.

Alex

2018-07-09 20:08 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com>:
> You may have missed one of my emails (still included here below) w.r.t.
> where the issue came from.  It's coming from application code outside of
> Yocto that is built as 32-bit apps, while Poky/BSP are built in 64-bit.
>
>
>
> ________________________________
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Monday, July 9, 2018 7:31 AM
> To: Raymond Yeung
> Cc: Burton, Ross; yocto@yoctoproject.org
> Subject: Re: [yocto] How to remove openssl from sysroots
>
> Just fix the build issue. Look into how opensslconf.h gets created and where
> the -32 suffix comes from and why the included file is absent.
>
> Seriously - that is less effort than trying to make Yocto do what it really
> was not designed for, and certainly takes less than one week to resolve.
>
> Also, you do not have to use core-image-minimal or -sato, or any of the
> standard images, if they pull in things that you do not want. Write your own
> image recipe, and specify there precisely what you want.
>
> Alex
>
> 2018-07-09 2:32 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com>:
>
>
> + yocto mailing list.
>
> ________________________________
> From: Raymond Yeung <rksyeung@hotmail.com>
> Sent: Sunday, July 8, 2018 5:31 PM
> To: Burton, Ross
> Subject: Re: [yocto] How to remove openssl from sysroots
>
>
> We're not going to integrate everything into one homogeneous package.  Poky
> and BSP would be together.  Then, we've application codes that we'd build in
> the same old way with SCONs the way we do before.  The two parts would link
> together.
>
>
> And we do have a number of 3rd party vendor packages beside openssl.
> Currently, the issue with openssl is that, we run into build issue with the
> version we got in 2016 release.  See this:
>
>
>
>
> In file included from
> /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/evp.h:66:0,
>
>                  from src/infra/utils/obf/cv_obfuscate.c:20:
>
> /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/opensslconf.h:41:36:
> fatal error: openssl/opensslconf-32.h: No such file or directory
>
>
> We plan to use 64-bit kernel, and 32-bit applications.  Perhaps that
> explains the issue above.  We don't want to spend a lot of effort doing
> porting simply because we adopt Yocto.  So ideally, if we could remove
> what's in Yocto, we could integrate our apps with our own openssl; no
> changes, including upgrade, would be needed.  We'd upgrade when we're ready.
>
> Another question from my team is why the "minimal" package includes
> connectivity, which includes openssl?
>
> Raymond
>
>
>

Re: How to remove openssl from sysroots

[Alexander Kanavin]

Ah, so are you attempting to build 32 bit apps against a 64 bit
openssl from poky? I'd say you need to either enable multilib and
build the apps against lib32-openssl:

https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image

or make a super-minimal image which doesn't pull in 64 bit openssl.

Alex

2018-07-09 20:16 GMT+02:00 Alexander Kanavin <alex.kanavin@gmail.com>:
> The error message you've provided is caused by an openssl header
> referring to another header file that doesn't exist. It does not come
> from application code, but is due to openssl being incorrectly
> configured.
>
> Alex
>
> 2018-07-09 20:08 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com>:
>> You may have missed one of my emails (still included here below) w.r.t.
>> where the issue came from.  It's coming from application code outside of
>> Yocto that is built as 32-bit apps, while Poky/BSP are built in 64-bit.
>>
>>
>>
>> ________________________________
>> From: Alexander Kanavin <alex.kanavin@gmail.com>
>> Sent: Monday, July 9, 2018 7:31 AM
>> To: Raymond Yeung
>> Cc: Burton, Ross; yocto@yoctoproject.org
>> Subject: Re: [yocto] How to remove openssl from sysroots
>>
>> Just fix the build issue. Look into how opensslconf.h gets created and where
>> the -32 suffix comes from and why the included file is absent.
>>
>> Seriously - that is less effort than trying to make Yocto do what it really
>> was not designed for, and certainly takes less than one week to resolve.
>>
>> Also, you do not have to use core-image-minimal or -sato, or any of the
>> standard images, if they pull in things that you do not want. Write your own
>> image recipe, and specify there precisely what you want.
>>
>> Alex
>>
>> 2018-07-09 2:32 GMT+02:00 Raymond Yeung <rksyeung@hotmail.com>:
>>
>>
>> + yocto mailing list.
>>
>> ________________________________
>> From: Raymond Yeung <rksyeung@hotmail.com>
>> Sent: Sunday, July 8, 2018 5:31 PM
>> To: Burton, Ross
>> Subject: Re: [yocto] How to remove openssl from sysroots
>>
>>
>> We're not going to integrate everything into one homogeneous package.  Poky
>> and BSP would be together.  Then, we've application codes that we'd build in
>> the same old way with SCONs the way we do before.  The two parts would link
>> together.
>>
>>
>> And we do have a number of 3rd party vendor packages beside openssl.
>> Currently, the issue with openssl is that, we run into build issue with the
>> version we got in 2016 release.  See this:
>>
>>
>>
>>
>> In file included from
>> /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/evp.h:66:0,
>>
>>                  from src/infra/utils/obf/cv_obfuscate.c:20:
>>
>> /volume/tools/x86_64_linux.x86_64/2.1.3/sysroots/corei7-64-poky-linux/usr/include/openssl/opensslconf.h:41:36:
>> fatal error: openssl/opensslconf-32.h: No such file or directory
>>
>>
>> We plan to use 64-bit kernel, and 32-bit applications.  Perhaps that
>> explains the issue above.  We don't want to spend a lot of effort doing
>> porting simply because we adopt Yocto.  So ideally, if we could remove
>> what's in Yocto, we could integrate our apps with our own openssl; no
>> changes, including upgrade, would be needed.  We'd upgrade when we're ready.
>>
>> Another question from my team is why the "minimal" package includes
>> connectivity, which includes openssl?
>>
>> Raymond
>>
>>
>>

Re: How to remove openssl from sysroots

[Alexander Kanavin]

If the issue is that openssl is 'out of date', then oe-core already
provides a 1.1 version that can be selected via PREFERRED_VERSION as
well.

What is the specific need for the 3rd party version?

Alex

2018-07-08 0:41 GMT+02:00 Burton, Ross <ross.burton@intel.com>:
> Presumably you've a recipe for the vendor openssl.  If it has the same
> name but is a different version then just set PREFERRED_VERSION.  If
> it has a different name too, it should PROVIDE openssl and you can
> just set PREFERRED_PROVIDER.
>
> If it doesn't do either of those things, then it is broken.
>
> Ross
>
> On 6 July 2018 at 23:06, Raymond Yeung <rksyeung@hotmail.com> wrote:
>> I've changed the subject heading to make it more specific to our problem.
>> Hopefully this generates some responses.
>>
>>
>> It has been blocking us for close to one week now.  We want to use our 3rd
>> party vendor openssl, not the one that comes with the source.  Apparently,
>> even with "minimal" instead of "base" or "sato" cannot exclude it.
>>
>>
>> Any idea [e.g. how do we systematically find out how it's included now, and
>> possibly what other packages/recipes we may also need to remove due to
>> dependency]?
>>
>>
>> Thanks,
>>
>> Raymond
>>
>>
>>
>> ________________________________
>> From: Raymond Yeung <rksyeung@hotmail.com>
>> Sent: Monday, July 2, 2018 11:05 PM
>> To: yocto@yoctoproject.org
>> Subject: How to remove a package from a build
>>
>>
>> We've our own non-yocto openssl that we want to use.  At the moment, we're
>> using "sato" image, rather than "minimal" and includes its openssl that is
>> out-of-date.  What is the best way to exclude it from our image (and from
>> sysroots)?
>>
>>
>> We have thought about two ideas -
>>
>>
>> Use smaller image like core-image-base, or core-image-full-cmdline (but not
>> -minimal that may remove too much functionality).
>> Use INSTALL_IMAGE_remove += " openssl"
>>
>>
>> Would either one work?  Also, how do I follow the .bb files etc (e.g.
>> starting from the one for sato) to trace down which sub-package includes
>> openssl?
>>
>>
>> Thanks,
>>
>> Raymond
>>
>>
>> --
>> _______________________________________________
>> 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: How to remove openssl from sysroots

[Philip Balister]

On 07/06/2018 03:06 PM, Raymond Yeung wrote:
> I've changed the subject heading to make it more specific to our problem.  Hopefully this generates some responses.
> 
> 
> It has been blocking us for close to one week now.  We want to use our 3rd party vendor openssl, not the one that comes with the source.  Apparently, even with "minimal" instead of "base" or "sato" cannot exclude it.
> 
> 
> Any idea [e.g. how do we systematically find out how it's included now, and possibly what other packages/recipes we may also need to remove due to dependency]?

I tend to use the ouput of the buildhistory class when I have these
questions.

Philip

> 
> 
> Thanks,
> 
> Raymond
> 
> 
> ________________________________
> From: Raymond Yeung <rksyeung@hotmail.com>
> Sent: Monday, July 2, 2018 11:05 PM
> To: yocto@yoctoproject.org
> Subject: How to remove a package from a build
> 
> 
> We've our own non-yocto openssl that we want to use.  At the moment, we're using "sato" image, rather than "minimal" and includes its openssl that is out-of-date.  What is the best way to exclude it from our image (and from sysroots)?
> 
> 
> We have thought about two ideas -
> 
> 
>   1.  Use smaller image like core-image-base, or core-image-full-cmdline (but not -minimal that may remove too much functionality).
>   2.  Use INSTALL_IMAGE_remove += " openssl"
> 
> 
> Would either one work?  Also, how do I follow the .bb files etc (e.g. starting from the one for sato) to trace down which sub-package includes openssl?
> 
> 
> Thanks,
> 
> Raymond
> 
> 
> 

Re: How to remove openssl from sysroots

[Andre McCurdy]

On Sun, Jul 8, 2018 at 7:04 PM, Philip Balister <philip@balister.org> wrote:
> On 07/06/2018 03:06 PM, Raymond Yeung wrote:
>> I've changed the subject heading to make it more specific to our problem.  Hopefully this generates some responses.
>>
>> It has been blocking us for close to one week now.  We want to use our 3rd party vendor openssl, not the one that comes with the source.  Apparently, even with "minimal" instead of "base" or "sato" cannot exclude it.
>>
>> Any idea [e.g. how do we systematically find out how it's included now, and possibly what other packages/recipes we may also need to remove due to dependency]?
>
> I tend to use the ouput of the buildhistory class when I have these
> questions.

An alternative quick and dirty approach is to make the recipe
unbuildable. If the recipe is unbuildable but needed by something then
the bitbake error message will give the dependency chain. You can make
a recipe unbuildable for the target by adding the following to the
recipe:

  COMPATIBLE_HOST_class-target = 'null'

Note that there are two openssl recipes in recent oe-core (v1.0.x and
v1.1.x). For this experiment you will need to make BOTH of them
unbuildable.

This seems like a somewhat pointless path to be going down though. If
you remove all packages which depend on openssl from the target rootfs
then you won't need to add in your 3rd party vendor openssl any
more... since nothing is going to use it.