From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6616615978640867328 X-Received: by 2002:a2e:9902:: with SMTP id v2-v6mr859286lji.6.1541762216434; Fri, 09 Nov 2018 03:16:56 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:2bda:: with SMTP id r87-v6ls117910ljr.0.gmail; Fri, 09 Nov 2018 03:16:55 -0800 (PST) X-Google-Smtp-Source: AJdET5cGT1b4GBwVCnGn0cxRT98P1vPwCySsiElGz6K19U5b/6La436FpEcuJtb86d0IMjXYQ+6p X-Received: by 2002:a2e:954b:: with SMTP id t11-v6mr855917ljh.28.1541762215775; Fri, 09 Nov 2018 03:16:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541762215; cv=none; d=google.com; s=arc-20160816; b=T5k06TEJ6scZN+tFZdv7cH0DydwHoAaU31uTgrxYqB7cR0SXwOJKkwRjnrUxm0ErDy T6nIYKhMq/5B19oJn7r8qlxxjl5QMLLzHiaqLezCVNpweQ4MoKSp9xZvdmIg21ssyw84 AoCVYkfASKhF/460k8QZSy3WhQFY53HAh381IdLXSeakaoVLBNDP5KMKEhLiH6klWadH bLi9cXURDh0XfNbAPjwvxfvC1JdzfZ2sGfNH9YBIfokdDqmPkNZe8IbuigAoqoe7cEWK ya6Bp0C1oTHrog1Kgk015dZUJAcakMD2puxqUtaMjndWP9RSh+cnykb9ohaGnK/LQswJ Rq/A== 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:references:cc:to:from:subject; bh=vCm4XyUSIJw2u08ppKPBO2mdVcbOe+p8YpVDTjd8Yf8=; b=ijR28m4wpMvBu04ymSHkSD7fGbYufVKEyPh7SI0xdyovch3b78xEpqAM1cQg8rmGbB StUuwHWSss2uW8p60ThAY6cV6e8M4SedbKxf/yxJblVPdZxSU79/9EV+mxEo+aQgKmI7 exMdIAQN3pR0zebCDBOSHzvRh83hi+Kx9V0QqIvM0GwXtijsVCx9+M2D9oZjCqQBVEIa kXibS29MzTyDNPCqTvsYjPv5bdSHoIx66kevmWKTDAtC/DCC8KtX2vHnbupLMaF7tc3L /42Ri8MXU6D17Tn/luGW4LI4RFizj/uNHSYu+qU5fEF4pGJwH/WWqdH9uS2Q4u3fC45H 69Ag== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id 205si223970lfb.2.2018.11.09.03.16.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 03:16:55 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id wA9BGs1e008828 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Nov 2018 12:16:55 +0100 Received: from [139.22.36.91] ([139.22.36.91]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wA9BGs45014920; Fri, 9 Nov 2018 12:16:54 +0100 Subject: Re: [PATCH] buildchroot: build debian packages as "builder" not "root" From: Jan Kiszka 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> <3a22b503-1f3f-00ec-12c5-0d2360f8d84f@siemens.com> Message-ID: <21e0e71f-485d-6e91-d4b7-2bbe93b01dce@siemens.com> Date: Fri, 9 Nov 2018 12:16:54 +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: <3a22b503-1f3f-00ec-12c5-0d2360f8d84f@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: w/YWNZs25rO5 On 09.11.18 10:37, Jan Kiszka wrote: > 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. > I just had to revert this commit: It started to block me as a build recipe under development got EPERM even during a clean build. We must fix the ID mess. Do you have anything in that direction already? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux