* [PATCH 0/2] Misc doc changes
@ 2021-04-01 0:11 Glenn Washburn
2021-04-01 0:11 ` [PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes Glenn Washburn
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Glenn Washburn @ 2021-04-01 0:11 UTC (permalink / raw)
To: grub-devel, Daniel Kiper; +Cc: 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes
2021-04-01 0:11 [PATCH 0/2] Misc doc changes Glenn Washburn
@ 2021-04-01 0:11 ` Glenn Washburn
2021-04-01 0:11 ` [PATCH 2/2] docs: Conform badmem and cutmem description indentations with other commands Glenn Washburn
2021-04-08 16:53 ` [PATCH 0/2] Misc doc changes Daniel Kiper
2 siblings, 0 replies; 19+ messages in thread
From: Glenn Washburn @ 2021-04-01 0:11 UTC (permalink / raw)
To: grub-devel, Daniel Kiper; +Cc: 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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/2] docs: Conform badmem and cutmem description indentations with other commands
2021-04-01 0:11 [PATCH 0/2] Misc doc changes Glenn Washburn
2021-04-01 0:11 ` [PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes Glenn Washburn
@ 2021-04-01 0:11 ` Glenn Washburn
2021-04-08 16:53 ` [PATCH 0/2] Misc doc changes Daniel Kiper
2 siblings, 0 replies; 19+ messages in thread
From: Glenn Washburn @ 2021-04-01 0:11 UTC (permalink / raw)
To: grub-devel, Daniel Kiper; +Cc: 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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 0/2] Misc doc changes
2021-04-01 0:11 [PATCH 0/2] Misc doc changes Glenn Washburn
2021-04-01 0:11 ` [PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes Glenn Washburn
2021-04-01 0:11 ` [PATCH 2/2] docs: Conform badmem and cutmem description indentations with other commands Glenn Washburn
@ 2021-04-08 16:53 ` Daniel Kiper
2021-04-08 19:28 ` GRUB 2.06 Didier Spaier
2 siblings, 1 reply; 19+ messages in thread
From: Daniel Kiper @ 2021-04-08 16:53 UTC (permalink / raw)
To: Glenn Washburn; +Cc: grub-devel, 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* GRUB 2.06
2021-04-08 16:53 ` [PATCH 0/2] Misc doc changes Daniel Kiper
@ 2021-04-08 19:28 ` Didier Spaier
2021-04-08 21:26 ` Didier Spaier
2021-04-20 19:58 ` Eli Schwartz
0 siblings, 2 replies; 19+ messages in thread
From: Didier Spaier @ 2021-04-08 19:28 UTC (permalink / raw)
To: grub-devel
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-08 19:28 ` GRUB 2.06 Didier Spaier
@ 2021-04-08 21:26 ` Didier Spaier
2021-04-20 13:53 ` Daniel Kiper
2021-04-20 19:58 ` Eli Schwartz
1 sibling, 1 reply; 19+ messages in thread
From: Didier Spaier @ 2021-04-08 21:26 UTC (permalink / raw)
To: grub-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-08 21:26 ` Didier Spaier
@ 2021-04-20 13:53 ` Daniel Kiper
2021-04-20 14:00 ` John Paul Adrian Glaubitz
2021-04-20 17:34 ` Didier Spaier
0 siblings, 2 replies; 19+ messages in thread
From: Daniel Kiper @ 2021-04-20 13:53 UTC (permalink / raw)
To: Didier Spaier; +Cc: grub-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 13:53 ` Daniel Kiper
@ 2021-04-20 14:00 ` John Paul Adrian Glaubitz
2021-04-20 17:34 ` Didier Spaier
1 sibling, 0 replies; 19+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-20 14:00 UTC (permalink / raw)
To: The development of GNU GRUB, Daniel Kiper, Didier Spaier
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 13:53 ` Daniel Kiper
2021-04-20 14:00 ` John Paul Adrian Glaubitz
@ 2021-04-20 17:34 ` Didier Spaier
2021-04-20 17:48 ` John Paul Adrian Glaubitz
2021-04-20 17:50 ` Mike Gilbert
1 sibling, 2 replies; 19+ messages in thread
From: Didier Spaier @ 2021-04-20 17:34 UTC (permalink / raw)
To: grub-devel; +Cc: Daniel Kiper, John Paul Adrian Glaubitz
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 17:34 ` Didier Spaier
@ 2021-04-20 17:48 ` John Paul Adrian Glaubitz
2021-04-20 20:33 ` Eli Schwartz
2021-04-20 17:50 ` Mike Gilbert
1 sibling, 1 reply; 19+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-20 17:48 UTC (permalink / raw)
To: Didier Spaier, grub-devel; +Cc: Daniel Kiper
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 17:34 ` Didier Spaier
2021-04-20 17:48 ` John Paul Adrian Glaubitz
@ 2021-04-20 17:50 ` Mike Gilbert
2021-04-20 18:21 ` Bruce Dubbs
2021-04-20 18:43 ` John Paul Adrian Glaubitz
1 sibling, 2 replies; 19+ messages in thread
From: Mike Gilbert @ 2021-04-20 17:50 UTC (permalink / raw)
To: The development of GNU GRUB
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 17:50 ` Mike Gilbert
@ 2021-04-20 18:21 ` Bruce Dubbs
2021-04-20 18:36 ` Mike Gilbert
2021-04-20 18:43 ` John Paul Adrian Glaubitz
1 sibling, 1 reply; 19+ messages in thread
From: Bruce Dubbs @ 2021-04-20 18:21 UTC (permalink / raw)
To: grub-devel
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 18:21 ` Bruce Dubbs
@ 2021-04-20 18:36 ` Mike Gilbert
0 siblings, 0 replies; 19+ messages in thread
From: Mike Gilbert @ 2021-04-20 18:36 UTC (permalink / raw)
To: The development of GNU GRUB
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 17:50 ` Mike Gilbert
2021-04-20 18:21 ` Bruce Dubbs
@ 2021-04-20 18:43 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 19+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-20 18:43 UTC (permalink / raw)
To: Mike Gilbert; +Cc: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-08 19:28 ` GRUB 2.06 Didier Spaier
2021-04-08 21:26 ` Didier Spaier
@ 2021-04-20 19:58 ` Eli Schwartz
2021-04-21 12:27 ` Daniel Kiper
1 sibling, 1 reply; 19+ messages in thread
From: Eli Schwartz @ 2021-04-20 19:58 UTC (permalink / raw)
To: The development of GNU GRUB, Didier Spaier
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 17:48 ` John Paul Adrian Glaubitz
@ 2021-04-20 20:33 ` Eli Schwartz
2021-04-20 20:43 ` John Paul Adrian Glaubitz
2021-04-21 12:21 ` Daniel Kiper
0 siblings, 2 replies; 19+ messages in thread
From: Eli Schwartz @ 2021-04-20 20:33 UTC (permalink / raw)
To: grub-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 20:33 ` Eli Schwartz
@ 2021-04-20 20:43 ` John Paul Adrian Glaubitz
2021-04-21 12:21 ` Daniel Kiper
1 sibling, 0 replies; 19+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-20 20:43 UTC (permalink / raw)
To: Eli Schwartz; +Cc: The development of GNU GRUB
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 20:33 ` Eli Schwartz
2021-04-20 20:43 ` John Paul Adrian Glaubitz
@ 2021-04-21 12:21 ` Daniel Kiper
1 sibling, 0 replies; 19+ messages in thread
From: Daniel Kiper @ 2021-04-21 12:21 UTC (permalink / raw)
To: Eli Schwartz; +Cc: grub-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GRUB 2.06
2021-04-20 19:58 ` Eli Schwartz
@ 2021-04-21 12:27 ` Daniel Kiper
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Kiper @ 2021-04-21 12:27 UTC (permalink / raw)
To: Eli Schwartz; +Cc: The development of GNU GRUB, Didier Spaier
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
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-04-21 12:27 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-01 0:11 [PATCH 0/2] Misc doc changes Glenn Washburn
2021-04-01 0:11 ` [PATCH 1/2] docs: Add note to cryptomount that UUIDs should be specified without dashes Glenn Washburn
2021-04-01 0:11 ` [PATCH 2/2] docs: Conform badmem and cutmem description indentations with other commands Glenn Washburn
2021-04-08 16:53 ` [PATCH 0/2] Misc doc changes Daniel Kiper
2021-04-08 19:28 ` GRUB 2.06 Didier Spaier
2021-04-08 21:26 ` Didier Spaier
2021-04-20 13:53 ` Daniel Kiper
2021-04-20 14:00 ` John Paul Adrian Glaubitz
2021-04-20 17:34 ` Didier Spaier
2021-04-20 17:48 ` John Paul Adrian Glaubitz
2021-04-20 20:33 ` Eli Schwartz
2021-04-20 20:43 ` John Paul Adrian Glaubitz
2021-04-21 12:21 ` Daniel Kiper
2021-04-20 17:50 ` Mike Gilbert
2021-04-20 18:21 ` Bruce Dubbs
2021-04-20 18:36 ` Mike Gilbert
2021-04-20 18:43 ` John Paul Adrian Glaubitz
2021-04-20 19:58 ` Eli Schwartz
2021-04-21 12:27 ` Daniel Kiper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.