| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Right now, users who install the pkg-vulnerabilities database find that
the vast majority of packages fail to build, penalizing them too severely.
Package auditing can still be done via "pkg_admin audit".
Alternatively, the previous behaviour can be restored with
ALLOW_VULNERABLE_PACKAGES=no in mk.conf.
Additionally, bmake-ify the check.mk logic. It was easier to do this,
as the package relied on a single long ${RUN} command.
Proposed on tech-pkg, with no objections to the idea of changing the
default, just the method of doing so.
|
|
|
|
|
|
|
|
Seen in cross/arm-none-eabi-gdb.
|
|
|
|
|
|
hashing.
|
|
|
|
This allows bulk builds or other setups to see interesting error
messages, without them being hidden in the noise of "checking ...".
|
|
Before, relative paths had been stored as-is. This affected those
packages that defined PATCHDIR or FILESDIR as relative directory instead
of prefixing it with ${.CURDIR}.
Since there are already several other paths that are interpreted relative
to the package directory (CONFLICTS, DEPENDS), allow PATCHDIR and
FILESDIR to be specified as relative paths, too. This makes the package
Makefiles a bit shorter.
|
|
The rewritten check for unknown configure options already checks for
options that are not defined anywhere. After that, the configure scripts
don't need to check for these options anymore since all remaining options
are known to the package, in at least one of its configure scripts.
|
|
The previous implementation could not reliably detect outdated configure
options. This was apparent in devel/gettext-tools, where the option
--with-included-libcroco had become unknown between May 2019 and May
2020, but the check was not run.
The behavior is the same in the pkgsrc default configuration. Only if
GNU_CONFIGURE_STRICT=yes, the new check is activated and will make
packages fail that previously succeeded to build. Since that variable is
not widely known, there won't be much sudden breakage, if any.
|
|
Like directories, they probably come from shell globs.
Seen in misc/byobu.
|
|
|
|
This makes the SUBST blocks stricter than before, to detect outdated or
unnecessary definitions.
Filename patterns that are not affected by any of the SUBST_SED
expressions make the build fail. It is still ok if only some of the
files from a pattern are affected and some aren't.
The latest bulk build shows that most of the build failures are fixed.
The packages that fail in that build are mostly due to other failures,
like missing C headers, wrong PLIST files, unresolved references at link
time. There may be a few packages that still fail because of this, but
these are near the leaves of the dependency tree.
https://mail-index.netbsd.org/pkgsrc-bulk/2020/05/14/msg018919.html
|
|
Seen in games/bastet. The 1 is not necessary though since it only
repeats the default behavior of sed.
|
|
|
|
|
|
Bulk builds with PKG_DEVELOPER set have been the status quo for a while.
Every package in pkgsrc has to be expected to build with this.
|
|
This variable is used in quite a few places, which makes it interesting
enough, even though it is an implementation detail.
|
|
For example, graphics/openjpeg on SunOS doesn't need it.
|
|
|
|
In a basic regular expression, a dollar-sign only means end-of-string if
it appears at the end of the pattern, or (at the choice of the
implementation) at the end of a \(...\) subexpression.
This affects the package converters/help2man that uses a regular
expression containing a dollar in a non-final position. This regular
expression had not been detected as an identity substitution even though
it is one.
|
|
Since GHC 7.10 or 7.8, the Haskell packages are installed in directories
whose name contains the package hash. This made it harder to predict the
exact pathname. Havin the exact pathnames in the PLIST file is the
ideal, it also helps to record the general structure of the installed
files to see whether some file unexpectedly appear or disappear.
To enable this for Haskell packages, the various base directories are
replaced with placeholders during print-PLIST. These placeholders are
translated back to their respective paths when the +PLIST is generated
from the PLIST in the package directory.
Except for 2 packages, all Haskell packages in main pkgsrc had their
package PLIST file removed. To help in adding them back, the pkgsrc
developer can set HS_UPDATE_PLIST=yes in mk.conf, which will generate the
PLIST directly into ${PKGDIR}/PLIST upon installation.
Most packages in pkgsrc-wip still have their old PLIST, and these are
migrated automatically as well.
|
|
This case can only happen in the following special case:
TOOLS_CREATE+= asdf
TOOLS_PATH.asdf= # empty
If there is a lonely TOOLS_CREATE without a corresponding TOOLS_PATH, it
defaults to ${FALSE} and thus doesn't trigger this code.
|
|
These are needed for the djb-errno-hack option, which includes the <>
characters.
|
|
Locking is not really internal since it has user-settable variables.
|
|
Packages that don't declare USE_TOOLS+=perl and whose configure script
invokes perl produce a warning.
Usually warnings are ignored, but they can also be configured as errors,
for example during a strict bulk build. In this situation it is
necessary to override the default behavior of the perl tool to fail
silently. Up to now, defining both TOOLS_BROKEN+=perl and
TOOLS_FAIL+=perl produced a duplicate make target.
To handle this situation, let TOOLS_BROKEN+=perl take precedence over
TOOLS_FAIL+=perl. This is much easier than finding out in each case how
to disable the perl check in the configure script, which is most often
done by adding any of the following to CONFIGURE_ENV: PERL=#none,
ac_cv_prog_PERL=#none, ac_cv_path_PERL=#none.
|
|
There is no need to include the comments from the shquote function.
|
|
This information is useful for getting the variable name that corresponds
to a tool. In most cases this is just the uppercase name of the tool,
but there are exceptions like ${SETENV} for env, ${HOSTNAME_CMD} for
hostname.
|
|
|
|
|
|
|
|
This fixes the build of converters/help2man in SUBST_NOOP_OK=no mode.
|
|
There are a few portability checks that have been existing for years.
Later additions need an opt-in phase to avoid breaking existing usages.
https://mail-index.netbsd.org/tech-pkg/2020/05/04/msg023084.html
|
|
|
|
A commonly occuring scenario is that a package patches the configure
script, but that the corresponding configure.in contains shell code that
is not portable. In cases like these, configure.in is typically not used
during the build, therefore there is no need to check it for portability.
This also applies to all other combinations where a file is patched and
the corresponding file.in contains unportable shell code.
|
|
There are many .pc files that don't have a "Libs:" line. That is totally
ok, therefore just skip these files.
|
|
|
|
Up to now, the generated warnings were not prefixed with anything.
|
|
|
|
|
|
|
|
Before, "bmake help" only printed the second section of the help topic.
|
|
|
|
|
|
The word "ignore" was too unspecific. There are lines that should be
printed, and there are lines that should be evaluated.
|
|
|
|
|
