Moving to a core KDE component to get the right eyes on this bug. (Presumably a spin-kickstarts issue, or a rogue dep on something large.)

Andre - do you have the spin compose logs?

(In reply to comment #1)
> Moving to a core KDE component to get the right eyes on this bug. (Presumably a
> spin-kickstarts issue, or a rogue dep on something large.)
> 
> Andre - do you have the spin compose logs?

I'm just a tester. I'm not involved with the compose at all.

OK, I think we were aware that the kde live image was going to be *very* close to the size limit.  I thought previous daily images did fit at one time, but as usual, stuff keeps growing bit by bit over time.

So the consensus in the KDE SIG is that the actual threshold should be the maximum size of a "700 MB" CD, which is 703 MiB, rather than exactly 700 MiB.

However, here, we're at 704 MiB, which is bad.

For the alpha, being oversized by less than a MiB (the exact size limit is slightly above 703 MiB) should not be critical (overburn exists) and it infringes only Beta criteria, but we need to solve this one way or the other by Beta.

But while we are at it, please set the limit to 703 MiB rather than 700.

In setting the size test at 700 MiB I argued that the difference between the advertised size and the actual size for optical media, in addition to being somewhat dependent on the exact type of media (for example R vs. RW), is less than half a percent. In addition, users aware of the advertised size who see an image larger than that may be confused and think it won't fit. So I think it would be better to stick to the advertised size (700 MiB for CDs - with the understanding that that's what the label actually means, 4.7 GB for DVDs, and 8.5 GB for Blu-ray).

For an example of what can happen when this isn't done, see the recent experience with CentOS 6.2 where they were willing to split the x86_64 DVD, but decided not to split the i386 DVD even though it went slightly over the advertised size of 4.7 GB. This requires using a specific type of DVD, since the actual maximum depends on that. Someone not reading the release notes and using a different type gets a coaster.

koji.fedoraproject.org/koji/tasks?state=all&owner=ausil&view=flat&method=createLiveCD&order=-id is where logs may be found.

Sorry, it was CentOS 6.0, not 6.2. For example see https://www.centos.org/modules/newbb/viewtopic.php?topic_id=32287 . It appears that for 6.1 and 6.2 they're splitting the i386 DVD.

> In setting the size test at 700 MiB I argued that the difference between the
> advertised size and the actual size for optical media, in addition to being
> somewhat dependent on the exact type of media (for example R vs. RW),

That is not true. The CD-R and CD-RW standards require the same minimum capacity of 360000 sectors, i.e. 737280000000 bytes, i.e. ~703⅛ MiB.

> is less than half a percent.

That half percent can make the difference between fitting and not fitting, so we care a lot about that half percent and are not willing to remove anything from our spin if we are in the 700-703 MiB range. (I put this up in a KDE SIG meeting and we all agreed that the limit should be the maximum CD size (737280000000 bytes) for our spin.)

As for users of larger than CD media (e.g. persistent USB stick), exactly the fact that it's only half a percent means that going with the larger limit should not make any practical difference for them.

> In addition, users aware of the advertised size who see an image larger than
> that may be confused and think it won't fit.

Then we need to educate our users. IIRC, we already shipped KDE images in the 700-703 MiB range in the past and it has never been an issue.

> For an example of what can happen when this isn't done, see the recent
> experience with CentOS [6.0] where they were willing to split the x86_64 DVD,
> but decided not to split the i386 DVD even though it went slightly over the
> advertised size of 4.7 GB. This requires using a specific type of DVD, since
> the actual maximum depends on that. Someone not reading the release notes and
> using a different type gets a coaster.

That is true for DVDs where there are different competing standards: DVD-R and DVD+R have a different maximum size, so you have to pick the smaller one as your maximum. "700 MB" CDs have a single well-established minimal maximum size required by the standards. (And FWIW, the actual maximum of physical media tends to be higher, e.g. I've once successfully burned a 712 MiB Alpha release of Fedora KDE on a "700 MB" CD-R. But burning software will start whining if you exceed the 360000 sector limit.)

As for where that number comes from: the media also advertises an audio recording time of 80 minutes, and a minute of Red Book audio requires exactly 75×60=4500 sectors, thus the media needs to carry at least 4500×80=360000 sectors to work as advertised.

So, looking at the logs, TC2 still had the old verne artwork on it, as did the latest successful nightly (the 20120211 compose failed due to xorg-x11 dependency issues), so the next compose might actually turn out either larger or smaller.

(In reply to comment #9)
> > In setting the size test at 700 MiB I argued that the difference between the
> > advertised size and the actual size for optical media, in addition to being
> > somewhat dependent on the exact type of media (for example R vs. RW),
> 
> That is not true. The CD-R and CD-RW standards require the same minimum
> capacity of 360000 sectors, i.e. 737280000000 bytes, i.e. ~703⅛ MiB.

See for example http://lists.fedoraproject.org/pipermail/test/2010-April/089943.html .

BTW, for 8.5 GB I should have said "dual-layer DVD", not "Blu-ray" - sorry about that.

The test list post says "One might think a disc_image.iso file no larger than 737280000 bytes is OK, but there are other format requirements that reduce the effective capacity of a 737280000 byte CD to 736970752 bytes
(reported by the wodim command).  Still, that is about 702.83 MB." He doesn't mention what the "other format requirements" are. http://www.berklix.com/~jhs/txt/cdroms.html lists capacities for specific brands. Most but not all for "700 MB" are 736970752 bytes, one is slightly smaller, 736968704 bytes.

FWIW, the latest nightly (still with Verne theming, we need to update kde-settings to pick up the new theming!) is now 706 MiB, so even more oversized. :-(

F17 Alpha RC2 is now well below 700 MiB. We dropped Amarok (and readded Krusader in the freed room, it is much smaller).