similar to: New gnu-efi release (3.0.5)

> Hi together, > > The gnu-efi project released in January a new version: 3.0.5. > > Unfortunately, I don't seem to be able to find a release-note or such. > > Fact is, syslinux has some difficulties building with that version. > Syslinux's devs might or might not reply to your email, so here are some comments, FWIW. If you mean that you have gnu-efi v.3.0.5

Signed-off-by: Beno?t Allard <benoit.allard at greenbone.net> --- efi/fio.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/efi/fio.h b/efi/fio.h index 65fff8d..a1bfe68 100644 --- a/efi/fio.h +++ b/efi/fio.h @@ -11,15 +11,6 @@ #define MAX_EFI_ARGS 64 #define WS(c16) (c16 == L' ' || c16 == CHAR_TAB) -/* VPrint is not in export declarations in gnu-efi lib yet

On Thu, 8 Jun 2017 17:19:41 +0000 Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > Hi together, > > > > The gnu-efi project released in January a new version: 3.0.5. > > > > Unfortunately, I don't seem to be able to find a release-note or > > such. > > > > Fact is, syslinux has some difficulties building with that version.

On Nov 25, 2014 12:30 AM, "Anatol Pomozov" <anatol.pomozov at gmail.com> wrote: > While we discuss gnu-efi. How difficult to make it using system-wide > installed library instead of checking out and building it? Some > systems already have gnu-efi packaged/installed. It makes sense to use > it. The first attempt was to do exactly that however Syslinux depended on too

> Syslinux depended on too many bleeding edge commits of gnu-efi to > make it viable. That _seems_ to be no longer accurate. The official 6.03 release (2014Oct06) was built based on the gnu-efi commit: ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999 from 2014Feb13. At the time Syslinux 6.03 was released, the build was no longer using a "bleeding edge" commit of gnu-efi (it was

> >>> > > How about > > 1) Laying every needed versions of gnu-efi under its own directory where > > its name could be just the version. > > 2) Defining the gnu-efi version to use in a Makefile variable; if the source > > is not present then the Makefile triggers the corresponding > > "check out" with git. > > > The

On Mon, 22 Dec, at 04:51:19PM, Gene Cumm wrote: > > Commit 6e832106 which originally created the shell scripts was the > first instance of this silencing. > > Aside from adding a few hundred lines of build output (which could be > beneficial), is there any reason not to remove the null redirects? There's no downside that I can see. Go for it. -- Matt Fleming, Intel Open

> On Mon, 22 Dec, at 04:51:19PM, Gene Cumm wrote: > > > > Commit 6e832106 which originally created the shell scripts was the > > first instance of this silencing. > > > > Aside from adding a few hundred lines of build output (which could be > > beneficial), is there any reason not to remove the null redirects? > > There's no downside that I can

On Mon, Dec 22, 2014 at 8:40 PM, Ady <ady-sf at hotmail.com> wrote: > >> On Mon, 22 Dec, at 04:51:19PM, Gene Cumm wrote: >> > >> > Commit 6e832106 which originally created the shell scripts was the >> > first instance of this silencing. >> > >> > Aside from adding a few hundred lines of build output (which could be >> >

The wiki: http://www.zytor.com/mailman/listinfo/syslinux says to use this to clone git with http rather than git protocol: git clone --recursive http://repo.or.cz/syslinux.git a-new-directory That works for the main project, but fails for the gnu-efi submodule, which specifies the git protocol in its .config file: $ git clone --recursive http://repo.or.cz/syslinux.git syslinux Cloning into

On 05/10/2013 06:27 AM, syslinux-bot for Matt Fleming wrote: > > diff --git a/efi/main.c b/efi/main.c > index 31f0bff..27e7f8f 100644 > --- a/efi/main.c > +++ b/efi/main.c > @@ -1177,13 +1177,10 @@ static void efi_setcwd(CHAR16 *dp) > > EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) > { > + EFI_PXE_BASE_CODE *pxe; > EFI_LOADED_IMAGE *info;

Hi all, I'm terribly sorry that I cannot follow emails in my gmail inbox, since gmail is blocked by China govement, as many of you may have already known. I'm a HP employee in China and we are going through the splitting process, so the blade server I was using were packed up and should be moved into a new room. I will try the latest source if possible. Thank you very much for your works.

2015-09-15 13:57 UTC+02:00, Patrick Masotta <masottaus at yahoo.com>: >>>> > > What's the default strategy for checking out new gnu-efi sources? > > We should have a way to set the version we want to work with > > and only update when we want to do so. > > That's true. All I did in these patches was to inline those shell > scripts in the

On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: > On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > Hi all, > > > > It has been the case for

FWIW, there are commits in gnu-efi after version 3.0.5 that seem to be relevant to these proposed patches. For example: http://sf.net/p/gnu-efi/code/ci/bf07e8141777e5a2d67ec8447084215224bdad4b One possibility could be to update the gnu-efi submodule in Syslinux so as to point at least to the above commit at the same time the Syslinux code is updated with the patches proposed here by Ben.

On Wed, Feb 6, 2019 at 2:35 PM H. Peter Anvin via Syslinux <syslinux at zytor.com> wrote: > > On 2/6/19 9:17 AM, Joakim Tjernlund via Syslinux wrote: > > On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: > >> On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: > >>> CAUTION: This email originated from outside of the organization. Do

From: Sylvain Gault <sylvain.gault at gmail.com> These few patches contain a few improvement about the Makefiles for EFI. Mainly, to rebuild the files when needed, and only when needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh disappeared and are now integrated as makefile recipes. You'll notice an argument ARFLAGS=rvU to the recursive make calls to gnu-efi. This is

The build would be failed and exit if build-gnu-efi.sh is failed, so we'd better not suppress the output of build-gnu-efi.sh, which is good for debugging. Signed-off-by: Robert Yang <liezhi.yang at windriver.com> --- efi/check-gnu-efi.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/check-gnu-efi.sh b/efi/check-gnu-efi.sh index 85305f8..7d99e9a 100755 ---

> The build would be failed and exit if build-gnu-efi.sh is failed, so > we'd better not suppress the output of build-gnu-efi.sh, which is good > for debugging. > > Signed-off-by: Robert Yang <liezhi.yang at windriver.com> > --- > efi/check-gnu-efi.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/efi/check-gnu-efi.sh

On 2/6/19 9:17 AM, Joakim Tjernlund via Syslinux wrote: > On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: >> On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: >>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>