New RPM Fusion packages: nvidia drivers for F12, staging drivers for F11 and F12

Just FYI:

• the nvidia graphics drivers finally showed up again in the RPM Fusion repository for rawhide (the current public rawhide to be precise, e.g. what becomes Fedora 12 soon)
• Most drivers from the linux-staging tree are disabled in the kernels that Fedora ships (among them a few wifi drivers like rtl8187se) . That's a good thing, as they are often of highly questionable quality (¹, ²). But some people nevertheless what them, as they own hardware that needs them(³). Those people from now on can get them easily for Fedora 11 and Rawhide/Fedora 12 by installing kmod-staging from RPM Fusion.
  Please note that:
  
  
  
  • the drivers for Fedora 11 are in rpmfusion-free-updates-testing currently and build for the kernel that is in Fedora's updates-testing repo; thus to use them you need to run something like "yum --enablerepo='*testing' install kmod-staging" and reboot into the kernel that is installed to use them
    
  • you need to install kmod-staging-PAE if you use a PAE kernel on your x86-32 machine
    
  • there are no akmod-staging package at this time
    
  • the package doesn't contain all the drivers from the staging tree; in case you miss one just file a bug in bugzilla.rpmfusion.org and tell the packager to enable it
    

Also note that it might take some hours till the mirror yum chooses for you offers the packages, as they were uploaded to the master repo just a few minutes before this blog posting got published.

We thank you for your attention and we wish you a pleasant flight.

(¹) that's the long story short

(²) don't expect the drivers to work well; NetworkManager for example will in have problems with some of the WiFi drivers in staging-kmod. In most cases that will be the fault of the driver and not NetworkManager, thus filing NetworkManager bugs that occur with staging drivers is likely a waste of your time.

(³) friends don't let friends buy hardware which need's staging (or even worse: proprietary) drivers on Linux

rpmfusion-{,non}free-remix-kickstarts -- or -- knurdix

There was always the idea to build a linux distribution with RPM Fusion packages within the RPM Fusion project -- e.g. live media and installer spins ^w remixes that are basically a distribution like Fedora under a different name and with some packages from RPM Fusion. There is/was Omega 10, which until now never became the official spin for one reason or another. Recently some other work was done to get one step closer to create a official "Fedora Remix" from RPM Fusion sooner or later:

RPM Fusion since a few weeks contains the packages rpmfusion-free-remix-kickstarts and rpmfusion-nonfree-remix-kickstarts in the repositories for Fedora 11 and Rawhide. They just like the Fedora package spin-kickstarts contain kickstart files that can be used to create your own linux distribution live-image using the Fedora Package Collection and Fedora's livecd-tools. A installer image is still on the todo list and might need some fixes in anaconda and the rpmfusion-{,non}free-release packages afaics.

The kickstart files in the two RPM Fusion packages are pretty basic: They simply include the kickstart files from Fedora, remove the Fedora branding, add the generic branding and add the repo definitions for RPM Fusion. That's basically it, because the comps groups from RPM Fusion extend the groups that Fedora defines and thus you automatically get all the packages you want depending on what's defined in the RPM Fusion comps files -- that is for example gstreamer-plugins-ugly and gstreamer-ffmpeg in the case of the Gnome groups and xine-lib-extras-freeworld for the KDE remix.

As a proffce of concept I created four remixes (Desktop and KDE for i586 and x86_64) for testing purposes and uploaded them to to the web for public testing. But warning: They are basically untested and just meant to show what's possible. Ohh, and due to the lack of a better name I just called them "knurdix" ;-) We'll need to find a different name for the official RPM Fusion images (which might be simply "RPM Fusion" or something else that sounds better).

Hopefully those packages and the kickstart files in it can help to get some people interested in the idea of a RPM Fusion remix -- maybe enough people to build and maintain official "Fedora remixes" with packages from RPM Fusion" in the long term. If you are interested to help just join the rpmfusion-developers list and share your ideas. Or get in contact with me directly, but the mailing list is the preferred way.

Make things easy

Alan Cox recently on LKML:

[...] If nobody else is interested then you can do the reviewing/acking
because clearly nobody else cares if you make a mistake. And if they do
then they'll be motivated to add resources to assist you ;) [...]

Sometimes I wonder if we should apply a similar concept in Fedora/RPM Fusion land more often.

Leave kmods in RPM Fusion, but make sure they work well

In short: Fedora IMHO should not ship separate packages with kernel modules (so called "kmod packages") as part of the package collection. But Fedora afaics needs to make sure things like kmods work well, even if they are not used in the Fedora package collection.

