Skip to content

Commit 5714761

Browse files
committed
Fix indentations
1 parent a6dddbe commit 5714761

File tree

1 file changed

+49
-49
lines changed

1 file changed

+49
-49
lines changed

src/maintainer/maintainer_faq.rst

Lines changed: 49 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ FAQ
1616
and the repository exists.
1717
Exited with code 128
1818

19-
open a new issue with a comment :ref:`ci_update_circle`.
19+
Open a new issue with a comment :ref:`ci_update_circle`.
2020
Once our web services have updated the circle configuration, restart the build.
2121

2222

@@ -46,8 +46,8 @@ FAQ
4646

4747
When you update a feedstock that still uses build numbers > 1000, the following rules apply:
4848

49-
- when you increase the version, reset the build number back to 0 (e.g. ``1005 -> 0``).
50-
- when the version stays the same and you need to upload a new package, increase the build number by 1 (e.g. ``1005 -> 1006``).
49+
- When you increase the version, reset the build number back to 0 (e.g. ``1005 -> 0``).
50+
- When the version stays the same and you need to upload a new package, increase the build number by 1 (e.g. ``1005 -> 1006``).
5151

5252

5353
**Backstory:** Build numbers of 1000 and larger are a relic from the compiler migration, where a build number offset of 1000 signified that a package was migrated to the new compilers.
@@ -59,105 +59,105 @@ FAQ
5959

6060
:ref:`(Q) <mfaq_windows_cmake>` **How to fix CMake not finding MSBuild.exe on Azure Windows builds?**
6161

62-
TL;DR: Use ``Ninja`` or ``NMake Makefiles JOM`` as the CMake generator (``cmake -G"Ninja"``), and add ``build`` requirements for ``ninja`` or ``jom``.
62+
TL;DR: Use ``Ninja`` or ``NMake Makefiles JOM`` as the CMake generator (``cmake -G"Ninja"``), and add ``build`` requirements for ``ninja`` or ``jom``.
6363

64-
Sadly in the Azure Windows images, `MSBuild.exe` is not correctly setup for CMake builds with the ``Visual Studio`` generators. To work around this, you can use a different CMake generator, e.g. ``cmake -GNinja`` or ``cmake -G"NMake Makefiles JOM"``. These two are preferred because they allow for concurrent builds in contrast to e.g. only using ``cmake -G"NMake Makefiles"``
64+
Sadly in the Azure Windows images, `MSBuild.exe` is not correctly setup for CMake builds with the ``Visual Studio`` generators. To work around this, you can use a different CMake generator, e.g. ``cmake -GNinja`` or ``cmake -G"NMake Makefiles JOM"``. These two are preferred because they allow for concurrent builds in contrast to e.g. only using ``cmake -G"NMake Makefiles"``
6565

6666
.. _mfaq_anaconda_delay:
6767

6868
:ref:`(Q) <mfaq_anaconda_delay>` **Why does my new version appear on Anaconda Cloud, but is not installable with conda?**
6969

70-
For certain, high-traffic channels (main & conda-forge), Anaconda uses a `CDN <https://cloudflare.com/learning/cdn/what-is-a-cdn/>`_ to decrease costs. The CDN is only reindexed every 20 minutes, however `Anaconda.org https://anaconda.org>`_ uses the original channel that the CDN mirrors. Therefore, packages will show up on the `Anaconda Cloud https://anaconda.org>`_ about 20 to 40 minutes before they are downloadable via conda. You can use ``conda search <pkg>`` to see if the package is installable, because this command reads from the CDN.
70+
For certain, high-traffic channels (main & conda-forge), Anaconda uses a `CDN <https://cloudflare.com/learning/cdn/what-is-a-cdn/>`_ to decrease costs. The CDN is only reindexed every 20 minutes, however `Anaconda.org https://anaconda.org>`_ uses the original channel that the CDN mirrors. Therefore, packages will show up on the `Anaconda Cloud https://anaconda.org>`_ about 20 to 40 minutes before they are downloadable via conda. You can use ``conda search <pkg>`` to see if the package is installable, because this command reads from the CDN.
7171

