From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6616615978640867328 X-Received: by 2002:a1c:f609:: with SMTP id w9-v6mr275906wmc.5.1541756278422; Fri, 09 Nov 2018 01:37:58 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:5287:: with SMTP id c7-v6ls238197wrv.14.gmail; Fri, 09 Nov 2018 01:37:57 -0800 (PST) X-Google-Smtp-Source: AJdET5cpDcS0N9+4DTiB1hjTyM8CtutM04p3JEDkI3rhqeqSNBxCoQw28epos4jFeZfqsQew9F9c X-Received: by 2002:adf:e50f:: with SMTP id j15-v6mr1549331wrm.5.1541756277926; Fri, 09 Nov 2018 01:37:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541756277; cv=none; d=google.com; s=arc-20160816; b=fPT2/cAGPN8vzbeN7lfNuSfO5BVh5GPW46Z5IS5F9iskH17G1eKrFbg1KlBFmJgUw3 qNLIdiuGs36PK8p9PJ2e/rUAd3x5knxCVhii1NcHRsNjmOpurx28HNptELfn4qs5DKdu hNKIm1PvbG0q+OyFkyWroxvOUBIb2Af91uDtQsca4l9n8ysU1diNN5DL9QyBzpCJWXol a6ZOMvZBZ6cMqoz+FgxKOZUlwqLgi1rk0tmouDaCtXx+fac4I+8c6WYPnJWDGpvXcEPc 0blUFf76VB4WF3Umu7ery8sLQbEOuYjzZOgRDapbY+6YU3MUf9DyGqoGAnGxAFe/B2Ux SWFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=zQ6ymxPMvbsukXgEsLR3hz794pgiRB5qUay7OFaJdcg=; b=i0R+LCXYLy9vYjXaxnOzoiYfrCWBiYclFSsXPBb+XGO9osnVdokjVD9RC56dqhlMky 2Ub8yxZMKqod38yN6eCUvRaRgUQO/DSpvTtlOt1gX2nTPjq6VIHc+Etso7ZeeKvu8/h+ wV5aWFtbAZ7zAsCBt+eHtlQcgz1Iu1LBdBd2VBlqC8kYUpdcJPrZ7YE3vLmIh/cQk2ol CaTzQpldtEFo/uCbMaCxDh5lXzw/FRk+dpHJEnVbCKtOP1i2fSyzY5hvp3HBjv7EE4k0 7mB+oarY+eFMtH8JojfY9ESI64tzzBml2qw3Fd1s/qpvWwberzOjNTanOzn4vPofe3jb 3GzA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id 191-v6si49980wmv.0.2018.11.09.01.37.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 01:37:57 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id wA99bvlu030565 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Nov 2018 10:37:57 +0100 Received: from [139.22.36.91] ([139.22.36.91]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wA99buY7023646; Fri, 9 Nov 2018 10:37:56 +0100 Subject: Re: [PATCH] buildchroot: build debian packages as "builder" not "root" To: Henning Schild Cc: Maksim Osipov , isar-users@googlegroups.com References: <20181026104914.25581-1-henning.schild@siemens.com> <9fc6082e-49ae-2e9c-6331-90b80b66baf0@siemens.com> <20181108155423.590f43de@md1za8fc.ad001.siemens.net> <72142f4d-4ce4-b4a2-9fe4-8199a8fb6fa2@siemens.com> <20181109103412.7eca6a2a@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <3a22b503-1f3f-00ec-12c5-0d2360f8d84f@siemens.com> Date: Fri, 9 Nov 2018 10:37:56 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20181109103412.7eca6a2a@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: RqolRH79UXfu On 09.11.18 10:34, Henning Schild wrote: > Am Fri, 9 Nov 2018 10:14:51 +0100 > schrieb Jan Kiszka : > >> On 08.11.18 15:54, Henning Schild wrote: >>> Am Thu, 8 Nov 2018 14:32:42 +0100 >>> schrieb Jan Kiszka : >>> >>>> On 26.10.18 12:49, [ext] Henning Schild wrote: >>>>> We used to build packages as "root" and now do that as a regular >>>>> user. Not building as "root" allows us to find mistakes in >>>>> debian/rules where privileged operations are used while they >>>>> should not (a sudo was found in a rules-file). Further some build >>>>> steps might actually expect to not run as root (seen in openssl >>>>> test suite). >>>>> >>>>> Not building as root should increase overall quality and brings us >>>>> closer to how debian packages are build by others. >>>> >>>> I strongly suspect this is the cause for more and more rebuild >>>> errors of this kind: >>>> >>>> | make[1]: Leaving directory '/home/builder/u-boot/u-boot-v2018.09' >>>> | dh_clean -O--parallel >>>> | dpkg-source -I -b u-boot-v2018.09 >>>> | dpkg-source: warning: no source format specified in >>>> debian/source/format, see dpkg-source(1) | dpkg-source: warning: >>>> source directory 'u-boot-v2018.09' is not >>>> - 'u-boot-2018.09' | dpkg-source: >>>> info: using source format '1.0' | dpkg-source: info: building >>>> u-boot in u-boot_2018.09.tar.gz | dpkg-source: error: cannot write >>>> u-boot_2018.09.dsc: Permission denied | dpkg-source: info: building >>>> u-boot in u-boot_2018.09.dsc | dpkg-buildpackage: error: >>>> dpkg-source -I -b u-boot-v2018.09 gave error exit status 13 | >>>> WARNING: exit code 13 from a shell command. | ERROR: Function >>>> failed: do_build (log file is located >>>> at /work/build/tmp/work/long-life-ebsy-armhf/u-boot-2018.09-r0/temp/log.do_build.15761) >>>> >>>> Are we missing some cleandirs in dpkg[-base].class? >>> >>> Does the file exist and can not be written by builder, or does it >>> not exist and the dir must not receive new files. I am guessing the >>> former but have not clue why. >>> Maybe you can tell be how to reproduce this. >> >> The breakage comes from the UID and GID of builder inside the chroot. >> They are not in sync with the IDs used on the host side, so we can >> end up chown'ing to unknown user:group from host perspective. > > I am not sure i get that. Before it was "root:root" so whatever the > host (the thing where isar runs?) is doing must have been privileged > and should be able to deal with any uids. As the build was run as root, it didn't matter if IDs matched - they were overruled. Now they mismatch and there no power to paper over that anymore. > > The user and group names are only used within the buildchroot(s). Nope, there are also steps run outside of the chroot, in recipes. > > What i see is a dpkg-source ... so my guess is we are talking about > cross compile and the two chroots are not sync ... id-wise. Will the > WORKDIR be mounted first in one chroot and later in another? > >> Either ensure that the IDs are synchronized or revert this commit for >> now. > > I will send a patch once i have understood the problem. Still do not > know how to reproduce ... Cross-build (didn't test native, but I bet it will be similar) de0-nano-soc, e.g. Change some dpkg-based recipe to retrigger a build, and you will get. In my case, it was u-boot. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux