Im have problem postgresql-10 in kali linux
│
│ The PostgreSQL version 10 is obsolete, but the server or client packages
│ are still installed. Please install the latest packages (postgresql-11
│ and postgresql-client-11) and upgrade the existing clusters with
│ pg_upgradecluster (see manpage).
│
│ Please be aware that the installation of postgresql-11 will
│ automatically create a default cluster 11/main. If you want to upgrade
│ the 10/main cluster, you need to remove the already existing 11 cluster
│ (pg_dropcluster --stop 11 main, see manpage for details).
│
│ The old server and client packages are no longer supported. After the
│ existing clusters are upgraded, the postgresql-10 and postgresql-client-10 packages should be removed.
│
│ Please see /usr/share/doc/postgresql-common/README.Debian.gz for
│ details.
How to fix it?
Capture screenshoot: https://imgur.com/Xq0mztb
You can apt-get remove postgresql-10 and postgresql-client-10, making the warning go away. You should first install the postgresql-11 packages and migrate your databases if you use any.
You can install the postgresql-11 using apt-get install.
Migrating the db could be done by following the instructions here:
https://www.postgresql.org/docs/10/upgrading.html
so that program works better if you update your kali linux first before installation.
sudo su
apt-get update
that trick always works in my case
Related
After having installed a few packages and the TensorFlow package updates with conda install, when running the command conda list I see that have two numpy packages:
numpy-base
numpy
numpy 1.14.3 py35h9bb19eb_2
numpy-base 1.14.3 py35h7ef55bc_1
Questions:
Why do I have two numpy versions?
which one is being used and why got numpy-base package even installed?
numpy, here, is an example of a metapackage, while numpy-base is the original numpy library package.
When a conda package is used for metadata alone and does not contain any files, it is referred to as a metapackage. The metapackage may contain dependencies to several core, low-level libraries and can contain links to software files that are automatically downloaded when executed. Metapackages are used to capture metadata and make complicated package specifications simpler.
The structure of a conda package is as follows, a metapackage only contains the info folder.
.
├── bin
│ └── f2py
├── info
│ ├── LICENSE.txt
│ ├── files
│ ├── index.json
│ ├── paths.json
│ └── recipe
└── lib
└── python3.x
If you look at meta.yaml file of numpy, it, in fact, has a comment saying
numpy is a metapackage that may include mkl_fft and mkl_random both of which require numpy-base to build.
Read more about conda packages.
I was installing a package using pkg and cancelled during the update check phase. I think this bugged it and now when I run pkg update it says it is on the latest versions. However, it most definitely is not.
Is there a way to force a clean repo list to pull the latest version info?
This is the error when I try to install php56 for example:
username#shavedbox:/usr/home/username # pkg install php56
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 1 packages will be affected (of 0 checked):
New packages to be INSTALLED:
php56: 5.6.6
The process will require 15 MiB more space.
2 MiB to be downloaded.
Proceed with this action? [y/N]: y
pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest/All/php56-5.6.6.txz: Not Found
(The most recent version is 5.6.7 so the file is obviously not found)
Any help is greatly appreciated! Not too used to FreeBSD...
The answer was simple.
pkg update -f
And then it worked fine. I need sleep.
Is yum aware of package chronology?
Suppose I build a package MY-PKG-0.40-1 and publish it in a yum repo with createrepo --update. Then I build another package with a lower version (from a different VCS branch), MY-PKG-0.38-5.
yum list recent seems to show the greatest version, not the latest one. However from the man page
yum list recent
List packages recently added into the repositories. This is often not
helpful, but what you may really want to use is
"yum list-updateinfo new" from the security yum plugin.
I've experimented with list-updateinfo new and finding little success. yum list-updateinfo new MY-PKG seems to return repositories the package belongs to...
What I want is something like yum list latest MY-PKG to return 0.38-5, given it's the latest version published to the repository, despite having already published 0.40-1.
The answer here is yes. Since yum manages RPMs and running rpm -qi <package> will list a Build Date field (which is part of the package header).
After digging around on the net, the yum python libraries, and working off some of the code samples on the yum wiki, I was able to code up a working sample which lists the latest version of a package.
#!/usr/bin/python
import sys
import yum
package = sys.argv[1:]
yb = yum.YumBase()
yb.conf.cache = 0 # Must run as root to search packages w/o cache
pl = yb.doPackageLists(patterns=package, pkgnarrow='all', showdups=True)
print 'Searching for latest version of package: ' + str(package[0])
if pl.available:
package = ''
latest = 0
for pkg in sorted(pl.available):
# XXX Works with sqlitesack, unsure if it works with rpmsack
buildtime = pkg['buildtime']
# If we're looking at the latest package, update the version
# and textual name for reference
if max(latest, buildtime) == buildtime:
latest = buildtime
package = pkg
print "Latest Package"
print package
I have tried to install mod_security, but it has the error, so I tried aptitude:
apt-get install libapache-mod-security
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libapache-mod-security : Depends: libapache2-modsecurity but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root#srv16540:~# aptitude install libapache2-modsecurity
The following NEW packages will be installed:
apache2.2-common{ab} libapache2-modsecurity modsecurity-crs{a}
0 packages upgraded, 3 newly installed, 0 to remove and 10 not upgraded.
Need to get 660 kB of archives. After unpacking 2,861 kB will be used.
The following packages have unmet dependencies:
apache2 : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
apache2.2-common : Depends: apache2.2-bin (= 2.2.22-1ubuntu1.4) but 2.4.6-2~precise+1 is installed.
apache2-bin : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
apache2-data : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
The following actions will resolve these dependencies:
**Keep the following packages at their current version:**
1) apache2.2-common [Not Installed]
2) libapache2-modsecurity [Not Installed]
3) modsecurity-crs [Not Installed]
Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
I do now know what Keep the following packages at their current version means.
I want to know what does happen if I press yes. Does it replace my current apache2? Do I need to back up before doing this?
ANSWERS
I do now know what Keep the following packages at their current version mean
aptitude is trying to resolve the dependencies and possible conflicts to satisfy your installation request. It then proposes a solution. In your particular case the first solution it finds is to keep everything as it actually is, that's what keep at their current version + [Not installed] means.
I want to know what does happen if I press yes , does it replace my current apache2 ?
No, that solution will basically do nothing.
Do I need back up before ?
As boring as it sounds, backups are a good strategy to save time in the long run. If you're messing with important data then it should be even more important for you.
CONTEXT
I've seen other scenarios make aptitute propose solutions with combinations like these:
Remove the following packages
Keep the following packages at their current version
Leave the following dependencies unresolved
The following packages have been kept back
The following packages will be upgraded
The following packages were automatically installed and are no longer required
The following extra packages will be installed
Suggested packages
The following packages will be REMOVED
(and probably others)
In your case if instead of accepting the solution (or quitting), you reject it by pressing n, then aptitude will try to figure out another scenario that could be useful and propose it to you again. You can iterate through the solutions doing that and if any of them satisfies you then you can accept it.
SOLUTION (?)
As far as I can see by your output:
apache2.2-common : Depends: apache2.2-bin (= 2.2.22-1ubuntu1.4) but 2.4.6-2~precise+1 is installed.
Your problem is that you have apache2-2.4.6-2~precise+1 installed which isn't available from standard Ubuntu precise repositories (most probably installed from this PPA), and you're requesting a package which conflicts with that other one.
I'd take a look at the answers on how to remove PPAs and after you have removed that source I'd reinstall apache 2.2 from the standard repos with this command:
sudo aptitude install apache2
That's exactly what it did for me:
$ sudo apt-get remove apache2-bin
$ sudo apt-get autoremove
$ sudo apt-get install apache2
Open synaptic manager and search for apache2.2-bin. Mark it for removal. Then
sudo apt-get install apache2
Just remove all the content of /var/lib/apt/lists directory:
sudo rm -rf /var/lib/apt/lists/*
then run:
sudo apt-get update
When using the priorities plugin for yum, I get shown the number of packages which have been excluded. Is there a way of displaying the names of those packages?
You could always run yum like this:
yum -d 9 install foo
and part of the logging output is excluded packages.
EDIT
Here's the command I use to see only the excluded packages:
yum -d 9 install foo | grep excluded
Just in case you were wondering.
From the docs available via Fedora's site, as well as the CentOS docs that sort of functionality is not supported.