I'm building my own RPM and I want to specify a specific version of the node.js package as dependency.
I've tried several way to specify it in the .spec file but none of theses works, how should I write it ?
I have tried :
BuildRequires: nodejs.x86_64 = 2:10.5.0-1nodesource
also
BuildRequires: nodejs = 10.5.0
also
BuildRequires: node = 10.5.0
Get the following error building the rpm :
error: Failed build dependencies: nodejs.x86_64 =
2:10.5.0-1nodesource is needed by ...
My building machine is a Centos 7
BuildRequires: nodejs = 2:10.5.0-1nodesource
The full version in necessary on the right-hand-side, but specifying .x86_64 on the left-hand-side was the problem with the first attempt.
You should probably not be specifying the arch, but if you must, it can generally be done like this:
BuildRequires: nodejs(x86-64) = 2:10.5.0-1nodesource
It should be
BuildRequires: nodejs = 2:10.5.0
The 2: stands for epoch, which is rarely used, but this package has it set.
Related
A while back, I created a fork of the RDCOMClient package to keep it working with R 3.6 (https://github.com/dkyleward/RDCOMClient). People are now running into issues again because it won't work with R 4.0. The problem doesn't seem as easy to fix, and I'm hoping for some help.
If I flip Rstudio back to R 3.6 (and rtools35), I can use the package after installing with devtools::install_github(). When I try in R 4.0 (and rtools40), the package builds and I can connect over COM to an application. The first line of code below works, and xl is a COM pointer; however, trying to do anything with it (like set Excel to visible) will crash R.
xl <- RDCOMClient::COMCreate("Excel.Application")
xl[["Visible"]] <- TRUE
Again, the above works in R 3.6.
Is there is a way to continue building with the previous rtools? I came across https://github.com/r-windows/rtools-backports#readme, which talks about using rtools35 to keep building packages, so I have hope, but I don't understand how to make it happen.
Alternatively, if there are minor changes I can make to the R or cpp code that will solve my problem, I'm all ears. I'm a cpp novice, though.
This was a quick fix :
install.packages("RDCOMClient", repos = "http://www.omegahat.net/R")
Install R-4.0.0
Install Rtools35
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64)
Rcmd INSTALL RDCOMClient
Rik's answer was incredibly helpful and got a version working; however, after spending a day on it, I was able to improve on it. I want to put that here in case I have to do it again. The main improvement is being able to build a working package for both 32- and 64-bit architectures. By default, R installs both, and this makes things easier when installing dependent packages.
The first two steps are the same:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
If (like me) you had already installed rtools40, a system environment variable named RTOOLS40_HOME is created. The first step is to change that to:
C:\rtools
If you don't have rtools40 installed, then create the RTOOLS40_HOME system environment variable.
Two changes are still needed in the make files. These are found in your R installation directory.
In etc\x64\Makeconf, add underscores to match the rtools35 directory structure by setting these values:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_64/bin/"
Do the same in etc\i386\Makeconf:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_32/bin/"
Do not set BINPREF as an environment variable, or this will overwrite the makefile changes (like RTOOLS40_HOME does). With these complete, finish off with the same steps that Rik outlined:
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I can confirm that the procedure delineated in the answer above leads in the right direction but a few extra steps may be required. I can also confirm that the procedure below produces a Windows binary file that can be installed and will run under R-4.0.0:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64) by changing
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools40
to
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools
Download RDCOMClient-master.zip from https://github.com/omegahat/RDCOMClient (click the green Clone button and select download zip)
Unpack to a directory named RDCOMClient
Ensure that the following PATH variables are set:
C:\Program Files\R\R-4.0.0\bin\x64 (assuming this is the location where R is installed)
C:\Rtools\bin
C:\Rtools\mingw_64\bin
Add environment variable BINPREF with the following value (the final slash is important):
C:/Rtools/mingw_64/bin/
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I am using R 4.1.2 and I found RDCOMClient will crash the R Session and the above solutions were not working.
Then, I further check with the source owner and found out the solution.
https://github.com/omegahat/RDCOMClient/issues/36
Duncantl gave the solution and it works.
dir.create("MyTemp")
remotes::install_github("BSchamberger/RDCOMClient", ref = "main", lib = "MyTemp")
If that is successful, we can then load the newly installed package with
library("RDCOMClient", lib.loc = "MyTemp")
Is it possible to post install Requires dependecies in a spec file on Centos /RHEL 7?
I tried Requires: somepackage = 1.0.0.0
The problem is that I need to run a script prior to the dependencies being installed.
I tried to run that in the %pre section but it appears that it's not executed before the requires' %pre section is run and failing due to a missing license file.
The spec file looks like this:
Name: MyClient
Requires: MyServerPackage = 1.0.0.0
%pre
echo "Write license that is needed by MyServerPackage prior to install" > /tmp/mylicense
The problem is that I get an error: %pre(MyServerPackage) scriptles failed, exit status 1
Because the /tmp/mylicense is not there at the time MyServerPackages %pre script runs.
I've also tried to add a package called mylicense and adding a PreReq: mylicense. But no matter what I try I get that error from the check in MyServerPackage %pre.
I need to run a script prior to the dependencies being installed.
That's impossible; the dependency might have been installed two years ago, for all you know.
To answer where I think you're going, you can specify that something is required for a specific section with:
Requires: MyServerPackage
Requires(pre,preun): MyServerPackage
This would tell it (line 1) that to be installed, MyServerPackage should always be there. Then line 2 explicitly says it should be there before installing or attempting to uninstall this package if you're installing them at the same time. This is useful if, for example, the other package sets up a user name, etc.
In Anaconda I am trying to create an environment using an environment.yml file which begins with the lines:
name: mytest
dependencies:
- anaconda=4.0.0=np110py27_0
However when trying to create the environment, I get the error:
Fetching package metadata .........
Solving package specifications: ....
Error: The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
I encountered no problems when I did this seven days ago, but when I tried this yesterday I got the error.
I am running on Windows 7 64-bit as administrator, Anaconda 2.2.0 (Python 2.7 version). The "conda list" output includes conda 4.1.11 and conda-env 2.5.2.
To try to isolate the error, I installed Miniconda2 on a different 64-bit Windows 7 computer (as administrator) that had never had any Anaconda/Miniconda installed before. This is the most recent 64-bit Python 2.7 series (Miniconda2-4.1.11-Windows-x86_64.exe).
But trying to install anaconda=4.0.0=np110py27_0, either to a new environment or to the root environment, both produce the same error I received before:
C:\>conda install anaconda=4.0.0=np110py27_0
Fetching package metadata .........
.Solving package specifications: ....
The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
C:\>conda create --name test400 anaconda=4.0.0=np110py27_0
Fetching package metadata .........
.Solving package specifications: ....
The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
How can I determine what is causing the conflict, and how could I resolve it, given that conda is not naming a second package in its error message? I have seen responses to other "specifications in conflict" questions in which the answer is often "Install the problematic package to a separate python environment", but in this case the new environment could not be created with the package. Starting from a clean Miniconda install did not work either. I suspect something has changed in the Anaconda repository (which would be consistent with the original environment.yml working in the past but not now), but how would I determine if this is the underlying issue?
Thanks.
The underlying issue was a temporary error in the https://repo.continuum.io/pkgs/free/win-64/repodata.json file, which has since been fixed.
For reference for anyone investigating Anaconda dependency conflicts, here are the details of the investigation, and the workaround for this case:
The cause:
The repodata.json file (linked above) is essentially a 'master list' of the dependencies of the various libraries in https://repo.continuum.io/pkgs/free/win-64/. The "conda" command uses this repodata.json file.
While the problem was occurring, the repodata.json file incorrectly listed "_nb_ext_conf" as a dependency for each version of ipywidgets. (The /info/index.json file inside "ipywidgets-4.1.1-py27_0.tar.bz2" did not list "_nb_ext_conf" as a dependency, however I think newer versions of ipywidgets require it.)
The "_nb_ext_conf-0.2.0-py27_0.tar.bz2" and "_nb_ext_conf-0.3.0-py27_0.tar.bz2" files list "notebook >=4.2.0" as a dependency in their info/index.json files.
The info/index.json file in anaconda-4.0.0-np110py27_0.tar.bz2 file (which is used when you specify "anaconda=4.0.0=np110py27_0" in an environment.yml) lists "ipywidgets 4.1.1 py27_0" as a dependency.
Due to the temporary problem in repodata.json, this "ipywidgets 4.1.1 py27_0" caused conda to think "_nb_ext_conf" needed to be installed, thus causing conda to think "notebook >=4.2.0" also needed to be installed.
But the info/index.json file in anaconda-4.0.0-np110py27_0.tar.bz2 file also specifies that the specific version "notebook 4.1.0 py27_2" must be installed.
The conflicting requirements for "notebook" versions (4.1.0 and >=4.2.0) caused the "specifications were found to be in conflict" error.
The workaround:
First, remove the line "- anaconda=4.0.0=np110py27_0" from the environment.yml file.
Next, replace that line in environment.yml with every library listed in the "depends" section of the info/index.json file from anaconda-4.0.0-np110py27_0.tar.bz2. (Remove the quotation marks, replace the spaces with equals signs, etc. to convert the .json syntax to the environment.yml syntax.)
Finally, remove the "- notebook=4.1.0=py27_2" line from this list.
This new environment.yml file will now list every library which would have been installed by "anaconda=4.0.0=np110py27_0", with the exception of "notebook", but "notebook" will get installed anyway due to the "notebook >=4.2.0" requirement in "_nb_ext_conf" due to "ipywidgets", and/or the "notebook" requirement in "ipywidgets" itself.
Investigative tools:
The command "conda info anaconda=4.0.0=np110py27_0" gives the list of libraries required by the specified package, according to repodata.json. I put this list of libraries into a temporary_environment.yml file. Attempting to create an environment from that temporary_environment.yml file caused conda to specify that "notebook" was involved in the conflict, which gave the hint to try omitting "notebook".
Running "conda info" lists all the libraries currently installed in the active environment. The output for the environment created by temporary_environment.yml was compared to the output from an environment from a computer where "anaconda=4.0.0=np110py27_0" had previously installed successfully. This highlighted "_nb_ext_conf" as one difference.
I created a batch file which ran "conda info" for every library listed in anaconda=4.0.0=np110py27_0, and I looked for instances of "notebook" and "_nb_ext_conf" in the output. This pointed to "ipywidgets" as a suspect.
I'm using a koji to build a package. In error, it's saying:
Error: Package: pacemaker-cluster-libs-1.1.10-14.el6.x86_64 (build)
Requires: libcman.so.3()(64bit)
What does it exactly mean?
'libcman.so' is in the package 'cluster'. Then I built the clusterlib, and add it into my build, but didn't fix the problem after I put 'cluster' into 'BuildRequires' since another problem 'no package found for cluster' came out.
I think I'm not on the correct track.
I didn't fix it, but did some work around to avoid it. It's '.so', so I don't think the python module I build really need it here. So I commented it out from the spec file. and Just ensure I have these packages installed at the server before I install the new python module.
I'm trying to install GDAL via buildout on MacOSX. I have following config:
[gdal]
recipe = zc.recipe.cmmi
url = http://download.osgeo.org/gdal/gdal-1.7.2.tar.gz
extra_options =
--with-geos=${geos:location}/bin/geos-config
--with-static-proj4=${proj:location}
--with-jpeg={libjpeg:location}
--with-spatialite=${spatialite-lib:location}
--with-sqlite=${spatialite-lib:location}
I tried many other configurations but all I've got is the following error:
http://pastebin.com/s0WxfnUu
Any clues?
I've managed to resolve the problem - description below.
Just for the record - proper configuration for building GDAL on MacOSX (for example purposes I've cut off additional stuff):
[libiconv]
# ...
[gdal]
recipe = hexagonit.recipe.cmmi
url = http://download.osgeo.org/gdal/gdal-1.7.3.tar.gz
configure-options =
--with-python
--with-jpeg=internal
--with-spatialite=${spatialite:location}
CFLAGS=-I${libiconv:location}/include
LIBS="${libiconv:location}/lib/libiconv.la ${libiconv:location}/lib/libcharset.la"
You need to specify libiconv (in my example I'm building it from source) - it will prevent charset errors.
Also my problem was in the version of jpeglib, so I've definied --with-jpeg=internal so the GDAL will use it's own libs. Depending on the error you can use --with-png=internal, --with-tiff=internal etc.
Good luck!
Buildout is great for a lot of things, but even I tend to hand over some responsibility to the OS.
The whole whopping geo stack is one of those things. Gdal, geos, libproj4, mapnik, I don't know what. Compiling everything from source is just too cumbersome, especially as you have a lot of dependencies.
In your case, it looks like there's a mismatch in some of the libraries that gdal compiles against. Wrong length of arguments.
My tip is to install gdal and friends via your OS (so: windows installer, apt-get, rpm, whatever).