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.
Related
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.
In order to install matplotlib in Debian 9 should I issue
sudo apt-get install python3-matplotlib
or
pip3 install matplotlib?
What is the preferred way? Let me add more detail.
'man pip3' says
pip is a Python package installer, recommended for installing Python
packages which are not available in the Debian archive.
matplotlib confirms this
To install Matplotlib at the system-level, we recommend that you use
your distribution's package manager. This will guarantee that
Matplotlib's dependencies will be installed as well.
According to this I shall run apt-get. However, I had a similar case with numpy. 'import numpy' worked after 'pip3 install numpy'.
Using
Debian GNU/Linux 9.6 (stretch)
$ python3 -V
Python 3.5.3
The key quote from man pip3 is:
recommended for installing Python packages which are not available in the Debian archive.
You can check whether a package is available in the Debian archive by issuing an apt search command, eg.
apt search matplotlib
If your system already has all the necessary dependencies then installing a package with pip will work (as you experienced with pip install numpy).
If you do not have the necessary dependencies your distribution’s package manager will install them automatically. However, this is not true of pip: you would need to resolve any dependency issues manually. In the case of matplotlib, you can find a list of the dependencies you'd need to install manually here.
Essentially, using your system package manager to install a package takes away the extra work of ensuring you have all the necessary dependencies for that package.
pip comes into its own if you desire to work with virtual environments.
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/.