Chocolatey-coreteampackages: (sysinternals) checksum error

[jberezanski]

The sysinternals zip file was updated on the origin server (SHA256 of https://download.sysinternals.com/files/SysinternalsSuite.zip is currently 9C55CEF14E4CFD65CDD2CAA27F3A718D68BDB7B9BDA14A54139B08B40B96015D). Looking inside, a few binaries were modified on 2017-06-08. However, Microsoft did not update the "last modified" text on the download page (https://technet.microsoft.com/en-us/sysinternals/bb842062), so AU did not notice the changes and the Chocolatey package did not get updated.

Assuming this is a one-time oversight on Microsoft side and the au_GetLatest logic does not need to change, is there an easy way to force AU to regenerate the checksums and publish the package with an explicitly specified version number?

[AdmiringWorm]

probably won't happen that often.
Why use a explicit version?
Why not just do a normal fix update? [AU sysinternals]?

Since we only use 3 parts of the version, that should be fine

[majkinetor]

As @AdmiringWorm noted, recheck is possible with [AU sysinternals] which would generate fix version. To force AU to update package on checksum change see for example how I handle cpu-z package:

https://github.com/majkinetor/au-packages/blob/master/cpu-z.install/update.ps1#L30-L37

[jberezanski]

Why use a explicit version?
Why not just do a normal fix update?

The versioning scheme for the package is "yyyy.mm.dd", so 2017.05.22.20170609 would look silly :-)
It could also imply a packaging fix only (no change in binaries), which is not the case here. That is why I think it would be best to release it as version 2017.06.08 (the latest modification date of the zipped binaries).

@majkinetor Neat trick. In this package we could go even further and compute the version based on binary modification dates.

[AdmiringWorm]

2017.05.22.20170609 would look silly

Package fix notations looks silly no matter what the version scheme IMO, so I feel that doesn't really matter.

It could also imply a packaging fix only (no change in binaries),

Not really, it implies that something have changed, but no new version is available. Which is appropriate in this case.

That is why I think it would be best to release it as version 2017.06.08 (the latest modification date of the zipped binaries).

I'm against this as that would imply that a new version is actually available, which isn't reflected on the project page.

[jberezanski]

The project page does not show the current version number, it only claims "Updated: May 22, 2017" (which may as well refer to the project page itself). Whatever, I don't really care about it.

Meanwhile, going back to my original question and clarifying it: does the commit message syntax ([AU ...]) support forcing a specific version number? (It seems that AU itself supports it via $au_Version.)

[AdmiringWorm]

it only claims "Updated: May 22, 2017"

Which is what we use as a version.

Meanwhile, going back to my original question and clarifying it: does the commit message syntax ([AU ...]) support forcing a specific version number? (It seems that AU itself supports it via $au_Version.)

yes it does, using [AU packageName:packageVersion]

[jberezanski]

Thanks, good to know.

As it seems I'm outvoted here, I'll just trigger AU to generate a fix version.

[jberezanski]

Something's weird.

• chocolatey.org correctly shows the newly published version 2017.5.22.20170609 as latest
• yet when I invoke cup -y sysinternals on my choco 0.10.5 it still tries to install 2017.05.22
• clist sysinternals shows 2017.5.22.20170609
• choco outdated shows 2017.05.22 as latest

Is there a known issue with "05" sometimes being treated as newer than "5"?

[AdmiringWorm]

That certainly is odd. There isn't any issues I'm aware of that treats 05 as newer than 5.
Just tried to install it inside a test environment (running choco v 0.10.6.1), and it grabbed the latest version for me.

[AdmiringWorm]

Also tried installing the previous version (ignoring the checksum) then upgrade it, still works fine for me.

[jberezanski]

Upgraded my choco to 0.10.7 - no change.
Fresh install on a test VM with choco 0.10.3 - it installed 2017.05.22.

By the way, choco info sysinternals returns for me "0 packages found", both on the main system and on the VM. Does it work for you?

[AdmiringWorm]

yup, just tried choco info sysinternals which worked fine for me.
But that is a known issue though. If I remember correctly, it's possibly related to a caching issue.

[jberezanski]

Alright, it came to its senses. Must have been a CDN/cache issue.