kernel: Update sources to DSM-7.2-72806 build

[th0ma7]

Description

kernel: Update sources to DSM-7.2-72806 build

Commits from PR #6646
In support to PR #6772

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

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[th0ma7]

@hgy59 for your review, exctracted from my original PR.

[th0ma7]

 @hgy59 friendly reminder, looks ok to me but a second pair of eye would be nice to have. thnx in advance.

[hgy59]

@hgy59 friendly reminder, looks ok to me but a second pair of eye would be nice to have. thnx in advance.

With the latest dicussions about os_min_ver, I just want to mention that we left the former toolchain versioning.
With DSM 6 we have 6.2 (i.e. 6.2.0), 6.2.2, 6.2.3 and 6.2.4
For DSM 7 we have 7.1 (i.e. 7.1.1) and 7.2 that is actually 7.2.2.
But we might split it to 7.2 (i.e. 7.2.0), 7.2.1 and 7.2.2.

IMHO this would be mandatory for kernel sources.

Luckily the os_max_ver can be overwritten by a package, i.e. we can define a lower build number like 63134 for DSM 7.2 PHP packages, that are independent of exact toolchain version.
But when we currently build for 7.2 we really build for 7.2.2 and do not support 7.2.0 and 7.2.1. this is leaving a gap when we have to implement different builds (and package dependencies) for DSM 7.0 to 7.1 and 7.2.

We probably want to lower the built number (in tc_vers.mk) for DSM 7.2 to the one of DSM 7.2.0 but still build with the DSM 7.2.2 toolchains.
This would look good to me as glibc and kernel versions are the same, but would this affect the kernel packages?

/cc @mreid-tt

see SynoCommunity/spkrepo#159 (comment)

[mreid-tt]

@hgy59, thanks for considering this. Since our noarch packages rely on manually defined lower bounds rather than the toolchain version, most of the PHP-based packages we build won’t be materially affected by the gap identified.

The greater impact is on architecture-specific packages. For DSM 6, there is indeed a support gap (build 23739 to 25555), but given the EOL status of DSM 6.2, I’m less concerned about that. My main focus is DSM 7.2 and the support gap there (build 64561 to 72805). Fortunately, we only have a few packages that rely on this — namely Jellyfin, Prowlarr, and Lidarr. If adjusting TC_VERS is problematic, I’m happy to define an OS_MIN_VER specifically for these packages to ensure appropriate coverage.

Alternatively, if we set TC_VERS to the earliest toolchain version available for each DSM version, we could ensure packages remain compatible across the full range without unintentional exclusions via toolchain updates. I’m not sure whether this might introduce any support issues, but that’s my initial thinking.

[mreid-tt]

Hey @th0ma7, based on my comment above which direction are we thinking of going... updating the TC_VERS or setting the OS_MIN_VER? I noted a new package in #6786 which has a DSM 7.2 requirement and wanted to know before reviewing it.

[th0ma7]

Unsure... I'll have to think further about this one.

[mreid-tt]

Unsure... I'll have to think further about this one.

Hmm, okay. Ideally it should be dynamic. We can have the TC_VERS for its intended purpose and maybe at the time of determining the OS_MIN_VER in package construction, lookup a BASE_TC_VERS that would report a build number at the start of the two-digit range. In other words, for TC_VERS of 6.2.4 the lookup would be for 6.2 in the BASE_TC_VERS which would report 22259. Similarly a BASE_TC_VERS for 7.2 would report a build 81180. What do you think?

[th0ma7]

It took me a little to (re)read the PR info, hopefully I capture the essence of the discussion and won't be mudding the water too much.

I particularly like view from your proposed table, with the caveat that OS Min should match our toolchain build number.

DSM Ver	OS Min	OS Max
DSM 6.2	6.2-22259 6.2-25556	6.2-39999
DSM 7.0	7.0-41890	7.0-42499
DSM 7.1	7.1-42661	7.1-59999
DSM 7.2	7.2-63134 7.2-72806	7.2-79999
DSM 7.3	7.3-81180	-

From my perspective we really shouldn't bother with the 3rd digit as the build number superseeds that anyway. What I gather is that any NAS being supported with, for instance the 7.2 branch, will keep being supported until the end of that 7.2 branch. Our builds should directly align with the build number used for the toolchain, with the exception of kernel modules that should align with the kernel build number. For users not seing packages, well, they should apply the security fix for that branch so their base build number becomes >= then our toolchain build number.

For instance, looking at what's currently available on synology download archive for toolchains:

• 7.2-72806
• 7.2-72746
• 7.2-63134

That said, kernel modules should never a toolchain build number higher than its own, here are kernel builds:

• 7.2-72806
• 7.2-64570

This means that kernel modules using build 7.2-64570 should only be built using a toolchain 7.2-63134, with a resulting os_min_ver="7.2-64570".

Issue is that we're not using build numbers in our framework... Instead we have in spksrc.tc-vers.mk the following:

ifeq ($(TC_VERS),7.2)
TC_BUILD = 72806
endif

It dictates what version to download but really this should be in the toolchain Makefile, like done for kernels and getting rid entirely of that spksrc.tc-vers.mk.

Question is: should the directory structure be revisited to match that, such as syno-apollolake-6.2-25556 instead of syno-apollolake-6.2.4? I tend to believe so. So doing a make arch-apollolake-7.2 would automaticallly pick the latest available 7.2 build number and os_min_ver would match that. To implement would be something such as make arch-apollolake-7.2-<build#> to complement, allowing us to have multiple 7.2 toolchains, similarly to what's being provided by synology.

All in all, from my perspective os_min_ver should match the toolchain used.

