Re: Problem: bash 2.01 dumps core!

[James Troup]

"Christian Hudon" <[EMAIL PROTECTED]> writes:

> I hit a  small problem while installing packages from
> Incoming... Bash now dumps core on startup. And one of the
> interesting side effects of this is that I can't install/remove
> packages anymore:

I suspect the problem was when you installed the new libreadline2,
somehow either ldconfig wasn't run or for some reason your bash
wouldn't work with the new libreadline even after ldconfig was run.

The critical section, as far as I can tell, is when installing the new
libc5 based libreadline from /lib into /lib/libc5-compat and keeping a
working /bin/sh (bash, understandably, doesn't like it when you move
it's libreadline to a different directory and don't tell the dynamic
linker).  The libreadline2_2.1-2.1 postinst is a C wrapper which runs
ldconfig since a shell script obviously wouldn't work.  Perhaps the
wrapper failed for some reason?  (Right now, I *really* wish dpkg kept
logs)

I've moved the new bash package out of Incoming/ and into ~troup/ on
master until I can get this sorted out.

I really don't understand what went wrong, I upgraded a machine from
unstable to bash-2.01 without problems, as did "netgod".  And from the
fact that two developers uploaded libreadlineg2 dependent packages, I
assume that it didn't hose their machine either.  I'm truly sorry it
did for you :-(

I'll have a look at the info you've written here, and ask anything
else I need in private mail.

-- 
James :(


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Hamm: Retracting request for chos to be standard

[Christoph Lameter]

Lilo 2.0 has the ability to display a file before the prompt and also the
ability to boot something with a single keystroke. If someone could update
the lilo package and provide a decent configuration then lilo could also
offer a nice menu on boot up so that newbies are no longer irritated.

Maybe lilo could also replace syslinux for the bootdisks??

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re^2: Debian's mail daemons

[Marco Budde]

Am 20.06.97 schrieb kai # khms.westfalen.de ...

Moin Kai!

KH> I completely fail to understand why a professional system administrator
KH> would _want_ to use a MTA that's _that_ notorious for security holes. My
KH> idea of professionalism seriously clashes with this.

Who tells you that the other MTAs don't have such holes? Because the
other MTAs are not often used such holes are not discovered.

KH> > And you should remember that the most Linux distributions use sendmail
KH> > as MTA. In my opinion Debian should use sendmail as standard MTA.
KH> People, eat shit. Millions of flies can't be wrong.

sendmail != MS ;-).

KH> Sendmail: Just say NO.

I say yes.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re^4: Status of Debian Policy

[Marco Budde]

Am 21.06.97 schrieb edd # rosebud.sps.queensu.ca ...

Moin Dirk!

DE> But they get html via the dwww package! Which gives them _more_
DE> documentation then there is in html only.

But this requires a www server! Not a good idea for slow systems like my  
notebook. And the result doesn't look great.

DE> Seconded. Nobody answered my mail from yesterday which showed that the
DE> doc-linux package will take up over 5 MB (instead of 1.6 MB) for the html
DE> stuff.

You could compress the HTML pages. But this is maybe a problem for some  
browsers.

DE> No way. IMHO, we should add a Policy Guideline stating that html should be
DE> in a seperate package [1] and that info should be shipped as usual. I for

No. Then we should info and html in seperate packages. And the policy says  
that HTML should be the Debian documentation format.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

xterm terminfo entry

[Erv Walter]

I have a question about the terminfo entry for 'xterm'  I am wondering
how I need to adjust it so that it says color is supported.  xterm now
supports color (demonstrated by ls --color and tin in color), but the
terminfo entry still says black and white so programs like lynx and
slrn are blackand white.

Maybe this should be fixed next time terminfo files are released.  In
the mean time, what entries do i need to change?

Thanks,
Erv

-- 
Graduate Student[EMAIL PROTECTED]
Department of Chemistry   [EMAIL PROTECTED]
Univ of Wisconsin-Madison   [EMAIL PROTECTED]
   



pgp0kRqPrjUQ2.pgp
Description: PGP signature

Re: Problem: bash 2.01 dumps core!

[Christian Hudon]

It's me again...

I fixed the problem by symlinking sh to zsh and doing a "dpkg --configure -a".
ldconfig got run a couple of times, and I suspect this is what fixed the
problem because the output of ldd /bin/bash looks much saner now:

[EMAIL PROTECTED]:[~/deb] >ldd /bin/bash
libreadline.so.2 => /lib/libc5-compat/libreadline.so.2 (0x4000b000)
libncurses.so.3.0 => /lib/libncurses.so.3.0 (0x4002c000)
libdl.so.1 => /lib/libdl.so.1 (0x40068000)
libc.so.5 => /lib/libc.so.5 (0x4006b000)

I'm still with bash 2.0, but I suspect that installing bash 2.01 won't
cause problems now.

If you want to know what changed on my system, just diff the following dpkg
--audit with the previous one:

[EMAIL PROTECTED]:[~chrish/deb] #dpkg --audit
The following packages are in a mess due to serious problems during
installation.  They must be reinstalled for them (and any packages
that depend on them) to function properly:
 metamail An implementation of MIME.
 mountTools for mounting and manipulating filesystems.

The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
 libgdbm1 GNU dbm database routines (runtime version). [libc5 compa
 libc5The Linux C library version 5 (run-time libraries).
 bash-builtinsBash loadable builtins - headers & examples
 libreadline2 GNU readline and history libraries, run-time libraries. [
 chimera2 Web browser for X

The following packages are only half configured, probably due to problems
configuring them the first time.  The configuration should be retried using
dpkg --configure  or the configure menu option in dselect:
 inform   A compiler for adventure games.

Now the question is, what should be done so that this doesn't happen to
other people?

  Christian


pgpe3EgSNfCx7.pgp
Description: PGP signature

Problem: bash 2.01 dumps core!

[Christian Hudon]

I hit a  small problem while installing packages from
Incoming... Bash now dumps core on startup. And one of the interesting side
effects of this is that I can't install/remove packages anymore:

[EMAIL PROTECTED]:[~chrish/deb] #dpkg -i libc5_5.4.33-5_i386.deb
(Reading database ... 53797 files and directories currently installed.)
Preparing to replace libc5 5.4.33-5 (using libc5_5.4.33-5_i386.deb) ...
dpkg: error processing libc5_5.4.33-5_i386.deb (--install):
 subprocess pre-installation script killed by signal (Segmentation fault), core 
dumped
Errors were encountered while processing:
 libc5_5.4.33-5_i386.deb
Exit 1

... since many packages have installation scripts that are bash
scripts. Needless to say, this is *bad*.

I'll give as much detail as I can... Hopefully someone else can figure out
what the problem is and fix the relevant packages. I'll post a followup
message once I've fixed the problem on my machine

I did:

dpkg -iEG bash_2.01-0_i386.deb bash-builtins_2.01-0_i386.deb
chimera2_2.0a2-2_i386.deb ching_1.0-1_i386.deb cpp_2.7.2.2-4.deb
ddd_2.1.1-1_i386.deb gdb_4.16-8_i386.deb inform_6.13-2_i386.deb
inform-docs_6.13-2_all.deb lftp_0.11.1-2_i386.deb libc5_5.4.33-5_i386.deb
libgdbm1_1.7.3-22_i386.deb libgdbmg1_1.7.3-22_i386.deb
libgdbmg1-dev_1.7.3-22_i386.deb libreadline2_2.1-2.1_i386.deb
libreadlineg2_2.1-2.1_i386.deb libreadlineg2-dev_2.1-2.1_i386.deb
metamail_2.7-22_i386.deb mount_2.6g-2_i386.deb ncurses3.0_1.9.9e-2_i386.deb
ncurses3.4_1.9.9g-1_i386.deb ncurses3.4_1.9.9g-2_i386.deb
ncurses3.4-dev_1.9.9g-1_i386.deb ncurses3.4-dev_1.9.9g-2_i386.deb
ncurses-base_1.9.9g-2_all.deb ncurses-bin_1.9.9g-2_i386.deb
procps_1.12.1_i386.deb slang0.99.34_0.99.38-2.1.deb
slang0.99.34_0.99.38-2.4_i386.deb slang0.99.34-dev_0.99.38-2.1.deb
svgatextmode_1.5-1_i386.deb

The bash install failed because I didn't have libreadlineg2 installed. Then
at some point in the middle (can't more precise, I can't scroll back far
enough) all the prerm's started dumping core when invoked.

Here's the current state of my system:

[EMAIL PROTECTED]:[~chrish/deb] #dpkg --audit
The following packages are in a mess due to serious problems during
installation.  They must be reinstalled for them (and any packages
that depend on them) to function properly:
 metamail An implementation of MIME.
 mountTools for mounting and manipulating filesystems.

The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
 ncurses3.4-dev   Video terminal manipulation - Developer's libraries and d
 slang0.99.34-dev A C programming library for user interfaces - development
 libgdbm1 GNU dbm database routines (runtime version). [libc5 compa
 libc5The Linux C library version 5 (run-time libraries).
 libgdbmg1-devGNU dbm database routines (development files) [libc6 vers
 gdb  The GNU Debugger
 lftp Sophisticated command-line FTP client programs
 bash-builtinsBash loadable builtins - headers & examples
 libreadlineg2GNU readline and history libraries, run-time libraries. [
 libreadline2 GNU readline and history libraries, run-time libraries. [
 chimera2 Web browser for X

The following packages are only half configured, probably due to problems
configuring them the first time.  The configuration should be retried using
dpkg --configure  or the configure menu option in dselect:
 inform   A compiler for adventure games.
 ncurses3.0   Old libc5 curses - shared libraries
 ncurses3.4   Video terminal manipulation - shared libraries
 inform-docs  Supplementary documentation for inform
 slang0.99.34 A C programming library for user interfaces - shared libr
 chingI Ching hexagram/fortune generator
 libgdbmg1GNU dbm database routines (runtime version). [libc6 versi

Here's some version information (my machine is tracking unstable fairly
closely):

[EMAIL PROTECTED]:[~/deb] >dpkg -l bash libc5 libc6 ldso libreadline2 
libreadlineg2 ncurses3.0 ncurses3.4 libgdbm1 libgdbmg1
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  bash2.0-3  The GNU Bourne Again SHell
iU  libc5   5.4.33-5   The Linux C library version 5 (run-time libr
ii  libc6   2.0.4-1The GNU C library version 2 (run-time files)
ii  ldso1.9.2-2The Linux dynamic linker, library and utilit
iU  libreadline22.1-2.1GNU readline and history libraries, run-time
iU  libreadlineg2   2.1-2.1GNU readline and history libraries, run-time
iF  ncurses3

Re: Debian-Policy Manual

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 21 Jun 1997, Christian Hudon wrote:
> On Jun 17, Scott Ellis wrote
> > I believe that the plan is to have them managed by update-alternatives,
> > and therefore be symlinks.  Less will probably have a higher priority than
> > more, although I don't know who gets to win the war over which editor is
> > best, although I suspect a vi varient on the grounds that that is what
 ^^^
> > happens on most unices.
> 
>  Here we go again.
> 
> Newbies should *not* be dumped into vi by default. It's just too
> user-hostile.

I'm not advocating any particular editor here.  I personally use joe for
brief editing jobs and emacs for the big stuff, but I can understand the
expectations of someone familiar with unix typing vipw or such.

++
|   Scott K. Ellis   |   Argue for your limitations and  |
|   [EMAIL PROTECTED]   | sure enough, they're yours.   |
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6wy2KCk2fENdzpVAQEZhgP/e2wVV5B+XL7N+nmI5k6GcFdDr1BApUnR
3JOtnd7uN+A5HLG1ucX/yPFmhAOU+HqlCvU1wMrngCVN33WXrqPEKfjRqwMuvEg9
dt9IlAuMIgSUkEC4PAqiFdq/rdxkrJJ62gyM7lYuJ/yrCgwJEYJIj1JY5Ti5cfNc
hQ1KrIE1QXs=
=gfyf
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Christian Schwarz]

On Sat, 21 Jun 1997, Martin Schulze wrote:

[snip]
> I don't like the idea of splitting packages that much.  It increses
> the confusion for users.   For new users it is incredible difficult
> to install Debian because of >1000 packages.

I can understand your argument very good. However:

  1. I don't think that we can get a consensus other than that we have
 now. :-)

  2. The new "deity" (dselect successor) will simplify the handling of 
 >1000 packages very much. I had another idea: Perhaps we could deity 
 adopt to have an overall switch about which documentation the
 user prefers. Then, it can hide all "xxx-doc-*" packages and select
 the necessary ones automatically if package "xxx" is selected.
 (Of course, there should be a way to switch this auto selection off,
 :-)

> And for my feeling the documentation belongs to the package itself.
> I don't want to install another package just because I need some
> documention.

Some users from not installing the documentation. For example, I run
Debian on lots of computers here and at work. I don't want to have the
bash manual installed on my firewall :-)


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Christian Schwarz]

On Sat, 21 Jun 1997, Scott K. Ellis wrote:

> 
> 
> -BEGIN PGP DECRYPTED MESSAGE-
> On Sat, 21 Jun 1997, Santiago Vila Doncel wrote:
> 
> > On Sat, 21 Jun 1997, Christian Schwarz wrote:
> >
> > >  The documentation will be distributed via several packages:
> > >
> > >foo-doc-html  for HTML docs
> > >foo-doc-info  for GNU info docs (where available)
> > >foo-doc-xxx   for other formats (only where appropriate)
> >
> > This is a very good compromise and I like it.
> >
> > BTW: Should foo Suggest/Recommends foo-doc-html and/or foo-doc-html?
> 
> At most, there should be a suggest for foo-doc-html|foo-doc-info.
> Recommends is too strong, it is annoying to beat dselect into submission
> when you really don't want a package.

I think the package should use "Suggests: foo-doc" and all doc packages
should use "Provides: foo-doc".


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: "bazaar" model for Debian software development

[David Welton]

On Sat, 21 Jun 1997, Martin Schulze wrote:

| James R. Van Zandt writes:
| 
| > John W. Eaton <[EMAIL PROTECTED]> (the maintainer of Octave) has
| > pointed out a very interesting document by Eric S. Raymond:
| > 
| > http://www.ccil.org/~esr/writings/cathedral.html

A very nice bit of writing indeed, thankyou for pointing this out.  I find
it relevant to Linux, Debian, and also on a much smaller scale, the Linux
Incompatibility List that I maintain.

Once again, recommended reading for sure:-)

Ciao,

David Welton   
[EMAIL PROTECTED]  [EMAIL PROTECTED]  http://www.efn.org/~davidw
Se quest'email e` in Italiano, mi dispiace per gli errori:-) FORZA PANTANI!
 --Debian GNU/Linux--



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: leap second

[branden]

On Sat, 21 Jun 1997, Mark Baker wrote:

> As it is, we use POSIX time, which means that the system time follows GMT.
> When there is a leap second the time itself is changed; the timezone
> information does not need to.
> 
> > This is completely unacceptable. OS time must be predictable.
> 
> Which is why real time would be much better than POSIX time.
> 
> Unfortunately we have to use POSIX time, so we're compatible with other
> computers on the network :(

Can someone explain to me exactly what POSIX time is?  I was under the
impression that many computers on the net (at least ones belonging to big
sites) grabbed their time from a radio signal broadcast by the U.S. Naval
Observatory or some similar organization, and propagated the correct time
from there.  xntp is supposed to figure in network latency from a host with
an authoritative notion of the time, right?

I do know that they do that very thing here at Purdue.

-- 
G. Branden Robinson
Purdue University
[EMAIL PROTECTED]
http://www.ecn.purdue.edu/~branden/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Christian Hudon]

On Jun 17, Scott Ellis wrote
> 
> I believe that the plan is to have them managed by update-alternatives,
> and therefore be symlinks.  Less will probably have a higher priority than
> more, although I don't know who gets to win the war over which editor is
> best, although I suspect a vi varient on the grounds that that is what
> happens on most unices.

 Here we go again.

Newbies should *not* be dumped into vi by default. It's just too
user-hostile.

  Christian




pgpfORqklxpkK.pgp
Description: PGP signature

Re: "bazaar" model for Debian software development

[Martin Schulze]

James R. Van Zandt writes:

> John W. Eaton <[EMAIL PROTECTED]> (the maintainer of Octave) has
> pointed out a very interesting document by Eric S. Raymond:
> 
> http://www.ccil.org/~esr/writings/cathedral.html

Just FYI This was subject of his talk on Linux-Kongress in Wuerzburg
last month.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

"bazaar" model for Debian software development

[James R. Van Zandt]

John W. Eaton <[EMAIL PROTECTED]> (the maintainer of Octave) has
pointed out a very interesting document by Eric S. Raymond:

http://www.ccil.org/~esr/writings/cathedral.html

It discusses two models for software development.  One is the standard
method of "test thoroughly, and release infrequently", which he likens
to a cathedral.  The other is "release often and cultivate a beta test
community" approach use for the Linux kernel, which he likens to a
bazaar.  He make a pursuasive argument that the latter is much more
effective.  For example, he observes that "debugging is
parallelizable".

Debian Linux has several "bazaar" characteristics, particularly its
open bug reporting system.  I recommend that all Debian developers
read the above document for ideas.

 - Jim Van Zandt


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: invalid CD

[Goswin Brederlow]

Bruce Perens wrote:
> 
> If it thinks your CD is an audio disk, it would be an error in the "xaa" file.
> The very first blocks on the CD tell what kind of CD it is.
> 
> Bruce
> --
> Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
> Finger [EMAIL PROTECTED] for PGP public key.
> PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3
> 

The filesystem allways reports an audio disk when it can't understand
the iso image. The error could be in xaa or in xbu, since both hold
vital information for the CD. 

Is the cksum wrong for any of those files?

May the Source be with you.
Mrvn.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Goswin Brederlow]

Kai Henningsen wrote:
> 
> [EMAIL PROTECTED] (Goswin Brederlow)  wrote on 21.06.97 in <[EMAIL 
> PROTECTED]>:
> 
> > OK, it's unmounted then, but it should remount the drive if its
> > untouched
> > or ask if it should remount it. I'm not repartitioning the drive, but I
> > had
> > to change the types of the partitions, cause I can't do it easily from
> > AmigaOS (I dunno the hex for LNX\0). The partition holding root is
> > unchanged
> > so remounting it would be harmless.
> 
> Of course, it can't know that.
> 
> In general, the kernel cannot reread the partition table when it has
> mounted something from that drive, even read-only, so the only proper
> choice after changing the partition table is to reboot.
> 
> You can re-mount the partition (mount -o remount,rw /), but the kernel
> will not know about any changes you made, which can be very dangerous.

You can't remount because the install script goes into an endless loop
evaluating you're system, failing and poping up with the
colour/monochrom menu. You can't even reboot. The only option is a
keyboard reset, which thankfully makes a shutdown -r when
Ctrl-Amiga-Amiga is pressed. (It just resets on CTRL-Alt-Del. Why?)

> 
> The boot disks should probably force a reboot at that point.

That's probably the best option.

> 
> The low memory boot disk probably does the same thing on the x86.
> 
> MfG Kai
> 

May the Source be with you.
Mrvn


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Goswin Brederlow]

Bruce Perens wrote:
> 
> From: Goswin Brederlow <[EMAIL PROTECTED]>
> > OK, it's unmounted then, but it should remount the drive if its
> > untouched or ask if it should remount it. I'm not repartitioning
> > the drive, but I had to change the types of the partitions
> 
> I think it should not unmount the root, but it should complain
> before you partition a disk that the root is running on. I don't
> know how many people will hit this.
> 
> Thanks
> 
> Bruce
> --
> Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
> Finger [EMAIL PROTECTED] for PGP public key.
> PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3

It's the only choise if you have a low mem system. 
As Kai Henning pointed out:

>> The boot disks should probably force a reboot at that point.
>> The low memory boot disk probably does the same thing on the x86.

The script complains that you have mounted filesystems on that drive
when you try to partition it, which is perfectly valid.
The script should eigther reboot after the disk holding root is
partitioned or try to remount root r/w. Rebooting is a bit anoying when
you only changed the type of another partition from DOS\0 to LNX\0,
whereas remounting might get stuck if the partition holding root has
changed name or place. So rebooting is probably the savest.

May the source be with you.
Mrvn


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 21 Jun 1997, Santiago Vila Doncel wrote:

> On Sat, 21 Jun 1997, Christian Schwarz wrote:
> 
> >  The documentation will be distributed via several packages:
> >
> >foo-doc-html  for HTML docs
> >foo-doc-info  for GNU info docs (where available)
> >foo-doc-xxx   for other formats (only where appropriate)
> 
> This is a very good compromise and I like it.
> 
> BTW: Should foo Suggest/Recommends foo-doc-html and/or foo-doc-html?

At most, there should be a suggest for foo-doc-html|foo-doc-info.
Recommends is too strong, it is annoying to beat dselect into submission
when you really don't want a package.

++
||  Your friends will know you better in the |
|   Scott K. Ellis   |   first minute you meet than your acquaintances   |
|   [EMAIL PROTECTED]   | will know you in a thousand years.|
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6wBHKCk2fENdzpVAQGBawQAr65LBV3lCpIZR+xBsFjVXheqo3oLuBRq
J3e7w3PQHpAcqUhJpQlmHBt5WgHxLDa2qFl4pVUjuM7Qej0KR1nUkkibJLfgoUi9
oenyMg0a8TobZqFNHR4m6uFh0k1h3lVYTSJhwzSbjIyyZKU9AzgbwdL5vr0azH8w
y2hNB3Na6Zs=
=e54s
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Martin Schulze]

Christian Schwarz writes:
> Hi folks!

re

> So I suggest the following policy. Note, that this is just a summary, not
> the actual text.
> 
> 
>  The unification of Debian documentation is being carried out via
>  HTML. However, we'll still provide GNU info documentation, where 
>  available.
> 
>  Thus, every package that contains documentation in a convertable
>  format has to provide HTML documentation. 
> 
>  The documentation will be distributed via several packages:
> 
>foo-doc-html  for HTML docs
>foo-doc-info  for GNU info docs (where available)
>foo-doc-xxx   for other formats (only where appropriate)
> 
>  (An example for the last case would be "DVI" documentation for TeX
>  related packages.)
> 
>  If the documentation files in all available formats do not require
>  more than 100k of disk space _together_, they may be included in the
>  "main" package. Otherwise, the will have to be distributed in
>  seperate packages, one for each format.
> 
> Any comments?

I don't like the idea of splitting packages that much.  It increses
the confusion for users.   For new users it is incredible difficult
to install Debian because of >1000 packages.

And for my feeling the documentation belongs to the package itself.
I don't want to install another package just because I need some
documention.

OTOH I do understand your way.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Santiago Vila Doncel]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 21 Jun 1997, Christian Schwarz wrote:

