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.
Related
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
Following on from here, when using OpenSUSE Tumbleweed I cannot get flatpak-builder to compile submodule dependencies. I first noticed this issue when developing a console application within Gnome Builder using the Vala dependencies Gee and GXml.
As a test, I have installed org.gnome.Books.json and issued the following command (as documented here):
$ flatpak-builder --repo=repo books-app org.gnome.Books.json
The outcome is the same as I observed when developing my own application, the fatal error:
Initializing build dir
Committing stage init to cache
Starting build of org.gnome.Books
fuse: failed to exec fusermount: Permission denied
<more stuff>
Cloning into '/home/robin/Projects-CSim/org.gnome.books/.flatpak-builder/build/gnome-online-accounts-1/telepathy-account-widgets'...
Submodule path 'telepathy-account-widgets': checked out '7d944b79961dfb6291110ceb27597a224d329b36'
error: Build directory /home/<user>/Projects/org.gnome.books/.flatpak-builder/rofiles/rofiles-D4R4cZ not initialized, use flatpak build-init
Error: module gnome-online-accounts: module gnome-online-accounts: Child process exited with code 1
Effectively it fails to build the very first submodule. This is the same behaviour that I observed when invoked from Gnome-Builder on my project; it downloaded but failed to build the very first submodule - in that case it was libgee-0.8.
I've double checked the Flatpak (V0.10.4) installation here and cannot find a solution. I understand from the documentation that invoking flatpak-builder should automatically invoke flatpak build-init.
This is worrisome as Gnome-Builder seems be using Flatpak as the default packager. Any suggestions?
The problem is not Flatpak. It is a conflict between Flatpak and fuse. For some reason this was not occuring with valac or meson from the command line, only Flatpak.
From here we find a solution:
# chmod +x /usr/bin/fusermount
Is this a peculiarity of OpenSUSE Tumbleweed? In any case, after making this change, Flatpak builds submodules as expected. Magnificent!
Not sure about the security aspect of this, however - any comments would be welcomed.
include sympy python packages into Chaquopy:
I started with the example python provided by Chaquopy available at github (https://github.com/chaquo/chaquopy) for Android studio 3.0.1.
Than I created 2 wheel files from the sympy source () files, based on python 3.6.3, see the below files that wheel generated:
"mpmath-1.0.0-py3-none-any.whl"
"sympy-1.1.1-py3-none-any.whl"
I tried to install the above files into the build.gradle of the demo example from 1., for testing purposes I tried some of there own wheel files (that process succeeded), but could not install my own wheel files.
I am fairly certain that the local wheel files that I generated are placed in the proper directory, because if I change the directory in the gradle file it complains that it cannot find the file.
I included the wheel files in the build.gradle(Module:app) file as follows:
python {
// Enable and edit the following line if "python" is not on your PATH.
// buildPython "C:/Python27/python.exe"
version "3.6.3"
// Android UI demo
pip {
install "Pygments==2.2.0" // Also used in Java API demo
}
pip {
install "wheels/mpmath-1.0.0-py3-none-any.whl"
// install "wheels/sympy-1.1.1-py3-none-any.whl"
// install "numpy==1.9.2"
// install "numpy==1.14.0"
}
When created the build gradle generates the following error:
sympy-1.1.1-py3-none-any.whl is not a supported wheel on this platform.
Exit status 1
:app:generatePy2DebugPythonRequirements FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':app:generatePy2DebugPythonRequirements'.
Process 'command 'python'' finished with non-zero exit value 1
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Get more help at https://help.gradle.org
BUILD FAILED in 2s
7 actionable tasks: 1 executed, 6 up-to-date
Does anyone have an idea what could be wrong?
sympy and mpmath have now been added to the Chaquopy wheel repository (https://github.com/chaquo/chaquopy/issues/20), so you don't need to build your own anymore.
Did some further investigation and did see that I somehow compiled for Py2, while my wheel files where version 3 changing this resulted in a correct executable.
It did run into a different issue, while the mpmath module could be imported into the interactive python console (part of the demo app), the sympy module gave an error:
ModuleNotFoundError: no module named 'distutils'
Let me know if anyone ran into a similar problem!
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 need to install ocropus on Ubuntu 11.04.
I went through a long and painful process of trying ocropus 0.3 and 0.4 from the project's Downloads page, but to no avail - I could find no way of making it locate tesseract, which it recommended. I labored on Google and came across the page http://code.google.com/p/ocropus/wiki/InstallTranscript.
Great. Except when I issue the command:
hg clone $release https://ocropus.googlecode.com/hg/ ocropus
I get the error message:
abort: unknown revision 'ocropus-0.4.4'!
A post here http://aur.archlinux.org/packages.php?ID=13444 by the maintainer of the ocropus package for archlinux says
they have completely refactored ocropus and at the same time they have also completely removed the old repository so it's not possible to access the old "stable" versions. I suggest using the ocropus-hg package, at least for the time being.
I thought I would go ahead with this idea and issued the command:
hg clone https://ocropus.googlecode.com/hg/ ocropus #I deftly avoid any
mention of the release
The result is I get a folder with a file interestingly named ocroinst. I run it and it says I need to run the following commands:
sudo ./ocroinst packages #checks the dependencies
./ocroinst install #installs ocropus
sudo ./ocroinst dl #downloads models
I was glad and I issued the first command, which is when I got the message:
Package libjpeg8-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package libjpeg8-dev has no installation candidate
I think a certain Murphy may have had a point.
The situation, with an delicious added complication, is this:
(please correct me if I am wrong)
Ubuntu 11.04 comes with libjpeg62-dev. The required version for ocropus is libjpeg8-dev.
Ocropus requires libtiff4-dev, and libtiff4-dev depends on libjpeg62-dev. Therefore there is no way for me to uninstall libjpeg62-dev.
libjpeg62-dev conflicts with libjpeg8-dev. Therefore, I can have only one of libjpeg8-dev or libjpeg62-dev, and never both.
If libjpeg8-dev is installed, I will have no libjpeg62-dev, which means I must remove libtiff4-dev and therefore have no way to install ocropus.
If libjpeg62-dev is installed, I will have no libjpeg8-dev and thus I will have no way to install ocropus.
NOTE:
(An experiment description)
I had libjpeg62-dev installed on the system already. I figured I could take a chance and I went right ahead and changed every libjpeg8-dev I could find to libjpeg-dev, and ran the 3 commands.
It installed. No error.
This gave me great joy
until
I ran the command
ocropus <image-file-name>
and I was greeted by the charming:
ImportError: /usr/local/lib/python2.6/dist-packages/_iulib.so: undefined symbol: _ZN5iulib6dcloseEv
The more sophisticated
ocropus book2pages out image*
failed with the same error. A post on stack overflow indicates that this is caused by incorrectly versioned libraries.
THE QUESTION:
How should I proceed?
Thanks in advance.