On Tue, Sep 19, 2006 at 04:24:17PM +0200, Wouter Verhelst wrote:
On Mon, Sep 18, 2006 at 12:36:00PM -0400, Nathanael Nerode wrote:
Perhaps the correct structure is this: after choosing Customization
modules, the user gets a menu of possible places to get them from (CD,
USB, floppy, net,
On Mon, Sep 18, 2006 at 12:36:00PM -0400, Nathanael Nerode wrote:
Wouter Verhelst wrote:
Can people please have a look and comment? I'd like to avoid some
specific GR by making whatever is going to be voted upon moot ;-)
We should have a way of doing the same thing, only with a custom
On Mon, Sep 18, 2006 at 01:12:52PM -0400, Nathanael Nerode wrote:
posted mailed
Wouter Verhelst wrote:
On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote:
Feedback is welcome.
Since the only feedback I received thus far was Goswin von Brederlow
saying he liked the
Wouter Verhelst wrote:
I've been thinking that the best way here is to just nuke the
configuration of the retriever before (or while) running
customization-modules in some way. We'll be assuming that there is at
least one way to get udebs onto the running debian-installer session; so
the
On Fri, Sep 08, 2006 at 10:55:12AM +0200, Goswin von Brederlow wrote:
Yoe recently checked in support for a trivial udeb image. You just
dump whatever udeb you want on the floppy, cd, usb, whatever and then
select a menu entry to install *.udeb from that medium.
Please do test it.
Where to
Joey Hess wrote:
Wouter Verhelst wrote:
Since the most central point of disagreement seems to be around the need
to support non-free firmware from the installation (whether by doing
that through supporting the non-free repository, or by just dropping
these firmware blobs in main, or
Wouter Verhelst wrote:
On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote:
Feedback is welcome.
Since the only feedback I received thus far was Goswin von Brederlow
saying he liked the idea, and since I didn't have much else to do today
(other than wait for a supplier...), I
posted mailed
Wouter Verhelst wrote:
On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote:
Feedback is welcome.
Since the only feedback I received thus far was Goswin von Brederlow
saying he liked the idea, and since I didn't have much else to do today
(other than wait for a
Joey Hess [EMAIL PROTECTED] writes:
Wouter Verhelst wrote:
* In case we're installing from the network, download (using a TFTP
client) a tarball with udebs from the same TFTP server we've booted
from (which would require us to figure out somehow where we booted
from). I *think* all
Rick Thomas [EMAIL PROTECTED] writes:
On Sep 7, 2006, at 3:05 PM, Joey Hess wrote:
This won't be practical. They are just udebs, but they have complex
interdependencies and we can't expect users to pick the right set of
udebs to put on a driver floppy that both supports all the hardware
Wouter Verhelst wrote:
Your mail suggests a number of things, but I feel most of those are
redundant; it should be possible to do just a subset.
My mail tries to explore all the positibities, it doesn't suggest
implementing them all. However, a certian amount of redundancy is
necessary to get
On Thu, Sep 07, 2006 at 03:05:09PM -0400, Joey Hess wrote:
Wouter Verhelst wrote:
Your mail suggests a number of things, but I feel most of those are
redundant; it should be possible to do just a subset.
My mail tries to explore all the positibities, it doesn't suggest
implementing them
On Sep 7, 2006, at 3:05 PM, Joey Hess wrote:
This won't be practical. They are just udebs, but they have complex
interdependencies and we can't expect users to pick the right set of
udebs to put on a driver floppy that both supports all the hardware
they
need to support and fit in its
On Thu, Sep 07, 2006 at 07:02:18PM -0400, Rick Thomas wrote:
On Sep 7, 2006, at 3:05 PM, Joey Hess wrote:
This won't be practical. They are just udebs, but they have complex
interdependencies and we can't expect users to pick the right set of
udebs to put on a driver floppy that both
Hi,
In the discussion about firmware-in-main, one argument that has come up
consistently is the fact that d-i doesn't currently support non-free,
and that implementing this support would take a significant development
effort. AIUI, anna would need to be updated to support multiple
installation
On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote:
Feedback is welcome.
Since the only feedback I received thus far was Goswin von Brederlow
saying he liked the idea, and since I didn't have much else to do today
(other than wait for a supplier...), I went ahead and wrote it. It's
Wouter Verhelst wrote:
Since the most central point of disagreement seems to be around the need
to support non-free firmware from the installation (whether by doing
that through supporting the non-free repository, or by just dropping
these firmware blobs in main, or whatnot), I'm trying to
On Tue, Sep 05, 2006 at 04:07:10PM -0400, Joey Hess wrote:
Wouter Verhelst wrote:
Since the most central point of disagreement seems to be around the need
to support non-free firmware from the installation (whether by doing
that through supporting the non-free repository, or by just
So there are cases of:
* CD-ROM drives needing firmware somewhere along the path (IDE/SATA
controller, drive itself perhaps?, more stuff...)
If you have a cdrom behind a firmware requiring scsi controller. Not so
likely, but not completely impossible. I have never seen
cdrom drives requiring
19 matches
Mail list logo
