Re: [RFR/RFC] Multi-desktop CDs for lenny - take 2
2008/12/2 Frank Lin PIAT [EMAIL PROTECTED]: BTW, I'm wondering whether light is misleading ( netinst). maybe lightx, lightX or something else. lightde, lightDE ? - Praveen -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) Join The DRM Elimination Crew Now! http://fci.wikia.com/wiki/Anti-DRM-Campaign
Please unblock openssh 1:5.1p1-4
Hi, If it's still feasible to do so, please unblock openssh 1:5.1p1-4; it fixes an interoperability problem with NetScreen devices reported by a number of Debian users. CCing debian-boot since it delivers udebs. openssh (1:5.1p1-4) unstable; urgency=low * ssh-copy-id: Strip trailing colons from hostname (closes: #226172, LP: #249706; thanks to Karl Goetz for nudging this along; forwarded upstream as https://bugzilla.mindrot.org/show_bug.cgi?id=1530). * Backport from upstream CVS (Markus Friedl): - Only send eow and no-more-sessions requests to openssh 5 and newer; fixes interop problems with broken ssh v2 implementations (closes: #495917). * Fix double-free when failing to parse a forwarding specification given using ~C (closes: #505330; forwarded upstream as https://bugzilla.mindrot.org/show_bug.cgi?id=1539). -- Colin Watson [EMAIL PROTECTED] Sun, 23 Nov 2008 14:46:10 + Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507653: installation-reports: partitioner shows warning: 'The kernel was unable to re-read the partition table on /dev/md0'
Package: installation-reports Boot method: flash Image version: http://ftp.uk.debian.org/debian/dists/lenny/main/installer-armel/current/images/iop32x/netboot/n2100.bin Date: 20 Nov 2008 Machine: Thecus n2100 Partitions: thecus-spare:~# df -Tl FilesystemType 1K-blocks Used Available Use% Mounted on /dev/md0 ext3 23964765208 226937960 1% / tmpfstmpfs 63504 0 63504 0% /lib/init/rw udev tmpfs 1024076 10164 1% /dev tmpfstmpfs 63504 0 63504 0% /dev/shm Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: This warning appears after setting up a RAID1 install (2 250GB HDDs, each partitioned into 1 0.5GB partition and 1 249.5GB partition. The 2 0.5s combined in a RAID1 array used as swap, the other 2 partitions combined in a RAID1 array used as ext3 mounted as /): ┌──┤ [!] Partition disks ├┐ │ Warning! │ │ The kernel was unable to re-read the partition table on /dev/md0 (Invalid argument).│ │ This means Linux won't know anything about the modifications you made until │ │ you reboot. You should reboot your computer before doing anything with /dev/md0. │ │ │ │ Go Back Continue │ │ │ └─┘ Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. The install seems to proceed with no sign of a problem from that point on.
Re: Please unblock openssh 1:5.1p1-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Watson [EMAIL PROTECTED] writes: Hi, If it's still feasible to do so, please unblock openssh 1:5.1p1-4; it fixes an interoperability problem with NetScreen devices reported by a number of Debian users. CCing debian-boot since it delivers udebs. openssh (1:5.1p1-4) unstable; urgency=low * ssh-copy-id: Strip trailing colons from hostname (closes: #226172, LP: #249706; thanks to Karl Goetz for nudging this along; forwarded upstream as https://bugzilla.mindrot.org/show_bug.cgi?id=1530). * Backport from upstream CVS (Markus Friedl): - Only send eow and no-more-sessions requests to openssh 5 and newer; fixes interop problems with broken ssh v2 implementations (closes: #495917). * Fix double-free when failing to parse a forwarding specification given using ~C (closes: #505330; forwarded upstream as https://bugzilla.mindrot.org/show_bug.cgi?id=1539). -- Colin Watson [EMAIL PROTECTED] Sun, 23 Nov 2008 14:46:10 + No objection - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkk2eyIACgkQLqiZQEml+FVUngCdGINLR8XpPZ0sEDEa4rBOmX+g Bo4AoI2CEuYqY6pTc2W+AyQVpSOqvJys =3udN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504721: Possible reason for serial console misdetection
On Tue, Dec 02, 2008 at 10:50:26PM +0100, Frans Pop wrote:
Someone who can actually write in C please check the code and let me know
if anything can be removed or is missing. I may well have added unneeded
includes for example and I have no idea what the original sprintf
statements were supposed to do.
Attached is a patch with a trimmed down version of console-type.c.
As we are not interested in the settings of the serial line or by the
state of the VT, we can just omit the struct declarations and be fine
with a dummy buffer. As printf() and ioctl() are the only functions
used, we can trim down the #include's to sys/ioctl.h and
stdio.h.
Cheers,
--
Jérémy Bobbio.''`.
[EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff --git a/packages/rootskel/src/sbin/Makefile b/packages/rootskel/src/sbin/Makefile
index b5e374e..83fb4bc 100644
--- a/packages/rootskel/src/sbin/Makefile
+++ b/packages/rootskel/src/sbin/Makefile
@@ -6,14 +6,18 @@ files_exec = \
shutdown \
init \
reopen-console \
+ console-type \
steal-ctty
+console-type: console-type.c
+ gcc -Os -Wall console-type.c -o console-type
+
steal-ctty: steal-ctty.c
gcc -Os -Wall steal-ctty.c -o steal-ctty
-build: steal-ctty
+build: console-type steal-ctty
clean:
- rm -f steal-ctty
+ rm -f console-type steal-ctty
include ../../Makefile.inc
diff --git a/packages/rootskel/src/sbin/console-type.c b/packages/rootskel/src/sbin/console-type.c
new file mode 100644
index 000..6105a3e
--- /dev/null
+++ b/packages/rootskel/src/sbin/console-type.c
@@ -0,0 +1,30 @@
+/* vi: set sw=4 ts=4: */
+/*
+ *
+ * Licensed under GPLv2
+ *
+ * Adapted for Debian Installer by Frans Pop fjp.debian.org from
+ * cttyhack from busybox 1.11, which is
+ *
+ * Copyright (c) 2007 Denys Vlasenko [EMAIL PROTECTED]
+ */
+
+#include sys/ioctl.h
+#include stdio.h
+
+enum { VT_GETSTATE = 0x5603 }; /* get global vt state info */
+
+int main(int argc, char ** argv)
+{
+ char buffer[256]; /* filled by ioctl */
+
+ if (ioctl(0, TIOCGSERIAL, buffer) == 0) {
+ /* this is a serial console */
+ printf(serial\n);
+ } else if (ioctl(0, VT_GETSTATE, buffer) == 0) {
+ /* this is linux virtual tty */
+ printf(virtual\n);
+ }
+
+ return 0;
+}
diff --git a/packages/rootskel/src/sbin/reopen-console b/packages/rootskel/src/sbin/reopen-console
index c6c55b5..702ddc3 100755
--- a/packages/rootskel/src/sbin/reopen-console
+++ b/packages/rootskel/src/sbin/reopen-console
@@ -6,11 +6,18 @@
NL=
+console=
if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted an handover message, then it's the one
+ # If the kernel emitted a handover message, then it's the one
console=$(dmesg -s 65535 |
sed -n -e 's/.*\] console handover: boot \[.*\] - real \[\(.*\)\]$/\1/p')
+ # Except if it is the wrong type...
+ if [ $console ] [ $(console-type) = serial ] \
+ expr $console : tty[0-9] /dev/null; then
+ console=
+ fi
+
consoles=
if [ -z $console ]; then
# Retrieve all enabled consoles from boot log; ignore those
signature.asc
Description: Digital signature
Bug#504721: Possible reason for serial console misdetection
Jérémy Bobbio [EMAIL PROTECTED] writes: On Tue, Dec 02, 2008 at 10:50:26PM +0100, Frans Pop wrote: As we are not interested in the settings of the serial line or by the state of the VT, we can just omit the struct declarations and be fine with a dummy buffer. Don't you risk overflowing the buffer by not using a union of the two structs? Or are both guarranteed to never grow above 256 bytes? -- Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504721: Possible reason for serial console misdetection
On Wednesday 03 December 2008, Ferenc Wagner wrote: Don't you risk overflowing the buffer by not using a union of the two structs? Or are both guarranteed to never grow above 256 bytes? The original code looks to have included a paranoia field in struct u of 3 times the size of serial_struct, probably for that reason. I'd think using 512 or even 1024 as buffer size may indeed be safer. Jérémy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504721: Possible reason for serial console misdetection
Frans Pop [EMAIL PROTECTED] writes: On Wednesday 03 December 2008, Ferenc Wagner wrote: Don't you risk overflowing the buffer by not using a union of the two structs? Or are both guarranteed to never grow above 256 bytes? The original code looks to have included a paranoia field in struct u of 3 times the size of serial_struct, probably for that reason. I'd think using 512 or even 1024 as buffer size may indeed be safer. But why magic constants? Why not a simple union of the two structs? The original paranoia isn't any better in this respect. Or do we try to avoid the need to recompile if the struct is later extended? That sounds silly... Maybe I'll learn something now. -- Curiously, Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504721: Possible reason for serial console misdetection
On Wednesday 03 December 2008, Ferenc Wagner wrote: But why magic constants? Why not a simple union of the two structs? The original paranoia isn't any better in this respect. Or do we try to avoid the need to recompile if the struct is later extended? That sounds silly... Maybe I'll learn something now. How would we magically get an updated version of the struct in our code anyway if that changes? We're not including header files here. We're making a copy of the code. My guess would be that the reason for the paranoia field is exactly that they wanted to allow for the possibility of a struct getting extended without them noticing! I guess it would make sense to at least mention in a comment what structs are supposed to be used, but I don't really see any benefit in writing them out. I think it's also fairly safe to assume this is a stable API. Disclaimer: I don't actually really know what I'm talking about... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-desktop CDs for lenny: root device does not exist
On Tuesday 02 December 2008, Holger Wansing wrote: You are indeed right. I've done a test install with a rc1 netinst cd, and had the same problem! Although it worked the first time I tried the rc1 installation. Just to make sure... I hope you have not been selecting this option for driver inclusion for initramfs-tools during your installation: targeted: only include drivers needed for this system (instead of: generic: include all available drivers). Because if you have, then you've probably been shooting yourself in the foot. The targeted option could well result in the generic drivers not being included in the initrd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507148: marked as done ([sparc] build d-i kernel-images with version -11)
Your message dated Wed, 3 Dec 2008 21:16:49 +0100 with message-id [EMAIL PROTECTED] and subject line Re: Bug#507148: [sparc] build d-i kernel-images with version -11 has caused the Debian Bug report #507148, regarding [sparc] build d-i kernel-images with version -11 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 507148: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507148 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: kernel-image-2.6.26-1-sparc64-di Version: 1.38 Severity: important Tags: d-i Hello, Now that http://bugs.debian.org/506711 is fixed, could the kernel-image-2.6.26-1-sparc64-di be rebuild with version 2.6.26-11 of http://packages.debian.org/sid/linux-image-2.6.26-1-sparc64 It will ( at least should ) fix the error that is in the daily build of netboot for debian-installer. ( gzip: ./tmp/netboot/vmlinuz-2.6.26-1-sparc64: not in gzip format ) Cheers Geert Stappers ---End Message--- ---BeginMessage--- Op 20081128 om 16:29 schreef Otavio Salvador: I plan to do that later today. thanks for doing so ---End Message---
Re: [RFR/RFC] Multi-desktop CDs for lenny - take 2
On Wednesday 03 December 2008, Frank Lin PIAT wrote:
- for light CD: separate rescue submenu on first isolinux screen
That's sensible. (even though a little,bit inconsistent with DVD)
Yes, but really a lot more logical for the light CD. And changing it for
other CD images too would mean they become inconsistent with netboot and
hd-media, which I like even less at this point.
BTW, I'm wondering whether light is misleading ( netinst). maybe
lightx, lightX or something else.
The file name for official images will probably be xfce+lxde or similar,
not light. Light (desktop environment) CD is for me more something to
use to identify it in conversation.
Finally a few comment on the images I tested:
* There's an empty /install folder on the CD, even though
/install.{386,amd} are used.
Unrelated to my changes. Probably because things are moved around when a
multi-arch is being assembled. Very minor issue. I may have a look after
my patches are committed.
* The file /pxelinux.cfg/default is a symlink, which make it impossible
to use on FAT/NTFS file system. would it be possible to replace it
with a simple file containing : include
../boot-screens/syslinux.cfg
That's about the netboot images, right?
There already were other symlinks in use in the netboot setup. I don't
really feel like worrying about this to be honest. Feel free to file a
wishlist BR about it.
* The multi-arch (i386+amd64) advanced sub-menu needs scrolling
I'll try to have a look.
Yes, I'm aware of that. But that is also true for current multi-arch
images. Could possibly be fixed (or at least reduced) by splitting out
rescue, but see above for why I don't really want to do that now.
Cheers,
FJP
signature.asc
Description: This is a digitally signed message part.
[RFC] Consequences for official CD/DVD images for Lenny
Now that everybody has had a chance to take a look at the patches and try out the test images (ahem...) we should decide how to use the new options and what it will mean for the images we make available for Lenny. Everything in this mail is a proposal (i.e. open for discussion), loosely based on some brainstorming Steve and I did a couple of weeks ago. The following images will remain essentially unchanged: - netinst/businesscard images for arches other than i386/amd64 - full CD images - KDE installation CD - alpha/hppa/ia64 multi-arch CD Light desktop environment CD image == This image, supporting both the XFCE and LXDE desktop tasks, would replace the existing XFCE CD. For i386 and amd64 the isolinux menu supports selecting which desktop environment (DE) should be installed. For some other arches for which debian-cd supports the KERNEL_PARAMS envvar (powerpc, sparc, hppa), the default desktop will be XFCE; users will need to manually add 'desktop=lxde' at boot time to change that. For other arches the default desktop will be GNOME and users need to manually add either 'desktop=lxde' or 'desktop=xfce'. All desktop environments support There are two aspects to that: 1) what packages get included on the first DVD 2) desktop environment selection [1] in isolinux menu for i386 and amd64 Why not use this option for CD sets? * It would mean non-key Gnome packages get pushed back to later CDs. * It would make CD1 effectively unusable for any DE when used by itself. * To be certain you can fully install any DE task you'd need to scan *a lot* of CDs (about 7) or you'll be downloading most packages from a mirror, in which case you should be using a netinst image anyway. So, it makes a lot of sense to just keep the CD sets GNOME-centered and keep the KDE and light DE installation CDs for those who really want to install the other DEs from CD. DVDs (and Blu-Ray) -- For DVDs it makes most sense IMO to keep the order in which packages are added the same for all architectures, so that would mean configuring debian-cd to use desktop=all for all arches. I have verified that for the i386 DVD all DE and server and language tasks easily fit on the first DVD with plenty of room left over for the top packages from popcon (first ~3900 get included). For all arches the default desktop will remain GNOME. For i386 and amd64 users will have the option to select which DE they want to install from the Advanced options boot menu. For other arches users will need to manually add 'desktop=...' to select an alternative DE. netinst and businesscard (i386 and amd64 only) -- We can also add the option to select an alternative DE to the smaller images. After all, packages will be downloaded from a mirror anyway so we know all desktops will be available. The contents of the images themselves will not change. I see only benefits from this as general usability is improved. This will mean configuring debian-cd to use desktop=all. Whether to do that for i386 and amd64 only, or for all arches is a matter of taste. For other arches it makes no sense, but it's also a safe no-op. multi-arch images - The i386/amd64/powerpc CD is basically a netinst image, so that can get desktop=all to enable DE selection in the boot menu for i386 and amd64. The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. Dropping images that make no sense? === Somewhat unrelated. We have several architectures that don't support booting from CD (armel, mipsel, s390) which means we're building a number of images that nobody will ever use: - businesscard and netinst - KDE, XFCE The full CD and DVD set make some sense for archival purposes. Should we configure d-cd to skip these arches for those images? Cheers, FJP [1] A bit of background info. One could wonder why this is being done in the isolinux boot menu rather than during the installation, e.g. in tasksel. The simple reason is that Joey Hess, the lead developer for tasksel, has always been opposed to doing it in tasksel with as main argument that tasksel is mostly for new users who are probably not aware of what DEs exist and thus would only be confused when having to choose between meaningless names as GNOME, KDE, etc. One could argue about the validity of that argument, or about implementing it so that the option would only be available for expert users, but the fact remains that tasksel currently does not support DE selection. But users do regularly keep asking about it. One reason I have chosen to hide DE selection in the Advanced options menu
Re: [RFC] Consequences for official CD/DVD images for Lenny
Hi, [My two cents tips below] On Wed, 2008-12-03 at 23:32 +0100, Frans Pop wrote: Now that everybody has had a chance to take a look at the patches and try out the test images (ahem...) we should decide how to use the new options and what it will mean for the images we make available for Lenny. [..] The following images will remain essentially unchanged: - netinst/businesscard images for arches other than i386/amd64 - full CD images - KDE installation CD - alpha/hppa/ia64 multi-arch CD I have noticed that Ubuntu only advertises CD1 on their download page. I think it is really sensible: The CD-1 contains Xwindow, so a [new] user gets a usable desktop... even if he/she face network connectivity problem. Advanced users can still use netboot/BC/jigdo/DVD... netinst and businesscard (i386 and amd64 only) -- We can also add the option to select an alternative DE to the smaller images. After all, packages will be downloaded from a mirror anyway so we know all desktops will be available. The contents of the images themselves will not change. I see only benefits from this as general usability is improved. yes multi-arch images - The i386/amd64/powerpc CD is basically a netinst image, so that can get desktop=all to enable DE selection in the boot menu for i386 and amd64. The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. PowerPC's popcon is steady (or even decreasing), probably because Apple don't sale any PPC system anymore. On the other hand, x86_64 system are now extremely popular now. I like the idea of such 2arch/4desktop/+2600pkg DVDs for events. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Consequences for official CD/DVD images for Lenny
The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. I'm not sure about this one, there are still quite a few powerpc macs out there and hopefully PS3 support will be coming to debian at some point. Dropping images that make no sense? === Somewhat unrelated. We have several architectures that don't support booting from CD (armel, mipsel, s390) which means we're building a number of images that nobody will ever use: - businesscard and netinst - KDE, XFCE aren't CD images also used to do hd-media installs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Consequences for official CD/DVD images for Lenny
Quoting Frans Pop ([EMAIL PROTECTED]): Now that everybody has had a chance to take a look at the patches and try out the test images (ahem...) we should decide how to use the new options Ahem, as you say...:-) I was planning to do such testing next week-end as I had no opportunity to do it during that week. However, I wonder if that's really worth it as Franklin did so and I trust him for the care of the tests (at least much more than /me). Everything in this mail is a proposal (i.e. open for discussion), loosely based on some brainstorming Steve and I did a couple of weeks ago. As often with your proposals, Frans (and, of course, that's not a criticism), it is well thought and written enough and therefore does not leave much things to comment on (except me too statements). Let's try, anyway because of the great work involved in the preparation of that proposal. Light desktop environment CD image == This image, supporting both the XFCE and LXDE desktop tasks, would replace the existing XFCE CD. For i386 and amd64 the isolinux menu supports selecting which desktop environment (DE) should be installed. For some other arches for which debian-cd supports the KERNEL_PARAMS envvar (powerpc, sparc, hppa), the default desktop will be XFCE; users will need to manually add 'desktop=lxde' at boot time to change that. For other arches the default desktop will be GNOME and users need to manually add either 'desktop=lxde' or 'desktop=xfce'. Fair enough. With the noticeable exception of powerpc, most arches are probably installed very rarely with a desktop environment anywayand this is not a regression, but only something that's made easier for popular arches. All desktop environments support There are two aspects to that: 1) what packages get included on the first DVD 2) desktop environment selection [1] in isolinux menu for i386 and amd64 Why not use this option for CD sets? * It would mean non-key Gnome packages get pushed back to later CDs. * It would make CD1 effectively unusable for any DE when used by itself. * To be certain you can fully install any DE task you'd need to scan *a lot* of CDs (about 7) or you'll be downloading most packages from a mirror, in which case you should be using a netinst image anyway. So, it makes a lot of sense to just keep the CD sets GNOME-centered and keep the KDE and light DE installation CDs for those who really want to install the other DEs from CD. In short: installs from CD will offer all desktops but only GNOME is installable without the network or other CDs. Do I understand correctly? DVDs (and Blu-Ray) -- For DVDs it makes most sense IMO to keep the order in which packages are added the same for all architectures, so that would mean configuring debian-cd to use desktop=all for all arches. I have verified that for the i386 DVD all DE and server and language tasks easily fit on the first DVD with plenty of room left over for the top packages from popcon (first ~3900 get included). For all arches the default desktop will remain GNOME. For i386 and amd64 users will have the option to select which DE they want to install from the Advanced options boot menu. For other arches users will need to manually add 'desktop=...' to select an alternative DE. Perfect, imho. netinst and businesscard (i386 and amd64 only) -- We can also add the option to select an alternative DE to the smaller images. After all, packages will be downloaded from a mirror anyway so we know all desktops will be available. The contents of the images themselves will not change. I see only benefits from this as general usability is improved. That is a *great* improvement. I see no objection at all, but the need to document this. multi-arch images - The i386/amd64/powerpc CD is basically a netinst image, so that can get desktop=all to enable DE selection in the boot menu for i386 and amd64. The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. Isn't that facing the reality that powerpc is probably no longer a popular architecture.and, even more, an architecture where people rarely reinstall new machines. Seems fair to me and a good compromise for keeping a very useful DVD image (IMHO, the multi-arch DVD will certainly be the choice of magazines who distribute DVDs or the choice of those of us who distribute installation media at booths in expos) Dropping images that make no sense? === Somewhat unrelated. We have several architectures that don't support booting from CD
