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]
Date:	Sun, 27 Jan 2008 22:40:25 -0600
From:	Eric Sandeen <>
To:	Theodore Tso <>
CC:	Matthias Koenig <>,,, Girish Shilamkar <Girish.Shilamkar@....COM>,
	Eric Sandeen <>
Subject: Re: Integrating patches in SLES10 e2fsprogs

Theodore Tso wrote:
> On Sun, Jan 27, 2008 at 09:06:59AM -0600, Eric Sandeen wrote:

>>> Patch12:        e2fsprogs-mkinstalldirs.patch
>>> Why?
>> Probably same as why we have something similar; for one reason or other
>> need to rerun autoconf, and e2fsprogs isn't compatible with latest
>> autoconf.  (This is a patch I inherited, and haven't yet investigated
>> all the details)
> Define "latest autoconf"?  I'm using autoconf 2.61, which is
> reasonably up-to-date.  Can you send me the output of config.status,
> so I can see what it's setting @MKINSTALLDIRS@ to?

[esandeen@...n devel]$ rpm -q autoconf automake

in our spec file we do:

%configure --enable-elf-shlibs --enable-nls --disable-e2initrd-helper
--enable-blkid-devmapper --enable-blkid-selinux --enable-dynamic-e2fsck
make %{?_smp_mflags}

and if I fire off the rpm w/o our changes, it terminates with:

making install in e2fsck
make[1]: Entering directory `/usr/src/redhat/BUILD/e2fsprogs-1.40.4/e2fsck'
	MKINSTALLDIRS /sbin /usr/share/man/man8
make[1]: MKINSTALLDIRS@: Command not found
make[1]: *** [installdirs] Error 127

the rpm-generated config.status has no reference to MKINSTALLDIRS.

The e2fsck looks like:

        @echo " MKINSTALLDIRS $(root_sbindir) $(man8dir)"
        @$(MKINSTALLDIRS) $(DESTDIR)$(root_sbindir) \
                $(DESTDIR)$(man8dir) $(DESTDIR)$(man5dir)

sooo... dunno.  I've never been proficient at autotools.  There's a RH
bug, btw,, which was
"resolved" with the patch we're carrying.

But if you have to chose, I'd rather have extents support in e2fsprogs
than have this problem fixed. ;)

>>> Patch22:        e2fsprogs-1.40.4-uuidd_pid_path.patch
>>> The problem with this patch is that /var/run is cleared via rm -rf, so
>>> it is highly problamtic to put the scratch directory for uuidd in
>>> /var/run.
>> Hm, I had similar issues with uuidd too - common theme here?
> What issues?  I thought you agreed that using /var/lib was the best
> approach for now.  The Novell patch moves it back to /var/run, which
> will cause significant problems if uuidd is run setuid to a non-root
> user.

Yeah, I ended up leaving it as is - I just mean I went around a bit on
this one too.

>>> Patch32:        libcom_err-no-e2fsck.static.patch
>>> This patch does two completely unrelated things.  One is to disable
>>> the libcom_err regression test suite (probably because some of the
>>> other changes made) and the other is to disable building the
>>> e2fsck.static file.  Why these two are bundled into a single patch I'm
>>> not sure.
>> And I have a patch to do the latter as well.  Interesting how we've
>> arrived at similar needed changes, independently.  :)
> Yeah, I'll check in a change so that e2fsck is built dynamically by
> default, and e2fsck.static is only built if it is explicitly
> requiested via --enable-static-e2fsck.

That'd be great, thanks, tho again I have a small patch to disable it
too (which I sent, tho I expect you'll do something different)

>> and Patch99:        e2fsprogs-no_cmd_hiding.patch
>> honestly I like that; I should whip up a nice patch to emulate kbuild,
>> with V=1 or something, unless there is some other easy way to show full
>> build commands already?
> Yes, a way to do kbuild with V=1 would be nice.  The main thing that
> makes this difficult is that I've tried to make e2fsprogs not rely on
> any GNU make'isms, since it builds on a number of non-Linux platforms,
> including *BSD, MacOS, Solaris, etc. 
> Personally, it's not a big deal; whenever I need to see what is going
> on, I just edit the makefile and quickly remove the '@' signs.  It's
> really not that hard, and it's rare that I need to look at things.  Of
> course, that could be because I'm more familiar with e2fsprog's build
> system.  :-)

Yes, but when you're sending it off to some multi-arch-build mothership,
and something fails, it's nice to be able to just look at the generated
logs and see exactly what was going on.... ah well.  Again, not the
biggest issue.

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists