roasting claims to fail because of missing disk space while hundreds of GB are available

[mcepl]

Describe the bug

2025-09-01T16:47:50.500907Z  INFO obs_service_cargo::cargo_commands: 🏪 `cargo vendor` finished.
2025-09-01T16:47:51.556297Z  INFO libroast::operations::roast: ❤️‍🔥 Starting Roast.
2025-09-01T16:47:51.559384Z  INFO libroast::utils: ✅ Matched an item: /tmp/.vendor_out7dkIjkh2YuOJ
2025-09-01T16:47:54.565810Z ERROR obs_service_cargo::cli: err=Os { code: 28, kind: StorageFull, message: "No space left on device" }
2025-09-01T16:47:54.568148Z ERROR obs_service_cargo::cli: 🛑 Your `$TMPDIR` at /tmp has less storage space.
Ensure that your `$TMPDIR` at /tmp has a large storage space than the vendor, registry, and extracted or copied source code.
ℹ️ A workaround is setting `$TMPDIR` to another directory larger than the total size of your vendored tarball. For example,

export TMPDIR="$HOME/.cache"
osc service -vvv mr cargo_vendor


2025-09-01T16:47:55.341746Z ERROR cargo_vendor: No space left on device (os error 28)
Error: Os { code: 28, kind: StorageFull, message: "No space left on device" }
Aborting: service call failed:  /usr/lib/obs/service/cargo_vendor --srcdir zed --update true --compression zst --outdir /home/matej/build/mcepl/zed/tmpk4__5lol.cargo_vendor.service
mitmanek:zed (1!2?5M) $ df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         477G  458G   14G  98% /
tmpfs           7,2G   24M  7,2G   1% /tmp
efivarfs        248K  108K  136K  45% /sys/firmware/efi/efivars
/dev/nvme0n1p3  477G  458G   14G  98% /var/tmp
devtmpfs        7,2G     0  7,2G   0% /dev
tmpfs           7,2G  1,6M  7,2G   1% /dev/shm
/dev/nvme0n1p3  477G  458G   14G  98% /etc/hosts
/dev/nvme0n1p3  477G  458G   14G  98% /home/matej
tmpfs           2,9G  2,6M  2,9G   1% /run/.containerenv
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/root
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/mnt
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/srv
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/etc
tmpfs           2,9G  2,6M  2,9G   1% /run/host/run
/dev/nvme0n1p3  477G  458G   14G  98% /mnt
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/opt
tmpfs           1,0M     0  1,0M   0% /run/host/run/credentials/systemd-journald.service
tmpfs           1,5G  1,1M  1,5G   1% /run/user/1000
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/usr/local
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/boot/grub2/i386-pc
/dev/nvme0n1p2  500M  304M  196M  61% /run/host/boot/efi
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/boot/writable
/dev/nvme0n1p3  477G  458G   14G  98% /run/host/boot/grub2/x86_64-efi
tmpfs           1,0M     0  1,0M   0% /run/host/run/credentials/[email protected]
mitmanek:zed (1!2?5M) $ 

obs-service-cargo version (runrpm -qa | grep obs-service-cargo) obs-service-cargo-7.1.0-1.1.x86_64

To Reproduce https://build.opensuse.org/package/show/home:mcepl/zed?rev=2

Steps to reproduce the behaviour:

1. In the checkout, run osc service manualrun cargo_vendor
2. script fails, claiming that there is not enough free space on the drive (talking about TMPDIR is the only indicator).

Expected behavior Script should pass

[uncomfyhalomacro]

I tried reproducing it and it seems it went okay with the custom TMPDIR?

Btw, as for the error, it happens when vendoring takes more space than the total size of the partition/filesystem/directory. Hence, the instruction to set TMPDIR.

[mcepl]

Could we get at least some error message in the style of “We need 2 GB space and /tmp has just 1 GB”, so that user would have at least any idea, what’s going on?

[uncomfyhalomacro]

Could we get at least some error message in the style of “We need 2 GB space and /tmp has just 1 GB”, so that user would have at least any idea, what’s going on?

Will push a patch later. kind of preoccupied a lot as of the moment.