Description of problem:
Fedora-Live-Desktop-i686-19-Beta-TC1-1.iso : 1,003,487,232 bytes (1.003 GB)
Fedora-Live-Desktop-x86_64-19-Beta-TC1-1.iso : 1,038,090,240 bytes (1.038 GB)
As indicated at https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size and https://fedoraproject.org/wiki/Releases/19/Spins , the size limit is 1,000,000,000 bytes = 1 GB.
Version-Release number of selected component (if applicable):
19 Beta TC1
Automatic Blocker by https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers : "Any release-blocking Beta or Final TC/RC image exceeding its target size (failures of QA:Testcase_Mediakit_ISO_Size) "
Still oversized in 19 Beta TC2.
Fedora-Live-Desktop-i686-19-Beta-TC2-1.iso : 1,003,487,232 bytes (1.003 GB)
Fedora-Live-Desktop-x86_64-19-Beta-TC2-1.iso : 1,038,090,240 bytes (1.038 GB)
Still oversized in 19 Beta TC3.
Fedora-Live-Desktop-i686-19-Beta-TC3-1.iso : 1,003,487,232 bytes (1.003 GB)
Fedora-Live-Desktop-x86_64-19-Beta-TC3-1.iso : 1,039,138,816 bytes (1.039 GB)
Setting to MODIFIED - mclasen made a bunch of changes that he has tested to save 100+MB, so TC4 should come out comfortably undersize.
Still oversized in 19 Beta TC4.
Fedora-Live-Desktop-i686-19-Beta-TC4-1.iso : 1,000,341,504 bytes (1.0003 GB)
Fedora-Live-Desktop-x86_64-19-Beta-TC4-1.iso : 1,035,993,088 bytes (1.036 GB)
Notes on this one for TC5/RC1/whatever:
have all been suggested as builds which should improve things if they are pulled in.
So as a progress report, I did a build this morning which used everything from stable, plus the 3.8.2 mega-update and the following builds:
We should pull all those in to TC5/RC1 as applying to this bug, note. That build came out:
1004535808 May 14 11:49 20130514-desktop-x86_64.iso
so still just barely over size. Assuming an 'official' compose matches mine, we still need to find another 5MB.
here are a few more fat-trimming proposals:
One more proposal that would reduce the media size by 11.5 MB:
In 19 Beta RC1, 64-bit is oversized, but 32-bit is not.
Fedora-Live-Desktop-i686-19-Beta-1.iso : 970,981,376 bytes (0.971 GB)
Fedora-Live-Desktop-x86_64-19-Beta-1.iso : 1,006,632,960 bytes (1.007 GB)
Note to self: I missed https://admin.fedoraproject.org/updates/FEDORA-2013-8108/brltty-4.5-5.fc19 out of RC1, add it for RC2.
Fixed (barely) in 19 Beta RC2.
Fedora-Live-Desktop-i686-19-Beta-1.iso : 961,544,192 bytes (0.961 GB)
Fedora-Live-Desktop-x86_64-19-Beta-1.iso : 996,147,200 bytes (0.996 GB)
now don't nobody breathe on *anything*.
Re-opening as we need to push all the updates stable.
I'm pretty sure all relevant updates are now stable. As long as RC3 remains under-size, we can close this.
RC3 is still under-size. Closing.
64-bit is oversized in 19 Final TC1.
Fedora-Live-Desktop-i686-19-TC1-1.iso : 977,272,832 bytes (0.977 GB)
Fedora-Live-Desktop-x86_64-19-TC1-1.iso : 1,012,924,416 bytes (1.013 GB)
Added packages, compared to F19 Beta:
size | name
If it helps, re libreoffice-pyuno and libreoffice-emailmerge they were added via commit 35e5abb40d013d53021f8dfefab62251ed0a3637 in comps to make the mail-merge default installed from https://bugzilla.redhat.com/show_bug.cgi?id=967165
ok, I'll exclude those in the kickstart file. Will that also get rid of libmwaw ?
I guess we'll find out
64-bit is still oversized in 19 Final TC2.
Fedora-Live-Desktop-i686-19-TC2-1.iso : 978,321,408 bytes (0.978 GB)
Fedora-Live-Desktop-x86_64-19-TC2-1.iso : 1,011,875,840 bytes (1.012 GB)
it'll have no effect on libmwaw which remains linked to (provides a bunch of file format import support)
still too large :-(
64-bit is still oversized in 19 Final TC3.
Fedora-Live-Desktop-i686-19-TC3-1.iso : 986,710,016 bytes (0.987 GB)
Fedora-Live-Desktop-x86_64-19-TC3-1.iso : 1,020,264,448 bytes (1.02 GB)
64-bit is still oversized in 19 Final TC5. There were no Live TC4 images.
Fedora-Live-Desktop-i686-19-TC5-1.iso : 987,758,592 bytes (0.988 GB)
Fedora-Live-Desktop-x86_64-19-TC5-1.iso : 1,020,264,448 bytes (1.02 GB)
F19 Beta vs F19 Final TC5.
size | name
64-bit is still oversized in 19 Final TC6.
Fedora-Live-Desktop-i686-19-TC6-1.iso : 986,710,016 bytes (0.987 GB)
Fedora-Live-Desktop-x86_64-19-TC6-1.iso : 1,021,313,024 bytes (1.021 GB)
Matthias tried to drop brasero and nautilus-brasero yesterday in the kickstart, but TC6 still contains it. Created with a non-updated spin-kickstarts?
I think the prime candidate for removal is gnome-boxes. The audience is very limited - general users don't usually use virtualized systems, and the experienced users are likely use different tools anyway. And it's taking a lot of space. After blacklisting gnome-boxes, the x86_64 Live size is 994,050,048 bytes.
Actually I believe that brasero is (much) more useful for general audience than gnome-boxes, despite the decline of optical media.
"Created with a non-updated spin-kickstarts?"
Possible, I think Dennis said I have to specifically request the latest s-k if it's important; I should've checked and found that change, apologies.
"The audience is very limited - general users don't usually use virtualized systems, and the experienced users are likely use different tools anyway."
Well, I think part of the *aim* of Boxes is to try and address both of those things, and it's a bit hard for it to do that if it's not pre-installed.
(In reply to Kamil Páral from comment #31)
> Matthias tried to drop brasero and nautilus-brasero yesterday in the
> kickstart, but TC6 still contains it. Created with a non-updated
> I think the prime candidate for removal is gnome-boxes. The audience is very
> limited - general users don't usually use virtualized systems, and the
> experienced users are likely use different tools anyway. And it's taking a
> lot of space. After blacklisting gnome-boxes, the x86_64 Live size is
> 994,050,048 bytes.
> Actually I believe that brasero is (much) more useful for general audience
> than gnome-boxes, despite the decline of optical media.
I don't think it is worth dropping either to save a few MBs. We are not using CDs any more and finding a usb key that can hold more then one GB is easier than one that can't.
I don't understand all the fuss about the non issue (neither why this is a blocker).
So how about just closing it?
+1 for excluding Boxes from me, FWIW. Given a common installation target is VMs, even if nested virt worked, it's just not a good default. On live media also you really can't create local VMs and expect that to work. It's a post-install thing.
A lot of this, really is just due to lack of an application installer...
drago01: you can't just close it without doing anything else. The release-blocking images *must* meet their declared size targets. It is a release requirement.
You could change the size target for the desktop live, of course. We don't give out style points. ;) I don't know if there's a restriction about when you're allowed to do that on the 'spins' side, I am not totally familiar with that process.
no, dropping boxes is not an option.
mclasen submitted an update with a bunch of small fat trimmings to try and help with this, but forgot to link it here, so here it is:
I'm currently testing the impact of building with and without this update.
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.
One more possible cut, but I am unsure how safe it would be to take it at this point: https://bugzilla.redhat.com/show_bug.cgi?id=977119
996147200 Jun 24 12:22 20130624-desktop-x86_64.iso
that's with the same package set as my third build in c#39, but with spin-kickstarts d4edc3b5a610d0abb5c8c42e96af124bf3f4e70e . looks like we can stop cutting now and we don't need to take any updates beyond the big one in c#38. We *may* even be able to get away without taking that one and still sneak under 1GB. perhaps we should try that for the next build.
(In reply to Adam Williamson from comment #42)
> looks like we can stop cutting now and we don't need to take any updates beyond the big one in c#38. We *may* even be able to get away without taking that one and still sneak under 1GB. perhaps we should try that for the next build.
Or take all the doc-removal fixes we have so far (comment #38 and comment #41), and if that leaves enough free space, could maybe add back some of the apps that got cut out?
# These things are cut purely for space reasons
that's possible, I'll try and do some more tests before filing next compose request.
A build with slightly updated package set (for remaining FE/blocker issues) and the updated sane-backends actually comes out *bigger*:
997195776 Jun 24 13:41 20130624-desktop_b-x86_64.iso
may be to do with the updates, or just live compose process weirdness. That looks like our current state-of-the-art. I'm not sure 2.9MB is enough to fit anything back in, but I'll try.
1001390080 Jun 24 13:53 20130624-desktop_b-x86_64.iso <--- that's current everything, inc. c#38 and c#41, with deja-dup added back. so not quite enough room :(
Both images are with size limit in 19 Final RC1.
Fedora-Live-Desktop-i686-19-1.iso : 962,592,768 bytes (0.963 GB)
Fedora-Live-Desktop-x86_64-19-1.iso : 996,147,200 bytes (0.996 GB)
_Within_ size limit, I mean.
Great. To close this we need to push at least https://admin.fedoraproject.org/updates/FEDORA-2013-11471 and https://admin.fedoraproject.org/updates/sane-backends-1.0.23-10.fc19 stable (they are in Final RC1 so must be pushed stable for consistency), I'll have to check if there was anything we put in an earlier TC that needs pushing.
(In reply to Kalev Lember from comment #43)
> # These things are cut purely for space reasons
This has caused bug 977764.
For the record, I'm waiting till we have a spin-kickstarts package build to close all these bugs fixed in spin-kickstarts; seems like a good way to make sure we get a spin-kickstarts build for final.
the two package updates have been pushed stable now, so just waiting on the s-k build.
spin-kickstarts-0.19.7-1.fc19 has been submitted as an update for Fedora 19.
This may be a litte late to the party, and not a whole lot of savings either, but I cut out the docs from babel...
Thanks, this will definitely help F20.
spin-kickstarts-0.19.8-1.fc19 has been submitted as an update for Fedora 19.
spin-kickstarts-0.19.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.