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).
In short, I’ve written a bash script (available from github) for configuring and removing instances of clamav-server on Fedora. It lets you create and remove individual instances with a specific user and port (if you specify them) and will install the required packages if not already present on the system.
In long, we use Clam AntiVirus as our antivirus protection for Digital Preservation Recorder and talk to it over the default port, 3310.
clamav-server package under Fedora however, doesn’t actually set up an instance. In fact, it doesn’t copy any system configuration files into place at all. This means that the system is left without any working ClamAV server out of the box.
Under Fedora, ClamAV server is configured on a per user basis. This is actually quite important (unless you run as root) because the daemon needs at minimum read access (and we’ve found also write) on the files/directory being passed for scanning.
The instructions on how to configure it are located under /usr/share/doc/clamav-server-[version]/ but I have taken these instructions and written a bash script to configure all of this for you.
The script is available from github. It can create or remove an individual instance of clamav-server using a specific username and port (if you want to specify them, else it defaults to clamav on port 3310). The script will also install any required packages, if you don’t already have them on the system.
Hopefully this is useful to someone else out there and not just us If you find any bugs feel free to let me know.
Matt has a post over on his blog about how to get the NVIDIA driver working under Fedora 12. I currently use the Nouveau driver, but I’m sure it’ll come in handy in the future. Thanks Matt!
It wasn’t as straight forward as it _should_ have been, as apparently there is a bug in the current (at time of writing) version of Xorg, which causes X to run really slow.
I’m not convinced that it’s a bug in X.org, sounds like a problem caused by the NVIDIA driver. If only it were open source..