Lidarr: Update to v2.0.7.3849

[mreid-tt]

Description

This includes the following fixes:

1. Update to v2.0.7.3849.

Fixes #

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Package update

[hgy59]

@mreid-tt to remember:

packages using SPK_VERS = $(shell date +%Y%m%d) as version
are using package internal updates and do not need package updates, except for the following reasons:

• There are spksrc framework changes, that need to be applied to the package (i.e. changes in install scripts, additional package archs, etc.)
• package internal updater does not provide updates to latest version (incompatible changes)
• published package version takes too long to self update to the latest version
• required package installation changes in wizards or service-setup.sh,

So for such package updates, I would expect that the reason is provided (in the PR and the CHANGELOG), why an update is required.

And to test that the internal self updates still work, it is required to build the package with one version before the latest.

[mreid-tt]

@hgy59, thanks for your feedback. The recent update was prompted by a major version change in the source. While the built-in updater still works, I find it beneficial to release a new update for users, especially in cases of significant version shifts.

A common issue occurs when a user updates internally, uninstalls the app (keeping configurations), and then reinstalls it. This can cause an incompatible database schema, leading to a broken install. While a solution exists involving SSH and relocating config files, it poses a challenge for many users. Let me know your thoughts.

EDIT: Testing the internal updater with the version preceding the latest one poses a significant challenge, especially for packages that have infrequent release cycles, spanning months between updates.

[mreid-tt]

@hgy59, I noted that when I published this build some of the archs which are explicitly excluded seem to have been built. For example, even though we have this line:

spksrc/spk/lidarr/Makefile

Lines 9 to 10 in 7625f23

	# Arch exclusions for dotnet 6.0
	DOTNET_SERVARR_ARCHS = 1

... and this line translates to these previously defined exclusions:

spksrc/mk/spksrc.archs.mk

Lines 67 to 71 in 7625f23

	# Exclusions for dotnet 6.0 servarr apps (except x86)
	ifeq ($(strip $(DOTNET_SERVARR_ARCHS)),1)
	UNSUPPORTED_ARCHS = $(PPC_ARCHS) $(ARMv5_ARCHS) $(ARMv7L_ARCHS) armada370 alpine alpine4k
	UNSUPPORTED_ARCHS_TCVERSION = armv7-6.1 armv7-1.2
	endif

I still see builds for Packages for armv7-6.2.4. Was there a change elsewhere in the framework that broke the exclusions?

[hgy59]

Was there a change elsewhere in the framework that broke the exclusions?

If armv7-6.2.4 must be excluded (as the comment tells) then UNSUPPORTED_ARCHS_TCVERSION must contain armv7-6.2.4.
Is seems that this was not adjusted when we switched from 6.1 to 6.2.4 toolchain builds in github action and make all-supported.

For the latest lidarr publish you can just delete the armv7-6.2.4 package in the repo.

For future builds we should fix the spksrc.archs.mk file.

[mreid-tt]

@hgy59, thanks much for getting to the bottom of this. I've manually removed the armv7-6.2.4 builds for Sonarr (v4), Radarr, Lidarr and Ombi.