Updates the subhook submodule to point to a edk2 mirror repo.
Fixes recursive cloning of the edk2 submodule.

Cc: Peter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2660
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 roms/edk2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/edk2 b/roms/edk2
index b158dad150bf..4dfdca63a934 160000
--- a/roms/edk2
+++ b/roms/edk2
@@ -1 +1 @@
-Subproject commit b158dad150bf02879668f72ce306445250838201
+Subproject commit 4dfdca63a93497203f197ec98ba20e2327e4afe4
-- 
2.47.0

On Mon, 11 Nov 2024 at 10:07, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Updates the subhook submodule to point to a edk2 mirror repo.
> Fixes recursive cloning of the edk2 submodule.
>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2660
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  roms/edk2 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/roms/edk2 b/roms/edk2
> index b158dad150bf..4dfdca63a934 160000
> --- a/roms/edk2
> +++ b/roms/edk2
> @@ -1 +1 @@
> -Subproject commit b158dad150bf02879668f72ce306445250838201
> +Subproject commit 4dfdca63a93497203f197ec98ba20e2327e4afe4
> --
> 2.47.0

Shouldn't this also come with an update of the binaries?
I know that in this case there's not supposed to be any
change to the edk sources, but I kind of expected that the
process of "update the edk submodule" ought to be
standardised to the extent that it would produce new
binary blobs to match the submodule bump.

thanks
-- PMM

On Wed, Nov 13, 2024 at 03:57:58PM +0000, Peter Maydell wrote:
> On Mon, 11 Nov 2024 at 10:07, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > Updates the subhook submodule to point to a edk2 mirror repo.
> > Fixes recursive cloning of the edk2 submodule.
> >
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2660
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> >  roms/edk2 | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/roms/edk2 b/roms/edk2
> > index b158dad150bf..4dfdca63a934 160000
> > --- a/roms/edk2
> > +++ b/roms/edk2
> > @@ -1 +1 @@
> > -Subproject commit b158dad150bf02879668f72ce306445250838201
> > +Subproject commit 4dfdca63a93497203f197ec98ba20e2327e4afe4
> > --
> > 2.47.0
> 
> Shouldn't this also come with an update of the binaries?
> I know that in this case there's not supposed to be any
> change to the edk sources, but I kind of expected that the
> process of "update the edk submodule" ought to be
> standardised to the extent that it would produce new
> binary blobs to match the submodule bump.

That is an exception.  This adds only one commit, which changes the
'subhook' submodule URL to point to a different location (a mirror repo
in the tianocore project).  So it doesn't carry any actual code changes.

But it is needed if you want do a local build (without already having a
'subhook' submodule clone) because the old repo location is gone ...

take care,
  Gerd

On Wed, 13 Nov 2024 at 15:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 11 Nov 2024 at 10:07, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > Updates the subhook submodule to point to a edk2 mirror repo.
> > Fixes recursive cloning of the edk2 submodule.
> >
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2660
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> >  roms/edk2 | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/roms/edk2 b/roms/edk2
> > index b158dad150bf..4dfdca63a934 160000
> > --- a/roms/edk2
> > +++ b/roms/edk2
> > @@ -1 +1 @@
> > -Subproject commit b158dad150bf02879668f72ce306445250838201
> > +Subproject commit 4dfdca63a93497203f197ec98ba20e2327e4afe4
> > --
> > 2.47.0
>
> Shouldn't this also come with an update of the binaries?
> I know that in this case there's not supposed to be any
> change to the edk sources, but I kind of expected that the
> process of "update the edk submodule" ought to be
> standardised to the extent that it would produce new
> binary blobs to match the submodule bump.

(but since I've checked that in this case it really doesn't
need new binaries, I'm going to put this in for rc0 so
we don't have potentially more bug reports about the
sub-repo from users who try rc0.)

thanks
-- PMM