gstreamer1.0-plugins-base: Add bbappend to apply patches from external git repo #1349

Raja-Ganapathi-Busam · 2026-01-02T14:54:40Z

Summary

This PR adds bbappend file to the gstreamer1.0-plugins-base recipe to append additional patches from an external series file after the base recipe patches. The patches are imported using quilt in the correct order and applied after existing patches.

Key Changes

Fetched additional patches and series file from external Git repository
Skipped lines starting with # in the series file (treated as comments).
Imported and applied patches in series file order using quilt import and push

Temporary Setup

There is a separate pull request raised on the patches repository which is pending review and merge.
Until that PR is merged, SRC_URI in this recipe points to my forked repository to fetch the patches.

Merge Condition

Please merge this PR only after the patches PR is merged in the patches repository, gst-qti-oss-patches, to ensure consistency.

Testing

Verified patches apply in correct order mentioned in series file.
Confirmed that comment lines (#) in the series file, if any, are skipped.
Build completed successfully with updated patches.

…l git repo - Fetched additional patches and series file from external Git repository - Imported and applied patches in series file order using quilt import and push - Skipped patches prefixed with '#' in the series file (treated as comments) Signed-off-by: Raja Ganapathi Busam <rbusam@qti.qualcomm.com>

lumag · 2026-01-02T15:23:30Z

I'm sorry, this is a nice hack, but no. Please follow the usual process: add the patches to the layer repo instead of storing them in the external repo. Contribute all the patches to the upstream project, UBWC compression should be supported upstream, it doesn't differ any other compression schemes.

CherukuriNaveenQC · 2026-01-05T05:10:38Z

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

@ndechesne could you please comment your feedback here.

Raja-Ganapathi-Busam · 2026-01-05T07:29:40Z

There are complications in upstreaming patches related to the UBWC (Universal Bandwidth Compression) format.
Please refer to the ongoing open-source discussion here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9712

Since UBWC is a proprietary format, we cannot provide the pack/unpack logic in open source. The upstream community does not accept a packed format without corresponding pack/unpack implementations.
Additionally, to leverage the memory:DMABuf caps feature, there are challenges in retrieving video meta information required for buffer mapping.

We are actively collaborating with the community to find a way forward, but this will take time to reach alignment.
Until then, we plan to maintain these patches locally to ensure functionality.

ndechesne · 2026-01-05T07:32:05Z

hi. this is indeed aligned with what we discussed (privately), but let's discuss that here now.

I proposed to manage gstreamer in a different way because it has , I think, different challenges.

the gst team needs to support many different gst version (major and minor), so they need to store gst patches for each of the supported versions 'somewhere'.
we want to package QCOM gstreamer 'changes' for each distro we support (yocto, but also debian). and we have 3rd party doing their own too (Ubuntu)
we are actively engaged to upstream our changes, so the goal remain to have less patches (no patches?) eventually.

I understand it is not the standard way to host patches for OE recipes, but it's a practical solution to help us overall.

sbanerjee-quic · 2026-01-05T09:26:32Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+SRCREV_qti_patches = "${AUTOREV}"
+
+qcom_do_patch() {
+    PATCHREPO="${WORKDIR}/sources/patchrepo"


Start as do_patch_
Can you name this more appropriately in the purpose?

sbanerjee-quic · 2026-01-05T09:29:01Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+            esac
+
+            if [ -f "${PATCHREPO}/${p}" ]; then
+                quilt import "${PATCHREPO}/${p}"


you need to depend on quit-native

In my understanding, Yocto uses quilt as the default PATCHTOOL.
Since this function runs inside do_patch:append, the environment already ensures quilt-native is available.
Therefore, we do not need to explicitly add DEPENDS += "quilt-native" in the .bbappend file.

Of course you need to do it. If something is changed in OE-Core then your recipe gets broken.

ndechesne · 2026-01-05T09:40:01Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+    git://github.com/Raja-Ganapathi-Busam/gst-qti-oss-patches.git;protocol=ssh;user=git;branch=${PV};name=qti_patches;destsuffix=patchrepo;subpath=${BPN} \
+"
+
+SRCREV_qti_patches = "${AUTOREV}"


no AUTOREV, we only rely on fixed content/metadata in meta-qcom.

Our intention is to avoid making changes in meta-qcom repo if there is any update in patches repo.
Please suggest.

there is no other way around. You need to make changes to meta-qcom when you change the version of the software we build in meta-qcom.

+1 here. If you make changes to your repo, it is a different version, a different recipe revision and a different set of packages. The item will go away once you drop the custom do_patch implementation and use OE's one (together with using raw URIs)

ndechesne · 2026-01-05T09:50:55Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

@@ -0,0 +1,37 @@
+# To apply patches to support Qualcomm specific formats and fixes
+SRC_URI:append:qcom = " \
+    git://github.com/Raja-Ganapathi-Busam/gst-qti-oss-patches.git;protocol=ssh;user=git;branch=${PV};name=qti_patches;destsuffix=patchrepo;subpath=${BPN} \


if the patches are available in a public http link, perhaps we could list them here directly. that might be a better approach that strictly depending on an external git tree.

a link like this one (this is just an example)

https://raw.githubusercontent.com/qualcomm-linux/meta-qcom/e74ef28e7df313edf77e6aafe2f789ef324b09d5/conf/layer.conf

At least you wouldn't need to have a custom do_patch implementation.

We are in process of making git://github.com/qualcomm/gst-qti-oss-patches public. Meanwhile, we would like to have a review of our approach

We are in the process of making the patches repository public.
Once it becomes publicly accessible, I will update the link accordingly.

I understand, and I made the review in this context. I am not saying that the link is not public, but suggesting a different approach. Instead of downloading the whole tree and manually applying the patches yourself in the qcom_do_patch() function, you can list all the patches as http:// links SRC_URI.

That way, you still preserver your tree with standalone patches which is convenient for what we discussed, and we still integrate patches 'normally' (almost) from an OE metadata perspective

I understand, and I made the review in this context. I am not saying that the link is not public, but suggesting a different approach. Instead of downloading the whole tree and manually applying the patches yourself in the qcom_do_patch() function, you can list all the patches as http:// links SRC_URI.

That way, you still preserver your tree with standalone patches which is convenient for what we discussed, and we still integrate patches 'normally' (almost) from an OE metadata perspective

I think that is also what as suggested by me in the meetings before the solstice break. Having a custom do_patch is very fragile and rarely required.

You can still point out the raw URIs inside your repo (and change them later to the official one once it's public).

lumag · 2026-01-05T20:16:18Z

Okay.

@lumag As canonical suggesting hosting in separate repo instead of putting patches along with distribution and we would like to maintain patches in one central repo for all distributions and our team had initial discussion with Nico and explained the reason to host in Github

This will not work in a long term. Ubuntu, Debian, Fedora and OE will have different versions of the GStreamer. At some point your patches won't be unuquelly applicable to those versions, so you will have to have separate branches or revisions. Having that in mind it is much easier to incorporate those patches into the distro package as it is usually done. I definitely don't expect Debian / Ubuntu packages fetching additional repo during the build stage.

Since UBWC is a proprietary format, we cannot provide the pack/unpack logic in open source. The upstream community does not accept a packed format without corresponding pack/unpack implementations.

UBWC format has been reverse engineered. There was another study of the compressed formats, which I can find quickly at this moment. As such, I can only recommend actually defining the compress and decompress functions and following Gstreamer requirements. Other projects would also benefit from it. We have hard time testing the UBWC support on the display side because there is no defined way to create or validate generated UBWC images.

lumag · 2026-01-05T20:20:49Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_%.bbappend

+}
+
+python do_patch:append:qcom() {
+    bb.build.exec_func('qcom_do_patch', d)


Any reason for not extending the function directly?

Raja-Ganapathi-Busam requested review from lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners January 2, 2026 14:54

sbanerjee-quic reviewed Jan 5, 2026

View reviewed changes

ndechesne reviewed Jan 5, 2026

View reviewed changes

lumag reviewed Jan 5, 2026

View reviewed changes

lumag marked this pull request as draft January 5, 2026 20:21

gstreamer1.0-plugins-base: Add bbappend to apply patches from external git repo #1349

Are you sure you want to change the base?

gstreamer1.0-plugins-base: Add bbappend to apply patches from external git repo #1349

Conversation

Raja-Ganapathi-Busam commented Jan 2, 2026

Summary

Key Changes

Temporary Setup

Merge Condition

Testing

Uh oh!

lumag commented Jan 2, 2026

Uh oh!

CherukuriNaveenQC commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Raja-Ganapathi-Busam commented Jan 5, 2026

Uh oh!

ndechesne commented Jan 5, 2026

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumag commented Jan 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

CherukuriNaveenQC commented Jan 5, 2026 •

edited

Loading