Tag Archive for 'yum'

Fix problem updating packages in Fedora/Korora due to broken SELinux update

Unfortunately an update to the SELinux policy package in Fedora 20 (and therefore Korora 20) caused RPM scriptlets to fail when updating packages.

This bug only affects systems that have SELinux mode set to enforcing (which is the default) and were updated to version 3.12.1-116 of the selinux-policy package. If you have seen the following sort of error when updating packages, then this bug may affect you:

warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64

Below are the commands to resolve this issue (which has been fixed in an updated 3.12.1-117 version of selinux-policy).

sudo setenforce 0
sudo yum clean expire-cache
sudo yum update selinux-policy\*
sudo setenforce 1

The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum cache and install the SELinux policy update which fixes this issue. The last command re-enables SELinux enforcement.

If you previously installed any packages which failed with scriptlet errors like above, you can reinstall them using the following command:

sudo yum reinstall

You can find out what packages were installed after the broken update using a command like this:

sudo sed '1,/selinux-policy-3.12.1-116/d' /var/log/yum.log

If you require any assistance please don’t hesitate to ask for help using Engage or jump onto the #korora channel in IRC freenode.net servers.

Jockey device manager port for Fedora (using Yum)

One of the things I wanted to do for Kororaa was make Ubuntu’s Jockey device manager work. This would replace my current dodgy script and provide a mechanism for extending support for other devices over time (if needed). I’ve put my code on github if you want to check it out.

It wasn’t meant to be a joke, but on the 1st April this year I contacted Martin Pitt (the Jockey project lead) to pitch the idea. He helpfully replied saying that they’d written Jockey to be pretty vendor agnostic and that he had already discussed the idea of porting it to Fedora with Jon Masters. Indeed, he had did have the test suite working on Fedora 12 already (using PackageKit).

So I started out trying to understand the code and seeing what was possible. The core of the work is in oslib.py which implements the package management side of things (the default code uses PackageKit). Ubuntu has their own apt implementation, so I wanted to make a native Yum implementation.

There is some detection code (which shouldn’t need to be touched) and then there are the handlers for each device you want to manage (nvidia, etc).

A few weekends ago, Jason Nielsen and I got together to work on the code. In a few hours we had ported oslib.py to Yum, so I think the majority of the work there is done (thanks for your help, Jason!). It’s a much cleaner implementation than running PackageKit and parsing the results, because Yum is written in Python :-)

That’s where it’s at now. Next I need to create some handlers and then begin some testing. I’m holding off on the next Kororaa release, because I want to get this working before I ship it. Longer-term this naturally won’t go into Fedora, but perhaps into RPMFusion.

Parsidora (another Fedora Remix) has also been working on Jockey, but using the PackageKit implementation (I’ve sent them a message to see if they are interested in the native Yum version). You can try their existing implementation for Fedora 15 if you’re interested.

Hopefully I’ll have everything ready for Kororaa in the next few weeks, before Fedora 16 comes out! :-)

Kororaa Beta2 bug fixes

If you’re running Kororaa Beta2, there are a few bugs which require fixing.

Yum
Firstly, the KDE version incorrectly included Yum from Rawhide (development) tree (GNOME version does not have this issue). This means you are running an untested version of Yum, the system’s default package manager.

To fix this, disable the repo (or remove the repository file for it), then downgrade yum to the stable version.
sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/fedora-yum-rawhide.repo
sudo yum downgrade yum

Livna
The Livna repository, which is configured out of the box, seems to be having lots of problems with availability. This will be fixed in the next release, but in the mean time, you can disable or remove that repository.
sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/livna.repo

If you find any more issues, please let us know!

How to upgrade Fedora (using PreUpgrade)

Coming from a Debian background, upgrading to new releases is second nature. Unfortunately, Fedora doesn’t seem to have it quite as down pat. Nevertheless, it’s possible and works quite well (but there are pitfalls, so read on).

While upgrading via PackageKit is coming, there’s a pretty decent way of doing it with PreUpgrade.

For the impatient, the steps are:

  • yum update
  • yum install preupgrade
  • preupgrade (reboot)
  • yum distro-sync
  • package-cleanup –orphans (be careful!)
  • package-cleanup –leaves (be careful!)

Now the longer version. First, update your current system:
yum update

Install preupgrade:
yum install preupgrade

Run the preupgrade tool, and follow the prompts (remote upgrades over VNC also supported):
preupgrade

PreUpgrade will prompt to reboot your computer and will update your system automatically. All of your packages should be updated and your repositories configured for you (I also had RPMFusion, Chromium and yum-rawhide which all updated as expected). On one of my systems, even the NVIDIA driver was automatically updated and configured. Now you’re booted into your new Fedora 14 system.

