Migrated to codeberg

This commit is contained in:
Tracker-Friendly 2023-08-05 21:19:04 +01:00
commit bd2754de65
504 changed files with 36983 additions and 0 deletions

4
.gitattributes vendored Normal file
View File

@ -0,0 +1,4 @@
template linguist-language=bash
common/shlibs merge=union
*.patch whitespace=-space-before-tab,-trailing-space
*.diff whitespace=-space-before-tab,-trailing-space

23
.gitignore vendored Normal file
View File

@ -0,0 +1,23 @@
*.swo
*.swp
*~
\#*#
# exclude everything in root except files and directories from void-packages
/*
!/.gitattributes
!/.github
!/.gitignore
!/.mailmap
!/CONTRIBUTING.md
!/COPYING
!/Manual.md
!/README.md
!/common
!/etc
!/srcpkgs
!/xbps-src
etc/conf
etc/conf.*
etc/virtual
etc/xbps.d/custom

64
.mailmap Normal file
View File

@ -0,0 +1,64 @@
# git mailmap (see git-shortlog(1))
# format: New Name <new@address> Old Name <old@address>
Tracker-Friendly <jliwin98@danwin1210.de> Tracker-Friendly <jliwin98@pm.me>
Andrea Brancaleoni <abc@pompel.me> Andrea Brancaleoni <andrea.brancaleoni@cleafy.com>
Andrea Brancaleoni <abc@pompel.me> Andrea Brancaleoni <miwaxe@gmail.com>
Andrea Brancaleoni <abc@pompel.me> Andrea Brancaleoni <virus@gmx.us>
Andrew Benson <abenson+void@gmail.com> Andrew Benson <abenson@gmail.com>
Andrew Benson <abenson+void@gmail.com> Andrewb Benson <abenson+void@gmail.com>
Cameron Nemo <cam@nohom.org> Cameron Nemo <cnemo@tutanota.com>
Cameron Nemo <cam@nohom.org> Cameron Nemo <camerontnorman@gmail.com>
Dominik Honnef <dominik@honnef.co> Dominik Honnef <dominikh@fork-bomb.org>
Duncaen <duncaen@voidlinux.org> Duncaen <mail@duncano.de>
Duncaen <duncaen@voidlinux.org> Duncan Overbruck <administrator@duncano.de>
Duncaen <duncaen@voidlinux.org> Duncan Overbruck <mail@duncano.de>
Enno Boland <gottox@voidlinux.org> Enno Boland <eb@s01.de>
Enno Boland <gottox@voidlinux.org> Enno Boland <g@s01.de>
Enno Boland <gottox@voidlinux.org> Gottox <g@s01.de>
Jan S <jan.schreib@gmail.com> jan-schreib <jan.schreib@gmail.com>
John Regan <john@jrjrtech.com> John Regan <jregan@mesonet.org>
Jürgen Buchmüller <pullmoll@t-online.de> Juergen Buchmueller <pullmoll@t-online.de>
Leah Neukirchen <leah@vuxu.org> Christian Neukirchen <chneukirchen@gmail.com>
Logen Kain <logen@sudotask.com> Logen Kain <walach.of.harkon@gmail.com>
Michael Aldridge <maldridge@VoidLinux.eu> Michael Aldridge <aldridge.mac@gmail.com>
Philipp Hirsch <itself@hanspolo.net> hanspolo <ph.hanspolo@googlemail.com>
Piraty <mail@piraty.dev> Piraty <piraty@users.noreply.github.com>
Piraty <mail@piraty.dev> Piraty <piraty1@inbox.ru>
Stefan Mühlinghaus <jazzman@alphabreed.com> Stefan Mühlinghaus <muehlinghaus@mmh.ag>
bougyman <bougyman@voidlinux.eu> bougyman <bougyman@rubyists.com>
bougyman <bougyman@voidlinux.eu> bougyman <bougyman@users.noreply.github.com>
bougyman <bougyman@voidlinux.eu> bougyman <tj@rubyists.com>
chrome-pepper-bot <eb@s01.de> Enno Boland (bot) <g@s01.de>
onekk <carlo.dormeletti@email.it> onekk <carlo.dormeletti@alice.it>
pancake <pancake@nopcode.org> pancake <pancake@flubox.(none)>
pancake <pancake@nopcode.org> radare <pancake@nopcode.org>
xdave <davehome@redthumb.info.tm> davehome <davehome@redthumb.info.tm>
yopito <pierre.bourgin@free.fr> yopito <yopito@users.noreply.github.com>
Duncaen <duncaen@voidlinux.org> Duncaen <duncaen@voidlinux.eu>
Enno Boland <gottox@voidlinux.org> Enno Boland <gottox@voidlinux.eu>
Juan RP <xtraeme@voidlinux.org> Juan RP <xtraeme@voidlinux.eu>
Toyam Cox <Vaelatern@voidlinux.org> Toyam Cox <Vaelatern@voidlinux.eu>
ananteris <ananteris@voidlinux.org> ananteris <ananteris@voidlinux.eu>
bougyman <bougyman@voidlinux.org> bougyman <bougyman@voidlinux.eu>
Rasmus Thomsen <oss@cogitri.dev> Rasmus Thomsen <rasmus.thomsen@protonmail.com>
Rasmus Thomsen <oss@cogitri.dev> Rasmus Thomsen <cogitri@exherbo.org>
Renato Aguiar <renato@renatoaguiar.net> Renato Aguiar <renato@renag.me>
Renato Aguiar <renato@renatoaguiar.net> Renato Aguiar <contact@renatoaguiar.org>
Renato Aguiar <renato@renatoaguiar.net> Renato Aguiar <renato@aguiar.info>
Đoàn Trần Công Danh <congdanhqx@gmail.com> <congdanhqx+sgn@gmail.com>
Đoàn Trần Công Danh <congdanhqx@gmail.com> Doan Tran Cong Danh <congdanhqx@gmail.com>
John <me@johnnynator.dev> John <johnz@posteo.net>
John <me@johnnynator.dev> John Zimmermann <johnz@posteo.net>
Daniel Kolesa <daniel@octaforge.org> q66 <daniel@octaforge.org>
teldra <teldra@rotce.de> Teldra <teldra@rotce.de>
teldra <teldra@rotce.de> xor <aur@rotce.de>
Andrew J. Hesford <ajh@sideband.org> Andrew J. Hesford <ahesford@gleason.com>
howtologinquickwiththirtyninecharacters <howtologinquickwiththirtyninecharacters@users.noreply.github.com> It looks like the profile name is limited to 256 characters, just like most error messages here it says 255 characters but we know better, do we? As usual, let's try to fill it with meaningless words about nothing at all. Maybe I can reach its limit. End <61999526+howtologinquickwiththirtyninecharacters@users.noreply.github.com>
Érico Nogueira <erico.erc@gmail.com> Érico Rolim <erico.erc@gmail.com>
Adam Gausmann <adam@gaussian.dev> Adam Gausmann <agausmann@fastmail.com>

207
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,207 @@
# Contributing to evolution-packages
evolution-packages is the backbone of the Evolution Linux distribution. It contains all the definitions to build packages from source.
This document describes how you, as a contributor, can help with adding packages, correcting bugs and adding features to evolution-packages.
## Package Requirements
To be included in the evolution repository, software must meet at least one of the following requirements.
Exceptions to the list are possible, and might be accepted, but are extremely unlikely.
If you believe you have an exception, start a PR and make an argument for why that particular piece of software,
while not meeting any of the following requirements, is a good candidate for the evolution packages system.
1. **System**: The software should be installed system-wide, not per-user.
1. **Compiled**: The software needs to be compiled before being used, even if it is software that is not needed by the whole system.
1. **Required**: Another package either within the repository or pending inclusion requires the package.
In particular, new themes are highly unlikely to be accepted.
Simple shell scripts are unlikely to be accepted unless they provide considerable value to a broad user base.
New fonts may be accepted if they provide value beyond aesthetics (e.g. they contain glyphs for a script missing in already packaged fonts).
Packages related to cryptocurrencies (wallets, miners, nodes, etc) are not accepted.
Browser forks, including those based on Chromium and Firefox, are generally not accepted.
Such forks require heavy patching, maintenance and hours of build time.
Software need to be used in version announced by authors as ready to use by the general public - usually called releases.
Betas, arbitrary VCS revisions, templates using tip of development branch taken at build time and releases created by the package maintainer won't be accepted.
## Creating, updating, and modifying packages in evolution by yourself
If you really want to get a new package or package update into evolution Linux, we recommend you contribute it yourself.
We provide a [comprehensive Manual](./Manual.md) on how to create new packages.
There's also a [manual for xbps-src](./README.md), which is used to build package files from templates.
For this guide, we assume you have basic knowledge about [git](http://git-scm.org), as well as a [GitHub Account](http://github.com) with [SSH set up](https://docs.github.com/en/authentication/connecting-to-github-with-ssh).
You should also [set the email](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address) on your GitHub account and in git so your commits are associated with your GitHub account properly.
To get started, [fork](https://help.github.com/articles/fork-a-repo) the evolution-linux `evolution-packages` git repository on GitHub and clone it:
$ git clone git@github.com:<user>/evolution-packages.git
To keep your forked repository up to date, setup the `upstream` remote to pull in new changes:
$ git remote add upstream https://github.com/evolution-linux/evolution-packages.git
$ git pull --rebase upstream master
This can also be done with the `github-cli` tool:
$ gh repo fork evolution-linux/evolution-packages
$ gh repo clone <user>/evolution-packages
This automatically sets up the `upstream` remote, so `git pull --rebase upstream master` can still be used to keep your fork up-to-date.
Using the GitHub web editor for making changes is strongly discouraged, because you will need to clone the repo anyways to edit and test your changes.
Using the `master` branch of your fork for contributing is also strongly discouraged.
It can cause many issues with updating your pull request (also called a PR), and having multiple PRs open at once.
To create a new branch:
$ git checkout master -b <a-descriptive-name>
### Creating a new template
You can use the helper tool `xnew`, from the [xtools](https://github.com/leahneukirchen/xtools) package, to create new templates:
$ xnew pkgname subpkg1 subpkg2 ...
Templates must have the name `evolution-packages/srcpkgs/<pkgname>/template`, where `pkgname` is the same as the `pkgname` variable in the template.
For deeper insights on the contents of template files, please read the [manual](./Manual.md), and be sure to browse the existing template files in the `srcpkgs` directory of this repository for concrete examples.
### Updating a template
At minimum, a template update will consist of changing `version` and `checksum`, if there was an upstream version change, and/or `revision`, if a template-specific change (e.g. patch, correction, etc.) is needed.
Other changes to the template may be needed depending on what changes the upstream has made.
The checksum can be updated automatically with the `xgensum` helper from the [xtools](https://github.com/leahneukirchen/xtools) package:
$ xgensum -i <pkgname>
### Committing your changes
After making your changes, please check that the package builds successfully. From the top level directory of your local copy of the `evolution-packages` repository, run:
$ ./xbps-src pkg <pkgname>
Your package must build successfully for at least x86, but we recommend also trying a cross-build for armv6l* as well, e.g.:
$ ./xbps-src -a armv6l pkg <pkgname>
When building for `x86_64*` or `i686`, building with the `-Q` flag or with `XBPS_CHECK_PKGS=yes` set in `etc/conf` (to run the check phase) is strongly encouraged.
Also, new packages and updates will not be accepted unless they have been runtime tested by installing and running the package.
When you've finished working on the template file, please check it with `xlint` helper from the [xtools](https://github.com/leahneukirchen/xtools) package:
$ xlint template
If `xlint` reports any issues, resolve them before committing.
Once you have made and verified your changes to the package template and/or other files, make one commit per package (including all changes to its sub-packages). Each commit message should have one of the following formats:
* for new packages, use `New package: <pkgname>-<version>` ([example](https://github.com/evolution-linux/evolution-packages/commit/8ed8d41c40bf6a82cf006c7e207e05942c15bff8)).
* for package updates, use `<pkgname>: update to <version>.` ([example](https://github.com/evolution-linux/evolution-packages/commit/c92203f1d6f33026ae89f3e4c1012fb6450bbac1)).
* for template modifications without a version change, use `<pkgname>: <reason>` ([example](https://github.com/evolution-linux/evolution-packages/commit/ff39c912d412717d17232de9564f659b037e95b5)).
* for package removals, use `<pkgname>: remove package` and include the removal reason in the commit body ([example](https://github.com/evolution-linux/evolution-packages/commit/4322f923bdf5d4e0eb36738d4f4717d72d0a0ca4)).
* for changes to any other file, use `<filename>: <reason>` ([example](https://github.com/evolution-linux/evolution-packages/commit/e00bea014c36a70d60acfa1758514b0c7cb0627d),
[example](https://github.com/evolution-linux/evolution-packages/commit/93bf159ce10d8e474da5296e5bc98350d00c6c82), [example](https://github.com/evolution-linux/evolution-packages/commit/dc62938c67b66a7ff295eab541dc37b92fb9fb78), [example](https://github.com/evolution-linux/evolution-packages/commit/e52317e939d41090562cf8f8131a68772245bdde))
If you want to describe your changes in more detail, explain in the commit body (separated from the first line with a blank line) ([example](https://github.com/evolution-linux/evolution-packages/commit/f1c45a502086ba1952f23ace9084a870ce437bc6)).
`xbump`, available in the [xtools](https://github.com/leahneukirchen/xtools) package, can be used to commit a new or updated package:
$ xbump <pkgname> <git commit options>
`xrevbump`, also available in the [xtools](https://github.com/leahneukirchen/xtools) package, can be used to commit a template modification for a package:
$ xrevbump '<message>' <pkgnames...>
`xbump` and `xrevbump` will use `git commit` to commit the changes with the appropriate commit message. For more fine-grained control over the commit, specific options can be passed to `git commit` by adding them after the package name.
### Starting a pull request
Once you have successfully built the package, you can [create a pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request). Pull requests are also known as PRs.
Most pull requests should only contain a single package and dependencies which are not part of evolution-packages yet.
If you make updates to packages containing a soname bump, you also need to update `common/shlibs` and revbump all packages that are dependant.
There should be a commit for each package revbump, and those commits should be part of the same pull request.
When you make changes to your pull request, please *do not close and reopen your pull request*. Instead, just [forcibly git push](#review), overwriting any old commits. Closing and opening your pull requests repeatedly spams the evolution maintainers.
#### Continuous Integration
Pull requests are automatically submitted for Continuous Integration (CI) testing to ensure packages build and pass their tests (on native builds) on various combinations of C library and architecture.
Packages that take longer than 120 minutes or need more than 14G of storage to complete their build (for example, Firefox or the Linux kernel) will fail CI and should include `[ci skip]` in the PR title or body (the comment field when the PR is being opened) to stray from wasting CI builder time.
Use your best judgment on build times based on your local building experience. If you skip CI when submitting a PR, please build and cross-build for a variety of architectures locally, with both glibc and musl, and note your local results in PR comments.
Make sure to cover 64-bit and 32-bit architectures.
If you notice a failure in CI that didn't happen locally, that is likely because you didn't run tests locally.
Use `./xbps-src -Q pkg <package>` to do so.
Some tests won't work in the CI environment or at all, and their templates should encode this information using the `make_check` variable.
Continuous Integration will also check if the templates you have changed
comply with the our guidelines. At the moment not all packages comply with the rules, so if you update a package, it may report errors about places you haven't touched. Please feel free to fix those errors too.
#### Review
It's possible (and common) that a pull request will contain mistakes or reviewers will ask for additional tweaks.
Reviewers will comment on your pull request and point out which changes are needed before the pull request can be merged.
Most PRs will have a single commit, as seen [above](#committing-your-changes), so if you need to make changes to the commit and already have a pull request open, you can use the following commands:
$ git add <file>
$ git commit --amend
$ git push -f
A more powerful way of modifying commits than using `git commit --amend` is with [git-rebase](https://git-scm.com/docs/git-rebase#_interactive_mode), which allows you to join, reorder, change description of past commits and more.
Alternatively, if there are issues with your git history, you can make another branch and push it to the existing PR:
$ git checkout master -b <attempt2>
$ # do changes anew
$ git push -f <fork> <attempt2>:<branch-of-pr>
#### Closing the pull request
Once you have applied all requested changes, the reviewers will merge your request.
If the pull request becomes inactive for some days, the reviewers may or may not warn you when they are about to close it.
If it stays inactive further, it will be closed.
Please abstain from temporarily closing a pull request while revising the templates. Instead, leave a comment on the PR describing what still needs work, [mark it as a draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#converting-a-pull-request-to-a-draft), or add "[WIP]" to the PR title. Only close your pull request if you're sure you don't want your changes to be included.
#### Publishing the package
Once the reviewers have merged the pull request, our [build server](http://build.evolutionlinux.org) is automatically triggered and builds
all packages in the pull request for all supported platforms. Upon completion, the packages are available to all evolution Linux users.
## Testing Pull Requests
While it is the responsibility of the PR creator to test changes before sending it, one person can't test all configuration options, usecases, hardware, etc.
Testing new package submissions and updates is always helpful, and is a great way to get started with contributing.
First, [clone the repository](https://github.com/evolution-linux/evolution-packages#quick-start) if you haven't done so already.
Then check out the pull request, either with `github-cli`:
$ gh pr checkout <number>
Or with `git`:
If your local evolution-packages repository is cloned from your fork, you may need to add the main repository as a remote first:
$ git remote add upstream https://github.com/evolution-linux/evolution-packages.git
Then fetch and check out the PR (replacing `<remote>` with either `origin` or `upstream`):
$ git fetch <remote> pull/<number>/head:<branch-name>
$ git checkout <branch-name>
Then [build and install](https://github.com/evolution-linux/evolution-packages#building-packages) the package and test its functionality.

23
COPYING Normal file
View File

@ -0,0 +1,23 @@
Copyright (c) 2008-2020 Juan Romero Pardines and contributors
Copyright (c) 2017-2023 The Void Linux team and contributors
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

1
Manual.md Normal file
View File

@ -0,0 +1 @@
Evolution Linux cannot be bothered to ship with a custom Manual. If you want one, look up the one on the void website, and use that brain of your to figure stuff out. The only major difference is that evolution uses 2 main XBPS repos.

507
README.md Normal file
View File

@ -0,0 +1,507 @@
## The XBPS source packages collection
This repository contains the XBPS source packages collection to build binary packages
for the Evolution Linux distribution.
The included `xbps-src` script will fetch and compile the sources, and install its
files into a `fake destdir` to generate XBPS binary packages that can be installed
or queried through the `xbps-install(1)` and `xbps-query(1)` utilities, respectively.
See [Contributing](./CONTRIBUTING.md) for a general overview of how to contribute and the
[Manual](./Manual.md) for details of how to create source packages.
### Table of Contents
- [Requirements](#requirements)
- [Quick start](#quick-start)
- [chroot methods](#chroot-methods)
- [Install the bootstrap packages](#install-bootstrap)
- [Configuration](#configuration)
- [Directory hierarchy](#directory-hierarchy)
- [Building packages](#building-packages)
- [Package build options](#build-options)
- [Sharing and signing your local repositories](#sharing-and-signing)
- [Rebuilding and overwriting existing local packages](#rebuilding)
- [Enabling distcc for distributed compilation](#distcc)
- [Distfiles mirrors](#distfiles-mirrors)
- [Cross compiling packages for a target architecture](#cross-compiling)
- [Using xbps-src in a foreign Linux distribution](#foreign)
- [Remaking the masterdir](#remaking-masterdir)
- [Keeping your masterdir uptodate](#updating-masterdir)
- [Building 32bit packages on x86_64](#building-32bit)
- [Building packages natively for the musl C library](#building-for-musl)
- [Building evolution base-system from scratch](#building-base-system)
### Requirements
- GNU bash
- xbps >= 0.56
- git(1) - unless configured to not, see etc/defaults.conf
- common POSIX utilities included by default in almost all UNIX systems
- curl(1) - required by `xbps-src update-check`
For bootstrapping additionally:
- flock(1) - util-linux
- bsdtar or GNU tar (in that order of preference)
- install(1) - GNU coreutils
- objcopy(1), objdump(1), strip(1): binutils
`xbps-src` requires [a utility to chroot](#chroot-methods) and bind mount existing directories
into a `masterdir` that is used as its main `chroot` directory. `xbps-src` supports
multiple utilities to accomplish this task.
> NOTE: `xbps-src` does not allow building as root anymore. Use one of the chroot
methods.
<a name="quick-start"></a>
### Quick start
Clone the `evolution-packages` git repository and install the bootstrap packages:
```
$ git clone https://github.com/evolution-linux/evolution-packages.git
$ cd evolution-packages
$ ./xbps-src binary-bootstrap
```
Build a package by specifying the `pkg` target and the package name:
```
$ ./xbps-src pkg <package_name>
```
Use `./xbps-src -h` to list all available targets and options.
To build packages marked as 'restricted', modify `etc/conf`:
```
$ echo XBPS_ALLOW_RESTRICTED=yes >> etc/conf
```
Once built, the package will be available in `hostdir/binpkgs` or an appropriate subdirectory (e.g. `hostdir/binpkgs/nonfree`). To install the package:
```
# xbps-install --repository hostdir/binpkgs <package_name>
```
Alternatively, packages can be installed with the `xi` utility, from the `xtools` package. `xi` takes the repository of the current working directory into account.
```
# xi <package_name>
```
<a name="chroot-methods"></a>
### chroot methods
#### xbps-uunshare(1) (default)
XBPS utility that uses `user_namespaces(7)` (part of xbps, default without `-t` flag).
This utility requires these Linux kernel options:
- CONFIG\_NAMESPACES
- CONFIG\_IPC\_NS
- CONFIG\_UTS\_NS
- CONFIG\_USER\_NS
This is the default method, and if your system does not support any of the required kernel
options it will fail with `EINVAL (Invalid argument)`.
#### xbps-uchroot(1)
XBPS utility that uses `namespaces` and must be `setgid` (part of xbps).
> NOTE: This is the only method that implements functionality of `xbps-src -t`, therefore the
flag ignores the choice made in configuration files and enables `xbps-uchroot`.
This utility requires these Linux kernel options:
- CONFIG\_NAMESPACES
- CONFIG\_IPC\_NS
- CONFIG\_PID\_NS
- CONFIG\_UTS\_NS
Your user must be added to a special group to be able to use `xbps-uchroot(1)` and the
executable must be `setgid`:
# chown root:<group> xbps-uchroot
# chmod 4750 xbps-uchroot
# usermod -a -G <group> <user>
> NOTE: by default in evolution you shouldn't do this manually, your user must be a member of
the `xbuilder` group.
To enable it:
$ cd evolution-packages
$ echo XBPS_CHROOT_CMD=uchroot >> etc/conf
If for some reason it's erroring out as `ERROR clone (Operation not permitted)`, check that
your user is a member of the required `group` and that `xbps-uchroot(1)` utility has the
proper permissions and owner/group as explained above.
#### bwrap(1)
bubblewrap, sandboxing tool for unprivileged users that uses
user namespaces or setuid.
See <https://github.com/containers/bubblewrap>.
#### ethereal
Destroys host system it runs on. Only useful for one-shot containers, i.e docker (used with CI).
<a name="install-bootstrap"></a>
### Install the bootstrap packages
There is a set of packages that makes up the initial build container, called the `bootstrap`.
These packages are installed into the `masterdir` in order to create the container.
The primary and recommended way to set up this container is using the `binary-bootstrap`
command. This will use pre-existing binary packages, either from remote `xbps` repositories
or from your local repository.
There is also the `bootstrap` command, which will build all necessary `bootstrap` packages from
scratch. This is usually not recommended, since those packages are built using your host system's
toolchain and are neither fully featured nor reproducible (your host system may influence the
build) and thus should only be used as a stage 0 for bootstrapping new Evolution systems.
If you still choose to use `bootstrap`, use the resulting stage 0 container to rebuild all
`bootstrap` packages again, then use `binary-bootstrap` (stage 1) and rebuild the `bootstrap`
packages once more (to gain stage 2, and then use `binary-bootstrap` again). Once you've done
that, you will have a `bootstrap` set equivalent to using `binary-bootstrap` in the first place.
Also keep in mind that a full source `bootstrap` is time consuming and will require having an
assortment of utilities installed in your host system, such as `binutils`, `gcc`, `perl`,
`texinfo` and others.
### Configuration
The `etc/defaults.conf` file contains the possible settings that can be overridden
through the `etc/conf` configuration file for the `xbps-src` utility; if that file
does not exist, will try to read configuration settings from `$XDG_CONFIG_HOME/xbps-src.conf`, `~/.config/xbps-src.conf`, `~/.xbps-src.conf`.
If you want to customize default `CFLAGS`, `CXXFLAGS` and `LDFLAGS`, don't override
those defined in `etc/defaults.conf`, set them on `etc/conf` instead i.e:
$ echo 'XBPS_CFLAGS="your flags here"' >> etc/conf
$ echo 'XBPS_LDFLAGS="your flags here"' >> etc/conf
Native and cross compiler/linker flags are set per architecture in `common/build-profiles`
and `common/cross-profiles` respectively. Ideally those settings are good enough by default,
and there's no need to set your own unless you know what you are doing.
#### Virtual packages
The `etc/defaults.virtual` file contains the default replacements for virtual packages,
used as dependencies in the source packages tree.
If you want to customize those replacements, copy `etc/defaults.virtual` to `etc/virtual`
and edit it accordingly to your needs.
<a name="directory-hierarchy"></a>
### Directory hierarchy
The following directory hierarchy is used with a default configuration file:
/evolution-packages
|- common
|- etc
|- srcpkgs
| |- xbps
| |- template
|
|- hostdir
| |- binpkgs ...
| |- ccache ...
| |- distcc-<arch> ...
| |- repocache ...
| |- sources ...
|
|- masterdir
| |- builddir -> ...
| |- destdir -> ...
| |- host -> bind mounted from <hostdir>
| |- evolution-packages -> bind mounted from <evolution-packages>
The description of these directories is as follows:
- `masterdir`: master directory to be used as rootfs to build/install packages.
- `builddir`: to unpack package source tarballs and where packages are built.
- `destdir`: to install packages, aka **fake destdir**.
- `hostdir/ccache`: to store ccache data if the `XBPS_CCACHE` option is enabled.
- `hostdir/distcc-<arch>`: to store distcc data if the `XBPS_DISTCC` option is enabled.
- `hostdir/repocache`: to store binary packages from remote repositories.
- `hostdir/sources`: to store package sources.
- `hostdir/binpkgs`: local repository to store generated binary packages.
<a name="building-packages"></a>
### Building packages
The simplest form of building package is accomplished by running the `pkg` target in `xbps-src`:
```
$ cd evolution-packages
$ ./xbps-src pkg <pkgname>
```
When the package and its required dependencies are built, the binary packages will be created
and registered in the default local repository at `hostdir/binpkgs`; the path to this local repository can be added to
any xbps configuration file (see xbps.d(5)) or by explicitly appending them via cmdline, i.e:
$ xbps-install --repository=hostdir/binpkgs ...
$ xbps-query --repository=hostdir/binpkgs ...
By default **xbps-src** will try to resolve package dependencies in this order:
- If a dependency exists in the local repository, use it (`hostdir/binpkgs`).
- If a dependency exists in a remote repository, use it.
- If a dependency exists in a source package, use it.
It is possible to avoid using remote repositories completely by using the `-N` flag.
> The default local repository may contain multiple *sub-repositories*: `debug`, `multilib`, etc.
<a name="build-options"></a>
### Package build options
The supported build options for a source package can be shown with `xbps-src show-options`:
$ ./xbps-src show-options foo
Build options can be enabled with the `-o` flag of `xbps-src`:
$ ./xbps-src -o option,option1 pkg foo
Build options can be disabled by prefixing them with `~`:
$ ./xbps-src -o ~option,~option1 pkg foo
Both ways can be used together to enable and/or disable multiple options
at the same time with `xbps-src`:
$ ./xbps-src -o option,~option1,~option2 pkg foo
The build options can also be shown for binary packages via `xbps-query(1)`:
$ xbps-query -R --property=build-options foo
> NOTE: if you build a package with a custom option, and that package is available
in an official void / evolution repository, an update will ignore those options. Put that package
on `hold` mode via `xbps-pkgdb(1)`, i.e `xbps-pkgdb -m hold foo` to ignore updates
with `xbps-install -u`. Once the package is on `hold`, the only way to update it
is by declaring it explicitly: `xbps-install -u foo`.
Permanent global package build options can be set via `XBPS_PKG_OPTIONS` variable in the
`etc/conf` configuration file. Per package build options can be set via
`XBPS_PKG_OPTIONS_<pkgname>`.
> NOTE: if `pkgname` contains `dashes`, those should be replaced by `underscores`
i.e `XBPS_PKG_OPTIONS_xorg_server=opt`.
The list of supported package build options and its description is defined in the
`common/options.description` file or in the `template` file.
<a name="sharing-and-signing"></a>
### Sharing and signing your local repositories
To share a local repository remotely it's mandatory to sign it and the binary packages
stored on it. This is accomplished with the `xbps-rindex(1)` utility.
First a RSA key must be created with `openssl(1)` or `ssh-keygen(1)`:
$ openssl genrsa -des3 -out privkey.pem 4096
or
$ ssh-keygen -t rsa -b 4096 -m PEM -f privkey.pem
> Only RSA keys in PEM format are currently accepted by xbps.
Once the RSA private key is ready you can use it to initialize the repository metadata:
$ xbps-rindex --sign --signedby "I'm Groot" --privkey privkey.pem $PWD/hostdir/binpkgs
And then make a signature per package:
$ xbps-rindex --sign-pkg --privkey privkey.pem $PWD/hostdir/binpkgs/*.xbps
> If --privkey is unset, it defaults to `~/.ssh/id_rsa`.
If the RSA key was protected with a passphrase you'll have to type it, or alternatively set
it via the `XBPS_PASSPHRASE` environment variable.
Once the binary packages have been signed, check if the repository contains the appropriate `hex fingerprint`:
$ xbps-query --repository=hostdir/binpkgs -vL
...
Each time a binary package is created, a package signature must be created with `--sign-pkg`.
> It is not possible to sign a repository with multiple RSA keys.
<a name="rebuilding"></a>
### Rebuilding and overwriting existing local packages
Packages are overwritten on every build to make getting package with changed build options easy.
To make xbps-src skip build and preserve first package build with given version and revision,
same as in official void / evolution repository, set `XBPS_PRESERVE_PKGS=yes` in `etc/conf` file.
Reinstalling a package in your target `rootdir` can be easily done too:
$ xbps-install --repository=/path/to/local/repo -yf xbps-0.25_1
Using `-f` flag twice will overwrite configuration files.
> Please note that the `package expression` must be properly defined to explicitly pick up
the package from the desired repository.
<a name="distcc"></a>
### Enabling distcc for distributed compilation
Setup the slaves (machines that will compile the code):
# xbps-install -Sy distcc
Modify the configuration to allow your local network machines to use distcc (e.g. `192.168.2.0/24`):
# echo "192.168.2.0/24" >> /etc/distcc/clients.allow
Enable and start the `distccd` service:
# ln -s /etc/sv/distccd /var/service
Install distcc on the host (machine that executes xbps-src) as well.
Unless you want to use the host as slave from other machines, there is no need
to modify the configuration.
On the host you can now enable distcc in the `evolution-packages/etc/conf` file:
XBPS_DISTCC=yes
XBPS_DISTCC_HOSTS="localhost/2 --localslots_cpp=24 192.168.2.101/9 192.168.2.102/2"
XBPS_MAKEJOBS=16
The example values assume a localhost CPU with 4 cores of which at most 2 are used for compiler jobs.
The number of slots for preprocessor jobs is set to 24 in order to have enough preprocessed data for other CPUs to compile.
The slave 192.168.2.101 has a CPU with 8 cores and the /9 for the number of jobs is a saturating choice.
The slave 192.168.2.102 is set to run at most 2 compile jobs to keep its load low, even if its CPU has 4 cores.
The XBPS_MAKEJOBS setting is increased to 16 to account for the possible parallelism (2 + 9 + 2 + some slack).
<a name="distfiles-mirrors"></a>
### Distfiles mirror(s)
In etc/conf you may optionally define a mirror or a list of mirrors to search for distfiles.
$ echo 'XBPS_DISTFILES_MIRROR="ftp://192.168.100.5/gentoo/distfiles"' >> etc/conf
If more than one mirror is to be searched, you can either specify multiple URLs separated
with blanks, or add to the variable like this. Remeber, offically, Evolution Linux uses 2 REPOS. This means not all packages are included.
$ echo 'XBPS_DISTFILES_MIRROR+=" https://sources.voidlinux.org/"' >> etc/conf
Make sure to put the blank after the first double quote in this case.
The mirrors are searched in order for the distfiles to build a package until the
checksum of the downloaded file matches the one specified in the template.
Ultimately, if no mirror carries the distfile, or in case all downloads failed the
checksum verification, the original download location is used.
If you use `uchroot` for your XBPS_CHROOT_CMD, you may also specify a local path
using the `file://` prefix or simply an absolute path on your build host (e.g. /mnt/distfiles).
Mirror locations specified this way are bind mounted inside the chroot environment
under $XBPS_MASTERDIR and searched for distfiles just the same as remote locations.
<a name="cross-compiling"></a>
### Cross compiling packages for a target architecture
Currently `xbps-src` can cross build packages for some target architectures with a cross compiler.
The supported target is shown with `./xbps-src -h`.
If a source package has been adapted to be **cross buildable** `xbps-src` will automatically build the binary package(s) with a simple command:
$ ./xbps-src -a <target> pkg <pkgname>
If the build for whatever reason fails, might be a new build issue or simply because it hasn't been adapted to be **cross compiled**.
<a name="foreign"></a>
### Using xbps-src in a foreign Linux distribution
xbps-src can be used in any recent Linux distribution matching the CPU architecture.
To use xbps-src in your Linux distribution use the following instructions. Let's start downloading the xbps static binaries:
$ wget http://repo-default.voidlinux.org/static/xbps-static-latest.<arch>-musl.tar.xz
$ mkdir ~/XBPS
$ tar xvf xbps-static-latest.<arch>-musl.tar.xz -C ~/XBPS
$ export PATH=~/XBPS/usr/bin:$PATH
If `xbps-uunshare` does not work because of lack of `user_namespaces(7)` support,
try other [chroot methods](#chroot-methods).
Clone the `evolution-packages` git repository:
$ git clone https://github.com/evolution-linux/evolution-packages.git
and `xbps-src` should be fully functional; just start the `bootstrap` process, i.e:
$ ./xbps-src binary-bootstrap
The default masterdir is created in the current working directory, i.e `evolution-packages/masterdir`.
<a name="remaking-masterdir"></a>
### Remaking the masterdir
If for some reason you must update xbps-src and the `bootstrap-update` target is not enough, it's possible to recreate a masterdir with two simple commands (please note that `zap` keeps your `ccache/distcc/host` directories intact):
$ ./xbps-src zap
$ ./xbps-src binary-bootstrap
<a name="updating-masterdir"></a>
### Keeping your masterdir uptodate
Sometimes the bootstrap packages must be updated to the latest available version in repositories, this is accomplished with the `bootstrap-update` target:
$ ./xbps-src bootstrap-update
<a name="building-32bit"></a>
### Building 32bit packages on x86_64
Two ways are available to build 32bit packages on x86\_64:
- native mode with a 32bit masterdir (recommended, used in official repository)
- cross compilation mode to i686 [target](#cross-compiling)
The canonical mode (native) needs a new x86 `masterdir`:
$ ./xbps-src -m masterdir-x86 binary-bootstrap i686
$ ./xbps-src -m masterdir-x86 ...
<a name="building-for-musl"></a>
### Building packages natively for the musl C library
Canonical way of building packages for same architecture but different C library is through dedicated masterdir.
To build for x86_64-musl on glibc x86_64 system, prepare a new masterdir with the musl packages:
$ ./xbps-src -m masterdir-x86_64-musl binary-bootstrap x86_64-musl
Your new masterdir is now ready to build packages natively for the musl C library:
$ ./xbps-src -m masterdir-x86_64-musl pkg ...
<a name="building-base-system"></a>
### Building evolution base-system from scratch
To rebuild all packages in `base-system` for your native architecture:
$ ./xbps-src -N pkg base-system
It's also possible to cross compile everything from scratch:
$ ./xbps-src -a <target> -N pkg base-system
Once the build has finished, you can specify the path to the local repository to `void-mklive`, i.e:
# cd void-mklive
# make
# ./mklive.sh ... -r /path/to/hostdir/binpkgs

View File

@ -0,0 +1,6 @@
if [ "$CROSS_BUILD" ]; then
export WX_CONFIG=${XBPS_WRAPPERDIR}/wx-config-gtk3
else
export WX_CONFIG=/usr/bin/wx-config-gtk3
fi
configure_args+=" -DwxWidgets_CONFIG_EXECUTABLE=${WX_CONFIG} "

View File

@ -0,0 +1,42 @@
#
# gir - build-helper for gobject-introspection
#
# This build-helper is used for packages that make use of
# the GObject introspection middleware layer.
#
# Check if the 'gir' build_option is set or if there is no
# 'gir' build_option.
if [ "$build_option_gir" ] || [[ $build_options != *"gir"* ]]; then
if [[ $hostmakedepends != *"gobject-introspection"* ]]; then
# Provide the host tooling, g-ir-scanner, g-ir-compiler
# and its wrappers.
hostmakedepends+=" gobject-introspection"
fi
if [ "$CROSS_BUILD" ]; then
# Required for running binaries produced from g-ir-compiler
# via g-ir-scanner-qemuwrapper
hostmakedepends+=" qemu-user-static"
# Required for running the g-ir-scanner-lddwrapper
hostmakedepends+=" prelink-cross"
if [[ $makedepends != *"gobject-introspection"* ]]; then
# Provide basic .gir types like GLib, GObject, DBus, Gio, cairo
# and tooling like g-ir-compiler
makedepends+=" gobject-introspection"
fi
export VAPIGEN_VAPIDIRS=${XBPS_CROSS_BASE}/usr/share/vala/vapi
export VAPIGEN_GIRDIRS=${XBPS_CROSS_BASE}/usr/share/gir-1.0
# Provide some packages in hostmakedepends if they are in makedepends
for f in gtk+3-devel python3-gobject-devel; do
if [[ $makedepends == *"${f}"* ]]; then
hostmakedepends+=" ${f}"
fi
done
unset f
fi
fi

View File

@ -0,0 +1,37 @@
#
# numpy - build-helper for packages that compile against python3-numpy
#
# This build-helper makes sure packages can find python3-numpy libraries and
# headers on the target architecture rather than the host, as well as making
# sure the gfortran cross compiler is properly identified.
# Even for cross compilation, numpy should be available on the host to ensure
# that the host interpreter doesn't complain about missing deps
if [[ $hostmakedepends != *"python3-numpy"* ]]; then
hostmakedepends+=" python3-numpy"
fi
if [ "$CROSS_BUILD" ]; then
if [[ $makedepends != *"python3-numpy"* ]]; then
makedepends+=" python3-numpy"
fi
# python3-setuptools finds numpy libs and headers on the host first;
# adding search paths up front allows the target to take priority
CFLAGS+=" -I${XBPS_CROSS_BASE}/${py3_sitelib}/numpy/core/include"
LDFLAGS+=" -L${XBPS_CROSS_BASE}/${py3_sitelib}/numpy/core/lib"
LDFLAGS+=" -L${XBPS_CROSS_BASE}/${py3_sitelib}/numpy/random/lib"
# distutils from python3-numpy looks to environment variables F77 and
# F90 rather than the XBPS-set FC
export F77="${FC}"
export F90="${FC}"
# When compiling and linking FORTRAN, distutils from python3-numpy
# refuses respect any linker name except "gfortran"; symlink to the
# cross-compiler to that the right linker and compiler will be used
if _gfortran=$(command -v "${FC}"); then
ln -sf "${_gfortran}" "${XBPS_WRAPPERDIR}/gfortran"
fi
unset _gfortran
fi

View File

@ -0,0 +1,16 @@
# fix building non-pure-python modules on cross
if [ -n "$CROSS_BUILD" ]; then
export PYPREFIX="$XBPS_CROSS_BASE"
export CFLAGS+=" -I${XBPS_CROSS_BASE}/${py3_inc} -I${XBPS_CROSS_BASE}/usr/include"
export LDFLAGS+=" -L${XBPS_CROSS_BASE}/${py3_lib} -L${XBPS_CROSS_BASE}/usr/lib"
export CC="${XBPS_CROSS_TRIPLET}-gcc -pthread $CFLAGS $LDFLAGS"
export LDSHARED="${CC} -shared $LDFLAGS"
export PYTHON_CONFIG="${XBPS_CROSS_BASE}/usr/bin/python3-config"
export PYTHONPATH="${XBPS_CROSS_BASE}/${py3_lib}"
for f in ${XBPS_CROSS_BASE}/${py3_lib}/_sysconfigdata_*; do
[ -f "$f" ] || continue
f=${f##*/}
_PYTHON_SYSCONFIGDATA_NAME=${f%.py}
done
[ -n "$_PYTHON_SYSCONFIGDATA_NAME" ] && export _PYTHON_SYSCONFIGDATA_NAME
fi

