[PATCH] dpkg-raw: Fix rebuilding recipes

[PATCH] dpkg-raw: Fix rebuilding recipes

[Harald Seiler]

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
 	cat<<-__EOF__ > ${D}/DEBIAN/control
 		Package: ${PN}
 		Architecture: ${DISTRO_ARCH}
-- 
2.14.1

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

[Jan Kiszka]

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.

Jan

>   	cat<<-__EOF__ > ${D}/DEBIAN/control
>   		Package: ${PN}
>   		Architecture: ${DISTRO_ARCH}
> 

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

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

[Harald Seiler]

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

I have seen this error with a lot of different packages so I am pretty certain that it
is not a bug in the recipes I tested.

Harald

> >   	cat<<-__EOF__ > ${D}/DEBIAN/control
> >   		Package: ${PN}
> >   		Architecture: ${DISTRO_ARCH}
> > 

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

[Jan Kiszka]

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.

Jan

> 
> I have seen this error with a lot of different packages so I am pretty certain that it
> is not a bug in the recipes I tested.
> 
> Harald
> 
>>>    	cat<<-__EOF__ > ${D}/DEBIAN/control
>>>    		Package: ${PN}
>>>    		Architecture: ${DISTRO_ARCH}
>>>
> 

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

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

[Jan Kiszka]

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

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

[Harald Seiler]

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.

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

-- 
Harald

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: hws@denx.de 

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

[Jan Kiszka]

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

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

[Henning Schild]

Am Tue, 9 Oct 2018 14:17:03 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

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

I once wrote a recipe for a customized debian package. Next to the
customization i also had to patch out an assertion that the build is
not allowed to run as root. So one thing to add to Isar would be to
actually create a user "builder" and do not build as "root".

That would have found the "sudo" and would never have triggered my
assertion. I doubt that debian folks build their packages as root ...

Henning

> Jan
> 
> > 
> > I have seen this error with a lot of different packages so I am
> > pretty certain that it is not a bug in the recipes I tested.
> > 
> > Harald
> >   
> >>>    	cat<<-__EOF__ > ${D}/DEBIAN/control
> >>>    		Package: ${PN}
> >>>    		Architecture: ${DISTRO_ARCH}
> >>>  
> >   
>