 
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:
 
 
        The result is that kernel-source is only needed and usable for building
yourNo extra packages needed to build kernel moduleskbuild in 2.6 almost requires packages to do it this waythe gross hacks we did to have unified "prebuild" 2.4
kernel-source were fragile and not scalable or well maintainablethe 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). 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.