View File

@ -0,0 +1,14 @@
if [ "$CROSS_BUILD" ]; then
export QEMU_LD_PREFIX=${XBPS_CROSS_BASE}
if [[ $hostmakedepends != *"qemu-user-static"* ]]; then
hostmakedepends+=" qemu-user-static"
fi
fi
vtargetrun() {
if [ "$CROSS_BUILD" ]; then
"/usr/bin/qemu-${XBPS_TARGET_QEMU_MACHINE}-static" "$@"
else
"$@"
fi
}

View File

@ -0,0 +1,95 @@
# This build-helper sets up qmakes cross environment
# in cases the build-style is mixed,
# e.g. when in a gnu-configure style the configure
# script calls qmake or a makefile in a gnu-makefile style,
# respectively.
if [ "$CROSS_BUILD" ]; then
mkdir -p "${XBPS_WRAPPERDIR}/target-spec/linux-g++"
cat > "${XBPS_WRAPPERDIR}/target-spec/linux-g++/qmake.conf" <<_EOF
MAKEFILE_GENERATOR = UNIX
CONFIG += incremental no_qt_rpath
QMAKE_INCREMENTAL_STYLE = sublib
include(/usr/lib/qt5/mkspecs/common/linux.conf)
include(/usr/lib/qt5/mkspecs/common/gcc-base-unix.conf)
include(/usr/lib/qt5/mkspecs/common/g++-unix.conf)
QMAKE_TARGET_CONFIG = ${XBPS_CROSS_BASE}/usr/lib/qt5/mkspecs/qconfig.pri
QMAKE_TARGET_MODULE = ${XBPS_CROSS_BASE}/usr/lib/qt5/mkspecs/qmodule.pri
QMAKEMODULES = ${XBPS_CROSS_BASE}/usr/lib/qt5/mkspecs/modules
QMAKE_CC = ${CC}
QMAKE_CXX = ${CXX}
QMAKE_LINK = ${CXX}
QMAKE_LINK_C = ${CC}
QMAKE_LINK_SHLIB = ${CXX}
QMAKE_AR = ${XBPS_CROSS_TRIPLET}-gcc-ar cqs
QMAKE_OBJCOPY = ${OBJCOPY}
QMAKE_NM = ${NM} -P
QMAKE_STRIP = ${STRIP}
QMAKE_CFLAGS = ${CFLAGS}
QMAKE_CXXFLAGS = ${CXXFLAGS}
QMAKE_LFLAGS = ${LDFLAGS}
load(qt_config)
_EOF
echo "#include \"${XBPS_CROSS_BASE}/usr/lib/qt5/mkspecs/linux-g++/qplatformdefs.h\"" > "${XBPS_WRAPPERDIR}/target-spec/linux-g++/qplatformdefs.h"
cat > "${XBPS_WRAPPERDIR}/qt.conf" <<_EOF
[Paths]
Sysroot=${XBPS_CROSS_BASE}
Prefix=${XBPS_CROSS_BASE}/usr
ArchData=${XBPS_CROSS_BASE}/usr/lib/qt5
Data=${XBPS_CROSS_BASE}/usr/share/qt5
Documentation=${XBPS_CROSS_BASE}/usr/share/doc/qt5
Headers=${XBPS_CROSS_BASE}/usr/include/qt5
Libraries=${XBPS_CROSS_BASE}/usr/lib
LibraryExecutables=/usr/lib/qt5/libexec
Binaries=/usr/lib/qt5/bin
Tests=${XBPS_CROSS_BASE}/usr/tests
Plugins=/usr/lib/qt5/plugins
Imports=${XBPS_CROSS_BASE}/usr/lib/qt5/imports
Qml2Imports=${XBPS_CROSS_BASE}/usr/lib/qt5/qml
Translations=${XBPS_CROSS_BASE}/usr/share/qt5/translations
Settings=${XBPS_CROSS_BASE}/etc/xdg
Examples=${XBPS_CROSS_BASE}/usr/share/qt5/examples
HostPrefix=/usr
HostData=/usr/lib/qt5
HostBinaries=/usr/lib/qt5/bin
HostLibraries=/usr/lib
Spec=linux-g++
TargetSpec=$XBPS_WRAPPERDIR/target-spec/linux-g++
_EOF
# create the qmake-wrapper here because it only
# makes sense together with the qmake build-helper
# and not to interfere with e.g. the qmake build-style
#
# + base flags will be picked up from QMAKE_{C,CXX,LD}FLAGS
# + hardening flags will be picked up from environment variables
cat > "${XBPS_WRAPPERDIR}/qmake" <<_EOF
#!/bin/sh
exec /usr/lib/qt5/bin/qmake "\$@" -qtconf "${XBPS_WRAPPERDIR}/qt.conf" \\
QMAKE_CFLAGS+="\${CFLAGS}" \\
QMAKE_CXXFLAGS+="\${CXXFLAGS}" \\
QMAKE_LFLAGS+="\${LDFLAGS}"
_EOF
else
cat > "${XBPS_WRAPPERDIR}/qmake" <<_EOF
#!/bin/sh
exec /usr/lib/qt5/bin/qmake \
"\$@" \
PREFIX=/usr \
QT_INSTALL_PREFIX=/usr \
LIB=/usr/lib \
QMAKE_CC="$CC" QMAKE_CXX="$CXX" \
QMAKE_LINK="$CXX" QMAKE_LINK_C="$CC" \
QMAKE_CFLAGS+="\${CFLAGS}" \
QMAKE_CXXFLAGS+="\${CXXFLAGS}" \
QMAKE_LFLAGS+="\${LDFLAGS}" \
CONFIG+=no_qt_rpath
_EOF
fi
chmod 755 ${XBPS_WRAPPERDIR}/qmake
cp -p ${XBPS_WRAPPERDIR}/qmake{,-qt5}