OK, this is where things get a little tricky. Some packages might be no-longer supported, there might be removed dependencies and the like. So, there are two neat commands that we will use to identify these packages, so that you can remove them.

package-cleanup --orphans
package-cleanup --leaves

But wait.. I discovered that there’s a more important step to do first, or you’ll cause yourself a headache!

On my machine, this wanted to remove some pretty important packages, like kdelibs.
[chris@shem ~]$ sudo package-cleanup --orphans
[sudo] password for chris:
Loaded plugins: refresh-packagekit, remove-with-leaves
akonadi-1.4.0-3.fc13.x86_64
kdeedu-marble-4.5.2-2.fc13.x86_64
kdeedu-marble-libs-4.5.2-2.fc13.x86_64
kdelibs-4.5.2-8.fc13.x86_64
kdelibs-common-4.5.2-8.fc13.x86_64
schroedinger-1.0.10-1.fc13.x86_64
xorg-x11-drv-wacom-0.10.8-2.fc13.x86_64

Fedora (unlike certain other distros I know) provides major updates to the latest versions of packages (like OpenOffice.org, KDE, GNOME, etc). Yay! It’s possible that your new Fedora system is running the same version of, say KDE, as your old one. This was indeed the case with my Fedora 13 to 14 upgrade (both run KDE 4.5.2 at time of F14 release).

Actually, the build of some important packages on Fedora 13 (like kdelibs-4.5.2-8.fc13.x86_64) were actually more recent than on the newer Fedora 14 system (kdelibs-4.5.2-5.fc14.x86_64).

The package-cleanup tool correctly lists kdelibs-4.5.2-8.fc13.x86_64 as being an orphan and if you were to remove this, you’d break your system badly. In fact, if you’re running yum’s brilliant new autoremove deps feature, as I am, you’ll lose most of your system. It makes sense – you are telling yum to remove kdelibs, so it goes and removes everything that relies on it! Yikes.

So first, we need to fix this by running the yum distro-sync command which recognises that we need to downgrade that kdelibs packages (and not remove it!).

[chris@shem ~]$ sudo yum distro-sync
Loaded plugins: refresh-packagekit, remove-with-leaves
Setting up Distribution Synchronization Process
Resolving Dependencies
--> Running transaction check
---> Package akonadi.x86_64 0:1.4.0-1.fc14 will be a downgrade
---> Package akonadi.x86_64 0:1.4.0-3.fc13 will be erased
---> Package kdeedu-marble.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-1.fc14 will be a downgrade
---> Package kdeedu-marble-libs.x86_64 0:4.5.2-2.fc13 will be erased
---> Package kdelibs.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs.x86_64 6:4.5.2-8.fc13 will be erased
---> Package kdelibs-common.x86_64 6:4.5.2-5.fc14 will be a downgrade
---> Package kdelibs-common.x86_64 6:4.5.2-8.fc13 will be erased
---> Package schroedinger.x86_64 0:1.0.9-2.fc14 will be a downgrade
---> Package schroedinger.x86_64 0:1.0.10-1.fc13 will be erased
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-1.20100726.fc14 will be a downgrade
---> Package xorg-x11-drv-wacom.x86_64 0:0.10.8-2.fc13 will be erased
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
----
Dependencies Resolved
=================================================
Package Arch Version Repository Size
=================================================
Downgrading:
akonadi x86_64 1.4.0-1.fc14 fedora 677 k
kdeedu-marble x86_64 4.5.2-1.fc14 fedora 14 M
kdeedu-marble-libs x86_64 4.5.2-1.fc14 fedora 902 k
kdelibs x86_64 6:4.5.2-5.fc14 fedora 12 M
kdelibs-common x86_64 6:4.5.2-5.fc14 fedora 1.7 M
schroedinger x86_64 1.0.9-2.fc14 fedora 276 k
xorg-x11-drv-wacom x86_64 0.10.8-1.20100726.fc14 fedora 73 k
---
Transaction Summary
=============================================================================================================================================
Downgrade 7 Package(s)
---
Total download size: 30 M
Is this ok [y/N]

Once we downgrade these packages, we can then remove any other orphans we might have, with package-cleanup –leaves and package-cleanup –orphans (I didn’t have any). One last thing to note – Fedora will not replace packages from the newer release if they are exactly the same version. For this reason, you will probably have some F13 packages still installed on your computer – don’t worry, that’s correct. They will be upgraded in time (if required).

So, now I think I know how to successfully upgrade the system without breaking it :-) If anyone has some other tips or corrections, please let me know! Hope that’s helpful.

