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

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

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 <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.
> 

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