I would like to pull the neo4j image on my Mac Book M1 machine.
The dockerfile is something like this
FROM neo4j:3.5.30-community
....
If I don't specify the target platform it gave me an error on pull :
=> ERROR [internal] load metadata for docker.io/library/neo4j:3.5.30-community 0.6s
------
> [internal] load metadata for docker.io/library/neo4j:3.5.30-community:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: no match for platform in manifest sha256:a3c8ec959f11ecac3e90c6c032afb217718128366b6ba3d59cf55ad6320be8d1: not found
ERROR: Service 'designer-neo4j' failed to build: Build failed
I google it a bit and I found that I need to do a:
export DOCKER_DEFAULT_PLATFORM=linux/amd64
This works and image is pulled and it runs - slow and with a lot of crashes...
Inside my docker dashboard, it warns me with a red exclamation mark: amd64: Image may have poor performance.... If I google it tells me, that I should have arm64 architecture images...
So how to pull the neo4j image on mac m1, so that it will work?
You need to use a more recent version of Neo4j, 3.5 is EOL already.
If you do use 4.3 or 4.4 you will be able to simply pull arm64 compatible images.
Check on docker hub https://hub.docker.com/_/neo4j?tab=tags&page=1 , you will see immediately the image tags compatible with arm64 architectures.
Related
im using imx6ull , where i need to enable prmeept_rt patch, i have enabled
--->General setup
-->(X) Fully Preemptible Kernel (Real-Time)
in Linux kernel 5.4.3 by using patch-5.4.3-rt1.patch.xz and created kernel image and i tried to boot the board with rootfs build (poky branch is kirkstone) using core-image-minimal image recipe it was not providing me root access ,
So i tried to build another rootfs (poky branch is kirkstone) using core-image-rt-sdk image recipe in yocto toaster it is showing error. as
Nothing PROVIDES 'core-image-rt-sdk'
core-image-rt-sdk was skiped : Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it
how to build rootfs using core-image-rt-sdk image recipe .
any suggestions will be more help full
I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!
I've been unable to query my existing contract recently due to Unable to create Enum via index 128, in Alive, Tombstone when using api.query.contracts.contractInfoOf. I get this error both on the command line and in the polkadot-js apps explorer.
These are the steps I took:
Deploy a contract with a salt
Retrieve the contract deployedAddress
Use contractInfoOf
const contractInfo = await api.query.contracts.contractInfoOf(deployedAddress);
I've tried downgrading ink! to 3.0-rc5, 3.0-rc4, 3.0-rc3 and then compiling but it doesn't seem to make any difference. Whenever my contract is built it references rc6 at the top:
{"metadataVersion":"0.1.0","source":{"hash":"0x...","language":"ink! 3.0.0-rc6","compiler":"rustc 1.58.0-nightly",
Which suggests its ignoring my .toml and using rc6 to compile the contract.
I changed my cargo-contract version to 0.14 but that causes polkadot-js to fail at reading the contract abi.
I've tried using the substrate-contracts-node using the latest commit from master and also using the v0.1.0 release. Same error in both cases.
> rustup info
stable-x86_64-unknown-linux-gnu (default)
rustc 1.56.1 (59eed8a2a 2021-11-01)
There are more details in an issue on polkadot-js.
Any pointers on how to get a working setup would be very helpful!
The problem here was substrate-contracts-node using an old version of the metadata.
I was able to check out the repo before the metadata merge was reverted and build locally (cargo build).
So checkout 8d91b8e to get the node to work with versions 7.7.1 and 6.6.1 of polkadot-js packages.
> git checkout 8d91b8e578065a7c06433cbd41ac059bf478a0bd
> cargo build
> ./target/debug/substrate-contracts-node --dev --tmp --version
substrate-contracts-node 0.1.0-8d91b8e-x86_64-linux-gnu
I get the following error when building after changed the mac machine(I'm using VMWare and created new machine to use the latest OS version)
I copied the xcode project from old machine to the new one.
Severity Code Description Project File Line Suppression State
Error 2019-12-16 04:09:43.959 ibtoold[1526:26675] DEBUG: Added to
environment: {
TMPDIR = "/var/folders/xn/r2znrb712jl3558nqh0000gn/T/1AA1234D-4B58-5555-6665-52BC1709F584";
} 2019-12-16 04:09:45.057 IBCocoaTouchImageCatalogTool[1549:27672]
Unable to get image dimensions for
file:///Users/user/Library/Caches/Xamarin/mtbs/builds/ExpoUp.iOS/xxx/obj/iPhone/Release/actool/cloned-assets/Assets.xcassets/AppIcon.appiconset/Icon-App-20x20#1x.png
2019-12-16 04:09:45.076 IBCocoaTouchImageCatalogTool[1549:27672]
CoreThemeDefinition: Unable to create image for
file:///Users/user/Library/Caches/Xamarin/mtbs/builds/ExpoUp.iOS/xxx/obj/iPhone/Release/actool/cloned-assets/Assets.xcassets/AppIcon.appiconset/Icon-App-60x60#2x.png
I am using Marmalade to build a PlayBook app, but I think my question applies to PlayBook apps in general. I have successfully created a debugtoken.bar file and have installed it on my device. When I go to try to install a built application.bar file on the device, I get:
[execute] "blackberry-deploy.bat -device 192.168.1.114 -password ******* -installApp -package deployments\default\playbook\release\Quote Unquote.bar"
Info: Sending request: Install
Info: Action: Install
Info: File size: 6400334
Info: Installing ...
Info: Processing 6400334 bytes
actual_dname::
actual_id::
actual_version::
result::failure 881 required signatures missing (RDK, AUTHOR)
ERROR: error running blackberry-deploy
***ERROR***
Note that this is the Marmalade deploy tool running the standard PlayBook installer.
What I don't understand is: I thought the point of using a debugtoken.bar file was that you could install unsigned apps. I have in fact successfully deployed these unsigned apps using the Marmalade deploy tool just like this. But I was having problems signing the app for distribution, so I went back and did everything from scratch, requested new code signing keys from RIM, made a new debugtoken.bar file and installed it, etc. And now I'm worse off than I was before because I can't even install to the device now.
So again: My understanding is that the point of debugtoken.bar was to be able to deploy to the device before actually signing the application.bar for distribution. So what does this error message even mean?
To answer my own question:
For deploying a "debug" build to a device, it's critical to have
Application-Development-Mode: true
in the MANIFEST.MF within the .bar file.
A stupid mistake, but I'll leave this up in case it helps anyone...
Taking a look to the QNX deployment plugin "C:\Marmalade\6.1\s3e\deploy\plugins\qnx\qnx.py" I found that 'FOR DEVELOPMENT' option is false if the 'playbook_keystore' is given so I just cleared the signing section on the Marmalade System Deployment Tool and it is not longer trying to sign it