Bugzilla Bug 123253

I've been searching for statfs inside NetBSD's headers and it seems to be
changed to statvfs, but findutils doesn't see this in it's configuration step.

So I'm attaching a working ebuild and patch for Gentoo/NetBSD and Linux (I
tested it on Linux, and there's no inteference). We have no problem like this
bug #114747 and we cannot use our own regex.h, so the patch for the ebuild is
needed. I don't know about this statfs on others systems, but it might work on
some. Changing it to fit others BSD's might be easy.

I'm going to attach the things in the next posts.

Created an attachment (id=80090) [details]
findutils-4.3.0-bsd.patch

Here's the patch for the sources.

Created an attachment (id=80091) [details]
findutils-4.3.0.ebuild-bsd.patch

Here's the patch for the ebuild.

Need to check this a bit more, findutils 4.3.0 still doesn't work on either
fbsd and dfly with this patch.

I tried also to update gnulib's support but it's a bit messed up.
I think we'll need to wait for findutils 4.3.1 hoping they'll update gnulib..

Benigno, did you check if newer gnulib has that problem fixed?

Okay seems like the use of external regex breaks fbsd badly.
I'm going to attach the an updated ebuild patch that enables the internal regex
when the libc does not provide the one used.

The nbsd patch is sort of a problem, it breaks at least FreeBSD, so it has to
be fixed and generalised and sent to gnulib maintainers (not to findutils
maintainer that are just using gnulib), when that is done, findutils
maintainers should be told to update the gnulib they use so that fixed version
can be pulled in.

Created an attachment (id=80422) [details]
Ebuild patch

Created an attachment (id=80424) [details]
Ebuild patch

Forgot ${myconf}.

(In reply to comment #4)
> Benigno, did you check if newer gnulib has that problem fixed?
> 

I only found fsusage.m4 and its corresponding source fsusage.c, which seems to
use statvfs, but importing it is a bit ridiculous (50kb+) and will not do what
we need without changing mountlist.c. I'll send an email to findutils' upstream
about this.

So I created an ugly hack (I know it might be stupid for upstream, though),
which only affect the system that has no statfs.h but has statvfs.h (the case
of NetBSD 2+. Is there other in the way?). Sir reb, do you need this?

I used the eautoconf to regenerate the configure script. I'm attaching the
patch in the next post. If someone knows how to correct this in a pretty way,
please, don't hesitate in helping! This is what I could do with minimal
changes. :)

Created an attachment (id=80484) [details]
findutils-4.3.0-statvfs-hack.patch

It's there.

so do we have a clean fix here ?

No. I've sent some emails to gnulib's upstream, but didn't get them back.
Newers coreutils have the same problem. Let's just schedule this for later,
it's not really mandatory now, since 4.1 still works.. :)

As Mike broke also the working findutils...

Is it an hack? Yes.
Is it ugly? Yes.

Did you break the only working version? Yes.

So thank you all for playing the ugly hack game :P


Serious bit: as this was broken, and the fix for glibc breaks the rest, I
consider this whole mess unfixable in other ways until upstream reacts, so I
added the needed fixes anyway.
Mike please next time you do something that you know breaks for us, do it in a
revbump and drop the keyword. Thanks.

the bug stays open until the hack is gone from portage

okay then.

4.3.1 should work properly