Coreutils-6.10

Some more observations:

* We should be able to remove the suppression patch. --enable-no-install-program="kill uptime su" should do the trick. We may want to add 'arch' to that list too, as it's not installed by default.

* The i18n patch doesn't apply cleanly. Probably just requires some slight adjustments, but I'm getting disillusioned with carrying the patch around.

* It no longer builds/installs hostname as the implementation was out of date. Apparently net-tools has an implementation, and there was talk of getting one into util-linux-ng too, but it doesn't appear to be in 2.13.1

Of additional note is that this release is available in .tar.gz and .tar.lzma (and not .tar.bz2). Should anyone feel like trying out the .lzma, it is available from http://tukaani.org/lzma/; the minimal unpack command I've found to date is lzcat path/to/coreutils-6.10.tar.lzma | tar x

What's your plan with respect to mktemp?

- Marty Jack

My plan is to drop the mktemp package and just use the coreutils implementation. As far as LZMA goes, I'd rather ignore it for now - it's very rarely used in Linux/UNIX from what I've seen, so we'll just revert to the .tar.gz tarball for the time being.

For hostname, we could just use 'uname -n'. Means altering our bootscripts for localnet. I'm still thinking about the i18n patch.

I think we ought to use the fedora patch from http://cvs.fedoraproject.org/viewcvs/devel/coreutils/coreutils-i18n.patch for the i18n part - after breaking it down into the component files, and comparing it to what we have for 6.9, the code is slightly different in a few places (cut, fold, sort; uniq now uses readline_buffer_delim instead of readline_buffer) but probably more often reviewed than our patch.

The problem with their patch is that they don't update tests/sort/Makefile.in, instead they rely on the wonders of autotools. That isn't an option for us in chapter 6, so I propose that we maintain a separate patch for this part.

Just to be clear, I think we should be rediffing with the fedora patch to apply our own standards to the patch header, and to make sure that users pick up a known version, but reviewing their changes from time to time. I'm in no doubt that some form of this patch is needed, even though upstream don't like it.

I'm planning to start a test build shortly, for this and a few other things, but I'd prefer comments on this change of "whose patch do we use" strategy.

Replying to ken@linuxfromscratch.org:

For hostname, we could just use 'uname -n'. Means altering our bootscripts for localnet. I'm still thinking about the i18n patch.

Of course, that's a non-starter because we're setting it, not asking what it is. I'm cool with using net-tools (again), but that's a big change.

Replying to ken@linuxfromscratch.org:

I'm planning to start a test build shortly, for this and a few other things, but I'd prefer comments on this change of "whose patch do we use" strategy.

Hmm, now that I've shot myself in the foot over hostname, I won't be testing this for the moment. Comments still welcome.

Well, you can use sysctl for hostname:

$ sysctl -n kernel.hostname
$ sysctl -q -w kernel.hostname=foo

We could write a wrapper script for that. Personally, I already disable the hostname from coreutils and use the one from net-tools because it has more features. It would be good to know if and/or when hostname might be added to util-linux-ng. That would be the proper place for it, anyway, since it could be tailored to Linux specific interfaces.

Replying to dnicholson@linuxfromscratch.org:

Well, you can use sysctl for hostname: {{{ $ sysctl -n kernel.hostname $ sysctl -q -w kernel.hostname=foo }}} We could write a wrapper script for that.

Or, just feed it into the bootscript as

sysctl -q -w kernel.hostname=${HOSTNAME}

As you might have guessed, I normally use 'uname -n' from my buildscripts to do host-specific things, I can quite happilly get by without a formal hostname script.

Personally, I already disable the hostname from coreutils and use the one from net-tools because it has more features. It would be good to know if and/or when hostname might be added to util-linux-ng. That would be the proper place for it, anyway, since it could be tailored to Linux specific interfaces.

No arguments that util-linux-ng would be the proper place, but google knows nothing about any intention to put hostname.c there.

Thanks for the response, if you hadn't posted that, I would have said that the choice comes down to either using the unmaintained net-tools, or using the not-installed-by-default version from coreutils, at least in the short term, and I would have to prefer the coreutils version. I think one of the reasons net-tools was dropped from LFS was because it is no longer maintained, as shown by the patches BLFS has to apply.

Replying to ken@linuxfromscratch.org:

