From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=t5kxq0t0; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by groups.io with SMTP; Wed, 03 Apr 2019 21:09:13 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x344247b018258; Wed, 3 Apr 2019 21:09:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ZwZoOQOJICvItVW7nV7LuSg3fjRLhZXg2T6+hEAwaJI=; b=t5kxq0t0+NdNgxtjsiEAA+oAwmJ/U2ox5q5kh9azG4tUVBUq7PjLGXUQLoSShkgb92qk KFS4sdOEoD0DM5MlgzLUP2jSLz5uUzymom/2wdOW2RvkRGjQmGVyaNX9tCiVO0bw10Gg 5UASUCaxW1wgalUDaJaHXXdLPOtGy3Nu6trd1TOLz2ZoHXkvyOAZM+RwW9gZ+CI11amj vkJVBHZyzgh8MFUR9zufmJT4LglEBSryxZbJWs7mz/ePRTNWOdp7txY0E0A0FgHIXmo2 M3MaAxwq5CssWC72OM1i8javLYwEf/8f9EG8EIEyqg/5TyR13m34TI9zVE6lQ4rLPkbm Og== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2rmg295947-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 03 Apr 2019 21:09:12 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PPF002PE4VBHL80@mr2-mtap-s02.rno.apple.com>; Wed, 03 Apr 2019 21:09:12 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PPF00J0048FC900@nwk-mmpp-sz09.apple.com>; Wed, 03 Apr 2019 21:09:11 -0700 (PDT) X-Va-A: X-Va-T-CD: ea1bec8879b9bcbea0419a42a7adbdb1 X-Va-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-Va-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-Va-CD: 0 X-Va-ID: 8c2a9748-ce42-4d09-8b44-1dddd8f9af88 X-V-A: X-V-T-CD: ef31e1a95087e9c711fcd85c1c36f28f X-V-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-V-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-V-CD: 0 X-V-ID: 89c6e7d9-bb02-44a2-853c-743b18ce75a7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_02:,, signatures=0 Received: from [17.234.80.230] (unknown [17.234.80.230]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PPF00K154V9G240@nwk-mmpp-sz09.apple.com>; Wed, 03 Apr 2019 21:09:10 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master Date: Wed, 03 Apr 2019 21:09:06 -0700 In-reply-to: <734D49CCEBEEF84792F5B80ED585239D5C0CCA8C@SHSMSX104.ccr.corp.intel.com> Cc: Mike Kinney , Laszlo Ersek , "Bi, Dandan" , "Cetola, Stephano" , "Gao, Liming" , "Carsey, Jaben" To: devel@edk2.groups.io, ray.ni@intel.com References: <3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com> <9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0C69A2@SHSMSX104.ccr.corp.intel.com> <82ac9c41-e12d-7287-74f2-d8bea4516280@redhat.com> <565232dc-a0ff-7b1b-3a7c-9c6db0b26969@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0CCA8C@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_02:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_SCneP/axH6DGFhRkmYeZgw)" --Boundary_(ID_SCneP/axH6DGFhRkmYeZgw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Apr 3, 2019, at 8:42 PM, Ni, Ray wrote: > > Mike, Laszlo, > It's a good idea to store the shell binaries into the assets of each stable tag. > > If we go in this way, it means "build" requires network connection to download the > shell binary from the assets of a certain release. > Do you think it's acceptable? > Ray, The other option would be to have a configuration step, like installing Python or the C compilers, that copies the binary. You need a network connection to clone the git repo and to stay in sync with it. I guess you could model that as a git submodule, or actually have a script that grabs the binary you want from a remote system, and fall back to the local copy if you don't have a network connection. > Or we can separate the binary download and build into two phases so build phase > can be independent on network connection. > > Is there any known practice/solution for such requirement (stable sub-component binaries > needed by a production image generation)? > I think to some extent this kind of thing is driven by the customers build rules. Basically what the customer think of as their manifest of parts for software version X. It might be possible for a build script to do something like this to just grab a specific version of the EFI Shell. I guess HEAD could really come from the manifest of what version you want, and the initial setup could run this command to make sure a backup version of Shell.efi is present in case the network is not present. git archive --remote=ssh://host/pathto/repo.git HEAD Shell.efi I'm sure an organization building something as complex as an OS probably has custom tools to deal with the manifest, but we can probably do something simple with a script/makefile. Thanks, Andrew Fish > Thanks, > Ray > >> -----Original Message----- >> From: Kinney, Michael D > >> Sent: Thursday, April 4, 2019 5:47 AM >> To: Laszlo Ersek >; Ni, Ray >; Bi, >> Dandan >; devel@edk2.groups.io ; Kinney, Michael D >> > >> Cc: Cetola, Stephano >; Gao, Liming >> >; Carsey, Jaben > >> Subject: RE: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master >> >> Laszlo, >> >> A PREBUILD action looks like a good idea. >> >> Release artifacts in GitHub are available as an http link, so a python script to >> download into a path in the build output directory and referenced by >> DSC/FDF should work. >> >> We could even post shell binaries for the past couple edk2-stable tags >> because release content can be updated. >> >> Mike >> >>> -----Original Message----- >>> From: Laszlo Ersek [mailto:lersek@redhat.com] >>> Sent: Wednesday, April 3, 2019 9:07 AM >>> To: Kinney, Michael D ; Ni, Ray >>> ; Bi, Dandan ; >>> edk2-devel@lists.01.org >>> Cc: Cetola, Stephano ; Gao, Liming >>> ; Carsey, Jaben >>> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master >>> >>> On 04/03/19 17:49, Kinney, Michael D wrote: >>>> Laszlo, >>>> >>>> I think it makes sense to post validated shell >>> binaries >>>> with the edk2-stable tag releases. GitHub does >>> support >>>> this when a release tag is made. >>>> >>>> However, we would need to make it simple for a >>> platform >>>> to use a binary from that location. We may need some enhancements >>>> to pull in binary artifacts from >>> different >>>> locations to support a platform build that uses one >>> or >>>> more pre-built binaries. >>> >>> Can PREBUILD scripts (written by platform owners) download the >>> required binaries? >>> >>> Thanks, >>> Laszlo > > --Boundary_(ID_SCneP/axH6DGFhRkmYeZgw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Apr 3,= 2019, at 8:42 PM, Ni, Ray <ray.ni@intel.com> wrote:

Mike, Laszlo,
It's a good idea to store the shell binaries into the as= sets of each stable tag.

If we go in this way, it means "bu= ild" requires network connection to download the
shell binary from the assets of a certain release= .
Do you think it's acc= eptable?


Ray,

The other option would be to have a confi= guration step, like installing Python or the C compilers, that copies the b= inary. You need a network connection to clone the git repo and to stay in s= ync with it. I guess you could model that as a git submodule, or actually h= ave a script that grabs the binary you want from a remote system, and fall = back to the local copy if you don't have a network connection. 
<= div>

Or we can separate the binary download = and build into two phases so build phase
can be independent on network connection.

Is there any known practice/solution for such requirement (stable sub-com= ponent binaries
needed = by a production image generation)?


I think to some extent this kind of thing is driven by= the customers build rules. Basically what the customer think of as their m= anifest of parts for software version X.

 It might be possible for a build script to do something like this t= o just grab a specific version of the EFI Shell. I guess HEAD could really = come from the manifest of what version you want, and the initial setup coul= d run this command to make sure a backup version of Shell.efi is present in= case the network is not present. 
git archive --remote=3Dssh://host/pathto/repo.git<= /a> HEAD Shell.efi

I'm sure an organiza= tion building something as complex as an OS probably has custom tools to de= al with the manifest, but we can probably do something simple with a script= /makefile. 

Thanks,
 
Andrew Fish


Thanks,
Ray
-----Original Message-----
From: Kinney,= Michael D <mic= hael.d.kinney@intel.com>
Sent: Thursday, April 4, 2019= 5:47 AM
To: Laszlo Ersek <lersek@redhat.com>; Ni, Ray <ray.ni@intel.com>; Bi,
Dan= dan <dandan.bi@intel.c= om>; devel@edk2.groups.io; Kinney, Mic= hael D
<michael.d.kinney@intel.com>
Cc: Cetola, Stephan= o <stephano.ceto= la@intel.com>; Gao, Liming
<liming.gao@intel.com>; Carsey, Jaben <= ;jaben.carsey@intel.co= m>
Subject: RE: [edk2] [RFC] Plan to delete ShellBinPk= g from edk2/master

Laszlo,

A PREBUILD action looks like a good idea.

Release artifacts in GitHub are available as an http link, so a pyth= on script to
download into a path in the build output directo= ry and referenced by
DSC/FDF should work.

We could even post shell binaries for the past couple edk2-stable= tags
because release content can be updated.
<= br class=3D"">Mike

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]Sent: Wednesday, April 3, 2019 9:07 AM
To: Kinne= y, Michael D <m= ichael.d.kinney@intel.com>; Ni, Ray
<ray.ni@intel.com>; Bi, Dandan <<= a href=3D"mailto:dandan.bi@intel.com" class=3D"">dandan.bi@intel.com>= ;;
edk2= -devel@lists.01.org
Cc: Cetola, Stephano <stephano.cet= ola@intel.com>; Gao, Liming
<liming.gao@intel.com>; = Carsey, Jaben <jaben.carsey@intel.com>
Subject: Re: [ed= k2] [RFC] Plan to delete ShellBinPkg from edk2/master

On 04/03/19 17:49, Kinney, Michael D wrote:
Laszlo,

I think it= makes sense to post validated shell
binaries
with the edk2-stable tag r= eleases.  GitHub does
support
this when a release tag is made.

However, we would need to make it simple for a
platform
to use a binary from that location.  We may need some enhance= ments
to pull in binary artifacts from
different
locations= to support a platform build that uses one
or
more pre-built binaries.

Can PREBUILD scripts (written by p= latform owners) download the
required binaries?

Thanks,
Laszlo


--Boundary_(ID_SCneP/axH6DGFhRkmYeZgw)--