packagegroup-qcom-test-pkg: Add minkipc into image #119

jiaxli-QC · 2025-12-17T06:36:43Z

Add MinkIPC libraries and binaries to the test image to facilitate communication between QTEE (Qualified Trusted Execution Environment) and REE (Rich Execution Environment).

Included components:

minkipc-qteesupplicant

Reference: qualcomm-linux/meta-qcom#1094

lumag · 2025-12-17T12:11:33Z

recipes-products/packagegroups/packagegroup-qcom-test-pkgs.bb


 RDEPENDS:${PN}:append:aarch64 = " \
    fastrpc-tests \
+    minkipc \


Why do we need this package? Just pull the qteesupplicant. Also, it should not be a part of the tests, it is not a test binary.

Currently, there are four .bb files in packagegroups dir. Can I install minkipc in the packagegroup-qcom-utilities.bb file?
Please note that minkipc currently only supports compilation for the aarch64 version

Okey, I will remove the minkipc package and only install the minkipc-qteesupplicant package.

However, the qcom-multimedia-image only installs the packagegroup-qcom-utilities-gpu-utils target.
We're unable to include the minkipc related binaries in the image when running kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml.

Could you please share any suggestions? Thank you.

jiaxli-QC · 2025-12-18T06:30:44Z

Add minkipc-qteesupplicant in packagegroup-qcom-utilities.bb.

lumag · 2025-12-18T11:48:52Z

recipes-products/packagegroups/packagegroup-qcom-utilities.bb

    "
+
+RDEPENDS:${PN}:append:aarch64 = " \
+    minkipc-qteesupplicant \


There is no need to append the var that was just defined. Just fix that vat instead.

Okey, add the minkipc-qteesupplicant into the packagegroup-qcom-test-pkgs

Is this correct?

diff --git a/recipes-products/packagegroups/packagegroup-qcom-utilities.bb b/recipes-products/packagegroups/packagegroup-qcom-utilities.bb index c9c781c..08bf7b9 100644 --- a/recipes-products/packagegroups/packagegroup-qcom-utilities.bb +++ b/recipes-products/packagegroups/packagegroup-qcom-utilities.bb @@ -77,3 +77,7 @@ RDEPENDS:${PN}-support-utils = " \ trace-cmd \ usbutils \ " + +RDEPENDS:${PN}:aarch64 = " \ + minkipc-qteesupplicant \ + "

I am sorry, your previous version (RDEPENDS:${PN}:append:aarch64 in the utils packagegroup) was correct. Add a comment that the package is arm64-only.

jiaxli-QC · 2025-12-19T02:03:08Z

Add the minkipc-qteesupplicant into packagegroup-qcom-test-pkgs

lumag · 2025-12-19T02:53:17Z

Add the minkipc-qteesupplicant into packagegroup-qcom-test-pkgs

It's not a test. Why did you move it back?

jiaxli-QC · 2025-12-19T03:05:27Z

There is no need to append the var that was just defined. Just fix that vat instead.

Add the minkipc-qteesupplicant into packagegroup-qcom-test-pkgs

It's not a test. Why did you move it back?

Sorry, I cannot get your point. How can we fix the var?

Is this correct?

diff --git a/recipes-products/packagegroups/packagegroup-qcom-utilities.bb b/recipes-products/packagegroups/packagegroup-qcom-utilities.bb
index c9c781c..08bf7b9 100644
--- a/recipes-products/packagegroups/packagegroup-qcom-utilities.bb
+++ b/recipes-products/packagegroups/packagegroup-qcom-utilities.bb
@@ -77,3 +77,7 @@ RDEPENDS:${PN}-support-utils = " \
     trace-cmd \
     usbutils \
     "
+
+RDEPENDS:${PN}:aarch64 = " \
+    minkipc-qteesupplicant \
+    "

harshaldev27 · 2025-12-19T07:16:25Z

Hello @lumag , thank you for you time here. I agree that packagegroup-qcom-test-pkg is not the right place to place the minkipc package. However, I am also not sure if packagegroup-qcom-utilities is also the right place.

On QLI 1.x, when we were shipping prebuilt binaries we had a packagegroup-qcom-security so that multiple recipes for security were clubbed under one consolidate packagegroup (I am unable to find the GitHub since it moved). After all, security features aren't utilities exactly. Also, we were including this packagegroup-qcom-security as part of qcom-console-image, because we felt that the security features should be available on even the smallest image. We could re-think this approach is some definitions have changed now. Let me know your thoughts.

lumag · 2025-12-19T07:39:35Z

I'm fine with packagegroup-qcom-security too.

harshaldev27 · 2025-12-19T08:31:53Z

I'm fine with packagegroup-qcom-security too.

Alright @lumag, I am thinking we can introduce a new packagegroup-qcom-security in recipes-products/packagegroups/ and add both minkipc and minkipc-supplicant to it.
Also, can you comment on the other part of my question, is it fine to place the packagegroup in 'qcom-console-image`?

lumag · 2025-12-19T08:33:51Z

I am thinking we can introduce a new packagegroup-qcom-security in recipes-products/packagegroups/ and add both minkipc and minkipc-supplicant to it.

You don't need to add minkipc to it, just the supplicant.

Also, can you comment on the other part of my question, is it fine to place the packagegroup in 'qcom-console-image`?

Yes

jiaxli-QC · 2025-12-20T13:15:15Z

I am thinking we can introduce a new packagegroup-qcom-security in recipes-products/packagegroups/ and add both minkipc and minkipc-supplicant to it.

You don't need to add minkipc to it, just the supplicant.

I think we need to include minkipc, because just adding minkipc-supplicant to the packagegroup-qcom-security bb file doesn't install the libraries that minkipc depends on into the rootfs.
After flashing build, the minkipc libraries that's needed are not present on the device.

jiaxli-QC · 2025-12-20T13:22:20Z

The kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml command works fine.
However, we encountered a compilation issue related to the luajit target in the meta-openembedded layer when running the kas build meta-qcom/ci/qcom-armv7a.yml:meta-qcom/ci/qcom-distro.yml command. This problem is not connected to our minkipc changes, but it may block the PR merge process.

Error Log:

