The goal is to compare the list of rpms under folder /tmp/list_of_rpms to installed rpm, and if the package is installed with a lower version then print this rpm.
The approach to check if rpm is installed or not can be easily verified with
rpm -qi gssproxy-0.7.0-30.el7_9.x86_64.rpm
package gssproxy-0.7.0-30.el7_9.x86_64.rpm is not installed
but actually this rpm installed with lower version as
rpm -qa | grep gssproxy
gssproxy-0.7.0-29.el7.x86_64
Can we identify also if rpm is installed with lower version?
The approach to take the installed rpm by rpm -qa | grep gssproxy
and then comparing it to the rpm file /tmp/gssproxy-0.7.0-30.el7_9.x86_64.rpm by regex is very complicated.
There's a dedicated tool called rpmdev-vercmp for comparing RPM versions. It's in the yum-utils package. apparently in a package named rpmdevtools.
Untested, but hopefully sufficient to get you started:
for rpm in /tmp/list_of_rpms/*.rpm; do
base=${rpm#/tmp/list_of_rpms/}
pkg=${base%-*-*}
if installed=$(rpm -q "$base"); then
rpmdev-vercmp "$pkg" "$installed" >/dev/null 2>&1
case $? in 12) echo "$installed is less than $pkg";; esac
fi
done
This doesn't do anything for packages which are not installed at all; perhaps you want to add an else clause and add a notification about those, too?
Some background from https://www.golinuxhub.com/2018/06/how-to-compare-rpm-version-bash-script-python-linux-algorithm/ but the actual code in that has problems. Also, https://unix.stackexchange.com/questions/163702/bash-script-to-verify-that-an-rpm-is-at-least-at-a-given-version
Related
I've installed this compiler before in a docker container, but I don't understand why it's missing right now. Command and error:
(iit_synthesis) brando9~ $ opam switch create ocaml-variants.4.07.1+flambda_coq-serapi.8.11.0+0.11.1 ocaml-variants.4.07.1+flambda
[ERROR] No compiler matching `ocaml-variants.4.07.1+flambda' found, use `opam switch list-available' to see what is available, or use `--packages' to
select packages explicitly.
but it's not in the list:
(iit_synthesis) brando9~ $ opam switch list-available
# Listing available compilers from repositories: default
# Name # Version # Synopsis
ocaml-option-32bit 1 Set OCaml to be compiled in 32-bit mode for 64-bit Linux and OS X hosts
ocaml-option-flambda 1 Set OCaml to be compiled with flambda activated
ocaml-option-nnpchecker 1 Set OCaml to be compiled with --enable-naked-pointers-checker
ocaml-option-spacetime 1 Set OCaml to be compiled with spacetime activated
ocaml-options-vanilla 1 Ensure that OCaml is compiled with no special options enabled
Opam update fails
Output:
$ opam update --all
<><> Updating package repositories ><><><><><><><><><><><><><><><><><><><><><><>
Processing 1/1: [default: http]
Processing 1/1: [default: http]
[default] synchronised from https://opam.ocaml.org
[ERROR] Could not update repository "default": "~/anaconda/bin/patch -p1 -i /dfs/scratch0/brando9/.opam/log/patch-99014-0624b6" exited with code 2
I probably should have started with this but I installed opam with "manually" with deb because I don't have sudo. In particular I did this:
# - opam (snap, no sudo)
# ref: https://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access
apt-get download opam
#apt-get download opam_1.2.2-4_amd64
# manually checked the opam name
#ls | less
mkdir -p ~/.local
dpkg -x opam_1.2.2-4_amd64.deb ~/.local/bin
export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc.user
source ~/.bashrc.user
tr ':' '\n' <<< "$PATH"
opam --version
before that I did try installing opam with conda (which has worked in the past) but it failed. I wonder if that screwed things up :/. Will try to reproduce to post the conda error. But I ran conda install -c conda-forge opam.
related:
How to install a specific version of ocaml compiler with opam
https://discuss.ocaml.org/t/why-doesnt-my-server-show-the-ocaml-compiler-that-i-need/10917
https://www.reddit.com/r/ocaml/comments/zed88p/how_does_one_install_a_specific_ocaml_compiler/
How does one install opam without sudo priveledges on linux/ubuntu?
I removed by mistake /usr/lib64/libpython2.7.so, and as a consequence, yum does not work.
So I'm trying to reinstall python2.7.18 (which is the version that I currently have) from source, but in compilation I get that some modules are missing
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _curses _curses_panel
_ssl _tkinter bsddb185
bz2 dl imageop
readline sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
But:
yum doesn't work, pip2 also doesn't work, setuptools for python setup.py install is not found...
And all solutions I'm finding involve some of those, so I'm getting into some circular problem here.
I looked for the *.rpm for python 2.7.18 for CentOS 7, in the hope I could just install it with rpm and solve the issue, but I couldn't find it.
Any idea?
Found a solution, starting from here.
After manually rm-ing all the /usr/**/*python2.7* files (probably just the libpython2.7.so* and the python2.7 executables would be enough), from
http://mirror.centos.org/centos/7/os/x86_64/Packages/, I downloaded
bzip2-devel-1.0.6-13.el7.x86_64.rpm
compat-db-4.7.25-28.el7.x86_64.rpm
dlm-devel-4.0.7-1.el7.x86_64.rpm
dlm-lib-4.0.7-1.el7.x86_64.rpm
gdbm-1.10-8.el7.x86_64.rpm
gdbm-devel-1.10-8.el7.x86_64.rpm
keyutils-libs-devel-1.5.8-3.el7.x86_64.rpm
krb5-devel-1.15.1-46.el7.x86_64.rpm
libcom_err-devel-1.42.9-17.el7.x86_64.rpm
libdb-devel-5.3.21-25.el7.x86_64.rpm
libdb-tcl-5.3.21-25.el7.x86_64.rpm
libdb-tcl-devel-5.3.21-25.el7.x86_64.rpm
libselinux-devel-2.5-15.el7.x86_64.rpm
libsepol-devel-2.5-10.el7.x86_64.rpm
libverto-devel-0.2.5-4.el7.x86_64.rpm
ncurses-devel-5.9-14.20130511.el7_4.x86_64.rpm
openssl-devel-1.0.2k-19.el7.x86_64.rpm
pkgconfig-0.27.1-4.el7.x86_64.rpm
python-2.7.5-88.el7.x86_64.rpm
python-devel-2.7.5-88.el7.x86_64.rpm
python-libs-2.7.5-88.el7.x86_64.rpm
python-pycurl-7.19.0-19.el7.x86_64.rpm
sqlite-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-devel-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-tcl-3.7.17-8.el7_7.1.x86_64.rpm
python-setuptools-0.9.8-7.el7.noarch.rpm
python-six-1.9.0-2.el7.noarch.rpm
python-tools-2.7.5-88.el7.x86_64.rpm
python-urlgrabber-3.10-10.el7.noarch.rpm
readline-6.2-11.el7.x86_64.rpm
readline-devel-6.2-11.el7.x86_64.rpm
popt-devel-1.13-16.el7.x86_64.rpm
rpm-4.11.3-43.el7.x86_64.rpm
rpm-apidocs-4.11.3-43.el7.noarch.rpm
rpm-build-4.11.3-43.el7.x86_64.rpm
rpm-build-libs-4.11.3-43.el7.x86_64.rpm
rpm-devel-4.11.3-43.el7.x86_64.rpm
rpmdevtools-8.3-5.el7.noarch.rpm
rpm-libs-4.11.3-43.el7.x86_64.rpm
rpm-python-4.11.3-43.el7.x86_64.rpm
sqlite-3.7.17-8.el7_7.1.x86_64.rpm
sqlite-devel-3.7.17-8.el7_7.1.x86_64.rpm
tcl-devel-8.5.13-8.el7.x86_64.rpm
tix-8.4.3-12.el7.x86_64.rpm
tix-devel-8.4.3-12.el7.x86_64.rpm
tk-devel-8.5.13-6.el7.x86_64.rpm
tkinter-2.7.5-88.el7.x86_64.rpm
yum-3.4.3-167.el7.centos.noarch.rpm
yum-metadata-parser-1.1.4-10.el7.x86_64.rpm
zlib-devel-1.2.7-18.el7.x86_64.rpm
and installed them with sudo rpm -Uvh --replacepkgs --force *.rpm.
Yum works fine now.
As the title said I can't install that specific version of g++ in my current ubuntu (20.04).
I have been trying the usual things as: sudo apt install g++- (and displaying all posibilities but there where only versions from 8 to 10). Same happend looking for gcc possibilities.
Also tried this: gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91 (same problem)
And after looking for a while I gave up in my research and ended up here. Hope someone with more wisdom than me can give my a hand with this.
These steps should work:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt upgrade
sudo apt-get install gcc-multilib libstdc++6:i386
wget https://ftp.gnu.org/gnu/gcc/gcc-4.8.5/gcc-4.8.5.tar.bz2 --no-check-certificate
tar xf gcc-4.8.5.tar.bz2
# cd gcc-4.8.5
# ./contrib/download_prerequisites
# cd ..
sed -i -e 's/__attribute__/\/\/__attribute__/g' gcc-4.8.5/gcc/cp/cfns.h
sed -i 's/struct ucontext/ucontext_t/g' gcc-4.8.5/libgcc/config/i386/linux-unwind.h
mkdir xgcc-4.8.5
pushd xgcc-4.8.5
$PWD/../gcc-4.8.5/configure --enable-languages=c,c++ --prefix=/usr --enable-shared --enable-plugin --program-suffix=-4.8.5
make MAKEINFO="makeinfo --force" -j
sudo make install -j
Note that you have to uncomment the .../download_prerequisites on some platform. For me it worked without on Centos 7 or Ubuntu 20 with the mandatory packages installed:
Ubuntu/Debian:
sudo apt install make wget git gcc g++ lhasa libgmp-dev libmpfr-dev libmpc-dev flex bison gettext texinfo ncurses-dev autoconf rsync
Centos:
sudo yum install wget gcc gcc-c++ python git perl-Pod-Simple gperf patch autoconf automake make makedepend bison flex ncurses-devel gmp-devel mpfr-devel libmpc-devel gettext-devel texinfo
Few seconds later (/giggles) gcc-4.8.5 is installed and available.
Notes:
if you don't have the resources to run make -j omit -j or use -j4 (or a different number which is adequate for your system)
your milage may vary and you may need to install further i386 packages
Since I can't comment I will add to #bebbo solution that on an Ubuntu 20.04 I had to add to his steps patching the following patches:
Add an include to signal.h to libsanitizer/asan/asan_linux.cc
https://patchwork.ozlabs.org/project/gcc/patch/6824253.3U2boEivI2#devpool21/
change a line in libsanitizer/tsan/tsan_platform_linux.cc
as shown. line number may not be the one stated in the patch so search for the line that was changed. There is no need to apply the patch to the other files
https://git.pantherx.org/mirror/guix/commit/0b93d04ac537d6413999349ebe7cdcb1e961700e
Adding to kpeace's answer...
sed -i '/#include <pthread.h>/a #include <signal.h>' path_to_gcc4.8.5src/libsanitizer/asan/asan_linux.cc
sed -i 's/__res_state \\*statp = (__res_state\\*)state\\;/struct __res_state \\*statp = (struct __res_state\\*)state\\;/g' path_to_gcc4.8.5src/libsanitizer/tsan/tsan_platform_linux.cc
Just adding a couple of sed lines to patch them inline.
Also, I've been writing some Ruby scripts to install some software (for fun of course.) I've recently successfully compiled gcc-4.8.5 under LinuxMint 20.1 (Ubuntu 20.04 based, compiler is the system gcc: 9.3.0, installed with sudo apt install build-essential) with this script. Also, I've installed all the packages that Bebbo suggested, including gcc-multilib and libstdc++6:i386 before running this script. Check up InstGcc4 class at the bottom of the code.
install_gcc.rb
They might end up to be 'un-installable' state a few months later. But at least gcc-4.8.5 works now.
ps. I've started to compile this old gcc due to CUDA... My hardware is a decade old GeForce 9600/9400 (yeah 2008 MBP) and CUDA 6.5 was the best option for that machine.
pps. Anyway, strange thing is, I had to give out '-std=gnu++11' for CXXFLAGS to avoid errors.
I have created a c++ app on Debian Jessie 8.10 amd64 which also need the following libraries:
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
I also need to cross compile the source code for armhf. So according to this quite helpful link https://wiki.embeddedarm.com/wiki/Jessie_armhf_Cross_Compile I gave the following commands:
sudo apt-get install curl build-essential
su root
echo "deb http://emdebian.org/tools/debian jessie main" >
/etc/apt/sources.list.d/emdebian.list
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | apt-key add -
dpkg --add-architecture armhf
apt-get update
apt-get install crossbuild-essential-armhf
Everything got installed correctly and then I also gave :
sudo apt-get install libssl-dev:armhf
sudo apt-get install libcurl4-openssl-dev:armhf
The first command executed successfully. On the other hand the second one failed giving the following output:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
libcurl4-doc:armhf libcurl3-dbg:armhf libidn11-dev:armhf libkrb5-dev:armhf libldap2-dev:armhf
librtmp-dev:armhf libssh2-1-dev:armhf pkg-config:armhf
The following NEW packages will be installed:
libcurl4-openssl-dev:armhf
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
23 not fully installed or removed.
Need to get 0 B/316 kB of archives.
After this operation, 863 kB of additional disk space will be used.
(Reading database ... 94032 files and directories currently installed.)
Preparing to unpack .../libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb ...
Unpacking libcurl4-openssl-dev:armhf (7.38.0-4+deb8u8) ...
dpkg: error processing archive /var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb (--unpack):
trying to overwrite shared '/usr/include/curl/curlbuild.h', which is different from other instances of package libcurl4-openssl-dev:armhf
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
/var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-4+deb8u8_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Since I'm quite new in cross compilation procedures does anyone have any idea what I'm doing wrong?
You are doing nothing wrong. It is a file conflict in related with multiarch packages. It is a bug in the package
Here is a explanation of this kind of bugs, from https://wiki.debian.org/MultiArch/Hints
The package in question is marked Multi-Arch: same, but has
conflicting versions of at least one file for different architectures.
The hint tells the filename (or the number of filenames) and the
architectures (or number of architectures) in question. The easiest
way to fix is to remove the Multi-Arch: same declaration, but often
enough it can be fixed by moving the offending files to
per-architecture locations (typically
/usr/lib/$(DEB_HOST_MULTIARCH)/). For *-dev packages, the Multi-Arch:
same capability often is not critical and removing is a good initial
measure.
I just run into the same kind of problem, which still is an issue with some packages. In my case libcurl-openssl-dev was replacing the /usr/bin/curl-config binary.
To me it required swapping from x64/i386 libraries when i needed cross-compiling but i am well aware it might not be possible for everyone.
opam list -a lists all packages currently available at OPAM, but does not display the version number for packages which are not currently installed, as per the opam list --help output:
(...) the output format displays one package per line, and each line contains the name of the package, the installed version or -- if the package is not installed, (...)
How can I list all packages including their version numbers?
Use opam info <packagename>.
I guess opam list does only prints the versions of already installed packages because of the package dependencies. Listing the latest versions of packages, for example, of not-yet-installed packages is not quite useful.
A refined (and quicker) version of anol's answer is to give the whole list of packages to opam show in one pass (asking opam to output both package and version field), and to process the result with sed, as apparently show outputs each field on its own line:
opam show -f package,version $(opam list -a -s) \
| sed -e '/ *package:/N; s/ *package: \([^\n]*\)\n *version: \([^\n]*\)/\1: \2/'
This is not an ideal solution, but using camlspotter's recommandation, I manually queried each package for its version field, using the following shell loop:
for p in $(opam list -a -s); do echo "$p $(opam show -f version $p)"; done
It works, but it takes ~85 seconds to complete on my machine (querying over 1000 packages currently available).