Re: Can't get pc speaker to work.

From: Enrique Perez-Terron (enrio_at_online.no)
Date: 09/10/05 

Date: Sat, 10 Sep 2005 22:23:55 +0200
To: "Jeffrey Adler" <jeffadler.at.bigfoot.dot.com@nowhere.com>

On Fri, 09 Sep 2005 18:57:21 +0200, Jeffrey Adler
<jeffadler.at.bigfoot.dot.com@nowhere.com> wrote:

> THANK YOU! I sincerely appreciate a real (and informative) answer. I
> can now go on with my quest for enlightenment. Just knowing where to
> start is a GREAT help.

Unless it is too late now, I can perhaps save you some more time by telling
a little about tweaking rpm packages. If you have already worked through
all
this, or opted for sidestepping rpm, this could be helpfull for people who
google and find this thread.

Since I am quite likely to get some details wrong, I hope anyone who
catch an error will speak up.

I use Fedora Core, not SuSE. That is likely to generate some differences.

There is a package kernel-source, which is not the same thing as the
kernel source package. Confused? Hang on.

All rpm packages have a source package. Sometimes a family of related
packages have a common source package. Source packages have names ending
in ".src.rpm". If you install such a package (rpm -i xxx-yyy.src.rpm),
then cd to (the path will likely be different on SuSE)
/usr/src/redhat/SPECS
and run the command "rpmbuild -ba xxx.spec", then rpmbuild will build the
binary rpm packages that are derived from this source package. The
result will be (almost) exactly the same as those packages you download
 from the distribution or update. (There can be differences because
the configure scripts can possibly optimize for the CPU you are building
on, which may be different from the one the distribution builders had.
There can also be differences because you have a newer compiler, etc.)

The kernel-source package is there to make it easier to build kernels
that are not equal to the one in the distribution. The kernel is the
only piece of software that I know of, that has such a "service".

In general, when you tweak software packages available as rpms, it is
a good idea to use the rpm source package, and keep a few files that
allow you to patch later versions of the package with limited effort.

Rpmbuild proceeds through the following stages, whose details are coded
in a file xxx.spec in the SPECS directory

  - untar source tarballs, that are unmodified by the distribution,
    or "pristine", just as the relevant project released them.
  - apply patches that the distribution added to the software.
  - the usual configure-make-make install cycle, but with the
    install step installing to a separate destination tree, usually
    in /tmp/something.
  - create binary rpms by picking files from the destination tree,
    in accordance with file lists in the xxx.spec file.
  - check if there are files in the destination tree not packaged
    into any binary rpm.
  - compute dependencies on libraries and possibly other things,
    and encode them into the binary rpms. The xxx.spec file can
    of course have something to say here.
  - save the binary rpms in SPECS/../RPMS/<arch, e.g. i386>
  - create a (new) source rpm packaging your (modified?) xxx.spec
    file, the source tarballs and patch files, and saving the
    source rpm in SPECS/../SRPMS

For documentation about rpm and spec files, google for "maximum rpm".

When you want to tweak the package, you will typically use the
-bp option instead of -ba. Then the process stops after applying
patches. You can now inspect and modify the build tree under
SPECS/../BUILD/xxx-yyy, generate patch files for your changes,
place the patch files in SPECS/../SOURCES, and add a few lines
to xxx.spec to have the next build include your patch files.
It is a good idea to create a copy of the build tree before
start changing it; it is harder to remember to save a copy of
each file you modify.

At this point you will use rpmbuild again, typically with the
-bc option. This deletes the build tree, and runs the process
above again, this time stopping after the configure-make-make-
install stage. This allows you to check the results
and iterate until you get everything right. In the end you will
run rpmbuild -ba.

If you then keep a patch for the spec file, and your added patch
files, when the next official update or release to this package
appears, you can apply your changes to the new spec file and run
rpmbuild -ba.

If you prefer to bypass rpm and just install directly from the
rpm build directory (or any other build directory), you will
later risk that some packages cannot be installed because rpm
does not know you do have the prerequisites installed.

(Of course, there is a --force and a --nodeps option to rpm, to get
you around this.)

    -----

When we talk about making kernels, the kernel-source package
comes already-patched with the distribution patches. The various
configuration files for smp, uniprocessor, etc, are in an added
directory, I have forgotten the name. Pick one as your starting
point and copy it to ".config" in the kernel build top directory.
Or, as others suggest, look for /boot/config* (note the star),
or, if your kernel supports it, look for /proc/config.gz.
Now run one of the configuration programs, like "make xconfig"
This runs a tcl application with lots of buttons and checks of
the interdependencies of the kernel configuration options.
Each option is more or less tersely described in the a help pane.
When you save, it will save to .config. You can also, from inside
xconfig, load other files and save results to other file names
than .config.

Then the steps are, IIRC, make deps; make; make modules; make install.

If you later want to make a different configuration, you should do
a "make mrproper" before "make deps".

I hope this helps.
-Enrique