On 03.03.2012 08:33, Seth Goldberg wrote:
Hi,
This code in menu.c::menuentry_eq() looks wrong:
{
const char *ptr1, *ptr2;
ptr1 = title;
ptr2 = spec;
while (1)
{
if (*ptr2 == '>'&& ptr2[1] != '>'&& *ptr1 == 0)
return 1;
if (*ptr2 == '>'&& ptr2[1] !=
Hello, all. Currently we use and recommend using the title for default
variable. It has however following problems:
1) When device names change the title changes (because of the "(on
$device)" part)
2) If user changes locale the part ", with" gets translated and again
the title changes
Attached
On 03.03.2012 15:02, Seth Goldberg wrote:
Sigh. I thought I tracked it down to this code, but it was late. I'll
double-check. The buggy behavior is as I described -- this just may not be the
actual root cause. BTW, with the code below, does this mean that having '>'
characters in the title
On 29.02.2012 07:10, Jordan Uggla wrote:
In my first patch I rather stupidly asked gettext for a translation of "%s".
Updated patch below does not have this mistake.
I attach the update on the top of menuid.
I think it would be bad to break every time user changes the
configuration entry. So I
On Sat, Mar 03, 2012 at 02:37:12PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Attached patch changes it to the use of IDs specified by --id but
> keeps title possiblity for backward compatibility. Any comments?
Massive +1 here!
This was something that bugged me quite a lot. Thanks for
Right now I believe that (1) is the most reasonable
Somethine like in the attached patch. I haven't tested it yet in real
migration scenario though
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'util/grub-mkconfig.in'
--- util/grub-mkconfig.in 2012-03-03 12:05:08 +000
Vladimir,
this enhancement is part of my patches which i sent some days ago.
I introduced an option "--label STRING" which will be used for display
if it's set and which can also have environment variables (another part
of my patches).
It's just a matter of taste though if to use a new optio
On 03.03.2012 15:51, Andreas Vogel wrote:
Vladimir,
this enhancement is part of my patches which i sent some days ago.
I introduced an option "--label STRING" which will be used for display
if it's set and which can also have environment variables (another
part of my patches).
It's just
Update
On 03.03.2012 15:41, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Right now I believe that (1) is the most reasonable
Somethine like in the attached patch. I haven't tested it yet in real
migration scenario though
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified fi
> Hi,
>
> This code in menu.c::menuentry_eq() looks wrong:
>
> {
> const char *ptr1, *ptr2;
> ptr1 = title;
> ptr2 = spec;
> while (1)
> {
> if (*ptr2 == '>' && ptr2[1] != '>' && *ptr1 == 0)
> return 1;
> if (*ptr2 == '>' && ptr2[1] != '>')
> return 0;
>
On 03.03.2012 19:10, Andreas Vogel wrote:
Hi,
This code in menu.c::menuentry_eq() looks wrong:
{
const char *ptr1, *ptr2;
ptr1 = title;
ptr2 = spec;
while (1)
{
if (*ptr2 == '>'&& ptr2[1] != '>'&& *ptr1 == 0)
return 1;
if (*ptr2 == '>'&& ptr2[1] !=
Am 03.03.2012 19:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 03.03.2012 19:10, Andreas Vogel wrote:
>>> Hi,
>>>
>>>This code in menu.c::menuentry_eq() looks wrong:
>>>
>>> {
>>>const char *ptr1, *ptr2;
>>>ptr1 = title;
>>>ptr2 = spec;
>>>while (1)
>>> {
>>>
BTW, one of the features which are missing and about what i read in
different forums is that it's not possible to reference entries in the
menu tree by number, e.g. "0>2>4>2".
This should work but isn't recommended if it doesn't please supply a
testcase or a fix.
--
Regards
Vladimir 'φ-
>> BTW, one of the features which are missing and about what i read in
>> different forums is that it's not possible to reference entries in the
>> menu tree by number, e.g. "0>2>4>2".
>
> This should work but isn't recommended if it doesn't please supply a
> testcase or a fix.
>
>
Just to let
I was thinking about your proposal again and I think your idea
introducing a --id option is better than my idea having a --label option.
> === modified file 'include/grub/menu.h'
> --- include/grub/menu.h 2011-01-10 22:27:58 +
> +++ include/grub/menu.h 2012-03-03 12:11:30 +
> @
On 03.03.2012 20:48, Andreas Vogel wrote:
I was thinking about your proposal again and I think your idea
introducing a --id option is better than my idea having a --label option.
=== modified file 'include/grub/menu.h'
--- include/grub/menu.h 2011-01-10 22:27:58 +
+++ include/grub/menu.h 20
> + menu_id = grub_strdup (id ? : menu_title);
I don't know about the policy for grub code regarding GNU compiler
extensions... at least you don't need in this place.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinf
On 03.03.2012 21:08, Andreas Vogel wrote:
+ menu_id = grub_strdup (id ? : menu_title);
I don't know about the policy for grub code regarding GNU compiler
extensions... at least you don't need in this place.
We support only GCC. Any of its extensions available since 4.2 and not
too obscure can
Here is a small patch which enhances the hotkey handling for menu entries.
- new static function parse_key()
- hotkey aliases are now case insensitive
- additional hotkey aliases
- handling now and modifiers for hotkeys
Any chance that this is included (Vladimir:
Here is another tiny patch which uses a enum to reference the options
array when dealing with command line options for a menuentry.
This method is already used by some other modules. I have some more
patches which are adding more options for the menuentry command so
finally readabilty will be impr
On 03.03.2012 21:43, Andreas Vogel wrote:
Here is a small patch which enhances the hotkey handling for menu entries.
Could you use GNU style? You miss the spaces before braces. Comments
have to be full sentences, start with uppercase and end with a dot
followed by 2 spaces.
Comment /*NOTHING*/
This tiny patch enables short command line options for the
menuentry/submenu command.
Any comments?
Andreas
revno: 4100
committer: Andreas Vogel
branch nick: 03-menuentry_short_options
timestamp: Thu 2012-03-01 22:42:05 +0100
message:
On 03.03.2012 21:50, Andreas Vogel wrote:
+enum options
+ {
Please don't define a type here, especially that a type "options" can
easily conflict with something else.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Gru
On 06.02.2012 21:27, Richard Laager wrote:
I tried booting off a 3-disk raidz1 pool. By default, ZFS on Linux uses
a GPT label even for whole-disk pools. I've also tried overriding that
and putting the zpool directly on the 3 disks.
Either way, grub-probe / is happy. grub-install /dev/sda doesn'
Keep list CC'ed.
On 03.03.2012 22:13, Andreas Vogel wrote:
On 03.03.2012 21:50, Andreas Vogel wrote:
+enum options
+ {
Please don't define a type here, especially that a type "options" can
easily conflict with something else.
I reused that idea from commands/search_wrap.c and basically i lik
> On 03.03.2012 21:43, Andreas Vogel wrote:
>> Here is a small patch which enhances the hotkey handling for menu
>> entries.
> Could you use GNU style? You miss the spaces before braces.
Sure. Missed by accident.
> Comments have to be full sentences, start with uppercase and end with
> a dot foll
> Keep list CC'ed.
> On 03.03.2012 22:13, Andreas Vogel wrote:
>>> On 03.03.2012 21:50, Andreas Vogel wrote:
+enum options
+ {
>>> Please don't define a type here, especially that a type "options" can
>>> easily conflict with something else.
>>>
>> I reused that idea from commands/searc
On 01.03.2012 20:47, Lennart Sorensen wrote:
root@rceng03new:~# /usr/sbin/grub-probe --device /dev/md1 --target=partmap
/usr/sbin/grub-probe: error: disk `mduuid/dc00bd3a0e9491bb0b66fa8b9246c2e8' not
found.
Attached patch eliminates some idiosyncracies problems with mdraid 1.x.
Also fixes parti
On 30.06.2010 19:10, step...@hyarros.com wrote:
GOP info:
List of video modes:
0: 1024 x 768, bitonly, scan line 1024
Current mode: 0
"bitonly" is a fancy way of telling "useless". Now GRUB ignores the GOP
interfaces like this. Some EFI versions have several GOP interfaces and
hopefully GRUB wi
29 matches
Mail list logo
