Thread: [SSI-devel] Preparing for 1.1.0 release
Brought to you by:
brucewalker,
rogertsang
From: Brian J. W. <Bri...@hp...> - 2004-09-22 02:41:01
|
Everybody, Make sure your ChangeLog entries are up to date. If you don't mention what you did in the ChangeLog, I won't write about it in the release notes. Brian Hi En Chiang, We need to finalize the 1.1.0 release. I spent most of the day syncing the various distro branches and improving the merge tag scheme. I also applied a REV-FC tag to the OPENSSI-FC branch, so we can keep track of when we need to bump OpenSSI revision numbers. Since we didn't have this tag before and I don't know what's changed since the release tarball on kahuna was generated, I bumped all of the revision numbers before applying the REV-FC tag. Can you generate a new 1.1.0 release tarball with a fresh set of packages, including John's latest FC1 kernel code from the OPENSSI-RH branch? Be sure to keep the kernel-ssi-debuginfo and kernel-ssi-source packages. Although they aren't part of the release tarball, the source package gets released on SF and the debuginfo package is used to debug netdumps. Be sure that you add the release banner to the ChangeLog and generate the various INSTALL* files before building openssi-tools. When you're generating the release tarball, checkin any changes you made to the OPENSSI-FC branch and apply the OPENSSI-FC-1-1-0 tag. Put the release tarball, kernel-ssi-source and kernel-ssi-debuginfo packages in /kahuna/linux/openssi/1.1.0. You can delete the old release tarball. Finally, somebody needs to test both a fresh install on FC2 and an upgrade from 1.0.0 on RH9 (that reminds me that docs/README.upgrade probably needs to be updated). Thanks, Brian |
From: En C. L. <en...@in...> - 2004-09-22 04:24:29
|
Hi Brian, I guess the build will have to be out of a hybrid RH-FC sandbox with ci, openssi/kernel*, srpms/kernel* and srpms/linux-fc* coming from RH and the rest from FC. Is this correct? Thanks, En Chiang On Wed, 2004-09-22 at 08:10, Brian J. Watson wrote: > Everybody, > > Make sure your ChangeLog entries are up to date. If you don't mention > what you did in the ChangeLog, I won't write about it in the release notes. > > Brian > > > Hi En Chiang, > > We need to finalize the 1.1.0 release. I spent most of the day syncing > the various distro branches and improving the merge tag scheme. I also > applied a REV-FC tag to the OPENSSI-FC branch, so we can keep track of > when we need to bump OpenSSI revision numbers. Since we didn't have this > tag before and I don't know what's changed since the release tarball on > kahuna was generated, I bumped all of the revision numbers before > applying the REV-FC tag. > > Can you generate a new 1.1.0 release tarball with a fresh set of > packages, including John's latest FC1 kernel code from the OPENSSI-RH > branch? Be sure to keep the kernel-ssi-debuginfo and kernel-ssi-source > packages. Although they aren't part of the release tarball, the source > package gets released on SF and the debuginfo package is used to debug > netdumps. > > Be sure that you add the release banner to the ChangeLog and generate > the various INSTALL* files before building openssi-tools. When you're > generating the release tarball, checkin any changes you made to the > OPENSSI-FC branch and apply the OPENSSI-FC-1-1-0 tag. Put the release > tarball, kernel-ssi-source and kernel-ssi-debuginfo packages in > /kahuna/linux/openssi/1.1.0. You can delete the old release tarball. > > Finally, somebody needs to test both a fresh install on FC2 and an > upgrade from 1.0.0 on RH9 (that reminds me that docs/README.upgrade > probably needs to be updated). > > Thanks, > > Brian > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |
From: Brian J. W. <Bri...@hp...> - 2004-09-22 22:11:56
|
En Chiang Lee wrote: > Hi Brian, > > I guess the build will have to be out of a hybrid RH-FC sandbox with ci, > openssi/kernel*, srpms/kernel* and srpms/linux-fc* coming from RH and > the rest from FC. Is this correct? That sounds correct. Brian |
From: En C. L. <en...@in...> - 2004-09-22 19:18:51
|
Hi Brian, The tarball is on kahuna/linux/openssi/1.1.0, along with the source and debuginfo rpms. Some of the README.* documents have references to 1.0.0 which probably need to be changed. I'll test the install and upgrade tomorrow to make sure everything is okay. En Chiang > We need to finalize the 1.1.0 release. I spent most of the day syncing > the various distro branches and improving the merge tag scheme. I also > applied a REV-FC tag to the OPENSSI-FC branch, so we can keep track of > when we need to bump OpenSSI revision numbers. Since we didn't have this > tag before and I don't know what's changed since the release tarball on > kahuna was generated, I bumped all of the revision numbers before > applying the REV-FC tag. > > Can you generate a new 1.1.0 release tarball with a fresh set of > packages, including John's latest FC1 kernel code from the OPENSSI-RH > branch? Be sure to keep the kernel-ssi-debuginfo and kernel-ssi-source > packages. Although they aren't part of the release tarball, the source > package gets released on SF and the debuginfo package is used to debug > netdumps. > > Be sure that you add the release banner to the ChangeLog and generate > the various INSTALL* files before building openssi-tools. When you're > generating the release tarball, checkin any changes you made to the > OPENSSI-FC branch and apply the OPENSSI-FC-1-1-0 tag. Put the release > tarball, kernel-ssi-source and kernel-ssi-debuginfo packages in > /kahuna/linux/openssi/1.1.0. You can delete the old release tarball. > > Finally, somebody needs to test both a fresh install on FC2 and an > upgrade from 1.0.0 on RH9 (that reminds me that docs/README.upgrade > probably needs to be updated). > > Thanks, > > Brian > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |
From: Brian J. W. <Bri...@hp...> - 2004-09-23 02:11:23
|
En Chiang Lee wrote: > Hi Brian, > > The tarball is on kahuna/linux/openssi/1.1.0, along with the source and > debuginfo rpms. Thanks. > Some of the README.* documents have references to 1.0.0 which probably > need to be changed. The core developers are looking over them. John and I have already fixed some. Laura's happy with the two I assigned her. > I'll test the install and upgrade tomorrow to make sure everything is > okay. Excellent. While you're at it, can you double-check that the installation instructions are accurate? I fixed them up a little today, but I don't have a lot of experience yet with Fedora Core 2. One thing to look out for is that the /cluster/nodetemplate/var/log/gdm directory should exist after both a fresh install and an upgrade from 1.0.0. This directory did not exist on 1.0.0, so I checked in code today to make sure it exists. Thanks, Brian |
From: Aneesh K. K.V <ane...@hp...> - 2004-09-23 06:37:43
|
Brian J. Watson wrote: > > One thing to look out for is that the /cluster/nodetemplate/var/log/gdm > directory should exist after both a fresh install and an upgrade from > 1.0.0. This directory did not exist on 1.0.0, so I checked in code today > to make sure it exists. > One thing i am confused is why we delete some of the directories after creating them under nodetemplate. ? For debian i am just copying the files and directories across when i am making a directory local to node. ie , $target = '/var/log'; mklocalfile $target; # SSI_XXX: Not idempotent `rm -rf $NODE_DIR/$target/wtmp`; mkglobalfile "$target/wtmp"; `rm -rf $TEMPLATE_DIR/$target/gdm/*`; `test -d $TEMPLATE_DIR/$target/gdm && mv $TEMPLATE_DIR/$target/gdm $TMP_DIR`; `rm -rf $TEMPLATE_DIR/$target/httpd/*`; `test -d $TEMPLATE_DIR/$target/httpd && mv $TEMPLATE_DIR/$target/httpd $TMP_DIR`; `rm -rf $TEMPLATE_DIR/$target/news/*`; `test -d $TEMPLATE_DIR/$target/news && mv $TEMPLATE_DIR/$target/news $TMP_DIR`; `mv $TEMPLATE_DIR/$target/wtmp $TMP_DIR`; `rm -rf $TEMPLATE_DIR/$target/*`; `mv $TMP_DIR/* $TEMPLATE_DIR/$target` Instead how about $target = '/var/log'; mklocalfile $target; mkglobalfile "$target/wtmp"; Why do we need all those mv and rm ? Without that also everything should work right ? -aneesh |
From: Brian J. W. <Bri...@hp...> - 2004-09-23 19:43:57
|
Aneesh Kumar K.V wrote: > Instead how about > > $target = '/var/log'; > mklocalfile $target; > mkglobalfile "$target/wtmp"; > > Why do we need all those mv and rm ? Without that also everything should > work right ? Most of the mv and rm stuff has nothing to do with mkglobalfile. Its purpose is to delete the stuff that's specific to the first node, while still preserving a few key subdirectories. John's proposed a more general approach of simply deleting all files and preserving all subdirectories, rather than special casing certain subdirectories with all the mv and rm commands. I agree with this in principle, but I'm not going to spend the time implementing that change right now. The reason for `rm -rf $NODE_DIR/$target/wtmp`; is that otherwise an unnecessary /cluster/node1/var/log/wtmp.ssisave directory is left lying around by the mkglobalfile command (assuming node 1 is the first node). During ssi-create, it's guaranteed to be an exact duplicate of the /var/log/wtmp that's made global, so it's best to just delete it. Hope this clarifies things, Brian |
From: En C. L. <en...@in...> - 2004-09-23 15:48:14
|
On Thu, 2004-09-23 at 07:41, Brian J. Watson wrote: > > The tarball is on kahuna/linux/openssi/1.1.0, along with the source and > > debuginfo rpms. > > Thanks. The latest tarball with all the changed docs is on kahuna. The corresponding code is tagged with OPENSSI-FC-1-1-0 in the various branches from which the code was used. While testing the install, here are my observations: - On a fresh install of RH9 (chose "Server" install), the install fails with a large number of dependencies. I haven't tried to resolve these. - On a fresh install of FC2 (chose "Server" install), the install goes through without a hitch. Forgot the readdir() work-around (tune2fs....) the first time, and caused ls to get stuck. After using tune2fs, the first node booted up fine. - ssi-addnode had a problem while updating the ramdisk. This is because the automatic loading of the loop module does not happen. In mkinitrd, "echo findlodev | /sbin/nash --quiet" does not return a loop device. The addnode went through after I did "insmod loop", but this should be fixed. - Upgrading from 1.0.0 has 2 problems - minor problem: the release numbers have the "devel" suffix, so fail this check in parse_rel (install.pm): $str =~ s/_ssi_(\d+)$//; - removed the '$', and this is what happens: error: Failed dependencies: beecrypt >= 3.0.1 is needed by rpm-4.3.1-0.3 libbeecrypt.so.6 is needed by rpm-4.3.1-0.3 libc.so.6(GLIBC_2.3.4) is needed by rpm-4.3.1-0.3 libselinux.so.1 is needed by rpm-4.3.1-0.3 popt = 1.9.1 is needed by rpm-4.3.1-0.3 libc.so.6(GLIBC_2.3.4) is needed by devfsd-1.3.25-1_ssi_4devel ethtool >= 1.8-2 is needed by initscripts-7.53-1_ssi_2devel libc.so.6(GLIBC_2.3.4) is needed by initscripts-7.53-1_ssi_2devel libselinux.so.1 is needed by logrotate-3.7-4.1_ssi_2devel lvm2 is needed by mkinitrd-3.5.22-1_ssi_2devel modutils >= 2.4.26-9 is needed by nfs-utils-1.0.6-20_ssi_2devel db4 = 4.2.52 is needed by pam-0.77-40_ssi_2devel libc.so.6(GLIBC_2.3.4) is needed by pam-0.77-40_ssi_2devel libselinux.so.1 is needed by pam-0.77-40_ssi_2devel libc.so.6(GLIBC_2.3.4) is needed by procps-3.2.0-1.1_ssi_2devel libselinux.so.1 is needed by psmisc-21.4-2_ssi_2devel libselinux.so.1 is needed by sudo-1.6.7p5-26_ssi_2devel filesystem >= 2.2.4-1 is needed by SysVinit-2.85-25_ssi_2devel libselinux >= 1.11.3-1 is needed by SysVinit-2.85-25_ssi_2devel libselinux.so.1 is needed by SysVinit-2.85-25_ssi_2devel libselinux.so.1 is needed by util-linux-2.12-18_ssi_2devel libxml2 = 2.5.4 is needed by (installed) libxml2-python-2.5.4-1 librpm-4.2.so is needed by (installed) rpm-python-4.2-0.69 librpmdb-4.2.so is needed by (installed) rpm-python-4.2-0.69 librpmio-4.2.so is needed by (installed) rpm-python-4.2-0.69 rpm = 4.2 is needed by (installed) rpm-python-4.2-0.69 chkconfig = 1.3.8 is needed by (installed) ntsysv-1.3.8-1 Failed to update packages Is it worth the effort to determine all the packages that need to be put into the tarball to make this upgrade possible? (These are more or less the same dependencies that resulted from the attempted install on the fresh RH9 machine). > One thing to look out for is that the /cluster/nodetemplate/var/log/gdm > directory should exist after both a fresh install and an upgrade from > 1.0.0. This directory did not exist on 1.0.0, so I checked in code today > to make sure it exists. This directory doesn't exist after the fresh install. Regards, En Chiang > One thing to look out for is that the /cluster/nodetemplate/var/log/gdm > directory should exist after both a fresh install and an upgrade from > 1.0.0. This directory did not exist on 1.0.0, so I checked in code today > to make sure it exists. > > Thanks, > > Brian > |
From: Brian J. W. <Bri...@hp...> - 2004-09-24 00:28:34
|
En Chiang Lee wrote: > The latest tarball with all the changed docs is on kahuna. The > corresponding code is tagged with OPENSSI-FC-1-1-0 in the various > branches from which the code was used. Thanks. I noticed that your version ChangeLog does not include changes Laura made last night. I also noticed that she added an entry above the release banner that presumably is not in the currently built kernel. You can deal with this by deleting that entry before copying ChangeLog into the release tarball and building openssi-tools (which includes ChangeLog), but leaving that entry in the OPENSSI-FC-1-1-0 version in the repository. BTW, for the CI repository it might be best to use the OPENSSI-FC version and copy in the OPENSSI-RH kernel* directories and specs/kernel-2.4.spec file, like you did for the OpenSSI repository. It's not a big deal this time, since the only difference between OPENSSI-FC and OPENSSI-RH (apart from the kernel stuff) is the revision number in specs/cluster-tools.spec. In the future, however, there might be a more significant difference. > - ssi-addnode had a problem while updating the ramdisk. This is because > the automatic loading of the loop module does not happen. In mkinitrd, > "echo findlodev | /sbin/nash --quiet" does not return a loop device. The > addnode went through after I did "insmod loop", but this should be > fixed. I'm not sure why this happens on the new FC2 release, but didn't happen on the old RH9 release. Perhaps it's a difference in nash. I guess we can hack around this problem by adding "insmod loop" before the findlodev line. > - Upgrading from 1.0.0 has 2 problems > - minor problem: the release numbers have the "devel" suffix, so fail > this check in parse_rel (install.pm): > $str =~ s/_ssi_(\d+)$//; Go ahead and make this change in the repository. >>One thing to look out for is that the /cluster/nodetemplate/var/log/gdm >>directory should exist after both a fresh install and an upgrade from >>1.0.0. This directory did not exist on 1.0.0, so I checked in code today >>to make sure it exists. > > > This directory doesn't exist after the fresh install. Probably because you didn't have Gnome installed, so you didn't originally have /var/log/gdm. I did a test install on my FC2 machine with Gnome already installed. /cluster/nodetemplate/var/log/gdm existed after I did the installation. Thanks, Brian |
From: Brian J. W. <Bri...@hp...> - 2004-09-24 01:10:17
|
Brian J. Watson wrote: > En Chiang Lee wrote: > >> The latest tarball with all the changed docs is on kahuna. The >> corresponding code is tagged with OPENSSI-FC-1-1-0 in the various >> branches from which the code was used. > > > Thanks. I noticed that your version ChangeLog does not include changes > Laura made last night. I also noticed that she added an entry above the > release banner that presumably is not in the currently built kernel. You > can deal with this by deleting that entry before copying ChangeLog into > the release tarball and building openssi-tools (which includes > ChangeLog), but leaving that entry in the OPENSSI-FC-1-1-0 version in > the repository. Scratch that. Apparently the kernel will need to be rebuilt with a new node monitor frequency that John's going to checkin. You can rebuild the kernel from the current top of the OPENSSI-RH branch. You can also move the release banner in ChangeLog so that it's above Laura's entry, since her change will be part of the new kernel that you build. Don't forget to bump the SSI revision number in the kernel specfile and update the REV-RH tag on the kernel* directories and specfile. Thanks, Brian |