[WBEL-devel] x86_64 images (ready, but not uploaded)

[John Morris]

On Wed, 17 Dec 2003, Pasi Pirhonen wrote:

> it's quiet out there? Are everyone waiting 'The Final Release'?

Probably.  The bits are out there!

> Anyway. I have built few images for x86_64 testing. Last night i
> installed 'whitebox enterprise linux' to my dual-opteron box and just
> recompiled the stuff once again. Today i've made ISO-images, but i have
> only crappy 384kbit/s uplink, so i'd need some space (3.2GB to be more
> exact).

Sounds like it is ready for a wider release.  If you would like I can drop 
a copy on whiteboxlinux.org so the mirror network can grab it.

Guess now is as good a time as any to work out the rules on ports.  Fair 
warning though, AMD64 is probably a platform I'll eventually adopt myself 
and start building inhouse.  But unless Intel or someone tosses me a 
MB/CPU I probably will never get around to Itanic.  Same for PPC/s390/etc.

So how about this as a rough first cut on requirements to submit a port 
and have it have equal status with i386:

1.  Must be complete, same packages as the equivelent RHEL port.

2.  Built from the same SRPMS as WBEL. (except for platform dependent
packages.)  Any changes required should be submitted back and merged.

3.  A commitment to get errata recompiled and submitted for inclusion into 
the mirror network within 48-72 hours of the errata notice appearing.

4.  Because of #2 above, all of the SRPMS can be signed by me, but you 
should generate your own signing key.  Name it GPG-RPM-KEY-whitebox-<port> 
on the root dir of the CD and in the up2date package.  For now just 
document it in the RELEASE-NOTES that it should be manually imported.  
Need a better solution.

> I've done few NFS-instalations by burning the boot.iso on CD-RW-disc.
> Burning now whole disc1 to see if that is really working ok.

Ok, one last minute gotcha that I haven't documented on the webpage yet
that you might not have caught then.  Make sure you edit .discinfo in the
main repository and snip the timestamp to two digits after you run
buildinstall.  Because splittree truncates to two digits in the individual
disc trees and if the longer stamp gets into the comps file
redhat-config-packages will reject the CDs as not being the right set of
discs.  That was the last showstopper bug that had me going till yesterday 
evening.

> PS. ia64 is building itself same way all the time. It's just that damn
> slow box :) Last night whitebox install and now recompile, making
> images, few test-installations and that is done too.

See why I care not for Itanic?  :)

-- 
John M.      http://www.beau.org/~jmorris        This post is 100% M$ Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r