Didier 'OdyX' Raboud o...@debian.org (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
2014/08/18 14:57 Christopher Chavez 2000...@gmail.com:
(Please let me know if there's a better venue for collecting feedback for
this
idea, or additional ones I should solicit feedback from. I primarily use
Ubuntu,
but I assume this is as upstream as it gets.)
Upstream relative to what? Boot
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
Package: debian-installer
Followup-For: Bug #742485
Dear Maintainer,
I tested installing from debian-testing-amd64-CD-1.iso obtained at
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, expecting the
Gnome desktop to be installed.
This image was dated 2014-08-18 08:52, MD5 sum
On Tue, Aug 19, 2014 at 10:07:17AM -0500, Fabian Rodriguez wrote:
Package: debian-installer
Followup-For: Bug #742485
Dear Maintainer,
I tested installing from debian-testing-amd64-CD-1.iso obtained at
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/,
expecting the Gnome desktop to
Hi Fabian,
Fabian Rodriguez magic...@member.fsf.org (2014-08-19):
Package: debian-installer
Followup-For: Bug #742485
Dear Maintainer,
I tested installing from debian-testing-amd64-CD-1.iso obtained at
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/,
expecting the Gnome
Cyril Brulebois k...@debian.org (2014-08-19):
Hi Fabian,
Fabian Rodriguez magic...@member.fsf.org (2014-08-19):
Package: debian-installer
Followup-For: Bug #742485
Dear Maintainer,
I tested installing from debian-testing-amd64-CD-1.iso obtained at
Hi,
Brian Potkin claremont...@gmail.com 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 Tue, Aug 19, 2014 at 09:45:03PM +0900, Joel Rees wrote:
2014/08/18 14:57 Christopher Chavez 2000...@gmail.com:
Questions:
1. Is it the case that the only reason for having a separate /boot was to
provide easy access /boot/grub? I.e., was it intentional to provide easy
access
to
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 case via
Hi KiBi,
On Mon, Jul 07, 2014 at 03:56:21AM +0200, Cyril Brulebois wrote:
Modestas Vainius mo...@debian.org (2013-12-29):
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
Hi Stephen ,
Stephen Kitt sk...@debian.org (2014-08-19):
On Mon, Jul 07, 2014 at 03:56:21AM +0200, Cyril Brulebois wrote:
Modestas Vainius mo...@debian.org (2013-12-29):
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++
On Tue 19 Aug 2014 at 17:39:18 +0200, Holger Wansing wrote:
Brian Potkin claremont...@gmail.com 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.
Holger Wansing hwans...@mailbox.org (2014-08-19):
Hi,
Brian Potkin claremont...@gmail.com 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
On Thu, 2014-08-14 at 23:38 +0200, Cyril Brulebois wrote:
[...]
1. Colin Watson will prepare dak changes to support upload and
subsequent signing of EFI executables. (This is an embedded, not
detached, signature.)
2. Steve Langasek will prepare and upload a package of the 'shim' EFI
Hi,
Cyril Brulebois k...@debian.org wrote:
Holger Wansing hwans...@mailbox.org (2014-08-19):
Hi,
Brian Potkin claremont...@gmail.com 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
On Tue, Aug 19, 2014 at 01:38:44PM -0700, Ben Hutchings wrote:
So far as I know, no progress has been made on the above steps or any
alternate approach.
Ditto, I've not seen (or done) anything about this.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
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 bit option
On Tue, Aug 19, 2014 at 01:17:02AM +0200, Cyril Brulebois wrote:
[ Adding -accessibility@ and -cd@ to the loop. ]
Steve McIntyre st...@einval.com (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
Steve McIntyre st...@einval.com (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
On Tue, Aug 19, 2014 at 11:58:27PM +0200, Cyril Brulebois wrote:
Steve McIntyre st...@einval.com (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
On 19/08/14 00:40, Cyril Brulebois wrote:
[ I'm adding -release@ to the loop. I tried to refrain from mentioning
my concerns in the Jessie Beta 1 announce, that's why I used a quite
neutral wording, but let's be honest: kfreebsd-* is looking bad right
now. ]
I was drafting a quite long reply
On 14/08/14 18:32, Cyril Brulebois wrote:
Now, I think there are several questions to answer:
1. What were the reasons for having arch-dependent dhcp clients?
I'd speculate because udhcpc from busybox is very small, and
isc-dhcp-client-udeb was about 2 MiB. It targets (currently only builds
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
On 14/08/14 18:32, Cyril Brulebois wrote:
Now, I think there are several questions to answer:
1. What were the reasons for having arch-dependent dhcp clients?
I'd speculate because udhcpc from busybox is very small, and
On 14/08/14 18:15, Cyril Brulebois wrote:
[...] If a
single extra udeb (or udeb size increase, which happens from time to
time) is going to break kfreebsd-*, it seems to me that their status
is far too brittle.
The fixed-size d-i initrds had to be carefully sized for kfreebsd wheezy.
We
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
On 14/08/14 18:15, Cyril Brulebois wrote:
[...] If a
single extra udeb (or udeb size increase, which happens from time to
time) is going to break kfreebsd-*, it seems to me that their status
is far too brittle.
The fixed-size d-i
On 20/08/14 01:49, Cyril Brulebois wrote:
If you're trying to insinuate I/we deliberately broke kfreebsd-* by
introducing partman-iscsi, [...]
No, I was not insinuating that.
But I am still asking: how is it that partman-iscsi is being installed
into a kfreebsd d-i image (by APT I believe)?
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
On 20/08/14 01:49, Cyril Brulebois wrote:
If you're trying to insinuate I/we deliberately broke kfreebsd-* by
introducing partman-iscsi, [...]
No, I was not insinuating that.
But I am still asking: how is it that partman-iscsi is
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
But I am still asking: how is it that partman-iscsi is being installed
into a kfreebsd d-i image (by APT I believe)? I'd expect it to be
uninstallable due to missing dependencies. Could that be a bug, or is
it a known limitation?
Thanks.
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
But it *is* also relevant here. Each udeb in our image takes up space
for the extracted files, but also I suspect _considerable_ space in
cdebconf data. Addressing this may already fix the ENOSPC error, and if
we can keep the anna excludes
I've finished testing these hypotheses:
On 20/08/14 03:14, Steven Chamberlain wrote:
I think all we need to do is add the expected-uninstallable packages to
/var/cache/anna/exclude
That works. I think on each architecture, any uninstallable udeb
(according to
On Tue, Aug 19, 2014 at 8:10 PM, Cyril Brulebois wrote:
Steven Chamberlain ste...@pyro.eu.org (2014-08-20):
On 14/08/14 18:32, Cyril Brulebois wrote:
Now, I think there are several questions to answer:
1. What were the reasons for having arch-dependent dhcp clients?
I'd speculate because
32 matches
Mail list logo
