binutils/README-how-to-make-a-release

   1                 README for MAKING BINUTILS RELEASES
   2
   3 This is a collection of notes on how to perform a binutils release.  A
   4 lot of this information can also be found in the maintain.texi file in
   5 the gnulib project:
   6
   7   https://www.gnu.org/software/gnulib/
   8
   9 It is useful to have a cloned copy of the sources of this project as
  10 it also contains an upload script used to install tarballs on the GNU
  11 FTP server.
  12
  13 Make sure that you have upload authority on sourceware and fencepost.
  14 See the maintain.texi file for details on how to obtain these
  15 permissions.
  16
  17 Note - when performing a release it is helpful to edit this document
  18 as you go, updating the example commands so that they are ready for
  19 the release that follows.
  20
  21 -------------------------------------------------
  22 How to perform a release.
  23 -------------------------------------------------
  24
  25   1. Choose dates for the branch and release.  Weekends are better
  26      because they are less busy.  It is typical to leave two weeks
  27      between creating the branch and creating the release.
  28
  29      Send an email out warning contributors about the forthcoming
  30      branch and release.
  31
  32   2. When the branch date is near:  Update the libiberty and config
  33      directories and the top level Makefile and configure files.  Also
  34      consider updating the toplevel libtool files.
  35
  36 -------------------------------------------------
  37 How to create the release branch.
  38 -------------------------------------------------
  39
  40 Approx time to complete from here: 2 hours ...
  41
  42   2.5 If you have not built from the sources recently then now is the
  43       time to check that they still work...
  44
  45   3. When branch day arrives add markers for the upcoming release to
  46      the NEWS files in gas, ld, and binutils.  No need to update NEWS
  47      in the gold directory - it has its own release numbering.
  48
  49      Likewise for the ChangeLog files in: bfd, binutils, cpu,
  50      elfcpp, gas, gold, gprof, include, ld, libctf, opcodes and toplevel.
  51
  52      Add a note of the name of the new branch to binutils/BRANCHES.
  53
  54      Commit these changes.
  55
  56   4. Create the release branch using:
  57
  58         git branch binutils-2_43-branch
  59         git push origin binutils-2_43-branch
  60
  61      If you get a message like:
  62
  63        remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..f974f26cb16cc6fe3946f163c787a05e713fb77b
  64
  65      It appears that this can be ignored...
  66
  67   5. Make sure that the branch is there.  IE check out the branch sources:
  68
  69         git clone ssh://sourceware.org/git/binutils-gdb.git -b binutils-2_43-branch 2.43
  70
  71      If you get a message about being in a "detached head" state, something
  72      has gone wrong...
  73
  74      Keep the checked out sources - they are going to be needed in future
  75      steps.
  76
  77   6. Update "BINUTILS_BRANCH" in gdbadmin's crontab:
  78
  79      Log in as gdbadmin on sourceware.org, and then:
  80
  81         $ cd crontab
  82         $ vi crontab
  83         [change BINUTILS_BRANCH]
  84         $ cvs ci crontab
  85         $ crontab crontab
  86
  87      If you do not have access to this account, please feel free to
  88      ask Joel Brobecker <brobecker AT adacore DOT com>.
  89
  90   7. Rename the current HEAD version entry in Bugzilla, and create a
  91      new one.  E.g. rename "2.43 (HEAD)" to 2.43, and create
  92      "2.44 (HEAD)":
  93
  94         https://sourceware.org/bugzilla/editversions.cgi?product=binutils
  95
  96   8. Update bfd/version.m4 on HEAD to indicate that is now a snapshot
  97      of the next release and the BRANCH to indicate that it is almost
  98      ready for the release.
  99
 100      So if the release is going to be 2.43 then the version number on
 101      the BRANCH should be set to 2.42.90 - ie almost, but not quite 2.43,
 102      and the version number on the MAINLINE should be set to 2.43.50 -
 103      ie half way to 2.44 release.
 104
 105      So the BRANCH bfd/version.m4 has:
 106
 107        m4_define([BFD_VERSION], [2.42.90])
 108
 109      and the MAINLINE has:
 110
 111        m4_define([BFD_VERSION], [2.43.50])
 112
 113      Regenerate various files on both branch and HEAD by configuring
 114      with "--enable-maintainer-mode --enable-gold --enable-shared" and then building
 115      with "make -j1 all-binutils all-gas all-gold all-gprof all-gprofng all-ld"
 116
 117      Add ChangeLog entries for the updated files.  Commit the changes.
 118      Make sure that this includes the .pot files as well as the
 119      configure and makefiles.
 120
 121   9. Create an initial pre-release:
 122
 123      a. Remove any auto-generated files, in order to force the
 124         src-release script to rebuild them.
 125
 126           cd <branch-sources>
 127           git clean -fdx
 128
 129      b. Create a source tarball of the BRANCH sources:
 130
 131           ./src-release.sh -x binutils
 132
 133         FIXME: Not sure if the following steps are needed...
 134
 135         Add a .dirstamp file to the gas/doc subdirectory:
 136
 137           touch -d <today's date> binutils-2.<release>/gas/doc/.dirstamp
 138           tar rvf binutils-<release>.tar binutils-<release>/gas/doc/.ditstamp
 139           rm binutils-<release>.tar.xz
 140           xz -9 binutils-<release>.tar
 141
 142           eg:
 143             touch -d 2024-08-01 binutils-2.42.90/gas/doc/.dirstamp
 144             tar rvf binutils-2.41.90.tar binutils-2.42.90/gas/doc/.dirstamp
 145             rm binutils-2.42.90.tar.xz
 146             xz -9 binutils-2.42.90.tar
 147
 148          ...END OF FIXME
 149
 150      c. Build a test target using this tarball.
 151
 152            cp binutils-2.42.90.tar.xz /dev/shm
 153            pushd /dev/shm
 154            tar xvf binutils-2.42.90.tar.xz
 155            mkdir build
 156            cd build
 157            ../binutils-2.42.90/configure --quiet --enable-gold
 158            make
 159            popd
 160
 161         If there are problems, fix them.
 162
 163      d. Upload the pre-release snapshot to the sourceware FTP site:
 164
 165           scp binutils-2.42.90.tar.xz sourceware.org:/var/ftp/pub/binutils/snapshots
 166           ssh sourceware.org sha256sum ~ftp/pub/binutils/snapshots/binutils-2.42.90.tar.xz
 167
 168         Paranoia: Compare the checksum with the local version.
 169
 170      e. Clean up the source directory again.
 171
 172          git clean -fdx
 173
 174   10. Tell the Translation Project where to find the new tarball.
 175       <coordinator@translationproject.org>
 176       qv: https://translationproject.org/html/maintainers.html
 177
 178 ------------------------------------------------------------------------
 179 Dear Translation Project
 180
 181   The 2.43 release branch has been created for the GNU Binutils project.
 182
 183   A snapshot of the branch sources can be found here:
 184
 185     https://sourceware.org/pub/binutils/snapshots/binutils-2.42.90.tar.xz
 186
 187   We hope to make the official release of the sources on the <DATE>
 188   although that could change if there are important bugs that need to
 189   be fixed before the release.
 190 ------------------------------------------------------------------------
 191
 192   11. Announce the availability of the snapshot and the branch on the
 193       binutils mailing list.  Set a date for when the release will
 194       actually happen.  Something like:
 195
 196
 197 Hi Everyone,
 198
 199   The <NEW_VERSION> branch has now been created:
 200
 201      git clone git://sourceware.org/git/binutils-gdb.git -b binutils-<NEW_VERSION>-branch
 202
 203   A snapshot of the sources is also available here:
 204
 205     https://sourceware.org/pub/binutils/snapshots/binutils-<OLD_VERSION>.90.tar.xz
 206
 207   Please could all patches for the branch be run by me.
 208   The rules for the branch are:
 209
 210     * No new features.
 211     * Target specific bug fixes are OK.
 212     * Generic bug fixes are OK if they are important and widely tested.
 213     * Documentation updates/fixes are OK.
 214     * Translation updates are OK.
 215     * Fixes for testsuite failures are OK.
 216
 217   Ideally I would like to make the release happen in two weeks time,
 218   i.e. <DATE>.  Which I hope will be enough time for everyone
 219   to get their final fixes in.
 220 ------------------------------------------------------------------------
 221
 222   12. Build various different toolchains, test them and nag
 223       maintainers to fix any testsuite failures for their
 224       architectures...
 225
 226 ==============================================================================
 227 ==============================================================================
 228
 229 For the next few weeks, monitor the mailing list for new translations
 230 and respond to any requests to have patches applied to the branch.
 231
 232 ==============================================================================
 233 ==============================================================================
 234
 235 Then, a couple of weeks later ...
 236
 237 -------------------------------------------------
 238 How to create the release.
 239 -------------------------------------------------
 240
 241   20. Make sure that the branch sources still build, test and install
 242       correctly.  Make sure that the sources are clean, without any
 243       patch files (.reg .orig *~) left over.
 244
 245          cd <branch>
 246          git pull
 247          git clean -fdx
 248          cd <builds>
 249          make
 250
 251   21. a. Update the release number in bfd/version.m4 on the release
 252          branch to a whole new minor version number, without a point
 253          value.  Eg "2.42.90" becomes "2.43".  NB/ Not: "2.43.00"
 254
 255       b. Change bfd/development.sh to set all values to "false".
 256
 257       c. Regenerate the configure and makefiles.  And *info* files.
 258
 259             cd <build-configured-with-enable-maintainer-mode>
 260             make -j1 all-gas all-ld all-binutils all-gprof all-gold all-gprofng all-libctf
 261             make info
 262
 263       d. Create a ChangeLog from the git refs for all of the commits
 264          from when changelog entries were no longer required:
 265
 266            gitlog-to-changelog --since=2021-07-03 > ChangeLog.git
 267            git add ChangeLog.git
 268
 269          The gitlog-to-changelog script is part of the sources
 270          of the "config" project.
 271
 272          Add an entry for ChangeLog.git to the src-release.sh script's
 273          DEVO_SUPPORT list, so that it is included in the release.
 274
 275          FIXME: it would be better if the ChangeLog.git file was permanently
 276          added to the src-release.sh script, but this mean that it would have
 277          to exist in the master repository, and that the GDB project would
 278          need to agree to have it there.
 279
 280       e. Add ChangeLog entries for all of the updates and add a
 281          "this-is-the-2.43-release" comment and commit.
 282
 283            git add .
 284            git commit -m "this-is-the-2.43-release"
 285            git push
 286
 287   22. Check that your file creation mask will create the
 288       correct file permissions.  Eg:
 289
 290             % umask
 291             22
 292
 293       Remove any spurious autom4te.cache files left over from the
 294       reconfiguring:
 295
 296             git clean -fdx
 297
 298   23. Note - check to see if any new files have been added to the top
 299       level of the source directory, but which are not in the
 300       DEVO_SUPPORT variable in the src-release.sh script.  If they are
 301       needed then add them.
 302
 303       PARANOIA: Check that there are no pending commits:
 304
 305              git status
 306
 307       Then create the release tarballs:
 308
 309             ./src-release.sh -b -g -l -x binutils
 310
 311       OR ... for a more reproducible tarball:
 312
 313             ./src-release.sh -b -g -l -x -r `git log -1 --format=%cd --date=format:%F bfd/version.m4` binutils
 314
 315   24. Check that the files in the tarballs have the correct
 316       permissions.
 317
 318            tar tvf binutils-*.tar.xz | grep -e "---"
 319
 320       Also check that the man files are not empty.  (cf PR 28144).
 321
 322            tar tvf binutils-*.tar.xz | grep -e "\.1"
 323
 324   25. Sanity check the release on x86_64-pc-linux-gnu by building and
 325        running the testsuites (gas, gold, binutils and ld).
 326       Make the source directory read-only before building.
 327       Also test 'make install'.
 328       Also build the html and pdf documentation files.
 329       If necessary fix any problems.
 330
 331         pushd /dev/shm
 332         mkdir delme
 333         cd delme
 334         tar xvf <path-to-sources>/binutils-2.*.tar.lz
 335         chmod -R -w binutils-2.*
 336         mkdir build
 337         cd build
 338         ../binutils-2.*/configure --quiet --enable-gold --prefix=`pwd`/install --enable-plugins --enable-shared
 339         make -j1 all-gas all-gold all-ld all-binutils all-gprof all-gprofng
 340         make check-gas check-binutils check-ld check-gold
 341         make install-gas install-gold install-ld install-binutils install-gprofng
 342
 343         # Needed for step 29...
 344         make html pdf html-libctf pdf-libctf html-libsframe pdf-libsframe
 345
 346         popd
 347
 348   26. Tag the branch with the new release number:
 349         [optional: add "-u XXXXX" to sign with a gpg key]
 350         enter a tag message such as: "Official GNU Binutils 2.4x release"
 351
 352             git tag -a <TAG>         -u <Your Key>
 353           eg:
 354             git tag -a binutils-2_43 -u DD9E3C4F      <=== Be careful to get the tag right
 355           or:
 356             git tag -a binutils-2_43 -u DD9E3C4F -m "Official GNU Binutils 2.43 release"
 357
 358         NB/ If you do sign the binaries make sure to use a key
 359         that has been published with the FSF.
 360
 361         Then push the release:
 362
 363             git push origin binutils-2_43
 364
 365         If you get an error message along the lines of:
 366           "Invalid revision range ..."
 367         you can ignore it.
 368
 369   27.  Upload the tarballs to ftp.gnu.org.
 370
 371           gnupload --to ftp.gnu.org:binutils binutils-2.43.tar.*
 372
 373         Be prepared to provide the password for the key, if you
 374         signed the binaries.
 375
 376         The gnupload script is in the gnulib/build-aux directory.
 377         It uses the ncftp package for transmitting the files.
 378
 379         Check for an email response from the upload.  If necessary
 380         fix any problems.  (The response might take a while, so
 381         proceed with the next steps if you are confident that
 382         everything is OK).
 383
 384   28. Upload the tarballs (and signatures) to sourceware.org:
 385
 386        sftp sourceware.org
 387          cd /sourceware/ftp/pub/binutils/releases
 388          put binutils-2.4*.tar.*
 389          chmod 644 binutils-2.4*.tar.*
 390          quit
 391
 392       FIXME: Are the signatures (created by the gnupload script in step 27)
 393       needed ?  [The above commands upload them and nobody has complained,
 394       so suggest that they are retained].
 395
 396   29. Update web pages.  For sourceware.org:
 397
 398       Clone the documentation (if you have not already done so):
 399
 400         git clone ssh://sourceware.org/git/binutils-htdocs
 401
 402       Create a new docs sub-directory and move into it:
 403
 404         cd binutils-htdocs
 405         mkdir docs-2.43
 406         cd docs-2.43
 407
 408       Copy the index.html from the previous release
 409
 410         cp ../docs/index.html .
 411
 412       Update the index.html file to reference this new release and to
 413       point back to the current (now old) release.
 414
 415       If necessary make the html documentation locally with the "make
 416       html" command.  (This should have been done by step 25 above).
 417
 418       Copy in the documentation files:
 419
 420          cp -r <build-dir>/gas/doc/as    .
 421          cp <build-dir>/gas/doc/as.html  .
 422          cp <build-dir>/gas/doc/as.pdf   .
 423
 424          cp -r <build-dir>/bfd/doc/bfd   .
 425          cp <build-dir>/bfd/doc/bfd.html .
 426          cp <build-dir>/bfd/doc/bfd.pdf  .
 427
 428          cp -r <build-dir>/binutils/binutils_html  binutils    [NB/ Path not like others]
 429          cp <build-dir>/binutils/doc/binutils.html .
 430          cp <build-dir>/binutils/doc/binutils.pdf  .
 431
 432          cp -r <build-dir>/gprof/doc/gprof     .
 433          cp <build-dir>/gprof/doc/gprof.html   .
 434          cp <build-dir>/gprof/doc/gprof.pdf    .
 435
 436          cp -r <build-dir>/ld/doc/ld     .
 437          cp <build-dir>/ld/doc/ld.html   .
 438          cp <build-dir>/ld/doc/ld.pdf    .
 439
 440             [NB/ The gprofng documentation does not have a node-per-page selection]
 441          cp <build-dir>/gprofng/doc/gprof.html   .
 442          cp <build-dir>/gprofng/doc/gprof.pdf    .
 443
 444          cp <build-dir>/libctf/doc/ctf-spec.html   .
 445          cp <build-dir>/libctf/doc/ctf-spec.pdf    .
 446
 447          cp <build-dir>/libsframe/doc/sframe-spec.html   .
 448          cp <build-dir>/libsframe/doc/sframe-spec.pdf    .
 449
 450       Update the symbolic link.
 451
 452          cd ..     [Should now be in be in binutils-htdocs/ ]
 453          rm docs
 454          ln -s docs-2.43 docs
 455
 456       Edit index.html file to change the links to point to the new
 457       release, mention any new features, update dates and so on.
 458
 459       Check that the new web page is correct:
 460
 461          file:///<path-to-binutils-htdocs>/index.html
 462
 463       Add the new directories and files, commit and push the changes:
 464
 465         git add .
 466         git commit -m"Update documenation for the 2.4x release"
 467         git push
 468
 469
 470   29.1 For the www.gnu.org site you have to email webmasters@gnu.org
 471       and ask them to copy the change(s):
 472 ---------------------------------------
 473 Hi FSF Webmasters,
 474
 475   Please could the GNU Binutils webpage at:
 476
 477 https://www.gnu.org/software/binutils/binutils.html
 478
 479   be updated to indicate that there is now a newer version available
 480   (2.4x).  I have already updated the related page on the sourceware
 481   website so this might be useful as a template:
 482
 483 https://sourceware.org/binutils/
 484
 485   Thanks very much.
 486
 487 Cheers
 488 --------------------------------------
 489
 490   30. Send emails to binutils@sourceware.org, info-gnu@gnu.org and
 491       David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 492       Sign the email and include the checksum:
 493
 494           sha256sum binutils-2.4*.tar.*
 495
 496       (The email to Davis is so that he can update the GNU Toolchain
 497       social media).  Something like this:
 498       -----------------------------------------------------------------------
 499         Hi Everyone,
 500
 501         We are pleased to announce that version 2.4x of the GNU Binutils project
 502         sources have been released and are now available for download at:
 503
 504           https://ftp.gnu.org/gnu/binutils
 505           https://sourceware.org/pub/binutils/releases/
 506
 507           checksums: xxxx
 508
 509         As an experiment these tarballs were made with the new "-r <date>"
 510         option supported by the src-release.sh script.  This attempts to make
 511         reproducible tarballs by sorting the files and passing the
 512         "--mtime=<date>" option to tar.  The date used for these tarballs was
 513         obtained by running:
 514
 515           git log -1 --format=%cd --date=format:%F bfd/version.m4
 516
 517         This release contains numerous bug fixes, and also the
 518         following new features:
 519
 520           <extract info from the NEWS files>
 521
 522         For more information see:
 523
 524           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;;hb=refs/tags/binutils-2_4x
 525           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_4x
 526           https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_4x
 527
 528         Our thanks go out to all of the binutils contributors, past and
 529         present, for helping to make this release possible.
 530
 531       -----------------------------------------------------------------------
 532
 533   31. Clean up the source tree:
 534
 535         git clean -fdx .
 536
 537   32. Edit bfd/development.sh on the branch and set the development flag
 538       to "true".  (Leave the experimental flag set to "false").  Also bump
 539       the version in bfd/version.m4 by adding a trailing .0, so that the
 540       date suffix keeps the version lower than the trunk version.
 541       Regenerate files.  Commit these changes.
 542
 543   33. Email the binutils list telling everyone that the 2.4x branch
 544       is now open for business as usual and that patches no longer
 545       need special approval.
 546
 547   34. Examine the bfd/config.bfd file in the mainline sources and move
 548       any pending obsolete targets into the definitely obsolete
 549       section.  Create a changelog entry and commit.
 550
 551   Sit back and relax, you are all done.
 552 --------------------------------------------------------------------------
 553 How to perform a POINT release.
 554 --------------------------------------------------------------------------
 555
 556 A point release is easier than a normal release since a lot of the
 557 work has already been done.  The branch has been created, the
 558 translations updated and the documentation uploaded.  So the procedure
 559 looks like this:
 560
 561   0. Decide that a point release is necessary.
 562
 563      Usually this only happens when a sufficient number of serious
 564      bugs have been found and fixed since the previous release, and a
 565      new official release is not imminent.
 566
 567   1. Tell the community that a point release is happening.  Ask
 568      maintainers to ensure that their ports are up to date on the
 569      release branch.  Ask the community if there are any bug fixes
 570      which are missing from the branch.  Allow some time for the
 571      responses to this step.
 572
 573   2. Make sure that the branch sources build, test and install
 574      correctly.
 575
 576   2.5 Prepare a list of the bugs which have been fixed.  This
 577       will be needed for step 8.
 578
 579   3. In the branch sources:
 580
 581        a. Update the minor release number in bfd/version.m4.
 582        b. Edit bfd/development.sh, set "development=false".
 583        c. Regenerate the configure files.
 584        d. Remove spurious autom4te.cache files:
 585
 586           git clean -fdx
 587
 588        e. Commit the updates along with a "this-is-the-2.3x.y-release"
 589           note in all of the changelogs.
 590        f. Tag the branch with the new release number:
 591
 592             git tag -a binutils-2_3x_y
 593               [optional: add "-u XXXXX" to sign with a gpg key]
 594             git push origin binutils-2_3x_y
 595
 596        g. Check that your file creation mask will create the
 597           correct file permissions.  Ie:
 598
 599             umask 022
 600
 601        h. Create the release tarballs:
 602
 603             ./src-release -b -g -l -x binutils
 604
 605        i. Check that the files in the tarballs have the correct
 606           permissions.
 607
 608        j. Clean the source tree again
 609
 610             git clean -fdx
 611
 612        k. Edit bfd/development.sh and set "development=true".
 613        l. Commit this change.
 614
 615   4. [If paranoid - upload the tarballs to one of the FTP servers and
 616       ask people to test it before going on to step 5].
 617
 618   5. Upload the tarballs to ftp.gnu.org.
 619
 620        gnupload --to ftp.gnu.org:binutils binutils-*.tar.*
 621
 622      The gnupload script is in the gnulib/build-aux directory.
 623
 624   6. Upload the tarballs to sourceware.org:
 625
 626        sftp sourceware.org
 627          cd /sourceware/ftp/pub/binutils/releases
 628          put binutils-*.tar.*
 629          chmod 644 binutils-*.tar.*
 630          quit
 631
 632     It is OK to upload the signatures as well.
 633
 634   7. Update web pages.  For sourceware.org:
 635
 636       * Clone the binutils documentation: git clone ssh://sourceware.org/git/binutils-htdocs
 637       * Edit index.html and update the latest release number (if this
 638         is a latest release).
 639       * Add new documentation (if necessary).
 640       * Commit and push the changes.
 641
 642       For the www.gnu.org site you have to email webmasters@gnu.org
 643       and ask them to make the change(s).
 644
 645   8. Send an emails to the binutils list, info-gnu@gnu.org and
 646      David Edelsohn <dje.gcc@gmail.com> announcing the new release.
 647      (The email to Davis is so that he can update the GNU Toolchain
 648      social media).  Something like this:
 649
 650 ------------------------------------------------------------------------
 651 Hi Everyone,
 652
 653   We are pleased to announce that version 2.3x.y of the GNU Binutils
 654   project sources have been released and are now available for download at:
 655
 656     https://ftp.gnu.org/gnu/binutils
 657     https://sourceware.org/pub/binutils/releases/
 658
 659   This is a point release over the previous 2.3x version, containing bug
 660   fixes but no new features.
 661
 662   Our thanks go out to all of the binutils contributors, past and
 663   present, for helping to make this release possible.
 664
 665   Here is a list of the bugs that have been fixed:
 666     xx
 667     xx
 668     xx
 669     xx
 670 --------------------------------------------------------------------------
 671
 672   9. Create a new Bugzilla entry for the point release.
 673
 674        https://sourceware.org/bugzilla/editversions.cgi?product=binutils
 675
 676      And a new milestone too:
 677
 678        https://sourceware.org/bugzilla/editmilestones.cgi?product=binutils
 679 \f
 680 Copyright (C) 2017-2024 Free Software Foundation, Inc.
 681
 682 Copying and distribution of this file, with or without modification,
 683 are permitted in any medium without royalty provided the copyright
 684 notice and this notice are preserved.