From mboxrd@z Thu Jan 1 00:00:00 1970 From: YOANN P Subject: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Date: Mon, 12 Mar 2018 19:18:24 +0000 Message-ID: References: , <87y3ixpfrm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evTGp-0001tI-6y for bug-guix@gnu.org; Mon, 12 Mar 2018 15:38:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evTGk-0006yb-Ur for bug-guix@gnu.org; Mon, 12 Mar 2018 15:38:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49641) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1evTGk-0006yN-Nw for bug-guix@gnu.org; Mon, 12 Mar 2018 15:38:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1evTGk-0001JN-A0 for bug-guix@gnu.org; Mon, 12 Mar 2018 15:38:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87y3ixpfrm.fsf@gnu.org> Content-Language: fr-FR List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> Hi Ludovic, > We won=92t apply this patch because in general there=92s no reason for bu= ild > processes to require /var/tmp (we=92ve never encountered that.) There's always a first time. Since i didn't encounter this behavior with ot= her=20 custom directories than i've tested, looking at the code of the test who fa= iled, i suppose than the store dir is mounted inside the build chroot as itself a= nd is=20 the reason why "/var/tmp" exist during the build with a store dir starting = by=20 "/var/tmp". Despite the fact that generally there=92s no reason for build processes to = require=20 /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn'= t want to=20 add it), maybe a warning about the fact than we should never use a director= y=20 inside "/var/tmp" as store should maybe be add (it will had saving me many= =20 hours banging my head) because i've never read somewhere that there was=20 some forbidden directories to use as store and it seems there is some=20 regarding the bug i encounter. > That said, are you sure you want to use > --with-store-dir=3D/var/tmp/xxxxx/gnu/store? Yeah, i'm pretty sure i did want to use this kind of path even if it sounds= =20 weird or the reasons are not good. The purpose of my tests was to=20 configure the store with a symlink /var/tmp/guix-[short-hash] who is=20 pointing to a directory where i have the rights. This way, i could use=20 my environment with user X on server A or user Y on server B only by=20 adapting my symlink. This way, i could achieve a unprivileged portable environment because=20 /var/tmp seems present and writable on all major distribution, plus it=20 seems to work even if /var/tmp is mount with noexec. > You probably got a =91configure=92 warning already that certain things ma= y > not work, for instance that the shebang max length may be exceeded. Regarding the warning , i just checked my ./configure log, and there is=20 no warning about the limit length for the store path due to the limit of=20 shebang length, only a warning regarding the substitutes. Even if i was aware of it after reading Pjotrp notes, i've never found a=20 clear limit after my readings on the web. If Guix Team has an idea of=20 the store path limit lenght, it could be a great idea to add it to the docs= =20 or did i missed it ? > Also using a store other than /gnu/store means you won=92t be able to use > substitutes, nor to compare build results with other machines. I'm pretty aware of that, but having a portable environment who could be=20 used even under unprivileged user without the needing of "proot" /=20 "usernamespace" come with some trade offs and is just a proof of concept=20 even if it is require to build all packages from scratch. > Thanks, > Ludo=92. =20 Regards, Yoann=