>  The documentation will be distributed via several packages:
> 
>foo-doc-html  for HTML docs
>foo-doc-info  for GNU info docs (where available)
>foo-doc-xxx   for other formats (only where appropriate)

This is a very good compromise and I like it.

BTW: Should foo Suggest/Recommends foo-doc-html and/or foo-doc-html?

Brian, will you submit maint-only bugs against all packages having a
Texinfo source .tex file and not having yet HTML documentation available?
(I think there are a lot of them, mostly GNU ones).

-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: latin1

iQCVAgUBM6v8ziqK7IlOjMLFAQFhaAQAsiQazsmFbbDZHWExcWEjWpPaYzw+fMnt
5ODipTZFkEdOaRpFyuT2gG/pPdkWeTCozIwdbJWYwJHfqBEc+yCq2Tr4mqbRzucM
am5hDO45XDA5KeQaGHt8i8q0c2WBN3DS5amKn3jpnX0NRtGEwBuAQy6EkBBuisTw
h1/hg1oKPqg=
=AQNU
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Documentation Policy

[Dirk Eddelbuettel]

That is a very reasonable proposal. I like it!

-- 
 [EMAIL PROTECTED]  [EMAIL PROTECTED]  http://rosebud.sps.queensu.ca/~edd
PGP key fingerprint = B2 49 75 BF 44 2C B7 AA  50 CB 19 7D 80 F7 CB DC


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Documentation Policy

