On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote:
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I know you're working on it)
I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup).
If that is not enough, next step will probably be removing some of the big font packages.
So Matthias forgot to link to his update, but here it is:
https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6...
It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size.
So here's some results.
f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384
that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere.
Thanks folks!
On Sat, 2013-06-22 at 22:51 -0700, Adam Williamson wrote:
So here's some results.
f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384
that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere.
Thanks for producing those numbers. I've made 2 more cuts in the kickstart file, and dropped eog (we have shotwell) and the Gnu FreeFont packages.
Maybe it is worth looking ahead and see how we can avoid this situation come F20. Here are some sizes as found on the current desktop spin:
total size 2671M
translations 402M input methods 133M fonts 89M rpm db 82M firmware 59M boot loader 40M
There are some possible savings by completing transitions / obsoletions:
- Both gstreamer1 and gstreamer are on the spin. 0.10 is pulled in by libpurple -> farstream. Possible savings: 17M. https://bugzilla.redhat.com/show_bug.cgi?id=962028
- GConf2 is still there, pulled in by gstreamer, gnome-session, libreoffice-core, NetworkManager-openconnect and gnome-terminal. Possible savings: 6M
- We have both js and mozjs17. js is still used by gjs, libpeas, libproxy-mozjs and gnome-shell. Possible savings: 7M
- Both festival and flite are getting pulled in by speech-dispatcher. Possible savings: 9M. https://bugzilla.redhat.com/show_bug.cgi?id=799140
- Both python2 and python3 are on the spin. This will certainly be with us for a while.
There are also quite a few minor one-off dependencies that are pulled in by a single package, such as libgphoto2 -> gd -> libXpm or frei0r-plugins -> gavl or festival -> sox -> libao.
On Sun, Jun 23, 2013 at 06:04:55PM -0400, Matthias Clasen wrote:
- Both festival and flite are getting pulled in by speech-dispatcher.
Possible savings: 9M. https://bugzilla.redhat.com/show_bug.cgi?id=799140
The festival package needs to be update to the latest version, a possible F20 feature. As part of that, I was planning to look at refactoring the package *anyway*, because there are a number of ways in which it could be subpackaged better. So maybe that will help some.
On Sun, Jun 23, 2013 at 06:04:55PM -0400, Matthias Clasen wrote:
come F20. Here are some sizes as found on the current desktop spin:
These are on-disk sizes, right, not RPM size?
translations 402M
On my F19 desktop, I have 530MB under /usr/share/locale; this compresses down to 94MB with xz -- 67MB with xz -9. And we're xz-ing the livecd and RPM payloads, right?
That's still a lot of space, of course. And I'm not super-excited about the uncompressed on-disk space. (And here, not even considering locale-archive.)
On Sun, Jun 23, 2013 at 20:17:23 -0400, Matthew Miller mattdm@fedoraproject.org wrote:
On my F19 desktop, I have 530MB under /usr/share/locale; this compresses down to 94MB with xz -- 67MB with xz -9. And we're xz-ing the livecd and RPM payloads, right?
The live images get compressed at the end, so looking at the potential savings you want to think about how compressible it is. Savings from reducing things that compress well are not going to be as good as that from data that is already compressed when installed.
On Sun, Jun 23, 2013 at 07:25:50PM -0500, Bruno Wolff III wrote:
On my F19 desktop, I have 530MB under /usr/share/locale; this compresses down to 94MB with xz -- 67MB with xz -9. And we're xz-ing the livecd and RPM payloads, right?
The live images get compressed at the end, so looking at the potential savings you want to think about how compressible it is. Savings from reducing things that compress well are not going to be as good as that from data that is already compressed when installed.
Yes, sorry, that was supposed to be my point. The translations are obviously a big chunk of the uncompressed usage, but _do_ compress well.
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mclasen@redhat.com wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time.
Bruno Wolff III (bruno@wolff.to) said:
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mclasen@redhat.com wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time.
It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system...
Bill
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham notting@redhat.com wrote:
Bruno Wolff III (bruno@wolff.to) said:
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mclasen@redhat.com wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time.
It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system...
And it allows stuff like "yum install foo" to work in the live environment.
On Mon, 2013-06-24 at 15:21 +0200, drago01 wrote:
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham notting@redhat.com wrote:
Bruno Wolff III (bruno@wolff.to) said:
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mclasen@redhat.com wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time.
It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system...
And it allows stuff like "yum install foo" to work in the live environment.
which is *extremely* useful both for normal use and for testing (I do 'yum update anaconda' for a quick test run all the time, fr'instance). Let's not lose that :)
On Mon, 2013-06-24 at 09:15 -0400, Bill Nottingham wrote:
Bruno Wolff III (bruno@wolff.to) said:
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mclasen@redhat.com wrote:
rpm db 82M
I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time.
It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system...
I don't really want to propose dropping the rpm db. I merely stated those numbers to give some perspective on what takes up how much space on the live image.
On Mon, 2013-06-24 at 09:14 -0400, Bill Nottingham wrote:
- We have both js and mozjs17. js is still used by gjs, libpeas,
libproxy-mozjs and gnome-shell. Possible savings: 7M
I thought Colin was fixing everything to use mosjz17. Is that a F-20 thing?
It missed f19, yes.
----- Original Message -----
On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote:
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I know you're working on it)
I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup).
If that is not enough, next step will probably be removing some of the big font packages.
So Matthias forgot to link to his update, but here it is:
https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6...
It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size.
So here's some results.
f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384
that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere.
Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more "we set it as we think it's a good idea". Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one.
R.
Thanks folks!
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
----- Original Message -----
----- Original Message -----
On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote:
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I know you're working on it)
I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup).
If that is not enough, next step will probably be removing some of the big font packages.
So Matthias forgot to link to his update, but here it is:
https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6...
It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size.
So here's some results.
f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384
that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere.
Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more "we set it as we think it's a good idea". Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one.
And I'm aware of multi desktop medias - not sure 5 megs means a huge difference there (and it still makes sense to have some limit +/-).
R.
R.
Thanks folks!
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2013-06-24 at 07:22 -0400, Jaroslav Reznik wrote:
that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere.
Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more "we set it as we think it's a good idea". Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one.
So my take on that is:
* As long as we have a size limit we should be byte-strict. This is just for practical reasons: it's excessively difficult to enforce a 'fuzzy' size cap. It's much easier if it's just Thou Shalt Not.
* There is nothing magical about 10000000000 (whatever the zero count is) bytes. We picked the power-of-10 GB as a pessimistic number for the USB stick case: we haven't actually sent anyone to Staples to buy a bunch of USB sticks and figure out exactly how many bytes you can write to one with a given stated capacity, we just figured that was the safe pessimistic number to use. Personally I'm not in any way wedded to that specific size limit for the desktop live image; if the desktop team wants to change it, fine. As I wrote earlier in the thread, I'd just like to make sure the spin doesn't get so large people consider it bloated, and doesn't start interfering with our ability to do the four-desktop live DVD.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
drago01 -
Jaroslav Reznik -
Matthew Miller -
Matthew Miller -
Matthias Clasen