when I try to merge it, it fails with an error message about the patch not being applicable. Well, no big surprise there - patching a file that has been autogenerated by a configure script doesn't sound like a very good idea.
Actually, while it might compile on some systems with "ssl" enabled, it will certainly not compile on systems with "ssl" disabled. To fix this, replace use ssl && \ patch -p1 < ${FILESDIR}/${P}-gentoo.diff || die "patch failed" with use ssl && \ ( patch -p1 < ${FILESDIR}/${P}-gentoo.diff || die "patch failed" ) in the ebuild. This doesn't solve the problem I'm having with "ssl" enabled, but at least I can now compile it with "ssl" disabled.
using ( ) like that wont accomplish what you want ... ( ) spawns another shell and when you use that 'die' in there, it kills the spawned shell while the parent shell keeps on emerging ...
Hm, OK, that was the first time I used () in a shell script... So I guess that this one would be right: use ssl && \ { patch -p1 < ${FILESDIR}/${P}-gentoo.diff || die "patch failed" }
Just looked at the Changelog for fetchmail and saw that the ssl patch was only needed to remove a warning message during compilation!? Since patch-a-file-generated-by-configure is a very flaky construction, I'd suggest that this patch be removed altogether (unless someone has the know-how required to patch the configure script itself and not break anything).
I got rid of that naughty patch. Sorry about that. I'll have a better method implemented eventually.
I had the problem with emerging fetchmail this morning and looked at this bug--figured that it would probably be fixed by the time I got home this evening (about 5:30 EDT). Tested it a few minutes ago, and yes, the emerge goes without problem. Thanks, and as always to the Gentoo developers, it's great having a distro where serious problems get fixed so quickly. Sincerely, Scott Robbins
