Re: [PATCH] dpkg-raw: Fix rebuilding recipes

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

On 09.10.18 14:17, [ext] Jan Kiszka wrote:
> On 09.10.18 12:28, Harald Seiler wrote:
>> On Tue, 2018-10-09 at 12:05 +0200, Jan Kiszka wrote:
>>> On 09.10.18 11:06, Harald Seiler wrote:
>>>> Rebuilding dpkg-raw packages fails because the
>>>> DEBIAN directories' ownership is transferred to
>>>> root in dpkg_runbuild.  This commit ensures the
>>>> ownership is reset before attempting to write
>>>> metadata.
>>>>
>>>> Signed-off-by: Harald Seiler <hws@denx.de>
>>>> ---
>>>>    meta/classes/dpkg-raw.bbclass | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
>>>> index c848f3d..806a2d4 100644
>>>> --- a/meta/classes/dpkg-raw.bbclass
>>>> +++ b/meta/classes/dpkg-raw.bbclass
>>>> @@ -18,7 +18,8 @@ addtask install after do_unpack before do_prepare_build
>>>>    deb_package_prepare() {
>>>>        sudo rm -rf ${D}/DEBIAN
>>>> -    mkdir -p ${D}/DEBIAN
>>>> +    sudo mkdir -p ${D}/DEBIAN
>>>> +    sudo chown ${USER}:${USER} ${D}/DEBIAN
>>>
>>> That makes no sense to me: We remove that folder first, and then create it under
>>> the name of the current user. These two changes are redundant in that light.
>>>
>>> Can you describe in more details what you did and how the error messages looked
>>> like? I frequently rebuild dpkg-raw packages and never saw such an issue 
>>> recently.
>>
>> Sure, the error message is the following:
>> mkdir: cannot create directory `[...]/image//DEBIAN`: Permission denied
>>
>> This makes sense, because image/ seems to somewhere get changed to be owned by 
>> root.
>> Because of this, the unprivileged mkdir fails when rebuilding.  The change I 
>> made is
>> to run mkdir as root and then change the ownership of the created directory.  
>> I chose
>> this solutuion because I did not want to touch the permissions of image/.
> 
> But if image has the wrong permissions/ownership, that is what should be 
> changed. It may actually cause other problems down the road.
> 

Actually, we should first of all understand what is causing this, if it is an 
Isar issue or maybe something downstream (check if your recipe doesn't do 
something special here). The dpkg-raw.bbclass itself only plays with the 
ownership of the DEBIAN folder, and it resolves that be purging it prior to the 
recreation. And if I check the Isar test case itself:

# ls -ld tmp/work/debian-stretch-amd64/example-raw-0.2-r0/image/
drwxr-xr-x 4 builder builder 4096 Oct  6 12:08 
tmp/work/debian-stretch-amd64/example-raw-0.2-r0/image/

Looks OK.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux