Merge branch 'master' into patch-13

about/faq.md

@@ -579,3 +579,8 @@ Arguably secure boot reliance on UEFI integrity is not the best design.
 The relevant binaries (shim.efi, xen.efi, kernel / initramfs) are not signed by the Qubes Team and secure boot has not been tested.
 Intel TXT (used in [Anti Evil Maid](/doc/anti-evil-maid/)) at least tries to avoid or limit trust in BIOS.
 See the Heads project [[1]](https://trmm.net/Heads) [[2]](http://osresearch.net/) for a better-designed non-UEFI-based secure boot scheme with very good support for Qubes.
+
+### What is the canonical way to detect Qubes VM?
+
+Check `/usr/share/qubes/marker-vm` file existence. Additionally, its last line contains Qubes release version (`3.2`, `4.0` etc).
+The file was introduced after initial Qubes 3.2 and 4.0 release. If you need to support not-fully-updated systems, check `/usr/bin/qrexec-client-vm` existence.

building/qubes-builder.md

@@ -135,6 +135,27 @@ If you want to somehow modify sources, you can also do it, here are some basic s
 
         make iso
 
+### 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.
+
+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.
+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 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 did, there could be leftover packages installed from those repos (which may or may not be desirable).
+
 Code verification keys management
 ---------------------------------
 

customization/bind-dirs.md

@@ -65,14 +65,13 @@ Creation of the file and folders in /rw/bind-dirs should be automatic the first
 
 If you want to circumvent this process, you can create the relevant filestructure under /rw/bind-dirs and make any changes at the same time that you perform the configuration, before reboot.
 
-
 ## Limitations ##
 
 * Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh.
 * Re-running `sudo /usr/lib/qubes/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/bind-dirs.sh umount` does not work.
 * Running `sudo /usr/lib/qubes/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that.
 * Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.
-Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs.rather than the file, or perform the file operation on the file in /rw/bind-dirs.
+Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs rather than the file, or perform the file operation on the file in /rw/bind-dirs.
 * Some files are altered when a qube boots - e.g. `/etc/hosts`. If you try to use bind-dirs on such files you may break your qube in unpredictable ways.
 
 You can add persistent rules to `/etc/hosts` file using script `/rw/config/rc.local` that is designed to override configuration in /etc, starting services and etc. For example, to make software inside some TemplateBasedVM resolving the domain `example.com` as `127.0.0.1` open `/rw/config/rc.local` inside this TemplateBasedVM and add:
@@ -83,8 +82,6 @@ echo '127.0.0.1 example.com' >> /etc/hosts
 
 After every boot of the TemplateBasedVM `rc.local` script will add line `127.0.0.1 example.com` to `/etc/hosts` file and the software inside the TemplateBasedVM will resolve domain `example.com` accordingly. You cam add several rules to `/etc/hosts` the same way.
 
-
-
 ## How to remove binds from bind-dirs.sh? ##
 
 `binds` is actually just a bash variable (an array) and the bind-dirs.sh configuration folders are `source`d as bash snippets in lexical order. 

managing-os/templates/fedora-minimal.md

@@ -67,7 +67,7 @@ Use case | Description | Required steps
 Use case | Description | Required steps
 --- | --- | ---
 **Standard utilities** | If you need the commonly used utilities | Install the following packages: `pciutils` `vim-minimal` `less` `psmisc` `gnome-keyring`
-**Audio** | If you want sound from your VM... | Install `pulseaudio-qubes`
+**Audio** | If you want sound from your VM | Install `pulseaudio-qubes`
 **FirewallVM** | You can use the minimal template as a [FirewallVM](/doc/firewall/), such as the basis template for `sys-firewall` | Install at least `qubes-core-agent-networking` and `iproute`, and also `qubes-core-agent-dom0-updates` if you want to use it as the updatevm (which is normally sys-firewall).
 **NetVM** | You can use this template as the basis for a NetVM such as `sys-net` | Install the following packages:  `qubes-core-agent-networking` `qubes-core-agent-network-manager` `NetworkManager-wifi` `network-manager-applet` `wireless-tools` `dejavu-sans-fonts` `notification-daemon` `gnome-keyring` `polkit` `@hardware-support`.
 **NetVM (extra firmware)** | If your network devices need extra packages for the template to work as a network VM | Use the `lspci` command to identify the devices, then run `dnf search firmware` (replace `firmware` with the appropriate device identifier) to find the needed packages and then install them.