Re: Fedora 19 Final blocker status: fix and karma requests
On 06/24/2013 03:27 AM, Bruno Wolff III wrote: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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 - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
- 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.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
- 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.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham nott...@redhat.com wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 09:15 -0400, Bill Nottingham wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, Jun 24, 2013 at 12:53:14 +0300, Panu Matilainen pmati...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 15:21 +0200, drago01 wrote: On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham nott...@redhat.com wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 100 (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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 1:51 AM, Michael Catanzaro mike.catanz...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 6:54 AM, Adam Williamson awill...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 5:20 PM, Matthew Miller mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 4:24 PM, Adam Williamson awill...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, 2013-06-23 at 19:22 +0200, drago01 wrote: On Sun, Jun 23, 2013 at 4:24 PM, Adam Williamson awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 size2671M translations 402M input methods 133M fonts 89M rpm db 82M firmware59M 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 20:17:23 -0400, Matthew Miller mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 mat...@mattdm.org http://mattdm.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
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.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 19 Final blocker status: fix and karma requests
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.1-3.fc19,gnome-mines-3.8.1-2.fc19,gnome-sudoku-3.8.1-2.fc19 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