No arguments that util-linux-ng would be the proper place, but google knows nothing about any intention to put hostname.c there.

Thread starts at http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00154.html and continues at http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00112.html.

Doesn't look like anything ever got committed in util-linux-ng upstream though. I'll chase them up later on today.

Replying to matthew@linuxfromscratch.org:

Replying to ken@linuxfromscratch.org:

No arguments that util-linux-ng would be the proper place, but google knows nothing about any intention to put hostname.c there.

Thread starts at http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00154.html and continues at http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00112.html. Doesn't look like anything ever got committed in util-linux-ng upstream though. I'll chase them up later on today.

Thanks for the links. In the meantime, and subject to a complete build actually working, I'd like to see 6.10 in the book. How about adding the following version of hostname at the end of procps, which is where sysctl is installed ?

cat >/bin/hostname <<EOF
#!/bin/sh
if [ \$# -gt 0 ]; then
        sysctl -q -w kernel.hostname=\$1
else
        uname -n
fi
EOF
chmod -m 0755 /bin/hostname

I need to do more testing on the coreutils build before I start a full system build, I had some odd errors yesterday (e.g. invocation of autotools, which failed at the lzma identifier), and it appeared to not install arch even though I had not mentioned it in my override of --enable-no-install-program.

Replying to ken@linuxfromscratch.org:

Replying to matthew@linuxfromscratch.org:

Replying to ken@linuxfromscratch.org:

No arguments that util-linux-ng would be the proper place, but google knows nothing about any intention to put hostname.c there.

Thread starts at http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00154.html and continues at http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00112.html. Doesn't look like anything ever got committed in util-linux-ng upstream though. I'll chase them up later on today.

Thanks for the links. In the meantime, and subject to a complete build actually working, I'd like to see 6.10 in the book. How about adding the following version of hostname at the end of procps, which is where sysctl is installed ? {{{ cat >/bin/hostname <<EOF #!/bin/sh if [ \$# -gt 0 ]; then sysctl -q -w kernel.hostname=\$1 else uname -n fi EOF chmod -m 0755 /bin/hostname }}}

I'd prefer hostname to be installed during util-linux-ng, assuming nothing in the build depends on it. That way, if/when util-linux-ng get release an upstream version, we just remove it at the same time as the version bump, without touching other packages.

I need to do more testing on the coreutils build before I start a full system build, I had some odd errors yesterday (e.g. invocation of autotools, which failed at the lzma identifier), and it appeared to not install arch even though I had not mentioned it in my override of --enable-no-install-program.

I've not tested the syntax for --enable-no-install-program out yet, but do remember seeing some emails flying around regarding whether it was a space-separated or comma-separated list.

I'd like to see 6.10 in the book too. To that end, I think we should proceed with a modified Fedora version of the i18n patch, `hostname' script added on to util-linux-ng's page, and the mktemp package removed. I'd appreciate it if you could find the time to test that combination out Ken. If not, I'll certainly get around to it at some point.

Replying to matthew@linuxfromscratch.org:

and it appeared to not install arch even though I had not mentioned it in my override of --enable-no-install-program. I've not tested the syntax for --enable-no-install-program out yet, but do remember seeing some emails flying around regarding whether it was a space-separated or comma-separated list.

Arch is not installed by default, same with su and hostname.

The syntax for the "--enable-no-install-program" is a comma-separated list.

Also groups will be installed, even if you try to exclude it.

Any objection if I suggest a little more (but not quite) complete hostname script? I'd have done yp, dec, and nis, but I don't know a thing about them. I assume without the appropriate kernel support, I cannot set the kernel parameters for them. :-) Anyway, attached.

Oops...don't use that...forgot to handle extra -args. :-) New one in a few minutes.

With --enable-no-install-program="kill,uptime,su" I don't get arch or hostname either. Not that I want them now, just a note that they don't need to be in the list here.

Replying to dj@linuxfromscratch.org:

Oops...don't use that...forgot to handle extra -args. :-) New one in a few minutes.

A quick look suggests that is a nice fully-featured version, instead of my "minimal, no error checking" version. But, I don't fancy instructing our builders to type it all in ?

