[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Coreutils



Hello guys,

Here you can find a completed (at least a lot) coreutils package that
seems to work properly on our systems.

http://toad.atari-source.com/~mduckworth/rpm_staging/

Inside you will find rpm and srpm, and you will also find the completed
build root which has the tests and such that are failing (Frank you
asked to see this).

This is a bit of a touchy subject but this coreutils, since we are
linking statically is costing about 800+K for something like ls where as
this tool used to be only 100-200K.  This means the coreutils binary RPM
is a whopping 47 megs!  I've been trying to shrink binary sizes but to
no avail.  I must be missing something.

So these are the tests that are failing.  Some may have been cured by my
more recent slashes patches, but others are definitely not, like the
no-x ones.  Also when these tests failed I forgot to adjust stack sizes
so that could have been a number of them.  I know the dd problem still
exists:

chgrp: no-x
chmod: no-x
dd: skip-seek
du: no-x
ln: misc, backup-1
ls: file-type
misc: nohup
rm: rm1
stty: basic-1
tail: tail-tests 
touch: not-owner, dangling-symlink

As always, be careful with this package as it seems to completely blow
away fileutils, textutils and sh-utils.  This'll increase bloat on your
system and some of the finer tools may not work properly though it seems
I got the basic ones, ls, cp, mv, rm rmdir, and mkdir working great.

So let me know what you guys think of this and which direction we should
go.  I for the most part went ahead with this because my rpms were
failing on stuff like mkdir $RPM_BUILD_ROOT/{stuff,temp,things} where
instead of creating the dirs separately it would literally create the
dir "{stuff,temp,things}".  It's kind of strange since mkdir didn't do
it outside of the rpm build process - leading me to believe we may have
absolutely no reason to upgrade.

Thanks,
Mark