From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web10.18140.1683253041950283951 for ; Thu, 04 May 2023 19:17:22 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=d2Z4VasP; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: mikuback@linux.microsoft.com) Received: from [192.168.4.22] (unknown [47.201.8.94]) by linux.microsoft.com (Postfix) with ESMTPSA id 59F8120EA256; Thu, 4 May 2023 19:17:20 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 59F8120EA256 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1683253041; bh=6eMoGCgMbrHWR4n1l0mj4TN4r9cbpqKeYkUCWDXNuNs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=d2Z4VasPdoTA+G0fY9O6oge72exuu0+MVaWeUhhrgN4C0VwPtVxj5HpZ50MgqYLar H6Ulwd0x00W8Unift3P5XQcHLuBHjthEVwZL1ypFtFR1fFJcLyZVzS9ACeuRI93tSo q/YHskDz8vbEQDGZKNveTmTsyl52akdl0ZmPS+So= Message-ID: <59fc37f5-af65-5578-4b19-315a23edd101@linux.microsoft.com> Date: Thu, 4 May 2023 22:17:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ? To: devel@edk2.groups.io, michael.d.kinney@intel.com, "spbrogan@outlook.com" , "rebecca@bsdio.com" , Ard Biesheuvel , "Yao, Jiewen" , "Justen, Jordan L" , Gerd Hoffmann Cc: Sean Brogan , "Gao, Liming" References: <5970efe0-b520-f92d-db2f-6ed809ce4e55@bsdio.com> From: "Michael Kubacki" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mike, If I understand correctly, yes. For example, that's how we're pulling=20 the CodeQL CLI from the codeql-cli-binaries repo here: https://github.com/microsoft/mu_basecore/blob/release/202208/.pytool/Plugin= /CodeQL/codeqlcli_ext_dep.yaml If a repo (like a fork) needs to build and publish a tagged release, the=20 files can be attached to the release from either a pipeline (using=20 something like the GitHub REST API) or a GitHub workflow (using the=20 GitHub CLI pre-installed on agents) with a command like gh release=20 upload - https://cli.github.com/manual/gh_release_upload. For example, we have pipelines that apply semantic versioning and upload=20 release artifacts as zip files to the GitHub release: https://github.com/microsoft/mu_tiano_platforms/releases - Michael On 5/4/2023 1:21 PM, Michael D Kinney wrote: > Sean, >=20 > Can a GitHub release area for each dependency be used as an alternative= =20 > to nuget? >=20 > Mike >=20 > *From:* devel@edk2.groups.io *On Behalf Of *Sean > *Sent:* Wednesday, May 3, 2023 12:51 PM > *To:* devel@edk2.groups.io; rebecca@bsdio.com; Ard Biesheuvel=20 > ; Yao, Jiewen ; Justen,= =20 > Jordan L ; Gerd Hoffmann > *Cc:* Sean Brogan ; Michael Kubacki=20 > ; Kinney, Michael D=20 > ; Gao, Liming > *Subject:* Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency=20 > be updated from 20190215.0.0 ? >=20 > Rebecca, >=20 > I agree the iasl dependency for CI has not been managed consistently. = =20 > When all of the CI was setup we decided that iasl should be controlled=20 > by the platform and thus EmulatorPkg, ArmVirt, and OVMF have their own=20 > extdep.=C2=A0 This gives those platforms control to rev their version as= =20 > necessary for their platform.=C2=A0=C2=A0 We have found it very common in= platform=20 > development for platforms to have different required versions of iasl.exe= . >=20 > For Core CI (meaning just package builds) we managed iasl in Basetools. = =20 > We decided that this would only need to be updated when newer features=20 > were used by core components (not very often given the very little ASL=20 > in edk2 tree). >=20 > As for the feed.=C2=A0 Yes they are inconsistent.=C2=A0=C2=A0 We were mov= ing away from=20 > a global nuget.org feed as it just didn't seem necessary to push to=20 > nuget.org.=C2=A0 But now we are evaluating ways to move entirely away fro= m=20 > nuget.=C2=A0 Nuget.exe worked pretty well for Windows development and our= =20 > initial use cases but has definitely created a headache on Linux, MacOS= =20 > and other.=C2=A0 There really isn't a generic package management solution= =20 > that is supported cross platform that has free/high quality/secure=20 > hosting.=C2=A0 If anyone has ideas please share. >=20 > So my suggestion is to hold off for a couple of weeks (unless something= =20 > is broken) and lets see if we can use web downloads from github=20 > releases.=C2=A0 This should still allow consistency with tools, work cros= s=20 > platform, and give the flexibility needed per platform. >=20 > Regarding the steps in that document.=C2=A0 In that example it doesn't ca= ll=20 > out all the steps needed as that would just rehash the section before. = =20 > Instead it relies on a user having followed the generic steps in the=20 > section above (How to Build With Stuart =C2=B7 tianocore/tianocore.github= .io=20 > Wiki=20 > ).=C2=A0 For example the user would= need to have also done:=C2=A0 setup python virtual env, install pypi depen= dencies, and clone source + submodules. >=20 > Thanks >=20 > Sean >=20 > On 5/3/2023 12:34 PM, Rebecca Cran wrote: >=20 > I noticed OvmfPkg/PlatformCI/iasl_ext_dep.yaml specifies iasl > version 20190215.0.0 while BaseTools/Bin/iasl_ext_dep.yaml has the > newer 20200717.0.0, and "mono .../edk2toolext/bin/NuGet.exe list > -Source > https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/= v3/index.json " shows there's version 20210105.0.6 available. >=20 >=20 > Though OvmfPkg is using source https://api.nuget.org/v3/index.json > while BaseTools uses > https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/= v3/index.json - I don't know why they're different. >=20 >=20 > I was wondering if iasl_ext_dep.yaml should be updated? >=20 >=20 > Also, the example in > https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-Wi= th-Stuart of using stuart_build to build OVMF seems to be missing a s= tep: running "stuart_update -c PlatformBuild.py TOOL_CHAIN_TAG=3DGCC5 -a X6= 4" appears to be required otherwise stuart_build will complain that the ias= l dependency hasn't been met. >=20 >=20