What causes "pacman -T failed: {}" in jdx/mise?

Run `pacman -T bash` manually and read the stderr shown in the error to see the underlying pacman failure

pacman -T failed: {}

Error message

pacman -T failed: {}

What it means

pacman -T (deptest) is used to check which package dependencies are missing. It exits 0 when all requirements are satisfied and 127 when some are unsatisfied (printing them to stdout); both are treated as normal. Any other exit code means pacman itself failed (bad DB, locked db, missing capability), and this error surfaces pacman's stderr.

Source

Thrown at src/system/packages/pacman.rs:368

    if names.is_empty() {
        return Ok(String::new());
    }
    let mut args = vec!["-T", "--"];
    args.extend(names.iter().map(String::as_str));
    debug!("$ pacman {}", args.join(" "));
    let output = tokio::process::Command::new("pacman")
        .args(&args)
        .env("LC_ALL", "C")
        .stdin(Stdio::null())
        .stdout(Stdio::piped())
        .stderr(Stdio::piped())
        .output()
        .await?;
    // deptest returns 127 when at least one requirement is unsatisfied and
    // prints those requirements to stdout. Both 0 and 127 are normal.
    if !matches!(output.status.code(), Some(0 | 127)) {
        let stderr = String::from_utf8_lossy(&output.stderr);
        bail!("pacman -T failed: {}", stderr.trim());
    }
    Ok(String::from_utf8_lossy(&output.stdout).into_owned())
}

pub(super) async fn resolve_installed_provider(
    request: &PackageRequest,
    eligible_names: &HashSet<String>,
) -> Result<Option<(String, PackageState)>> {
    let requirement = deptest_requirement(request);
    let deptest = pacman_deptest(&[requirement]).await?;
    let unsatisfied = parse_pacman_deptest(&deptest);
    let constraint_satisfied = unsatisfied.is_empty();
    if !constraint_satisfied {
        if request.version.is_none() {
            return Ok(None);
        }
        let bare_deptest = pacman_deptest(std::slice::from_ref(&request.name)).await?;
        let bare_missing = parse_pacman_deptest(&bare_deptest);

View on GitHub (pinned to afd2eddd3a)

Solutions

Run `pacman -T bash` manually and read the stderr shown in the error to see the underlying pacman failure
Reinitialize or repair the pacman database (e.g. `pacman -Sy` after fixing any lock: remove /var/lib/pacman/db.lck if no pacman is running)
Confirm you are on an Arch-based system with pacman installed and in PATH; otherwise configure a different package provider
If running in a minimal container, install/initialize pacman (e.g. via the base pacman package) before using this provider

Example fix

// before (container without pacman db)
mise packages install --provider pacman curl
// error: pacman -T failed: error: failed to init transaction (unable to lock database)
// after
pacman-key --init && pacman -Sy && mise packages install --provider pacman curl

Defensive patterns

Strategy: try-catch

Validate before calling

if !command_exists("pacman") { /* configure another provider */ }
let ok = Command::new("pacman").args(["-T","bash"]).status().map(|s| [0,127].contains(&s.code().unwrap_or(-1))).unwrap_or(false);

Type guard

fn pacman_usable(out: &Output) -> bool { matches!(out.status.code(), Some(0 | 127)) }

Try / catch

match provider.installed(&req).await {
    Ok(status) => use(status),
    Err(e) if e.to_string().contains("pacman -T failed") => fallback_to_other_provider(),
    Err(e) => return Err(e),
}

Prevention

Verify pacman exists and the pacman db is initialized before selecting the pacman provider
Avoid running pacman operations concurrently with other pacman processes (db.lck)
In containers, run `pacman -Sy` once at setup before package queries

When it happens

Trigger: Calling resolve_installed_provider or installed on a system where `pacman -T <deps>` exits with a code other than 0 or 127 — e.g. corrupted/missing local package database, pacman database lock, or pacman not functioning on a non-Arch system.

Common situations: Running mise's pacman package provider on a non-Arch system or in a container where /var/lib/pacman is absent or uninitialized; another process holding the pacman db lock; partial pacman upgrade leaving the db inconsistent.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/156838765bbd8332. Report an issue: GitHub.