Bugzilla Bug 184925

The programmer put a #include in the wrong place and the problem only occurs
when you aren't compiling md5.c for testing.  I am actually uncertain of the
real outcome of this issue, although it's likely to cause nasties in some form
or another.

Created an attachment (id=124520) [details]
fdupes-1.40-r1.ebuild

new ebuild to fix the problem

Created an attachment (id=124521) [details]
fdupes-1.40-md5.c.patch

Oh yea, I've only tested this on Gentoo/amd64, but the problem is pretty
straight forward.

Created an attachment (id=124593) [details]
fdupes-1.40-r1.ebuild

Adds md5sum-external use flag to cause fdupes to use an eternal md5sum
executable rather than it's bundled md5 routines.  I know there's some stuff
that should go in the manifest.xml and probably the ChangeLog, sorry I haven't
learned all of that yet.

Well, the outcome is simple: It causes segfaults on 64bit architectures.

@Daniel: Did you report the bug to upstream?

(In reply to comment #5)
> Well, the outcome is simple: It causes segfaults on 64bit architectures.
> 
> @Daniel: Did you report the bug to upstream?

Well, I did now :)  I figured it would do something nasty like that.  So how do
I make sure that fixes like this actually make it into the main portage tree in
the future?

(In reply to comment #4)
> Created an attachment (id=124593) [edit] [details]
> fdupes-1.40-r1.ebuild
> 
> Adds md5sum-external use flag to cause fdupes to use an eternal md5sum
> executable rather than it's bundled md5 routines.  I know there's some stuff
> that should go in the manifest.xml and probably the ChangeLog, sorry I haven't
> learned all of that yet.
> 

Sounds like this should be a separate bug.

(In reply to comment #7)
> (In reply to comment #4)
> > Created an attachment (id=124593) [edit] [details]
> > fdupes-1.40-r1.ebuild
> > 
> > Adds md5sum-external use flag to cause fdupes to use an eternal md5sum
> > executable rather than it's bundled md5 routines.  I know there's some stuff
> > that should go in the manifest.xml and probably the ChangeLog, sorry I haven't
> > learned all of that yet.
> > 
> 
> Sounds like this should be a separate bug.
> 

Separate bug for the new use flag or not, the patch to fix this segfaulting bug
has has been here since last July, half a year ago, and it still isn't in the
portage tree.  The new use flag is an enhancement that adds support for one of
the features in the configure script. Use the older ebuild if you want, but it
would be nice if the user community could get access to patches that work a bit
sooner after they are documented and submitted.

oh, I forgot to mention that using an external md5sum program would also
work-around the issue, although you can't use that feature with the ebuild in
its current state because that feature isn't supported.

Tiziano what did cause segfaults on amd64? patch or usage of external program?

Daniel, please, show us the errors you experience and steps to reproduce the
problem. At first glance string.h seems to be in correct place as all str*()
are used only inside #ifdef TEST ... #endif block.

Daniel, drop my last comment. I was obviously wrong there. I did not manage to
reproduce any segfalts on amd64 with this patch, so I've applied it in
fdupes-1.40-r1. In fdupes-1.40-r2 I've added md5sum-external USE flag... Thank
you for your work. FIXED.

(In reply to comment #11)
> Daniel, drop my last comment. I was obviously wrong there. I did not manage to
> reproduce any segfalts on amd64 with this patch, so I've applied it in
> fdupes-1.40-r1. In fdupes-1.40-r2 I've added md5sum-external USE flag... Thank
> you for your work. FIXED.
> 

hurray! :)