-c

Testing yum’s autoremove orphaned deps feature

Yesterday I wrote about yum’s new feature which can automatically remove unused dependencies when a package is uninstalled.

Today I got my hands on a suitable build of yum (add the yum-rawhide repo and set clean_requirements_on_remove=1 under [main] in /etc/yum.conf) and I started to test it out on several packages, all of which introduced dependencies. My initial findings? It’s great.

Single package with dependencies
I started with a single package with several dependencies. When I uninstalled the parent package, yum also removed all of its dependencies which were not needed by any other package (i.e. orphaned dependencies).

Let’s look at an example; installing Ekiga which pulls in 5 dependencies.

yum install ekiga
...
Installed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Installed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

OK, so we have Ekiga, and we have 5 dependencies installed. What happens if I remove Ekiga?

yum erase ekiga
...
Removed:
ekiga.x86_64 0:3.2.7-4.fc14
Dependency Removed:
evolution-data-server.x86_64 0:2.32.0-3.fc14 libgdata.x86_64 0:0.6.4-4.fc14 libgweather.x86_64 0:2.30.3-1.fc14 opal.x86_64 0:3.6.8-1.fc14
ptlib.x86_64 0:2.6.7-1.fc14

As I was hoping, yum removed all 5 dependencies along with Ekiga itself. Ta da!

Result: Tick!

Packages with shared dependencies
I then tested two packages which have shared dependencies. What I would expect is that only the dependencies which are unique to the application being removed, are uninstalled. Other shared dependencies remain, because the other program still requires them and is not being removed.

Let’s look at an example; mplayer and vlc. Both require the libcaca library and installing both packages pulled in this library.
VLC needs libcaca:

yum deplist vlc |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

And mplayer needs libcaca:

yum deplist mplayer |grep libcaca
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14
dependency: libcaca.so.0()(64bit)
provider: libcaca.x86_64 0.99-0.10.beta17.fc14

When I want to remove mplayer, yum only removes those mplayer dependencies which vlc does not also require, and leaves the rest (including libcaca).


yum erase mplayer
...
Removed:
mplayer.x86_64 0:1.0-0.119.20100703svn.fc14
Dependency Removed:
libvdpau.x86_64 0:0.4.1-1.fc14.1 lzo.x86_64 0:2.03-3.fc12 mplayer-common.x86_64 0:1.0-0.119.20100703svn.fc14

Note that libcaca was not removed, which is the expected result.

Result: Tick!

Removing a package’s dependency
I then tried to remove a dependency, rather than the parent package. I would expect this to remove all parents which required that package, along with their other dependencies.

Let’s look at an example, gnash-plugin. This package pulls in three dependencies (including the actual gnash package).


yum install gnash-plugin
...
Installed:
gnash-plugin.x86_64 1:0.8.8-4.fc14
Dependency Installed:
agg.x86_64 0:2.5-9.fc13 gnash.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

Now, let’s see what happens if I try and remove one of the dependencies.

yum erase agg
...
Removed:
agg.x86_64 0:2.5-9.fc13
Dependency Removed:
gnash.x86_64 1:0.8.8-4.fc14 gnash-plugin.x86_64 1:0.8.8-4.fc14 gtkglext-libs.x86_64 0:1.2.0-10.fc12

As you can see, it correctly removed the parent package, which could no-longer operate without the dependency.

This is such a great advancement over remove-leaves, where last time I tried to remove gnash-plugin (after testing it out, I didn’t want it) yum wanted to remove Firefox!! Fail.

Result: Tick!

Suggestion – clean up existing system
One thing I would like, is the ability to run a system wide cleanup using this code in yum, rather than other rpm orphan tools. Sort-of like an apt-get autoremove. Theoretically, if you’ve always removed any packages on your system with this new feature then you should be right, but it would be nice to sort-of do a clean up at any point (on any system) and get yum to remove any orphaned deps for you. Maybe this already exists.

If you want to clean up existing orphaned dependencies, then package-cleanup is your friend (from yum-utils).

Take a look at all the packages that are orphaned, and make sure it is sane.

package-cleanup --leaves

If you’re happy with the list, you can just remove them all (after you’ve enabled yum’s new autoremove feature, of course!):


yum erase $(package-cleanup --leaves)

You can instantly see the benefit of this new feature – on my machine this command also removes brand new orphaned dependencies, created by the orphans I’m removing! That’s 59 packages in total.

Without this yum feature, it would only remove 36 packages. You would need to run package-cleanup several times, until you’ve really removed all orphaned packages.

