Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Added the SDODS apt source and the key, then:
E: The repository 'https://sdods.com/apt ./ Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.The odd part: the files are there. curl https://sdods.com/apt/dists/stable/InRelease returns a signed index perfectly happily. So apt is asking for something in a different place than the one I can fetch by hand.
Accepted answer
Look at the distribution in your error: ./. That is a flat-repository source line, and this repository is not flat — it is a standard dists/ layout, which is why your curl of the dists/ path works and apt's fetch does not.
A flat source puts a ./ segment into every path apt builds, so it asks for:
https://sdods.com/apt/./InReleaseFix the source line to name the distribution and the component:
echo "deb [signed-by=/usr/share/keyrings/sdods-archive-keyring.gpg] https://sdods.com/apt stable main" | sudo tee /etc/apt/sources.list.d/sdods.listsudo apt update && sudo apt install sdodsThe two setup lines in full, with the key, are at https://sdods.com/apt/ and in Getting started → Installation.
Adding the detail that makes this worth reading rather than just fixing: the repository was published flat once, and it failed for everybody in exactly this way while looking perfectly healthy to curl.
The hosting layer answers a path containing /./ with a redirect to somewhere that 404s. Every file was reachable on the normalised path, so checking the files existed said the repository was fine. Only an actual apt install in a container found it.
If you copied the old line from somewhere, check for a stray [trusted=yes] too while you are in there. That disables signature checking for the source, and people add it to get past an error that is really about layout rather than signing.
General lesson from that one, since it applies well beyond apt: "the files are reachable" and "the client can use them" are different questions, and only the second one is the one you care about. The check that catches this is an install in a clean container, not a curl of each artifact.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.