3:39 p.m.
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
2:51 a.m.
On Sat, Nov 10, 2012 at 10:39 PM, Kevin Fenzi <kevin(a)scrye.com> 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
2:56 a.m.
On Sat, 10 Nov 2012 14:39:37 -0700
Kevin Fenzi <kevin(a)scrye.com> 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..
--
Regards,
Frank
11:26 a.m.
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
11:51 a.m.
On Sun, 11 Nov 2012 18:26:53 +0100
Christoph Wickert <christoph.wickert(a)gmail.com> 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.
--
Charlie Kravetz
Linux Registered User Number 425914 [http://counter.li.org/]
Never let anyone steal your DREAM. [http://keepingdreams.com]
12:03 p.m.
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
12:41 p.m.
On Sun, 11 Nov 2012 19:03:27 +0100
Christoph Wickert <christoph.wickert(a)gmail.com> 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.
--
Charlie Kravetz
Linux Registered User Number 425914 [http://counter.li.org/]
Never let anyone steal your DREAM. [http://keepingdreams.com]
6:17 a.m.
Am Sonntag, den 11.11.2012, 11:41 -0700 schrieb Charlie Kravetz:
On Sun, 11 Nov 2012 19:03:27 +0100
Christoph Wickert <christoph.wickert(a)gmail.com> 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
6:24 a.m.
On Mon, Nov 12, 2012 at 1:17 PM, Christoph Wickert <
christoph.wickert(a)gmail.com> wrote:
Am Sonntag, den 11.11.2012, 11:41 -0700 schrieb Charlie Kravetz:
> On Sun, 11 Nov 2012 19:03:27 +0100
> Christoph Wickert <christoph.wickert(a)gmail.com> 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
xfce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xfce
11:17 p.m.
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
--
Dominic Hopf
http://dominichopf.de/
Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
5:39 a.m.
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.
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
2:58 p.m.
On Mon, 12 Nov 2012 12:39:15 +0100
Matthias Runge <mrunge(a)matthias-runge.de> 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
5:27 a.m.
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.
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
5:49 a.m.
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
7:01 a.m.
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.
9:02 a.m.
On Tue, Nov 13, 2012 at 12:49 PM, Martin Sourada
<martin.sourada(a)gmail.com>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
3:15 p.m.
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
3:28 p.m.
...
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.
11:09 a.m.
On Tue, 13 Nov 2012 12:49:26 +0100
Martin Sourada <martin.sourada(a)gmail.com> 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
2:55 p.m.
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
4:42 p.m.
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.↑
4:56 p.m.
On Tue, 13 Nov 2012 20:42:37 -0200
Sergio <secipolla(a)gmail.com> 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
4:58 p.m.
On 11/13/2012 08:56 PM, Kevin Fenzi wrote:
On Tue, 13 Nov 2012 20:42:37 -0200
Sergio <secipolla(a)gmail.com> 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 ;-)
4:20 p.m.
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
11:46 p.m.
On Thu, Nov 15, 2012 at 11:20 PM, Kevin Fenzi <kevin(a)scrye.com> 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
5:06 p.m.
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).
3:45 p.m.
On Sun, 11 Nov 2012 18:26:53 +0100
Christoph Wickert <christoph.wickert(a)gmail.com> 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
7:57 a.m.
Kevin Fenzi kevin at scrye.com
Sat Nov 10 21:39:37 UTC 2012
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
8:18 a.m.
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 <raphgro(a)web.de> 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
xfce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xfce
8:31 a.m.
On 12/02/2012 12:18 PM, tim.lauridsen(a)gmail.com 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 <raphgro(a)web.de> 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.
4157
days inactive
4179
days old
29 comments
11 participants
participants (11)
-
Charlie Kravetz -
Christoph Wickert -
Dominic Hopf -
Frank Murphy -
Johannes Lips -
Kevin Fenzi -
Martin Sourada -
Matthias Runge -
Raphael Groner -
Sergio Cipolla -
Tim Lauridsen