I'm trying to get Python 2.7 working on my OpsWorks instance but I keep running into errors starting up.
My OpsWork stack is set up with Chef version 11.10 and Berkshelf version 3.2.0.
My metadata.rb has the following in it:
depends "poise-python"
depends "apt", ">= 1.8.2"
My Berksfile is set up with:
source "https://supermarket.chef.io"
cookbook 'poise-python'
cookbook 'apt'
Every time I launch I keep getting the following error and I'm not sure how to resolve it:
Halite is not compatible with no_lazy_load false, please set
no_lazy_load true in your Chef configuration file.
I tried adding a chef/configuration.rb file to set no_lazy_load to true but it doesn't seem to be working. Frankly I'm new to OpsWorks and Chef so I may be missing something very basic.
More Info
The stack I'm taking over originally referenced python instead of poise-python but I had switched from that to resolve a different error (but, I guess, related) when I tried to run with that:
This resource is written with Chef 12.5 custom resources, and requires
at least Chef 12.0 used with the compat_resource cookbook, it will not
work with Chef 11.x clients, and those users must pin their cookbooks
to older versions or upgrade.
I tried pinning to an older version of python but still couldn't get it to work. Basically, I know this instance can run (previous maintainer had it going) but I'm not sure what I'm missing.
After some Googling, I figured out how to make this work without upgrading Chef version. I added the following line to my Berksfile:
cookbook 'build-essential', '= 3.2.0'
My cookbooks aren't compatible with Chef 11, you'll have to upgrade your stack to Chef 12.
Related
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
When VSCode tries to start one of my extensions (Salesforce Extension Pack), the extension crashes. When I check out the console, it looks like the first error, which I'm assuming is the cause of the others and the crash is from the Extension Host saying:
Unsupported Node.js version 4.2.6, version 8.4.0 of later is required.
I can't even find node version 4.2.6 installed on my machine and my default is 8.12.0. Is the Extension host using a different path than it would use in a terminal? And if so is there some place I should look to find where that path is set? I can't seem to find any information on where it is or how to control what version of Node it's using.
I've tried everything I can think of, including a full uninstall of VSCode and all extensions and deleting the config in .config/Code and .vscode/ and reinstalling it, but it keep getting the same error. This is on Linux Mint v18.3 if that makes a difference. Any help on this would be greatly appreciated.
I figured out my own question. It seems it might be the result of installing nvm to manage/install versions of node. The extension host doesn't seem to be using nvm. So, it was just executing the basic version on my machine, which seems to be 4.2.6. I logged in as root and manually updated the nodejs version and everything works fine, now.
I am trying to set up a stack project that uses the postgresql-simple package among others. When trying to stack build, all of the dependencies for postgresql-simple installed without issue, but stack is having trouble installing postgresql-simple itself. I get the following error:
C:project> stack build --extra-include-dirs="C:\PostgreSQL\8.4\include" --extra-lib-dirs="C:\PostgreSQL\8.4\lib"
... omitted ...
*****************
--extra-include-dirs=C:\PostgreSQL\8.4\include
*****************
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
*****************
--extra-lib-dirs=C:\PostgreSQL\8.4\lib
*****************************
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\User\Desktop\draftkings\NFAccuracy\.stack-work\logs\postgresql-libpq-0.9.1.1.log
Configuring postgresql-libpq-0.9.1.1...
Setup.hs: Missing dependency on a foreign library:
* Missing C library: pq
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
I've tried also specifying the paths in my stack.yaml file, same error.
I've tried manually copying the library and include files from my postgres installation to the mentioned ...\mingw64\lib and ...\mingw64\include folders. Same error.
I have the files libpq.dll and libpq.lib in my C:\PostgreSQL\8.4\lib folder.
I feel like I'm missing something obvious but I can't get this to work and I'm not sure what I'm doing wrong. Any help is appreciated.
Update
I forgot to mention two important details.
First, I have added C:\PostgreSQL\8.4\bin to my PATH. As far as I know, this works as expected, because I got past an error about pg_config missing, to the error I currently have.
Second, I also tried adding the lib and include directories to my PATH, but this did not change the error.
I should also mention my Postgres installation works fine on its own.
I know that the Snowdrift project uses PostgreSQL and builds with Stack on Windows. They have a build guide on their site. It looks like one difference is that they mention:
Add the PostgreSQL bin directory to the path C:\Program Files (x86)\PostgreSQL\9.4\bin
Can you try adding that to the PATH and see if that fixes it?
There was some kind of version mismatch.
Installing Postgres 9.4 instead of 8.4 allowed the postgresql-simple package to be built in the manner I was attempting.
My stack project, without intervention by me, defaulted to using resolver: 'lts-3.7' This provided version 0.4.10.0 of the postgresql-simple package to my project. I wish I had a more detailed answer, but all I can tell is that this version of postgresql-simple (which is fairly recent) works fine with PostgreSQL 9.4 (which is also recent).
And thankfully, using haskell and postgresql-simple built against Postgres 9.4 libraries is having no issue communicating with my 'remote' (virtualbox) database which is Postgres 8.4.
I'm tempted to flag my question as not constructive unless others find this useful info.
When I try running Unicorn after setting up postgres (works perfectly with Trinidad and Thin) I get the following error.
dyld: lazy symbol binding failed:
Symbol not found: _rb_thread_select
Referenced from:/Users/pls/.rvm/gems/ruby-2.2.0#coinino/extensions/x86_64-darwin-13/2.2.0/do_postgres-0.10.14/do_postgres/do_postgres.bundle
Expected in: flat namespace
Datamapper connects to the database normally inside a model.rb which then is required in app.rb.
What is wrong and how do I fix it?
Edit: Looks like this is a bug in Ruby 2.2.0.
A call used by old versions of the pg gem has been removed in Ruby 2.2. More recent versions of the gem no longer use this call; I know the latest version (0.18.1) doesn't, but I don't know when that change was made. You can update the pg gem by running the following command:
bundle update pg
As long as you're doing this, you may want to run just a plain bundle update to update all of your project's gems to the most recent versions—who knows what else might be incompatible with Ruby 2.2?
As always when updating dependencies, test that the update doesn't introduce any new bugs before you deploy the new version to production. I doubt pg will cause any problems, but other gems might.
It looks like this is a bug in Ruby 2.2.0. Going to Ruby 2.1.5 gets things going without trouble.
I'm trying to use the same CentOS instance to get me to build packages for both versions 5 and 6. Until now everything was working OK, but I think an update in the building instance (6) now includes some dependencies that seems they're not available in version 5:
error: Failed dependencies:
rpmlib(FileDigests) <= 4.6.0-1 is needed by pulse-13.1.0-181013.noarch
rpmlib(PayloadIsXz) <= 5.2-1 is needed by pulse-13.1.0-181013.noarch
My question: is there any way of doing this? Is this even suppose to work i.e. building RPM for different target versions?
There are two ways whose performance is better than normal VM:
Make CentOS 5 or 6 chroot environment and build RPM inside it.
Configure LXC and builde RPM inside it, see also http://wiki.centos.org/HowTos/LXC-on-CentOS6 and http://whistl.com/index.php/blog/2011/08/28/linux-containers-under-centos-6
you can try crosstool-ng. OSDev Wiki page has a lot of information about cross compilation.