I'm seeing a somewhat peculiar error in Jenkins where a gem is being invoked correctly, but the error is spitting out an option with a whitespace character between the options identifier (--) and the option name (checksum).
gemname publish_artifact --version 0.1.0 --checksum 01fakechecksum89 --repository release
publish_artifact: unrecognised option -- checksum
I checked the Jenkins node and the option is available. I haven't run the command because the deployment is not mine to make, I'm just on the ops team and am not really that familiar with Ruby yet.
I ran a command with a fake option for a different gem and got a different error response.
$ yard list --fakename blah
[warn]: Unrecognized/invalid option: --fakename
Notice no whitespace between the option specifier and the name. I'm digging into the Jenkins pipeline configuration because it is quite complex, and maybe the command is getting butchered between the master and the node, but it just doesn't make much sense to me.
It turned out to be a rather misleading error. The problem was that gem failed to update to the newest version. The older version didn't have the checksum option.
Related
I'm trying to install frama-c on my distro of manjaro 18.1.5, but no matter what I try, I always have an error.
First I tried to install via the AUR, and it seems to work, but when i try to open a file from the gui, it fails and says something like "invalid user input" even though I use files that works on a known good install.
Edit: here is the error output for this file:
[kernel] Parsing max.c (with preprocessing)
[kernel:annot-error] max.c:2: Warning:
unbound logic variable INT_MIN. Ignoring logic specification of function max
[kernel] User Error: warning annot-error treated as fatal error.
[kernel] User Error: stopping on file "max.c" that has errors. Add '-kernel-msg-key pp'
for preprocessing command.
Then I tried to install it using opam, so I first try to install dependencies with depext but it does not install anything then when I tried to install frama-c, it fails with the following error :
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ERROR] The compilation of frama-c failed at
"/home/benoit/.opam/opam-init/hooks/sandbox.sh build make -j7".
#=== ERROR while compiling frama-c.20.0 =======================================#
# context 2.0.5 | linux/x86_64 | ocaml-system.4.09.0 | https://opam.ocaml.org#2d21a0b6
# path ~/.opam/default/.opam-switch/build/frama-c.20.0
# command ~/.opam/opam-init/hooks/sandbox.sh build make -j7
# exit-code 2
# env-file ~/.opam/log/frama-c-4880-6d07ae.env
# output-file ~/.opam/log/frama-c-4880-6d07ae.out
### output ###
# [...]
# Ocamlopt src/plugins/value/legacy/eval_terms.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_transfer.cmx
# Ocamlopt src/plugins/value/legacy/eval_annots.cmx
# Ocamlopt src/plugins/value/engine/transfer_logic.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_domain.cmx
# /usr/bin/ld: cannot find -lgtksourceview-2.0
# collect2: error: ld returned 1 exit status
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_specification.cmx
# File "_none_", line 1:
# Error: Error while building custom runtime system
# make: *** [Makefile:1294: bin/viewer.byte] Error 2
# make: *** Waiting for unfinished jobs....
My final attempt was to build it from source, but the make fails with the following error :
Ocamlc src/plugins/server/jbuffer.cmo
File "src/plugins/server/jbuffer.ml", line 23, characters 12-26:
23 | type json = Yojson.Basic.t
^^^^^^^^^^^^^^
Error: Unbound type constructor Yojson.Basic.t
make: *** [share/Makefile.generic:78: src/plugins/server/jbuffer.cmo] Error 2
My only remaining solution is to use a VM with debian but it's really ideal for me...
Does anyone have an idea of what i could do?
Thank you!
There are multiple issues in your question, and I believe some of them are worthy of investigation as possible bugs or issues. I'd recommend trying one of the official Frama-C support channels:
Creating an issue in the Frama-C Gitlab public repository;
Or creating an issue in the Frama-C Github snapshot repository (currently being deprecated in favor of the Gitlab repository, which is updated daily);
Or trying some interactive opam-related support in the IRC #frama-c channel on freenode.net (interactive support is often more efficient for installation issues related to opam, especially since it's hard to know in advance which information might be useful).
Dealing with "Invalid user input" errors in the GUI
As a general rule, when trying to open a file in the GUI fails, I'd recommend running the command-line version of Frama-C with the filename. Its output is much more detailed and can indicate if there are parsing issues with the file (which could be due to missing dependencies, non-C99 syntax, or configuration problems).
Otherwise, the Console tab in the GUI should contain detailed error messages, which you could then add to this SO question, in case they are relevant to understand your issue.
Issues with graphical libraries in non-major Linux distributions
The second issue I can see in your question, is the error related to -lgtksourceview-2.0. This means that one of the library dependencies for the graphical interface is missing. Maybe there's a way to fix it, but at the very least it should be possible to identify the error before compilation, and report the incompatibility earlier. The fact that depext did not work is unusual; maybe it's not currently well-supported for Manjaro, but it's worth investigating. Unfortunately, opam can sometimes be complex to handle for first-time users, so I understand it's a bit frustrating and may take more time than you'd want. But if you intend to use Frama-C or other OCaml packages for some reasonable amount of time, it is worth understanding some of the common errors in opam, since it is very useful for handling dependencies.
Handling issues with OCaml dependencies when compiling manually
Finally, the issue with Yojson is probably due to the version of the package that is installed. In particular, versions before 1.6.0 do not have the type Yojson.Basic.t. Frama-C used to support 1.4.1, but the latest version requires at least 1.6.0. Again, it's not obvious to spot in advance all possible issues with different package versions, but reporting them allows us to include checks to prevent it in the future, or at least to give a more precise error message.
Normally opam handles that part, hence why it's recommended even for manual compilation of Frama-C, since it helps manage its dependencies.
Overall, it seems that some underlying issue with the dependencies in opam depext is preventing the whole chain from working properly. Your report does contain much useful information but not all the details, so I believe the interactive route should allow to quickly converge towards a working installation.
Please help me I am being tortured by the linting squiggly and I cannot get rid of it. Here is the context
working in vscode 1.37.0
on a chef project (mostly ruby syntax)
I have the chef extension installed and chefdk installed an available in my path
And for the life of me I cannot get the linting warning for Style/PercentLiteralDelimiters to go away. I will get this warning when I am using []
Then if I make the suggested change to () it wants me to flip it the other way.
I get the same results if I specify this rule in my rubocop.yml
Style/PercentLiteralDelimiters:
Enabled: true
PreferredDelimiters:
default: '[]'
I know this is an obscure issue and if there is any further information that would help I will be happy to supply it but for my sanity I would really like to figure this out.
Update
Running rubocop from the command line does not report any issue. I believe that vscode is using chefdk's foodcritic. As according to the extension If you have the ChefDK installed, Foodcritic should "just work" on Windows. My understanding is foodcritic is just rubocop with a special config for chef style conventions. But even running foodcritic from the command line does not seem to report these as an issue.
I have even tried to be explicit in the vscode workspace settings, by setting the configFile path for both rubocop and foodcritic but this has not changed anything. Seems more and more like an issue the extension. Found this issue that sounds related. Might just have to watch this issue https://github.com/pendrica/vscode-chef/issues/29
So thanks to the comment from Draco Alter I was able to figure out the issue I had.
First I had a miss understanding about Foodcritic and was conflating it with cookstyle. After understanding that and the comment that Draco made saying
Some of the rules in Cookstyle and Rubocop are conflicting - and %w
is one of them.
I figured I would favor cookstyle as I am using ruby exclusively for chef. So I ensured rubocop was gone gem uninstall rubocop and then I just needed to update my vscode workspace settings to have from
{
"ruby.lint": {
-- "rubocop": true
++ "cookstyle": true
}
}
I installed vargrant in my windows 7, my VM box is CentOS 6, well vagrant is working fine.But now I want to install rsync-back for syncing my VM files to Windows, I am getting few errors.
When I use the command in CMD windows,
vagrant plugin install vagrant-rsync-back
I get the below errors
Installing the 'vagrant-rsync-back' plugin. This can take a few
minutes... Bundler, the underlying system Vagrant uses to install
plugins, reported an error. The error is shown below. These errors are
usually caused by misconfigured plugin installations or transient
network issues. The error from Bundler is:
Could not fetch specs from http://gems.hashicorp.com/
Warning: this Gemfile contains multiple primary sources. Using
source more than once without a block is a security risk, and may
result in installing unexpected gems. T o resolve this warning, use a
block to indicate which gems should come from the secondary source. To
upgrade this warning to an error, run bundle config disable_multisou
rce true.
I am pretty new to vagrant, I am unable to solve this issue. Any suggestion where I am doing wrong ?
The "multiple primary sources" warning you are seeing is just that: a warning. The error that prevented the installation was the "Could not fetch specs from ..." part you see above the warning.
My guess is just that this gem server was down at the time you tried to install it. In fact, it looks like someone reported a similar issue on the vagrant github repository back in July, and one of the top contributors guessed exactly that: https://github.com/mitchellh/vagrant/issues/5966
Have you tried it again to see if the issue has gone away (the gem server appears to be up for me)?
I am a beginning programmer trying to install the Python Protocol Buffers from this package: http://code.google.com/p/protobuf/downloads/detail?name=protobuf-2.4.1.zip
The readme states:
1) Make sure you have Python 2.4 or newer. If in doubt, run:
$ python -V
2) If you do not have setuptools installed, note that it will be
downloaded and installed automatically as soon as you run setup.py.
If you would rather install it manually, you may do so by following
the instructions on this page:
http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions
3) Build the C++ code, or install a binary distribution of protoc. If
you install a binary distribution, make sure that it is the same
version as this package. If in doubt, run:
$ protoc --version
4) Run the tests:
$ python setup.py test
If some tests fail, this library may not work correctly on your
system. Continue at your own risk.
Please note that there is a known problem with some versions of
Python on Cygwin which causes the tests to fail after printing the
error: "sem_init: Resource temporarily unavailable". This appears
to be a bug either in Cygwin or in Python:
http://www.cygwin.com/ml/cygwin/2005-07/msg01378.html
We do not know if or when it might me fixed. We also do not know
how likely it is that this bug will affect users in practice.
5) Install:
$ python setup.py install
This step may require superuser privileges.
NOTE: To use C++ implementation, you need to install C++ protobuf runtime
library of the same version and export the environment variable before this
step. See the "C++ Implementation" section below for more details.
I have added both python and version 2.4.1 of protoc.exe into my PATH. However, when I try to run the test, I get an error message that says there's invalid syntax on line 38:
print "Can't find required file " + source
Okay, so it's missing parenthesis. I add them, and it encounters two more print statement syntax error messages. I fix those, and it encounters a syntax error message on an 'except' statement. What am I doing wrong?
Thanks.
Perhaps you are using Python 3?
The code you refer to will only work in Python 2.X
I have followed same steps , but I didn't get any errors.
Please make sure that you are getting correct Python and protoc version.
Export the environment LD_LIBRARY_PATH variable.
I get a slightly heisen error from eventmachine (0.12.10, on OSX 10.6.4):
terminate called after throwing an instance of 'std::runtime_error'
what(): no loop breaker
It only occurs in tests, and only when all tests are run together. Run individually they pass.
I spotted the only place in the eventmachine code that mentions the error's message:
http://github.com/eventmachine/eventmachine/blob/master/ext/em.cpp#L333
(What puzzles me as well is that it looks like a win32 code path, or am I wrong?)
To me it looks like some ressource like sockets are used up. That would explain the occurence pattern.
Ok, I found it myself.
The error comes in fact from the win32 conditionally compiled code. I get a plain old "Too many open files" error if I build locally, and that problem is easy to releave by increasing the ulimit value for open files (which is said to be quite modest by default on OSX).
ulimit -n 1024 # or whichever value you find appropriate
(Default is 255, look at the output of ulimit -a)
If I build and install from the cloned git repository using rake gem:install, I get the expected (Unix) error message. So the bug appears to be fixed in master.
Filed bug for the rubygems.org gem is here: http://github.com/eventmachine/eventmachine/issues#issue/88