oversize on f18 again. ;)

[Kevin Fenzi]

https://bugzilla.redhat.com/show_bug.cgi?id=853590

Some options:

- nuke icedtea-web (this saves 100MB or so, but means people won't be
  able to test java in the live instance).

- seahorse - 7mb

- Longer term: split perl deps out of exo and see if we can remove
  perl? lm_sensors also needs perl, so we would have to drop
  xfce4-sensors-plugin, but I think it's worth it. That could save us a
  ton of room down the road. This dep is due exo-compose-mail-1 helper
  being a perl script.

- drop one of firefox or midori. ;)

- We really only need a bit of room at this point, so other smaller
  suggestions?

kevin

[Tim Lauridsen]

On Sat, Nov 10, 2012 at 10:39 PM, Kevin Fenzi  wrote:
> nuke icedtea-web (this saves 100MB or so, but means people won't be
> able to test java in the live instance).

+1 to remove java from the livecd, the size is to high for the limited web
sites needing the java web plugin.

Tim

[Frank Murphy]

On Sat, 10 Nov 2012 14:39:37 -0700
Kevin Fenzi  wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=853590
>
> Some options:
> nuke icedtea-web (this saves 100MB or so, but means people won't
>
> be able to test java in the live instance).

Have it somewhere on the spin page.
You may need to install java..icedtea..

[Christoph Wickert]

Am Samstag, den 10.11.2012, 14:39 -0700 schrieb Kevin Fenzi:
> https://bugzilla.redhat.com/show_bug.cgi?id=853590
>
> Some options:
> nuke icedtea-web (this saves 100MB or so, but means people won't be
> able to test java in the live instance).

It should be ~70 mb at least, but I am afraid it is unintuitive. People
will just see that something doesn't work but hardly know how to fix it.
"icedtea" is not really to find in the package management.
> seahorse - 7mb

Not a bad idea, however I consider seahorse useful.
> Longer term: split perl deps out of exo and see if we can remove
> perl? lm_sensors also needs perl, so we would have to drop
> xfce4-sensors-plugin, but I think it's worth it. That could save us a
> ton of room down the road. This dep is due exo-compose-mail-1 helper
> being a perl script.

I doubt that we cal really remove perl form the spin and even if we can,
it means we loose some features like attaching a file form Thunar to a
mail via the "Send to" menu.
> drop one of firefox or midori. ;)

Yes please! The question is: Which one? Throw a coin or play
rock-paper-scissors(-spock)? ;)
> We really only need a bit of room at this point, so other smaller
> suggestions?

Drop some themes!

Kind regards,
Christoph

[Charlie Kravetz]

On Sun, 11 Nov 2012 18:26:53 +0100
Christoph Wickert  wrote:
> Am Samstag, den 10.11.2012, 14:39 -0700 schrieb Kevin Fenzi:
> > https://bugzilla.redhat.com/show_bug.cgi?id=853590
> >
> > Some options:
> > nuke icedtea-web (this saves 100MB or so, but means people won't be
> > able to test java in the live instance).
>
> It should be ~70 mb at least, but I am afraid it is unintuitive. People
> will just see that something doesn't work but hardly know how to fix it.
> "icedtea" is not really to find in the package management.
> > seahorse - 7mb
>
> Not a bad idea, however I consider seahorse useful.
> > Longer term: split perl deps out of exo and see if we can remove
> > perl? lm_sensors also needs perl, so we would have to drop
> > xfce4-sensors-plugin, but I think it's worth it. That could save us a
> > ton of room down the road. This dep is due exo-compose-mail-1 helper
> > being a perl script.
>
> I doubt that we cal really remove perl form the spin and even if we can,
> it means we loose some features like attaching a file form Thunar to a
> mail via the "Send to" menu.
> > drop one of firefox or midori. ;)
>
> Yes please! The question is: Which one? Throw a coin or play
> rock-paper-scissors(-spock)? ;)
> > We really only need a bit of room at this point, so other smaller
> > suggestions?
>
> Drop some themes!
>
> Kind regards,
> Christoph

I will second the "drop some themes"! It is an easy way to gain a bit
of space.

If more than that is needed, flip the coin. Cutting one browser does
not prevent anyone from installing it when wanted.

[Christoph Wickert]

