I have Portable Msys2.
I mean to install cminpack.
As I understand, https://aur.archlinux.org/packages/mingw-w64-cminpack/ means such package is available. I expected then that the package shows up in the list of available packages, but
$ pacman -Ss minpack
gave no results.
Did I infer correctly that the package should show up as available in this list?
I also tried
$ pacman -Qs minpack
which gave no results.
(As I understand, any package listed in pacman -Qs should also be listed in pacman -Ss, so it was useless at this point).
Having concluded that a package being listed in this search list possibly does not imply it is available for msys2, I checked
$ pacman -Ss <pkg>
for a few other packages in that list. Some effectively gave no results.
Thus the question
How can I be certain if a package is available for msys2?
(If and when I am sure about that, I guess pacman -S <pkg> would install it).
See also this.
I think you got mixed between msys2 pacman and arch linux pacman. What you have linked is an AUR repository for arch linux, not MSYS2. The utility used pacman is taken over from arch linux, but that is all.
To search package for a packages within your repositories you really can use pacman -Ss <package_name>. If you can't find your package that means that within the installed repositories there is no such package.
If you can't find it you can always check the web: search within msys2 packages. If that is not enough you can do that search within all generated package MSYS2 history: packages at msys2 repositories.
I have check the repositories for your mingw-w64-cminpack package and that is not available for msys2. You would have to cross-compile it yourself.
Related
Is there a way to find out what default packages are installed along with Msys2 installation. I see that there is openssh, curl, git installed which I didn't. If there is a list that would also be useful. The official base package repository has a long list with thousands of entry.
After installing MSYS2, run pacman -Q to list the packages that are installed.
I just installed Windows Subsystem for Linux for the first time and downloaded the Debian distribution from the Windows Store.
The first thing I tried to do was use the "mv" command. The second thing was to run "man mv" because I don't remember how to use it. But I received the error:
-bash: man: command not found
It looks like the package I want is called manpages. But I can't install that:
sudo apt-get install manpages
[sudo] password for pi:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package manpages is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or is only available from another source
E: Package 'manpages' has no installation candidate
How do I get the man command up and running?
apt update to update the local package lists followed by apt install man-db to install the actual package.
I want to add to elken's answer that apparently, the 'man-db' packages doesn't cover all the manpages. For example, I needed documentation for the C stdio library (fopen, fgets, ...), and for that I had to install 'manpages-dev':
sudo apt install manpages-dev
Apparently there are also some other manpage collections (/different names for them on certain unix distros), see https://superuser.com/questions/40609/how-to-install-man-pages-for-c-standard-library-functions-in-ubuntu
I packaged an rpm using
make package
command, and copied the resulting rpm to another machine which has a company specific OS. Now when I try to install the rpm using
rpm --nodeps -i filename.rpm
I get the error the same as the one in the title.
So I ran
rpm -qa | grep rpm
on the machine used to build the rpm package, and got this:
rpm-4.8.0-37.el6.x86_64
rpm-devel-4.8.0-37.el6.x86_64
rpm-python-4.8.0-37.el6.x86_64
rpm-libs-4.8.0-37.el6.x86_64
rpm-build-4.8.0-37.el6.x86_64
redhat-rpm-config-9.0.3-51.el6.noarch
After a bit of investigation, I tried removing the redhat-rpm-config package and bam, rpm installation worked on the other machine. Now, this is a solution and all but I don't think I can just uninstall this package for every machine that we're going to use in creating the rpm. Is there any other way to ignore this redhat-rpm-config-9.0.3-51.el6.noarch when creating an rpm package using cmake?
What is the RPM version of the system you are installing on? Are its sources publicly available somewhere?
There could be various compatibility issues if you build binary RPMs using a newer RPM/distribution. In general, we build binary RPMs using the RPM and redhat-rpm-config versions in the buildroot (which is created by mock) itself, which matches the target RPM version, even if the build host has a newer RPM version.
If this is not an option for you, I would look at specific RPM features controlled by redhat-rpm-config. The one that sticks out to me immediately is payload compression:
# Use XZ compression for binary payloads
%_binary_payload w2.xzdio
Other changes include support for larger files, but this does not seem to be the issue here because it would not change by uninstalling the redhat-rpm-config package.
You very likely made binary RPM using rpmbuild on different OS than was the target OS. You should use "mock" for building the package.
dnf install mock
mock -r epel-6-x86_64 yourpackage.src.rpm
To solve "error: unpacking of archive failed: cpio: Bad magic" issue at RPM package installation on your machine:
1/ List rpm pkgs which are installed on the server machine (the machine on which the rpm pkg is generated):
$ rpm -qa | grep rpm
….
….
2/ If pkg redhat-rpm-config-9.0.3-51.el6.noarch is present in the given list, desinstall it:
$ rpm -e redhat-rpm-config-9.0.3-51.el6.noarch
3/ Generate now the pkg and tranfer it on your dev machine. Pkg installation should work.
Philippe.
I am using Mac for development. I installed Rust 1.13.0 using brew install rust and the Rust plugin 0.1.0.1385 for IntelliJ IDEA. I created my first test project with cargo and while opening it with IDEA I got the message
No standard library sources found, some code insight will not work
I haven't found any sources installed, nor the Rust sources package in Homebrew.
How do I provide sources for the project and what are the practical implication if I ignore this step?
As commented, the supported approach is to use rustup:
Navigate to https://rustup.rs/ and follow the installation instructions for your platform.
Add the rust-src component by running: rustup component add rust-src
Create a new Rust project in IntelliJ and choose your existing Rust project source. If the folder already contains previous IntelliJ project files, you may have to delete those first before it will let you proceed.
IntelliJ-Rust should automatically configure the standard library sources to point to the sources downloaded by rustup.
As a reference, since the question title is broad, for Fedora 28 I had to:
dnf install cargo rust-src
sudo ln -s /usr/lib/rustlib/src /usr/lib/rustlib/x86_64-unknown-linux-gnu/
then give /usr/lib/rustlib/x86_64-unknown-linux-gnu/src/rust/src as "Standard library"
Full setup:
Issue opened to simplify the process
When not using the rustup installer, one can install the source package and direct the rust plugin to use those:
(Tested with CLion 2020.2.1, rust-1.46.0-x86_64-pc-windows-gnu.msi, rustc-1.46.0-src.tar.gz. Offline Rust installers and source archive from there: https://forge.rust-lang.org/infra/other-installation-methods.html )
Although the preferred way of installing Rust is by using rustup, as pointed out by the other posts, it is not uncommon to use the packages that your distro makes available.
I use, for example, the packages provided by Gentoo and I share the same problem about the not prefilled field for standard libraries.
Nevertheless, you can easily find out where your standard libraries have been installed by typing the following find command:
find /usr/lib* -type d -name "rust" | grep src
or the following if you installed rust in your home
find -type d -name "rust" | grep src
The previous commands will help, unless, of course, in your distro there is a package for the binaries and one for the source and you only installed the binary one.
I know the question is for MacOS but this answer is shown up when searching for it on Linux. Below I will answer for Ubuntu.
The path is /usr/lib/rustlib/src/rust/src for Ubuntu 20.04
The way I did is:
Installed rustc from the repositories, which includes cargo
sudo apt install rustc
Then installed rust source package
sudo apt install rust-src
I used apt-file (can be installed with sudo apt install apt-file) to search for the install path of the sources
sudo apt-file update
apt-file list rust-src
This show the path as /usr/src/rustc-1.41.0/src .
But a ls -la in /usr/lib/rustlib/ will reveal symlinks and /usr/lib/rustlib/src/rust/src points to the previous found directory.
Using the symlink on IntelliJ will survive new rust versions.
For Fedora 32 install Rust using command:
dnf install cargo rust-src
and the path to standard libary source is:
/usr/lib/rustlib/src/rust
I used Ubuntu. I follow these steps:
sudo apt install rust-src
wait for the install, then
dpkg -L rust-src
copy the last line. For me it is the standard library path:
/usr/lib/rustlib/src/rust
For MacOS, you need to put /opt/homebrew/bin/.
Suppose I want to install python2.7 with yum, and do
sudo yum install python27
This will install a python2.7 in the /usr/bin directory. However, the symbolic link /usr/bin/python still points to python2.6.
Is there a yum command that can manage this symbolic link rather than doing it manually? I know the port select in MacPorts does so, and am looking for a counterpart in yum. Thanks a lot!
Unless the distribution has been set up to handle this sort of thing (the way debian and some others are) you do not want to be changing the default value of something like /usr/bin/python because you will break anything the distribution packages which depends on the default python being the version of python in the default python package.
Things built against the python27 package almost certainly use /usr/bin/python2.7 when they need to run python scripts and/or on their shebang lines. Things packaged by the default system almost certainly just use /usr/bin/python assuming that is the default system python version.