I wish to use CTF conversion with perf. From the scarce information around, I've figured out that I need to recompile perf.
I've installed the epel repository and used yum to install
babeltrace and libbabeltrace
for the run time as well as
libunwind-devel slang-devel libbabeltrace-devel and asciidoc
for compilation.
I cloned git.kernel.org (as alternative I also tried github.com/torvalds) and used
LIBBABELTRACE=1 make
to build the perf with babeltrace support. However, I get the error:
Makefile.config:780: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
So I try adding LIBBABELTRACE_DIR with /usr but this, too, fails. Checking out the Makefile.conf, I see that the configuration is looking in the wrong places: it is set up to use a locally compiled babeltrace with well defined subdirectories (include and lib), but these are NOT used when installing from rpm (yum). The rpm places them in /usr/include/babeltrace and /usr/lib64.
Patching the Makefile also doesn't help.
So, short of being forced to use a locally compiled babeltrace, what options do I have?
This is for a cluster of 26 nodes and I really would prefer a simple 'yum install' as this simplifies restaging nodes when the get corrupted (we do research with them and regularily corrupt stuff) and does not require setting specific environments.
ADDENDUM:
I tried compiling babeltrace from https://github.com/efficios/babeltrace.git: this, too, fails with the error:
babeltrace-cfg-cli-args.c:2390:29: error: ‘POPT_ARG_LONGLONG’ undeclared (first use in this function)
and, surely enough, popt.h does not define POPT_ARG_LONGLONG.
Thanks in advance.
Related
I cannot opam init:
$ opam init --verbose
[NOTE] Will configure from built-in defaults.
Checking for available remotes: rsync and local, git, mercurial.
- you won't be able to use darcs repositories unless you install the darcs command on your system.
<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[ERROR] Could not update repository "default": OpamDownload.Download_fail(_, "Curl failed: \"/usr/bin/curl --write-out %{http_code}\\\\n --retry 3 --retry-delay 2
--user-agent opam/2.0.7 -L -o /tmp/opam-1697-6d07ae/index.tar.gz.part https://opam.ocaml.org/index.tar.gz\" exited with code 28")
[ERROR] Initial download of repository failed
However, I've manually downloaded index.tar.gz. How to manually specify index.tar.gz to opam init?
System info:
$ uname -a
CYGWIN_NT-10.0-19043 xxx 3.4.5-1.x86_64 2023-01-19 19:09 UTC x86_64 Cygwin
P.S. I'm trying to build one project using OCaml, but it turned out that it is very tricky: either OCaml complains about compatibility (is not a compiled interface for this version of OCaml followed by It seems to be for an older version of OCaml; does it mean that OCaml is not backward compatible?), either opam init fails, either <whatever>.
Your error message indicates that you either have network problems or very poor connection. Also, you opam version is very old, so it might not handle bad networks very well, I would suggest your installing a newer version of opam (at least 2.1.x), or, if it is possible, switching to docker or a virtual machine.
Answering your original question: I don't think there is a way (at least officially supported to specify your own downloaded index). Also, if you have trouble with downloading the index it most likely means that you will have more trouble in the future with your network when opam will start downloading actual packages.
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.
Based on the bug report filed here, Gnash will not compile with the latest giflib. I assume that means that if I use an older giflib, it'll compile just fine. I'm not sure how to do this, though - my package manager (I'm on Manjaro, and have access to AUR) doesn't seem to help here, and I'm not sure what I would have to modify or do in such a case anyway.
Basically, after I get the code for Gnash from Savannah, what would I need to do/change to make it compile using an older giflib?
If you haven't already seen it, as Raydel notes there has been a reply to your request for a workaround on the bug report itself.
This is certainly the quicker solution, though there is nothing wrong with having two versions (or just the older, working) version of the GifLib library on your system.
To do that, you can download GifLib v4.2.3 here, a version older than the change that breaks gnash compilation.
Either place it in a different directory (you probably have v5.1 in /usr/local/lib?) and change the include/linker paths or replace v5.1 files in-place and you shouldn't need to change your compilation steps at all.
Trying the same steps myself, I have been unable to replicate your error.
Excluding sudo apt-get install-ing numerous packages (which aren't the cause of your troubles - and at every step I was told exactly what was missing) these were my steps on a fresh installation:
$ git clone git://git.sv.gnu.org/gnash.git
$ curl http://sourceforge.net/projects/giflib/files/giflib-4.x/giflib-4.2.3.tar.bz2/download
$ tar xvjf giflib-4.2.3.tar.bz2
$ cd giflib-4.2.3
$ ./configure
$ sudo make
$ sudo make install
$ cd ../gnash
$ ./autogen.sh
$ ./configure.ac
$ sudo make
$ sudo make install
I recommend you begin afresh, since these steps took care of everything for me - without any manual moving of files, specifying compiler/linker options or editing of makefiles which seems to be causing you problems.
Well I, just checked the bug report you have posted. And there is a workaround:
As a workaround, you can change line 123 of libbase/GnashImageGif.cpp file as follows:
GifInput::~GifInput()
{
// Clean up allocated data.
- DGifCloseFile(_gif);
+ DGifCloseFile(_gif, 0);
}
EDIT: According to my experience, it is better practice to apply the patch. If you use an older version of giflib you will miss any change made in the newer version. And those changes most of the time are for good, bug fixes, optimization ect ..
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.
Does anyone have any experience with trying to install cairo for django using buildout?
It will install pycairo or py2cairo (the first is for python >3.0, the latest is for python 2.6, which I Am using)
I found 2 recipes to use for installation, both of them gives me errors, in buildout.cfg I have them as 2 parts (of course tried them seperately, not thogether).
The errors are totally different, but the result is the same: I can't get cairo installed using buildout.......
based on: http://pypi.python.org/pypi/tl.buildout_gtk/
[cairo_tl]
recipe = tl.buildout_gtk
#pycairo-url = http://cairographics.org/releases/py2cairo-1.10.0.tar.bz2
pycairo-url = http://cairographics.org/releases/py2cairo-1.8.10.tar.gz
pycairo-md5sum = http://cairographics.org/releases/py2cairo-1.8.10.tar.gz.md5
based on: https://bitbucket.org/lgs/yaco.recipe.pycairo
[cairo_yaco]
recipe = yaco.recipe.pycairo
find-links = http://pypi.python.org/pypi/yaco.recipe.pycairo/0.1.1
#find-links = http://pypi.python.org/pypi/yaco.recipe.pycairo/0.1
# pkg-config-path ?
Both need a local install of cairo (pycairo and py2cairo depend on this):
so use on the server:
sudo apt-get install libcairo2-dev
The part jusing tl.buildout_gtk:
Either using the py2cairo-1.10.0 or pycairo-1.8.2 gives me a MD5 checksum mismatch
(see for available releases: http://cairographics.org/releases/)
e.g:
Error: MD5 checksum mismatch downloading 'http://cairographics.org/releases/py2cairo-1.10.0.tar.bz2'
or:
Error: MD5 checksum mismatch downloading 'http://cairographics.org/releases/py2cairo-1.8.10.tar.gz'
The part jusing yaco:
I Am pretty sure this part is not configured correctly (pkg-config-path refering to the local cairo package), but I do not even get to that point.
It gives an error:
DistributionNotFound: zc.recipe.cmmi
However, this is installed in the eggs
By the way, I had the same kind of headache trying to install PIL by buildout, which I solved combining a lot of options and posts on the internet, together with a lot of time and trials and errors.
If anyone want to know how I finally got it working, just ask, and I will publish it.
(I consider myselve still a django starter, so I do not know for sure if anyone is interested in the solution)
PIL does not have all the options I found in cairo, so I started using cairo. On my local PC everything works fine (ubuntu desktop), on my server (Ubuntu server) I can't getting it to work......
Any other options for making drawings on the fly..... (like matplotlib...) let me know.
Pretty sure you have to give the real md5 hash to the pycairo-md5 option instead of a string with some url in it.
I would avoid specialized recipes like those two whenever possible. There are some cases when a specialized recipe really is needed, but those are cases where the dependency is so egregiously eccentric that no common build/install pattern is usable. I don't know pycairo so that may be the case.
But before assuming it is, try the following. Always try using an egg first by adding it to the eggs option of the relevant buildout part. If that doesn't work, update your question with those details, and then try adding a separate zc.recipe.egg part with build options that may help the distribution build successfully. If that doesn't work or the distribution uses a ./configure && make && make install (AKA "CMMI") build system, update your question with those details, and then try using zc.recipe.cmmi to build the package after which you can use the extra-paths option of your zc.recipe.egg part to include the relevant bits of the CMMI part (extra-paths = ${cmmi-part:location}/weird/path/to/python/modules).
This is the general dance for getting poorly/oddly behaved distributions. If this doesn't work, then a specialized recipe may be in order but in general there's a way to get it to work with the above and that will be much more maintainable.