I'm trying to interact with helm via the go SDK and I'm getting the following error when I try to build my code:
../../../go/pkg/mod/github.com/deislabs/oras#v0.11.1/pkg/oras/push.go:52:31: not enough arguments in call to remotes.PushContent
have (context.Context, remotes.Pusher, v1.Descriptor, "github.com/containerd/containerd/content".Store, nil, func(images.Handler) images.Handler)
want (context.Context, remotes.Pusher, v1.Descriptor, "github.com/containerd/containerd/content".Store, *semaphore.Weighted, platforms.MatchComparer, func(images.Handler) images.Handler)
I've traced it down to package helm.sh/helm/v3/pkg/action :
$ go get helm.sh/helm/v3/pkg/action
# github.com/deislabs/oras/pkg/oras
../../../go/pkg/mod/github.com/deislabs/oras#v0.11.1/pkg/oras/push.go:52:31: not enough arguments in call to remotes.PushContent
have (context.Context, remotes.Pusher, v1.Descriptor, "github.com/containerd/containerd/content".Store, nil, func(images.Handler) images.Handler)
want (context.Context, remotes.Pusher, v1.Descriptor, "github.com/containerd/containerd/content".Store, *semaphore.Weighted, platforms.MatchComparer, func(images.Handler) images.Handler)
I suspect that this is related to this change: https://github.com/helm/helm/commit/663c5698878c959805de053116581d15673e1ce3
How do I fix this? I've tried using older versions of the helm package to no avail.
The signature for github.com/containerd/containerd/remotes.PushContent was changed incompatibly in commit f8c2f0, which was released in v1.5.0. (The containerd Go API appears to be unstable, despite its apparently-semantic version v1.5.5; see containerd#3554.)
The short-term fix is to go get -d github.com/containerd/containerd#v1.4 to downgrade to the latest v1.4.* until your dependencies are compatible with the latest release.
The longer-term fix appears to be helm commit 663c56, which migrates to a different oras library whose latest release is compatible with the containerd v1.5 API. As far as I can tell that commit has not yet been included in a helm release, but you may be able to try it out using go get -d helm.sh/helm/v3/pkg/action#main; see https://golang.org/doc/modules/managing-dependencies#repo_identifier.
Related
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 am following tutorial [Implementing the Contract Trait]. Added code snip to [parameter_types!] and to [imp trait runtime].
When I run [cargo check -p node-template-runtime] receive error:
error[E0282]: type annotations needed
error: could not compile sp-arithmetic
note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
I've had this error previously and it was due to nightly?
I am using windows not mac..
Just to Add to #dundro answer. Go to the link he suggested:
https://github.com/substrate-developer-hub/substrate-node-template/commit/5769470053ba48f364100ff106e32f1beea43127
and download the "rust-toolchain" file. Then place it in the "substrate-node-template" folder. Then try to build again using the command "cargo build --release".
In my case, it solved the E0282 error and gave me a new one E0463. Searching for a fix now
I got the exactly same error, but then I just checked out master ( there is now a toolchain file since https://github.com/substrate-developer-hub/substrate-node-template/commit/5769470053ba48f364100ff106e32f1beea43127)
and with nightly-2020-10-06 the build was successful.
Good luck
Solved: I forgot to add nightly [cargo +nightly-2020-10-06 check -p node-template-runtime]..
I have built a Cordova-based Windows application. As soon as I add any plugin, the app starts crashing with the exception cordova/windows8/commandProxy not found.
Cordova version: 4.3.0
It seems that cordova/windows8/commandProxy is deprecated in Cordova 4.3.0.
I have replaced this statement in plugin file
require("cordova/windows8/commandProxy")
to
require("cordova/exec/proxy")
and it seems to work.
For example I changed line number 18 in PushPluginProxy.js from
require("cordova/windows8/commandProxy").add("PushPlugin", module.exports);
to
require("cordova/exec/proxy").add("PushPlugin", module.exports);
The name in the string varies depending on the plugin.
Alternatively, you can patch the plugin like in this pull request from the AppVersion plugin i.e.:
Change
require("cordova/windows8/commandProxy").add("AppVersion", AppVersionProxy);
to
cordova.commandProxy.add("AppVersion", AppVersionProxy);
I have quite a complex TeamCity-Solution.
Configuration "tcBuild" builds and creates nuget-packages, as well as it modifies the version number of the assembly.
Configuration "tcDeploy" depends on "tcBuild", takes the nuget-packages and send it using octopus.
tcBuild just works fine and also creates the wanted packages.
tcDeploy throws the following error for each package:
2014-01-28 14:50:05.5826 ERROR Unable to download package:
Octopus.Platform.Deployment.ControlledFailureException: Could not find package Packagename 1.1.0.903 in feed: 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/'
at Octopus.Shared.Packages.PackageDownloader.FindPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 155
at Octopus.Shared.Packages.PackageDownloader.AttemptToFindAndDownloadPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log, String cacheDirectory, IPackage& downloadedPackage, String& path) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 130
at Octopus.Shared.Packages.PackageDownloader.AttemptToDownload(PackageMetadata metadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 89
2014-01-28 14:50:05.5826 ERROR Error in DownloadAndPushToTentaclesOrchestrator-OCw-lDdz+eWP#SQ-PESY0002-F9FA8F1A while receiving bedf70c1-1f30-496f-91ca-aba6cc956042
(where "packagename" is the name of the package)
The version number of the error message is the same as of the nuget packages' "core-properties"-folder.
Other, quite similar builds on that machine work just fine. Tell me if I need to provide more information.
You can try to create one tc project to package which triggers another project to deploy. We ended up with this approach so that we can deploy the latest build to octopus. Good luck.
I'm trying to use hgsubversion plugin for mercurial from Windows. Pull from SVN repositpry works on Windows. But when I'm trying to push to the repository, I get the following message:
pushing to svn+ssh://user#server.com/home/user/.repo/test.svn/
abort: command unavailable for Subversion repositories
It seems this happens because hgsubversion is using SWIG bindings instead of subvertpy( on Linux everything works fine with subvertpy)
D:\test\>hg version --svn
hgsubversion: 88f3cda47def
Subversion: 1.6.13
bindings: SWIG
But I didn't find any easy way to install it(now I'm trying to compile it myself, but there are some problems). Maybe I missed something. Bzr is using subvertpy, maybe it is possible to extract it? Any suggestions?
Does anyone using hgsubversion from Windows?
P.S To compile the library i tried this hint: https://bitbucket.org/tortoisehg/thg-winbuild/issue/14/request-add-subvertpy-to-the-default
UPD: solved initial problem with fail on push. The largefiles(which is distributed with mercurial >= 2.0) extension breaks hgsubversion. Just disabled it and got hgsubversion working.
Well, I had slightly different results
hgsubversion: 6c4d15d8cfbd
Subversion: 1.6.13
bindings: SWIG
on my test-repo with commit-auth
Test 1, inside TortoiseHG
Cloned from root http://mayorat.ursinecorner.ru:8088/svn/Hello/
Tip is revision from trunk, edit file, commit OK
On push I got long waiting (really long) on "Searching for changes" stage (without any requests from server)
"Stop operation" show me error message "Basic authentification rejected by server"
Test 2, CLI-mode
Cloned only trunk http://mayorat.ursinecorner.ru:8088/svn/Hello/trunk/
>hg push --stupid
pushing to http://mayorat.ursinecorner.ru:8088/svn/Hello/trunk/
searching for changes
Auth realm: <http://mayorat.ursinecorner.ru:8088> VisualSVN Server
Password for Badger:
Auth realm: <http://mayorat.ursinecorner.ru:8088> VisualSVN Server
Username: lazybadger
Password for lazybadger:
[r32] lazybadger: Cleanups
pulled 1 revisions
saved backup bundle to ...
Can say nothing about first password request, second and third are obvious and correct. 32 revision exist and visible to everybody
Sidenote: my changes doesn't broke linear history of SVN