Rocky Linux ships its CRB repository switched off. The first dnf install of a -devel package or an EPEL tool like yamllint then stops with “Unable to find a match” or “nothing provides”, and it keeps failing until you turn CRB on. AlmaLinux 10 dropped that hurdle in a September 2025 update that ships CRB enabled, while RHEL still keeps the same content, called CodeReady Linux Builder there, behind subscription-manager.
Below is the command for each 10 and 9 release, the PowerTools equivalent on 8, and the crb helper that ships with epel-release. Rocky Linux 10.2 (dnf 4.20) ran on a full VM with SELinux enforcing in October 2026, Rocky Linux 8.10 and AlmaLinux 8.10 ran in containers, and the 9-series and AlmaLinux 10 repo files came from the vendors’ packages. The RHEL commands were checked against Red Hat and EPEL documentation, not run, because the lab has no subscription.
Pick the Command for Your Release
The repo ID is crb on Rocky Linux and AlmaLinux 9 and 10, powertools on their 8 releases, and a subscription-managed codeready-builder-for-rhel ID on RHEL. So the command you need depends on the family and the major version:
| Release | CRB repo ID | Default | Enable it with |
|---|---|---|---|
| Rocky Linux 10, 9 | crb | Disabled | sudo dnf config-manager --set-enabled crb |
| AlmaLinux 10 | crb | Enabled | Nothing to do |
| AlmaLinux 9 | crb | Disabled | sudo dnf config-manager --set-enabled crb |
| Rocky Linux 8, AlmaLinux 8 | powertools | Disabled | sudo dnf config-manager --set-enabled powertools |
| RHEL 10 | codeready-builder-for-rhel-10-$(arch)-rpms | Disabled | sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms |
| RHEL 9 | codeready-builder-for-rhel-9-$(arch)-rpms | Disabled | sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms |
| RHEL 8 | codeready-builder-for-rhel-8-$(arch)-rpms | Disabled | sudo subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms |
| Rocky Linux or AlmaLinux, with epel-release installed | Detected for you | n/a | sudo crb enable |
Two rows break the pattern. AlmaLinux 10 needs nothing, because its almalinux-crb.repo now ships with enabled=1, a change AlmaLinux made after users kept filing EPEL dependency failures as bugs. RHEL needs subscription-manager rather than dnf, because subscription-manager generates /etc/yum.repos.d/redhat.repo and, by Red Hat’s own account, sets it back to its last saved state whenever it runs. If you look after a mix of Rocky Linux and AlmaLinux releases, the crb helper further down saves you most of the table.
Check Whether CRB Is Already Enabled
Look before you change anything, since an AlmaLinux 10 box already has CRB on and a host someone else built may too. CRB holds the packages the base repos leave out:
- development headers (
-develpackages) - build tools such as
doxygenandninja-build - Python and Perl libraries that EPEL packages build on
- static libraries such as
glibc-static
On Rocky Linux 10, 445 of the 1,293 package names in CRB end in -devel, so sooner or later every source build reaches for it. To see where a host stands, list every repo, enabled or not, and filter for the three names CRB goes by. The pattern catches all three, so the same line works on 8, 9 and 10.
dnf repolist --all | grep -iE 'crb|powertools|codeready'A fresh Rocky Linux 10 install reports all three CRB entries, the binary repo plus its debug and source twins, as disabled. Only the first one matters for installing packages, so you can ignore the other two. They hold debug symbols and source RPMs, which you need only when you’re debugging a crash or rebuilding a package.
crb Rocky Linux 10 - CRB disabled
crb-debuginfo Rocky Linux 10 - CRB - Debug disabled
crb-source Rocky Linux 10 - CRB - Source disabledA disabled CRB shows up as a package that dnf claims does not exist. doxygen is a typical case, because plenty of source builds call it to generate their docs, and on our VM the install failed outright.
sudo dnf install -y doxygendnf searched only BaseOS, AppStream and Extras, so the name never matched. The message reads exactly like a typo, which sends a lot of people hunting for the wrong problem. Check the repo list before you check your spelling.
Last metadata expiration check: 0:15:37 ago on Thu Oct 15 19:44:47 2026.
No match for argument: doxygen
Error: Unable to find a match: doxygenMissing headers fail with the same message, as in this libvirt-devel install failure. To confirm a package really lives in CRB before you enable anything, switch the repo on for a single query with --enablerepo, which changes no repo file.
dnf --enablerepo=crb info doxygenWe trimmed the output to the useful lines. The Repository field answers the question:
Name : doxygen
Version : 1.13.2
Release : 1.el10
Repository : crbYou could install the package the same way, with --enablerepo=crb on the install line, but we would not. dnf reads CRB only during that one transaction, so later dnf upgrade runs never see newer builds of what you pulled from it. The package then quietly falls behind on fixes, which is why the rest of this guide enables the repo properly.
Enable the CRB Repository on Rocky Linux and AlmaLinux
On Rocky Linux 10 and 9 and on AlmaLinux 9, dnf config-manager flips enabled=0 to enabled=1 in the repo file and saves it. That makes the change permanent, so it survives reboots and every later dnf run sees CRB. The subcommand comes from dnf-plugins-core, which our Rocky Linux 10 VM already had installed.
sudo dnf config-manager --set-enabled crbIt prints nothing when it works. The older --enable crb spelling you will see in many guides makes the same edit on dnf 4, and we ran both to be sure. For the rest of dnf’s repository options, our dnf guide for RHEL, Rocky Linux and AlmaLinux covers them. Confirm that CRB now sits next to the default three repos.
dnf repolistCRB now appears alongside BaseOS, AppStream and Extras. A name in this list only proves the repo is enabled, not that its metadata downloaded, so ask dnf repoinfo next.
repo id repo name
appstream Rocky Linux 10 - AppStream
baseos Rocky Linux 10 - BaseOS
crb Rocky Linux 10 - CRB
extras Rocky Linux 10 - ExtrasBesides the status, repoinfo shows the repo’s revision, its last update and how many packages it carries. A count of zero or a months-old date would point at the mirror rather than at your configuration.
sudo dnf repoinfo crbRocky Linux 10 reported 1,807 packages at revision 10.2, updated the day before our run. We cut the output down to the fields that matter.
Repo-id : crb
Repo-name : Rocky Linux 10 - CRB
Repo-status : enabled
Repo-revision : 10.2
Repo-updated : Wed Oct 14 07:53:46 2026
Repo-pkgs : 1807
Repo-available-pkgs: 1807
Repo-size : 33 GWith CRB on, the doxygen install that failed earlier goes through. It is a heavy package, though, so expect a long transaction.
sudo dnf install -y doxygenWe trimmed the output to the doxygen line and the transaction summary. That transaction installed 120 packages, 41 MB to download and 146 MB on disk, most of it graphviz, Ghostscript fonts, X11 libraries and 58 Perl packages, so we removed it again once the test was done, and you may want to do the same on a lean server.
Dependencies resolved.
================================================================================
Package Arch Version Repo Size
================================================================================
Installing:
doxygen x86_64 2:1.13.2-1.el10 crb 5.2 M
Transaction Summary
================================================================================
Install 120 Packages
Total download size: 41 M
Installed size: 146 MCheck where the package came from before you remove anything.
dnf info --installed doxygenFrom repo names the repository dnf installed a package from, so it’s the line to check whenever a package’s origin is in doubt. Here it reads crb.
Name : doxygen
Version : 1.13.2
Release : 1.el10
From repo : crbThe capture below strings the key steps together on the Rocky Linux 10 VM: the repo list before, the failed doxygen install, the enable command, the repo list after and the source of the installed package. The successful install sits between the last two commands but is left out, because its 120-package transaction would not fit on screen.
CRB is not the same size on every release, and its contents shift between majors. We read each repo’s package count from the vendors’ mirrors on 15 October 2026:
| Release | Repo ID | On by default | Packages | How we checked |
|---|---|---|---|---|
| Rocky Linux 10 | crb | No | 1,807 | Full VM |
| AlmaLinux 10 | crb | Yes | 1,803 | Repo file and mirror metadata |
| Rocky Linux 9 | crb | No | 2,955 | Repo file and mirror metadata |
| AlmaLinux 9 | crb | No | 2,910 | Repo file and mirror metadata |
| Rocky Linux 8 | powertools | No | 4,591 | Container |
| AlmaLinux 8 | powertools | No | 4,375 | Container |
Rocky Linux 9’s count looks bigger mostly because 856 of its CRB packages are i686 multilib builds, while the x86_64 CRB on both 10 releases carries no i686 packages at all. Content moves between majors as well, since python3-pathspec, which EPEL’s yamllint needs on 10, is not in Rocky Linux 9’s CRB. So when a package you remember from one release is missing on another, check the repo before you blame the mirror.
AlmaLinux 10 is the one host where you skip all of this. We pulled the almalinux-repos package from the AlmaLinux 10 BaseOS mirror, and its [crb] stanza reads:
[crb]
name=AlmaLinux $releasever - CRB
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/crb
# baseurl=https://repo.almalinux.org/almalinux/$releasever/CRB/$basearch/os/
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-10
metadata_expire=86400
enabled_metadata=0If dnf repolist on your AlmaLinux 10 machine does not show crb, one of three things happened. The host is a 10.0 install that never took the 2025-09-09 update, or someone switched CRB off. Otherwise the repo file was edited locally, and rpm then keeps your copy (it’s marked %config(noreplace)) and writes the new one as almalinux-crb.repo.rpmnew. In every case sudo dnf config-manager --set-enabled crb puts it back. AlmaLinux 9 still ships the same file with enabled=0, so it follows the Rocky Linux steps above.
Enable CRB with the crb Helper from EPEL
Most people enable CRB because EPEL asked them to, and EPEL’s release package ships a script that does it on any of these distributions. On Rocky Linux and AlmaLinux, epel-release sits in the Extras repository, so you install it by name without hunting for a URL.
On 10, enable CRB with dnf config-manager before you install epel-release, even if you plan to use the helper later. The epel-release 10 spec recommends selinux-policy-extra, which lives in CRB, and notes that weak dependencies missing at install time are skipped and never installed afterwards. That ordering comes from the spec rather than our run: we installed epel-release with CRB still off, and dnf installed that one package alone. If EPEL is already on your host, add the policy package once CRB is enabled.
sudo dnf install -y selinux-policy-extraOn a host without EPEL yet, install the release package itself.
sudo dnf install -y epel-releaseIts install scriptlet prints the next step for you, and it’s the only part of that transaction worth reading. EPEL adds the hint because so many of its packages fail without CRB, as the numbers further down show.
Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.On 8 and 9, crb enable is the one command to remember, and on a 10 host where you already enabled CRB it just confirms the state. The script lands in /usr/bin/crb with mode 0744. Only root can execute it, so a plain crb status fails with “Permission denied” and every subcommand needs sudo.
sudo crb enableIt reports the repo it found and switched on. On Rocky Linux and AlmaLinux 9 or 10 that is crb.
Enabling CRB repo
CRB repo is enabled and named: crbWe ran epel-release 10-7 from Rocky Linux Extras. EPEL’s 10-8 and 9-11 builds, released in June 2026 to fix a repo-detection bug, changed how the helper picks the repo on 9 and 10, and Rocky Linux and AlmaLinux hosts get them from EPEL on their first dnf upgrade. The new script takes the first crb, powertools or codeready repo in dnf repolist --all that isn’t a debug, source, EUS or virt variant. EPEL 8’s newest build, 8-22, keeps the older rule, which also drops RHUI repos and doesn’t stop at the first match, but on Rocky Linux and AlmaLinux 8 both rules land on powertools. Either way the helper hands the ID to subscription-manager repos on RHEL and to dnf config-manager everywhere else, so crb enable printed CRB repo is enabled and named: powertools on our Rocky Linux 8 container.
That makes the helper handy in a cloud-init file or an Ansible task that covers Rocky Linux and AlmaLinux 8, 9 and 10, with one catch on Rocky Linux 10. A script has to install epel-release before the helper exists, and CRB is still off at that moment on Rocky, so the selinux-policy-extra recommendation gets skipped. AlmaLinux 10 ships CRB enabled and doesn’t hit this. On Rocky Linux 10, follow crb enable with sudo dnf install -y selinux-policy-extra; we didn’t run that exact sequence in the lab.
Enable CodeReady Linux Builder on RHEL
On RHEL the repository is called CodeReady Linux Builder, it’s included with every RHEL subscription, and Red Hat does not support the packages in it. That matters on production hosts, so enable it on build machines and wherever EPEL needs it, but don’t expect a support case about a CRB package to go anywhere. The host has to be registered first, so check that.
sudo subscription-manager identityA registered host prints its system identity, and an unregistered one says it isn’t registered. Use this rather than subscription-manager status, because on a registered Simple Content Access host status can report Overall Status: Disabled, which Red Hat says is not an error. If it isn’t registered, register it with your Red Hat account login. Red Hat moved every account to Simple Content Access by October 2025, and RHEL 10 only registers against such accounts. Registration alone therefore opens the repositories, so the attach --auto step from older guides does not apply.
sudo subscription-manager registerNow enable the repository. $(arch) expands to x86_64 or aarch64, so the same line works on ARM servers. On RHEL 9 or 8, change the 10 to your major version; both lines are in the table at the top.
sudo subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpmsConfirm it from subscription-manager’s side. We can’t paste the output without a subscription in the lab, but you’re looking for a Repo ID line reading codeready-builder-for-rhel-10-x86_64-rpms, or the aarch64 name on ARM.
sudo subscription-manager repos --list-enabled | grep -i codereadyPay-as-you-go cloud images are the exception. They get RHEL content through Red Hat Update Infrastructure (RHUI) rather than subscription-manager, so the CRB repo ID differs. Skip the crb helper there. Since epel-release 9-11 and 10-8 (Bugzilla 2308671) it can pick up an RHUI repo ID, but on RHEL it still passes that ID to subscription-manager, which only manages redhat.repo. Find the IDs with dnf repolist --all | grep -i codeready, pick the one without debug, source or eus in its name, and enable it with sudo dnf config-manager --set-enabled followed by that ID. We couldn’t test any of the RHEL paths without a subscription.
Configuring access to RPM repositories is also an RHCSA exam objective. If you’re working through this to prepare for it rather than to close a ticket, these RHCSA and RHCE study books pair well with the lab work.
Enable PowerTools on Rocky Linux 8 and AlmaLinux 8
The 8 releases have no crb repo at all. Rocky Linux 8 and AlmaLinux 8 kept CentOS 8’s name for the same content, PowerTools, so an instruction written for 9 or 10 fails on them with a “No matching repo to modify” error. The troubleshooting section below shows it in full, and the fix is to use the other ID.
sudo dnf config-manager --set-enabled powertoolsIn our Rocky Linux 8 and AlmaLinux 8 containers, libyaml-devel failed with “Unable to find a match” before this command and installed right after it. Check the source the same way as on 10.
dnf info --installed libyaml-develThis time From repo reads powertools, so the repo ID is the only thing that changed. The verification step is otherwise identical to 10.
Name : libyaml-devel
Version : 0.1.7
Release : 5.el8
From repo : powertoolsRHEL 8 is the odd one out in this family, because it uses the same CodeReady naming as RHEL 9 and 10 (codeready-builder-for-rhel-8-$(arch)-rpms) instead of PowerTools. Our older PowerTools guide for CentOS 8 and RHEL 8 covers the 8-only details. On Rocky Linux and AlmaLinux 8, the crb helper finds powertools for you, as it did in both of our containers.
Install EPEL Packages That Need CRB
EPEL is built against RHEL with CRB available, so some of its packages need a library only CRB ships. To size that, we installed epel-release and ran dnf’s repoclosure check over the whole EPEL repo, once against BaseOS, AppStream and Extras alone and once with CRB (or PowerTools) added.
| Release | EPEL packages | Unresolved without CRB | Unresolved with CRB |
|---|---|---|---|
| Rocky Linux 10 (VM) | 23,984 | 457 | 4 |
| Rocky Linux 8 (container) | 10,348 | 850 | 145 |
| AlmaLinux 8 (container) | 10,348 | 848 | 144 |
On 10, CRB is the difference for about 450 EPEL packages, roughly 2% of the repo. The four that stay unresolved with CRB on carry only conditional dependencies, so CRB can’t fix them. dkms wants realtime or 64k kernel headers when those kernels are installed, two python3.13 packages want a wheel package alongside an older setuptools wheel, and wayvnc wants a newer sway when sway is present. On 8, PowerTools fixes about 700 packages and leaves 145 with other gaps we didn’t chase. Here are a few of the packages that broke on Rocky Linux 10 without CRB, and what each one was missing:
- yamllint:
python3.12dist(pathspec) - tox:
python3.12dist(pluggy) - moreutils:
perl(IPC::Run) - lcov:
perl(JSON::XS)andperl(Capture::Tiny) - mpv:
libuchardet.so.0
The check took about 20 seconds on the VM and needs only dnf-plugins-core plus EPEL. It reads repository metadata and installs nothing, so it’s safe to run on a production box. Its full report runs to well over a thousand lines, so we saved it to a file and counted the packages it flags. These are the Rocky Linux and AlmaLinux repo IDs, so on RHEL swap in the names dnf repolist shows.
sudo dnf repoclosure -q --repo baseos --repo appstream --repo extras --repo epel --check epel > /tmp/rc-nocrb.txt 2>&1; grep -c "^package:" /tmp/rc-nocrb.txtWithout CRB, you should see a count like ours, which is how many EPEL packages came back with unresolved dependencies on Rocky Linux 10:
457Add CRB to the repo set and run it again, and you get the last column of the table, the packages still unresolved with CRB on.
sudo dnf repoclosure -q --repo baseos --repo appstream --repo extras --repo epel --repo crb --check epel > /tmp/rc-crb.txt 2>&1; grep -c "^package:" /tmp/rc-crb.txtWith CRB in the set, you’re left with four:
4On 8, you swap --repo crb for --repo powertools, which is how we got the two container rows. Every package in that report fails to install for the same reason, a dependency that only CRB carries, and yamllint shows what it looks like from the command line: with EPEL installed and CRB still off, it cannot resolve its Python dependency.
sudo dnf install -y yamllintdnf names the missing capability and the EPEL package that wanted it. python3.12dist(pathspec) is an automatic Python dependency, and on Rocky Linux 10 the only package that provides it lives in CRB.
Last metadata expiration check: 0:00:55 ago on Thu Oct 15 20:03:10 2026.
Error:
Problem: conflicting requests
- nothing provides python3.12dist(pathspec) >= 0.5.3 needed by yamllint-1.37.1-1.el10_2.noarch from epel
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)Don’t reach for --skip-broken here, because it just skips the package you asked for. After sudo crb enable, the same install resolves, and the transaction shows exactly which piece came from CRB. Every package in the list above fails and recovers the same way.
================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
yamllint noarch 1.37.1-1.el10_2 epel 115 k
Installing dependencies:
python3-pathspec noarch 0.12.1-5.el10 crb 63 k
Transaction Summary
================================================================================
Install 2 PackagesThe capture below shows the helper’s status, the failed install, sudo crb enable, the source of python3-pathspec and the working yamllint. The successful install ran between sudo crb enable and dnf info --installed python3-pathspec and is left out of the capture. It installed yamllint from EPEL and python3-pathspec from CRB, as the transaction above shows.
Enable CRB first, then EPEL, then install the EPEL package, and this error never shows up. Our EPEL guide for Rocky Linux and AlmaLinux covers the full setup, including the GPG key import on the first install.
On RHEL, EPEL comes from the Fedora-hosted release RPM rather than Extras, and the EPEL install on RHEL 10 and CentOS Stream 10 walks through it. That RPM carries the crb helper too, but on RHEL the helper calls subscription-manager, a path we couldn’t test without a subscription, so the RHEL section’s commands are the safer route.
If you’re turning a server into a build host, set up the GCC compiler and Development Tools group as well. CRB supplies the headers but not the toolchain that compiles against them, so you need both before a source build gets far.
Fix the CRB Errors We Hit
Every error below came up during testing, on the Rocky Linux 10 VM or in the 8 containers. Each one points at a specific cause, so match the message before you change anything. Two of them only appeared on the 8 releases.
Error: No matching repo to modify: crb.
dnf config-manager couldn’t find a repo with that exact ID. On Rocky Linux 8 and AlmaLinux 8 that’s expected, because the ID there is powertools. Both containers returned this for sudo dnf config-manager --set-enabled crb:
Error: No matching repo to modify: crb.On 9 or 10 the same message means a typo, since the Rocky Linux 10 VM answered a misspelled ID with Error: No matching repo to modify: crb_typo. Run dnf repolist --all and copy the ID exactly as printed, or let sudo crb enable find it for you.
No such command: config-manager
The config-manager subcommand is a dnf plugin, and minimal or container images can leave it out. Our Rocky Linux 8 container had no dnf-plugins-core, so the first enable attempt stopped here.
No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"Install the plugin package and re-run the enable command. The crb helper checks for the same capability and aborts with a similar hint when it is missing, so it won’t get you around this one.
sudo dnf install -y dnf-plugins-core/usr/bin/crb: Permission denied
Every epel-release build we looked at (EL8, EL9 and EL10) installs the helper with mode 0744. A regular user can read it but not execute it, even for crb status. We captured the failure over a non-interactive SSH command, which is why bash prefixes it with bash: line 1:; an interactive login shell prints -bash: /usr/bin/crb: Permission denied instead.
bash: line 1: /usr/bin/crb: Permission deniedPrefix it with sudo. Don’t chmod the file, because the next epel-release update resets the mode anyway. sudo crb status is harmless to run anywhere, since it only reads dnf repolist.
Command line error: one of the following arguments is required
Fedora habits cause this one. dnf config-manager setopt crb.enabled=1 is dnf5 syntax, but Rocky Linux 10 and AlmaLinux 10 still ship dnf 4, whose config-manager only understands the flag form. Run it there and you get a usage error that starts like this:
Command line error: one of the following arguments is required: --save --add-repo --dump --dump-variables --set-enabled --enable --set-disabled --disableUse --set-enabled crb on the EL releases and keep setopt for Fedora, where the dnf5 config-manager syntax replaced the old flags. Nothing was changed by the failed command, so run the right one and carry on.
Disable CRB Without Stranding Packages
Turning CRB off takes one command, but check what you would strand first. Packages installed from CRB stay installed when the repo goes away. They just stop getting updates, because dnf can no longer see newer builds. The next EPEL update that needs a newer CRB build then fails. dnf records the source repo at install time, so you can list everything that came from CRB.
dnf list --installed | grep @crbOn the VM that meant the two packages from the tests above, and nothing else, since CRB started out disabled there. Review each line before you disable the repo, because every one of them stops receiving updates.
doxygen.x86_64 2:1.13.2-1.el10 @crb
python3-pathspec.noarch 0.12.1-5.el10 @crbUse @powertools on Rocky Linux and AlmaLinux 8, and grep @codeready on RHEL, where dnf records the full codeready-builder-for-rhel repo ID. If the list is empty, or you remove those packages first, disable the repo on Rocky Linux or AlmaLinux with the helper or with sudo dnf config-manager --set-disabled crb, which is also how you opt out of the AlmaLinux 10 default.
sudo crb disableThe helper confirms the new state, while dnf config-manager stays silent. Run sudo crb status afterwards if you used the dnf form and want the same confirmation.
Disabling CRB repo
CRB repo is disabledOn RHEL, dnf config-manager --set-disabled crb fails because no repo there is named crb, hand edits to redhat.repo get reset by subscription-manager, and we never tested the helper’s RHEL path. Red Hat’s documented route is subscription-manager again, and like the other RHEL commands we didn’t run it without a subscription. On 9 or 8, change the 10 to your major version.
sudo subscription-manager repos --disable codeready-builder-for-rhel-10-$(arch)-rpmsWe leave CRB on for any host running EPEL or building software, and off on minimal appliances that never install either, because a CRB package without its repo is a package that stops getting fixes. On RHEL, weigh that against the support question, since Red Hat never covered those packages in the first place.
I did that. And it’s enabled. Now how am i supposed to use it to start creating apps?