--KuLpqunXa7jZSBt+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 23, 2004 at 03:50:37PM -0500, John Klos wrote:
> Hi,
>=20
> > > Yes, the fact that releng's last snapshot was more than a month ago i=
sn't
> > > very helpful...
> >
> > I asked about this. The problem is that 1) current has grown, so a full
> > build takes a while, and 2) the 1.6.2 release cycle is in process. The
> > current builds greatly slow down the 1.6.2 builds, so they have been
> > suspended.
>=20
> I'm not sure I understand that. How many pullups are being done? Once the
> pullups are done, building a new set of release snapshots should only take
> a few hours. So why would the releng machines be tied up for all of
> January? Just curious...

Since I'm not one of their keepers, I can't really say. I can however=20
guess.

I think all the builds are full builds, not update builds, to make sure we=
=20
don't have any stale binary issues. I was informed that compiling 1.6.2=20
when -current builds are in process takes 3 days. So for a 1.6.2 build to=
=20
complete in a timely manner, there needs to be no current builds taking=20
place. Our current autobuild system is not, as I understand it, graced=20
with the concept of pausing a running build. So it's not readily easy to=20
stop a -current build so that a 1.6.2 build can proceed. Thus I believe=20
the autobuild maintainers decided to just turn off -current builds. They=20
can be started manually.

Also, the project is in the process of getting more autobuild systems set=
=20
up, so that this issue hopefully won't be present in the future.

> > I asked, and a current build was kicked off manually. Also, I checked, =
and
> > Darrin had fixed the bug that killed the last build. And today's -curre=
nt
> > GENERIC compiled for me just now too.
>=20
> Ok. I've built and booted a custom kernel using build.sh under 1.6.2, but
> the kernel was around 4 megs. Are you saying that the new ofwboot.xcf will
> boot larger kernels without any changes or any problems? That's great, but
> it might be useful to document that somewhere; I looked through the
> mailing list quite a bit, but never saw that discussed.
>=20
> So, if I get this right, we fetch and install a new ofwboot.xcf, then
> don't worry about the size of current kernels?

Yes. Well, we don't worry for a while. The change moves ofwboot.xcf's load=
=20
to E00000 or so (as I recall). Thus all the space from 100000 (where the=20
kernel starts) to E00000 will be open. Thus we should handle kernels up to=
=20
13 MB.

Take care,

Bill

--KuLpqunXa7jZSBt+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAEZpMWz+3JHUci9cRAnlrAJ4u5HbrFQ5EDn8trZOCb/6HvaC78ACeJxGm
ByocgZ36Rr1ZxCDoVhnj3bk=
=M/h8
-----END PGP SIGNATURE-----

--KuLpqunXa7jZSBt+--