For `pkg --version`, Redirect stdin from /dev/null to avoid waiting on
/usr/sbin/pkg's bootstrap prompt if the pkg package is not installed.
Also redirect stderr to /dev/null to discard the warning message in
this case.
Reported by: mjg
Fixes: 4e224e4be7 ("pkgbase: accommodate pkg < 1.17")
Sponsored by: The FreeBSD Foundation
It is more idiomatic. CFLAGS is only augmented with $SSP_CFLAGS when
$MK_SSP != "no".
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31401
Alphabetize and give each option its own line, ahead of making another
change to these lists. This makes future diffs easier to read.
Reviewed by: imp, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31399
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to
enable instrumentation of all binaries with AddressSanitizer and/or
UndefinedBehaviourSanitizer. This current patch is almost sufficient
to get a complete buildworld with sanitizer instrumentation but in
order to actually build and boot a system it depends on a few more
follow-up commits.
Reviewed By: brooks, kib, markj
Differential Revision: https://reviews.freebsd.org/D31043
In some cases `pkg --version` might produce unexpected or additional
output. Use a regex /^[0-9.]+$/ to match only the line containing the
version number.
Reported by: Michael Butler on freebsd-current@
Fixes: 4e224e4be7 ("pkgbase: accommodate pkg < 1.17")
Sponsored by: The FreeBSD Foundation
6cafdee71d adapted the pkgbase build for 1.17, but broke Cirrus-CI's
use of PKG_FORMAT=tar (the quarterly package set still has pkg 1.16).
Because of this I disabled the pkgbase build and test in 2bfba2a04b.
Now, check `pkg --version` and use the old logic for < 1.17.
To be reverted once we no longer encounter pkg 1.16 in Cirrus-CI (i.e.,
via GCP cloud images) to avoid keeping this extra complexity around.
PR: 257422
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31324
In the CVS days this used be a wrapper around either CVS or CVSup and
used to support updating src, doc, and ports checkouts. With the move
to subversion this only supported updating src and was itself a
wrapper around 'svn update'. With Git, users are probably better off
using appropriate Git commands directly to update without needing an
explicit make target as a wrapper.
Reviewed by: bcr, imp, emaste
Differential Revision: https://reviews.freebsd.org/D30736
The jevents build tool will create an empty table if it doesn't find any
events, so we can remove the extra $MACHINE_CPUARCH checks.
Reviewed by: gnn, ray, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30531
Since we don't build and install the terminfo db anymore this is not
needed
This reverts commit b6a51d39e3.
This reverts commit e5e4845959.
This reverts commit 0af562d7e1.
This option has been equivalent to any form of C++ support since libstdc++
was removed. Therefore, replace all MK_LIBCPLUSPLUS uses with MK_CXX.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D27974
WITHOUT_LIBTHR has been broken for a little over five years now, since the
xz 5.2.0 update introduced a hard liblzma dependency on libthr, and building
a useful system without threading support is becoming increasingly more
difficult.
Additionally, in the five plus years that it's been broken more reverse
dependencies have cropped up in libzstd, libsqlite3, and libcrypto (among
others) that make it more and more difficult to reconcile the effort needed
to fix these options.
Remove the broken options.
PR: 252760
Reviewed by: brooks, emaste, kib
Differential Revision: https://reviews.freebsd.org/D28263
If ${REPODIR}/${PKG_ABI} does not exist when we begin real-update-packages,
skip the comparison with the non-existent previous repository and just
finish the repo off. This allows external scripts to just assume they can
run `update-packages` rather than figuring out if they'd previously run
`packages` for this Version/Arch combo.
PKG_VERSION_FROM_DIR was added so that we could perhaps detect the three
distinct cases:
1.) If the repo has not yet been created, PKG_VERSION_FROM_DIR will be
empty.
2.) If the repo is in some intermediate state between created and fully
initialized, PKG_VERSION_FROM_DIR may point to the ABI directory.
3.) If the repo is fully initialized, then PKG_VERSION_FROM_DIR points to
the latest build to compare to.
Option #2 is explicitly unhandled at the moment, but this is no different
than it was before.
Reviewed-by: manu
Differential-Revision: https://reviews.freebsd.org/D28229
The current postfix conversions are:
CURRENT / STABLE / PRERELEASE, 12.x-CURRENT becomes 12.snapYYYYMMDDhhmmss
ALPHAx -> .ax, so 11.3-ALPHA1 becomes 11.3.a1.YYYYMMDDhhmmss
BETAx -> .bx, so 12.1-BETA2 becomes 12.1.b2.YYYYMMDDhhmmss
RCx -> .rcx, so 13.0-RC3 becomes 13.0.rc3.YYYYMMDDhhmmss
RELEASE -> (nothing), so 12.1-RELEASE becomes 12.1
RELEASE-pX -> pX, so 12.1-RELEASE-p1 becomes 12.1p1
Note that for development branches we will start to drop the minor version
component entirely, which more closely matches how these branches are
physically named (stable/NN).
snap is a new prefix that was added to pkg in [0], which is simply a more
verbose version of the current ".s" used.
As noted, build timestamps are also added to ALPHA/BETA/RC versions. This
is largely irrelevant for re@ snapshots because they will only produce one
set of snapshots for each alpha/beta/rc, but external folks may produce
multiple in that timeframe -- at least for alpha. For them, it is
imperative that the builds have a differentiating characteristic like this
rather than multiple builds across multiple revisions being versioned
identically.
[0] https://github.com/freebsd/pkg/pull/1929
Reviewed by: gjb, manu
Submitted by: rene (original, original version)
Differential Revision: https://reviews.freebsd.org/D28167
PKG_ABI is defined in some other targets that do not need to shell out and
calculate PKG_VERSION_FROM. Moreover, it produces extra errors when
bootstrapping an initial pkgbase repo, as the /latest link doesn't exist
yet.
-PRERELEASE exists as a given stable/X branch while the next minor version
release is in progress. From a functional standpoint, it should be treated
as -STABLE since it'll typically be a superset of what's included in the
concurrent releng branch.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D28166
These only get staged off to the side, not installed into the system. Let's
change the default for packages/update-packages to be less surprising.
MFC after: 1 week
Reviewed by: manu, meena <me igalic co>
Differential Revision: https://reviews.freebsd.org/D28190
This reverts commit aef769614f.
While the package names are a bit prettier this confuse pkg about upgrading :
$ pkg version -t 13.0.s2021011313063 13.0.a1
>
$ pkg version -t 13.0.s2021011313063 13.0_ALPHA1
<
Note that the current scheme isn't good when bumping from ALPHA to BETA or
even BETA to RC:
$ pkg version -t 13.0_ALPHA1 13.0_BETA1
=
$ pkg version -t 13.0_BETA1 13.0_RC1
=
But more thoughts have to be put into this renaming.
release/Makefile.inc1 has git executions that were being ran for each of
these lookups. The results were not needed so just lookup what we want
directly instead.
Reviewed by: gjb, rlibby, emaste (maybe)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D27643
As suggested in D27598. This also supports MK_WERROR.clang=no and
MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D27601
I got annoyed by the number of warnings that the CheriBSD build was
emitting. It turns out that we are emitting lots of warnings during
bootstrap because bootstrap tools are built with the default compiler
flags and ignore the warnings flags that are set in bsd.sys.mk.
Looking at git blame, it appears that MK_WARNS=no has been passed since
rS112869, replacing the -DNO_WERROR option that was added in rS87775.
This commit changes MK_WARNS=no back to -DNO_WERROR. We need to pass
-DNO_WERROR, since the system compiler might have new warnings that we
don't know about yet, and we shouldn't fail the build in that case.
Reviewed By: imp, brooks
Differential Revision: https://reviews.freebsd.org/D27598
Having this as part of the bootstrap tools is useful to build disk images
to boot in QEMU (especially when building on a Linux/macOS host where
mkimg is not available). We have been bootstrapping mkimg in CheriBSD for
a long time (using LOCAL_XTOOL_DIRS) but I believe this is also useful
upstream.
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D27602
Only keep the widechar version of ncurses as libncursesw.so.9
Keep the old name to avoid breaking the ABI compatibility (the non
widechar version libncurses.so.9 is not binary compatible with
libncursesw.so.9) since all ports and base are already only linking
against the widechar version we can simply remove libncurses.so.9
Since the .9 version only lived in the dev branch and never ended in a
release, it is simply removed and not added to any binary compat
package.
Add symlinks to keep build time compatibility for anyone linking against
-lncurses
this way, it'll be automatically picked up by poudriere
That's quite handy when building pkgbase!
Submitted by: Mina Galić <me@igalic.co>
Reviewed By: bapt, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D27690
While porting over the local changes from CheriBSD for upstreaming, I
accidentally committed a broken version of find_entry_point(): we have to
return NULL if the value is not found instead of a value with
ep->name == NULL, since the checks in main were changed to check ep instead
of ep->name for NULL.
This only matters if the crunched tool cannot be found using normal lookup
and one of the fallback paths is used, so it's unlikely to be triggered
in rescue. However, I noticed that one of our CheriBSD test scripts was
failing to run commands under `su` on minimal disk images where all
binaries are hardlinks to a `cheribsdbox` tool generated with crunchgen.
This also updates the bootstrapping check in Makefile.inc1 to bootstrap
crunchgen up to the next version bump.
Reviewed By: kevans
Differential Revision: https://reviews.freebsd.org/D27474
Default KERNCONF for powerpc64le should be GENERIC64, and powerpcspe should
select MPC85XXSPE
Reviewed by: bdragon,emaste
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D27257
automatically by tools via /etc/make.conf, so remind people (me) where
to find where it's set..
It would be nice for someone to document what DISTDIR is better than:
where the file for a distribution gets installed
This adds a new target update-packages which will create the new packages
compared to the last run.
This is how to use it:
At this point we cut a release
$ make buildworld ...
$ make buildkernel
$ make packages
There is now a PKG_VERSION directory with latest link pointing to it
Distribute the packages to server
$ something something that update the source tree
$ make buildworld ...
$ make buildkernel
$ make update-packages
You know have a PKG_VERSION directory in the REPODIR and latest link pointing to it.
In PKG_VERSION dir only the packages which differs from the latest run are
named PKG_VERSION, otherwise the old packages are there.
The process is :
Build the new packages in the PKG_VERSION directory
Compare the internal data with the PKG_VERSION_FROM version. The comparison is done
by checking the internal hash of the packages.
By default PKG_VERSION_FROM is set to what the latest link points to.
If the old and new version matches, we rm the new package and cp the old one.
Differential Revision: https://reviews.freebsd.org/D25984
libjail is pretty small, so it makes for a good proof of concept demonstrating
how a system library can be wrapped to create a loadable Lua module for flua.
* Introduce 3lua section for man pages
* Add libjail module
Reviewed by: kevans, manpages
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D26080
It turns out that the majority of the test time for the mkimg tests isn't
mkimg itself but rather the use of jot and hexdump which can be quite slow
on emulated platforms such as QEMU.
On QEMU-RISC-V this reduces the time for `kyua test mkimg_test` from 655
seconds to 200. And for CheriBSD on QEMU-CHERI this saves 4-5 hours (25%
of the time for the entire testsuite!) since jot ends up triggering slow
functions inside the QEMU emulation a lot.
Reviewed By: lwhsu
Differential Revision: https://reviews.freebsd.org/D26796