7272
.. _mfaq_mamba_local:
7373

7474
:ref:`(Q) <mfaq_mamba_local>` **How can I make debugging solver failures on the CI faster?**
7575

76-
An alternative to the conda solver is the mamba solver. The mamba solver has a faster solve speed and prints better error messages that make debugging simpler.
77-
78-
You can configure the conda-forge CI to run a debug build using the mamba solver with the following changes:
79-
80-
- Set ``build_with_mambabuild: True`` in ``conda-forge.yaml`` file
81-
- Rerender with ``conda-smithy`` (to rerender manually use ``conda smithy rerender`` from the command line)
82-
[Note: Builds made with ``mambabuild`` won't be uploaded to ``conda-forge``. These builds are purely for debugging purposes.]
83-
84-
You can also do this locally by using:
85-
86-
- ``conda install boa -c conda-forge``
87-
- ``conda mambabuild myrecipe``
88-
For more details visit `this <https://boa-build.readthedocs.io/en/latest/mambabuild.html>`_ page.
89-
90-
.. _mfaq_conda_verify:
76+
An alternative to the conda solver is the mamba solver. The mamba solver has a faster solve speed and prints better error messages that make debugging simpler.
77+
78+
You can configure the conda-forge CI to run a debug build using the mamba solver with the following changes:
79+
80+
- Set ``build_with_mambabuild: True`` in ``conda-forge.yaml`` file
81+
- Rerender with ``conda-smithy`` (to rerender manually use ``conda smithy rerender`` from the command line)
82+
[Note: Builds made with ``mambabuild`` won't be uploaded to ``conda-forge``. These builds are purely for debugging purposes.]
83+
84+
You can also do this locally by using:
85+
86+
- ``conda install boa -c conda-forge``
87+
- ``conda mambabuild myrecipe``
88+
For more details visit `this <https://boa-build.readthedocs.io/en/latest/mambabuild.html>`_ page.
89+
90+
.. _mfaq_conda_verify:
9191

9292
:ref:`(Q) <mfaq_conda_verify>` **I am seeing** ``Importing conda-verify failed.`` **error message during build. What do I do?**
9393

94-
.. code-block:: shell
95-
96-
Importing conda-verify failed. Please be sure to test your packages. conda install conda-verify to make this message go away.
94+
.. code-block:: shell
95+
96+
Importing conda-verify failed. Please be sure to test your packages. conda install conda-verify to make this message go away.
9797
98-
You are seeing this error message because by default, conda-build uses conda-verify to ensure that your recipe and package meet some minimum sanity checks.
99-
This message can be safely ignored as conda-forge doesn't use conda-verify.
98+
You are seeing this error message because by default, conda-build uses conda-verify to ensure that your recipe and package meet some minimum sanity checks.
99+
This message can be safely ignored as conda-forge doesn't use conda-verify.
100100

101101

102-
.. _mfaq_version_update:
102+
.. _mfaq_version_update:
103103

104104
:ref:`(Q) <mfaq_version_update>` **When the bot creates a pull request to a feedstock to update the version, should I approve the pull request and wait with merging until everybody else that is a code owner has approved the PR?**
105105

106-
There is no need to approve the PR. Every maintainer can verify and merge the bot PR without waiting on the approval of the other maintainers.
106+
There is no need to approve the PR. Every maintainer can verify and merge the bot PR without waiting on the approval of the other maintainers.
107107

108108

109-
.. _mfaq_docker_139:
109+
.. _mfaq_docker_139:
110110

111111
:ref:`(Q) <mfaq_docker_139>` **How to fix "build-locally.py fails with exit code 139"?**
112112

113-
With Linux Kernel 4.11 there were some changes in the ``vsyscall`` linking. Depending on your distribution this may cause the above error. You can fix that on Debian by editing ``/etc/default/grub`` and specifiy ``GRUB_CMDLINE_LINUX_DEFAULT="vsyscall=emulate"`` in this file. Afterwards, you need to run ``update-grub`` and reboot your system. On other Linux distributions the fix is similar but you need to edit a different configuration file to change the Linux kernel cmdline. This workaround is only needed for images based on CentOS 6 (``cos6``). You could also workaround this by forcing the CentOS 7 based images using ``DOCKER_IMAGE=quay.io/condaforge/linux-anvil-cos7-x86_64 ./build-locally.py``.
113+
With Linux Kernel 4.11 there were some changes in the ``vsyscall`` linking. Depending on your distribution this may cause the above error. You can fix that on Debian by editing ``/etc/default/grub`` and specifiy ``GRUB_CMDLINE_LINUX_DEFAULT="vsyscall=emulate"`` in this file. Afterwards, you need to run ``update-grub`` and reboot your system. On other Linux distributions the fix is similar but you need to edit a different configuration file to change the Linux kernel cmdline. This workaround is only needed for images based on CentOS 6 (``cos6``). You could also workaround this by forcing the CentOS 7 based images using ``DOCKER_IMAGE=quay.io/condaforge/linux-anvil-cos7-x86_64 ./build-locally.py``.
114114

115-
The exit code 139 itself actually is the general exit code for a segmentation fault. This could also mean that you have run into a different issue but the above issue is the most likely one with our CentOS 6-based images.
115+
The exit code 139 itself actually is the general exit code for a segmentation fault. This could also mean that you have run into a different issue but the above issue is the most likely one with our CentOS 6-based images.
116116

117-
.. _mfaq_package_submit:
117+
.. _mfaq_package_submit:
118118

119119
:ref:`(Q) <mfaq_package_submit>` **Is it necessary for me to be an upstream maintainer of the package I submit to Conda-forge?**
120120

121-
Everybody can submit a package to Conda-forge, irrespective of whether they maintain the upstream version or not. Additionally, it’s not required but considered good practice to inform the upstream of a new package and invite them to be maintainers as well.
121+
Everybody can submit a package to Conda-forge, irrespective of whether they maintain the upstream version or not. Additionally, it’s not required but considered good practice to inform the upstream of a new package and invite them to be maintainers as well.
122122

123123

124-
.. _mfaq_libGL_so_1:
124+
.. _mfaq_libGL_so_1:
125125

126126
:ref:`(Q) <mfaq_libGL_so_1>` **How do I fix the** ``libGL.so.1`` **import error?**
127127

128128

129-
Error:
130-
129+
Error:
130+
131131
.. code-block:: shell
132-
132+
133133
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
134-
134+
135135
136136
To fix the error, create a `yum_requirements.txt <https://conda-forge.org/docs/maintainer/knowledge_base.html#yum-deps>`_ file and add *mesa-libGL*.
137137

138138

139-
.. _mfaq_qt_load_xcb:
139+
.. _mfaq_qt_load_xcb:
140140

141141
:ref:`(Q) <mfaq_qt_load_xcb>` **How can I fix the** ``The Qt platform plugin "xcb" could not be loaded`` **error during testing?**
142142

143143

144-
When testing packages that have a dependency on pyqt, the following error might occur under linux:
145-
146-
144+
When testing packages that have a dependency on ``pyqt``, the following error might occur under linux:
145+
146+
147147
.. code-block:: shell
148-
148+
149149
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
150150
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
151151
152152
Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb.
153153
154-
155-
154+
155+
156156
This comes from the CI environment being headless and can be fixed by adding the ``QT_QPA_PLATFORM=offscreen`` `environment variable <https://docs.conda.io/projects/conda-build/en/latest/user-guide/environment-variables.html#inherited-environment-variabless>`_.
157-
The variable can either be added directly to the test command or provided in the `meta.yaml <https://conda-forge.org/docs/maintainer/adding_pkgs.html#the-recipe-meta-yaml>`_ like so:
158-
159-
.. code-block:: yaml
160-
157+
The variable can either be added directly to the test command or provided in the `meta.yaml <https://conda-forge.org/docs/maintainer/adding_pkgs.html#the-recipe-meta-yaml>`_ like so:
158+
159+
.. code-block:: yaml
160+
161161
build:
162162
script_env:
163163
- QT_QPA_PLATFORM=offscreen

0 commit comments

Comments
 (0)