From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GhpFs-0000O5-IG for garchives@archives.gentoo.org; Wed, 08 Nov 2006 15:22:21 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kA8FIhMl018451; Wed, 8 Nov 2006 15:18:43 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kA8FIgPI012234 for ; Wed, 8 Nov 2006 15:18:42 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhpBx-0002wo-Vq for gentoo-amd64@lists.gentoo.org; Wed, 08 Nov 2006 16:18:18 +0100 Received: from ip68-230-97-209.ph.ph.cox.net ([68.230.97.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Nov 2006 16:18:17 +0100 Received: from 1i5t5.duncan by ip68-230-97-209.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Nov 2006 16:18:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Unexpected side effect of GCC 4 Date: Wed, 8 Nov 2006 15:17:38 +0000 (UTC) Message-ID: References: <200611050845.42865.prh@gotadsl.co.uk> <200611061144.01773.prh@gotadsl.co.uk> <200611081119.07931.prh@gotadsl.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-209.ph.ph.cox.net User-Agent: pan 0.118 (Gustaf Von Musterhausen) Sender: news X-Archives-Salt: 4a65487d-ec06-45e5-9987-a17d550cfc57 X-Archives-Hash: 99759dfcc2edb2bfccce6903e5c23920 Peter Humphrey posted 200611081119.07931.prh@gotadsl.co.uk, excerpted below, on Wed, 08 Nov 2006 11:19:07 +0000: > I decided on an even simpler approach. As I don't really want all the other > stuff in /var/tmp to evaporate every time I shut down, I put /tmp on > tmpfs, with this entry in /etc/fstab: > tmpfs /tmp tmpfs nodev,nosuid,size=85% 0 0 Hmm... I wasn't aware size could be set as a percentage of memory. man mount says size is in bytes, and offers the suffixes k, m and g, with no mention of the % suffix, tho it does say the default is half of memory. Does the 85% actually work as implied? If so, I just learned something new. =8^) > Then I added these entries to /etc/make.conf: > BUILD_PREFIX="/tmp/portage/build" # not sure I need this I don't think you do. I don't have that var set here. > CCACHE_DIR="/var/tmp/ccache" # to make sure it doesn't go looking in/tmp > PORTAGE_TMPDIR="/tmp" > >> Note that setting [PORTAGE_TMPFS] to a small, say 50 meg, tmpfs, is >> useful even if you aren't setting PORTAGE_TMPDIR on tmpfs. It's used >> for quick/small stuff like lockfiles and the like. The portage docs >> suggest setting it to /dev/shm, an LSB standard location for such >> things. I have a separate (max 50 meg as I said) tmpfs mounted at >> /dev/shm and followed the recommendation to point PORTAGE_TMPFS at it. > > Where did you find this recommendation? I can't find any reference to > it. PORTAGE_TMPFS is a fairly new setting that may not have made it to stable portage yet. It doesn't appear to have made it into the make.conf manpage yet, but from make.conf.example: # PORTAGE_TMPFS is a location where portage may create temporary files. # If specified, portage will use this directory whenever possible # for all rapid operations such as lockfiles and transient data. # It is _highly_ recommended that this be a tmpfs or ramdisk. Do not # set this to anything that does not give a significant performance # enhancement and proper FS compliance for locks and read/write. # /dev/shm is a glibc mandated tmpfs, and should be a reasonable # setting for all linux kernel+glibc based systems. #PORTAGE_TMPFS="/dev/shm" >> Of course, you'll only need PKG_TMPDIR if you have FEATURES=buildpkg >> set or otherwise deal with binary packages. > > Same question. Hmm... I don't see any documentation on this. A google search on PKG_TMPDIR turns up mostly BSD references (here you can see portage's BSD heritage, Daniel Robbins found the concept there and liked it so created portage for Gentoo when he started it). However, adding the terms portage or gentoo to the search helps. There are a bit less than a hundred hits in each of those two cases. They are interesting but I don't see anything authoritative. I must have picked it up elsewhere, probably from either the gentoo-dev or gentoo-portage lists, or from gentoo-user, which I followed for a few months as a newbie. Anyway, PKG_TMPDIR/binpkgs is used temporarily when merging binary packages. Thus, it'll be used with FEATURES=buildpkg, which I have set and recommend as a very useful feature, as well as when a previously built binary package is merged using -k or -K. (The buildpkg FEATURE doesn't do the usual ebuild qmerge step, but rather merges from the binary package just created, thus testing it, using PKG_TMPDIR in the process.) Note that you only need to point the var at /tmp, as portage automatically uses the binpkgs subdir of whatever it's pointed at, just as it uses the portage subdir of PORTAGE_TMPDIR during the build process. Interesting it doesn't seem to be documented, and PORTAGE_TMPFS is in make.conf.example, but not in the make.conf manpage. I should file a bug. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list