This issue was discovered after upgrading from ChefDK 3.2.30 to 4.2.0, and everything worked fine before the upgrade (Including these two commands).
The full error from "knife node list":
C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/rbvmomi-1.13.0/lib/rbvmomi/vim.rb:8: warning: Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead
Traceback (most recent call last):
8: from C:/opscode/chefdk/bin/knife:359:in <main>' 7: from C:/opscode/chefdk/bin/knife:359:inload'
6: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-15.1.36-universal-mingw32/bin/knife:24:in <top (required)>' 5: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-15.1.36-universal-mingw32/lib/chef/application/knife.rb:162:inrun'
4: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-15.1.36-universal-mingw32/lib/chef/knife.rb:221:in run' 3: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-15.1.36-universal-mingw32/lib/chef/knife.rb:440:inconfigure_chef'
2: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-15.1.36-universal-mingw32/lib/chef/knife.rb:185:in load_config' 1: from C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-config-15.1.36/lib/chef-config/workstation_config_loader.rb:72:inload'
C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-config-15.1.36/lib/chef-config/mixin/credentials.rb:92:in load_credentials': undefined local variable or methodcredentials_file' for #<ChefConfig::WorkstationConfigLoader:0x000000000c311e68> (NameError)
The full error from 'kitchen converge':
------Exception-------
Class: Kitchen::ClientError
Message: Could not load the 'chef_zero' provisioner. Error: undefined local variable or method `credentials_file' for #<ChefConfig::WorkstationConfigLoader:0x0000000006f176a0>
Did you mean? credentials_profile
credentials_found
#credentials_found
----------------------
Please see .kitchen/logs/kitchen.log for more details
Also try running kitchen diagnose --all for configuration
We found that the problem in this case was an invalid profile being requested.
The profile can be set either with the CHEF_PROFILE environment variable, or in a file named 'context' in the users home .chef directory (~/.chef on Linux, C:\Users\username.chef on Windows).
If a profile other than 'default' is specified, than the ChefDK looks for a file named 'credentials' in that same directory. It will then parse that file and look for a section matching the profile name.
If it doesn't find a matching profile, then it will generate errors like the one in the question.
To fix the problem for this user, we changed the value of the 'context' file to "default" (without quotes) and everything started working again.
There are several possible resolutions, which one is best for you depends on where the problem comes from
If the profile name is valid, then add the proper section to the ~/credentials file
If the value of the CHEF_PROFILE environment variable is the problem, change it to "default" or to a valid name
If the value of the ~/context file is the problem, than you can either delete it, or change the value in it to a valid profile (NOTE: Always make a back up of the file before deleting or making changes)
I found the details listed above that led me to the resolution by going through the code in C:/opscode/chefdk/embedded/lib/ruby/gems/2.6.0/gems/chef-config-15.1.36/lib/chef-config/mixin/credentials.rb (which was where the initial exception was thrown)
Related
I just tried the standalone PyQGIS application by running the custom script "Proximity.py"* in a VS Code project without the need of a GUI (such as QGIS).
But, when I run the python-program I get the following message:
proj_create_from_database: C:\Program Files\PostgreSQL\14\share\contrib\postgis-3.2\proj\proj.db contains DATABASE.LAYOUT.VERSION.MINOR = 0 whereas a number >= 2 is expected. It comes from another PROJ installation. (see also: Error Message after launching the configuration (launch.json) from VS Code (when pressing F5))
I'm trying this online example with the following installations:
PostgreSQL 14
Python39
.vscode\extensions\ms-python.python-2022.4.1\pythonFiles\lib\python\debugpy\launcher
osgeo4w-setup.exe (including QGIS LTR)
I read that there is a solution by undefining [PROJ_LIB] before importing pyproj or osgeo: del os.environ ['PROJ_LIB'] as described under this link. If this is also supposed to be the correct solution in this case, can someone help me with step-by-step instructions (for dummies)?
. * The "Proximity.py" script is a pyqgis standalone example from "https://github.com/MarByteBeep/pyqgis-standalone"
Finally, I got a solution to be able to run the "standalone PyQGIS"* example "Proximity" (provided by MarByteBeep).
This solution was possible without needing to launch the configuration file "launch.json" as above described. And so, avoiding the need to make any configuration to the environment variable "PROJ_LIB" by trying to circumvent the above issue.
I just first added the following two code-lines (see here line 2 and 3) in the python file "main.py" so as to be able to use the plugin "PROCESSING" (initially line 8 of the "main.py" file), then I store it and finally I ran it.
Line 1: from qgis.core import
Line 2: import sys
Line 3: sys.path.append('C:\Program Files\QGIS 3.24.1\apps\qgis\python\plugins')
Line 4: qgs = QgsApplication([], False)
Line 5: ...
The Proximity example is based on the answer of "Mar Tjin" to the following Question: "Looking for manual on how to properly setup standalone PyQGIS without GUI"
. * By "Standalone PyQGIS" I refer to code/scripts that can be run outside the QGIS-GUI (=> QGIS-Desktop/Server Application). In my case under the external Editor VS Code
I'm upgrading from SoapUI 5.4.0 to 5.7.0 and trying to put the log files in a specific directory. Note: The alternate error logs directory was working prior to the upgrade.
I have both the following specified in my JAVA_OPTS for SoapUITestCaseRunner
-Dsoapui.logroot="%SOAPUI_LOGSDIR%"
-Dsoapui.log4j.config="%SOAPUI_HOME%/soapui-log4j.xml"
In my soapui-log4j.xml I specify the error file as:
<RollingFile name="ERRORFILE"
fileName="${soapui.logroot}/soapui-errors.log"
filePattern="${soapui.logroot}/soapui-errors.log.%i"
append="true">
The error file then gets created without resolving ${soapui.logroot} e.g.
$ find . -name "*errors*"
./${soapui.logroot}/soapui-errors.log
I also tried it as lookup but ended up with this:
ERROR Unable to create file ${sys:soapui.logroot}/soapui-errors.log java.io.IOException: The filename, directory name, or volume label syntax is incorrect
Am I missing anything? Any ideas for next steps?
I tried replacing
fileName="${soapui.logroot}/soapui-errors.log"
with
fileName="${sys:soapui.logroot}/soapui-errors.log"
and it worked for me.
I no longer see unresolved '${soapui.logroot}' directory created.
A
I'm trying to set the "noImplicitAny": true option for an existing TypeScript project. After making all the necessary code changes I'm getting the following error for one of our dependencies on Node 6 and 7:
Could not find a declaration file for module '#firebase/database'. '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js' implicitly has an 'any' type.
This works fine on Node 8 (both locally and on Travis CI).
Does anybody know why this is? I can kind of understand the error, but no clue why it happens only on certain versions of Node.
Edit
Added the traceResolution option, and I do see a difference in how the dependency gets resolved between Node 7 and 8.
On Node 8:
'package.json' has 'typings' field 'dist/index.d.ts' that references '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts' exist - use it as a name resolution result.
Resolving real path for '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts', result '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
======== Module name '#firebase/database' was successfully resolved to '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'. ========
On Node 7:
'package.json' has 'typings' field 'dist/index.d.ts' that references '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts' does not exist.
Loading module as file / folder, candidate module location '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts', target file type 'TypeScript'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts.ts' does not exist.
...
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js' exist - use it as a name resolution result.
Resolving real path for '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js', result '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js'.
======== Module name '#firebase/database' was successfully resolved to '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js'. ========
Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
(:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?
If I create a new project, I can click on it in my list and see the project just fine. However if I commit changes locally and push them to the remote I get an error trying to view the project's page, I get a 500 error. The production log shows the following error:
ActionView::Template::Error (undefined method `sha' for nil:NilClass):
39: = link_to project_compare_index_path(#project, from: #repository.root_ref, to: #ref || #repository.root_ref), class: 'btn btn-block' do
40: Compare code
41:
42: - if #repository.readme
43: - readme = #repository.readme
44: = link_to project_blob_path(#project, tree_join(#repository.root_ref, readme.name)), class: 'btn btn-block' do
45: = readme.name
app/models/repository.rb:177:in `tree'
app/models/repository.rb:161:in `block in readme'
app/models/repository.rb:160:in `readme'
app/views/projects/show.html.haml:42:in `_app_views_projects_show_html_haml___610828608301993518_70108750838020'
app/controllers/projects_controller.rb:69:in `block (2 levels) in show'
app/controllers/projects_controller.rb:63:in `show'
Started GET "/david/striker" for 99.73.162.163 at 2014-07-14 01:22:24 -0400
Processing by ProjectsController#show as HTML
I wanted to take a look at this in the console, but that doesn't seem possible. Unfortunately I don't know the password to the postgres database so I couldn't look inside the console either. It appears that the repository variable is nil inside the template.
Anyone have any ideas?
As mentioned in issue 417, check your Ruby version:
While reverting back to 6.9.2 I add the same exact problem, which made me revert the ruby version 2.1.2p95, to the one I add before: "ruby 2.1.0p0 (2013-12-25 revision 44422)" I gave another try to gitlab 7.0 with the old ruby version and the error described before does not happen anymore
So try to see if ruby 2.1.0 works (Dec. 2013), because a more recent ruby (like 2.1.2, May 2014) might not.