[Christian Schwarz]

Hi folks!

The "html vs. info" discussion reminds me of "vi vs. emacs" discussions
:-)

It's pretty clear to me that we'll have to support "info" in the future,
since we would have to drop the "GNU" from "Debian GNU/Linux" otherwise.

However, HTML is getting more and more popular these days and I think it
would be very unwise not to choose HTML as "preferred document format".

To summarize this: We'll provide HTML documentation where possible. In
addition, all texinfo manuals will be distributed in the info format, too. 

This can easily be accomplished by creating new packages carrying the info
and html docs, respectively.

For example, the current emacs package installs about 1mb of info docs in
/usr/info/emacs-info. I suggest to split this off into a new package
called "emacs-doc-info". In addition, we should create an "emacs-doc-html"
package. This way, the user (actually, the sysadmin) can choose whether
he/she wants to have a)  no document, b) info docs, c) html docs, or d)
both. 

I know, this means a little more work for the maintainers, but it's
definitely worth it!

So I suggest the following policy. Note, that this is just a summary, not
the actual text.


 The unification of Debian documentation is being carried out via
 HTML. However, we'll still provide GNU info documentation, where 
 available.

 Thus, every package that contains documentation in a convertable
 format has to provide HTML documentation. 

 The documentation will be distributed via several packages:

   foo-doc-html  for HTML docs
   foo-doc-info  for GNU info docs (where available)
   foo-doc-xxx   for other formats (only where appropriate)

 (An example for the last case would be "DVI" documentation for TeX
 related packages.)

 If the documentation files in all available formats do not require
 more than 100k of disk space _together_, they may be included in the
 "main" package. Otherwise, the will have to be distributed in
 seperate packages, one for each format.


Any comments?


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

I found the Xemacs problem!

[Tom Lees]

I installed the new 3.1 binary (not support) package. It still coredumped
on me - XFree 3.2-1. Then I upgraded libc5 - 5.4.17-1 to 5.4.23-1. It now
works perfectly. I looks like its pretty dependent on a specific version
on libc.

Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>  http://www.lpsg.demon.co.uk/
PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Info or HTML: which should be the default, which in a separate package?

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 21 Jun 1997, Lars Wirzenius wrote:
> There's no reason why HTML should be much bigger than Info. I assume
> you used uncompressed HTML. There's no inherent reason why HTML can't
> be compressed; the only reason it isn't is that links break, but that
> is fixable. dwww already fixes it by giving you foo.html.gz if it exists,
> and foo.html doesn't exist. (That conversion doesn't help if you don't
> browse via dwww, but that's a minor blemish. We need a tool to fix the
> HTML files, but dwww's fix makes it less urgent.)

Except for those of us who don't want DWWW, don't want a web server, but
do want to browse HTML under lynx.  Then the links break if you compress
it.  But as I've stated earlier, I'd much rather have the info.

> > Make it an option to add html docs, but don't make it compulsory.
> 
> HTML docs must be compulsory, because info2www is not an acceptable
> alternative.

Yes, but info is.  I have no desire to clutter my drives with useless html
versions of stuff info works for.

> >   Scott>  Okay, show me how to search a HTML version of the bash info
> >   Scott> documentation for a concept and I'll believe you.
> 
> Searching in HTML requires a separate program, which we don't yet
> have. That's one place where Info is better. For now. (When we get
> a search engine for dwww, it will be able to search through all
> documentation, not just a single document. But it will be quite some
> time until we get it, I think.)

Exactly, the tool doesn't exist.  Therefore HTML is less functional than
info.  I will be unhappy if you take my info away from me without
providing the functionality elsewhere.  And I'm not convinced an HTML
search engine is the solution, that requires cluttering my drive up with
cache files for the engine.

++
||  Your friends will know you better in the |
|   Scott K. Ellis   |   first minute you meet than your acquaintances   |
|   [EMAIL PROTECTED]   | will know you in a thousand years.|
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6vo9qCk2fENdzpVAQFIMwP/e0QZ2XR3LjQJ6X7UGJaeiNbaqxLNHjR2
raz5yrVzt1RfuSlD/okSG9xO4NX17PNRG+u1NQFzAdiwoDItdmUmaYYxwHSKxt9L
IQmXyVn7p3nbxe8KcOyFrARserylrOLvN0agAKibFPkurNVj0tHRChqovbv2QQfO
ArFCG1BI5A4=
=kVDk
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Summary: File locking discussion

[Christian Schwarz]

Hi folks!

I'm glad that so many people are finally involved in our "file locking
discussion". However, we had lots of discussions about this topic in the
past and we have no results, yet. 

That's why I want to try to bring more "structure" into the discussion.
(Please complain if you don't agree :-) And someone else mentioned that we
should write a little assey about the possible decision we'll draw soon,
so that newcomers are informed why we have chosen a specific locking
mechanism.

Thus, I started to write such a document. It's attached below. Please
note, that this is release 0.1 of the document so feel free to tell me
_any_ comments/critics/suggestions.

I'll try to update this document often and introduce all new arguments
that will show up here. Perhaps we can come to a result this time, and
have the documentation ready when we have a decision.

(Please do not quote the whole document if you are referring to a single
section to reduce the traffic on this list.)

--

File Locking in the Debian system
=

Table of Contents
-

0. References
1. Current situation
2. Locking mechanisms
3. Debian specific ideas
4. Open issues
5. Frequently Asked Questions


Chapter 0: References
-

- The open(2) describes "dot-locking" and a NFS safe locking
mechanism.
- http://www.swb.de/personal/okir/lockd.html explains rpc.lockd
- several discussions on debian-devel (starting from Mar 97)
- Lars' "publib" library (see publib Debian package)
- Karl's "LockFile.pm"--a Perl implementation of publib's lockfile
  (see http://inetarena.com/~karlheg/Public)


Chapter 1: Current situation


1.1 Debian Policy Manual

The current Debian Poliy Manual (2.1.3.3) only mentions file locking
for MUAs (mail-user-agents) and MTAs (mail-transport-agents). In
section 4.3 "Mail processing on Debian systems" it says:

  Mailboxes are locked using the username.lock lockfile
  convention, rather than fcntl, flock or lockf.

Note, that this is obviously not enough information for the
maintainers to adopt their packages. This results in incompatible
locking mechanism. Thus, sometimes problem occur on Debian systems
with mail locking when using NFS.


1.2 Where do we need locking?

We need file locking in several places. For example, the incoming mail
boxes in /var/spool/mail/*, mail folders that are accessed by
"procmail" and "pine", etc.


Chapter 2: Locking mechanisms
-

2.1 fcntl, flock, lockf
---

The Linux kernel provides some system calls to do file
locking. However, neither of these functions is working over NFS.


2.2 dot-locking
---

To perform dot-locking, create the file .lock using
open(name, O_CREAT|O_EXCL, 0644). Create with O_EXCL will fail if the
file exists. If you can't create it, sleep for a while and try again.
To unlock, unlink() the file.

This technique is not NFS safe, since the NFS "open" function is not
atomic. The man page open(2) reads:

   O_EXCL When used with O_CREAT, if the file already  exists
  it  is  an error and the open will fail.  O_EXCL is
  broken on NFS file systems, programs which rely  on
  it for performing locking tasks will contain a race
  condition. 


2.3 rcp.lockd
-

Please refer to http://www.swb.de/personal/okir/lockd.html for a
more detailed description. 

The idea is simple: Each "server host" runs a rcp.lockd daemon. When a
process wants to lock a file, it contacts that daemon and asks for
locking the file. 

This technique is obviously NFS safe. However, there is no Linux
implementation of rpc.lockd, yet.


2.4 SUN's lockd
---

(Is this the same as "rpc.lockd"?)

Rumors say, that "lockd" can cause dead-locks when unlocking a file.
And there is no Linux port of this daemon, yet.


2.5 NFS safe locking through "link"
---

The man page open(2) reads:

   The solution for performing atomic file
   locking using a lockfile is to create a unique file
   on the same fs (e.g.,  incorporating  hostname  and
   pid),  use  link(2)  to make a link to the lockfile
   and use stat(2) on the unique file to check if  its
   link  count  has  increased  to  2.  Do not use the
   return value of the link() call.

This method is currently implemented in Lars' "publib" and has been
ported to a Perl module by Karl. 

There is no documentation available for "publib" yet, but this could
easily be fixed :-)


2.6 Other implementations
-

A few packages install binaries that handle the locking of files:

   `lockfile' --> procmail
   `shlock'   --> innd
   `newslock' --> mgetty-fax

If we should choose supporting one of these locking mechanisms, we
would have to change these binaries into shared lib

Re: Policy wrt mail lockfile (section 4.3)

[Christian Schwarz]

On 20 Jun 1997, Karl M. Hegbloom wrote:

> > "Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
> 
> Christian> This is buggy since it's not working over NFS. (I'm
> Christian> running into problems every few days since I use
> Christian> sendmail/procmail/pine over a NFS mounted
> Christian> /var/spool/mail !)
> 
> Christian> That's the exact reason why I started this discussion
> Christian> again.
> 
> What happens?  Can you describe the problem?  Explain your setup in
> more detail, please.  I would like to know more about the problems
> that are encountered with nfs.

I have a server running Debian 1.2.x, sendmail 8.8.5-1, procmail 3.10-4
and a client running Debian 1.3, pine 3.96L-2. 

The servers receives all mails from the Internet through sendmail (via
UUCP). I have a ".forward" on my account to transfer all mails to
procmail. procmail sorts the Debian mailing lists out (puts them in
specific folders). All other mails are stored in /var/spool/mail/schwarz.

When I access that folder with pine exactly when procmail modifies it
(this happens frequently!) pine complains about some other process
modifying "his" folder and aborts.



Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: checker libs with debugging symbols

[Ben Pfaff]

Michael Meskes <[EMAIL PROTECTED]> writes:
> What have libc*-dev, gdb, gcc etc. in common with debugging symbols in
> checkerlibs?
> 
> When I debug my program it suffices to me to know the problem came in
> the call to gets() for instance. I'm not interested in seeing more
> details, simply because I expect the library to be okay. Usually I
> expect a bug in my software before I consider a buggy libc.
> 
> But if the common feeling is to not do that I can still strip the
> libararies myself, you're right. But it'll have to be strip
> /usr/i486-linuxchecker/lib/* :-)
> 
> Anyway, with your arguments you could as well ask for libc-dbg to be
> fold into libc-dev again as it was earlier on.

Look, it already takes over an hour to compile the checker package and
about 300MB of disk space.  Then it takes a couple hours to upload the
thing.  And sometimes I find myself doing this multiple times per
week.  If I made another version of the package, without debugging
symbols on the libraries, it would double the time-and-space effort.
I'm *not* going to do this without a good reason.  And yours is *not*
a good enough reason, to double the effort just so someone can avoid
typing `sudo strip /usr/i486-linuxchecker/lib/*'.  Checker is for
debugging, and if you really want to do debugging, you need those
symbols.

Like I said before, it's not The Right Thing To Do.

I am happy, however, to find that my package is popular enough to
spark controversy. :-)
-- 
Ben Pfaff <[EMAIL PROTECTED]>http://www.msu.edu/user/pfaffben
PGP key: http://www.msu.edu/user/pfaffben/pgp.html or a keyserver near you
Linux: choice of a GNU generation -- Debian GNU/Linux: the only free Linux


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: leap second

[Kai Henningsen]

[EMAIL PROTECTED] (Mark Baker)  wrote on 21.06.97 in <[EMAIL PROTECTED]>:

> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (Kai Henningsen) writes:
>
> > Consider a system using "real" time. On June 31, its idea of time would be
> > wrong until the next software upgrade.
>
> No. Using real time, the system clock increments normally, and correctly
> measures the time since the epoch. The conversion from system time to local
> time changes every time there is a leap second.

Exactly. But how does the system know about leap seconds? Only by  
upgrading the software.

> > Then, all time stamps would suddenly change by one second (possibly
> > causing FTP server remirroring and other unpleasant effects).
>
> No, because they are based on the system time which is consistent. This
> would be a good thing.

This turns out not to be the case.

You know, I have a private Debian mirror. I know whereof I speak. FTP and  
mirror usually both use local time, not GMT. Changing the GMT-local  
conversion _does_ cause remirroring. I've seen it happen.

> As it is, we use POSIX time, which means that the system time follows GMT.
> When there is a leap second the time itself is changed; the timezone
> information does not need to.

And this is a good thing. (It's also completely automatic if you use  
xntpd.)

> > This is completely unacceptable. OS time must be predictable.
>
> Which is why real time would be much better than POSIX time.

I cannot rightfully understand the mental confusion that leads to  
sentences like this. (Slightly modified from a Babbage quote about GIGO, I  
believe.)

POSIX time is completely predictable.
"Real" or "right" time is completely unpredictable.

> Unfortunately we have to use POSIX time, so we're compatible with other
> computers on the network :(

Fortunately, we can use POSIX time, which is the only sane time for  
computers.

There's one way of doing it that can work completely automatic, no user  
intervention.

There's another way of doing it that needs software updates whenever a  
leap second is introduced, and which then invalidates local time for any  
time after that leap second insertion.

Why on earth would any rational person want to use the latter, except for  
some very few specialized applications?

MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: leap second

[Kai Henningsen]

[EMAIL PROTECTED] (John Goerzen)  wrote on 20.06.97 in <[EMAIL PROTECTED]>:

> What's the big deal?  Why would you have to update everything?  All
> you do is add an extra second to your system clock at the end of June
> and be done with it.  Or you don't.  Big deal.

That's when you use POSIX time. I said POSIX time was the way to go,  
didn't I?

So-called "real" (or was it "right"?) time is the problem, because the  
machine has to *know* about all leap seconds to get it right. With POSIX  
time, there's no need to know anything about leap seconds - which, after  
all, are completely unpredictable.

Also, non-POSIX time gets you the dreaded "timezone differs by a non- 
integral amount of minutes from GMT" (or whatever the exact wording is)  
from 822-date when you try to do a dpkg-buildpackage.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Kai Henningsen]

[EMAIL PROTECTED] (Goswin Brederlow)  wrote on 21.06.97 in <[EMAIL PROTECTED]>:

> OK, it's unmounted then, but it should remount the drive if its
> untouched
> or ask if it should remount it. I'm not repartitioning the drive, but I
> had
> to change the types of the partitions, cause I can't do it easily from
> AmigaOS (I dunno the hex for LNX\0). The partition holding root is
> unchanged
> so remounting it would be harmless.

Of course, it can't know that.

In general, the kernel cannot reread the partition table when it has  
mounted something from that drive, even read-only, so the only proper  
choice after changing the partition table is to reboot.

You can re-mount the partition (mount -o remount,rw /), but the kernel  
will not know about any changes you made, which can be very dangerous.

The boot disks should probably force a reboot at that point.

> The reason why I did use a partition to hold root.bin was that I tried
> to
> install Debian with only 4 MB. With only 4 MB ram you don't have enough
> space
> the kernel and a ramdisk, so I used a spare partition for it. It works
> fine,
> except from the reboot I had to make to get root remounted again.

The low memory boot disk probably does the same thing on the x86.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: RFC: library conventions for libc5 and libc6 in hamm Take 4

[joost witteveen]

> On Jun 20, Helmut Geyer wrote
> : 
> :  1. Run time packages
> : 
> : A package providing a shared library has to support both C library
> : packages, libc5 and libc6 based libraries. This must be done using
> : two Debian packages, each depending on the correct C library
> : package.
> : The package naming convention currently suggests to name these
> : packages as follows. Some packages (mostly from base) may use
> : locations in /lib. 
> : 
> :based on  | package name | library location
> :
> :  libc6   |   libfoog [1]| /usr/lib/libfoo.so.
> :  libc5   |   libfoo | /usr/lib/libc5-compat/libfoo.so. [2]
> 
> Why not simply include both libraries in one package. 

Well, with the current setup, a new libc6 package can depend on libfoog,
and the old libc5 package depends on libfoo.

> I'd think, the
> overhead can be ignored.  And package version in the future will have libc6 
> only.
> But it must be ensured, that the package w/o libc5 compat can't be
> installed as long as there are packages depending on libc5.  IMHO the
> dependency system should support it.

But that's much more difficult with your version: now all packages needing
"libfoo" just depend on "libfoo", and I seen no way to specify that
"libfoo_libc6version" cannot be installed when there are old packages
installed that depend on an old libfoo version (unless you want to
put a whole lot of Confilicts in the library, but that's really difficult
to get right). For the current setup, we get it for free.

> The libfoo/libfoog approach seems a little bit ugly.  It's pure name
> space pollution ;-)

We already have that for libraries, when we upgrade to different sonames.
And in this case, although the soname doesn't change, the library is
not usable for the libc5 programmes.

> Ok, same with namespace pollution.  Why not calling the ``normal''
> (libc6) dev package libfoo-dev and the ``old'' is libfoo-5dev or
> similar.  Again, it can disappear somewhen in future.

That's 
 -the same amount of name-space pollution
 -although it will look better in the future, it looks worse in the
  past. Yes, I ageree that it's better to have things look bad in the
  past and good in the future, but the point is: we cannot change the
  past. And the simple fackt is, that the past (also called "bo" or "hamm")
  used libfoo-dev for the names. So, there's no way we can change bo/hamm
  any more.

-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Policy wrt mail lockfile (section 4.3)

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
>--==_Exmh_970021023P
>Content-Type: text/plain; charset=us-ascii
>
>[ Please don't Cc: public replies to me. ]
>
>Karl M. Hegbloom:
>> What happens?  Can you describe the problem?  Explain your setup in
>> more detail, please.  I would like to know more about the problems
>> that are encountered with nfs.
>
>When you try to create a lock file with open(2) using O_CREAT|O_EXCL
>(i.e., you ask the kernel to create the file, but fail if it exists
>already), the operation will sometimes fail, when you network drops
>a packet. That operation simply isn't guaranteed to work over NFS,
>even though it is for normal Unix filesystems.

It's more the case that the O_EXCL flag doesn't exist in the NFS protocol.
So the operation is not atomic. The kernel itself does:

[pseudo code]

if (flags & O_EXCL) {
if (stat(file) >= 0)
return EEXIST;
}
return open (file, flags);

This is atomic on local file systems but not on NFS file systems. Usually
it will work, but I tested it by running a program repeatedly getting
a lockfile on 2 computers on a NFS mounted file system, and every once
in a while this method fails, as you would expect ofcourse.

I once wrote a patch where the kernel does:

if (flags & O_EXCL) {
/*
 *  Here the kernel uses a method with link() ing to the
 *  file, similar to NFS mailbox locking, to create the
 *  file atomically
 */
...
...
}
return open (file, flags);

It worked like a charm, but Linus wouldn't accept it in the kernel.
Too bad, all of our problems would have been solved..

I now have open() in a preloaded library, /lib/nfslock.so that gets
preloaded on all our machines through /etc/ld.so.preload. Does about
the same thing, and lets us safely share mail over NFS. A bit (a bit?!)
of a hack, though.

Mike.
-- 
| Miquel van Smoorenburg |  "I need more space" "Well, why not move to Texas" |
| [EMAIL PROTECTED] |  "No, on my account, stupid." "Stupid? Uh-oh.."|
| PGP fingerprint: FE 66 52 4F CD 59 A5 36  7F 39 8B 20 F1 D6 74 02   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Correct path for upgrading to libc6-dev?

[joost witteveen]

> 
> In article <[EMAIL PROTECTED]>,
>   Ben Gertzfield <[EMAIL PROTECTED]> writes:
> 
> >> You should certainly remove libdb-dev, since libc6-dev replaces it (as
> >> libc6 includes libdb.)  I haven't done a libdb-altdev, and unless
> >> someone asks probably won't bother (the libgdbm* packages are already
> >> uploaded though.) 
> > 
> > Oh, okay. Do you know anything about the others?
> 
> For libg++, I'd wait until there's a libg++272 package, and install the
> development stuff from that;

