compatibility is maintained afaict, except an additional "mx" prefix
in the namespace
-make it a "distutils" pkg, so it works with Python-2.2.x
-license change - now freely redistibutable
pclock is a simple analog clock program designed to run under WindowMaker
window manager (also runs fine on any other window manager which supports
dock apps, such as PWM). Any 64x64 pixmap may be used as a background.
Submitted by Lubomir Sedlacik <salo@Xtrmntr.org> in PR 18008
extension Makefile fragments, because they really don't have anything to
do with the buildlink[12] frameworks. Change all the Makefiles that use
application.buildlink.mk and extension.buildlink.mk to use application.mk
and extension.mk instead.
Remove `-p' from mkdir arguments, it is already part of ${MKDIR}.
While here substitute a couple of ${PREFIX} by `%D' in
`@exec ${MKDIR} ...' lines and add a couple of missing `%D' in such lines too!
packages collection.
Xchrono is a multi-timezone, multi-face clock program for X Windows.
Several cities have been compiled into xchrono, and can be invoked with
command-line arguments, xchrono -help gives:
Usage: xchrono [-analog] [-bw <pixels>] [-digital]
[-fg <color>] [-bg <color>] [-hd <color>]
[-hl <color>] [-bd <color>]
[-fn <font_name>] [-help] [-padding <pixels>]
[-rv] [-update <seconds>] [-display displayname]
[-geometry geom]
[-width clockWidth] [-height clockHeight] [-local localName]
[-boston] [-newyork] [-chicago] [-denver] [-la]
[-hawaii] [-tokyo] [-sydney] [-london]
[-paris] [-frankfurt] [-rio]
OK, OK, Hawaii isn't a city, but you get the point. The timezones used
are taken from tztab in the SYSV case, and from /usr/lib/zoneinfo
otherwise, and as such may or may not be correct (the TZ variable
definitions or the city->timezone mappings).
The -local <localName> option causes a clock labeled with <localName>
using the value of TZ at startup as it's timezone. In addition, a GMT
clock always appears.
[Requested by groo, who has enough trouble with one timezone, so why he
wants more is beyond me.]
Project Clock lets you record the time you spend on different tasks
with a single mouse click. It is easy to add and delete projects. An
included utility generates reports.
all dependencies on packages depending on "png" which contain shared
libraries, all for the (imminent) update to the "png" package.
[List courtesy of John Darrow, courtesy of "bulk-build".]
redefines about which buildlink.mk files would care is BUILDLINK_X11_DIR,
which points to the location of the X11R6 hierarchy used during building.
If x11.buildlink.mk isn't included, then BUILDLINK_X11_DIR defaults to
${X11BASE} (set in bsd.pkg.mk), so its value is always safe to use. Remove
the ifdefs surrounding the use of BUILDLINK_X11_DIR in tk/buildlink.mk and
revert changes to move x11.buildlink.mk before the other buildlink.mk files.
use X11_BUILDLINK_MK as a test value. Generally just reordering the
inclusions so that x11.buildlink.mk comes before the other buildlink.mk
files will make everthing work.
foo-* to foo-[0-9]*. This is to cause the dependencies to match only the
packages whose base package name is "foo", and not those named "foo-bar".
A concrete example is p5-Net-* matching p5-Net-DNS as well as p5-Net. Also
change dependency examples in Packages.txt to reflect this.
to ${X11BASE} in the header and library search paths into references to
${LOCALBASE}/share/x11-links. These packages should now be strongly-
buildlinked regardless of whether xpkgwedge is installed.
Changes well-tested on NetBSD-1.5X/i386 with and without xpkgwedge and
lightly-tested on NetBSD-1.5.1/alpha without xpkgwedge.
CXXFLAGS, and LDFLAGS by the buildlink.mk files so remove the extra
definitions to add them from the package Makefiles. As advised by the
bsd.buildlink.mk file, also ensure that the buildlink.mk files are
included prior to defining any package-specific CFLAGS/LDFLAGS to ensure
that the buildlink directories are at the head of the compiler search
paths.
