[PATCH 0/2] Misc doc changes

[PATCH 0/2] Misc doc changes

[Glenn Washburn]

The first patch adds a long overdue note to the cryptomount command that UUIDs
should be specified without dash, differently than how fs uuids are specified.

The second patch makes the indentation of command description text for cutmem
and badmem conform with the indentation of the rest of the commands.

Glenn

Glenn Washburn (2):
  docs: Add note to cryptomount that UUIDs should be specified without
    dashes
  docs: Conform badmem and cutmem description indentations with other
    commands

 docs/grub.texi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
2.27.0

[PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes

[Glenn Washburn]

Signed-off-by: Glenn Washburn <development@efficientek.com>
---
 docs/grub.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index eeb3118eb..93ae12a88 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4307,6 +4307,9 @@ GRUB suports devices encrypted using LUKS, LUKS2 and geli. Note that necessary
 modules (@var{luks}, @var{luks2} and @var{geli}) have to be loaded manually
 before this command can be used. For LUKS2 only the PBKDF2 key derivation
 function is supported, as Argon2 is not yet supported.
+
+Also, note that, unlike filesystem UUIDs, UUIDs for encrypted devices must be
+specified without dash separators.
 @end deffn
 
 @node cutmem
-- 
2.27.0

[PATCH 2/2] docs: Conform badmem and cutmem description indentations with other commands

[Glenn Washburn]

Signed-off-by: Glenn Washburn <development@efficientek.com>
---
 docs/grub.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 93ae12a88..e2c58415a 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4125,7 +4125,6 @@ can be changed only when using @samp{gfxterm} for terminal output.
 
 @deffn Command badram addr,mask[,addr,mask...]
 Filter out bad RAM.
-@end deffn
 
 This command notifies the memory manager that specified regions of
 RAM ought to be filtered out (usually, because they're damaged).  This
@@ -4147,6 +4146,7 @@ The command is similar to @command{cutmem} command.
 Note: The command is not allowed when lockdown is enforced (@pxref{Lockdown}).
       This prevents removing EFI memory regions to potentially subvert the
       security mechanisms provided by the UEFI secure boot.
+@end deffn
 
 @node blocklist
 @subsection blocklist
@@ -4317,7 +4317,6 @@ specified without dash separators.
 
 @deffn Command cutmem from[K|M|G] to[K|M|G]
 Remove any memory regions in specified range.
-@end deffn
 
 This command notifies the memory manager that specified regions of RAM ought to
 be filtered out. This remains in effect after a payload kernel has been loaded
@@ -4330,6 +4329,7 @@ The command is similar to @command{badram} command.
 Note: The command is not allowed when lockdown is enforced (@pxref{Lockdown}).
       This prevents removing EFI memory regions to potentially subvert the
       security mechanisms provided by the UEFI secure boot.
+@end deffn
 
 @node date
 @subsection date
-- 
2.27.0

Re: [PATCH 0/2] Misc doc changes

[Daniel Kiper]

On Wed, Mar 31, 2021 at 07:11:51PM -0500, Glenn Washburn wrote:
> The first patch adds a long overdue note to the cryptomount command that UUIDs
> should be specified without dash, differently than how fs uuids are specified.
>
> The second patch makes the indentation of command description text for cutmem
> and badmem conform with the indentation of the rest of the commands.
>
> Glenn
>
> Glenn Washburn (2):
>   docs: Add note to cryptomount that UUIDs should be specified without
>     dashes
>   docs: Conform badmem and cutmem description indentations with other
>     commands

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel

GRUB 2.06

[Didier Spaier]

I am fine with shipping GRUB up to some commit in Slint, but not all
distributions accept to do that, or to carry a zillion patches as does 
Debian.

As result, end users complain "GRUB is broken" whereas a patch that fix the
issue of which they suffer of has been committed upstream a long time ago.

An example that comes to mind is:
6643507ce30f775008e093580f0c9499dfb2c485

Folks running Slackware-current also suffer of it:
https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

Best regards
Didier

Le 08/04/2021 à 18:53, Daniel Kiper a écrit :
> On Wed, Mar 31, 2021 at 07:11:51PM -0500, Glenn Washburn wrote:
>> The first patch adds a long overdue note to the cryptomount command that UUIDs
>> should be specified without dash, differently than how fs uuids are specified.
>>
>> The second patch makes the indentation of command description text for cutmem
>> and badmem conform with the indentation of the rest of the commands.
>>
>> Glenn
>>
>> Glenn Washburn (2):
>>    docs: Add note to cryptomount that UUIDs should be specified without
>>      dashes
>>    docs: Conform badmem and cutmem description indentations with other
>>      commands
> 
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: GRUB 2.06

[Didier Spaier]

Le 08/04/2021 à 21:28, Didier Spaier a écrit :
> I am fine with shipping GRUB up to some commit in Slint, but not all
> distributions accept to do that, or to carry a zillion patches as does 
> Debian.
> 
> As result, end users complain "GRUB is broken" whereas a patch that fix the
> issue of which they suffer of has been committed upstream a long time ago.
> 
> An example that comes to mind is:
> 6643507ce30f775008e093580f0c9499dfb2c485
> 
> Folks running Slackware-current also suffer of it:
> https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544 

Sorry, wrong link, read:
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544 


And sorry to have appended by mistake a quote from another thread.

Didier

Re: GRUB 2.06

[Daniel Kiper]

Hi Didier,

On Thu, Apr 08, 2021 at 11:26:08PM +0200, Didier Spaier wrote:
> Le 08/04/2021 à 21:28, Didier Spaier a écrit :
> > I am fine with shipping GRUB up to some commit in Slint, but not all
> > distributions accept to do that, or to carry a zillion patches as does
> > Debian.
> >
> > As result, end users complain "GRUB is broken" whereas a patch that fix the
> > issue of which they suffer of has been committed upstream a long time ago.
> >
> > An example that comes to mind is:
> > 6643507ce30f775008e093580f0c9499dfb2c485
> >
> > Folks running Slackware-current also suffer of it:
> > https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544
>
> Sorry, wrong link, read:
> https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

I tried a few times but I am not able to open this link. Sorry...
Could you explain your problem here?

Daniel

Re: GRUB 2.06

[John Paul Adrian Glaubitz]

Hello!

On 4/20/21 3:53 PM, Daniel Kiper wrote:
> I tried a few times but I am not able to open this link. Sorry...
> Could you explain your problem here?

The correct link seems to point to this thread:

> https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/

But it's not opening for me either although I can see the Slackware forum:

> https://www.linuxquestions.org/questions/slackware-14/

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06

[Didier Spaier]

Hi Daniel and John Paul Adrian,

Le 20/04/2021 à 15:53, Daniel Kiper a écrit :
 > Hi Didier,
 >
 > On Thu, Apr 08, 2021 at 11:26:08PM +0200, Didier Spaier wrote:
 >> Le 08/04/2021 à 21:28, Didier Spaier a écrit :
 >>> I am fine with shipping GRUB up to some commit in Slint, but not all
 >>> distributions accept to do that, or to carry a zillion patches as does
 >>> Debian.
 >>>
 >>> As result, end users complain "GRUB is broken" whereas a patch that 
fix the
 >>> issue of which they suffer of has been committed upstream a long 
time ago.
 >>>
 >>> An example that comes to mind is:
 >>> 6643507ce30f775008e093580f0c9499dfb2c485
 >>>
 >>> Folks running Slackware-current also suffer of it:
 >>> 
https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544
 >>
 >> Sorry, wrong link, read:
 >> 
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544
 >
 > I tried a few times but I am not able to open this link. Sorry...
 > Could you explain your problem here?
 >
 > Daniel

Sorry for the link

Let's try again to paste it:
https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/page4.html#post6236544

Anyway here is the posts' content, minus the forum's formatting:

-- pasted post below

Originally Posted by teoberi below:
The root cause is GRUB itself and if I understood correctly from what I 
read on the mailing lists it is not certain that problem will be solved!
@Didier, do you know anything about this?

Answer by Didier:
Indeed, this patch has been committed more than one year ago! From git 
log in the master branch:

[code]commit 6643507ce30f775008e093580f0c9499dfb2c485
Author: Simon Hardy <hidden>
Date:   Tue Mar 24 13:29:12 2020 +0000

     build: Fix GRUB i386-pc build with Ubuntu gcc

     With recent versions of gcc on Ubuntu a very large 
lzma_decompress.img file is
     output. (e.g. 134479600 bytes instead of 2864.) This causes 
grub-mkimage to
     fail with: "error: Decompressor is too big."

     This seems to be caused by a section .note.gnu.property that is 
placed at an
     offset such that objcopy needs to pad the img file with zeros.

     This issue is present on:
     Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
     Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008

     This issue is not present on:
     Ubuntu 19.10 with gcc (Ubuntu 7.5.0-3ubuntu1~19.10) 7.5.0
     RHEL 8.0 with gcc 8.3.1 20190507 (Red Hat 8.3.1-4)

     The issue can be fixed by removing the section using objcopy as 
shown in
     this patch.

     Signed-off-by: Simon Hardy <hidden>
     Reviewed-by: Daniel Kiper <hidden>[/code]So it's already in 2.06~rc1.

-- end of pasted post

So, it's hard to understand for many end users that:

1. The issue appeared after gcc-10 began to be used, well after the 
release of grub 2.04.
2. It has been fixed long ago.
3. But for the fix to be effective one of these conditions should be met:
a. A new grub version has been released and is provided by the 
distribution they use.
b. The distributon they use patches the source of GRUB 2.04 to bring the 
fix.
c. The distribution they use provides a package build from a source 
pulled from with the patch already committed.

Unfortunately if none of these conditions is met many users tend
to blame GRUB instead of the distributions and go saying in fora "I'll 
avoid to use GRUB, it's broken"

Best regards,
Didier

Re: GRUB 2.06

[John Paul Adrian Glaubitz]

On 4/20/21 7:34 PM, Didier Spaier wrote:
> So, it's hard to understand for many end users that:
> 
> 1. The issue appeared after gcc-10 began to be used, well after the release of grub 2.04.
> 2. It has been fixed long ago.
> 3. But for the fix to be effective one of these conditions should be met:
> a. A new grub version has been released and is provided by the distribution they use.
> b. The distributon they use patches the source of GRUB 2.04 to bring the fix.
> c. The distribution they use provides a package build from a source pulled from with the patch already committed.
> 
> Unfortunately if none of these conditions is met many users tend
> to blame GRUB instead of the distributions and go saying in fora "I'll avoid to use GRUB, it's broken"

I think it's reasonable to expect from a distribution that they backport upstream fixes, at
least in Debian, openSUSE and Fedora, it isn't a problem.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3341 bytes --]

On 4/20/21 1:48 PM, John Paul Adrian Glaubitz wrote:
> I think it's reasonable to expect from a distribution that they
> backport upstream fixes, at least in Debian, openSUSE and Fedora, it
> isn't a problem.

I think it is unreasonable -- backporting upstream fixes is a sign that
upstream software has failed to be usable out of the box, and needs to
release more often.

If a distro is being *forced* to backport 200+ patches, we've officially
entered the Madness Place:

https://build.opensuse.org/package/view_file/Base:System/grub2/grub2.spec
lines 174 - 395 (9 pages of source files, most named 0001?)

https://src.fedoraproject.org/rpms/grub2/tree/rawhide
carefully numbered list of patches 0001 - 0198

https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/series
patch series of 219 patches

...

I'm sorry? Claiming that distros "are capable of backporting, therefore
it's reasonable to expect it is their job to do so" is completely
missing the point.

Claiming that for these distros "it isn't a problem" to roll a patchset
for elaborate backport lists, based on I guess the evidence that they've
done so, unjustly conflates "we like doing this" with "we were forced to
do this with much gnashing of teeth".

I can't point to citations where either one has been said, but I somehow
doubt the former viewpoint is the one distro maintainers are holding.
(Well, I'm given to understand Debian maintainers seem to actively enjoy
having many patches. So I guess I shouldn't be *too* surprised that a
Debian Developer is insisting that people maintain downstream patches.)

"Basically insulting except not outright" a person who would like to see
more frequent (read: any) maintenance releases because I dunno, clearly
they're just irresponsible at running a distro if they're afraid of
importing 200 patches in one go, is kind of really bad.

This is a real problem that grub really has. Whyever that might be a
problem (the standard reason is lack of developer time) can be seen as
forgivable, because software development is hard and all too often
unrewarding, and demanding more releases may not actually be feasible in
practice.

But I'd really, really, really like to NOT see victim blaming and
holding the current state of affairs as some kind of joyous ideal which
must be held sacred, because pooh-pooh anyone who dares post to the list
merely asking if such a thing might be possible -- it's your own darned
job, noob, stop being unreasonable and lern2patch, reasonable distros
will reasonably patch.

(I think it bears mentioning again -- 200+ patches. *200*. At what point
is there more patches than source code?)

...

Anyway, a grub 2.04.1 would have been fantastic 6 months or a year ago.
At this point, people should just use 2.06-rc1, there is not much point
in trying to stabilize a maintenance release in the middle of the
freeze/RC cycle for 2.06 as the same effort is better spent getting 2.06
out the door.

But I'm pretty sure there have been previous threads discussing the hope
of maintenance releases, and a tentative statement by the project
maintainers that they will try to do so going forward.

So hopefully the situation will be better going forward.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.06

[John Paul Adrian Glaubitz]

On 4/20/21 10:33 PM, Eli Schwartz wrote:
> (Well, I'm given to understand Debian maintainers seem to actively enjoy
> having many patches. So I guess I shouldn't be *too* surprised that a
> Debian Developer is insisting that people maintain downstream patches.)
Why do you think you need to resort to personal attacks. You are reading
things into my messages that I never said. Please refrain from doing that
and please don't make assumptions about people you don't know.

Also, I find it insulting to accuse the whole Debian project of a bad
maintenance culture. Debian has probably done more to open source and
Linux than Arch ever will.

PS: I also happen to be a SUSE employee and openSUSE/SLE maintainer, so
your first assumption that I'm somehow subject to Debian culture is flawed.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06

[Daniel Kiper]

On Tue, Apr 20, 2021 at 04:33:37PM -0400, Eli Schwartz wrote:
> On 4/20/21 1:48 PM, John Paul Adrian Glaubitz wrote:
> > I think it's reasonable to expect from a distribution that they
> > backport upstream fixes, at least in Debian, openSUSE and Fedora, it
> > isn't a problem.
>
> I think it is unreasonable -- backporting upstream fixes is a sign that
> upstream software has failed to be usable out of the box, and needs to
> release more often.
>
> If a distro is being *forced* to backport 200+ patches, we've officially
> entered the Madness Place:
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2.spec
> lines 174 - 395 (9 pages of source files, most named 0001?)
>
> https://src.fedoraproject.org/rpms/grub2/tree/rawhide
> carefully numbered list of patches 0001 - 0198

AFAICT F34 dropped more than 100 custom patches after 2.06~rc1 release.
And this did not happen by chance. It required a lot of work. I know the
situation is still not perfect. Though other folks and I are still going
to work on dropping most of these patches. So, please be patient...

> https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/series
> patch series of 219 patches

...same for Debian and other distros...

> ...
>
> I'm sorry? Claiming that distros "are capable of backporting, therefore
> it's reasonable to expect it is their job to do so" is completely
> missing the point.
>
> Claiming that for these distros "it isn't a problem" to roll a patchset
> for elaborate backport lists, based on I guess the evidence that they've
> done so, unjustly conflates "we like doing this" with "we were forced to
> do this with much gnashing of teeth".
>
> I can't point to citations where either one has been said, but I somehow
> doubt the former viewpoint is the one distro maintainers are holding.
> (Well, I'm given to understand Debian maintainers seem to actively enjoy
> having many patches. So I guess I shouldn't be *too* surprised that a
> Debian Developer is insisting that people maintain downstream patches.)
>
> "Basically insulting except not outright" a person who would like to see
> more frequent (read: any) maintenance releases because I dunno, clearly
> they're just irresponsible at running a distro if they're afraid of
> importing 200 patches in one go, is kind of really bad.
>
> This is a real problem that grub really has. Whyever that might be a
> problem (the standard reason is lack of developer time) can be seen as
> forgivable, because software development is hard and all too often
> unrewarding, and demanding more releases may not actually be feasible in
> practice.
>
> But I'd really, really, really like to NOT see victim blaming and
> holding the current state of affairs as some kind of joyous ideal which
> must be held sacred, because pooh-pooh anyone who dares post to the list
> merely asking if such a thing might be possible -- it's your own darned
> job, noob, stop being unreasonable and lern2patch, reasonable distros
> will reasonably patch.
>
> (I think it bears mentioning again -- 200+ patches. *200*. At what point
> is there more patches than source code?)
>
> ...
>
> Anyway, a grub 2.04.1 would have been fantastic 6 months or a year ago.
> At this point, people should just use 2.06-rc1, there is not much point
> in trying to stabilize a maintenance release in the middle of the
> freeze/RC cycle for 2.06 as the same effort is better spent getting 2.06
> out the door.

Sorry, I am not going to make maintenance releases until we are able to
make stable releases in proper cadence. Then we can get back to this
discussion...

Daniel

Re: GRUB 2.06

[Mike Gilbert]

On Tue, Apr 20, 2021 at 1:34 PM Didier Spaier <didier@slint.fr> wrote:
> So, it's hard to understand for many end users that:
>
> 1. The issue appeared after gcc-10 began to be used, well after the
> release of grub 2.04.
> 2. It has been fixed long ago.
> 3. But for the fix to be effective one of these conditions should be met:
> a. A new grub version has been released and is provided by the
> distribution they use.
> b. The distributon they use patches the source of GRUB 2.04 to bring the
> fix.
> c. The distribution they use provides a package build from a source
> pulled from with the patch already committed.
>
> Unfortunately if none of these conditions is met many users tend
> to blame GRUB instead of the distributions and go saying in fora "I'll
> avoid to use GRUB, it's broken"

My 2 cents:

If a distro starts shipping a new version of GCC, they should really
test their packages first and patch them as needed.

If an end user installs a new version of GCC manually, I would hope
they are smart enough to know that it might break things.

If an end user builds GRUB manually, they are also responsible for
applying any patches that are necessary for their toolchain.

Re: GRUB 2.06

[Bruce Dubbs]

On 4/20/21 12:50 PM, Mike Gilbert wrote:
> On Tue, Apr 20, 2021 at 1:34 PM Didier Spaier <didier@slint.fr> wrote:
>> So, it's hard to understand for many end users that:
>>
>> 1. The issue appeared after gcc-10 began to be used, well after the
>> release of grub 2.04.
>> 2. It has been fixed long ago.
>> 3. But for the fix to be effective one of these conditions should be met:
>> a. A new grub version has been released and is provided by the
>> distribution they use.
>> b. The distributon they use patches the source of GRUB 2.04 to bring the
>> fix.
>> c. The distribution they use provides a package build from a source
>> pulled from with the patch already committed.
>>
>> Unfortunately if none of these conditions is met many users tend
>> to blame GRUB instead of the distributions and go saying in fora "I'll
>> avoid to use GRUB, it's broken"
> 
> My 2 cents:
> 
> If a distro starts shipping a new version of GCC, they should really
> test their packages first and patch them as needed.
> 
> If an end user installs a new version of GCC manually, I would hope
> they are smart enough to know that it might break things.
> 
> If an end user builds GRUB manually, they are also responsible for
> applying any patches that are necessary for their toolchain.

And my two cents:

Actively maintained packages like GRUB should make releases more often 
than every 2-4 years.  GCC is on a schedule to produce stable releases 
twice a year.  GRUB should release new stable releases at least as often.

Re: GRUB 2.06

[Mike Gilbert]

On Tue, Apr 20, 2021 at 2:21 PM Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
>
> On 4/20/21 12:50 PM, Mike Gilbert wrote:
> > On Tue, Apr 20, 2021 at 1:34 PM Didier Spaier <didier@slint.fr> wrote:
> >> So, it's hard to understand for many end users that:
> >>
> >> 1. The issue appeared after gcc-10 began to be used, well after the
> >> release of grub 2.04.
> >> 2. It has been fixed long ago.
> >> 3. But for the fix to be effective one of these conditions should be met:
> >> a. A new grub version has been released and is provided by the
> >> distribution they use.
> >> b. The distributon they use patches the source of GRUB 2.04 to bring the
> >> fix.
> >> c. The distribution they use provides a package build from a source
> >> pulled from with the patch already committed.
> >>
> >> Unfortunately if none of these conditions is met many users tend
> >> to blame GRUB instead of the distributions and go saying in fora "I'll
> >> avoid to use GRUB, it's broken"
> >
> > My 2 cents:
> >
> > If a distro starts shipping a new version of GCC, they should really
> > test their packages first and patch them as needed.
> >
> > If an end user installs a new version of GCC manually, I would hope
> > they are smart enough to know that it might break things.
> >
> > If an end user builds GRUB manually, they are also responsible for
> > applying any patches that are necessary for their toolchain.
>
> And my two cents:
>
> Actively maintained packages like GRUB should make releases more often
> than every 2-4 years.  GCC is on a schedule to produce stable releases
> twice a year.  GRUB should release new stable releases at least as often.

I would also like to see more frequent releases.

However, I recognize that GRUB has a very conservative release/testing
process, and the developers have limited time available.

Re: GRUB 2.06

[John Paul Adrian Glaubitz]

On 4/20/21 7:50 PM, Mike Gilbert wrote:
> My 2 cents:
> 
> If a distro starts shipping a new version of GCC, they should really
> test their packages first and patch them as needed.
> 
> If an end user installs a new version of GCC manually, I would hope
> they are smart enough to know that it might break things.
> 
> If an end user builds GRUB manually, they are also responsible for
> applying any patches that are necessary for their toolchain.

Fully agree on all points. And while I cannot speak for Gentoo, I know that
Fedora, Debian and openSUSE did full archive rebuilds with gcc-10 when it
was released.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB 2.06

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1975 bytes --]

On 4/8/21 3:28 PM, Didier Spaier wrote:
> I am fine with shipping GRUB up to some commit in Slint, but not all
> distributions accept to do that, or to carry a zillion patches as does
> Debian.
> 
> As result, end users complain "GRUB is broken" whereas a patch that fix 
the
> issue of which they suffer of has been committed upstream a long time ago.
> 
> An example that comes to mind is:
> 6643507ce30f775008e093580f0c9499dfb2c485
> 
> Folks running Slackware-current also suffer of it:
> https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544

Can you *please* not do this?

References: <cover.1617235760.git.development@efficientek.com>
 <20210408165349.otipx6gohm64bsud@tomti.i.net-space.pl>
In-Reply-To: <20210408165349.otipx6gohm64bsud@tomti.i.net-space.pl>

And randomly top-posting on top of a completely unrelated thread that
you've hit "reply to" despite having no connection to your actual reply.

There is zero benefit to this, and it's seriously inconvenient to people
who have seemingly disappearing emails due to threading.


...

Now, on to your actual discussion. Seems to me like you're using a very
confusing way of saying:

"It would be very nice if grub would commit to creating a maintenance
branch and publish periodic 2.04.1, 2.04.2, 2.04.3 style releases when
the most recent stable release is completely unsuitable for use. As a
distro maintainer, it's really awkward to have to hunt down dozens of
patches that fix important bugs, which the grub developers know are
critical, but every distro needs to painfully rediscover through the
brute force approach because no one is publicizing a list of
FYI-these-patches-are-really-important-and-you-really-should-backport-them".

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: GRUB 2.06

[Daniel Kiper]

On Tue, Apr 20, 2021 at 03:58:18PM -0400, Eli Schwartz wrote:
> On 4/8/21 3:28 PM, Didier Spaier wrote:
> > I am fine with shipping GRUB up to some commit in Slint, but not all
> > distributions accept to do that, or to carry a zillion patches as does
> > Debian.
> >
> > As result, end users complain "GRUB is broken" whereas a patch that fix
> the
> > issue of which they suffer of has been committed upstream a long time ago.
> >
> > An example that comes to mind is:
> > 6643507ce30f775008e093580f0c9499dfb2c485
> >
> > Folks running Slackware-current also suffer of it:
> > https://https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/#post6236544
>
> Can you *please* not do this?
>
> References: <cover.1617235760.git.development@efficientek.com>
>  <20210408165349.otipx6gohm64bsud@tomti.i.net-space.pl>
> In-Reply-To: <20210408165349.otipx6gohm64bsud@tomti.i.net-space.pl>
>
> And randomly top-posting on top of a completely unrelated thread that
> you've hit "reply to" despite having no connection to your actual reply.
>
> There is zero benefit to this, and it's seriously inconvenient to people
> who have seemingly disappearing emails due to threading.

FYI, Didier spotted own mistake earlier and said sorry in separate email...

Daniel