abra incorrectly handles missing recipe folders with commands new and app ls --status #749

New Issue

namnatulco · 2026-01-11T11:51:14Z

namnatulco commented

2026-01-11 11:51:14 +00:00

edit

This issue can be related to your firewall setup. If you're encountering this issue, one possible cause is that you're using both iptables and nftables. If that doesn't resolve the issue, verify whether you have firewall rules in place that could prevent abra from pulling the repositories (includind DNS resolution).

if you're on archlinux (like me) and have both iptables and nftables, you can fix it by installing iptables-nft (see Wiki). This can happen if you install docker (since it depends on nftables), since a standard archlinux installation depends on iptables.

original issue

I stumbled on the following issue (with abra version 0.12.0-beta-db7c404), possibly because I copied my .abra over and muddled around with it a bit. I can't entirely reconstruct how this state arose, but I also figured out a fix (see below).

Initial setup:

.
├── catalogue
│   ├── compose.yml
│   ├── makefile
│   ├── nginx.conf
│   ├── README.md
│   ├── recipes.json
│   └── renovate.json
├── logs
├── recipes
│   ├── traefik
│   ├── traefik-local
│   ├── traefik-upstream
│   └── writefreely
└── servers
    └── arch.fritz.box -> /home/namnatulco/repos/coop-cloud-server-config/

Bugreport

I typed abra app ls -S to see the status of my running services.

Expected behavior: get a list of running services and their status

Actual behavior:

FATA <app/list.go:148> unable to clone lauti.dyn.namnatulco.eu: Get "https://git.coopcloud.tech/coop-cloud/lauti.git/info/refs?service=git-upload-pack": dial tcp: lookup git.coopcloud.tech on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address
``´

## Possible fix
After some debugging, I figured out that the problem seems to be the missing .abra/recipes/lauti folder, since the same command with traefik works fine.

Creating the folder by itself changes the error:

FATA <app/list.go:153> unable to retrieve tags for lauti.dyn.namnatulco.eu: repository does not exist
``´

Aftter git init in the new folder, it works as expected.

I have attached a .txt with some outputs that describe the debugging in detail.

## edit This issue can be related to your firewall setup. If you're encountering this issue, one possible cause is that you're using both `iptables` and `nftables`. If that doesn't resolve the issue, verify whether you have firewall rules in place that could prevent abra from pulling the repositories (includind DNS resolution). if you're on archlinux (like me) and have both `iptables` and `nftables`, you can fix it by installing `iptables-nft` (see [Wiki](https://wiki.archlinux.org/title/Nftables#Installation)). This can happen if you install `docker` (since it depends on `nftables`), since a standard archlinux installation depends on `iptables`. ## original issue I stumbled on the following issue (with `abra version 0.12.0-beta-db7c404`), possibly because I copied my `.abra` over and muddled around with it a bit. I can't entirely reconstruct how this state arose, but I also figured out a fix (see below). Initial setup: ``` . ├── catalogue │ ├── compose.yml │ ├── makefile │ ├── nginx.conf │ ├── README.md │ ├── recipes.json │ └── renovate.json ├── logs ├── recipes │ ├── traefik │ ├── traefik-local │ ├── traefik-upstream │ └── writefreely └── servers └── arch.fritz.box -> /home/namnatulco/repos/coop-cloud-server-config/ ``` ## Bugreport I typed `abra app ls -S` to see the status of my running services. Expected behavior: get a list of running services and their status Actual behavior: ``` FATA <app/list.go:148> unable to clone lauti.dyn.namnatulco.eu: Get "https://git.coopcloud.tech/coop-cloud/lauti.git/info/refs?service=git-upload-pack": dial tcp: lookup git.coopcloud.tech on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address ``´ ## Possible fix After some debugging, I figured out that the problem seems to be the missing .abra/recipes/lauti folder, since the same command with traefik works fine. Creating the folder by itself changes the error: ``` FATA <app/list.go:153> unable to retrieve tags for lauti.dyn.namnatulco.eu: repository does not exist ``´ Aftter git init in the new folder, it works as expected. I have attached a .txt with some outputs that describe the debugging in detail.

abra-bugreport-checkout-missing-recipe.txt

8.0 KiB

namnatulco commented

2026-01-11 12:04:15 +00:00

okay, and I can confirm the issue for the new command;

abra app new nextcloud
FATA unable to update catalogue: Get "https://git.coopcloud.tech/coop-cloud/recipes-catalogue-json.git/info/refs?service=git-upload-pack": dial tcp: lookup git.coopcloud.tech on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address

This also happens with other recipes I haven't used, so maybe the issue is that I broke something while doing stuff to my .abra folder.

okay, and I can confirm the issue for the `new` command; ``` abra app new nextcloud FATA unable to update catalogue: Get "https://git.coopcloud.tech/coop-cloud/recipes-catalogue-json.git/info/refs?service=git-upload-pack": dial tcp: lookup git.coopcloud.tech on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address ``` This also happens with other recipes I haven't used, so maybe the issue is that I broke something while doing stuff to my `.abra` folder.

namnatulco commented