I agree about not typing it in. I'm not sure if/where it could fit into LFS's layout, but we provide a download in BLFS for the .mozconfig files. Could just tack it onto the packages download page...or not. The one you provided does the job for LFS's purpose. I also used cut, which is a nono because it's in /usr/bin, but that can be replaced with sed. I've just haven't liked the hostname that's been in LFS since we ditched net-tools (a package which I'm all for leaving in the past). On a side note though, it would be nice to *see* a more advanced shell script directly in the book, at least from an educational standpoint. I'm fairly sure that few people go digging through the functions and rc scripts in the bootscripts package.

Final...explicit path for /sbin/sysctl and removed cut

The absence of hostname means we'll need to do something for perl's testsuite. I hadn't spotted we were invoking hostname in a subshell there - obviously, that breaks.

Tried omitting the hostname, but I get one failure, lib/Net/t/hostname. I guess $(uname -n) should work there, but my buildscript is continuing after the one failure in the perl tests.

Before they get lost, time to document a couple of things for the coreutils testsuite: it needs the perl Errno module - Dan posted a make command for that on diy, looks strange but works nicely - and the non-root tests need a chown to the user running them, similar to what Greg posted there. Thread at http://www.diy-linux.org/pipermail/diy-linux-dev/2008-February/001182.html but note it doesn't all apply to LFS.

Yes, I should have posted that here. Basically add "ext/Errno/pm_to_blib" onto the make command. That's just stripped from the default $nonxs_ext that would be built if you did "make all". I couldn't find a convenient target to leech off of so that $(nonxs_ext) would be pulled in without a bunch of other stuff.

My work-in-progress patch series adds the hostname script from comment 13 to util-linux-ng and moves the build/install of util-linux-ng to before coreutils. Admittedly, the script is useless prior to Procps, which is 5 packages later on in the build, but it's not needed until Perl which is after Procps anyway. I'll try and upload my patch series tonight so everyone can review it, but does the above seem sensible?

Alternatively, you could also add it for the Ch. 5 util-linux-ng and leave all the order alone.

In fact, you could probably just use the really minimal hostname script Ken added in comment:10 since it's just to satisfy the perl and coreutils testsuites. Then you could use DJ's fully featured script in Ch. 6 util-linux-ng.

What do you think?

Replying to matthew@linuxfromscratch.org:

My work-in-progress patch series adds the hostname script from comment 13 to util-linux-ng and moves the build/install of util-linux-ng to before coreutils. Admittedly, the script is useless prior to Procps, which is 5 packages later on in the build, but it's not needed until Perl which is after Procps anyway. I'll try and upload my patch series tonight so everyone can review it, but does the above seem sensible?

I'm unhappy about adding a script which won't work until later - it leaves a hostage to fortune. And I'm very uncomfortable about moving util-linux just for this.

Replying to dnicholson@linuxfromscratch.org:

Alternatively, you could also add it for the Ch. 5 util-linux-ng and leave all the order alone. In fact, you could probably just use the really minimal hostname script Ken added in comment:10 since it's just to satisfy the perl and coreutils testsuites. Then you could use DJ's fully featured script in Ch. 6 util-linux-ng. What do you think?

I like this.

Unless I've forgotten something (very possible), it's only perl that needs this.

