Opened 17 years ago

Closed 17 years ago

#2133 closed enhancement (fixed)

Coreutils-6.10

Reported by: Matthew Burgess Owned by: Jeremy Huntwork
Priority: normal Milestone: 7.0
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

New version. hostname and su are no longer installed by default. Also includes an implementation of mktemp and arch.

Attachments (2)

hostname (3.0 KB ) - added by DJ Lucas 17 years ago.
Final...explicit path for /sbin/sysctl and removed cut
hostname.2 (2.9 KB ) - added by DJ Lucas 17 years ago.
Replaced sysctl with cat and echo commands

Download all attachments as: .zip

Change History (39)

comment:1 by Matthew Burgess, 17 years ago

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

comment:2 by Marty Jack, 17 years ago

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

comment:3 by Matthew Burgess, 17 years ago

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.

comment:4 by ken@…, 17 years ago

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

comment:5 by ken@…, 17 years ago

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.

in reply to:  4 comment:6 by ken@…, 17 years ago

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.

in reply to:  5 comment:7 by ken@…, 17 years ago

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.

comment:8 by dnicholson@…, 17 years ago

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.

in reply to:  8 ; comment:9 by ken@…, 17 years ago

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.

in reply to:  9 ; comment:10 by Matthew Burgess, 17 years ago

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.

in reply to:  10 ; comment:11 by ken@…, 17 years ago

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.

in reply to:  11 ; comment:12 by Matthew Burgess, 17 years ago

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.

in reply to:  12 comment:13 by Ag. Hatzimanikas, 17 years ago

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.

comment:14 by DJ Lucas, 17 years ago

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.

comment:15 by DJ Lucas, 17 years ago

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

comment:16 by ken@…, 17 years ago

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.

in reply to:  15 comment:17 by ken@…, 17 years ago

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 ?

comment:18 by DJ Lucas, 17 years ago

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.

by DJ Lucas, 17 years ago

Attachment: hostname added

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

comment:19 by ken@…, 17 years ago

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.

comment:20 by dnicholson@…, 17 years ago

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.

comment:21 by Matthew Burgess, 17 years ago

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?

comment:22 by dnicholson@…, 17 years ago

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?

in reply to:  21 comment:23 by ken@…, 17 years ago

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.

in reply to:  22 comment:24 by ken@…, 17 years ago

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.

comment:25 by dnicholson@…, 17 years ago

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

comment:26 by Matthew Burgess, 17 years ago

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?

comment:27 by dnicholson@…, 17 years ago

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.

comment:28 by DJ Lucas, 17 years ago

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

by DJ Lucas, 17 years ago

Attachment: hostname.2 added

Replaced sysctl with cat and echo commands

comment:29 by DJ Lucas, 17 years ago

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

comment:30 by Matthew Burgess, 17 years ago

Resolution: fixed
Status: newclosed

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.

in reply to:  11 comment:31 by ken@…, 17 years ago

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.

comment:32 by Thomas, 17 years ago

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

in reply to:  32 comment:33 by Thomas, 17 years ago

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

in reply to:  16 ; comment:34 by randy@…, 17 years ago

Resolution: fixed
Status: closedreopened

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.

in reply to:  34 comment:35 by Jeremy Huntwork, 17 years ago

Owner: changed from lfs-book@… to Jeremy Huntwork
Status: reopenednew

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.

comment:36 by Jeremy Huntwork, 17 years ago

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

comment:37 by Jeremy Huntwork, 17 years ago

Resolution: fixed
Status: newclosed

Fixed in r8508.

Note: See TracTickets for help on using tickets.