From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 214E5138247 for ; Wed, 1 Jan 2014 20:51:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83F41E0919; Wed, 1 Jan 2014 20:51:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E769FE0919 for ; Wed, 1 Jan 2014 20:51:10 +0000 (UTC) Received: from [192.168.1.9] (pool-72-95-221-222.pitbpa.fios.verizon.net [72.95.221.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id CBB3F33F563 for ; Wed, 1 Jan 2014 20:51:09 +0000 (UTC) Message-ID: <52C47FBF.2090105@gentoo.org> Date: Wed, 01 Jan 2014 15:51:11 -0500 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 To: gentoo-catalyst@lists.gentoo.org Subject: [gentoo-catalyst] Re: sem_open bug building python References: <52C47F17.3060202@gentoo.org> In-Reply-To: <52C47F17.3060202@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 248cab46-e06c-4ef3-b4f5-683d63322632 X-Archives-Hash: ecb8f1aa26a83fd2c960743c32bbe1a3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Resending to gentoo-catalyst because I'm stupid. - -Zero On 01/01/2014 03:48 PM, Rick "Zero_Chaos" Farina wrote: > Team, > > My builds just started failing with a known issue while building > python. A patch was written by blueness (and backported by > dol-sen), however, I'd like to discuss the implementation and get > this fixed before we cut the 2.0.16 release. Here is the patch as > it stands: > > X-Git-Url: > http://git.overlays.gentoo.org/gitweb/?p=proj%2Fcatalyst.git;a=blobdiff_plain;f=modules%2Fgeneric_stage_target.py;h=9edafe99f83a8a6f4f1ef8e60f2b54e59dc95963;hp=848aca2f8616574ce1a8cdc0d1c4cf33c6620bb8;hb=648c9cc9bfdf88e3612399f2cc9bed9a3bae17f5;hpb=5fb71eb045f0b1b8252b85ce9e8042c87a9bdb1a > > diff --git a/modules/generic_stage_target.py > b/modules/generic_stage_target.py index 848aca2..9edafe9 100644 --- > a/modules/generic_stage_target.py +++ > b/modules/generic_stage_target.py @@ -174,16 +174,21 @@ class > generic_stage_target(generic_target): > > """ Setup our mount points """ if "SNAPCACHE" in self.settings: - > > self.mounts=["/proc","/dev","/usr/portage","/usr/portage/distfiles","/var/tmp/portage"] > > + self.mounts=["/proc", "/dev", "/usr/portage", > + "/usr/portage/distfiles", "/var/tmp/portage"] > self.mountmap={"/proc":"/proc","/dev":"/dev","/dev/pts":"/dev/pts",\ > > "/usr/portage":self.settings["snapshot_cache_path"]+"/portage",\ > - > "/usr/portage/distfiles":self.settings["distdir"],"/var/tmp/portage":"tmpfs"} > > + > "/usr/portage/distfiles":self.settings["distdir"],"/var/tmp/portage":"tmpfs", > > + "/dev/shm": "/dev/shm"} > else: - > self.mounts=["/proc","/dev","/usr/portage/distfiles","/var/tmp/portage"] > > + self.mounts=["/proc", "/dev", "/usr/portage/distfiles", > + "/var/tmp/portage"] > self.mountmap={"/proc":"/proc","/dev":"/dev","/dev/pts":"/dev/pts",\ > > - - > "/usr/portage/distfiles":self.settings["distdir"],"/var/tmp/portage":"tmpfs"} > > + > "/usr/portage/distfiles":self.settings["distdir"],"/var/tmp/portage":"tmpfs", > > + "/dev/shm": "/dev/shm"} > if os.uname()[0] == "Linux": self.mounts.append("/dev/pts") + > self.mounts.append("/dev/shm") > > self.set_mounts() > > > I'm not a fan of this because /dev/shm is writable, and we are > sharing /dev/shm with not only the host, but all the other catalyst > runs (in my case that is up to 3) which means it is entirely > possible for writes to collide, or worse, cleanup to collide. > > Simply chaning the second "/dev/shm" to "tmpfs" is also not right > because it ends up with the wrong permissions: > > shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) tmpfs > on /catalyst/tmp/hardened/stage1-amd64-2013.0/dev/shm type tmpfs > (rw,relatime,size=20971520k) > > > I'd like to have the patch rewritten to mount this properly as it's > own tmpfs with the proper mount options. > > Does anyone have issues with this? It is a rather trivial thing to > copy from my work making /var/tmp/portage a tmpfs, anyone can do > the work. I can do it, or whomever. > > Please discuss quickly, I fear this bug will stop all forward > progress and we really can't afford for the builds to stop, again. > I know I can't. > > Thanks, Zero > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxH+/AAoJEKXdFCfdEflKk/EP/RiGZwZV+vg+VB3E0pFPJww9 RdIy7zPDTxjQ4GVczUqUF9DEOBJ0zXRoNKiwpKWhyxK6I2wIYFBrggnQY8duLmX3 GUBLlprwtFfOYGOLJIFibsIamKHEIHXRgs8PGwEPyG0qiqA2N+uFVbgi8m/Vsp0/ MRhm1Rd8gclWzAyJ/RJaTm6OIWOKcUklgYEmwADoXzFOpROdR3N7GqHyz6XzUPlZ kx+DuVCMaVFXMIHFJHSMTKC2RlQP7ZAhB0MGV/0rppFOM0EIV4DizVHKlkNXB9jE MBgXC1grg2cCX7FrKx7NXX37aN6LtgFYdCjPOesnteCe8kCn03MFqAF9/b3grqIG /d0LcTdAUjXFZoh37EjhvhWPvJu3qkm+9JDmtaqRYC3Ygn5iuXxCc8e9GbWA5rhi eSZofGls2kzoEQsDYngpdIRmVxru+qtXBDwb7InmRzpDW6UcVBBPc4vEq+3i09br qPLmSEJDo8eVTkQr9A5GFpzPIese6drSPlA8+4GiLIgbgMpL8p3+nHUey3Akg9RS aEWd6KmhxE8bZvTHo2RgVhQotkUz3mf4YI/JP7JCzWh/WIj1E4tMzxfhT7zS2nxY eAo+NHSmWcI393ysghX6mACg43mLZSQ9d51KrnlcqAsHt60VarDQ/7+6paIF5puY TaBl9SDTfSkFbJ6CsM85 =9Tj7 -----END PGP SIGNATURE-----