I downloaded and untared package named gnome-system-tools-3.0.0. When typing the command ./configure I've got the following error massage:
configure: error: glib-compile-schemas not found.
I've tried to update glib. I have the file glib-compile-schemas in /usr/bin directory.
OS: Fedora 28
These tools were last updated in 2011. That is seven and a half years ago. In computer time, that's.... ancient. You would probably need corresponding versions of other parts of GNOME and of system libraries from that era to even get it to build, and even if you did that, the actual features for system management are unlikely to work.
Instead, I encourage you to look at Cockpit, a modern GUI systems management tool. See these instructions for installing and launching Cockpit on Fedora.
Related
I'm trying to initiate astro. When i don't choose a framework i get this error although i have git installed and fully working. Any help will be highly appreciated.
√ Which frameworks would you like to use? »
> Copying project files...
could not find commit hash for latest
This seems to be an issue with degit. Please check if you have 'git' installed on your system, and install it if you don't have (https://git-scm.com).
If you do have 'git' installed, please file a new issue here: https://github.com/withastro/astro/issues
It depends on your OS and environment.
For instance, withastro/astro issue 2144 reports the exact same error message, but on Windows, using Linux on WSL2 (Ubuntu 20.04.3 LTS).
Double-check your %PATH%/$PATH in your execution environment.
Update Oct. 2022, ten month later: withastro/astro issue 2144 is reported closed with the workaround by Matej Bunček:
As I was researching this seems to be a general issue with NPM for those who uses SSH.
There's an open issue here: npm/cli#2610 which is still far from being resolved and it's a huge thread.
Some folks might be interested in these workarounds to get it working.
git config --global url."https://github.com/".insteadOf git#github.com:
git config --global url."https://".insteadOf git://
Also I've tried yarn, npm and pnpm, all of them seems to have same problem so I believe it's core problem of node.
Also both npm 6 and 7 are not working.
Not a direct solution to your error message, but a general solution for those kinds of errors:
I would recommend doing the development inside docker containers, so called devcontainers.
Since you will develop in separate and isolated environments containing only the project's minimum dependencies and tools, it is a lot less likely to face OS specific issues in general.
Here are some resources to get started:
https://code.visualstudio.com/docs/remote/containers
https://microsoft.github.io/code-with-engineering-playbook/developer-experience/devcontainers/
https://github.com/microsoft/vscode-dev-containers
I am attempting to install closed source software from Silego, GreenPAK Designer, on a machine running Fedora 19. The supported installation packages on Silego's Website only target Ubuntu and Debian. I downloaded the .deb package and used Alien to convert to an RPM. So far so good, but a dry run of yum install showed dependency errors, which I solved by installing the necessary packages with yum:
qt5-qbase
qt5-qbase-gui
qt5-qtdeclarative
qt5-qtlocation
qwt
Now, yum installed the above libraries in /usr/lib/ but the GreenPAK RPM defaults to /usr/local/bin as the output dir. I figured I could run
sudo yum localinstall --nodeps --noscripts greenpak-designer-x.x.x.rpm
and get a successful install but I received conflict errors relating to dirs such as '/', '/usr', '/usr/bin' etc. I worked around this issue with:
rpmrebuild -pe --notest-install --replacefiles --noscripts greenpak-designer.x.x.x.rpm
and removing the offending lines in the script. It allowed me to install rpm but the software is broken because of dependency issues (not surprisingly). From the system log:
Jan 4 16:06:49 pelican gnome-session[1729]: /usr/local/greenpak-designer/bin/GP5: error while loading shared libraries: libicui18n.so.52: cannot open shared object file: No such file or directory
The machine has a /usr/lib/libicui18n.so.50
One thing I did not try is rebuilding my shared object cache with ldconfig, which sometimes solves problems with missing .so links when building from source but I don't see how that would apply in this instance (I'm not trying to link object files to libraries, rather simply trying to drop binaries in default install locations, no?)
Of course, I contacted the vendor and begged for an RPM. The contact was helpful but informed me the software folks are on a well deserved break. I thought I'd continue puttering with this in the meantime while I have time.
Any ideas? It seems the solution to this problem would be helpful when trying to install almost any closed source software targeting Debian on a Fedora box.
I just installed a fresh copy of Fedora 24 Workstation and did a full dnf update on the entire system.
Then I installed the jProfiler rpm from the jProfiler site.
However, when I try to launch jProfiler (either from the /opt/jprofiler9/jProfiler.desktop icon or from /opt/jprofiler9/bin/jprofiler shell script), I get the following error message:
java.awt.HeadlessException
at java.awt.SplashScreen.getSplashScreen(SplashScreen.java:117)
at com.exe4j.runtime.splash.AwtSplashScreen.<init>(AwtSplashScreen.java:17)
at com.exe4j.runtime.splash.SplashEngine.setJavaSplashScreenConfig(SplashEngine.java:17)
at com.install4j.runtime.launcher.UnixLauncher.main(UnixLauncher.java:50)
I've tried setting my display using DISPLAY=0.0 or even DISPLAY=:0, but neither seem to make any difference/impact.
Any suggestions how to get this to work? I suspect it is something obvious that I am overlooking.
After a bunch of trial and error, I finally tried to install the Oracle Hotspot JRE instead of the OpenJDK JRE. I downloaded Oracle's JDK, installed it, and then configured it as the system default using:
sudo alternatives --config java
Now everything works properly with Oracle JRE.
I have previously given up on installing OpenCV on my Windows 7 PC but now it has come back to haunt me, this time I'm trying to build its libraries using Visual Studio Community 2015.
I have tried finding a decent procedure on how to install it but they all sound simple until you encounter tons of errors when building ALL_BUILD in VS.
Here's what I did:
Downloaded the OpenCV 3.1 installer
Ran the installer and installed OpenCV in C:\
Added the OPENCV_DIR environment variable pointing to C:\opencv\build
Opened cmake-gui and set the source and build folders to C:\opencv\sources and C:\opencv\build, respectively
Clicked Configure, unchecked WITH_VTK option, clicked Configure again, then clicked Generate
Opened the generated solution file in C:\opencv\build
Right-clicked on the ALL_BUILD project and clicked Build
Only 11 projects were successfully built and 79 failed. The procedure they have on the OpenCV website is so outdated that it made me give up a long time ago. And there are several other resources that give equally confusing instructions.
Your help will be appreciated!
Upon further investigation, I saw this error frequently generated through build:
nvcc fatal : nvcc cannot find a supported version of Microsoft Visual Studio. Only the versions 2010, 2012, and 2013 are supported
This is caused by CUDA not supporting Visual Studio 2015 yet. So, I unchecked WITH_CUDA in cmake-gui, clicked Generate, opened the generated OpenCV solution file and built ALL_BUILD. No errors were generated after that.
I've built a service and I'd like to distribute it via rpm and should work on different fedora releases. Since it is a service it should be integrated with the system so it is possible to do:
$ service myapp start
The problem is that fedora used upstart in releases 9 to 14 and systemd from 15 and up. I can do this for both systems, but I'm not sure how to package it correctly.
I think I have to build different rpms for the fedora releases. The only thing that differs is a few files to be copied to different locations.
How should I handle the differences? In the .spec-file or Makefile? Or should I use two different .spec-files?
Do it in the spec file. Use separate sources for the upstart and systemd scripts, and include the appropriate script based on the version of Fedora being built on. So, single spec file to handle both cases.