Re: call for volunteers -- woody boot-floppies
Looks like you have not gotten much response to this? I hacked long and
hard on the Caldera boot procedure while employed there. I've also build
custom installation procedures for other linux distros and
architectures. (including ia64) I'd like to get involved in the
installation soon, but I'm still on the NM queue and have limited
I work with Erik Andersen at Lineo now, he can speak a bit on my
What's the plan for woody? I've mostly done 2.88 boot images for CD
installs and then similar split 1.44 images for floppy. It would be a
Good Thing to continue to support the various install procedures that
are now in place and I assume this is one of the goals.
Are there any plans to add things like PXE boot installs etc?
Is there a plan in place (either for sid or woody) to switch over to
grub as default loader? stage1 + full stage2 eats about 80k on a floppy
image. I would recommend this if possible as it offers more rescue
options. What about smp kernels with nosmp by default? Then detection
can just change the boot options to enable SMP "out of the box" [hmm...
I suppose "on first reboot" would be more accurate?]
If you would like my help/input on this, please tell me what I can do as
a NM applicant (or suggestion on getting through the queue faster ;-).
I'm not now on the debian-boot list, so please copy me. (though I
suppose Erik will fill me in if you don't ;-)
The current install is very flexible. The intent to move more init stuff
into the .debs themselves is a Good Thing. Keep up the good work! I look
forward to helping out.
Adam Di Carlo wrote:
> I am in need of volunteers -- people who know makefile and have worked
> with boot-floppies before.
> You may have heard about the debian-installer effort -- it's true.
> Boot-floppies is end-of-life and will eventually be taken out and
> shot. Hooray. No one will be happier than I.
> OTOH, we do want to freeze woody prior to July, so we're going to need
> to hobble along with boot-floppies for one more release -- woody.
> Unfortunately, a lot of the "talent" have been sucked into
> debian-installer. I have pretty much no one helping me right now with
> boot-floppies maintenance.
> Fortunately, I don't have to worry about including a bunch of fat new
> features. Its more of a taking away operation, woody boot-floppies
> is, than an adding features operation. But there's tons of work to be
> - fold out mklib.sh (library reduction) into it's own package
> Marcus Brinkmann promised to do this
> - mklib.sh is actually totally broken right now, all arches, with
> - integrate AJ's dynamic base building package
> /usr/bin/ld: /tmp/,mklibs.2558/lib-so: undefined versioned symbol
> name fegetexceptflag@GLIBC_2.1
> - eliminate all "configure the base system" steps -- they should be
> handled, ideally, be debconf stuff run devolved into the right
> - eliminate hacked libraries -- we've removed hacked newt, slang,
> and libutf8, but we need to be sure that the packaged versions meet
> our needs -- or file RC bugs and hopefully patches against those
> bugs if not
> - i18n -- we were *heartbreakingly* close to this in woody, but the
> effort from the i18n team just seemed to fizzle out
> - eliminate the top-level Makefile ickyness -- I'm working on this
> now, I've broken up that makefile and I'm replacing all those hacked
> out rules with wildcard rules and such -- requires a bit of makefile
> wizardy but the 8-fold reduction in makefile size is worth it
> - hppa, ia64, and other porting
> - pci auto-detection, work with in with modconf ?
> Please help me out. Otherwise, god knows when we'll be able to
> release woody!
> I forgot in my last message to include the info on getting the
> stuff from CVS. That's included below.
> Followups to firstname.lastname@example.org, please. I don't read
> .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
> CVS and boot-floppies Sources
> You can access the boot-floppies using CVS; this is particularly
> useful if you are actively working on the package.
> CVS comes with excellent documentation; in particular, see the `cvs'
> info pages, and "Open Source Development with CVS", a GPL book freely
> available online, at <URL:http://cvsbook.red-bean.com/>. (There is a
> Debian package of it, called "cvsbook".)
> There are various ways to access the CVS repository for boot-floppies,
> depending on your circumstances. However, once you've set up your
> CVSROOT variable properly, all the access methods behave almost much
> There is a web interface for CVS, which is great for browsing the commit
> logs, pulling diffs from the repository, and getting a good look at
> the layout of the module. It can be accessed via:
> * Getting the boot-floppies source via CVS
> This version of the sources is for Debian 2.2, aka Potato.
> The following are POSIX bourne shell commands you can run to get the
> CVS area; other shell users should be able to translate to their shell
> language easily. Commands with a `#' are comments; you don't have to
> type those.
> # If you are logged into to cvs.debian.org (CNAME va.debian.org):
> export CVSROOT=/cvs/debian-boot
> # If you are using `ssh' to access the area, and you have an
> # account on cvs.debian.org -- this is the recommended method:
> export CVS_RSH=ssh
> export CVSROOT=:ext:<MY-USERNAME>@cvs.debian.org:/cvs/debian-boot
> # If you are using anonymous (readonly) access:
> export CVSROOT=:pserver:email@example.com:/cvs/debian-boot
> cvs login
> # You will be prompted for a password -- just hit `Enter'.
> # If you are using a pserver account (i.e., you need write access
> # but do not have a login account, and you have been given a
> # pserver username and password):
> export CVSROOT=:pserver:<USERNAME>@cvs.debian.org:/cvs/debian-boot
> cvs login
> # Enter the password you have been given.
> After that, all techniques are the same. Simply check out the
> sources. For the lastest Potato version, do:
> cvs co boot-floppies
> * Working on Woody
> If you are working on the woody boot-floppies, you presently need to
> use the 'woody' branch:
> cvs co -r woody boot-floppies
> If you want to change an existing checked out area to woody, in the
> checked out source directory, do
> cvs up -r woody
> >From there, you can use `cvs update -d -P' (the '-d -P'is to get new
> directories, and prune empty directories), `cvs commit', `cvs diff',
> and `cvs status' -- see the info pages.
> * Committing Changes
> If you do not have write access to the repository, and have made
> modifications that you would like us to incorporate, please mail the
> `cvs diff -u' output along with a brief description of what the patch
> does to <firstname.lastname@example.org>. It is helpful if you put
> "[patch]" in the subject line.
> Please try to make meaningful commit log entries that describe
> something fairly specific about what changes you have made. It is
> best to commit one file at a time, or group them logically, so that
> modifications to several files that pertain to fixing one particular
> bug or add a certain feature contain a log message that is relevant
> for that file, without cruft about unrelated changes to unrelated
> files. A massive commit of 15 files with a common log entry that
> says "blah changes that fix bugs, C-u M-! fortune" are not very
> useful later on when you are trying to find out when a certain change
> happened. The log entry should describe what's been changed, so that
> later on maintainers do not have to parse every single diff to find
> one simple modification. You should be able to scan the log and
> narrow down the search based on what's written there. There is a
> good discussion of this in the GNU `Standards' info document, under
> "Documenting Programs", "Change Logs". `Standards' is considered
> required reading.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.