ERROR: Task (/local/mnt2/workspace/jiaxli/upstream/build/../meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_git.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 6478 tasks of which 3426 didn't need to be rerun and 1 failed.
NOTE: Build completion summary:
NOTE:   do_populate_sysroot: 0.0% sstate reuse(0 setscene, 48 scratch)
NOTE:   do_deploy_source_date_epoch: 0.0% sstate reuse(0 setscene, 415 scratch)
NOTE:   do_package_qa: 70.4% sstate reuse(19 setscene, 8 scratch)
NOTE:   do_recipe_qa: 0.0% sstate reuse(0 setscene, 415 scratch)
NOTE:   do_package: 0.0% sstate reuse(0 setscene, 15 scratch)
NOTE:   do_packagedata: 61.1% sstate reuse(22 setscene, 14 scratch)
NOTE:   do_package_write_ipk: 70.4% sstate reuse(19 setscene, 8 scratch)
NOTE:   do_populate_lic: 0.0% sstate reuse(0 setscene, 413 scratch)
NOTE:   do_create_spdx: 51.2% sstate reuse(22 setscene, 21 scratch)
NOTE:   do_create_package_spdx: 60.6% sstate reuse(20 setscene, 13 scratch)
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 4 seconds

Summary: 1 task failed:
  /local/mnt2/workspace/jiaxli/upstream/build/../meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_git.bb:do_compile
    log: /local/mnt2/workspace/jiaxli/upstream/build/tmp/work/cortexa15t2hf-neon-vfpv4-qcom-linux-gnueabi/luajit/2.1/temp/log.do_compile.3947426
Summary: There were 2 ERROR messages, returning a non-zero exit code.
2025-12-20 20:53:06 - ERROR    - Command "/local/mnt2/workspace/jiaxli/upstream/bitbake/bin/bitbake -c build qcom-multimedia-image" failed with error 1

lumag · 2025-12-20T17:12:39Z

I am thinking we can introduce a new packagegroup-qcom-security in recipes-products/packagegroups/ and add both minkipc and minkipc-supplicant to it.

You don't need to add minkipc to it, just the supplicant.

I think we need to include minkipc, because just adding minkipc-supplicant to the packagegroup-qcom-security bb file doesn't install the libraries that minkipc depends on into the rootfs. After flashing build, the minkipc libraries that's needed are not present on the device.

Then qteesupplicant must depend on the minkipc package. BTW: what is the reason for dynamically opening those libraries? Are they used for anything else than QTEE supplicant?

jiaxli-QC · 2025-12-23T02:56:04Z

Then qteesupplicant must depend on the minkipc package. BTW: what is the reason for dynamically opening those libraries? Are they used for anything else than QTEE supplicant?

Yes, the MinkIPC libraries are currently used only by qtee_supplicant. The minkipc libraries cannot be installed into the image unless I add the minkipc package into packagegroup-qcom-security bb file, for example:

RDEPENDS:${PN}:aarch64 = " \
+    minkipc \
    minkipc-qteesupplicant \
    "

harshaldev27 · 2025-12-23T10:10:05Z

I am thinking we can introduce a new packagegroup-qcom-security in recipes-products/packagegroups/ and add both minkipc and minkipc-supplicant to it.

You don't need to add minkipc to it, just the supplicant.

I think we need to include minkipc, because just adding minkipc-supplicant to the packagegroup-qcom-security bb file doesn't install the libraries that minkipc depends on into the rootfs. After flashing build, the minkipc libraries that's needed are not present on the device.

Then qteesupplicant must depend on the minkipc package. BTW: what is the reason for dynamically opening those libraries? Are they used for anything else than QTEE supplicant?

Hi @lumag , no the libraries aren't used by any other daemon apart from QTEE supplicant. However, we have historically had a workflow where each team owns their own listener library (say RPMB) and delivers updates/bug-fixes to the customer independently by recompiling it separately from the QTEE supplicant. We want to continue with that workflow. This enables OTA updates to be provided by the tech owning team without our own involvement. There is a minor performance penalty that we pay for that via dlopen, but we are okay with it.

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

harshaldev27 · 2025-12-19T07:17:13Z

recipes-products/packagegroups/packagegroup-qcom-test-pkgs.bb


 RDEPENDS:${PN}:append:aarch64 = " \
    fastrpc-tests \
+    minkipc-qteesupplicant \


Shouldn't minkipc package also be listed here? Or just listing the subpackage is fine?

This line is now outdated.

harshaldev27 · 2025-12-23T10:14:12Z

recipes-products/images/qcom-multimedia-image.bb

    packagegroup-container \
    packagegroup-qcom-test-pkgs \
    packagegroup-qcom-utilities-gpu-utils \
+    packagegroup-qcom-security \


Do we really need to add it here? I can see we add qcom-console-image.bb on line 1 which already adds packagegroup-qcom-security.

This line is required to enable minkipc on meta-qcom, as the qcom-multimedia-image is currently only included in meta-qcom/ci/qcom-distro.yml.

Yes but I thought the qcom-multimedia-image is a superset of qcom-console-image, with all images in console-image + additional for multimedia. Both are appending the CORE_IMAGE_BASE_INSTALL list. So I was under the assumption that just adding to console image should add it here as well. Is this not the case?

Yes, that's right. The qcom-multimedia-image is a superset of qcom-console-image, and the qcom-console-image target is included on line 1 of the qcom-multimedia-image.bb file.

require qcom-console-image.bb SUMMARY = "Basic Wayland image with Weston" IMAGE_FEATURES += "weston"

I will update it in the next version.

lumag · 2025-12-24T17:38:52Z

Hi @lumag , no the libraries aren't used by any other daemon apart from QTEE supplicant. However, we have historically had a workflow where each team owns their own listener library (say RPMB) and delivers updates/bug-fixes to the customer independently by recompiling it separately from the QTEE supplicant. We want to continue with that workflow. This enables OTA updates to be provided by the tech owning team without our own involvement. There is a minor performance penalty that we pay for that via dlopen, but we are okay with it.

How does that differ if qteesupplicant is dynamically linked to the libraries instead of using dlopen?

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

harshaldev27 · 2025-12-26T14:21:31Z

Hi @lumag , no the libraries aren't used by any other daemon apart from QTEE supplicant. However, we have historically had a workflow where each team owns their own listener library (say RPMB) and delivers updates/bug-fixes to the customer independently by recompiling it separately from the QTEE supplicant. We want to continue with that workflow. This enables OTA updates to be provided by the tech owning team without our own involvement. There is a minor performance penalty that we pay for that via dlopen, but we are okay with it.

How does that differ if qteesupplicant is dynamically linked to the libraries instead of using dlopen?

I am not sure if I have a real answer to this one. It seems this choice was made with our downstream implementation long before I was around, (probably a decade ago or so) and since the same code has now been open-sourced, it continues to exist. I will try to ask around if someone has a concrete reason, but I am not aware of any at least.

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

Thanks my query was, where should this RDEPENDS go? In packagegroup-qcom-security?

jiaxli-QC · 2025-12-30T13:46:22Z

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

Hi @lumag , do you recommend adding the RDEPENDS to the minkipc_git.bb file? Is it correct approach for the patch?

diff --git a/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb b/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
index 8b29c87..8c7e222 100644
--- a/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
+++ b/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
@@ -33,6 +33,7 @@ FILES:${PN}-qteesupplicant = "${bindir}/qtee_supplicant \
                               ${nonarch_libdir}/udev/rules.d/99-qcomtee-udev.rules \
 "

+RDEPENDS:${PN}-qteesupplicant += " ${PN}"
 # Currently, this recipe only builds and installs for ARMv8 (aarch64) machine.
 COMPATIBLE_MACHINE = "^$"
 COMPATIBLE_MACHINE:aarch64 = "(.*)"

harshaldev27 · 2026-01-02T06:55:47Z

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

Hi @lumag , do you recommend adding the RDEPENDS to the minkipc_git.bb file? Is it correct approach for the patch?
diff --git a/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb b/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
index 8b29c87..8c7e222 100644
--- a/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
+++ b/dynamic-layers/openembedded-layer/recipes-security/minkipc/minkipc_git.bb
@@ -33,6 +33,7 @@ FILES:${PN}-qteesupplicant = "${bindir}/qtee_supplicant \
                               ${nonarch_libdir}/udev/rules.d/99-qcomtee-udev.rules \
 "

+RDEPENDS:${PN}-qteesupplicant += " ${PN}"
 # Currently, this recipe only builds and installs for ARMv8 (aarch64) machine.
 COMPATIBLE_MACHINE = "^$"
 COMPATIBLE_MACHINE:aarch64 = "(.*)"

+1 I also think this is probably the right approach.

lumag · 2026-01-02T15:14:35Z

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

Hi @lumag , do you recommend adding the RDEPENDS to the minkipc_git.bb file? Is it correct approach for the patch?

Yes.

Another possibility is, if the libraries are exclusively to be used by the qteesupplicant, move them to the qteesupplicant package.

lumag · 2026-01-02T15:15:15Z

recipes-products/images/qcom-console-image.bb

    packagegroup-qcom-utilities-profile-utils \
    packagegroup-qcom-utilities-support-utils \
    ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'packagegroup-qcom-virtualization', '', d)} \
+    packagegroup-qcom-security \


Separate commit, also keep the list sorted.

Updated, separate into two commits.

Define packagegroup-qcom-security to include MinkIPC libraries and binaries, enabling communication between QTEE (QCOM Trusted Execution Environment) and REE (Rich Execution Environment). Signed-off-by: Jiaxing Li <jiaxing.li@oss.qualcomm.com>

Add packagegroup-qcom-security to qcom-console-image to provide MinkIPC libraries and service, enabling communication between QTEE and REE. Signed-off-by: Jiaxing Li <jiaxing.li@oss.qualcomm.com>

jiaxli-QC · 2026-01-05T03:36:38Z

Also, regarding your request for minkipc-qteesupplicant depending on minkipc package, since these are packages built from the same recipe, we are not clear on how to satisfy this requirement.

As usual, RDEPENDS.

Hi @lumag , do you recommend adding the RDEPENDS to the minkipc_git.bb file? Is it correct approach for the patch?

Yes.

Another possibility is, if the libraries are exclusively to be used by the qteesupplicant, move them to the qteesupplicant package.

Okay, we'll make updates to the meta-qcom repo later based on the comments.

jiaxli-QC · 2026-01-05T06:25:48Z

Hi Maintainer, it's very strange that I have already packaged all the minkipc libraries and binaries into the qcom-multimedia-image in my local compilation build, but there are no corresponding library files after flashing local build. How can I troubleshoot the problem?

