linux-ext4 - Re: xfstests failures in v3.13-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140111215809.GA10995@thunk.org>
Date:	Sat, 11 Jan 2014 16:58:09 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	"Verma, Vishal L" <vishal.l.verma@...el.com>
Cc:	"jonernst07@...il.com" <jonernst07@...il.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"matthew@....cx" <matthew@....cx>
Subject: Re: xfstests failures in v3.13-rc7

On Thu, Jan 09, 2014 at 02:09:52AM +0000, Verma, Vishal L wrote:
> As an aside, when I installed e2fsprogs using simply 'make install', it
> replaced /sbin/blkid with it's own version (1.0.0), down from what I had
> (2.x). Reinstalling the util-linux-ng package brings me back up...
> (I had to modify the check script in xfstests to use the -p option in
> blkid to actually read superblock since ramdisks don't seem to make it
> into /etc/blkid/blkid.tab, and this wasn't there in blkid v1.0.0).
> 
> I quickly searched for a bit of history on the topic, and sounds like I
> should be using --disable-libblkid for configure. Tried that, and got
> some errors, the same as seen here:
> http://patchwork.ozlabs.org/patch/36491/

Did you do a full "make distclean" after you reran the configure
script?  This was caused by a left over header file, if memory serves
correctly.

If you used a separate build directory (i.e., "mkdir build ; cd build
; ../configure --enable-...") then just rm -rf the build directory and
then start from scratch.  If you used git, you can do "git clean
-xdq".  If neither of these apply, you may need to delete the full
source tree and then unpack the source tarfile again.

I'm open to patches to make this the transition between one set of
configure options to another more smooth, but given that I tend to
just do things like have multiple build directories, for things like
"build-coverity", "build-quota", "build-dietlibc", etc., it's not high
on my priority list to figure out why someone who fails to run "make
distclean", or deletes the full build tree, before running configure
with a different set of options, is losing.

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html