I-Gene Leong <[EMAIL PROTECTED]> writes: > Yes, that's correct. I got ahold of the source to boot-floppies (didn't > know the package name initially) so I'll see if I can spot anything. Great. You will want to look in utilities/libfdisk I bet. If feel motivated to work from CVS, that sometimes has minor differences. Note that the 'tater version is on the 'potato' branch, and woody is on the trunk. See the attached file for CVS access info, you don't need to be a Debian maintainer to have it. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onshored.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 identically. 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: <URL:http://cvs.debian.org/>. * 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 PROTECTED]:/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 -r potato boot-floppies Note that Potato is on a branch now for maintenance only. If you want to change an existing checked out area to woody, in the checked out source directory, do cvs up -r potato * Working on Woody If you are working on the woody boot-floppies, use the trunk: cvs co boot-floppies If you want to change an existing checked out which was on the woody branch to the latest version, in the checked out source directory, do cvs up -A -d -P >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 <[EMAIL PROTECTED]>. 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.
