It seems I’m stuck at 2.0.0.rc25 even after I added Signed-by: … in my syncthing.sources file
Here is the whole file
Types: deb
URIs: ``http://apt.syncthing.net/
Suites: syncthing
Components: candidate
Signed-By: /usr/share/keyrings/syncthing-archive-keyring.gpg`
sudo apt-get update && sudo apt list –upgradable doesn’t show 2.0.2 is available
BTW, maybe apt.syncthing.net should be updated because recent distros use “package.sources” instead of “package.list”, and keys are now in /usr/share/keyrings/.
I suppose the candidate channel will receive a new version when there’s a new candidate release? Did it previously get stable releases before a new candidate came about?
Regarding the new syntax, I had looked into that previously but decided against it. Much harder to construct a one-liner for easy copy-pasting from the website. What Debian really needs is a tool to accept short syntax and write out the proper format in the proper location.
Maybe I’m puzzled André, don’t worry and I’ll wait - maybe I missed to see two stable without a candidate between them… more this time there were 3 stables after the latest candidate : it seems I misunderstood the channel usage.
About one-line commands, as one day the new source files format will become mandatory, we see Anydesk shows it’s own way with backslashes … but I admit even a friend of mine who was sysadmin (non nux) had headache with anydesk way… even me after 17 years in linux
Yeah, stable releases don’t go to the candidate channel, although they arguably should. I have on my mental todo list to improve our APT scripting to make things like that automatic.
In the meantime, yeah, we normally drop a candidate before a stable release. In this case I pushed out several “stables” with minor bugfixes to fix the immediate 2.0 regressions, somewhat short circuiting that loop. Once things stabilize the process will return to normal
I think you misunderstood. I was talking about which releases end up on the candidate channel, which does not include stable releases. Of course one could expect that any stable release had a matching candidate release directly preceding it, but that’s not quite true. There are usually some small fixes or translation updates in between.
And in this specific case, yes there were even stable “hotfix” releases without any candidate beforehand.
I agree that including stable in the candidate channel makes sense, although it will never be the latest version for long. That would make it a strict superset of the stable channel. Should increase the amount of historic versions offered there, when we do that.
You are right. I built my own interpretation without really knowing the actual mechanism of candidate vs stable releases. I wasn’t that much puzzled to see all my buddies one step ahead from me when it comes to using a new stable release. I just put this to account of they all are using stable channel and mainly all but 4 in Windows with autoupdate, when here I’m the only one with linux+candidate, so relying on scheduled update manager that introduces some delay.
That would mean I never used a stable release and didn’t even realize this !
Is it intended that ATM I see them (Windows/autoupdate) stuck at 1.30.0 ? Is there some manual exception/extended delay showing the “Update now” blue (in my memory) button in autoupdate mechanism to jump to 2+ ?
The only one that jumped to v2 is a daughter linux one that I had to help to update according to new apt.syncthing.net instructions (stable**-v2** channel) because it was stuck to 1.22 for monthes years (synthing.list disabled on dist-upgrade). And linux ones (with legacy stable-v2 channel setup) do not go to v2 ?
Regular Windows auto-updating installs should show a red upgrade button if they are still on 1.x. (Unless, I guess, they are on a Windows that’s old enough that they can’t run the new version. In that case they’d already be on something a lot older than 1.30.0.)
!
(synthing.list disabled on dist-upgrade). And linux ones (with legacy stable