Bump dockerfile to bookworm

[jisakiel]

Required for 7.2 builds in my tried experience, as some tools (bat) seemingly relied on the newer glibc shipped on the toolchain (2.33). Unfortunately this means python2 has to go, since it's well out of support. I'm uncertain of the impact of building (but I'd argue, given python2 is well out of support by now, if it's really needed it should be shipped in native/ instead).

Used to build synocli-files (what I was /actually/ trying here, some serious yak shaving in between) for 7.2 and arch-apollolake successfully.

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]

First, thnx for your contribution, it really is appreciated.

Two things that cones to mind:

1. Meson: probably best to maintain it ourselves through pip install as we can evolve the version more quickly than debian may be.
2. The publishing part used to be python2 specific from what i recall. Not sure if this will work with py3 and or if it needs adjusting? @hgy59 any idea?

Edit: also, all documentation needs to be updated to reflect this change. This is mainly the master readme.

[hgy59]

@th0ma7, @jisakiel it is not a solution to update the dev env (i.e. dockerfile) to the brand new Debian 12.

All builds must never depend on a library version in the dev env.
The problem with the rust tools failing to build for DSM 7.2 is based in the fact, that the DSM 7.2 toolchains are providing glibc v2.36 only and the failing tools expect glibc <= 2.34.

All rust tools fail to build for DSM 7.2 with errors like:

   Compiling autocfg v1.1.0
   Compiling libc v0.2.146
   Compiling cfg-if v1.0.0
   Compiling scopeguard v1.1.0
   Compiling crossbeam-utils v0.8.16
error: failed to run custom build command for `libc v0.2.146`

Caused by:
  process didn't exit successfully: `/spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build` (exit status: 1)
  --- stderr
  /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build)
  /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build)
  /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target/release/build/libc-d3efe7bce9d1ad22/build-script-build)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `dua-cli v2.17.2 (/spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2)`, intermediate artifacts can be found at `/spksrc/diyspk/dua/work-x64-7.2/dua-cli-2.17.2/target`
make[3]: *** [../../mk/spksrc.cross-rust.mk:59: rust_install_target] Error 101
make[3]: Leaving directory '/spksrc/cross/dua'

and

  ==> Cargo install rust package bat
  Installing bat v0.22.1 (/spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1)
    Updating crates.io index
   Compiling libc v0.2.146
   Compiling proc-macro2 v1.0.60
error: failed to run custom build command for `proc-macro2 v1.0.60`

Caused by:
  process didn't exit successfully: `/spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build` (exit status: 1)
  --- stderr
  /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build)
  /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build)
  /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target/release/build/proc-macro2-b3a4a8d2807c7603/build-script-build)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `bat v0.22.1 (/spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1)`, intermediate artifacts can be found at `/spksrc/diyspk/bat/work-x64-7.2/bat-0.22.1/target`
make[3]: *** [../../mk/spksrc.cross-rust.mk:59: rust_install_target] Error 101
make[3]: Leaving directory '/spksrc/cross/bat'
make[2]: *** [../../mk/spksrc.depend.mk:54: depend_target] Error 2
make[2]: Leaving directory '/spksrc/diyspk/bat'
make[1]: *** [../../mk/spksrc.spk.mk:625: build-arch-x64-7.2] Error 1
make[1]: Leaving directory '/spksrc/diyspk/bat'
make: *** [../../mk/spksrc.spk.mk:619: arch-x64-7.2] Error 2

[jisakiel]

@th0ma7, @jisakiel it is not a solution to update the dev env (i.e. dockerfile) to the brand new Debian 12.

All builds must never depend on a library version in the dev env. The problem with the rust tools failing to build for DSM 7.2 is based in the fact, that the DSM 7.2 toolchains are providing glibc v2.36 only and the failing tools expect glibc <= 2.34.

That was my point though - by moving the build environment to something with a newer libc (well, same 2.36, https://packages.debian.org/source/bookworm/glibc ) you pretty much bypass this problem. And I'd trust both libstdc++ and glibc's backwards compatibility, so that any older toolchains you might want will still work, leaving aside gcc becoming stricter over time.

The alternative to that is a full bootstrap of every native toolchain, which in fairness might be better, but it will definitely be slower to get up and running. Think the 3 stage gcc, glibc, etc.

I've successfully built synocli-files with this dockerfile for a 7.2-apollolake target.

[hgy59]

this PR got obsolete due #6183