https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Image_size_requirements

"The release-blocking images must meet current size requirements."

we have never enforced any size limit on ARM disk images.

For the KDE image, we will be discussing this for Beta, but most likely we will just increase the size target. (There have already been talks of lifting the 1 GB limit.) There has also always been some discussion on whether we are actually trying to target 1 GB = 1000000000 bytes or 1 GiB = 1073741824 bytes (the latter not being currently exceeded), but we are likely going to increase the target to something higher than either.

I am personally very unhappy about the constant size increases, but with the coexistence of Qt 4 / kdelibs 4 and Qt 5 / KDE Frameworks 5 coming, and with the "KDE 5" stuff (KDE Frameworks 5, Plasma 5 and the applications that go with it) dropping the separate kde-l10n-* langpacks (and shipping all the translations directly), a size increase of the KDE image will be unavoidable anyway.

(In reply to Kevin Kofler from comment #3)
> For the KDE image, we will be discussing this for Beta, but most likely we
> will just increase the size target. (There have already been talks of
> lifting the 1 GB limit.) There has also always been some discussion on
> whether we are actually trying to target 1 GB = 1000000000 bytes or 1 GiB =
> 1073741824 bytes (the latter not being currently exceeded), but we are
> likely going to increase the target to something higher than either.

The capacity of thumb drives is measured in powers of 10, so a "1 GB" thumb drive actually is 1,000,000,000 bytes, and AFAIK there is no physical media or file system size limit corresponding to 1 GiB, so no reason to target it. There is the FAT file size limit which is 4 GiB - 1 byte, so that would be a reasonable limit (in fact at least one of the spins use that). Optical media is in powers of 10 with the exception of CDs which are 700 MiB.

andre: I think in the real world it tends to be more variable. A USB stick sold as '1GB' is fairly unlikely to have a usable size of *precisely* 1,000,000,000 bytes, it's not that strict. sizes not tied to standards-defined media like CDs and DVDs tend to be fairly notional.

for e.g., I just plugged in various USB sticks I have lying around:

"4GB" -> [sdc] 8060928 512-byte logical blocks: (4.12 GB/3.84 GiB)
"16GB" -> [sdc] 30514176 512-byte logical blocks: (15.6 GB/14.5 GiB)
"8GB" -> [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
"2GB" -> [sdc] 4014080 512-byte logical blocks: (2.05 GB/1.91 GiB)
"2GB" -> [sdc] 4102144 512-byte logical blocks: (2.10 GB/1.95 GiB)
"4GB" -> [sdc] 7831552 512-byte logical blocks: (4.00 GB/3.73 GiB)

For that last one, 7831552*512 = 4009754624

So yeah, the capacity of USB sticks is kind of notional; if we were really concerned to fit on USB sticks of a particular labelled size, I'd probably set the max image size as say 50MB smaller than that size in power-of-ten units, though in practice most sticks are slightly larger than their advertised size in power-of-ten (based on my highly scientific 'stuff I have in my USB stick drawer' sample, and also other observations I've made).

I have 5 thumb drives (2 GB, 8 GB, 16 GB, 32 GB, 32 GB) and only the 16 GB is slightly under its advertised size, but it's a cheap brand (the others are Kingstons), and since it was undersize, I would have been within my rights to return it as defective. Since both 1 GB and 2 GB thumb drives are ridiculously cheap today, I'm guessing those size targets are at least partly intended for media that are handed out for free at large events, so they would be bought in bulk, and if they were undersize, you would definitely return them for a refund or replacement.

TL;DR - The manufacturer is accountable for the advertised size, so if you're motivated, you can hold them to it. I didn't care enough with my 16 GB drive, since I only had one and didn't need the full capacity.

There's one physical size limit that we are considering targeting: MiniDVD, which is somewhere around 1.4 GB (some sources say 1.4, some 1.46, both in decimal GB, not in GiB). I don't know for sure whether there's an exact byte size for PC MiniDVDs, but according to one source I found, Gamecube games are 1459978240-byte ISOs and are supposed to be burnable to a MiniDVD, so those MiniDVDs that work for Gamecube games should have at least that capacity (which is slightly less than either 1.46 GB or 1.36 GiB). Whether there are Mini-DVD-Rs that can only carry something like 1400000000 bytes, I don't know for sure.

https://en.wikipedia.org/wiki/MiniDVD#MiniDVD_capacities shows 8 different sizes depending on 8 cm vs. 12 cm, single vs. double sided, or single vs. double layer capacity. All of those appear to be decimal sizes, as expected. Table copied below.

Physical size 	Single layer capacity 	Dual/Double layer capacity
12 cm, single sided 	4.7 GB 	8.5 GB
12 cm, double sided 	9.4 GB 	17 GB
8 cm, single sided 	1.4 GB 	2.66 GB
8 cm, double sided 	2.8 GB 	5.2 GB

I have seen that, but that is not a size in bytes, but something that could be rounded.

I found one source of the size increase: The default Chinese fonts changed:
https://git.fedorahosted.org/cgit/comps.git/commit/?id=1219571b4ba89f15b6df0bdaf7eebb9eaaad269d
so the CJK font blacklist we have is no longer current. (We have only shipped wqy-microhei-fonts as the only CJK font for a while, for space reasons.) I'm updating the kickstart.

(In reply to Kevin Kofler from comment #9)
> I have seen that, but that is not a size in bytes, but something that could
> be rounded.

Whatever the size is that's printed on the box or the disc, that corresponds to a precise guarantee (i.e. 2.66 GB means the manufacturer is promising at least 2,660,000,000 bytes). The current optical media byte size limits at https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size are set the same way - they correspond to what's printed on the media (except for 700 MiB CDs, which are advertised as "700 MB", probably because saying "MiB" would confuse people). Interestingly, on the image shown at the top right of the wikipedia page, the smaller 8cm disc has printed on it a size of 1.46 GB which is not in the table, so the table is apparently not complete.

I guess the conservative target is just going to be 1400000000 bytes. With my latest spin-kickstarts commit, we might be below 1000000000 bytes again, several huge CJK fonts had snuck in, I updated the blacklist now. But we are likely going to increase the target for Beta anyway (and at that point the font blacklist might also go away entirely).

1400000000 sounds like a good compromise, at least for now. It can always be reconsidered later.

Updating for Beta TC1. We agree that it does not make sense to check the compressed size of ARM disk images. The x86_64 live for Beta TC1 is under the current limit, but i686 live is over:

[adamw@adam relval (master *%)]$ curl -sI https://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC1/Live/i386/Fedora-Live-KDE-i686-21_Beta-TC1.iso
Content-Length: 1054867456

Discussed at 2014-10-01 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-01/f21-blocker-review.2014-10-01-15.58.log.txt . This is fairly clearly a blocker per the criteria, but as there's an expectation that the target size may change, we decided to delay the decision for a week and revisit next week, when the target size may have changed and/or a smaller TC2 may have arrived.

It was agreed at today's KDE SIG meeting to increase the size limit from 1 GB (1 000 000 000 bytes) to 1.4 GB (1 400 000 000 bytes). Therefore, the images are not oversized anymore.