Re: Wrong MD5SUM values in LFS-6.3
Bryan Kadzban wrote: > I'd say yes, do a stealth update. (For reference: Make the bootscript > and udev-config tarballs extract into a -6.3 directory, and rename the > files themselves if they aren't already, get the new md5sums, fix > packages.ent, and re-render the book to the website. Or let the render > happen automatically, either way.) > If any changes are needed to the ftp repo files, ping me after it is fixed and I'll update that also. Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Bruce Dubbs wrote: > I could do a "stealth" update to 6.3. That is, update what is on > the web site without announcements or file name changes. > > I don't know if that we should do that, but if so, it should be soon. I'd say yes, do a stealth update. (For reference: Make the bootscript and udev-config tarballs extract into a -6.3 directory, and rename the files themselves if they aren't already, get the new md5sums, fix packages.ent, and re-render the book to the website. Or let the render happen automatically, either way.) I'm not sure how jhalfs gets the book sources to extract the md5sums, but we may also have to re-tag /branches/6.3/ in SVN before it'll work right. I think that'd fix everything, right? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1iLtS5vET1Wea5wRAwVvAKC/fs66v5XYxXuB3luIG7+59v8lxgCfbhXe Lc5UD8TnDjcIcSX1RjZGHD0= =MPN8 -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
Bryan Kadzban wrote: > Dan Nicholson wrote: >> On 8/29/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: >>> In the future, I'll need to figure out how to copy the proper >>> config files from the development bz2 files instead of regenerating >>> them. >> I've thought about this a bunch of times, but I can't really think of >> an ideal way to make this automated. > > Automated, no, but this works for me when I update the book to a new > bootscript or udev-config version: > > 1) Export udev-config trunk to a dated directory (in the case of a > release book, it'd be a versioned directory). Tar up this directory. > > 2) Upload the tarball to the downloads area, and get its md5sum. > > 3) Update packages.ent: bump the datestamp and fix the md5sum. > > The critical part is to know that the md5sum will change whenever the > datestamp (or version number) changes, as we just found out. (Seems > kinda obvious in retrospect, but I'm guessing it was the last thing on > Bruce's mind at the time. It didn't help that we didn't document any > requirement for this kind of thing anywhere that I remember.) > > But I think versioning all the releases is a good idea. I.e., instead > of date-stamped versions, call the next tarball of udev-config something > like udev-config-7.0-01.tar.bz2 or something. (Where the 7.0 matches > the intended target book version, and the -01 is a sequential "release" > number for udev-config.) The final 7.0 book could then use the most > recent "release" number: udev-config-7.0-42.tar.bz2, or whatever we're > up to by that point. (Making it use udev-config-7.0.tar.bz2 would cause > this issue again when we release the 7.0 book. So just make it use the > highest "release" number instead.) > > The only problem I see with that might be if we had to do a release for > a book version 6.3.1 or something. (Like if we wanted to collect all > the known errata and run a new stable book or whatever.) But AFAIK we > haven't done a lot of that type of release; none since 6.1.1. I could do a "stealth" update to 6.3. That is, update what is on the web site without announcements or file name changes. I don't know if that we should do that, but if so, it should be soon. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dan Nicholson wrote: > On 8/29/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: >> In the future, I'll need to figure out how to copy the proper >> config files from the development bz2 files instead of regenerating >> them. > > I've thought about this a bunch of times, but I can't really think of > an ideal way to make this automated. Automated, no, but this works for me when I update the book to a new bootscript or udev-config version: 1) Export udev-config trunk to a dated directory (in the case of a release book, it'd be a versioned directory). Tar up this directory. 2) Upload the tarball to the downloads area, and get its md5sum. 3) Update packages.ent: bump the datestamp and fix the md5sum. The critical part is to know that the md5sum will change whenever the datestamp (or version number) changes, as we just found out. (Seems kinda obvious in retrospect, but I'm guessing it was the last thing on Bruce's mind at the time. It didn't help that we didn't document any requirement for this kind of thing anywhere that I remember.) But I think versioning all the releases is a good idea. I.e., instead of date-stamped versions, call the next tarball of udev-config something like udev-config-7.0-01.tar.bz2 or something. (Where the 7.0 matches the intended target book version, and the -01 is a sequential "release" number for udev-config.) The final 7.0 book could then use the most recent "release" number: udev-config-7.0-42.tar.bz2, or whatever we're up to by that point. (Making it use udev-config-7.0.tar.bz2 would cause this issue again when we release the 7.0 book. So just make it use the highest "release" number instead.) The only problem I see with that might be if we had to do a release for a book version 6.3.1 or something. (Like if we wanted to collect all the known errata and run a new stable book or whatever.) But AFAIK we haven't done a lot of that type of release; none since 6.1.1. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1eypS5vET1Wea5wRAwmKAKDB02BL1gdEU5bLppuAnSVqp6QWRQCdF7k2 7jdML1cWTfLZGxo61ZQrWxo= =TSrM -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
On 8/29/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > > In the future, I'll need to figure out how to copy the proper config > files from the development bz2 files instead of regenerating them. I've thought about this a bunch of times, but I can't really think of an ideal way to make this automated. Some possibilities: 1. Always generate the tarball manually so that you can make the appropriate updates in the book packages.ent file before the render step. The render script would just have to output a strong reminder to do this or something. The drawback is extra work and more failure points. 2. Always use the dated tarball and just copy it instead of generating it. The drawback is that there isn't a clear correlation between LFS release and the data files. 3. Decouple the data projects from the LFS book. I.e., make lfs-bootscripts a fully versioned project. This is the same as 2, but with real versions instead of snapshot dates, e.g. lfs-bootscripts-0.1.2. The drawback being that the projects might have to be split up for version controlling reasons (tags and branches of the book wouldn't necessarily correspond to tags and branches of the data files). I think 1 is probably the easiest to do right now, even though it adds an extra step. It's also nice to have a clear correspondence that "this set of udev rules works with what's in this LFS version". -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
Dan Nicholson wrote: > Since you're extracting the contents and rolling your own tarball, the > directory name and all the file metadata changes (e.g., your uid is > not the same as mine). It would be better if those tarballs were > manually generated or the releases just used the same dated tarball. > > This was also the reason why we stopped having the lfs-bootscripts and > udev-config tarballs generated at commit time. Instead, someone (me or > Bryan or whoever) manually generates them and updates the book > version/md5sum. > > I'll be happy to help fix up any issues, but it might help if I could > read your render script. The file is render-lfs-book-6.3.sh in my home directory. Use sudo to look at it, but please don't change it directly. The metadata is not relevant, but does change the md5sums. The directory that is extracted is probably significant. For the release process only, we may have to create the tarballs, run a sed to the packages.ent, and then commit the changes back. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
M.Canales.es wrote: > El Miércoles, 29 de Agosto de 2007 20:20, Bruce Dubbs escribió: > >> OK, I copied the config files from development to 6.3 and renamed >> appropriately. The md5sums match what is in the book. That should fix >> the jhalfs problem. > > Thanks. > > I will test that the new files are properly downloaded and verified when the > first machine finished doing it current LFS build. As Dan just pointed out, the directory that is extracted is probably wrong. :( -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
Bruce Dubbs wrote: > If I get the time, I'll investigate why my build script changed the > contents. OK, I think I found out. The contents of the files are not changed. I did two regenerations of the bootscripts and compared them. The files were identical, but the md5sum of the bz2 files were different. This is probably due to timestamps on the files or possibly permissions or ownership. In the future, I'll need to figure out how to copy the proper config files from the development bz2 files instead of regenerating them. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
El Miércoles, 29 de Agosto de 2007 20:20, Bruce Dubbs escribió: > OK, I copied the config files from development to 6.3 and renamed > appropriately. The md5sums match what is in the book. That should fix > the jhalfs problem. Thanks. I will test that the new files are properly downloaded and verified when the first machine finished doing it current LFS build. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
On 8/29/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > Bruce Dubbs wrote: > > M.Canales.es wrote: > >> Hi, > >> > >> jhalfs has reported this when trying to build LFS-6.3: > >> > >> lfs-bootscripts-6.3.tar.bz2 does not match MD5SUMS value > >> NEW MD5SUM: 4898129064e2edf93d52c9def3053ae1 lfs-bootscripts-6.3.tar.bz2 > >> udev-config-6.3.tar.bz2 does not match MD5SUMS value > >> NEW MD5SUM: 154bb3fd0aa36506ffa57e88cc08910d udev-config-6.3.tar.bz2 > >> > >> Both packages has been downloaded from > >> http://www.linuxfromscratch.org/lfs/downloads/6.3/ > >> > >> > >> That MD5SUM discrepancies need be verifyed and fixed on the XML sources to > >> can > >> release both jhalfs-2.3.1 and the LFS LiveCD. An entry on the errata page > >> don't solve the issue. > > > > The best fix is to replace the config files for 6.3 on quantum with the > > ones that match the md5sums in the book if we can. I'll investigate. > > OK, I copied the config files from development to 6.3 and renamed > appropriately. The md5sums match what is in the book. That should fix > the jhalfs problem. Except that the extracted directory name will not be lfs-bootscripts-6.3, but lfs-bootscripts-2007, which will probably make jhalfs barf. > If I get the time, I'll investigate why my build script changed the > contents. Since you're extracting the contents and rolling your own tarball, the directory name and all the file metadata changes (e.g., your uid is not the same as mine). It would be better if those tarballs were manually generated or the releases just used the same dated tarball. This was also the reason why we stopped having the lfs-bootscripts and udev-config tarballs generated at commit time. Instead, someone (me or Bryan or whoever) manually generates them and updates the book version/md5sum. I'll be happy to help fix up any issues, but it might help if I could read your render script. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
Bruce Dubbs wrote: > M.Canales.es wrote: >> Hi, >> >> jhalfs has reported this when trying to build LFS-6.3: >> >> lfs-bootscripts-6.3.tar.bz2 does not match MD5SUMS value >> NEW MD5SUM: 4898129064e2edf93d52c9def3053ae1 lfs-bootscripts-6.3.tar.bz2 >> udev-config-6.3.tar.bz2 does not match MD5SUMS value >> NEW MD5SUM: 154bb3fd0aa36506ffa57e88cc08910d udev-config-6.3.tar.bz2 >> >> Both packages has been downloaded from >> http://www.linuxfromscratch.org/lfs/downloads/6.3/ >> >> >> That MD5SUM discrepancies need be verifyed and fixed on the XML sources to >> can >> release both jhalfs-2.3.1 and the LFS LiveCD. An entry on the errata page >> don't solve the issue. > > The best fix is to replace the config files for 6.3 on quantum with the > ones that match the md5sums in the book if we can. I'll investigate. OK, I copied the config files from development to 6.3 and renamed appropriately. The md5sums match what is in the book. That should fix the jhalfs problem. If I get the time, I'll investigate why my build script changed the contents. It is doing: SVN="svn://svn.linuxfromscratch.org/LFS/tags/6.3" TMP_DIR=`mktemp -d /tmp/renderlfsbook.XX` BOOTSCRIPTS_VERSION=$(grep "ENTITY lfs-bootscripts-version" \ $TMP_DIR/BOOK/packages.ent | cut -d\" -f2) svn -q export "$SVN/bootscripts" "$TMP_DIR/bootscripts BOOTSCRIPTS="lfs-bootscripts-$BOOTSCRIPTS_VERSION tar -cjf download/$BOOTSCRIPTS.tar.bz2 \ lfs-bootscripts-$BOOTSCRIPTS_VERSION --- To Justin: Will the mirrors automatically pick up these changed files? The date/content has changed slightly, but the file names have not. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
M.Canales.es wrote: > Hi, > > jhalfs has reported this when trying to build LFS-6.3: > > lfs-bootscripts-6.3.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: 4898129064e2edf93d52c9def3053ae1 lfs-bootscripts-6.3.tar.bz2 > udev-config-6.3.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: 154bb3fd0aa36506ffa57e88cc08910d udev-config-6.3.tar.bz2 > > Both packages has been downloaded from > http://www.linuxfromscratch.org/lfs/downloads/6.3/ > > > That MD5SUM discrepancies need be verifyed and fixed on the XML sources to > can > release both jhalfs-2.3.1 and the LFS LiveCD. An entry on the errata page > don't solve the issue. The best fix is to replace the config files for 6.3 on quantum with the ones that match the md5sums in the book if we can. I'll investigate. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wrong MD5SUM values in LFS-6.3
On 8/29/07, M.Canales.es <[EMAIL PROTECTED]> wrote: > > jhalfs has reported this when trying to build LFS-6.3: > > lfs-bootscripts-6.3.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: 4898129064e2edf93d52c9def3053ae1 lfs-bootscripts-6.3.tar.bz2 > udev-config-6.3.tar.bz2 does not match MD5SUMS value > NEW MD5SUM: 154bb3fd0aa36506ffa57e88cc08910d udev-config-6.3.tar.bz2 > > Both packages has been downloaded from > http://www.linuxfromscratch.org/lfs/downloads/6.3/ > > > That MD5SUM discrepancies need be verifyed and fixed on the XML sources to can > release both jhalfs-2.3.1 and the LFS LiveCD. An entry on the errata page > don't solve the issue. Looks like the tag will have to be regenerated again. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
