[no description] https://git.osdyson.ru/mirror/pkgsrc/atom?h=pkgsrc_2004Q4 2004-10-03T00:12:51Z 2004-10-03T00:12:51Z tv tv 2004-10-03T00:12:51Z urn:sha1:b5510d5a2d7f9a1406603d922ae5d8548950233c in the process. (More information on tech-pkg.) Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and installing .la files. Bump PKGREVISION (only) of all packages depending directly on the above via a buildlink3 include. 2004-09-22T08:09:14Z jlam jlam 2004-09-22T08:09:14Z urn:sha1:08039266e343e3cb99feb5cbfd5fd9acf006ac97 All library names listed by *.la files no longer need to be listed in the PLIST, e.g., instead of: lib/libfoo.a lib/libfoo.la lib/libfoo.so lib/libfoo.so.0 lib/libfoo.so.0.1 one simply needs: lib/libfoo.la and bsd.pkg.mk will automatically ensure that the additional library names are listed in the installed package +CONTENTS file. Also make LIBTOOLIZE_PLIST default to "yes". 2004-06-03T16:21:14Z minskim minskim 2004-06-03T16:21:14Z urn:sha1:57efe61db7b254de100618104b606a4a7407ff3e Changes since 0.3: The big NEWS is that LibStroke now can draw the strokes! Yeeepeeee! But it does not do so by default, you need to pass --with-mouse-footprints to ./configure. After compiling everything try tests/stroke_test to see how this works. There's even more: libgstroke, a stroke implementation for GNOME has been contributed by Dan Nicolaescu. It is fully functional (it also supports mouse footprints by default!) and has a very easy to use API. Try tests/gnome_stroke_test to see how it works (source code in tests/gnome_stroke_test.c). We are proposing a set of strokes to be standard strokes. A pretty picture with them their string representation can be found in doc/standard_strokes.jpg A text listing is in doc/standard_strokes.txt (we will find some better names than the current ones). We'll also add some "sloppy strokes" for the standard strokes. We created autoconf macros for libstroke and libgstroke, they are in the macros subdir. Java port included and some misc bug fixes with the install process. 2004-04-11T20:31:02Z snj snj 2004-04-11T20:31:02Z urn:sha1:52b1b5b3ca8b11ed354094a5fe2534fb489b0288 2004-03-18T09:12:08Z jlam jlam 2004-03-18T09:12:08Z urn:sha1:847385cb2d9851c0ea2e94e51e8cb05abfdd6dbf by moving the inclusion of buildlink3.mk files outside of the protected region. This bug would be seen by users that have set PREFER_PKGSRC or PREFER_NATIVE to non-default values. BUILDLINK_PACKAGES should be ordered so that for any package in the list, that package doesn't depend on any packages to the left of it in the list. This ordering property is used to check for builtin packages in the correct order. The problem was that including a buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed from BUILDLINK_PACKAGES and appended to the end. However, since the inclusion of any other buildlink3.mk files within that buildlink3.mk was in a region that was protected against multiple inclusion, those dependencies weren't also moved to the end of BUILDLINK_PACKAGES. 2004-03-08T19:52:50Z minskim minskim 2004-03-08T19:52:50Z urn:sha1:4f0302b31790a10bf8e1c50a2612b7aefad894b9 be updated to depend on lang/tcl after Tcl/Tk update. 2004-03-05T19:25:06Z jlam jlam 2004-03-05T19:25:06Z urn:sha1:12109d5b873e13ef999184b4ace84a18e0a72358 buildlink3.mk file in revision 1.101 of bsd.buildlink3.mk. 2004-02-14T05:09:45Z dmcmahill dmcmahill 2004-02-14T05:09:45Z urn:sha1:4265e56265872376adea783f95c824deff39d7d9 2004-02-14T05:08:50Z dmcmahill dmcmahill 2004-02-14T05:08:50Z urn:sha1:48ac8bf15e2c7a4585d7ba84d898de0793a9f60c 2003-07-17T21:31:04Z grant grant 2003-07-17T21:31:04Z urn:sha1:86b1aded8c3dd192d07546fb2d7a5cb8eeb4596f