I've seen the following issue mentioned in another thread a few days ago amongst other problems, but the solution for this issue (to me) didn't seem to be addressed.
I recently ran a test on my Ruby 1.9.2-p290 environment and was presented with the following error when I ran a test script:
You are using an old or stdlib version of json gem
Please upgrade to the recent version by adding this to your Gemfile:
gem 'json', '~> 1.7.7'
This issue continued when I created a completely fresh Ruby 1.9.3-p392 environment, running on Windows XP (don't ask). What confuses me is that even when I have json 1.7.7 or 1.8.0 installed (gem list is pasted below), I still get this message when I run my test. It's not really affecting my test results, but the warning is just rather annoying to see each time.
Which Gemfile do I need to add this version into, and where would it be located?
gem list:
bigdecimal (1.1.0)
childprocess (0.3.9)
commonwatir (4.0.0)
ffi (1.8.1 x86-mingw32)
io-console (0.4.2, 0.3)
json (1.8.0, 1.7.7, 1.5.5)
mini_portile (0.5.0)
minitest (5.0.0, 2.5.1)
multi_json (1.7.3)
rake (10.1.0.beta.3, 10.0.4, 0.9.2.2)
rdoc (4.0.1, 3.9.5)
rubygems-update (2.0.3)
rubyzip (0.9.9)
selenium-webdriver (2.32.1)
watir-webdriver (0.6.4)
websocket (1.0.7)
win32-api (1.4.8 x86-mingw32)
win32-process (0.7.2)
windows-api (0.4.2)
windows-pr (1.2.2)
The message is coming from the multi_json gem, and it seems like it could be a bug. I suggest keeping an eye on this GitHub ticket.
If the message is too distressing, you can downgrade multi_json to version 1.6.1 to get rid of it. (At least this works for me.)
UPDATE:
It looks to me like the root of the problem is that while multi_json wants to limit its use of the json and json_pure gems to specific versions, the author of multi_json isn't using the gem method in his code to activate these versions. (It sounds like he thinks Bundler is the only way to specify versions of gems; it isn't.)
Since multi_json will try the oj and yajl-ruby gems before it tries json, using one of those may be the best workaround of all. So you can just install the latest multi_json and then install either oj or yajl-ruby along with it.
Try this:
gem update --system
gem update
Go to your Ruby installation path, for example,
C:\Ruby192\lib\ruby\1.9.1\json
Open version.rb file and update the version detail as shown bellow:
VERSION = '1.7.7'
Try running your tests with the bundle exec command. This will force your environment to use the gems in Gemfile.lock.
Related
One of my deployment pipelines on Azure DevOps fails when executing the build module images action of Azure IoT Edge task. I am trying to deploy a custom module developed using the Azure IoT SDK for C# (.NET 6).
Error message:
##[error]/usr/lib/python3/dist-packages/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.12) or chardet (3.0.4) doesn't match a supported version!
I tried to include this solution as CmdLine task before the build task. It worked a few runs and then failed again.
The pipeline already had a "Temporary fix" installing iotedgedev separately as a workaround for this bug
The deployment logs don't tell much about where to focus. I wonder what could be the cause of this issue? and if there is a quick fix or something to avoid while developing the application (i.e. warning messages while building or something like that)
I've had the same problem. After checking previous success Pipelines it seems that then new iotedgedev version 3.3.5 has a problem in DevOps Build Task (I haven't investigate more)
To fix that, at least temporally, I have added a Command Line Script before Build Modules Images Task that installs version 3.3.4.
pip install -U iotedgedev==3.3.4
It has worked for me, but as I said is a temporally patch.
As this appears to happen again and again and again and again (in different flavours), I felt it made sense to explain why this happens. It's right there in the error message actually, in my case:
.local/lib/python3.11/site-packages/requests/__init__.py:102:
RequestsDependencyWarning: urllib3 (1.26.9) or
chardet (5.1.0)/charset_normalizer (2.0.12) doesn't match a supported version!
So, apparently the requests package needs its dependencies at a certain version level to work correctly. But pip doesn't show which versions:
$ pip show requests | grep Requires
Requires: certifi, charset-normalizer, idna, urllib3
Let's look at init.py then, this is where the error occured:
if chardet_version:
major, minor, patch = chardet_version.split(".")[:3]
major, minor, patch = int(major), int(minor), int(patch)
# chardet_version >= 3.0.2, < 5.0.0
assert (3, 0, 2) <= (major, minor, patch) < (5, 0, 0)
....and on it goes, and we can now fiddle around with the expected version strings until the warning goes away or update the requests package to a version that accepts its required packages at the correct versions.
TL;DR: One has to upgrade or downgrade the affected packages (request or its dependencies) to get it right, or fiddle around with requests/__init__.py until the warning goes away :-)
Short answer -> force pyOpenSSL to version 22.0.0
(Edited 09.01.20223)
pip install -U iotedgedev pyOpenSSL==22.0.0 urllib3 requests
The cause seems to be a reported bug related to a dependency issue connected to a new pyOpenSSL release: github.com/Azure/iotedgedev/issues/589
pyOpenSSL>=20.0.1 on iotedgedev requirements resolves pyOpenSSL-22.1.0 creating some conflict with urlib or chardet
In this case, a temporary fix needed a "quick" temporary fix :D
I'm pretty new with NodeJS and I'm trying to use a module called "updated-node-msmq" (from this repository) in my project but getting an error.
What I've done:
I opened a new folder for the project.
I used the command "$ npm install --save updated-node-msmq" and got some warnings (Screenshot attached).
When I try to use the module according to the README, and run my "test.js" file I got the following error here in the screenshot).
I am using version 14.16.0 of NodeJS and after trying to fix this myself I realized that probably the problem is that the module was built for older versions of NodeJS.
I understand that low version is not a recommended solution, but I have no clue how to update a module.
Help / guidance in solving the problem?
Thanks in advance everyone!
Why are you using updated-node-msmq? That package seems like a mess, and the errors you are getting is because the whole module is written with ES2015 but doesn't seem to have been transpiled to node.js compatible code before published to NPM.
I'd advise you to use a tried and tested module for MSMQ first and foremost.
EDIT: Seems like the author fucked up in the 0.2.0 version. You could use the 0.1.9 (by instead using npm install updated-node-msmq#0.1.9 but that one is 3 years old.
I'm new to Electron, and I really love it so far, but I'm unable to package any of mine apps, at first I thought that it's maybe something related to my code, then I download "https://github.com/atom/electron-quick-start" run npm install and then I run "electron-packager . FooBar --platform=darwin --arch=x64 --version=0.28.2" it build the app but when I try to open it I get
so I didn't touch any code from the example, just wanted to build it and I got an error, what am I doing wrong? Thanks!
The versions of electron are moving very very fast.
And some times, they don't respect the "old" ways to do things (for example, declaring the app).
I advise you to not use the 0.28.2 version of electron but the most recent one.
It is very likely that the version of electron-prebuilt you are using to develop is much much much more recent than the 0.28.2 version. So, you are developing with something much newer, and then you are building with 0.28.2. This would cause the exact error that you are seeing, as older versions may not have had the electron module, which your code explicitly is importing. So... that is my suggestion. Change the version in your electron-packager command from 0.28.2 to something like 0.36.0. See if that works. Or better yet, use the same version as electron-prebuilt in your package.json.
This could be a combination of factors.
First, as others stated, the version of electron that you have might be newer than the one referenced in your build command. Locate the 'electron_prebuilt' folder inside your 'node_modules' folder, and examine the package.json file and make sure the version # is the same as what you are declaring in your build command.
If they are the same, then the issue might be that you have another version of electron on your computer that node is trying to use. If you installed electron via the -g option (global), check your home folder to see if there is another different version of electron. If you find one, either delete it or rename the 'electron_prebuilt' folder you find to something else. Try your build command again, and it should work now that you've eliminated the other versions of electron_prebuilt on your computer that node was referencing.
What worked for me was to move the "electron" module from "dev-dependencies" to "dependencies" in package.json. Try this and see if it works.
I've seen similar questions but no real solution that worked for me yet (most users just reinstall fibers or meteor (I'm not using meteor)).
I've added the nodejs module Sync to my nodejs 0.12.6 project. It's dependency is the Fibers module that got installed automatically with Sync. Now I wanted to load Sync via require, but it fails with the message
... /win32-x64-v8-4.3/fibers.node not found
And it's correct: In sync/node_modules/fibers/bin/ is no directory named win32-x64-v8-4.3, only win32-x64-v8-4.2 and renaming didn't solve the problem (would have been too easy)... 🙈
How can I solve this problem? How can this happen?
What is the meaning of the last number (4.3)? I guess it's windows, 64bit, Javascript v8 engine, and then? Fibers version?
Any ideas or hints?
Update:
I tried to updgrade node to 0.12.6, but nothing changed.
I found out what the 4.3 is about, it's the v8 version. Well, when running my application with electron, it is v8: '4.3.61.21'. When checking the version with node, it is 3.28. So it's maybe electrons "fault"?
Update #2:
Okay i found out that electron is based on io.js and not node. That explains the different v8 versions. But still no solution. When installing fibers with latest io.js (2.3.3), it tests the 4.2 binary, but electron requires 4.3 :(
Update #3:
Even with the same io.js version 2.3.1 as electron, it does only install the 4.2 binary.
Update #4:
Now, I've tried all three ways described at http://electron.atom.io/docs/v0.27.0/tutorial/using-native-node-modules/ (with electron version 0.29.1) - still no solution. There aren't any binaries for v8-4.3, still only the v8-4.2 ones. :(
Solution:
See my answer below. :)
At the end, i had to compile fibers on my own. As described in Update #4, i've tried it before. But node-gyp always failed and i didn't notice that i have to link to the new binary file on my own...
cd ~/my-project-root/
npm install sync
cd ./node_modules/sync/node_modules/fibers
node-gyp configure
HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
Then i've created the missing directory and moved the new binary there:
mkdir bin/win32-x64-v8-4.3
mv build/Release/fibers.node bin/win32-x64-v8-4.3/fibers.node
Now Sync works like a charm.
You need to use the electron-rebuild tool to rebuild your native module against the version of Electron you're using
I used Fire.app before but they haven't updated for a long time.
Then I turn to Compass 1.0.0alpha, Sass 3.3, and Susy 2.1.2
I installed via gem:
compass (1.0.0.alpha.19)
compass-core (1.0.0.alpha.19)
compass-import-once (1.0.4)
sass (3.3.8)
susy (2.1.2)
While creating a new project using susy:
compass create --using susy,
an error reads:
error sass/style.scss (Line 4 of sass/_grids.scss: File to import not found or unreadable: susy.
Load paths:
/******/sass
/Library/Ruby/Gems/2.0.0/gems/compass-core-1.0.0.alpha.19/stylesheets
Compass::SpriteImporter)
Many articles say a 1.0alpha version of compass will do, but it appears not.
How do I solve the problem? Thanks!
I don't know where SpriteImporter figures in your website. However, I would suggest installing Bundler, creating a Gemfile to include at least these two:
gem "susy", "~>2.1.0"
gem "sass", "~>3.3.0"
Then let Bundle install all the gems required. In case you aren't aware, this will be done inside Terminal on mac. The Bundler website explains all.