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] [day] [month] [year] [list]

Message-ID: <1389672128.5830.1.camel@vverma7-desk1-amr-corp-intel-com>
Date:	Tue, 14 Jan 2014 04:02:06 +0000
From:	"Verma, Vishal L" <vishal.l.verma@...el.com>
To:	"tytso@....edu" <tytso@....edu>
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 Sat, 2014-01-11 at 16:58 -0500, Theodore Ts'o wrote:
> 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.
> 
Thanks! A git clean did solve the problem.

> 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