Tag Archive for 'fedora'

Page 3 of 6

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
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
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
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
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
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.

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…

New Fedora website is great

I just noticed that in time for Fedora 14 (which has just gone gold), the project has released a new website.

It’s great. Has lots of useful information about Fedora, especially for new users.

Fedora website

Great work!

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.
name=Fedora Core $releasever - $basearch - ATrpms

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!


Samsung R480 laptop LCD brightness

Mendy got a Samsung R480 laptop but screen brightness did not work properly. Using KDE’s brightness slider caused the screen to flicker horribly and once you let go, it’s too dark. GNOME’s just doesn’t work at all.

After a suspend and resume with the Nouveau driver, the slider works properly, but only goes to half brightness at the maximum setting. It was possible to set the brightness manually via:
echo -n 60 > /proc/acpi/video/NVID/LCD/brightness

That was not suitable. So I switched to the NVIDIA driver, but the laptop brightness was immutable until I discovered a post with the solution. Simply adding the following to the Device section in /etc/X11/xorg.conf lets KDE control the brightness correctly, and perfectly. Great!
Section "Device"
Identifier "Videocard0"
Driver "nvidia"
Option "RegistryDwords" "EnableBrightnessControl=1"
Option "UseEdidDpi" "false"
Option "DPI" "96 x 96"

I also added the DPI option above to get 96×96 as some text was too large after switching to the NVIDIA driver. Fedora still suspends and resumes and everything is just perfect!

Getting full 32-bit support in 64-bit Fedora

Is as easy as installing the 32bit version of Red Hat’s Linux Standard Base (LSB) package:
yum install redhat-lsb.i686

Fedora minimal install

To get a basic, command line only, base packages install of Fedora, simply add “text” to the installer’s kernel line at boot.

This will then install around 200 base packages and give a small, clean, lean system. From here you can install whatever package or group you like to built it up to something you want.

See here for more options for Anaconda, the Fedora installer.

Update: Alternatively, select “Customize now” during the standard installation process and un-tick everything (yes, ALL package groups even the Base group!). This will then also install the same 200 base packages for a minimal system, but has the added benefit of providing the graphical installer. Use the netinstaller to reduce your initial download.

When Compiz won’t start..

So now that you know how to get Compiz working properly, what do you do if it still refuses to enable itself via the “Desktop Effects” program?

Justin had this exact problem on his machine. It appears that the compiz-gtk script wouldn’t start and my theory was that it’s unable to replace Metacity (for some reason).

So I fixed this by editing his gconf file directly
sed -i 's/metacity/compiz-gtk/' \

This means that Metacity is never loaded to begin with, instead calling compiz-gtk to do its magic.

This is exactly what is set after successfully enabling Compiz via the “Desktop Effects” program, so we’re just bypassing whatever problem was stopping it from being enabled (like I said, I think it was unable to replace Metacity).

If you have the same problem, try this fix. If it can’t start Compiz it will safely revert to Metacity.


Fedora 12 and Compiz (Settings Manager)

Fedora uses the older method of enabling Compiz, via the gconf plugin.

The “Desktop Effects” program under System -> Preferences runs the /usr/bin/compiz-gtk script (part of the compiz-gnome package) to enable Compiz, or fall back to Metacity (GNOME’s window manager).

gconf backend
The compiz-gtk script executes the command:
compiz --ignore-desktop-hints glib gconf gnomecompat

On systems here (with NVIDIA cards at least), the gconf backend package was not installed. This means that even though NVIDIA and 3D is all working, Compiz won’t start. So, installing the required gconf backend package should make it all work.

su -c 'yum -y install compizconfig-backend-gconf'

Now try again.

ccp backend
Upstream however, Compiz has moved away from gconf and is using libcompizconfig (ccp) and the CompizConfig Settings Manager (ccsm) to handle settings.

Installing the ccsm package under Fedora and changing Compiz settings using the graphical manager (CompizConfig Settings Manager) results in none of those taking effect.

This is because the compiz-gtk script is not loading the ccp module. So the workaround is to install ccsm and then modify the script to replace gconf with ccp.

su -c "sed -i 's/gconf/ccp/' /usr/bin/compiz-gtk"

Now try again.

Keep in mind that updated versions of the compiz-gnome package may overwrite this file, so you’ll need to edit it again in future if this happens.

Does your Mac have 64bit EFI?

Update: Actually, you might be able to install 64bit Linux on a Mac with 32bit EFI by including the “fakebios” GRUB2 option. I’ve updated the grub-efi tarball to include this and it works on my Mac Pro. Thanks to Martijn Broeders for this.

To install 64bit Linux onto a Mac using only EFI (and not MBR emulation) then your Mac must have a 64bit EFI. Run the following under OS X to discover whether you have 64bit or only 32bit:
ioreg -l -p IODeviceTree | grep firmware-abi

This should return something like:
| | "firmware-abi" = <"EFI32">

If you see “EFI32” like I do, then it means your machine can’t execute 64bit EFI loaders, so you’re stuck with 32bit, d’oh!. If you see “EFI64” then you should be able to install native 64bit Linux using EFI only, yay!

I discovered this while trying to load 64bit only my Mac Pro at work as an alternative to running Linux with multiple drives and MBR (which doesn’t really work) :-(

This is why the 64bit Fedora efidisk.img never worked on my Mac, but the 32bit one does.