View File

@ -0,0 +1,59 @@
# Define equivalent of TOML config in environment
# [build]
# jobs = $XBPS_MAKEJOBS
export CARGO_BUILD_JOBS="$XBPS_MAKEJOBS"
export CARGO_HOME="/host/cargo"
if [ "$CROSS_BUILD" ]; then
# Define equivalent of TOML config in environment
# [target.${RUST_TARGET}]
# linker = ${CC}
_XBPS_CROSS_RUST_TARGET_ENV="${XBPS_CROSS_RUST_TARGET^^}"
_XBPS_CROSS_RUST_TARGET_ENV="${_XBPS_CROSS_RUST_TARGET_ENV//-/_}"
export CARGO_TARGET_${_XBPS_CROSS_RUST_TARGET_ENV}_LINKER="$CC"
unset _XBPS_CROSS_RUST_TARGET_ENV
# Define equivalent of TOML config in environment
# [build]
# target = ${RUST_TARGET}
export CARGO_BUILD_TARGET="$RUST_TARGET"
# If cc-rs needs to build host binaries, it guesses the compiler and
# uses default (wrong) flags unless they are specified explicitly;
# innocuous flags are used here just to disable its defaults
export HOST_CC="gcc"
export HOST_CFLAGS="-O2"
# Crates that use bindgen via build.rs are not cross-aware unless these are set
export BINDGEN_EXTRA_CLANG_ARGS+=" --sysroot=${XBPS_CROSS_BASE} -I${XBPS_CROSS_BASE}/usr/include"
else
unset CARGO_BUILD_TARGET
fi
# For cross-compiling rust -sys crates
export PKG_CONFIG_ALLOW_CROSS=1
# gettext-rs
export GETTEXT_BIN_DIR=/usr/bin
export GETTEXT_LIB_DIR="${XBPS_CROSS_BASE}/usr/lib/gettext"
export GETTEXT_INCLUDE_DIR="${XBPS_CROSS_BASE}/usr/include"
# libssh2-sys
export LIBSSH2_SYS_USE_PKG_CONFIG=1
# sodium-sys
export SODIUM_LIB_DIR="${XBPS_CROSS_BASE}/usr/include"
export SODIUM_INC_DIR="${XBPS_CROSS_BASE}/usr/lib"
export SODIUM_SHARED=1
# openssl-sys
export OPENSSL_NO_VENDOR=1
# pcre2-sys, only necessary for musl targets
export PCRE2_SYS_STATIC=0
# zstd-sys
export ZSTD_SYS_USE_PKG_CONFIG=1
# onig-sys
export RUSTONIG_SYSTEM_LIBONIG=1

View File

@ -0,0 +1,17 @@
BUILD PROFILES
==============
This directory contains build profiles to set properties on native builds
for a specific architecture:
- XBPS_TRIPLET (the compiler triplet)
- XBPS_CFLAGS (C compiler flags for host compiler)
- XBPS_CXXFLAGS (C++ compiler flags for the host compiler)
- XBPS_FFLAGS (Fortran compiler flags for the host compiler)
- XBPS_RUST_TARGET (the compiler triplet for usage by cargo)
- XBPS_ZIG_TARGET (the arch-os-abi target triplet for zig)
- XBPS_ZIG_CPU (the cpu/feature set for zig)
These properties are also set in a cross environment, but the compiler
flags are not added into the global flags. XBPS_RUST_TARGET is also
exposed as RUST_BUILD instead of RUST_TARGET.

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv8-a"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="aarch64-unknown-linux-musl"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="aarch64-linux-musl"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv8-a"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="aarch64-unknown-linux-gnu"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="aarch64-linux-gnu"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="armv6l-linux-musleabihf"
XBPS_RUST_TARGET="arm-unknown-linux-musleabihf"
XBPS_ZIG_TARGET="arm-linux-musleabihf"
XBPS_ZIG_CPU="generic+v6"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="armv6l-unknown-linux-gnueabihf"
XBPS_RUST_TARGET="arm-unknown-linux-gnueabihf"
XBPS_ZIG_TARGET="arm-linux-gnueabihf"
XBPS_ZIG_CPU="generic+v6"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard"
XBPS_TARGET_CXXFLAGS="$XBPS_CXXFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="armv7l-linux-musleabihf"
XBPS_RUST_TARGET="armv7-unknown-linux-musleabihf"
XBPS_ZIG_TARGET="arm-linux-musleabihf"
XBPS_ZIG_CPU="generic+v7a+vfp3"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="armv7l-unknown-linux-gnueabihf"
XBPS_RUST_TARGET="armv7-unknown-linux-gnueabihf"
XBPS_CROSS_ZIG_TARGET="arm-linux-gnueabihf"
XBPS_CROSS_ZIG_CPU="generic+v7a+vfp3"

