Age | Commit message (Collapse) | Author | Files | Lines |
|
the darwin build. PR 20507.
|
|
a non-gcc compiler) by passing the '-i' flag to automake.
|
|
|
|
Should anybody feel like they could be the maintainer for any of thewe packages,
please adjust.
|
|
|
|
|
|
Noted by Frederick Bruckman on tech-pkg.
|
|
please update for gmake can get into an endless loop
|
|
|
|
w3c.org. It features some bug fixes and new function calls that are used in
the new Amaya f.e.
Tested on Alpha
|
|
seems good enouth, and using libwww's one breaks other system lib (librt).
|
|
|
|
|
|
|
|
|
|
buildlink2.mk files back into the main trunk. This provides sufficient
buildlink2 infrastructure to start merging other packages from the
buildlink2 branch that have already been converted to use the buildlink2
framework.
|
|
partially revert Makefile, v1.32, so platforms without openssl-0.9.6e
in base will be able to find libssl.so.300 and libcrypto.so.300 for
binaries linked against libwwwwwl.so. Bump pkgrevision to reflect the
change in dependencies on platforms without openssl-0.9.6e in base.
|
|
after consulting with Todd. Any volunteers for any of these packages?
|
|
makes these packages build correctly on Darwin where perl>=5.8.0 is
required.
|
|
1) Linking a shared library against a static "socks{4,5}" library
does not have the desired effect of eliminating the dependency on
"socks" (not as it does for binaries).
2) No package linked against "libwww" seems to actually utilize
"socks".
Also bump the PKGREVISION and buildlink DEPENDS to the current level,
and liberalize the (formal) dependency on "openssl", for the benefit
of pre-NetBSD-1.5 systems. From now on, we can have no more issues
with "openssl" or "socks{4,5}" versions, as only the libwwwssl.*
shared libraries carry a run-time dependency on "openssl", but no
package links against them, and no "libwww" shared libraries can carry
a run-time dependency on any "socks" libraries. [Previous versions, of
course, may have had issues -- see PR 17010, which this is a partial
fix for.]
|
|
|
|
|
|
depends on libwww currently requires openssl. If one ever does, it
can just include the openssl buildlink file in it's "Makefile".
|
|
to list them both when we listing just automake will do.
|
|
pkgsrc. Instead, a new variable PKGREVISION is invented that can get
bumped independent of DISTNAME and PKGNAME.
Example #1:
DISTNAME= foo-X.Y
PKGREVISION= Z
=> PKGNAME= foo-X.YnbZ
Example #2:
DISTNAME= barthing-X.Y
PKGNAME= bar-X.Y
PKGREVISION= Z
=> PKGNAME= bar=X.YnbZ (!)
On subsequent changes, only PKGREVISION needs to be bumped, no more risk
of getting DISTNAME changed accidentally.
|
|
|
|
installed files. We don't want buildlink references to escape into the
install directory.
|
|
|
|
|
|
Include a bugfix for lisp_LISP independently discovered by me that has
been pulled up to the automake-1-4 branch of automake cvs.
Changes are:
New in 1.4-p5:
* Allow AM_PROG_LIBTOOL again.
* Diagnose AC_CONFIG_HEADERS the same as AC_CONFIG_HEADER.
* Display distributed file list correctly in usage message.
* Allow numbers in macro names.
* Bugfixes.
New in 1.4-p4:
* Deal with configure.ac as well as configure.in -- this time for real!
* The version numbering system now allows three point version numbers,
such as 1.4.4, without thinking they are alpha release numbers.
New in 1.4-p3:
* Deal with configure.ac as well as configure.in.
* Don't complain if `version.texi' is included in multiple places.
New in 1.4-p2:
* Deal with AC_CONFIG_FILES from autoconf-2.50.
* Improvements to f77 support.
* DESTDIR now works for script targets.
* distcheck-hook works correctly.
New in 1.4-p1:
* The version numbering system now allows fork identifiers (such as
the p1 in this version of automake).
* Cope gracefully with various versions of libtool which may or may not
require ltconfig, ltcf-c.sh, ltcf-cxx.sh or ltcf-gcj.sh.
* Bugfixes.
|
|
set FOO_CONFIG=${BUILDLINK_CONFIG_WRAPPER.foo} in both CONFIGURE_ENV and
MAKE_ENV. We remove the check for GNU_CONFIGURE because if a package
Makefile includes the buildlink.mk file, then it most likely wants to use
the config script wrappers as well. Change suggested by Hubert Feyrer
(hubertf) and Tomasz Luchowski (zuntum).
|
|
installation directory in case the package isn't installed.
|
|
BUILDLINK_PREFIX.<pkgname>. This allows buildlink to find X11BASE packages
regardless of whether they were installed before or after xpkgwedge was
installed. Idea by Alistair Crooks <agc@pkgsrc.org>.
|
|
|
|
baggage for packages that have ${DEPENDS} on the libwww package, but
don't need to link in "libwwwssl" (currently all of them). These
packages _do_ _not_ need to have their DEPENDS changed now, as the
package system currently makes them require "libssl", whether they
truly require it to run, or not.
This will prove useful, however, when the version number of the
"libssl.so" shared library is bumped[1]. Then, we'll have to bump
again, but the depending packages will only need to depend on _this_
version, "libwww>=5.3.2nb1", the first version in which the "libwww*"
libraries (except libwwwssl) carry no dependency on "libssl".
[1] It's already been bumped in the HEAD of the base tree, but not
yet in the openssl package or in any release branch.
|
|
USE_BUILDLINK_ONLY.
|
|
|
|
|
|
|
|
|
|
|
|
on other libraries, on both ELF and (NetBSD/)a.out, to make
libwwwssl.so.?.? depend on the correct openssl shared libraries, as
determined by the setting of ${SSLBASE} in bsd.pkg.mk. This closes PR
pkg/12570, and has the additional advantage that programs that _do_ _not_
need to link in "-lwwwssl" won't get "-lssl" or "-lcrypto" at all.
Also, make"w3c" and "www" build again with USE_SOCKS=4.
|
|
|
|
+ move the patch digest/checksum values from files/patch-sum to distinfo
|
|
first component is now a package name+version/pattern, no more
executable/patchname/whatnot.
While there, introduce BUILD_USES_MSGFMT as shorthand to pull in
devel/gettext unless /usr/bin/msgfmt exists (i.e. on post-1.5 -current).
Patch by Alistair Crooks <agc@netbsd.org>
|
|
|
|
out of date - it was based on a.out OBJECT_FMT, and added entries in the
generated PLISTs to reflect the symlinks that ELF packages uses. It also
tried to be clever, and removed and recreated any symbolic links that were
created, which has resulted in some fun, especially with packages which
use dlopen(3) to load modules. Some recent changes to our ld.so to bring
it more into line with other Operating Systems also exposed some cracks.
+ Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain
the ELF symlinks.
+ Don't mess about with file system entries when handling shared objects in
bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will
have got it right, and have a much better idea than we do.
+ Modify PLISTs to contain "ELF symlinks"
+ On a.out platforms, delete any "ELF symlinks" from the generated PLISTs
+ On ELF platforms, no extra processing needs to be done in bsd.pkg.mk
+ Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on
a.out platforms
+ Update the documentation in Packages.txt
With many thanks to Thomas Klausner for keeping me honest with this.
|
|
executable doesn't exist, as that's the minimum package requirement for
the executable.
|
|
|
|
grautiutiously reinstalled whenever "perl" is reinstalled. For the
NetBSD package, the dependence on autoconf and automake has already
been removed, so it remained only to patch the configure script.
|