Re: dc and bc in Important?

1997-06-27 Thread Erik B. Andersen
> 
> On Jun 23, John Goerzen wrote
> > It seems to me that dc and bc aren't vital to the workings of a
> > system (when I deselect them, dselect doesn't warn about any
> > dependencies), yet they are in Important.  Why?
> 
> In addition to what everyone else has said about what "Important"
> Really Means, please realize that bc/dc are ideal for doing 
> arithmetic in shell scripts.  [Sure, you can use awk, just as 
> you can use awk to replace grep -- but it's awkward.]
> 
> -- 
> Raul
> 

For most math, expr works just fine.  Of course, expr is limited
to integer math, but it works and is portable.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Packaging questions regarding plan

1997-06-24 Thread Erik B. Andersen
> 
> On Mon, 23 Jun 1997, Alex Yukhimets wrote:
> 
> [snip]
> > > contrib.  Try to run it on Lesstif and it won't work, because it will
> > > not find a Motif 2.0 library.  Lesstif provides a Motif 1.2 lib.
> > 
> > Yeah, but Lesstif was not meant to be *binary* compatible with real
> > Motif, only *source code* compatible! 
> 
> Is this true? Then there would be no reason to create the "motif-libs"
> virtual packages! (The only use for them would be to allow drop-in
> replacements of the compiled shared library packages.)
> 
> 
> Thanks,
> 
> Chris
> 
> --  Christian Schwarz

The reason we need virtual packages is so that we can allow people who
(like myself) have gone out and bought real Motif to use it on Debian.
I would be glad to throw away my Motif CD, and only use Lesstif.  Last
time I tried compiling Nedit against lesstif, the results were almost
usable, but still disappointing.  I am getting a new computer (K6-200)
to replace my old 486, and I plan on compiling Nedit against the latest
Lesstif again.  If it works, i will upload it (and we can get it out of
contrib).  I still plan on compiling a statically linked version against
REAL Motif though (for those who want everything to work perfectly).
I don't believe Lesstif is quite ready for primetime.  Regardless, since
there are two versions of Motif, with different Library names that are
not compatable (sure, you can recompile but they are not binary compatable),
we need both motif12 and motif20 virtual packages.  Lesstif should be
modified to provide motif12.  For other people that have commercial Motif,
we need to have TWO motif dummy packages.  Or one that provides both
virtual packages... 

Just my $0.02,

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Hamm: Retracting request for chos to be standard

1997-06-23 Thread Erik B. Andersen
> 
> >>>>> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes:
> 
> 
> Christoph> Lilo 2.0 has the ability to display a file before the
> Christoph> prompt and also the ability to boot something with a
> Christoph> single keystroke. If someone could update the lilo
> Christoph> package and provide a decent configuration then lilo
> Christoph> could also offer a nice menu on boot up so that newbies
> Christoph> are no longer irritated.
> 
> I'll have a look at this.
> 
> Christoph> Maybe lilo could also replace syslinux for the
> Christoph> bootdisks??
> 
> As someone else already said, this would be a bad idea, since the advantage
> of syslinux is its DOS support.
> 
> -- 
> 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.
> 
> 

My wife likes chos because it offers a nice simple and friendly 
and obvious like Windoze type of menu that lets her use the arrow
keys to move a color menu bar onto the (unmentionable OS) selection
a press enter.  This is very easy, and requires no domestic fighting.
I took a quick glance at the lilo 2.0 user's manual last night and 
I wasn't convinced that the "message" feature was going to be a 
nice simple and friendly and obvious like Windoze type of replacement.  
chos is much better than booting Linux using loadlin from a certain 
unmentionable OS, (which is how I used to not freak out my wife).  
If the "message" feature of lilo 2.0 can make lilo as
friendly as chos, fine, I will use it.  I doubt I will be making a
switch really soon though. How hard would it be to hack bzImage
support into chos?  That is the only real problem with chos, right?
Are there any other features lacking from it that make it unusable
by Debian?  I can certainly attest to the fact that this is one 
piece of software that passes the wife test!

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Experiences with compiling Debian

1997-06-23 Thread Erik B. Andersen
> 
> On Mon, 23 Jun 1997, joost witteveen wrote:
> 
> > (in fakt so much, that I may be tempted to write it myself. You
> > don't need that many changes).
> 
> Well, you need to write your own version of make that looks for any attempt
> to run chmod, chown etc, and then fakes all the ownership and modes in the 
> resulting tar.
> 
> I'm not sure whether it's possible in general even then, what if the package
> tries to set the ownership of a file from within another shell script or a
> perl script; how can you intercept that so it works properly?
> 
> With a few minor changes in the way packages are made---having tars all made
> as any user, and chowns done after the package is installed, either in the
> postinst or by dpkg first (the former would have the advantage of running on
> existing systems)---we could build as non-root.
> 
> 

I like this.  dpkg could set permissions on install based on a
package file similar to the suidmanager approach.  If we did this,
we could also have a global security policy setting that could, using
only dpkg, find all suid programs.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Editor wars considered harmful

1997-06-23 Thread Erik B. Andersen
> 
> > Show me a computer that can boot off a cdrom... and gimme a cdrom that
> > will boot up debian...  And Ill buy it like a shot.
> 
> Most modern motherboards will boot an IDE CD-ROM in the "El Torrito" format.
> The Debian Official CD will boot into the installation system. No floppies,
> no LOADLIN, etc.
> 
>   Bruce

Where can I buy one?  Neither CheapBytes nor Linux Systems Labs have 
made an Official CD yet because they are (apparently) waiting for us 
to release Debian 1.3.1 with Xfree86 3.3 and last I heard people didn't 
want 3.3 to go into stable...  I know lsl has made TriLinux with 1.3,
but that doesn't have ANY source and won't boot.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: New field `Entered-Date' in Packages.gz

1997-06-23 Thread Erik B. Andersen
> 
> 
>  That would be enable the WWW pages to mark the new packages with a
> `[NEW!]'.
>  It look a silly feature, but I think that it would be very useful to
> users. Other package management utilities can take advantage of this field
> too...
> 
> --=20
> Nicol=E1s Lichtmaier.-
> 

Fine with me.  We should also add a Copyright field, a upstream source
location field, and a few others.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Packaging questions regarding plan

1997-06-23 Thread Erik B. Andersen
> 
> > On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote:
> > 
> > > What about the motif-dummy thingie we discussed? How can I run plan having
> > > Motif and not lesstif installed?  Can you make sure it doesn't Depends: on
> > > lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a
> > > to-be-created-dummy package for Motif owners, would provide. Is that 
> > > doable?
> > > CC'ed this to the virtual-package-list maintainer for comments.
> > 
> > That's a good idea! AFAIK, Motif 1.x and 2.x are quite different.
> > Shouldn't we use two different virtual package names for these major
> > versions? (You can't use "versions" of a virtual package, yet.)
> > 
> 
> I don't think that support for different Moitfs are needed.
> All known software despite of being compiled with Motif 2.0 does not
> use features not present in Motif 1.2  
> The reason for this is that "big unices" does not have Motif 2.0 actively
> shiped from the vendors yet and using Motif 2.0 features would make your
> application imposible to port. *When* situation changes, I don't think
> that anyone using Motif for i386 Linux would have Motif 1.2
> 
> (And franckly speaking, 2.0 also. By that time all vendors will be
> shipping 2.1 which would _hopefully_ be compiled against glibc for Linux)
> 
> Alex Y.
> 

But things linked against Motif 2.0 cannot link against and run with a
Motif 1.2 library.  Take for example nedit-dmotif, currently in
contrib.  Try to run it on Lesstif and it won't work, because it will
not find a Motif 2.0 library.  Lesstif provides a Motif 1.2 lib.
When I compiled nedit, I used a Motif 2.0 library.  I agree with 
Chris that we should have both a motif12 and a motif20 virtual package.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Plans for Debian 1.3.1?

1997-06-22 Thread Erik B. Andersen
Are there any plans for Debian 1.3.1?  When will it happin,
and what will be included?  Will Xfree86 3.3 be included?
I am curious because I want to buy one of the CHEAP official
CDs, but I understand that the cheap cd makers are waiting
for 1.3.1, which means there are no cheap CDs yet... 

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


--
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)

1997-06-20 Thread Erik B. Andersen
This sounds good to me.  When finished, we should announce this
on c.o.l.a. and try to see if the Red Had folks will adopt it as
well.  If we both adopt it as policy, then it will live on forever!

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


> 
> On Fri, 20 Jun 1997, Lars Wirzenius wrote:
> 
> > [ Please don't Cc: public replies to me. ]
> > 
> > John Goerzen:
> > > Why are we using dotfile locking only?  There are much better
> > > mechanisms (flock, etc.) that should be used instead.  I can see no
> > > place where dotfile locking would work and flock-style locking would 
> > > fail...
> > 
> > NFS. Scripts that use procmail's lockfile.
> > 
> > (If it doesn't already, the policy manual should explain the
> > reasons behind policy. I'd check if it does, but I don't have
> > a copy and am offline.)
> 
> The current policy manual (2.1.3.3) only says:
> 
> > Mailboxes are locked using the username.lock lockfile convention, rather
> > than fcntl, flock or lockf.
> 
> This is buggy since it's not working over NFS. (I'm running into problems
> every few days since I use sendmail/procmail/pine over a NFS mounted
> /var/spool/mail !)
> 
> That's the exact reason why I started this discussion again.
> 
> AFAIK, there is at least one safe way to lock a file over NFS. The
> procedure is partially explained in the open(2) man page and is also
> implemented, for example, in your "publib" library. 
> 
> Since the procedure is not that simple, I suggested to provide a shared
> library that the other packages could be linked against, so that not every
> maintainer has to program this on his/her own (this is likely to produce
> new bugs!). And I suggested to produce "modules" for Perl/Python etc.
> 
> Someone else mentioned that the UN*X (at least Linux) world is laking such
> a library and we should therefore build not a debian specific lib, but a
> new "upstream library" which can be used by the other distributions as
> well. IMHO, that's a very good idea.
> 
> Note, that all programs will have to use the same locking mechanism (this
> has been discussed before). Thus, we should implement the simpliest
> available algorithm that is NFS-safe, since a few maintainers will
> probably need to hand-code this themselves (for example, for other
> programming languages, etc.). 
> 
> There are also tools available, that do locking, for example "lockfile" in
> the procmail package. However, calling this program with "system" produces
> IMHO too much unnecessary overhead and the source code of this program is
> a bit to complicated to force all our developers to implement this.
> 
> IMHO, the code in "publib" looks very good. I suggest that we extract the
> necessary files and put them together in a new package, called
> "liblockfile" (or similar). This package should install a shared library
> "liblockfile.so" that contains a few necessary commands to
> lock/unlock/test a file.
> 
> In addition, we could create a new "lockfile" binary (just as in procmail)
> that can be used by shell scripts or other programs (via "system").
> 
> We'll also provide "modules" for Perl/Python/etc.
> 
> 
> Any comments?
> 
> 
> (I feel like I presented these arguments several times now on this list,
> but we've not got any results so far.)
> 
> 
> Thanks,
> 
> Chris
> 
> -- Christian Schwarz
> [EMAIL PROTECTED], [EMAIL PROTECTED],
> Don't know Perl? [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.perl.com 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] .
> 


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



Re: Status of Debian Policy

1997-06-16 Thread Erik B. Andersen
I cannot agree more.  We should definatly add these fields to the
.deb package format!  This will involve a bit of work, but will be
VERY worth it.  No more licensing surprises, for instance.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--

> 
> > 
> > TOPIC 8: packages have to specify their source urls
> > ---
> >   STATUS: DISCUSSION
> >   
> 
> 
> In addition to what you propose below, I think that "dpkg -I" should be
> concerned with some of that info. Specifically, three important fields are
> missing:
> 
> Author: name and email of main upstream author (copyright holder)
> License: code describing license type
> Original-Site: site/URL at which the package is originally stored
> 
> 
> The "Author" field I think is important for giving due credit to whom
> rightfully deserves it. Some novice Debian users might think that the
> maintainer mentioned in "dpkg -I" is the author or the upstream maintainer.
> That is convenient for having users contact the Debian maintainer instead
> of bypassing them for the upstream author. However, I am convinced it is not
> fair for the "real authors" to create this confusion. Once the package is
> installed, users can check who the real author is, but they should be able
> to know it from the beginning.
> 
> The License field shoud be a code taken from a list like the following:
> 
> GPL LGPL BSD Artistic: we know what they are
> PD: public domain
> 
> Freeware: free use and redistribution, according to Debian policy (this will
>   be used only for packages which do not follow any of the types given
>   above)
> 
> Non-Free: does not comply with Debian definition of free software
> 
> We could even go further and specify the type of non-free license.
> Common types are:
> 
> packages containing sources
> ---
> 
> Non-Commercial: free use and redistribution for non-commercial purposes
> Academic: free use and redistribution for academic/research purposes
> Non-Commercial-Academic: combination of previous types
> Source-Shareware: redistribution allowed, but payment for use expected
> Tidyware: free use, redistribution only in original form or if approved
>   by author
> 
> packages without sources
> 
> Crippleware: crippled functionality, fully functional version must be 
> purchased
> Demoware: time-bombed fully functional program
> Shareware: redistribution allowed, payment for use expected
> Promotional: free use for only some people or for some time only, or due to
>  blatantly promotional reasons (like MSIE)
> Shyware: free use and redistribution of binaries, sources not available
>  because author considers them still alpha.
> 
> 
> I don't think there are many more types. The precise terms should be available
> in the "copyright" file, but since most packages would fall in one of 
> the previous categories, it would be really useful to have that shown
> in a concise way before installing a package.
> 
> The "Original-Site" field could be optional, since it is not that necesary to
> know it in normal cases. Of course, it should always be mentioned in
> the "README.debian" file, as you propose.
> 
> In summary, I think that at least the "Author" field should be added for
> ethical reasons and it would be convenient to add the "License" field.
> If you agree that this should be part of Debian policy then we should
> have the "dpkg" authors implement it.
> 
> > 
> > It has been proposed that all packages should include some information
> > about where to get the upstream sources. Thus, I propose that we list
> > all pieces of information we want to have included in the
> > ``/usr/doc/*/README.debian'' files.
> > 
> > If we have a consensus about this, we could include a ``good example''
> > for a ``/usr/doc/*/README.debian'' file.
> > 
> > I propose that the following infos are listed in this file:
> > 
> >  - Name and email address of current Debian maintainer
> >  - specification about where to get the upstream sources
> >  - short description of all major changes to the program
> >(for example, new command line options, changed locking
> >mechanism, major bug fixes, etc.)
> >  - URL of ``official home page'' if there is one (optional)
> > 
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 



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



Re: S: workaround for dpkg replaces bug

1997-06-15 Thread Erik B. Andersen
I ran into this exact problem some time ago with elvis.  What I did was
to create a bunch of zero byte files (think touch) and install them on
top of the files from the old package.  I then deleted the files in the
post init script.  This allowed dpkg to mark all files as removed from
the old package, but marked a lot of non-existant files as part of the new 
package.  I couldn't think of anything else that worked (except to conflict
with all the old stuff).  The right thing is to get dpkg fixed.  I submitted
a bug on this one a LONG time ago.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--

> 
> the dpkg replace function works only for the first package listed.
> one of my package (isdnutils) replaces more than one package (vbox,
> isdnlog, xisdnutils). maybe someone has an idea how i can make sure,
> that these three packages are not installed ? (will something in
> preinst work ?). i have no idea what i can do, till this bug in dpkg is
> fixed...
> 
> any help would be great.
> 
> thanks, andreas
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 



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



Re: Hamm: Exim + Chos standard?

1997-06-14 Thread Erik B. Andersen
> 
> Also we might think about replacing lilo with chos as the standard boot
> loader from harddisk. lilo always is a difficulty for newbies, chos
> offers:
> 
> - Menudriven Boot Loader (Cryptic Prompt only on demand)
> - Highly Customizable Color Menus.
> - Simple configuration in passwd style file /etc/chos.conf
> 

I fully agree, except for one thing...  Last I looked, chos did not
include any source code, and was in non-free.  Has this changed?
If it has, I completely agree, it should be the standard.  It is
VERY easy to use, and works VERY well.  I like it.

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: booting bzImage with chos

1997-06-14 Thread Erik B. Andersen
> 
> Chos is able to chain to a LILO boot block on a partition. It worked fine
> chaining to /dev/hdd, for example. So you can boot bzImage kernels that
> way until someone fixes "chos".
> 
> Nice program. I think it assumes that /boot is on the first drive,
> doesn't it?
> 
>   Thanks
> 
>   Bruce

Yup.  I tried to use a kernel on my second hard drive one, and it gave a
error when I ran chos.  As long as it is on the first hard drive, you should
be fine.  I don't know what it would take to snag some functionality from
lilo and stick it into chos, but I guess since chos is now GPLed (YEA!!!)
some of us should probably take a look.  (sound of ftping source in 
background). 

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Re: Tri-Linux's discription

1997-06-10 Thread Erik B. Andersen
Do you know if they will be selling the Official 1.3.0 CD
or the Official 1.3.1 CD with the new XFree86 3.3 release?

 -Erik

--
Erik B. Andersen   Web:http://www.inconnect.com/~andersen/ 
   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


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



Bug#4265: util-linux_2.5-5.deb: /sbin/clock Seg. faults

1996-08-25 Thread Erik B Andersen
Package: util-linux
Version: 2.5-5

/sbin/clock seg. faults.  The following illustrates this problem:


   Dillweed# dpkg -i util-linux_2.5-5.deb
   (Reading database ... 15590 files and directories currently
   installed.)
   Preparing to replace util-linux (using util-linux_2.5-5.deb) ...
   Unpacking replacement util-linux ...
   Setting up util-linux (2.5-5) ...

   Dillweed# clock 
-> Segmentation fault
   Dillweed# dpkg -i util-linux_2.5-4.deb 
   dpkg - warning: downgrading util-linux from 2.5-5 to 2.5-4.
   (Reading database ... 15590 files and directories currently
   installed.)
   Preparing to replace util-linux (using util-linux_2.5-4.deb) ...
   Unpacking replacement util-linux ...
   Setting up util-linux (2.5-4) ...

   Dillweed# clock
-> Fri Aug 23 01:21:12 1996
   Dillweed# 

I solved this by copying the binary from util-linux_2.5-4.deb over the
binary
from util-linux_2.5-5.deb, and everything was fine...

I am using Debian 1.1, patched up to everything in the experimental
distribution as of August 24, 1996, with kernel version 2.0.14 and
libc.so.5.2.18 from libc5.5.2.18-10.deb.

-- 
Erik B. Andersen Web:   
http://www.et.byu.edu/~andersee/ 
2485 South State St. email:  [EMAIL PROTECTED]
Springville, Ut 84663phone:  (801) 489-1231
--This message was written using 73% post-consumer electrons--