conda-forge now uses mambabuild as default
conda-forge now uses mamba during
the build process (via conda mambabuild
of the
boa project). This was changed in
conda-smithy
3.13.0
and should automatically apply when re-rendering.
conda-forge now uses mamba during
the build process (via conda mambabuild
of the
boa project). This was changed in
conda-smithy
3.13.0
and should automatically apply when re-rendering.
These compilers will become the default for building packages in
conda-forge. One notable change in gcc 10 is that the -fopenmp`` flag in
FFLAGSis dropped. In clang 12,
-std=c++14explicit flag has been dropped from
CXXFLAGS, as it is the default compilation mode for clang 12. In gcc 11, the default is
-std=gnu++17`. In clang>=12 and gcc>=11,
we will not provide an explicit C++ standard, and will defer to the
compiler default.
Python 3.6 is end-of-life in December 2021 and we are dropping support for it early to avoid having to rebuild packages as part of python 3.10 migration as that would save lots of CI resources.
You can get the previous behaviour by using the channel_sources
setting in conda-forge.yml
You can now cite conda-forge using our Zenodo entry! This entry credits the entire conda-forge community for its hard work in building our amazing ecosystem.
conda-forge's compiler stack uses repackaged libraries from CentOS 6 to
supply certain libraries, notably glibc
when building recipes. We
currently default to using CentOS 6 with the glibc
2.12 ABI. However,
CentOS 6 reached end-of-life in November 2020 and increasingly software
packages require at least CentOS 7 with the glibc
2.17 ABI. We also
realize that due to recent events, some communities that may have been
planning to skip CentOS 7 and move straight to CentOS 8 might be
reconsidering those plans. Further, they may not be ready for a
full-scale switch to CentOS 7. Thus the conda-forge core team has
decided to delay moving to CentOS 7 until sometime early next year,
likely the end of January 2021 at the earliest. We are actively looking
for feedback from our users on this issue. Please do
get in touch if you have comments or concerns!
In an effort to better secure conda-forge, we are developing a process
to validate artifacts before they are uploaded to anaconda.org
. This
validation will look for various security-related items, such as
artifacts that overwrite key pieces of certain packages. While this
process is in development, we will not be rejecting uploads. However, we
will start scanning our current artifacts and working with the
maintainers of those artifacts to mark broken any which we deem a
security risk. We will also be running validation on new artifacts being
upload and will report any issues back to feedstocks. At a future date,
artifacts that do not pass validation will not be uploaded.
We will be upgrading all GCC
-based compilers to version 9.3.0
on all
platforms. This upgrade will not affect C
or C++
code, but will
require a rebuild of all feedstocks that use FORTRAN
due to a change
in the SONAME
. During this rebuild, we will keep the old compiler
versions in production, temporarily doubling the build matrix. Once the
migration is deemed complete, these old compiler versions will be
removed.
We have now completed rolling out the new staging process for uploads to
anaconda.org. Direct uploads to the conda-forge
channel will no longer
work. If you are having trouble with package uploads, please rerender
your feedstock with the latest version of conda-smithy
. As always, if
you need help, bump us on Gitter or GitHub!
We have fixed a bug where the maintainers of feedstocks listed in the
meta.yaml
did not match those listed in the GitHub team. Due to this
change, you may notice emails from GitHub informing you that you have
been removed from a GitHub team if you have recently removed yourself
from a feedstock via changing the meta.yaml
. A similar fix has been
applied for maintenance teams as well, though you will not see emails
from this fix.