View File

@ -0,0 +1,3 @@
XBPS_CFLAGS="-O2 -pipe"
XBPS_CXXFLAGS="$XBPS_CFLAGS"
XBPS_FFLAGS="-fPIC -pipe"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=i686"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="i686-linux-musl"
XBPS_RUST_TARGET="i686-unknown-linux-musl"
XBPS_ZIG_TARGET="i686-linux-musl"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=i686"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="i686-pc-linux-gnu"
XBPS_RUST_TARGET="i686-unknown-linux-gnu"
XBPS_ZIG_TARGET="i386-linux-gnu"
XBPS_ZIG_CPU="_i686+sse2"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=G4"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc-linux-musl"
XBPS_RUST_TARGET="powerpc-unknown-linux-musl"
XBPS_ZIG_TARGET="powerpc-linux-musl"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=G4"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc-linux-gnu"
XBPS_RUST_TARGET="powerpc-unknown-linux-gnu"
XBPS_ZIG_TARGET="powerpc-linux-gnu"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mcpu=970 -mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc64-unknown-linux-musl"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="powerpc64-linux-musl"
XBPS_ZIG_CPU="970"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mcpu=970 -mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc64-unknown-linux-gnu"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="powerpc64-linux-gnu"
XBPS_ZIG_CPU="970"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc64le-unknown-linux-musl"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="powerpc64le-linux-musl"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpc64le-unknown-linux-gnu"
XBPS_RUST_TARGET="$XBPS_TRIPLET"
XBPS_ZIG_TARGET="powerpc64le-linux-gnu"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mcpu=power8 -mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpcle-linux-musl"
XBPS_RUST_TARGET="powerpcle-unknown-linux-musl"
XBPS_ZIG_TARGET="powerpcle-linux-musl"
XBPS_ZIG_CPU="pwr8"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mcpu=power8 -mtune=power9"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="powerpcle-linux-gnu"
XBPS_RUST_TARGET="powerpcle-unknown-linux-gnu"
XBPS_ZIG_TARGET="powerpcle-linux-gnu"
XBPS_ZIG_CPU="pwr8"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-march=rv64imafdc"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="riscv64-unknown-linux-gnu"
XBPS_RUST_TARGET="riscv64gc-unknown-linux-gnu"
XBPS_ZIG_TARGET="riscv64-linux-gnu"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=generic"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="x86_64-unknown-linux-musl"
XBPS_RUST_TARGET="${XBPS_TRIPLET}"
XBPS_ZIG_TARGET="x86_64-linux-musl"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
XBPS_TARGET_CFLAGS="-mtune=generic"
XBPS_TARGET_CXXFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TARGET_FFLAGS="$XBPS_TARGET_CFLAGS"
XBPS_TRIPLET="x86_64-unknown-linux-gnu"
XBPS_RUST_TARGET="${XBPS_TRIPLET}"
XBPS_ZIG_TARGET="x86_64-linux-gnu"
XBPS_ZIG_CPU="baseline"

View File

@ -0,0 +1,7 @@
#
# This helper is for templates using R-cran.
#
do_install() {
mkdir -p ${DESTDIR}/usr/lib/R/library
( cd .. && R CMD INSTALL -l ${DESTDIR}/usr/lib/R/library ${pkgname#R-cran-} )
}

12
common/build-style/README Normal file
View File

@ -0,0 +1,12 @@
BUILD STYLES
============
These shell snippets provide support for multiple build systems, i.e GNU configure,
CMake, etc. A build style file must provide at least the following functions:
- do_configure
- do_build
- do_install
If a source package defines its own do_xxx() function, the function defined in
the build style file is simply ignored.

View File

@ -0,0 +1,27 @@
#
# This helper is for building rust projects which use cargo for building
#
do_build() {
: ${make_cmd:=cargo auditable}
${make_cmd} build --release --locked --target ${RUST_TARGET} ${configure_args}
}
do_check() {
: ${make_cmd:=cargo auditable}
${make_check_pre} ${make_cmd} test --release --locked --target ${RUST_TARGET} \
${configure_args} ${make_check_args}
}
do_install() {
: ${make_cmd:=cargo auditable}
: ${make_install_args:=--path .}
${make_cmd} install --target ${RUST_TARGET} --root="${DESTDIR}/usr" \
--offline --locked ${configure_args} ${make_install_args}
rm -f "${DESTDIR}"/usr/.crates.toml
rm -f "${DESTDIR}"/usr/.crates2.json
}

137
common/build-style/cmake.sh Normal file
View File

@ -0,0 +1,137 @@
#
# This helper is for templates using cmake.
#
do_configure() {
local cmake_args=
[ ! -d ${cmake_builddir:=build} ] && mkdir -p ${cmake_builddir}
cd ${cmake_builddir}
if [ -z "$CHROOT_READY" ]; then
cat >bootstrap.cmake <<_EOF
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER ${CC})
SET(CMAKE_CXX_COMPILER ${CXX})
SET(CMAKE_FIND_ROOT_PATH "${XBPS_MASTERDIR}/usr;${XBPS_MASTERDIR}")
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
_EOF
configure_args+=" -DCMAKE_TOOLCHAIN_FILE=bootstrap.cmake"
elif [ "$CROSS_BUILD" ]; then
case "$XBPS_TARGET_MACHINE" in
x86_64*) _CMAKE_SYSTEM_PROCESSOR=x86_64 ;;
i686*) _CMAKE_SYSTEM_PROCESSOR=x86 ;;
aarch64*) _CMAKE_SYSTEM_PROCESSOR=aarch64 ;;
arm*) _CMAKE_SYSTEM_PROCESSOR=arm ;;
mips*) _CMAKE_SYSTEM_PROCESSOR=mips ;;
ppc64le*) _CMAKE_SYSTEM_PROCESSOR=ppc64le ;;
ppc64*) _CMAKE_SYSTEM_PROCESSOR=ppc64 ;;
ppcle*) _CMAKE_SYSTEM_PROCESSOR=ppcle ;;
ppc*) _CMAKE_SYSTEM_PROCESSOR=ppc ;;
*) _CMAKE_SYSTEM_PROCESSOR=generic ;;
esac
cat > cross_${XBPS_CROSS_TRIPLET}.cmake <<_EOF
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER ${CC})
SET(CMAKE_CXX_COMPILER ${CXX})
SET(CMAKE_CROSSCOMPILING TRUE)
SET(CMAKE_SYSTEM_PROCESSOR ${_CMAKE_SYSTEM_PROCESSOR})
SET(CMAKE_FIND_ROOT_PATH "${XBPS_CROSS_BASE}/usr;${XBPS_CROSS_BASE}")
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
_EOF
cmake_args+=" -DCMAKE_TOOLCHAIN_FILE=${wrksrc}/${build_wrksrc}/${cmake_builddir}/cross_${XBPS_CROSS_TRIPLET}.cmake"
fi
cmake_args+=" -DCMAKE_INSTALL_PREFIX=/usr"
cmake_args+=" -DCMAKE_BUILD_TYPE=None"
cmake_args+=" -DCMAKE_INSTALL_LIBDIR=lib${XBPS_TARGET_WORDSIZE}"
cmake_args+=" -DCMAKE_INSTALL_SYSCONFDIR=/etc"
cmake_args+=" -DFETCHCONTENT_FULLY_DISCONNECTED=ON"
if [ "$CROSS_BUILD" ]; then
cmake_args+=" -DQT_HOST_PATH=/usr"
# QT_HOST_PATH isn't enough in my system,
# which have binfmts support on and off
cmake_args+=" -DQT_HOST_PATH_CMAKE_DIR=/usr/lib/cmake"
fi
if [[ $build_helper = *"qemu"* ]]; then
echo "SET(CMAKE_CROSSCOMPILING_EMULATOR /usr/bin/qemu-${XBPS_TARGET_QEMU_MACHINE}-static)" \
>> cross_${XBPS_CROSS_TRIPLET}.cmake
fi
cmake_args+=" -DCMAKE_INSTALL_SBINDIR=bin"
export CMAKE_GENERATOR="${CMAKE_GENERATOR:-Ninja}"
# Remove -pipe: https://gitlab.kitware.com/cmake/cmake/issues/19590
CFLAGS="-DNDEBUG ${CFLAGS/ -pipe / }" CXXFLAGS="-DNDEBUG ${CXXFLAGS/ -pipe / }" \
cmake ${cmake_args} ${configure_args} \
${LIBS:+-DCMAKE_C_STANDARD_LIBRARIES="$LIBS"} \
${LIBS:+-DCMAKE_CXX_STANDARD_LIBRARIES="$LIBS"} \
${wrksrc}/${build_wrksrc}
# Replace -isystem with -I
if [ "$CMAKE_GENERATOR" = "Unix Makefiles" ]; then
find . -name flags.make -exec sed -i -e 's/-isystem/-I/g' "{}" +
elif [ "$CMAKE_GENERATOR" = Ninja ]; then
sed -i -e 's/-isystem/-I/g' build.ninja
fi
}
do_build() {
: ${make_cmd:=ninja}
cd ${cmake_builddir:=build}
${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}
}
do_check() {
: ${make_cmd:=ninja}
cd ${cmake_builddir:=build}
if [ -z "$make_check_target" ]; then
case $make_cmd in
make)
if make -q test 2>/dev/null; then
:
else
if [ $? -eq 2 ]; then
msg_warn 'No target to "make test".\n'
return 0
fi
fi
;;
ninja)
if ! ninja -t query test >/dev/null 2>&1; then
msg_warn 'No target to "ninja test".\n'
return 0
fi
;;
*)
msg_warn "Can't run tests with '$make_cmd', define do_check.\n"
;;
esac
fi
: ${make_check_target:=test}
${make_check_pre} ${make_cmd} ${makejobs} ${make_check_args} ${make_check_target}
}
do_install() {
: ${make_cmd:=ninja}
: ${make_install_target:=install}
cd ${cmake_builddir:=build}
DESTDIR=${DESTDIR} ${make_cmd} ${make_install_args} ${make_install_target}
}

View File

@ -0,0 +1,40 @@
#
# This helper is for templates using configure scripts (not generated
# by the GNU autotools).
#
do_configure() {
: ${configure_script:=./configure}
${configure_script} ${configure_args}
}
do_build() {
: ${make_cmd:=make}
${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}
}
do_check() {
if [ -z "$make_cmd" ] && [ -z "$make_check_target" ]; then
if make -q check 2>/dev/null; then
:
else
if [ $? -eq 2 ]; then
msg_warn 'No target to "make check".\n'
return 0
fi