[mreid-tt]

Hey @th0ma7, thanks for the analysis. If I understand correctly, you’re saying that users on an earlier 7.2.x build (e.g., 7.2.1-69057) who choose not to update to the latest 7.2-72806 would effectively be excluded from installing packages (such as Jellyfin) when the OS minimum is set to 7.2. That feels quite restrictive, and I’d prefer if we could support the full range of 7.2 builds, ideally back to the first 7.2 release (7.2-63134), to be more inclusive of all variants.

[th0ma7]

If I understand correctly, you’re saying that users on an earlier 7.2.x build (e.g., 7.2.1-69057) who choose not to update to the latest 7.2-72806 would effectively be excluded from installing packages (such as Jellyfin) when the OS minimum is set to 7.2. That feels quite restrictive, and I’d prefer if we could support the full range of 7.2 builds, ideally back to the first 7.2 release (7.2-63134), to be more inclusive of all variants.

@mreid-tt I disagree related to the restrictiveness part of this: there are no reasons for a user to avoid applying security updates, and honestly I don't find this is our problem neither. Still, to follow your thought, that would mean we always stick to using the lowest toolchain build version i.e. 7.2-63134 to ensure proper compatibility, wich we currently aren't as we are rather using latest, 7.2-72806. But easy to do...

It also goes back to the potential need of having multiple 7.2- toolchains and removing the third digit used in versions... noting that kernels always needs to match as closely as possible to your running kernel. And personally I'm not willing to provide both 7.2-72806 and 7.2-64570 kernel modules packages ... that is too much work, user simply needs to upgrade.

And then again, this problem only concerns 7.2, for the handful of packages no longer compatible with 7.1. I don't see much fuzz of telling users to upgrade (otherwise we must downgrade our toolchain accordinly to ensure compatibility).

This is currently quite "niche" but might change with the arrival of 7.3 for which the toolchain isn't yet available ...

[mreid-tt]

Hey @th0ma7, thanks for the feedback. Just to clarify, I wasn’t proposing that we build using multiple toolchains. My intention is to continue building with the latest toolchain, but to set the package’s OS minimum to the earliest build for that major–minor DSM version. With that in mind, adding a manual override for OS_MIN_VER seems like a straightforward way to accomplish this if spksrc won’t handle it automatically.

[th0ma7]

Thnx for the p precisions @mreid-tt , this would mean risking that packages may be incompatible considering updated libs and all between toolchain builds. Risk probably low but still.

While i get your point I'm unsure of the benefits. I still believe users must upgrade their dsm and our packages should reflect real build matches. But I'll adjust to what the majority will agree towards.

Noting that having package download stats would have been nice.. knowledge of are there really that many users in this scenario.

[mreid-tt]

Hey @thomas, okay. The part I’m still a bit unsure about is how we treat noarch packages, since they don’t really align with the toolchain used to build them (assuming we always use the latest toolchain). Do you have any thoughts on this? Should we also keep the noarch build numbers aligned with the toolchain version?

[hgy59]

Hey @th0ma7, thanks for the feedback. Just to clarify, I wasn’t proposing that we build using multiple toolchains. My intention is to continue building with the latest toolchain, but to set the package’s OS minimum to the earliest build for that major–minor DSM version. With that in mind, adding a manual override for OS_MIN_VER seems like a straightforward way to accomplish this if spksrc won’t handle it automatically.

Yes, that was my intention too.
Build for 7.1 with the latest 7.1.1 toolchain and build for 7.2 with the latest 7.2.2 toolchain but having the os_min_version in the INFO file at the lowest 7.1 version (7.1.0-42661) and lowest 7.2 version (7.2.0-63134).

Just wanted to ask @th0ma7 what this means for packages containing kernel modules

[th0ma7]

The part I’m still a bit unsure about is how we treat noarch packages, since they don’t really align with the toolchain used to build them (assuming we always use the latest toolchain). Do you have any thoughts on this? Should we also keep the noarch build numbers aligned with the toolchain version?

I would keep things as simple as possible and align with what ever is the decision for regular builds.

Yes, that was my intention too.
Build for 7.1 with the latest 7.1.1 toolchain and build for 7.2 with the latest 7.2.2 toolchain but having the os_min_version in the INFO file at the lowest 7.1 version (7.1.0-42661) and lowest 7.2 version (7.2.0-63134).

I'm concerned that we may hit a compatibility issue and should avoid that: either build with the lowest toolchain build number or the highest, but in all cases ensure the OS_MIN_VER matches. But I'll align with you two if you both want to go a different way and reconvene if there is really a compatibility issue.

what this means for packages containing kernel modules

From my perspective this is non-negociable: build versions must match, therefore kernel modules must use the build number matching the kernel sources... and toolchain used must be as close as possible to that build.

[mreid-tt]

Noting that having package download stats would have been nice.. knowledge of are there really that many users in this scenario.

I agree. Am working on a number of things for the spkrepo, will see if we can revisit this (SynoCommunity/spkrepo#118).

[th0ma7]

@hgy59 and @mreid-tt two remaining things, 1) would you rather move subsequent exchanges to that other PR (if any still needed) - and 2) this PR is ready for merging from my perspective, a quick 👁️ from either of you would be appreciated.

[th0ma7]

I agree. Am working on a number of things for the spkrepo, will see if we can revisit this (SynoCommunity/spkrepo#118).

@mreid-tt that would be super nice to get this worked out - and thnx for your work on spkrepo, overdue and much appreciated :) Another thing that would be a nice-to-have is having a more modern look & feel for our web site - but that's clearly out of my league.

EDIT: Maybe there's someone on discord that has that skillset and would be willing to update it?