We are looking at our Windows toolchain not being fully compatible with the GStreamer MSI releases as we build with VS2022 and our VCRuntime redist is 14.38 instead of 14.36. Because we build gst-interpipe and a custom ICE agent as part of our codebase we think the different toolchains are contributing to Access Violation crashes inside glib allocation and memory management.
I’m looking at using cerbero to build the required packages on our toolchain so we can stress test and validate this theory.
We’re currently using gstreamer 1.22.6.
The one thing I can’t figure out is how to specify which release tag we want cerbero to use for the packages.
I saw the custom remotes docs in the README and I could certainly set that to use the gstreamer monorepo with the tag for the branch name, but before I do that I wanted to check if there is an argument or config based way to specify version as to me it seems the custom remotes is for building against a custom fork, not just for version management.
If you check out the 1.22.6 tag in cerbero that should build you GStreamer 1.22.6 and is what our binaries were built from at the time.
Having said that, specifying a custom remote and specifying the monorepo 1.22.6 tag is probably going to work fine most of the time with other 1.22 branch revisions of cerbero and perhaps even main branch revisions. YMMV.
Not sure if that actually was your question though
That answered my question directly. Given that more recent versions have the windows PS for cerbero-uninstalled, I think what I’m going to checkout cerbero 1.22.8 tag and set a custom remote to point to the 1.22.6 tag for gstreamer and cross my fingers.
There were some windows-related fixes that might be relevant to you that landed yesterday in the 1.22 branch for what it’s worth, so might as well try the tip of 1.22 branch if those look useful.
So I’ve got cerbero bootstrapped on 1.22.8, I entered
# Set custom remote and branch for all gstreamer recipes
recipes_remotes = {'gstreamer-1.0': {'custom-remote': 'https://gitlab.freedesktop.org/gstreamer/gstreamer.git'}}
recipes_commits = {'gstreamer-1.0': 'custom-remote/1.22.6'}
in my localconf.cbc file but when it tries to pull the sources for the gstreamer-1.0 package I get the following error:
Running command ['git', 'remote', 'add', 'origin', 'https://gitlab.freedesktop.org/gstreamer/gstreamer.git'] in C:/Users/dcpmc1/.cache/cerbero-sources/gstreamer-1.0
error: remote origin already exists.
Running command ['git', 'remote', 'set-url', 'origin', 'https://gitlab.freedesktop.org/gstreamer/gstreamer.git'] in C:/Users/dcpmc1/.cache/cerbero-sources/gstreamer-1.0
Running command ['git', 'remote', 'add', 'custom-remote', 'https://gitlab.freedesktop.org/gstreamer/gstreamer.git/1.22.6'] in C:/Users/dcpmc1/.cache/cerbero-sources/gstreamer-1.0
Running command ['git', 'fetch', '--all'] in C:/Users/dcpmc1/.cache/cerbero-sources/gstreamer-1.0
Fetching origin
Fetching custom-remote
fatal: unable to update url base from redirection:
asked for: https://gitlab.freedesktop.org/gstreamer/gstreamer.git/1.22.6/info/refs?service=git-upload-pack
redirect: https://gitlab.freedesktop.org/users/sign_in
error: could not fetch custom-remote
Running command ['git', 'reset', '--hard', 'https://gitlab.freedesktop.org/gstreamer/gstreamer.git/1.22.6'] in C:/Users/dcpmc1/.cache/cerbero-sources/gstreamer-1.0
fatal: invalid object name 'https'.
I used the example from the README file for trying to figure out what my custom repo/branch config should look like but to me it looks like I misunderstood something.
I got a working local build on my machine last week and I’ve been working on a few things. When I started adding to a branch for our build process, I noticed two things that have me thinking that even though I’ve checkout out the corresponding cerbero tag - git checkout 1.22.8 - the user agent doing the various fetches is logging as 1.23.0..., and the default revision for everything seems to be main unless there is a manifest file that has a revision/version specified. And the resulting MSI was named gstreamer-1.0-msvc-x86_64.1.23.0.1 (the develop one following the same version number).
This makes me think that without the manifest file it just builds the latest from main. That said, I can’t find docs or indication on what the structure of the manifest file is supposed to look like and it doesn’t look like any manifest file is included in the repo.
I can use the recipe-commits in a local config to force it to pull from the gstreamer tag I want to build, but that seems wrong in the sense of the labeled version of the MSI build is still going to be off.
Thanks! I just checked the fetch and it’s definitely pulling main. I’ve confirmed we’re properly checking out the tag on the cerbero build. Would I be correct in basically patching those python files to set the version to 1.22.8 and setting up the custom recipe_commits in local conf? Having seen in the scripts the check for the manifest and version, the manifest file feels less dirty but whatever works
I’ve been trying to read through and see if there are environment args I can set that Cerbero will use as well.
