Oof, yeah that's painful. I'm impressed you've gone to these lengths, most maintainers don't do that. They generally rely on the folks who want to use the software packaging it for their distros. Obviously there's a bit of a chicken and egg problem there, though, if you care about getting your software in front of users.
For the Debian situation specifically:
> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.
Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.
The software referenced is open source and it's already packaged to deb (see home page), so setting up the boilerplate for PPA submission (via AI) is very easy.
If a package doesn't have particular build requirements, setting up a PPA is overall simpler than hosting a personal repo (I do both).
To be clear, I'm not trying to argue or disagree with you. I agree that PPAs are a fine option. I'm not trying to disparage them, I'm trying to explain the reasoning behind my suggestion: PPAs enforce a number of requirements that exist for a reason, but that can be a challenge to meet depending on the project. The biggest example is that of source packages. I don't mean "your source needs to be open" (which of course this project is), but rather "your software needs to be built on Launchpad infrastructure." If you take a look at the existing CI the maintainer has in place to build the binary deb, you'll see what I mean: https://github.com/sinelaw/fresh/blob/master/.github/workflo... . The maintainer already has this, and it would need to be completely re-done to make it work in Launchpad, and the amount of work might be quite significant. A standalone Debian repo can just have binary debs, i.e. the work that has already been done can continue being used.
Thus my recommendation for aptly/reprepro: it's a more natural extension of what the project already has in place rather than a "you should do this instead."
Yeah, the one thing you're missing is getting into the users' `apt update`/`apt upgrade` flow, right? This will get you there without needing to change the Debian package you already create (although you can ship different ones this way if e.g. older Ubuntu/Debian distros require it and you want to support them).
You will also see this page if your smartphone is degoogled and you try to open the reCAPTCHA attestation URL in a web browser instead of in Google Play Services.
Yeah that's all it says ANYWHERE right now (https://status.canonical.com/, X, etc.), but so much of their infrastructure is down. Hoping for an update before too long.
That's not actually true: cell phone rx/tx power is quite low. We can get away with that because all they need to do is get to the nearest tower, which has a ton of power, sensitive antennas, and is very tall. Amateur radios have far more power available to them, but any "p2p" (i.e. simplex in amateur radio) runs into normal RF issues, like obstacles and interference. If you used the existing radios in cell phones to communicate directly with other cell phones, you wouldn't get very far. Even amateur radios, with all their power, use repeaters to the same effect as cell towers.
Why? That's kind of the whole point of this: they can cooperate entirely and give them everything they have. You think they'll get into legal trouble because they aren't gathering data?
There are a number of companies/products that operate under this principle (mullvad and signal come to mind). Are you saying all of those are futile and misleading? Or are you saying that you expect they all have significant money and legal teams to defend against a crooked cop's thirst for vengeance for not responding the way they wanted during an investigation?
For the Debian situation specifically:
> It would've been nice if there was a quick serverless solution where you could just say a URL to look for newer versions of a single package, and both apt and dnf would remember that and update a package.
Have you considered just hosting your own Debian repo? It's basically what you're looking for here. You don't need more infrastructure, either, you can host them straight in github pages with aptly or reprepro or something, and drop new releases in there from CI.