Everything boot x86_64 image https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20211210.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20211210.n.0.iso from compose Fedora-Rawhide-20211210.n.0 is 749731840 bytes, exceeding the maximum size 734003200. Canonical maximum sizes can be found at https://fedoraproject.org/wiki/Releases/36/Spins and https://fedoraproject.org/wiki/Releases/36/ReleaseBlocking . This check is run by the 'relval' tool, which has its own list of maximum sizes derived from those pages. If the maximum size used for this comparison is wrong, please add a comment and file a bug against relval at https://pagure.io/fedora-qa/relval/issues and it will be corrected. If you believe the canonical maximum size for an image should be changed, please follow the appropriate process before filing a relval bug.
Everything boot x86_64 image https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20211215.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20211215.n.0.iso from compose Fedora-Rawhide-20211215.n.0 is 749731840 bytes, exceeding the maximum size 734003200.
Everything boot x86_64 image https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20211229.n.1/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20211229.n.1.iso from compose Fedora-Rawhide-20211229.n.1 is 761266176 bytes, exceeding the maximum size 734003200.
Same as https://bugzilla.redhat.com/show_bug.cgi?id=2031214 . Should hopefully be improved in the next compose.
Yup, it's fixed now.
Everything boot x86_64 image https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220202.n.1/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20220202.n.1.iso from compose Fedora-Rawhide-20220202.n.1 is 783286272 bytes, exceeding the maximum size 734003200.
I love how this always happens after we don't have a compose for several days, just to make investigating it extra fun :( I'll try and figure out the cause tomorrow.
Oh, I see it. This is the RPM database move: https://bugzilla.redhat.com/show_bug.cgi?id=2042099 lorax does: remove /var/lib/rpm/* /var/lib/yum /var/lib/dnf so we should probably add /usr/lib/sysimage/rpm/* to that.
https://github.com/weldr/lorax/pull/1213
Everything boot x86_64 image https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220205.n.1/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20220205.n.1.iso from compose Fedora-Rawhide-20220205.n.1 is 736100352 bytes, exceeding the maximum size 734003200.
Gah, so there must be something else too. I'll try and figure it out on Monday.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
So I looked into this and found two major things: * The 'replace DejaVu with Noto fonts' change was applied to lorax as well, and included some fonts we probably don't really need in the installer. I've sent a PR: https://github.com/weldr/lorax/pull/1214 * webkit2gtk3 made gstreamer1-plugins-good and gstreamer1-plugins-bad-free into hard requirements[0][1] (they were recommended before). This pulled in those packages plus a ton of deps to the installer environment: gssdp, gupnp, lame-libs, libdvdnav, libdvdread, libnice, libshout, libsrtp, libv4l, libva, libvpx, mpg123-libs, speex, soundtouch, wavpack . AFAIK the installer needs webkit2gtk3 because yelp uses it, and the installer uses yelp to display its help...so in order to show the installer's help pages, we pull in MP3 encoding and DVD playback support (etc). This seems questionable. The dumb fix is to tweak lorax templates to kick all those packages we don't really need back out again, but it would be nice if this could be finessed somehow on webkit2gtk3 side, so CCing mcatanzaro. [0]: https://src.fedoraproject.org/rpms/webkit2gtk3/c/b2bf422ca3438763a55a3e9096ef4cc0b17adce5?branch=rawhide [1]: https://src.fedoraproject.org/rpms/webkit2gtk3/c/06cdc3e5730f00f46fbb41a519d91fc101f6ab26?branch=rawhide
(In reply to Adam Williamson from comment #12) > * webkit2gtk3 made gstreamer1-plugins-good and gstreamer1-plugins-bad-free > into hard requirements[0][1] (they were recommended before). This pulled in > those packages plus a ton of deps to the installer environment: gssdp, > gupnp, lame-libs, libdvdnav, libdvdread, libnice, libshout, libsrtp, libv4l, > libva, libvpx, mpg123-libs, speex, soundtouch, wavpack . AFAIK the installer > needs webkit2gtk3 because yelp uses it, and the installer uses yelp to > display its help...so in order to show the installer's help pages, we pull > in MP3 encoding and DVD playback support (etc). This seems questionable. The > dumb fix is to tweak lorax templates to kick all those packages we don't > really need back out again, but it would be nice if this could be finessed > somehow on webkit2gtk3 side, so CCing mcatanzaro. I don't think there's much room for finesse here. I wanted them to be Recommends and graceful failure to play media if not installed, but upstream has other plans and I've changed this per their recommendation. I appreciate that size limit chasing is useful to avoid huge increases in media size, but keeping the Everything image under 7.3 GB is probably not going to work.
I've asked in https://bugs.webkit.org/show_bug.cgi?id=233230#c22 to confirm one more time, just to be perfectly sure the Requires is definitely desired.
It's not about the Everything ISO size, it's about the Everything (and Server) *netinst* sizes, which are determined by the size of the installer environment. Those are targeted to less than 700M (i.e. CD size). Equally important with the media size, everything in the installer environment is loaded into memory at boot time, since there is nowhere else to load into. So space consumed by the installer environment directly equates to space taken up in RAM (and hence RAM required) during installation.
Note, I tested my fonts PR and it only saves just over 1M on the image size, so it looks like that won't be enough to get back under the limit. If we really can't change the webkit deps I'll have to patch lorax to rip them out.
After consulting further with upstream, we're going to switch the GStreamer deps back to Recommends. I will kick off a build.
Yeah, I saw, that's awesome, thanks a lot for engaging with them on that. I also got nerdsniped into poking around the installer environment for other savings, so I have a branch with a bunch of changes I'm working on that I'll send to Brian when I'm done. Hopefully that'll chop another few dozen megs.
So with https://github.com/weldr/lorax/pull/1216 and the new webkit2gtk3 build, marking as POST.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.