I understand that grub.git#master does (most likely) compile for everyone else:
[ 135s] + env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall ../grub2-src/configure
--target=i386-suse-linux --with-platform=pc
--prefix=/usr/lib64/grub2-chainloader --disable-boot-time --disable-cache-stats
--disable-de
Hi Olaf,
CC-ing Peter...
On Wed, Mar 11, 2020 at 08:44:33AM +0100, Olaf Hering wrote:
> I understand that grub.git#master does (most likely) compile for everyone
> else:
>
> [ 135s] + env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall
> ../grub2-src/configure --target=i386-suse-linux --with-platform
On Tue, Mar 03, 2020 at 06:26:03PM +0100, Daniel Kiper wrote:
> On Wed, Feb 19, 2020 at 04:01:38PM +0100, Daniel Kiper wrote:
> > Hi all,
> >
> > As I told during my FOSDEM 2020 presentation we are preparing for
> > GRUB 2.06 release. Tentative schedule is below:
> > - code freeze: 15th of March,
On 3/11/20 11:39 AM, Daniel Kiper wrote:
>> [ 135s] + env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall
>> ../grub2-src/configure --target=i386-suse-linux
Which version of SUSE Linux is that, in case I want to reproduce that?
FWIW, I work at SUSE, so I have access to all versions :).
Adrian
--
.
Am Wed, 11 Mar 2020 11:39:08 +0100
schrieb Daniel Kiper :
> Nothing suspicious pooped out. I expect that the issues you are
> hitting are related to set of configure flags which you are using.
It turned out --disable-mm-debug does for some reason fix the build with gcc7.
But building with gcc48
Am Wed, 11 Mar 2020 11:56:27 +0100
schrieb John Paul Adrian Glaubitz :
> Which version of SUSE Linux is that, in case I want to reproduce that?
SLE_12 and Leap 42.3, everything with gcc-4.8. I may be able to work around it
by using a newer compiler.
Olaf
pgpyMboyE0v9G.pgp
Description: Digital
On 3/11/20 12:01 PM, Olaf Hering wrote:
> Am Wed, 11 Mar 2020 11:56:27 +0100
> schrieb John Paul Adrian Glaubitz :
>
>> Which version of SUSE Linux is that, in case I want to reproduce that?
>
> SLE_12 and Leap 42.3, everything with gcc-4.8. I may be able to work around
> it by using a newer com
Hello Olaf,
On 3/11/20 11:59 AM, Olaf Hering wrote:
> Am Wed, 11 Mar 2020 11:39:08 +0100
> schrieb Daniel Kiper :
>
>> Nothing suspicious pooped out. I expect that the issues you are
>> hitting are related to set of configure flags which you are using.
>
> It turned out --disable-mm-debug does f
Adding Michael, Mihai, Javier and Peter...
Below you can find what more or less Vladimir and I agreed WRT small MBR
gap. In general Vladimir convinced me to phase out small MBR gaps
support gradually. This is first step in this journey. We think that we
have to build some warnings into the code an
Hello Daniel,
On 3/11/20 1:43 PM, Daniel Kiper wrote:
> Adding Michael, Mihai, Javier and Peter...
>
> Below you can find what more or less Vladimir and I agreed WRT small MBR
> gap. In general Vladimir convinced me to phase out small MBR gaps
> support gradually. This is first step in this journ
On Wed, Mar 11, 2020 at 01:43:14PM +0100, Daniel Kiper wrote:
> Adding Michael, Mihai, Javier and Peter...
>
> Below you can find what more or less Vladimir and I agreed WRT small MBR
> gap. In general Vladimir convinced me to phase out small MBR gaps
> support gradually. This is first step in thi
Am Wed, 11 Mar 2020 12:30:01 +0100
schrieb Javier Martinez Canillas :
> +#if !(defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L))
This does not help. I have seen similar code in one of the zstd headers.
Whatever the outcome will be, it should get a 'Fixes commit d5a32255d' tag.
Olaf
On 3/11/20 4:41 PM, Olaf Hering wrote:
> Am Wed, 11 Mar 2020 12:30:01 +0100
> schrieb Javier Martinez Canillas :
>
>> +#if !(defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L))
>
> This does not help. I have seen similar code in one of the zstd headers.
>
Yes, I mentioned in the commi
Le 11/03/2020 à 13:43, Daniel Kiper a écrit :
> Adding Michael, Mihai, Javier and Peter...
>
> Below you can find what more or less Vladimir and I agreed WRT small MBR
> gap. In general Vladimir convinced me to phase out small MBR gaps
> support gradually. This is first step in this journey. We
Hey all, I previously discussed my concept for this patch in my email
https://lists.gnu.org/archive/html/grub-devel/2020-01/msg4.html .
I'm pleased to announce that I've gotten it into a working state and
it is ready to review. There are a number of changes here, which I
will break down below.
This patch modifies the loadenv command to take advantage of the new envblock
functions provided by a previous patch. These functions will be used instead
of the normal file-based functions if the boot filesystem is detected to
support them. There is also a config variable, grubenv_src, that can be
This patch introducces the idea of envblk functions to GRUB. These functions
are used to interact with a grubenv file stored not in the usual grub tree,
but instead in a special filesystem-managed region that can more easily be
accessed at boot time. These functions interface between calling code a
This patch refactors the DEFAULT_ENVBLK_SIZE definition into a header file for
reuse in other code, and renames it to match other definitions in that header.
Signed-off-by: Paul Dagnelie
---
include/grub/lib/envblk.h | 1 +
util/editenv.c| 9 -
2 files changed, 5 insertions(+
This patch updates the grub-editenv command to support editing the zfs
envblock by using specific libzfs functions. In order to ensure that GRUB will
continue to build against both old and new versions of libzfs, logic was also
added to the configure script to detect if the bootenv functions are pr
This patch refactors out the logic that applies filters to files for reuse in
other code.
Signed-off-by: Paul Dagnelie
---
grub-core/kern/file.c | 46 +--
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/grub-core/kern/file.c b/grub-core/ker
This patch factors out the filling of the grubenv buffer into a separate
function for reuse.
Signed-off-by: Paul Dagnelie
---
include/grub/util/install.h | 3 +++
util/editenv.c | 26 +-
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/include
This patch adds a ZFS implementation of the fs_envblk_* functions. These
functions will be used to load the grubenv block from a padding area in the
label of ZFS. This padding area is protected by an embedded checksum, and
multiple copies are stored on each disk. This should provide sufficient
reli
On Wed, Mar 11, 2020, 18:08 Didier Spaier wrote:
>
>
> Le 11/03/2020 à 13:43, Daniel Kiper a écrit :
> > Adding Michael, Mihai, Javier and Peter...
> >
> > Below you can find what more or less Vladimir and I agreed WRT small MBR
> > gap. In general Vladimir convinced me to phase out small MBR gap
23 matches
Mail list logo