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

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

On 09.10.18 16:23, Harald Seiler wrote:
> On Tue, 2018-10-09 at 14:31 +0200, Jan Kiszka wrote:
>> 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.
> 
> Looks like it was an error in the recipes.  As far as I can tell, the faulty
> recipes all used some form of `sudo install` which messes up the permissions.
> Removing sudo fixed the issue.

Perfect!

> 
> It would be nice if this kind of mistake would be easier to detect. Maybe by
> adding a warning?

That could make sense if the detection pattern is generic enough.

Jan

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