It's sortof difficult to wait till May 18, as that's when 
libg++272 was released, along with libg++272-dev.


> for ncurses there are libc6 versions of the

Hell, ncurses was only uploaded one week ago or something, libg++272
is _much_ older!

(And, why do you call it libg++272, why not libg++27g, that's what
the standard tells us to use. I only chose libg++272 because
HJ Lu did that, and it doesn't seem to cause problems).


-- 
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Policy wrt mail lockfile (section 4.3)

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>, Lars Wirzenius <[EMAIL PROTECTED]> wrote:
>--==_Exmh_970021023P
>> Publib uses the return value from the stat call, which
>> you're not supposed to do.  (I don't know why yet.)
>
>I check that the link count is two to see if I managed to create
>the lock file with link(2). If the stat fails, I can't check
>the link count. I _must_ check the return of the stat.

The link count is not guaranteed to be updated because of inode
caches etc. Really.. The only thing you can do is stat the original
file and the link, and compare dev/ino pairs. Only then you're sure
the link() call succeeded.

As I said before, the implementation in qpopper-2.2-4 is IMO correct.
Looking at the code now, I only see one problem and that is:

time(&now);
/* Locks are invalid after 5 minutes. */
if (now < st.st_ctime + 300)
continue;

It should really do 

/* Locks are invalid after 5 minutes. */
if ((fd  = open(lockfile, O_RDONLY)) >= 0) {
(void)read(fd, 1, buf);
fstat(fd, &st1);
now = st1.st_atime;
close(fd);
} else
time(&now);
if (now < st.st_ctime + 300)
continue;

