Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Monday 09 July 2007, Gerd Hoffmann wrote: > Joel Becker wrote: > > 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 ... API's change, ABI's dont -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 | [EMAIL PROTECTED] ` 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :)
* Bodo Eggert <[EMAIL PROTECTED]> dixit:
> On Thu, 5 Jul 2007, DervishD wrote:
> > * Bodo Eggert <[EMAIL PROTECTED]> 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!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Thu, 5 Jul 2007, DervishD wrote: > * Bodo Eggert <[EMAIL PROTECTED]> 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Mike :) * Mike Frysinger <[EMAIL PROTECTED]> 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. 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 ? -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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). as for the workarounds you allude to, autotools is designed to be portable everywhere which means including workarounds for random bugs in major releases of operating systems. just because autotools lacks workarounds for bugs found in random versions of dash does not make dash magical. there is also the fact that autotools works on systems that predate POSIX or lack shells which support POSIX. and claiming that it's safer to depend on CMake than bash in this Linux world is just plain bogus. -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On 5 Jul 2007, Bernhard Walle stated: > * Nix <[EMAIL PROTECTED]> [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.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Nix :) * Nix <[EMAIL PROTECTED]> 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Thursday 05 July 2007, Bryan Henderson wrote: > >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. which brings us back to the package maintainer maintains the autotool source files, not joe blow user. if there's trouble with the build system, then the maintainers (who are knowledgeable in autotools) are in a pretty easy position to fix/address it. as you've stated, hand rolled build systems work great for the guy rolling it, but beyond that all bets are off. util-linux had a hand rolled build system that fell apart in many places. the maintainers of util-linux have well versed autotool people at their disposal, so i really dont see this as being worrisome. > > > 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. the large majority of time, i find this to be trivial: read config.log. but this comes with familiarity with the tool and autotools is sitting by far the best right now. if you're having trouble with the package in question, just ask on the mailing list and post your config.log; i'm sure you'd get someone to readily point out the answer. -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Thursday 05 July 2007, Nix wrote: > 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. granted, this can be a pain (ive spent an annoying amount of time tracking down unbalanced quotes/parens/etc... by trying to correlate configure.ac with configure), but i dont feel like this is a autotool-specific issue as it can come up with other auto-build-generators as well. heck, a minor typo in a hand written makefile can sometimes be a time sink and hard to trace back (just look at linux kernel makefiles). -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Thursday 05 July 2007, Bodo Eggert wrote: > Nix <[EMAIL PROTECTED]> 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. i dont see how blaming autotools for other people's misuse is relevant ... this same exact claim could be made for just about any other build system, simply apply 's/autotools/$some_build_system_you_wish_to_complain/'. > It tests for the availability of a fortran compiler for a C-only project a libtool bug that has been fixed upstream and is trivial to work around ... you could also point out that libtool will also search for a C++ compiler in a C-only project. the libtool stuff can probably be easily cleaned out from util-linux completely thus negating this whole topic. > 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. > 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 which means you have to go through the documentation and figure out the magic incantation to get the thing to build up the way you need. > 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 -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
* Nix <[EMAIL PROTECTED]> [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On 5 Jul 2007, DervishD spake thusly: > * Bodo Eggert <[EMAIL PROTECTED]> 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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :) * Bodo Eggert <[EMAIL PROTECTED]> dixit: > Nix <[EMAIL PROTECTED]> 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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)
> 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.
> > 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 really at all. hand written build systems are a constant source of pain
for distribution maintainers and people trying to cross-compile (and the one
that was in util-linux had many problems in both these areas).
> 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.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Nix <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Karel :) * Karel Zak <[EMAIL PROTECTED]> 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
From: Christoph Hellwig <[EMAIL PROTECTED]>
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] util-linux-ng 2.13-rc1
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 SieversStepan 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= 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_no
