FYI, if you're not using xdm/kdm/gdm but are instead starting the X11 server manually with
startx (which is what I usually do) you might have experienced brokenness in Debian unstable recently:
Fatal server error: Unrecognized option: /etc/X11/xinit/xserverrc
--- /usr/bin/startx.orig 2008-05-26 18:21:26.000000000 +0200 +++ /usr/bin/startx 2008-05-26 18:21:36.000000000 +0200 @@ -107,9 +107,7 @@ if [ x"$server" = x ]; then # if no server arguments or display either, use rc file instead if [ x"$serverargs" = x -a x"$display" = x ]; then - server=$defaultserver serverargs=$defaultserverargs - display=$defaultdisplay else server=$defaultserver fi
Hope that saves some people out there lengthy investigations and hassle.
If you want to generate a custom Debian live CD, including only the tools you want (and maybe additional tools you don't find in other live CDs) there's a really simple solution: live-helper.
Creating a basic bootable Debian live CD ISO image in the current directory is as simple as:
$ lh_config $ lh_build
That's it. The result will be a file called binary.iso, which you can either burn on a CD-ROM via
$ wodim binary.iso
or test in QEMU using a command line like this:
$ qemu -boot d -cdrom binary.iso
Of course there are many possibilities to customize the generated image to your likings, see the documentation in the Debian wiki, or the lh_config/lh_build manpages.
Please note that live-helper can not only generate CD ISOs, but also bootable DVDs, images for USB thumb drives, or netboot images.
There's also a nice GUI called live-magic which will make the process a bit easier if you don't like doing things on the command line.
I got bored recently, so I rebuilt the whole Debian archive on one of my machines. To make this not a completely useless excercise, I used the Open64 compiler instead of gcc and created build logs for your perusal.
So what is Open64?
From the Wikipedia page:
Open64 is an open source, state-of-art, optimizing compiler for the Intel IA-64 (Itanium), AMD Opteron and Intel IA-32e architecture. It derives from the SGI compilers for the MIPS R10000 processor. It was released under the GPL in 2000, and now mostly serves as a research platform for compiler and computer architecture research groups. Open64 is licensed under the GPL. Open64 supports Fortran 77/95 and C/C++, as well as the shared memory programming model OpenMP. It can conduct high-quality interprocedural analysis, data flow analysis, data dependence analysis and array region analysis.
The installation is pretty easy fortunately:
$ wget http://ovh.dl.sourceforge.net/sourceforge/open64/open64-4.0-src.tar.bz2 $ tar xfvj open64-4.0-src.tar.bz2 $ cd open64-4.0 $ export TOOLROOT=/opt/open64 $ make $ make install (as root)
I think you need gcc-3.4 (gcc 4.x is not yet supported), and for some odd reason you also need csh as one of the install scripts seems to use it.
It would be nice if someone could package Open64 for Debian, I definately don't have the time to maintain such a huge package (a whole maintainer team would probably be good here).
Rebuilding the Debian archive
First we need to install the required packages, setup a cowbuilder base chroot, and get the list of packages:
$ apt-get install cowdancer grep-dctrl wget devscripts sudo $ cowbuilder --create --distribution lenny --basepath /var/cache/pbuilder/testing-base.cow $ cp -r /usr/share/doc/pbuilder/examples/rebuild . $ cd rebuild $ ./getlist lenny
Now we add Open64 into the cowbuilder chroot and fix up the chroot by pointing the gcc/g++ symlinks to Open64:
$ cp -a /opt/open64 /var/cache/pbuilder/testing-base.cow/opt $ chroot /var/cache/pbuilder/testing-base.cow $ cd /usr/bin $ mv gcc gcc.orig $ ln -s /opt/open64/bin/opencc gcc $ mv g++ g++.orig $ ln -s /opt/open64/bin/openCC g++ $ exit
In addition, we set the
CXX environment variables to Open64, which will make 90% of all (autoconf-using) packages automatically use Open64. We need a small script for that:
$ cat c.cfg: export CC="/opt/open64/bin/opencc -m32" export CXX="/opt/open64/bin/openCC -m32"
Now edit the
buildall script. Change the Debian mirror used there (optional) and make it use our
c.cfg script by adding the
--configfile /path/to/rebuild/c.cfg option in the "pdebuild" line.
We can now finally start building the archive:
./buildall list.lenny.i386 lenny
You can also run multiple
buildall instances at once to speed up the archive rebuild on SMP/multicore machines, and you can even abort the command and simply restart it later. The script will continue where it left off.
The whole rebuild (with 2 instances of
buildall running at the same time) took ca. 9 days on an AMD64 Athlon64 X2 (dual core, 1.8 GHz each) machine with 1 GB of RAM.
I really should have used something like apt-proxy to speed up the rebuild and save some bandwidth, but I read about apt-proxy too late...
All log files from my rebuild are available for detailed analysis if anybody is interested (you can browse the logfiles online or download all of them as tarball). I didn't perform any detailed analysis, just some rough numbers here:
If anybody does some more elaborate analysis, please let me know.
Note: This article is part of my Testing stuff with QEMU series.
From the Debian GNU/kFreeBSD port page:
Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.
Q: Why would anybody want to do that?
A: Why not? 
So, after we have talked about that, let's start:
apt-get install qemu
qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
ALT-F3. Do it.
At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.
qemu -hda qemu_kfreebsd_i386.img
apt-get update && apt-get dist-upgrade
apt-get install vim xorg icewm xterm
apt-get install kbdcontrol
Section "InputDevice" Option "Device" "/dev/psm0" Option "Protocol" "PS/2" [...] Section "Device" Driver "vesa"
Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages...
 More elaborate answer(s) and reasons are available in the Debian wiki.
This is really sad in my opinion, as we should rather support more architectures instead of less architectures. After all, Debian is "The Universal Operating System" .
Now, I know that my opinion doesn't matter much in this case, but many other people who own sparc32 boxes seem to feel the same, judging from the thread which was started by the announcement.
Also, I do realize that nobody wants to retire the port just for fun. To my understanding there is one major problem which needs to be sorted out in order to "save" the sparc32 support in Debian (and also in Linux!):
There is no Linux kernel maintainer for the sparc32 Linux code at the moment!
This seems to be the root of the whole problem. It makes maintaining a Debian port for sparc32 really hard, as you can surely imagine. Also, there seem to be too few people who actively work on the surrounding toolchain stuff (gcc, binutils, etc) which is also very important.
My suggestion would be to not drop the Debian support for now, but rather set the status to "needs help" or something and actively search for contributors and/or maintainers. Heck, list it on Unmaintained Free Software, or write a "call for help" Slashdot article, post the issue on all Linux-/Debian-/SPARC-related mailing lists etc. etc. (or write funny blog posts, heh).
I guess if two or three experienced SPARC developers would step up and take care of the kernel and toolchain maintenance for sparc32, there would be no reason to drop it anytime soon.