From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 11 13:48:47 2018 Received: (at submit) by debbugs.gnu.org; 11 Mar 2018 17:48:47 +0000 Received: from localhost ([127.0.0.1]:55639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ev55S-000828-9b for submit@debbugs.gnu.org; Sun, 11 Mar 2018 13:48:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ev3Wg-0005Ba-SC for submit@debbugs.gnu.org; Sun, 11 Mar 2018 12:08:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ev3WP-0001Fv-2t for submit@debbugs.gnu.org; Sun, 11 Mar 2018 12:08:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,RECEIVED_FROM_WINDOWS_HOST,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ev3WO-0001Fm-SK for submit@debbugs.gnu.org; Sun, 11 Mar 2018 12:08:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ev3WM-0003Ad-Ts for bug-guix@gnu.org; Sun, 11 Mar 2018 12:08:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ev3WJ-0001Dc-KF for bug-guix@gnu.org; Sun, 11 Mar 2018 12:08:26 -0400 Received: from mail-oln040092068071.outbound.protection.outlook.com ([40.92.68.71]:45089 helo=EUR02-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ev3WI-0001Cu-TA for bug-guix@gnu.org; Sun, 11 Mar 2018 12:08:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kXbfC+o7i54EnqgwwnUdKlqMzndHP6b9qLfjkJl915A=; b=FM9x3XiAIGPoH0jNuxk84a8stV+TijBDVryIihxP23+Jjv9WWTv+0Ky9AysppFIRnioMA0LsTSbTKao+2dMjuhIamMmK1r0/xO1xiSK7GtTMFQ9ygG5b/SgNtpUpWQZE0m2sKhsxCnec4jEVZ/5hXFDMHBPccgLiLat3nBy8MKesHINQEQi4WuFrXzXRK0W35pMANGPTYAa8byyvuVpHUMzLtfGKTQUZrAdV+hrb1SdGk/6+fSLtT7D+oPqNVaDSKgTaqZSo7Ec3zZLiF5Nk3EFUB4j3VKmXToszV9ySRdAgLqoNXFoR0ReNYnZsxD5r88I9XWx8KNsIsRNA09sbeQ== Received: from VE1EUR02FT024.eop-EUR02.prod.protection.outlook.com (10.152.12.57) by VE1EUR02HT173.eop-EUR02.prod.protection.outlook.com (10.152.13.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Sun, 11 Mar 2018 16:08:20 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM (10.152.12.53) by VE1EUR02FT024.mail.protection.outlook.com (10.152.12.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15 via Frontend Transport; Sun, 11 Mar 2018 16:08:20 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82]) by DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82%13]) with mapi id 15.20.0567.018; Sun, 11 Mar 2018 16:08:20 +0000 From: YOANN P To: "bug-guix@gnu.org" Subject: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Topic: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Index: AQHTuU5QUGmxXwsupE+9xWIKbzUzbg== Date: Sun, 11 Mar 2018 16:08:20 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3B50BF838C011E9BF124265B918E5CD23EF9CE743D22425EE2071C7BE99D1C78; UpperCasedChecksum:5342ACC0DC9B59CC86DAA7375A1E2F633539E4CD48E3C60B7A02384CCDEE9C58; SizeAsReceived:6969; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [3zoDloFE9Pq69cvSUfd6oVHAjjzNX4bQ] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VE1EUR02HT173; 6:9VcEuWgOD71NfAbspiENKS8p59qPbezkt39H3yqVLAs1fNRi+yD/QJ9XVWsj6kO19967BB1SMTxfm44Kcp5oKJ2uQ3QbC1/PC14lEN9uhwGaH1w4rkPnQBVDH6rXVF0j2TWzqfyUfV6uYkJr23uXoE9eaeWbXR1AyY1XOvWMMS2MdABrEAzyV66i7NQr7rDPUhLKJe5Ta/UnBDfSGj8Zz7TPka8tcRNWcj2Vkws3B5ndpBwV4tC2f+1E2DvA6qP+x3IuwljIuxjqdTslbE55riQ9jlbYP/BPtRkKp9GrE31H0DeXpuEqh/D0M6eZM4eMXleiK+C82+Uab+LG4ER9FK02rHmSHGjCEwGZH4yWr7A=; 5:Ai7sOK0rvbaJSlg1Nk/ISYK8ySDGfMfolKjA7J9JJNb1Gf7neVQHfINsPI7nMf5RuBUQlI1HlGCNCa/aivVyGYbddJiHqoo0en5DCVgp3cSJFSb1LIuCMAybf8OiAogv68MmApLI8UZ3feA+yuLvCWlD6DxcoyTWu4DUzMfVUOk=; 24:jPF3V4ikPWZ1qF4Z6JJAyJG8LMlLF33/OS6nbtFxQnG2FQ8eEMRuF/NreL6kqXFUXlELdIh0SpmDOOBVY5TYGbKLDbk4dA3RD4S9ZsZoMt8=; 7:WEY3BPkom1+Sf9QP6CAcw4AsgRKJBBE1ju6zJ7Gg1XlyjU7UCYcJA3QDAjDhYMCf4uHi/u8XZ8/L1VZpJ5nmtPXqPQMiTzctcBon6rB9dHD3qZkohMKM+V6MQegMOGZKkqeGI2EPk8jsAAzyc3y4Uyn94GjF6Vt0t2D8E6G5v/0Maw9abtdEzQM6S10TOKkwDQ+4ehmPTBBgQKFtDHnBQgfLqjtSY1klZlpu1+49azz1Y1KcH4JWvzIUHCfDYZdM x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:VE1EUR02HT173; x-ms-traffictypediagnostic: VE1EUR02HT173: x-ms-office365-filtering-correlation-id: f383e0d4-f2b6-480d-eb51-08d5876a4f16 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:VE1EUR02HT173; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR02HT173; x-forefront-prvs: 0608DEDB67 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:VE1EUR02HT173; H:DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: KnvOwyuNkcFsQSun7cmpqbI2Qc4w/vbLqGB0n/A9gYSO2et8H1G+dabB44OiPfS37+TLUGMmK7CdgiF4gAdCenmdabnqU6iCs5eY2Ob2apvVaf0cJv3ByxdEcg884jroaWFdOF3YoMHaFZkSsaRgWlPO4vlg6ocwYNuxto2g7sOGYQx7/MbJLMd757HhlaMl spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_005_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: f383e0d4-f2b6-480d-eb51-08d5876a4f16 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2018 16:08:20.5197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT173 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 11 Mar 2018 13:48:45 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --_005_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_ Content-Type: multipart/alternative; boundary="_000_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_" --_000_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I'm not sure about the reason of this behavior but if configure guix --with= -store-dir=3D/var/tmp/test_guix/gnu/store for exemple, the tests for gettex= t failed with a permission denied for test-copy-file-1.sh. If i configure guix with a store to $HOME/.local, everything run smoothly. Please find attached : - my guix build script from git for this test - the test-suite.log The daemon was launched like this : ------ $ sudo ./pre-inst-env guix-daemon --build-users-group=3Dguixbuild --no-subs= titutes -c 4 -M 4 --debug ------ The package installation command : ------ $ ./pre-inst-env guix package -i hello --no-grafts --fallback -K ------ The permissions on /var /var/tmp : ------ $ stat -c "%a %n" /var /var/tmp 755 /var 1777 /var/tmp ------ If I take a look at the test-copy-file-1.sh, it seems that the /var/tmp is = present inside the build chroot cause TMPDIR is defined as /var/tmp instead= of /tmp. ------ $ head -n10 /tmp/guix-build-gettext-minimal-0.19.8.1.drv-0/gettext-0.19.8.1= /gettext-tools/gnulib-tests/test-copy-file-1.sh #!/var/tmp/test_guix/gnu/store/sqvi3glr2jzgrvfbj624k1sgs15a954c-bash-minima= l-4.4.12/bin/sh # Test copy-file on the file system of /var/tmp, which usually is a local # file system. if test -d /var/tmp; then TMPDIR=3D/var/tmp else TMPDIR=3D/tmp fi ------ In the "Build Environment Setup" documentation section, there is a mention = about /tmp to be writable inside the chroot but there is no mention about /= var/tmp and haven't seen a section for /var/tmp chroot inside guix file "bu= ild.cc". Best regards, Yoann --_000_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,


