Summary: | Updating portage tries to build sys-apps/sandbox-1.6-r2 and needs lzma support (which old versions of portage don't have) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | arctika42 |
Component: | [OLD] Core system | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | aholler, esigra, ikelos, Martin.vGagern |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
arctika42
2009-05-28 15:22:36 UTC
First do emerge -1 =sys-apps/sandbox-1.2.18.1-r2, then try emerge -1 portage. Hit the same thing. My solution was to manually add support for lzma to /usr/lib/portage/bin/ebuild.sh, by copying the bz2 entry and replacing bzip2 with lzma. In any case, I'd believe that packages from the system set should pay more attention to portability than storage efficiency, so I'd wish for sandbox and friends to use good old tar.gz for distribution. That way, users wouldn't have to look for this bug report before they could update their system. Let's see what our sandbox-maintainers thinks about this. *** Bug 272947 has been marked as a duplicate of this bug. *** I'm having a similiar problem on ARM. emerging sandbox fails because of support for lzma. lzma is only available as unstable for arm. libtool fails too because of missing lzma. lzma unstable couldn't be emerged because it blocks the available man. So just a mess. Ah, I've found the problem, I'm using a machine with only 128mb:
--------------------------
>>> Unpacking source...
>>> Unpacking libtool-2.2.6b.tar.lzma to /var/tmp/portage/sys-devel/libtool-2.2.6b/work
lzma: /var/tmp/portage/sys-devel/libtool-2.2.6b/distdir/libtool-2.2.6b.tar.lzma: Memory usage limit reached
lzma: Limit was 49 MiB, but 65 MiB would have been needed
tar: Das sieht nicht wie ein „tar“-Archiv aus.
tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.
--------------------------
So using lzma for critical packages is more than a bad idea.
Here is my memory-configuration: -------------- $ free total used free shared buffers cached Mem: 125984 72324 53660 0 18996 33128 -/+ buffers/cache: 20200 105784 Swap: 3903784 1128 3902656 -------------- Because swap is enough available, it seems lzma wants real RAM which could be a problem for many (small) computers. After rebooting I've got the same error, even with more RAM free: --------------------- # free total used free shared buffers cached Mem: 125984 45404 80580 0 9200 24012 -/+ buffers/cache: 12192 113792 Swap: 3903784 0 3903784 --------------------- So it seems it wants the 65mb in one chunk of memory, which could be problem for even more machines. The memory-problem seems to be a problem of xz-utils. Using lzma it works. I filed bug #303975 against xz-utils. sandbox now unpacks itself by hand with older versions of a PM http://sources.gentoo.org/sys-apps/sandbox/sandbox-1.6-r2.ebuild?r1=1.14&r2=1.15 http://sources.gentoo.org/sys-apps/sandbox/sandbox-2.2.ebuild?r1=1.2&r2=1.3 |