Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end.
Given the time frame, it's going to be hard to make a smooth transition of the cluster to somewhere else (TBD). Please expect in the next months some hiccups in the service and probably at least a full week of downtime to transfer gitlab to a different place.
All help is appreciated.
This is an archived project. Repository and other project resources are read-only.
Zynq and rpi can be built on desktop as well so we can check for building regressions.
We won't be able to run them but gst-omx doesn't have any test anyway. :p
Thanks for the issue, we could totally expand it and build the rest of targets. Is there any weird dep that might be needed? I could figure it out during configure but knowing about them upfront would be useful.
It's just a matter of building with the right target and header_path options.
So we'll have to checkout the proper OMX stack for each target (no need to build it, we just need the headers):
As you can see tools/tizonia-dev-build --deps isn't working as it seems to be Debian only. So I tried manually installing some missing deps. That's not enough as it now needs libspotify which is not packaged in Fedora.
Would it be possible to do a minimum tizonia build with just the bare minimum needed to build gst-omx?
Actually Juan told me that this flags is not forwarded to configure so instead of running tizonia-dev-build script you can do: autoreconf -ifs && ./configure --disable-player --without-libspotify && make && make install I tried and it worked locally.
Do we really need this component as well? Would it be possible to add build options so we can build the bare minimum to build gst-omx? If only to reduce the CI build time.
We do not need this component but I requested to add an option. Regarding the error this is really strange providing everything looks good at configure time:
checking for a Python interpreter with version >= 3.5... python3checking for python3... /usr/bin/python3checking for python3 version... 3.7checking for python3 platform... linuxchecking for python3 script directory... ${prefix}/lib/python3.7/site-packageschecking for python3 extension module directory... ${exec_prefix}/lib64/python3.7/site-packageschecking for python3.7... (cached) /usr/bin/python3checking for a version of Python >= '2.1.0'... yeschecking for a version of Python >= '3.5'... yeschecking for the distutils Python package... yeschecking for Python include path... -I/usr/include/python3.7mchecking for Python library path... -L/usr/lib64 -lpython3.7mchecking for Python site-packages path... /usr/lib/python3.7/site-packageschecking python extra libraries... -lcrypt -lpthread -ldl -lutil -lmchecking python extra linking flags... -Xlinker -export-dynamicchecking consistency of all components of python development environment... yeschecking for boostlib >= 1.54 (105400)... yeschecking whether the Boost::Python library is available... yeschecking whether boost_python is the correct library... nochecking whether boost_python37 is the correct library... yes
I already opened !225 (merged) adding the couple of extra deps needed. Ideally we shouldn't depend on the develop branch as we don't want that a build regression in Tizonia breaks our CI. Do you know if there is any plan to make a release with meson soon?