Date:	Sun, 27 Jan 2008 22:40:25 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....edu>
CC:	Matthias Koenig <mkoenig@...e.de>, linux-ext4@...r.kernel.org,
	hvogel@...e.de, Girish Shilamkar <Girish.Shilamkar@....COM>,
	Eric Sandeen <esandeen@...hat.com>
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
autoconf-2.61-9.fc8
automake-1.10-6

in our spec file we do:

%build
aclocal
autoconf
%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:

MKINSTALLDIRS = @MKINSTALLDIRS@
...
installdirs:
        @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, https://bugzilla.redhat.com/show_bug.cgi?id=220715, 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.

-Eric
-
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

Powered by blists - more mailing lists