On Thu, Sep 3, 2009 at 3:43 AM, Michal Suchanek wrote:
> 2009/9/2 Bean :
>> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek wrote:
>>> 2009/9/2 Bean :
On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek
wrote:
> How will it fit screen? What if the image is 4:3 and the screen is
> 5
Hi,
I know I've been annoyed by this (as have many others I've talked to). How
about we enabling paging (set pager=1) automatically for the duration of the
help command, since it will inevitable scroll off of the screen for
console output devices with a limited number of lines?
--S
__
Duh. Sorry about that. I was getting "unknown command" errors. I'll try to be a
bit more investigative in the future.
--S
Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Wed, 2...:
On Wed, Sep 2, 2009 at 7:04 AM, Seth Goldberg wrote:
Hi,
Has the idea come up of ha
>Why not just check if the compiler accepts -fno-PIE and use it? No
>harm done if -fPIE wasn't default, right?
--
Didn't want to add -fno-PIE when it was not needed and to be on the
safe side . I can make it to check for -fno-PIE and use that.
Hardened-Development Overlay
Magnus Granberg (Zor
2009/9/2 Bean :
> On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek wrote:
>> 2009/9/2 Bean :
>>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek wrote:
How will it fit screen? What if the image is 4:3 and the screen is
5:4 or widescreen?
>>>
>>> It'd scale to fit the new proportion, alth
On Thu, Sep 3, 2009 at 1:25 AM, Michal Suchanek wrote:
> 2009/9/2 Bean :
>> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek wrote:
>>> How will it fit screen? What if the image is 4:3 and the screen is
>>> 5:4 or widescreen?
>>
>> It'd scale to fit the new proportion, although the image perhaps w
2009/9/2 Bean :
> On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek wrote:
>> How will it fit screen? What if the image is 4:3 and the screen is
>> 5:4 or widescreen?
>
> It'd scale to fit the new proportion, although the image perhaps won't
> look nice in this case. We could choose one of the foll
ChangeLog:
2009-09-02 Yves Blusseau
Change clean rules to properly remove files
* genmk.rb: add new clean rules
* Makefile.in (clean): add the new targets
(mostlyclean): likewise
---
Makefile.in |4 ++--
genmk.rb| 55 +++---
On Wed, Sep 2, 2009 at 11:27 PM, Michal Suchanek wrote:
> How will it fit screen? What if the image is 4:3 and the screen is
> 5:4 or widescreen?
It'd scale to fit the new proportion, although the image perhaps won't
look nice in this case. We could choose one of the following rendering
method ba
2009/9/2 Bean :
> On Wed, Sep 2, 2009 at 7:07 PM, Michal Suchanek wrote:
>> Hello
>>
>> 2009/9/2 Bean :
>> ...
>>> + box {
>>> + screen {
>>> bgimage = "splash.png"
>>> }
>>> }
>>> }
>>
>> Where would this image get displayed? It's highly unlikely it would
>> have the same resolution a
On Wed, Sep 2, 2009 at 7:07 PM, Michal Suchanek wrote:
> Hello
>
> 2009/9/2 Bean :
> ...
>> + box {
>> + screen {
>> bgimage = "splash.png"
>> }
>> }
>> }
>
> Where would this image get displayed? It's highly unlikely it would
> have the same resolution as the screen box.
We have imag
This is an updated version of Vladimir's savedefault patch in
http://lists.gnu.org/archive/html/grub-devel/2009-06/msg2.html. I
think I've taken into account the feedback offered there. It depends on
my recent save_env patch
(http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00038.html).
Hello
2009/9/2 Bean :
...
> + box {
> + screen {
> bgimage = "splash.png"
> }
> }
> }
Where would this image get displayed? It's highly unlikely it would
have the same resolution as the screen box.
>
> + screen {
> + text {
> class = "header"
> x = 10
> y = 10
> text =
This implements saving an environment variable with a given value
without having to set that variable first, as suggested by Pavel here:
http://lists.gnu.org/archive/html/grub-devel/2009-06/msg00190.html
2009-09-02 Colin Watson
* commands/loadenv.c (grub_cmd_save_env): Allow an opti
ChangeLog:
2009-09-02 Yves BLUSSEAU
Embedding loadenv module into grub-emu
* conf/i386-pc.rmk (grub_emu_SOURCES): add lib/envblk.c and
commands/loadenv.c
* conf/i386-coreboot.rmk (grub_emu_SOURCES): Likewise
* conf/i386-efi.rmk (grub_emu_SOURCES): Likewise
* conf/i386-ieee1
On Wed, Sep 02, 2009 at 11:13:19AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Wed, Sep 2, 2009 at 11:06 AM, Colin Watson wrote:
> > I'm afraid I temporarily ran out of steam at this point, so there are
> > still lots of commands to go, but here's a start. Does this look OK?
> >
> > 2009-09-02
On Wed, Sep 2, 2009 at 11:06 AM, Colin Watson wrote:
> I'm afraid I temporarily ran out of steam at this point, so there are
> still lots of commands to go, but here's a start. Does this look OK?
>
> 2009-09-02 Colin Watson
>
> * docs/grub.texi: Describe one-based partition numbering.
>
On Wed, Sep 2, 2009 at 7:04 AM, Seth Goldberg wrote:
> Hi,
>
> Has the idea come up of having a file that maps commands to module names
> along with the required code to autoload the corresponding module(s) when
> the corresponding commands are used (something like:
Actually it's already implement
I'm afraid I temporarily ran out of steam at this point, so there are
still lots of commands to go, but here's a start. Does this look OK?
2009-09-02 Colin Watson
* docs/grub.texi: Describe one-based partition numbering.
Document acpi, blocklist, crc, export, insmod, keystatus,
Hi,
I am about to start a new branch on github for the new menu interface.
Here is the first draft of design.
The building block of menu interface is component. There are two basic
component, text and box, available both for text and graphics mode.
text is a single line of text, while box is a re
20 matches
Mail list logo