To compensate for when the clocks of the 2 systems are out of sync.

Mike.
-- 
| Miquel van Smoorenburg |  "I need more space" "Well, why not move to Texas" |
| [EMAIL PROTECTED] |  "No, on my account, stupid." "Stupid? Uh-oh.."|
| PGP fingerprint: FE 66 52 4F CD 59 A5 36  7F 39 8B 20 F1 D6 74 02   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re^4: Status of Debian Policy

[Marco Budde]

Am 20.06.97 schrieb pdm # informatics.muni.cz ...

Moin Milan!

MZ> There is one good info browser: GNU Emacs.  On the other side I don't
MZ> know any good browser for HTML, that's the main problem of HTML
MZ> documentation.

Your're kidding ;-)? There're several really great HTML browsers like  
netscape, lynx etc. And you should remember that for example KDE will use  
HTML as help format.

MZ> really don't know why to waste my limited disk space for (mostly
MZ> uncompressed!) HTML documents, when (from my point of view) better
MZ> format is available.

We could compress the HTML documents. But that would require a www server.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re^4: Status of Debian Policy

[Marco Budde]

Am 20.06.97 schrieb schwarz # monet.m.isar.de ...

Moin Christian!

CS> Just unpack all .tar.gz files in the same directory and use the file
CS> "HOWTO-INDEX-3.html" as "index.html". It contains an overview over all
CS> available HOWTOs and mini-HOWTOs and hyperlinks to them.

Oh no, that's not a good idea. We've have produced a nice script for
doc-linux-de. The output look's much better.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Correct path for upgrading to libc6-dev?

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Ben Gertzfield <[EMAIL PROTECTED]> writes:

>> You should certainly remove libdb-dev, since libc6-dev replaces it (as
>> libc6 includes libdb.)  I haven't done a libdb-altdev, and unless
>> someone asks probably won't bother (the libgdbm* packages are already
>> uploaded though.) 
> 
> Oh, okay. Do you know anything about the others?

For libg++, I'd wait until there's a libg++272 package, and install the
development stuff from that; for ncurses there are libc6 versions of the
library itself, I'm not sure about the development stuff but a force-depends
seems to work (the header files aren't changed). I don't know about slang.

Re: leap second

[Mark Baker]

In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kai Henningsen) writes:

> Consider a system using "real" time. On June 31, its idea of time would be  
> wrong until the next software upgrade.

No. Using real time, the system clock increments normally, and correctly
measures the time since the epoch. The conversion from system time to local
time changes every time there is a leap second.

> Then, all time stamps would suddenly change by one second (possibly
> causing FTP server remirroring and other unpleasant effects).

No, because they are based on the system time which is consistent. This
would be a good thing.

As it is, we use POSIX time, which means that the system time follows GMT.
When there is a leap second the time itself is changed; the timezone
information does not need to.

> This is completely unacceptable. OS time must be predictable.

Which is why real time would be much better than POSIX time.

Unfortunately we have to use POSIX time, so we're compatible with other
computers on the network :(

Re: mgetty Needs Maintainer!

[Martin Schulze]

John Goerzen writes:
> No.  What happened is this:
> 
>  * You handed the package over to me.  I uploaded several versions
>into unstable.  (Bug reports are now going to me.)  The person
>posting that message must have been using an old version, from 1.2.
>I never made a release of mgetty to stable since there were no
>serious bugs to fix.
>  * Several months ago, I handed the package over to Siggy -- a couuple
>of days before he had a fire.  I finally figured out what happened,
>so I handed it over to a different person.

Siggy is willing to work on mgetty again.  He'll be available again,
soon.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: RFC: library conventions for libc5 and libc6 in hamm Take 4

[Heiko Schlittermann]

On Jun 20, Helmut Geyer wrote
: 
:  1. Run time packages
: 
: A package providing a shared library has to support both C library
: packages, libc5 and libc6 based libraries. This must be done using
: two Debian packages, each depending on the correct C library
: package.
: The package naming convention currently suggests to name these
: packages as follows. Some packages (mostly from base) may use
: locations in /lib. 
: 
:based on  | package name | library location
:
:  libc6   |   libfoog [1]| /usr/lib/libfoo.so.
:  libc5   |   libfoo | /usr/lib/libc5-compat/libfoo.so. [2]

Why not simply include both libraries in one package.  I'd think, the
overhead can be ignored.  And package version in the future will have libc6 
only.
But it must be ensured, that the package w/o libc5 compat can't be
installed as long as there are packages depending on libc5.  IMHO the
dependency system should support it.

The libfoo/libfoog approach seems a little bit ugly.  It's pure name
space pollution ;-)

:   2.  Development packages
: 
...
:   based on  | package name| hierarchy locations
:   ---
:   libc6 | libfoog-dev | /usr/{lib,include}
:   libc5 | libfoo-altdev   | /usr/-linuxlibc1/{lib,include}

Ok, same with namespace pollution.  Why not calling the ``normal''
(libc6) dev package libfoo-dev and the ``old'' is libfoo-5dev or
similar.  Again, it can disappear somewhen in future.



... but probably my thought are not very clear or on the other hand
_too_ much simple :-/



Heiko
--
email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [EMAIL PROTECTED][EMAIL PROTECTED]


pgpZVeC6cLQM0.pgp
Description: PGP signature

invalid CD

[Bruce Perens]

If it thinks your CD is an audio disk, it would be an error in the "xaa" file.
The very first blocks on the CD tell what kind of CD it is.

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Bruce Perens]

From: Goswin Brederlow <[EMAIL PROTECTED]>
> OK, it's unmounted then, but it should remount the drive if its
> untouched or ask if it should remount it. I'm not repartitioning
> the drive, but I had to change the types of the partitions

I think it should not unmount the root, but it should complain
before you partition a disk that the root is running on. I don't
know how many people will hit this.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: leap second

[John Goerzen]

What's the big deal?  Why would you have to update everything?  All
you do is add an extra second to your system clock at the end of June
and be done with it.  Or you don't.  Big deal.

[EMAIL PROTECTED] (Kai Henningsen) writes:

> [EMAIL PROTECTED] (Bruce Perens)  wrote on 18.06.97 in <[EMAIL PROTECTED]>:
> 
> > The time is out of joint, o 'cursed spite.
> >
> > The U.S. National Institute of Standards and Technology will set it right
> > on June 30, at one second before midnight UTC, by adding a leap second.
> > Systems that run on POSIX time will ignore this. The effect is that they
> > will consider the difference between the epoch and now to be 22 seconds
> > less than it really is.
> 
> We already had this debate. For an OS, the POSIX time is the only  
> reasonable choice.
> 
> Consider a system using "real" time. On June 31, its idea of time would be  
> wrong until the next software upgrade. Then, all time stamps would  
> suddenly change by one second (possibly causing FTP server remirroring and  
> other unpleasant effects).
> 
> This is completely unacceptable. OS time must be predictable.

-- 
John Goerzen  | Running Debian GNU/Linux (www.debian.org)
Custom Programming| 
[EMAIL PROTECTED] | 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Unidentified subject!

[Goswin Brederlow]

I've downloaded the Debian 1.3 Source CD as isoimage and cat'ed all 
peaces together. Mounting the file over a loopback device I got an error: 
'Invalid Audio Disk   Lentgh 0:00:00' from the filesystem.

