From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4900 invoked by uid 1002); 13 Apr 2003 05:32:31 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 19555 invoked from network); 13 Apr 2003 05:32:31 -0000 From: Justin Whitney To: gentoo-dev@gentoo.org Content-Type: text/plain Organization: Message-Id: <1050211931.15530.22.camel@osiris.ripple.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 13 Apr 2003 01:32:11 -0400 Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] wget 1.8.2 breaks resumed emerges when using sandboxing X-Archives-Salt: 1ff4b220-5426-4b97-ba39-7a3fe75f9c4e X-Archives-Hash: 586faf77d2d9acde0e22bbd29540c54b There's bug (feature?) in wget 1.8.2 where any wget from an ftp source that resumes to an existing file (-c flag) gets chmod'd to 0600. If you're using "userpriv usersandbox" (in portage's FEATURES flag) this means that any time you ctrl-c an emerge during a download from an ftp mirror, then emerge again, the resumed file will no loger have o+r priv's, and therefore emerge will give you an "access denied". The fix is simple: chmod o+r the file, and emerge a third time. Alternatively, one could change the default download commands in make.conf to use curl or something else. Here's an excerpt from the guilty wget source file: ftp.c- /* #### Is this correct? */ ftp.c:// chmod (con->target, 0600); Seems like the answer is no, this is not correct. It is worth noting that, as I said above, this applies to only resumed files... which is curious behaviour. I've emailed the wget-bug list, but no one has responded - so maybe the wget maintainers want to take a look at this, and patch it. Or maybe portage should make sure o+r is set when userpriv/usersandbox is being used. --Justin -- gentoo-dev@gentoo.org mailing list