Verbose variant: Recently there was another(¹) discussion on fedora-devel about allowing packages with kernel-modules in the Fedora package collection. I'm one of the drivers of the original "kmod" packaging standard for kernel-modules in Fedora and take care of it in RPM Fusion these days (which uses a modified version). So obviously I have a strong interest in the area.

Nevertheless I stayed away from the discussion and I guess many would have been surprised if I'd shared my option: It doesn't make much (if any) sense to package kernel modules as separate packages in Fedora. The main reason for this option: Everything lands in one package repository anyway(²), so it's much easier for everyone to get the bits into Fedora's proper kernel package directly. And I agree with the suggested approach way to make that happen as well: get the modules upstream, e.g. in linus' "vanilla" kernel (and not the staging area), then Fedora will get them automatically.

But: Some widely used kernel-modules will never make it upstream. For others (like some of those in linux-staging) it's a long way that takes a lot of time, because the code of those modules often is in a bad shape; until that's fixed and an improved variant merged a lot of people are nevertheless willing to use the ugly code we have today, because for them it's often better than throwing hardware away.

Fedora ignores those cases -- afaics because they are "not the right thing to do" or maybe "politically incorrect". One can argue if that is right or wrong for Fedora, but that's a topic for a different blog entry. The real point I'm up to: users still want to get the modules they need. Thus they will either work around it locally, use/contribute to repositories like RPM Fusion, or switch to a distribution that offers them what they want.

The latter is something that is neither in the interest of Fedora or Red Hat. Hence I'd say it would be good if Fedora would make sure that things like kmods work well, *even if they are not used within Fedora* -- just like Red Hat makes sure that Oracle DBs work fine on RHEL (which uses kmods in RHEL5, so RHEL would benefit from proper kmod support and testing in Fedora as well). But that's not the case right now(³), which makes Fedora sometimes annoying or hard to use.

(¹) There have been a lot similar discussion around kmods over the past years.

(²) My option might be different if we had something like a "extras"/"unsupported" add-on repositories within Fedora, as that would make it obvious "hey, these modules are not part of the upstream kernel/might not work so well/might suddenly go away again".

(³) Note that the main problem afaics is on the Fedora side, so it's not really fixable for RPM Fusion. I outlined the details in a posting to fedora-devel last August, but nothing happened. There are ways to work around the problem using a yum-plugin. But that is not a real fix, because the problem is not specific to kmods -- it happens with a lot of other packages as well in cases where a RPM Fusion package depends on a specific version of a package that is part of Fedora (xine-lib and xine-lib-extras-freeworld for example). And yes, sorry, I don't have the skills to fix the problem myself. But I don't think I have to -- Fedora afaics is meant to be a community where people with different skills work on different areas of the project to make the whole thing better.

Fedora 11, kernel-PAE, and what it means for your x86-32 system

There is one small change in Fedora 11 that I guess will confuse Fedora and RPM Fusion users with x86-32 (aka i386/ix86) systems quite a lot, but afaics did not get enough attention yet:

• By default, the PAE kernel will be used on 32-bit hardware, where appropriate(¹).

"Appropriate" is not really explained -- maybe because it's a bit hard to sum up without going into the boring details. But basically it boils down to: The kernel with PAE support will be installed by Fedora 11 for x86-32 on the majority of x86-compatible systems that have been manufactured in the past three or four years(¹). So likely on your system as well if you are running a x86-32 distro on a modern system.

The important part: the package containing the kernel with PAE support is not called "kernel" -- it's called "kernel-PAE" instead. And that's not the only package where "-PAE" is used as suffix. That has major certain consequences on systems where Fedora 11 installs kernel-PAE:

• when you build kernel modules with akmods, dkms, or manually, then you from now on need to install kernel-PAE-devel instead of kernel-devel
• similar for kernel-modules: instead of "yum install kmod-nvidia" your now need to type "yum install kmod-nvidia-PAE". Yum otherwise will try to install the matching kernel without PAE support for you, which (in short without the boring details) is something you most of the time don't want(²).

In other words: the change in Fedora 11 makes lots of howtos, FAQs, articles on the net and in computer magazines confusing, wrong, misleading or harmful (depending on view and specific howto/FAQ/article), because most of those docs don't consider the above fact (yet).

And that's not Fedora's fault -- PAE kernels are around for a long time in Fedora already. But they were used only on a minority of systems. Most (not all!) of those that have written today's howtos, FAQs or articles were likely either not aware of it or chose to ignored it to keep things simple.

That's backfiring now. So go and spread the news on mailing lists, forums and other places where it might be of interest. Feel free to copy-n-paste this whole text or simply point to this blog entry. Thanks in advance!

