Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-01-26 06:26:18 -05:00
Code Issues Packages Projects Releases Wiki Activity

Clean up text

Browse Source
This commit is contained in:
Andrew David Wong 2019-02-11 23:36:39 -06:00 committed by GitHub
parent 3daf19985f
commit 3a8624ed20
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
building/qubes-builder.md
View File

@ -135,21 +135,26 @@ If you want to somehow modify sources, you can also do it, here are some basic s
make iso
### Use pre-build Qubes packages
### Use pre-built Qubes packages
For building just few selected packages, it's very useful to download pre-built qubes-specific dependencies from `{yum,deb}.qubes-os.org`. This is especially true for gcc, which takes several hours to build.
For building just few selected packages, it's very useful to download pre-built qubes-specific dependencies from `{yum,deb}.qubes-os.org`.
This is especially true for `gcc`, which takes several hours to build.
Before creating the chroot, add to your builder.conf
Before creating the `chroot`, add this to your `builder.conf`:
USE_QUBES_REPO_VERSION = $(RELEASE)
It will add the 'current' Qubes repository to your chroot environment. In that case, you can build only the packages you are interested in. If you want to use also the 'current-testing' repository, add also to your configuration
It will add the 'current' Qubes repository to your `chroot` environment.
This way, you can build only the packages you are interested in.
If you also want to use the 'current-testing' repository, add this to your configuration:
USE_QUBES_REPO_TESTING = 1
In case of an existing chroot, for mock-enabled builds, it works immediately because chroot is constructed each time separately. For legacy builds, it will not add the necessary configuration into the build environement unless specific builder change or configuration would force rebuilding chroot.
In the case of an existing `chroot`, for mock-enabled builds, it works immediately because `chroot` is constructed each time separately.
For legacy builds, it will not add the necessary configuration into the build environment unless a specific builder change or configuration would force rebuilding chroot.
Also, once enabled, disabling this setting will not disable repositories in relevant chroots. And even if it would, there may be left packages installed from those repos (which may or may not be desirable).
Also, once enabled, disabling this setting will not disable repositories in relevant chroots.
And even if it did, there could be leftover packages installed from those repos (which may or may not be desirable).
Code verification keys management
---------------------------------