Re: [PATCH] buildchroot: build debian packages as "builder" not "root"

[Jan Kiszka <jan.kiszka@siemens.com>]

On 09.11.18 10:34, Henning Schild wrote:
> Am Fri, 9 Nov 2018 10:14:51 +0100
> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
>> On 08.11.18 15:54, Henning Schild wrote:
>>> Am Thu, 8 Nov 2018 14:32:42 +0100
>>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
>>>    
>>>> 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
>>>> <sourcepackage>-<upstreamversion> '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