Skip to content

camxcommon: package provide common utility API used by all CamX components #1231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

camxcommon: package provide common utility API used by all CamX components #1231

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions recipes-multimedia/camx/camxcommon_1.0.1.bb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
SUMMARY = "Qualcomm camera common utility API used by all CamX components"
DESCRIPTION = "Collection of prebuilt libraries to support common utility API used by all CamX components."
LICENSE = "LICENSE.qcom-2"
LIC_FILES_CHKSUM = "file://${UNPACKDIR}/usr/share/doc/${PN}/NO.LOGIN.BINARY.LICENSE.QTI.pdf;md5=7a5da794b857d786888bbf2b7b7529c8"

SRC_URI = "https://qartifactory-edge.qualcomm.com/artifactory/qsc_releases/software/chip/component/camx.qclinux.0.0/${PBT_BUILD_DATE}/prebuilt_yocto/${BPN}_${PV}_armv8-2a.tar.gz"
Copy link
Contributor

@lumag lumag Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay... So, you did it again. Tarball changed, PV didn't. Could you please STOP doing that?

Copy link
Contributor Author

@gkhose-qipl gkhose-qipl Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay... So, you did it again. Tarball changed, PV didn't. Could you please STOP doing that?

For the base PR, we often see that the artifactory and SHA are updated even when there are no changes in the camxcommon recipe. However, if other recipes are modified, the SHA for all recipes also changes. Therefore, we need to update the SHA for all recipes whenever any changes occur. We were considering updating the version with every change once the base PR is merged. Would that be acceptable?

Copy link
Contributor

@lumag lumag Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was no PR in my sentence. No recipes. Stop reusing tarball names. Ever. It breaks OE caching. It breaks other possible ways to cache things. It breaks my mind, when I download yet another tarball pointed out by the recipe's URL and then face several files with the same basename. If I or somebody else downloads the tarball, wraps it in deb, rpm, apk or any other package, processes something then reports you an error, how would you determine, which one of the 1.0.1 tarballs had an issue? The rule of thumb is very, very simple: new upload means new tag, new version, new tarball name. If the contents doesn't change, find the ways to create binary reproducible tarballs (yes, it is possible, there are flags for that). But there should never be two tarballs with the same name and with different checksums.

Copy link
Contributor

@ricardosalveti ricardosalveti Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, big NAK for tarball changes without any actual content change, it should at least be fully reproducible.

Copy link
Contributor Author

@gkhose-qipl gkhose-qipl Nov 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was no PR in my sentence. No recipes. Stop reusing tarball names. Ever. It breaks OE caching. It breaks other possible ways to cache things. It breaks my mind, when I download yet another tarball pointed out by the recipe's URL and then face several files with the same basename. If I or somebody else downloads the tarball, wraps it in deb, rpm, apk or any other package, processes something then reports you an error, how would you determine, which one of the 1.0.1 tarballs had an issue? The rule of thumb is very, very simple: new upload means new tag, new version, new tarball name. If the contents doesn't change, find the ways to create binary reproducible tarballs (yes, it is possible, there are flags for that). But there should never be two tarballs with the same name and with different checksums.

As each distribution brings their own GCC, GLIBC and other differences, can we use same binaries for ubuntu distributions?

Copy link
Contributor

@lumag lumag Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As each distribution brings their own GCC, GLIBC and other differences, can we use same binaries for ubuntu distributions?

It's called ABI compatibility. In 99.9 % of the cases the binary compiled with the older GCC against the older Glibc will work with the newer ones. So, a typical approach would be to select some balanced old baseline and test that the binaries built with it still work with the newest one.

SRC_URI[sha256sum] = "0d80f438c0bacd924e02b7d151ca9c3a484ad210449bbc0e70b0edd2b48b6d50"
PBT_BUILD_DATE = "251125"
S = "${UNPACKDIR}"

DEPENDS += "glib-2.0"

# This package is currently only used and tested on ARMv8 (aarch64) machines.
# Therefore, builds for other architectures are not necessary and are explicitly excluded.
COMPATIBLE_MACHINE = "^$"
COMPATIBLE_MACHINE:aarch64 = "(.*)"

# Disable configure and compile steps since this recipe uses prebuilt binaries.
do_configure[noexec] = "1"
do_compile[noexec] = "1"

do_install() {
install -d ${D}${libdir}
install -d ${D}${datadir}/doc/${PN}

cp -r ${S}/usr/lib/* ${D}${libdir}
install -m 0644 ${S}/usr/share/doc/${PN}/NO.LOGIN.BINARY.LICENSE.QTI.pdf ${D}${datadir}/doc/${PN}
}

FILES:${PN} += "${libdir}/qcs9100/*${SOLIBS}"
FILES:${PN}-dev += "${libdir}/qcs9100/*${SOLIBSDEV}"
Loading