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.
Related
On last Friday morning, I tried a "yum update" on my CentOS laptop, and it reported this:
Loaded plugins: fastestmirror, langpacks, verify
Loading mirror speeds from cached hostfile
* base: repo1.dal.innoscale.net
* epel: fedora-epel.mirror.lstn.net
* extras: mirror.unl.edu
* nux-dextop: mirror.li.nux.ro
* rpmfusion-free-updates: mirror.us.leaseweb.net
* updates: mirror.spro.net
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.16.2.3-13.el7_1 will be updated
---> Package nss-softokn-freebl.i686 0:3.16.2.3-14.2.el7_2 will be an update
---> Package python-ecdsa.noarch 0:0.11-3.el7.centos will be obsoleted
---> Package python2-ecdsa.noarch 0:0.13-4.el7 will be obsoleting
---> Package tzdata.noarch 0:2016c-1.el7 will be updated
---> Package tzdata.noarch 0:2016d-1.el7 will be an update
---> Package tzdata-java.noarch 0:2016c-1.el7 will be updated
---> Package tzdata-java.noarch 0:2016d-1.el7 will be an update
--> Finished Dependency Resolution
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
1. You have an upgrade for nss-softokn-freebl which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of nss-softokn-freebl of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude nss-softokn-freebl.otherarch ... this should give you an error
message showing the root cause of the problem.
2. You have multiple architectures of nss-softokn-freebl installed, but
yum can only see an upgrade for one of those architectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.
3. You have duplicate versions of nss-softokn-freebl installed already.
You can use "yum check" to get yum show these errors.
...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).
Protected multilib versions: nss-softokn-freebl-3.16.2.3-14.2.el7_2.i686 != nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64
I asked about this on #centos, and someone gave me some exploratory advice, but no real solution.
I experienced the very same issue on a Fedora 20 system (run in a docker container) when trying to install i686 development libraries. Reason were two not matching versions for x86_64 and i686, respectively.
Protected multilib versions: nss-softokn-freebl-3.19.1-1.0.fc20.i686 != nss-softokn-freebl-3.19.2-1.0.fc20.x86_64
For me it helped to call
yum distribution-synchronization
That automatically downgraded the x86_64 version. After that
I could install with
yum install nss-softokn-freebl.i686
and
yum list installed | grep nss-softokn-freebl
showed now:
nss-softokn-freebl.i686 3.19.1-1.0.fc20 #updates
nss-softokn-freebl.x86_64 3.19.1-1.0.fc20 #updates
Problem solved.
Today my Ubuntu updated Mono to 4.2.1.102. It will not allow a certain program I absolutely need to run. How can I down-grade it to 4.0.5.1? I have tried...
sudo apt-get install mono-complete=4.0.5.1
That doesn't work.
Edit your /etc/apt/sources.list.d/mono-xamarin.list and change:
deb http://download.mono-project.com/repo/debian wheezy main
to:
deb http://download.mono-project.com/repo/debian wheezy/snapshots/4.0.5.1 main
That will pin it to version 4.0.5.1.
FYI: Make sure that you do not have any alpha/beta repos for mono in any of your /etc/apt/sources/list.d/xxxxx.list files.
Basic Steps to Downgrade:
sudo apt-get remove mono-complete
# Edit your mono-xamarin.list and pin it to the version of your choice.
sudo apt-get update
sudo apt-get install mono-complete
Accessing older releases If for some reason you want to pin an older
version of Mono rather than updating to the latest, you can modify the
Debian repository to “wheezy/snapshots/X.XX.X” instead of “wheezy”.
For example, “wheezy/snapshots/3.10.0” will lock you to that version.
These snapshots will cease receiving updates as soon as the next major
Mono version gets uploaded - for example, as soon as Mono 3.12 gets
uploaded, 3.10 will never receive updates.
On RPM distributions, force the package version in your package
manager - all older versions are published in the YUM metadata and
should be available.
Ref: http://www.mono-project.com/docs/getting-started/install/linux/#accessing-older-releases
Ref: Versions available:
http://download.mono-project.com/repo/debian/pool/main/m/mono/
If, like me, you followed the official guide: https://www.mono-project.com/download/stable/ then you would have added an apt key and created
/etc/apt/sources.list.d/mono-official-stable.list
You can keep the key, but remove the file above using sudo rm -r /etc/apt/sources.list.d/mono-official-stable.list
Then make sure you follow the best answer above by editing the mono-xamarin.list file for the version you want and remove the version of mono you have.
Then apt update, then install mono-complete. An easy way to know you are correctly downloading and compiling a different version is that apt will prompt you asking if you want to download the files, and the size will be different.
Hope this helps someone, this last step made it work for me.
My system is Ubuntu 18.04.
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
I am hosting django-1.5 app on openshift. I need django-registration module which I have specified in requirements.txt file.
The problem is that openshift is not able to find latest version django-registration-1.0 but only django-registration-0.8 which is not compatible with django-1.5 Any idea how to resolve this or how to add manual link to latest version in requirements.txt?
I'm not getting why its not able to find package while it is available at PyPI.
remote: Searching for django-registration==1.0
remote: Reading http://mirror1.ops.rhcloud.com/mirror/python/web/simple/django-registration/
remote: Reading http://www.bitbucket.org/ubernostrum/django-registration/wiki/
remote: Reading <some other link>
remote: Reading <some other link>
remote: Reading <Some Other link>
remote: No local packages or download links found for django-registration==1.0
remote: Best match: None
I made it work using setuptools specifying dependency link, though why PyPI package is not working is still not clear to me.
from setuptools import setup, find_packages
setup(
...
...
packages=find_packages(),
include_package_data=True,
install_requires=['django-registration==1.0'],
dependency_links = [
"http://pypi.python.org/pypi/django-registration"
],
)
How about directly installing package by logging into the application gear via ssh and running:
source ~/python-2.6/virtenv/bin/activate
pip install --log $OPENSHIFT_DATA_DIR/inst.log https://URL_TO_CUSTOM_PACKAGE
OR
source ~/python-2.6/virtenv/bin/activate
pip install --log $OPENSHIFT_DATA_DIR/inst.log -E $VIRTUAL_ENV $path_to/package
Since the issue is still alive (argh!) and I couldn't install the last security release for django I had to find a workaround for this problem.
Inserting the following line to the top of the requirements.txt magically solved the problem:
--index-url https://pypi.python.org/simple
It just sets the base url for finding packages.
I know that the question is a bit old, but I had a similar problem with OpenShift. On PyPi the package wagtail had the latest version of 1.4.1, but on OpenShift only 1.3.1 was found. After git push it show an url in the output, which seemed to point to a mirror instead os the pypi.python.org.
I logged in the app and:
env | grep -i pypi
OPENSHIFT_PYPI_MIRROR_URL=http://mirror1.ops.rhcloud.com/mirror/python/web/simple
It seems that OpenShift by default uses it's own mirror for Python packages. A mirror that is a bit out of date. I don't know why. I can't really say whether it is better to do as tomako suggests or could the change be made to the env variable OPENSHIFT_PYPI_MIRROR_URL or how often the mirror is updated.