For example, the libtimeservice.so.1 file can be found in the compiled build using the find command. And the build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1 is copied from build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/package/usr/lib/libtimeservice.so.1.

jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$ find build/ -name "libtimeservice.so.1"
build/tmp/sysroots-components/armv8-2a/minkipc/usr/lib/libtimeservice.so.1
build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1
build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/package/usr/lib/libtimeservice.so.1
build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/image/usr/lib/libtimeservice.so.1
build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/build/listeners/libtimeservice/libtimeservice.so.1
build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/sysroot-destdir/usr/lib/libtimeservice.so.1
build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/packages-split/minkipc/usr/lib/libtimeservice.so.1
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$ ls -al build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1
lrwxrwxrwx 1 jiaxli users 23 Mar  9  2018 build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1 -> libtimeservice.so.1.0.0*
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$ ls -al build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1.0.0
-rwxr-xr-x 1 jiaxli users 67416 Mar  9  2018 build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1.0.0*
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$ md5sum build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1
9a42239efe27d00689a3976ddadaeb7a  build/tmp/work/rb3gen2_core_kit-qcom-linux/qcom-multimedia-image/1.0/rootfs/usr/lib/libtimeservice.so.1
jiaxli@cse-cd01-lnx:/local/mnt2/workspace/jiaxli/upstream$ md5sum build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/package/usr/lib/libtimeservice.so.1.0.0
9a42239efe27d00689a3976ddadaeb7a  build/tmp/work/armv8-2a-qcom-linux/minkipc/0.0+git/package/usr/lib/libtimeservice.so.1.0.0

But when I flashed the device, I was able to find the qtee_supplicant binary in the device, but couldn't find the libtimeservice.so.1 library. The following error log:

PS C:\Users\jiaxli> adb wait-for-device shell
root@rb3gen2-core-kit:/# qtee_supplicant
qtee_supplicant: process entry PPID = 877
Total listener services to start = 4
dlopen(libtimeservice.so.1, RLTD_NOW) failed: libtimeservice.so.1: cannot open shared object file: No such file or directory
init_listener_svc failed: 0xffffffff
Total listener services to be stopped = 4
ERROR: listeners registration failed
root@rb3gen2-core-kit:/#
root@rb3gen2-core-kit:/# find / -name "libtimeservice.so.1"

lumag · 2026-01-05T20:56:31Z

Hi Maintainer, it's very strange that I have already packaged all the minkipc libraries and binaries into the qcom-multimedia-image in my local compilation build, but there are no corresponding library files after flashing local build. How can I troubleshoot the problem?

Which package will pull in the minkipc libraries into the image? And how?

jiaxli-QC · 2026-01-06T03:05:46Z

Hi Maintainer, it's very strange that I have already packaged all the minkipc libraries and binaries into the qcom-multimedia-image in my local compilation build, but there are no corresponding library files after flashing local build. How can I troubleshoot the problem?

Which package will pull in the minkipc libraries into the image? And how?

minkipc-qteesupplicant is part of packagegroup-qcom-security, which itself is included in qcom-console-image. When I run kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml command, the minkipc package, which is depended by mink-qteesupplicant, will be installed to qcom-multimedia-image.

lumag · 2026-01-07T07:30:19Z

Hi Maintainer, it's very strange that I have already packaged all the minkipc libraries and binaries into the qcom-multimedia-image in my local compilation build, but there are no corresponding library files after flashing local build. How can I troubleshoot the problem?

Which package will pull in the minkipc libraries into the image? And how?

minkipc-qteesupplicant is part of packagegroup-qcom-security, which itself is included in qcom-console-image. When I run kas build meta-qcom/ci/qcs6490-rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml command, the minkipc package, which is depended by mink-qteesupplicant, will be installed to qcom-multimedia-image.

With the RDEPENDS:${PN}-qteesupplicant = "${PN}" I can't reproduce your issue.

vkraleti · 2026-01-07T11:06:03Z

recipes-products/packagegroups/packagegroup-qcom-security.bb

