Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update default spksrc image to Debian12 #6183

Merged
merged 13 commits into from
Aug 27, 2024
Merged

Conversation

th0ma7
Copy link
Contributor

@th0ma7 th0ma7 commented Jul 28, 2024

Description

Update default spksrc image to Debian12

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

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

@th0ma7 th0ma7 requested a review from hgy59 July 28, 2024 13:35
@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 28, 2024

I've been struggling with my newer PR I've been working on due to the old Debian 11 package set, which also doesn't work well with DSM 7.2 due to older libc version. Above an update that I'll begin testing more in depth on my end and check if there's anything breaking elsewhere.

One thing that will require testing is the publishing that still relied on older python2 which is no longer available.

@hgy59
Copy link
Contributor

hgy59 commented Jul 28, 2024

@th0ma7 I already had a look at debian 12

what about using nasm (and yasm) from debian instead of native/nasm and native/yasm?

And I added python3-mako and python3-virtualenv but you probably have another solution for those...

And I would ommit man-db and manpages-dev since we never provide man pages in packages (due lacking man in DSM)

IMHO python2 is not available in debian 12 isn't it.

@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 28, 2024

@th0ma7 I already had a look at debian 12

what about using nasm (and yasm) from debian instead of native/nasm and native/yasm?

good idea, let's add them by default. for the time being framework could check if available in path, else use native.

And I added python3-mako and python3-virtualenv but you probably have another solution for those...

yup, python3-virtualenv already in, and I just hit mako on one of my PR so I'll definitively add it as well.

And I would ommit man-db and manpages-dev since we never provide man pages in packages (due lacking man in DSM)

well, as i am often running in my container as spksrc it is quite useful to have the man pages close by...

IMHO python2 is not available in debian 12 isn't it.

indeed, now gone.

@hgy59
Copy link
Contributor

hgy59 commented Jul 28, 2024

@th0ma7 IMHO you will get errors, since the install RUN command is too long (currently 1184 characters)

# ATTENTION: the total length of the following RUN command must not exceed 1024 characters

if we really need to install all those components, we have to split the installation into two RUN commands
e.g use a new RUN für apt-get clean...

@hgy59
Copy link
Contributor

hgy59 commented Jul 28, 2024

@th0ma7 As already mentioned somewhere, I suspected problems with old ppc archs under debian 12.

With recent tests I found that only a few packages fail to build for arch-ppc853x-5.2 under debian 12:

  • ffmpeg(4)
  • ffmpeg5
  • ffmpeg6
  • chromaprint
  • synocli-file
  • java-11-openjdk [is not supported, should use REQUIRED_MIN_DSM = 6.0]
  • synocli-devel
  • comskip

Further analysis of ffmpeg revealed an error in the Makefiles of ffmpeg

The following configure arg must not be defined for OLD_PPC_ARCHS, but only for qoriq

CONFIGURE_ARGS += --extra-libs=-latomic

otherwise configure fails with

/spksrc/toolchain/syno-ppc853x-5.2/work/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc is unable to create an executable file.

@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 28, 2024

With recent tests I found that only a few packages fail to build for arch-ppc853x-5.2 under debian 12:

Nice, well done if these are the only ones failing.

IMHO you will get errors, since the install RUN command is too long (currently 1184 characters)

In theory fixed now with the RUN division I've setup.

The following configure arg must not be defined for OLD_PPC_ARCHS, but only for qoriq

CONFIGURE_ARGS += --extra-libs=-latomic

I adjusted ffmpeg accordingly, now to be confirmed if this will run properly as ? if I recall ? changing the Dockerfile isn't replicated immediately to github-action but rather on subsequent PR after merge.

@th0ma7 th0ma7 self-assigned this Jul 28, 2024
@hgy59
Copy link
Contributor

hgy59 commented Jul 30, 2024

@th0ma7 you didn't update to debian 12 yet.
you have to replace bullseye by bookworm 😆

@hgy59
Copy link
Contributor

hgy59 commented Jul 30, 2024

@th0ma7 some more issues:

  • with bookworm gh is not a valid package
  • the third RUN must not end with && \

@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 30, 2024

@hgy59 sigh... clearly an oversight, thnx. now fixed (and tested locally) - should now be ok.

todo: adjust framework to make usage of local nasm and yasm by default if available.

@hgy59
Copy link
Contributor

hgy59 commented Jul 30, 2024

  • with bookworm gh is not a valid package

This was a false comment
with bullseye the gh package is not available, with bookworm it is.
But why should we have github command line tool?

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated
Comment on lines 93 to 97
# Install hg github tool
RUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg && \
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | tee /etc/apt/sources.list.d/github-cli.list > /dev/null && \
apt update && \
apt install gh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as commented, gh is installable in debian-bookworm without additional prerequisites...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thnx, now fixed and using default debian repository.

But why should we have github command line tool?

I figured, when things goes sideways gh can be quite handy to play with your repository. Totally optionnal, agreed, but as our project entirely sits under github, and its nice to have it around once in a while, it doesn't cost too much, further as now part of default debian repository.

I must admit, that I didn't had to use it in a while as I have a strong preference on git. Although there may be something to do with it for future download options ... Unless you disagree I'd keep it included for now on?

@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 31, 2024

BTW, thnx for the review @hgy59 as I've been pursuing this during the too litle spare time I have currently and while simple it definitively needs another pair of eye :)

@th0ma7
Copy link
Contributor Author

th0ma7 commented Jul 31, 2024

@hgy59 I've updated cmake rules to switch to use host nasm when available... Looking at the cross/* directory there would be other use cases to disable using native/nasm:

  • dav1d
  • ffmpeg4-5-6
  • lame
  • libvpx
  • openh264
  • x264

Wonder if it would be worth adding a GNU_CONFIGURE_USE_NASM similar to cmake ... ? That could handle the PATH and AS environment variable handling...

Any thoughts?

EDIT: Actually, maybe even a more generic variable name ?USE_NASM? or similar as for instance ffmpeg4-5-6 doesn't use gnu configure approach...

@th0ma7
Copy link
Contributor Author

th0ma7 commented Aug 20, 2024

@hgy59 I've been testing this new container image sucessfully since a few weeks already. Besides proposal above #6183 (comment) which can wait later, anything else missing before merging?

@th0ma7 th0ma7 merged commit 53a380a into SynoCommunity:master Aug 27, 2024
18 checks passed
@th0ma7 th0ma7 deleted the debian12 branch August 27, 2024 15:00
@th0ma7 th0ma7 mentioned this pull request Aug 27, 2024
10 tasks
@hgy59
Copy link
Contributor

hgy59 commented Aug 27, 2024

Wonder if it would be worth adding a GNU_CONFIGURE_USE_NASM similar to cmake ... ? That could handle the PATH and AS environment variable handling...

Any thoughts?

we don't need any nasm path nor native/nasm if nasm is a dev env prerequisite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants