Re: Official test-cycle-1 images!
Attila Nagy <bra@iif.hu> writes:
> Hello,
>
> > > Where is the potato-m68k-1.raw?
> > It currently fails to build because of a difference between what the
> > bootable scripts expect and what is actually in, the m68k boot-floppies.
> Argh. I see. It is an autobuild... :)
> That's why I make all the CDs by "hand".
No it's not, but at this point I'd been sodding about with debian-cd
for about 20 of the 40+ hours that I'd been awake, and I don't see how
it's my responsibility to fix this, when I have no worthwhile ability
to test the non-intel images.
I'm certainly not going to do hand crafted CDs for each architecture.
Admittedly, I should have noticed the lack of a CD#1 for m68k, but my
response would probably have been to point out that debian-cd or the
archive should be fixed (perhaps with a patch -- hint, hint)
If someone wants to appoint themselves guardian for each of the
non-intel architectures, and either keep me informed of what's wrong
with each architecture, and tell me things like the fact that a
particular set of CDs is shite, and should be regenerated, go ahead.
I have no ability to test these non-intel CDs in any useful manner, so
see little point in even doing the loop mount test, since that does
not prove they work, it just does a very partial test for thing that
might make it fail.
If we can make this happen more rapidly by the architecture guardian
being able to make their own CD images, by them having an account on
open (aka cdimage.d.o), then that's fine with me.
The reason that I bothered to put that sort of effort in on the i386
images was that I had a deadline for the images to make glass masters,
because we're pressing 700 copies for the London Linux Expo2000 next
month. Hence the need to make sure that not only were they produced,
but that they were mostly valid, and that you could boot them, and do
an install. This made the test cycle a bit over two hours long, since
I have to rsync them over a 64k line before I can get my hands on
them.
The fact is that I started the non-intel run and went to bed, and have
not had time to do much more than glance at them since. So if the
architecture you care about is currently broken, fix it, tell me about
it, and we'll have some test CDs for you soon after.
We must have the official CDs built by the latest debian-cd scripts,
because otherwise you're relying on me to remember all the tweaks I
did last time. (I've got to write up the tweaks that I did do so they
can be folded back into debian-cd --- should have time this morning)
> > This is really sad. Weren't the build logs checked before these were
> > put on the site and marked "Official"?! Did you even mount the images
> > via loopback to make sure they all mounted? Were there no integrity
> > checks on this?
> In addition I must ask does 684896256 bytes fit on a normal CD?
You're right, that is too big for a normal CD.
Given that debian-cd (or one of its support scripts) actually says
something about the size used for the base system on the first CD,
would it not be possible to take that number away from 650MB to find
the SIZELIMIT1 value on the fly?
We could do with keeping the i386 size pretty close to the limit, for
the International CDs at least, because otherwise gnupg gets left off
CD#1.
Cheers, Phil.
P.S. This is a lot calmer than my first response to the pathetic
whinging that's been going on here. Building CD images is not a
trivial task, because it is prone to being tripped up by the tiniest
things, and the test cycle is long, so it normally involves skipping a
lot of sleep. Sleep deprivation is a great way to make me irritable.
If those complaints were in fact people volunteering to take
responsibility for making the images for their architecture, then
great, mail me and we'll sort something out. Otherwise, if you cannot
say something constructive, I suggest you keep quiet around me,
especially after painful CD build runs.
Reply to: