[Bug]: wrong architecture detected

[a-mnich]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Something seems to have changed with the architecture detection. Multiple applications which I already updated a few times now detect a different (wrong) architecture.

komac update KeeperSecurity.Commander --version 16.11.20 --urls https://github.com/Keeper-Security/Commander/releases/download/v16.11.20/keeper-commander-windows-v16.11.20.exe

InstallerType: inno
Detected: x86 Correct: x64

komac update wire.wire --version 3.37.5077 --urls  https://github.com/wireapp/wire-desktop/releases/download/windows/3.37.5077/Wire-Setup.exe

InstallerType: exe
Detected: x86 Correct: x64

komac update UltimateGadgetLaboratories.UHKAgent --version 5.0.0 --urls https://github.com/UltimateHackingKeyboard/agent/releases/download/v5.0.0/UHK.Agent-5.0.0-win-ia32.exe https://github.com/UltimateHackingKeyboard/agent/releases/download/v5.0.0/UHK.Agent-5.0.0-win.exe https://github.com/UltimateHackingKeyboard/agent/releases/download/v5.0.0/UHK.Agent-5.0.0-win-x64.exe

InstallerType: nullsoft
Multiple installer blocks with architecture x86 while the one with UHK.Agent-5.0.0-win.exe should be neutral
microsoft/winget-pkgs@3e19c7d

PRs:

• New version: KeeperSecurity.Commander version 16.11.20 microsoft/winget-pkgs#196924
• New version: wire.wire version 3.37.5077 microsoft/winget-pkgs#194941
• New version: UltimateGadgetLaboratories.UHKAgent version 5.0.0 microsoft/winget-pkgs#199079

[russellbanks]

For KeeperSecurity.Commander, I don't believe x64 is the correct architecture. The header of the Inno data defines it as being x86compatible:

architectures_allowed: ArchitectureIdentifiers(X86_COMPATIBLE),
architectures_disallowed: ArchitectureIdentifiers(0x0),
architectures_install_in_64_bit_mode: ArchitectureIdentifiers(X86_COMPATIBLE),

In the Inno setup documentation:

x86compatible
Matches systems capable of running 32-bit x86 binaries. This includes systems running x86 Windows, x64 Windows, and also Arm64 Windows 10 and 11 systems, which have the ability to run x86 binaries via emulation.

x86 binaries can still install fine on x64 systems. Specifying x64 in the manifest will unnecessarily prevent users on x86 systems being able to install it through WinGet.

[russellbanks]

The UHK.Agent-5.0.0-win.exe for UltimateGadgetLaboratories.UHKAgent is not actually a neutral installer. Neutral is a value generally used for MSIX installers that defines that it can install on x86, x64, arm, and arm64 systems. This binary is instead a combination of both the x64 and x86 installers.

Instead, this installer entry should be removed as it has no purpose other than allowing WinGet to mistakenly attempt to install it on arm and arm64 systems. It is also twice the size of the other two installers as it incorporates both of them which again has no added benefit here as WinGet already knows what architecture the system is so it can download the relevant one.

[a-mnich]

For KeeperSecurity.Commander, I don't believe x64 is the correct architecture. The header of the Inno data defines it as being x86compatible:

architectures_allowed: ArchitectureIdentifiers(X86_COMPATIBLE),
architectures_disallowed: ArchitectureIdentifiers(0x0),
architectures_install_in_64_bit_mode: ArchitectureIdentifiers(X86_COMPATIBLE),

That's interesting. When initially opening the PR with x86, the validation pipeline got a validation executable error label and with the error The specified executable is not a valid application for this OS platform in the logs.
References:

• Logs
• Failed run
• All runs of the PR

So in this case I would say it's an issue of the installer being declared as x86compatible even though it seemingly isn't. (Unfortunately I don't have a x86 machine at hand for testing this)

The UHK.Agent-5.0.0-win.exe for UltimateGadgetLaboratories.UHKAgent is not actually a neutral installer. Neutral is a value generally used for MSIX installers that defines that it can install on x86, x64, arm, and arm64 systems. This binary is instead a combination of both the x64 and x86 installers.

Thanks for checking this. Makes sense :)
Do you happen to have any tools available for such situations? I feel a bit guilty for raising an issue since these two seem to be installer problems or just incorrect manifests.

[russellbanks]

That's interesting. When initially opening the PR with x86, the validation pipeline got a validation executable error label and with the error The specified executable is not a valid application for this OS platform in the logs.

Even if a pull request gets the tag validation executable error, it doesn't necessarily mean there's anything wrong with the manifest. Unless it's very explicit like the manifest is clearly wrong, it's often best to see what a mod says rather than trying to make changes. For example, the pipelines could just have an issue running it and oftentimes I, as a moderator, manually rerun it and it'll be successful that time.

I tried resubmitting the pull request with the x86 architecture and while it did get the same label, this was able to be removed by another moderator - microsoft/winget-pkgs#199434.

I feel a bit guilty for raising an issue since these two seem to be installer problems or just incorrect manifests.

Don't feel guilty at all. Every issue I've had has been helpful to me. Even if it's not necessarily something to be fixed, it allows me to test komac on installers I haven't come across in more depth.

Also, the wire.wire installer is an unknown installer but I think I've found a way to be able to unpack it and get the correct architecture.

[russellbanks]

Do you happen to have any tools available for such situations?

The next version of komac is, as always, a bit better with manifests than the previous/current version. Submitting UltimateGadgetLaboratories.UHKAgent with just the x64 and x86 URLs passed creates a more correct manifest here - microsoft/winget-pkgs#199483.

This will be because it will try to pair up one of the installers with the 'neutral' installer, notice that it's not actually neutral and change it to x86, and then remove it because it's then identical to the x86 installer.

[hovancik]

Hi, I think I have the same issue: microsoft/winget-pkgs#204638

Is there some way to workaround it with kamac or should I manually change architecture in PR?

I am asking because I would like to make this automatic via github actions when I make new release.

Thanks!

[russellbanks]

Hi @hovancik! Thanks for reporting! This is fixed in 320c288 and will be included in komac v2.9.0.