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 possible
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
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]
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
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 real.
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
Changes
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
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
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 for OS
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 zpools) or
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 this
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 of the
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
partitions if
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,
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 broken
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
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
17 matches
Mail list logo
