[ANNOUNCE] util-linux-ng 2.13-rc1

[Karel Zak]

The first util-linux-ng 2.13 release candidate is available at

ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/

Thanks to all who help with util-linux resuscitation:

H. Peter Anvin
Ian Kent

and contribute to this project:

Arkadiusz Miskiewicz Matthias Koenig
Cliff Wickman Mike Frysinger
David Brownell Pádraig Brady
David Miller Radek Biba
Jason Vas Dias Ram Pai
Kay Sievers Stepan Kasal
Luciano Chavez Steve Grubb
Marco d'Itri Valerie Henson
Martin Schlemmer

Feedback and bug reports, as always, are welcomed.

Karel

Util-linux-ng 2.13 Release Notes
================================

Release highlights:
------------------

mount(8) doesn't include NFS client code anymore. Don't forget to
install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.

mount(8) doesn't include filesystem detection code anymore. You
have to compile --with-fsprobe={blkid,volume_id}, and libblkid
(e2fsprogs) or libvolume_id (udev >= v110) is required.

mount(8) supports new relatime, context, fscontext, and defcontext
mount options.

losetup(8) supports command line option "-a" to list all used loop
devices, '-s' to print a device name if "-f" and a file argument
are present, and "-r" to create a read-only loop device.

fdisk(8) Sun label support has been improved. fdisk(8) is also able
to warn about detected GPT (fdisk doesn't support GPT).

taskset(1) is independent on hardcoded NR_CPUS. chrt(1) supports
SCHED_BATCH scheduling policy.

The package build system is now based on autotools. The build system
supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
SUID_LDFLAGS). For more details see the README file

hwclock(8) supports command line option --rtc=<path> and /dev/rtc0
device. --systohc functionality has been improved, and it doesn't cause
a 500ms inaccuracy each time it is used.

Audit system support (--with-audit) has been added to hwclock(8) and
login(1).

SELinux support (--with-selinux) has been added to mkswap(8) and
mount(8).

The setarch(8) upstream has been merged with util-linux-ng.

Fixed security issues:
---------------------

CVE-2007-0822 - mount(8) allows local users to trigger a NULL
dereference and an application crash
CVE-2006-7108 - login(1) omits PAM account validation when auth is
skipped

Changelog:
---------

agetty:
add 'O' escape code to display domain name
check gethostname() return value
blockdev:
add BLKFRAGET/BLKFRASET ioctls
cleanup usage() and update man page
build-sys:
add AC_GNU_SOURCE
add Automake option dist-bzip2
add missing files
add SUID_CFLAGS
add SUID_LDFLAGS
add support for audit
amend .gitignore
call automake after autoconf
cleanup architecture conditionals
cleanup sys-utils/ rdev symlinks
configure.am selinux support cleanup
declare SUID_CFLAGS and SUID_LDFLAGS as precious
do not build convenience libraries in lib/
do not kick off AM_CFLAGS by SUID_CFLAGS
do not play with DEFS, use AM_CPPFLAGS
do not set with_foo twice
do not use internal Autoconf variables
do not use wildcards in EXTRA_DIST
factor out common parts from mount/Makefile.am
fix HAVE_NCURSES
fix ifdef ENABLE_WIDECHAR usage
fix linking when ncurses is built with --with-termlib=tinfo
fix README filenames and add missing files to EXTRA_DISTs
fix the example configure call in README
fix the final message of autogen.sh
in configure.ac, change "po" -> "$srcdir/po"
in the clean targets use "find ... | xargs rm -f"
let configure instantiate the misc-utils/*.pl scripts
make the getopt example directory relative to datadir
merge adjacent AC_CONFIG_HEADERS and AC_CONFIG_FUNCS calls
minor fixes in configure.in
mount/Makefile.am tiny cleanup
mount/Makefile.am tiny cleanup II
move -D flags to *_CPPFLAGS
move the optimization flags to AM_CFLAGS
--prefix defaults to /usr
remove aclocal.m4 from SCM
remove AC_PROG_RANLIB
remove config.h.in from VCS
remove config/include-Makefile.am from EXTRA_DIST
remove DEFAULT_INCLUDES workaround
remove -fomit-frame-pointer
remove generated autotools stuff from git
remove po/Makevars.template from EXTRA_DIST
remove swapargs.h, move the tests to main configure.ac
rename to -ng, change maintainer name
replace AC_TRY_* by AC_*_IFELSE
s/AC_HELP_STRING/AS_HELP_STRING/
set DISTCHECK_CONFIGURE_FLAGS in top-level makefile
simplify "clean" in tests/Makefile.am
update po/POTFILES.in
use dist_example_DATA
use dist_noinst_DATA to work around the bug with dist_man_MANS
use dist_noinst_HEADERS in include/Makefile.am
use dist_usrbinexec_SCRIPTS in misc-utils/Makefile.am
check exit status of autotools
cal:
fix a segfault and -3m highlighting
ifdef cleanup, non-curses/tempcap code fixes
widechar code cleanup
cfdisk:
build-sys defines HAVE_RPMATCH, not HAVE_rpmatch
fix stupid typo in GPT checker call
chsh:
remove tailing wihit-spaces and use PATH_BSHELL
col:
getwchar() errors shouldn't be hidden
ddate:
fix compiler warnings
docs:
add the DEPRECATED file
clean up TODO file and add a new resuest for 2.14
fix info about devel/master branchs
fix URL and typos in README.devel
refresh AUTHORS file
remove deprecated section from README
update AUTHORS file
update TODO file
fdisk:
add GPT detection code
add MAC label detection
cleanup full disk detection code
fix "differ in signedness" compiler warnings
fix "type qualifiers ignored on function return type"
Makefile.am refactoring
many significant improvements and fixes to Sun label handling
move duplicate stuff from fdisk*label.h to fdisk.h
use unsigned long long instead int for sectors
getopt:
remove old unused files
hexdump:
don't use memset with zero lenght
hwclock:
add --rtc=<path> option and support for /dev/rtc0
add support for audit system
fix --systohc sets clock 0.5 seconds slow
make ggc happy and check return values from fgets, read and write
remove tailing white-spaces and clean up clock.h
ipcs:
add new tests for ipcs limits
add regression test for output headers
fix typo in Semaphore headers
max total shared memory in kbytes instead pages
login:
add audit support
add IPv6 support
add regression test for IP address checking code
attempt to run if it has no read/write access to its terminal
close PAM session after failed pam_setcred
improve work with signals
keep syslog useful for end of PAM session.
login's timeout can fail
omits PAM account validation when auth is skipped (CVE-2006-7108)
remove triiling white-spaces
update 32bit utmp correctly on 64bit system
look:
fix problem with !isalnum() words
remove tailing white-spaces
losetup:
add a new option -s
add -a option to list all used loop devices
add long options and fix man page
add support read-only loops
add to man page info about deprecated cryptoloop
man pages:
add "AVAILABILITY" section
mcookie:
remove non-linux code
misc-utils:
add scriptreplay manpage
remove old cal test
mkfs.cramfs:
cleanup HAVE_ macros usage
fix a way how mkfs works with empty files
remove hardcoded limit for directories
mkswap:
add regression test
automatically add selinux label to swapfile
avoid mkswap usage on already mounted device
gcc happy: unsigned long usage
fix libuuid usage in mkswap
more:
fix file descriptor leak
mount:
add note about /etc/mtab unreliability to mount.8
add note about fcntl/ioctl unreliability on NFS to mount.8
add -s and -f and note to man page for external mount helpers
add simple (printf-like) debug routine and --debug option
add support for context, fscontext and defcontext selinux mount options
add support for mixed usage of SPECes
add support for mtab "uhelper" option
avoid duplicate entries in mtab when mount -f
call /sbin/mount.<type> also when mounting without "-t"
clean up getfs* (fstab.c) interface
clean up info about NFS in mount.8
doesn't rpc_pipefs and nfsd on umount -a
do not treat arm/sparc specially.
don't umount sysfs when running umount -a
fix -fv so that it doesn't incorrectly spit out an error that nothing was done.
fix has_* functions (CVE-2007-0822)
fix list logic in update_mtab
fix memory usage in update_mtab
fix mtab_lock
fix typo in error message
fsprobe: add libvolume_id support
fsprobe: add libvolume_id support to configure.ac
fsprobe: make fsprobe_get_devname functions more generic
fsprobe: remove mount_guess_fstype.{c,h}
fsprobe: remove non-blkid code
fsprobe: rename files to fsprobe_*
fsprobe: rename the rest of API routines to fsprobe_*
fsprobe: use blkid cache only when really necessary
getfs_* (fstab) interface has to work with canonicalize()
kill mount_guess_rootdev
loop device race condition
needs to handle special mountprog even on guessed file systems.
parse SPEC before search in fstab
relative atime support
remove all NFS code
remove nfsmount() from sundries.h
rewrite getfs_by_specdir() without mem leaks
shared-subtree support
update mtab correctly when mount --move
use encoded labels for volume_id
use growable string for options
use loop= option when mounting by /sbin/mount.<type>
use realloc for xstrconcat functions
use verbose mode instead debug mode
namei:
fix logic and infinite loop of symlinks
new regression test
newgrp:
add support for /etc/gshadow
check result from getgrnam() more carefully
partx:
add man pages for addpart, delpart and partx
po:
rename mount/mntent.c to mount/mount_mntent.c
typo in french translation of mount error.
update po files
vipw doesn't use rpmatch, all translations have to use y/n
raw:
add file with udev rule example
don't accept raw0 as a target name
move the raw command to /sbin
update man page (about dd and O_DIRECT)
schedutils:
add support for SCHED_BATCH
define SCHED_BATCH when compile with old glibc
remove extra hyptens from man pages
taskset is independent of hardcoded NR_CPUS max
fix ionice build on sparc
setarch:
add NLS support
sfdisk:
fix "differ in signedness" compiler warnings
fix "may be used uninitialized" compiler warnings
setting default geometry values
swapon:
cleanup PATH_ macros and tailing white-spaces
does not correctly deal with symlinks
fix swapon headers and syscalls
simplify an #if
sys-utils:
added setarch command
add note about obsolete ramsize option to rdev.8
fix man page headers
move some man pages from category 8 to 1
tests:
add basic infrastructure for regression tests
add cal -1 test
add cal -3 test
add cal -y test
add expected outputs for cramfs
add functions for label, uuid and fstype detection
add hwclock systohc test
add library for LD_PRELOAD to manipulate with time() in tests
add lock_mtab() performance and reliability test
add look test for words with separator
add missing header
add mkfs.cramfs tests
add more variants to {mount,fstab}-by-{label,uuid,devname}
add mount by devname from fstab
add mount by devname test
add mount by devname with label in fstab
add mount by devname with uuid in fstab
add mount by label from fstab test
add mount by LABEL test
add mount by label with devname in fstab
add mount by label with uuid in fstab
add mount by UUID from fstab test
add mount by UUID test
add mount by uuid with devname in fstab
add mount by uuid with label in fstab
add mount /dev/symlink test
add mount --move test
add mount -o remount test
add return code
add simple helper that returns info about system
add support for fstab modification
add support for suid programs
add swapon by devname test
add swapon by UUID test
add test for /sbin/mount.<type> call
add ts_log and --verbose support
add ts_ok and ts_failed
cleanup blkid cache after test device deinitialization
code refactoring -- new ts_device_init function
code refactoring -- new ts_skip_nonroot function
code refactoring -- new ts_udev_loop_support function
enable mtablock test when uid=0 only
fix argv[] usage in mnt_test_sysinfo.c
fix dependence on blkid
fix Makefile.am (add missing tests)
fix ts_fstab_add function
"if [...]" clean up
make clean need to remove diffs and outputs
pass all arguments to ts_init, add ts_has_option function
refresh mtablock output in expected/ directory
simplify devices usage
text-utils:
fix the more command compilation against termcap
tools:
add codecheck-config that checks for {HAVE,ENABLE}_ orphans
vipw:
fix permissions (600->400) for edited /etc/[g]shodow files
wall:
fix O_NONBLOCK usage
misc:
Clean up pagesize/PAGE_SIZE usage.
clean up realpath.[ch] includes and macros
execl() should be use NULL not 0

--
Karel Zak <kz...@redhat.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Christoph Hellwig]

On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> mount(8) doesn't include filesystem detection code anymore. You
> have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> (e2fsprogs) or libvolume_id (udev >= v110) is required.

Sorry, but it's really annoying to pull in a filesystem-specific devel
package for that. Having a library is fine, but please move the library
into util-linux so it's always available without another dependency. That
way xfsprogs could for example drop it's own detection library aswell.

> The package build system is now based on autotools. The build system
> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> SUID_LDFLAGS). For more details see the README file

And this is really dumb. autotools is a completely pain in the ass and
not useful at all for linux-only tools.

[David Miller]

From: Christoph Hellwig <h...@infradead.org>
Date: Wed, 4 Jul 2007 09:42:11 +0100

> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > mount(8) doesn't include filesystem detection code anymore. You
> > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > (e2fsprogs) or libvolume_id (udev >= v110) is required.
>
> Sorry, but it's really annoying to pull in a filesystem-specific devel
> package for that. Having a library is fine, but please move the library
> into util-linux so it's always available without another dependency. That
> way xfsprogs could for example drop it's own detection library aswell.

I totally agree with Christophe, this dependency is a complete
pain for trying to do util-linux-ng development. I meant to
complain about this myself.

> > The package build system is now based on autotools. The build system
> > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > SUID_LDFLAGS). For more details see the README file
>
> And this is really dumb. autotools is a completely pain in the ass and
> not useful at all for linux-only tools.

I second this sentiment as well. It's not like we expect this stuff
to get used on other systems at all, and the only thing it's getting
used for really is to detect the awful external blkid/volume_id
dependencies.

I totally think this stuff can and should be completely eliminated.

[Jan Engelhardt]

On Jul 4 2007 00:11, Karel Zak wrote:
>newgrp:
> add support for /etc/gshadow
> check result from getgrnam() more carefully

Hm, gshadow looks like it is really obsolete. (There is no such file anymore in
suse releases since a long while. Previously, gshadow was filled with all the
groups that existed.)

Jan
--

[DervishD]

Hi Karel :)

* Karel Zak <kz...@redhat.com> dixit:

> The package build system is now based on autotools. The build system
> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> SUID_LDFLAGS). For more details see the README file

If you want to have configurable installation directories and
configurable settings for building but with the pain of autotools, you
can give "mobs" a try if you want. You will find in my homepage (see my
signature below). If you find it so much big and/or you think you will
be changing a pain for another pain, I can help porting.

Anyway, if you don't like mobs or you just don't want to try it,
that's fine, but please don't use autotools, it doesn't make much sense
for a linux only project, since you will be using only the "directory
choosing" part of autotools. Maybe a hand made script will help (and I
can help with that, too) if you just want to have selectable directories
and CFLAGS support...

And thanks for util-linux-ng, I was waiting for them :))

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

[Nix]

On 4 Jul 2007, DervishD stated:

> Anyway, if you don't like mobs or you just don't want to try it,
> that's fine, but please don't use autotools, it doesn't make much sense
> for a linux only project, since you will be using only the "directory
> choosing" part of autotools. Maybe a hand made script will help (and I

Oh, yeah, great, another hand-rolled build system. That's *juwt* what
those of us who have autotools working well (with config.site's that
do all we need and then some) are looking forward to.

There are advantages to standardization, you know. A *lot* of
autobuilders know how to make autoconf-generated configure scripts jump
through hoops. I was downright *happy* when util-linux was
autoconfiscated: I could ditch the code to handle automatic
configuration of yet another one-package hand-rolled build system.

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

[Bodo Eggert]

Nix <n...@esperi.org.uk> wrote:
> On 4 Jul 2007, DervishD stated:

>> Anyway, if you don't like mobs or you just don't want to try it,
>> that's fine, but please don't use autotools, it doesn't make much sense
>> for a linux only project, since you will be using only the "directory
>> choosing" part of autotools. Maybe a hand made script will help (and I
>
> Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> those of us who have autotools working well (with config.site's that
> do all we need and then some) are looking forward to.
>
> There are advantages to standardization, you know. A *lot* of
> autobuilders know how to make autoconf-generated configure scripts jump
> through hoops. I was downright *happy* when util-linux was
> autoconfiscated: I could ditch the code to handle automatic
> configuration of yet another one-package hand-rolled build system.

Standardisation is good, but autotools (as they are used) usurally isn't. It
tests for the availability of a fortran compiler for a C-only project, checks
the width of integers on i386 for projects not caring about that and fails to
find installed libraries without telling how it was supposed to find them or
how to make it find that library.

Configuring the build of an autotools program is harder than nescensary;
if it used a config file, you could easily save it somewhere while adding
comments on how and why you did *that* choice, and you could possibly
use a set of default configs which you'd just include.

The Makefiles generated by autotools is a huge mess, if autotools got it
wrong (again!), fixing them requires editing a lot of files.

I'm really really happy if I read 'edit Makefile.conf and run make...'.
--
No matter which way you have to march, its always uphill.

Friß, Spammer: n...@kqYYs.7eggert.dyndns.org mlyg...@d.7eggert.dyndns.org
cDm...@z-luqs.7eggert.dyndns.org .-@IfuiUgj.7eggert.dyndns.org

[H. Peter Anvin]

Jan Engelhardt wrote:
> On Jul 4 2007 00:11, Karel Zak wrote:
>> newgrp:
>> add support for /etc/gshadow
>> check result from getgrnam() more carefully
>
> Hm, gshadow looks like it is really obsolete. (There is no such file anymore in
> suse releases since a long while. Previously, gshadow was filled with all the
> groups that existed.)
>

gshadow is used when you have groups which have passwords, which is very
rare in practice but permitted in theory.

-hpa

[Andreas Dilger]

On Jul 05, 2007 12:41 -0400, Mike Frysinger wrote:

> On Wednesday 04 July 2007, Christoph Hellwig wrote:
> > Sorry, but it's really annoying to pull in a filesystem-specific devel
> > package for that. Having a library is fine, but please move the library
> > into util-linux so it's always available without another dependency.
>

> ugh, moving libraries which are already actively maintained by other core
> projects into util-linux is so not a good idea (ignoring the fact that it'd
> easily be a pita/waste for distro maintainers)

Some distros (Debian and SuSE I think) split the e2fsprogs libraries
into separate packages so that you are not depending on "e2fsprogs",
but rather "libuuid" and/or "libblkid".

> > That way xfsprogs could for example drop it's own detection library aswell.
>

> i dont really think this is dependent on util-linux at all. nothing is
> stopping xfsprogs from depending on udev or e2fsprogs now.

In fact, Eric Sandeen and I discussed splitting the xfsprogs "libdisk"
(or similar, it detects RAID geometry for DM/MD/etc) into a standalone
library so that e2fsprogs could use it. The only issue is the increased
maintenance and packaging of separate libraries.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

[DervishD]

Hi Bodo :)

* Bodo Eggert <7eg...@gmx.de> dixit:

> Nix <n...@esperi.org.uk> wrote:
> > On 4 Jul 2007, DervishD stated:
> >> Anyway, if you don't like mobs or you just don't want to try it,
> >> that's fine, but please don't use autotools, it doesn't make much sense
> >> for a linux only project, since you will be using only the "directory
> >> choosing" part of autotools. Maybe a hand made script will help (and I
> >
> > Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> > those of us who have autotools working well (with config.site's that
> > do all we need and then some) are looking forward to.
> >
> > There are advantages to standardization, you know. A *lot* of
> > autobuilders know how to make autoconf-generated configure scripts jump
> > through hoops. I was downright *happy* when util-linux was
> > autoconfiscated: I could ditch the code to handle automatic
> > configuration of yet another one-package hand-rolled build system.
>
> Standardisation is good, but autotools (as they are used) usurally isn't.

Usually, by picking other's project configure.in and tweak blindly.

> It tests for the availability of a fortran compiler for a C-only
> project, checks the width of integers on i386 for projects not caring
> about that and fails to find installed libraries without telling how
> it was supposed to find them or how to make it find that library.

My favourite is when the project doesn't honor --*dir options. Or
when the project breaks badly if you put some files in different places
by using configure options... That's good standarization.

> Configuring the build of an autotools program is harder than nescensary;
> if it used a config file, you could easily save it somewhere while adding
> comments on how and why you did *that* choice, and you could possibly
> use a set of default configs which you'd just include.

Looks like CMake...

> I'm really really happy if I read 'edit Makefile.conf and run make...'.

Again, this looks like CMake...

I share your view entirely.

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

[Nix]

On 5 Jul 2007, Bodo Eggert outgrape:

> I'm really really happy if I read 'edit Makefile.conf and run make...'.

autobuild scripts find it a hell of a lot more annoying to edit a different
makefile for every project than to run one unchanging config.site...

It's hardly a killer, but it would be a step backwards IMO :( by all
means switch to a nicer build system: cmake, perhaps? but ditching
standardized build systems entirely is not so good.

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

[Nix]

On 5 Jul 2007, DervishD spake thusly:

> * Bodo Eggert <7eg...@gmx.de> dixit:

>> Standardisation is good, but autotools (as they are used) usurally isn't.
>
> Usually, by picking other's project configure.in and tweak blindly.

You'd think they'd never heard of autoscan...

> My favourite is when the project doesn't honor --*dir options. Or
> when the project breaks badly if you put some files in different places
> by using configure options... That's good standarization.

That's a broken project, I'd say. But you have a point, which is that
autoconf does too little, and automake plugs the gaps badly (and let's
not even talk about the abomination which is libtool).

>> Configuring the build of an autotools program is harder than nescensary;
>> if it used a config file, you could easily save it somewhere while adding
>> comments on how and why you did *that* choice, and you could possibly
>> use a set of default configs which you'd just include.
>
> Looks like CMake...

That's cool :) thanks to KDE using it everyone's autobuilders are having
to adapt to cmake anyway, and it's not hard and you only have to do it
once.

>> I'm really really happy if I read 'edit Makefile.conf and run make...'.
>
> Again, this looks like CMake...

:)

My only real grouch with cmake is that the authors have invented a
language with so bloody many capital letters in it. Looking at cmake
macros makes my eyes bleed even more badly than looking at the mass of
involuted nested brackets in configure.ac's, and that's a difficult
thing to do. (It's less portable than autoconf-generated configure
scripts but most of autoconf's portability tests are for long-dead
systems anyway, and as you said util-linux of all projects doesn't give
a damn. I don't really care if software isn't portable to an Interactive
box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.)

There's a good reason most text is lowercase. Even Lisp moved to
lowercase a long time ago...

[Bernhard Walle]

* Nix <n...@esperi.org.uk> [2007-07-05 22:42]:

>
> My only real grouch with cmake is that the authors have invented a
> language with so bloody many capital letters in it.

The real problem I see with cmake is that you need to have cmake
installed on the build system. While cmake itself isn't the problem,
often, it also depends on the version of cmake that is installed. The
good idea about auto* tools is the idea that you don't need to install
any tools to build, just to develop. A POSIX shell and Perl should be
installed everywhere ...

Maybe the problem becomes less important in a few years if everyone
has cmake installed and it's more "stable" in terms of adding new
features.

Thanks,
Bernhard

[Karel Zak]

On Thu, Jul 05, 2007 at 12:41:59PM -0400, Mike Frysinger wrote:
> On Wednesday 04 July 2007, Christoph Hellwig wrote:

> > On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > > mount(8) doesn't include filesystem detection code anymore. You
> > > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > > (e2fsprogs) or libvolume_id (udev >= v110) is required.
> >
> > Sorry, but it's really annoying to pull in a filesystem-specific devel
> > package for that. Having a library is fine, but please move the library
> > into util-linux so it's always available without another dependency.
>

> ugh, moving libraries which are already actively maintained by other core
> projects into util-linux is so not a good idea (ignoring the fact that it'd
> easily be a pita/waste for distro maintainers)

Yes. We have good experience with libblkid and libvolume_id. This
concept is nothing new (see current RHEL, FC, Suse, ...). The change
is that we've removed old, useless and unmaintained FS detection code
from util-linux.

I think move the library to util-linux is really bad idea. A better
idea is detach libblkid or libvolume_id (or both) from e2fsprogs/udev
and create an independent libfsprobe library and use everywhere
(e2fsprogs, udev, util-linux) this library only.

> > > The package build system is now based on autotools. The build system
> > > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > > SUID_LDFLAGS). For more details see the README file
> >
> > And this is really dumb. autotools is a completely pain in the ass and

Well, Adrian Bunk added autotools stuff to util-linux during his work
on v2.13. This stuff has been fixed and stabilized in util-linux-ng
v2.13.

I'm not fanatical autotools protagonist, but it seems useful in
util-linux. We will see...

I'm ready to change or fix arbitrary thing in util-linux-ng, but I
always need a real reason -- bug report, new feature, or so. This
discussion is about impressions and feelings only.

> > not useful at all for linux-only tools.
>

> incorrect. linux changes over time as does the kernel/libc/architecture
> api's. look at the old util-linux build system -- it had a crappy hand
> written configure script to try and detect all these different issues.

Right. The autotools provides more features that portability only.

Karel

--
Karel Zak <kz...@redhat.com>

[Nix]

On 5 Jul 2007, Mike Frysinger outgrape:

> On Thursday 05 July 2007, Bodo Eggert wrote:
>> The Makefiles generated by autotools is a huge mess, if autotools got it
>> wrong (again!), fixing them requires editing a lot of files.
>

> this looks like a no brainer to me: dont edit generated files

There is a worthwhile point here: if your input to the makefile
generator is buggy and make errors out, you'll have to look at the
generated code in order to relate the make error to the original.

(It's not that hard with automake, admittedly, but make should
really have a #line analogue to help. It could be much worse, as
anyone who ever tried to use Knuth's old WEAVE tool would know.
At least automake doesn't intentionally obfuscate the makefiles
it emits...)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

[Jeff Garzik]

Christoph Hellwig wrote:
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
>> The package build system is now based on autotools. The build system
>> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
>> SUID_LDFLAGS). For more details see the README file
>
> And this is really dumb. autotools is a completely pain in the ass and
> not useful at all for linux-only tools.

A myth. It is quite useful for packagers, because of the high Just
Works(tm) factor. After porting an entire across several revisions of a
distro, the autotools-based packages are the ones that work out of the
box 90% of the time.

The other 90% of _my_ time comes from annoying people who roll their own
Makefile/build solution, which the packager has to then learn.

It's just not scalable for people to keep building their own build
solutions.

Jeff

[Bryan Henderson]

>i dont see how blaming autotools for other people's misuse is relevant

Here's how other people's misuse of the tool can be relevant to the choice
of the tool: some tools are easier to use right than others. Probably the
easiest thing to use right is the system you designed and built yourself.
I've considered distributing code with an Autotools-based build system
before and determined quickly that I am not up to that challenge. (The
bigger part of the challenge isn't writing the original input files; it's
debugging when a user says his build doesn't work). But as far as I know,
my hand-rolled build system is used correctly by me.

>> checks the width of integers on i386 for projects not caring about that
and
>> fails to find installed libraries without telling how it was supposed
to
>> find them or how to make it find that library.
>

>no idea what this rant is about.

The second part sounds like my number 1 complaint as a user of
Autotools-based packages: 'configure' often can't find my libraries. I
know exactly where they are, and even what compiler and linker options are
needed to use them, but it often takes a half hour of tracing 'configure'
or generated make files to figure out how to force the build to understand
the same thing. And that's with lots of experience. The first five times
it was much more frustrating.

>> Configuring the build of an autotools program is harder than
nescensary;
>> if it used a config file, you could easily save it somewhere while
adding
>> comments on how and why you did *that* choice, and you could possibly
>> use a set of default configs which you'd just include.
>

>history shows this is a pita to maintain. every package has its own
build
>system and configuration file ...

It's my understanding that autotools _does_ provide that ability (as
stated, though I think "config file" may have been meant here as
"config.make"). The config file is a shell script that contains a
'configure' command with a pile of options on it, and as many comments as
you want, to tailor the build to your requirements.

[Matthew Wilcox]

On Thu, Jul 05, 2007 at 11:30:20PM +0200, Karel Zak wrote:
> > > > The package build system is now based on autotools. The build system
> > > > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > > > SUID_LDFLAGS). For more details see the README file
> > >
> > > And this is really dumb. autotools is a completely pain in the ass and
>
> Well, Adrian Bunk added autotools stuff to util-linux during his work
> on v2.13. This stuff has been fixed and stabilized in util-linux-ng
> v2.13.
>
> I'm not fanatical autotools protagonist, but it seems useful in
> util-linux. We will see...
>
> I'm ready to change or fix arbitrary thing in util-linux-ng, but I
> always need a real reason -- bug report, new feature, or so. This
> discussion is about impressions and feelings only.

No, it's based on long, hard and painful experiences attempting to debug
the fuckups that autoconf creates when it goes wrong.

--
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

[DervishD]

Hi Nix :)

* Nix <n...@esperi.org.uk> dixit:

> On 5 Jul 2007, DervishD spake thusly:

> >> Configuring the build of an autotools program is harder than nescensary;
> >> if it used a config file, you could easily save it somewhere while adding
> >> comments on how and why you did *that* choice, and you could possibly
> >> use a set of default configs which you'd just include.
> >
> > Looks like CMake...
>
> That's cool :) thanks to KDE using it everyone's autobuilders are having
> to adapt to cmake anyway, and it's not hard and you only have to do it
> once.

I really like the spirit of CMake. Of course, it adds a dependency,
but IMHO is much safer to depend on CMake being installed (or Perl, for
that matter) than to depend on a shell. Every shell out there seems to
do things on its own, and apart from dash, which is more or less
standard, the rest of shells do actually violate the standard one way or
another (in fact, configure script include workarounds for at least Bash
and Zsh).

> My only real grouch with cmake is that the authors have invented a
> language with so bloody many capital letters in it. Looking at cmake
> macros makes my eyes bleed even more badly than looking at the mass of
> involuted nested brackets in configure.ac's, and that's a difficult
> thing to do. (It's less portable than autoconf-generated configure
> scripts but most of autoconf's portability tests are for long-dead
> systems anyway, and as you said util-linux of all projects doesn't give
> a damn. I don't really care if software isn't portable to an Interactive
> box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.)
>
> There's a good reason most text is lowercase. Even Lisp moved to
> lowercase a long time ago...

Well, that's nothing that a good editor can't solve. You can
configure VIM to lowercase your CMakelist while you edit, and uppercase
it afterwards. And yes, I also thing that's a bad idea and eyes hurt
badly when reading uppercase. Maybe it's not too late to change it ;)

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

[Nix]

On 5 Jul 2007, Bernhard Walle stated:

> * Nix <n...@esperi.org.uk> [2007-07-05 22:42]:
>>
>> My only real grouch with cmake is that the authors have invented a
>> language with so bloody many capital letters in it.
>
> The real problem I see with cmake is that you need to have cmake
> installed on the build system.

I don't see that as being very much more of a problem than having make
installed (except of course that make is defined by POSIX and cmake is
not). The real problem is that nearly all the cmake macros are shipped
with cmake itself, so version-dependent scripts are more common, and
instead of being hit with `you need at least this version of GNU make,
released in 1998' you're likely to get hit with `you need at least this
version of cmake, released three months ago' which is more likely to
annoy the poor users.

> While cmake itself isn't the problem,
> often, it also depends on the version of cmake that is installed. The
> good idea about auto* tools is the idea that you don't need to install
> any tools to build, just to develop. A POSIX shell and Perl should be
> installed everywhere ...

You don't need Perl to run configure scripts, either, and it's only
recently that it started requiring a POSIX shell rather than something
of the calibre of Solaris's /bin/sh.

(But I'm spamming this list so I'll shut up now.)

[Gerd Hoffmann]

Jeff Garzik wrote:

> Christoph Hellwig wrote:
>> And this is really dumb. autotools is a completely pain in the ass and
>> not useful at all for linux-only tools.
>
> A myth. It is quite useful for packagers, because of the high Just
> Works(tm) factor. After porting an entire across several revisions of a
> distro, the autotools-based packages are the ones that work out of the
> box 90% of the time.

And the 10% where it doesn't work it is a real pain to figure what goes
wrong due to the completely unreadable Makefiles generated by autotools.
After all they are not Makefiles, they are shellscripts embedded into
Makefiles.

> The other 90% of _my_ time comes from annoying people who roll their own
> Makefile/build solution, which the packager has to then learn.

Well, it's not *that* hard to write makefiles which follow the usual
gnuish conventions, so stuff like "make DESTDIR=/tmp/buildroot install"
works just fine. That isn't a reason to use autotools. Especially as
people get that wrong *even with* autotools from time to time ...

cheers,

Gerd

[Jeff Garzik]

Gerd Hoffmann wrote:
> Jeff Garzik wrote:
>> Christoph Hellwig wrote:
>>> And this is really dumb. autotools is a completely pain in the ass and
>>> not useful at all for linux-only tools.
>> A myth. It is quite useful for packagers, because of the high Just
>> Works(tm) factor. After porting an entire across several revisions of a
>> distro, the autotools-based packages are the ones that work out of the
>> box 90% of the time.
>
> And the 10% where it doesn't work it is a real pain to figure what goes
> wrong due to the completely unreadable Makefiles generated by autotools.
> After all they are not Makefiles, they are shellscripts embedded into
> Makefiles.
>
>> The other 90% of _my_ time comes from annoying people who roll their own
>> Makefile/build solution, which the packager has to then learn.
>
> Well, it's not *that* hard to write makefiles which follow the usual
> gnuish conventions, so stuff like "make DESTDIR=/tmp/buildroot install"
> works just fine. That isn't a reason to use autotools. Especially as
> people get that wrong *even with* autotools from time to time ...

It's not _just_ makefiles, though. Packaging systems know what to do
with configure scripts, and automatically plug that into their systems,
e.g. with rpm's %configure, %make_install, etc.

Having ported an entire distro, the time savings with autotools [OR
ANOTHER STANDARD BUILD/CONFIGURE SYSTEM] are very real. Similarly, the
time sink with each project doing its own home-rolled build/configure
system is also very real.

Jeff

[DervishD]

Hi Mike :)

* Mike Frysinger <vap...@gentoo.org> dixit:

> On Friday 06 July 2007, DervishD wrote:
> > I really like the spirit of CMake. Of course, it adds a dependency,
> > but IMHO is much safer to depend on CMake being installed (or Perl, for
> > that matter) than to depend on a shell. Every shell out there seems to
> > do things on its own, and apart from dash, which is more or less
> > standard, the rest of shells do actually violate the standard one way or
> > another (in fact, configure script include workarounds for at least Bash
> > and Zsh).
>

> careful, you tread into dangerous territory making silly statements like that.
> by "standard" you probably mean "POSIX standard" which dash too has had
> plenty of bugs in terms of implementing it properly (and still does).

Probably, I haven't carried thoroughly tests, but up to date, it's
the most POSIX compliant shell I've found. Probably dash is crappy too,
regarding POSIX compliance, but that only reinforces my point: depending
on shells is less safe than depending on CMake.

> and claiming that it's safer to depend on CMake
> than bash in this Linux world is just plain bogus.

Probably. I didn't claim that, anyway. I said "shell" and not
"Bash". Depending on a C program is safer, IMHO, than depending on the
features of an unknown shell. And FWIW, /bin/sh can be *any* shell on
*any* system where autotools run.

And yes, I have bash installed on my system because some people
insist in writing bash scripts while asking for "#!/bin/sh". That's
bogus.

[Bodo Eggert]

On Thu, 5 Jul 2007, DervishD wrote:
> * Bodo Eggert <7eg...@gmx.de> dixit:

> > Standardisation is good, but autotools (as they are used) usurally isn't.

>
> Usually, by picking other's project configure.in and tweak blindly.

If it were that easy to write a correct automake script, people would do
that. Wouldn't they?

> > Configuring the build of an autotools program is harder than nescensary;
> > if it used a config file, you could easily save it somewhere while adding
> > comments on how and why you did *that* choice, and you could possibly
> > use a set of default configs which you'd just include.
>
> Looks like CMake...

Obviously something I should look at.
--
Top 100 things you don't want the sysadmin to say:
45. Was that YOUR directory?

[DervishD]

Hi Bodo :)

* Bodo Eggert <7eg...@gmx.de> dixit:
> On Thu, 5 Jul 2007, DervishD wrote:
> > * Bodo Eggert <7eg...@gmx.de> dixit:
>
> > > Standardisation is good, but autotools (as they are used) usurally isn't.
> >
> > Usually, by picking other's project configure.in and tweak blindly.
>
> If it were that easy to write a correct automake script, people would do
> that. Wouldn't they?

That's exactly what I meant! People don't write good autotools
scripts because it's difficult to learn autoconf and automake and it's
almost impossible to master. It's more or less easy to write an autoconf
script, but it's not so easy to make it right, powerful and to honor
every configure switch, etc...

> > > Configuring the build of an autotools program is harder than nescensary;
> > > if it used a config file, you could easily save it somewhere while adding
> > > comments on how and why you did *that* choice, and you could possibly
> > > use a set of default configs which you'd just include.
> >
> > Looks like CMake...
>
> Obviously something I should look at.

Me too. I've learned a bit of CMake because I have my own building
system ("configure" compatible from the point of view of the packager),
but instead of adding new features I think I'm going to switch to CMake
fully.

Raúl Núñez de Arenas Coronado

--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

[Bryan Henderson]

>the
>maintainers of util-linux have well versed autotool people at their
disposal,
>so i really dont see this as being worrisome.

As long as that is true, I agree that the fact that so many autotool
packages don't work well is irrelevant.

However, I think the difficulty of using autotools (I mean using by
packagers), as evidenced by all the people who get it wrong, justifies
people being skeptical that util-linux really has that expertise
available. Also, many open source projects are developed by a large
diverse group of people, so even if there exist people who can do the
autotools right, it doesn't mean they'll be done right.

One reason I try to minimize the number of tools/skills used in
maintaining packages I distribute is to enable a larger group of people to
help me maintain them.

[Joel Becker]

On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
> And the 10% where it doesn't work it is a real pain to figure what goes
> wrong due to the completely unreadable Makefiles generated by autotools.
> After all they are not Makefiles, they are shellscripts embedded into
> Makefiles.

Do not mistake the use of autoconf with automake. automake
generates the unreadable Makefiles. You can quite easily create a
useful Makefile yourself and use autoconf to select installation
locations, detect features of older/newer libcs, etc. See
http://oss.oracle.com/projects/makebo/ for an example of a build system
that doesn't use automake, but allows for autoconf to do build-time
configuration (an example user of makebo is ocfs2-tools, see
http://oss.oracle.com/projects/ocfs2-tools/src/trunk/).
And if you think that all packages should Just Work on all
Linuxen, with out any build-time detection, try determining the
differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.
Or where manpages go. The %configure of RPM specfiles and the
dh_installman of debian packages handle this for you...often because
they can use expected behavior of your build system. What about
futexes? Older systems don't have them. Gotta detect that.

Joel

--

"I'm drifting and drifting
Just like a ship out on the sea.
Cause I ain't got nobody, baby,
In this world to care for me."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel....@oracle.com
Phone: (650) 506-8127

[Nix]

On 6 Jul 2007, Mike Frysinger spake thusly:

> On Friday 06 July 2007, Nix wrote:
>> On 5 Jul 2007, Bernhard Walle stated:

>> > While cmake itself isn't the problem,
>> > often, it also depends on the version of cmake that is installed. The
>> > good idea about auto* tools is the idea that you don't need to install
>> > any tools to build, just to develop. A POSIX shell and Perl should be
>> > installed everywhere ...
>>
>> You don't need Perl to run configure scripts, either, and it's only
>> recently that it started requiring a POSIX shell rather than something
>> of the calibre of Solaris's /bin/sh.
>

> since when does autotools require a POSIX shell ?

autoconf 2.55's NEWS said:

,----
| - shell functions
|
| Shell functions will gradually be introduced, probably starting with
| Autotest. If you know machines which are in use that you suspect
| *not* to support shell functions, please run the test suite of
| Autoconf 2.55 on it, and report the results to
| bug-au...@gnu.org.
`----

but actually I'm not sure if this was ever done. That's not actually `a
POSIX shell' I suppose, but it's also not going to work on prehistoric
shells like Solaris's 1980-vintage /bin/sh.

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

[Gerd Hoffmann]

Joel Becker wrote:
> On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
>> And the 10% where it doesn't work it is a real pain to figure what goes
>> wrong due to the completely unreadable Makefiles generated by autotools.
>> After all they are not Makefiles, they are shellscripts embedded into
>> Makefiles.
>
> Do not mistake the use of autoconf with automake. automake
> generates the unreadable Makefiles. You can quite easily create a
> useful Makefile yourself and use autoconf to select installation
> locations, detect features of older/newer libcs, etc.

Sure. I have some projects using autoconf only. 90% of the projects
use both though, autoconf-only is quite rare these days (used to be
different because autoconf was the first ...).

> And if you think that all packages should Just Work on all
> Linuxen, with out any build-time detection, try determining the
> differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.

s/build/run/ time check IMHO. Otherwise things blow up if the user
upgrades fc6 to 7 ...

> Or where manpages go.

/usr/share/man everythere, since years. Maybe except Debian because
they first discuss 5 years how to handle that ;)

> What about
> futexes? Older systems don't have them. Gotta detect that.

Sure, there are some things left you might want to check for even for
linux-only projects. If it is only whenever some library is installed.
autoconf will do that, sure. It's still quite some overkill in many
cases IMHO. On smaller projects the configure script can easily take
more than 80% of the tarball size ...

cheers,
Gerd