fix: route forky/loong64 base-files lookups to the main archive

[igorpecovnik]

Summary

The scheduled `Data: Generate base-files package index` workflow (run 25245214054) is failing with:

```
Downloading Packages.gz for forky (loong64)...
requests.exceptions.HTTPError: 404 Client Error: Not Found for url:
http://ftp.ports.debian.org/debian-ports//dists/forky/main/binary-loong64/Packages.gz
```

Root cause

`generate-base-files-info-json.py` had an unconditional rule: any `loong64` lookup goes to `ftp.ports.debian.org/debian-ports/`. That was correct when loong64 was strictly a port — but in forky's testing cycle loong64 graduated to the main Debian archive. forky's `InRelease` now lists it under `Architectures:`, so the architecture loop hits it, and the hard-coded debian-ports URL 404s because that path doesn't exist.

`sid` still hosts loong64 as a port (sid's main `InRelease` doesn't list it, which is why `architectures += ['loong64']` is added manually for sid at the call site), so we can't just remove the debian-ports branch — we still need it for sid.

Fix

Replace the global `architecture == 'loong64'` switch with a per-release set of "ports-only" architectures. Today only `sid + loong64` is in the bucket; forky and later get the main archive.

```python
debian_ports_only = {
'sid': {'loong64'},
}.get(release_name, set())

if architecture in debian_ports_only:
base_url = "http://ftp.ports.debian.org/debian-ports/"
else:
base_url = "http://ftp.debian.org/debian/"
```

When sid finally promotes loong64 to main, drop the dict entry; when a future arch goes through the same promotion cycle, add it here per-release.

Test plan

• Re-run the failed cron (workflow_dispatch on `Data: Generate base-files package index`) — should complete and commit `base-files.json` with forky/loong64 populated from the main archive.
• Output JSON includes `forky.loong64` with a base-files filename present at `http://ftp.debian.org/debian/dists/forky/main/binary-loong64/Packages.gz\`.
• sid/loong64 entry continues to come from `debian-ports` (sanity check the dict-driven fallback still fires for sid).

[coderabbitai]

Warning

Rate limit exceeded

@igorpecovnik has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 25 minutes and 10 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c015f991-34b1-4113-8eff-6c2f7cc326fc

📥 Commits

Reviewing files that changed from the base of the PR and between 5575e41 and 0f5ef58.

📒 Files selected for processing (1)

• scripts/generate-base-files-info-json.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-base-files-loong64-in-forky

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 25 minutes and 10 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}