Am Sonntag, den 11.11.2012, 10:51 -0700 schrieb Charlie Kravetz:
> I will second the "drop some themes"! It is an easy way to gain a bit
> of space.
>
> If more than that is needed, flip the coin. Cutting one browser does
> not prevent anyone from installing it when wanted.

Right, and installing one's favorite browser is way more intuitive than
installing icedtea-web.

Cheers,
Christoph

[Charlie Kravetz]

On Sun, 11 Nov 2012 19:03:27 +0100
Christoph Wickert  wrote:
> Am Sonntag, den 11.11.2012, 10:51 -0700 schrieb Charlie Kravetz:
> > I will second the "drop some themes"! It is an easy way to gain a bit
> > of space.
> >
> > If more than that is needed, flip the coin. Cutting one browser does
> > not prevent anyone from installing it when wanted.
>
> Right, and installing one's favorite browser is way more intuitive than
> installing icedtea-web.
>
> Cheers,
> Christoph

I am sorry. I thought someone was asking for suggestions. I did not
realize you already decided what to cut.

[Christoph Wickert]

Am Sonntag, den 11.11.2012, 11:41 -0700 schrieb Charlie Kravetz:
> On Sun, 11 Nov 2012 19:03:27 +0100
> Christoph Wickert  wrote:
> > Am Sonntag, den 11.11.2012, 10:51 -0700 schrieb Charlie Kravetz:
> > > Cutting one browser does
> > > not prevent anyone from installing it when wanted.
> >
> > Right, and installing one's favorite browser is way more intuitive than
> > installing icedtea-web.
>
> I am sorry. I thought someone was asking for suggestions. I did not
> realize you already decided what to cut.

No need to be sorry, we didn't make a decision yet. It's not on me to
decide anyways, it's on all of us. :)

I just wanted to point out that we both agree that installing a browser
is easier than to figure out how to get Java working.

Kind regards,
Christoph

[Johannes Lips]

On Mon, Nov 12, 2012 at 1:17 PM, Christoph Wickert <
[e-mail]> wrote:
> Am Sonntag, den 11.11.2012, 11:41 -0700 schrieb Charlie Kravetz:
> > On Sun, 11 Nov 2012 19:03:27 +0100
> > Christoph Wickert  wrote:
> > > Am Sonntag, den 11.11.2012, 10:51 -0700 schrieb Charlie Kravetz:
> > > > Cutting one browser does
> > > > not prevent anyone from installing it when wanted.
> > >
> > > Right, and installing one's favorite browser is way more intuitive than
> > > installing icedtea-web.
> >
> > I am sorry. I thought someone was asking for suggestions. I did not
> > realize you already decided what to cut.
>
> No need to be sorry, we didn't make a decision yet. It's not on me to
> decide anyways, it's on all of us. :)
>
> I just wanted to point out that we both agree that installing a browser
> is easier than to figure out how to get Java working.
>
> Kind regards,
> Christoph

Hi all,

I think we should get rid of the browser which needs most space. If the
removal of firefox does give us more space, then I would remove it or vice
versa.
If we stick to midori, we would probably also emphasize the fact of a
lightweight spin.
Also I think it's better to remove user-space programs than some packages
like icedtea, where it's not so obvious what's missing. If firefox or
midori is missing in the menu, it's kind of obvious to solve the "problem".

Just my opinion,

Johannes
> xfce mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/xfce

[Dominic Hopf]

On Sun, 2012-11-11 at 18:26 +0100, Christoph Wickert wrote:
> > drop one of firefox or midori. ;)
>
> Yes please! The question is: Which one? Throw a coin or play
> rock-paper-scissors(-spock)? ;)

[x] drop Firefox
[ ] drop Midori

[Matthias Runge]

On 11/12/2012 06:17 AM, Dominic Hopf wrote:
> On Sun, 2012-11-11 at 18:26 +0100, Christoph Wickert wrote:
> > > drop one of firefox or midori. ;)
> >
> > Yes please! The question is: Which one? Throw a coin or play
> > rock-paper-scissors(-spock)? ;)
>
> [x] drop Firefox
> [ ] drop Midori

Does midori work with the icedtea stuff? Currently, I'm asking myself, 
if we could drop one browser AND also icedtea?

Another good candidate to drop would be some fonts:
- cjkuni-uming-fonts
- wqy-zenhei-fonts
both about 38 megs

What about opencv? (about 32 megs)

Or maybe we should discuss, if we drop printer drivers. In the Windows 
world, it seems so common to install a printer driver first, before you 
could configure it.

[Kevin Fenzi]

On Mon, 12 Nov 2012 12:39:15 +0100
Matthias Runge  wrote:
> On 11/12/2012 06:17 AM, Dominic Hopf wrote:
> > On Sun, 2012-11-11 at 18:26 +0100, Christoph Wickert wrote:
> > > > drop one of firefox or midori. ;)
> > >
> > > Yes please! The question is: Which one? Throw a coin or play
> > > rock-paper-scissors(-spock)? ;)
> >
> > [x] drop Firefox
> > [ ] drop Midori
>
> Does midori work with the icedtea stuff? Currently, I'm asking
> myself, if we could drop one browser AND also icedtea?

Yes, it does work with icedtea just fine.
> Another good candidate to drop would be some fonts:
> cjkuni-uming-fonts
> wqy-zenhei-fonts
>
> both about 38 megs

yeah, except then we drop looking nice in several locales. ;(
> What about opencv? (about 32 megs)

Huh. Wonder what pulls that in... I'm happy removing it, and can't see
what needs it off hand. Wait... I don't see it in the current spin. ;(
> Or maybe we should discuss, if we drop printer drivers. In the
> Windows world, it seems so common to install a printer driver first,
> before you could configure it.

If there was an easy way to install them for users, sure... but that
needs PackageKit, which we dropped in favor of yumex.

kevin

[Matthias Runge]

On 11/12/2012 09:58 PM, Kevin Fenzi wrote:
> Huh. Wonder what pulls that in... I'm happy removing it, and can't see
> what needs it off hand. Wait... I don't see it in the current spin. ;(

Oh I took that
https://bugzilla.redhat.com/show_bug.cgi?id=853590#c16

(that bz, you linked in the origin posting)
> > Or maybe we should discuss, if we drop printer drivers. In the
> > Windows world, it seems so common to install a printer driver first,
> > before you could configure it.
>
> If there was an easy way to install them for users, sure... but that
> needs PackageKit, which we dropped in favor of yumex.

That's sad. Maybe we want to revert this decision? But: would that be a 
step forward? I really can't say.

[Martin Sourada]

On Tue, 13 Nov 2012 12:27:13 +0100 
Matthias Runge wrote:
> > If there was an easy way to install them for users, sure... but that
> > needs PackageKit, which we dropped in favor of yumex.
>
> That's sad. Maybe we want to revert this decision? But: would that be
> a step forward? I really can't say.

Ah, yes, I would also be for keeping the packagekit related stuff in.
True, PK looks a bit strange in a xfce environment but the "install
missing codecs", "install detected printer's driver" and "click to
install" are rather useful features... I cannot say anything about the
main interface though -- I never liked yumex (but it's a couple of years
since I last tried it) and PK also never grew on me -- looks like I'm
stuck on command line yum forever, so I'm not very fit to give opinions
on gui package managers.

Martin

[Sergio Cipolla]

On 11/13/2012 09:49 AM, Martin Sourada wrote:
> Ah, yes, I would also be for keeping the packagekit related stuff in.
> True, PK looks a bit strange in a xfce environment but the "install
> missing codecs", "install detected printer's driver" and "click to
> install" are rather useful features... I cannot say anything about the
> main interface though -- I never liked yumex (but it's a couple of years
> since I last tried it) and PK also never grew on me -- looks like I'm
> stuck on command line yum forever, so I'm not very fit to give opinions
> on gui package managers.
>
> Martin

yumex has click-to-install, the codecs thing isn't needed I suppose as 
any codec one might need is outside fedora repos so the one-click thing 
is already busted there.

Rests the driver one.

[Tim Lauridsen]

On Tue, Nov 13, 2012 at 12:49 PM, Martin Sourada
wrote:
> Ah, yes, I would also be for keeping the packagekit related stuff in.
> True, PK looks a bit strange in a xfce environment but the "install
> missing codecs", "install detected printer's driver" and "click to
> install" are rather useful features... I cannot say anything about the
> main interface though -- I never liked yumex (but it's a couple of years
> since I last tried it) and PK also never grew on me -- looks like I'm
> stuck on command line yum forever, so I'm not very fit to give opinions
> on gui package managers.
>
> Martin

Martin, I am always open to suggestion to how to improve yumex, maybe your
should try the current version, and let me know what you don't and how to
improve it.

click to install has recently been implemented in yumex.
install missing codecs is not very useful, because most of it exists
outside fedora (rpmfusion), so most people has to go to rpmfusion.org to
install the repos, so they also
enter the one line yum command to install all the need gstreamer codecs. It
is not something you do every day.

next mayor released will be using a yum based dbus daemon, there will make
it much simpler to use for 3. party application to performing packaging
action and is designed with simplicity in mind and not over engineered as
PackageKit, there is trying to support every package engine there exists.

Tim

[Martin Sourada]

Hi Tim,
> Martin, I am always open to suggestion to how to improve yumex, maybe
> your should try the current version, and let me know what you don't
> and how to improve it.

Sorry if I sounded too critical -- after all it's really been a long
time since I tried yumex, and, after all, I seem to be more of a CLI guy
when it comes to package management -- yumex didn't impress me (in the
deep past), packagekit kept me interested for a while thanks to fancy
updates, but I always fell back to just using yum... It seems that any
hint of a UI either graphical or text (I recently tried some TUI on
OpenSUSE and didn't like it one bit, same with debian about a year back)
gets in my way no matter how complex, or simple it is.

Anyway, in the case I'd give it a spin then if I'd have some
constructive critic (suggestions) by then, I'd definitely share it with
you :)
> click to install has recently been implemented in yumex.

That's good to hear as that's the only case where I'm rather grateful
that GUI package manager exists.
> install missing codecs is not very useful, because most of it exists
> outside fedora (rpmfusion), so most people has to go to rpmfusion.org
> to install the repos, so they also
> enter the one line yum command to install all the need gstreamer
> codecs. It is not something you do every day.

I hate to remember names of packages so I always used to do it in a way
that I installed rpmfusion and then let the music/video players install
the missing codecs on demand via PK. Though I'm not sure how much of
them is actually able to do that -- I used preupgrade the last time
and before then I was using rythmbox+totem+mplayer instead of
quodlibet+parole+mplayer2...

Anyway, the bottom line is, if the mentioned "killer" features of PK do
not work on XFCE spin (sans rpmfusion installation) then having it there
gives no added value and I don't have any issues with having yumex
instead.

Regards,
Martin

[Sergio Cipolla]

...
> next mayor released will be using a yum based dbus daemon, there will make
> it much simpler to use for 3. party application to performing packaging
> action and is designed with simplicity in mind and not over engineered as
> PackageKit, there is trying to support every package engine there exists.
>
> Tim

I've added a couple of suggestions on github that I had noticed here.

On a side-note, I'm using the test package for 3.0.10 and I noticed that 
its 'working window' is a bit more verbose than in 3.0.9 with some 
messages like

Unknown metadata type (group_gz) ..
Unknown metadata type (pkgtags) ..
Unknown metadata type (other_db) ..
Repo Metadata for XXXX.xml

appearing on occasions.

[Kevin Fenzi]

On Tue, 13 Nov 2012 12:49:26 +0100
Martin Sourada  wrote:
> On Tue, 13 Nov 2012 12:27:13 +0100 
> Matthias Runge wrote:
> > > If there was an easy way to install them for users, sure... but
> > > that needs PackageKit, which we dropped in favor of yumex.
> >
> > That's sad. Maybe we want to revert this decision? But: would that
> > be a step forward? I really can't say.
>
> Ah, yes, I would also be for keeping the packagekit related stuff in.
> True, PK looks a bit strange in a xfce environment but the "install
> missing codecs", "install detected printer's driver" and "click to
> install" are rather useful features... I cannot say anything about the
> main interface though -- I never liked yumex (but it's a couple of
> years since I last tried it) and PK also never grew on me -- looks
> like I'm stuck on command line yum forever, so I'm not very fit to
> give opinions on gui package managers.

I'm not sure those features actually work under Xfce in any case.

I know there's no updates indicator in Xfce. Also, I think PackageKit
pulls in a bunch more gnome stuff we don't want/use.

I also use yum (or dnf if I am feeling dangerous), but I think yumex is
a better fit for our spin.

kevin

[Martin Sourada]

On Tue, 13 Nov 2012 10:09:16 -0700 
Kevin Fenzi wrote:
> I'm not sure those features actually work under Xfce in any case.
>
> I know there's no updates indicator in Xfce. Also, I think PackageKit
> pulls in a bunch more gnome stuff we don't want/use.

Ah, that's bad... I wish gnome people would make their apps more
usable outside the gnome environment :-(
> I also use yum (or dnf if I am feeling dangerous), but I think yumex
> is a better fit for our spin.

Well, if the features does not work, than it's a no-brainer... But I
vaguely recall that at least the printer driver install worked for me.

Martin

[Sergio Cipolla]

On 11/13/2012 03:09 PM, Kevin Fenzi wrote:
> I know there's no updates indicator in Xfce.

If there's one for Mate (and other conveniences) it can be installed 
with https://github.com/linuxmint/xfce4-xfapplet-plugin
Might be worth packaging.↑

[Kevin Fenzi]

On Tue, 13 Nov 2012 20:42:37 -0200
Sergio  wrote:
> On 11/13/2012 03:09 PM, Kevin Fenzi wrote:
> > I know there's no updates indicator in Xfce.
>
> If there's one for Mate (and other conveniences) it can be installed 
> with https://github.com/linuxmint/xfce4-xfapplet-plugin
> Might be worth packaging.↑

It was, we dropped it when gnome2 was dropped, I suppose we could bring
it back if mate folks package up the applets again.

Are you sure update indicators work in mate? My understanding is that
PackageKit no longer has any systray support, it uses gnome3
notifications only, so I would expect it to not work in mate either.

kevin

[Sergio Cipolla]

On 11/13/2012 08:56 PM, Kevin Fenzi wrote:
> On Tue, 13 Nov 2012 20:42:37 -0200
> Sergio  wrote:
> > On 11/13/2012 03:09 PM, Kevin Fenzi wrote:
> > > I know there's no updates indicator in Xfce.
> >
> > If there's one for Mate (and other conveniences) it can be installed
> > with https://github.com/linuxmint/xfce4-xfapplet-plugin
> > Might be worth packaging.↑
>
> It was, we dropped it when gnome2 was dropped, I suppose we could bring
> it back if mate folks package up the applets again.
>
> Are you sure update indicators work in mate? My understanding is that
> PackageKit no longer has any systray support, it uses gnome3
> notifications only, so I would expect it to not work in mate either.

I don't know. Isn't there a mate-packagekit ;-)

[Kevin Fenzi]

So, heres the current top 40 packages by size:

122862271 kernel
117821428 glibc-common
93833830 java-1.7.0-openjdk
40656267 webkitgtk
40381410 xulrunner
35623360 linux-firmware
35475387 mesa-dri-drivers
34904384 perl
33147198 foomatic-db-ppds
29809732 firefox
29454189 gnumeric
28363236 libpinyin-data
27879319 libpurple
26038006 anthy
25009477 python-libs
22247740 libicu
21457344 llvm-libs
21094325 cjkuni-uming-fonts
20990480 gutenprint
20543461 libabiword
18509337 grub2-efi
17156348 wqy-zenhei-fonts
17036975 ghostscript
16501168 samba-libs
16088019 selinux-policy-targeted
15989135 binutils
15914825 grub2-tools
15147474 claws-mail
14233669 coreutils
14149244 iso-codes
13845828 glibc
13351916 gtk2
12803865 nhn-nanum-gothic-fonts
12632645 geany
12370754 gtk3
12012878 poppler-data
11713752 sssd
10076667 spherical-cow-backgrounds-single
9739522 glib2
9638099 gnome-icon-theme

Looking at this... what about removing gnumeric? Most folks that need
spreadsheets aren't going to use a live media, even then they would
probibly want to test the libreoffice version? gnumeric has no deps and
is 28MB.

Any objections?

kevin

[Tim Lauridsen]

On Thu, Nov 15, 2012 at 11:20 PM, Kevin Fenzi  wrote:
> Looking at this... what about removing gnumeric? Most folks that need
> spreadsheets aren't going to use a live media, even then they would
> probibly want to test the libreoffice version? gnumeric has no deps and
> is 28MB.
>
> Any objections?

+1, On of the first things i remove after installing the Xfce Live cd.

Tim

[Sergio Cipolla]

