I wonder how to find out the version of the cygwin setup program (setup-x86 or setup-x86_64). I know there's setup.ini file when the setup program downloads stuff. There's a line "setup_version: 2.XXX" therein. Is there any direct way to get the version number? Something akin to "setup --version" on the command line.
There is no version command line as you can see from the help output
/setup-x86.exe -h
You can ask on the mailing list for this additional info to be added
as setup is currently under deep review.
The only way, currently available, is to look at the start window
I followed the readme instructions for building Parity from source and then executed:
cargo build --release
~/.cargo/bin/cargo build --release
as instructed, both of which returned the following message while the prompt hung:
Blocking waiting for file lock on the registry index
I'm on a Mac.
Running cargo clean seems to fix the problem.
I had the same issue and got around it by using
rm -rf ~/.cargo/registry/index/*
I suggest looking at 'Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source' first.
This happens when you run two compilations of the same project at the same time. The compiler uses a lock file to avoid having data race issues.
There are some possibilities:
If you ran the two compilations yourself, the solution is obvious: you need to cancel one of them.
If you use an IDE that automatically compiles your project: you can wait for the job to be finished or close the IDE. If it does not work, this is probably because of RLS hanging out. You can run pkill rls to solve the issue.
As a last resort, you can force the removal of the lock using rm -rf ~/.cargo/registry/index/* as said in jvatic's answer.
It is important to ensure you have no other rls or cargo running.
sudo pkill rls cargo is a good way to ensure they are not.
Removing rm $CARGO_HOME/.package-cache worked for me.
I accidentally hit ctrl+z instead of ctrl+c while executing cargo run and the next execution of cargo run showed me Blocking waiting for file lock on the registry index. I removed the said file and then it worked again.
Edit:
If you accidentally hit ctrl+z like me, you can unsuspend the cargo run process by running fg instead of deleting the package cache file. ctrl+z actually sends a SIGTSTP signal to the process and that process will be suspended until you tell it to continue. See this answer for more info.
You usually get this error when you run the cargo build command twice at the same time. If you are using an IDE check if a plugin is running a cargo command in the background, this was the case for me with VS Code.
I am using this command in macOS Monterey 12.4:
rm -rf ~/.cargo/.package-cache
then rerun the build command, works.
My issue was the IDE was running cargo and had locked the directory. Try closing your IDE
My VSCode intellisense was working on a build. Make sure your intellisense is not builing. It displays a little gear icon spinning on bottom. Happens mostly when you update Cargo.toml
I fixed this issue by running the following commands:
Search for all rust related processes by $ ps aux | grep rls
Stop all of them one by one with $ sudo kill -9 <PID>
You can point your IDE to use a different path when building the code.
This will prevent conflicts with locks in the future. Add the following compile flags to the IDE:
--target-dir target/rls/
In VSCode use the following setting:
"rust-analyzer.runnables.extraArgs": [
"--target-dir",
"target/rls/"
]
Same issue in VScode : if you've installed RLS
File | Preferences | Settings
Search for "rls"
In "rust" extension, uncheck "Start RLS automatically when opening a file or project"
Re-open your project, and it should be solved.
Before removing the Cargo registry index as suggested in the accepted answer, make sure no other process is currently compiling Parity or any other Rust package.
it's work for me on the linux (ubuntu) :
$ rm ~/.cargo/.package-cache
I tried to create a Polkadot Node by following the Readme instructions.
I was able to build it by running the following commands (copy/paste into Bash Terminal):
git clone https://github.com/paritytech/polkadot;
cd polkadot; git checkout master;
rustup update nightly;
rustup target add wasm32-unknown-unknown --toolchain nightly;
rustup update stable;
rustup default stable;
cargo install --git https://github.com/alexcrichton/wasm-gc --force;
cargo install --git https://github.com/pepyakin/wasm-export-table.git --force;
brew install openssl; brew upgrade openssl;
rustc --version; cargo --version;
./build.sh;
cargo build;
cargo run -- --help;
./target/debug/polkadot --help;
I then tried to run a Polkadot Node with the following commands (which are equivalent):
./target/debug/polkadot -- --chain=dev --validator --key Alice -d /tmp/alice;
cargo run -- --chain=dev --validator --key Alice -d /tmp/alice;
But instead it showed the following:
Blocking waiting for file lock on the git checkouts
Blocking waiting for file lock on build directory
I found it was caused by CLion (Jetbrains IDE).
I solved the problem by closing CLion. I used Visual Studio Code editor instead, which also allows for debugging Rust code with breakpoints
if you ever hit "Blocking waiting for file lock on package cache",
Run the command below and run cargo again.
rm $CARGO_HOME/.package-cache
I had a case where there was an update to my rust extension rust-analyzer in vscode that was causing it. I updated and reloaded the extension and then cargo build ran fine.
Problem was another process using cargo. I could not find the process to kill so I restarted my local machine and it worked.
Finally. And I absolutely mean finally when all fails and you want a quick out. Restart your machine.
Perhaps it's also the rust-analyzer taking way too long so don't open vscode on reboot, use your terminal instead.
You Should Temporarily Stop the rls Process.
On the risk of coming late to the party, while cargo, rls or rust-analyzer are responsible for the lock to avoid data races.
An underlying issue maybe the number of inotify filewatchers.
Usually they work fine by spawning a new watcher and wait their turn but if they run out of watchers space this can be a problem.
Agreeing to all the above solutions but suggesting to check the number of max_user_watches
# view current settings
cat /proc/sys/fs/inotify/max_user_watches
# increasing it, /etc/sysctl.conf
fs.inotify.max_user_watches=524288
# The new value can then be loaded in by running s
$sudo sysctl -p.
What worked for me
For me, I found that the issue was caused by configuring my target dir:
[build]
target-dir = ".cargo/target"
in my .cargo/config.
What didn't work
I ran cargo build --release -vv and saw a message that didn't appear without the -vv flag:
Blocking waiting for file lock on build directory
I thought this a big clue so I tried stuff like disabling my file backups. I also tried all the answers on this page with no luck.
For me rust analyzer didn't stop and closing the IDE didn't help. But instead of shutting the computer just close the IDE and go into task manager (this is at least for windows). In task manager under details tab you can find any cargo processes that may be running and kill them there. Then you can reopen IDE and you should be back to normal.
I think you should use cargo clean and re-run the cargo run command and wait for some time. This usually happens when you try to use a new module in your code by adding it into Cargo.toml file.
Kill the cargo process that is running in the background, it should fix.
Had the same issue
Actually, on another terminal, I was running my debugger and that's why this command was blocked.
So just stopped the debugger and then ran the command and everything went fine.
I got the same problem when cargo run but nothing work for me i restart my system and problem fixed.
Windows: i opened the task manager and end the Cargos processes
In my case, I had Sourcetree running in the background, and it seems that was holding the file lock. Closing the app fixed the issue.
If you are sure that there is no other cargo process executing, but this problem still occur frequently, it might be your network problem.
I am trying to trying to execute a shell command from tortiseHg. My end goal is to run a large shell command with {REV} being a parameter. Does anyone know of a way to do this?
I tried using the custom tools option in tortiseHg and it is not working for me.
No matter what I add as the command, It always returns:
The command "my command and args" could not be executed.
"No such file or directory"
Please check that the command path is valid and that it is a valid application
How to reproduce:
In tortoiseHg (linux), go to Settings> Tools > New Tool, add a new command.
Eg. touch /path/success.txt
Add tool to list
Restart thg
Click on the tool.
As lgriZdes mentioned in his answer, custom tool seems to accept only hg commands. Got around this issue by creating an alias in hg which executes a shell command, and calling this alias from custom tools. Let me know if you guys want more detailed info.
In old prehistoric versions of tortoisehg only hg commands were working. It is said here that now shell commands should work without problem How to add a custom tool/command to tortoisehg in linux?
How can I have the pre-build step in eclipse/CDT (Linux) run a simple shell command, echo specifically. I think eclipse has a screwed up value for PKG_CONFIG_PATH and want to see what Linux thinks the value is.
Under the covers, Eclipse uses "make". You can simly edit the project's makefile:
help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/concepts/cdt_c_makefile.htm
You can also create an:
"External Tool", which is up there beside the Debug and Run buttons in
the toolbar. Then I tell the external tool to run the shell with the
configure script and any of it's arguments as arguments to the tool.
http://www.eclipse.org/forums/index.php/t/61866/
We are avid Eclipse fans -- it is fantastic! But we have about 40 c++ projects (and growing), and building all of these projects, when all projects are up-to-date, takes about half a minute (total). If I were to simply create a bash script that executed "make all" on all 40 projects, it would execute in way less than a second.
Eclipse seems to want to run a test for the proper tools each time by executing:
g++ -E -P -v -dD /myfolder/.metada/.plugins/org.eclipse.cdt.make.core/specs.cpp
where specs.cpp is an empty file. This step seems to be taking most of the build time.
Any insight here from anyone? Any way to tell Eclipse to trust the tools?
I would suggest you to experiment with C/C++ Build Discovery options page of your projects properties. The first thing that I would try is to turn off "Enable generate scanner info command" option.