Re: bootfloppies with new libc
Please do not just email me -- the proper address to email these
issues is debian-boot@lists.debian.org.
>the mklibs.sh in the bootfloppies package is in need of an upgrade to
>libc-2.1.3:
>
>in line 523 '2.1.2' needs to be changed to 2.1.3, so it works with the
>up to date libc.
I think you must be using 2.2.7. This has been fixed in CVS I
believe, where that line reads:
if [ "x$1" = "xlibc-2.1.2.so" -o "x$1" = "xlibc-2.1.3.so" ] ; then
>What about the libs that do not come with '-pic.a'-files? only few have
>some.
They don't get reduced.
>When I run mklibs.sh now, it fails to make a minimal libc-2.1.3:
>
>/usr/bin/ld: /tmp/,mklibs.25128/lib-so: undefined versioned symbol name
>sys_siglist@@GLIBC_2.1
>/usr/bin/ld: failed to set dynamic section sizes: Bad value
>collect2: ld returned 1 exit status
>/home/andreas/lrp/devel/router/bin/mklibs.sh: install-small-lib: gcc or
>objcopy failed.
>I tried to track down this sys_siglist@@GLIBC_2.1 -symbol, but my lowlevel
>library-knowledge failed me.
Hmm... seems to work over here.
Try working out of CVS and see if you still have a problem.
Instructions enclosed.
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
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".) It is highly recommend, if
you are an emacsen user, that you use the excellent `pcl-cvs' mode
interface. If you are a `vi' user, please try one of the emacsen in
`vi' emulation mode, and see if you like it. You can have the best
of both worlds.
There are various ways to access the CVS repository for the `boot-
floppies', depending on your circumstances. However, once you've set
up your CVSROOT variable properly, all the access methods behave
pretty much identically.
There is a `cvsweb' interface, 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/cgi-bin/cvsweb>.
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:anonymous@cvs.debian.org:/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 (possibly unstable) version, do:
cvs co boot-floppies
For the slink CVS branch, which is probably what you are using if you
are working on translating slink documentation:
cvs co -r adam-boot-floppies_2-1_branch boot-floppies
From there, you can use `cvs update', `cvs commit', `cvs diff', and
`cvs status'. -- see the info pages. 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' along with appropriate
ChangeLog entries with a brief description of what the patch does to
<URL:mailto:debian-boot@lists.debian.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.
Reply to: