* Correct detection of following cases.
non-editline/readline, editline/non-readline, and editline/readline.
* If builtin editline has header files in include/editline, create
include/readline/* symlinks.
* Fix PR pkg/48062 with above fixes. Confirmed on Ubuntu Linux/amd64 13.04.
Many thanks for obache@.
* READLINE_DEFAULT is depends on builtin editline/readline type if possible.
* _READLINE_ACCEPTED is always "editline readline", both are provided.
Tested on OmniOS (builtin readline-6.2; with some modifications) and NetBSD.
XXX If buitin readline is incompatible, READLINE_DEFAULT is set as readline.
According to devel/readline/builtin.mk, SunOS, Darwin, and Interix's
readline is incompatible with GNU readline.
This behavior should be fixed.
Our make(1) now sets $MAKELEVEL. While this should cause no harm, gmake
detects a non-zero $MAKELEVEL and automatically sets "w" in $MAKEFLAGS
for subordinate makes, in order to print the entry and exit directories.
Our make, does not understand -w, so it prints an error message and exits.
In order to catch this everywhere (since cmake for example can invoke
either our make or gmake depending on how it feels), we reset the variable
for any top level command. This effectively reverts to the behavior of
our make not setting $MAKELEVEL.
satisfy the BISON_REQD check, it does not function correctly in the tools
environment when not called as /usr/bin/bison, as it is unable to find its
m4sugar.m4 without BISON_PKGDATADIR being set.
Whilst we could work around that in bison.mk I feel that's something of a
hack, and it is simpler and cleaner to just use the pkgsrc tool instead.
With this change, .include "../../devel/readline/buildlink3.mk" with
USE_GNU_READLINE=yes should be replaced with
.include "../../devel/readline/buildlink3.mk",
and .include "../../devel/readline/buildlink3.mk" without USE_GNU_READLINE
should be replaced .include "../../mk/readline.buildlink3.mk".
USE_GNU_READLINE is removed.
so that they are correctly calculated as independent.
This avoids issues in bulk builds where the package version was taking
precedence and causing the wrong user package to be depended upon.
from 2006 and the OSX bison has been upgraded long since then. In any
case, if the bison is too old, the BISON_REQD check will ensure that a
working version is pulled in if necessary.
Only one compiler is used when "ada" is listed in LANGUAGES, and that
is the one built by the lang/gcc-aux source package. When PKGSRC_COMPILER
is defined as anything else other than "gcc", the Ada packages fail to
build. This can be seen when clang is used with CLANGBASE=${LOCALBASE}.
This straight-forward fix is to override the user specification of
PKGSRC_COMPILER when Ada is specified and define it as "gcc" in all cases.
Tested on NetBSD 6.1 amd64 with CLANGBASE=${LOCALBASE}
Whilst it works for the most part, the mk/extract/extract script expects
an -O flag which it does not support, and adding conditionals to that
script would be messy.
Fixes 5 direct packages.
the package. For f2c, all Fortran 95+ programs are broken and it is
generally not possible to mix output from different Fortran compilers.
Default to g95 for now as fallback compiler.
This is a provisional kludge to work around PR pkg/47838. Sorry for
taking far too long to find a workaround that doesn't break various
other stuff too -- this duration of time was ridiculous, and it was
entirely my fault.
We can get rid of this kludge when we start using `env -i' in the
build phase or when we replace TARGET_ARCH by TARGET_MACHINE_PLATFORM
(and replace the make-internal variable MACHINE_ARCH by
MACHINE_PLATFORM -- that is part of what makes the logic in
pkgformat/pkg/depends.mk and bsd.prefs.mk so fragile). However,
although I intend to do both of these things, they were deemed too
likely to cause too much fallout just before the freeze, so they'll
wait until after the freeze.
and force USE_BUILTIN.pkg=no for packages that depend on packages where
USE_BUILTIN.pkg is no. The names of any such packages are accumulated in
the variable FORCED_PKGSRC for reference; this is currently undocumented
and could be dropped in the future.
This makes it a lot safer to install pkgsrc versions of selected X
libraries without switching wholesale to pkgsrc X; however, other
issues may still exist and caution is still advisable.
As seen on tech-pkg.
Also note: this may affect the builds of packages we don't realize are
affected and that haven't been revbumped. If you find one, let us know
so we can bump its version (or do that yourself) -- most likely this
change will produce in working, properly-linked packages that were
previously broken, but if problems arise please speak up.
1.) It breaks the build of "www/firefox" which gets upset if "SHELL" is
not defined in the environment. There are probably more packages
which similar problems.
2.) It breaks established use case like this one:
export ALLOW_VULNERABLE_PACKAGES=yes
cd pkgsrc/multimedia/ffmpeg2theora
bmake install
In this case the value of "ALLOW_VULNERABLE_PACKAGES" will not be
passed to the build of "pkgsrc/multimedia/ffmpeg". And the build of
this package will fail due to known vulnerabilities.
`install' with USE_DESTDIR=yes.
This changes prevent to unwanted overwite of existing binary packages with
test installation (`stage-install', `replace' & `undo-replace', and so on).
To do both `install' and `package', you can still use `package-install' target,
same as USE_DESTDIR=no.
substitutions will not be correct.
Fixes issue with ABI=64 where /usr/lib/amd64 was being exposed, but
packages will need to be rebuilt for the change to take effect.
however that is not the case. To get that behaviour use ':S/c/ /g'.
Fixes a number of issues on various OPSYS introduced with the recent
COMPILER_* and SYSTEM_DEFAULT_RPATH abstractions.
It is used in limited case, and does not exist by default on some platforms.
proposed at over 30 months ago, and no negative feedback (only one request).
hierarchy.
This values should be generated from output of some commands,
but I cannot find the rule.
Tested on armel and x86_64 Debian GNU/Linux environment.
The values are shown in http://wiki.debian.org/Multiarch/Tuples .
Build depends are target packages that are needed at build-time for,
e.g., static libraries to link against, header files to include, &c.
Tool depends are native packages that are needed at build-time for,
e.g., compilers/linkers/&c. to run.
ok agc
The NATIVE_xyz versions are for packages that build tools that they
run natively but don't end up in the final product.
This is a provisional scheme -- it should be replaced eventually by
something more principled.
ok agc
is also start with "\n", but msgctxt is inserted before it, to avoid msgfmt(1)'s
format mismatch check (`msgid' and `msgstr' entries do not both begin with '\n')
instead of hard-coded /usr/include, /usr/lib, ... paths.
* allow empty BUILDLINK_PREFIX.${_pkg_}, for builtin packags not match such
model (Haiku's system headers and libraries are in different hier).
default value are _OPSYS_INCLUDE_DIRS, _OPSYS_LIB_DIRS and _OPSYS_DEFAULT_RPATH,
defined in mk/platform/${OPSYS}.mk.
(maybe defined with compiler/development tools specific variables).
ghostscript-agpl.
Reverts revisions 1.255 and 1.254
----------------------------
revision 1.255
date: 2013/03/16 23:03:33; author: dholland; state: Exp; lines: +3 -3
print/ghostscript -> print/ghostscript-agpl
----------------------------
revision 1.254
date: 2013/03/16 21:47:14; author: dholland; state: Exp; lines: +13 -3
Choose ghostscript package for ghostscript tools based on whether
gnu-agpl-* is in ACCEPTABLE_LICENSES.
This is mostly the same as the old ghostscript type logic that was
removed in version 1.223.
A major security issue fixed in this release, CVE-2013-1899, makes it possible for a connection request containing a database name that begins with "-" to be crafted that can damage or destroy files within a server's data directory. Anyone with access to the port the PostgreSQL server listens on can initiate this request.
Two lesser security fixes are also included in this release: CVE-2013-1900, wherein random numbers generated by contrib/pgcrypto functions may be easy for another database user to guess, and CVE-2013-1901, which mistakenly allows an unprivileged user to run commands that could interfere with in-progress backups. Finally, this release fixes two security issues with the graphical installers for Linux and Mac OS X: insecure passing of superuser passwords to a script, CVE-2013-1903 and the use of predictable filenames in /tmp CVE-2013-1902.
For Windows Vista or later, executable files including special keywords
(install, update, patch, and so on) in its name are expected as requireing
privileged permissions by default (UAC).
If not, it must be specified with manifest file, or it will be failed to
execute as "Permission denied".
Mac OS X Mountain Lion's "sed" will otherwise reject some patch files
(e.g. "pkgsrc/devel/libcfg+/patches/patch-ab") because of broken
UTF-8 encoding.
It would probably be better not to use the bundled "sed" under
Mac OS X Mountain Lion at all. But it seems that this is not
supported by "pkgsrc" at the moment.
Mac OS X Mountain Lion. "/usr/X11" is only a symbolic link. Use the correct
path because buidlink3 will otherwise filter out "-I/opt/X11/include" which
causes build failures of e.g. the "cairo" package.
- remove LIBXAW variable. It is handled by buildlink3.mk now
- simplify patches and Makefile in packages using libXaw
- in some cases force use of Xaw3d (won't build with Xaw)
- replace some directly included of x11/Xaw3d with mk/xaw.buildlink3.mk
In next part:
- replace more includes with mk/xaw.buildlink3.mk
turned off in www/curl.
Modify the curl package to be aware of the libidn option. Ensure default
is on.
No functional change, so no version number bump.
DragonFly has two compilers in base, GCC 4.4.7 and GCC 4.7.2.
The way one switches between them for userland programs is to set
CCVER in the environment.
However, to set this via make.conf is tricky. I've been using the
low level "ALL_ENV+= CCVER=gcc47", but this trick fails to properly
identify the compiler which results in _GCC_VERSION being incorrectly
defined.
Additionally, there are some prominent packages that do not build on
gcc 4.7 and the fix is either not fully understood or would require a
large amount of work to implement. In these cases, it is desireable
to specify the package be built on gcc 4.4 regardless of CCVER setting.
To address these issues, a new directive is added: DRAGONFLY_CCVER.
It is only effective if OPSYS equals "DragonFly", and it will properly
set CCVER and properly define _GCC_VERSION. It will also allow a
per package specification of a particular compiler in the pkg makefile.
By default pkgsrc uses LOCABASE/gnu as a prefix for packages to install
native versions of GNU tools, which are them symbolically linked back to
the 'g' versions of the files in LOCALBASE, and users can then add
LOCALBASE/gnu/bin to PATH to pick up those tools.
On systems where the GNU environment is desired, PKGGNUDIR now allows
users to install the non-'g' files directly into LOCALBASE, making them
the default without having to alter PATH, whilst retaining the 'g' files
in order to ensure dependencies and tool paths remain the same.
This change modifies the algorithm used to keep track of the files that
have not yet been checksummed to use a simple loop instead of shell pattern
matching.
For packages with few distinfo entries, either way yields the same result
as the list of files to check is very short. But for those packages with
hundreds of distinfo entries (vim, I'm looking at you), the difference is
huge. In my old macppc machine, the checksum of vim used to take around
40 minutes and now it takes ~35 seconds. The difference is also clearly
visible in my faster amd64 machine (although I haven't bothered to time it).
Introduce USE_GCC_RUNTIME for packages which build shared libraries, but
do not use libtool to do so, and add logic to always define _USE_GCC_SHLIB
on Solaris if either USE_LIBTOOL or USE_GCC_RUNTIME are defined. On Solaris,
a non-GNU linker is always used, so this correctly adds a dependency upon the
gcc runtime for those packages.
"yes" or "no" for whether BUILDLINK_{INCDIRS,LIBDIRS,RPATHDIRS}.<pkg>
should automatically be added to the compiler/linker search paths.
Defaults to "yes".
