Log message:
Replaced ${PKGNAME} with ${PKGNAME_NOREV} to match the PLIST. Bumped
PKGREVISION.

Log message:
Recursive revision bump / recommended bump for gettext ABI change.

Log message:
Removed unknown JVM "jdk13".

Log message:
Create directories before installing files into them.

Log message:
Massive cleanup of buildlink3.mk and builtin.mk files in pkgsrc.
Several changes are involved since they are all interrelated.  These
changes affect about 1000 files.

The first major change is rewriting bsd.builtin.mk as well as all of
the builtin.mk files to follow the new example in bsd.builtin.mk.
The loop to include all of the builtin.mk files needed by the package
is moved from bsd.builtin.mk and into bsd.buildlink3.mk.  bsd.builtin.mk
is now included by each of the individual builtin.mk files and provides
some common logic for all of the builtin.mk files.  Currently, this
includes the computation for whether the native or pkgsrc version of
the package is preferred.  This causes USE_BUILTIN.* to be correctly
set when one builtin.mk file includes another.

The second major change is teach the builtin.mk files to consider
files under ${LOCALBASE} to be from pkgsrc-controlled packages.  Most
of the builtin.mk files test for the presence of built-in software by
checking for the existence of certain files, e.g. <pthread.h>, and we
now assume that if that file is under ${LOCALBASE}, then it must be
from pkgsrc.  This modification is a nod toward LOCALBASE=/usr.  The
exceptions to this new check are the X11 distribution packages, which
are handled specially as noted below.

The third major change is providing builtin.mk and version.mk files
for each of the X11 distribution packages in pkgsrc.  The builtin.mk
file can detect whether the native X11 distribution is the same as
the one provided by pkgsrc, and the version.mk file computes the
version of the X11 distribution package, whether it's built-in or not.

The fourth major change is that the buildlink3.mk files for X11 packages
that install parts which are part of X11 distribution packages, e.g.
Xpm, Xcursor, etc., now use imake to query the X11 distribution for
whether the software is already provided by the X11 distribution.
This is more accurate than grepping for a symbol name in the imake
config files.  Using imake required sprinkling various builtin-imake.mk
helper files into pkgsrc directories.  These files are used as input
to imake since imake can't use stdin for that purpose.

The fifth major change is in how packages note that they use X11.
Instead of setting USE_X11, package Makefiles should now include
x11.buildlink3.mk instead.  This causes the X11 package buildlink3
and builtin logic to be executed at the correct place for buildlink3.mk
and builtin.mk files that previously set USE_X11, and fixes packages
that relied on buildlink3.mk files to implicitly note that X11 is
needed.  Package buildlink3.mk should also include x11.buildlink3.mk
when linking against the package libraries requires also linking
against the X11 libraries.  Where it was obvious, redundant inclusions
of x11.buildlink3.mk have been removed.

Log message:
USE_X11=	yes

should fix problems seen in latest bulk-build

Log message:
Add RMD160 digests.

Log message:
Replace RPATH_FLAG with LINKER_RPATH_FLAG and COMPILER_RPATH_FLAG,
which are the full option names used to set rpath directives for the
linker and the compiler, respectively.  In places were we are invoking
the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is
inserted in case the flag is a word, e.g. -rpath.  The default values
of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the
compiler that you use.  They may be overridden on a ${OPSYS}-specific
basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG,
respectively.  Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.

Log message:
Fix PLIST for 1.7.0 (hi jschauma!)

Log message:
Update jGRASP to version 1.7.0.  Changes/bug fixes since 1.6.4:

- Some compatibility issues when running under Sun Java 1.5 beta are
  resolved. There probably are other problems.
- Some characters with valid font mappings, such as curly double quotes on
  Windows, may show up as hex codes in the CSD and Run I/O windows.
- After doing a "find" in the Run I/O window, the cursor may move into the
  output region, which will allow editing of previous output, and may lead
  to other problems.
- If a "clear" or "File / Open" is done from a CSD window, \ 
settings for
  the previous file will not be saved, and the file will not be added to
  the "Recent Files" menu.
- If text above the screen which contains all bookmarks or breakpoints is
  cut, the on-screen text will not be shifted, and the display may be
  temporarily corrupted.
- In the jar and documentation generating tools, some of the files are not
  stored as relative, and will become absolute when jGRASP is restarted.
- This means that if a project is move, the jar target file and
  documentation target directory will not move with it, and will have to
  be reset.
- Command paths for compile, run, etc. are not quoted on Windows. This can
  cause "C:\Program Files\etc\etc\something.exe" to fail if the file"
  C:\Program" exists, for example.
- Selecting both files and the project in the project tab and using "Open"
  from the popup menu will cause a harmless crash, and some or all of the
  files may not open.

- Switched default debug attacher from shared memory to socket on Windows
  NT/2000/XP, since the shared memory attacher tends to lock up under Sun
  Java 1.5 beta.

- In a CSD window, undoing edits on a saved file then doing an equal
  number of edits will mark the file as unmodified, even though it is
  modified. This may cause unexpected behavior, and lost edits.
- In the debugger and workbench, doubles and floats with NaN values will
  always be shown in red text (indicating change) even when the values
  were previously NaN.
- In 1.6.6, timeouts were added to kill the debugger if it did not respond
  for 10 seconds. This proved to be a problem because of modal dialogs. If
  jGRASP locks up while using the debugger or workbench, you should kill
  the target process externally using Task Manager on Windows, "kill" on
  UNIX/Linux, etc.

- Multiple projects can be open simultaneously.
- Workspaces can be saved and loaded.
- Project level run and debug commands are available on the UML window.
- Methods can be invoked while debugging from within the workbench.
- Numerous other small features were added, menus reorganized, etc.

- The default project has been eliminated, and users can now use jGRASP
  "projectless".
- Expression evaluation in the Java debugger now supports varargs and
  autoboxing/unboxing.
- Values in the Java debugger can now be dragged to anywhere and released
  to pop up a "view by name" viewer.
- Shortcut operators -- && || ?: -- can now be used in eval expressions,
  method arguments, etc. in the integrated Java debugger.

- Long lines in PostScript printouts may contain added spaces.
- UML print preview fails (display is incorrect) when the size of the
  previewed pages is smaller than a certain size.
- Text can be dragged and dropped into compile messages window and jGRASP
  messages window, which can result in mangled output.
- Debug "eval" gives incorrect results for == and != when applied to
  Objects.

-  Printing may crash when part of the text is folded.
- Closing the UML window while compiling from the UML window causes a crash

-  Paste of plain text was broken in Beta 3 (rtf still worked though).
- For the Java debugger, watch markers on inaccessible fields are the same
  color as the field marker instead of black, which can make them hard to
  see

- CLASSPATH is passed to appletviewer commands
- Detailed messages are now given when a compiler or program fails to run
  on UNIX/Linux

- A bug that was causing an occasional crash at start-up was fixed