FedoraNEWS.ORG
Google Site SearchFN Site Search FN Blog Login FN Blog Login
Site Navigation:
 
 

Fedora News Updates #14

by Colin Charles

For the week of: Saturday, July 31 2004

Available at: http://fedoranews.org/colin/fnu/issue14.shtml

Issue fourteen has arrived. Why the delay? Because traveling, chilling, and having a life seemed like a fun thing to do :) But that meant catching up with lots more news to update this with, so, this is probably going to be very lengthy. Rest assured, I'm all energized to take on the lists again, and thanks for all the e-mail contributions for this issue.


Fedora Core 3 goals & schedule; FC3 test1 released

The schedule and goals have been posted up at the Fedora Project website. Fedora Core 3 test1 has also been released.

USB Multi-card readers

Some folks seem to have problems when using USB multi-card readers, so Robert Dale wrote a quick HOWTO: FC2 USB Multicard Reader. William Hooper adds that recompiling the SCSI module is not required, and reminds others to provide the information to Bugzilla, so that the multi-card readers can be white-listed. Dave Ulrick mentions using max_luns as an option instead, and all this is provided in the updated guide linked above.

kernel-sourcecode

This has been a change that seems to have caused a lot of discussion on the lists. Arjan van de Ven has kindly provided some insight into the issue.

Ok this needs a bit of perspective:

1) Ever since RHL 7.0, the only true location of kernel headers to build
external modules against has been /lib/modules/`uname -r`/build/include. In
RHL7.0 to RHL9 and in FC1 that was *implemented* via a symlink into a
directory that is populated by kernel-source package. Unfortunately it has
taken 3+ years for the more obscure external modules to adjust to this, some
still reference /usr/include or /usr/src/linux which are wrong since after
RHL6.2

2) In all 2.6 kernel rpms we've had ever since the first ones (October last
year or so), we made the "build" directory not a symlink but an actual
directory with real files in it. Doing things this way has quite a few
advantages:
  • No extra packages needed to build kernel modules
  • kbuild in 2.6 almost requires packages to do it this way
  • the gross hacks we did to have unified "prebuild" 2.4 kernel-source were fragile and not scalable or well maintainable
  • the 2.4 situation caused a *lot* of problems for people who wanted to build their own customer kernel (just search bugzilla or Google for "make mrproper" and such).
The result is that kernel-source is only needed and usable for building your
own custom kernel with modified .config file. This approach thus shipped in all FC2 test releases and in FC2 final.

3) For the FC2 erratum we had a problem, kernel-source became noarch (which
is better for a lot of reasons including space usage and build time). In the
testing phase we found that going i386->noarch broke updates via yum and
up2date (see fedora-test-list archives). The only sane way out was to rename
kernel-source to something else, and make it Obsoletes: and Provide:
kernel-source. The name of choice was kernel-sourcecode. Since that provides
kernel-source, no rpm dependencies break and yum can now upgrade properly
etc. Doing such a change is of course unpleasant but I think few people
think it's really a big deal, especially given the rpm level compatibility.

Now the actual controversy; after the flamewar that was riddled with
misunderstandings about how 2.4 and 2.6 are different etc, some people
started wondering "why do we ship something like this which basically
duplicates files and not much more; they are one rpmbuild -bp away after
all". (well to be honest such questions were raised before already just now
they became higher in volume). The question is a good question, so I decided
to make kernel-sourcecode a separatable specfile toggle so that we can
experiment with disabling kernel-sourcecode for Fedora Core 3. After all, if
you're going to build your own kernel you have to do like 10 steps already,
one more isn't that big a deal. The package with this switch in the off
state ended up in rawhide (which is good, it tested if upgrades worked) and
that caused yet another flamewar.

In both flamewars the issue of building kernel module rpms came up, and
especially in relationship to building those for various architectures in
parallel. 2 existing solutions for that exist already as discussed on
fedora-devel-list, yet some people in that flamewar ignored those entirely
and considered the removal (or even the renaming of kernel-sourcecode)
making such things impossible. That would have been true for the 2.4 based
distributions, but is not so for FC2; as described above, kernel-sourcecode
is not preconfigured. In fact ever since RHL8 or so the Makefile in
kernel-source contains the word "custom" in the version to not let people
who build their own kernel not overwrite their existing working kernel by
accident and ending up with a non-booting system. For FC2 we now (based on
complaints in fedora-devel-list) are going to ship different example config
files in kernel-sourcecode with defaults that are more suitable for custom
self builds.

Now how to write 2.6 compatible makefiles for modules:

Say your module is called foo.c, this is how you build it for 2.6
Create a Makefile with just one line:
obj-m := foo.o

and build it with
make -C /lib/modules/`uname -r`/build SUBDIRS=$PWD modules

and.. that's it. It JustWorks(tm), no complex 20 page long Makefiles needed
etc etc etc.

In addition to that, Arjan has also enabled a patch for gpg-signed kernel modules, with more information available at: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg01072.html.

FC1 to FC2 updates

While most of us should be discussing FC3 test1, Tom Mitchell has a good summary of the issues that will plague users upgrading from Fedora Core 1 to Fedora Core 2. The useful summary is at http://www.redhat.com/archives/fedora-list/2004-June/msg04502.html. This is built up upon what Jim Cornette had to say.

Getting external (tape) storage working

James Kaufman goes through the methods for getting a tape drive working under Fedora. It includes possible debugging steps, and is relatively complete. If you're running an Iomega REV, rather than a tape drive, a user has pointed to the IOM RRD Tools website.

Some new documentation

Translations in Fedora

Plenty has been happening with the Fedora Translation Project, and some of the discussion has sprouted:

Fedora.us update policy improved

Ville Skyttä has got some concrete documents on improving the flow and the documentation of the fedora.us process. The relevant links are at: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00887.html.

Michael Tiemann has written a rather lengthy piece titled the Definition of Core, Extras and more (Fedora Collection Strawman). It provides a general view of how one person sees the Fedora Project. Read more at: http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01325.html.

A few more bits and pieces

Errata

Jef Spaleta wrote in with regards to the gnome-session-properties missing in the menu entries. This is fixed in the next release, as stated in bug #121458. It turned out to be a tiny syntax bug, missing  a single ";"!

Software

OpenAFS RPMS

Preliminary OpenAFS 1.3.x RPMS have been created by Matthew Miller, and they're available for Fedora Core 2. Read the announcement at: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00708.html.

Desktop Enabled kernel

Jean-Eric Cuendet decided to create a "desktop enabled" kernel. He has added Supermount, Preempt, and NTFS read/write, and there are plans to integrate laptop patches (?), Con Kolivas' patchset for interactivity and possibly others. Check it out at http://gdj.sf.net/.

GFS

Red Hat released GFS, when they bought Sistina, and Havoc Pennington pointed out to the relevant links when this happened. Matias Feliciano also points us to a wiki and some untested RPMS at: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg01010.html.

nVidia releases drivers

Many people submitted that nVidia have finally released a 4kstacks compatible binary at http://www.nvidia.com/object/linux_display_ia32_1.0-6106.html, and the RPMS should make their way soon, so keep watching http://bugzilla.livna.org/show_bug.cgi?id=83.

udev in initrd

Thomas Woerner has some RPMS available for testing udev with - these are FC3 test1 based. Read more at http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00514.html.

dmraid

The Device Mapper RAID tool which discovers, activates/deactivates and displays properties for software RAID sets has been released, and testers are required. Read more at: http://www.redhat.com/archives/fedora-list/2004-July/msg03335.html.

Thank you for reading this issue of Fedora News Updates. Think there's some news snippet you'd like to contribute to Fedora News Updates? Send e-mail to colin@fedoranews.org.

This issue of Fedora News Updates brought to you by Colin Charles.