gstreamer pointing to wrong commit

[ck3mp3r]

Hi,

gstreamer is pointing to the wrong commit within the sources directory.

christian@MacBook:gstreamer-1.0 (cerbero_build)$ git log
commit d11e657412e657f9a5146680ca8fd703574b63f2
Author: Evan Nemerson evan@nemerson.com
Date: Thu Jun 5 13:27:28 2014 -0700

docs: annotate C examples as such

https://bugzilla.gnome.org/show_bug.cgi?id=731292

This causes the build to break because all other gstreamer related commits point to the correct commits that already have 1.7.90 vs 1.7.1.1

Update:

...
checking for python extension module directory... ${exec_prefix}/lib/python2.7/site-packages
checking for python >= 2.7... checking pkg-config is at least version 0.9.0... yes
checking for GST... configure: error: Package requirements (gstreamer-1.0 >= 1.7.90) were not met:

Requested 'gstreamer-1.0 >= 1.7.90' but version of GStreamer is 1.7.1.1
...

Cheers,
Christian

[ck3mp3r]

@sdroege, @superdump
I have noticed some commits in the recipes either point to a commit id or just origin/master.
Commit ids aren't for me, I don't want to go hunting for info... how about pointing to 'tags/tagname'.
In the case of gst-xxxxx we should now use 'tags/1.7.90' so we know which release it is pointing to.
As for 'origin/master' that will always cause havoc for stable builds as origin/master obviously is a moving target...
Any ideas?

Also, I am busy trying to run through an imerge from upstream cerbero. Because I don't have enough background information as to how much of the changes you want to keep I could use some guidance...

[ck3mp3r]

I've got a working branch here if you want to give it a run.
I didn't want to do a pull request because I think it might make merging more difficult later on when it comes to doing a full up stream merge...
Let me know what you think.

[sdroege]

Usually we selected a coherent GIT commit id for all modules, but around releases it should be fine to just take the release tags. It's just not possible if we need to get a snapshot somewhere between releases.

Are you also planning on updating/syncing cerbero in general btw?

[ck3mp3r]

Hi, I was trying with imerge but some of the conflicts have me wondering if
I need to pull in everything new from upstream cerbero. I think I need to
pair with someone who knows.

On Mon, 14 Mar 2016 at 09:55 Sebastian Dröge notifications@github.com
wrote:

Usually we selected a coherent GIT commit id for all modules, but around
releases it should be fine to just take the release tags. It's just not
possible if we need to get a snapshot somewhere between releases.

Are you also planning on updating/syncing cerbero in general btw?

—
Reply to this email directly or view it on GitHub
#48 (comment)
.

[superdump]

Right, we have some differences in our cerbero which is the reason for maintaining a fork. I will update and sync cerbero with upstream sometime soon. I was waiting for some GL optimisations in GStreamer to be finished off before bumping everything.

[superdump]

And we use specific git commit hashes for GStreamer because not everything we need is in GStreamer releases yet. When it is we can just track releases but for the time being there are contributions being made to GStreamer master branches that we need to track.

[ck3mp3r]

Definitely use origin/master for current snapshots and 'tags/realease-xxx' for releases vs commit IDs.
@superdump I would love to learn more about the differences and how to apply them. If you can point me to some docs I'll start prepping.

[superdump]

What are you doing and what is wrong for you with using our cerbero fork as it is?

"origin/master" would be incorrect as it is not what we intend. We do not want users to build from upstream master at the point in time when they are building. We want them to build at the point in master that we have chosen to sync to. The commit hash is the best representation of this that we have without trying to get tags pushed to the upstream repo for our purposes or mirroring the upstream repo and tagging in our repo. I don't like either of those options.

It sounds like you are trying to maintain a fork of our fork. It would be better to work with us to discuss whatever you think are the shortcomings of our fork and figure out solutions to them. I don't think the commit hash for GStreamer repo master branches is a shortcoming in reality but you are welcome to clarify what you think is wrong with it.

As for the original issue in this thread - did you try doing a clean build from our cerbero master branch after you updated it? Sometimes there are breaking changes that require cleaning out the build directories and building from scratch.

cd ~/cerbero
./cerbero-uninstalled -c config/osx-x86-64.cbc wipe --build-tools

And then follow on from here as usual: https://github.com/EricssonResearch/openwebrtc/wiki/Building-OpenWebRTC#prepare-the-host

[ck3mp3r]

Hi, I'm not advocating origin/master from upstream, but rather components within cerbero that need snapshot dependencies. Everything that is safe to point to 'tags/xxxx' should obviously to that.

I'm using a fork because I have a forked version of openwebrtc as I need extra components activated for my iOS build so I can use custom sinks. Not sure if you remember but you advised me some time back to do so.

If something breaks I always run from a clean slate as to not muddy the waters... that is how I found out openssl was pointing to a wrong version. Then it broke on gst related components, hence this thread.

I've now updated my version of cerbero and pointed to 1.7.90 and also moved opus from bad to base as it broke there as well...