[adamw@adam spin-kickstarts (master %)]$ curl -sI https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_RC1/Images/armhfp/Fedora-Mate-armhfp-21_Alpha-1-sda.raw.xz | grep Length Content-Length: 1034011688 https://fedoraproject.org/wiki/Releases/21/Spins lists the target size as 1GB, so it is over. I note that the MATE live kickstart and package kickstart seem to have gone basically unmaintained for a year - I don't know what happened to vicodan (the maintainer). The live images were not built for RC1, perhaps because of this lack of maintenance, but the ARM disk image was generated... This isn't a release blocking image. Nominating as freeze exception just in case there's a very simple fix we can take for an RC2 if one happens.
AFAIK there is no size limit on arm images,
welp, they're listed on the Spins page which is the reference, and it's a primary arch. We can discuss appropriate limits, of course, but there's gotta be something.
(In reply to Adam Williamson (Red Hat) from comment #0) > I note that the MATE live kickstart and package kickstart seem to have gone > basically unmaintained for a year - I don't know what happened to vicodan > (the maintainer). The live images were not built for RC1, perhaps because of > this lack of maintenance, but the ARM disk image was generated... The MATE live images seem to be building nightly at least and seem to work fine (I just downloaded and tried Fedora-Live-MATE_Compiz-x86_64-21_Alpha-3.iso). Is there a reason they are not included? I think it is good to include them.
I added raveit65 not too long ago to work on the mate spin. He has made some commits... The spin wasn't composing in the late TC's and RC1 due to some changes with kickstart naming. rdieter fixed that so they are composing now. We didn't have images for RC1 however (which is what we shipped).
Is the oversize issue in arm iso still exists? I'm still wondering a bit because x86_64 iso has 914MB. Is there a different kickstart file for arm arch? And whwere is it in git repo?
I see on todays f21: Length: 1033240248 (985M) [application/x-xz] So, I think it's under now? Anyhow, this kickstart is also in spin-kickstarts repo. It's the fedora-arm-mate.ks one that includes the packages in fedora-mate-packages.ks like the main live media does.
Ok, if more adjustments is needed we can drop the compiz stuff from arm image. I'm not really happy about that compiz is in arm image because i don't have arm hardware to test my compiz packages, and compiz needs to be tested on bare metal, and i don't like blind maintaining. In my opinion compiz is in extra package which isn't needed for a standard Installation and fans of it can install it later.
(In reply to Wolfgang Ulbrich from comment #7) > In my opinion compiz is in extra package which isn't needed for a standard > Installation and fans of it can install it later. +1
there is little to no point in removing the packages, they will barely make a difference in the compressed size. the size limit here is a bogus check that should not be done. the Mate arm disk image needs an 8gb or bigger sd card or usb stick. the image is an installed os, that when you boot you run final configuration on via initial-setup on first boot. the critical things here are that there is a 512Mb /boot 512Mb swap then 5000Mb / the partitions needs at least 6Gb of space we then xz compress the disk image and ship that. unlike isos where we want them to be under a size limit to enable them to be burnt onto a CD or DVD where we have a size limit we must be under for the iso the disk images have very different targets and what is critical is the size of the compressed disk image. the Mate Image is just way too big to fit on 4Gb media. Now we should make it clearer what sizeMedia is needed for each disk image.
It's not a bogus check. If the opinion you suggest is shared by the maintainer of the spin, then it's a perfectly valid check being run against a "bogus" *value*. The maximum size of an image is chosen by various people depending on what type the image is, but never by QA. We just check the size of actual images against the size that is defined by policy as being the maximum size of the image. If the MATE spin owner thinks 1GB is no longer the appropriate maximum size for the spin, then they should change it. The Spins process, like much of Fedora that I didn't wave my Process Bureaucracy wand at yet :), is under-documented, but the above is how it's always been considered to work, as I understand it. The Spin review checklist: https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist has a sort of implicit requirement that all spins be under 4.0GB (motivated by the FAT32 filesystem limitation), but that looks like it's pretty old.
(In reply to Adam Williamson (Red Hat) from comment #10) > It's not a bogus check. If the opinion you suggest is shared by the > maintainer of the spin, then it's a perfectly valid check being run against > a "bogus" *value*. > > The maximum size of an image is chosen by various people depending on what > type the image is, but never by QA. We just check the size of actual images > against the size that is defined by policy as being the maximum size of the > image. If the MATE spin owner thinks 1GB is no longer the appropriate > maximum size for the spin, then they should change it. If you mean Dan Marchal as owner, he is missed in a big country called USA. If you mean me as the person who did all the work for mate in fedora, where can i change the limit? IMO using installer images policys for disk images it's a bit weird, it doesn't reflect a technical base. Last but not least: [root@mother rave]# curl -sI https://kojipkgs.fedoraproject.org//work/tasks/8358/7708358/Fedora-Mate-armhfp-21-20140927-sda.raw.xz | grep Length Content-Length: 1033240248 1033240248 bytes = 985.37469 MB = 0.96228 GB So the shipping size is fixed and this bug can be closed.
As I said, the process is under-documented. The number we actually compare against is the number in the table at https://fedoraproject.org/wiki/Releases/21/Spins . Given that I can't for the life of me find any kind of documentation of the process for setting or changing that number, I'd say you should just edit it to whatever you think it ought to be, with an edit summary explaining that you're the new de facto owner of the spin and you're asserting your right to change it, with a link back to this bug report. If anyone kicks, then hey, we can write a proper process! "IMO using installer images policys for disk images it's a bit weird, it doesn't reflect a technical base." Well, I was making it up as I went along to some extent, as we've only been shipping the disk images for a couple of releases. It seemed reasonable to assume they should have *some* kind of maximum size. I tend to figure that any target size which is not tied to an optical medium - CD, DVD - is considered to be the size of USB stick the image owner wants the image to fit on, and it seemed reasonable to assume that number would be the same for a 'disk image' version of the spin as for a 'live image' version (if you want 'Fedora MATE live' images to fit on 1GB USB sticks, presumably you also want 'Fedora MATE disk' images to fit on 1GB USB sticks). See, this is why I like properly defined, thought through, and documented processes...=)
note that page distinguishes between 'iB' to denote power-of-two numbers and 'B' to denote power-of-ten numbers. The column for MATE lists '1GB', not '1GiB', and therefore the limit is taken to be 1,000,000,000 bytes, not 1,073,741,824 bytes (1GiB). You could, of course, amend it from the former to the latter, though we kind of have a convention of using power-of-ten bytes for sizes intended to map to USB stick capacities.
Note also that that page doesn't distinguish between arm and not arm, which makes it pretty useless for this unless we add a arm col. ;) ie, the Xfce spin is targeting a 700MB CD image for the live media... but the arm image is under the same contraints Dennis already mentioned and should be 8GB or whatever.
I wouldn't add a new column, but just add a note in the size column. This stuff is all checked by hand and a note should work.
I edited the wiki page and mentioned that arm arch needs < 1.5 GB for shipping image. Hope that's is Ok to make everybody in this round happy :) , and we can close this report.
This should have been closed ages ago. Arm needs to be installed onto at least 8gb media. Well you could use a bit smaller if it existed. The critical thing for arm images is the filesystem sizes defined in the kickstart, not the size of the compressed disk image.