4:14 p.m.
Hey folks, time for another F19 Final status update!
We're looking relatively hopeful at this point, but still some work to
be done.
Outstanding blockers
--------------------
We need fixes for:
https://bugzilla.redhat.com/show_bug.cgi?id=924162 - "A software
selection with dependency errors is allowed to proceed if the dependency
check runs twice" - anaconda team (I know you're working on it)
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)
https://bugzilla.redhat.com/show_bug.cgi?id=679486 - "Liveinst doesn't
start if hostname changes" - anaconda / X teams
Karma requests
--------------
We need karma for these blocker-bug-fixing-updates:
https://admin.fedoraproject.org/updates/anaconda-19.30.9-1.fc19
https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19
We also could do with karma for the following FE bugs, esp. grub2:
https://admin.fedoraproject.org/updates/swell-foop-3.8.1-3.fc19,iagno-3.8...
https://admin.fedoraproject.org/updates/grub2-2.00-22.fc19
https://admin.fedoraproject.org/updates/initial-setup-0.3.6-2.fc19
https://admin.fedoraproject.org/updates/PackageKit-0.8.9-5.fc19
https://admin.fedoraproject.org/updates/php-5.5.0-1.fc19
https://admin.fedoraproject.org/updates/lightdm-1.6.0-10.fc19
https://admin.fedoraproject.org/updates/mate-power-manager-1.6.1-3.fc19
(proposed)
anaconda 19.30.9 is in TC6; if that's basically working for you, you can
+1 the update. glib2 is supposed to fix the bug that causes dconf
database corruption on unclean system shutdown: you can +1 it so long as
it doesn't cause any major breakage, but it'd be ideal if people could
verify the fix. The swell-foop etc. update fixes the direct F17->F19
upgrade path; should be testable by installing F17, ensuring gnome-games
is installed, and trying a fedup or yum upgrade with those packages
available. The upgrade should not fail on
https://bugzilla.redhat.com/show_bug.cgi?id=976107 . The grub2 update
should fix editing wrapped lines in the edit mode -
https://bugzilla.redhat.com/show_bug.cgi?id=976643 - that's kind of
important. The initial-setup update fixes a few bugs, just +1 it if TC6
installs other than GNOME work okay and i-s doesn't seem busted. The
PackageKit bug implements the stricter PolicyKit policy requested by
FESCo in https://fedorahosted.org/fesco/ticket/1115 ; you can +1 it so
long as PK stuff isn't broken, but ideally we should verify the policy
behaves as expected. PHP should just be +1ed if it works properly for
normal PHP stuff. lightdm should fix things so shutdown and restart
options are offered by lightdm (which is used by Xfce, MATE, Cinnamon
and Sugar spins). mate-power-manager should fix a bug where MATE was not
suspending on laptop lid close (not accepted as an FE yet, but worth
testing in case it is).
Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10 a.m.
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.
10:58 a.m.
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.
Thanks a lot, Matthias. I'll try and test the changes and see what size
a live image with them included comes out at if I get a free moment
today.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:51 p.m.
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
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).
That's a shame; Deja Dup is an excellent GNOME 3 backup app, and
including it by default encourages good (encrypted) backup habits.
But I guess something has to go if we care about 1 GB. (It just seems
like such a strange target... I don't think you can buy 1 GB USB sticks
anymore.)
Michael Catanzaro
11:54 p.m.
On Sat, 2013-06-22 at 18:51 -0500, Michael Catanzaro wrote:
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
> 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).
That's a shame; Deja Dup is an excellent GNOME 3 backup app, and
including it by default encourages good (encrypted) backup habits.
But I guess something has to go if we care about 1 GB. (It just seems
like such a strange target... I don't think you can buy 1 GB USB sticks
anymore.)
It was the next 'obvious step up' from 700MB, and at the time was
comfortable enough for everything we really needed. Stuff happened.
Desktop team might be able to rejig things early in F20 cycle somehow,
or we might have to go up in size again.
Going too big does have consequences: a, say, 2GB download is pretty
slow for some people, some people do still have nasty caps, and at some
point you start getting people saying 'why does it have to be so big?
What's all the bloat?' If all the lives start getting bigger, we may
also not be able to manage the four-desktop-spin live DVD any more. (If
anything, it'd be nice to get *more* desktops on that, not fewer, but it
seems unlikely).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:44 a.m.
On Sun, Jun 23, 2013 at 6:54 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2013-06-22 at 18:51 -0500, Michael Catanzaro wrote:
> On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
> > 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).
> That's a shame; Deja Dup is an excellent GNOME 3 backup app, and
> including it by default encourages good (encrypted) backup habits.
>
> But I guess something has to go if we care about 1 GB. (It just seems
> like such a strange target... I don't think you can buy 1 GB USB sticks
> anymore.)
It was the next 'obvious step up' from 700MB, and at the time was
comfortable enough for everything we really needed. Stuff happened.
Desktop team might be able to rejig things early in F20 cycle somehow,
or we might have to go up in size again.
Going too big does have consequences: a, say, 2GB download is pretty
slow for some people,
1) Removing the limit does not mean you have to put in twice as many stuff in.
We are currently bikesheeding about a few MBs. Which is nonsense. If you
cannot download a few more MBs using Fedora with that internet connection
is rather pointless.
The end result is a worse default offering then we had before to save a few MBs.
2) We don't have to set a limit at all. Just include the stuff we want
to include (and try to optimize that to be as small as possible).
Just because someone decided "there has to be a size limit and if we
don't meet that target we block the release" does
not mean that this is the right thing to do (note: it isn't). A limit
only makes sense if you target a CD.
9:24 a.m.
On Sun, 2013-06-23 at 09:44 +0200, drago01 wrote:
2) We don't have to set a limit at all. Just include the stuff we
want
to include (and try to optimize that to be as small as possible).
Let's be realistic: 'trying to optimize that to be as small as possible'
only happens when we have a limit and start hitting it. Was anyone
checking and splitting out dependencies, tweaking the package set, and
looking for unnecessary data to cut out *before* we were filing bugs on
the size? Nope, no-one was.
I'm not saying there must be a limit, but I know what's going to happen
if there isn't one, don't kid yourself: limitless sprawl, and no-one's
going to bother about size reductions.
Just because someone decided "there has to be a size limit and
if we
don't meet that target we block the release" does
not mean that this is the right thing to do (note: it isn't). A limit
only makes sense if you target a CD.
As noted in my previous message, we are in fact still targeting optical
media with the live images: the multi-live DVD image.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:20 a.m.
On Sun, Jun 23, 2013 at 07:24:15AM -0700, Adam Williamson wrote:
> Just because someone decided "there has to be a size limit
and if we
> don't meet that target we block the release" does
> not mean that this is the right thing to do (note: it isn't). A limit
> only makes sense if you target a CD.
As noted in my previous message, we are in fact still targeting optical
media with the live images: the multi-live DVD image.
Small size is also desirable for cloud images -- it makes them easier to
manipulateand faster to deploy. I know that's not the _current_ discussion,
but I hope people remember that if optical media go away (or increase 10x in
capacity, or whatever), a small core still has practical advantages.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:20 p.m.
On Sun, Jun 23, 2013 at 5:20 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Sun, Jun 23, 2013 at 07:24:15AM -0700, Adam Williamson wrote:
> > Just because someone decided "there has to be a size limit and if we
> > don't meet that target we block the release" does
> > not mean that this is the right thing to do (note: it isn't). A limit
> > only makes sense if you target a CD.
> As noted in my previous message, we are in fact still targeting optical
> media with the live images: the multi-live DVD image.
Small size is also desirable for cloud images -- it makes them easier to
manipulateand faster to deploy. I know that's not the _current_ discussion,
but I hope people remember that if optical media go away (or increase 10x in
capacity, or whatever), a small core still has practical advantages.
Two things:
1) no one really uses the desktop image as a basis for cloud
2) having no limit does not mean people will stop caring about size
... as this example shows. If someone cares he/she can work on
reducing size.
But we do not need to enforce it using arbitrary limits.
3:01 p.m.
On Sun, Jun 23, 2013 at 07:20:20PM +0200, drago01 wrote:
1) no one really uses the desktop image as a basis for cloud
Some classes at a large university where I used to work do.
Also see http://adam.younglogic.com/2012/09/vm-from-live-cd/
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:02 p.m.
On Sun, Jun 23, 2013 at 04:01:20PM -0400, Matthew Miller wrote:
On Sun, Jun 23, 2013 at 07:20:20PM +0200, drago01 wrote:
> 1) no one really uses the desktop image as a basis for cloud
Some classes at a large university where I used to work do.
Also see http://adam.younglogic.com/2012/09/vm-from-live-cd/
But that said, I *did* say that I know that the cloud images aren't the
current discussion. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:22 p.m.
On Sun, Jun 23, 2013 at 4:24 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sun, 2013-06-23 at 09:44 +0200, drago01 wrote:
> 2) We don't have to set a limit at all. Just include the stuff we want
> to include (and try to optimize that to be as small as possible).
Let's be realistic: 'trying to optimize that to be as small as possible'
only happens when we have a limit and start hitting it. Was anyone
checking and splitting out dependencies, tweaking the package set, and
looking for unnecessary data to cut out *before* we were filing bugs on
the size? Nope, no-one was.
I'm not saying there must be a limit, but I know what's going to happen
if there isn't one, don't kid yourself: limitless sprawl, and no-one's
going to bother about size reductions.
See my reply to Matthew.
> Just because someone decided "there has to be a size limit
and if we
> don't meet that target we block the release" does
> not mean that this is the right thing to do (note: it isn't). A limit
> only makes sense if you target a CD.
As noted in my previous message, we are in fact still targeting optical
media with the live images: the multi-live DVD image.
Well this is a valid reason to limit the size but not of one specific
spin but all of them jointly.
i.e we have to build it as part of our release and testing process and
spot size problems there etc.
12:30 p.m.
On Sun, 2013-06-23 at 19:22 +0200, drago01 wrote:
On Sun, Jun 23, 2013 at 4:24 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Sun, 2013-06-23 at 09:44 +0200, drago01 wrote:
>
>> 2) We don't have to set a limit at all. Just include the stuff we want
>> to include (and try to optimize that to be as small as possible).
>
> Let's be realistic: 'trying to optimize that to be as small as
possible'
> only happens when we have a limit and start hitting it. Was anyone
> checking and splitting out dependencies, tweaking the package set, and
> looking for unnecessary data to cut out *before* we were filing bugs on
> the size? Nope, no-one was.
>
> I'm not saying there must be a limit, but I know what's going to happen
> if there isn't one, don't kid yourself: limitless sprawl, and no-one's
> going to bother about size reductions.
See my reply to Matthew.
I meant in the desktop image specifically, not in the distro in general.
There are people who care strongly about the core/minimal size and work
to keep it down, but the live spins generally just keep growing until
they hit a limit, whereupon we start filing bugs and people start
caring.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:38 a.m.
On Sun, Jun 23, 2013 at 1:51 AM, Michael Catanzaro
<mike.catanzaro(a)gmail.com> wrote:
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote:
> 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).
That's a shame; Deja Dup is an excellent GNOME 3 backup app, and
including it by default encourages good (encrypted) backup habits.
Well I agree with Colin's comment in the bug. The primary issue is that we
don't have an application installer. So we tend to install lots of
stuff by default.
We should fix this in F20.
But I guess something has to go if we care about 1 GB. (It just
seems
like such a strange target... I don't think you can buy 1 GB USB sticks
anymore.)
It is a rather arbitrary and pointless limit IMO.
12:17 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:51 a.m.
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
5:04 p.m.
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.
6:44 p.m.
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>
7:17 p.m.
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>
7:25 p.m.
On Sun, Jun 23, 2013 at 20:17:23 -0400,
Matthew Miller <mattdm(a)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.
7:30 p.m.
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/>
7:27 p.m.
On Sun, Jun 23, 2013 at 18:04:55 -0400,
Matthias Clasen <mclasen(a)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.
4:53 a.m.
On 06/24/2013 03:27 AM, Bruno Wolff III wrote:
On Sun, Jun 23, 2013 at 18:04:55 -0400,
Matthias Clasen <mclasen(a)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.
Well you can't create the rpmdb out of nothing on reboot.
There are three different types of data in the rpmdb:
- the main Packages database which holds the package headers
- indexes like Name, Requirename etc which can always be recreated from
the main Packages db
- host-specific __db.* files (BDB internal cache, locks etc) which must
NOT be included in live images, and which get created as needed
The __db.* files hopefully are not included on live images to begin
with. It might be possible to drop the indexes too: current rpm
versions will automatically generate missing indexes on access, but
obviously it needs to run as root for that to work. So if indexes are
dropped, non-root queries would be very broken until root does a query
or runs an explicit 'rpmdb --rebuilddb' (which could be arranged to
happen on boot)
- Panu -
8:51 a.m.
On Mon, Jun 24, 2013 at 12:53:14 +0300,
Panu Matilainen <pmatilai(a)laiskiainen.org> wrote:
On 06/24/2013 03:27 AM, Bruno Wolff III wrote:
The __db.* files hopefully are not included on live images to begin
with. It might be possible to drop the indexes too: current rpm
Those are the files I was referring to and my memory is that they are
removed from live images. I don't know if they were included in the
quoted size for rpmdb.
8:15 a.m.
Bruno Wolff III (bruno(a)wolff.to) said:
On Sun, Jun 23, 2013 at 18:04:55 -0400,
Matthias Clasen <mclasen(a)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
8:21 a.m.
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham <notting(a)redhat.com> 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> 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.
3:17 p.m.
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> 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> 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
8:39 a.m.
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> 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.
6:22 a.m.
----- 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
6:25 a.m.
----- 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
9:22 a.m.
New subject: media capacity and Fedora 19
On 06/24/2013, Jaroslav Reznik wrote:
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.
Device sizes vary according to manufacturer and model. 3% is not uncommon.
Here's one actual "1GB" USB2.0 flash memory device that I use
[from syslog, /var/log/messages]:
usb 1-9: New USB device found, idVendor=154b, idProduct=0005
sd 9:0:0:0: [sdc] 2015232 512-byte logical blocks: (1.03 GB/984 MiB)
That's 30MB (3%) more capacity than labeled.
Here's a "4GB" device:
usb 1-9: New USB device found, idVendor=154b, idProduct=000f
sd 13:0:0:0: [sdc] 8060928 512-byte logical blocks: (4.12 GB/3.84 GiB)
That's 127MB (3.2%) more capacity than labeled.
Here's a "8GB" device:
usb 1-9: New USB device found, idVendor=13fe, idProduct=5100
sd 11:0:0:0: [sdc] 15466496 512-byte logical blocks: (7.91 GB/7.37 GiB)
That's 81MB (1%) less capacity than labeled.
Here's a "16GB" device:
usb 1-10: New USB device found, idVendor=13fe, idProduct=5200
sd 10:0:0:0: [sdc] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB)
That's 495MB (3.1%) less capacity than labeled. [Almost illegal.]
--
11:27 a.m.
New subject: media capacity and Fedora 19
On 06/24/2013 07:22 AM, John Reiser wrote:
Device sizes vary according to manufacturer and model. 3% is not uncommon.
[snip examples]
Flash drives, like RAM, (technically, they are non-volatile RAM) always
come in binary units. The difference between the nominal and actual
capacity is space used for bookkeeping and replacement of faulty blocks.
Perhaps the manufacturer of your last example expects the flash chips
to be not very reliable. :-)
3:21 p.m.
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
4004
days inactive
4007
days old
34 comments
12 participants
participants (12)
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
drago01 -
Jaroslav Reznik -
John Reiser -
Matthew Miller -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Panu Matilainen -
Samuel Sieb