Hi,
On Dec/07/2009, Carles Pina i Estany wrote:
> And then implement grub_printf_:
> -
> int
> grub_printf_ (const char *fmt, ...)
> {
> va_list ap;
> int ret;
>
> va_start (ap, fmt);
> ret = grub_vprintf (_(fmt), ap);
actually I would better call grub_printf here instead of gr
On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
> From: Robert Millan
> Date: Sun, 6 Dec 2009 14:10:26 +0100
>
> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
> > of hardcoding, etc.
>
> Well, for one thing I don't use initrd's for my Linux kernels,
> therefore
Am Sonntag, den 06.12.2009, 23:30 -0800 schrieb David Miller:
> I was trying to figure out why the kernel image paths generated
> automatically for me by grub-mkconfig were not correct.
>
> I have /boot on a seperate partition, but in the generated config
> files it uses paths like /boot/vmlinux-2
David Miller wrote:
> From: Robert Millan
> Date: Sun, 6 Dec 2009 14:10:26 +0100
>
>
>> grub-mkconfig generates a grub.cfg that relies on UUIDs instead
>> of hardcoding, etc.
>>
>
> Well, for one thing I don't use initrd's for my Linux kernels,
> therefore specifying root devices via UUIDs
Committed.
David Miller wrote:
> I tried to surmise other ways to do this more cleanly, such as
> resolving the path and looking for some device property inside of the
> resulting node, but there simply isn't anything we can check for.
>
>
If you find a cleaner way we can commit it later. I was
From: Colin Watson
Date: Mon, 7 Dec 2009 10:20:16 +
> On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
>> From: Robert Millan
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>>
>> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
>> > of hardcoding, etc.
>>
>> Well, fo
From: Vladimir '$B&U(B-coder/phcoder' Serbinenko
Date: Mon, 07 Dec 2009 11:48:07 +0100
> The problem actually is the following:
> When we're in OS we know the OS device name but not the firmware device
> name. So we're able to generate correct root= for kernel command line
> but can only guess
From: Vladimir '$B&U(B-coder/phcoder' Serbinenko
Date: Mon, 07 Dec 2009 12:05:24 +0100
> Committed.
> David Miller wrote:
>> I tried to surmise other ways to do this more cleanly, such as
>> resolving the path and looking for some device property inside of the
>> resulting node, but there simpl
From: Felix Zielcke
Date: Mon, 07 Dec 2009 11:39:22 +0100
> Am Sonntag, den 06.12.2009, 23:30 -0800 schrieb David Miller:
>> I was trying to figure out why the kernel image paths generated
>> automatically for me by grub-mkconfig were not correct.
>>
>> I have /boot on a seperate partition, but
David Miller wrote:
> From: Vladimir 'φ-coder/phcoder' Serbinenko
> Date: Mon, 07 Dec 2009 11:48:07 +0100
>
>
>> The problem actually is the following:
>> When we're in OS we know the OS device name but not the firmware device
>> name. So we're able to generate correct root= for kernel command
David Miller wrote:
> From: Vladimir 'φ-coder/phcoder' Serbinenko
> Date: Mon, 07 Dec 2009 12:05:24 +0100
>
>
>> Committed.
>> David Miller wrote:
>>
>>> I tried to surmise other ways to do this more cleanly, such as
>>> resolving the path and looking for some device property inside of the
On Fri, Dec 04, 2009 at 10:31:54PM +0100, Robert Millan wrote:
> On Wed, Dec 02, 2009 at 10:14:29AM +, Colin Watson wrote:
> > On Wed, Dec 02, 2009 at 10:01:44AM +0100, Richard Hartmann wrote:
> > > On Wed, Dec 2, 2009 at 09:47, Colin Watson wrote:
> > > > Thanks for your patch. However, it ap
On Sun, Dec 06, 2009 at 12:28:11AM +, Carles Pina i Estany wrote:
> Is it fine to have a translatable string ended with a space? I think
> that it's fine (same case than \n, even thought in this case msgfmt is
> not warning).
In my experience as a translator and as a i18n coordinator, I know t
On Sun, Dec 06, 2009 at 04:21:50PM -0800, David Miller wrote:
> From: Robert Millan
> Date: Sun, 6 Dec 2009 14:10:26 +0100
>
> > We're actually in the process of getting rid of device.map;
>
> Meanwhile, please fix the regression you added to the tree. :-)
I think this should do it. Please can
On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
> From: Robert Millan
> Date: Sun, 6 Dec 2009 14:10:26 +0100
>
> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
> > of hardcoding, etc.
>
> Well, for one thing I don't use initrd's for my Linux kernels,
> therefore
Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
(IMO rightly!) complain about constructs such as this:
grub_printf (_("foo"));
... because it's all too easy for a translator to (usually accidentally)
insert % sequences which would cause printf to behave incorrectly. This
s
As Robert said recently, we're trying to get rid of our reliance on
device.map. Right now, it is still necessary to at least have entries in
device.map for any disks you wish to use with GRUB, although they don't
have to be particularly sensible; any bidirectional mapping will do (at
least as long
Hi,
We have an obvious problem with the Multiboot 2 loader: It's in
severe bitrot. Nobody complains because nobody uses it, which is
understandable given that nobody programs for MB2, because it's not
ready (both in spec and in implementation), and we don't improve it
because nobody complains,
On Fri, Sep 04, 2009 at 06:47:17PM +0200, Neal H. Walfield wrote:
> At Wed, 2 Sep 2009 02:49:39 +0100,
> Colin Watson wrote:
> > +#ifndef HAVE_VASPRINTF
> > +
> > +int
> > +vasprintf (char **buf, const char *fmt, va_list ap)
> > +{
> > + /* Should be large enough. */
> > + *buf = xmalloc (512);
Robert Millan, le Mon 07 Dec 2009 16:08:31 +0100, a écrit :
> - Release a new revision of Multiboot 1, with only modifications that don't
> alter the spec. I.e. GRUB Legacy continues to be compliant, and we don't
> change the signature. These modifications would basically cope with the
On Mon, Dec 07, 2009 at 02:28:06PM +, Colin Watson wrote:
> As Robert said recently, we're trying to get rid of our reliance on
> device.map. Right now, it is still necessary to at least have entries in
> device.map for any disks you wish to use with GRUB, although they don't
> have to be parti
I did a fresh checkout of revision 1917 and autogen.sh produces several
warnings, although the configure and make stages are OK. I am using
relatively new versions of autoconf and automake:
automake (GNU automake) 1.11
autoconf (GNU Autoconf) 2.64
When building, a lot of warnings is a red fla
On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
> configure.ac:176: required file `./config.rpath' not found
>
> The can be fixed by `touch config.rpath`
configure does actually run this, so I'd recommend copying the file from
gettext or gnulib instead.
> automake: no `Makefile.am' f
From: Vladimir '$B&U(B-coder/phcoder' Serbinenko
Date: Mon, 07 Dec 2009 12:52:01 +0100
> It already works on MIPS and AFAICT only thing it needs to work is PCI.
> Do you mean that accessing PCI on sparc is a lot of work?
Even just calculating the register addresses is a lot of work.
You can't
From: Robert Millan
Date: Mon, 7 Dec 2009 15:05:16 +0100
> On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
>> From: Robert Millan
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>>
>> > grub-mkconfig generates a grub.cfg that relies on UUIDs instead
>> > of hardcoding, etc.
>>
>> Well, f
Bruce Dubbs wrote:
> I did a fresh checkout of revision 1917 and autogen.sh produces
> several warnings, although the configure and make stages are OK. I am
> using relatively new versions of autoconf and automake:
>
> automake (GNU automake) 1.11
> autoconf (GNU Autoconf) 2.64
>
> When building,
Hello,
On Dec/07/2009, Colin Watson wrote:
> Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
> (IMO rightly!) complain about constructs such as this:
>
> grub_printf (_("foo"));
I see...
(actually some weeks ago I thought about gettext security implications,
and I though
On Mon, Dec 07, 2009 at 11:50:33AM -0800, David Miller wrote:
> From: Robert Millan
> Date: Mon, 7 Dec 2009 15:05:16 +0100
>
> > On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
> >> From: Robert Millan
> >> Date: Sun, 6 Dec 2009 14:10:26 +0100
> >>
> >> > grub-mkconfig generates a
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Thanks. I'll let someone more familiar with automake to review automake
parts. Just a comment to import_gcry
These are generated by util/import_gcry.py by copying (and in some
cases modifying) the files in lib/libgcrypt to lib/libgcrypt-grub. It
al
On Mon, Dec 07, 2009 at 08:14:08PM +, Carles Pina i Estany wrote:
> On Dec/07/2009, Colin Watson wrote:
> > Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
> > (IMO rightly!) complain about constructs such as this:
> >
> > grub_printf (_("foo"));
>
> I see...
> (actual
Colin Watson wrote:
On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
configure.ac:176: required file `./config.rpath' not found
The can be fixed by `touch config.rpath`
configure does actually run this, so I'd recommend copying the file from
gettext or gnulib instead.
The gettex
Hi,
Attached a patch that makes a new function (grub_printf_) which one
calls _( ) for the format argument. Also adapts the current
translations but not the pending patch.
Can someone take a look? If the grub_printf_ approach is used then this
should be committed. Conflicts with Colin Watson ide
Hi,
On Dec/07/2009, Jordi Mallach wrote:
> On Sun, Dec 06, 2009 at 12:28:11AM +, Carles Pina i Estany wrote:
> > Is it fine to have a translatable string ended with a space? I think
> > that it's fine (same case than \n, even thought in this case msgfmt is
> > not warning).
[...]
> IME, if
Robert Millan wrote:
> On Mon, Dec 07, 2009 at 11:50:33AM -0800, David Miller wrote:
>
>> From: Robert Millan
>> Date: Mon, 7 Dec 2009 15:05:16 +0100
>>
>>
>>> On Sun, Dec 06, 2009 at 05:22:52PM -0800, David Miller wrote:
>>>
From: Robert Millan
Date: Sun, 6 Dec 2009 14:1
Colin Watson wrote:
> Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
> (IMO rightly!) complain about constructs such as this:
>
> grub_printf (_("foo"));
>
> ... because it's all too easy for a translator to (usually accidentally)
> insert % sequences which would cause prin
Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller:
> In fact I don't see why these scripts don't do that, and relatively
> resolve the /boot directory whatever seperately.
Because it's faster to just call once for the directory
make_system_path_relative_to_its_root() instead of once for
Bruce Dubbs wrote:
>
> I'm not sure GRUB uses or needs the output of config.rpath. I was
> just suppressing a warning.
>
Just suppressing warning is a wrong approach. If warning is there it
usually means there is a reason for it. And the reason should be
corrected, we shouldn't just silence the wa
Bruce Dubbs wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> Thanks. I'll let someone more familiar with automake to review automake
>> parts. Just a comment to import_gcry
>
>>> These are generated by util/import_gcry.py by copying (and in some
>>> cases modifying) the files in lib/libgc
On Mon, Dec 07, 2009 at 02:28:19PM -0600, Bruce Dubbs wrote:
> Colin Watson wrote:
>> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
>>> configure.ac:176: required file `./config.rpath' not found
>>>
>>> The can be fixed by `touch config.rpath`
>>
>> configure does actually run this,
Hi,
On Dec/07/2009, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 08:14:08PM +, Carles Pina i Estany wrote:
> > a) It's a bit of false security because it's not fixing the case of file
> > normal/menu_text.c, line 191 (search the string "Use the %C and %C keys
> > to") or menu_text.c line 37
Carles Pina i Estany wrote:
> Hi,
>
> Attached a patch that makes a new function (grub_printf_) which one
> calls _( ) for the format argument. Also adapts the current
> translations but not the pending patch.
>
> Can someone take a look? If the grub_printf_ approach is used then this
> should be c
I've been looking at autogen.sh some more.
Does anyone know why the lines:
# FIXME: automake doesn't like that there's no Makefile.am
automake -a -c -f || true
are present at all? Since there is no Makefile.am, it looks like
automake only creates a few files and aborts.
Doing an experiment,
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Bruce Dubbs wrote:
I'm not sure GRUB uses or needs the output of config.rpath. I was
just suppressing a warning.
Just suppressing warning is a wrong approach. If warning is there it
usually means there is a reason for it. And the reason should be
On Mon, Dec 07, 2009 at 11:04:52PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Colin Watson wrote:
> > Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
> > (IMO rightly!) complain about constructs such as this:
> >
> > grub_printf (_("foo"));
> >
> > ... because it
Hi,
On Dec/07/2009, Vladimir '??-coder/phcoder' Serbinenko wrote:
> Colin Watson wrote:
> > Ubuntu's GCC enables -Wformat-security by default. This causes GCC to
> > (IMO rightly!) complain about constructs such as this:
> >
> > grub_printf (_("foo"));
> >
> > ... because it's all too easy for
From: Felix Zielcke
Date: Mon, 07 Dec 2009 23:06:46 +0100
> Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller:
>> In fact I don't see why these scripts don't do that, and relatively
>> resolve the /boot directory whatever seperately.
>
> Because it's faster to just call once for the d
Carles Pina i Estany wrote:
> Hello,
>
> I've started to add gettext support in commands/*
>
> See the attached patch and ChangeLog.
>
> It's not completely exhaustive (hdparm is not in this patch).
>
> Comments before committing?
>
> Notice the the grub_register_command use N_(" ") and then these
Carles Pina i Estany wrote:
> And confirmed: if the translator adds %C in the second string
> ("Booting a command list") msgfmt -c is not complaining.
>
> So I would apply your patch, after understanding that it's only for
> strings that doesn't have any %C (and in my opinion xgettext could
> add t
Colin Watson wrote:
On Mon, Dec 07, 2009 at 02:28:19PM -0600, Bruce Dubbs wrote:
Colin Watson wrote:
It is very likely to be incorrect to suppress a warning about a missing
executable by touching an empty file.
As I said, configure does use the output of config.rpath. You can verify
this f
Hi,
On Dec/07/2009, Carles Pina i Estany wrote:
> So I would apply your patch, after understanding that it's only for
one more thing Colin. What do you think to not apply your patch and
apply the attached patch?
It force that the argument 1 of _ and N_ is a c-format (in this way
appears in gru
Furthermore, the style I suggested is used in many other GNU projects.
Here are just a few examples:
coreutils/src/du.c:994: error (0, 0, "%s", _("invalid zero-length file
name"));
diffutils/src/sdiff.c:853: fprintf (stderr, "%s", _("\
diffutils/src/sdiff.c-854-ed:\tEdit then use bot
On Mon, Dec 07, 2009 at 04:49:08PM -0600, Bruce Dubbs wrote:
> I've been looking at autogen.sh some more.
>
> Does anyone know why the lines:
>
> # FIXME: automake doesn't like that there's no Makefile.am
> automake -a -c -f || true
>
> are present at all? Since there is no Makefile.am, it looks l
On Mon, Dec 07, 2009 at 09:11:00PM +, Carles Pina i Estany wrote:
> +int
> +grub_printf_ (const char *fmt, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start (ap, fmt);
> + ret = grub_printf (_(fmt), ap);
Doesn't this need to be grub_vprintf?
--
Colin Watson
On Tue, Dec 08, 2009 at 12:25:01AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Your N_ patch superseeds Colin's patch. Feel free to use printf_ where
> necessary. It solves format-security problems
It only works around the compiler warning if functions have not been
given the correct fu
On Mon, Dec 07, 2009 at 11:38:04PM +, Carles Pina i Estany wrote:
> On Dec/07/2009, Carles Pina i Estany wrote:
> > So I would apply your patch, after understanding that it's only for
>
> one more thing Colin. What do you think to not apply your patch and
> apply the attached patch?
>
> It fo
Colin Watson wrote:
> Furthermore, the style I suggested is used in many other GNU projects.
> Here are just a few examples:
>
> coreutils/src/du.c:994: error (0, 0, "%s", _("invalid zero-length
> file name"));
> diffutils/src/sdiff.c:853: fprintf (stderr, "%s", _("\
> diffutils/src/s
On Mon, Dec 07, 2009 at 10:46:30PM +, Carles Pina i Estany wrote:
> Your patch conflicts with my one (Subject: gettext: grub_printf_ and N_)
> but it's not a big problem. If you commit before I would adapt
> my one, else I would adapt your one.
Please go ahead with your patch after due discus
Colin Watson wrote:
> On Mon, Dec 07, 2009 at 04:49:08PM -0600, Bruce Dubbs wrote:
>
>> I've been looking at autogen.sh some more.
>>
>> Does anyone know why the lines:
>>
>> # FIXME: automake doesn't like that there's no Makefile.am
>> automake -a -c -f || true
>>
>> are present at all? Since
Hi,
On Dec/07/2009, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 09:11:00PM +, Carles Pina i Estany wrote:
> > +int
> > +grub_printf_ (const char *fmt, ...)
> > +{
> > + va_list ap;
> > + int ret;
> > +
> > + va_start (ap, fmt);
> > + ret = grub_printf (_(fmt), ap);
>
> Doesn't this nee
On Tue, Dec 08, 2009 at 12:59:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Colin Watson wrote:
> > Furthermore, the style I suggested is used in many other GNU projects.
> > Here are just a few examples:
> >
> > coreutils/src/du.c:994: error (0, 0, "%s", _("invalid zero-lengt
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Why can't Makefile.in moved to Makefile.am and then just let automake
mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea
I've been invoking automake for years, but not writing for it. I'll
volunteer to try to make a prope
Hi,
On Dec/08/2009, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 10:46:30PM +, Carles Pina i Estany wrote:
> > Your patch conflicts with my one (Subject: gettext: grub_printf_ and N_)
> > but it's not a big problem. If you commit before I would adapt
> > my one, else I would adapt your one.
Colin Watson wrote:
> What on earth?! I said nothing of the kind! That would obviously be
> completely insane.
Sorry for having misunderstood you.
> How did you arrive at that impression?
>
Extrapolation of proposed changes since a lot of patches in gettext
threads were "samples".
> My patch ma
On Tue, Dec 08, 2009 at 01:01:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Why can't Makefile.in moved to Makefile.am and then just let automake
> mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea
I wouldn't recommend it. The syntax looks similar, but ther
Colin Watson wrote:
> I wouldn't recommend it. The syntax looks similar, but there are some
> slight differences, and Automake has its own ideas of what rules and
> variables you are and aren't allowed to override. Besides, there's quite
> a lot of stuff that Automake will output even with an entir
On Mon, Dec 7, 2009 at 13:48, Colin Watson wrote:
> OK. I've committed the patch at the head of this thread, then. Thanks,
> Richard.
Thanks for commiting to legacy :)
Richard
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mail
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Colin Watson wrote:
I wouldn't recommend it. The syntax looks similar, but there are some
slight differences, and Automake has its own ideas of what rules and
variables you are and aren't allowed to override. Besides, there's quite
a lot of stuff that
From: Felix Zielcke
Date: Mon, 07 Dec 2009 11:39:22 +0100
> The one mount point case is now fixed in r1917
> See Subject: `handling mount points in grub-mkrelpath' from me for the
> patch.
Seems to work properly now. The paths all start with "//" but
I guess that's ok.
Thanks!
__
From: Robert Millan
Date: Mon, 7 Dec 2009 15:04:11 +0100
> On Sun, Dec 06, 2009 at 04:21:50PM -0800, David Miller wrote:
>> From: Robert Millan
>> Date: Sun, 6 Dec 2009 14:10:26 +0100
>>
>> > We're actually in the process of getting rid of device.map;
>>
>> Meanwhile, please fix the regression
69 matches
Mail list logo
