| Summary: | emerge-webrsync bugs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Evgeny Stambulchik <fnevgeny> |
| Component: | Current packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | Keywords: | InVCS |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Evgeny Stambulchik
2004-11-29 07:53:45 UTC
looks like a bad sync to me. app-portage/gentoolkit is still in the tree. Changed title.
The culprit appears to be the "emerge-webrsync" script.
1. When opening the snapshot's tarball, it doesn't check for the exit status of `tar' command. In my case, on (a ~1GB ext3) /var partition, it ran out of inodes, so the /usr/portage tree was damaged as a result. A check for "$?" should be added after these lines:
sync_local() {
echo Syncing local tree...
tar jxf $FILE
2. It doesn't honour PORTAGE_TMPDIR set in /etc/make.conf. Instead of
DISTDIR="/var/tmp/emerge-webrsync"
there should be
DISTDIR="$(/usr/lib/portage/bin/portageq envvar PORTAGE_TMPDIR)/emerge-webrsync"
Included fixes for 51-r9 Fixed on or before 2.0.51.22-r1 Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened. I believe the two issues I reported on are indeed fixed now. Thanks! |
