I tried several things, and it was not a perl suid issue.
So I found build.pl and examined it, and found this (starting at line
1100):
print "# curling index $fetch\n";
if ($fetch =~ /\.bz2$/) {
$path = "$CURL -q -s -o - \"$fetch\" | $bzip2 -dc |";
} else {
$path = "$CURL -q -s -o - \"$fetch\" |";
}
>From the docs for curl, it looks like -q as the first argument *disables*
.curlrc
Therefore, removing it solved my problem. Adding --disable-epsv to the
command line above also had the same effect.
I'm sure there are some good reasons to use -q, but in my case, since EPSV
doesn't work, it would be nice to disable it without modifying build.pl
Should we call this a bug or a feature? 8-)
--
Vinod
On Wed, 7 Apr 2004, Michael van Elst wrote:
> If curl is working for user opkg then you should be able to
> run 'openpkg build' as that user.
>
> Saying that, I just read about someone who, for some unknown reason,
> had suid-bits set on his perl executable. Maybe you are a victim
> too and the script isn't running under the uid of opkg ?
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