Oh, you're right! That's why you mentioned procps. Here's one more thought. Ken originally suggested just using uname -n' as a hostname wrapper. If all that hostname is ever used for in the testsuites is just getting the current name like host=hostname`, then you could just use this in Ch. 5 util-linux.

cat > /tools/bin/hostname << "EOF"
#!/bin/sh
exec uname -n
EOF
chmod 755 /tools/bin/hostname

OK, just so I have a clearer idea of what's being proposed here:

1) Put Dan's mini-hostname wrapper from comment 25 into chapter05's util-linux-ng 2) Put DJ's full-hostname wrapper from the attachment into chapter06's util-linux-ng 3) Leave the build-order alone

The only issue I have with that is how we get 2) installed. It's not feasible to have our user's type all of that in. Neither can we assume they'll use scripts or even copy and paste it in.

I'd think the easiest is to add a download link to the script on the software packages page, then just do the required 'cp' and 'chmod' commands on it. If that's all it takes, the instructions for doing that will be less than for typing in Dan's mini-hostname wrapper, so we may as well install DJ's in both chapter 5 & 6. Bonus points for consistency between the 2, right?

The problem Ken brought up about using DJ's full script is that you need sysctl from procps. We don't have that in /tools, so I think the mini-hostname is needed. Or, we could just build Ch. 5 coreutils with --enable-install-program=hostname, right? I mean, that hostname might not be optimal, but it's been working and it should be enough for testsuites.

How about just ditching sysctl and do it up in the old style. It'll take me 5 minutes, starting now, to replace sysctl with cat and have it uploaded. ;-)

Replaced sysctl with cat and echo commands

Wait..you mean it does include a hostname? I thought it wasn't included at all. Anyway, the script works if you want it, without sysctl as a dependency. But if NG comes with the one we had before, then why bother? Those that want something similar to the old hostname from net-tools without all of net-tools can use my old crusty patch of the net-tools one, or a script similar to this one on their own. I had thought we were completely without a hostname binary and figured if we had to make one, then make it the good one (well as close as I needed to it anyway).

It still has hostname.c in the tarball but I mistakenly thought they'd ripped out all the Makefile rules to have it built. As it is, they've just put it under the control of --enable-install-program, so I've added that to chapter 5 & 6's Coreutils instructions. Fixed in r8470.

Replying to ken@linuxfromscratch.org:

{{{ cat >/bin/hostname <<EOF #!/bin/sh if [ \$# -gt 0 ]; then sysctl -q -w kernel.hostname=\$1 else uname -n fi EOF chmod -m 0755 /bin/hostname }}}

OK, I know we've got a real hostname now|again, but I've finally got to the end of my current build with this, so I'll now say: "Don't try this at home!". Something in my blfs packages for the things I build before booting managed to call 'hostname -f'. I still haven't found which package it was, but it altered the host-system's name to -f and my automated backup scripts were distinctly unimpressed. So, anyone who wants to use a script for hostname needs to handle that in some form.

Ok, I know, LFS-Book doesn't care about others than x86, but I like to add this nevertheless:

Using the actual instructions for x86 on a PPC results in:

...
mv t-ref-del.sed ref-del.sed
make[2]: Leaving directory `/tools/newlfs/sources/coreutils/coreutils-6.10/lib'
make[1]: Leaving directory `/tools/newlfs/sources/coreutils/coreutils-6.10/lib'
Making all in src
make[1]: Entering directory `/tools/newlfs/sources/coreutils/coreutils-6.10/src'
make  all-am
make[2]: Entering directory `/tools/newlfs/sources/coreutils/coreutils-6.10/src'
gcc -std=gnu99  -I. -I../lib  -I../lib   -g -O2 -MT uname.o -MD -MP -MF .deps/uname.Tpo -c -o uname.o uname.c
uname.c: In function 'main':
uname.c:447: warning: initialization discards qualifiers from pointer target type
uname.c: In function 'has_sse':
uname.c:500: error: impossible constraint in 'asm'
make[2]: *** [uname.o] Error 1
make[2]: Leaving directory `/tools/newlfs/sources/coreutils/coreutils-6.10/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tools/newlfs/sources/coreutils/coreutils-6.10/src'
make: *** [all-recursive] Error 1

-- Thomas

Replying to Moody:

Forget it - i used the LFS uname patch instead the CLFS uname patch. That caused the failure.

Sorry for the noise.

-- Thomas

Replying to ken@linuxfromscratch.org:

With --enable-no-install-program="kill,uptime,su" I don't get arch or hostname either. Not that I want them now, just a note that they don't need to be in the list here.

Reopening this ticket as I've got a question, but didn't want it to get lost in the -dev list.

I did a fair amount of research looking at this ticket and trying to find as much as I could on the -dev list, but I really don't see the answer.

Is there a reason that the uptime binary is not added to the --enable-no-install-program= list? The Procps package later adds uptime, which would overwrite it, but I'm just wondering if it shouldn't be suppresed in the first place?

Sorry if this has been answered.

Replying to randy@linuxfromscratch.org:

Is there a reason that the uptime binary is not added to the --enable-no-install-program= list? The Procps package later adds uptime, which would overwrite it, but I'm just wondering if it shouldn't be suppresed in the first place?

Yes, this appears to be a mistake. The patch used to suppress kill, su and uptime since those are provided later on. We already have a su-tools in /tools that we use for testsuites, so continuing to suppress that as well won't hurt.

Woops, of course, as this ticket begins, the installation of su is already suppressed, even though it builds it. Still could use uptime added.

Fixed in r8508.