+PACKAGES = "${PN}"
+
+RDEPENDS:${PN}:append:aarch64 = " \
+    minkipc-qteesupplicant \


Packagegroup for a single package may be an over kill. Can't minkipc-qteesupplicant be added directly to image?

@vkraleti , we are planning to use this packagegroup for adding more security packages such as optee_client which supports libckteec library immediately after this PR. We would need this anyways since more packages from our team will keep arriving, hence I think it's better if we do it upfront.

jiaxli-QC requested review from lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners December 17, 2025 06:36

jiaxli-QC force-pushed the MinkIPCEanblement branch from c9b313e to d704df5 Compare December 17, 2025 07:18

lumag requested changes Dec 17, 2025

View reviewed changes

jiaxli-QC force-pushed the MinkIPCEanblement branch 2 times, most recently from eb7e888 to b859d08 Compare December 18, 2025 06:27

jiaxli-QC requested a review from lumag December 18, 2025 06:28

lumag requested changes Dec 18, 2025

View reviewed changes

jiaxli-QC force-pushed the MinkIPCEanblement branch from b859d08 to 845cbef Compare December 19, 2025 02:00

jiaxli-QC requested a review from lumag December 19, 2025 02:01

jiaxli-QC force-pushed the MinkIPCEanblement branch from 845cbef to 5aec8a6 Compare December 20, 2025 01:37

harshaldev27 reviewed Dec 23, 2025

View reviewed changes

jiaxli-QC requested a review from harshaldev27 December 24, 2025 05:58

jiaxli-QC force-pushed the MinkIPCEanblement branch from 5aec8a6 to a1c7a96 Compare December 30, 2025 13:52

lumag reviewed Jan 2, 2026

View reviewed changes

jiaxli-QC added 2 commits January 5, 2026 11:23

qcom-console-image: add packagegroup-qcom-security

ff2a553

Add packagegroup-qcom-security to qcom-console-image to provide MinkIPC libraries and service, enabling communication between QTEE and REE. Signed-off-by: Jiaxing Li <jiaxing.li@oss.qualcomm.com>

jiaxli-QC force-pushed the MinkIPCEanblement branch from a1c7a96 to ff2a553 Compare January 5, 2026 03:29

jiaxli-QC requested a review from lumag January 5, 2026 03:33

jiaxli-QC mentioned this pull request Jan 6, 2026

Compilation issue: Minkipc package located in qcom-console-image could not be packeged into image file #130

Open

vkraleti reviewed Jan 7, 2026

View reviewed changes

packagegroup-qcom-test-pkg: Add minkipc into image #119

Are you sure you want to change the base?

packagegroup-qcom-test-pkg: Add minkipc into image #119

Conversation

jiaxli-QC commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiaxli-QC commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiaxli-QC commented Dec 19, 2025

Uh oh!

lumag commented Dec 19, 2025

Uh oh!

jiaxli-QC commented Dec 19, 2025

Uh oh!

harshaldev27 commented Dec 19, 2025

Uh oh!

lumag commented Dec 19, 2025

Uh oh!

harshaldev27 commented Dec 19, 2025

Uh oh!

lumag commented Dec 19, 2025

Uh oh!

jiaxli-QC commented Dec 20, 2025

Uh oh!

jiaxli-QC commented Dec 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lumag commented Dec 20, 2025

Uh oh!

jiaxli-QC commented Dec 23, 2025

Uh oh!

harshaldev27 commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harshaldev27 Dec 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumag commented Dec 24, 2025

Uh oh!

harshaldev27 commented Dec 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jiaxli-QC commented Dec 30, 2025

Uh oh!

harshaldev27 commented Jan 2, 2026

Uh oh!

lumag commented Jan 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiaxli-QC commented Jan 5, 2026

Uh oh!

jiaxli-QC commented Dec 17, 2025 •

edited

Loading

jiaxli-QC commented Dec 20, 2025 •

edited

Loading

harshaldev27 commented Dec 23, 2025 •

edited

Loading

harshaldev27 Dec 28, 2025 •

edited

Loading

harshaldev27 commented Dec 26, 2025 •

edited

Loading

jiaxli-QC commented Jan 5, 2026 •

edited

Loading