Now I wonder which chunk has an error in it? Could somebody with the 
proper rights create chsums for the files please or check them agains my 
checksums?

Thanx for you're help.



---[ cksum * > ../source.cksum ]---

902672379 10485760 xaa
1964344229 10485760 xab
3103465723 10485760 xac 
3051413027 10485760 xad 
563480720 10485760 xae  
3676171232 10485760 xaf  
1496207183 10485760 xag
3982017721 10485760 xah
1996529395 10485760 xai
347485891 10485760 xaj
4224425993 10485760 xak
66454489 10485760 xal
694356895 10485760 xam
4230220127 10485760 xan
3211775232 10485760 xao
3288838828 10485760 xap
3541577135 10485760 xaq
281846891 10485760 xar
4206128507 10485760 xas
3941621231 10485760 xat
1702358845 10485760 xau
776497012 10485760 xav
2698546466 10485760 xaw
3091640865 10485760 xax
3661039644 10485760 xay
1887882477 10485760 xaz
1172648290 10485760 xba
1148886921 10485760 xbb
3528467631 10485760 xbc
4247028238 10485760 xbd 
3640030866 10485760 xbe 
989355418 10485760 xbf  
1177760836 10485760 xbg 
1760558446 10485760 xbh 
1705652203 10485760 xbi  
2413912409 10485760 xbj
4183587600 10485760 xbk
2077502854 10485760 xbl
1114555149 10485760 xbm
4249618532 10485760 xbn
3655281930 10485760 xbo
2189570894 10485760 xbp
2498623941 10485760 xbq
694282994 10485760 xbr
3161855180 10485760 xbs
890386295 10485760 xbt
3184349101 5382144 xbu

-[ end ]---

-[ Hello to all fans in domestic surveillance ]
 security NORAD plutonium DES radar Semtex Clinton Uzi NSA domestic disruption 
 smuggle kibo nuclear fissionable Legion of Doom SDI cryptographic SEAL Team 6
-[ Hello to all fans in domestic surveillance ]



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Goswin Brederlow]

OK, it's unmounted then, but it should remount the drive if its
untouched 
or ask if it should remount it. I'm not repartitioning the drive, but I
had 
to change the types of the partitions, cause I can't do it easily from 
AmigaOS (I dunno the hex for LNX\0). The partition holding root is
unchanged
so remounting it would be harmless.

The reason why I did use a partition to hold root.bin was that I tried
to 
install Debian with only 4 MB. With only 4 MB ram you don't have enough
space
the kernel and a ramdisk, so I used a spare partition for it. It works
fine, 
except from the reboot I had to make to get root remounted again.


Bruce Perens wrote:
> 
> Yes, it would do that. The problem is that un-mounting / leaves it
> mounted read-only, not unmounted. You can't unmount root. If it
> remounts it at all, it doesn't do it correctly, and re-partitioning the
> disk that root is running on is problematical, to say the least.
> On the PC installation floppy root would be a RAM disk at this point,
> and this problem would never come up. I wonder if your boot parameters
> are wrong, or if it is a 68k-specific issue.
> 
> Thanks
> 
> Bruce
> 
> From: Goswin Brederlow <[EMAIL PROTECTED]>
> > I found a bug in the installation procedure on my Amiga, but the same
> > will probably happen on all systems.
> >
> > When I try to partition the drive my root.bin is on during installation,
> > it pops up a requester asking to unmount / before starting fdisk on it.
> > After quitting fdisk it remounts /, but the installation routines
> > complain about / being read-only and nothing works anymore.
> >
> > To reproduce this behavior on another system you need a spare partition
> > at least the size of the root.bin (e.g. the swap partition). Dump the
> > root.bin onto it and boot with it as root. Select the keyboard and then
> > fdisk it (be carefull not to change anything that might erase youre
> > data). Just quiting it again should do the trick.
> > Before fdisk is started the installation routine will complain about the
> > root mounted from that drive and unmount it. After fdisk it will remount
> > it and you have the above bug.
> >
> > Can somebody second this on another system or is it just my Amiga?
> >
> >
> > May the Source be with you.
> >   Mrvn.
> >
> --
> Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
> Finger [EMAIL PROTECTED] for PGP public key.
> PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Policy wrt mail lockfile (section 4.3)

[Lukas Nellen]

[EMAIL PROTECTED] said:

> Hmm, but why would that cause a problem with mailers/programs that use
> lockfile locking *and* flock/fcntl locking at the same time?

Last time this discussion came up, Bruce found some info in the debian mail 
archive related to this. Can't find it now, though. If I remember correctly, 
the problem is that flock/fcntl locking on NFS mounted filesystems can cause 
complete lockup ( :-) ) of the process.

cheers,
Lukas
---
   Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
   Depto. de Fisica Teorica, IFUNAM |
   Apdo. Postal 20-364  | Tel.:  +52 5 622 5166
   01000 Mexico D.F., MEXICO| Fax:   +52 5 622 5015



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug in Boot-Disk Package?

[Bruce Perens]

Yes, it would do that. The problem is that un-mounting / leaves it
mounted read-only, not unmounted. You can't unmount root. If it
remounts it at all, it doesn't do it correctly, and re-partitioning the
disk that root is running on is problematical, to say the least.
On the PC installation floppy root would be a RAM disk at this point,
and this problem would never come up. I wonder if your boot parameters
are wrong, or if it is a 68k-specific issue.

Thanks

Bruce

From: Goswin Brederlow <[EMAIL PROTECTED]>
> I found a bug in the installation procedure on my Amiga, but the same
> will probably happen on all systems.
> 
> When I try to partition the drive my root.bin is on during installation,
> it pops up a requester asking to unmount / before starting fdisk on it.
> After quitting fdisk it remounts /, but the installation routines
> complain about / being read-only and nothing works anymore.
> 
> To reproduce this behavior on another system you need a spare partition
> at least the size of the root.bin (e.g. the swap partition). Dump the
> root.bin onto it and boot with it as root. Select the keyboard and then
> fdisk it (be carefull not to change anything that might erase youre
> data). Just quiting it again should do the trick. 
> Before fdisk is started the installation routine will complain about the
> root mounted from that drive and unmount it. After fdisk it will remount
> it and you have the above bug.
> 
> Can somebody second this on another system or is it just my Amiga?
> 
> 
> May the Source be with you.
>   Mrvn.
> 
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Bug in Boot-Disk Package?

[Goswin Brederlow]

I found a bug in the installation procedure on my Amiga, but the same
will probably happen on all systems.

When I try to partition the drive my root.bin is on during installation,
it pops up a requester asking to unmount / before starting fdisk on it.
After quitting fdisk it remounts /, but the installation routines
complain about / being read-only and nothing works anymore.

To reproduce this behavior on another system you need a spare partition
at least the size of the root.bin (e.g. the swap partition). Dump the
root.bin onto it and boot with it as root. Select the keyboard and then
fdisk it (be carefull not to change anything that might erase youre
data). Just quiting it again should do the trick. 
Before fdisk is started the installation routine will complain about the
root mounted from that drive and unmount it. After fdisk it will remount
it and you have the above bug.

Can somebody second this on another system or is it just my Amiga?


May the Source be with you.
Mrvn.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Correct path for upgrading to libc6-dev?

[Ben Gertzfield]

Mark Eichin <[EMAIL PROTECTED]> writes:

> You should certainly remove libdb-dev, since libc6-dev replaces it (as
> libc6 includes libdb.)  I haven't done a libdb-altdev, and unless
> someone asks probably won't bother (the libgdbm* packages are already
> uploaded though.) 

Oh, okay. Do you know anything about the others?

-- 
Brought to you by the letters K and I and the number 0.
"More testicles means more iron." -- Lunchlady Doris, The Simpsons
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .