public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH 2/3] Revert "Change ownership of WORKDIR prior to unpacking"
Date: Thu, 15 Nov 2018 09:28:37 +0100	[thread overview]
Message-ID: <20181115092837.5e61f393@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <40092afd-a891-0b0e-4dd2-9752f16f59f1@siemens.com>

Am Wed, 14 Nov 2018 16:45:36 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 14.11.18 16:43, Henning Schild wrote:
> > Am Wed, 14 Nov 2018 15:11:39 +0100
> > schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:
> >   
> >> Am Wed, 14 Nov 2018 14:58:57 +0100
> >> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >>  
> >>> On 14.11.18 14:23, Jan Kiszka wrote:  
> >>>> On 14.11.18 14:10, Jan Kiszka wrote:  
> >>>>> On 12.11.18 16:51, Henning Schild wrote:  
> >>>>>> We do not build as root anymore and the non-root uid/gid are
> >>>>>> now in sync between inside and outside the chroot.
> >>>>>>
> >>>>>> This reverts commit 624b7c484bf59940ac2a4114018f7d56892dc05e.
> >>>>>> ---
> >>>>>>     meta/classes/base.bbclass | 5 -----
> >>>>>>     1 file changed, 5 deletions(-)
> >>>>>>
> >>>>>> diff --git a/meta/classes/base.bbclass
> >>>>>> b/meta/classes/base.bbclass index fce1084..d4082de 100644
> >>>>>> --- a/meta/classes/base.bbclass
> >>>>>> +++ b/meta/classes/base.bbclass
> >>>>>> @@ -120,17 +120,12 @@ do_unpack[stamp-extra-info] =
> >>>>>> "${DISTRO}-${DISTRO_ARCH}" # Unpack package and put it into
> >>>>>> working directory python do_unpack() {
> >>>>>> -    import subprocess
> >>>>>> -
> >>>>>>         src_uri = (d.getVar('SRC_URI', True) or "").split()
> >>>>>>         if len(src_uri) == 0:
> >>>>>>             return
> >>>>>>         rootdir = d.getVar('WORKDIR', True)
> >>>>>> -    uid = str(os.getuid())
> >>>>>> -    subprocess.call('sudo chown -R ' + uid + ' ' + rootdir,
> >>>>>> shell=True) -
> >>>>>>         try:
> >>>>>>             fetcher = bb.fetch2.Fetch(src_uri, d)
> >>>>>>             fetcher.unpack(rootdir)
> >>>>>>       
> >>>>>
> >>>>> This possibly causes this regression:
> >>>>>
> >>>>> ERROR: expand-on-first-boot-1.0-r0 do_install: Function failed:
> >>>>> do_install (log file is located at
> >>>>> /work/build/tmp/work/ebsy-arm64/expand-on-first-boot-1.0-r0/temp/log.do_install.263)
> >>>>>
> >>>>> ERROR: Logfile of failure stored in:
> >>>>> /work/build/tmp/work/ebsy-arm64/expand-on-first-boot-1.0-r0/temp/log.do_install.263
> >>>>>
> >>>>> Log data follows:
> >>>>> | DEBUG: Executing shell function do_install
> >>>>> | install: cannot remove
> >>>>> '/work/build/tmp/work/ebsy-arm64/expand-on-first-boot-1.0-r0/image//lib/systemd/system/expand-on-first-boot.service':
> >>>>> Permission denied
> >>>>> | WARNING: exit code 1 from a shell command.
> >>>>> | ERROR: Function failed: do_install (log file is located at
> >>>>> /work/build/tmp/work/ebsy-arm64/expand-on-first-boot-1.0-r0/temp/log.do_install.263)
> >>>>>
> >>>>>       
> >>>>
> >>>> OK, that wasn't a "clean" re-build (rather a rebuild after the
> >>>> Isar update). Retesting with the same Isar version for build 1
> >>>> and 2.  
> >>
> >> Arghh ... on a side-note. I have a few Isar-CI partial rebuild
> >> patches in a queue, they target both dpkg and dpkg-raw.
> >>  
> >>> It persists, at least for dpkg-raw, and that is likely because of
> >>> the chroot we do for that package.  
> >>
> >> Yes.  
> > 
> > That actually revealed that we kept collecting changes in ${D} and
> > never cleaned it before install. I just sent a patch fixing that.
> > 
> > Next step will probably be to make the raw class use standard
> > debian/rules and just take the long dpkg-buildpkg route. Should not
> > be too hard to just write a debian/ folder that just does "make
> > install". Will look into that ...
> >   
> 
> Thanks, looking forward to test everything.

I have a working prototype of the idea, where dpkg-raw is basically
dpkg with a debianization step in front of it. Still looking into the
details because we now have a lot of debhelpers enforcing quality
standards.
And the debianization looks like it could make it into a general lib
that could be reused to debianize random sources.

Henning

> Jan
> 


  reply	other threads:[~2018-11-15  8:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 15:51 [PATCH 0/3] "root" to "builder" repair series Henning Schild
2018-11-12 15:51 ` [PATCH 1/3] buildchroot: Align UID and GID of builder user with caller Henning Schild
2018-11-13  7:53   ` Jan Kiszka
2018-11-14  7:32     ` Henning Schild
2018-11-14  8:31       ` [PATCH v2 " Jan Kiszka
2018-11-12 15:51 ` [PATCH 2/3] Revert "Change ownership of WORKDIR prior to unpacking" Henning Schild
2018-11-14 13:10   ` Jan Kiszka
2018-11-14 13:23     ` Jan Kiszka
2018-11-14 13:58       ` Jan Kiszka
2018-11-14 14:11         ` Henning Schild
2018-11-14 15:43           ` Henning Schild
2018-11-14 15:45             ` Jan Kiszka
2018-11-15  8:28               ` Henning Schild [this message]
2018-11-12 15:51 ` [PATCH 3/3] buildchroot: do not chown to builder:builder anymore Henning Schild
2018-11-14 12:55 ` [PATCH 0/3] "root" to "builder" repair series Maxim Yu. Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181115092837.5e61f393@md1za8fc.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox