Ultimately I am trying to full install GNURadio on this server and been in dependency hell!
I am pretty close but the modeul gr-gtgui won't install. This is the error it gives:
-- Python checking for PyQt5 - found
-- Checking for module 'Qt5Qwt6'
-- Package 'Qt5Qwt6', required by 'virtual:world', not found
--
-- Configuring gr-qtgui support...
-- Dependency QT_FOUND = 1
-- Dependency QWT_FOUND = FALSE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PYQT5_FOUND = TRUE
-- Disabling gr-qtgui support.
-- Override with -DENABLE_GR_QTGUI=ON/OFF
I have (or atleast I think) I have installed qt5-devel correctly on my RHEL 8.7 server. I just did:
sudo yum install qt5-devel
I now need to install qwt. sudo yum install qwt gives the following errors:
Problem: conflicting requests
- nothing provides libQtCore.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtGui.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtXml.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtSvg.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtScript.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtOpenGL.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides libQtDesigner.so.4()(64bit) needed by qwt-6.1.1-1.el7.x86_64
- nothing provides qt4(x86-64) >= 4.8.5 needed by qwt-6.1.1-1.el7.x86_64
sudo yum install qwt-devel gives these errors:
Problem: conflicting requests
- nothing provides pkgconfig(QtGui) needed by qwt-devel-6.1.1-1.el7.x86_64
- nothing provides pkgconfig(QtXml) needed by qwt-devel-6.1.1-1.el7.x86_64
- nothing provides pkgconfig(QtOpenGL) needed by qwt-devel-6.1.1-1.el7.x86_64
- nothing provides pkgconfig(QtSvg) needed by qwt-devel-6.1.1-1.el7.x86_64
I have also tried to build qwt from source and it seems to work but doesn't seem to install the libraries that GNURadio needs.
Anyone have any suggestions?
Related
The problem I’m having is after the profiles.yml All checks passed! (the connection successful)
when i run dbt get this message
Configuration paths exist in your dbt_project.yml file which do not apply to any resources. There are 1 unused configuration paths:- models.dbt_project.example
when I run
dbt --version
Core: - installed: 1.4.1
- latest: 1.4.1 - Up to date!
Plugins: - sqlserver: 1.3.0 - Not compatible!
- synapse: 1.3.2 - Not compatible!
At least one plugin is out of date or incompatible with dbt-core.
You can find instructions for upgrading here:
https://docs.getdbt.com/docs/installation
The error message is telling you what is wrong. There is config in your dbt_project.yml file that does not apply to any files in your models directory.
When you run dbt init, it creates some example models (.sql files) in the models/example directory, like my_first_dbt_model.sql. It also adds some example config to dbt_project.yml that looks like this:
# towards the bottom...
models:
your_project_name:
# Config indicated by + and applies to all files under models/example/
example:
+materialized: view
You need to delete the example key, since you deleted that directory. You could also delete the keys above it, or keep them, since you'll probably add config at some point.
The OTHER error is probably because you installed dbt-core separately from dbt-synapse. You should delete your virtual environment and start over by just running pip install dbt-synapse, which will automatically install a compatible version of dbt-core. You should NEVER pin versions of dbt-core, only the version of your adapter (since the adapter will specify its compatible versions of dbt-core).
I am trying to make a recipe for a C++ app that uses libmariadb. While developing I was using vcpkg but now I want to use Yocto.
Here is the application_1.0.0.bb file:
# Metadata
SUMMARY = "Customer API Backend"
DESCRIPTION = "Customer API in C++ using gRPC"
# License is closed, no checksum to avoid warnings
LICENSE = "CLOSED"
LIC_FILE_CHKSUM = ""
DEPENDS = "protobuf protobuf-c protobuf-native grpc grpc-native openssl mariadb poco"
SRCREV = "${AUTOREV}"
SRC_URI = "git://git#gitlab.com/software/projects/embedded/application.git;protocol=ssh;branch=master;"
S = "${WORKDIR}/git"
inherit pkgconfig cmake
Here is the CMake part that poses problem with Yocto:
find_package(unofficial-libmariadb CONFIG REQUIRED)
find_package(Poco REQUIRED COMPONENTS Data DataMySQL)
target_link_libraries(database_api
PRIVATE
unofficial::libmariadb
Poco::DataMySQL
)
I get this error message during the configure step (CMake):
CMake Error at src/libraries/external_interfaces/database_api/CMakeLists.txt:20 (find_package):
Could not find a package configuration file probided by
"unofficial-libmariadb" with any of the following names:
unofficial-libmariadbConfig.cmake
unofficial-libmariadb-config.cmake
Add the installation prefix of "unofficial-libmariadb" to CMAKE_PREFIX_PATH
or set "unofficial-libmariadb_DIR" to a directory containing one of the
above files. If "unofficial-libmariadb" provides a separate development
package or SDK, be sure it has been installed.
I tried adding mariadb-native to the DEPENDS on the bitbake recipe but then I get this error messagewhen configuring mariadb-native`:
CMake Error at /home/oe-core/build/tmp/work/x86_64-linux/mariadb-native/10.7.5-r0/recipe-sysroot-native/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find GnuTLS (missing: GNUTLS_LIBRARY GNUTLS_INCLUDE_DIR)
(Required is at least version "3.3.24")
Call Stack (most recent call first):
(...)
-- Configuring incomplete, errors occurred!
Ok I figured it out by using more recent versions of the mariadb recipes + vcpkg mariadb port patches:
For the mariadb-native build:
Add a mariadb-native_%.bbappend in a recipes-dbs/mysql/ folder in your layer:
DEPENDS:append = " gnutls-native fmt-native"
Alternative is to have the more recent mariadb-native_%.bb recipe as it is already included. If, like me, you have 10.7.4 or something, the bbappend is required.
For the unofficial-mariadb target:
Using Yocto's devtool on mariadb recipe, I just reproduced the patches that vcpkg port of libmariadb has (found here: https://github.com/microsoft/vcpkg/tree/master/ports/libmariadb). The one that matters is the modification to libmariadb/CMakeLists.txt (but from mariadb recipe this is libmariadb/libmariadb/CMakeLists.txt since this is a higher repo layer). This patch export unofficial-libmariadb and also uses the unofficial:: namespace. This makes my project compatible.
I'm trying to build secondlife viewer but fail on:
Building 'Second Life Test' Version 3.8.5.34241
-- Found PkgConfig: /usr/bin/x86_64-pc-linux-gnu-pkg-config (found version "0.29")
-- checking for module 'ogg'
-- package 'ogg' not found
I've libogg installed: https://bpaste.net/show/c6d60173da44
full build log: https://bpaste.net/show/9b3ecbd254c4
pkg_check_modules soruce: https://bitbucket.org/lindenlab/viewer-release/src/dfd2e1723b72b62e8b6c3746fd5f7fbb1132f389/indra/cmake/Audio.cmake?at=default&fileviewer=file-view-default
full build log shows that I'm using USESYSTEMLIBS flag, that means that pkg_check_modules(OGG REQUIRED ogg) just doesn't find /usr/lib64/pkgconfig/ogg.pc with some reason...
What could cause such mysterious bug?
(here is CMakeOut log : https://bpaste.net/show/a2fc804afc73)
pkg-config --exists ogg --print-errors returns nothing
seems like just CMake doesn't work right -__-' https://github.com/Techwolf/techwolf-overlay/issues/2#issuecomment-144851500
This bug is in cmake 3.3.x, downgrade to 3.2.3-r1 will fix it
everything works with 3.2.3
-- checking for module 'ogg'
-- found ogg, version 1.3.2
I just upgraded & updated my homebrew and now if I run brew doctor, I get the following errors and it fails to run. May I deleted the unexpected header files or is there a better solution?
Warning: Your XQuartz (2.7.6) is outdated
Please install XQuartz 2.7.7:
https://xquartz.macosforge.org
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/node/ares.h
/usr/local/include/node/ares_version.h
/usr/local/include/node/eio-emul.h
/usr/local/include/node/ev-emul.h
/usr/local/include/node/node.h
/usr/local/include/node/node_buffer.h
/usr/local/include/node/node_object_wrap.h
/usr/local/include/node/node_version.h
/usr/local/include/node/uv-private/eio.h
/usr/local/include/node/uv-private/ev.h
/usr/local/include/node/uv-private/ngx-queue.h
/usr/local/include/node/uv-private/tree.h
/usr/local/include/node/uv-private/uv-unix.h
/usr/local/include/node/uv-private/uv-win.h
/usr/local/include/node/uv.h
/usr/local/include/node/v8-debug.h
/usr/local/include/node/v8-preparser.h
/usr/local/include/node/v8-profiler.h
/usr/local/include/node/v8-testing.h
/usr/local/include/node/v8.h
/usr/local/include/node/v8stdint.h
Basically, you just need to upgrade the XQuartz in your system and ignore all the other warnings.
You may build some software that utilise X11 components, so just go to https://xquartz.macosforge.org/, download and install the latest version.
It is obvious that you install node.js without using homebrew so that the header files are added into /use/local/include/ not via homebrew and confuse it. Unless you encounter some kind of problems as mentioned in the warning message, you can just ignore them.
I have added a section in my buildout to install python-ldap as described here:
http://bluedynamics.com/articles/jens/python-ldap-as-egg-with-buildout
However my buildout fails with:
While:
Initializing.
Getting section buildout.
Initializing section buildout.
Getting option buildout:eggs.
Getting section python-ldap.
Initializing section python-ldap.
Installing recipe zc.recipe.egg.
Error: There is a version conflict.
We already have: zc.buildout 1.4.2
but zc.recipe.egg 1.3.2 requires 'zc.buildout>=1.5.0'.
Why is buildout trying to get the latest version of zc.recipe.egg for this particular part even though it is pinned to 1.2.2 in the versions para?
You can pin any and all eggs (regardless of what they are used for) with a versions section. You have to explicitly declare such a section, but then it applies to recipe eggs as well:
[buildout]
... # Other options in the buildout section omitted
versions = versions
[versions]
zc.recipe.egg = 1.2.2
You can name the part that specifies version pins any way you want, but most people just name it versions.
I just had the exact same problem, and solved it by uninstalling the python-zc.buildout Debian package which was installed on my machine with version 1.4.3.