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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm/fs meetup details
On Thu, Jul 05, 2007 at 05:40:57PM -0400, Rik van Riel wrote: > David Chinner wrote: > >On Thu, Jul 05, 2007 at 01:40:08PM -0700, Zach Brown wrote: > >>>- repair driven design, we know what it is (Val told us), but > >>> how does it apply to the things we are currently working on? > >>> should we do more of it? > >>I'm sure Chris and I could talk about the design elements in btrfs > >>that should aid repair if folks are interested in hearing about > >>them. We'd keep the hand-waving to a minimum :). > > > >And I'm sure I could provide a counterpoint by talking about > >the techniques we've used improving XFS repair speed and > >scalability without needing to change any on disk formats > > Sounds like that could be an interesting discussion. > > Especially when trying to answer questions like: > > "At what filesystem size will the mitigating fixes no > longer be enough?" > > and > > "When will people start using filesystems THAT big?" :) Keep in mind that the way to get the most out of this meeting is for the fs people to have topics of the form "we'd really like to do X, can we get some help from the VM"? Or vice versa from vm people. That said, we can talk about whatever interests the group on the day. And that could definitely include issues common to different filesystems. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm/fs meetup details
On Thu, Jul 05, 2007 at 01:54:06PM -0400, Rik van Riel wrote: > Nick Piggin wrote: > >Hi, > > > >The vm/fs meetup will be held September 4th from 10am till 4pm (with the > >option of going longer), at the University of Cambridge. > > I am interested. A few potential topics: OK, I'll put you on the list. Hope to see you there. > - improving laptop_mode in the VFS & VM to further increase > battery life in laptops > > - repair driven design, we know what it is (Val told us), but > how does it apply to the things we are currently working on? > should we do more of it? Thanks for the suggestions. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/26] sys_mknodat(): elevate write count for vfs_mknod/create()
On Sat, 2007-06-30 at 10:39 +0100, Christoph Hellwig wrote:
> On Mon, Jun 25, 2007 at 08:19:52AM -0700, Dave Hansen wrote:
> > > Should we just take the calls outside the switch statement?
> >
> > Yeah, that's much better. I assume we don't care whether we're getting
> > -EROFS or -EPERM/-EINVAL for the S_IFDIR and default cases?
>
> We need to keep the exact error returns, so you'll have to add some
> special case checks before the r/o check. It's probably still cleaner,
> though.
How does this (untested) patch look?
--
This takes care of all of the direct callers of vfs_mknod().
Since a few of these cases also handle normal file creation
as well, this also covers some calls to vfs_create().
So that we don't have to make three mnt_want/drop_write()
calls inside of the switch statement, we move some of its
logic outside of the switch.
One thing I noticed: do we actually _need_ the first
S_ISDIR() check at the top of the function?
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/namei.c | 29 -
lxc-dave/fs/nfsd/vfs.c |8 ++--
lxc-dave/net/unix/af_unix.c |4
3 files changed, 30 insertions(+), 11 deletions(-)
diff -puN fs/namei.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
fs/namei.c
--- lxc/fs/namei.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
2007-07-05 15:40:18.0 -0700
+++ lxc-dave/fs/namei.c 2007-07-05 15:40:26.0 -0700
@@ -1911,13 +1911,27 @@ asmlinkage long sys_mknodat(int dfd, con
error = do_path_lookup(dfd, tmp, LOOKUP_PARENT, &nd);
if (error)
goto out;
+
dentry = lookup_create(&nd, 0);
error = PTR_ERR(dentry);
+ if (error)
+ goto out_unlock;
if (!IS_POSIXACL(nd.dentry->d_inode))
mode &= ~current->fs->umask;
- if (!IS_ERR(dentry)) {
- switch (mode & S_IFMT) {
+ if (S_ISDIR(mode)) {
+ error = -EPERM;
+ goto out_dput;
+ }
+ if (!S_ISREG(mode) && !S_ISCHR(mode) && !S_ISBLK(mode) &&
+ !S_ISFIFO(mode) && !S_ISSOCK(mode) && (mode != 0)) {
+ error = -EINVAL;
+ goto out_dput;
+ }
+ error = mnt_want_write(nd.mnt);
+ if (error)
+ goto out_dput;
+ switch (mode & S_IFMT) {
case 0: case S_IFREG:
error = vfs_create(nd.dentry->d_inode,dentry,mode,&nd);
break;
@@ -1928,14 +1942,11 @@ asmlinkage long sys_mknodat(int dfd, con
case S_IFIFO: case S_IFSOCK:
error = vfs_mknod(nd.dentry->d_inode,dentry,mode,0);
break;
- case S_IFDIR:
- error = -EPERM;
- break;
- default:
- error = -EINVAL;
- }
- dput(dentry);
}
+ mnt_drop_write(nd.mnt);
+out_dput:
+ dput(dentry);
+out_unlock:
mutex_unlock(&nd.dentry->d_inode->i_mutex);
path_release(&nd);
out:
diff -puN
fs/nfsd/vfs.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
fs/nfsd/vfs.c
---
lxc/fs/nfsd/vfs.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
2007-07-05 15:40:18.0 -0700
+++ lxc-dave/fs/nfsd/vfs.c 2007-07-05 15:40:18.0 -0700
@@ -1199,7 +1199,11 @@ nfsd_create(struct svc_rqst *rqstp, stru
case S_IFBLK:
case S_IFIFO:
case S_IFSOCK:
+ host_err = mnt_want_write(fhp->fh_export->ex_mnt);
+ if (host_err)
+ break;
host_err = vfs_mknod(dirp, dchild, iap->ia_mode, rdev);
+ mnt_drop_write(fhp->fh_export->ex_mnt);
break;
default:
printk("nfsd: bad file type %o in nfsd_create\n", type);
@@ -1810,7 +1814,7 @@ nfsd_permission(struct svc_export *exp,
inode->i_mode,
IS_IMMUTABLE(inode)?" immut" : "",
IS_APPEND(inode)? " append" : "",
- __mnt_is_readonly(exp->mnt)?" ro" : "");
+ __mnt_is_readonly(exp->ex_mnt)? " ro" : "");
dprintk(" owner %d/%d user %d/%d\n",
inode->i_uid, inode->i_gid, current->fsuid, current->fsgid);
#endif
@@ -1821,7 +1825,7 @@ nfsd_permission(struct svc_export *exp,
*/
if (!(acc & MAY_LOCAL_ACCESS))
if (acc & (MAY_WRITE | MAY_SATTR | MAY_TRUNC)) {
- if (EX_RDONLY(exp) || __mnt_is_readonly(exp->mnt))
+ if (EX_RDONLY(exp) || __mnt_is_readonly(exp->ex_mnt))
return nfserr_rofs;
if (/* (acc & MAY_WRITE) && */ IS_IMMUTABLE(inode))
return nfserr_perm;
diff -puN
net/unix/af_unix.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
net/unix/
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: vm/fs meetup details
David Chinner wrote: On Thu, Jul 05, 2007 at 01:40:08PM -0700, Zach Brown wrote: - repair driven design, we know what it is (Val told us), but how does it apply to the things we are currently working on? should we do more of it? I'm sure Chris and I could talk about the design elements in btrfs that should aid repair if folks are interested in hearing about them. We'd keep the hand-waving to a minimum :). And I'm sure I could provide a counterpoint by talking about the techniques we've used improving XFS repair speed and scalability without needing to change any on disk formats Sounds like that could be an interesting discussion. Especially when trying to answer questions like: "At what filesystem size will the mitigating fixes no longer be enough?" and "When will people start using filesystems THAT big?" :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm/fs meetup details
On Thu, Jul 05, 2007 at 01:40:08PM -0700, Zach Brown wrote: > >- repair driven design, we know what it is (Val told us), but > > how does it apply to the things we are currently working on? > > should we do more of it? > > I'm sure Chris and I could talk about the design elements in btrfs > that should aid repair if folks are interested in hearing about > them. We'd keep the hand-waving to a minimum :). And I'm sure I could provide a counterpoint by talking about the techniques we've used improving XFS repair speed and scalability without needing to change any on disk formats Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm/fs meetup details
- repair driven design, we know what it is (Val told us), but how does it apply to the things we are currently working on? should we do more of it? I'm sure Chris and I could talk about the design elements in btrfs that should aid repair if folks are interested in hearing about them. We'd keep the hand-waving to a minimum :). - z - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] error out if signing was requested, but can't be fulfilled
Currently, if mount with a signing-enabled sec= option (e.g.
sec=ntlmi), the kernel does a warning printk if the server doesn't
support signing, and then proceeds without signatures.
This is probably OK for people that think to look at the ring buffer,
but seems wrong to me. If someone explicitly requests signing, we
should error out if that request can't be satisfied. They can then
reattempt the mount without signing if that's ok.
Is there any reason not to do something like the following patch?
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 4a2458e..c9cae48 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -650,6 +650,7 @@ signing_check:
(SECMODE_SIGN_ENABLED | SECMODE_SIGN_REQUIRED)) == 0) {
cERROR(1,
("signing required but server lacks support"));
+ rc = -EOPNOTSUPP;
} else
server->secMode |= SECMODE_SIGN_REQUIRED;
} else {
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
On Thu, Jul 05, 2007 at 09:57:40AM -0400, John Stoffel wrote: > > "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes: > Erik> The only valid use of Streams in Windows I've seen was a virus > Erik> checker that stored a hash of the file in a separate > Erik> stream. Checking a file was a matter of rehashing it and > Erik> comparing against the hash stored in the special hash data > Erik> stream for that particular file. > > So what was stopping a virus from infecting a file, re-computing the > hash and pushing the new hash into the stream? Nothing, but the same holds for virus checkers that store the hash in a separate file. The only advantage of storing the hash in a stream is that the stream is automatically deleted when you remove the file. > You need to keep the computed hashes on Read-Only media for true > security, once you let the system change them, then you're toast Agreed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: vm/fs meetup details
Nick Piggin wrote: Hi, The vm/fs meetup will be held September 4th from 10am till 4pm (with the option of going longer), at the University of Cambridge. I am interested. A few potential topics: - improving laptop_mode in the VFS & VM to further increase battery life in laptops - repair driven design, we know what it is (Val told us), but how does it apply to the things we are currently working on? should we do more of it? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
On Wed, Jul 04, 2007 at 04:47:59PM -0400, Theodore Tso wrote: > On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote: > > (sorry for the late reply, just got back from holiday) > > > > On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > > > As I mentioned in my Linux.conf.au presentation a year and a half ago, > > > the main use of Streams in Windows to date has been for system > > > crackers to hide trojan horse code and rootkits so that system > > > administrators couldn't find them. :-) > > > > The only valid use of Streams in Windows I've seen was a virus checker > > that stored a hash of the file in a separate stream. Checking a file > > was a matter of rehashing it and comparing against the hash stored in > > the special hash data stream for that particular file. > > And even that's not a valid use. All the virus would have to do is to > infect the file, and then update the "special hash data stream". Why > is it that when programmers are told about streams as a potential > technology choice, it makes their thinking become fuzzy? :-) I meant valid like "not used as malware". I agree a virus could recompute the hash and go unnoticed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: [PATCH] dio: remove bogus refcounting BUG_ON
On Thu, 2007-07-05 at 10:11 -0700, Zach Brown wrote: > > the BUG_ON(). But unfortunately, our perf. team is able reproduce the > > problem. > > What are they doing to reproduce it? How much setup does it take? Huge OLTP run :( > > > Debug indicated that, the ret2 == 1 :( > > That could be consistent with the theory that we're racing with the > dio struct being freed and reused before it's tested in the BUG_ON() > condition. Suparna's suggestion to sample dio->is_async before > releasing the refcount and using that in the BUG_ON condition is a > good one. I will ask them to try that. Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dio: remove bogus refcounting BUG_ON
the BUG_ON(). But unfortunately, our perf. team is able reproduce the problem. What are they doing to reproduce it? How much setup does it take? Debug indicated that, the ret2 == 1 :( That could be consistent with the theory that we're racing with the dio struct being freed and reused before it's tested in the BUG_ON() condition. Suparna's suggestion to sample dio->is_async before releasing the refcount and using that in the BUG_ON condition is a good one. - z - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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: [PATCH 6/6] nfs: disable leases over NFS
On Sat, Jun 30, 2007 at 10:25:16AM +0100, Christoph Hellwig wrote: > On Fri, Jun 29, 2007 at 03:21:30PM -0400, J. Bruce Fields wrote: > > Define an nfs setlease method that just returns -EOPNOTSUPP. > > > > If someone can demonstrate a real need, perhaps we could reenable > > them in the presence of the "nolock" mount option. > > I'm not a big fan of default methods that do the wrong thing instead > of just missing functionality. Would you mind just returning > -EOPNOTSUPP if ->setlease is not implemented and add it to all > the local filesystems while all the network/distributed filesystems > should not have it, not just nfs. OK, after looking at this a little more, I'm less happy about the idea of erroring out by default: - There are a ton of filesystems that probably should allow leases, and only a few (network filesystems) that shouldn't, so leaving leases on by default seems simpler. - We already fall back on the local method by default in the case of locks, and I don't see a reason to treat leases differently. - The patch to add .setlease = setlease, to all the file_operations is going to be a big patch that changes behavior in a way that might be easy to miss (because it changes behavior exactly on those filesystems it *doesn't* touch.) I think it'll be easier to get better review on the patch that adds a method just to those filesystems that we're disabling leases for. I agree about dealing with the other network filesystems, though, and not just NFS and GFS2; I'll look into that. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm/fs meetup details
On Thu, 2007-07-05 at 06:01 +0200, Nick Piggin wrote: > Hi, > > The vm/fs meetup will be held September 4th from 10am till 4pm (with the > option of going longer), at the University of Cambridge. > > Anton Altaparmakov has arranged a conference room for us with whiteboard > and projector, so many thanks to him. I will send out the location and > plans for meeting/getting there after we work out the best strategy for > that. > > At the moment we have 15 people interested so far. We can have a few > more people, so if you aren't cc'ed and would like to come along please > let me know. We do have limited space, so I'm sorry in advance if anybody > misses out. > > I'll post out a running list of suggested topics later, but they're > really just a rough guideline. It will be a round-table kind of thing > and long monologue talks won't be appropriate, however some slides or > whiteboarding to interactively introduce and discuss your idea would > be OK. > > I think we want to avoid assigning slots for specific people/topics. > Feel free to propose anything, if it only gets a small amount of > interest then at least you'll know who to discuss it with later :) I'm interested in attending, worst that could happen is that I learn something :-) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
On Thu, 5 Jul 2007 09:57:40 -0400 "John Stoffel" <[EMAIL PROTECTED]> wrote: > > "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes: > > Erik> (sorry for the late reply, just got back from holiday) > Erik> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > >> As I mentioned in my Linux.conf.au presentation a year and a half > >> ago, the main use of Streams in Windows to date has been for system > >> crackers to hide trojan horse code and rootkits so that system > >> administrators couldn't find them. :-) > > Erik> The only valid use of Streams in Windows I've seen was a virus > Erik> checker that stored a hash of the file in a separate > Erik> stream. Checking a file was a matter of rehashing it and > Erik> comparing against the hash stored in the special hash data > Erik> stream for that particular file. > > So what was stopping a virus from infecting a file, re-computing the > hash and pushing the new hash into the stream? > > You need to keep the computed hashes on Read-Only media for true > security, once you let the system change them, then you're toast I'm not a huge fan of streams, but I'm pretty sure there are various encryption tools that let us verify and validate the source of data. It's entirely possible the virus checker wasn't doing it right, but storing verification info in an EA or stream isn't entirely invalid. You still need an external key that you do trust of course. -chris - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] LTP Roadmap Released
Hi All, Sometime back we started retrospection on LTP and the various ways to make it better. It resulted in critical evaluation of LTP within & outside LTP users community. It also reflected the various ways on making it more better and effective. Working in this direction, we have come up with a road map which we feel will be helpful to the community. The following wiki pages will throw some light on the same: * http://ltp.sourceforge.net/wiki/ * http://ltp.sourceforge.net/wikiArchives.php Your comments on the contents and the goals set will be highly appreciated. All comments will be published on the above wiki pages. Regards & Thanks-- Subrata Modak - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
> "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes: Erik> (sorry for the late reply, just got back from holiday) Erik> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: >> As I mentioned in my Linux.conf.au presentation a year and a half ago, >> the main use of Streams in Windows to date has been for system >> crackers to hide trojan horse code and rootkits so that system >> administrators couldn't find them. :-) Erik> The only valid use of Streams in Windows I've seen was a virus Erik> checker that stored a hash of the file in a separate Erik> stream. Checking a file was a matter of rehashing it and Erik> comparing against the hash stored in the special hash data Erik> stream for that particular file. So what was stopping a virus from infecting a file, re-computing the hash and pushing the new hash into the stream? You need to keep the computed hashes on Read-Only media for true security, once you let the system change them, then you're toast John - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Hello, Jens. Jens Axboe wrote: > On Mon, May 28 2007, Neil Brown wrote: >> I think the implementation priorities here are: >> >> 1/ implement a zero-length BIO_RW_BARRIER option. >> 2/ Use it (or otherwise) to make all dm and md modules handle >>barriers (and loop?). >> 3/ Devise and implement appropriate fall-backs with-in the block layer >>so that -EOPNOTSUP is never returned. >> 4/ Remove unneeded cruft from filesystems (and elsewhere). > > This is the start of 1/ above. It's very lightly tested, it's verified > to DTRT here at least and not crash :-) > > It gets rid of the ->issue_flush_fn() queue callback, all the driver > knowledge resides in ->prepare_flush_fn() anyways. blkdev_issue_flush() > then just reuses the empty-bio approach to queue an empty barrier, this > should work equally well for stacked and non-stacked devices. > > While this patch isn't complete yet, it's clearly the right direction to > go. Finally took a brief look. :-) I think the sequencing for zero-length barrier can be better done by pre-setting QUEUE_ORDSEQ_BAR in start_ordered() rather than short circuiting the request after it's issued. What do you think? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
