We're using Ethereal chroot style on Travis CI.
In that chroot style, `uname -m` reports x86_64 even if we're
bootstrapped with i686 systems.
Some i686 build that employ `uname -m` is failing on Travis CI,
e.g: https://travis-ci.org/void-linux/void-packages/jobs/648010517#L5787
Change `uname` output to make Travis Output meaningful for i686.
The new behavior is basically this:
1) Local repos are installed same as before.
2) Multilib configs are now handled only if they exist. They follow
a naming system repos-{local,remote}-ARCH-multilib.conf.
3) Remote repo files follow naming repos-remote-ARCH.conf. If that
does not exist, repos-remote.conf or repos-remote-musl.conf is
used instead (fallback).
4) Cross follows the same behavior, just without multilib.
[ci skip]
That means instead of having a single hostdir/repocache, there
is now hostdir/repocache-$XBPS_TARGET_MACHINE.
This solves multiple problems:
1) When cross-compiling for different architectures and the repos
for host and target differ, you will not get signature/checksum
conflicts for noarch packages.
2) The clean-repocache command will not delete noarch packages that
don't belong to that architecture.
3) Clean mixing of glibc and musl masterdirs with the same hostdir
is now possible; even when building natively, the musl masterdir
will use its repocache-foo-musl, while the glibc masterdir will
use repocache-foo.
[ci skip]
The problem here is that newly introduced behavior in commit
b2b0409be4 resulted in builddir and
destdir *always* being removed when starting a build, as a part of
masterdir auto-update. We don't want this as we may want to resume
a previous build (e.g. by running stages individually or by resuming
a failed build from where it stopped).
Therefore, explicitly override the removal to restore previous behavior.
If `etc/xbps.d/custom` exists (directory) and contains
xbps.d(5) .conf files, those will be copied verbatim
to `masterdir/etc/xbps.d`.
This allows you to set your custom xbps.d(5) settings
without having to modify any other file.
This is also useful for testing xbps.d(5) noextract feature.
Reason: https://gitlab.kitware.com/cmake/cmake/issues/19590
Our workaround within cmake is not sufficient as it does not
address the issue fully and things still break sometimes. So
work around this in the build-style for the time being (and
drop the cmake patch).
Once this is fixed upstream (probably needs special casing
for the -pipe flag and strip it during compile tests) we
can drop this.
There may be /etc/xbps.d/*remote* config files dangling from a previous
run w/o XBPS_SKIP_REMOTEREPOS being set. Make sure to remove them
in case $XBPS_SKIP_REMOTEREPOS is set for this run.
This patchset contains multiple changes to xbps-src and
its required package "base-chroot" for building packages
via chroot.
- moved xbps.d(5) conf files to `etc/xbps.d`.
- renamed xbps.d(5) repository files to `etc/xbps.d/repos-{local,remote}*`.
- do not set `--repository` to any xbps command that supports it,
xbps-src now simply populates `rootdir/etc/xbps.d` with correct
settings (taking care of CHROOT_READY/IN_CHROOT).
- Unless `-C` is set (to preserve builddir/destdir/autodeps), when
entering to the chroot (if CHROOT_READY is set), xbps-src will
clean up the masterdir and then perform a system update to always
use a constant set of packages for that exact date.
- Improved some normal/error msgs.
- Includes support for `xbps>=0.58`.
- common/hooks: switch to bsdtar.
- base-chroot:
- base-chroot-musl is gone, now unified for glibc/musl.
- deps removed: gettext, mpfr, readline, texinfo, which, xz.
- deps changed: tar -> bsdtar.
Effectively this reduces dependencies in `base-chroot`, makes
it unified for musl and glibc, switches xbps-src to use `bsdtar`
rather than GNU `tar` and `xz`, gets rid of useless host dependencies
like GNU gettext, texinfo, etc.
I've been testing these changes for 1 month or so already,
I was able to build from scratch `base-system` for both native
and multiple targets, i.e `./xbps-src -a target -Nt pkg base-system`
- Grepping whole files is inefficient
- git-instaweb (in git package) has the code to generate python file in
a here doc in the middle of its code, old hook generates false
positive with this package