2026-01-11 12:26:27 +00:00

can reproduce the issue with a fresh install and a new .abra directory.
It could be related to the IPv6 lookup; I tried to force IPv4 by disabling IPv6 on the loopback and wireless interfaces (via /proc/sys/net/ipv6/conf/INTERFACE/disable_ipv6), but it still prints the v6 [::] addresses. Pulling works fine, though. Unfortunately that doesn't seem to be the case for the recipe fetching.

can reproduce the issue with a fresh install and a new .abra directory. It _could_ be related to the IPv6 lookup; I tried to force IPv4 by disabling IPv6 on the loopback and wireless interfaces (via `/proc/sys/net/ipv6/conf/INTERFACE/disable_ipv6`), but it still prints the v6 `[::]` addresses. Pulling works fine, though. Unfortunately that doesn't seem to be the case for the recipe fetching.

namnatulco commented

2026-01-11 13:31:34 +00:00

The new issue seems to be a separate problem. I tried to chase it down through the go-code, but it looks like the git clone indeed just fails (and the debug output that the clone was successful seems to be incorrect -- this suggests it was either an authentication error or an empty remote)

Replication via commandline git:

 git clone "https://git.coopcloud.tech/coop-cloud/recipes-catalogue-json.git/info/refs?service=git-upload-pack"
Cloning into 'refs?service=git-upload-pack'...
warning: redirecting to https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack/
error: inflate: data stream error (incorrect header check)
error: inflate: data stream error (incorrect header check)
error: File 7fda16bf55bbe256fd8b478e13c7db6c25da8d32 (https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack/objects/7f/da16bf55bbe256fd8b478e13c7db6c25da8d32) corrupt
error: Unable to find 7fda16bf55bbe256fd8b478e13c7db6c25da8d32 under https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack
Cannot obtain needed object 7fda16bf55bbe256fd8b478e13c7db6c25da8d32
error: fetch failed.

skipping the redirect gives the same output without the warning.

Removing the /info/refs?service=git-upload-pack works:

git clone https://git.coopcloud.tech/toolshed/recipes-catalogue-json
Cloning into 'recipes-catalogue-json'...
remote: Enumerating objects: 3532, done.
remote: Counting objects: 100% (3532/3532), done.
remote: Compressing objects: 100% (3531/3531), done.
remote: Total 3532 (delta 2326), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3532/3532), 798.20 KiB | 1.87 MiB/s, done.
Resolving deltas: 100% (2326/2326), done.

unfortunately it seems tracking down where the DNS issue comes from is beyond my go skills. Does it make sense to split this into a separate issue at this point?

In case anyone reads this with the same issue -- a workaround seems to be manually pulling the repos and then using --offline

The `new` issue seems to be a separate problem. I tried to chase it down through the go-code, but it looks like the git clone indeed just fails (and the debug output that the clone was successful seems to be incorrect -- [this](https://git.coopcloud.tech/toolshed/abra/src/branch/main/pkg/git/clone.go#L77) suggests it was either an authentication error or an empty remote) Replication via commandline git: ``` git clone "https://git.coopcloud.tech/coop-cloud/recipes-catalogue-json.git/info/refs?service=git-upload-pack" Cloning into 'refs?service=git-upload-pack'... warning: redirecting to https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack/ error: inflate: data stream error (incorrect header check) error: inflate: data stream error (incorrect header check) error: File 7fda16bf55bbe256fd8b478e13c7db6c25da8d32 (https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack/objects/7f/da16bf55bbe256fd8b478e13c7db6c25da8d32) corrupt error: Unable to find 7fda16bf55bbe256fd8b478e13c7db6c25da8d32 under https://git.coopcloud.tech/toolshed/recipes-catalogue-json/info/refs?service=git-upload-pack Cannot obtain needed object 7fda16bf55bbe256fd8b478e13c7db6c25da8d32 error: fetch failed. ``` skipping the redirect gives the same output without the warning. Removing the `/info/refs?service=git-upload-pack` works: ``` git clone https://git.coopcloud.tech/toolshed/recipes-catalogue-json Cloning into 'recipes-catalogue-json'... remote: Enumerating objects: 3532, done. remote: Counting objects: 100% (3532/3532), done. remote: Compressing objects: 100% (3531/3531), done. remote: Total 3532 (delta 2326), reused 0 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (3532/3532), 798.20 KiB | 1.87 MiB/s, done. Resolving deltas: 100% (2326/2326), done. ``` unfortunately it seems tracking down where the DNS issue comes from is beyond my go skills. Does it make sense to split this into a separate issue at this point? In case anyone reads this with the same issue -- a workaround seems to be manually pulling the repos and then using `--offline`

namnatulco closed this issue

2026-01-11 14:24:20 +00:00

namnatulco commented

2026-01-11 14:24:41 +00:00

closed as discussed on matrix, since better errorhandling is kidn of a rabbithole

👍 1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#749

abra incorrectly handles missing recipe folders with commands new and app ls --status #749

edit

original issue

Bugreport

abra incorrectly handles missing recipe folders with commands `new` and `app ls --status` #749