---->Anonymous ftp Directory [ANU_News.Patches]<---- The files in this directory are source patches for Geoff Huston's ANU News implementation of News/NNTP under VMS which have been posted to the newsgroup news.software.anu-news. Patch files are named as follows: - If a patch has not been incorporated into the distributed source code of an ANU News release, the file name has the format yymmdd_file.Patch, where 'yymmdd' is the date the patch was posted, and 'file' is the name of the source file which is revised by the patch. Some patches may affect more than one file; in this case, the name is that of the C source file most affected (the name of a header file is used only if the patch does not revise any C files). - If a patch has been incorporated into a subsequent release of the distributed ANU News source code, the file name has the format described above, but the file type has the format .Patch_ObsltNNNN, where NNNN is a 4 character string identifying the release into which the patch was incorporated (e.g. 920629_NewsFiles.Patch_Obslt61b7, which was incorporated into release 6.1b7 of ANU News). At present, the following version identifiers are in use: 61b6 - indicates patches incorporated into ANU News release 6.1beta6 61b7 - indicates patches incorporated into ANU News release 6.1beta7 61b8 - indicates patches incorporated into ANU News release 6.1beta8 Thus, if you want to retrieve only the patches which revise the most recent ANU News release, you can use the ftp command mget *.patch, while if you want to retrieve all patches which revise a given ANU News release, you should add to this a series of mget *.patch_obsltNNNN commands, for each NNNN which identifies a release later than the one you wish to revise. At present, the following version identifiers are in use: ---->Applying a Patch<---- The patch files are designed to be used with the Wall patch tool. This program, along with the corresponding diff utility, is available for anonymous ftp here (in directory [Anonymous.Util.VMS.SysMaint]). The DCL procedure NewsPatch.Com, located in this directory, is designed to apply a patch after making copies of the affected files. (In order to take full advantage of NewsPatch.Com, you should use the version of the Wall patch program which incorporates the -a and FAILURE patches [the one available here does].) Alternatively, you can apply the patches by defining a symbol which invokes patch as a foreign command (e.g. UxPatch == "$dev:[dir]Wall_Patch"), set default to the News_Src directory, and run patch with the command UxPatch <{patchfile} where {patchfile} is the file specification of the patch you want to apply. In this case, you can use patch -R to remove a troublesome patch. The patch tool will print progress reports, and will inform you of the results at each step in the process. More information on the function of patch and diff can be found in the documentation accompanying these programs. There's nothing magic about the patch files, and the changes can be made by hand; the patch program just makes it easier. Occasionally, if you're using a modified version one of the files affected by the patch (either previously patched or modified by hand), automatic application of the patch may fail. In this case, you will have to make the necessary changes by hand. ---->The PatchList.h File<---- Since News patches aren't cumulative in general, and since some sites may not choose to apply all patches, I felt that rather than incrementing a patchlevel.h file, it would be better to create a patchlist.h file and just record the ID of each patch applied. In order to do this automatically as the patch is applied, create a file named PatchList.h in your News_Src directory, and type the line "=+=+= End =+=+=" (no quotes) as the body of the file. The Patch ID of each patch applied will be added automatically to this file just before the end marker, if the patch is applied using the directions above. ---->Caveats<---- These patches are just the changes posted by the original author, placed in a standard format. In general, I haven't been able to test their correctness or effects. YMMV - I can't accept any responsibility for any consequences of applying any patch to your code. Always keep an unpatched version of all affected files, in case the patch does more harm than good. If it becomes apparent that a patch is defective, I'll try to supplement it with a corrected patch. In this case, I'll replace the diff in the defective patch file with a pointer to the corrected patch ID, and place a note in the Description: header of the corrected patch indicating that it supersedes the defective patch. In no case will I make any changes to source code which were not specified in the original post, without changing the author attribution of the patch, or getting the original author's approval. Please remember that I'm maintaining this patch collection on my own time, so I may not be able to address a specific issue for some time, depending on the demands of other committments. Finally, maintaining of this collection is my work alone, and does not reflect the efforts of HHMI, the University of Pennsylvania or any other organization. The patches are available free of charge, and may be redistributed freely, as long as no charge is made and attribution to the original author is maintained. No warranty is made as to the effectiveness of these patches, or their suitability for any purpose. None of the individuals or organizations mentioned herein will accept any responsibility for any damages of any kind arising from use of these patches. 'Nuff said. ---->Format of the Patch Files<---- Each patch is generated by making the changes specified in the post to a copy of the appropriate source files, in the form distributed with the version of News indicated in the News Version: header. Since you may not apply the same patches I do, or do so in the same order, each patch consists of a diff vs the version of the source file distributed in the saveset, regardless of any earlier patches to that file which may have been posted. The revised file and the original are then used to generate a context diff to be used as input for the patch utility. In these diffs, the name of the original file is unchanged, while the name of the revised file has _New appended. This convention allows patch to identify the necessary files when applying the revisions. Only the changes specified by the original author are incorporated into the patch, with one exception - if the post didn't contain instructions to include a notice of the modification the the leading comment of each affected file, I have added such a notice. Each patch file is in the following format: 1. The first line is always "ANU News Patch". 2. The second line begins with the string "Patch ID: ", and is followed by an ID string of the form yymmdd_filename!author@address, where the portion of the ID preceding the ! is derived in the same way as the file name, and author@address is the email address of the person posting the patch, or the person cited as the author, if different from the poster. 3. The third line begins with the string "Date: ", and is followed by the date the patch was posted, in the format dd-mmm-yyyy. (No new information, just more readable.) 4. The fourth line begins with the string "Author: ", and is followed by the name of the patch's author, and his/her email address. 5. The fifth line begins with the string "News Version: ", and is followed by a string noting the News version of the source file from which the patch file was generated. 6. The sixth line begins with the string "News Files: ", and is followed by the name(s) of all files affected by the patch (except PatchList.h; see below). Unless otherwise specified, these files are distributed in the News_Src saveset. 7. The seventh line begins with the string "Description: ", and is followed by a brief description of the patch's purpose and/or effects. This may be taken directly from the post describing the patch, or I may summarize. 8. Following the description may be one or more of the following headers (in the order given below): a. "Requires: " - this patch requires that the patch(es) whose ID(s) are listed in this header have been applied, either for this patch to be successfully applied, or for it to function properly once applied. b. "Supplemented: " - the patch(es) whose ID(s) are listed in this header either extends the function of this patch or corrects nonfatal errors in this patch. The patches referenced are not required for this patch to function, though they may be necessary for it to function properly according to its description. c. "Superseded: " - this patch has been replaced by the patch(es) whose ID(s) appear in this header, and is no longer current. Unless you have a specific reason to apply this patch (e.g. you are using an outdated version of News), you should not apply this patch, but should apply the patch(es) which supersede it instead. If the text of this header indicates that this patch has been included in a distributed version of News, the patch is not necessary if you are using that version of News, whether or not the precise changes specified by this patch have been made to the distributed version of the News source. d. "Replaces: " - this patch supersedes a previous patch(es), because it corrects a fatal error in the original(s), obviates the need for the original(s), or simply makes the same changes to a newer version of the News source. If this patch is applied, you need not apply any patch(es) listed in this header. If you do apply any of the replaced patches, or if you apply this patch to a copy of the source code to which any of the replaced patches have been applied, the results are undefined (patch application may fail or may break News). 8. Following the headers is the actual set of patch instructions. Each context diff is of the file version distributed with the version of News indicated in the header (e.g. NewsFoo.C) vs the patched file, named for the original file + _New (e.g. NewsFoo_New.C). 9. After all patch instructions for News files, there is a final context diff of the form: *** patchlist.h;-1 --- patchlist.h ************** *** 1,1 =+=+= End =+=+= --- 1,2 ----- + =+=+= End =+=+= where is the ID of the current patch. This is used to record the application of the patch in PatchList.h, as described above. ---->Example<---- ANU News Patch Patch ID: 920923_newspost.c!ewilts@galaxy.gov.bc.ca Date: 23-Sep-1992 Author: Ed Wilts ewilts@galaxy.gov.bc.ca News Version: 6.1beta5 News Files: NewsPost.C Description: Fixes a typo in the user message 'Invoking mailer'. *** newspost.c; --- newspost_new.c ************** *** 31,36 ** - Add support for UWO/Mail for Vax/VMS ** V6.1 9-Feb-1992 rankin@eql.caltech.edu ** - Lint cleanup **-- **/ --- 31,38 ----- ** - Add support for UWO/Mail for Vax/VMS ** V6.1 9-Feb-1992 rankin@eql.caltech.edu ** - Lint cleanup + ** V6.1 23-Sep-1992 ewilts@galaxy.gov.bc.ca + ** - Fixed typo in user message "Invoking mailer" **-- **/ ************** *** 1244,1250 sprintf(&xfrbuf[strlen(xfrbuf)],"%s,",add_transform(address_field)); address_field = comma_pointer; } while (address_field); ! if (*xfrbuf) call_mail(Post_file,s,xfrbuf,"Invoiking mailer - reply to poster"); } if (mail_self) call_mail(Post_file,s,usr_username,"CC: self - mailing"); } --- 1246,1252 ----- sprintf(&xfrbuf[strlen(xfrbuf)],"%s,",add_transform(address_field)); address_field = comma_pointer; } while (address_field); ! if (*xfrbuf) call_mail(Post_file,s,xfrbuf,"Invoking mailer - reply to poster"); } if (mail_self) call_mail(Post_file,s,usr_username,"CC: self - mailing"); } *** patchlist.h;-1 --- patchlist.h ************** *** 1,1 =+=+= End =+=+= --- 1,2 ----- + 920923_newspost.c!ewilts@galaxy.gov.bc.ca =+=+= End =+=+= ---->Comments<---- If anyone has any comments or suggestions about the format of these files, or about the general value or lack thereof of this collection, feel free to drop me a line or to post to news.software.anu-news group. Questions about specific patches are best directed to the original authors - they probably know more about what's going on than I do. I hope folks find this a useful addition to ANU News support. Thanks to everyone out there who takes the time to publish their patches for the rest of us. Charles Bailey Howard Hughes Medical Institute/Dept. of Genetics University of Pennsylvania School of Medicine bailey@genetics.upenn.edu Rev. 12-Aug-1993