V7.10 still having trouble removing packages

[drtinaz]

I thought it best to open a new issue so things don't get buried in the mud. I am still having trouble removing a package if there is a conflict or an error. I click on remove and get the prompt "remove package name?" But there is no button to confirm, only cancel.

Packages with no issues or conflicts can be removed without issue.

Edit to add: One more thing I discovered while poking around with this is that the package that was showing the error was a patching error. The cause showed to be no source file, which is false. Regressing to setuphelper v6.10 allowed installation of the package with a successful patch.

[kwindrem]

I am able to REMOVE packages with a conflict showing.

I'd need firmware version, SetupHelper version, Package name and version - both that are involved in the conflict

I also need logs.

Use Backup and restore to backup the settings to a USB stick. On the stick you'll find a logs.zip. Post that here

[kwindrem]

I do see a bug where the conflict information is not cleared after it's been resolved. You can restart PackageManager to resolve that until I can push out a fix. But this should not be disabling Uninstall or Remove buttons.

[kwindrem]

v7.11 is out that should clear the conflict information if it is resolved.

As I said above, the fact that conflict info wasn't being cleared should not have been blocking Uninstall or Remove. (but does block Install).

v6.x does not have any conflict resolution.

What was the complete error regarding no source file? It should have said which one. Further, you can check the active file location to make sure either the file or the .orig file are present.

[drtinaz]

The file was /usr/lib/node_modules/node-red/venus-settings.js. It's just a simple patch that enables context storage. The file did exist and did match the .source file. Something got hung up somewhere. I reverted to setuphelper v6.10, removed the package, went back to v7.10 and readded the package and there was no error. Install was successful. I believe this was Venus v3.30. this was on my test system which is in my shop so I don't have access to it right now.

[drtinaz]

This morning I checked my test system to see that v7.11 was installed, it was not, I must have left it on v6.10 with back and forth testing last night. I switched back to "latest" and v7.11 installed. When I opened the active packages menu, the same package that had the patching error yesterday (ContextStorage) was showing "patching error", even though it is installed and working. I opened the package to see the error, and within a few seconds the error went away. It now shows as normal. Maybe something going on in the checking process? Or is this expected behavior? Maybe setuphelper needed to 'catch up' and realize that the package was already installed and therefore the patch can't be applied anyway? I don't want to cause a problem for you where there isn't one.

[kwindrem]

The source file reference is to the active file on the GX device Either the .orig or the active file itself is needed during install to create the patched file which eventually replaces the active file.

(The .source and .edited files are only used by updatePackage to generate the .patch file. They are not used on the GX device.)

Regarding the Package conflict message not going away: There was a bug in SetupHelper v7.10 (and possibly previous versions) that didn't clear the conflict even though it was resolved. v7.11 fixed that. It may take a few seconds to clear the message however. (Previously, the only thing that cleared the conflict was downloading or installing the package!)

[drtinaz]

Ok so I'm hearing that it's not necessarily a problem, it just took a few seconds to clear the old error when setuphelper updated to v7.11.

I've never been someone to leave things alone, I always have to tinker. Am I trying your patience yet? I appreciate your long-suffering.

[kwindrem]

No problem at all. I appreciate the dialog and it's helping make SetupHelper better. So thanks, and keep it coming.