From: Henning Schild <henning.schild@siemens.com>
To: <cedric_hombourger@mentor.com>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: dpkg-raw git fetch
Date: Tue, 10 Mar 2020 16:36:21 +0100 [thread overview]
Message-ID: <20200310163621.1d87716c@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <87825320-c0cc-4876-8b53-8c3fe6d30db2@googlegroups.com>
On Tue, 10 Mar 2020 08:08:27 -0700
<cedric_hombourger@mentor.com> wrote:
> On Monday, March 9, 2020 at 5:59:40 PM UTC+1, Henning Schild wrote:
> >
> > On Fri, 28 Feb 2020 13:08:10 +0000
> > "[ext] sven.sc...@siemens.com <javascript:>"
> > <sven.sc...@siemens.com <javascript:>>
> > wrote:
> >
> > > Hi,
> > >
> > > I'm a little bit confused. In the task unpack the SRC_URI files
> > > will be put into WORKDIR
> > >
> > https://github.com/ilbers/isar/blob/f3d50cfb9b7a5740c6dd11ee58fc4ba1a1815eca/meta/classes/base.bbclass#L182
> >
> > >
> > > But in the next task S (workdir/git) will be cleared.
> > >
> > https://github.com/ilbers/isar/blob/f3d50cfb9b7a5740c6dd11ee58fc4ba1a1815eca/meta/classes/dpkg-raw.bbclass#L15
> >
> > >
> > > Should I understand why ${S} will be cleard before do_install is
> > > called?
> >
> > I think you might have found an issue with the distinction of S and
> > D. In fact they should be different folders but for dpkg-raw they
> > are not. I think also the debianize class does not clearly
> > distinguish them.
> >
> >
> I coincidentally ran into the same issue yesterday and yes debianize
> assumes all the work should be done in ${S}
> should debianize expose a DEBIANIZE_DIR defaulting to ${S} and let
> dpkg-raw set it to ${D} instead?
Unfortunately bitbake/oe lack good descriptions of the two. But those
can be found here:
https://devmanual.gentoo.org/ebuild-writing/variables/ and probably
also in FreeBSD
That means that debianization should be done on S, not D.
And OE also has 'D = "${WORKDIR}/image"', which seems to be missing in
Isar.
Henning
> One workaround would be to create that second copy on your own. So
> you
> > clone i.e with destsuffix and make sure that the unpacked copy and
> > the installed copy are not the same directory.
> >
> > Once you have found a solution and have a clue where the line
> > between S and D should be drawn, please give feedback on how to
> > improve the class.
> >
> > Henning
> >
> > > Mit freundlichen Grüßen
> > > Sven Angelo Schultschik
> > >
> > > Siemens AG
> > > Digital Industries
> > > Process Automation
> > > Software House Khe
> > > DI PA CI R&D 2
> > > Östliche Rheinbrückenstr. 50
> > > 76187 Karlsruhe, Deutschland
> > > Tel.: +49 721 595-2827
> > > mailto:sven.sc...@siemens.com <javascript:>
> > >
> > > www.siemens.com/ingenuityforlife
> > >
> > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim
> > > Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch,
> > > Lisa Davis, Klaus Helmrich, Cedrik Neike, Michael Sen, Ralf P.
> > > Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland;
> > > Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB
> > > 6684; WEEE-Reg.-Nr. DE 23691322
> > >
> > > Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen enthalten
> > > firmenvertrauliche Informationen. Sollten Sie diese E-Mail
> > > irrtümlich erhalten haben, benachrichtigen Sie uns bitte durch
> > > Antwort-Mail und löschen Sie diese E-Mail nebst Anlagen von Ihrem
> > > System. Vielen Dank. -----Ursprüngliche Nachricht----- Von: Jan
> > > Kiszka <jan....@siemens.com <javascript:>> Gesendet: Donnerstag,
> > > 27. Februar
> > 2020 18:00
> > > An: Schultschik, Sven (DI PA CI R&D 2)
> > > <sven.sc...@siemens.com <javascript:>>; isar-...@googlegroups.com
> > >
> > <javascript:> Betreff:
> > > Re: dpkg-raw git fetch
> > >
> > > On 27.02.20 17:39, Schultschik, Sven (DI PA CI R&D 2) wrote:
> > > > Fetch does put the repository into the downloads folder.
> > > >
> > > > Which task is responsible to bring the files from
> > > > downloads/../git-repo to ${S} ??
> > >
> > > Right: unpack.
> > >
> > > > S = "${WORKDIR}/git" ist defined in the recipe.
> > > >
> > > > Log.unpack says clone -s -n downloads/git
> > > > recipe-name/version/git without an error
> > > >
> > > > Shouldn't the see the files then?
> > >
> > > Yes - provided the default revision checked out contains
> > > anything.
> > >
> > > Jan
> > >
> > > --
> > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
> > > Competence Center Embedded Linux
> > >
> >
> >
>
next prev parent reply other threads:[~2020-03-10 15:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 14:51 sven.schultschik
2020-02-27 14:58 ` Jan Kiszka
2020-02-27 16:39 ` AW: " sven.schultschik
2020-02-27 17:00 ` Jan Kiszka
2020-02-28 13:08 ` AW: " sven.schultschik
2020-02-28 13:46 ` Gylstorff Quirin
2020-03-09 16:59 ` Henning Schild
2020-03-10 15:08 ` cedric_hombourger
2020-03-10 15:36 ` Henning Schild [this message]
2020-04-03 10:06 ` Jan Kiszka
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=20200310163621.1d87716c@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=cedric_hombourger@mentor.com \
--cc=isar-users@googlegroups.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