New releases

[opusforlife2]

Hi. I randomly stumbled upon the main repo and noticed that there have been 2 new releases of Stubby. Could this Chocolatey package please be updated too?

[opusforlife2]

Hi, could this please be triaged?

[saradickinson]

There was an update in the 1.7.3 getdns release that broke the Windows build, and while there is a PR to fix it, it hasn't been merged.... getdnsapi/getdns#538. I'll reach out to see when we might be able to get a new getdns release that includes this fix.

[saradickinson]

OK - rather than a new official release, we've created a patched release that just fixes the problems with the Windows build for now. This is listed on the webpage as 0.4.4-rc1:
https://dnsprivacy.org/dns_privacy_daemon_-_stubby/installation/windows_installer_for_stubby/#version-044-rc1
Chocolately package has been submitted and is waiting moderation.

[opusforlife2]

Thanks for the update! The new package is now available. However, the upgrade fails via Chocolatey, and the error message talks about a restart requirement.

Could you please check this? There is the option to manually upgrade directly via an installer, but that makes using Chocolatey moot.

[saradickinson]

Sorry you had problems with this....
So both an upgrade and a clean install work for me from Chocolatety on Windows 10 - what version are you on?
Did you try to remove and re-install?
Can you send me any more details from the chocolatey log file? C:\ProgramData\chocolatey\logs\chocolatey.log

[opusforlife2]

Turns out that the Stubby service couldn't be stopped by the upgrade/install script due to a lack of permissions. Instead, looking at the Services list showed that Stubby was "Stopping" indefinitely.

Don't know why that happened, because you need to run choco as admin to be able to modify packages. I tried manually stopping the service and then installing the package. That worked. So I'm successfully on the latest version now.

For context, the error I talked about above, also contained a suggested command to run (--install-arguments...) to obtain the MSI log file, and to look for the error there. That's where the permission error showed up.

Thanks for the help and the update! I'll close this issue since it is solved.

(If you would like to debug the permission thing, we could do that with the next update?)