This won't have any effect on space but while looking on gstreamer stuff 
I found that gstreamer-plugins-espeak is installed on the live-cd but 
nothing requires it (it's for sugar).

[Kevin Fenzi]

On Sun, 11 Nov 2012 18:26:53 +0100
Christoph Wickert  wrote:
> Am Samstag, den 10.11.2012, 14:39 -0700 schrieb Kevin Fenzi:
> > https://bugzilla.redhat.com/show_bug.cgi?id=853590
> >
> > Some options:
> > nuke icedtea-web (this saves 100MB or so, but means people won't
> >
> > be able to test java in the live instance).
>
> It should be ~70 mb at least, but I am afraid it is unintuitive.
> People will just see that something doesn't work but hardly know how
> to fix it. "icedtea" is not really to find in the package management.

indeed. ;(
> > seahorse - 7mb
>
> Not a bad idea, however I consider seahorse useful.

I don't use it here, so I would be fine with it going away...
> > Longer term: split perl deps out of exo and see if we can remove
> > perl? lm_sensors also needs perl, so we would have to drop
> > xfce4-sensors-plugin, but I think it's worth it. That could save
> >
> > us a ton of room down the road. This dep is due exo-compose-mail-1
> > helper being a perl script.
>
> I doubt that we cal really remove perl form the spin and even if we
> can, it means we loose some features like attaching a file form
> Thunar to a mail via the "Send to" menu.

Well, we would need to re-implement that... Probibly in python if not
c. ;(
> > drop one of firefox or midori. ;)

Well, I use midori, so you know my vote. ;)

Happy to go the other way if people like tho.
> Drop some themes!

We could, I guess that would be fine too.

kevin

[Raphael Groner]

Kevin Fenzi kevin at scrye.com 
Sat Nov 10 21:39:37 UTC 2012
> https://bugzilla.redhat.com/show_bug.cgi?id=853590

Bug is closed, so I respond here.

The guys of aptosid managed to do a Xfce media image that has not at
all the size of a full CD. KDE full needs >2GB but with an older
version (4.8.4 - F18 is known to ship the 4.9 version).

Maybe we can steal some good ideas to shrink the image? ;)

distrowatch.eu:
aptosid-2012-01-kde-full-i386-amd64.iso" (2,054MB)
aptosid-2012-01-xfce-i386.iso (509MB) 
aptosid-2012-01-xfce-amd64.iso (515MB)

BG,
Raphael

[Tim Lauridsen]

Not a problem to reduce size, the problem is to find that functionality to
cut away :)

On Sun, Dec 2, 2012 at 2:57 PM, Raphael Groner  wrote:
> Kevin Fenzi kevin at scrye.com
> Sat Nov 10 21:39:37 UTC 2012
> > https://bugzilla.redhat.com/show_bug.cgi?id=853590
>
> Bug is closed, so I respond here.
>
> The guys of aptosid managed to do a Xfce media image that has not at
> all the size of a full CD. KDE full needs >2GB but with an older
> version (4.8.4 - F18 is known to ship the 4.9 version).
>
> Maybe we can steal some good ideas to shrink the image? ;)
>
> distrowatch.eu:
> aptosid-2012-01-kde-full-i386-amd64.iso" (2,054MB)
> aptosid-2012-01-xfce-i386.iso (509MB)
> aptosid-2012-01-xfce-amd64.iso (515MB)
>
> BG,
> Raphael
> _______________________________________________
> xfce mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/xfce

[Sergio Cipolla]

On 12/02/2012 12:18 PM, [e-mail] wrote:
> Not a problem to reduce size, the problem is to find that functionality to
> cut away :)
>
> On Sun, Dec 2, 2012 at 2:57 PM, Raphael Groner  wrote:
> > Kevin Fenzi kevin at scrye.com
> > Sat Nov 10 21:39:37 UTC 2012
> > > https://bugzilla.redhat.com/show_bug.cgi?id=853590
> >
> > Bug is closed, so I respond here.
> >
> > The guys of aptosid managed to do a Xfce media image that has not at
> > all the size of a full CD. KDE full needs >2GB but with an older
> > version (4.8.4 - F18 is known to ship the 4.9 version).
> >
> > Maybe we can steal some good ideas to shrink the image? ;)
> >
> > distrowatch.eu:
> > aptosid-2012-01-kde-full-i386-amd64.iso" (2,054MB)
> > aptosid-2012-01-xfce-i386.iso (509MB)
> > aptosid-2012-01-xfce-amd64.iso (515MB)
> >
> > BG,
> > Raphael

I didn't check the aptosid isos but Debian splits a lot the sources so 
that tends to make it easier to do a smaller installation.