Matthew Burgess wrote: > Bryan, the fix looks sane and simple enough, but I'm not sure what > the process is for generating a tarball from our bootscripts in SVN.
Actually, I'm not completely sure either. ;-) > Is it just a case of tarring up an `svn export' of the > lfs-bootscripts repo? It should be, but there may have been other steps. There used to be a render script on belgarath (/usr/bin/render-lfs-book-dev.sh) which also had some (commented-out) code in it to set up both udev-config and the bootscripts tarballs. But that script looks like it's gone from quantum (even though it's still trying to run from fcron?). Anyway, I used to refer to that script to know what to do when releasing a new udev-config, but I never really looked at the bootscripts portion of it all that closely. I suspect it was close to the same process for them. Looking at my shell history, it looks like when I made a udev-config tarball, I did an svn export, then renamed the directory to have the datestamp in its name, then tar/bzip2ed it, then grabbed an md5sum and updated the filename/md5sum in the book. Then, I scp'ed it to belg, did a "chgrp wwwdownloads", and moved it to the downloads.lfs.org vhost directory. Hopefully that's sufficient for the bootscripts. Actually I should have updated the bootscripts quite a while ago; recent udev versions require a different udev_retry script. The script is correct in the bootscripts SVN repo, but not in the book. If you want to update the bootscripts Makefile and regenerate the tarball, go ahead, otherwise I can.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