I'm not sure about the reaso= n of this behavior but if configure guix --with-store-dir= =3D/var/tmp/test_guix/gnu/store for exemple, the tests for gette= xt failed with a permission denied for test-copy-file-1.sh.

If i configure = guix with a store to $HOME/.local, everything run smoothly.


Please find att= ached : 


- my guix&= nbsp;build script from git for this test

- the test-suit= e.log


The daemon was = launched like this :

------

$ sudo ./pre-inst-env guix-daemon --build-users-= group=3Dguixbuild --no-substitutes -c 4 -M 4 --debug

------


The packa= ge installation command : 

= ---= ---

= $ ./pre-inst-env guix package -i hello --n= o-grafts --fallback -K

= ---= ---


The permi= ssions on /var /var/tmp :

------
$ stat -c "%a %n" /var /= var/tmp
755 /var
1777 /var/tmp
------

If I take a look at the test-copy-file-1.sh, it seems that = the /var/tmp is present inside the build chroot cause TMPDIR is defined as&= nbsp;/var/tmp instead of /tmp.
------
$ head -n10 /tmp/guix-build-gettex= t-minimal-0.19.8.1.drv-0/gettext-0.19.8.1/gettext-tools/gnulib-tests/test-c= opy-file-1.sh
#!/var/tmp/test_guix/gnu/store/sqv= i3glr2jzgrvfbj624k1sgs15a954c-bash-minimal-4.4.12/bin/sh

# Test copy-file on the file syste= m of /var/tmp, which usually is a local
# file system.

if test -d /var/tmp; then
  TMPDIR=3D/var/tmp
else
  TMPDIR=3D/tmp
fi
------

In the "Build Environment Setup" docum= entation section, there is a mention about /tmp to be writable inside the c= hroot but there is no mention about /var/tmp and haven't seen a section for= /var/tmp chroot inside guix file "build.cc".

Best rega= rds,

Yoann

