By default, xz (from xz-utils) limits memory use to 40% of total physical memory. According to the emerge output, eix-0.17.1 needs to use 65M to extract, which means 162.5M physical ram is needed. Won't extract on my machine w/ 128M. Reproducible: Always Steps to Reproduce: 1. emerge eix Actual Results: >>> Emerging (1 of 1) app-portage/eix-0.17.1 * eix-0.17.1.tar.xz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * Unpacking /var/tmp/portage/app-portage/eix-0.17.1/distdir/eix-0.17.1.tar.xz to /var/tmp/portage/app-portage/eix-0.17.1/work xz: /var/tmp/portage/app-portage/eix-0.17.1/distdir/eix-0.17.1.tar.xz: Memory usage limit reached xz: Limit was 45 MiB, but 65 MiB would have been needed tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors * * ERROR: app-portage/eix-0.17.1 failed.
Ben, The lzma sources worked for you before?
Using xz-utils, I can extract neither eix-0.17.0 (lzma) nor eix-0.17.1 (xz), they both die with that error saying 65M is needed. Using lzma-utils, I can extract/build eix-0.17.0 (lzma) but obviously not eix-0.17.1 (xz) since xz is not available.
@base-system: Do you consider this a showstopper for xz-utils migration. Or even a problem?
that depends on whether the 65MB estimate is directly proportional to the archive size. eix is only 480KB, so if you cant even unpack that, then doing larger ones (like coreutils -- 10MB) isn't going to happen. so try unpacking coreutils-7.5.tar.xz and see how much memory it wants.
coreutils-7.5.tar.xz is not nearly as bad, 9M needed. The xz manpage gives some details about memory usage, apparently it varies wildly depending on compression options. You can test a particular xz by forcing a lower memory limit: # unxz coreutils-7.5.tar.xz --memory=2M unxz: coreutils-7.5.tar.xz: Memory usage limit reached unxz: Limit was 1 MiB, but 9 MiB would have been needed
thanks for the --memory tip. the excessive memory usage is because the packager of eix picked -9 compression. so fix the eix packaging and lets call it a day. lvl mem filesize -6 9M 484240 -9 65M 484240 seems like a no brainer to me
I suppose that a temporary workaround might be to cheat xz about the available memory if there is sufficient swap space: export XZ_OPT='--memory=80M' (I cannot try since all my systems have more memory). Due to checksum problems, I should probably not modify the released tarballs. Anyway, eix-0.18.0 will be released soon, and the tarballs will be created from now on without -9.
New versions are in the tree, this bug can be closed. Thanks for the analysis, everyone. (0.17.1 will not be marked stable due to this issue)