(¹) E.g. since processors with NX bit became mainstream; NX stands for NoeXecute and is also called Enhanced Virus Protection by AMD and xD-Bit by Intel

(²) not sure, but maybe the yum-plugin "yum-fedorakmod" could have made yum to the right thing and install the proper kmod for the PAE kernel. I never tried and it doesn't matter much as the plugin is not available in the Fedora or RPM Fusion repositories for F11. If someone wants take care of yum-fedorakmod and wants to get it into RPM Fusion then please drop me a line.

Enable RPM Fusion during Fedora install

To all those that install the brand new Fedora 10: If you enable the RPM Fusion online repositories during install you'll in F10 and later will automatically get some of the packages installed that RPM Fusion provides. Which packages? Well, that depends on what software you choose; if you for example stick to GNOME you'll get gnome-mplayer and some gstreamer plugins by default.



For details how to use RPM Fusion during install please take a look at the documentation in the RPM Fusion wiki. It also holds some information's how to enable RPM Fusion after installing Fedora.

See also:

• RPM Fusion free and nonfree repositories for Fedora 10 (Cambridge) now available on fedora-announce-list

RPM Fusion for EL in the early testing stage

A lot of people in the past asked for a „Livna for RHEL/CentOS“. There were rough plans to create one, but they got dropped immediately when the idea to merge Livna with other 3rd party repositories for Fedora came up. That lead to RPM Fusion being formed,which was announced one week ago.

Sharp eyes will have noticed that the announcement did not contain any information's regarding support for EL. That was on purpose – we focused on getting RPM Fusion running, hence the EL branch (which was planed right from the start) did not get as much love as the Fedora branch. But the EL branch is in the works and some of the most important RPM Fusion packages have been built for EL already. Xine and xine-lib-extras-freeworld for example are available in the testing repository already; the AMD and Nvidia drivers are still missing, just like mplayer and vlc. But all of them should hopefully get into the repositories over the next few weeks.

You can already help testing the RPM Fusion packages for EL repositories by enabling it with this command:

rpm -ivh http://download1.rpmfusion.org/free/el/updates/testing/5/x86_64/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/x86_64/rpmfusion-nonfree-release-5-0.1.noarch.rpm

Some of the RPM Fusion packages for EL require bits from EPEL, hence it's necessary that you have EPEL configured and enabled as well – just like you had to enable Fedora Extras to use Livna in the Fedora Core days. Just remember that the RPM Fusion for EL repositories are still in the early stages. Also not that you for now need to enable epel-testing, as some of the RPM Fusion packages depend on packages that are currently in epel-testing. That requirement should hopefully vanish with the next testing -> stable move in EPEL. The RPM Fusion for EL repositories of course don't replace and packages from EL or EPEL.

Note that not all RPM Fusion contributors have interest in building their packages for EL (just like not all Fedora contributors participate in EPEL). Hence we could need some help and people with rpm packaging skills that help getting the RPM Fusion repositories for EL filled and maintained. If you are interested contact me in private or (preferred) join the mailing list and just start to help.

Second step of the transition from Livna to RPM Fusion: Moving F8 and F9 testing users over

After enabling the RPM Fusion repositories for users of Livna devel a few weeks ago we now do the next step to move livna users over to RPM Fusion: Enable RPM Fusion for those F8 and F9 users that have livna's testing repos enabled.

The way to do that is round about the same as in the devel branch earlier: I added the rpmfusion-release packages for RPM Fusion's free and nonfree repos to the livna repo for F8 and F9; afterwards I built new livna-release for F8 and F9 that went into livna-testing; those two livna-release packages track the two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically.

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release.

The plan is to move regular livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

It's even easier if you have livna enabled already:

yum install rpmfusion-free-release rpmfusion-nonfree-release

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Just a reminder while at it: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.

First steps of the transition from Livna to RPM Fusion begins soon

Over the next few days (likely on Tuesday evening CEST) we'll begin to slowly move users from Livna over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide repos for livna-devel users.

The plan to realize that transition is quite simple: We'll add the rpmfusion-release packages for RPM Fusion's free and nonfree rawhide repos to the livna-devel repo; then we'll build a new livna-release package that tracks those two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) will get RPM Fusion enabled automatically. Yum/PK will download a big bunch of updates during the next update, as all the packages were build anew for RPM Fusion; but rawhide users are likely used to that, so this should hopefully not be a big problem ;-)

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna-devel enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release. But please note that all the packages that have been imported to RPM Fusion will not be updated anymore in livna-devel from now on, to save work for repo and package maintainers!

The plan is to move livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

And if you installed a Fedora Beta or Rawhide then from now on use the following command to enable RPM Fusion for rawhide:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.