Am Mittwoch, den 03.09.2008, 19:47 -0400 schrieb Pavel Roskin:
> You can get the current config.* files from CVS:
> cvs -d :pserver:[EMAIL PROTECTED]:/sources/config co config
> They are maintained in a very conservative matter, so it may be better
> to use the CVS versions. Actually, it's possi
Am Mittwoch, den 03.09.2008, 19:43 -0400 schrieb Pavel Roskin:
>
> I don't see any old stuff being removed. I don't see any justification
> for any of the changes. The new code is longer and less readable. I
> don't think AC_TRY_COMPILE is a big problem yet. It's not like it won't
> produce a
static grub_err_t
grub_raid_read (grub_disk_t disk, grub_disk_addr_t sector,
grub_size_t size, char *buf)
case 0:
case 1:
case 10:
{
read_sector = grub_divmod64 (sector, array->chunk_size, &b);
Bean, this is a bit wrong because array->chunk_size is 0 in
With my configure.ac autoconf[0] topic I just got the idea to add
`-Wall' option to `autoconf' in `autogen.sh'
We're using -Wall for gcc so why not for autoconf and autoheader too?
Then once in a while someone will hopefully notice that something might
need a change and will look into it.
[0] h
There was already the topic to rename update-grub to grub-update[0]
On Debian such things are always called update-something not
something-update[1]
I just told again in a Debian Bugreport to use grub-install to update
grub in real.
So I suggest to rename update-grub to something like update-gru
On Thu, 2008-09-04 at 14:22 +0200, Felix Zielcke wrote:
> There was already the topic to rename update-grub to grub-update[0]
>
> On Debian such things are always called update-something not
> something-update[1]
>
> I just told again in a Debian Bugreport to use grub-install to update
> grub in
On Thu, 2008-09-04 at 13:16 +0200, Felix Zielcke wrote:
> With my configure.ac autoconf[0] topic I just got the idea to add
> `-Wall' option to `autoconf' in `autogen.sh'
>
> We're using -Wall for gcc so why not for autoconf and autoheader too?
>
> Then once in a while someone will hopefully noti
On Thu, 2008-09-04 at 09:45 +0200, Felix Zielcke wrote:
> > Okuji wrote that he uses Autoconf 2.59, so it would be nice to check
> > that your changes would still work with that version.
>
> Luckly it's still avaible in Debian oldstable (sarge)
> newest CentOS 5.2 even still has autoconf 2.59
> C
Am Donnerstag, den 04.09.2008, 12:49 -0400 schrieb Pavel Roskin:
> I'm fine with the shorter patch, but I'd like you to wait a couple of
> days in case there are any objections.
Vesa said already on IRC to me that it's fine for me to but he suggests
waiting vor Okuji or Marco which I wanted to do
Pavel Roskin wrote:
> On Thu, 2008-09-04 at 14:22 +0200, Felix Zielcke wrote:
>> There was already the topic to rename update-grub to grub-update[0]
>>
>> On Debian such things are always called update-something not
>> something-update[1]
>>
>> I just told again in a Debian Bugreport to use grub-in
Am Donnerstag, den 04.09.2008, 12:44 -0400 schrieb Pavel Roskin:
> Fine, but only if we decide to fix the existing warnings. I'm not sure
> it's worth the trouble. Just because a macro is considered obsolete,
> it's not necessarily broken. End users won't run Autoconf, so they
> won't have probl
Am Donnerstag, den 04.09.2008, 20:38 +0300 schrieb Vesa Jääskeläinen:
> > If you are going to rename it, please use a name starting with "grub",
> > not with "update". Debian is free to provide a wrapper starting with
> > "update".
>
> How about grub-update-config ?
I have now read over the old
Am Dienstag, den 02.09.2008, 07:30 -0400 schrieb Pavel Roskin:
> If I was releasing GRUB, I would avoid using DISTLIST even temporarily.
> I would use a separate script for making releases that would:
>
> 1) call "svn export" to create a clean tree
> 2) create generated files
> 3) remove non-dist
On Wed, Sep 03, 2008 at 04:15:33PM +0530, BVK Chaitanya wrote:
> Hi,
>
>
> What is the conclusion of this thread? is this idea still explored?
>
>
> Robert Millan wrote:
> >
> >The first concern that comes to mind is how would GRUB coexist with the
> >payload area which precisely starts at 0x1
Am Donnerstag, den 04.09.2008, 11:29 +0200 schrieb Felix Zielcke:
> The easiest fix would be probable to just set chunk_size to for example
> 64.
> Attached patch does it, but maybe you have a better/other idea?
Thanks to Bean on IRC.
I think this is now the right place to do it, at end of insert
On Wed, Sep 03, 2008 at 07:44:33PM +0300, Vesa Jääskeläinen wrote:
>
> Do anyone have skills to decipher Lua's license is it compatible with
> GPLv3 ?
Yes. It's a standard MIT/X11 style license.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
ho
On Wed, Sep 03, 2008 at 02:25:51PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
> >> Hello, all.
> >> For some FS sometimes additional functions are needed. It could be some
> >> type of control (e.g. in ZFS manage zpools) or preparation
On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >
> > I assume you talk about GRUB loading itself; what kind of information would
> > you pass from one GRUB to the other?
> Boot device,
Multiboot already handles that (although it's not reliable; I don't
think this feature should be us
On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>
> Possibilites are there, but basically they are limited to something like:
>
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
I think this is overkill, and doesn't really address the root of the problem.
The real s
On Wed, Sep 03, 2008 at 08:08:50PM +0200, phcoder wrote:
> Hello. I was looking at the grub code and seen that if a disk has
> multiple partition tables (e.g. macintel with bootcamp) then only first
> one will be detected. In some cases it can lead to unreachable
> partitions if for some reason par
On Thu, Sep 04, 2008 at 07:50:19PM +0200, Felix Zielcke wrote:
>
> I have now read over the old thread, I was just too lazy first and it
> was half a year old anyway.
> Okuji suggested grub-update-config too.
>
> Personally as a user I would still prefer update-grub* and even
> install-grub
> Bec
Commited in the hope that Marco isn't angry with me ;)
and I noticed I used still past once and there was a reason for len = +1
and if < len not <= len
Am Dienstag, den 02.09.2008, 17:59 +0200 schrieb Felix Zielcke:
> Am Dienstag, den 02.09.2008, 17:59 +0300 schrieb Vesa Jääskeläinen:
> > Felix
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:25:51PM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
Hello, all.
For some FS sometimes additional functions are needed. It could be some
type of control (e.g. in ZFS manage
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
>>> I assume you talk about GRUB loading itself; what kind of information would
>>> you pass from one GRUB to the other?
>> Boot device,
>
> Multiboot already handles that (although it's not reliable; I don't
> think
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>> Possibilites are there, but basically they are limited to something like:
>>
>> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
>
> I think this is overkill, and doesn't really address the root o
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:08:50PM +0200, phcoder wrote:
>> Hello. I was looking at the grub code and seen that if a disk has
>> multiple partition tables (e.g. macintel with bootcamp) then only first
>> one will be detected. In some cases it can lead to unreachable
>> partit
BTW GPT module checks the protective MBR. In some cases when legay OS
modified the MBR it's no longer "protective MBR". And in theese cases
GRUB will refuse to boot. Isn't the magic number check enough?
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:08:50PM +0200, p
El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
> phcoder wrote:
> > Hello. In this case we can transfer the whole functionality located in
> > kern/loader.c to a dedicated module boot.mod. This module will also
> > register "boot" command. In this way the encapsulation won't be b
hi, all:
Collin has submit the 'Fancy Menu', when it will be available on the main
svn thread?
And i want to make sure:
- the fancy menu will support two bytes language?
- the vbe engine support non linear frame buffer modes?
i read the vbe.c line 445:
/* We support o
Lua has been widely used. for example, the Warcraft, the 'AutoPlay Menu
Studio', 'Adobe Photoshop Lightroom'; Samba4, Damn Small Linux, SciTE ...
here are two list:
http://lua-users.org/wiki/LuaUses,
http://en.wikipedia.org/wiki/Lua_%28programming_language%29#Applications
so, i think, we can
30 matches
Mail list logo
