Syslinux - Dec 2014 - check-gnu-efi.sh: print the output of build-gnu-efi.sh

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
many bleeding edge commits of gnu-efi to make it viable.  It also levels
the field such that everyone has the same version.

The only viable alternatives I can think of are:

1) Use our own repo.
2) Put a Makefile variable in to indicate to use system then check if
sufficient else fail the entire build.

Bear in mind this also complicates debugging.

--Gene

> 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 several months old and
dozens
of commits old). By the time I am writing this email, the Syslinux 
source code is still pointing to the same "old" commit and there are 
more than 50 newer ones in gnu-efi.

Although at some point there were reports (maybe it was just one, or 
two) that building with a specific newer commit of gnu-efi would fail, 
I believe that there should be a new attempt to build Syslinux with a 
newer gnu-efi commit / version, as to at least try to reduce the 
reported problems about syslinux.efi failing in certain VM environments 
(OVMF, KVM, whatever). I'm not saying it has to be now, but it might be 
worth testing this matter before the next pre-release (whenever it 
might occur).

In particular, the *gnu-efi.sh scripts in Syslinux should be tested 
with the new gnu-efi git tree (changed, 2014Nov25).
 
 
> It also levels the field such that everyone has the same version. 
Using a consistent version / commit of gnu-efi makes sense. Otherwise, 
the resulting behavior could be changing (or the build might fail for 
some reason), according to whichever version / commit is "freely"
used.
As I said above, it might be worth pointing the gnu-efi submodule to a 
newer "consistent" commit (or version) and resolve any potential
issues
with it before the next Syslinux pre-release.  

Regards,
Ady.

I really think we should not take chances;
Syslinux source should include (probably as an optional download tarball)
the gnu-efi used to build the particular Syslinux version.

Pat


--------------------------------------------
On Mon, 12/22/14, Ady <ady-sf at hotmail.com> wrote:

 Subject: Re: [syslinux] check-gnu-efi.sh: print the output of	build-gnu-efi.sh
 To: syslinux at zytor.com
 Date: Monday, December 22, 2014, 9:29 AM
 
 
 >
 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 several months old and
 dozens 
 of commits old). By the time I am
 writing this email, the Syslinux 
 source
 code is still pointing to the same "old" commit
 and there are 
 more than 50 newer ones in
 gnu-efi.
 
 Although at some
 point there were reports (maybe it was just one, or 
 two) that building with a specific newer commit
 of gnu-efi would fail, 
 I believe that there
 should be a new attempt to build Syslinux with a 
 newer gnu-efi commit / version, as to at least
 try to reduce the 
 reported problems about
 syslinux.efi failing in certain VM environments 
 (OVMF, KVM, whatever). I'm not saying it
 has to be now, but it might be 
 worth
 testing this matter before the next pre-release (whenever it
 
 might occur).
 
 In particular, the *gnu-efi.sh scripts in
 Syslinux should be tested 
 with the new
 gnu-efi git tree (changed, 2014Nov25).
  
  
 > It also levels the field
 such that everyone has the same version. 
 
 Using a consistent version /
 commit of gnu-efi makes sense. Otherwise, 
 the resulting behavior could be changing (or
 the build might fail for 
 some reason),
 according to whichever version / commit is
 "freely" used. 
 As I said above,
 it might be worth pointing the gnu-efi submodule to a 
 newer "consistent" commit (or
 version) and resolve any potential issues 
 with it before the next Syslinux pre-release.?
 
 
 Regards,
 Ady.
 _______________________________________________
 Syslinux mailing list
 Submissions to Syslinux at zytor.com
 Unsubscribe or set options at:
 http://www.zytor.com/mailman/listinfo/syslinux

Hi

On Mon, Dec 22, 2014 at 8:29 AM, Ady <ady-sf at hotmail.com>
wrote:
> Using a consistent version / commit of gnu-efi makes sense. Otherwise,
> the resulting behavior could be changing (or the build might fail for
> some reason), according to whichever version / commit is "freely"
used.
As an active package maintainer I strongly believe in idea that
software should use system packages as much as possible. The reasons
are:
 - embedding libraries makes project bloating and the build system
more complicated.
 - package maintainers tend to provide higher quality support for
packages than alone developers. System libraries get bug/security
fixes, version updates faster than libraries embedded into projects.
And embedded libraries are usually left at some obsolete version just
because developer have no time to update it.
 - compiling a project with already-built system libraries is faster
than compile embedded libraries each time.

I am not an syslinux/efi expert but for me it looks like syslinux can
be perfectly fine using system gnu-efi library. For example in Linux
Arch both refind and gummiboot use the system library and never had
problems with it.