Hi,
Holger Wansing wrote:
> > > > Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean
> > > > that it becomes the regular frontend, unless it is desired to credit the
> > > > "newt" frontend with some special status.
> > >
> > > >From a global point of view, the graphical front
On Tue, Aug 19, 2014 at 11:58:27PM +0200, Cyril Brulebois wrote:
>Steve McIntyre (2014-08-19):
>> or do we split things even more? That menu is already too long, and
>> causes scrolling for people to see the lower options (if they realise
>> such a thing is possible!). How about we split things up
Steve McIntyre (2014-08-19):
> or do we split things even more? That menu is already too long, and
> causes scrolling for people to see the lower options (if they realise
> such a thing is possible!). How about we split things up some more,
> assuming we can get the auto-detect to work:
>
> #if (
On Tue, Aug 19, 2014 at 01:17:02AM +0200, Cyril Brulebois wrote:
>[ Adding -accessibility@ and -cd@ to the loop. ]
>
>Steve McIntyre (2014-08-17):
>> On Sun, Aug 17, 2014 at 01:25:28PM +0200, Cyril Brulebois wrote:
>> >Control: tag -1 confirmed
>> >> Another issue is that it requires much more mem
On Tue, Aug 19, 2014 at 02:02:17PM -0400, Joey Hess wrote:
>Didier 'OdyX' Raboud wrote:
>> Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to
>> determine the menu order depending on the machine (see [0]): no "64 bit"
>> option on 32 bit machines, "hidden or down the menu" "32
Hi,
Cyril Brulebois wrote:
> Holger Wansing (2014-08-19):
> > Hi,
> >
> > Brian Potkin wrote:
> > > On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote:
> > >
> > > > I have prepared a patch for this (attached) and I would like to receive
> > > > some
> > > > thoughts on it.
> > > >
Holger Wansing (2014-08-19):
> Hi,
>
> Brian Potkin wrote:
> > On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote:
> >
> > > I have prepared a patch for this (attached) and I would like to receive
> > > some
> > > thoughts on it.
> > > I have added Samuel Thibault in CC, since he has
On Tue 19 Aug 2014 at 17:39:18 +0200, Holger Wansing wrote:
> Brian Potkin wrote:
> > Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean
> > that it becomes the regular frontend, unless it is desired to credit the
> > "newt" frontend with some special status.
>
> >From a global
Didier 'OdyX' Raboud wrote:
> Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to
> determine the menu order depending on the machine (see [0]): no "64 bit"
> option on 32 bit machines, "hidden or down the menu" "32 bit" option on
> 64 bit-capable machines.
This used to be the
Hi,
Brian Potkin wrote:
> On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote:
>
> > I have prepared a patch for this (attached) and I would like to receive
> > some
> > thoughts on it.
> > I have added Samuel Thibault in CC, since he has also some knowledge and
> > interest on the d-i
On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote:
> I have prepared a patch for this (attached) and I would like to receive some
> thoughts on it.
> I have added Samuel Thibault in CC, since he has also some knowledge and
> interest on the d-i manual.
>
> Basically I moved the chapter
Didier 'OdyX' Raboud (2014-08-19):
> While I don't have a definitive opinion on the ordering of the menu
> choices, I definitively think amd64 should be picked by default on amd64
> architectures. Especially since multiarch, there's no good reason left
> for installing i386 on amd64-capable mac
Hoy,
Le mardi, 19 août 2014, 01.17:02 Cyril Brulebois a écrit :
> The default is "Install" right now, which installs i386. The topic of
> this bug report is switching to "Graphical install" by default, but
> shouldn't we also promote amd64 by default while we're at it? This
> would mean having "64
Cyril Brulebois, le Tue 19 Aug 2014 01:17:02 +0200, a écrit :
> => debian-accessibility@: if we go from i386 to amd64 by default, is
>there anything that needs to be done on your side (doc update etc.)
Normally, only the installer manual would need an update. I don't see
the multi-arch boot me
[ Adding -accessibility@ and -cd@ to the loop. ]
Steve McIntyre (2014-08-17):
> On Sun, Aug 17, 2014 at 01:25:28PM +0200, Cyril Brulebois wrote:
> >Control: tag -1 confirmed
> >> Another issue is that it requires much more memory, but that IMO is not a
> >> blocker. It does require careful docum
Cyril Brulebois (2014-08-18):
> Now, hurd-i386 doesn't need caring about; kfreebsd-* architectures are
> looking quite badly already, so I won't change anything on those right
> now. I expect arm* people to tell us whether any change is needed for
> those, but since I see no menu anyway… This left
Helloo,
Holger Wansing, le Mon 18 Aug 2014 23:07:11 +0200, a écrit :
> Basically I moved the chapter "Appendix D.6. The Graphical Installer" to
> 5.1.8 (at the end of "Booting the installer on 32-bit PC"), leaving the
> content unchanged.
>
> And I moved chapter "Appendix D.6.1. Using the graphic
Cyril Brulebois, le Mon 18 Aug 2014 23:36:03 +0200, a écrit :
> > +
> > +
> > +The graphical installer requires significantly more memory to run than
> > +the regular installer: &minimum-memory-gtk;. If insufficient memory is
> > +available, it will automatically fall back to the regular
> > +newt
Hi Holger,
and thanks for the proposed patch!
Holger Wansing (2014-08-18):
> Index: en/boot-installer/x86.xml
> ===
> --- en/boot-installer/x86.xml (Revision 69238)
> +++ en/boot-installer/x86.xml (Arbeitskopie)
> @@ -401,7 +401,7 @
Hi,
Cyril Brulebois wrote:
> Holger Wansing (2014-08-17):
> > That would lead to more changes to the d-i manual IMO.
>
> Indeed, and since you were updating the manual already I thought it
> might make sense to batch everything together.
>
> > At least:
> > booting of the graphical installer i
Holger Wansing (2014-08-17):
> That would lead to more changes to the d-i manual IMO.
Indeed, and since you were updating the manual already I thought it
might make sense to batch everything together.
> At least:
> booting of the graphical installer is now only documented in an
> appendix. If Gr
Hi,
Cyril Brulebois wrote:
> Control: tag -1 confirmed
>
> Frans Pop (2008-06-10):
> > On Tuesday 10 June 2008, Didier Raboud wrote:
> > > In my humble opinion, with the stability (and the beauty) of the
> > > graphical installer, the graphical menu (under i386 and amd64) should
> > > default t
On Sun, Aug 17, 2014 at 01:25:28PM +0200, Cyril Brulebois wrote:
>Control: tag -1 confirmed
>> Another issue is that it requires much more memory, but that IMO is not a
>> blocker. It does require careful documentation though.
>
>Holger's last reports reminded of this, which we finally didn't do f
Control: tag -1 confirmed
Frans Pop (2008-06-10):
> On Tuesday 10 June 2008, Didier Raboud wrote:
> > In my humble opinion, with the stability (and the beauty) of the
> > graphical installer, the graphical menu (under i386 and amd64) should
> > default to the graphical installer.
> >
> > Obviousl
Processing control commands:
> tag -1 confirmed
Bug #485586 [debian-installer] debian-installer: Default to graphical install
Added tag(s) confirmed.
--
485586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485586
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To
On Tuesday 10 June 2008, Didier Raboud wrote:
> In my humble opinion, with the stability (and the beauty) of the
> graphical installer, the graphical menu (under i386 and amd64) should
> default to the graphical installer.
>
> Obviously, the change has to be done with care and only on arches where
Package: debian-installer
Severity: wishlist
Hi,
In my humble opinion, with the stability (and the beauty) of the graphical
installer, the
graphical menu (under i386 and amd64) should default to the graphical
installer.
Obviously, the change has to be done with care and only on arches where
ap
27 matches
Mail list logo