--_000_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_-- --_005_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_ Content-Type: text/x-log; name="test-suite.log" Content-Description: test-suite.log Content-Disposition: attachment; filename="test-suite.log"; size=5589; creation-date="Sun, 11 Mar 2018 15:45:32 GMT"; modification-date="Sun, 11 Mar 2018 15:45:32 GMT" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 CiAgIGdldHRleHQtdG9vbHMgMC4xOS44LjE6IGdudWxpYi10ZXN0cy90ZXN0LXN1aXRlLmxvZwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K CiMgVE9UQUw6IDE5OAojIFBBU1M6ICAxNzAKIyBTS0lQOiAgMjcKIyBYRkFJTDogMAojIEZBSUw6 ICAxCiMgWFBBU1M6IDAKIyBFUlJPUjogMAoKLi4gY29udGVudHM6OiA6ZGVwdGg6IDIKClNLSVA6 IHRlc3Qtc2V0LW1vZGUtYWNsLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09CgorIHRlc3Qg MCA9IDAKKyBlY2hvICdTa2lwcGluZyB0ZXN0OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQnClNr aXBwaW5nIHRlc3Q6IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydAorIGV4aXQgNzcKU0tJUCB0ZXN0 LXNldC1tb2RlLWFjbC5zaCAoZXhpdCBzdGF0dXM6IDc3KQoKU0tJUDogdGVzdC1zZXQtbW9kZS1h Y2wtMS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09CgorIHRlc3QgMCA9IDAKKyBlY2hv ICdTa2lwcGluZyB0ZXN0OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQnClNraXBwaW5nIHRlc3Q6 IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydAorIGV4aXQgNzcKU0tJUCB0ZXN0LXNldC1tb2RlLWFj bC0xLnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LXNldC1tb2RlLWFjbC0yLnNoCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KCisgdGVzdCAwID0gMAorIGVjaG8gJ1NraXBwaW5n IHRlc3Q6IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydCcKU2tpcHBpbmcgdGVzdDogaW5zdWZmaWNp ZW50IEFDTCBzdXBwb3J0CisgZXhpdCA3NwpTS0lQIHRlc3Qtc2V0LW1vZGUtYWNsLTIuc2ggKGV4 aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3QtY29weS1hY2wuc2gKPT09PT09PT09PT09PT09PT09 PT09PQoKKyB0ZXN0IDAgPSAwCisgZWNobyAnU2tpcHBpbmcgdGVzdDogaW5zdWZmaWNpZW50IEFD TCBzdXBwb3J0JwpTa2lwcGluZyB0ZXN0OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQKKyBleGl0 IDc3ClNLSVAgdGVzdC1jb3B5LWFjbC5zaCAoZXhpdCBzdGF0dXM6IDc3KQoKU0tJUDogdGVzdC1j b3B5LWFjbC0xLnNoCj09PT09PT09PT09PT09PT09PT09PT09PQoKKyB0ZXN0IDAgPSAwCisgZWNo byAnU2tpcHBpbmcgdGVzdDogaW5zdWZmaWNpZW50IEFDTCBzdXBwb3J0JwpTa2lwcGluZyB0ZXN0 OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQKKyBleGl0IDc3ClNLSVAgdGVzdC1jb3B5LWFjbC0x LnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LWNvcHktYWNsLTIuc2gKPT09PT09PT09 PT09PT09PT09PT09PT09CgorIHRlc3QgMCA9IDAKKyBlY2hvICdTa2lwcGluZyB0ZXN0OiBpbnN1 ZmZpY2llbnQgQUNMIHN1cHBvcnQnClNraXBwaW5nIHRlc3Q6IGluc3VmZmljaWVudCBBQ0wgc3Vw cG9ydAorIGV4aXQgNzcKU0tJUCB0ZXN0LWNvcHktYWNsLTIuc2ggKGV4aXQgc3RhdHVzOiA3NykK ClNLSVA6IHRlc3QtYnRvd2MxLnNoCj09PT09PT09PT09PT09PT09PT09CgpTa2lwcGluZyB0ZXN0 OiBubyB0cmFkaXRpb25hbCBmcmVuY2ggbG9jYWxlIGlzIHN1cHBvcnRlZApTS0lQIHRlc3QtYnRv d2MxLnNoIChleGl0IHN0YXR1czogNzcpCgpGQUlMOiB0ZXN0LWNvcHktZmlsZS0xLnNoCj09PT09 PT09PT09PT09PT09PT09PT09PT0KCisgZnVuY190bXBkaXIKKyA6IC92YXIvdG1wCisgdG1wPQor IHRtcD0vdmFyL3RtcC9nbDIyMzA0LTY0MTAKKyB1bWFzayAwNzcKKyBta2RpciAvdmFyL3RtcC9n bDIyMzA0LTY0MTAKbWtkaXI6IGNhbm5vdCBjcmVhdGUgZGlyZWN0b3J5ICcvdmFyL3RtcC9nbDIy MzA0LTY0MTAnOiBQZXJtaXNzaW9uIGRlbmllZAorIGVjaG8gJy4vdGVzdC1jb3B5LWZpbGUuc2g6 IGNhbm5vdCBjcmVhdGUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGluIC92YXIvdG1wJwouL3Rlc3Qt Y29weS1maWxlLnNoOiBjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBpbiAvdmFy L3RtcAorIGV4aXQgMQorIGZ1bmNfdG1wZGlyCisgOiAvdmFyL3RtcAorIHRtcD0KKyB0bXA9L3Zh ci90bXAvZ2wyMjMxOS0xNzk2MAorIHVtYXNrIDA3NworIG1rZGlyIC92YXIvdG1wL2dsMjIzMTkt MTc5NjAKbWtkaXI6IGNhbm5vdCBjcmVhdGUgZGlyZWN0b3J5ICcvdmFyL3RtcC9nbDIyMzE5LTE3 OTYwJzogUGVybWlzc2lvbiBkZW5pZWQKKyBlY2hvICcuL3Rlc3QtY29weS1maWxlLnNoOiBjYW5u b3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGRpcmVjdG9yeSBpbiAvdmFyL3RtcCcKLi90ZXN0LWNvcHkt ZmlsZS5zaDogY2Fubm90IGNyZWF0ZSBhIHRlbXBvcmFyeSBkaXJlY3RvcnkgaW4gL3Zhci90bXAK KyBleGl0IDEKRkFJTCB0ZXN0LWNvcHktZmlsZS0xLnNoIChleGl0IHN0YXR1czogMSkKClNLSVA6 IHRlc3QtZmlsZS1oYXMtYWNsLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09CgorIHRlc3Qg MCA9IDAKKyBlY2hvICdTa2lwcGluZyB0ZXN0OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQnClNr aXBwaW5nIHRlc3Q6IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydAorIGV4aXQgNzcKU0tJUCB0ZXN0 LWZpbGUtaGFzLWFjbC5zaCAoZXhpdCBzdGF0dXM6IDc3KQoKU0tJUDogdGVzdC1maWxlLWhhcy1h Y2wtMS5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09CgorIHRlc3QgMCA9IDAKKyBlY2hv ICdTa2lwcGluZyB0ZXN0OiBpbnN1ZmZpY2llbnQgQUNMIHN1cHBvcnQnClNraXBwaW5nIHRlc3Q6 IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydAorIGV4aXQgNzcKU0tJUCB0ZXN0LWZpbGUtaGFzLWFj bC0xLnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LWZpbGUtaGFzLWFjbC0yLnNoCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KCisgdGVzdCAwID0gMAorIGVjaG8gJ1NraXBwaW5n IHRlc3Q6IGluc3VmZmljaWVudCBBQ0wgc3VwcG9ydCcKU2tpcHBpbmcgdGVzdDogaW5zdWZmaWNp ZW50IEFDTCBzdXBwb3J0CisgZXhpdCA3NwpTS0lQIHRlc3QtZmlsZS1oYXMtYWNsLTIuc2ggKGV4 aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3QtbWJydG93YzEuc2gKPT09PT09PT09PT09PT09PT09 PT09PQoKU2tpcHBpbmcgdGVzdDogbm8gdHJhZGl0aW9uYWwgZnJlbmNoIGxvY2FsZSBpcyBzdXBw b3J0ZWQKU0tJUCB0ZXN0LW1icnRvd2MxLnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0 LW1icnRvd2MzLnNoCj09PT09PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vIHRy YWRpdGlvbmFsIGphcGFuZXNlIGxvY2FsZSBpcyBzdXBwb3J0ZWQKU0tJUCB0ZXN0LW1icnRvd2Mz LnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LW1icnRvd2M0LnNoCj09PT09PT09PT09 PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vIHRyYW5zaXRpb25hbCBjaGluZXNlIGxvY2Fs ZSBpcyBzdXBwb3J0ZWQKU0tJUCB0ZXN0LW1icnRvd2M0LnNoIChleGl0IHN0YXR1czogNzcpCgpT S0lQOiB0ZXN0LW1icnRvd2MtdzMyLTEuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09CgpT a2lwcGluZyB0ZXN0OiBub3QgYSBuYXRpdmUgV2luZG93cyBzeXN0ZW0KU0tJUCB0ZXN0LW1icnRv d2MtdzMyLTEuc2ggKGV4aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3QtbWJydG93Yy13MzItMi5z aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vdCBhIG5hdGl2 ZSBXaW5kb3dzIHN5c3RlbQpTS0lQIHRlc3QtbWJydG93Yy13MzItMi5zaCAoZXhpdCBzdGF0dXM6 IDc3KQoKU0tJUDogdGVzdC1tYnJ0b3djLXczMi0zLnNoCj09PT09PT09PT09PT09PT09PT09PT09 PT09PQoKU2tpcHBpbmcgdGVzdDogbm90IGEgbmF0aXZlIFdpbmRvd3Mgc3lzdGVtClNLSVAgdGVz dC1tYnJ0b3djLXczMi0zLnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LW1icnRvd2Mt dzMyLTQuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09CgpTa2lwcGluZyB0ZXN0OiBub3Qg YSBuYXRpdmUgV2luZG93cyBzeXN0ZW0KU0tJUCB0ZXN0LW1icnRvd2MtdzMyLTQuc2ggKGV4aXQg c3RhdHVzOiA3NykKClNLSVA6IHRlc3QtbWJydG93Yy13MzItNS5zaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vdCBhIG5hdGl2ZSBXaW5kb3dzIHN5c3RlbQpT S0lQIHRlc3QtbWJydG93Yy13MzItNS5zaCAoZXhpdCBzdGF0dXM6IDc3KQoKU0tJUDogdGVzdC1t YnNydG93Y3MxLnNoCj09PT09PT09PT09PT09PT09PT09PT09PQoKU2tpcHBpbmcgdGVzdDogbm8g dHJhZGl0aW9uYWwgZnJlbmNoIGxvY2FsZSBpcyBzdXBwb3J0ZWQKU0tJUCB0ZXN0LW1ic3J0b3dj czEuc2ggKGV4aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3QtbWJzcnRvd2NzMy5zaAo9PT09PT09 PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vIHRyYWRpdGlvbmFsIGphcGFuZXNl IGxvY2FsZSBpcyBzdXBwb3J0ZWQKU0tJUCB0ZXN0LW1ic3J0b3djczMuc2ggKGV4aXQgc3RhdHVz OiA3NykKClNLSVA6IHRlc3QtbWJzcnRvd2NzNC5zaAo9PT09PT09PT09PT09PT09PT09PT09PT0K ClNraXBwaW5nIHRlc3Q6IG5vIHRyYW5zaXRpb25hbCBjaGluZXNlIGxvY2FsZSBpcyBzdXBwb3J0 ZWQKU0tJUCB0ZXN0LW1ic3J0b3djczQuc2ggKGV4aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3Qt bWJzc3RyMy5zaAo9PT09PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vIGNoaW5l c2UgR0IxODAzMCBsb2NhbGUgaXMgc3VwcG9ydGVkClNLSVAgdGVzdC1tYnNzdHIzLnNoIChleGl0 IHN0YXR1czogNzcpCgpTS0lQOiB0ZXN0LXdjcnRvbWItdzMyLTEuc2gKPT09PT09PT09PT09PT09 PT09PT09PT09PT09CgpTa2lwcGluZyB0ZXN0OiBub3QgYSBuYXRpdmUgV2luZG93cyBzeXN0ZW0K U0tJUCB0ZXN0LXdjcnRvbWItdzMyLTEuc2ggKGV4aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3Qt d2NydG9tYi13MzItMi5zaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRl c3Q6IG5vdCBhIG5hdGl2ZSBXaW5kb3dzIHN5c3RlbQpTS0lQIHRlc3Qtd2NydG9tYi13MzItMi5z aCAoZXhpdCBzdGF0dXM6IDc3KQoKU0tJUDogdGVzdC13Y3J0b21iLXczMi0zLnNoCj09PT09PT09 PT09PT09PT09PT09PT09PT09PQoKU2tpcHBpbmcgdGVzdDogbm90IGEgbmF0aXZlIFdpbmRvd3Mg c3lzdGVtClNLSVAgdGVzdC13Y3J0b21iLXczMi0zLnNoIChleGl0IHN0YXR1czogNzcpCgpTS0lQ OiB0ZXN0LXdjcnRvbWItdzMyLTQuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09CgpTa2lw cGluZyB0ZXN0OiBub3QgYSBuYXRpdmUgV2luZG93cyBzeXN0ZW0KU0tJUCB0ZXN0LXdjcnRvbWIt dzMyLTQuc2ggKGV4aXQgc3RhdHVzOiA3NykKClNLSVA6IHRlc3Qtd2NydG9tYi13MzItNS5zaAo9 PT09PT09PT09PT09PT09PT09PT09PT09PT0KClNraXBwaW5nIHRlc3Q6IG5vdCBhIG5hdGl2ZSBX aW5kb3dzIHN5c3RlbQpTS0lQIHRlc3Qtd2NydG9tYi13MzItNS5zaCAoZXhpdCBzdGF0dXM6IDc3 KQoK --_005_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_ Content-Type: application/x-shellscript; name="build_guix_from_sources.sh" Content-Description: build_guix_from_sources.sh Content-Disposition: attachment; filename="build_guix_from_sources.sh"; size=1241; creation-date="Sun, 11 Mar 2018 15:45:53 GMT"; modification-date="Sun, 11 Mar 2018 15:45:53 GMT" Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2gKc2V0IC1vIGVycmV4aXQKCnByZWZpeF9pbnN0YWxsPS9ob21lL3Rlc3RfdXNl cjIvLmxvY2FsCnNyY19kaXI9JHtwcmVmaXhfaW5zdGFsbDo/fS91c3Ivc3JjCnNyY19pbnN0YWxs PSR7c3JjX2Rpcjo/fS9ndWl4Cmd1aXhfc3RvcmU9L3Zhci90bXAvdGVzdF9ndWl4L2dudS9zdG9y ZQpndWl4X3N0YXRlPS92YXIvdG1wL3RldHNfZ3VpeC92YXIvZ3VpeApndWl4X2JyYW5jaD0ndjAu MTQuMCcKClsgLXogIiRDTEVBTkVEIiBdIFwKICAgICYmIGd1aXhfYmluPSIvdXNyL2xvY2FsL2Jp bi9ndWl4IiBcCiAgICAmJiBleGVjIGVudiAtaSBDTEVBTkVEPTEgJHtndWl4X2Jpbn0gZW52aXJv bm1lbnQgZ3VpeCAtLWFkLWhvYyBcCiAgICAgICAgICAgIGF1dG9tYWtlIGJhc2gtbWluaW1hbCBi emlwMiBnY2MtdG9vbGNoYWluIGdldHRleHQtbWluaW1hbCBnaXQgZ251dGxzIFwKICAgICAgICAg ICAgZ3JhcGh2aXogZ3VpbGUgZ3VpbGUtZ2l0IGd1aWxlLWpzb24gZ3VpbGUtc3NoIGd6aXAgaGVs cDJtYW4gbGliZ2NyeXB0IFwKICAgICAgICAgICAgbnNzLWNlcnRzIHNxbGl0ZSB0ZXhpbmZvIHps aWIgXAogICAgICAgICAgICAtLSBiYXNoIC0tbG9naW4gLS1ub3Byb2ZpbGUgLS1ub3JjICIkezA6 P30iICIke0AtfSIKCmVjaG8gIj09PT0gRElTUExBWSBFTlYgPT09PT0iCmVudgplY2hvICI9PT09 ID09PT0iCgojIyMjIwojIFBSRVBBUkUgU09VUkNFUwojIyMjIwplY2hvICI9PT09IFByZXBhcmlu ZyBzb3VyY2VzID09PT09IgoKbWtkaXIgLXAgJHtzcmNfZGlyOj99Cm1rZGlyIC1wICR7Z3VpeF9z dG9yZTo/fSAke2d1aXhfc3RhdGU6P30KCmlmIFtbIC1kICR7c3JjX2luc3RhbGw6P30gXV07dGhl bgogICAgY2QgJHtzcmNfaW5zdGFsbDo/fQogICAgZ2l0IGZldGNoIC0tYWxsIC0tcmVjdXJzZS1z dWJtb2R1bGVzCmVsc2UKICAgIGdpdCBjbG9uZSAtLXJlY3Vyc2UgaHR0cHM6Ly9naXQuc2F2YW5u YWguZ251Lm9yZy9naXQvZ3VpeC5naXQgJHtzcmNfaW5zdGFsbDo/fQpmaQpjZCAke3NyY19pbnN0 YWxsOj99CmdpdCBjaGVja291dCAke2d1aXhfYnJhbmNoOj99CmdpdCBjbGVhbiAtZCAteCAtZgou L2Jvb3RzdHJhcAouL2NvbmZpZ3VyZSAtLXdpdGgtc3RvcmUtZGlyPSR7Z3VpeF9zdG9yZTo/fSAt LWxvY2Fsc3RhdGVkaXI9JHtndWl4X3N0YXRlOj99CmVjaG8gIj09PT0gPT09PSIKCiMjIyMKIyBC VUlMRElORwojIyMjCmVjaG8gIkJ1aWxkaW5nLi4uLi4iCm1ha2UgLWogOAo= --_005_DB6P18901MB002262D076C3BE3D6D9BAF16DBDC0DB6P18901MB0022_-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 11 19:20:56 2018 Received: (at 30768) by debbugs.gnu.org; 11 Mar 2018 23:20:56 +0000 Received: from localhost ([127.0.0.1]:55834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evAGt-0001mO-Eb for submit@debbugs.gnu.org; Sun, 11 Mar 2018 19:20:56 -0400 Received: from mail-oln040092064093.outbound.protection.outlook.com ([40.92.64.93]:62285 helo=EUR01-DB5-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ev79j-0005Bq-KM for 30768@debbugs.gnu.org; Sun, 11 Mar 2018 16:01:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PTzPrZ/7gr03IiBrge3yIS9ddT5ThUViII3+aGecA1o=; b=mNNy6oZdDhnqezNcX5h4Nqe6i9tVrW+nVZOKo1pBxBy7JghpUlMmdxAxT2msUUlLMYsuoWwaa3ij9ZeQ7L+4AUlti8s23DXzCiYibf2WRhQEG1gB+lcVR3LWs1jgb2DPn19iac6VopY/JM66zpvaN+7cFsoX2uX4KEiclNXFZJcSSNkXmWwfy4EIOS6Z/IFGw8eD9dWiHdSdgNKYcQNw2/vVyRVraAYcaSv1kmjooOg58BJF+ooijLlNVICH+mNvpgnIAbIj82t92yX/DLDBIz5fSU/mmNHctZsFkeDbJQAyOq2JBnr5WF2IaSaJBVQeegiBd6qZcDi+gIbvfLZ2CQ== Received: from HE1EUR01FT012.eop-EUR01.prod.protection.outlook.com (10.152.0.59) by HE1EUR01HT220.eop-EUR01.prod.protection.outlook.com (10.152.1.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.22; Sun, 11 Mar 2018 20:01:12 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM (10.152.0.57) by HE1EUR01FT012.mail.protection.outlook.com (10.152.0.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15 via Frontend Transport; Sun, 11 Mar 2018 20:01:12 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82]) by DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82%13]) with mapi id 15.20.0567.018; Sun, 11 Mar 2018 20:01:12 +0000 From: YOANN P To: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> Subject: Re: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Topic: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Index: AQHTuXKa20ey3wEEckidOhjCtuUcJQ== Date: Sun, 11 Mar 2018 20:01:12 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:2E0C1FF3B03D84F7025E1CA51E3557C3C52724BE003489205AA69B15E6B2ED52; UpperCasedChecksum:4F4EADAF42E2A0D3CFD833BCD40FD567D9A659F70918E6258C086AE806652542; SizeAsReceived:6982; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [IDhsIrkoipJcViaaCH2xyiwJt6C01GE8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT220; 6:k1E+P9qtG42uxSkY6jiYjRFJrn96b+fGqOJQifoZ7p04CkpDqVUk19D9ysulwPo7z9A6zGWknO4FVxrk85nxpZoPRFATnjBQzrCQX3m1Pyj/MgzeIdSwiAtkAe4xns39dQ1FrzJkx/i4cyMqi3S/4vJugAl74dxtZ++pcLBJGG+ShJm6nvjdI2vSzcm8HPaioqIGThYSnsufHW9+x1l3mopsJy52jTCTSXlwA22eCR69Cpl0oHZlDV3IFqG/O/xBQM8i+gIIF69+2vMQeTwd4N6Xv+t8eSMUovdNdstMwTNGiKWUYYyNE9hpT2gLXIWdgV/y0HrmF7qvZ1eRv4w11B/DVy0Fl5xJsCd1GOLML2g=; 5:W26cr/FYVP53FMhEkRrgWNqu1xxnGEviUhLxY3YT0x19pbUACieWLvNOmh+Kn33LVBNValSGTXCc4neBK7Mc7jU5NtAYbQP58DYWasxZrTxybAkZzsGn1C7/+dD2c+pNsiWzJ1RAeiPnGzuKC2t0n9jDjNFQxZ4/Db1VqGcSRw8=; 24:eE8Huhx3NDutnI+Kql+uSS0aBXdoAoNlcCigcqs63mK3flMxaB9GuAJ8guceo7uex5aYV+HiWUqLQ5bGUY42eZ/xpolD/7GjgiVd2RtrJQk=; 7:jZrD5bRK2vmANY6mCeOaxBh0DUmNgzLbbmDbBd93/qtMIEGs6u51nHpsdgwbHQ01068VysWjK+zeX7KxHxafJk/d98uL6tztlsrPirTBwFp6Lj3IBgr+7t3gJSRrvumwX/fRgKV8+fKLEh5Jm60gHC6N01p8JR7c1iw1bEf4f8KSflb4LJQELsDJpNVUkc+6D2SLvS+LTFpkLm7oUrp7KBVEq08K+MYfbXRv+TQp77wqKg+DwTw4AcE8QyN3vWig x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HE1EUR01HT220; x-ms-traffictypediagnostic: HE1EUR01HT220: x-ms-office365-filtering-correlation-id: 4fdeac84-a9c4-4f5e-eb60-08d5878ad71e x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR01HT220; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR01HT220; x-forefront-prvs: 0608DEDB67 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT220; H:DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: U3bbOxBN9svWDDSe6x8IDdtg6xF2F2tg6xULB64KPlUfjgDukWcobiCDWL8WLaC6TfYVpr5SefneaJcZUOXMFKMMi0s+Vjwcefsp33h9LJ/EWFksw+xmShjsct1zoaTnMbRi/wXj8vhKKL47S3cpkITnjFfSEUBa2xmkGL2OVzob90HLUagp2WJ9nStiVKhX spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4fdeac84-a9c4-4f5e-eb60-08d5878ad71e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2018 20:01:12.6220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT220 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 30768 X-Mailman-Approved-At: Sun, 11 Mar 2018 19:20:53 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --_004_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_ Content-Type: multipart/alternative; boundary="_000_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_" --_000_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've add "/var/tmp" into the chroot directories inside nix/libstore/build.c= c with the attached patch (based on v0.14.0 tag) and the installation of ge= ttext and the other dependencies not yet installed seem to finished correct= ly. Is there someone who could validate than this patch is correct and is the c= orrect way to solve this problem before i try to submit my the patch mailin= g list ? :) Thanks, Best regards, --_000_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I've add "/var/tmp" int= o the chroot directories inside nix/libstore/build.cc with the a= ttached patch (based on v0.14.0 tag) and the installation of get= text and the other dependencies not yet installed seem to finished correctly.


Is there someone who = could validate than this patch is correct and is the correct way to solve t= his problem before i try to submit my the patch mailing list ? :)=


Thanks,=


Best regards,<= /span>

--_000_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_-- --_004_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_ Content-Type: text/x-patch; name="0001-Add-writable-var-tmp-to-chroot.patch" Content-Description: 0001-Add-writable-var-tmp-to-chroot.patch Content-Disposition: attachment; filename="0001-Add-writable-var-tmp-to-chroot.patch"; size=938; creation-date="Sun, 11 Mar 2018 19:59:38 GMT"; modification-date="Sun, 11 Mar 2018 19:59:38 GMT" Content-Transfer-Encoding: base64 RnJvbSBkODc5ZDlmYWU0MDUxMzFhNjA1ODYwMjYwZjAzNGQwZDRkY2M4NmU4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSb2NrQW5kU2thIDx5b2Fubl9tYWNfZG9uYWxkQGhvdG1haWwu Y29tPgpEYXRlOiBTdW4sIDExIE1hciAyMDE4IDIwOjQ4OjM0ICswMTAwClN1YmplY3Q6IFtQQVRD SF0gQWRkIHdyaXRhYmxlIC92YXIvdG1wIHRvIGNocm9vdAoKLS0tCiBuaXgvbGlic3RvcmUvYnVp bGQuY2MgfCA1ICsrKysrCiAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspCgpkaWZmIC0t Z2l0IGEvbml4L2xpYnN0b3JlL2J1aWxkLmNjIGIvbml4L2xpYnN0b3JlL2J1aWxkLmNjCmluZGV4 IGQ2OGU4YjIuLmFkMDhiM2EgMTAwNjQ0Ci0tLSBhL25peC9saWJzdG9yZS9idWlsZC5jYworKysg Yi9uaXgvbGlic3RvcmUvYnVpbGQuY2MKQEAgLTE4NDksNiArMTg0OSwxMSBAQCB2b2lkIERlcml2 YXRpb25Hb2FsOjpzdGFydEJ1aWxkZXIoKQogICAgICAgICBjcmVhdGVEaXJzKGNocm9vdFRtcERp cik7CiAgICAgICAgIGNobW9kXyhjaHJvb3RUbXBEaXIsIDAxNzc3KTsKIAorICAgICAgICAvKiBD cmVhdGUgYSB3cml0YWJsZSAvdmFyL3RtcCBpbiB0aGUgY2hyb290LiAqLworICAgICAgICBQYXRo IGNocm9vdFZhclRtcERpciA9IGNocm9vdFJvb3REaXIgKyAiL3Zhci90bXAiOworICAgICAgICBj cmVhdGVEaXJzKGNocm9vdFZhclRtcERpcik7CisgICAgICAgIGNobW9kXyhjaHJvb3RWYXJUbXBE aXIsIDAxNzc3KTsKKwogICAgICAgICAvKiBDcmVhdGUgYSAvZXRjL3Bhc3N3ZCB3aXRoIGVudHJp ZXMgZm9yIHRoZSBidWlsZCB1c2VyIGFuZCB0aGUKICAgICAgICAgICAgbm9ib2R5IGFjY291bnQu ICBUaGUgbGF0dGVyIGlzIGtpbmQgb2YgYSBoYWNrIHRvIHN1cHBvcnQKICAgICAgICAgICAgU2Ft YmEtaW4tUUVNVS4gKi8KLS0gCjIuNy40Cgo= --_004_DB6P18901MB0022308B270EB51633D14D13DBDC0DB6P18901MB0022_-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 12 09:47:33 2018 Received: (at 30768) by debbugs.gnu.org; 12 Mar 2018 13:47:33 +0000 Received: from localhost ([127.0.0.1]:56168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evNnX-0006ir-HN for submit@debbugs.gnu.org; Mon, 12 Mar 2018 09:47:33 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:51208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evNnV-0006ih-U6 for 30768@debbugs.gnu.org; Mon, 12 Mar 2018 09:47:30 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id BBA15123C5; Mon, 12 Mar 2018 14:47:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfd96MJRb0AS; Mon, 12 Mar 2018 14:47:26 +0100 (CET) Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 1E6CF123BC; Mon, 12 Mar 2018 14:47:26 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: YOANN P Subject: Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store References: Date: Mon, 12 Mar 2018 14:47:25 +0100 In-Reply-To: (YOANN P.'s message of "Sun, 11 Mar 2018 20:01:12 +0000") Message-ID: <87y3ixpfrm.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 30768 Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello Yoann, YOANN P skribis: > --- a/nix/libstore/build.cc > +++ b/nix/libstore/build.cc > @@ -1849,6 +1849,11 @@ void DerivationGoal::startBuilder() > createDirs(chrootTmpDir); > chmod_(chrootTmpDir, 01777); >=20=20 > + /* Create a writable /var/tmp in the chroot. */ > + Path chrootVarTmpDir =3D chrootRootDir + "/var/tmp"; > + createDirs(chrootVarTmpDir); > + chmod_(chrootVarTmpDir, 01777); We won=E2=80=99t apply this patch because in general there=E2=80=99s no rea= son for build processes to require /var/tmp (we=E2=80=99ve never encountered that.) That said, are you sure you want to use --with-store-dir=3D/var/tmp/xxxxx/gnu/store? You probably got a =E2=80=98configure=E2=80=99 warning already that certain= things may not work, for instance that the shebang max length may be exceeded. Also using a store other than /gnu/store means you won=E2=80=99t be able to= use substitutes, nor to compare build results with other machines. Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 12 15:37:03 2018 Received: (at 30768) by debbugs.gnu.org; 12 Mar 2018 19:37:03 +0000 Received: from localhost ([127.0.0.1]:57538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evTFn-0001Hu-2m for submit@debbugs.gnu.org; Mon, 12 Mar 2018 15:37:03 -0400 Received: from mail-oln040092070063.outbound.protection.outlook.com ([40.92.70.63]:45181 helo=EUR03-AM5-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evSxq-0000nV-P4 for 30768@debbugs.gnu.org; Mon, 12 Mar 2018 15:18:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PJ+QGeGW/Cf0BwizndC298ZTsUdsUoWAJgtFS2qTiuE=; b=nJW0LYQgMuyDPRnFwhLDD+SYwrb47FD1N1fpcxBr26PFGFe32ujIrtEoRZiBLZ5gAqaQBYKmUDFLYMwcFcH0vEAcLNHZzKhfAPKzaoXkJx8zzF4PdVsFX3qG5YcoCvIl4o+ANFzmPGOFRpHCjaYfADmoU2MrV2UKmN5CCWYscqTEozV1dmkqcRnN8xW1JgT5bEcenHfDjAB4hMfObGbnNHdWqu9G9AfKMOgyXsufYq+NiRhXssEp8bnoif5HOMfYUOqq9XZfFfLJwO5YJslhVMdPjmBKN6AmBvCQqMl+V87Z5+AhWR66+WLqVpM8A7L/adJwq3bv/la8R43Of5PNoA== Received: from DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com (10.152.20.51) by DB5EUR03HT046.eop-EUR03.prod.protection.outlook.com (10.152.21.0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.16; Mon, 12 Mar 2018 19:18:24 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM (10.152.20.60) by DB5EUR03FT048.mail.protection.outlook.com (10.152.21.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.16 via Frontend Transport; Mon, 12 Mar 2018 19:18:24 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82]) by DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82%13]) with mapi id 15.20.0567.018; Mon, 12 Mar 2018 19:18:24 +0000 From: YOANN P To: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> Subject: RE: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Topic: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Index: AQHTuXKa20ey3wEEckidOhjCtuUcJaPMnnK6gAA8gZo= Date: Mon, 12 Mar 2018 19:18:24 +0000 Message-ID: References: , <87y3ixpfrm.fsf@gnu.org> In-Reply-To: <87y3ixpfrm.fsf@gnu.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F79FD970D4AD4FC4FD554EFB188281D7DD5C14BFF103CC25ACB5D000D523C6B7; UpperCasedChecksum:0060B933648EE3BE21364BBBC4D9CFDC577CAF823E76B543591F375FB620C447; SizeAsReceived:7324; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [d/7dI6YKegO9QgtpDtbRjeKC6bwppq2e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5EUR03HT046; 6:ZNJdbieAj3MUazkNx3SB59gDErbGLpr33iWHLRbhZP2/Gas5C9Fna9/tNwUF29TJR47Qw2TkTTWaSPEFqjzLMJerrinUofl0l6yz5EP4iUfEtEe5EtDDpDkh+pLY0XzOC3KlKADqJ6fRyUtoW2YdwyT24IqS94eQxB9K1e8+46AjENSj5/lPppZf3RNOBGccVr6d011snVpHNscjT1beHOJzkeXjkuVWEzJS80ZPYvjzWpeC30oeiUWqkuibNMxDNNVNs7ZoLk6c8byBkpev/9HVK0ahzsmAinhE6UJ1Hhth/YP+VmVCeS583k3d/ug3GRLt7nnJ1+x3CCTXQCKnFf+k8FY6PxMDskqxESFPx0I=; 5:sPZyWHMzJJQ58g+VOnprHJMztMbnB/fWw6Vu2yaKGRpRbTviDlfY9UM2ZUhcAeT27Z0fxaFS6wVSJJerVBOhy4rG8Jc2+GiiTXXcS2F0vtSYEfEzWorjin21po9nCSB1IAouhSyCnS/pXKf5awpP39uxVVhrLh7mg1v681u8cUk=; 24:0/QpzQHxv9pBtzelqh49UlbUBhhMk4KFIC84MKRJd5Y+CSD/+GFlFg9xhfxFGb2sRB0wI5tx9xx8Q6d+20Qvz79jkKFza34lz5py/ReDzGw=; 7:QVqJZu9F2q5sbaQ/5DDUTz7zgt2JQsf0nGJJuPunnXwqmOROd6YkiE0Pi5CfJHo68iwMNInzVZ0Ut3ygfmQg6vUCKW40/mEab0SSaavCmVknJa2khHr/ZyQik4EoqIh9LULPvKUHHfgrEVYdOLLALFdnNmWfE8pX0Mk0g+wPPgW+0ueS4Zzud2tzUNSq59ivaWVg+jBEfMF+NDZxp2B9G+Cljk7ZvOBZF0ysdhfVz20g0A/p3r8oSslsil/tRPN5 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:DB5EUR03HT046; x-ms-traffictypediagnostic: DB5EUR03HT046: x-ms-office365-filtering-correlation-id: cbeb9f87-ff6a-4689-29c0-08d5884e06b6 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DB5EUR03HT046; BCL:0; PCL:0; RULEID:; SRVR:DB5EUR03HT046; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR03HT046; H:DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: IZJ6QR/DxkCUf8edDo/YRJk5wg6hyV+8KQTMxOg2MP7wzMzXGM7BeVunK2nAbr76mv6Owgoi/6thuXR8eUzN4AfcLSDPGE7GogGEwgw4KFL2KFAgeXbi7OCI9gz1q1GZeyE5EA9faH4hzmfquw6JVVAG/cj1oqDd2xzWWwTTHWtH04YOy/PLSEsPLxOCup2d spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbeb9f87-ff6a-4689-29c0-08d5884e06b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 19:18:24.2971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT046 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 30768 X-Mailman-Approved-At: Mon, 12 Mar 2018 15:37:02 -0400 Cc: =?Windows-1252?Q?Ludovic_Court=E8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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= From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 12 17:09:03 2018 Received: (at 30768) by debbugs.gnu.org; 12 Mar 2018 21:09:03 +0000 Received: from localhost ([127.0.0.1]:57563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evUgp-0003dY-Bz for submit@debbugs.gnu.org; Mon, 12 Mar 2018 17:09:03 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:54282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evUgn-0003d8-0P for 30768@debbugs.gnu.org; Mon, 12 Mar 2018 17:09:02 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 0452F12492; Mon, 12 Mar 2018 22:09:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0heF1CcpXJSO; Mon, 12 Mar 2018 22:08:59 +0100 (CET) Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 93DB912029; Mon, 12 Mar 2018 22:08:58 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: YOANN P Subject: Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store References: <87y3ixpfrm.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 22 =?utf-8?Q?Vent=C3=B4se?= an 226 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 12 Mar 2018 22:08:48 +0100 In-Reply-To: (YOANN P.'s message of "Mon, 12 Mar 2018 19:18:24 +0000") Message-ID: <87vae1knmn.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 30768 Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hi Yoann, YOANN P skribis: >> We won=E2=80=99t apply this patch because in general there=E2=80=99s no = reason for build >> processes to require /var/tmp (we=E2=80=99ve never encountered that.) > > There's always a first time. Since i didn't encounter this behavior with = other=20 > custom directories than i've tested, looking at the code of the test who = failed, > i suppose than the store dir is mounted inside the build chroot as itself= and is=20 > the reason why "/var/tmp" exist during the build with a store dir startin= g by=20 > "/var/tmp". > > Despite the fact that generally there=E2=80=99s no reason for build proce= sses to require=20 > /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or did= n't want to=20 > add it), maybe a warning about the fact than we should never use a direct= ory=20 > inside "/var/tmp" as store should maybe be add (it will had saving me man= y=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. In general we=E2=80=99re very cautious about changing what goes into the bu= ild environment. The daemon provides isolated build environments, and things will behave differently if we start adding/removing directories or files; even simple changes like this can easily hinder reproducibility. >> 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 soun= ds=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. OK, I see. That=E2=80=99s a worthy goal and a neat hack (I don=E2=80=99t t= hink it=E2=80=99s been tried before.) >> You probably got a =E2=80=98configure=E2=80=99 warning already that cert= ain things may >> 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 do= cs=20 > or did i missed it ? >From m4/guix.m4: --8<---------------cut here---------------start------------->8--- dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zer= o.) dnl The Hurd has a limit of about a page (see exec/hashexec.c.) m4_define([LINUX_HASH_BANG_LIMIT], 127) dnl Hardcoded 'sun_path' length in . m4_define([SOCKET_FILE_NAME_LIMIT], 108) --8<---------------cut here---------------end--------------->8--- >> Also using a store other than /gnu/store means you won=E2=80=99t 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. Understood. Are you in a situation where user namespaces are unavailable? HPC? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 13 19:49:03 2018 Received: (at 30768) by debbugs.gnu.org; 13 Mar 2018 23:49:04 +0000 Received: from localhost ([127.0.0.1]:60146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evtfD-0005EE-IQ for submit@debbugs.gnu.org; Tue, 13 Mar 2018 19:49:03 -0400 Received: from mail-oln040092068032.outbound.protection.outlook.com ([40.92.68.32]:14684 helo=EUR02-HE1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evtfB-0005Dg-E7 for 30768@debbugs.gnu.org; Tue, 13 Mar 2018 19:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pstXzOJZ0sIAYgfOK+7DTvBRLZbh0UBB5rG0TUfM+YQ=; b=ohqNFa+R8j6WOmcLO6mkc4lYY0vvuxI9G+4/Ry9mt9V8b6VHzNvvyDrx8gfZF16qEKYHPnUz8r76bOeA79BkMpcE1yi9nXGiKDSdUMsM7s9l5p2m+y/RDupaXpE9A22WU48//umBRErao8wAnrixNwwY+Vt4+NFdeMPE823u7Viao/ETWt6o9ZgUTJ7bsY3p/tPFg4X+X4y6fWUO/SQRxH9zkavkQR5TXN4O2sdwb2qSXBjX8s3Xul0p85TP46bmzIlkgwvX/4gmbI/2okYdzV3o1AHWNOO+4B30N2MY2lJx47JMx+1icLkryy5tTpGyoysRibdIJsXfBeYYedtMpg== Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (10.152.12.55) by VE1EUR02HT127.eop-EUR02.prod.protection.outlook.com (10.152.13.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.22; Tue, 13 Mar 2018 23:48:55 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM (10.152.12.52) by VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.22 via Frontend Transport; Tue, 13 Mar 2018 23:48:54 +0000 Received: from DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82]) by DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM ([fe80::6c30:a849:7a2b:f82%13]) with mapi id 15.20.0567.018; Tue, 13 Mar 2018 23:48:54 +0000 From: YOANN P To: =?Windows-1252?Q?Ludovic_Court=E8s?= Subject: RE: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Topic: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store Thread-Index: AQHTuXKa20ey3wEEckidOhjCtuUcJaPMnnK6gAA8gZqAAD7Zi4ABpeIn Date: Tue, 13 Mar 2018 23:48:54 +0000 Message-ID: References: <87y3ixpfrm.fsf@gnu.org> , <87vae1knmn.fsf@gnu.org> In-Reply-To: <87vae1knmn.fsf@gnu.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:AFC1AC7B06E8299AF531B6485283E2E5B5AE95541235AF9849D88DACFD1FA7E6; UpperCasedChecksum:9FDD0D791988AC367B6C7AD033EBAFC5E2DE0E4503A713ACF071DA2880BE1732; SizeAsReceived:7425; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [hypXsVb1j1n/IDBTtLm81IpmmtqGfU1J] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VE1EUR02HT127; 6:UJmJ7JYy1a+sbsTyrq30hU6+5adRBiRNuzlXc50aPwPXcVbAdEBx9A/N7vm8FrwA/z0UUwiVlhTfKZDeuFVIZ9X/O6/6OE8ubKQc+eczXeu/zs9MDOiPicOsuevVGUec7acw9ioqfwlzbEcIp1xi9ZO0Khp/QIKVBgITANdf5PJe9NEi7f9B6Xan8RrNuM3JELrJG63KTkWaPBBJKZPXw/JnIgTmGVQhkoPSoTVGSsj2umU3t1aqJ1V0AIP+9z9sLXM7OwjuNoCHfianStup8rNZ74xN20T0jcE97sQgTKITx/PVkdLd/Y/UkOvJmB0wFx7kd2BEfWiUGaUIHuDD1I8FNq+4NkJ3OrBlcRnu0I8=; 5:ubzORWjHmmS+YYu52JvVsmZiNIgS8IOJTvjwDYB8FuwWH45PN7qgluqU8kMZfRT4vUc7xQP+Ew039nvEBfUg2VGSiVGq2SGj6Gab6oBEbXKRmu2dQAdiBPWJ6lfTA7jzgLv2vGafjKpi+TPSP69bO1y5RcPxwUTm1s2yu/0pidk=; 24:FkMedkb5fj4VCBSNS1mzDVQOdPgxz1MUtJGdyI91MhnHi6n+q3nLlOPIdgoEPbDO49YPs3koZlmj93i6GcsNLJZywN3wMmHtAbdo0xWml7M=; 7:rt1jtaL6AKApS78sOnzAIrh2Z0XXGkVoQa2I7VvsSrTaqLjAV6XcrFf1MWWpZNLHc25cALvJ5cZmTM66CMXNvPNN/UpUWFUmb7Tm0wGQv5BtP/OhQYpmb/16CO8BEt1AdkzxHl3m1pbF8vmiwcAFdjwKWebaXenCrERturJDGsJd4L7nZBx0eBlWDk9qIFhE3fz2Zp6LJJ9Rknsuy8S+IiDQkvD1C6le4fbMXotv0ZeALq1SGK2Wmjj/f8JOzKQg x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:VE1EUR02HT127; x-ms-traffictypediagnostic: VE1EUR02HT127: x-ms-office365-filtering-correlation-id: ad8e6343-8503-44cd-2032-08d5893cfb33 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:VE1EUR02HT127; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR02HT127; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:VE1EUR02HT127; H:DB6P18901MB0022.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: 087rFNOHACEmxfQ1Jw0ZDEQE4L6RD/ud5L8eZYDAJpqEMn6oGJOzW2w681Dsos4j4pKl35nvsTQe1ZAqM3WkRwXBqyhtFIrDReXAf8GMR8ifHvP6C2sWq4zbaqS1ztV8iavZ0666xvOXA6V4jSN++2/HmRaSoIcgxUcZlprcLRq4/rXGmF7YCLpofZZ85hUb spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad8e6343-8503-44cd-2032-08d5893cfb33 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2018 23:48:54.7799 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT127 X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 30768 Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo, >Hi Yoann, > >YOANN P skribis: > >>> We won=92t apply this patch because in general there=92s no reason for = build >>> processes to require /var/tmp (we=92ve never encountered that.) >> >> There's always a first time. Since i didn't encounter this behavior with= other=20 >> custom directories than i've tested, looking at the code of the test who= failed, >> i suppose than the store dir is mounted inside the build chroot as itsel= f and is >> the reason why "/var/tmp" exist during the build with a store dir starti= ng by=20 >> "/var/tmp". >> >> Despite the fact that generally there=92s no reason for build processes = to require >> /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or di= dn't want to >> add it), maybe a warning about the fact than we should never use a direc= tory=20 >> inside "/var/tmp" as store should maybe be add (it will had saving me ma= ny=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. > >In general we=92re very cautious about changing what goes into the build >environment.=A0 The daemon provides isolated build environments, and >things will behave differently if we start adding/removing directories >or files; even simple changes like this can easily hinder >reproducibility. > Indeed. If I keep to persist with my patch applied inside my test env, we'll see if= =20 i hit some bug, but i'm pretty sure that your continuous deployment already= =20 test if this kind of patch have an impact on the builds. >>> That said, are you sure you want to use=20 >>> --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 sou= nds=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. > >OK, I see.=A0 That=92s a worthy goal and a neat hack (I don=92t think it= =92s >been tried before.) > Maybe if it hasn't test before, there was a good reason ;) Like the fact I wasn't aware of this kind of patch who seems to prevent the= =20 daemon to access directly the store via a direct symlink but require to sym= link=20 the upper directory. https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protec= tion >>> You probably got a =91configure=92 warning already that certain things = may >>> 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 d= ocs=20 >> or did i missed it ? > >>From m4/guix.m4: > >--8<---------------cut here---------------start------------->8--- >dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing ze= ro.) >dnl The Hurd has a limit of about a page (see exec/hashexec.c.) >m4_define([LINUX_HASH_BANG_LIMIT], 127) > >dnl Hardcoded 'sun_path' length in . >m4_define([SOCKET_FILE_NAME_LIMIT], 108) >--8<---------------cut here---------------end--------------->8--- > Hum, i'm not sure this part of code answer my question :) Are we agreed than LINUX_HASH_BANG_LIMIT is the max number of char for a=20 shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file na= me ? What i was asking is the maximum lenght for the store path regarding the fa= ct=20 (if i am not wrong) than a shebang inside guix is compose like this : [store_path]/[build_hash]-[program_name]-[program_version]/bin/[program_nam= e] - is there a convention who defined the maximum lenght of a program version= string ?=20 (1.1.1, 1.1.1-rc1, 1.1.1-beta) - is there a convention who defined the maximum lenght of a program name ?= =20 I think than if there is no limit for those two strings inside the store, w= e can't exactly know=20 the maximum lenght for the store path but maybe you have a quick way to loo= kup at=20 the maximum lenght for thoses two strings in all guix builds ? >>> Also using a store other than /gnu/store means you won=92t be able to u= se >>> 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. > >Understood. > >Are you in a situation where user namespaces are unavailable?=A0 HPC? Not at all, i was just playing with Guix to see if it can fulfill my long d= esires to have=20 an easy unprivileged portable environment due to old habits to intervene in= to some=20 hostiles environments in my previous job. The need to use "proot" / "usernamespace" keep the huge benefit that is the= use of=20 substitutes but require to rewrite all commands present inside the profile. I had first thinked to try to write a guix-wrapper who create small launche= rs for binaries=20 found inside a profile and add the directory containing the launchers in PA= TH but paused=20 this idea because i didn't find yet how you could easily fully bind "/" (re= ad-only) inside NS , but=20 overwrite some specific files and directories like a docker container (need= to test=20 bubblewrap, Proot seems to be able to achieve it). i'll try to re-think about scripting a launcher generator soon, because i t= hink it is by far a=20 better option than my hat trick with /var/tmp :) > >Thanks, >Ludo=92. Regards, Yoann= From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 14 05:33:55 2018 Received: (at 30768) by debbugs.gnu.org; 14 Mar 2018 09:33:56 +0000 Received: from localhost ([127.0.0.1]:60390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ew2nD-0001fz-NI for submit@debbugs.gnu.org; Wed, 14 Mar 2018 05:33:55 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:40224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ew2nB-0001fp-RE for 30768@debbugs.gnu.org; Wed, 14 Mar 2018 05:33:55 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C21DC12963; Wed, 14 Mar 2018 10:33:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Boj3nLzTrV3b; Wed, 14 Mar 2018 10:33:51 +0100 (CET) Received: from ribbon (unknown [IPv6:2a01:e0a:1d:7270:af76:b9b:ca24:c465]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 81F911294A; Wed, 14 Mar 2018 10:33:51 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: YOANN P Subject: Re: bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store References: <87y3ixpfrm.fsf@gnu.org> <87vae1knmn.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 24 =?utf-8?Q?Vent=C3=B4se?= an 226 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 14 Mar 2018 10:33:51 +0100 In-Reply-To: (YOANN P.'s message of "Tue, 13 Mar 2018 23:48:54 +0000") Message-ID: <87bmfrypa8.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 30768 Cc: "30768@debbugs.gnu.org" <30768@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Hello, YOANN P skribis: >>YOANN P skribis: [...] >>> 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 ? >> >>>From m4/guix.m4: >> >>--8<---------------cut here---------------start------------->8--- >>dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing z= ero.) >>dnl The Hurd has a limit of about a page (see exec/hashexec.c.) >>m4_define([LINUX_HASH_BANG_LIMIT], 127) >> >>dnl Hardcoded 'sun_path' length in . >>m4_define([SOCKET_FILE_NAME_LIMIT], 108) >>--8<---------------cut here---------------end--------------->8--- >> > > Hum, i'm not sure this part of code answer my question :) > Are we agreed than LINUX_HASH_BANG_LIMIT is the max number of char for a= =20 > shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file = name ? Yes. > What i was asking is the maximum lenght for the store path regarding the = fact=20 > (if i am not wrong) than a shebang inside guix is compose like this : The only limit here is PATH_MAX. >>Are you in a situation where user namespaces are unavailable?=C2=A0 HPC? > > Not at all, i was just playing with Guix to see if it can fulfill my long= desires to have=20 > an easy unprivileged portable environment due to old habits to intervene = into some=20 > hostiles environments in my previous job. Then I strongly recommend using it as documented, i.e., using /gnu/store as the store and running guix-daemon as root. You can=E2=80=99t really get around it: https://guix-hpc.bordeaux.inria.fr/blog/2017/09/reproducibility-and-root-= privileges/ Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 15 05:31:18 2018 Received: (at control) by debbugs.gnu.org; 15 Mar 2018 09:31:18 +0000 Received: from localhost ([127.0.0.1]:34037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewPED-0004bp-Uo for submit@debbugs.gnu.org; Thu, 15 Mar 2018 05:31:18 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:52934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewPEB-0004bf-RN for control@debbugs.gnu.org; Thu, 15 Mar 2018 05:31:16 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 268EC11776 for ; Thu, 15 Mar 2018 10:31:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8iPcQJOnJUR for ; Thu, 15 Mar 2018 10:31:14 +0100 (CET) Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 45DA210437 for ; Thu, 15 Mar 2018 10:31:14 +0100 (CET) Date: Thu, 15 Mar 2018 10:31:13 +0100 Message-Id: <873711wuqm.fsf@gnu.org> To: control@debbugs.gnu.org From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: control message for bug #30768 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) tags 30768 wontfix close 30768 From unknown Fri Jun 13 15:06:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 12 Apr 2018 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator