Re: Fedora 19 Final blocker status: fix and karma requests

[Adam Williamson]

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....
>  
>  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!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Fedora 19 Final blocker status: fix and karma requests

[Matthias Clasen]

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.

Fedora 19 Final blocker status: fix and karma requests

[Matthew Miller]

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.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Fedora 19 Final blocker status: fix and karma requests

[Matthew Miller]

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.)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Fedora 19 Final blocker status: fix and karma requests

[Bruno Wolff III]

On Sun, Jun 23, 2013 at 20:17:23 -0400,
   Matthew Miller <mattdm(a)fedoraproject.org&gt; 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.

Fedora 19 Final blocker status: fix and karma requests

[Bruno Wolff III]

On Sun, Jun 23, 2013 at 18:04:55 -0400,
   Matthias Clasen <mclasen(a)redhat.com&gt; 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.

Fedora 19 Final blocker status: fix and karma requests

[Matthew Miller]

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.

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

Fedora 19 Final blocker status: fix and karma requests

[Jaroslav Reznik]

----- 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....
>  > 
>  > 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 19 Final blocker status: fix and karma requests

[Jaroslav Reznik]

----- 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....
>  > > 
>  > > 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(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 19 Final blocker status: fix and karma requests

[Bill Nottingham]

>  - 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?

Bill

Fedora 19 Final blocker status: fix and karma requests

[Bill Nottingham]

Bruno Wolff III (bruno(a)wolff.to) said: 
>  On Sun, Jun 23, 2013 at 18:04:55 -0400,
>    Matthias Clasen <mclasen(a)redhat.com&gt; 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

Fedora 19 Final blocker status: fix and karma requests

[drago01]

On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  Bruno Wolff III (bruno(a)wolff.to) said:
> > On Sun, Jun 23, 2013 at 18:04:55 -0400,
> >   Matthias Clasen <mclasen(a)redhat.com&gt; 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.

Fedora 19 Final blocker status: fix and karma requests

[Matthias Clasen]

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.

Fedora 19 Final blocker status: fix and karma requests

[Matthias Clasen]

On Mon, 2013-06-24 at 09:15 -0400, Bill Nottingham wrote:
>  Bruno Wolff III (bruno(a)wolff.to) said: 
>  > On Sun, Jun 23, 2013 at 18:04:55 -0400,
>  >   Matthias Clasen <mclasen(a)redhat.com&gt; 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.

Fedora 19 Final blocker status: fix and karma requests

[Adam Williamson]

On Mon, 2013-06-24 at 15:21 +0200, drago01 wrote:
>  On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham
> <notting(a)redhat.com&gt; wrote:
>  > Bruno Wolff III (bruno(a)wolff.to) said:
>  >> On Sun, Jun 23, 2013 at 18:04:55 -0400,
>  >>   Matthias Clasen <mclasen(a)redhat.com&gt; 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 :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Fedora 19 Final blocker status: fix and karma requests

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net