Similarly, this works for package-cleanup –orphans but it would be great it this was built into a single yum cleanup type function – one command to do it all.

Summary
From my initial testing, this works really well, although I’ll continue to test it and see how we go. Hopefully this will find its way into Fedora 12, 13, and 14 rather than just 15.

I’m so grateful for this work – it’s something I’ve been crying out for ever since I made the decision to stick with Fedora. Thank you, thank you, thank you!!

Yum gets autoremove dependency feature

Coming from a Gentoo/Debian background, one thing that has constantly bugged me on RPM based platforms like Fedora is the lack of decent, reliable dependency removal.

It seems so simple (and Debian has done it since the dawn of time) – if I install package x which pulls in dependencies y and z, then when I remove package x, I want to remove dependencies y and z, if they are not required by any other package.

Yes, there is the remove-leaves plugin for Yum and various RPM orphan checking tools, but in my experience, they are just not reliable.

So, I’m very happy to have discovered that Seth Vidal has merged orphaned dependency cleanup on removal into Yum. Hallelujah!

It’s in rawhide yum-3.2.28-13, and I’ll do some testing soon…

Encrypted DVDs and Fedora

The well known RPMFusion repository contains a lot of the useful software which Red Hat doesn’t ship by default (for licensing, patent or legal reasons). It is the amalgamation of several other repositories, including Dribble, Freshrpms, and Livna.

One helpful package that RPMFusion does not package however, is libdvdcss, the free software library which enables Linux to play encrypted DVDs.

Most users keep Livna around for this single purpose, but it is often offline (especially recently). So, here’s another solution – use ATrpms – another third party repository that includes lots of handy software.

The problem is, ATrpms has lots of other software which you might not want to update and which could conflict with the packages from RPMFusion. The solution? Tell yum to only include libdvdcss* packages from that repository. Easy.

To do this, simply add a new repo file (/etc/yum.repos.d/atrpms.repo) for Yum to configure it.
[atrpms]
name=Fedora Core $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1
includepkgs=libdvdcss*

Now, just run the following to update the repo and install libdvdcss (you may wish to remove the old package first, if you have it).
sudo yum check-update
sudo yum install libdvdcss

That’s about it!

-c

Die, yum, die

When running a yum command (such as yum check-update) it doesn’t always seem to capture the CTRL+C signal in order to terminate the process. This means it sits there for ages while it tries to access the internet.

So, to kill yum I simply background it with CTRL+Z and then run kill %1, which will kills the first in the jobs queue. Problem solved!

-c

Groups are yum

Just discovered how I can install grouped packages in Fedora using Yum.

First, you can list the groups which are available in your repositories with:
yum grouplist

This will contact the online repositories to retrieve the lists and dump it to your terminal.

I wanted to install KDE 4.3.x (yes, Fedora has updated to the latest version from 4.2.x, which was impressive) so to do this I ran:
yum grouplist |grep -i kde

This returned two results, the desktop itself and a development group for KDE. Naturally I want the first one, so I then installed KDE via:
yum groupinstall "KDE (K Desktop Environment)"

It’s quite a nice easy way to install groups of packages, rather than figuring them all out individually.

I’m sure this will create some issues but presumably I can remove the group with:
yum groupremove "KDE (K Desktop Environment)"

Indeed, running this wants to remove only 65 of the just installed 127 packages.. d’oh.

Running the same command with –remove-leaves now wants to remove 143 packages. I still don’t get removing packages with Yum. Nevertheless, group install is handy.

Fedora – removing unwanted deps?

OK, so I have Fedora running on my main machine (the default GNOME install), more on that later. First I need to understand some basic principles of Yum.

I have Firefox and everything is dandy. I wanted to watch a YouTube clip so I installed gnash-plugin.

Then I wanted to remove it because it wasn’t performing particularly well, but I want to also remove dependencies it has pulled in, leaving my system in the same pristine state it was in before I installed it.

So how do you do this?

I installed the package gnash-plugin with the command:
sudo yum install gnash-plugin

This pulled down three dependencies: agg, boost and gnash itself.

What’s the correct way to remove gnash-plugin and all the dependencies?

If I run:
sudo yum remove gnash-plugin
Then it wants to only remove the gnash-plugin package itself, leaving all the dependencies. Fair enough.

If I run:
sudo yum remove gnash
Then it only wants to remove the gnash-plugin dependency and leaves the rest. Also probably fair enough.

If I run:
sudo yum remove --remove-leaves gnash-plugin
Then it wants to remove all the dependencies plus some others which were not brought in by gnash-plugin like Firefox.

I don’t want to remove Firefox!

Help?

-c