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…
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.
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!
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!
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!
Is as easy as installing the 32bit version of Red Hat’s Linux Standard Base (LSB) package:
yum install redhat-lsb.i686
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.
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 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).
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.
Upstream however, Compiz has moved away from gconf and is using libcompizconfig (ccp) and the CompizConfig Settings Manager (ccsm) to handle settings.
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
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.
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.
With X.Org 7.5, multitouch support under Linux has finally arrived and appears to be working very well. There’s a new video showing it off, along with instructions on how to get it going (most of it works out of the box on Fedora 12).