Folks, What can I do to help get rpmFusion branched for RHEL 6? I have mirrors of the beta setup here: http://ftp.linux.ncsu.edu/pub/redhat/linux/beta/6/ Being that folks seem more interested in trying the kABI method of packaging kernel modules I've taken a look at what the current status of that is and what work needs to go into that. First off, there are no kernel modules in the RHEL 6 Beta. However, all the packaging foo that generate the ABI hash values are still in place. I've looked at the gfs-kmod, kvm, and the ipw3945-kmod packages from RHEL 5. Unfortunately, Red Hat isn't so much as using a packaging standard as we know and love them. The source packages vary wildly from the standard specs described in the kmodv1 standard. The gfs-kmod and ipw3945-kmod packages are, however, pretty close to kmodv1 standard. I don't really see anything that we couldn't deal with, but I would not expect kmods packaged by Red Hat to be as consistent as we've been with kmodv1 and v2. As with kmodv1, the source packages include the kmodtool helper script. I believe that the kmodtool provided by all three of the above packages are different in minor ways. Creating a standard version shouldn't be hard. The main difference with the script from kmodv1 is that the script will insert in the kmod-foo package %global _use_internal_dependency_generator 0 Which makes RPM not use its internal dependency magic. Rather, RPM uses the following scripts to generate requires and provides: /usr/lib/rpm/redhat/find-requires /usr/lib/rpm/redhat/find-provides The find-requires script will locate files in the package that look like kernel modules (matches ^.*/lib/modules/(.*)/(.*).ko$) and if those files are present find-requires executes /usr/lib/rpm/redhat/find-requires.ksyms Which generate the kABI hash values that the kmod-foo package needs to require. I wanted to port my OpenAFS package to use kABI for the start of a working proof of concept, but I was unable to build kABI packages in mock. The find-requires.ksyms script uses the 'join' command which groks its file descriptors directly in /dev/fd/*. That symlink is not created in mock's /dev setup. My attempts to bind mount my workstation's /dev into the build chroot made other parts of the chroot creation fail.[1] Poking around with the kABI stuff leaves me with some questions for the group: This is very much kmodv1 with very few changes. The nature of this method keeps multiple installed packages and upgrading corner cases to a minimum as only one kmod-foo package per kernel variant is needed. No kernel version-in-package-names. Are there other features of kmodv2 that kABI doesn't in some way supply when applied to kmodv1? Do we want to update the kABI "standard" in any ways and will the resulting differences in our standard vs. Red Hat's packages cause concern? A Yum plugin may still be handy to cover some corner cases. (Installing a kmod-foo for all installed kernel variants. Others?) Red Hat tends to build their kABI kmods for kernels that were never released. These packages could have a tendency to clutter /lib/modules/* Would anyone know the right mock incantations to get these things to build properly? Once I have a working proof of concept building in mock I'll get the rpmFusion wiki updated with some documentation of this standard. Jack Neely [1]: Why this started failing I never figured out: DEBUG util.py:291: Executing command: ['perl', '-p', '-i', '-e', 's/^(mockbuild:)!!/$1/;', '/etc/passwd'] DEBUG util.py:330: Child returncode was: 2 -- Jack Neely <jjneely(a)ncsu.edu&gt; Linux Czar, OIT Campus Linux Services Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89