On Thu, Jul 25, 2002 at 07:57:22AM +0200, Michael Bramer wrote:
we don't need real developing in b-f. B-f should only a fall back for
sarge, if d-i is not ready.
I suppose it was a while ago now, but it's still a bit sad that people
are forgetting this is _exactly_ what we were saying for
On Thu, Jul 25, 2002 at 05:17:42PM +1000, Anthony Towns wrote:
On Thu, Jul 25, 2002 at 07:57:22AM +0200, Michael Bramer wrote:
we don't need real developing in b-f. B-f should only a fall back for
sarge, if d-i is not ready.
I suppose it was a while ago now, but it's still a bit sad that
On Thu, Jul 25, 2002 at 05:17:42PM +1000, Anthony Towns wrote:
I suppose it was a while ago now, but it's still a bit sad that people
are forgetting this is _exactly_ what we were saying for woody.
Of course we didn't actually do that for woody. We changed a whole heck
of a lot in b-f, moved
Anthony Towns [EMAIL PROTECTED] immo vero scripsit:
b-f's as a fallback doesn't work, it's too thorougly unmaintainable. Or
installation system needs _major_ work, easy solutions like just fall
back to boot-floppies *don't* work.
It's quite interesting that you insist on b-f being so
On Thu, Jul 25, 2002 at 11:46:37PM +0900, Junichi Uekawa wrote:
Anthony Towns [EMAIL PROTECTED] immo vero scripsit:
b-f's as a fallback doesn't work, it's too thorougly unmaintainable. Or
installation system needs _major_ work, easy solutions like just fall
back to boot-floppies *don't*
#include hallo.h
Anthony Towns wrote on Tue Jul 23, 2002 um 08:33:55PM:
You can propose whatever you like, but the above is sadly deluded. From
experience, getting b-f's updated and ported to the existing architectures
takes between 8 and 12 months.
We won't be freezing until we have a
On Wed, Jul 24, 2002 at 12:22:34PM +0200, Eduard Bloch wrote:
Anthony Towns wrote on Tue Jul 23, 2002 um 08:33:55PM:
We won't be freezing until we have a satisfactory and functioning
installer.
Nice. I have seen how motivation disappears when you are waiting longer
than 8 months for the
On Mon, Jul 22, 2002 at 01:12:24AM +0200, Tollef Fog Heen wrote:
* Eduard Bloch
| #include hallo.h
| Tollef Fog Heen wrote on Wed Jul 17, 2002 um 09:25:19AM:
|
| Are you, or somebody else ready to continue developing b-f? Note,
| _developing_, not maintaining. I am not willing to do
On Tue, Jul 23, 2002 at 01:16:29AM +0200, Eduard Bloch wrote:
I propose that we use what we have and do not try to force _new and
untested_ code to replace BFs. IMHO, either we base on boot-floppies and
freeze in few months,
You can propose whatever you like, but the above is sadly deluded.
On 16 Jul 2002 17:09:25 +0200
Tollef Fog Heen [EMAIL PROTECTED] wrote:
other arches like mips, mipsel, hppa, s390, arm etc will have to be
taken care of by people who know those arches. The same goes for our
Hurd and *BSD people -- if you want to release with woody + 1, you
will have to
On Tue, 16 Jul 2002 14:30:15 +0200
Eduard Bloch [EMAIL PROTECTED] wrote:
#include hallo.h
Greetings :)
Anthony Towns wrote on Tue Jul 16, 2002 um 04:53:26PM:
We can stick with boot-floppies for Woody+1 and release
Debian-4.0 with DI ;)
From what I have read of the difficulties
#include hallo.h
Tollef Fog Heen wrote on Mon Jul 22, 2002 um 01:12:24AM:
* Eduard Bloch
| #include hallo.h
| Tollef Fog Heen wrote on Wed Jul 17, 2002 um 09:25:19AM:
|
| Are you, or somebody else ready to continue developing b-f? Note,
| _developing_, not maintaining. I am not
* Eduard Bloch
| LVM can be added. EVMS has AFAIK still some stability issues and does
| not have any pvmove equivalent feature.
and you are saying LVM does not have stability issues? Where were you
wrt LVM about beginning of May?
| frontends to it -- both text-only and GUI ones.
|
| GUI
* Tollef Fog Heen [EMAIL PROTECTED] [2002-07-22 10:58]:
Also, how are you going to add support for *BSD in b-f?
That's not relevant since *BSD won't release with sarge anyway.
--
Martin Michlmayr
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
* Martin Michlmayr
| * Tollef Fog Heen [EMAIL PROTECTED] [2002-07-22 10:58]:
| Also, how are you going to add support for *BSD in b-f?
|
| That's not relevant since *BSD won't release with sarge anyway.
But our Hurd friends might.
and it seems to me like Eduard Bloch is proposing that we
#include hallo.h
Tollef Fog Heen wrote on Mon Jul 22, 2002 um 02:45:43PM:
| That's not relevant since *BSD won't release with sarge anyway.
But our Hurd friends might.
and it seems to me like Eduard Bloch is proposing that we extend b-f
indefinitely, something which I hope I have
* Eduard Bloch
| #include hallo.h
| Tollef Fog Heen wrote on Wed Jul 17, 2002 um 09:25:19AM:
|
| Are you, or somebody else ready to continue developing b-f? Note,
| _developing_, not maintaining. I am not willing to do that. I want
| to make d-i happen, however.
|
| What do you
* Richard Hirst
| Current status is that it can handle msdos and gpt table creation, and
| partition creation and deletion. Tested only on ia64. Not touched it
| since March, but I can certainly make the code available.
yes please.
--
Tollef Fog Heen
* Eduard Bloch
| Why not? It works. It is available and stable. It is smart. It does not
| require large media or network connection to load even the installation
| subsystem.
Are you, or somebody else ready to continue developing b-f? Note,
_developing_, not maintaining. I am not willing to
On Tue, 2002-07-16 at 21:17, Richard Hirst wrote:
Current status is that it can handle msdos and gpt table creation, and
partition creation and deletion. Tested only on ia64. Not touched it
since March, but I can certainly make the code available.
That would be cool, please do.
I see there
On Wed, Jul 17, 2002 at 09:21:51AM +0200, Tollef Fog Heen wrote:
* Richard Hirst
| Current status is that it can handle msdos and gpt table creation, and
| partition creation and deletion. Tested only on ia64. Not touched it
| since March, but I can certainly make the code available.
On Tue, Jul 16, 2002 at 07:24:11PM +0200, Eduard Bloch wrote:
Why not? It works.
Knock yourself out.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year
#include hallo.h
Tollef Fog Heen wrote on Wed Jul 17, 2002 um 09:25:19AM:
Are you, or somebody else ready to continue developing b-f? Note,
_developing_, not maintaining. I am not willing to do that. I want
to make d-i happen, however.
What do you understand under developing? It does what
On Mon, Jul 15, 2002 at 06:03:38PM +0200, Eduard Bloch wrote:
#include hallo.h
Anthony Towns wrote on Tue Jul 16, 2002 um 01:39:21AM:
We can stick with boot-floppies for Woody+1 and release Debian-4.0 with
DI ;)
No, no we can't.
You like argumenting with semi-technical reasons - so
On Tue, 2002-07-16 at 05:49, Timshel Knoll wrote:
The bigger issue is that parted is very strict about the partition
tables it reads, so parted will not work well with inconsistent / dodgy
partition tables which may have been caused by other programs. The
ability to resize filesystems in the
#include hallo.h
Anthony Towns wrote on Tue Jul 16, 2002 um 04:53:26PM:
We can stick with boot-floppies for Woody+1 and release Debian-4.0 with
DI ;)
No, no we can't.
You like argumenting with semi-technical reasons - so which one is it
this time?
Good grief, you _weren't_
On Tue, Jul 16, 2002 at 02:30:15PM +0200, Eduard Bloch wrote:
#include hallo.h
Anthony Towns wrote on Tue Jul 16, 2002 um 04:53:26PM:
We can stick with boot-floppies for Woody+1 and release Debian-4.0 with
DI ;)
No, no we can't.
You like argumenting with semi-technical
On Tue, Jul 16, 2002 at 10:36:11AM +0100, Philip Blundell wrote:
On Tue, 2002-07-16 at 05:49, Timshel Knoll wrote:
The bigger issue is that parted is very strict about the partition
tables it reads, so parted will not work well with inconsistent / dodgy
partition tables which may have been
* Eduard Bloch
| Nope. The smiley was for Debian-4.0. If we cannot guarantee stable DI in
| appropriate time, the whole distribution should not wait for it.
We can't guarantee anything, but we _will_ have a stable d-i in
appropriate time. We _must_ have a stable d-i in time.
The alternative
* Chris Tillman
| For the installer, porting is a major effort, because architectural
| differences are greatest when dealing with the hardware at a low level
| such as during partitioning/booting. i386 is the _best_-understood.
True. Help for other architectures is appreciated, and needed.
On Tue, 2002-07-16 at 15:05, Chris Tillman wrote:
Wouldn't it be possible to write an API to fdisk so we could fall back to
it underneath without affecting the presentation?
Sure, it would be possible, but it's gonna be a chunk of extra work. I
would much rather put the effort into making
Anthony Towns [EMAIL PROTECTED] writes:
I'm expecting some working installation systems (PGI, d-i, whatever)
within a couple of months... (i386 only, and other limitations, sure,
but working nevertheless)
PGI works now. As for parted's stability, we have been using it since
Progeny Debian,
#include hallo.h
Tollef Fog Heen wrote on Tue Jul 16, 2002 um 04:58:19PM:
| Nope. The smiley was for Debian-4.0. If we cannot guarantee stable DI in
| appropriate time, the whole distribution should not wait for it.
We can't guarantee anything, but we _will_ have a stable d-i in
On Tue, Jul 16, 2002 at 10:43:00AM -0500, Eric Gillespie wrote:
Anthony Towns [EMAIL PROTECTED] writes:
I'm expecting some working installation systems (PGI, d-i, whatever)
within a couple of months... (i386 only, and other limitations, sure,
but working nevertheless)
PGI works now.
On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote:
in order to get debian-installer into working shape, it is obvious
that the user has some way to partition the hard drive. An
auto-partitioner will probably only need debconf as it's UI. However,
manual partitioning using debconf will be
#include hallo.h
Philip Blundell wrote on Tue Jul 16, 2002 um 09:03:29PM:
Ah, I just noticed that there is already a newt-based parted frontend
(nparted), which will do for dialog mode. The standard parted should
suffice for readline mode; I think it should be easy enough to put
I tested
On Tue, 2002-07-16 at 21:14, Eduard Bloch wrote:
Philip Blundell wrote on Tue Jul 16, 2002 um 09:03:29PM:
Ah, I just noticed that there is already a newt-based parted frontend
(nparted), which will do for dialog mode. The standard parted should
suffice for readline mode; I think it should
On Tue, Jul 16, 2002 at 10:14:36PM +0200, Eduard Bloch wrote:
#include hallo.h
Philip Blundell wrote on Tue Jul 16, 2002 um 09:03:29PM:
Ah, I just noticed that there is already a newt-based parted frontend
(nparted), which will do for dialog mode. The standard parted should
suffice for
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit:
We can't guarantee anything, but we _will_ have a stable d-i in
appropriate time. We _must_ have a stable d-i in time.
The alternative is PGI (or both). Not b-f.
The reality is: The current alternative is b-f only,
and there are a few
* Joey Hess
| Tollef Fog Heen wrote:
|
| Does anybody have a suggestion on how to solve this problem?
|
| I'd suggest writing the partitioner with some real ui toolkit and making
| it feed relevant values back into the debconf database.
how would you call the right partitioner based on UI?
On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote:
in order to get debian-installer into working shape, it is obvious
that the user has some way to partition the hard drive. An
auto-partitioner will probably only need debconf as it's UI. However,
manual partitioning using debconf will be
* Philip Blundell
| On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote:
| in order to get debian-installer into working shape, it is obvious
| that the user has some way to partition the hard drive. An
| auto-partitioner will probably only need debconf as it's UI. However,
| manual
On Mon, Jul 15, 2002 at 09:50:26AM +0100, Philip Blundell wrote:
On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote:
However,
manual partitioning using debconf will be very painful. Developing a
debconf partitioning widget might be a little overkill, so I am not
sure how we want to
#include hallo.h
Anthony Towns wrote on Mon Jul 15, 2002 um 08:19:39PM:
That seems like a fair chunk of effort, and relying on libparted being
stable and usable (when we've never tried it before), _and_ signficantly
enhanced, seems like a good way of adding another long delay before we
can
On Mon, Jul 15, 2002 at 03:58:03PM +0200, Eduard Bloch wrote:
We can stick with boot-floppies for Woody+1 and release Debian-4.0 with
DI ;)
No, no we can't.
Cheers,
aj
(Joke you say? Like in an egg? Funny? Yes, they are runny if you don't
boil them.)
--
Anthony Towns [EMAIL PROTECTED]
On Mon, Jul 15, 2002 at 11:10:55AM +0200, Tollef Fog Heen wrote:
* Philip Blundell
| On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote:
| in order to get debian-installer into working shape, it is obvious
| that the user has some way to partition the hard drive. An
| auto-partitioner
in order to get debian-installer into working shape, it is obvious
that the user has some way to partition the hard drive. An
auto-partitioner will probably only need debconf as it's UI. However,
manual partitioning using debconf will be very painful. Developing a
debconf partitioning widget
Tollef Fog Heen wrote:
in order to get debian-installer into working shape, it is obvious
that the user has some way to partition the hard drive. An
auto-partitioner will probably only need debconf as it's UI. However,
manual partitioning using debconf will be very painful. Developing a
On Sun, Jul 14, 2002 at 08:03:27PM -0400, Joey Hess wrote:
Tollef Fog Heen wrote:
in order to get debian-installer into working shape, it is obvious
that the user has some way to partition the hard drive. An
auto-partitioner will probably only need debconf as it's UI. However,
manual
49 matches
Mail list logo
