bitcoin core version
Trying to use listtransactions
I don't understand why my bitcoin core don't have this method. How add this method to core?
I installed the node using this guide: https://baloian.medium.com/how-to-setup-and-run-a-bitcoin-full-node-on-ubuntu-a106fb86dbb3
In your screenshot the bitcoin-core version is equal to 23.99.0-something. You should build or download binaries of the latest release which is 23.0.
In order to use listtransactions you need:
bitcoin core daemon running bitcoind --daemon
created/loaded a wallet bitcoin-cli createwallet "sometag"
then you can bitcoin-cli listtransactions which will return an empty array in my case because the wallet is new
official build notes
download bitcoin-core
running a full node
personal gist to download and install bitcoin core on linux x86_64
Related
My Goal is to run openstack using packstack for ovs. Facing ovs-dpdk start issues in ovs startup in various format.
Linux: 3.10.0-957.el7.x86_64
OVS: ovs-vswitchd (Open vSwitch) 2.9.0 DPDK 17.11.0
DPDK: dpdk-devel-18.11.8-1.el7_8.x86_64
Did anyone tried or give pointer how we can integrate ovs and dpdk.
I've created an ASP.NET Core 2.1 app that I'm trying to deploy to Google Cloud Platform. It builds just fine using dotnet build locally.
I cannot build it through Google Cloud Shell, though. Running dotnet --version confirms the Google Cloud Shell has .NET Core 2.0 installed.
Running gcloud app deploy initiates a deployment of the app, but I receive a cryptic error from the log saying:
Step #0: Status: Downloaded newer image for gcr.io/gcp-runtimes/aspnetcorebuild#sha256:ad1b788a9b4cca75bb61eb523ef358ca059c4bd208fba15a10ccc6acab83f49a
Step #0: No .deps.json file found for the app
Finished Step #0
ERROR: build step 0 "gcr.io/gcp-runtimes/aspnetcorebuild#sha256:ad1b788a9b4cca75bb61eb523ef358ca059c4bd208fba15a10ccc6acab83f49a" failed: exit status 1
I was under the impression that GCP supports .NET Core 2.1 containers by default, so I haven't included a Dockerfile.
I'm trying to deploy to the flexible environment, here's my app.yaml file:
runtime: aspnetcore
env: flex
Do I need to create a custom Docker container? Or is there some other way to get support for .NET Core 2.1 in Google Cloud Shell?
Edit: For now I've installed Google Cloud Tools to run gcloud app deploy in a shell locally after running dotnet publish.
I tried to reproduce it - indeed, Cloud Shell supports .NET Core 2.0 only. I've raised that with the right engineers so Cloud Shell image is updated to support .NET Core 2.1.
In the meantime:
Create a docker file based off of this image:
gcr.io/google-appengine/aspnetcore:2.1
Try using gcloud builds submit to build an image. When you run gcloud builds submit for the first time, it will ask to enable Cloud Build API. Approve that. This will not use local (i. e. CloudShell's) docker build command but rather submit your artifacts to be built by Cloud Build and pushed to container registry.
Deploy to AppEngine Flex with gcloud app deploy, specifying --image-url with the image address from container registry as you built it in previous step.
Remember that Microsoft switch from aspnetcore to dotnet on the dotnet core image.
https://hub.docker.com/r/microsoft/dotnet/
I know Mule ESB Enterprise edition can be installed on Raspberry Pi because it ships with support for arm based processors. Unfortunately, Community edition does not have it. This makes it difficult to use Mule ESB on pi for longer time as I don't have the enterprise license (it's for personal projects and enterprise trial ends in 30 days). I wonder, why community edition does not have this support? Are there any restrictions for using community edition on pi?? Can the support be added to community edition? Has anyone done it and using it?
Yes, it is possible to install and run Mule on Raspberry PI 3 (and by extension any armhf/armel machine). You have to tweak your installation to ensure Mule uses the Linux armhf 32-bit Java Service Wrapper (or the related OS/architecture Wrapper). The steps in details:
Install Mule CE
Install Mule Standalone as you would do on any other machine:
Download the Mule CE Runtime
Unpack the content somewhere, such as in /opt/mule (i.e. MULE_HOME=/opt/mule) and change owner of the content to a Mule user (such as mule:mule)
Optionally, perform some hardening
You should be able to run Mule using $MULE_HOME/bin/mule start|stop|restart
Configure Java Service Wrapper
You need to manually add the Java Service Wrapper support for your OS and processor architecture, for Raspberry PI 3 it would be Linux armhf 32-bit.
Download the Linux armhf 32-bit Community Tanuki Java Service Wrapper and unpack it
Copy the Wrapper lib/libwrapper.so to $MULE_HOME/lib/boot/libwrapper-linux-armhf-32.so, ensure it has read+execute permission and is Mule user owned
Copy the Wrapper lib/wrapper.jar to $MULE_HOME/lib/boot/wrapper-{version}.jar (replace {version} by your Wrapper version), ensure it's Mule user owned and remove or backup somewhere else the previous wrapper-{oldVersion}.jar
Copy the Wrapper bin/wrapper to $MULE_HOME/lib/boot/exec/wrapper-linux-armhf-32, ensure it has read+execute permission and is Mule user owned
This one is a bit tricky, you have to update the $MULE_HOME/bin/mule launch script. Look for the line case "$PROC_ARCH" in, Such as:
'x86_64')
DIST_ARCH="x86"
DIST_BITS="64"
break;;
Each case match a specific hardware name to define DIST_ARCH and DIST_BITS variables, allowing to use the proper Wrapper files. Add a new case to handle your Raspberry PI hardware. For Raspberry 3, it's should be something like armv71 (check with uname -m if required):
'armv71')
DIST_ARCH="armhf"
DIST_BITS="32"
break;;
You may need to update $MULE_HOME/conf/wrapper.conf to avoid memory related issues. I usually have to play around with the following properties:
wrapper.java.initmemory=512
wrapper.java.maxmemory=512
wrapper.java.additional.X=-XX:PermSize=256m
wrapper.java.additional.Y=-XX:MaxPermSize=256m
wrapper.java.additional.Z=-XX:NewSize=512m
wrapper.java.additional.V=-XX:MaxNewSize=512m
When Mule will run on armv71 hardware, it will now use wrapper-{OS}-{DIST_ARCH}-{DIST_BITS}, in our case wrapper-linux-armhf-32. You should be able to run Mule as usual - check the logs for any error on start-up.
This method has been tested with Raspberry PI 2 and 3 for Mule CE 3.7 and 3.8 (it should work for previous versions). It may be a bit tricky, if you have any issue post a comment I'll update this post to add details.
By the way, this method can be used to add support for any architecture and OS as long as it is supported by Java Service Wrapper.
I wonder, why community edition does not have this support?
I don't know, Mule CE simply does not support ARM architecture - for now. Only a limited list of platform and architecture is supported by CE (i.e. the launch script filtering architecture types). Maybe they simply did not take the time (~money) to add support, or they purposefully prevent ARM support to favor Mule EE. Considering Mule CE is open-source, in theory someone could contribute to add such support... (just saying ! :)
I am doing my local openwhisk installtion on Ubuntu 16.04.
I was try to do my hands-on on the below sample
https://github.com/IBM/openwhisk-data-processing-message-hub
it using /whisk.system/messaging package
but when i check the installed packages i see below
/whisk.system/alarms
/whisk.system/watson-translator
/whisk.system/github
/whisk.system/weather
/whisk.system/watson-textToSpeech
/whisk.system/slack
/whisk.system/utils
/whisk.system/combinators
/whisk.system/samples
/whisk.system/websocket
/whisk.system/watson-speechToText
Can someone let me know how to install the messaging package
The messaging package relies on a microservice that relays Kafka messages as OpenWhisk trigger fires. You can find instructions on how to build and deploy the microservice, as well as the actions in the messaging package here: https://github.com/apache/incubator-openwhisk-package-kafka/issues/99#issuecomment-300536379
I need to do integration testing for a spring cloud application running with spring data on redis.
Tests work locally with the regular redis server instance and I need to run this on a Jenkins CI server that is controlled by the corporate CI engineering group.
Obviously I can attach to a redo server there so I used an embedded redis server (from here: https://github.com/kstyrc/embedded-redis).
Running tests locally with this redis server works well since there is a test profile to inject the embedded server in place of the production one.
Now the problem is that when we run this in the Jenkins environment this is the error we see.
/tmp/1430170830037-0/redis-server-2.8.19: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/1430170830037-0/redis-server-2.8.19)
So this version of redis has specific dependency on a specific version of glibc. I tried a couple of other libraries but they all depend on the same underlying version of the embedded redis server.
Is there a spring data mock framework that can be used to get around this sort of issue?
This might come a little late for you, but there is indeed a Spring Data Mock framework that you can use, which let's you mock repositories (regardless of the specific backend solution) without a real database connection.
Here is a link: https://github.com/mmnaseri/spring-data-mock
You don't have a high enough version of libc6, that is causing the error.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:
That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).
So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).
To upgrade it, use these commands in a terminal:
sudo apt-get update
sudo apt-get install libc6
p.s. This is answer from askubuntu.com by minerz029