I need to update libvncserver and libvncclient libraries to 0.9.11.
I am running CentOS 7.3, currently, the latest libvncserver RPM is 0.9.9
So I took the libvncserver SRPM, modified the spec file, and updated the libvncserver tarball to create a 0.9.11 version of libvncserver and libvncclient RPM's.
I'm having a dependency challenge upon install.
Loaded plugins: fastestmirror
Examining ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm as an update to libvncserver-0.9.9-9.el7_0.1.x86_64
Examining ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Examining ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-devel-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package libvncserver.x86_64 0:0.9.9-9.el7_0.1 will be updated
--> Processing Dependency: libvncclient.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
Loading mirror speeds from cached hostfile
--> Processing Dependency: libvncserver.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
---> Package libvncserver.x86_64 0:0.9.11-1.el7.centos.1 will be an update
---> Package libvncserver-debuginfo.x86_64 0:0.9.11-1.el7.centos.1 will be installed
---> Package libvncserver-devel.x86_64 0:0.9.11-1.el7.centos.1 will be installed
--> Finished Dependency Resolution
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncclient.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncclient.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncclient.so.1()(64bit)
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncserver.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncserver.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncserver.so.1()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
x11vnc is using libvncserver.so.0 and libvncclient.so.0 from 0.9.9
[localhost SPECS]$ sudo ldd /usr/bin/x11vnc | grep -i vnc
libvncserver.so.0 => /lib64/libvncserver.so.0 (0x00007fee9387d000)
libvncclient.so.0 => /lib64/libvncclient.so.0 (0x00007fee9365f000)
Running the above in verbose, rpm tries to update x11vnc (to there is none)
Potential Provider: libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode is ud for provider of libvncserver.so.0()(64bit): libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode for pkg providing libvncserver.so.0()(64bit): ud
Trying to update x11vnc-0.9.13-11.el7.x86_64 to resolve dep
No update paths found for x11vnc-0.9.13-11.el7.x86_64. Failure!
Searching pkgSack for dep: libvncserver.so.0()(64bit)
I could "force-install" but before I do so I'm interested is there a better way to do this? Is it possible to specify dependency checker to not highlight the dependency? Another approach is to create a custom x11vnc RPM, just to update the library path.
The problem is that your package does not provide libvncserver.so.0, but replaces libvncserver, which provides libvncserver.so.0. The easiest solution is to rename your package, so that it can be installed along with the existing libvncserver package.
The -devel subpackage will probably have to conflict with libvncserver-devel because some of the files will overlap, but for the main package, you should be able to enable parallel installation.
You already mentioned the other clean solution: Port all packages from libvncserver.so.0 to libvncserver.so.1. But that could involve quite a bit of unnecessary work and makes your system less similar to others.
(You could also keep the libvncserver package name and create a compat-libvncserver package with the old library, but that's again quite a bit of work for very little benefit.)
Related
I am trying to add my modified version of vega as a local package as a dependency via:
yarn add vega#file:../vega/packages/vega
however, when I then do yarn, it tells me my package is invalid:
invalid: vega#5.22.1 /Users/alex/Documents/Work/Research/vega_profiler/VegaProf.nosync/editor/node_modules/vega
I think this is because it tries to match the version with the one in my package.json, which does not contain version information for the local package. However, I don't know how to address this.
We have a distributed subsystem consisting of multiple components, each component is deployed in it's own RPM package onto various different RHEL/CentOS environments. For example the components might be called:
JL_batman,
JL_superman, and
JL_wonderwoman.
And they are deployed as follows:
host1:
JL_batman
JL_wonderwoman
host2:
JL_superman
We do periodic system releases and also maintenance releases. So the initial few System Releases might look like this:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm
So in each System Release not all packages are updated. Currently we use symbolic links on the YUM repo for the packages that are not updated between releases:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm --> ../SR1/superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm --> ../SR2/batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
Each release directory (SR1, SR2, SR3, ...) is a YUM repository. We also use symlinks to link to the following rolling repositories:
JL-old-stable --> SR1
JL-stable --> SR2
JL-testing --> SR3
This is all managed on the YUM repo server using some home grown scripts to pull packages from Jenkins and put them into the JL-testing repo (replacing any old versions there). When SR3 testing is complete and it is promoted to stable, we jiggle the symlinks as follows:
JL-old-stable --> SR2
JL-stable --> SR3
JL-testing --> SR4
Each production environment has the yum .repo file installed for JL-old-stable.repo and JL-stable.repo. Test environments also have a JL-testing.repo file. Then yum upgrade 'JL_*' is used on each environment to keep it up to date. Works OK but has some issues, mainly:
When SR3 is promoted to stable, but we need to rollback to SR2 we need to use something like yum --disablerepo='JL-*' --enablerepo='JL-old-stable' downgrade 'JL-*'.
There is no way to easily rollback from SR3 (stable) to SR1 apart from installing a new JL-SR1.repo file and then using yum --disablerepo='JL-*' --enablerepo='JL-SR1' downgrade 'JL-*'.
Is there a better way?
I would instead use a single RPM that provides no files, but Requires the various other packages with exact versioning. The "Version" of each of the config RPMs is just the release number.
OurConfig_SR_1.noarch requires:
JL_batman = 1.0
JL_superman = 2.7
JL_wonderwoman = 1.1
OurConfig_SR_2.noarch requires:
JL_batman = 2.0
JL_superman = 2.7
JL_wonderwoman = 1.1
Then you can have them all in a single repo and versionlock the OurConfig on the machine until you're ready to move it. A quick check with rpm -qi OurConfig can tell you what that system expects. Requiring the exact versions should stop an SR1 system from automatically upgrading JL_batman to 2.0 (I didn't test this of course!).
I'm new to Purescript and am following the tutorial for installation. Purescript itself is working and I can start the CLI using pulp psci, but installing purescript-list runs into trouble.
Having entered the command bower install purescript-lists --save, I get a long list of package names, but when it gets to purescript-eff and purescript-prelude I run into some version conflicts:
bower purescript-eff#^2.0.0 cached https://github.com/purescript/purescript-eff.git#2.0.0
bower purescript-eff#^2.0.0 validate 2.0.0 against https://github.com/purescript/purescript-eff.git#^2.0.0
Unable to find a suitable version for purescript-eff, please choose one by typing one of the numbers below:
1) purescript-eff#^1.0.0 which resolved to 1.0.0 and is required by purescript-console#1.0.0
2) purescript-eff#^2.0.0 which resolved to 2.0.0 and is required by purescript-st#2.0.0
Prefix the choice with ! to persist it to bower.json
? Answer
A similar message is shown for purescript-prelude. No matter which options I choose, both pulp build and pulp run fail with:
$ pulp build
* Building project in /Developer/purescript/training1
Error found:
in module PSCI.Support
at /Developer/purescript/training1/bower_components/purescript-psci-support/src/PSCI/Support.purs line 10, column 34 - line 10, column 53
Cannot import value unsafeInterleaveEff from module Control.Monad.Eff.Unsafe
It either does not exist or the module does not export it.
See https://github.com/purescript/purescript/wiki/Error-Code-UnknownImport for more information,
or to contribute content related to this error.
Compiling PSCI.Support
* ERROR: Subcommand terminated with exit code 1
What have I missed here?
Thanks
Chris W
If you are using psc version 0.10.* you should go with prelude, lists and eff v2*.
If you are using psc version 0.9.* you should go with prelude, lists and eff v1*.
If you are using psc 0.10.* you might want to update pulp to version 9.1.0
The problem occurs due to breaking changes between psc 0.9 and 0.10 and the relevant libraries. by writing bower install purescript-lists --save you are asking bower for the latest dependencies which conflict with the dependency versions specified in your bower.json.
In one of my setuptools-based Python projects I would like to add a dependency to numpy-stl. That package is on PyPI and depends on numpy. Due to a bug, setuptools is unable to install packages with dashes in their names in some circumstances.
This is a minimal setup.py which reproduces the problem:
import setuptools
setuptools.setup(
install_requires=['numpy-stl'])
Running python setup.py develop produces the following output:
running install
running bdist_egg
running egg_info
writing UNKNOWN.egg-info/PKG-INFO
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing requirements to UNKNOWN.egg-info/requires.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.9-x86_64/egg
running install_lib
warning: install_lib: 'build/lib' does not exist -- no Python modules to install
creating build/bdist.macosx-10.9-x86_64/egg
creating build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
copying UNKNOWN.egg-info/PKG-INFO -> build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
copying UNKNOWN.egg-info/SOURCES.txt -> build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
copying UNKNOWN.egg-info/dependency_links.txt -> build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
copying UNKNOWN.egg-info/requires.txt -> build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
copying UNKNOWN.egg-info/top_level.txt -> build/bdist.macosx-10.9-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating 'dist/UNKNOWN-0.0.0-py3.5.egg' and adding 'build/bdist.macosx-10.9-x86_64/egg' to it
removing 'build/bdist.macosx-10.9-x86_64/egg' (and everything under it)
Processing UNKNOWN-0.0.0-py3.5.egg
Copying UNKNOWN-0.0.0-py3.5.egg to /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages
Adding UNKNOWN 0.0.0 to easy-install.pth file
Installed /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/UNKNOWN-0.0.0-py3.5.egg
Processing dependencies for UNKNOWN==0.0.0
Searching for numpy-stl
Reading https://pypi.python.org/simple/numpy-stl/
[... installing numpy-stl and some of its dependencies ...]
Installed /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/nine-0.3.4-py3.5.egg
Searching for numpy
Best match: numpy stl-1.7.1
Downloading https://pypi.python.org/packages/source/n/numpy-stl/numpy-stl-1.7.1.tar.gz#md5=fa3a9324418b72a6827f266671198fe1
Processing numpy-stl-1.7.1.tar.gz
Writing /var/folders/r3/lpx2z49s5hs8mmh3vzrgxd9c0000gs/T/easy_install-yvi_spnk/numpy-stl-1.7.1/setup.cfg
Running numpy-stl-1.7.1/setup.py -q bdist_egg --dist-dir /var/folders/r3/lpx2z49s5hs8mmh3vzrgxd9c0000gs/T/easy_install-yvi_spnk/numpy-stl-1.7.1/egg-dist-tmp-72gff1lq
File "build/bdist.macosx-10.9-x86_64/egg/stl2/stl.py", line 41
except RuntimeError, (recoverable, e):
^
SyntaxError: invalid syntax
zip_safe flag not set; analyzing archive contents...
tests.__pycache__.test_convert.cpython-35: module references __file__
removing '/Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/numpy_stl-1.7.1-py3.5.egg' (and everything under it)
creating /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/numpy_stl-1.7.1-py3.5.egg
Extracting numpy_stl-1.7.1-py3.5.egg to /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages
File "/Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/numpy_stl-1.7.1-py3.5.egg/stl2/stl.py", line 41
except RuntimeError, (recoverable, e):
^
SyntaxError: invalid syntax
numpy-stl 1.7.1 is already the active version in easy-install.pth
Installing stl2ascii script to /Users/michi/Desktop/STL_Plot/stl_plot/venv/bin
Installing stl2bin script to /Users/michi/Desktop/STL_Plot/stl_plot/venv/bin
Installing stl script to /Users/michi/Desktop/STL_Plot/stl_plot/venv/bin
Installed /Users/michi/Desktop/STL_Plot/stl_plot/venv/lib/python3.5/site-packages/numpy_stl-1.7.1-py3.5.egg
error: The 'numpy' distribution was not found and is required by numpy-stl
(venv)michi ~/.../STL_Plot/stl_plot$
After installing nine, setuptools tries to find a numpy distribution and finds numpy-stl, thinking its the package numpy in version stl and installs numpy-stl again. In the end it detects that numpy is still not installed and gives up.
Is this just the way it is, that setuptools projects cannot depend on packages with dashes in their names, which is about 1/4 of the packages on PyPI? Or is there a workaround which allows setuptools to install such dependencies?
How do I install Helm (https://hackage.haskell.org/package/helm) on Windows 7 (64-bit)?
(Update: I had posted a lot of error messages here, but I've moved them to my answer to not clutter up the question.)
Installation for Windows 64-bit:
I'm including error messages, for if you follow all the steps up to that point and then just try to install directly. This is a conglomeration of a bunch of ad-hoc steps from following many different posts. Any simplification would be appreciated!
Note: Do all work in directories without spaces. I'm doing all work in C:/PF; modify this to your directory.
Download MSYS2-x86_64 from https://msys2.github.io/ and install it. Cabal install cairo (or helm) will give something like:
Configuring cairo-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
Missing C libraries: z, cairo, z, gobject-2.0, ffi, pixman-1, fontconfig,
expat, freetype, iconv, expat, freetype, z, bz2, harfbuzz, glib-2.0, intl,
ws2_32, ole32, winmm, shlwapi, intl, png16, z
Download C libraries. In MINGW64 (NOT MSYS2 - I had trouble with MSYS2 at random stages in the process), use the package manager:
pacman -Ss cairo
to search for the Cairo package. You'll find "mingw64/mingw-w64-x86_64-cairo", so install that:
pacman -S mingw64/mingw-w64-x86_64-cairo
*.pc files should have been added to C:\PF\msys64\mingw64\lib\pkgconfig and C:\PF\msys64\usr\lib\pkgconfig. (pkg-config needs to be able to find these files. It looks in PKG_CONFIG_PATH, which by default should have the lib/pkgconfig folder above. Moving the file here is easiest. See Can't install sdl2 via cabal) If you get
The pkg-config package ... version ... cannot be found
errors then check your *.pc files.
Repeat with other required libraries, like atk
pacman -S mingw64/mingw-w64-x86_64-atk
(I don't know the complete list, but error messages later on will let you know what to get.)
Get the development files for these libraries (as suggested by How to install cairo on Windows). Most of them are bundled up at http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/. Unzip.
Copy files (.a, .dll.a) in lib to C:\PF\msys64\mingw64\lib. Copy the pkgconfig folder, which contains the .pc files.
Copy files in include to C:\PF\msys64\mingw64\include.
Add C:\PF\gtk+-2.22.1\bin to the path.
(2) and (3) might be redundant. I don't know - I did them both.
At this point you can probably do "cabal install cairo". (Warning: if your end goal is something else, you may not want to "cabal install" intermediate packages, see https://wiki.haskell.org/Cabal/Survival#Issue_.232_--_Not_installing_all_the_packages_in_one_go.)
See (4) for the syntax in specifying extra-include-dirs and extra-lib-dirs (but if you copied the files above this shouldn't be necessary),
Any time you get
Missing (or bad) header file
check to see you copied the *.h files to mingw64\include and/or add the include folder to the PATH. Use cabal install -v3 to get verbose error messages if the problem persists.
If you get something like
cairo-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
try --ghc-pkg-options="--force" (as mentioned at https://github.com/gtk2hs/gtk2hs/issues/139).
Get SDL. Otherwise you'll get
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5.1
Follow the instructions in (2) to get sdl/sdl2 libraries. (See instructions here Installing SDL on Windows for Haskell (GHC).)
The new version helm-0.7.1 requires sdl2, but there are other dependency issues with helm-0.7.1 as of writing. Download SDL from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (direct download link to newest version as of writing http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-SDL-1.2.15-7-any.pkg.tar.xz.sig/download), unzip. "cabal install sdl" gives
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
so we specify where the dirs are (change the name depending on where you extracted sdl to)
cabal install sdl --extra-include-dirs=C:/PF/sdl\include --extra-lib-dirs=C:/sdl/lib
If you got SDL2 (http://libsdl.org/download-2.0.php) (for a newer version of Helm): there is a fatal bug that hasn't been fixed in the release version. (If you don't fix it, cabal install -v3 things which depends on it will give error
winapifamily.h: No such file or directory
("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks) Download https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h, replace the file in the include folder and in C:/PF/msys64/mingw64/include/SDL2.
Download gtk2hs from http://code.haskell.org/gtk2hs and run
the following
cd gtk2hs/tools
cabal install
cd ../glib
cabal install
cd ../gio
cabal install
cd ../pango
cabal install --ghc-pkg-options="--force"
(Maybe you have already installed glib and gio from before? I did this step because normal install of Pango caused an error for me (https://github.com/gtk2hs/gtk2hs/issues/110)
pango-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
Once the Helm developers get things updated you should be able to do "cabal install helm" but right now there seem to be dependency issues. For me, cabal automatically tries to install helm-0.4 (probably because 0.4 didn't give upper bounds on dependencies, while newer versions do. You could try "cabal unpack"ing and deleting the upper bounds...). Then
cabal unpack helm-0.4
Installing gives an error because "pure" got moved to Prelude. Open helm-0.4\src\FRP\Helm\Automaton.hs and change line 17:
import Prelude hiding (id, (.), pure)
Now
cabal install
Try to compile and run a program using Helm
(This is 0.4 - look on the website for a newer sample if you tried a newer Helm)
import FRP.Helm
import qualified FRP.Helm.Window as Window
render :: (Int, Int) -> Element
render (w, h) = collage w h [filled red $ rect (fromIntegral w) (fromIntegral h)]
main :: IO ()
main = run $ fmap (fmap render) Window.dimensions
If you get an error about a missing .dll (sdl.dll), find it in a bin/ folder and add the folder to your PATH (or copy it to somewhere on your path).